W3C home > Mailing lists > Public > www-http-ng-comments@w3.org > July to September 1998

Re: draft-gettys-webmux-00.txt

From: Scott Lawrence <lawrence@agranat.com>
Date: Thu, 06 Aug 1998 20:27:42 +0000
Message-ID: <35CA11BE.1ADE342E@agranat.com>
To: HTTP-NG Comments <www-http-ng-comments@w3.org>
1. Reserved Session IDs (nit)

  > Each session is allocated a session identifier. Session
  > Identifiers below 0 and 1 are reserved for future use.

  The declaration of the w3mux_hdr session_id field declares it as
  unsigned; given that, what is the meaning of 'below 0'?

2. Session ID allocation

  > Session IDs allocated by initiator of the transport TCP connection
  > are even; those allocated by the receiver of the transport
  > connection odd.

  The 'initiator' of a TCP connection is ambiguous; TCP connections
  may be created by a simultaneous open in both directions - both
  parties see themselves as the initiator.  Not an issue in current
  HTTP usage, since HTTP/1.x servers don't create connections, but a
  problem if this is to be a general purpose protocol.

  Even in the HTTP case one can easily envision that this could be a
  problem for hierarchical proxies:

      client <-1-> proxy-A <-2-> proxy-B <-3-> server

  Picture an architecture in which proxy-A and proxy-B are configured
  to know about each other (B may be the only way A can go - it exists
  to save bandwidth on slow link 2) and bring connection 2 up
  immediately when they initialize.

  I'm also not clear on how session ids are selected by one party when
  in the section on Endpoints the draft says:

  > To establish a new session, the initiating end sends a SYN
  > message, allocating a free session number out of its address
  > space.

  and in the section on End Points:

  > A MUX protocol ID only identifies a MUX channel relative to a
  > particular "endpoint". The pair of <endpoint><protocol ID>
  > completely identify a MUX channel, without regard to IP address,
  > TCP port, or other information. Endpoint IDs are URI names for
  > endpoints. Any endpoint may have multiple endpoint IDs. We do not
  > place any further restrictions on the types of URIs that are used
  > as endpoint IDs.

  ... if the endpoint is not dependant on "IP address, TCP port, or
  other information", then how do I know whether or not a given
  session id is available at the other end?

  It may be that I'm being confused here by the lack of a definition
  for the term 'MUX channel', and the fact that an 'Endpoint' is only
  defined in terms of the messages that describe it.  What exactly is
  an 'Endpoint' and how does it relate to what in other protocols is
  described as a Service Access Point (that is, some identifier
  provided by a lower layer to an upper layer)?

3. Flow Control

  The initial credit per session is given as 16K bytes; in memory
  constrained environments that may be large enough to trigger the
  deadlock scenarios you describe in the introduction.

  The SetMSS message sets the maximum fragment size across all
  sessions - wouldn't it be better named SetDefaultMFS? and might it
  be usefull to have a SetMFS that applied only to the session it is
  sent on?

  Similarly, I don't see a definition for the maximum allowed fragment
  size at the start of a connection.

  Why are AddCredit and SetDefaultCredit described as R->T rather than
  Both?  Either party may be a receiver.

4. What are the appropriate strategies for determining if the WebMUX
   protocol can be used?

  Shouldn't this just be a (new) well known TCP port?  WebMUX already
  includes a mechanism for describing the next layer above it.  HTTP
  servers that support http over mux would listen on both 80 and the
  new WebMUX TCP ports.

  This leaves open the problem of discovery by clients that the WebMUX
  is available, but we could define a new HTTP response header to be
  returned (I can't think of a currently defined one that meets the
  need) to indicate the availability of mux as an alternative for
  subsequent requests.

  We could define a new response code 102 WebMUX; if the server had
  WebMUX available on its well known port, it could return '102 CRLF
  CRLF' before the final response when a request is received on port
  80; 7 bytes overhead that allows the client to discover the
  availability of WebMUX for subsequent interactions with that server.

  Upgrade could also be used to switch an existing HTTP connection
  from HTTP to WebMUX if the client indicated readiness to do so by
  sending an 'Upgrade: WebMUX/1.0' request header.

5. Message Formats (nit)

  It always makes me nervous to see wire protocol message formats
  expressed as C structures - C compilers don't translate them
  uniformly to bits on a wire.

  Here is my rendering of the two header formats in graphical form.

  Data Message

          8        1 1 1 1 1 1               18
  |               | |S|F|R|P|L|                                   |
  |  Session Id   |0|Y|I|S|S|N|   Fragment Size                   |
  |               | |N|N|T|H|G|                                   |
  |                                                               |
  |  Long Fragment Size (present only if LNG == 1)                |
  |                                                               |

  Control Message

          8        1    4    1               18
  |               | |       |L|                                   |
  |  Session Id   |1|Control|N|   Fragment Size                   |
  |               | | Code  |G|                                   |

  |                                                               |
  |  Long Fragment Size (present only if LNG == 1)                |
  |                                                               |

Scott Lawrence           Consulting Engineer      <lawrence@agranat.com>
Agranat Systems, Inc.  Embedded Web Technology   http://www.agranat.com/
Received on Thursday, 6 August 1998 16:26:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:37:19 UTC