Re: [tcpm] Faster application handshakes with SYN/ACK payloads

Joe Touch <touch@ISI.EDU> Sun, 21 September 2008 21:53 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 3C40C28C193; Sun, 21 Sep 2008 14:53:00 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA97D3A6C18 for <>; Sun, 21 Sep 2008 14:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IcQwnPxiXN2I for <>; Sun, 21 Sep 2008 14:52:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 238A03A6877 for <>; Sun, 21 Sep 2008 14:52:58 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m8LLqkRg028952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 21 Sep 2008 14:52:48 -0700 (PDT)
Message-ID: <>
Date: Sun, 21 Sep 2008 14:52:46 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Stefanos Harhalakis <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: Adam Langley <>,
Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hash: SHA1

Hi, Stefanos,

Stefanos Harhalakis wrote:
> Hello,
> I'm sending this reply mostly to clarify the things. Perhaps there is 
> something that I don't understand or I don't express well. If it is so, 
> please excuse the stubbornness of mine.
> On Sunday 21 September 2008, Joe Touch wrote:
>> HTTP does send a banner of that type; the issue is that you want #2
>> above - if you don't act on the banner info until after the TWHS, you
>> "waste" an RTT waiting for the connection to be established before the
>> server can reply.
>> That's a **design feature** and requirement of TCP, not a "waste".
> I don't exactly understand what you mean by saying that HTTP sends a banner. 
> An HTTP server will never send anything unless it is triggered to do so by a 
> client request. Creating an HTTP version that sends an initial one-line (or 
> more) will break backwards compatibility. (no?)

Yes - that would be a different service, which is also why it should sit
on a different port.

>>> and more specifically with the first sentence. Supposing that (a
>>> hypothetical) HTTP/1.3 would support an optional banner, such an option
>>> would allow the server side to send it without braking backwards
>>> compatibility:
>>> Client --> SYN+DATA --> Server
>>> Client <-- SYNACK+? <-- Server
>>> Client -->   ACK    --> Server
>>> Client <--  BANNER  <-- Server
>> The server can start sending data before the TWHS completes (let's call
>> the above "sequence 1" and the below "sequence 2"):
>> Client --> SYN+DATA --> Server
>> Client <-- SYNACK+? <-- Server
>> Client <--  BANNER  <-- Server
>> Client -->   ACK    --> Server
>> In sequence 1, the banner can depend on the SYN+DATA data. In BOTH
>> sequences, however, the SYNACK+? "?" **cannot** depend on the SYN+DATA
>> data.
> I believe that I didn't describe well what I meant (or else I don't completely 
> understand what you're saying).
> I'm talking about (lets say) 8 bits of out-of-band information that the client 
> can send to the server side and vice-versa. The server side application will 
> most probably get those data after the TWHS completes. There is no placed 
> requirement to do otherwise.

If the data is "out of band", then the application needs to understand
what it means. TCP ports currently specify services with no out-of-band
information. If you want a service that understands that kind of
additional information, those would be a different service.

> So, a complete trace (with most function arguments ommited or altered for 
> simplicity, no error handling, etc etc :-) of a non-well thought proposal 
> (there are issues) would be:

Understood; you're setting up a second data channel, and ACKing it

First, that can't be used to help reduce the RTT as Adam has suggested
without changing the "app doesn't get data until the handshake
completes" semantics.

Second, that information can't be used by the app unless you change the
*service* semantics, which means these are different services.

TCP options are for changing TCP behavior, not changing application
semantics, IMO.

> p.s. Do you know if there is a way to force the tcpm mailing list to send me 
> duplicates for mails that are CC'd to me too? It seems that all mails that 
> I'm CC'd are only sent directly and not via the list. I've set the "Avoid 
> duplicate copies of messages?" to "No" in the mailman options but there was 
> no change.

You should take this up with the list manager; I'm not sure of how TCPM
is setup.

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list