On Wed, Jun 7, 2017 at 5:43 PM, Dave Garrett <davemgarr...@gmail.com> wrote:
> 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. > I'm not sure what units we are measuring in here: 222% of what? And what exactly is wrong with special formats that be much more compact on embedded devices, or enabling point compression? If you want root+intermediate+leaf that's 224 bytes of keys and signatures. Being sparing in extra data can probably have <300 byte chains, without the CPU overhead of compression at the cost of compatibility. > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
