Re: Handling Packet Misordering?

[Fred Baker <[e-mail]>]

At 05:46 PM 9/9/2002 +0100, Poh Tze Ven wrote:
> > routing comes up with a multipath route, or changes the route that it is
> > using for a session, reordering can happen, and TCP should not break.
>
>  TCP does not break, but the performance degrades.

should it trigger the fast retransmit mechanism, yes. But it can also 
improve - if I alternate segments over two disjoint paths of speed 
<mumble>, my theoretical capacity is 2*<mumble>, and the degradation is 
against theoretical capacity. If actual capacity used exceeds <mumble>, I 
have a net improvement over using a single path. Or, if I am using a single 
path a routing changes, and I have a temporary reordering that triggers 
fast retransmit, the new route is likely to be stable, and the degradation 
will only last for a few RTTs after that before undegraded service is restored.

My point is that the real alternative to accepting resolution of reordering 
at the endpoints is doing something in the network while will guarantee 
sequential packet ordering. That is something that could be pretty 
interesting to design and implement in terms of complexity and brittleness 
added to the network, and very possible has the same effects.

For example, suppose we decide that MPLS is the solution to the world's 
problems in this area. Some say it is, and then ask "what was your 
question?". It would force packet order by forcing a single route - no 
multipath routes - and by forcing the network to drain the traffic in 
flight before imposing a new path when things change. Since TCP doesn't see 
the routing change, the process of draining the network necessarily 
involves dropping traffic, whether it is the traffic already in the 
pipeline when an MPLS path changes, or by denying new traffic entry to the 
network for a period of time, and maybe both.

Reordering has a certain probability of triggering fast retransmit - if the 
session has four or more packets outstanding (relatively unusual) and drops 
the first, the duplicate acks resulting from its successors will trigger 
fast retransmit. The probability is relatively low, though - you might want 
to read "TCP Behavior of a Busy Internet Server: Analysis and Improvements" 
in INFOCOMM '98 on that. Behaviors which trigger reordering, however, have 
a non-zero probability of delivering the traffic, while behaviors that drop 
the traffic during the re-route event by definition do not. Which has a 
greater effect on TCP, and on the applications it supports?

If you want to re-design fast retransmit to do so better, such as is done 
in New Reno or in SACK, I'm all for that. But I really don't think that the 
network behaviors which might eliminate reordering are improvements. They 
require the network to support additional complexity, which itself is prone 
to failures, and their cure may be worse than the disease.