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

Naidu, Venkata Venkata.Naidu at Marconi.com
Mon Sep 17 16:41:19 PDT 2001


All:

   Interested guys can look at SCTP Performance over TCP
   (How strict ordering introduces head of line blocking and delay)
   http://tdrwww.exp-math.uni-essen.de/pages/forschung/atm2000.pdf
   http://www.ietf.org/proceedings/00jul/SLIDES/sigtran-bakeoff/sld009.htm

   Yes! Megaco/H.248 over SCTP has been proposed!
   http://www.ietf.org/proceedings/00dec/I-D/draft-ietf-megaco-h248h-00.txt
   
   There were proposal for SIP & LDP over SCTP but not accepted!
   http://www.ietf.org/internet-drafts/draft-rosenberg-sip-sctp-01.txt   
  
--Venkata Naidu


-> 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
-> 



More information about the end2end-interest mailing list