Subject: [hybi] Draft 12 - Ordering Guarantees

From: Tobias Oberstein <[email-masked]>
Date: Thu, 25 Aug 2011 06:00:55 -0700

I'd like to propose the following additions.

5.4.  Fragmentation

* An intermediary MUST NOT coalesce message frames accross frames with FIN bit set.

5.5.  Control Frames

Control frames MUST be delivered to the recipient in the order sent by the sender.

---

From: John Tamplin <[email-masked]>
Date: Thu, 25 Aug 2011 10:48:12 -0400

> * An intermediary MUST NOT coalesce message frames accross frames with FIN

I'm not sure how to handle this, but I think extensions may need to expand
on this point.  For example, a MUX extension might well do so for
interleaved messages on different channels.  Perhaps adding an explicit note
"unless altered by a negotiated extension"?

> Control frames MUST be delivered to the recipient in the order sent by the

I think this needs some flexibility for not delivering control frames at
all, if the intermediary is the one best to respond to them.  Consider a WS
front-end that handles pings so the backend servers don't have to.

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

---

From: Joe Mason <[email-masked]>
Date: Thu, 25 Aug 2011 11:09:08 -0400

How about, “Control frames MUST be handled in the order sent by the sender.”  That leaves it open WHO is doing the handling.

This does impose a limitation on intermediaries: if an intermediary receives “PING, CLOSE, PING” it’s not valid to do “PONG, send CLOSE to endpoint, PONG” because then then second pong may go out before the endpoint handles the CLOSE.

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Tamplin
Sent: Thursday, August 25, 2011 10:48 AM
To: Tobias Oberstein
Cc: [email-masked]
Subject: Re: [hybi] Draft 12 - Ordering Guarantees

On Thu, Aug 25, 2011 at 9:00 AM, Tobias Oberstein <[email-masked]<mailto:[email-masked]>> wrote:
I'd like to propose the following additions.

5.4.  Fragmentation

I'm not sure how to handle this, but I think extensions may need to expand on this point.  For example, a MUX extension might well do so for interleaved messages on different channels.  Perhaps adding an explicit note "unless altered by a negotiated extension"?

5.5.  Control Frames

I think this needs some flexibility for not delivering control frames at all, if the intermediary is the one best to respond to them.  Consider a WS front-end that handles pings so the backend servers don't have to.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 25 Aug 2011 08:14:40 -0700

How about:

5.4.  Fragmentation

* An intermediary MUST NOT coalesce message frames accross frames with FIN bit set,
unless in the context of a connection where extensions known to the intermediary
have been negotiated which allow for such coalescing.

5.5.  Control Frames

Control frames delivered to the recipient MUST be delivered to the recipient in the order sent by the sender.

==

The latter leaves open the case where all or only some control frames are not delivered to the endpoint at all.

However, what you point out was somewhat surprising to me (before the comments of Greg and yours).

Of course I see what's up with the example you gave, but ..

As an endpoint, I can't be sure that my peer will receive control frames at all?

So for example, if I wanted to use the payload of Pings for credit repl. in a flat MUX scheme that does
all it's stuff inside standard WS, then I couldn't be sure that my peer receives those frames …

How about this

Control frames with empty payload MAY be handled by an intermediary directly and not delivered to the otherwise receiving endpoint.

Control frames with non-empty payload MUST be delivered to the recipient.

Here, I assume that

recipient = receiving endpoint

is understood.

Von: John Tamplin [mailto:[email-masked]]
Gesendet: Donnerstag, 25. August 2011 16:48
An: Tobias Oberstein
Cc: [email-masked]
Betreff: Re: [hybi] Draft 12 - Ordering Guarantees

5.4.  Fragmentation

5.5.  Control Frames

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 25 Aug 2011 17:41:30 +0200

2011/8/25 Tobias Oberstein <[email-masked]>:
> Control frames with empty payload MAY be handled by an intermediary directly
> and not delivered to the otherwise receiving endpoint.

What is that??? are you suggesting a specification for a non
standarized element (a "websocket intermediary")?

If the WS draft does NOT define what an intermediary is, then don't
add stuf in the spec about such "intermediaries", period.

WebSocket is a end-to-end protocol (client-to-server), and the spec
should just talk about that and not about custom/propietary/strange
network elements doing non standarized stuf ("WebSocket
intermediary??").

If you want to introduce the concept of a "WebSocket proxy" in the WS
spec, then do it properly and define a robust mechanism for frames
between the client and the proxy (which would require some routing
logic, such as 'destination' field within the WS frame).

It seems that some people here do know "what a websocket intermediary
is" because they have some custom/propietary/non-standard network
elements ready for doing something "cool" with HTTP/WS traffic, and
they want WS protocol to facilitate it.

This is a IETF draft, not a HowTo document in which each one can add
non standard custom stuf.

If a suggestion like this would be made in IETF SIP/SIMPLE Working
Group, the 3rd World War would start, but here it seems that
vendor-custom-needs can influence on the resulting specification just
to make them happy, even if we end with a IETF RFC talking about
"WebSocket intermediaries" which is defined NOWHERE.

No please. I hope the IETF will stop this kind of aberrations soon.

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

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 25 Aug 2011 09:00:46 -0700

> > Control frames with empty payload MAY be handled by an intermediary
> > directly and not delivered to the otherwise receiving endpoint.
> 
> What is that??? are you suggesting a specification for a non standarized
> element (a "websocket intermediary")?
> 
> If the WS draft does NOT define what an intermediary is, then don't add stuf
> in the spec about such "intermediaries", period.

<cut long rant>

1. Read the spec, it describes semantics using the word "intermediary" in over two dozens places
2. Read the group charter (http://datatracker.ietf.org/wg/hybi/charter) .. it lists several examples of intermediaries
3. Calm down

Regards,
Tobias

---

From: John Tamplin <[email-masked]>
Date: Thu, 25 Aug 2011 12:13:01 -0400

On Thu, Aug 25, 2011 at 11:41 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> directly

You appear to be the only one here who doesn't understand what a WS
intermediary is.  Quite simply, it is anything in the path between two WS
endpoints which understands WS.  They may observe traffic, they may
intercept (either transparently, by being an HTTP proxy and noticing that
the connection is WS, or through a yet-to-be defined method of telling the
browser to use a WS proxy specifically) a WS connection and
log/filter/whatever it wants to do with the traffic.  Saying exactly what
they may do is outside the scope of this spec, and we are unlikely to have
good ideas of what you might want to do with them at this point anyway.  The
spec's job is to make sure that when such intermediaries do arise, the rules
of what they can do to the traffic are defined so they don't unintentionally
break connectivity.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 25 Aug 2011 18:26:39 +0200

> 1. Read the spec, it describes semantics using the word "intermediary" in over two dozens places

The way in which "intermediary" is defined within the spec is just a
hack ("proxies and other intermediaries?").

> 2. Read the group charter (http://datatracker.ietf.org/wg/hybi/charter) .. it lists several examples of intermediaries

"HTTP-aware intermediaries like proxies, load balancers, caches, etc"

Ok.

> Control frames with empty payload MAY be handled by an intermediary directly and not delivered to the otherwise receiving endpoint.

What about if there are more than one "intermediary"? or must we
assume a vendor-specific infraestructure with an HTTP load-balancer in
front of a cluster of application servers?

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

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 25 Aug 2011 09:35:05 -0700

> What about if there are more than one "intermediary"? or must we assume a
> vendor-specific infraestructure with an HTTP load-balancer in front of a
> cluster of application servers?

"_an_ intermediary" = any of potentially many on the path between the endpoints

i.e.

A Ping with empty payload may be handled by a WS load-balancing front-end
directly by sending (an empty payload) Pong back.

An unsolicited empty payload Pong may be filtered out by a WS gateway system
operated by a mobile carrier. That Pong would never reach the otherwise
receiving endpoint, and it would also not reach the load-balancing WS frontend
cluster.

However, what above rule would establish was that a peer sending a Ping
with non-empty payload can be sure that this Ping will reach the receiving
peer.

The other proposed rules would ensure that it is also well defined what
the ordering relation between the received Ping and other received
control and non-control frames would be.

All for the base WS protocol when no extension is active.

If an extension is active, the rules of WS already allow that extension
to define far-reaching rules regarding reception and ordering guarantees.

However, I expect that only very few extensions which specify special
rules might find the full support for their specific rules by all vendors of
whatever intermediaries.

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 25 Aug 2011 18:36:38 +0200

On 8/25/11 6:13 PM, John Tamplin wrote:
> On Thu, Aug 25, 2011 at 11:41 AM, Iñaki Baz Castillo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     2011/8/25 Tobias Oberstein <[email-masked]
>     <mailto:[email-masked]>>:
> intermediary is.  Quite simply, it is anything in the path between two 
> WS endpoints which understands WS.  They may observe traffic, they may 
> intercept (either transparently, by being an HTTP proxy and noticing 
> that the connection is WS, or through a yet-to-be defined method of 
> telling the browser to use a WS proxy specifically) a WS connection 
> and log/filter/whatever it wants to do with the traffic.  Saying 
> exactly what they may do is outside the scope of this spec, and we are 
> unlikely to have good ideas of what you might want to do with them at 
> this point anyway.  The spec's job is to make sure that when such 
> intermediaries do arise, the rules of what they can do to the traffic 
> are defined so they don't unintentionally break connectivity.

(as individual)

adding to the spec some text explaining what a WS intermediary would be 
opportune.

/Sal

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 25 Aug 2011 18:46:38 +0200

> adding to the spec some text explaining what a WS intermediary would be

Yes, please, thanks a lot.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 25 Aug 2011 23:52:09 +0200

> directly by sending (an empty payload) Pong back.

And how would the WS client know whether to send a Ping with body or
empty body? how would it know whenever there is an intermediary or
not? perhaps should the JS developer *know* it when writting the
JavaScript code?

Are we assuming that the webpage/JavaScript developer would be the
same person building the service infraestructure (servers,
load-balancers, and so)?

IMHO this seems a hack and I doubt such "feature" should be included
in an IETF RFC.

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

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 26 Aug 2011 08:55:25 +1000

> hack ("proxies and other intermediaries?").

I don't think there is very much value (or even a possibility of) in
nailing down what an intermediary is and what it can/can't do beyond
the minimal needed.    I think we need the minimal of requirements
(such as the existing limitations on changing fragmentation if
extensions are not understood).

It is a valid question to ask if control frame order is such a minimal
requirement, but I think the answer to that question is no.
Intermediaries may run different ping/pong policies on a hop by hop
basis.  They may inject proprietary control messages on one hop but
not the other.  We already allow a single pong response to cover two
outstanding pings, so that is in effect allowing one ping to overtake
another.

regards

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 30 Aug 2011 10:48:58 +0100

Salvatore Loreto wrote:

>> intermediary is.  Quite simply, it is anything in the path between 
>> two WS endpoints which understands WS.  They may observe traffic, 
>> they may intercept (either transparently, by being an HTTP proxy and 
>> noticing that the connection is WS, or through a yet-to-be defined 
>> method of telling the browser to use a WS proxy specifically) a WS 
>> connection and log/filter/whatever it wants to do with the traffic. 
>>  Saying exactly what they may do is outside the scope of this spec, 
>> and we are unlikely to have good ideas of what you might want to do 
>> with them at this point anyway.  The spec's job is to make sure that 
>> when such intermediaries do arise, the rules of what they can do to 
>> the traffic are defined so they don't unintentionally break connectivity.
>
> (as individual)
>
>
> adding to the spec some text explaining what a WS intermediary would 
> be opportune.

Sal,
Can you suggest some text?