<WG chair hat off> Two thoughts:
If there can be more than one ENO option in a packet, lexicographic ordering within each portion of the transcript (i.e., a canonical format for the transcript, independent of what happened on the wire) is your friend, and carries no additional packet overhead (i.e., start with idea #2). The MUST NOT for middleboxes in idea #1 below is unrealistic, IMHO. In the context of this discussion, generalizing ENO so that one only ever has to send one instance is appealing ... but ... it costs option space, and I'm not holding my breath for appearance of larger option space in a widely usable fashion. </WG chair hat off> Thanks, --David > -----Original Message----- > From: Tcpinc [mailto:[email protected]] On Behalf Of David Mazieres > Sent: Friday, November 06, 2015 1:28 PM > To: [email protected] > Subject: [tcpinc] Call for data and opinions on option reodering > > Wednesday, Tero brought up the prospect of middleboxes reordering > back-to-back unknown options. This would currently mess up the ENO > transcript. Obviously middleboxes can process and manipulate options > they know about. The question is whether anyone has knowledge of a > middlebox that would flip the order of two, back-to-back, options of the > same, unknown kind. It's hard to see a rationale for such behavior. > Then again, rationality is not the best predictor middlebox behavior. > Hence, I'm wondering if anyone has any concrete data or knows of a box > that would do this in practice. > > Depending on the likelihood of such reordering, I see several ways to > proceed. > > 1. If it truly never happens in practice, then we can leave ENO as-is > and add a clause to the effect that middleboxes MUST NOT reorder ENO > options with respect to one another. > > 2. If it happens extremely rarely, then the transcript can > lexicographically sort host A's ENO options. The order of options > is meaningful in host B, however, so there we don't sort. Since > host B SHOULD send only one ENO option except in weird fringe cases > (such as simultaneous open), we can figure that two unlikely things > are really unlikely to happen simultaneously. > > 3. Use bytes of the form 1000xxxx (general suboptions with v=1) as > no-ops, and specify that multiple ENO options must be > lexicographically sorted. This sacrifices other uses of bytes > 128-143, but has the advantage that in the common case it requires > no extra bytes. Another advantage is that if we ever get truly > large SYN options, this would potentially allow more than 256 bytes > of ENO options. > > 4. We could add a length byte to every variable-length suboption, > allowing multiple variable-length suboptions to be packed into the > same ENO option. Then we limit hosts to sending only one ENO option > in a SYN segment. The cost is an extra byte of precious option > space in the common case, and limitation to 254 ENO bytes if we ever > get large SYN options. > > 5. Use bytes of the form binary 100xxxxx (that's general suboption and > reserved cs values, with v=1) as markers for a 1-32 byte suboption > (where the length of variable data is 1 + xxxxx). This has the > advantage that you only need the byte if you have more than one > variable-length suboption, and the disadvantage that bytes 128-159 > might have been useful for something else in the future. Another > disadvantage, if we ever get large SYN options, is that all but the > biggest variable-length suboption is now limited to 32 bytes. > > 6. Like the previous, but certain values of xxxxx could mean "a length > byte follows." This has the disadvantage that the most likely value > of xxxxx is 32, yet 32 is a nice number for ECDHE parameters if we > ever get large SYN options. Also, again all ENO suboptions are > limited to 254 total bytes. > > My preference, in order of decreasing appeal, is: 1, 2, 3, 6, 5, 4, with > a big distance between the first three (1, 2, 3) that I'm basically okay > with, and the last three (6, 5, 4) for which I would require some > convincing. However, now that the document belongs to the working > group, I'm soliciting opinions from everyone. > > Obviously my preference is heavily motivated by the hope that we someday > get large TCP options. Though it seems unlikely in the near future, > history is littered with examples of people underestimating maximum > parameter values. Particularly given that large options would make us > want to embed public-key-like values into SYN segments, and that each > individual ENO option will still be 256 bytes, I'd like to preserve the > ability to have more than one ENO option per SYN segment. > > David > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
