On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos <[email protected]> wrote:
> On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: >> Hi, Nikos >> >> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos <[email protected]> >> wrote: >> >>> >>> Hi, >>> Up to the current draft of TLS1.3 the record layer is restricted >>> to >>> sending 2^14 or less. Is the 2^14 number something we want to >>> preserve? >>> 16kb used to be a lot, but today if one wants to do fast data >>> transfers >>> most likely he would prefer to use larger blocks. Given that the >>> length >>> field allows for sizes up to 2^16, shouldn't the draft allow for >>> 2^16- >>> 1024 as maximum? >> >> I am not opposed to this, but looking at real browsers and servers, >> we see that they tend to set the size of records to fit IP packets. > > IP packets can carry up to 64kb of data. I believe you may be referring > to ethernet MTU sizes. I’m referring to the IP packets that they actually use, and that is set by TCP to fit the PMTU, which is <= the ethernet MTU. In practice it is 1500 bytes for most network paths. > That to my understanding is a way to reduce > latency in contrast to cpu costs. An increase to packet size targets > bandwidth rather than latency (speed). Sure, but running ‘openssl speed’ on either aes-128-cbc or hmac or sha256 (there’s no test for AES-GCM or ChaCha-poly) you get smallish differences in terms of kilobytes per second between 1024-byte buffers and 8192-byte buffers. And the difference going to be even smaller going to 16KB buffers, let alone 64KB buffers. >> The gains from increasing the size of records from the ~1460 bytes >> that fit in a packet to nearly 64KB are not all that great, and the >> gains from increasing records from 16 KB to 64KB are almost >> negligible. At that size the block encryption dominates the CPU time. > > Do you have measurements to support that? I'm quite surprized by such a > general statement because packetization itself is a non-negligible cost > especially when encryption is fast (i.e., in most modern CPUs with > dedicated instructions). As long as you run over a network that has a smallish MTU, you’re going to incur the packetization costs anyway, either in your code or in operating system code. If you have a 1.44 GB file you want to send, it’s going to take a million IP packets either way and 100 million AES block operations. Whether you do the encryption is a million 1440-byte records or 100,000 14,400-byte records makes a difference of only a few percent. Measurement that we’ve made bear this out. They’re with IPsec, so it’s fragmentation rather than packetization, but I don’t think that should make much of a difference. Again, I’m not opposed to this. A few percent is a worthy gain. Yoav
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
