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

[Michael Tuexen <[e-mail]>]

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

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