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
>>
>>
>