On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: > Hi, Nikos > > On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos <n...@redhat.com> > 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. 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). > 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). regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
