Subject: [tsvwg] WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 3 Aug 2021 09:11:46 +0100

TSVWG,

The WG is running an adoption call for:

DCCP Extensions for Multipath Operation with Multiple Addresses

draft-amend-tsvwg-multipath-dccp  <https://www.potaroo.net/ietf/idref/draft-amend-tsvwg-multipath-dccp/rfcmarkup?repository=/away/ietf&url=/away/ietf/all-ids/draft-amend-tsvwg-multipath-dccp-05>

This document is currently marked as Experimental. The adoption call 
will end at midnight UTC on 19th August, 2021.

Please do read the draft, and send any comments/concerns to either the 
tsvwg or to the chairs <[email-masked]>. Notes of support to 
progress this work, and volunteers to review the drafts will be very 
welcome at this stage.

Thanks, Gorry, David and Wes
(tsvwg co-chairs)

Note: The IPR search relating to this draft returns: 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-amend-tsvwg-multipath-dccp 
(updated 19/7/2021).

---

From: <[email-masked]>
Date: Tue, 10 Aug 2021 13:33:02 +0000

I support wg adoption
Best wishes
Phil
________________________________
From: tsvwg <[email-masked]> on behalf of Gorry Fairhurst <[email-masked]>
Sent: Tuesday, August 3, 2021 9:13 am
To: [email-masked]
Cc: [email-masked]
Subject: [tsvwg] WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021

TSVWG,

draft-amend-tsvwg-multipath-dccp<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.potaroo.net%2Fietf%2Fidref%2Fdraft-amend-tsvwg-multipath-dccp%2Frfcmarkup%3Frepository%3D%2Faway%2Fietf%26url%3D%2Faway%2Fietf%2Fall-ids%2Fdraft-amend-tsvwg-multipath-dccp-05&data=04%7C01%7Cphilip.eardley%40bt.com%7C52016cbb67804017455f08d956567cd1%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637635752309970912%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=eMROW6%2FU45tmbatawD2%2FDNyDptYvQ9dLd9fOl6hlohI%3D&reserved=0>

This document is currently marked as Experimental. The adoption call will end at midnight UTC on 19th August, 2021.

Please do read the draft, and send any comments/concerns to either the tsvwg or to the chairs <[email-masked]><mailto:[email-masked]>. Notes of support to progress this work, and volunteers to review the drafts will be very welcome at this stage.

Note: The IPR search relating to this draft returns: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-amend-tsvwg-multipath-dccp<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fipr%2Fsearch%2F%3Fsubmit%3Ddraft%26id%3Ddraft-amend-tsvwg-multipath-dccp&data=04%7C01%7Cphilip.eardley%40bt.com%7C52016cbb67804017455f08d956567cd1%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637635752309980909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ks3L29q%2FMGSA5TUBo%2FiK3kw47%2FUhArmnkmjDQtIV3bk%3D&reserved=0> (updated 19/7/2021).

---

From: Giorgi Gulbani <[email-masked]>
Date: Wed, 11 Aug 2021 13:49:20 +0000

I also support WG adoption of the multipath-dccp.

Kind regards,

Giorgi

From: tsvwg [mailto:[email-masked]] On Behalf Of philip.eardley=[email-masked]
Sent: Tuesday, 10 August 2021 16.33
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021

I support wg adoption
Best wishes
Phil
________________________________
From: tsvwg <[email-masked]<mailto:[email-masked]>> on behalf of Gorry Fairhurst <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, August 3, 2021 9:13 am
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [tsvwg] WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021

TSVWG,

---

From: "Smith, Kevin, Vodafone" <[email-masked]>
Date: Thu, 12 Aug 2021 08:39:55 +0000

I support WG adoption of MP-DCCP to facilitate its assessment for 3GPP ATSSS
All best,
Kevin

From: tsvwg <[email-masked]> On Behalf Of Giorgi Gulbani
Sent: 11 August 2021 14:49
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021

CYBER SECURITY WARNING: This email is from an external source - be careful of attachments and links. Please follow the Cyber Code and report suspicious emails.
I also support WG adoption of the multipath-dccp.

Kind regards,

Giorgi

From: tsvwg [mailto:[email-masked]] On Behalf Of philip.eardley=[email-masked]<mailto:philip.eardley=[email-masked]>
Sent: Tuesday, 10 August 2021 16.33
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021

I support wg adoption
Best wishes
Phil

TSVWG,

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Aug 2021 11:10:08 +0100

This adoption call is on-going on the tsvwg list. So far I have seen 
notes of support from the editors and on-list from:

Minjun Xi
Kevin Smith
Giorgi Gulbani
Phil Eardley

If you have read this and do support work on this please respond on-list 
by midnight UTC on 19th August, 2021.

Best wishes,
Gorry

(tsvwg co-chair)

-------- Forwarded Message --------
Subject: 	WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 
19th August 2021
Resent-Date: 	Tue, 3 Aug 2021 01:12:26 -0700 (PDT)
Resent-From: 	[email-masked]
Resent-To: 	[email-masked], [email-masked], [email-masked]
Date: 	Tue, 3 Aug 2021 09:11:46 +0100
From: 	Gorry Fairhurst <[email-masked]>
To: 	[email-masked] <[email-masked]>
CC: 	[email-masked] <[email-masked]>

TSVWG,

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 16 Aug 2021 12:25:20 +0000

Hi all,

given ATSSS is mention again, I would like to comment (knowing that discussion should and will in future rather take place in 3GPP). In rel-17 there was agreement to work on a QUIC-based solution for ATSSS, however, given work on MP-QUIC is still pending in the IETF, ATSSS support for non-TCP was postponed to rel-18 where discussion now is re-started what to study. So far there was large support in 3GPP for a QUIC-based solution for non-TCP traffic in ATSSS and no discussion about MP-DCCP.

Even though there is a proposal now  from DT to study use of MP-DCCP, I personally think that a QUIC-based approach is more future-looking for ATSSS rather than supporting yet another transport stack (DCCP) only for this use case. Also in the IETF I was hoping that those people interesting in multipath work, would rather cluster their resources to work on MP-QUIC. I of course won’t stop anybody from working on MP-DCCP but I personally don’t think it will be adopted for ATSSS and am not sure if therefore it will be widely used in future.

Mirja

From: tsvwg <[email-masked]> on behalf of "Smith, Kevin, Vodafone" <Kevin.Smith=[email-masked]>
Date: Thursday, 12. August 2021 at 10:45
To: Giorgi Gulbani <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [tsvwg] WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021

Kind regards,

Giorgi

I support wg adoption
Best wishes
Phil

TSVWG,

draft-amend-tsvwg-multipath-dccp<https://protect2.fireeye.com/v1/url?k=11fd7916-4e664055-11fd398d-861fcb972bfc-f35a4a522aca432c&q=1&e=d90d662d-1f31-4084-9c07-7716a118bc27&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.potaroo.net%252Fietf%252Fidref%252Fdraft-amend-tsvwg-multipath-dccp%252Frfcmarkup%253Frepository%253D%252Faway%252Fietf%2526url%253D%252Faway%252Fietf%252Fall-ids%252Fdraft-amend-tsvwg-multipath-dccp-05%26data%3D04%257C01%257Cphilip.eardley%2540bt.com%257C52016cbb67804017455f08d956567cd1%257Ca7f356889c004d5eba4129f146377ab0%257C0%257C0%257C637635752309970912%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C2000%26sdata%3DeMROW6%252FU45tmbatawD2%252FDNyDptYvQ9dLd9fOl6hlohI%253D%26reserved%3D0>
This document is currently marked as Experimental. The adoption call will end at midnight UTC on 19th August, 2021.

Note: The IPR search relating to this draft returns: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-amend-tsvwg-multipath-dccp<https://protect2.fireeye.com/v1/url?k=9fbea4e8-c0259dab-9fbee473-861fcb972bfc-52cbeacecdadb17d&q=1&e=d90d662d-1f31-4084-9c07-7716a118bc27&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fipr%252Fsearch%252F%253Fsubmit%253Ddraft%2526id%253Ddraft-amend-tsvwg-multipath-dccp%26data%3D04%257C01%257Cphilip.eardley%2540bt.com%257C52016cbb67804017455f08d956567cd1%257Ca7f356889c004d5eba4129f146377ab0%257C0%257C0%257C637635752309980909%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C2000%26sdata%3Dks3L29q%252FMGSA5TUBo%252FiK3kw47%252FUhArmnkmjDQtIV3bk%253D%26reserved%3D0> (updated 19/7/2021).

---

From: <[email-masked]>
Date: Mon, 16 Aug 2021 15:41:49 +0000

Hi Mirja,

please find my comments inline starting with [MA].

Br

Markus
From: tsvwg <[email-masked]> On Behalf Of Mirja Kuehlewind
Sent: Montag, 16. August 2021 14:25
To: Smith, Kevin, Vodafone <Kevin.Smith=[email-masked]>; Giorgi Gulbani <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021

Hi all,

given ATSSS is mention again, I would like to comment (knowing that discussion should and will in future rather take place in 3GPP).
[MA] Agree, such discussion should take place in 3GPP SA2, maybe best as part of the study phase.

In rel-17 there was agreement to work on a QUIC-based solution for ATSSS, however, given work on MP-QUIC is still pending in the IETF, ATSSS support for non-TCP was postponed to rel-18 where discussion now is re-started what to study.
[MA] Yep, you perfectly described the dilemma. There was no option provided from IETF for the non-TCP issue and the consequence was to postpone any solution from Rel. 16 up to the current Rel. 18 discussion. With MP -DCCP a real alternative, supporting steering, switching and spitting, is available now and perfectly fits into a 3GPP study phase for an assessment. Otherwise it’s likely that we have to postpone again and again because no well-suited MP-QUIC for ATSSS purpose is available, which is against the demand from the operators who signed https://datatracker.ietf.org/liaison/1741/.

So far there was large support in 3GPP for a QUIC-based solution for non-TCP traffic in ATSSS and no discussion about MP-DCCP.
[MA] …which became available now with an Open Source Linux reference implementation, a progressed IETF draft and support from some operators and vendors which believe a solution should be provided in Rel. 18 timeframe. With a potential WG adoption of MP-DCCP, a 3GPP prerequisite is fulfilled.

Even though there is a proposal now  from DT to study use of MP-DCCP,
[MA] Yep, see https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_146E_Electronic_2021-08/Docs/S2-2106497.zip
I personally think that a QUIC-based approach is more future-looking for ATSSS
[MA] What is the definition of future-looking? I see MP-DCCP definitively supporting the future development in ATSSS 😊
rather than supporting yet another transport stack (DCCP)
[MA] I think 3GPP already maintains a lot of stacks, where one additional for DCCP should not be of any importance (similar to MP-QUIC). DCCP is further part of the widely used mainline Linux Kernel which allows similar implementation as for MP-TCP within the ATSSS framework.
only for this use case. Also in the IETF I was hoping that those people interesting in multipath work, would rather cluster their resources to work on MP-QUIC. I of course won’t stop anybody from working on MP-DCCP but I personally don’t think it will be adopted for ATSSS and am not sure if therefore it will be widely used in future.
[MA] I think the scope of MP-DCCP is a little bit broader than ATSSS, even if the latter is now in the foreground because of the urgency there. From Hybrid Access to any multipath support for real-time services, MP-DCCP promises to support. Moreover it delivers and will deliver answers for general research questions in the area of multipath transport for real-time and unreliable traffic (UDP).
To quote here Martin Duke (https://datatracker.ietf.org/doc/minutes-111-tsvwg/): “…There are generic problems around multipath that are maybe research questions and I am glad we have a platform with this [MP-DCCP] and SCTP to explore those.”
[MA] So a support of MP-DCCP should not be understood as a vote against MP-QUIC, it’s rather complementary.

Mirja

From: tsvwg <[email-masked]<mailto:[email-masked]>> on behalf of "Smith, Kevin, Vodafone" <Kevin.Smith=[email-masked]<mailto:Kevin.Smith=[email-masked]>>
Date: Thursday, 12. August 2021 at 10:45
To: Giorgi Gulbani <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tsvwg] WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021

From: tsvwg <[email-masked]<mailto:[email-masked]>> On Behalf Of Giorgi Gulbani

Kind regards,

Giorgi

I support wg adoption
Best wishes
Phil

TSVWG,

---

From: <[email-masked]>
Date: Mon, 16 Aug 2021 15:41:53 +0000

Hi Mirja, all,
Thanks for the comments!
Although it’s true that MP-DCCP was not as much discussed before at 3GPP compared to MPQUIC, DCCP itself was already proposed for non-TCP traffic in ATSSS in Rel.16 back in 2018 (see https://www.3gpp.org/ftp//Specs/archive/23_series/23.793/23793-g00.zip<https://www.3gpp.org/ftp/Specs/archive/23_series/23.793/23793-g00.zip>). The decision to first develop the MP-extension in IETF seemed reasonable, since 3GPP is generally reluctant to have individual drafts referenced in its specs in normative phase.
Additional support for MP-DCCP is provided by, e.g., GSMA (https://datatracker.ietf.org/liaison/1741/) reflecting mainly operators’ perspective in need for a solution to efficiently handle non-TCP traffic (including QUIC) without running into problems with e.g., encryption potentially affecting the required MP-proxy functionality (see e.g., D4.3_V1.1.pdf (sat5g-project.eu)<https://www.sat5g-project.eu/wp-content/uploads/2020/06/D4.3_V1.1.pdf>). Also MP-DCCP is a quite simple straight-forward on-purpose protocol, dedicated for multi-connectivity architectures thus promising rapid development and subsequent operational benefits (see, e.g., slides-104-tsvwg-sessb-43-markus-amend-multipath-dccp-00 (ietf.org)<https://datatracker.ietf.org/meeting/104/materials/slides-104-tsvwg-sessb-43-markus-amend-multipath-dccp-00>)
Thanks!
Best Regards
Dirk
From: tsvwg <[email-masked]> On Behalf Of Mirja Kuehlewind
Sent: Montag, 16. August 2021 14:25
To: Smith, Kevin, Vodafone <Kevin.Smith=[email-masked]>; Giorgi Gulbani <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021

Hi all,

Mirja

Kind regards,

Giorgi

I support wg adoption
Best wishes
Phil

TSVWG,

---

From: Francisco Fontes <[email-masked]>
Date: Wed, 18 Aug 2021 14:46:31 +0000

Dear all,
I also support MP-DCCP adoption by the WG, with a special interest in its potential for 3GPP ATSSS, complementary to MP-TCP and MP-QUIC.
With my best regards,
Francisco

From: tsvwg [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
Sent: 3 de agosto de 2021 09:12
To: [email-masked]
Cc: [email-masked]
Subject: [tsvwg] WG adoption call for draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021

Atenção: Este email foi originado fora da Altice Portugal. Por favor, não clique em links nem abra anexos, a não ser que conheça o remetente e saiba que o seu conteúdo é seguro.

TSVWG,

draft-amend-tsvwg-multipath-dccp<https://www.potaroo.net/ietf/idref/draft-amend-tsvwg-multipath-dccp/rfcmarkup?repository=/away/ietf&url=/away/ietf/all-ids/draft-amend-tsvwg-multipath-dccp-05>
This document is currently marked as Experimental. The adoption call will end at midnight UTC on 19th August, 2021.

Note: The IPR search relating to this draft returns: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-amend-tsvwg-multipath-dccp (updated 19/7/2021).

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 18 Aug 2021 12:56:14 -0500

Just following up here ...

On Mon, Aug 16, 2021 at 10:42 AM <[email-masked]> wrote:

> *From:* tsvwg <[email-masked]> *On Behalf Of *Mirja Kuehlewind
> *Sent:* Montag, 16. August 2021 14:25
> *To:* Smith, Kevin, Vodafone <Kevin.Smith=[email-masked]>;
> Giorgi Gulbani <[email-masked]>; [email-masked];
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [tsvwg] WG adoption call for
> draft-amend-tsvwg-multipath-dccp, to end: 19th August 2021
>
>
>
> Hi all,
>
>
>
> given ATSSS is mention again, I would like to comment (knowing that
> discussion should and will in future rather take place in 3GPP).
>
> *[MA] Agree, such discussion should take place in 3GPP SA2, maybe best as
> part of the study phase.*
>

That would be awesome, and I will not comment on 3GPP topics here (it's not
WRONG to do so, but none of us can speak for 3GPP, or even for SA2 - and
that's their rules about liaisons, not ours).

So my IETF comment is that I support TSVWG adoption
of draft-amend-tsvwg-multipath-dccp, and would encourage TSVWG participants
to consider whether MP-DCCP would make the Internet a better place in years
to come.

>  In rel-17 there was agreement to work on a QUIC-based solution for
> ATSSS, however, given work on MP-QUIC is still pending in the IETF, ATSSS
> support for non-TCP was postponed to rel-18 where discussion now is
> re-started what to study.
>
> *[MA] Yep, you perfectly described the dilemma. There was no option
> provided from IETF for the non-TCP issue and the consequence was to
> postpone any solution from Rel. 16 up to the current Rel. 18 discussion.
> With MP -DCCP a real alternative, supporting steering, switching and
> spitting, is available now and perfectly fits into a 3GPP study phase for
> an assessment. Otherwise it’s likely that we have to postpone again and
> again because no well-suited MP-QUIC for ATSSS purpose is available, which
> is against the demand from the operators who signed
> https://datatracker.ietf.org/liaison/1741/
> <https://datatracker.ietf.org/liaison/1741/>.*
>
>
>
> So far there was large support in 3GPP for a QUIC-based solution for
> non-TCP traffic in ATSSS and no discussion about MP-DCCP.
>
> *[MA] …which became available now with an Open Source Linux reference
> implementation, a progressed IETF draft and support from some operators and
> vendors which believe a solution should be provided in Rel. 18 timeframe.
> With a potential WG adoption of MP-DCCP, a 3GPP prerequisite is fulfilled.*
>

I can't speak for 3GPP (see above), but I can say from experience that
having a draft in IETF that has NOT been adopted by any working group is
almost completely disqualifying, unless an AD agrees to sponsor it.

So, yes, that's a Big Deal in other SDOs (not just 3GPP). That shouldn't
sway TSVWG's decision whether to adopt draft-amend-tsvwg-multipath-dccp as
a working group draft, although it's a good thing for TSVWG to know.

> *[MA] Yep, see
> https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_146E_Electronic_2021-08/Docs/S2-2106497.zip
> <https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_146E_Electronic_2021-08/Docs/S2-2106497.zip>*
>
> *[MA] What is the definition of future-looking? I see MP-DCCP definitively
> supporting the future development in ATSSS **😊*
>
> *[MA] I think 3GPP already maintains a lot of stacks, where one additional
> for DCCP should not be of any importance (similar to MP-QUIC). DCCP is
> further part of the widely used mainline Linux Kernel which allows similar
> implementation as for MP-TCP within the ATSSS framework.*
>
> only for this use case. Also in the IETF I was hoping that those people
> interesting in multipath work, would rather cluster their resources to work
> on MP-QUIC.
>

I have shared Mirja's hope for several years. 🙂

> I of course won’t stop anybody from working on MP-DCCP but I personally
> don’t think it will be adopted for ATSSS and am not sure if therefore it
> will be widely used in future.
>
> *[MA] I think the scope of MP-DCCP is a little bit broader than ATSSS,
> even if the latter is now in the foreground because of the urgency there.
> From Hybrid Access to any multipath support for real-time services, MP-DCCP
> promises to support. Moreover it delivers and will deliver answers for
> general research questions in the area of multipath transport for real-time
> and unreliable traffic (UDP).*
>
> *To quote here Martin Duke
> (https://datatracker.ietf.org/doc/minutes-111-tsvwg/
> <https://datatracker.ietf.org/doc/minutes-111-tsvwg/>): “…There are generic
> problems around multipath that are maybe research questions and I am glad
> we have a platform with this [MP-DCCP] and SCTP to explore those.”*
>

Martin can certainly Confirm Or Deny that this is his current thinking, but
that seems to be an accurate quote in Gather discussions with Martin as
well.

I happen to agree with that thinking - to the point where I took a recent
draft on "path selection for QUIC" to PANRG at IETF 111 and presented it
(slides are here:
https://datatracker.ietf.org/meeting/111/materials/slides-111-panrg-path-selection-for-multiple-paths-stepping-back-00,
and minuted discussion is here:
https://datatracker.ietf.org/meeting/111/materials/minutes-111-panrg-02).

In my mind, the high-order bits are that

   - There is work to be done on multipath topics that is not
   protocol-specific,
   - some of this work is research, and
   - none of the first two points in this list should block consideration
   of protocol-specific multipath drafts in appropriate working groups as
   testbeds for experimentation.

*[MA] So a support of MP-DCCP should not be understood as a vote against
> MP-QUIC, it’s rather complementary.*
>

I think so, too, and I might even have said "orthogonal", but I'm still
working to understand the various use cases under discussion in various
places.

Best,

Spencer