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

[Eric Kinnear <[e-mail]>]

I don't think migration vs. multipath is currently the distinction for how many paths a client probes, it's the restriction on how many paths the client _uses_ at any one time, and I think that's appropriate. There are many cases where I'd want to be able to probe more than one path, and assuming that a device has a single network attachment (where we need to include IPv4 and IPv6 as more than one given that you need a new CID for each local address) doesn't make sense either.

The number of paths that a client can probe simultaneously is limited by how many CIDs the server is willing to issue to that client. 

To the point of the original issue: 
> 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.

If adding that TP is unnecessarily complex (and I agree that it probably is), what's wrong with recommending servers to remember paths up to as many as the number of spare CIDs that they issue? The whole point of issuing more than one spare CID is that the other endpoint may need to probe additional paths or those probes may be lost, but if you aren't willing to deal with things coming in from 100 places, don't issue 100 CIDs. Obviously that's an exaggeration, but 2/4/6/8 for each client puts a nice bound and is roughly what I'd expect to be sending in a TP anyways.

There's already a mechanism where the person doing the probing can "retire" that CID and signal to you that you no longer need to have that state around, and that's tied directly into their ability to generate new state that you'd need to keep around.

In essence, I think I agree with @martinthomson's statement above, if a server needs to reduce its exposure further it can do so, at the potential cost of performance or burning CIDs faster (as @kazuho points out). 

Enhancing the text around the existing sentence in Section 5.1.1 (that cautions against issuing too many CIDs) to also say that a server needs to maintain this state and should consider that when issuing new CIDs could be reasonable, but I wouldn't consider that time for a new TP?

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