[hybi] Summary of open issues regarding Framing Proposal Take VII

[John Tamplin <[e-mail]>]

I am trying to summarize here what seem to be issues up for further
discussion -- forgive me if I leave something out:

   1. the use of a 2-level length field vs a fixed 64-bit length or a
   variable-length-length field (as in v76)
   2. the use of continuation opcode
   3. putting close/ping/pong in the control frame payload rather than as
   separate opcodes
   4. the presence of the complete message length field in the base protocol

If there are any others, feel free to reply to this thread.

#1 - length field
=================
For #1, I think a fixed 64-bit length is unacceptable because of the penalty
it imposes on small messages.  As discussed previously, existing WebSocket
apps make heavy use of small frames, compression will make more frames
smaller, and I suspect many future WebSocket apps will make heavy use of
small frames.  Finally, existing mobile networks pay a penalty for larger
frames, so we should strive to make as many as possible fit in small frames.

Regarding the variable-length length, I prefer the current proposal for the
following reasons:

   - it saves a bit in the header, which gives us more options for future
   expansion
   - it has two steps of length rather than 9, and looking at the overhead
   at various packet lengths there is little justification for more than 3
   - reading one byte at a time imposes an (admittedly small) penalty on the
   performance of the reader
   - the variable-length length has additional complications which need to
   be defined away, namely leading 0x80 bytes and the maximum length of the
   field.  I would suspect that many naive implementations use a 32-bit field
   for the length and would fail to notice overflow when shifting the current
   length.  Being able to convince some implementations that the frame length
   is different than others would be a key way to exploit vulnerabilities.

That said, I would not block consensus over this issue -- if others feel the
variable-length length is better I could live with it -- we would just move
RSV2 into the length field, and define that additional length bytes follow
if the high bit is set (while outlawing leading 0x80 bytes and limiting the
number of bytes in the length to 9, giving the same 63 bits of length as the
current proposal).


#2 - the use of the continuation opcode
=======================================
What I was trying to avoid here was defining how changing opcodes across
fragments should be defined.  What do you do when the first frame has a
different opcode than later frames?  Should the last one win even if the
receiver has already started decoding it based on the first opcode?  Should
the receiver check it and drop the message if the opcode changes?

I would not object to leaving this out and simply defining it as a protocol
error to use a different opcode in a continuation frame, though I worry that
might open up more opportunities for bugs where an implementation doesn't
verify that and opens an attack vector (admittedly, if an implementation
doesn't verify the continuation opcode there may still be attacks, but if it
is specifically expected I suspect that would make implementations more
robust - they might ignore the opcodes of subsequent packets which would be
mostly ok).


#3 - putting close/ping/pong/etc in a control frame rather than giving them
their own opcode
============================================================================================
These frames will be infrequent and we have limited opcode space (especially
if we primarily use opcodes for extensions).  I would strongly prefer
defining a control opcode and moving all out-of-band operations into the
control-frame payload.

Here too, I would not block consensus over this issue, so if most people
prefer them as opcodes I could go with that, though we would likely need to
allocate one of our precious reserved bits to the opcode field to do so, as
otherwise we would be leaving little room for growth.  Note that while we
could later add an extended opcode that lets you allocate additional
opcodes, that would be no different than using the control frame as
proposed, other than we would have reserved first-class opcodes for less
frequent frames while delegating presumably more frequent opcodes to
second-class status.


#4 - the presence of the complete message length field in the base protocol
===========================================================================
If we are supporting fragmentation in the base protocol, it seems that an
intermediary that fragments the message should be able to provide the
receiver the original message length, without requiring that recipient
support extensions.

Again, I would not object strongly to removing this (leaving CMLP as a
reserved bit) as long as that didn't bring back the objections about
fragmentation it was intended to address.


So, while I prefer the proposed solution in each of the above cases, I am
not entrenched against other options.  Can we get a feel from the group on
the following questions:

   - are there other divisive issues which need to be addressed before we
   can declare the framing for the base protocol done?
   - does anyone feel strongly enough about the above issues that they want
   to make a case for why an alternative should be chosen?  Or are there a lot
   of people who would be happier if a different choice was made?

If the answer to both of the above are no, can we accept this as the base
protocol?

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