Re: [tcpinc] Revised version of TCP-ENO

[David Mazieres <[e-mail]>]

Kyle Rose <[e-mail]> writes:

> What is the meaning of "first valid spec identifier"? This allowance
> for multiple spec identifiers sent by host B makes sense if the chosen
> spec is "the first spec identifier also among those spec identifiers
> that host A sent",

That is the intent.  In other words, if A and B have multiple compatible
spec identifiers, the negotiated spec is the one at the lowest byte
offset in B's SYN segment.

> but otherwise there's no difference between host B
> sending a single static identifier or multiple: if host A supports the
> first in host B's static list, that would get used; otherwise TCP-ENO
> negotiation would fail.

That's right.  So that's why if possible B should send only one.  But in
the case of simultaneous open, both A and B may want to send multiple
supported identifiers, since they don't know what the other side
accepts.  In that case the priority is determined by B.

> You seem to imply the meaning above in figure 8, in which case I think
> the text should be clarified.

I think the confusion is that if you are creating a SYN-ACK in response
to a SYN, there is no reason to include more than one spec identifier.
It's just that we wanted to leave room for the possibility that B' SYN
doesn't depend on A's SYN, either because of simultaneous open, or for
implementation reasons.

Does what I wrote in this email make sense, and if so, can you identify
more precisely the source of the confusion, or suggest a specific edit?

> 3.3:
>
>> A TCP segment MUST
>> include at most one suboption whose high nibble is 0.
>
> Does this mean "A TCP SYN segment including the TCP-ENO option MUST..."?

Yes.  Would the following wording help:  "A TCP segment MUST include at
most one ENO suboption whose high nibble is 0."

> 4.1: Do you want to add the additional requirement that session IDs be
> public, i.e., not be secret to endpoints/applications?

This was the intent of the following bullet in section 4.1:

   o  The session ID MUST NOT contain any confidential data (such as
      data permitting the derivation of session keys).

We didn't use the word "public" because that almost sounds like there's
a requirement to disclose the session ID.  But if the existing wording
is not clear, we are certainly open for suggestions.

Thanks for the feedback.

David