Re: Straw Poll: Restore Header Table and Static Table Indices

Willy, if you have a concrete proposal that you think can can strong consensus, please make it ASAP. Stopping the work to do research on whether a change is necessary isn't appropriate at this point in the work; that train left the station a while ago.

Cheers,


On 7 Oct 2014, at 4:49 pm, Willy Tarreau <w@1wt.eu> wrote:

> On Tue, Oct 07, 2014 at 04:41:06PM +1100, Mark Nottingham wrote:
>> Willy,
>> 
>> On 7 Oct 2014, at 4:28 pm, Willy Tarreau <w@1wt.eu> wrote:
>> 
>>> On Tue, Oct 07, 2014 at 03:24:45PM +1100, Mark Nottingham wrote:
>>>> That's not where we're at, Greg.
>>>> 
>>>> The current stance on changing the static table was that we'd do so *if*
>>>> we've agreed to make other breaking changes. 
>>> 
>>> But Mark, people's experience differ depending on the environment where
>>> they deploy the protocol, so that means that the current status is too
>>> white or too black and that possibly making it a little bit grayer would
>>> make it more suitable for most environments. I don't see what's wrong
>>> with considering feedbacks from real deployments, *even at this stage*.
>>> Otherwise that means testers are useless and we should just work on
>>> paper with a wet finger in the wind.
>> 
>> We are certainly considering feedback from deployment, and we're also
>> considering many other things. 
>> 
>> So far, the WG is strongly leaning towards not making a change here,
> 
> No, the WG is strongly against *reverting* as it's the only option that
> was offered. One user in a very specific case encounters issues, and one
> of the HPACK authors thinks this radical change was a mistake. I think it
> at least deserves being studied. I don't think either that reverting would
> be a good idea, but I too think that one of the benefit of HPACK lies in
> its ability to act as a cache of recently used header fields at a very low
> cost, and the last change has increased this cost. Maybe just offering
> provisions for 16 indexed headers instead of zero would significantly
> improve the situation without affecting other users at all, but that
> option was not offered yet.
> 
>> and I
>> don't see any overriding security or interoperability concern that would make
>> a change at this late stage necessary.
>> 
>> We've discussed this many times, and had it confirmed by our Area Director;
>> it's entirely appropriate to reject changes that don't meet this bar (either
>> an overriding security or interop issue, or strong group consensus to make
>> the change) at this point in the lifetime of the protocol.
> 
> I understand this, but I just think that we should at least wonder whether
> Jeff's case is unique (in which case we can decide to ignore it) or just a
> preview of many new ones that the protocol will meet after the release. At
> least thinking a bit could avoid this bitter late feeling of "too bad we
> didn't do X or Y when the same issue was reported 6 months ago".
> 
> That's my point.
> 
> Willy

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 7 October 2014 05:54:31 UTC