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

[Kazuho Oku <[e-mail]>]

At the moment, it is my understanding that we do not give any advice in particular. But to me it seems that there would be issues if the number of probed paths that the server remembers is less than the number of spare connection IDs it issues.

Consider the case of a server that advertises three spare connection IDs, but retains information of one probing path (i.e. remember one set of 5-tuple that has been probed, and the connection ID being associated to that tuple).

If a client connecting to this server probes three paths concurrently, and if it keeps on sending PATH_CHALLENGE packets periodically on that path (in order to keep the holes in NAT open), two issues arise:
* The connection ID pool of the server would run out quickly, as the server would use a new connection ID for each probing packet it sends in response (because each probing packet sent by the client would have a different source address than the previous packet). This is an issue, as we state that _an endpoint MAY limit the frequency or the total number of connection IDs issued for each connection to avoid the risk of running out of connection IDs_ [section 5.1.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-5.1.1-5).
* The purpose of path probing is to prepare an alternate path beforehand. That benefit diminishes if the server remembers only one (or few) of the paths being probed.

Instead of recommending servers to remember paths as much as the number of spare connection IDs that they issue, we can introduce a transport parameter that caps the number paths that a client may probe. But IMO having a new TP seems unnecessarily complex, because I think that servers can simply associate path information to each active connection ID it maintains.

-- 
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