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

[[e-mail]]

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

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

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