Re: [hybi] how do we move forward on agreeing on framing?

["Shelby Moore" <[e-mail]>]

Synopsis: your correct attempts to maximize frame size (versus proposals
for fixed maximum frame size) is analogous to eliminating framing as much
possible, because we already have the framing otimization at the TCP
layer.

There is no way to entire eliminate framing from our layer, but maximized
frame size is no framing (with re-fragmentation to handle the degenerative
fallback).

> But the framing and fragmentation are unavoidable, receiving end has to
> know the size to expect and there is no advantage of fixed length over
> variable sizing:
>
> http://www.ietf.org/mail-archive/web/hybi/current/msg03402.html
>
> So what exactly are they putting in the base protocol that isn't
> transport?
>
> BONUS FOR FREE: and WS sits on top of a base framing algorithm (TCP/IP)
> and the way to optimize it is to send data in the largest possible chunks,
> so variable size is a big win. Plus as a small extra benefit, it is less
> headaches for developers to not have to chunk large data blocks to a
> smaller fixed size on sending data.
>
> This is one of those cases where you make things as simple and optimized
> as possible but not more simple and not more optimized.  For example
> analogy, when writing code I can do all sorts of hand-coded optimizations
> that the compiler does any way, which only makes my code harder to read
> and maintain, and may even prevent some (current or future) compiler
> optimizations.  So no need for us to fragment more than necessary with
> fixed size frames.  Lets always send the maximum size frame (because the
> TCP/IP will optimize best), but the problem is that intermediaries might
> not handle our preferred size, so we need fragmentation.  And ditto for
> any size we choose, even a fixed size.
>
> I have not yet read enough of the archives about the proposed multiplexing
> impacts:
>
> http://www.ietf.org/mail-archive/web/hybi/current/msg03403.html
> http://www.ietf.org/mail-archive/web/hybi/current/msg03408.html