Re: [re-ECN] RE-ECN without ECN.

[Fred Baker <[e-mail]>]

On Oct 5, 2009, at 2:45 PM, Matt Mathis wrote:

> On Mon, Oct 5, 2009 at 3:03 PM, Fred Baker <[e-mail]> wrote:
>>
>> On Oct 1, 2009, at 9:36 AM, Matt Mathis wrote:
>>
>>> If you add the assumption that the network itself does not reorder
>>> packets, then the number of out-of-order packets is a direct measure
>>> of the upstream congestion.  (e.g. the first transmission was lost,
>>> and I see the retransmission).
>>
>> The assumption concerns me. There are probably places in the  
>> Internet where
>> loss is unusual and reordering is unusual, but making it a baseline
>> assumption... The Internet is still a best effort service, which is  
>> to say
>> that datagrams may be lost, duplicated, or reordered.
>
> Reordering is not insurmountable.   Network reordering is most often
> bound by some fairly small maximum offset related to the number of
> parallel paths or processing stripes.  Retransmissions are always
> out-of-order by slightly more than one full window of data.   At small
> window/low rates these are indistinguishable, but it probably isn't as
> important  to get it right.   At higher rates, these are likely to be
> different by an order of magnitude or more.  My hunch would be that a
> pretty simple adaptive controller might do well enough.

Well, yes, they are bounded, but that doesn't make them without effect.

Take for example one case that some of my customers report to be  
fairly common - the use of multiple parallel DSL, Frame Relay, or ect  
circuits at some point in their network. We have several ways of  
dealing with such, including both PPP Multilink (which tries to  
distribute load approximately evenly) and IP equal cost multipath  
routing. The latter can be used in a round-robin fashion or by hashing  
addresses as described in some RFC. the issue there is that in cases  
where reordering happens, it can be sustained for a while.