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

[Joe Touch <[e-mail]>]

-----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.

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