DCCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-tsvwg-multipath-dccp-20

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tsvwg-multipath-dccp-17. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are six actions which we must complete.

First, in the Feature Numbers registry in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

a single new registration will be made as follows:

Number: [ TBD-at-Registration ]
Description/Meaning: Multipath Capable
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 10 for this registration. Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Second, a new registry is to be created called the MP-DCCP Versions registry. The new registry will be located in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

The new registry is managed via Specification Required as defined by RFC8126. There is a single initial registration in the new registry as follows:

Version: 0
Value: 0000
Reference: [ RFC-to-be ]

Values 0001 through 1111 are unassigned.

Third, in the Option Types registry also in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

a single new registration will be made as follows:

Type: 46
Description/Meaning: Multipath Options
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the Multipath Options registry. The new registry will be located in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

The registry is managed via Specification Required as defined by RFC8126. The values in the new registry range from 0-255. There are initial registrations in the new registry as follows:

Multipath Option Name Description Reference
-----------------+-----+-----------+-----------
MP_OPT=0 MP_CONFIRM Confirm reception/processing of an MP_OPT option [ RFC-to-be; Section 3.2.1 ]
MP_OPT=1 MP_JOIN Join subflow to existing MP-DCCP connection [ RFC-to-be; Section 3.2.2 ]
MP_OPT=2 MP_FAST_CLOSE Close MP-DCCP connection [ RFC-to-be; Section 3.2.3 ]
MP_OPT=3 MP_KEY Exchange key material for MP_HMAC [ RFC-to-be; Section 3.2.4 ]
MP_OPT=4 MP_SEQ Multipath sequence number [ RFC-to-be; Section 3.2.5 ]
MP_OPT=5 MP_HMAC Hash-based message auth. code for MP-DCCP [ RFC-to-be; Section 3.2.6 ]
MP_OPT=6 MP_RTT Transmit RTT values and calculation parameters [ RFC-to-be; Section 3.2.7 ]
MP_OPT=7 MP_ADDADDR Advertise additional address(es)/port(s) [ RFC-to-be; Section 3.2.8 ]
MP_OPT=8 MP_REMOVEADDR Remove address(es)/ port(s) [ RFC-to-be; Section 3.2.9 ]
MP_OPT=9 MP_PRIO Change subflow priority [ RFC-to-be; Section 3.2.10 ]
MP_OPT=10 MP_CLOSE Close MP-DCCP subflow [ RFC-to-be; Section 3.2.11 ]
MP_OPT=11 MP_EXP Experimental suboption for private use [ RFC-to-be; Section 3.2.12 ]

Fifth, in the Reset Codes registry also in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

a single, new registration will be made as follows:

Reset Code: [ TBD-at-Registration ]
Name: Abrupt MP termination
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 13 for this Reset Code. Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Sixth, a new registry is to be created called the Multipath Key Type registry. The new registry will be located in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

The registry is managed via Specification Required as defined by RFC8126. The values in the new registry range from 0-255. There are three, initial registrations in the new registry as follows:

Type: 0
Name: Plain Text
Meaning: Plain text key
Reference: [ RFC-to-be; Section 3.2.4 ]

Type: 1
Name: ECDHE-C25519-SHA256
Meaning: ECDHE with SHA256 and Curve25519
Reference: [ RFC-to-be; Section 3.2.4 ]

Type: 2
Name: ECDHE-C25519-SHA512
Meaning: ECDHE with SHA512 and Curve25519
Reference: [ RFC-to-be; Section 3.2.4 ]

Values 3-255 in the new registry are unassigned.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-10-17):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tsvwg-multipath-dccp@ietf.org, gorry@erg.abdn.ac.uk, tsvwg-chairs@ietf.org, tsvwg@ietf.org, zahed.sarker.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DCCP Extensions for Multipath Operation with Multiple Addresses) to Proposed Standard


The IESG has received a request from the Transport and Services Working Group
WG (tsvwg) to consider the following document: - 'DCCP Extensions for
Multipath Operation with Multiple Addresses'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-10-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  DCCP communications as defined in RFC 4340 are restricted to a single
  path per connection, yet multiple paths often exist between peers.
  The simultaneous use of available multiple paths for a DCCP session
  could improve resource usage within the network and, thus, improve
  user experience through higher throughput and improved resilience to
  network failures.  Use cases for Multipath DCCP (MP-DCCP) are mobile
  devices (e.g., handsets, vehicles) and residential home gateways
  simultaneously connected to distinct networks as, e.g., a cellular
  and a Wireless Local Area (WLAN) network or a cellular and a fixed
  access network.  Compared to existing multipath protocols such as
  MPTCP, MP-DCCP offers special support for latency-sensitive services
  with different requirements for reliability and in-order delivery.

  This document specifies a set of extensions to DCCP to support
  multipath operations.  The protocol offers the same type of service
  to applications as DCCP and provides the components necessary to
  establish and use multiple DCCP flows across different paths
  simultaneously.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-multipath-dccp/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5025/
  https://datatracker.ietf.org/ipr/3639/

This is a shepherd report for: draft-ietf-tsvwg-multipath-dccp-16
DCCP Extensions for Multipath Operation with Multiple Addresses

Document History

    1. Was the document considered in any WG, and if so, why was it not adopted as a
    work item there?

DCCP is maintained by TSVWG.

    2. Was there controversy about particular points that caused the WG to not adopt
    the document?

There was discussion about whether the requirements as represented by
ATSSS from 3GPP would be addressed by this spec or by other means.  It
was not the responsibility of the IETF to decide on the different
technologies that might be used, and there was support for progressing
this specification as one alternative that could be realised.

    3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
    so, please summarize the areas of conflict in separate email messages to the
    responsible Area Director. (It should be in a separate email because this
    questionnaire is publicly available.)

No.

    4. For protocol documents, are there existing implementations of the contents of
    the document? Have a significant number of potential implementers indicated
    plans to implement? Are any existing implementations reported somewhere,
    either in the document itself (as RFC 7942 recommends) or elsewhere
    (where)?

There is one fork of the Linux tree that includes support for this
extension. This was demonstrated at IETF Hackathons and the results
reported to the TSVWG. See also: https://multipath-dccp.org/.

Additional Reviews

    5. Do the contents of this document closely interact with technologies in other
    IETF working groups or external organizations, and would it therefore benefit
    from their review? Have those reviews occurred? If yes, describe which
    reviews took place.

No. There is also multi-path work for MP-TCP and for MP-QUIC, but this
specification related to use with DCCP.

    6. Describe how the document meets any required formal expert review criteria,
    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There were no reviews.

    7. If the document contains a YANG module, has the final version of the module
    been checked with any of the recommended validation tools for syntax and
    formatting validation? If there are any resulting errors or warnings, what is
    the justification for not fixing them at this time? Does the YANG module
    comply with the Network Management Datastore Architecture (NMDA) as specified
    in RFC 8342?

There is no Yang module.

    8. Describe reviews and automated checks performed to validate sections of the
    final version of the document written in a formal language, such as XML code,
    BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks needed to be performed.

Document Shepherd Checks

    9. Based on the shepherd's review of the document, is it their opinion that this
    document is needed, clearly written, complete, correctly designed, and ready
    to be handed off to the responsible Area Director?

The document completed review within the WG included invited reviews and
WG feedback after which it was revised. There was a final WGLC in
02/2024, in which no significant changes were requested.  Rev 14 of this
document is now thought to be complete.

    10. Several IETF Areas have assembled lists of common issues that their
    reviewers encounter. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

    11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard,
    Informational, Experimental or Historic)? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document was originally charted as Experimental. However, once the
work had progressed there was a request to move this to PS. This case
was presented to the WG and was discussed. Finally a consensus call
confirmed that the WG wished to publish this as a PS in 07/2023.

    12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in BCP 79? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The current IPR disclosures were discussed by TSVWG. All authors have
declared that they are not aware of any undisclosed IPR.

    13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all authors have confirmed this.

    14. Document any remaining I-D nits in this document. Simply running the idnits
    tool is not enough; please review the "Content Guidelines" on
    authors.ietf.org. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is one unused Reference: 'I-D.muley-network-based-bonding-hybrid-access',
but no explicit reference was found in the text. This ID has expired and
as far as I know is not adopted by any IETF group. This could be removed
prior to publication if unused.

    15. Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

Checked.

    16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

    17. Are there any normative downward references (see RFC 3967 and BCP
    97) that are not already listed in the DOWNREF registry? If so,
    list them.

There is a DOWNREF.
This is a Normative reference to an Informational RFC: RFC 6234, SHA256 is used to generate a HMAC.
This RFC is listed in the DOWNREF registry.

    18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

    19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

    20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see RFC 8126).

The IANA considerations were reviewed by the Shepherd, and have been
reviewed by IANA. IANA is in the course of preparing a provisional
allocation of the codepoints based on this spec.

    21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

See above, IANA provisional allocation is in progress.

---

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

This is a shepherd report for: draft-ietf-tsvwg-multipath-dccp-16
DCCP Extensions for Multipath Operation with Multiple Addresses

Document History

    1. Was the document considered in any WG, and if so, why was it not adopted as a
    work item there?

DCCP is maintained by TSVWG.

    2. Was there controversy about particular points that caused the WG to not adopt
    the document?

There was discussion about whether the requirements as represented by
ATSSS from 3GPP would be addressed by this spec or by other means.  It
was not the responsibility of the IETF to decide on the different
technologies that might be used, and there was support for progressing
this specification as one alternative that could be realised.

    3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
    so, please summarize the areas of conflict in separate email messages to the
    responsible Area Director. (It should be in a separate email because this
    questionnaire is publicly available.)

No.

    4. For protocol documents, are there existing implementations of the contents of
    the document? Have a significant number of potential implementers indicated
    plans to implement? Are any existing implementations reported somewhere,
    either in the document itself (as RFC 7942 recommends) or elsewhere
    (where)?

There is one fork of the Linux tree that includes support for this
extension. This was demonstrated at IETF Hackathons and the results
reported to the TSVWG. See also: https://multipath-dccp.org/.

Additional Reviews

    5. Do the contents of this document closely interact with technologies in other
    IETF working groups or external organizations, and would it therefore benefit
    from their review? Have those reviews occurred? If yes, describe which
    reviews took place.

No. There is also multi-path work for MP-TCP and for MP-QUIC, but this
specification related to use with DCCP.

    6. Describe how the document meets any required formal expert review criteria,
    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There were no reviews.

    7. If the document contains a YANG module, has the final version of the module
    been checked with any of the recommended validation tools for syntax and
    formatting validation? If there are any resulting errors or warnings, what is
    the justification for not fixing them at this time? Does the YANG module
    comply with the Network Management Datastore Architecture (NMDA) as specified
    in RFC 8342?

There is no Yang module.

    8. Describe reviews and automated checks performed to validate sections of the
    final version of the document written in a formal language, such as XML code,
    BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks needed to be performed.

Document Shepherd Checks

    9. Based on the shepherd's review of the document, is it their opinion that this
    document is needed, clearly written, complete, correctly designed, and ready
    to be handed off to the responsible Area Director?

The document completed review within the WG included invited reviews and
WG feedback after which it was revised. There was a final WGLC in
02/2024, in which no significant changes were requested.  Rev 14 of this
document is now thought to be complete.

    10. Several IETF Areas have assembled lists of common issues that their
    reviewers encounter. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

    11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard,
    Informational, Experimental or Historic)? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document was originally charted as Experimental. However, once the
work had progressed there was a request to move this to PS. This case
was presented to the WG and was discussed. Finally a consensus call
confirmed that the WG wished to publish this as a PS in 07/2023.

    12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in BCP 79? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The current IPR disclosures were discussed by TSVWG. All authors have
declared that they are not aware of any undisclosed IPR.

    13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all authors have confirmed this.

    14. Document any remaining I-D nits in this document. Simply running the idnits
    tool is not enough; please review the "Content Guidelines" on
    authors.ietf.org. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is one unused Reference: 'I-D.muley-network-based-bonding-hybrid-access',
but no explicit reference was found in the text. This ID has expired and
as far as I know is not adopted by any IETF group. This could be removed
prior to publication if unused.

    15. Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

Checked.

    16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

    17. Are there any normative downward references (see RFC 3967 and BCP
    97) that are not already listed in the DOWNREF registry? If so,
    list them.

There is a DOWNREF.
This is a Normative reference to an Informational RFC: RFC 6234, SHA256 is used to generate a HMAC.
This RFC is listed in the DOWNREF registry.

    18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

    19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

    20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see RFC 8126).

The IANA considerations were reviewed by the Shepherd, and have been
reviewed by IANA. IANA is in the course of preparing a provisional
allocation of the codepoints based on this spec.

    21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

See above, IANA provisional allocation is in progress.

---

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

There was WG consensus to adopt as a PS (07/2023).
A WGLC in 02/2024 received reviews by:
Kevin Smith, read and ready
Franisco Fontes, read and ready
Hang,  read and ready
Chris Box, ready and review comments

There were no WGLC comments indicating that this document was not ready for publication.

This started a 2 week WG Last Call call to determine if the following TSVWG ID is ready to publish:

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-multipath-dccp/

This document targets PROPOSED STANDARD.

The document shepherd for the MP-DCCP will be: Gorry Fairhurst.

The WGLC will end at midnight UTC on 5th March 2024.

Request for posting confirmation emailed to previous authors: Andreas Kassler , Anna Brunstrom , Dirk Hugo , Markus Amend , Stephen Johnson , Veselin Rakocevic , tsvwg-chairs@ietf.org