Re: [hybi] Framing take IV

[Mike Belshe <[e-mail]>]

On Tue, Aug 3, 2010 at 6:18 PM, Maciej Stachowiak <[e-mail]> wrote:

>
> On Aug 3, 2010, at 5:53 PM, Ian Hickson wrote:
>
> > On Wed, 4 Aug 2010, Greg Wilkins wrote:
> >>
> >> I think that we have reasonable consensus on something like:
> >>
> >>  +--------------------------------------------------+
> >>  | frag(1) |unused(3) | opcode(4) |  Length(16)     |
> >>  +--------------------------------------------------+
> >>  |                      Data                        |
> >>  +--------------------------------------------------+
> >
> > Why would we have a fixed length field with fragmentation rather than a
> > variable length field?
> >
> > If we can have a variable width length field, do we need to support
> > fragmentation in the first version? I could see an argument for
> supporting
> > fragmentation in the case of multiplexing, but without that it doesn't
> > seem to actually gain us anything.
>


I'm going to write a bunch of stuff which makes it seem like I'm in favor of
variable length encoding.  My true position:  it's not materially different
to use a fixed length + frags vs a variable-length-encoding which supports
large sizes.



>
> I agree. I can't see any benefit to fragmentation over a variable-size
> length field for an initial version without multiplexing.


I agree with that statement.  The issue is that several folks on this list
are trying to make multiplexing work as an extension.  Of course, the frag
flag could be part of the extension rather than part of the base...


> If the variable-size length field is well-designed, then in the common case
> where the message size is small it will only cost one extra branch to read
> the length. In the rare case where the message size is large, a
> variable-size length is easier to deal with than reassembling fragments, and
> easier on the sending side too.
>

I like the variable-sized length field.  As modest "data" on this topic.
 Every place in SPDY where we used fixed, 16bit fields initially, we've
changed.  16bit fields are just on-the-cusp of being too small in some
cases.  Going to 32bits is easy to do, but leaves you with a lot of extra
zeros for most cases.  The frag-flag works around this.  Variable encoding
is also attractive.  Server folks will say "it's not scalable", but I
haven't seen any data to support that claim.



> I'm not really persuaded we need multiplexing at all until I see data
> proving the benefits. Useful data would be:
>
> - Average degree of multiplexing we could likely get in real Web
> applications, based on measured user behavior. I'd like to see this for at
> least two different Web apps from two different vendors to make sure we are
> not overtuning to a single vendor's setup.
>

Well, WebSockets is about letting apps write their own apps, so this is
pretty hard to do, right?  I thought from the WebSockets view, this was
about reducing the number of connections more than anything.  It's unclear
that "average degree of multiplexing" is measurable or even the right
metric?



> - Concrete performance benefits of multiplexing over a single TCP
> connection vs. using multiple connections. I have yet to hear an answer that
> involves numbers and doesn't sound handwavey.
>

Oh - I tested this with SPDY stuff a lot.  What specifically do you want?
 But it is all app-specific.  In our case, the app was HTTP pages.  That is
probably not indicative of what people will use websockets for.



>
> - Performance cost of implementing multiplexing at the application level
> compared to doing it at the protocol level (either in terms of more
> connections resulting and the actual cost of that, or in terms of additional
> overhead on the client side from using an iframe or shared worker or
> whatever to share the connection.)
>

Multiplexing is relatively easy (not trivial, though).  It's the flow
control that is hard.   And unfortunately, I don't think you can seriously
claim to have multiplexing unless you address flow control (SPDY version 1
did it, it falls back to TCP flow control, which can stall out streams
inappropriately and is generally not-good).  But when you add flow control
to the multiplexed data, it's very very easy to kill performance
(underthrottle).


>
> I'm open to trading off simplicity for performance, but only if I see data
> backing up the performance claims. Every performance project should start
> with measurement.
>

I would really love to see multiplexing as part of the websocket protocol.
 I don't see how we get there.  Roberto's hooks for "leave it in an
extension" seem about right to me.  But that does mean that the base
protocol should not be attempting to solve multiplexing issues.

One approach to getting to multiplexing it to leave it to a lower level.
 For instance, if we had SCTP, we wouldn't discuss putting multiplexing at
the WebSocket layer.  Of course, replacing lower levels is hard, so this may
sound like something that would never happen.  But SPDY intends to put
multiple streams over a TCP stream.  Maybe that would be the vehicle for
multiplexing.

Mike





>
> Regards,
> Maciej
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>