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

[Sam Liang]

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


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