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

["Adam Langley" <[e-mail]>]

On Sun, Aug 3, 2008 at 2:13 PM, Joe Touch <[e-mail]> wrote:
> | However, without SYNACK payloads, this banner would cost another round
> | trip.
>
> I have noted this before; an extra RTT doesn't do much of anything.
> There are more delays in HTTP over TCP that incur round trips, e.g.,
> dealing with interactions with sending an ACK every other segment, as
> well as apps that fail to disable Nagle optimizations (as  they should
> when they're interactive and have messages longer than a single byte).

A extra round trip is very important. See the two quotes that I
highlighted above for some evidence. At Google we work to shave off
every millisecond and anything which required a whole extra round trip
would, rightly, be dismissed immediately. I wouldn't even bother
proposing such a scheme.

> | With SYNACK payloads, we can add this very useful banner without add a
> | round trip. However, servers can't just start including the banner
> | whenever the server's kernel supports the SYNACK payload setsockopt
> | because it would break all the existing clients who wouldn't know what
> | to make of it.
>
> This is where you've lost me. Server TCPs can send data in the SYNACK.
> Clients that ACK just the SYN cause the server to retransmit; clients
> that ACK the whole segment work as you intend.
>
> What part if this isn't sufficient?

Taking HTTP as an example, the very first bytes from the server must
be the reply to the first request from the client. If servers started
sending something else before hand, no matter what packet it's carried
in, all existing HTTP clients would break.

I'm suggesting that, if the ability to get a short banner from the
server to the client in the SYNACK had been generally available when
HTTP was created, the authors would have used it and the
application-level protocol would have been different. The fact that it
otherwise requires an extra round trip was strong reason for the
client to start the exchange.

However, since it wasn't availible, in order for some protocols (inc
HTTP) to take advantage of such a capability we need an option to
signal to both ends that they can use a slightly different application
level protocol. At the server side, to add the extra banner, and at
the client side to expect it.

> | This would be a major change to the sockets API.
>
> I agree, but isn't that where this is going? If not, how do you expect
> it to be used?

I expect it to be a setsockopt at both the client and server ends.

> This code is confusing; is it a library that happens to be in the
> kernel, or is it intended to be code inside TCP?
>
> If this is intended inside TCP, you're having TCP insert data into the
> user stream. That changes TCP semantics.
>
> Can you explain which of the above applies, or some other interpretation
> that explains the code without such inconsistencies?

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.

There are stacks which could do that[1]. However, for most stacks that
would be painfully incongruent and the additional load would make SYN
floods a real problem.

So, as an implementation detail, we might have that function in the
kernel. Since few kernels are happy with userspace machine code
running in kernelspace, I expect that most implementations will choose
to allow the application to configure a fixed function. The code was
pseudocode for what that fixed function might look like. Applications
would be able to configure the inputs: payload, payload_length,
include_random_nonce and only_send_if_requested in that example.

It might be the case that all such details, being implementation
specific, shouldn't be included in the spec. I didn't want to spec to
be too abstract, however.


[1] http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack

> | In correctness terms, you are correct. It doesn't matter when the
> | banner gets sent, or if it gets split over several packets. However,
> | applications would very much like to know how many bytes the kernel
> | will agree to transmit in reply to a SYN frame because, if a banner
> | would cost an extra round trip they might prefer not to include it.
>
> ***WHY???***
>
> I know I'm repeating myself here, but ***TCP IS NOT A REALTIME
> PROTOCOL***, and there is *no correlation between user writes and
> segment boundaries*.

"realtime" to me means that there are known latency bounds. My this
definition, TCP isn't a realtime protocol. However, average latency
still matters very much.

> Did you actually try reducing the overal latency of a single TCP
> connection by 1 RTT and see if it actually matters? If these apps are
> using persistent connections, then the first RTT exchange is all they'll
> see anyway.

Yes. These are internal numbers, sadly, but a RTT really does matter.
For well connected users, an RTT might be only 20ms to multi-homed
service. That, I'll agree, is fairly inconsequential. But San
Francisco <-> London is about 150ms and if you're in less well
connected continents (like Africa), RTTs are hundreds of milliseconds
to anywhere. An RTT really matters.


AGL

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