Subject: Re: [hybi] MUC: channel ID semantics

From: "Arman Djusupov" <[email-masked]>
Date: Mon, 2 Apr 2012 16:04:14 +0300

As for arguing against it now, I think it greatly complicates the protocol (some examples: how do you represent the parameters of all the channels, what happens when one of the channels can't be created as requested,

It is likely that several channels muxed within the same connection will share the same target URI and have the same parameters. The delta encoding that is proposed/TBD in the spec provides the ability to send a sequence of AddChannel requests that would reuse the handshake of the first logical channel. But currently there is a limitation that only the handshake of the first logical channel can be reused. By extending this a little bit, it will be possible to enable the reuse of handshakes for channels with similar parameters. This would speed up the allocation of logical channels in general.

DoS considerations currently blocked by one creation in flight at a time, complicates buffer space handling, etc) and provides limited benefits.

The current specification already allows multiple AddChannel requests to be batched into a single binary message. Sending to the server a large pre-generated sequence of separate AddChannel requests would force the server to perform a large sequence of handshakes, gradually allocating resources until it reaches a limit and has to refuse new logical channels. When receiving a single AddChannel request batch with a single handshake and the specified final number of channels required, the server can either allocate the requested channels sequentially as in the previous case or refuse the entire batch with minimal effort. Neither case blocks DoS considerations.

Predicting more than one logical channel will be needed soon sounds like it reduces to the halting problem to me, so I wouldn't hold my breath on anything better than a raw guess.

Maybe for browsers it is seems as an unforeseeable use case. But for example, when an intermediary needs to move a large set of logical channels to a failover (or just another) connection, it would need to establish a known number of logical channels fast.

I disagree, but it doesn't matter; at hybi we are only discussing the wire protocol -- if someone wants to build an API that exposes all of that, fine.  We already leave it up to the client for the choice of when/how to use MUX, so if you are building your own non-browser client you can already do as you wish.

If others don’t support this, I don’t insist.

-- 
John A. Tamplin
Software Engineer (GWT), Google

With best regards,

Arman

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 13 Apr 2012 16:05:29 +0900

On Mon, Apr 2, 2012 at 22:04, Arman Djusupov <[email-masked]> wrote:

> As for arguing against it now, I think it greatly complicates the protocol
> (some examples: how do you represent the parameters of all the channels,
> what happens when one of the channels can't be created as requested,****
>
> ** **
>
> It is likely that several channels muxed within the same connection will
> share the same target URI and have the same parameters. The delta encoding
> that is proposed/TBD in the spec provides the ability to send a sequence of
> AddChannel requests that would reuse the handshake of the first logical
> channel. But currently there is a limitation that only the handshake of the
> first logical channel can be reused. By extending this a little bit, it
> will be possible to enable the reuse of handshakes for channels with
> similar parameters. This would speed up the allocation of logical channels
> in general.****
>
> **
>

It's true that there's some gain from such optimization. But WebSocket
connections are expected to last for long time. Amount of data spent for
handshake is little relatively. Different from SPDY for which reduction of
bandwidth spent for headers is really significant, I don't think it's so
beneficial to inflate the spec to add much optimization.

If it's really useful, I'd just add some flag "DIFF_BASE" to
AddChannelRequest and AddChannelResponse to mark certain request/response
as a key entry based on which the following entries with diff-based
compression are processed. Browser may use some heuristics behind JS, and
any other non-browser applications may employ as they like it to optimize
batch allocation.

Just change the spec of delta-encoded to refer "last AddChannelRequest with
Enc=identify" as base for diff is also fine.

>  **
>
> DoS considerations currently blocked by one creation in flight at a time,
> complicates buffer space handling, etc) and provides limited benefits.****
>
> ** **
>
> The current specification already allows multiple AddChannel requests to
> be batched into a single binary message. Sending to the server a large
> pre-generated sequence of separate AddChannel requests would force the
> server to perform a large sequence of handshakes, gradually allocating
> resources until it reaches a limit and has to refuse new logical channels.
> When receiving a single AddChannel request batch with a single handshake
> and the specified final number of channels required, the server can either
> allocate the requested channels sequentially as in the previous case or
> refuse the entire batch with minimal effort. Neither case blocks DoS
> considerations.****
>
> **
>

It's just missing in the current spec. This point is open for discussion.
That said, as:
- different from raw WebSocket, sending multiple AddChannel requests
doesn't increase TCP connection attempts
- under multiplexing, there's no worry that WebSocket is used to DoS normal
HTTP server. (de-multiplexing proxy must place the limit again.)
we can allow simultaneous AddChannelRequests.

Thoughts?

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 13 Apr 2012 16:45:32 +0900

On Fri, Apr 13, 2012 at 16:05, Takeshi Yoshino <[email-masked]> wrote:

> - under multiplexing, there's no worry that WebSocket is used to DoS
> normal HTTP server. (de-multiplexing proxy must place the limit again.)

Correction.

It "WAS" missing in tamplin-03 but it's in from ietf-00.

http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-00#section-7.1

   The same limit on simultaneous opening handshake as specified in
   Section 4.1 of [RFC6455] is applied to AddChannelRequests for
   multiplexed channels.

---

From: "Arman Djusupov" <[email-masked]>
Date: Fri, 13 Apr 2012 14:09:20 +0300

Hello Takeshi,

Using delta encoding would enable the fast allocation of channels in batches
if necessary. IMO it's preferable to send a batch of multiple
AddChannelRequest in a single control message and then receive a batch of
AddChannel responses, rather than sending a complex single AddChannel
request that is supposed to create more than one channel. We don't really
need to change much in the specification, we just need to optimize the delta
encoding that is already there.

If it's really useful, I'd just add some flag "DIFF_BASE" to
AddChannelRequest and AddChannelResponse to mark certain request/response as
a key entry based on which the following entries with diff-based compression
are processed. Browser may use some heuristics behind JS, and any other
non-browser applications may employ as they like it to optimize batch
allocation.

I think that an encoding based on the last 'identify' handshake is fine, and
is as simple as an encoding based on the first one. A mux intermediary /
server will simply have to remember the last handshake rather than first
one.

- different from raw WebSocket, sending multiple AddChannel requests doesn't
increase TCP connection attempts

Thoughts?

Note that Section 4 of RFC 6455 has requirements that apply mostly to
browsers and it limits the number of concurrent connections in CONNECTING
state and does not explicitly mention concurrent handshakes. In case of a
mux channel the network  connection is one and it is CONNECTED, so this
needs a bit of clarification if this paragraph will remain in the spec.
 
As you mentioned above the DoS attack against non-WebSocket servers  is not
applicable when creating logical channels. The only concern that comes to
mind is that a malicious script can flood the high priority channel ID 0
with AddChannel requests using long header values, this way trying to
disrupt the communication of other channels on the same connection. But such
behavior can be detected and limited by the browser.
 
BTW:
"Different from non-multiplexed WebSocket connection, data frames of
multiplexed channel except for the channel 1 opened by default MAY be sent
before receiving AddChannelResponse as far as there's sufficient
send quota.  In case the AddChannelRequest fails, those frames are ignored
by the other peer."

As far as I had previously understood, until a new logical channel receives
the AddChannelResponse its flow control quota is 0. The initial quota is
assumed to be 64K but this quota applies only once the channel is accepted
and the handshake did not include/specify a quota that overrides this value.
Wouldn't this mean that the logical channel cannot send anything prior it
was accepted due to the 0 quota even if the specification permits it to send
messages, or did I miss something?

With best regards,

Arman

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 18 Apr 2012 17:03:08 +0900

Hi,

On Fri, Apr 13, 2012 at 20:09, Arman Djusupov <[email-masked]> wrote:

> Using delta encoding would enable the fast allocation of channels in
> batches if necessary. IMO it’s preferable to send a batch of multiple
> request that is supposed to create more than one channel. We don’t really
> need to change much in the specification, we just need to optimize the
> delta encoding that is already there.
>

OK.

> I think that an encoding based on the last ‘identify’ handshake is fine,
> and is as simple as an encoding based on the first one. A mux intermediary
> / server will simply have to remember the last handshake rather than first
> one.
>

OK. I'll do so.

> needs a bit of clarification if this paragraph will remain in the spec.

Thanks. Yes, even in case we keep the requirement, we need to rephrase
current one.