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

[Martin Duke <[e-mail]>]

Hi Markus,

My separability question is not whether it's technically possible (I'm
convinced it is); it's whether excluding the encapsulation part leaves us
with a use case that's actually worth working on.

On Tue, Nov 17, 2020 at 12:07 AM <[e-mail]> wrote:

> 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.
>
> 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 <[e-mail]>
> Sent: Dienstag, 17. November 2020 01:46
> To: Amend, Markus <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
>
> 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:[e-mail]> wrote:
> > -----Original Message-----
> > From: Michael Tuexen <mailto:[e-mail]>
> > Sent: Montag, 16. November 2020 19:40
> > To: Amend, Markus <mailto:[e-mail]>
> > Cc: mailto:[e-mail]
> > Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
> >
> > > On 16. Nov 2020, at 18:46, mailto:[e-mail] wrote:
> > >
> > >> -----Original Message-----
> > >> From: Michael Tuexen <mailto:[e-mail]>
> > >> Sent: Montag, 16. November 2020 17:51
> > >> To: Amend, Markus <mailto:[e-mail]>
> > >> Cc: mailto:[e-mail]
> > >> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
> > >>
> > >>> On 16. Nov 2020, at 17:21, mailto:[e-mail] wrote:
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Michael Tuexen <mailto:[e-mail]>
> > >>>> Sent: Montag, 16. November 2020 17:06
> > >>>> To: Amend, Markus <mailto:[e-mail]>
> > >>>> Cc: mailto:[e-mail]
> > >>>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
> > >>>>
> > >>>>> On 16. Nov 2020, at 16:43, mailto:[e-mail] wrote:
> > >>>>>
> > >>>>> Hi Michael,
> > >>>>>
> > >>>>> inline
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Michael Tuexen <mailto:[e-mail]>
> > >>>>>> Sent: Montag, 16. November 2020 15:38
> > >>>>>> To: Amend, Markus <mailto:[e-mail]>
> > >>>>>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
> > >>>>>>
> > >>>>>>> On 16. Nov 2020, at 13:52, mailto:[e-mail] 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%2023793-
> > >>>> 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/materials/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-03
> > >>>>>>>
> https://tools.ietf.org/html/draft-amend-tsvwg-multipath-framework-
> > >>>> 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-reordering-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
> > >>>>>
> > >>>
> > >
>