Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt

["Scheffenegger, Richard" <[e-mail]>]

Thanks!

Still, without additional constraints my simplistic reading of how the
GID value mapping to groups doesn't seem to address such collisions
entirely..

Also, some options are not necessarily negotiated, but only indicated -
thus a constraint that corresponding bits of the group may only be set
in a <SYN,ACK>, when they where present in the <SYN> is not sufficient.

One constraint I could come up with would be to require  the server to
reflect back "empty" (all zero option flags) blocks received from the
client, in case a bitstream collision would otherwise happen


e.g. client wants to signal option flag 7 of group 2, while server wants
to send back option flag 7 of group 1 (but not flag 7 of group 2), the
current draft would allow a "valid" exchange that looks like a reflection.

With the above, additional constraint, the server would have to return
an all-zero block for group 2 also, and may NOT skip over that...

Best regards,
    Richard




Am 08.02.2021 um 23:15 schrieb Matthew Luckie:
> Hi Richard,
>
> On Mon, Feb 08, 2021 at 10:46:45PM +0100, Scheffenegger, Richard wrote:
>> Hi Yoshi,
>>
>> Sorry to nitpick - in your draft, you mention that some hosts reflect
>> back unknown tcp options, which is why you are using different GID
>> mappings between SYN and SYN,ACK.
>>
>> I did read about this behavior concerning TCP header flags / reserved
>> bits - but have not come across a paper where this behavior is described
>> for unknown TCP options (or I may have missed that aspect in the various
>> studies around TCP option investigations done by MPTCP and other groups).
>
> There is some discussion of systems that seem to reflect TCP options here:
>
> http://blog.multipath-tcp.org/blog/html/2018/12/19/which_servers_use_multipath_tcp.html
>
> Matthew
>