Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages

From: Tobias Oberstein <[email-masked]>
Date: Tue, 16 Aug 2011 07:47:13 -0700

Bob,

fragmenting control messages is forbidden and control frames can have a max. payload of 125 octets.

My question is:

When an intermediary receives

[MSG1-fragment1] [MSG1-fragment2] [CONTROL-frame] [MSG1-fragment3]

which of the following is it allowed to coalesce into when forwarding:

C1.
[MSG1-fragment12] [CONTROL- frame] [MSG1-fragment3]

C2.
[MSG1-fragment123] [CONTROL- frame]
 
C3.
[CONTROL-message] [MSG1-fragment123]

C4.
[MSG1-fragment1] [CONTROL- frame] [MSG1-fragment23]

==

"allowed" = according to rules as defined by the base WS spec with no active extension

Tobias

> -----Ursprüngliche Nachricht-----
> Von: Bob Gezelter [mailto:[email-masked]]
> Gesendet: Dienstag, 16. August 2011 16:26
> An: Tobias Oberstein
> Cc: [email-masked]
> Betreff: Ping/Pong, Intermediaries, Multiplexing
> 
> Tobias,
> 
> I cannot give you a precise citation at this instant, but it has always been my
> assumption that Control frames were not of the sizes that would be subject
> to further fragmentation.
> 
> If this is not specifically prohibited, IMHO it should be.
> 
> That would admittedly somewhat transform the discussion from "Maximum
> frame size" to "Minimum/Maximum frame size".
> 
> - Bob Gezelter, http://www.rlgsc.com

---

From: John Tamplin <[email-masked]>
Date: Tue, 16 Aug 2011 10:53:22 -0400

On Tue, Aug 16, 2011 at 10:47 AM, Tobias Oberstein When an intermediary
receives
> "allowed" = according to rules as defined by the base WS spec with no

I don't believe the spec has anything to say about this currently, so I
believe all of them would be allowed.  Personally, I would think #1 should
definitely be allowed, and that it might be useful for an intermediary that
collected small frames to do #3 or #4.  It seems you wouldn't want to delay
a control frame while waiting for more frames in a message, so I would
prefer to outlaw #2, but I don't feel strongly about it.

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

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 16 Aug 2011 08:20:01 -0700

My concern is wrt to the ordering guarantees (if any) between messages and control frames.

C2 changes the order in which "OnControl" and "OnMessage" handlers would fire on the receiving endpoint.

original:
[MSG1-fragment1] [CONTROL-frame1] [MSG1-fragment2] [MSG2-fragment1] [CONTROL-frame2] [MSG2-fragment2]

by C2 =>
[MSG1-fragment1] [MSG1-fragment2] [CONTROL-frame1] [MSG2-fragment1] [MSG2-fragment2] [CONTROL-frame2]

by coalescing =>
[MSG1-fragment12] [CONTROL-frame1] [MSG2-fragment12] [CONTROL-frame2]

?? =>
[MSG1-fragment12] [MSG2-fragment12] [CONTROL-frame1] [CONTROL-frame2]

==

If the spec does not require anything in this area, then we have actually 2 channels (control/data) with strict ordering
within, but no ordering relationship between?

Von: John Tamplin [mailto:[email-masked]]
Gesendet: Dienstag, 16. August 2011 16:53
An: Tobias Oberstein
Cc: Bob Gezelter; [email-masked]
Betreff: Re: [hybi] Intermedaries: coalescing with interleaved control messages

On Tue, Aug 16, 2011 at 10:47 AM, Tobias Oberstein When an intermediary receives

C1.

C2.

C3.

C4.

==

I don't believe the spec has anything to say about this currently, so I believe all of them would be allowed.  Personally, I would think #1 should definitely be allowed, and that it might be useful for an intermediary that collected small frames to do #3 or #4.  It seems you wouldn't want to delay a control frame while waiting for more frames in a message, so I would prefer to outlaw #2, but I don't feel strongly about it.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Aug 2011 17:33:00 +0200

> "allowed" = according to rules as defined by the base WS spec with no active extension

If WS frames contain an "id" field (a random token value), and each
frame belonging to same WS message has the same "id" value, then
problem solved.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: John Tamplin <[email-masked]>
Date: Tue, 16 Aug 2011 11:36:57 -0400

> frame belonging to same WS message has the same "id" value, then

No, that solves nothing about the order guarantees between control and data
frames.  I'm not sure exactly what it does solve, other than being able to
say a particular frame was too large or providing an acknowledgement to each
frame (which would be completely undesired in many applications).  It
doesn't provide any basis for solving MUX, as you still need a channel id.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Aug 2011 17:48:10 +0200

2011/8/16 John Tamplin <[email-masked]>:
> frames.

And why should be such order a problem?

> I'm not sure exactly what it does solve, other than being able to
> say a particular frame was too large

...which would solve a so long recent mail thread.

> or providing an acknowledgement to each
> frame (which would be completely undesired in many applications).

I'm not suggesting it now :)

> It doesn't provide any basis for solving MUX, as you still need a channel id.

I must read what MUX is. But for sure, using a id in each frame would
allow that a very *big* WS message can be sent within N frames
allowing other frames in parallel belonging to other WS messages. Of
course, is the application who decides whether it can send, or not,
two message in parallel.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: John Tamplin <[email-masked]>
Date: Tue, 16 Aug 2011 11:54:37 -0400

> And why should be such order a problem?

That was the entire subject of this particular thread.  Regardless of the
outcome of the discussion, the spec ought to be clear about what order
guarantees are provided.

> ...which would solve a so long recent mail thread.

No, the debate has been about whether there should be such a "frame too
large" error or should implementations be required to accept any legal
frame.  Being able to identify which frame is in error would be nice, but
does not address this debate and does not justify the cost of including a
message ID in every frame for something which is expected to be at best an
unusual condition.

> course, is the application who decides whether it can send, or not,

Imagine two totally disconnected WebSocket connections sharing transport.
 For example, multiple tabs in a browser all connecting to the same server.
 These applications in different tabs should not know anything about each
other and their traffic should be delivered only to the appropriate
application, yet you want to reduce the number of connections to the server.
 MUX is a way to let the browser (or equally some intermediary, say a cell
provider or a corporate gateway) combine these separate connections into a
single one while preserving all the semantics of individual connections.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Aug 2011 18:36:32 +0200

> single one while preserving all the semantics of individual connections.

Thanks a lot for the explanation, got it.

-- 
Iñaki Baz Castillo
<[email-masked]>