Re: Some clarifications

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

I misunderstood what you guys mentioned in the BOF...  I was wondering what
Jim's callback channel was.  Since TCP stream is bidirectional, I thought
Jim was asking for some channel which expedited data could be sent, outside
the original TCP stream.  So I guess what he was asking for was a mux.

> 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 think it is very easy.  For one thing, unless you use T/TCP, you
need to pay the initial 3-way handshake cost when opening multiple TCP
connections to the same host.  Sharing window (congestion and send) info
among multiple TCP connections need a lot of thoughts.  Note that a lot of
existing implementations already have some form of state sharing.  RTT, RTT
variance, cong window threshold, and MSS info are shared and are used to
initialize TCP connections.  But this does not solve the problem you are
talking about.

BTW, a mux over TCP means that if a packet of one session is dropped, all
packets from other sessions, depending on the window size, may have to be
delayed until the dropped packet is recovered.  With multiple TCP streams,
this is not a problem.  But to me, a mux over TCP is easier to understand
and implement than sharing TCP states (correctly) and let TCP do the work
(correctly again).

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

So I guess you guys want an API which gets info like netstat does.  BTW,
the TCP_MAXSEG socket option gives you the segment size.  It is implemented
in many TCP stacks.  Maybe people on this mailing can write a document which
lists those info needed and propose to have them added to socket API.

							K. Poon.
							kcpoon@eng.sun.com

Received on Monday, 14 December 1998 22:18:35 UTC