On Wednesday, June 07, 2017 07:03:55 am Piotr Sikora wrote: > > Additionally, there's one bit of the spec which I question the need for: > > zlib support. Unless someone can show a legitimate case where zlib will > > consistently and notably outperform brotli, I don't see the point in > > defining it as an option. This is a bran new extension; we don't need > > backwards compatibility here. There's been a general consensus in this WG > > to avoid algorithm agility unless there's a real reason for it, so I > > propose we ditch zlib support and make brotli the default and only > > specified at the start (promoting it to id 0). Should some problem arise in > > the future where we actually need to use a decades old compression > > algorithm, it can be added later. Furthermore, we should probably define a > > pre-defined dictionary for brotli to use here which is based on common > > strings in certificates, rather than its default one for the general web > > (if such a thing is practical to do here). This could boost efficiency here > > and make it even more worth preferring (also likely reducing t he size of said dictionary, as the default one is 120kB). > > To play devil's advocate, why do suggest we ditch zlib and not Brotli? > > I just did an experiment using certificate chains for facebook.com > (ECDSA) and google.com (RSA). > [...snip...] > > As you can see, at level 1, Brotli is easily outperformed by gzip with > and without dictionary, at level 6, both are basically the same, and > at level 9/Z, Brotli wins by a small margin in terms of file size. > > However, you need to keep in mind that Brotli has significantly higher > cost of compression, both in terms of CPU and memory allocations > (>40MB at higher levels), which might be unacceptable in some > environments. > > Don't get me wrong, I'm a big fan of Brotli, but unless we want to > squeeze every single byte out of the compression and/or use > pre-compressed certificates, then maybe Brotli isn't the best and only > choice here?
This is a convincing argument to me. Thanks for the data. Given this information, I agree that supporting both algorithms can be helpful here, depending on server hardware constraints. I'm still curious to know if we can potentially create a lightweight cert-specific dictionary here that can boost things a bit. Or, is the QUIC one largely based on certs too? As to your devil's advocate suggestion: ... yeah, if Brotli doesn't give us any useful gains here over zlib, even with a new dict, I'd be ok with not specifying it for use. Your test does show it getting a small win at max compression, so that may not be the case. After fiddling with defining a new dict, test data against a larger set of certs could be useful. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
