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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 3DE013A6840; Thu, 14 Aug 2008 13:37:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58C463A6840 for <>; Thu, 14 Aug 2008 13:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.801
X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.798, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sKbgErfDQEDR for <>; Thu, 14 Aug 2008 13:37:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5FEC63A67B7 for <>; Thu, 14 Aug 2008 13:37:43 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m7EKbUwD020250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 13:37:32 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Aug 2008 13:36:45 -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 Thu, Aug 14, 2008 at 1:12 PM, Joe Touch <> wrote:
|> Client-speaks-first puts data in the SYN, not the SYN-ACK. Or have you
|> got the roles reversed, as with FTP data connections?
| Sorry, I was speaking of the application layer protocol. Commonly,
| client-speaks-first application protocols are putting data in the
| final ACK of the 3-way handshake.
|> If the option is ignored, and you don't intend to change TCP semantics,
|> then the data - i.e., the hash or whatever - needs to be sent in the
|> next data packet.
| Ok, I'm fine with that. But there will always be servers which ignore
| the option because they don't understand it. In that case, obviously,
| they can't send it in the next packet.

Please walk through this again. AFAIK, "client" refers to the initiator
of the first connection. Let's use that convention here:

client sets socket option before connect
		server sets socket option after listen, before accept?
		(again, this is a problem; the socket of the connection
		exists only after the accept returns; before that, the
		'socket' applies to *any* connection that would return
		a subsequent listen call)

1.	SYN->
2.		<- SYN/ACK
3.	ACK->
4.	data->
5.		<- data

The option you're talking is useful, AFAICT, only in #2 (the SYN/ACK).

I'm proposing that the data that the server sends in the socket option
be considered equivalent to a WRITE on the socket - which would
otherwise have been possible only after the ACCEPT call. I.e.:

	- if the SYN (#1) has the option, then the socket option
	data commences in the SYN/ACK (#2) [it could spill over into
	later data segments #5 (or even between steps 3 and 4)]

	- if the SYN (#1) lacks the option, then the socket option
	data commences in the data segments #5 (or between steps
	3 and 4)

At that point, there is no real need for an option. The server can
ALWAYS send the data in the SYN/ACK, and just resend it if the ACK (#3)
is just for the SYN (in the SYN/ACK #2).

Isn't it a *lot* simpler to avoid an option and just send the data anyway?

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

tcpm mailing list