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

On Thu, Aug 14, 2008 at 10:30 AM, Joe Touch <touch@isi.edu> wrote:
> OK. So why bother with an option at that point? Why does the user data
> need to be different if the option is present?
>
> If the user data were not different, then this all boils down to a
> change in the implementation of the API. The trouble is that you're
> expecting a TCP option to change the *content* of the data stream, and
> that seems bizarre to me.

Because for server-speaks-first application protocols there's no
problem. This is just for client-speaks-first protocols. For these
protocols, had common stacks been able to send data in the SYN/ACK
when they were being designed, then they might have ended up as
server-speaks-first protocols. But they didn't for latency reasons.

In order for them to take advantage of this they need to be able to
signal their compliance somehow. There is, indeed, a cleanliness
argument against such a option, but I'm arguing that it's worthwhile
for backward compatibility reasons.

> This is a big change - you're saying that if the payload fits, it goes
> in the SYN-ACK. If not, *none* of it is sent in the SYN-ACK? Why?

I'm saying that implementations have latitude here. If the passive
open end wishes to ignore the client's option it may. Equally, it may
echo it, but not include the data in the SYNACK if the MTU makes it
troublesome. In that case, it needs to send it in the next packet as
normal. Since the implementation has the best knowledge of what's
best, I didn't see any reason to constrain it.

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm