Maybe a solution would be a better maximum fragment length extension which allows the size can be negotiated in a more fine-grained way, as pointed in: https://www.ietf.org/mail-archive/web/tls/current/msg12472.html
I also found these requests asking for larger packet sizes. https://www.ietf.org/mail-archive/web/tls/current/msg13569.html https://mailarchive.ietf.org/arch/msg/tls/K_6Ug4GtAxbrQJy2CFFFoxxtJ60 On Wed, 2016-11-23 at 00:46 -0800, Judson Wilson wrote: > I worry about the buffer sizes required on embedded devices. > Hopefully the other endpoint would be programmed to limit record > sizes, but is that something we want to rely on? This could be a > parameter agreed upon during the handshake, but that seems bad. > > > On Wed, Nov 23, 2016 at 12:41 AM, Nikos Mavrogiannopoulos <nmav@redha > t.com> wrote: > > On Wed, 2016-11-23 at 00:39 -0800, Judson Wilson wrote: > > > Can you send multiple records in one data transfer to achieve > > > whatever gains are desired? > > > > The packetization cost still remains even if you do that. However, > > the > > question is how does the 2^14 limit comes from, and why TLS 1.3 > > should > > keep it? > > > > regards, > > Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
