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

[Martin Duke <[e-mail]>]

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 <[e-mail]> wrote:

> > -----Original Message-----
> > From: Michael Tuexen <[e-mail]>
> > Sent: Montag, 16. November 2020 19:40
> > To: Amend, Markus <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
> >
> > > On 16. Nov 2020, at 18:46, [e-mail] wrote:
> > >
> > >> -----Original Message-----
> > >> From: Michael Tuexen <[e-mail]>
> > >> Sent: Montag, 16. November 2020 17:51
> > >> To: Amend, Markus <[e-mail]>
> > >> Cc: [e-mail]
> > >> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
> > >>
> > >>> On 16. Nov 2020, at 17:21, [e-mail] wrote:
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Michael Tuexen <[e-mail]>
> > >>>> Sent: Montag, 16. November 2020 17:06
> > >>>> To: Amend, Markus <[e-mail]>
> > >>>> Cc: [e-mail]
> > >>>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
> > >>>>
> > >>>>> On 16. Nov 2020, at 16:43, [e-mail] wrote:
> > >>>>>
> > >>>>> Hi Michael,
> > >>>>>
> > >>>>> inline
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Michael Tuexen <[e-mail]>
> > >>>>>> Sent: Montag, 16. November 2020 15:38
> > >>>>>> To: Amend, Markus <[e-mail]>
> > >>>>>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
> > >>>>>>
> > >>>>>>> On 16. Nov 2020, at 13:52, [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://
> 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
> > >>>>>
> > >>>
> > >
>
>