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

["Caitlin Bestler" <[e-mail]>]

There are several separable issues here. Each needs to be
considered on its own to determine if they should be addressed
by TCPM.

1) The sockets API forces applications to supply the necessary
   content for the first application message only after connection
   establishment has been signaled to the application layer.
   This typically results in an unneeded round-trip between the
   application domain and the TCP stack domain, which under most
   conventional Operating Systems is relatively expensive.

This is true. In addition to the problem cited, virtually all
client applications could supply the first request message in
the same call/request to initiate the connection.

But optimizing the local TCP stack interface can be done by
any TCP stack developer. It is a local interface. No IETF 
permission is required.



2) There are applications which would benefit from having
   optional application payload during connection setup.
   Such optional application payload is optionally provided
   by the client, and optionally provided to the server if
   the server requests it.

   This allows a "free upgrade" to the upper layer protocol,
   because *both* sender and receiver must be aware of the
   enhanced transport capability. If either is unaware, the
   protocol functions in compatibility mode based on the
   pre-existing definition of the TCP Stream.

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. This is especially relevant
when the client obtains the server contact info through a URL
whose format and distribution is already fixed (meaning that the
URL cannot effectively be used to tell the client which way to
attempt the connection). As the draft points out, the goal of
the optional data is typically to expedite latency, therefore
trial and error probing for capabilities would undermine the
intended benefit.

The two strongest counter-arguments against supporting such an
option are 1) it's new, all new TCP features should be viewed
with suspicion and avoided unless their benefits are strong,
and 2) Designing a feature that deliberately throws away some
of the TCP payload stream seems contrary to the whole concept
of a reliable transport.


3) The presence of this optional payload should be signaled
   through TCP options.

If this is going to be done, this is the only way to do it.
The existing definition of TCP payloads encompasses all possible
byte streams. Therefore the alternate semantics must come from
outside of the TCP payload stream itself. For ULPs driven by
URLs (HTTP, SMTP, etc.) the TCP options are the only solution.


4) The size of the optional payload is what fits in the SYN ACK
   response.

I have a major problem with this. Having an option to indicate
that the TCP payload stream will start with a special header
that documents its own length would make a lot more sense to me.

The key problem here is that if the active side is not capable of
delivering SYN-ACK payload it will just not ACK that portion.
There is no guarantee that the resulting retransmit will be
segmented the same way.

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