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

[Michael Tuexen <[e-mail]>]

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

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