On Mon, 2019-01-21 at 16:13 +1100, Martin Thomson wrote: > On Sat, Jan 19, 2019, at 19:02, Daiki Ueno wrote: > > My interpretation is that, if the client sent "record_size_limit" > > but > > didn't receive the extension from the server, that would mean the > > extension was not negotiated and the server may not respect the > > limit. > > > > Is this correct, or 64 is really mandatory to implement? > > Unfortunately, if you want your peer to respect your limit, then you > have to be willing to generate very small records. > > BTW, 64 is entirely an arbitrary number. It's at the point where the > overheads get really noticeable, so performance is probably pretty > bad well before you get to this point. But we didn't get any > indication that it was impossible to go that low. > > If there had been feedback about it being too small, I'm fairly sure > that a large number would have been fine. Do you know why 64 is > considered too hard to implement?
I do not think that 64 is not hard to implement, but I think it is very hard to implement it in a way that it is efficient. I have not measured specifically TLS with 64 byte packets, but my experience with ATM (telephony) which has 53-byte packets, suggest to avoid small packetizations if you want use your CPU for something other than packing and unpacking frames. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
