Re: [TLS] TLS Record Size Limitation

["Yngve N. Pettersen" <[e-mail]>]

On Tue, 08 Dec 2015 11:11:52 +0100, Peter Gutmann  
<[e-mail]> wrote:

> Dave Garrett <[e-mail]> 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