Re: [tcpm] Faster application handshakes with SYN/ACK payloads

Joe Touch <touch@ISI.EDU> Sun, 21 September 2008 06:17 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id BC4573A6933; Sat, 20 Sep 2008 23:17:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16EE13A6933 for <>; Sat, 20 Sep 2008 23:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.417
X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-1.806, BAYES_00=-2.599, FRT_STOCK2=3.988]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EnF1PN2QPN36 for <>; Sat, 20 Sep 2008 23:17:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 15FB63A677D for <>; Sat, 20 Sep 2008 23:17:43 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m8L6Hi1m020885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Sep 2008 23:17:46 -0700 (PDT)
Message-ID: <>
Date: Sat, 20 Sep 2008 23:17:44 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Stefanos Harhalakis <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: Adam Langley <>,
Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads
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

Hash: SHA1

Hi, Stefanos,

Stefanos Harhalakis wrote:
> Hello Adam,
> I've just looked again at this. Its 1.5 month late but time runs fast.
>> However, it appears that I've not made the case for the option yet. To
>> do this, let me take HTTP as an example.
>> HTTP is very latency sensitive[1]. Because of this, and guided by the
>> sockets API, the client starts the exchange. Thus, if the client
>> wishes to probe for optional features (like TLS upgrade: RFC2817) the
>> exchange works like this:
>>   Client --- OPTIONS ---> Server
>>   Client <--- 101 Switching --- Server
>>   Client --- GET ---> Server
> AFAIKT, you're proposing that whenever the server side detects the SA option 
> it switches to a different protocol behavior. Why not extend this even more 
> and provide a generalized framework for more advanced customization?
> I believe that this was not proposed before so here it goes:
> Add a generic 'user data' option for SYN fields that would carry user data. 
> Something like this:
> Most of the time it should be: 
> KIND | 3 | "1 Byte of data"

I've been calling a a user data option for that reason, but I feel that
it changes TCP semantics. You're using a SYN option to change the
behavior of a service on a port. This requires substantial changes to
the interface as outlined in RFC793 (and implemented in sockets). In
particular, you need the server to be able to read the SYN options from
a socket before writing the response to a SYN-ACK.

This is outlined in previous emails to the list; it might be useful to
review them.

> This is easy to implement (at the client side) and will allow for premature 
> negotiation. 

As per above and in previous emails, it seems impossible to implement in
existing stacks without substantial modification of the socket interface.

> For example this could include the client side application layer 
> protocol capabilities. It can also be symmetric so that server side also 
> sents some out-of-band data but most probably this should not be required 
> with SA data (but an echo/acknowledge is required).
> The implementation at the client will just require a setsockopt() that would 
> set the extra header data and perhaps a getsockopt() that would get the reply 
> (if any). This part needs some working.

The issue is that the data is carried in the DATA of the SYN, not in the
option (in the SYN-ACK reply once negotiated). A different issue is that
TCP cannot ensure that data, once written, is solely in the SYN - it
could be retransmitted in subsequent data packets anyway, so it should
not be assumed to be inside the SYN.

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

tcpm mailing list