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

[Michael Tuexen <[e-mail]>]

> On 17. Nov 2020, at 10:40, [e-mail] wrote:
> 
>> -----Original Message-----
>> From: Michael Tuexen <[e-mail]>
>> Sent: Dienstag, 17. November 2020 10:32
>> To: Amend, Markus <[e-mail]>
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
>> 
>>> On 17. Nov 2020, at 09:41, [e-mail] wrote:
>>> 
>>> Hi Martin,
>>> 
>>> My clear motivation was and is the encapsulation use case, however I'm happy
>> to learn about different views from others. The overhead free DCCP-UDP header
>> conversion may inspire people to use in future DCCP in their applications directly,
>> since middle-box issues are prevented - but probably that is a weak assumption
>> under the knowledge that RFC6773 (DCCP-UDP) exists.
>> I have a question related to the U-DCCP format: What is the src/dst port
>> numbers? I guess they are from the UDP
>> space port number space. But in the DCCP header they are from the DCCP port
>> number space. From which port
>> number space are they taken?
>> 
> 
> That's still open and not clarified yet. I remember a comment from Dave when I presented the draft for the first time which went in a similar direction.
> 
> I see two possibilities here:
> 
> 1. Takeover the ones from the original DCCP communication with the risk to interfere with the UDP port space. So probably a showstopper here.
> 
> 2. To specify a distinct (IANA) (src/)dst port
If you use an IANA reserved UDP port number for DCCP/UDP encapsulation, you can have only one such
endpoint on a host. So how would you support multiple DCCP endpoints using this feature?
This looks like the UDP encapsulation specified in RFC 6951 for SCTP. However, in this solution
UDP and SCTP port numbers both exist...

Best regards
Michael
> 
>> Best regards
>> Michael
>>> 
>>> In respect to adoption - and sorry here, I had not read your original mail clearly
>> to the end - the question of use cases is really something we should consider.
>>> 
>>> What would be your conclusion if it turns out, that tunneling is the only/main
>> use case? Specifying  DCCP encapsulation (protocol) separately or within the MP-
>> DCCP?
>>> 
>>> Br
>>> 
>>> Markus
>>> 
>>> From: Martin Duke <[e-mail]>
>>> Sent: Dienstag, 17. November 2020 09:24
>>> To: Amend, Markus <[e-mail]>
>>> Cc: Michael Tuexen <[e-mail]>; tsvwg
>> <[e-mail]>
>>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
>>> 
>>> Hi Markus,
>>> 
>>> My separability question is not whether it's technically possible (I'm convinced it
>> is); it's whether excluding the encapsulation part leaves us with a use case that's
>> actually worth working on.
>>> 
>>> On Tue, Nov 17, 2020 at 12:07 AM <mailto:[e-mail]>
>> wrote:
>>> Hi Martin,
>>> 
>>> Good point to raise MASQUE's chartered focus on CC in CC. Discussing the MP-
>> DCCP encapsulation framework makes this challenge even stronger and I'm
>> happy to support any attempt to bring this jointly to ICCRG.
>>> 
>>> From a separation point of view I have no doubt that we can clearly distinguish
>> the MP extension of DCCP from the encapsulation/tunneling stuff. That's already
>> the way how we applied the drafts.
>>> 
>>> https://tools.ietf.org/html/draft-amend-tsvwg-multipath-dccp only takes care
>> to specify the DCCP extension
>>> 
>>> while https://tools.ietf.org/html/draft-amend-tsvwg-multipath-framework-
>> mpdccp is intended to be informational and give guidance towards multipath
>> support of non-DCCP traffic using tunneling/encapsulation.
>>> 
>>> Br
>>> 
>>> Markus
>>> 
>>> From: Martin Duke <mailto:[e-mail]>
>>> Sent: Dienstag, 17. November 2020 01:46
>>> To: Amend, Markus <mailto:[e-mail]>
>>> Cc: mailto:[e-mail]; mailto:[e-mail]
>>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
>>> 
>>> Hi Markus,
>>> 
>>> I should note that MASQUE is specifically chartered to provide
>> recommendations for cc-in-cc without designing a new protocol or starting any
>> research projects. The draft probably ought to say *something.*
>>> 
>>> Header conversion and multipath seem uncontroversial to me, but
>> encapsulation may raise some concerns. Can you tell me how separable the
>> drafts are? Would there be any point in adopting two of them, or is encapsulation
>> the use case that drives all the interest in these changes?
>>> 
>>> On Mon, Nov 16, 2020 at 11:04 AM
>> <mailto:mailto:[e-mail]> wrote:
>>>> -----Original Message-----
>>>> From: Michael Tuexen <mailto:mailto:[e-mail]>
>>>> Sent: Montag, 16. November 2020 19:40
>>>> To: Amend, Markus <mailto:mailto:[e-mail]>
>>>> Cc: mailto:mailto:[e-mail]
>>>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
>>>> 
>>>>> On 16. Nov 2020, at 18:46, mailto:mailto:[e-mail] wrote:
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Michael Tuexen <mailto:mailto:[e-mail]>
>>>>>> Sent: Montag, 16. November 2020 17:51
>>>>>> To: Amend, Markus <mailto:mailto:[e-mail]>
>>>>>> Cc: mailto:mailto:[e-mail]
>>>>>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
>>>>>> 
>>>>>>> On 16. Nov 2020, at 17:21, mailto:mailto:[e-mail]
>> wrote:
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Michael Tuexen
>> <mailto:mailto:[e-mail]>
>>>>>>>> Sent: Montag, 16. November 2020 17:06
>>>>>>>> To: Amend, Markus <mailto:mailto:[e-mail]>
>>>>>>>> Cc: mailto:mailto:[e-mail]
>>>>>>>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
>>>>>>>> 
>>>>>>>>> On 16. Nov 2020, at 16:43, mailto:mailto:[e-mail]
>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Michael,
>>>>>>>>> 
>>>>>>>>> inline
>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Michael Tuexen
>> <mailto:mailto:[e-mail]>
>>>>>>>>>> Sent: Montag, 16. November 2020 15:38
>>>>>>>>>> To: Amend, Markus <mailto:mailto:[e-mail]>
>>>>>>>>>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
>>>>>>>>>> 
>>>>>>>>>>> On 16. Nov 2020, at 13:52,
>> mailto:mailto:[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://http://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
>>>>>>>>> 
>>>>>>> 
>>>>> 
>