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

Joe Touch <touch@ISI.EDU> Thu, 14 August 2008 17:06 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id B7E9E3A6C89; Thu, 14 Aug 2008 10:06:34 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE4273A6C60 for <>; Thu, 14 Aug 2008 10:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.392
X-Spam-Status: No, score=0.392 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_00=-2.599, FRT_STOCK2=3.988]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f2Y5b2-MAzyZ for <>; Thu, 14 Aug 2008 10:06:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 190DB3A6B7F for <>; Thu, 14 Aug 2008 10:06:32 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m7EH60kh006995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 10:06:02 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Aug 2008 10:05:16 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
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
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Hash: SHA1

Adam Langley wrote:
| 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
|>        - 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));
| listen(socket);
| for (;;) { accept(); ... }
| Obviously, this is just an implementation detail.

It's a lot more than that; it hints that the socket interface is
insufficient for using the available TCP capability for sending data
with either SYNs or SYN-ACKs. I'm wondering how/if this has been
explored before, and whether there would be a solution that maps to
TCP's model of a stream better.

The socket option above is incorrect, IMO. It implies that the user
should have control over data that ends up in the SYN-ACK directly; IMO,
TCP's stream model should allow only that data be written to the stream
early - which may require a socket option - BUT should *not* imply that
the data maps to the SYN-ACK directly.

E.g., what happens if the data is larger than the MSS? Or if the SYN-ACK
comes back with an ICMP 'too-big'? I.e., this should be called just

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

I do not understand the semantics of a TCP option that changes the TCP
stream. TCP is a stream-oriented protocol, and each connection provides
one stream. If you want a separate channel, you ought to be using a
different protocol, e.g., SCTP.

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

That's fine as an implementation decision, as Caitlin notes, but has no
business affecting the TCP protocol spec.

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

tcpm mailing list