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

[David P. Reed]

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.

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