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

[Willy Tarreau <[e-mail]>]

Hi Mark,

On Mon, Oct 13, 2014 at 11:52:43AM +1100, Mark Nottingham wrote:
> Roberto,
> 
> So far, we've had a large number of people -1 any change here. Summarising:
> 
> * It's been asserted that the current approach is "much simpler" to implement
> * The difference is "marginal" 
> * There's concern about "churn" in the spec and implementations
> * There's concern that the proposals are untested 
> 
> You say it's "highly suboptimal", but you don't back this up. Indeed, we've
> long established that the WG is not terribly interested in getting the *most*
> efficient compression available -- especially if it's bought with complexity.

I think the complexity that was lost with the change was the copy from static
to dynamic. In fact, swapping static and dynamic was done only to get smaller
indexes on static that can now be compressed in one byte, possibility that was
previously offered to dynamic headers only. What we really need to satisfy all
users is to be able to encode *most common* static headers with 1 byte, and
a number of dynamic headers with 1 byte as well.

> As Mike said once long ago, the important part is that we get *some*
> compression, and my perception is that there's wide agreement in the WG on
> that point.

I also agree with this.

> In the face of that, a one-byte overhead for dynamic headers is hard to
> characterise as "highly suboptimal."

I wouldn't be as categoric as Roberto here but I understand his point. The
previous design allowed headers not belonging to the static table to be
correctly compressed (whatever X-* headers appearing inside companies).
The new one makes new headers less efficient than the static ones, and I
think Roberto sees less possibilities of future improvements with this
design.

> Other folks have discussed / proposed more elaborate changes than Jeff, but I
> detect very little stomach in the WG for doing so.
> 
> At most, I think we're at a point where the most reasonable thing to do, *if*
> we do anything here, would be to revisit the static table and "make room" for
> more dynamic entries by pruning it some, as per
> <https://github.com/http2/http2-spec/issues/587>.

It's more or less similar to what I suggested as well to what I proposed except
that we don't need to *prune* some entries if the single-byte encoding covers
part of both tables.

> However, as discussed before, we'd need to see broad support for such a
> change; so far, we've held that #587 will only happen if we're making other
> breaking changes.

The problem when there are implementations available is that developers know
what it means for them to have to modify them : modify both encoders and
decoders in multiple products, plan certain outages etc... The problem is
that we need to be careful about future users, not early adopters, and all
of us have to think about how efficient the protocol will be in 1-10 years,
not just right now in implementations that will inevitably evolve in the
following months.

I personally think that the single-byte encoding of *some* dynamic headers
has a real value, and even if people are not pleased with revisiting their
code, we should do something for it.

Best regards,
Willy