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

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

Adam Langley wrote:
| 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.

Client-speaks-first puts data in the SYN, not the SYN-ACK. Or have you
got the roles reversed, as with FTP data connections?

| 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.

If the option is ignored, and you don't intend to change TCP semantics,
then the data - i.e., the hash or whatever - needs to be sent in the
next data packet.

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

iEYEARECAAYFAkikkbgACgkQE5f5cImnZruy5gCfZvj6azlW6J5XITA9qESS0ovN
W7wAmwWpXEzT+gMsXWT5PgpnLQsJ6uDx
=mqEW
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm