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

Joe Touch <touch@ISI.EDU> Tue, 15 July 2008 20:52 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id AC3DD3A696C; Tue, 15 Jul 2008 13:52:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99EFA3A696C for <>; Tue, 15 Jul 2008 13:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dVonQJ2tysk5 for <>; Tue, 15 Jul 2008 13:52:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6F7303A6863 for <>; Tue, 15 Jul 2008 13:52:25 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m6FKqVS3028147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Jul 2008 13:52:32 -0700 (PDT)
Message-ID: <>
Date: Tue, 15 Jul 2008 13:52:29 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Adam Langley <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:, Lloyd Wood <>
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Hash: SHA1

Hi, Adam (et al.),

I looked this over, and had a clarification:

Data could *always* come in the SYN/ACK (i.e., in a SYN), but often it's
just ignored. So this option is just a hint to the server that the
client won't ignore that data. It doesn't change any rules about data
delivery; once the SYN/ACK arrives, the client can send that data up to
the user as per conventional rules, AFAICT.

Adam Langley wrote:
| On Tue, Jul 15, 2008 at 11:22 AM, Lloyd Wood <> wrote:
|> This looks awfully like reinventing transactional TCP to me - and
IIRC the
|> reason that never got widely adopted was the increased potential for DOS
|> attacks by tying up memory early on with a loaded SYN.

Transaction TCP allows a server to push data to the user that arrives in
the SYN without waiting for the client's final ACK; that doesn't appear
to be related to this.

I think the only catch is that this works only when there's a
unidirectional-initiated connection from client to server, and only
helps hint the server that the client will accept data in the SYN/ACK.
It doesn't help with simultaneous opens, e.g., since neither side can
send the data up until their SYN is ACK'd -- *that* is what T/TCP
changes, but this doesn't, again AFAICT.

I'm really not sure what buying a single RTT will do for TCP, though.
Very few exchanges that need reliable transfer of a single packet need

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

tcpm mailing list