Re: [PANRG] Path Selection for Multiple Paths

[[e-mail]]

Hi Spencer,

See inline [MA]

From: Spencer Dawkins at IETF <[e-mail]>
Sent: Montag, 2. August 2021 22:43
To: Amend, Markus <[e-mail]>
Cc: [e-mail]
Subject: Re: [PANRG] Path Selection for Multiple Paths

Hi, Markus,

On Mon, Aug 2, 2021 at 10:40 AM <[e-mail]<mailto:[e-mail]>> wrote:
Dear Spencer, all,

I just had a look into the IETF111 PANRG recordings and found the presentation about Path Selection for Multiple Paths very refreshing. It would be good to have a place where multipath challenges and solutions can be consolidated in IETF. The challenges you brought up in your presentation are related to multipath transport layer approaches like MP-TCP/QUIC/SCTP/DCCP, but also (partly) to any other approach on layers different to this, e.g. GRE bonding (RFC8157) etc. pp. That's why I appreciated your updated presentation title "Path Selection for Multiple Paths" instead of "Path Selection for Multiple Paths in QUIC".

Thanks for your kind words!

The individual topics you raised (and I expanded)

  - scheduling
  - reordering
  - path estimation by CC or other means
  - sequencing
  - loss detection and handling
  - nested or concatenated CC - e.g. QUIC over MP-DCCP (3GPP ATSSS)

and also their possible interworking is an interesting research area.

In the MP-DCCP development we are quite advanced in the identification of this challenges and for some of them we are providing quite efficient solutions. Some of them are documented as part of the MP-DCCP protocol draft in TSVWG others like scheduling, reordering and fast packet loss detection are provided to ICCRG or published in academic paper.

I think this is a key question for PANRG (and, more broadly, potentially for other IRTF research groups). I like your topic list. Do you have thoughts about which topics involve loss detection and congestion control, which likely are (should be?) in scope for ICCRG, and which ones are broader questions?
[MA] I think that is not always selective. Loss detection is something which can be useful on sender and receiver side. While the first can use it for scheduling adaptation (e.g. by CC), path exclusion and re-transmission purposes, the latter can trigger NACK messages to the sender or skip lost packets in the reordering process. In the known L4 multipath protocols, CC is commonly used to estimate the path and provide input to the scheduling process. Most often CC algorithms are sensitive to packet loss… So loss detection and CC are very much correlated in multipath scenarios, while not in all.
[MA] If it comes to loss handling it’s even more complicated. Different re-transmissions strategies with multiple tuning parameter can be applied (strict, partial, rescheduling on other flow, …), but also pro-active things like network coding on connection and path level.
[MA] A general mean to facilitate loss detection and handling is the sequencing. In multipath scenarios this can be applied on different layers like connection and path layer. Stream aware network protocols (SCTP, QUIC) even introduce an additional sequencing layer to keep track of the streams. Smart combinations allow in certain scenarios real-time loss detection… However when multipath protocols are designed, the sequencing for optimized packet loss detection is often not in scope. For example MP-DCCP specifies consciously a connection sequencing and a path sequencing, which gives the receiver an immediate distinction between outstanding and lost packets when a continuous stream of data is processed.

[MA] Keep the long (incomplete) story short, I wonder if we need a specific Multipath RG which covers such topics instead of distributing individual multipath topics across RGs?

I made the assertion last week in PANRG that path selection was in scope, and we seemed to agree on that.
[MA] Yep, I do as well as long as there is no overarching multipath group.
I'm also wondering about path estimation (especially by "other means"), and about nested or concatenated paths (assuming that not all the issues with nested or concatenated paths are about CC).
[MA] Assuming the demand from 3GPP ATSSS, it’s pretty likely that we face the challenge of nested CC (QUIC over MP-xxx) and concatenated CC (MPTCP Proxy). I agree that those could be considered generically, on the other hand there are specific known challenges 😊 That does not mean that I have a preference for the one or other direction, I simply say one can deal with this on certain abstraction levels. Btw. one interesting “other means” I see, is including cross layer information into the scheduling process.

But I'd like to know what you think, and what others think as well.

I encourage and invite people interested in that research area to look into https://multipath-dccp.org as a nice little playground. The provided MP-DCCP Linux reference implementation there provides at least initial support for all of the topics mentioned above.

Very nice! and thank you for posting the pointer here - I also keep an eye on TSVWG, and I supported the "sense of the room" hum for adoption there.

So full support from my side, please go ahead with this work!

Is your plan now to shift your work on draft-dawkins-quic-multipath-selection to PANRG? And maybe change the title of your current draft to a more general title like for example "Path Selection in Multipath transport"?

Striking out "in QUIC'' in my presentation title on https://datatracker.ietf.org/doc/draft-dawkins-quic-multipath-selection/ for PANRG was a guess, but it seems to have been a good guess. That's certainly what I took away from last week's discussion, so, yes. I think I'm changing the filename to -panrg- in the next submission.

Btw. it's my first post to the PANRG mailing list 😊

Welcome to the party 😂

Best,

Spencer

Br

Marku