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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 99E033A6B35; Sun, 21 Sep 2008 09:30:51 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25B893A6B16 for <>; Sun, 21 Sep 2008 09:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.874
X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BCYk5DLIe57C for <>; Sun, 21 Sep 2008 09:30:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A06E93A69E1 for <>; Sun, 21 Sep 2008 09:30:48 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m8LGUeTw028986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 21 Sep 2008 09:30:42 -0700 (PDT)
Message-ID: <>
Date: Sun, 21 Sep 2008 09:30:39 -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

Stefanos Harhalakis wrote:
> On Sunday 21 September 2008, Joe Touch wrote:
>>> Stefanos Harhalakis wrote:
>>>> Add a generic 'user data' option for SYN fields that would carry user
>>>> data.
>> There are two reasons for doing this:
>> 	1- to send an out-of-band signal
>> 	2- to send a signal that the server acts on before the
>> 	handshake completes
>> #2 violates TCP semantics, so the SYN-ACK cannot have application data
>> that depends on the SYN's user data option (which is the desired result
>> here). The signal can't be acted on at the application layer until the
>> handshake completes.
>> #1 changes TCP semantics as well, since TCP does not have an out-of-band
>> signal path, and this would add that. However, because it cannot be
>> acted on until after the handshake completes, it cannot modify
>> application behavior that isn't required to wait until the handshake
>> finishes - i.e., apps that can write to the socket before the handshake
>> completes (e.g., to write data available to a SYN-ACK) would never
>> change because of this signal. The utility of this feature depends on
>> application behavior, which cannot be known, and thus cannot be relied
>> upon.
> What I proposed is what you describe in #1. It is different from the 
> SA-with-data proposal and thus it hasn't to do anything with #2. As I said in 
> the original mail, it has to do with what Adam said:
> "If HTTP sent a banner, like SMTP servers, then my life would be a lot
> easier! The banner could advertise all the extensions supported.
> However, without SYNACK payloads, this banner would cost another round
> trip."

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".

> 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.

> Without changing current behavior (It is not required that data be sent with 
> the SYNACK option).
> Also, this is not exactly "data" as there is space for a very small amount of 
> information (some bits). Considering the possibilities of this, it can be 
> used in many situations such as:
> * HTTP or other protocols that use a well-known-port, to negotiate different
>   behavior without introducing a new port number (SSL over port 80?).
> * Cryptographic applications
> * Anything that someone out there can think of. 8 bits (or a little more) of 
>   information can be used for many things.
> Wrong?
> p.s: I can write a draft if this would clarify things.

I think you're exploring the space of the discussion that has already
been had on this list...

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

tcpm mailing list