Subject: [hybi] Frame Size Declaration

From: "Bob Gezelter" <[email-masked]>
Date: Tue, 09 Aug 2011 07:43:51 -0700

Everyone,

Frame size, message size, and the run-time object interface are, or had
better be as close to mutually orthogonal as can be achieved. If not,
the WebSocket protocol will have problems in the field as it is adopted,
both for anticipated uses and for those uses that we as a group have not
yet considered.

While the present run-time interface seems to require message buffering,
this is not an immutable decision. As I noted previously, other network
stacks provide examples of streamed or segmented interfaces for
supporting applications that feel the need for messages longer than that
supported by the underlying software/hardware infrastructure.

Very large frame sizes are another issue entirely. They "rediscover" all
of the challenges that gave rise to the ARPAnet design decision to use
packet switching over the more familiar message switching. Even though
today's speeds are far higher, the challenges of message switching vs.
packet switching remain relevant. Frames are an issue that are
effectively invisible to the user, except insofar as the incremental
overhead and possible extra per frame processing, both of which should
not be significant for frame sizes measured in thousands of bytes (Note:
it is important to remember that the WebSocket protocol is not a bare
wire protocol, and is always operating over an underlying sequenced,
very-low error pipe, e.g., TCP). 

The main user perceived issue is latency for control messages (and
latency impacts on multiplexed streams, when they are integrated into
the protocol). I cannot see a significant benefit to very large (e.g., >
2**16) frames.

As has been said, there will be limits in any infrastructure. I see no
reason why a control regime that states that proxies in the path may
reduce maximum frame size at session establishment will give rise to any
problems.

Frame level integrity controls would need to be recomputed by such
proxies upon frame fragmentation. Overall message integrity controls are
best done at the message level, and thus would be unaffected by frame
level issues.

In summary, maximum frame size should be negotiated on a
connection-by-connection basis (and on a sub-channel basis in any
multiplexing scheme). Intermediaries should be free to further reduce
frame sizes. Frame size should not affect any user level interfaces.
Frame size, message size, and user API should be mutually orthogonal
issues. As a footnote, techniques for processing very large messages
without the need for entire message to be stored have been well-studied
since at least the Second World War, and are suitable for many, if not
all applications creating extremely large messages.

- Bob Gezelter, http://www.rlgsc.com

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 9 Aug 2011 18:12:07 +0200

> frame sizes. Frame size should not affect any user level interfaces.

100% agreed!

I hope WS authors would take it into consideration. Don't mix layers,
please. OSI layers are there for being studied even if never applied
XD
Frames size should never affect to user/client layer. That's a MUST in
every Internet protocol (and WS is already "special" enough by
breaking the rule of "one TCP port => one protocol/service", please
don't break more).

> all applications creating extremely large messages.

200% agreed.

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