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

[Jon Crowcroft]

In message <200109180529.WAA01620 at Pescadero.DSG.Stanford.EDU>, Sam Liang typed:

 >>> 
 >>> Congestion control is useful, but it is not an "application benefit" (at 
 >>> least directly).  Out of order delivery has *nothing* to do with whether 
 >>> congestion control signals are sent, or how their coding (as ACKs or 
 >>> whatever) reflects their meaning.
 >>
 >>  I certainly was not saying out-of-order delivery had anything directly
 >>to do with congestion control signals.  Because Amr was suggesting a way to
 >>transfer a large file that didn't send any ACKs until the end, I was
 >>asking if no intermediate ACKs were sent back, how did the sender detect any
 >>congestion condition.  Of course if you want, you can invent other ways to
 >>report congestion condition.  But it won't be trivial.

Sam


most people working on a variety of techniques for
congestion control for multicast transport protocols have 
had to tackle the problem of efficient sampling of congestion
conditions without a "full on" feedback channel - c.g. 
pgmcc: A TCP-friendly Single-Rate Multicast Congestion Control Scheme 
Luigi Rizzo (Universita di Pisa) 
http://www.acm.org/sigcomm/sigcomm2000/conf/abstract/1-2.htm
and
Extending Equation-Based Congestion Control to Multicast Applications
Joerg Widmer (University of Mannheim), Mark Handley (ACIRI)
in sigcom2001
http://www.acm.org/sigcomm/sigcomm2001/p22.html
and the also mentioned receiver based schemes by vicisano and also
used by luby et al...

also, the HIPPARCH project did a bunch of work on ALF type protocols -
see
http://www.docs.uu.se/hipparch/
for links to papers

 >>
 >>
 >>> 
 >>> At 04:06 PM 9/17/2001 -0700, Sam Liang wrote:
 >>> >Amr,
 >>> >
 >>> >   You suggested an interesting way to transmit a large file.  However,
 >>> >just as you alluded to, how are you going to do congestion control if you
 >>> >don't send back any intermediate feedback with ACKs?  Congestion control
 >>> >is a complicated problem.
 >>> >
 >>> >   You want to reduce the number of ACKs the ftp server processes, I think
 >>> >we should try to figure out a way to reduce the ACK frequency, which still
 >>> >provide certain feedback to the sender for congestion control purpose.
 >>> >
 >>> >Sam
 >>> >
 >>> >
 >>> > >
 >>> > > Large file downloads is a very good example application. For example, a 
 >>> > 1GB
 >>> > > can be sent in any order with no retransmission, then at end of the 
 >>> > cycle a
 >>> > > single NACK is sent for all missing packets and then iteratively go 
 >>> > through
 >>> > > the next batch and so on until all packets belonging to the file are
 >>> > > delivered. Some loss signaling will still be needed for TCP congestion 
 >>> > control
 >>> > > to work. This might not lead to much improvement of goodput (since all 
 >>> > packets
 >>> > > still need to be delivered), but it simplifies the task of an ftp 
 >>> > server with
 >>> > > many receivers, since it does not need to handle as many ACK packets.
 >>> > >
 >>> > > Take a look at the work from digital fountain:
 >>> > >
 >>> > > http://www.digitalfountain.com/technology/library
 >>> > >
 >>> > > -- Amr
 >>> > >
 >>> > > Sam Liang wrote:
 >>> > >
 >>> > > >   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
 >>> > > >
 >>> > > >
 >>> > >
 >>> > >
 >>> > >
 >>> 
 >>> 
 >>

 cheers

   jon