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

[Spencer Dawkins at IETF <[e-mail]>]

Just following up here ...

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

> Hi Mirja,
>
>
>
> please find my comments inline starting with [MA].
>
>
>
> Br
>
>
>
> Markus
>
> *From:* tsvwg <[e-mail]> *On Behalf Of *Mirja Kuehlewind
> *Sent:* Montag, 16. August 2021 14:25
> *To:* Smith, Kevin, Vodafone <Kevin.Smith=[e-mail]>;
> Giorgi Gulbani <[e-mail]>; [e-mail];
> [e-mail]
> *Cc:* [e-mail]
> *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.


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

>