Re: [TLS] TLS Record Size Limitation

"Yngve N. Pettersen" <yngve@spec-work.net> Tue, 08 December 2015 11:20 UTC

Return-Path: <yngve@spec-work.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628281B29BB for <tls@ietfa.amsl.com>; Tue, 8 Dec 2015 03:20:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQRy-GDboOuR for <tls@ietfa.amsl.com>; Tue, 8 Dec 2015 03:20:57 -0800 (PST)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383C41AD1F5 for <tls@ietf.org>; Tue, 8 Dec 2015 03:20:56 -0800 (PST)
Received: from 36.54.34.95.customer.cdi.no ([95.34.54.36]:63612 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <yngve@spec-work.net>) id 1a6GKD-0007KQ-S6; Tue, 08 Dec 2015 12:20:53 +0100
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Dave Garrett" <davemgarrett@gmail.com>, "Software Engineer 979" <softeng979@gmail.com>, "Peter Gutmann" <pgut001@cs.auckland.ac.nz>
References: <CANSok=bDBCo4ko9WAoTurt84Krinpsf6_=g3Hq0-JWiiSo3WjQ@mail.gmail.com> <201512080349.59635.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4BA2303@uxcn10-5.UoA.auckland.ac.nz>
Date: Tue, 08 Dec 2015 12:20:39 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.x9bogpkt3dfyax@killashandra.invalid.invalid>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BA2303@uxcn10-5.UoA.auckland.ac.nz>
User-Agent: Opera Mail/12.17 (Win32)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/WtOonNAme068ruj14Cz4QaIhfd4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS Record Size Limitation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 11:20:59 -0000

On Tue, 08 Dec 2015 11:11:52 +0100, Peter Gutmann  
<pgut001@cs.auckland.ac.nz> wrote:

> Dave Garrett <davemgarrett@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