On 12/14/2020 12:30 PM, Mikkel Fahnøe Jørgensen wrote:
OK, thanks for explaining.
I wonder if the current asymmetric approach could be enhanced
relatively easily by allowing a server to announce a list of
address/port/QoE tuples that it can recommend the client to use as
virtual endpoints, without initiating anything. The client would then
issue path challenges as usual, but can do so to any one of the
proposed endpoints. The server could periodically propose new such
tuples or update QoE on existing. If a server wants to retire an
endpoint, it could send that information too, but a draining period
would be needed.
This could also piggy back on the existing CID update system where a
server CID is associated with a virtual endpoint.
Yes, it is tempting to add a way for a server "to announce a list of
address/port/QoE tuples that it can recommend the client to us" as part
of the multipath design. I think that we should resist that temptation,
and treat "annoucing addresses" as a separate problem. After all, even
if the endpoint do not use the multipath extension, they might still use
these server addresses as targets of V1-supported address migration.
Nick Banks was discussing this server address migration issue in the
Slack chat room a couple of weeks ago. His use case was a server joined
through a bandwidth limited VPN; there would be benefits in moving the
connection to a direct path outside the VPN. It turns out that this
migration requires more than merely communicating alternate server
addresses to the peer: server and clients also need to cooperate to open
a hole in the firewall that protects the server. This gets very close to
problems encountered in peer to peer scenarios.
These are good problems to address, but I would rather address them in a
targeted effort than as part of the multipath design.
-- Christian Huitema
