[46707] in North American Network Operators' Group
Re: packet reordering at exchange points
daemon@ATHENA.MIT.EDU (E.B. Dreger)
Mon Apr 8 19:20:25 2002
Date: Mon, 8 Apr 2002 23:19:56 +0000 (GMT)
From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: Paul Vixie <paul@vix.com>, nanog@merit.edu
In-Reply-To: <20020409002240.X76423-100000@sequoia.muada.com>
Message-ID: <Pine.LNX.4.20.0204082309170.1595-100000@www.everquick.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
> Date: Tue, 9 Apr 2002 00:32:50 +0200 (CEST)
> From: Iljitsch van Beijnum <iljitsch@muada.com>
> Obviously some applications care. In addition to the examples mentioned
> earlier: out of order packets aren't really good for TCP header
> compression, so they will slow down data transfers over slow links.
How about ACK? I think that's the point that Richard was
making... even with SACK, out-of-order packets can be an issue.
> But how is packet reordering on two parallell gigabit interfaces ever
> going to translate into reordered packets for individual streams? Packets
Queue depths. Varying paths. IIRC, 802.3ad DOES NOT allow round
robin distribution; it uses hashes. Sure, hashed distribution
isn't perfect. But it's better than "perfect" distribution with
added latency and/or retransmits out the wazoo.
> 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.
What MTU? Compare to jitter multiplied by line rate.
--
Eddy
Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@brics.com>
To: blacklist@brics.com
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@brics.com>, or you are likely to
be blocked.
