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

Joe Touch <touch@ISI.EDU> Tue, 05 August 2008 23:47 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 066953A6B98; Tue, 5 Aug 2008 16:47:29 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 914953A6B93 for <>; Tue, 5 Aug 2008 16:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.17
X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=1.429, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TSrSYmpaianw for <>; Tue, 5 Aug 2008 16:47:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 79BD93A6A56 for <>; Tue, 5 Aug 2008 16:47:26 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m75NlOXp001608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Aug 2008 16:47:28 -0700 (PDT)
Message-ID: <>
Date: Tue, 05 Aug 2008 16:46:44 -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] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Hash: SHA1

Hi, Adam,

Adam Langley wrote:
| On Mon, Aug 4, 2008 at 11:20 AM, Joe Touch <> wrote:
|> | Imaging that we change the sockets interface such that applications
|> | get a callback when a SYN frame is received on a listening socket.
|> | Applications could inspect the SYN frame and choose to enqueue data to
|> | be written. Hopefully the kernel would send some of that data in the
|> | SYNACK, but that's unimportant here.
|> Why wouldn't the application just enqueue the data? Why does it need to
|> know that the other end supports this?
| It doesn't always. SMTP, IRC and SSH protocols, for example, all
| include a banner from the server to the client. In this case, the data
| can be unconditionally enqueued for transmission. It's for protocols
| which don't already start with a server->client transmission, and for
| which we wish to add one, that the client must signal that we're
| changing the application level protocol for this connection.

Using a transport signal to change the application protocol seems very
strange to me. Others can comment on that. My view is that this is a
case where perhaps you want something that is better encoded by using a
different port number (thus a different application service, explicitly)
than a TCP option that implies that application behavior.

|> 150ms is large when considered in the context of a small number of RTTs,
|> but in the context of a connection that lasts 10 RTTs, it's 10%; the
|> impact drops as you keep the connection going.
|> I.e., a reduction of a single RTT is important only when the total
|> exchange lasts 2-3 RTTs. That's 8KB-16KB of data - and it matters only
|> for the first chunk of data in a persistent connection. For web pages
|> with dozens of embedded components (in specific, more than 4, which is
|> the typical limit for simultaneous connections), again this seems very
|> much in the noise...
| Many Google users are now using search bars to submit queries. Thus
| they type into a text field in the browser, hit enter and the browser
| makes a connection, sends the query encoded in a GET and displays the
| result. This is one example of a situation where the connection
| latency isn't amortised. There are many others, but obviously, this is
| the example that usually dominates my thinking. And, in this
| situation, it turns out that every 10ms makes a difference.

Understood and appreciated. Can you see if the port solution might work??

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

tcpm mailing list