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

"Adam Langley" <> Thu, 14 August 2008 17:23 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 466F13A6B77; Thu, 14 Aug 2008 10:23:33 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17DBF3A6B77 for <>; Thu, 14 Aug 2008 10:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.017
X-Spam-Status: No, score=0.017 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C+qQ06a5rs6E for <>; Thu, 14 Aug 2008 10:23:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8DE743A696B for <>; Thu, 14 Aug 2008 10:23:27 -0700 (PDT)
Received: by with SMTP id x19so444358pyg.24 for <>; Thu, 14 Aug 2008 10:23:31 -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=OsX2h2sz+6oxYEZsYvYINirzhG81i+V/CSDlmeJTuD8=; b=jZoBS10NOGSN87B6AAPtXcyJ4k7xLHiOBvCrYZGVjCrS8jf80/ijYeuE5D48euZIJf dc/a6Xu+6QvpdES2RGNjMkGPQrrGE0LRsxpBQQwAHRjC1Ri+DfC4OVdbi8mHq3DzM4vU /hez/bNYk9IMYdCsrPVxtqQO4JuMzUNwyrRB8=
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=Bcr1pbu0xXNmgSsQ5Hsop9zzOWwVEXM7NJIuNJ/jTp8F9OBvnXFPe6gW3a49To9Qvv V55Ro1t2FS0dNsM+VOnKcB8ezuhhAG4dJiBPJAzEBEoekOU4B2Nz2kH3oX69RXVal7XN Dt2tZNBL1cXnHDjXQWkMA9RRF5gB8K8Qb11Ts=
Received: by with SMTP id g5mr858922rvp.30.1218734611397; Thu, 14 Aug 2008 10:23:31 -0700 (PDT)
Received: by with HTTP; Thu, 14 Aug 2008 10:23:31 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Aug 2008 10:23:31 -0700
From: Adam Langley <>
To: Joe Touch <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <> <> <> <> <> <> <> <> <>
X-Google-Sender-Auth: 9b9a3485ebe71395
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 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.

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.

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

It's not a separate channel, it's just that the option is an
application level signal. Caitlin probably puts it's better than I do:

"While this is an application layer problem that any application
could have solved on its own, there is some merit in providing
this as a generic transport capability precisely because it enables
support of existing clients and servers."



Adam Langley
tcpm mailing list