Re: [tcpinc] TCP's treatment of data in SYN packets

[Kyle Rose <[e-mail]>]

On Fri, Jul 29, 2016 at 2:46 PM, Joe Touch <[e-mail]> wrote:

>
> The thing about TCP is that it doesn't say what to do with data that is
> retransmitted.
>
> E.g., let's say you send SYN-abc, and I ACK only the SYN (not the data
> "abc").
>
> Then you send "def". I ACK the data *at the position of 3*. There's
> nothing that indicates which "position of 3" data I'm ACKing. For all you
> know, I cached the data in the SYN but did not ACK It, but when the new
> data came in I didn't overwrite it.
>
> Although I know this is unusual behavior, I'm not entirely positive it's
> prohibited by the spec. TCP doesn't say what happens to data that is sent
> more than once at a given position - there's no rule that it MUST be the
> variant seen in the most recently received segment.
>
> So I can easily imagine compliant implementations that might end up doing
> something you didn't want.
>
> That's why, IMO, if you send ENO, you need to make sure the SENDER doesn't
> put anything in the SYN data that has to be *changed*. Re-sent is fine. But
> CHANGED is not.
>

Right, I get that for interoperability with ENO-unaware stacks there is no
way to change data presented in the SYN. In the case where both ends
understand ENO but the server is not negotiating it, we can define TCP SYN
payload semantics differently: essentially, when there is an ENO option in
the SYN, an ENO-aware server will do one of two things:

(1) If it is negotiating ENO, it will hand the data off to the chosen TEP,
which will then indicate back to ENO whether to ACK the data or not.

(2) If it is not negotiating ENO, it will not ACK the data, and will in
fact throw it away and explicitly permit transmission of *different* data
for the same sequence number range.

This seems fine to me: since we're defining it in this case, we get to
choose the behavior. The problem is with interoperability with servers that
don't understand ENO, because they can't make an informed decision here,
and don't all throw away SYN data.

(4) Require signaling from the client application. This allows a client to
decide whether to support SYN data based on a priori knowledge of the
server's support for ENO.

I'm not sure what you mean here...

Allow the client to assume that a particular server supports ENO, and so
choose to send SYN data knowing a priori that the server will be able to
make the choice I outlined above. If you run a service on a particular
version of Linux that supports ENO, and distribute a phone app that
contacts only that service, it seems perfectly fine to tell your app to
assume the server knows ENO.

I'm not so sure about this case, as a middlebox unaware of ENO might be
breaking the connection: without SYN data, the connection simply wouldn't
negotiate ENO; with SYN data, the connection wouldn't negotiate ENO, and
the server might receive garbage data from the middlebox. Basically, cases
2-4 from my last email all carry similar potential for interoperability
problems.

Kyle