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

Thank you for addressing my discuss and comments.

# Internet AD comments for draft-ietf-tsvwg-multipath-dccp-20
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S1

* "between user user-equipment/residential" ->
  "between user-equipment/residential"

* The slides reference says "IETF 115" but the slides themselves say
  "IETF 105".

# Gunter Van de Velde, RTG AD, comments for draft-ietf-tsvwg-multipath-dccp-20

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tsvwg-multipath-dccp-20.txt

# I am not familiar with DCCP technology, hence my review comments are from a novice perspective. 

# for your convenience, please find some non-blocking COMMENTS

# comments
# ========

18	   DCCP communications as defined in RFC 4340 are restricted to a single

GV> Maybe expand DCCP at first usage to Datagram Congestion Control Protocol. I had to go look it up what it was

18	   DCCP communications as defined in RFC 4340 are restricted to a single
19	   path per connection, yet multiple paths often exist between peers.
20	   The simultaneous use of available multiple paths for a DCCP session
21	   could improve resource usage within the network and, thus, improve
22	   user experience through higher throughput and improved resilience to
23	   network failures.  Use cases for Multipath DCCP (MP-DCCP) are mobile
24	   devices (e.g., handsets, vehicles) and residential home gateways
25	   simultaneously connected to distinct networks as, e.g., a cellular
26	   and a Wireless Local Area (WLAN) network or a cellular and a fixed
27	   access network.  Compared to existing multipath protocols such as
28	   MPTCP, MP-DCCP offers special support for latency-sensitive services
29	   with different requirements for reliability and in-order delivery.
30
31	   This document specifies a set of extensions to DCCP to support
32	   multipath operations.  The protocol offers the same type of service
33	   to applications as DCCP and provides the components necessary to
34	   establish and use multiple DCCP flows across different paths
35	   simultaneously.

GV> May i sugegst the following from readability perspective

"
Datagram Congestion Control Protocol (DCCP) communications, as defined in RFC 4340, are inherently restricted to a single path per connection, despite the availability of multiple network paths between peers. The ability to utilize multiple paths simultaneously for a DCCP session can enhance network resource utilization, improve throughput, and increase resilience to network failures, ultimately enhancing the user experience.

Use cases for Multipath DCCP (MP-DCCP) include mobile devices (e.g., handsets, vehicles) and residential home gateways that maintain simultaneous connections to distinct network types, such as cellular and Wireless Local Area Networks (WLANs) or cellular and fixed access networks. Compared to existing multipath transport protocols, such as Multipath TCP (MPTCP), MP-DCCP is particularly suited for latency-sensitive applications with varying requirements for reliability and in-order delivery.

This document specifies a set of protocol extensions to DCCP that enable multipath operations. These extensions maintain the same service model as DCCP while introducing mechanisms to establish and utilize multiple concurrent DCCP flows across different network paths.
"

192	   This document uses terms that are either specific for multipath
193	   transport or are defined in the context of MP-DCCP, similar to
194	   [RFC8684], as follows:

GV> I suspect that the used terminology is not similar, but identical? maybe clarify that and explicitly call out a difference when needed

368	    +========+===================+============+===============+=======+
369	    | Number | Meaning           | Rec'n Rule | Initial Value | Req'd |
370	    +========+===================+============+===============+=======+
371	    |   10   | Multipath Capable |     SP     |       0       |   N   |
372	    +--------+-------------------+------------+---------------+-------+

374	                         Table 1: Multipath feature

376	   Rec'n Rule:  The reconciliation rule used for the feature.  SP
377	      indicates the server-priority.

GV> What is a "Rec'n Rule"? I guess i am missing something obvious

399	      Note to the RFC Editor: Please update the Number and Type with the
400	      value assigned by IANA.

GV> It would help to call out explicitly which value to update

Gunter Van de Velde
RTG Area Director

Section 6, paragraph 0
>    The approach described above has been implemented in open source
>    across different testbeds and a new scheduling algorithm has been
>    extensively tested.  Also demonstrations of a laboratory setup have
>    been executed and have been published at [multipath-dccp.org].

Much like Gunter, I do not have much experience with DCCP. This review will therefore look at this protocol from a manageability perspective. For details on how to evaluate a protocol from manageability perspective, please refer to RFC 5706. In particular, I am referring to Section 1.2 and 3.
Those sections suggest that implementations start by identifying the entities that need to be managed, both from a configuration and monitoring perspective. In this particular case, that would include both endpoints and middleboxes. Has that evaluation been done?

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "traditionally"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"
 * Term "blind"; alternatives might be "visually impaired", "unmindful of",
   "unconcerned about", "negligent of", "unaware", "uncomprehending",
   "unaware", "uncritical", "unthinking", "hasty", "blocked", "opaque"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 1
> ling and setting up multiple paths (a.k.a, "subflows"), managing these subflo
>                                     ^^^^^
The abbreviation/initialism is missing a period after the last letter.

Section 2.1, paragraph 5
>  specifics of the implementation. If a MP-DCCP peer host wishes to limit the
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.1, paragraph 7
> he MP-DCCP connection MUST either fallback to regular DCCP or MUST close the
>                                   ^^^^^^^^
The word "fallback" is a noun. The verb is spelled with a space.

Section 3.1, paragraph 10
> escribed in Table 3. MP_OPT refers to an Multipath option. +======+========+=
>                                       ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 3.2, paragraph 5
> that are identified as outdated. Similarly an MP_CONFIRM could arrive out of
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Similarly".

Section 3.2.2, paragraph 4
> protect from unauthorized shutdown of a MP-DCCP connection, the selected Key 
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.3, paragraph 10
> ]. The MP_SEQ number space is independent from the path individual sequence n
>                               ^^^^^^^^^^^^^^^^
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

Section 3.2.3, paragraph 18
> = HMAC-SHA256(Key=d-keyB, Msg=RB+RA) An usage example is shown in Figure 21.
>                                      ^^
Use "A" instead of "An" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 3.2.5, paragraph 2
> ADDADDR or MP_REMOVEADDR. Therefore, a MP_HMAC MUST directly follow its asso
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.5, paragraph 2
> ption. In the likely case of sending a MP_JOIN together with a MP_ADDADDR, t
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.5, paragraph 2
> se of sending a MP_JOIN together with a MP_ADDADDR, this results in concatena
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.8, paragraph 9
> long with the MP_REMOVEADDR suboption a MP_HMAC option MUST be sent for authe
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.8, paragraph 10
>  the option. A receiver MUST include a MP_SEQ (Section 3.2.5) in a DCCP data
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.8, paragraph 17
> ts for using different paths (e.g., WiFi is free while cellular has limit on
>                                     ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Section 3.2.9, paragraph 4
> if more capacity is needed than the WiFi path can provide, indicating a clea
>                                     ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Section 3.2.9, paragraph 5
> ion. At least one path ought to have a MP_PRIO value greater or equal to one
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.9, paragraph 9
> up to the multipath scheduler logic. A MP_SEQ (Section 3.2.5) MUST be presen
>                                      ^
Use "An" instead of "A" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.10, paragraph 1
> n of the first DCCP-CloseReq carrying a MP_CLOSE with valid Key Data, or due 
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.10, paragraph 3
> tion of the first DCCP-Close carrying a MP_CLOSE with valid Key Data at the p
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.10, paragraph 6
> MP_JOIN MUST be ignored. Contrary to a MP_FAST_CLOSE (Section 3.2.3), no sin
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.10, paragraph 14
> ique identifier during the lifetime of a MP-DCCP connection. * Host B sends a
>                                        ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.4.1, paragraph 5
> tablished and the handshake SHOULD fallback to regular DCCP. If this is not p
>                                    ^^^^^^^^
The word "fallback" is a noun. The verb is spelled with a space.

Section 3.4.1, paragraph 9
> blishment, MP-DCCP connection will fallback to regular DCCP. The fallback pro
>                                    ^^^^^^^^
The word "fallback" is a noun. The verb is spelled with a space.

Section 3.5, paragraph 4
> e 24: Most common state transitions of a MP-DCCP subflow 3.8. Congestion Cont
>                                        ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.6, paragraph 5
>  of the multiple DCCP subflows within a MP-DCCP connection for data transmiss
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.7, paragraph 1
> livery. Some of the DCCP subflows of a MP-DCCP connection might become inact
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.8, paragraph 1
> hat the new address to be included in a MP connection is valid for a peer to 
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.11, paragraph 1
> m Packet Size (MPS) is maintained for a MP-DCCP connection. If MP-DCCP expos
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.11.1, paragraph 2
> orithm has been extensively tested. Also demonstrations of a laboratory setup
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Also".

Section 5, paragraph 1
> cy (Section 4.6 of [RFC8126]). In addition IANA is requested to assign a new 
>                                   ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

Section 5, paragraph 1
> ined in section Section 3.2.3. In addition IANA is requested to assign for th
>                                   ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

Section 8, paragraph 17
> ed byte-stream. DCCP behaves in a different way and does not guarantee to del
>                              ^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "differently" to avoid
wordiness.

Thanks for Russ Housley for the ARTART review.
And to the authors for addressing his comments.

# Éric Vyncke, INT AD, comments for draft-ietf-tsvwg-multipath-dccp-20
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Gorry Fairhurst for the shepherd's write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## COMMENTS (non-blocking)

### Section 1

What is a middle box in `to pass middleboxes`? Please add a reference as "middlebox" covers a wide range of devices/roles. Section 5 is better on this topic.

### Section 1.2

Please use RFC 5952 when writing IPv6 addresses.

### Section 3.2

Suggest appending "TLV" to all sub-sections title.

I was about to DISCUSS on the lack of behavior specification for a node receiving an unknown MP_OPT value, is it ignored or does it break the whole set-up ?

### Section 3.2.6

Even if this document only specifies SHA-256 for HMAC, it is not fully clear (albeit guessing a new code for MP_OPT in the registry) how to add another HMAC later.

### Section 3.2.8

Even if probably obvious, what is the expected receiver behavior in the absence of the MP_HMAC ?

Should there be a requirement that the addresses are unicast ? (assuming that link-local, ULA, RFC 1918, global are accepted by default).

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

Thanks for dealing with my DISCUSS position.  My original comments, which may or may not still be applicable:

Many SHOULD [NOT]s in this document would benefit from either conversion to MUST [NOT]s, or some explanation of under what circumstances an implementer/operator might legitimately decide to deviate from the advice presented.

I think Section 8 should be broken into subsections, one subsection per major IANA request.  It's otherwise a bit unclear where one action ends and another begins.

Other than supporting Deb's position, I have nothing useful to add.