Re: [quicwg/base-drafts] How many probed paths should a server remember? (#3489)

[Martin Thomson <[e-mail]>]

So a server doesn't need to probe in response to a client that probes a path, so it doesn't really have any state to attribute to probed paths.  A server can just respond to probes.  The cost to it, if it doesn't, is that it has to probe after a migration and that could have performance implications.

I would be happy saying that an endpoint ideally both probes and remembers the status of those probes for as many paths as it has issued, active connection IDs.  Probing paths and remembering the status of probes partly mitigates the reduction in CWND that follows migration, so there is a potential performance gain from keeping this state.  But the window is still likely reset, so the performance hit is essentially unavoidable either way.

The total number of paths a server might have to remember is limited by the active_connection_id_limit of the client, but it can be less (as you already noted), so the server has the ability to limit its exposure.

Thus, a server can probe and remember the status of as many paths as it likes.  I'd say that this is a fine piece of advice, but that's all it needs to be.  I agree that yet another transport parameter is not a great reaction to this relatively minor issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3489#issuecomment-598017306