Re: [tcpm] SYN/ACK Payloads, draft 01

"Adam Langley" <> Thu, 14 August 2008 16:40 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 6A3423A6DB7; Thu, 14 Aug 2008 09:40:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 581883A6D53 for <>; Thu, 14 Aug 2008 09:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.435
X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[AWL=-1.576, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PQJrTcCSFxbx for <>; Thu, 14 Aug 2008 09:40:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1452D3A6D17 for <>; Thu, 14 Aug 2008 09:40:42 -0700 (PDT)
Received: by with SMTP id b25so439071rvf.49 for <>; Thu, 14 Aug 2008 09:40:46 -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=dAIYDTmstaw4vOKQj+YMugsZb7iJUSzl5dlyXVQTy9w=; b=b5QqDEEQdu7vIw/OxxMsYTT0YHikrmuSrxLOWbBqeznlqw/JPYV7tzr6tWbwCP2c6/ vaXVxUZo2PIw/G44xU6EjfesoBmIHaR7BxoVB25Vb39ynE4FS/L1sgr97y9X86OmkytD MpwzJQbFEW486REoKyx6VV7ICAd/vA0v6jXWs=
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=Q5HrL+KvYm9asC1+YfMqm+hvP6kJCjN12OxBIySlxO2L0SCqS6j4zvXKx4oZmXsdOQ Xmn7Np837qQIrkHxGMwmgYzUZj7xK3jhecx2q/EjENt1uSmLz2r/2SQs2Xo42eJUt8Ha bju6v8eDeN9KU40X29SMdp0r0v0GcId3mt7ss=
Received: by with SMTP id u15mr824701rvn.171.1218732046273; Thu, 14 Aug 2008 09:40:46 -0700 (PDT)
Received: by with HTTP; Thu, 14 Aug 2008 09:40:46 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Aug 2008 09:40:46 -0700
From: Adam Langley <>
To: Joe Touch <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <> <> <> <> <> <> <> <> <>
X-Google-Sender-Auth: 00862bc176bbbe3b
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01
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 Wed, Aug 13, 2008 at 10:20 PM, Joe Touch <> wrote:
> I'm confused now; your code - and your note. Let's go back to the key issue:
>        - is the data received by the client dependent on the option?

I do apologise, the confusion is my fault:

There are two extensions interacting here. Firstly, there's an
extension to include data in the SYNACK. Then there's the application
layer signaling with the option. I was outlining the code for the
latter. The former is an extension that could be deployed today, it's
managed with a setsockopt on the server socket:

struct tcpsa tcpsa;
memcpy(tcpsa.tcpsa_payload, mysynackdata, length);
setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa));


for (;;) { accept(); ... }

Obviously, this is just an implementation detail. It's nice for
sockets based APIs to do it like this. Since such stacks are dominant,
the idea of a constant payload appears in the draft. I make a couple
of exceptions to this. The ability to include a 64-bit nonce is very
useful and easy for the stack to manage. That's done with:

struct tcpsa tcpsa;
memcpy(tcpsa.tcpsa_payload, mysynackdata, length);
tcpsa.tcpsa_flags = TCP_SADATA_INC_NONCE;
tcpsa.tcpsa_nonce_offset = 0;
setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa));

Also, the ability to only send this data when the SYN includes the
SAPP option. At the moment, this is the default, although there is
space in the flags set aside for when I get round to it.

Example client side code and stack patches are referenced below.

Again, this is just to appease the sockets API. Stacks like [1] allow
the application to process the SYN directly and construct any SYNACK
payload they like on a per-packet basis.


> As a final question, if this is experimental, why not just use the
> experimental TCP option KIND?
> (and how much of this has been implemented, traced, and checked for
> things like simultaneous open - I don't recall if you noted that before)

A linux patch[2] has been reviewed by the networking maintainer,
although I haven't asked for it to be applied yet because it's not
quite final. (It's using an experimental KIND number for one). Example
client side code example can be found at [3]. This includes preload
code to support Apache, Firefox etc (screenshot: [4]). It's been
tested by several people over the real Internet. (Note that [3] is
just a dump of my current code, it has many rough edges at the moment.
And ignore the TCP-AO stuff therein, it's #ifdef'ed out).

Also, I believe that I currently have the Diffie-Hellman speed record
with [5] since my implementation is 10% faster than the previously
claimed best[6]. (The version in [3] is much slower, I've yet to
update it.)

I'm am currently using an experimental KIND. However, if I were to,
say, deploy this on all the Google frontend servers (hypothetically,
of course), I suspect that would be in excess of what the experimental
kinds were for.

As for simultaneous open. The linux patch handles it by not doing
anything different. The option may be carried in the SYN, but the ACKs
are as normal. Since all BSD like stacks would, very likely, work the
same, it might be best to specify that behaviour in the draft.




Adam Langley
tcpm mailing list