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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 860053A6872; Thu, 14 Aug 2008 13:14:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF24F3A6872 for <>; Thu, 14 Aug 2008 13:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yefxHCdhNYoQ for <>; Thu, 14 Aug 2008 13:14:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6BC7C3A6407 for <>; Thu, 14 Aug 2008 13:14:20 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m7EKDQiY012167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 13:13:28 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Aug 2008 13:12:41 -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 10:30 AM, Joe Touch <> wrote:
|> OK. So why bother with an option at that point? Why does the user data
|> need to be different if the option is present?
|> If the user data were not different, then this all boils down to a
|> change in the implementation of the API. The trouble is that you're
|> expecting a TCP option to change the *content* of the data stream, and
|> that seems bizarre to me.
| Because for server-speaks-first application protocols there's no
| problem. This is just for client-speaks-first protocols. For these
| protocols, had common stacks been able to send data in the SYN/ACK
| when they were being designed, then they might have ended up as
| server-speaks-first protocols. But they didn't for latency reasons.

Client-speaks-first puts data in the SYN, not the SYN-ACK. Or have you
got the roles reversed, as with FTP data connections?

| In order for them to take advantage of this they need to be able to
| signal their compliance somehow. There is, indeed, a cleanliness
| argument against such a option, but I'm arguing that it's worthwhile
| for backward compatibility reasons.
|> This is a big change - you're saying that if the payload fits, it goes
|> in the SYN-ACK. If not, *none* of it is sent in the SYN-ACK? Why?
| I'm saying that implementations have latitude here. If the passive
| open end wishes to ignore the client's option it may. Equally, it may
| echo it, but not include the data in the SYNACK if the MTU makes it
| troublesome. In that case, it needs to send it in the next packet as
| normal.

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.

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

tcpm mailing list