Re: [hybi] Multiplexing extension spec draft 03

[Takeshi Yoshino <[e-mail]>]

Hi Greg,

Thanks for commenting throughout.

On Tue, Feb 28, 2012 at 19:03, Greg Wilkins <[e-mail]> wrote:

>
> 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?
>
>
John, may I confirm what this text is intended to mean?


> 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?
>
>
I wondered if it's useful if there's a choice to drop only one logical
channel. As quota is independent among logical channels, we don't have to
close the physical channel.

But yes, as you said, this means there's bug in the sender's multiplexing.
If no one opposes, I'll change this to _Fail the Physical Channel_ from the
next version.

>    This send quota is
>    replenished via control frames as the receiver processes the data.
>
> s/This/The/
>

Thanks


>
> 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:
>
>
Just used the same formatting as RFC 6455. But yes... for this case, it's
just making it ugly. I'll remove them.


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

ok


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

ok


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

>       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" ?
>
>
"plain" sounds good. how about identity as like content-encoding of HTTP?


>       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?
>
>
ok. it might be misleading to say this within the context of quota. We
should just say "any frame MUST not be sent over the logical channel until
AddChannel response is received" somewhere else. I'll try to fix this.


>    3 - DropChannel
>
> Can a dropped channel be readded later?
>
>
Hmm. One case we need to consider is:

- S sends a frame(ID=1, body="blah")
- C issues a DropChannel(ID=1)
- C issues a AddChannelReq(ID=1)

We need to be able to determine if the data frame should be dropped or not
when these three happen at almost same time.

But I think this is not a problem. C should drop any frame received after
issue of DropChannel but before AddChannel response.

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
>

This text is intended to note that a receiver can try to maintain fairness
of inbound traffic between logical channels even if the sender doesn't
employ good algorithm to assign transmission slot to each logical channel.
That's why there's "on the sender".

Hmm, but maybe I should revise this like...

The receiver MAY limit the send quota of a logical channel by not
replenishing it to make sure that any logical channel doesn't dominate the
connection.


>
> 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.
>
>
OK. Let's add some text to note that point.


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

Great. I'll take it.


>
>    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?
>
>
Ah,... maybe I've duplicated.


>
>
> 13.  Nesting
>
> I think we should disallow nesting.  Any intermediary that wants to MUX
> channels understands MUX, so it can flatten.
>
>
Thanks for opinion.