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

"Adam Langley" <> Wed, 06 August 2008 00:14 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 3A6BB3A6AA5; Tue, 5 Aug 2008 17:14:30 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 956403A6880 for <>; Tue, 5 Aug 2008 17:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.627
X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TRhNx+s6Cg30 for <>; Tue, 5 Aug 2008 17:14:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A70333A6AA5 for <>; Tue, 5 Aug 2008 17:14:28 -0700 (PDT)
Received: by with SMTP id b25so2409848rvf.49 for <>; Tue, 05 Aug 2008 17:15:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=1bFg9MxSuPP6+/E8jajXg5zdjJeze58fcPtHkDJ76YM=; b=ufoEEwj8B4sGWrZbT8r8ciI/Vs3+7AEtsxOOb1sLrVopWUDzpwVR8ZEpb/FdN+1pM5 RKuoqeCQWf2+O5BLhrlr1JFA/j0/JRgAAA3ZA6+QUqyiTwBFSY6xzLZacaAiiKCrC+tC afvD0jW232kZ/z4Ug0Rri35UspNrAnEKODan4=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=XUpGMujgvvi6/pBKKblMQvK3pnDKOzTw5tAuoMo/gCwJN23GPwePphZf1PF6jJadTf 52zRV/oUC3Ksq74eomwSihEFvNQMT6dPKHqxfkDrDb3SgFl+bBQMcVYXnRcjrFz1fl25 KcnKxByEfb/Or8MsiclQYH9+nrpVQbrxbfJ6M=
Received: by with SMTP id x1mr8532600rvc.217.1217981697371; Tue, 05 Aug 2008 17:14:57 -0700 (PDT)
Received: by with HTTP; Tue, 5 Aug 2008 17:14:57 -0700 (PDT)
Message-ID: <>
Date: Tue, 05 Aug 2008 17:14:57 -0700
From: Adam Langley <>
To: Joe Touch <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <> <> <> <> <> <> <> <> <>
X-Google-Sender-Auth: a6d9a2459050c8fd
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

On Tue, Aug 5, 2008 at 4:46 PM, Joe Touch <> wrote:

I've just posted a new version of the draft, incorporating your
comments, which I hope is a lot clearer. Thanks for everything so far.

> Using a transport signal to change the application protocol seems very
> strange to me. Others can comment on that. My view is that this is a
> case where perhaps you want something that is better encoded by using a
> different port number (thus a different application service, explicitly)
> than a TCP option that implies that application behavior.

It is strange, I agree. My usual test about such things is if I get an
"ick" reaction and, in this case, I don't. Although, that might just
be me.

Two reasonable questions arise:

"Where will this stop?"  - obviously, the TCP option space shouldn't
be a repository for application data. In this case, at least, the
option is advertising a certain minimum capability of the TCP stack,
as defined in the draft. Also, I'll claim that this is the last such
need in this area:

The SYNACK payload sizes is a decision for the server (within the
advertised window). No more client options could be needed to
advertise support for larger ones.

Since the SYNACK payload is (nearly) constant, and TCP stacks are not
going to differ sufficiently to change this in the next 20 years,
applications don't gain anything else by stuffing anything more in the
SYN option space.

So I don't think this sets an unreasonable precedent.

"Is it really needed?" - If you consider examples one and three from
the 01 draft that I just posted, I'm claiming that it would at least
be very useful. Of course, alternative ports solve the problem but I
believe that such a solution is messy enough as to be not a going
concern. Much of the time, SYNs to a closed port on a public server
will result in no reply at all, meaning that timeouts have to trigger
the back off.

The above is the sort of stuff that I should have put in the revised
draft :) I probably shall include it in -02.



Adam Langley
tcpm mailing list