Re: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt

Bodo Moeller <bmoeller@acm.org> Fri, 04 June 2010 19:51 UTC

Return-Path: <SRS0=h2jj=NM=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD483A69C7 for <tls@core3.amsl.com>; Fri, 4 Jun 2010 12:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.261
X-Spam-Level:
X-Spam-Status: No, score=-100.261 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_50=0.001, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7HuPeouDdnU for <tls@core3.amsl.com>; Fri, 4 Jun 2010 12:51:39 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 12B213A69C0 for <tls@ietf.org>; Fri, 4 Jun 2010 12:51:38 -0700 (PDT)
Received: from [172.16.124.10] ([74.125.121.49]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Ldqml-1P34Xq1HMJ-00iNnO; Fri, 04 Jun 2010 21:51:22 +0200
From: Bodo Moeller <bmoeller@acm.org>
To: mrex@sap.com
In-Reply-To: <201006041537.o54FbT23020988@fs4113.wdf.sap.corp>
References: <201006041537.o54FbT23020988@fs4113.wdf.sap.corp>
Message-Id: <92D302BA-E0F2-41FB-89DA-682B8AEB21A4@acm.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 4 Jun 2010 21:51:18 +0200
X-Mailer: Apple Mail (2.936)
X-Provags-ID: V01U2FsdGVkX18+3qOUaF8hC4AAz9XwNhV+I7HGz0VtVuDKHNn Pz/bMm9vx6kVjTyQ5auwl9+JkYgKHhEIkKM9Qlsc79pt57flMX idEiJ8J9rtCcDpFhtb6AA==
Cc: tls@ietf.org
Subject: Re: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Fri, 04 Jun 2010 19:51:40 -0000

On Jun 4, 2010, at 5:37 PM, Martin Rex wrote:
> Brian Smith wrote:

>> Trying to separate the packets will [not] do any good, as the  
>> server operating
>> system is just going to coalesce them anyway before the application  
>> can
>> process them.  And, sending separate packets would be quite a  
>> pessimization
>> for the GRPS clients that would benefit the most from this extension.
>
> The underlying operating system is not allowed to coalesce across a
> TCP Push boundary.

I don't think this is accurate.  Even with the "push" bit set, while  
the receiving system shouldn't just buffer the data waiting for more,  
the later TCP record may already have arrived when the earlier one is  
being processed, and boundaries won't necessarily be preserved.   
Heuristically, the sender's boundaries often *will* reappear as  
boundaries when receiving, but this isn't reliable.

Bodo