Re: packet reordering at exchange points

[Iljitsch van Beijnum <iljitsch () muada com>]

On Mon, 8 Apr 2002, Stephen Sprunk wrote:

> Thus spake "Iljitsch van Beijnum" <iljitsch () muada com>
> > But how is packet reordering on two parallell gigabit interfaces
> > ever going to translate into reordered packets for individual
> > streams?

> Think of a large FTP between two well-connected machines.  Such flows tend
> to generate periodic clumps of packets; split one of these clumps across two
> pipes and the clump will arrive out of order at the other end.  The
> resulting mess will create a clump of retransmissions, then another bigger
> clump of new data, ...

I don't think it will be this bad, even if hosts are connected at GigE and
the trunk is 2 x GigE. In this case, a (delayed) ACK will usually
acknowledge 2 segments so it will trigger transmission of two new
segments. These will arrive back to back at the router/switch doing the
load balancing. Since there is obviously need for more than 1 Gbit worth
of bandwidth, it is likely the average queue size is at least close to 1
(= ~65% line use) or even higher. If this is the case, there is a _chance_
the second packet gains a full packet time over the first and arrives
first at the destination.  However, this is NOT especially likely if both
packets are the same size:  the _average_ queue sizes will be the same so
in half the cases the first packet gains an even bigger advance over the
second, and only in a fraction of half the cases the second packet gains
enough over the first to pass it. And then, the destination host still
only sees a single packet coming in out of order, which isn't enough to
trigger fast retransmit.

You need to load balance over more than two connections to trigger
unnecessary fast retransmit (over two lines, packet #3 isn't going to pass
by packet #1), AND you need to send more than two packets back to back.
Also, you need to be at the same speed as the load balanced lines,
otherwise your packet train gets split up by traffic from other interfaces
or idle time on the line.

And _then_, if all of this happens, all the retransmitted data is left of
window. I'm not even sure if those packets generate an ACK, and if they
do, if the sender takes any action on this ACK. If this triggers another
round of fast retransmit, the FR implementation should be considered
broken, IMO.

> > Packets for streams that are subject to header compression or
> > for voice over IP or even Mbone are nearly always transmitted
> > at relatively large intervals, so they can't travel down parallell
> > paths simultaneously.

> RTP reordering isn't a problem in my experience, probably since RTP has an
> inherent resequencing mechanism.

My point is real time protocols will not see reordering unless they are
using up nearly the full line speed or there is congestion, because these
protocols don't send out packets back to back like TCP sometimes does. How
big are VoIP packets? Even with an 80 byte payload you get 100 packets per
second = 10 ms between packets, which is more than 80 packet times for
GigE = congestion. And if there is congestion, all performance bets are
off.

It seems to me spending (CPU) time and money to do more complex load
balancing than per packet round robing in order to avoid reordering only
helps some people with GigE connected hosts some of the time. Using this
time or money to overcome congestion is probably a better investment.

PS. For everyone looking at their netstat -p tcp output: packet loss also
    counts towards the out of order packets, it is hard to get the real
    out of order figures.

PS2. Isn't it annoying to have to think about layer 4 to build layer 2 stuff?