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

[[e-mail]]

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