Subject: [hybi] Multiplexing: Pre-AddChannelResponse quota

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 28 May 2012 17:28:53 +0900

Hi all,

Sorry for delay on the decision making on the pre-response quota feature of
the multiplexing extension. Based on input on the list, I'm going to add
two extension parameters for use in the server's opening handshake of the
physical channel.

One is pre_handshake_quota. It indicates the number of bytes allowed to be
sent by the client before receiving an AddChannelResponse for each logical
channel.

The second one I want to introduce is max_simultaneous_handshakes that
limits the number of in-flight AddChannelRequests the client may issue not
to run out the server's buffer for pre-handshake data.

Servers may send these extension parameter based on their buffering
capacity.

I also considered limiting total pre-handshake bytes summed for all
channels. This doesn't increase complexity so much as it introduces only
one extension parameter. But not to run out buffer for each channel, this
would be practically limited up to the minimum value of quota for all
logical channel. So, the pre-handshake quota won't be utilized well if many
AddChannelRequests are issued simultaneously.

As John said in the thread, if we allow the WebSocket API to send data
before receiving AddChannelResponse, the JS application should be
responsible for re-sending. Otherwise, the WebSocket stack would need to
buffer much data in case re-sending is necessary.

That said, in the first place, we haven't discussed for what case
re-sending would happen. We need to clarify this and have a way to allow JS
to know what to do.

Takeshi

---

From: "Arman Djusupov" <[email-masked]>
Date: Mon, 28 May 2012 14:23:06 +0300

Resending would be required when the allocation of a logical channel has
failed on the server or the intermediary due to any kind of mux related
error. For example: "Maximum number of logical channels per physical
connection has been reached " or "Intermediary cannot reach the destination
endpoint". The current draft requires that if an AddChannelResponse is
received with a failed flag, the client attempts to open a new physical
connection. Since the browser must keep the mux extension transparent it
cannot let the JS application handle the recovery from mux related errors. 

I like the idea of using the total pre-handshake quota for all logical
channels. This would allow high throughput channels to utilize a common
pre-handshake quota when other channels do not require to send any data
prior to receiving an AddChannelResponse. I believe that this solution would
be more optimal than having a pre-handshake quota per logical channel.
However,  this solution would require the client to subtract the required
value from the common quota and specify this value in the AddChannelRequest
header, so that the server knows from which initial value to start counting
the remote side quota. There should also be a way to restore the common
quota, e.g. in AddChannelResponse the server can send a header which would
specify the value that should be added to the common pre-handshake quota.

With best regards,

Arman

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Yoshino
Sent: Monday, May 28, 2012 11:29 AM
To: [email-masked]
Subject: [hybi] Multiplexing: Pre-AddChannelResponse quota

Hi all,

Sorry for delay on the decision making on the pre-response quota feature of
the multiplexing extension. Based on input on the list, I'm going to add two
extension parameters for use in the server's opening handshake of the
physical channel.

I also considered limiting total pre-handshake bytes summed for all
channels. This doesn't increase complexity so much as it introduces only one
extension parameter. But not to run out buffer for each channel, this would
be practically limited up to the minimum value of quota for all logical
channel. So, the pre-handshake quota won't be utilized well if many
AddChannelRequests are issued simultaneously.

That said, in the first place, we haven't discussed for what case re-sending
would happen. We need to clarify this and have a way to allow JS to know
what to do.

Takeshi