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

[Michael Tüxen <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm