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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Adam,

Adam Langley wrote:
| On Mon, Aug 4, 2008 at 11:20 AM, Joe Touch <touch@isi.edu> 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??

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiY5mQACgkQE5f5cImnZrunEQCeJsum/G9ClwtD8cfX3zwrVZ8n
EmAAoMlGT6BdWE3JfwTjTEcXVVjlJ9Qr
=ctQh
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm