Re: Some clarifications

> From: Henrik Frystyk Nielsen <frystyk@w3.org>
> Date: Sun, 13 Dec 1998 18:08:13 -0500
> To: <kcpoon@eng.sun.com>, "Jim Gettys" <jg@pa.dec.com>, <kcpoon@eng.sun.com>
> Cc: <ietf-http-ng@w3.org>
> Subject: Re: Some clarifications
> -----
> At 15:44 08/12/1998 -0800, Kacheong Poon wrote:
> >>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? 
> 
> The WebMux model is more symmetric than what I think you are referring to
> with your OOB channel. For example, I expect that in many cases, the role
> of the server and client will simply swap so that the server can initiate a
> new channel to the client and send a request. There should be no
> constraints on the amount of data going in either direction.

This kind of call back is common in distributed object systems.

> 
> Jim mentions some scenarios where this is useful. Another example is an
> inter-cache communication where two caches can cooperate as two peers in a
> Web of caches and not only as a downstream vs. upstream cache.

Good example.

> 
> Maybe your question is really whether we need to be able to prioritize
> streams either from the client to the server or the other way. In fact, we
> have been discussing this as there are several scenarios where this comes
> up in typical Web applications. My feeling is that it should be done at a
> higher layer and not try and deal with it in neither TCP nor WebMux.
> 
> Note that there is no reason why bidirectionality can't be done in TCP
> already and if peers can reuse state then this may be just as efficient as
> what we are attempting to do in WebMux. I don't believe that the firewall
> argument is useful here as I can't see why firewall administrators should
> be more willing to have outgoing Mux channels than outgoing TCP
> connections. However, I don't think your question is whether WebMux can be
> done completely in TCP (in fact it can't) so I will not dive into this
> discussion here.

The issue is one of initiation: a firewall admin is much more comfortable
if the application is known to have been started on behalf of someone
inside the firewall.  (I speak as one once upon a time responsible for
Digital's major Web firewall relay).  The information a firewall
admin most wants/needs are:
	o who is making the request.
	o what protocol is being relayed (so that it can be verified that
	that is actually being used).
	o what type of content is being transferred.

Mux makes a firewall only slightly harder to engineer, and it provides
at least as good identification of what protocol(s) are in use.

> 
> >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.
> 
> Yes, this is what we have in mind. When we implemented HTTP/1.1 with
> persistent connections, pipelining, and output buffering, it would have
> been extremely useful for us to have had access to segment sizes, timers,
> etc. The best we can do for now is to guess these parameters.
> 

And there are times one really wants such information.

For example, say you have a highly interactive application.
Most socket buffers are quite large, and you can have many seconds
of data "stuck" in the socket buffers.  If the bandwidth observed is
low, you may really want/need to avoid writing (committing to transmission)
data into the socket buffers.

But the socket interface currently hides the information required for
an application to adapt its behavior.

We plan to write up a note to circulate what problems we have using
TCP and the problems we have with the current socket interface.
				- Jim

Received on Monday, 14 December 1998 12:30:10 UTC