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

[[e-mail]]

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

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