Re: [hybi] Masking only Payload/Extension Data

[[e-mail]]

[e-mail] wrote on 03/09/2011 11:04:41 AM:

> On Wed, Mar 9, 2011 at 1:41 PM, <[e-mail]> 
wrote:
> Let me join in the voices for +1 on the use of reserved bit. 
> 
> I agree with your points of debate in the following messages: 
>  - http://www.ietf.org/mail-archive/web/hybi/current/msg06631.html 
>  - http://www.ietf.org/mail-archive/web/hybi/current/msg06633.html 
> 
> Reasons: 
> 
>  o Sniffers can choose whether to go ahead and parse masked payload 
>    based on the bit without having to capture from the start. 
>    (It greatly helps us in debugging or trouble shooting) 
> 
> I agree this is useful, but I disagree that this is sufficient to 
> warrant the cost.
>  
>  o Ability to turn off masking for debugging/trouble shooting. 
>    (this should not be manipulable by user code, of course, just to be 
clear)
> 
> This is orthogonal to whether to use a bit in the frame, and from 
> previous discussions there is little support for being able to disable 
it.

Right, I meant, to sniffers, the bit will tell whether the payload is 
masked
in the midst of trasferring data while turning on/off on the fly for
debugging purpose.

>  
>  o It is worthier allocating a bit for this than reserving it 
>    for something we don't even know especially when we still have 
>    at least a few bits left. 
> 
> The problem is there are only a few reserved bits, and we don't know
> how many it would be useful to have.  One thing that was discussed 
> earlier that would require allocation of a reserved bit would be 
> per-frame compression, so you can avoid compressing non-compressible
> data.  Another possibility is that we generally allocate more 
> opcodes for extensions, in which case we would like to be able to 
> allocate some of the reserved bits to the opcode field.  We won't 
> know we used too many until we need more than we have, at which 
> point it becomes expensive (50% additional overhead for small 
> frames) to get more.  When we came up with this framing, this was 
> the compromise between cost and leaving options open for the future 
> that everybody could live with.

Obviously you have much clearer picture of possible usage of the reserved
bits than I. I should respect your view/concern on this.

>  
> Think about it from an efficiency point of view -- you are 
> suggesting allocating a bit in every frame that is going to be the 
> same for every frame in the same direction.  How can that possibly 
> be good stewardship of limited resources, rather than specifying it 
> once in the header (or not at all if it is known to be set or clear 
> based on which side is initiating the connection)?

We are already sending these reserved bits on the wire for nothing as
of today, which is where I am coming from. (I understand, when we
need to extend reserved bits field in the future, that's when the use 
of bit may be perceived as 'extra-bandwidth'.)

> 
>  o Lacking the bit seems to be the source of sense of asymmetry - 
>    as in the frame not being self-descriptive for what's in the 
>    payload (not to be confused by 'understanding' the payload), 
>    seems to be a bad protocol design choice. 
>  
> The frame is already not self-descriptive -- if compression is 
> negotiated, you have to know that (plus the current compression 
> state) in order to interpret the frames.  Likewise, other extensions
> will likely modify interpretation of the payload.

The compression is an extension and is optional, where making is a MUST
in normal operations. We can always turn off compression, if needed during 

trouble shooting, then I am hoping to be able to dissect packets on
the wire with unmasked data on the screen. Since WebSocket is long
lived, it could be difficult to capture entire data with sniffer
with finite amount of memory/disk space, and I am aware Wireshark really 
slows down when it captures large files for a long time. If we could 
selectively capture/dissect data, that would be very very helpful.

> I still think it is not worth allocating a reserved bit to indicate 
> masking is present, but if most people want it I won't object too 
strenuously.

I have been spending large portion of my time for debugging/trouble 
shooting, I may be too concerned about debuggability. I understand your
points of arguments, though let me keep my +1 on the use of reserved
bit for now. Thanks a lot for your comments.


- Yutaka