Re: Implementer intent -- option 3 for #578

On Thu, Oct 23, 2014 at 2:15 PM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Mark,
>
> On Thu, Oct 23, 2014 at 12:01:46PM +1100, Mark Nottingham wrote:
> > It looks like there's a good amount of interest in Option 3 (Willy's
> proposal) for issue #578. However, there's also concern that it is
> untested, and pushback on that basis.
> >
> > I am *extremely* wary of making a substantial change in the protocol at
> the last minute without implementation and testing; there is a large risk
> of introducing bugs, security issues and interop problems.
> >
> > So, if we want to pursue option #3, I think we need to do another
> Implementation Draft based upon it, with a subsequent interop. This will
> blow out our schedule by one cycle; historically, that means about two to
> three months (although the holiday season is approaching, so it may be
> longer).
> >
> > Such an interop might be another Interim (likely in January), or it
> might be virtual; we'd figure that out later.
> >
> > With that in mind, I'd like to hear from our implementers -- who is
> interested in this enough to implement a new draft and be able to bring it
> an interop on such a timeframe?
> >
> > Please, one person per implementation, and identify your implementation
> as you do so (we have enough now that it's necessary).
> >
> > Note that I'm not saying we're converging on option 3 yet -- I'm trying
> to find out more about what it would mean if we go in that direction.
>
> Speaking for haproxy, I'm far from having anything close to an
> implementation
> and don't expect to have one by the time we have a standard. However I'll
> implement whatever encoding we come up with by then since I'm not worried
> with swapping a few bits around. What matters for me is that we don't emit
> a new frozen standard that adapts poorly to new use cases. We've known the
> set-cookie mess, NTLM, pipelining issues and such things causing all of us
> some trouble with H1, I find it important to care a lot about possible
> future implementations.
>
> I would like it if someone with an easy-to-modify implementation could run
> some tests quickly, as I mostly focused minimizing changes first without
> having a working implementation to verify them, and am convinced the
> encoding I proposed is not optimal (as shown later in the same thread),
> and we'd rather ensure we don't degrade current performance in a new
> draft (which was the cause for this proposal). But since we don't have
> numbers yet, we could have good surprizes as well.
>
> Also since Jeff is the one who experienced the regression in the first
> place, he definitely has an example of problematic workload. It would
> be nice if he could either give this a try, or provide some traces to
> someone with a flexible implementation.
>
>
​I've done quick hack to implement option 3 in nghttp2:
https://github.com/tatsuhiro-t/nghttp2/tree/hpack-opt3

Not much tested, but it should work for me with hpack-test-cases.

deflatehd under src directory is handy to test compression ratio.
I don't have custom header dominated data to experiment with.

​I still think that unless it shows drastic improvements over -09 draft,
another interop is not worth it.

​Best regards,
Tatsuhiro Tsujikawa
​



> Best regards,
> Willy
>
>
>