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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id AD0533A67EF; Thu, 14 Aug 2008 14:27:18 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF5A03A67EF for <>; Thu, 14 Aug 2008 14:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JVJAqmRgdqwe for <>; Thu, 14 Aug 2008 14:27:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C06493A67E7 for <>; Thu, 14 Aug 2008 14:27:16 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m7ELQalR006788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Aug 2008 14:26:40 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Aug 2008 14:25:50 -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 1:36 PM, Joe Touch <> wrote:
|> Isn't it a *lot* simpler to avoid an option and just send the data
| Yep! And I intend to patch Linux to support exactly this (no options
| involved anywhere) at some point. To reuse an example, I could have an
| SMTP server which writes "200 ESMTP\r\n" this way and save
| a round trip. (Although SMTP isn't too latency sensitive some busy
| servers might be glad of it.)
| But many application level protocols have been designed as
| client-speaks-first, like HTTP.

OK, so the crux of the matter is that:

	- most app protocols are client-speaks first
	- you want server-speaks-first

There's nothing about TCP that prevents that, but I agree that the
current socket interface isn't quite sufficient.

| So, let's define HTTP-ssf (server
| speaks first). HTTP-ssf is exactly the same as HTTP, except that the
| client waits for a banner from the HTTP server before sending a banner
| of it's own. We can use the same trick as the SMTP server to maybe fit
| this banner in the SYNACK. If it doesn't fit, no loss, it can go in
| later packets. If the client doesn't ACK all the data from the SYNACK,
| no loss, again it goes in the next packets.

Yup. That works.

| Now, I can run an HTTP-ssf server, but no web browser on the planet
| can talk to me! And the browsers that I modify to speak HTTP-ssf can't
| take to any non-ssf HTTP servers. It's a very lonely website.

YES. You have a problem because you're redefining HTTP, not because of
anything in TCP. FWIW, there's an HTTPbis WG in which this issue would
be relevant.

| I could define a whole new URL scheme (httpssf://...) and a new port.
| But then there's no gradual deployment path because users with old
| browsers don't understand httpssf:// and it confuses the users anyway.
| Most type http:// by habit.

So let's consider secure HTTP. That could have been done with a TCP
option, but instead it was done in exactly the way you don't think works
- - a new port, and a new URI prefix (https:). Initially, users needed to
know what to type; eventually, that ended up being embedded in URLs on
web pages people click anyway (e.g., search engine results).

OK, so why doesn't that path suffice? It worked once, why won't it work

- ----

What you're *really* asking for is a way to send data from client to
server BEFORE the TWHS completes. You talk about server-talks-first, but
it's really the client speaking - by sending the option. If this were a
flag in the HTTP request, and if the data were available to the server
app when the SYN arrives, you'd be done. You're using the option as a
trick to get around the fact that TCP doesn't want to send user data up
to the app until the end of the TWHS.

I don't think that sort of channel is something TCP needs. IMO, this is
precisely what T/TCP was designed for; T/TCP may need fixing, but that's
a different issue. I'm not familiar enough with SCTP to know if that's
an alternate path.

I don't support the idea that doing this in TCP is appropriate just to
get around deployment issues.

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

tcpm mailing list