W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Re: Call for Adoption: HTTP/2 Bis

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 23 Dec 2020 15:25:15 +1100
Cc: Willy Tarreau <w@1wt.eu>, Ian Swett <ianswett@google.com>, Tommy Pauly <tpauly@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <D096EAC3-CEA1-472B-89D3-21954E6DD6CE@mnot.net>
To: Cory Benfield <cory@lukasa.co.uk>


> On 22 Dec 2020, at 7:39 pm, Cory Benfield <cory@lukasa.co.uk> wrote:
> 
> 
> 
>> On 20 Dec 2020, at 06:55, Willy Tarreau <w@1wt.eu> wrote:
>> 
>> On Sat, Dec 19, 2020 at 03:38:56PM -0500, Ian Swett wrote:
>>> A question for the working group is: Are there servers that are going to
>>> actively pursue GREASE in H2?  We might do some, but it'll be limited in
>>> scope due to past issues.
>> 
>> I'd say "it depends". I'm seeing two impacts of enabling GREASE on the
>> server side:
>> 
>> - a lot of server-side users don't want to disclose what technologies
>>   they are using, and try hard to limit the visible signatures outside.
>>   By having a server start to emit random frame types, it will
>>   inevitably sign itself.
>> 
>> - a large number of performance testing tools do not care about standards
>>   since the goal is to focus on performance, and I suspect that when such
>>   tools will be used against a grease-enabled server, they will report
>>   failures that will scare their users away.
>> 
>> All these could be addressed by having an option to disable greasing, but
>> in both cases users will be fooled. The first ones will consider the server
>> had purposely cheated on them. The second ones won't go past the initial
>> test and will declare the server as bogus. And by having an option to
>> explicitly enable greasing, well, I doubt users will enable it "for the
>> sake of improving the net" if they know it can cause some trouble to them.
> 
> This is accurate. Server implementers are often caught in a bind between “want to conform tightly to the spec” and “get scored based on nonsensical microbenchmarks”. The end result is that plenty of servers take liberties with parts of the specification, and offer modes where you can disable their spec conformance features for speed. Even more just don’t bother to conform at all.
> 
> I think the bigger issue with greasing, though, is the failure mode Willy is outlining. Servers that fail to interoperate with a client when all other servers do are “broken”, even when they are morally in the right and the clients are morally in the wrong. Blame is always assigned to the most recent thing that changed, or the thing you can easily test with.

My .02 - this makes me think that we need to carefully consider the incentives for (and against) adoption if we do introduce a new ALPN for greasing. Adding grease to the existing h2 is one thing; people can adopt it or not as they see fit, within the bounds of interoperability. OTOH if greasing is segregated into a separate ALPN identifier, it's going to create disincentives for adoption (and perhaps implementation) by some people. 

Cheers,


--
Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 23 December 2020 04:25:41 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 23 December 2020 04:25:44 UTC