Subject: Re: [hybi] consensus call on ability to announce max frame size

From: Tobias Oberstein <[email-masked]>
Date: Mon, 1 Aug 2011 13:56:12 -0700

How would that related to intermediaries?

Even if two endpoints agree on a maximum frame size of N
(where N >= 125 + 6 .. since that is a masked control msg max. size and
control frames must never be fragmented), an intermediary might
want to have frame size < N. Or > N.

It may further fragment or coalesce. In the latter case, even if
the endpoints agree, the frames arriving at those endpoints may be
longer since they could have been coalesced by an intermediary.

Or is some path MTU discovery for frame length the idea?

Lots of complexity ..

Why is there a need for max. frame size anyway?

A specific implementation might buffer all frames to disk .. or
compute something on the fly. So there would never be out of mem.

Isn't the fact that the WebSockets JS API is message based something
independent of the WS protocol? Couldn't there be a data-frame based
API in some other context? Or even a stream based one?

from the draft:

"The WebSocket message does
not necessarily correspond to a particular network layer framing, as
a fragmented message may be coalesced, or vice versa, e.g. by an
intermediary."

An intermediary MUST NOT change the fragmentation of a message if
      any reserved bit values are used and the meaning of these values
      is not known to the intermediary.

   o  An intermediary MUST NOT change the fragmentation of any message
      in the context of a connection where extensions have been
      negotiated and the intermediary is not aware of the semantics of
      the negotiated extensions.

---

From: Diogo Pereira <[email-masked]>
Date: Mon, 1 Aug 2011 23:30:28 +0100

> Why is there a need for max. frame size anyway?

Good question.

If the API is messaged based then the implementation has to buffer the
entire message. A frame size limit does not help.

If the API is stream based there is no buffering problem at all.

If the API is frame based (and it shouldn't be), the implementation
can still fairly easily perform local fragmentation.

--
Diogo

---

From: Piotr Kulaga <[email-masked]>
Date: Fri, 5 Aug 2011 16:12:13 +0000

-1.50 for announcing frame size. So far no one  (in my opinion) posted any reasonable justification for this behavior. In my opinion this will just complicate implementations instead of simplifying them (every intermediary will have to obey this limits) and bloat the spec.
-0.25 for announcing message size. I see some benefits of it, but I think we should discuss this before moving forward.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Diogo Pereira
Sent: Monday, August 01, 2011 3:30 PM
To: Tobias Oberstein
Cc: [email-masked]
Subject: Re: [hybi] consensus call on ability to announce max frame size

Good question.

If the API is messaged based then the implementation has to buffer the entire message. A frame size limit does not help.

If the API is frame based (and it shouldn't be), the implementation can still fairly easily perform local fragmentation.

--
Diogo
_______________________________________________
hybi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hybi

---

From: Tobias Oberstein <[email-masked]>
Date: Fri, 5 Aug 2011 14:22:51 -0700

-1 for announcing max. frame size
-1 for announcing max. message size

===

>From my experience, which is limited to endpoint development: when I'm
a) outside the browser, and b) not limited by dubious network restrictions,
I prefer TCP and do my own/whatever stuff.

The whole attraction for me of WebSockets is with browser as run-time
and network limitations, like all kinds of fancy firewalls/proxies/content
inspection systems.

I can't see how limits/negotiation on frame/message size helps in browsers.

However, everything which increases the chances/adoption/support of
WebSockets across those intermediaries is worth considering.

Are there people from vendors/packages related to intermediaries on this
list, which might have an opinion on frame/message size limits/negotiation?

On 05.08.11 18:12, "Piotr Kulaga" <[email-masked]> wrote:

> -1.50 for announcing frame size. So far no one  (in my opinion) posted any
> reasonable justification for this behavior. In my opinion this will just
> complicate implementations instead of simplifying them (every intermediary
> will have to obey this limits) and bloat the spec.
> -0.25 for announcing message size. I see some benefits of it, but I think we
> should discuss this before moving forward.
> 
> If the API is messaged based then the implementation has to buffer the entire
> message. A frame size limit does not help.
> 
> If the API is frame based (and it shouldn't be), the implementation can still
> fairly easily perform local fragmentation.
> 
> 
> --
> Diogo

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 9 Aug 2011 11:01:41 +1000

> Or is some path MTU discovery for frame length the idea?

I believe that intermediaries should be allowed to change the declared
frame size headers.  In fact the frame size header should probably be
listed in Connection and be a hop by hop header as each leg may have
different frame size.

regards

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 9 Aug 2011 00:34:44 -0700

> I believe that intermediaries should be allowed to change the declared frame

decrease only, or increase also?

> size headers.  In fact the frame size header should probably be listed in
> Connection and be a hop by hop header as each leg may have different
> frame size.

I'm glad you bring back the question of intermediaries in this discussion
about announcing max. frame size, since I think it should be the tie breaker.

the reason I think so is: the two competitors of WebSockets are

1) raw TCP:
++ simple (to use), efficient
-- not compatible (by Web measures)

2) plain old HTTP (some long poll, Comet, Bosh whatever)
++ compatible (with infrastructure)
-- not simple, not efficient

So, does "max. frame size" make WebSockets any simpler or more efficient?
I guess not.

Does "max. frame size" make WebSockets more compatible (with intermediaries)?
I don't know.

It may make it less compatible, since it imposes more logic onto intermedaries that they
have to deal with, without helping them.

It may make it more compatible, since it might help intermediaries doing the stuff
they want to do.

I.e. when a content inspection systems wants to do it's inspection on a per frame basis,
a max. frame size might help. If it wants to do that on a per message basis, it won't be
sufficient.

---

From: Bruce Atherton <[email-masked]>
Date: Tue, 09 Aug 2011 09:21:45 -0700

On 08/08/2011 6:01 PM, Greg Wilkins wrote:
> On 2 August 2011 06:56, Tobias Oberstein<[email-masked]>  wrote:

How about this:

If an intermediary does not wish to declare its maximum frame size, it 
MUST pass through any max-frame-size header unaltered.

If it wishes to declare a maximum frame size and it is not going to 
refragment the frames, then it MUST send downstream a max-frame-size 
header that is the lesser of the two values for its own maximum frame 
size and the received max-frame-size header.

If it wishes to declare a maximum frame size and it plans on reframing 
(implying that it understands all extensions in the stream), then it MAY 
send its own maximum frame size downstream regardless of the received 
maximum frame size, but it MUST refragment to frames that are no larger 
than the received maximum frame size.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 10 Aug 2011 10:18:44 +1000

> Does "max. frame size" make WebSockets more compatible (with intermediaries)?

Remember this is not about having a max frame size or not.  Every
implementation will have a max frame size - even if that is 2^64 or
imposed by the amount of free disk space.

This is a question about knowing what that limit is or not.

Does having an unknown limit make any implementation simpler or more
efficient?  Maybe by ignoring the fact that such a limit exists, but
the price is that you become more fragile and will fail necessarily if
that limit is exceeded.

cheers