Re: Fragmentation for headers: why jumbo != continuation.

And yes I realize this is on-list, but this is how I see it, and I think it
should be clear already :)
-=R


On Fri, Jul 11, 2014 at 7:11 PM, Roberto Peon <grmocg@gmail.com> wrote:

> I like the larger frame max-length so long as the max-framesize setting is
> there.
> imho, 64k is big enough given that MTU is likely to stay below 64k for the
> forseeable future (~9k is the current jumbo frame!).
> When we venture into things like QUIC, smaller frame sizes will become
> important, as you really want to fit frames into packets-- that way the
> encryption context doesn't require HoL blocking when there is packet loss,
> and things like FEC can work.
>
> I don't like things that require buffering at the protocol level-- that
> should be an implementation decision.
> I think that people are underestimating the value that announcing limits
> gives to attackers.
> It is often better to accept a request/header that you know you won't
> serve and just sit on it for a while than it is to reject it quickly.
> Rejecting quickly and announcing limits allows the attacker to easily
> optimize their attack. Not good.
>
> I don't like interleaving-- it multiplicatively increases the DoS surface
> (and makes it significantly worse than it was with HTTP/1)
>
> I do wish that there was a more clear separation of session-layer and
> HTTP, but I wasn't able to win that argument way back when.. :)
>
> I think that continuations are ugly in terms of flag handling, but are
> otherwise not too difficult to handle.
> The state machine essentially lends itself to:
> see HEADERS, stay in HEADERS state until you seen END_HEADERS on a frame.
>
> -=R
>
> On Fri, Jul 11, 2014 at 6:43 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
>>
>> On 11 July 2014 10:41, Roberto Peon <grmocg@gmail.com> wrote:
>>
>>>
>>> I like some of the parts of what you proposed there, and don't like
>>> other parts. I'd prefer discussing that in a separate thread, though so we
>>> don't dilute this conversation too much.
>>> -=R
>>>
>>
>> Roberto,
>>
>> [offlist]
>>
>> I'm curious as to what parts of this thought bubble you like and what
>> bits you don't?
>>
>> I think the current inability to reach consensus is due to some earlier
>> poor design decisions that forced the WG down a path that nobody is really
>> happy with and I fear that the current disputes are really just fighting
>> over where to put the deck chairs on the titanic.
>>
>> I basically agree with you that headers should be fragmentable and
>> interleavable( I also think they should be flow controllable ), however
>> that requires changes to HPACK, which I did not think the WG was willing to
>> make, hence my proposal for a single frame header (the better of two evils
>> with regards to continuations).
>>
>> However, if the current stalemate and additional concerns you have raised
>> do inspire a new interest in revisiting HPACK, then perhaps there might
>> come an opportunity for something a bit more radical and  I might consider
>> putting some effort into preparing a real proposal along the lines of this
>> thought bubble.
>>
>> Hence I'm interested in what you did/didn't like about the idea of
>> mapping HTTP semantics onto data frames?
>>
>> Fundamentally I would like the code that has to deal with all the framing
>> concerns: buffering, fragmentation, interleaving, priority, aggregation,
>> flow control, etc.   to be application protocol neutral.    It should not
>> know or care if it is transporting headers or data or websockets etc.
>> All it need to do is give enough indication of where the semantics are so
>> that actors that do need to know some more semantics (eg proxy routing
>> algorithm) know where in the stream to look to apply higher level
>> decoding.  I think stream segments are sufficient for that.
>>
>> Anyway,  if you have any additional personal bandwidth,  I'd be
>> interested in your thoughts.
>>
>> I don't think the WG is actually ready/interested in such a proposal at
>> the moment (hence offlist), but who knows what the future may hold.
>>
>> cheers
>>
>>
>>
>>
>>
>>>
>>>  On Thu, Jul 10, 2014 at 4:38 PM, Greg Wilkins <gregw@intalio.com>
>>> wrote:
>>>
>>>>
>>>> Roberto,
>>>>
>>>> I agree that this is a concern, even if large headers are only 0.01%
>>>> (or whatever it is ) of the traffic.
>>>>
>>>> But I don't think fragmentation on it's own is sufficient. You need
>>>> fragmentation and flow control.       To achieve this we need to stop
>>>> treating headers as a special case and forget about any deadlines by the
>>>> end of the year. I would propose that:
>>>>
>>>>    - We remove HEADERS, CONTINUATION and PUSH_PROMISE from the
>>>>    specification
>>>>    - We retain END_SEGMENT in DATA frames
>>>>    - Streams are created by sending a stream SETTINGs frame with a
>>>>    PROTOCOL parameter!
>>>>
>>>> We now have a multiplexed framing layer that is totally devoid of any
>>>> knowledge of HTTP!   The framing supports segmented data streams that are
>>>> flow controlled and of unlimited size.    We then come up with an mapping
>>>> of HTTP semantics to this framing layer:
>>>>
>>>>    - HTTP streams start with a SETTINGS frame that has PROTOCOL=h2
>>>>    - Odd data segments on the stream carry header/trailers.  So a
>>>>    Stream with  1 segment is just headers. A stream with 3 segments is
>>>>    headers, data, trailers etc.
>>>>
>>>> Now we have to work out how to encode the headers into those data
>>>> frames.  The stateless parts of HPACK are a pretty reasonable start, using
>>>> Static-H gives a 0.66 compression factor.  However, I think there are
>>>> probably other alternatives that are less order dependent - eg sending the
>>>> header set mutations only on stream 0 and normal decoding does not mutate
>>>> the table. If we wanted to make HTTP a bit of a special case, we could go
>>>> to Linear-H, with 0.31 compression factor, but then decoding of the headers
>>>> must be done in the order they are sent - making header compression part of
>>>> the framing layer.... but I could live with a little bit of conflation for
>>>> efficiency purposes:)
>>>>
>>>> With this scheme, we could even support lazy proxies that would send
>>>> HTTP/1.1 by having PROTOCOL=h1 on a stream and just sending the http/1
>>>> bytes unaltered.   Websocket could be supported the same way or it too
>>>> could have it's own segmented data mapping.
>>>>
>>>> Even if we go for a less drastic way to do fragmentation of headers, I
>>>> think the process has to be the same - start with data frame semantics and
>>>> work out how to transport compressed headers.  Don't come up with a
>>>> different fragmentation/flowcontrol regime based on the content of the
>>>> frame.
>>>>
>>>>
>>>> cheers
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 11 July 2014 06:27, Roberto Peon <grmocg@gmail.com> wrote:
>>>>
>>>>> There are two separate reasons to fragment headers
>>>>>
>>>>> 1) Dealing with headers of size > X when the max frame-size is <= X.
>>>>> 2) Reducing buffer consumption and latency.
>>>>>
>>>>> Most of the discussion thus far has focused on #1.
>>>>> I'm going to ignore it, as those discussions are occurring elsewhere,
>>>>> and in quite some depth :)
>>>>>
>>>>>
>>>>> I wanted to be sure we were also thinking about #2.
>>>>>
>>>>> Without the ability to fragment headers on the wire, one must know the
>>>>> size of the entire set of headers before any of it may be transmitted.
>>>>>
>>>>> This implies that one must encode the entire set of headers before
>>>>> sending if one will ever do transformation of the headers. Encoding the
>>>>> headers in a different HPACK context would count as a transformation, even
>>>>> if none of the headers were modified.
>>>>>
>>>>> This means that the protocol, if it did not have the ability to
>>>>> fragment, would require increased buffering and increased latency for any
>>>>> proxy by design.
>>>>>
>>>>> This is not currently true for HTTP/1-- the headers can be
>>>>> sent/received in a streaming fashion, and implementations may, at their
>>>>> option, choose to buffer in order to simplify code.
>>>>>
>>>>> -=R
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Greg Wilkins <gregw@intalio.com>
>>>> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
>>>> scales
>>>> http://www.webtide.com  advice and support for jetty and cometd.
>>>>
>>>
>>>
>>
>>
>> --
>> Greg Wilkins <gregw@intalio.com>
>> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
>> scales
>> http://www.webtide.com  advice and support for jetty and cometd.
>>
>
>