Re: Some clarifications

>The issue comes up of how to use the return from the server;
>traditionally, most protocols just use the TCP stream to return
>responses and/or errors, and you can't interspearse other traffic over
>the return channel.

This was my question.  From your description in the BOF, it seemed to me
that HTTP needed an out of band (OOB) channel, what you called call back
channel.  Currently, TCP does not have such a thing.  By OOB channel, I
mean a stream which is not constrained by the original TCP stream.  This
means data sent/received in the OOB channel is independently handled.  My
question is if there is such a OOB channel, how it will be used?  

>Once you have a multiplexing layer that enables its use, if the server 
>needs to call back the client, this is easy and much faster to do over 
>an existing TCP connection than establishing a new TCP connection, which 
>saves packets, the round trip times to establish a connection, and it may
>not even be possible to establish a separate TCP connection (think about
>how firewalls work. 

Mutiplexing is not what I really meant.  By multiplexing several application
streams over a single TCP stream, all those streams are still constrained by
the single TCP stream.  The constraints are the result of TCP's requirement
of in-order delivery of segments.  An OOB channel does not have this problem.
You may ask about all those congestion control/avoidance, timer, ... of the
OOB channel.  But I think we need to understand if such an OOB channel is
useful, and how it is going to be used before we can decide how those things
are to be handled, hence my original questions.  I want to know if my
understanding of the requirement is correct.

If the OOB channel is only used for a small amount of "expedited" data, the
whole problem can be much more easily solved in the existing TCP with some
modifications.  But if the OOB channel is going to be used just like another
TCP stream, it is probably not possible because what you want is really 2
streams.

>If you are doing a distributed object system on top, your natural programming
>model is to send object references around that get called; method invocations
>in this sense often invert client and server to get thie jobs done.  We exploit
>this in the prototype HTTP-NG implementation; if there is a callback to
>an object on the "client", it goes over a new session we establish
>in the MUX over the same TCP connection, rather than establishing a new
>connection, saving a connection establishment (with the multiple packets
>and RTT's as a result).  As RTT's are large in the Internet, this is a major
>win for many uses.

Going a level lower, does this kind of call back require a substanial amount
of data being sent?  By substanial, I mean more than 1 or 2 TCP segments.  In
today's Internet, you may assume 1 TCP segment can take about 1 KB data.

>And about the most commonly asked for feature of the Web is some way to 
>provide notifications.  I've had people describe to me amazingly gross
>ways of doing really ugly things inside of HTTP to do this.  Yuk....

By notification, did you mean the server wanted to send some control data
while it was still busy sending response data to the client?

Can you also explain your requirements about getting more info from TCP?  I
guess this was what you meant by a better socket API.  Please correct me if
this is not what you meant.

							K. Poon.
							kcpoon@eng.sun.com

Received on Tuesday, 8 December 1998 18:01:11 UTC