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

[Michael Tuexen <[e-mail]>]

> On 17. Nov 2020, at 12:04, [e-mail] wrote:
> 
>> -----Original Message-----
>> From: Michael Tuexen <[e-mail]>
>> Sent: Dienstag, 17. November 2020 11:01
>> To: Amend, Markus <[e-mail]>
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
>> 
>>> 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?
> 
> Possible solutions for further discussion:
> 
> 1. In controlled environments, there is nothing which prevents implementers to use other ports than specified.
Sure.
> 2. Fix dst.port for UDP (IANA) and original DCCP dst.port has to be transmitted in the DCCP handshake.
Then it will not be zero overhead.
> 3. Client/Server have to select for each DCCP port an equivalent UDP port and map internally
How does the client knows how the server is doing an internal mapping?
> 4. Handshaking procedure for DCPP-UDP header conversion
Is that still zero overhead?
> 5. Use DCCP-UDP negotiation procedure to signal support for DCCP-UDP header conversion. If not supported keep encapsulation...
So you have zero overhead after the handshake. But you have 4 port numbers during the handshake, under
which constraints can you reduce to two. I guess these would be the UDP port numbers...

Best regards
Michael
> 
> 
>> 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
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>> 
>