Thanks for replies everyone. I also posted the same question the OpenSSL mailing list. One interesting response stated that the size was limited to prevent DOS attacks due to resource exhaustion (in the case that data was being injected).
"The peer is required to buffer the entire record before processing it, at at that point the data could be from an untrusted party/attacker. So the limit is for protection against denial-of-service via resource exhaustion." Not sure If I totally buy this as you have the same issue (on a smaller scale) w/16K buffers. Also, you underlying application implementation would have alot to due with as well. On Tue, Dec 8, 2015 at 5:20 AM, Yngve N. Pettersen <yn...@spec-work.net> wrote: > On Tue, 08 Dec 2015 11:11:52 +0100, Peter Gutmann < > pgut...@cs.auckland.ac.nz> wrote: > > Dave Garrett <davemgarr...@gmail.com> writes: >> >> A TLS extension to negotiate max length might be viable. >>> >> >> I think a better starting point would be to look at the implementation >> that's >> causing the problem. There's nothing magical about a 16K max segment size >> that causes poor performance, TCP typically has an MSS of 1400-1500 >> bytes, one >> tenth of the TLS segment size, without there being a 187% loss in >> throughput >> so it looks like the problem is in the implementation, not the protocol. >> I >> don't see any reason why you couldn't get close to wire speeds, or at >> least >> min( crypto speed, wire speed ) for TLS for a properly-done >> implementation. >> >> > Based on my past experience, a possible reason is that the code does the > following: > > read_event_handler: > read data from socket > decrypt data > handle application data > return > > rather than: > > read event handler: > read data from socket > queue data for decryption > signal decryption handler > return > > decryption handler: > decrypt data > handle application data > > Another factor I have seen influencing speed is the size of the buffer > reading from the socket, bigger buffer gives better speed. Within reason, > of course; IIRC the benefit of increasing the buffer stops at around 5-10% > of the connection speed. A good rule of thumb is that the buffer should be > larger than the largest block that you will ever receive over the > computer's local connection, provided you read the arriving data when you > are notified about the data. > > I recently saw 10x+ speed increase by changing an application's handling > of these two aspects (on Windows). In that case 300KB buffer was > sufficient, but I prefer a 1 MB buffer. > > > > -- > Sincerely, > Yngve N. Pettersen >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
