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

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

On Thu, Jul 31, 2008 at 4:02 PM, Joe Touch <[e-mail]> wrote:
> - - TCP is already permitted to send data in the SYN-ACK
>        prohibiting it when the SA-PP option is missing violates
>        RFC1122 sec 4.2.2.5 -- unknown options are silently ignored
>
>        options that change TCP need to be explicitly acknowledged,
>        and current (legacy) behavior should be assumed if not
>        acknowledged

Ah, I didn't know this. Thank you!

I don't believe changing TCP to disallow this is a good idea. However,
it's important that userland knows weather this experiment is in
effect. Thus, I believe that I should echo the SA-PP option in the
SYNACK. Also, it should probably change names: SYN/ACK Payloads
Processed or some similar.

> - - The rule "For a given SYN, if any resulting SYNACK frame has a payload
> then all resulting frames MUST have a payload" appears to disable
> persists and ACKs as would be needed for proper operation when data is
> not available in one or more direction

That's badly worded on my part. It should read:
"For a given SYN, if any resulting SYNACK frame has a payload then all
resulting SYNACK frames MUST have a payload"

(i.e. the restriction only apply to SYNACK frames. It's just so a host
cannot decide the retransmit a different SYNACK)

> - - AFAICT, it isn't sensible to retransmit a SYN with the same ISN, port,
> etc. and different options. Since you do not explicitly acknowledge the
> option, how do you know which SYN is being ACKd - the presence of SA
> data isn't sufficient (e.g., legacy TCPs could do this)

As you note, as another consequence of my misunderstanding, the
presence of SA data isn't sufficient to tell which SYN is getting
acked. Echoing the option should also solve this issue.

> - - the diagrams need to include some corner cases:
>        - when KX is larger than the PMTU in fig 3 (or NList is
>        larger than the PMTU in fig 2)
>        (i.e., it seems like there is a missing MUST NOT on the length)

It's suggested that the payload be limited to 64-bytes to prevent
amplification backscatter from a SYN flood. Thus these bytestrings
have to fit within the MTU. If an implementation doesn't enforce this,
then it has to drop support when replying on a link where the MTU is
insufficient.

>        - how do you handle simultaneous opens?

I believe that simultaneous opens work just fine, although both sides
will believe that the other doesn't support this experiment since the
option won't be echoed in the SYN.

> - - can you explain why you use a bit-field for the TCP option flag,
> rather than just using a 2-byte option? (i.e., KIND, length)

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.
If SACK permitted has been defined this way, for example, then this
draft wouldn't need to take any more space.

However, this is very subjective. If people would prefer not to do
this, or would prefer to break it out into its own draft, I'm
perfectly happy with that.


Thanks!

AGL

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