Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt

[Christian Huitema <[e-mail]>]

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