Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport

From: Anna Brunström <[email-masked]>
Date: Fri, 19 Feb 2021 10:40:00 +0000

From: tsvwg <[email-masked]> On Behalf Of Martin Duke
Sent: den 17 november 2020 10:37
To: Markus.Amend <[email-masked]>
Cc: Michael Tuexen <[email-masked]>; tsvwg <[email-masked]>
Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport

On Tue, Nov 17, 2020 at 12:41 AM <[email-masked]<mailto:[email-masked]>> wrote:

What would be your conclusion if it turns out, that tunneling is the only/main use case? Specifying  DCCP encapsulation (protocol) separately or within the MP-DCCP?

Markus

I'm not sure. I does seem to be true that if the other two are valuable on their own, they have fewer concerns for adoption.

Hi all, I was caught up in my day job and did not manage to follow up on this thread in November.

I just wanted to add that while the number of use cases can of course be relevant in relation to the adoption discussion, I think the drafts should be kept separate either way. I do not think it makes sense to merge them.

Cheers,
Anna

När du skickar e-post till Karlstads universitet behandlar vi dina personuppgifter<https://www.kau.se/gdpr>.
When you send an e-mail to Karlstad University, we will process your personal data<https://www.kau.se/en/gdpr>.

---

From: Anna Brunström <[email-masked]>
Date: Fri, 19 Feb 2021 11:20:38 +0000

> -----Original Message-----
> From: tsvwg <[email-masked]> On Behalf Of
> [email-masked]
> Sent: den 17 november 2020 09:08
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Hi Martin,
> Good point to raise MASQUE's chartered focus on CC in CC. Discussing the
> MP-DCCP encapsulation framework makes this challenge even stronger and
> I'm happy to support any attempt to bring this jointly to ICCRG.

And to follow up on the CC in CC discussion, it is worth pointing out that running the tunnel CC over multipath adds some additional complexities. In particular, the choice of multipath scheduler can have a large impact on the CC in CC interaction. Perhaps this was also what Markus was thinking of above.

Cheers,
Anna

>
> From a separation point of view I have no doubt that we can clearly
> distinguish the MP extension of DCCP from the encapsulation/tunneling
> stuff. That's already the way how we applied the drafts.
>
> https://tools.ietf.org/html/draft-amend-tsvwg-multipath-dccp only takes
> care to specify the DCCP extension
>
> while https://tools.ietf.org/html/draft-amend-tsvwg-multipath-framework-
> mpdccp is intended to be informational and give guidance towards multipath
> support of non-DCCP traffic using tunneling/encapsulation.
>
> Br
>
> Markus
>
> From: Martin Duke <[email-masked]>
> Sent: Dienstag, 17. November 2020 01:46
> To: Amend, Markus <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Hi Markus,
> I should note that MASQUE is specifically chartered to provide
> recommendations for cc-in-cc without designing a new protocol or starting
> any research projects. The draft probably ought to say *something.*
>
> Header conversion and multipath seem uncontroversial to me, but
> encapsulation may raise some concerns. Can you tell me how separable the
> drafts are? Would there be any point in adopting two of them, or is
> encapsulation the use case that drives all the interest in these changes?
>
> On Mon, Nov 16, 2020 at 11:04 AM <mailto:[email-masked]>
> wrote:
> > -----Original Message-----
> > From: Michael Tuexen <mailto:[email-masked]>
> > Sent: Montag, 16. November 2020 19:40
> > To: Amend, Markus <mailto:[email-masked]>
> > Cc: mailto:[email-masked]
> > > On 16. Nov 2020, at 18:46, mailto:[email-masked] wrote:
> > >
> > >> -----Original Message-----
> > >> From: Michael Tuexen <mailto:[email-masked]>
> > >> Sent: Montag, 16. November 2020 17:51
> > >> To: Amend, Markus <mailto:[email-masked]>
> > >> Cc: mailto:[email-masked]
> > >>> On 16. Nov 2020, at 17:21, mailto:[email-masked] wrote:
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Michael Tuexen <mailto:[email-masked]>
> > >>>> Sent: Montag, 16. November 2020 17:06
> > >>>> To: Amend, Markus <mailto:[email-masked]>
> > >>>> Cc: mailto:[email-masked]
> > >>>>> On 16. Nov 2020, at 16:43, mailto:[email-masked]
> wrote:
> > >>>>>
> > >>>>> Hi Michael,
> > >>>>>
> > >>>>> inline
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Michael Tuexen <mailto:[email-masked]>
> > >>>>>> Sent: Montag, 16. November 2020 15:38
> > >>>>>> To: Amend, Markus <mailto:[email-masked]>
> > >>>>>>> On 16. Nov 2020, at 13:52, mailto:[email-masked]
> wrote:
> > >>>>>>>
> > >>>>>>> Dear all,
> > >>>>>>>
> > >>>>>>> as the TSVWG chairs suggested in the IETF 109 session, I
> > >>>>>>> continue the
> > >>>> discussion
> > >>>>>> on the mailinglist.
> > >>>>>> Hi Markus,
> > >>>>>>
> > >>>>>> I have two questions:
> > >>>>>>
> > >>>>>> 1. You stated that you are using CCID2. This means that you are
> > >>>>>> adding to handling of UDP packets a congestion control. How
> > >>>>>> does this interact with a congestion
> > >>>> control
> > >>>>>> provided by
> > >>>>>> the application?
> > >>>>>
> > >>>>> Yes, and moreover we also implemented BBRv1 into the DCCP CCID
> > >> framework.
> > >>>> The interaction between CCs is given and first results were
> > >>>> published a
> > while
> > >> ago
> > >>>> in https://arxiv.org/pdf/1907.04567.pdf based on NADA as
> application CC.
> > >> More
> > >>>> recent results are part of our presentation at ICCRG on Friday,
> > >>>> discussing a broader mix of CCs. Probably there is a trend not to
> > >>>> use packet loss based
> > CC
> > >> for
> > >>>> the tunnel.
> > >>>>>
> > >>>>> Two points here:
> > >>>>> 1. Nested CC is a broader topic beyond MP-DCCP and also valid
> > >>>>> e.g. for
> > >>>> MASQUE. Maybe something which should be independently
> > >>>> investigated in ICCRG?
> > >>>> I agree that this is not specific to the scenario you describe,
> > >>>> but a broader
> > >> issue.
> > >>>>> 2. Solving efficiently out-of-order aggregated multipath packet
> > >>>>> delivery is
> > >>>> equally important and often overlooked in favor of CC in CC.
> > >>>>>
> > >>>>>>
> > >>>>>> 2. Considering that you are fine with a tunneling protocol that
> > >>>>>> provides a congestion control, what are the benefits of using
> > >>>>>> DCCP instead of using SCTP with UDP encapsulation? You can use
> > >>>>>> PR-SCTP with the "don't retransmit" policy and could also let
> > >>>>>> the
> > >>>> reordering
> > >>>>>> done by
> > >>>>>> SCTP. Your failover scenario should be supported by all SCTP
> > >>>> implementations.
> > >>>>>> The
> > >>>>>> load-sharing would require some standardisation effort.
> > >>>>>>
> > >>>>>
> > >>>>> Excellent this question :-) I fully agree with you, that SCTP
> > >>>>> can provide
> > similar
> > >>>> mechanisms. Some years ago we developed, in parallel to our
> > >>>> MP-DCCP prototype, a SCTP based prototype leveraging PR-, PF- and
> > >>>> CMT-SCTP. The results looked very promising and we proposed this
> > >>>> to 3GPP ATSSS
> > >>>> (ftp://3gpp.org/Email_Discussions/SA2/Archive/2018-
> 10/Draft%20237
> > >>>> 93- 070_rm.doc, 6.1.7.4), but it was rejected.
> > >>>>>
> > >>>>> After that we gave up the SCTP development in favor of DCCP for
> > >>>>> several
> > >>>> reasons:
> > >>>>> -  bad/no Linux support for CMT-SCTP at this time
> > >>>> Compared to MP-DCCP support, I don't think there is much of a
> difference.
> > I
> > >>>> guess it would be implemented
> > >>>> in Linux, if the corresponding specification could be finished
> > >>>> (Linux recently
> > >> got
> > >>>> support for UDP encapsulation.). However, that is blocked up to
> > >>>> now in
> > >> TSVWG.
> > >>>> Since I'm not following 3GPP:
> > >>>> Is availability on Linux a requirement for 3GPP?
> > >>>
> > >>> No, but it was a requirement for our DT internal prototype
> environment.
> > With a
> > >> Linux reference implementation of (MP-)DCCP it was much simpler for
> > >> us to move forward and implement it for example in an Android device.
> > >>> Please don't forget, that was a decision we took in 2017.
> > >>>
> > >>> However, -just being proactively here - we currently should not
> > >>> end up with
> > >> the question:  Should we move forward exclusively with MP-DCCP or a
> > >> SCTP based approach. Both has from my view value and MP-DCCP is
> > >> first of all only
> > a
> > >> multipath extension for DCCP. Using encapsulation on top makes it
> > >> capable of transporting any traffic. It's the same as with SCTP, QUIC and
> TCP.
> > >> TCP might be a problem with strict ordering.
> > >
> > > Agree
> > >
> > >> But SCTP, QUIC, and DCCP could be
> > >> used the same way.
> > >> The only difference is that SCTP does support multihoming, for QUIC
> > >> and
> > DCCP it
> > >> is a yet to
> > >> be specified extension, QUIC needs unreliability, and all need a
> > >> way of load sharing. But then all of them could be used.
> > >>>
> > >>>>> -  No real unreliable delivery is given. Even PR-SCTP requires a
> > >>>>> reliable
> > >>>> "FORWARD-TSN" to become unreliable.
> > >>>> How does that impact the user experience? User messages can be
> > delivered
> > >> as
> > >>>> soon as possible to the application.
> > >>>
> > >>> Please correct me if I'm wrong, but as long as the FORWARD TSN has
> > >>> not be
> > >> received, head of line blocking occurs, right?
> > >> I don't see why. The receiver can deliver user messages as soon as
> > >> the
> > ordering
> > >> constraints can
> > >> be fulfilled. So if you send all user messages as unordered
> > >> messages (like on
> > UDP
> > >> or DCCP),
> > >> no buffering for reordering is required. So no HOL blocking.
> > >>
> > >
> > > Yep, I identified we argued from different perspectives. I agree,
> > > setting the U-
> > Bit will bypass any re-ordering functionality from SCTP and move
> > packets forward immediately to the application layer. That would give
> > support for steering and switching (seamless handover), however, for
> > CMT-SCTP the SCTP re-ordering function might be kept and then we step
> into the FORWARD-TSN trap with HoL.
> > Unless a re-ordering function is specified outside of the SCTP.
> > As far as I understand, DCCP does not provide an ordering preserving
> service.
> > Isn't it a UDP like service?
>
> That's true
>
> > > In contrast to this, our MP-DCCP Linux reference implementation is
> > > shipped
> > with a modular re-ordering scheme, which easily let define and use
> > various re- ordering logics. I hope we can publish the Linux implementation
> soon.
> > So you are adding something to DCCP? You could do that also as a shim
> > on top of SCTP using the U-bit.
> >
>
> Yes, that's what I wrote. However, with MP-DCCP we could think about
> defining a modular re-ordering scheme directly as part of the protocol, at
> least the signaling/negotiation for it. So no shim layer is required.
>
>
> In the meantime I also remember another experienced drawback from our
> SCTP prototype. I think it was quit inflexible when new communication paths
> came up during the lifetime of a SCTP session, a scenario often happens in
> mobile use cases. Only with an INIT chunk, communication paths can be
> negotiated once during the handshake. Any new IP addresses/paths, e.g.
> while changing from one Wi-Fi AP to another, requires a re-establishment of
> the SCTP session.
>
> I think for MP-DCCP we can resemble a lot of the well proved handshake
> procedures and address/path updates from MPTCP.
>
> > Best regards
> > Michael
> > >
> > >> Best regards
> > >> Michael
> > >>>
> > >>>>> -  UDP encapsulation overhead
> > >>>> True. It is an 8 byte overhead.
> > >>>>
> > >>>> Best regards
> > >>>> Michael
> > >>>>>
> > >>>>>> Best regards
> > >>>>>> Michael
> > >>>>>>
> > >>>>>>>
> > >>>>>>> For all who were not able to attend, the presented slides are
> > >>>>>>> available
> > >>>>>> u==[=[nderhttps://http://datatracker.ietf.org/meeting/109/mater
> > >>>>>> ials/slides-
> > 109-
> > >>>> tsvwg-
> > >>>>>> sessa-61-dccp-extensions-for-multipath-operation-00, with a
> > >>>>>> main focus
> > on
> > >>>> the
> > >>>>>> prototype implementation. This prototype leverages MP-DCCP
> > >>>>>> between
> > a
> > >>>>>> mobile handset and a public aggregation point, for giving
> > multipath/multi-
> > >>>> access
> > >>>>>> benefit to at least UDP traffic - complementing MPTCP - when
> > >> communicating
> > >>>>>> with the Internet. Due to the MP-DCCP encapsulation framework,
> > support
> > >> is
> > >>>> not
> > >>>>>> restricted to UDP and it’s even possible to provide the
> > >>>>>> multipath service
> > to
> > >> IP
> > >>>> or
> > >>>>>> Ethernet traffic. Packet based scheduling, as well as flow
> > >>>>>> based
> > scheduling
> > >> is in
> > >>>>>> scope of the prototype/drafts and explained together with
> > >>>>>> results as
> > part
> > >> of
> > >>>> the
> > >>>>>> above mentioned presentation.
> > >>>>>>>
> > >>>>>>> Seamless handover for reliability and path/access aggregation
> > >>>>>>> for high
> > >>>> speeds
> > >>>>>> are supported by design, fitting for example excellently into
> > >>>>>> the 3GPP
> > >> ATSSS
> > >>>>>> scope, leveraging:
> > >>>>>>> https://tools.ietf.org/html/draft-amend-tsvwg-multipath-dccp-0
> > >>>>>>> 3
> > >>>>>>> https://tools.ietf.org/html/draft-amend-tsvwg-multipath-framew
> > >>>>>>> ork-
> > >>>> mpdccp-
> > >>>>>> 01
> > >>>>>>> https://tools.ietf.org/html/draft-amend-tsvwg-dccp-udp-header-
> > >>>> conversion-
> > >>>>>> 01
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> and general scheduling and re-ordering concepts from
> > >>>>>>> https://tools.ietf.org/html/draft-amend-iccrg-multipath-reorde
> > >>>>>>> ring-01
> > >>>>>>> https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers
> > >>>>>>> -01
> > >>>>>>>
> > >>>>>>> Especially for 3GPP ATSSS purposes, this very dedicated and
> > >>>>>>> simple MP-
> > >> DCCP
> > >>>>>> framework provides an alternative over the currently discussed
> > >>>>>> MP-
> > QUIC
> > >>>>>> (+DATAGRAM + MASQUE), which is from an IETF perspective much
> > broader
> > >> in
> > >>>>>> scope and not dedicated to ATSSS purposes.
> > >>>>>>>
> > >>>>>>> However MP-DCCP is not limited to ATSSS and can be applied
> > >>>>>>> end-to-
> > end
> > >>>> with
> > >>>>>> or without encapsulation.
> > >>>>>>>
> > >>>>>>> So I encourage you to read through the drafts, give feedback
> > >>>>>>> and
> > discuss
> > >> the
> > >>>>>> potential roadmap towards WG adoption.
> > >>>>>>>
> > >>>>>>> Br
> > >>>>>>>
> > >>>>>>> Markus
> > >>>>>
> > >>>
> > >