W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: #540: "jumbo" frames

From: Mike Belshe <mike@belshe.com>
Date: Wed, 25 Jun 2014 13:19:43 -0700
Message-ID: <CABaLYCuuy2K-arPbCfMgcsSNB7SEVm9NjOO20rmBwiuPF6k+Pw@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Willy Tarreau <w@1wt.eu>, Patrick McManus <pmcmanus@mozilla.com>, Jason Greene <jason.greene@redhat.com>, Nicholas Hurley <hurley@todesschaf.org>, Mark Nottingham <mnot@mnot.net>, K.Morgan@iaea.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Greg Wilkins <gregw@intalio.com>, IETF HTTP WG <ietf-http-wg@w3.org>, Martin Dürst <duerst@it.aoyama.ac.jp>
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.

Mike





>
> -=R
>
>
>> Regards,
>> Willy
>>
>>
>
Received on Wednesday, 25 June 2014 20:20:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC