Re: Handling Packet Misordering?

Fred Baker <fred@cisco.com> Mon, 09 September 2002 20:54 UTC

Message-Id: <5.1.1.6.2.20020909135008.02a28860@mira-sjcm-4.cisco.com>
X-Sender: fred@mira-sjcm-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Mon, 09 Sep 2002 13:54:40 -0700
To: raj@cup.hp.com
From: Fred Baker <fred@cisco.com>
Subject: Re: Handling Packet Misordering?
Cc: tcp-impl@grc.nasa.gov
In-Reply-To: <3D7D0067.6D1B6FC7@hp.com>
References: <5.1.1.6.2.20020906181142.02c09348@mira-sjcm-4.cisco.com> <5.1.1.6.2.20020909120131.01dbfaf0@mira-sjcm-4.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1290
Lines: 25

At 01:11 PM 9/9/2002 -0700, Rick Jones wrote:
>Wouldn't four or more segments outstanding on a
>session/connection/flow/whatever :) being relatively unusual imply that
>there would relatively little improvment (for that
>session/connection/flow/whatever) from a load balancing scheme that
>spreads packets of a given session/connection/flow/whatever across
>multiple links?

it does suggest that.

>Should we distinguish between eliminating reordering and not doing
>things that may reorder as a frequent matter of course?

I'm not sure that we encourage reordering "as a frequent matter of course" 
now. Many routers have the option of distributing traffic round-robin on a 
multi-path route, but most that I am aware of default to sending any 
specific microflow along a specific sub-path of that route, by such 
techniques as hashing the flow signature (source/destination address and 
perhaps more) and using the hash to deterministically select a route. The 
other behaviors that can cause reordering, such as changing routes, happen 
infrequently and are presumably necessary to implement a routing policy or 
avoid something worse, such as not having a route that works.

What I understood the original request to be was "eliminate reordering". 
That is what I have been addressing.