Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/multipath-tcp/mptcp_net-next/issues/536 below:

avoid selecting initial endpoint upon `ADD_ADDR` reception if servers deny MPJ to initial address · Issue #536 · multipath-tcp/mptcp_net-next · GitHub

If servers set the C flag (deny MPJ to the initial address+port) in their MP_CAPABLE, clients will likely not use their other endpoints.

This supposes clients are using the in-kernel PM, endpoints are not flagged as fullmesh, and the limit is high enough. There are two cases that involve the creation of new subflows:

• Endpoints flagged as subflow will be used to create new subflows, one at a time, to the address of the server used in the initial subflow → because of the C flag, clients will not do anything here.
• Upon the reception of an ADD_ADDR, a new subflow will be created using the local address the routing configuration will pick → very likely the one of the initial subflow, not from a new endpoint.

If the C flag has been set, upon ADD_ADDR reception, the PM should probably first look at unused endpoint, before picking IPADDRANY.

Also, by default the limits are add_addr_accepted 0 subflows 2. Should we do something about that if the server set the C flag? (We don't want the server to react to ADD_ADDR if the client set the C flag)

#503 could be a possibility, but something should be done for the default use-case: when only the subflow flag is set on the endpoint.

Thanks to @majek for pointing out this issue to me.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4