Two things ... one for Yanmei, one for Mikkel. On Thu, Nov 12, 2020 at 5:11 AM Mikkel Fahnøe Jørgensen <[email protected]> wrote:
> Hi Yanmei Liu > > I think this sounds like a good approach. It takes all the work an > application would otherwise have to do and hides the complexity, without > completely introducing a lot of new protocol complexity. This allows an > application to open a stream and keep working on it regardless of which > connections are currently alive. > > I wonder if there are cases where this is a bit too heavy. For example > handshakes could perhaps be simpler on secondary connections. > > Also I wonder about privacy. For example if it is easy to detect that to > concurrent connections belong to the same endpoint, fingerprinting might be > easier. I guess that would always be a problem for MP. > For Mikkel, ISTM that we are wobbling between "true multipath is easier to track" and "connection migration is the weakest form of multipath, so if multipath is trackable, so is connection migration", and I wonder if someone could point me to an analysis of "how to avoid tracking for connection migration" - one strategy I've learned a lot about at/since the virtual interim was validating multiple paths early in the life of a connection, so that failover can happen quickly, for instance. One strategy that's happening in my world is "open one connection per QoS, on each path". In my world, that's a total of four connections (the reasons why don't matter). Is it better to open two connections on one path, and wait SOME_RANDOM_TIME to open connections on the other path, or to open all four paths roughly simultaneously? I'm asking this in QUIC, because QUIC connection migration isn't limited to two paths, and ISTM that the more paths you are going to use, the more we should pay attention to tracking. I'm not a genius of privacy, but some of them are here, and more are certainly available if we needed them, so I'd like to understand the thinking here. > There are also subtleties such as idle-timeout. What if each connection > has a different timeout, is it only the sub connection that dies, or the > entire connection? There could even be a case where connections remain > alive without any currently open sub-connection in order to deal with > aggressive NAT gateways etc. > > If secondary handshakes get simplified, I suspect it is more of an > implementation whether to see it as sub-connections, or just protocol > messages on different paths. > > - Mikkel > > On 12 November 2020 at 11.48.50, Yanmei Liu ([email protected]) > wrote: > > Hi Lucas, > > > > > > > You are right, connection migration is the weakest form of multipath. > > > > > > > > Thanks. We heard use cases that would like stronger forms. I think it will > > help continue to move the discussion forward if we can establish some > > common ground on terms and capabilities. > > For Yanmei, > > I > strongly agree that we need to establish some common ground on terms and > capabilities, > so I’d like to explain some design considerations in > [draft-an-multipath-quic]( > https://tools.ietf.org/html/draft-an-multipath-quic-00 > ), and we hope to get more feedbacks. > > I think "we need to establish some common ground on terms and capabilities" is exactly right. > > If I understood David Scinazi's comment to me about this at the virtual interim, he found the steering/switching/splitting characterization in my presentation helpful, so I started working on an individual draft in Github here - https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with-multipath - to begin capturing understandings of ways in which multiple paths might be used, and different strategies for using them. The current version of the draft uses language that's ATSSS-specific, although I don't think the ideas are closely tied to ATSSS. As I said in the draft, This section uses terminology from 3GPP ATSSS {Access Traffic Steering, Switch and Splitting, [TS23501]) to describe three different patterns of packet forwarding that could be used when multiple disjoint paths are available. Note that these terms describe concepts that are not ATSSS-specific, and could apply to any multipath environment. If terminology more accessible to IETF QUIC working group participants presents itself, I'll change it. If people agree that common ground on terms and capabilities would be useful, they are invited to contribute. And thanks for bringing your work to the QUIC working group. Best, Spencer
