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

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Thu, 14 August 2008 22:04 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6F13A6857; Thu, 14 Aug 2008 15:04:39 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588183A6918 for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 15:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.038
X-Spam-Level: **
X-Spam-Status: No, score=2.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHH7DrwxcfO3 for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 15:04:37 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 4F50F3A6857 for <tcpm@ietf.org>; Thu, 14 Aug 2008 15:04:35 -0700 (PDT)
Received: from [192.168.1.15] (p508FE40C.dip.t-dialin.net [80.143.228.12]) by mail-n.franken.de (Postfix) with ESMTP id 3DE5B1C0C0BC0; Fri, 15 Aug 2008 00:04:36 +0200 (CEST)
Message-Id: <6FEDDE45-C396-4A97-A510-0FD236229197@lurchi.franken.de>
From: =?ISO-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <48A4A2DE.3090400@isi.edu>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Fri, 15 Aug 2008 00:04:35 +0200
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A3C0B3.8050003@isi.edu> <396556a20808140940p63dec2d2ib3332b27da8260ae@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> <48A4975D.3070303@isi.edu> <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> <48A4A2DE.3090400@isi.edu>
X-Mailer: Apple Mail (2.926)
Cc: Adam Langley <agl@imperialviolet.org>, tcpm@ietf.org
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Aug 14, 2008, at 11:25 PM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Adam Langley wrote:
> | On Thu, Aug 14, 2008 at 1:36 PM, Joe Touch <touch@isi.edu> wrote:
> |> Isn't it a *lot* simpler to avoid an option and just send the data
> anyway?
> |
> | 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 example.com 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
> again?
>
> - ----
>
> 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.
SCTP has a four way handshake:
---- INIT ---->
<-- INIT-ACK --
--- COOKIE --->
<- COOKIE-ACK -

You can send user data with the third and fourth message, not
with the first or second.

The socket API supports sending user data on the third message...
>
>
> I don't support the idea that doing this in TCP is appropriate just to
> get around deployment issues.
>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkikot4ACgkQE5f5cImnZrvyWACgtAlcCP3R5UijYW+IpRc2x3VX
> Rw0AoPiUJhbWhD2cWKliTRFrhtINfYai
> =pX3/
> -----END PGP SIGNATURE-----
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm