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

[[e-mail]]

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

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