Re: HTTP/2 and Websockets

On 22 November 2014 00:01:49 GMT+08:00, Amos Jeffries <squid3@treenet.co.nz> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 22/11/2014 12:53 a.m., Andy Green wrote:
>> 
>> 
>> On 21 November 2014 18:57:13 GMT+08:00, Amos Jeffries 
>> <squid3@treenet.co.nz> wrote: On 21/11/2014 7:58 p.m., Andy Green 
>> wrote:
>>>>> 
>>>>> 
>>>>> On 21 November 2014 14:41:19 GMT+08:00, Yutaka Hirano 
>>>>> <yhirano@google.com> wrote:
>>>>>> On Fri, Nov 21, 2014 at 12:38 PM, Andy Green 
>>>>>> <andy@warmcat.com> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 21 November 2014 11:30:46 GMT+08:00, Yutaka Hirano
>>>>>> <yhirano@google.com>
>>>>>>> wrote:
>>>>>>>> On Fri, Nov 21, 2014 at 11:42 AM, Andy Green 
>>>>>>>> <andy@warmcat.com>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 21 November 2014 10:02:28 GMT+08:00, Yutaka
>>>>>>>>> Hirano
>>>>>>>> <yhirano@google.com>
>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> I think you have to take the atomic large ws
>>>>>>>>>>> frame thing as a
>>>>>>>> genuine
>>>>>>>>>>> problem because http2 has the transmit credit 
>>>>>>>>>>> concept. So even
>>>>>> if
>>>>>>>>>> you
>>>>>>>>>>> buffered one ws frame, you can't sit there
>>>>>>>>>>> spewing as much
>>>>>> http2
>>>>>>>> DATA
>>>>>>>>>> frame
>>>>>>>>>>> as it needs to atomically encapsulate it, without
>>>>>>>>>>>  sizing your
>>>>>>>> http2
>>>>>>>>>> frame
>>>>>>>>>>> to suit the tx credit. But it's OK because the 
>>>>>>>>>>> implementation can transparently
>>>>>> fragment
>>>>>>>> the
>>>>>>>>>> ws
>>>>>>>>>>> data using the ws message semantics... I think 
>>>>>>>>>>> there's no
>>>>>> choice
>>>>>>>> but
>>>>>>>>>> to
>>>>>>>>>>> take that approach.
>>>>>>>>>> 
>>>>>>>>>> Sorry I don't understand what you are proposing.
>>>>>>>>>> Can you explain?
>>>>>>>>> 
>>>>>>>>> I'm agreeing with what was already written by
>>>>>>>>> someone else on the
>>>>>>>> thread.
>>>>>>>>> 
>>>>>>>>> Talking about buffering huge ws frames until you have
>>>>>>>>>  enough to
>>>>>> issue
>>>>>>>> it
>>>>>>>>> all in one big http2 DATA frame will not fly.
>>>>>>>>> 
>>>>>>>>> If you're using this putative ws-over-http2 scheme,
>>>>>>>>> and you get
>>>>>> given
>>>>>>>> a
>>>>>>>>> huge ws frame to transmit, you should fragment it 
>>>>>>>>> using RFC6455
>>>>>>>> message
>>>>>>>>> semantics to some implementation-defined limit that
>>>>>>>>> is friendly
>>>>>> for
>>>>>>>> mux'd
>>>>>>>>> http2 transport.
>>>>>>>>> 
>>>>>>>> Thanks.
>>>>>>>> 
>>>>>>>> Strictly speaking, RFC6455 allows an extension to give
>>>>>>>>  meaning to WebSocket frames, so merging / fragmenting 
>>>>>>>> frames breaks such extensions. We discussed this
>>>>>>>> problem in HyBi and many of us said "don't care".
>>>>>>> 
>>>>>>> Yeah extensions except for compression have just not
>>>>>>> come into
>>>>>> existence.
>>>>>>> 
>>>>>>> So I also see it as don't care.  I'm not even sure it's 
>>>>>>> true since
>>>>>> the
>>>>>>> intention during ws discussion was an intermediary can 
>>>>>>> fragment
>>>>>> frames same
>>>>>>> as how tcp packets may be fragmented.
>>>>>>> 
>>>>>>>> In any case, an http/2 frame cannot be bigger than
>>>>>>>> 2^24 (or 2^14 without an explicit permission), so I
>>>>>>>> think we don't have to worry about DoS.
>>>>>>> 
>>>>>>> ... I don't see that.  If I keep spamming 16MB frames
>>>>>>> even on one
>>>>>> stream
>>>>>>> on a consumer link your latency goes to pieces and if 
>>>>>>> something is
>>>>>> doing
>>>>>>> multiple instances of it even a big pipe will feel pain.
>>>>>>> 
>>>>>>> 
>>>>>> The spec says: Length: The length of the frame payload 
>>>>>> expressed as an unsigned 24-bit integer. Values greater
>>>>>> than 2^14 (16,384) MUST NOT be sent unless the receiver has
>>>>>> set a larger value for SETTINGS_MAX_FRAME_SIZE. So by
>>>>>> default 2^14 is the upper limit. Larger frames will be used
>>>>>> only if the receiver wants.
>>>>> 
>>>>> Okay.  But if buffering whole ws frames no matter how big
>>>>> was the plan, and the one end wanted to send a 16MB ws frame,
>>>>> the other end would say, "sure" you can send me >16K and he'd
>>>>> spam his 16MB frames.  Default 16K limit doesn't help much
>>>>> because the server is complicit in thinking sending huge ws
>>>>> frames is good.
>>>>> 
>> 
>> You switched between "receiver" and "server" there in your
>> concepts.
>> 
>>> Well okay, it's not my day job.
>> 
>> Overlooking the fact that intermediaries in HTTP can cut DATA up 
>> into smaller frames and stitch them together into larger ones as 
>> needed hop-by-hop. So what your sender gets told it can send on the
>>  client->proxy connection may not be what gets delivered to the 
>> server.
>> 
>> That was the major reason for WSDATA not being HTTP/2 DATA. That 
>> flags byte being mentioned at the beginning of DATA payload will
>> get screwed over and moved around too much. Unless it is at fixed 
>> positions of the total WS stream inside the DATA payloads.
>> 
>>> What does 'too much' mean... it should not attempt to preserve
>>> the original ws frame sizes, just send http2 frames of a size
>>> that suit it when an amount of ws payload data that suits it has
>>> appeared. So the bit of tx logic that chops up the ws payload
>>> data, takes care of deferring FIN until the last chunk.  And the
>>> receiver doesn't have to do anything just pass up the frames it
>>> got with the ws flags it got.
>> 
>>> What's the problem?
>
>"with the ws flags it got" is the problem. HTTP/2 recipients know
>nothing about any syntax embeded in the opaque DATA payload area.

Well I think this boils down only to the "intermediary who doesn't know about tracking stream upgrade state corrupting DATA" thing.  Otherwise there's no problem chopping up ws frames.  If that's not it please help me with an example corruption sequence.

>> But then, as has been mentioned since HEADERS initiated a WS
>> stream, why is DATA needing to be re-flagged specially? it is
>> opaque payload bytes of the stream already flagged as being a WS
>> transaction.
>> 
>>> I think it's alright being an implicit attribute of the stream.
>> 
>>> But I understood the general objection from Hirano-san, it's
>>> that there might be dumb proxies who didn't follow the update
>>> activity on that stream and might parse what they see there as...
>>> http2 data.
>> 
>>> 'Magic bad proxies' was a stick that extinguished a lot of 
>>> discussion on hybi.... he's not going to get fired for shaking
>>> that stick at us.  It doesn't damage the argument to point out
>>> there's no evidence the bad proxy exists.  But if it's WSDATA and
>>> http2 wraps up without containing WSDATA this stuff will never
>>> get deployed, because if anybody doesn't understand WSDATA the 
>>> connection won't work even if the handshake does, lol
>
>Nod. One of the flaws behind the basic concept of WebSockets is that
>it imposes knowledge upon the underlying routing infrastructure - or
>dies.
>
>Imagine how useful (or not) TCP would be if you could successfully
>SYN/SYN+ACK a stream setup, then had to rely on every IP-router along
>the pathway decoding and processing the layer-7 protocols inside the
>TCP stream in order to pass on each packet - or would terminate the
>connection. The Internet would be a very different and unfriendly
>place.
>
>
>
>If its a DATA frame then recipients should be handling it as per the
>HTTP/2 spec handling regardless of WS knowledge level. The DATA
>payload is opaque and may be sliced and diced on any 8-bit boundary
>within, so long as the end recipient gets it all in proper order.
>(Think DATA approximates TCP DATA packet with HEADERS as the SYN
>handshake preceeding it all).

Yeah... libwebsockets anyway has a bytewise parser so he doesn't care about as much fragmentation as you like.

>So it comes down to a question of what WSDATA frames do exactly. Are
>they there to signal length+etc information about formatted chunks of
>the data stream? or are they there to transfer opaque payload blobs
>around?

Literally they are there to hide the payload from Hirano-san's theoretical intermediary that treats all DATA as something to corrupt, otherwise we can put it in DATA neatly.

> - if they are there for passing opaque payload, then that overlaps
>directly with DATA and the WS specific bits seem needless.
> - if they are there to signal lengths or type of pieces inside the
>payload, then a DATA sequence with all the formatting meta data
>opaquely inside it would be the right mapping IMHO. WS just needs to
>be able to receive and parse it separately to the DATA frames which
>deliver the bytes.

Hirano-san will throw his DATA-corrupting proxy at any solution involving non http2 data inside DATA, which applies to what you're saying there.  So it can't go forward unless Hirano-san recants.

At some point the protocol tunelling with full frames doesn't buy anything over the individual streams doing a full ws upgrade themselves (they can do that today on http2, right?) and then the DATA frames... will contain ws frames... the thing Hirano-san says is verboten due to the magic corruption proxies...

-Andy

>Amos
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2.0.22 (MingW32)
>
>iQEcBAEBAgAGBQJUb2HsAAoJELJo5wb/XPRjfq0IAInV42knM225y7NprbTxEHdG
>fqIAyfGq7B6yZzsgVlPkG0v88CVLOqrzdmlqT8BVuBqna0Q6Fe97HTVjDMMoYyW0
>5bcpcNukq7AbdCGS0gcy2aGwiHb1NGLUr5N4/ZgNCQHxZmKIsk3r1ffgRh2friXh
>mzLDdAbXKOrt3TNDBzAib2sIQENxv/2vH3Fhc4NBesbWHhsDXqhdWlO9DVi6iALC
>YU0LrjZDptCEvrEZudOzlJP4UQ4cx0jUoFS31plZHuM8pVoPYt2nb4rnNzMieiTv
>JkKvO3+4cd2g6zd1rfmTDgr1yulKwj4D8EUzF+0HyARghNA6bnenlgi0GTdqTVg=
>=c2/+
>-----END PGP SIGNATURE-----

Received on Friday, 21 November 2014 16:42:43 UTC