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

On Thu, Aug 14, 2008 at 10:05 AM, Joe Touch <touch@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.

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.

> I do not understand the semantics of a TCP option that changes the TCP
> stream. TCP is a stream-oriented protocol, and each connection provides
> one stream. If you want a separate channel, you ought to be using a
> different protocol, e.g., SCTP.

It's not a separate channel, it's just that the option is an
application level signal. Caitlin probably puts it's better than I do:

"While this is an application layer problem that any application
could have solved on its own, there is some merit in providing
this as a generic transport capability precisely because it enables
support of existing clients and servers."

Cheers

AGL

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