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

Stefanos Harhalakis <> Sat, 20 September 2008 23:05 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id ECFBE3A68FD; Sat, 20 Sep 2008 16:05:05 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19CE83A6814 for <>; Sat, 20 Sep 2008 16:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.389
X-Spam-Level: *
X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f5gRtAltiPMS for <>; Sat, 20 Sep 2008 16:05:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EC16F3A68FD for <>; Sat, 20 Sep 2008 16:05:03 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id m8KN5nOr014893; Sun, 21 Sep 2008 02:05:49 +0300
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id m8KN5Ijq005834; Sun, 21 Sep 2008 02:05:18 +0300
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id m8KN58OM027407; Sun, 21 Sep 2008 02:05:10 +0300
Authentication-Results:; spf=neutral
Authentication-Results:; sender-id=neutral
From: Stefanos Harhalakis <>
Date: Sun, 21 Sep 2008 02:05:08 +0300
User-Agent: KMail/1.9.9
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <>
Cc: Adam Langley <>, Joe Touch <>
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

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"

This is easy to implement (at the client side) and will allow for premature 
negotiation. 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.

> If HTTP sent a banner, like SMTP servers, then my life would be a lot
> easier! The banner could advertise all the extensions supported.
> However, without SYNACK payloads, this banner would cost another round
> trip.

Such a solution would allow the HTTP protocol to switch to HTTP-with-banner as 
you wished, without braking compatibility. Of course there can be many other 
uses for it. It is also 100% TCP friendly since a receiver that doesn't 
support such an option will just ignore it.
tcpm mailing list