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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id EB75A3A6974; Thu, 14 Aug 2008 10:32:37 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD40F3A6957 for <>; Thu, 14 Aug 2008 10:32:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.724
X-Spam-Status: No, score=0.724 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, FRT_STOCK2=3.988]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KyjH0Fc74G2t for <>; Thu, 14 Aug 2008 10:32:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C33903A692D for <>; Thu, 14 Aug 2008 10:32:35 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m7EHVnH1021671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 10:31:52 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Aug 2008 10:30:59 -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:05 AM, Joe Touch <> wrote:
|> 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
| There are several cases:
| If the setsockopt has requested that the data be included in the
| stream without exception, then it is enqueued like any other data. If
| there's space in the SYN/ACK, it can go in there. If not, it will be
| sent as usual. If the client doesn't ACK a SYNACK payload, it will be
| retransmitted etc. This requires no standards effort, it's a TODO for
| me at the moment.

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.

| If the setsockopt flags request that the data only be sent in reply to
| SYNs with the SAPP option:
| If the payload fits in the SYNACK (given MSS etc) then it is
| transmitted and the option is echoed back. Otherwise, a bare SYNACK
| (without the option) is sent back. In the latter case, the data is not
| enqueued to be sent in the future. The applications on both sides are
| aware of what happened and proceed correctly given the situation.

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?

TCP provides a *byte stream*. The description above implies that the
application knows/sees segment boundaries, which isn't TCP anymore.

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

tcpm mailing list