[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
- [tsvwg] Gunter Van de Velde's No Objection on dra… Gunter Van de Velde via Datatracker
- [tsvwg] Re: Gunter Van de Velde's No Objection on… Markus.Amend
- [tsvwg] Re: Gunter Van de Velde's No Objection on… Gunter van de Velde (Nokia)