[e2e] What's the benefit of out-of-order processing?

[Craig Partridge]

I suspect some SCTP folks will have better answers, but here's a
small perspective.

About 14 years ago I did a little bit of study with RDP (RFC 908).
RDP supported out-of-order delivery of segments.

You could get some performance leverage by delivering segments as they
arrived to applications that knew where to put the segments in their
memory or disk (so, for instance, file transfer went a bit faster because
the receiving system was almost always saving data to the file -- it didn't
get the feast/famine mode that TCP gives you when a segment gets dropped).  

Craig

In message <200109171954.MAA30066 at Pescadero.DSG.Stanford.EDU>, Sam Liang writes
:

>
>  RFC2960 for SCTP lists the lack of out-of-order processing as the first
>major drawback of TCP:
>
>   "TCP provides both reliable data transfer and strict order-of-
>    transmission delivery of data.  Some applications need reliable
>    transfer without sequence maintenance, while others would be
>    satisfied with partial ordering of the data.  In both of these
>    cases the head-of-line blocking offered by TCP causes unnecessary
>    delay."
>
>  Is there any study done on evaluating the effect of this TCP
>"deficiency"?  What applications really need to and are capable to do
>out-of-order processing? Can video over IP or voice over IP applications
>process frames out-of-order? With SCTP's order-of-arrival delivery, how
>much performance boost can be achieved over TCP, in terms of increased
>throughput and reduced delay?
>
>  Thanks,
>
>Sam
>