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

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

On Fri, Aug 1, 2008 at 11:17 AM, Joe Touch <[e-mail]> wrote:
> It's not an experiment; it's valid TCP behavior.

Whenever I'm speaking about an experiment, I mean this draft - it
being "experimental"

> Although there is more detailed feedback below, it might be useful to
> raise this up a level.

Thanks for your detailed response, I fear that there's a
misunderstanding somewhere and that's almost certainly the fault of my
inadequate writeups. Please let me try again:

At the moment, almost no stacks will send payloads in the SYNACK even
though they could as an optimisation. This springs from a few reasons:
  R1) Processing time for a SYN must be minimal to mitigate the
effects of SYN floods. Even waking up an application to process a SYN
would greatly increase the costs.
  R2) Replies to SYNs must be small, otherwise it provides a way to
amplify a DDoS attacks using false source IP addresses.
  R3) The ubiquitous sockets API doesn't make it easy to do so.

I'm proposing that a constant payload (optionally with 8 random bytes)
overcomes R1 and R3. And limiting the size of that payload to 64 bytes
overcomes R2.

There are protocols that could immediately benefit from a gradual
deployment of hosts which supported a setsockopt to set a constant
payload and hosts that would ACK and enqueue such a payload. (I
currently know of no stacks that do either however.) SMTP would be one
such protocol: clients wait for a 200 code banner from the server
before starting their part of the exchange and the banner is small and
constant. SMTP is also a protocol which ends up making many, short
connections.

Additionally, this would also be easy to deploy. For clients that
don't support it, they will ACK only the SYN flag and then the server
knows to include the payload again in the next frame.

However, the sockets API has guided the design of many application
level protocols. Because of this, these protocols are often designed
such that
  * The client starts the exchange: see HTTP
  * The exchange is large, since there's little space pressure: SSH
algorithm agreement uses strings like "diffie-hellman-group14-sha1"
(28 bytes) because of this.

Modifications to take advantage of SYNACK payloads would then require
changes to the application level protocol. This could be managed by
assigning new ports, trying connections on the new ports first,
backing off etc. However, given that this is a partly a latency
optimisation, that's an anathema.

So I additionally define an option that the application layer can set
and query that advertises support for this trick and allows many more
application level protocols to take advantage of it.

So, fundamentally, we end up with an opportunistic experiment that can
provide advantages, but may also have some costs if middleware gets
upset etc, as you note:

> (side note) Such an option might be useful, but might also be an issue.
> It tests the fact that TCPs ignore unknown options, a test that might
> fail. It also tests the fact that middleboxes should pass options
> unmodified, which also might fail.

Because of this, I wanted to make sure that clients were free to retry
a connection without the option in the case that something was
reacting badly to it. Many of the words in the draft are then
dedicated to making sure that both endpoints reach a consistent view
of when this option is in effect. Like the prohibition of not
including the option in a SYNACK if the previous SYNACK included it.
If that were to happen, the endpoint couldn't know which SYNACK the
peer saw and thus wouldn't know if the option was in effect or not.

For all of your comments that I have removed below, I hope that I've
addressed them in the above. If not, please highlight them again and I
will attempt to better do so.

Also, if the above was clearer then I should consider using it in the draft.

To address the remainder of your points:

> A 576 MTU is the smallest size that endpoints agree to reassemble; it is
> NOT the smallest MTU all links agree to support in the Internet. The
> smallest MTU is 68 bytes - i.e., IP with all possible options, TCP with
> none, and the smallest possible fragment (8 bytes) [see RFC791]. As a
> result, a 64-byte payload is too large to assume that it won't be
> fragmented (that may be true practically in many cases, but it isn't a
> requirement).

I don't believe that we should specify this. If a host finds itself in
a situation where the SYNACK payload is problematic in the face of the
MTU it may, validly, choose to fragment or to not echo the option. I
think the implementations have better information about which is the
best course of action.


> |>        - how do you handle simultaneous opens?
> If confirming the option is critical, you need to handle this case. As
> noted above, it might not be critical (or even necessary).

I believe that both sides will end up with a consistent view of
weather the option is in effect (neither will believe it to be so).

> | My hope was that by defining a flags option like this, future options
> | that require only to signal their presence in a SYN could save space.
> That might be a useful to document as a separate issue, since it's
> orthogonal to this option. However, you'd need more rules, like the fact
> that the responder needs to clear (or truncate) all bits it doesn't
> understand or doesn't agree to.

Yes, I'll add that words to that effect.

Looking at the list of currently assigned options, very few of them
are binary flags like this (SACK permitted is the other major one,
"Partial Order Connection Permitted", etc), suggesting that it might
not be worthwhile. As you point out:

> the 25th such flag pays an extra 3-byte penalty when no
> other flags are used.

Which is true. I'm happy with whatever the consensus is.



Cheers

AGL

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