Re: [ draft may be of interest]

On Thu, 13 Jun 1996, Jon Crowcroft wrote:
>  >I've completed and submitted an internet draft on
>  >TCP Control Block Interdependence, which has some 
>  >observations on how to augment TCP implementations
>  >to provide performance similar to persistant-TCP
>  >layerings, without the multiplexing hazards.
> as with T/TCP, this seems orthogonal to persistent HTTP......
> (if only for deployment reasons), but a nice piece of work....
> and academically, a more satisfactory approach.....but just hard to

Yeah - I had a quick glance at the paper, and it seems to be advocating 
something I think I raised at either SIGCOMM or the TCP-prob or TCP-NG bof a 
couple of IETFs ago - sharing of congestion control and RTO information 
between multiple connections on the same machine. 

I've always argued that this is absolutely essential for T/TCP, and the 
ultimate solution has some nice advantages over the HTTP-NG approach apart 
from moving complexity out of the application; the most important are a 
limited  ability to cope with out-of-order delivery (if a packet for one 
connection is lost, any following packets for different connections can 
still be processed).

Unfortunately, to be done properly, it requires changes in every single
TCP stack on the net. As you may have noticed from the nearly universal
deployment of IPv6, this is quite simple :-) The only way a solution like
this could be deployed in a decent timeframe would be if T/TCP with
sharing were reimplemented at the user level.  This places a pretty nasty 
hurdle in front of any implementor.

The SCP approach of interleaving different sessions over TCP stream seems 
to be the only  solution suitable for deployment today. It's a stopgap 
measure, and it seems to stop the gap pretty well now.

IMHO TCP is going to become less important in terms of bytes carried as
time goes on - media specific transport protocols are much better suited 
for things like images, video, and sounds; the HTTP-NG philosophy is that 
eventually TCP or it's replacement will basically just be used for text 
and for control messages.


Received on Thursday, 13 June 1996 13:48:24 UTC