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

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 17 Sep 2001 19:41:19 -0400

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 
-> <[email-masked]>, 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
-> > [email-masked]
-> > http://www1.ietf.org/mailman/listinfo/tsvwg
-> 

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Sam Liang <[email-masked]>
Date: Mon, 17 Sep 2001 18:25:01 -0700 (PDT)

Venkata,

  I took a look at the documents you suggested.  The first two
(atm2000.pdf and sld009.htm) presented some data to show that SCTP is TCP
friendly.  But I saw no experiements done and no data presented to show
TCP's alleged problem of head-of-line blocking and delay.  

  Also, doesn't TCP's urgent pointer offer a means to deliver out-of-band
data?

Sam

---

From: Jacob Heitz <[email-masked]>
Date: Mon, 17 Sep 2001 18:36:25 -0700

The urgent pointer does not point at a range, only at a single
byte. It can only deliver a single byte of out-of-band data.

---

From: John Wroclawski <[email-masked]>
Date: Mon, 17 Sep 2001 22:31:55 -0400

>byte. It can only deliver a single byte of out-of-band data.

Actually, TCP urgent delivers an out of band _notification_ of the 
presence of urgent _in band_ data.

(The idea being that on receiving the notification the app would know 
to chug through the data stream in whatever way it sees fit until it 
gets to the 'urgent' part.)

This was a well defined, useful semantic for canceling or aborting 
the processing of previously queued data - see telnet. But long ago 
various folks tried to contort it into actually delivering the data 
out of band. Since the protocol mechanism wasn't designed for that, 
it never worked very well, different implementations had different 
bugs/limitations, and things went downhill from there.

cheers,
john

---

From: "David P. Reed" <[email-masked]>
Date: Tue, 18 Sep 2001 10:45:35 -0400

The urgent pointer delivers no out of band data, except for the pointer itself.
What it does do is tell the receiver where in the upcoming stream it needs 
to "read" to in order to get urgent data.  The TCP recipient still needs to 
acknowledge all bytes up to that point - thus the stream remains 
ordered.  In the design of TCP (I designed the urgent pointer mechanism in 
1977 or so, as part of eliminating the entanglement of TELNET functionality 
with TCP), out-of-band data was deliberately not supported, since the same 
function could be achieved more simply and generally, by opening one or 
more parallel TCP connections for the out-of-band data.

> >   Also, doesn't TCP's urgent pointer offer a means to deliver out-of-band

- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Thu, 20 Sep 2001 10:09:47 -0400

>TCP's alleged problem of head-of-line blocking and delay.

Paul Lin (of Telcordia Technologies then) showed several plots
depicting the problem at the first sigtran meeting (or maybe
the BOF that led to sigtran's creation). The "alleged" problem is
real for transactions stuck behind the blocked/dropped
segment. Maybe Paul's slides they are archived in the
sigtran meeting minutes.

I think Paul is now at Intel ... but do not know if he is on tsvwg.

> >    http://www.ietf.org/internet-drafts/draft-rosenberg-sip-sctp-01.txt

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188