[112791] in North American Network Operators' Group
Re: Shady areas of TCP window autotuning?
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Mar 18 09:25:46 2009
Date: Wed, 18 Mar 2009 08:25:35 -0500
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <20090318072725.M9898@bts.sk>
Errors-To: nanog-bounces@nanog.org
--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Wed, Mar 18, 2009 at 09:04:42AM +0100, Marian ??urk=
ovi?? wrote:
> It's fine to have smaller buffers in the high-speed core, but at the edge=
you
> still need to buffer for full RTT if you want to fully utilize the link w=
ith
> TCP Reno. Thus my conclusion holds - if we reduce buffers at the bottlene=
ck
> point to 50 msec, flows with RTT>50 msec would suffer from reduced throug=
hput.
Ah, I understand your point now. There is a balance to be had at
the edge; the tuning to support a single TCP stream at full bandwidth
and the tuning to reduce latency and jitter are on some level
incompatable; so one must strike a balance between the two.
Of course...
> Anyway we probably have no other chance in situations when the only avail=
able
> queueing is FIFO. And if this gets implemented on larger scale, it could =
even
> have a positive side-effect - it might finally motivate OS maintainers to
> seriously consider deploying some delay-sensitive variant of TCP since Re=
no
> will no longer give them the best results.
Many of the problems can be mitigated with well known queueing
strategies. WRED, priority queues, and other options have been
around long enough I refuse to believe they add significant cost.
Rather, I think the problem is of awareness, far too few network
engineers seem to really understand what effect the queuing options
have on traffic.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--1yeeQ81UyVL57Vl7
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFJwPZONh6mMG5yMTYRAhpkAJ994zxsGvknBruj5C/jC1RPvG86uACgg/Y2
J5VyMygPFalaHCRBA3rSF0s=
=ShEk
-----END PGP SIGNATURE-----
--1yeeQ81UyVL57Vl7--
