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

[[e-mail]]

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?
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
-  No real unreliable delivery is given. Even PR-SCTP requires a reliable "FORWARD-TSN" to become unreliable.
-  UDP encapsulation overhead

> 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