Re: [hybi] Multiplexing extension spec draft 03

[Greg Wilkins <[e-mail]>]

Some comments


3.

   If WebSocket payload data is masked by a per-frame key, such masking
   is applied to frames for each logical channel separately.


I'm not sure what it means to apply masking to a logical channel
separately?  Surely a mask is applied to the frame that carries it before
the MUX extension interprets the payload?

5.  Flow Control   Each logical channel, including the implicitly
created channel 1, is
   initially given a quota of bytes that may be transmitted in each
   direction without acknowledgement.  It is illegal to send more bytes
   than the remaining send quota, and the receiver MUST _Fail the
   Logical Channel_ for any sender that does so.

Should this not be a failure of the physical channel as it indicates a
failure of the other ends MUX implementation?

   This send quota is
   replenished via control frames as the receiver processes the data.

s/This/The/

7.  Multiplex Control Frames

nice clarifications in this section! - specifically "Objectve channel ID"

Is the text diagram a standard?  I find the + - - - - - + lines confusing
and would prefer to see:

      0 1 2 3 4 5 6 7
     +---------------+
     | Objective     |
     : channel ID    :
     | (8-32)        |
     +-----+---------+
     | Opc | Opcdata |
     +-----+---------+
     | Additional    |
     : data          :
     | (0-?          |
     +---------------+


7.1.  Multiplex Control Opcodes   0 - AddChannel request (only from client)
      Create a new logical channel, exactly as if a new connection were
      received on a separate transport connection,

s/exactly //
s/a new logical channel/the objective channel/

probably need to state somewhere that it is an error to add and already
added channel.


      0 - uncompressed

This is a bad name for this encoding scheme as it implies there is a
compressed scheme (OK delta encoding is a compression... but you know what
I mean).   How about calling this "absolute" or "complete" or "plain" ?

      The initial quota for the new logical channel is 0, so the client
      may not send any data for this connection until the AddChannel
      response is received.

Does this mean that control frames can be sent for a channel before the add
channel response is received?

   3 - DropChannel

Can a dropped channel be readded later?

11.  Fairness

   A multiplexing implementation MUST ensure reasonable fairness among
   the logical channels.  This is accomplished in several ways:

   Receiver side

   o  The receiver MAY limit the other peer's send quota of a logical
      channel by not replenishing the send quota to make sure that any
      logical channel cannot dominate its buffer space on the sender.

s/on the sender//   as it is the buffer space on the receiver that is of
concern

Also we should say that the receiver does not need to process frames from
different logical channels serially.  ie the processing of a message from a
logical channel should not defer the processing of messages on other
logical channels.

   o  The sender MUST fragment a message into smaller frames when it's
      too big so that that logical channel will occupy the connection
      and the other logical channels get stuck for long time.

Cumbersome.  How about: The sender MUST fragment a large message into
smaller frames to prevent a large message in a logical channel occupying
the physical channel and thus delaying messages in other logical channels.

   o  Logical channel frames that are sent SHOULD be limited in size
      (such as by refragmenting) when there is contention for the
      physical channel to minimize head-of-line blocking

How is this different from the previous?



13.  Nesting

I think we should disallow nesting.  Any intermediary that wants to MUX
channels understands MUX, so it can flatten.



cheers