Re: #540: "jumbo" frames

On Wed, Jun 25, 2014 at 4:19 PM, Mike Belshe <mike@belshe.com> wrote:

>
>
>
> On Wed, Jun 25, 2014 at 1:12 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
>>
>>
>>
>> On Wed, Jun 25, 2014 at 12:59 PM, Willy Tarreau <w@1wt.eu> wrote:
>>
>>> Hi Roberto,
>>>
>>> On Wed, Jun 25, 2014 at 12:47:11PM -0700, Roberto Peon wrote:
>>> > The benefit to jumbo frames is solely that one can do fewer
>>> sendfile/splice
>>> > calls, at the cost of more framing complexity,
>>>
>>> If we just use a single bit to indicate whether the advertised length is
>>> shifted or not, I don't think we can call that "more framing complexity",
>>> and I would personally be fine with this (as with anything that allows
>>> to pass 1MB or so of data I guess).
>>>
>>>
>> Look at this from a hardware engineer's perspective. This bit changes how
>> you must structure hardware buffers in order to parse things properly.
>> This requires far more complexity for a hardware implementation, and
>> would reduce the chance that we get acceleration in HW for HTTP2.
>>
>>
>>> > and at the cost of having
>>> > naive implementations (especially server implementations) do things
>>> that
>>> > would affect performance/latency such that HTTP2 would be a downgrade.
>>> > Patrick mentions this, and it is a large motivator here-- getting the
>>> > muxing wrong, as is much more likely to happen with larger frame sizes,
>>> > means poor latency.
>>>
>>> Well, a naive implementation will not do any muxing at all, that's the
>>> most complex part to deal with in my opinion. I think that anyone who's
>>> able to implement the muxing correctly will not have any trouble with
>>>
>>>      len <<= (8 * R);
>>>
>>
>> That isn't what we've seen, however. We've seen that implementations get
>> that muxing is an important part of the protocol, however the implication
>> that small frames is essential to being able to respond quickly to a change
>> in circumstance is not.
>> Large enough frames might require a receiver to close the connection (as
>> we've seen from HTTP) when it is uninterested in a response when the
>> bandwidth is lower, for instance. Using smaller frames vastly decreases the
>> chance that this needs to be done, and simplifies the receiver's
>> implementation.
>>
>>
>>>
>>> And for senders, it does not change anything, they continue to send the
>>> reserved bit to zero and nothing changes over the wire.
>>>
>>> > Experimentation with this seems reasonable as an extension.
>>>
>>> I suspect that we're going to rediscover the benefits of TCP's window
>>> scaling :-/
>>>
>>>
>> Given that the frame size has nothing to do with RTTs or flow control, I
>> think that is orthogonal and completely different :)
>>
>
>
> +1 to everything Roberto stated here.
>

+1

PS: Sorry for the lame, late, terse response. I am too busy for more for
now, and everyone else already wrote all the content I would have written,
although I may have phrased things differently. This is clearly a decision
about tradeoffs, and different people prioritize different things
(responsiveness vs throughput, etc) differently. My position remains
unchanged from what I've previously voiced.


>
> Mike
>
>
>
>
>
>>
>> -=R
>>
>>
>>> Regards,
>>> Willy
>>>
>>>
>>
>