Re: #540: "jumbo" frames

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

-=R


> Regards,
> Willy
>
>