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

[[e-mail]]

> -----Original Message-----
> From: Michael Tuexen <[e-mail]>
> Sent: Dienstag, 17. November 2020 12:36
> To: Amend, Markus <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [tsvwg] MP-DCCP for UDP multipath transport
> 
> > 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.

You are right for this small piece of DCCP SYN packet, but all following communication is overhead free.

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

OK, I forgot to mention that this has to be a prerequisite (maybe only a solution for controlled environments), otherwise it requires handshaking.

> > 4. Handshaking procedure for DCPP-UDP header conversion
> Is that still zero overhead?

Not in terms of handshaking, but afterwards then, similar to 5.

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

Probably

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