[46711] in North American Network Operators' Group
Re: packet reordering at exchange points
daemon@ATHENA.MIT.EDU (Stephen Sprunk)
Mon Apr 8 21:56:16 2002
Message-ID: <00b301c1df69$5561d6c0$e1876540@amer.cisco.com>
From: "Stephen Sprunk" <ssprunk@cisco.com>
To: "Iljitsch van Beijnum" <iljitsch@muada.com>,
"Paul Vixie" <paul@vix.com>
Cc: <nanog@merit.edu>
Date: Mon, 8 Apr 2002 20:52:50 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Errors-To: owner-nanog-outgoing@merit.edu
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, ...
> 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. The problem with RTP is that if the
packets don't follow a deterministic path, the header compression scheme is
severely trashed. Also, non-deterministic paths tend to increase jitter,
requiring more bufferring at endpoints.
S
