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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id BF5D03A6A39; Sat, 20 Sep 2008 23:38:05 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 054DB3A6A40 for <>; Sat, 20 Sep 2008 23:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.466
X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_05=-1.11]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HMQP-M2qKDei for <>; Sat, 20 Sep 2008 23:38:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 121D03A698E for <>; Sat, 20 Sep 2008 23:38:04 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m8L6c8oA027204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Sep 2008 23:38:10 -0700 (PDT)
Message-ID: <>
Date: Sat, 20 Sep 2008 23:38:07 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: Adam Langley <>,, Stefanos Harhalakis <>
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


Here's a more brief, self-contained reply:

Joe Touch wrote:
> Hi, Stefanos,
> Stefanos Harhalakis wrote:
>> Hello Adam,
>> I believe that this was not proposed before so here it goes:
>> 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.

As a result, I cannot see how this feature can be used to extend TCP.

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

tcpm mailing list