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

[Joe Touch <touch at ISI.EDU>]

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



Adam Langley wrote:
| On Thu, Aug 14, 2008 at 10:05 AM, Joe Touch <touch at isi.edu> wrote:
|> It's a lot more than that; it hints that the socket interface is
|> insufficient for using the available TCP capability for sending data
|> with either SYNs or SYN-ACKs. I'm wondering how/if this has been
|> explored before, and whether there would be a solution that maps to
|> TCP's model of a stream better.
|>
|> The socket option above is incorrect, IMO. It implies that the user
|> should have control over data that ends up in the SYN-ACK directly; IMO,
|> TCP's stream model should allow only that data be written to the stream
|> early - which may require a socket option - BUT should *not* imply that
|> the data maps to the SYN-ACK directly.
|>
|> E.g., what happens if the data is larger than the MSS? Or if the SYN-ACK
|> comes back with an ICMP 'too-big'? I.e., this should be called just
|> TCP_DATA, not TCP_SADATA.
|
| There are several cases:
|
| If the setsockopt has requested that the data be included in the
| stream without exception, then it is enqueued like any other data. If
| there's space in the SYN/ACK, it can go in there. If not, it will be
| sent as usual. If the client doesn't ACK a SYNACK payload, it will be
| retransmitted etc. This requires no standards effort, it's a TODO for
| me at the moment.

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.

| If the setsockopt flags request that the data only be sent in reply to
| SYNs with the SAPP option:
|
| If the payload fits in the SYNACK (given MSS etc) then it is
| transmitted and the option is echoed back. Otherwise, a bare SYNACK
| (without the option) is sent back. In the latter case, the data is not
| enqueued to be sent in the future. The applications on both sides are
| aware of what happened and proceed correctly given the situation.

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?

TCP provides a *byte stream*. The description above implies that the
application knows/sees segment boundaries, which isn't TCP anymore.

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

iEYEARECAAYFAkika9IACgkQE5f5cImnZrvUUQCgwS0gBBPzVhXF5YoJCpEw84B7
XCMAnj+w6SpKM39Gv7e9AdrfUmb1allb
=OzbR
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm at ietf.org
https://www.ietf.org/mailman/listinfo/tcpm