Subject: Re: connection bonding?
To: None <mouse@Rodents.Montreal.QC.CA>
From: Havard Eidnes <>
List: tech-net
Date: 12/14/2005 01:22:57
> > The agr(4) man page hints at the issue.  The problem is that you
> > *really* don't want TCP segments from a single connection arriving
> > out of order.  While TCP semantics guarantee that things will work,=

> > it will cause a tremendous performance hit.
> Surely that's a (performance) bug in the TCP stacks?

Well, actually, it's the other way around.  This goes back to the
modifications done to TCP by Van Jacobson to optimize the common case,
i.e. shaving instructions from the common path, which was done back in
the day when filling a 10Mbit/s Ethernet was a challenge with a Sun-3,
if I recall correctly.

So...  It's the common path which has been optimized, not the result
of a performance bug in the TCP stack.

Besides, for normal traffic rates, as observed on wide-area Internet
connections, the impact is not "tremendous", it is only an issue when
you close in on 100% CPU load due to network stack processing.  For
those shooting for high performance transfers, this is an issue one
needs to take into consideration, but for "normal" connections I would
claim that the impact is rather insignificant.

> > In particular, if a sender receives 3 duplicate ACKs in a row, it
> > slams its congestion window shut and restarts the whole slow start
> > business.
> Wouldn't it make more sense to either be less hair-trigger in the
> congestion detection algorithms or also implement some kind of
> reordering detection to avoid this?  Assuming the network won't reord=
> packets really strikes me as a modern version of the "everything is o=
> a fast LAN" problem that many Berkeley network programs suffered from=
> and which got smoked out once IP started getting used over longer
> paths.

Well, as Steven M. Bellovin say, improving TCP is still an active
research topic.  There are some basic limitations when proposing a new
TCP variant: e.g. it must be fair to other TCP traffic (also older
implementations).  Tweaking TCP's congestion control algorithm is not
something which should be undertaken on a whim.


- H=E5vard