[tsvwg] Gunter Van de Velde's No Objection on draft-ietf-tsvwg-multipath-dccp-20: (with COMMENT)

Gunter Van de Velde via Datatracker <noreply@ietf.org> Fri, 21 February 2025 06:04 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from mail2.ietf.org (mail2.ietf.org [166.84.6.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 68830C151985; Thu, 20 Feb 2025 22:04:20 -0800 (PST)
Received: from mail.ietf.org (mail.ietf.org [50.223.129.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPSA id BEAB21CCAE0; Fri, 21 Feb 2025 06:04:19 +0000 (UTC)
Received: from [10.244.8.251] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id A5CB4C151985; Thu, 20 Feb 2025 22:04:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Gunter Van de Velde via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <174011785833.290.472190317172133008@dt-datatracker-7fdd5d767c-975l9>
Date: Thu, 20 Feb 2025 22:04:18 -0800
Message-ID-Hash: DVS3A6NNUSSQ6ZKYLZHIOLYX6NWXHL2R
X-Message-ID-Hash: DVS3A6NNUSSQ6ZKYLZHIOLYX6NWXHL2R
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-tsvwg-multipath-dccp@ietf.org, tsvwg-chairs@ietf.org, tsvwg@ietf.org, gorry@erg.abdn.ac.uk
X-Mailman-Version: 3.3.9rc6
Reply-To: Gunter Van de Velde <gunter.van_de_velde@nokia.com>
Subject: [tsvwg] Gunter Van de Velde's No Objection on draft-ietf-tsvwg-multipath-dccp-20: (with COMMENT)
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/RehaOo2cv_qx_J8uJ9i8-WyEdPw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

Gunter Van de Velde has entered the following ballot position for
draft-ietf-tsvwg-multipath-dccp-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-multipath-dccp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# 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