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

[Qiaobing Xie]

This out-of-order processing service was specifically required by MEGACO
folks at one point (don't know whether they still use it). Some of
MEGACO messages were transaction-oriented and always carried a
transaction ID inside, this means that the receiver can often process
them independently.

The same is true for other transaction-oriented applications, such as
database query services.

-Qiaobing

Craig Partridge wrote:
> 
> 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
> >
> 
> _______________________________________________
> tsvwg mailing list
> tsvwg at ietf.org
> http://www1.ietf.org/mailman/listinfo/tsvwg