I-D list for Transport and Services Working Group RSS FeedDocument changesurn:uuid:4caf98ca-82cf-53b8-87b8-d4d949fcf2772024-03-29T07:42:01-0700Transport Options for UDP9831732024-03-25T07:58:51-07002024-03-25T07:58:51-0700Gorry FairhurstThis starts a 3 week WG Last Call call to determine if the following TSVWG IDs are ready to publish:<br><br><br>https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/<br><br>https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options-dplpmtud/<br><br>These documents target PROPOSED STANDARD.<br><br>The document shepherd for the UDP Options will be: Gorry Fairhurst.<br><br>The document shepherd for DPLPMTUD with UDP Options will be: Marten Seemann.<br><br>The WGLC will end at midnight UTC on 10th April 2024. <br><br>Please do read the drafts, and send any comments/concerns to the TSVWG mailing list, including notes on whether these are ready to publish (or send an email directly to the chairs <tsvwg-chairs@ietf.org>).<br><br>Best wishes,<br><br>Gorry and Marten<br><br>(tsvwg co-chairs)<br><br>—<br><br>The IETF WG Last Call process is described in RFC 6174.added_commentietftsvwgGorry Fairhurstactiveidexistswg-lcTransport Options for UDP9831722024-03-25T07:58:51-07002024-03-25T07:58:51-0700Gorry FairhurstIETF WG state changed to <b>In WG Last Call</b> from WG Documentchanged_stateietftsvwgGorry Fairhurstactiveidexistswg-lcDatagram PLPMTUD for UDP Options9831712024-03-25T07:58:48-07002024-03-25T07:58:48-0700Gorry FairhurstThis starts a 3 week WG Last Call call to determine if the following TSVWG IDs are ready to publish:<br><br>https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/<br><br>https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options-dplpmtud/<br><br>These documents target PROPOSED STANDARD.<br><br>The document shepherd for the UDP Options will be: Gorry Fairhurst.<br><br>The document shepherd for DPLPMTUD with UDP Options will be: Marten Seemann.<br><br>The WGLC will end at midnight UTC on 9th April 2024. <br><br>Please do read the drafts, and send any comments/concerns to the TSVWG mailing list, including notes on whether these are ready to publish (or send an email directly to the chairs <tsvwg-chairs@ietf.org>).<br><br>Best wishes,<br><br>Gorry and Marten<br><br>(tsvwg co-chairs)<br><br>—<br><br>The IETF WG Last Call process is described in RFC 6174.added_commentietftsvwgMarten Seemannactiveidexistswg-lcDatagram PLPMTUD for UDP Options9831702024-03-25T07:58:47-07002024-03-25T07:58:47-0700Gorry FairhurstIETF WG state changed to <b>In WG Last Call</b> from WG Documentchanged_stateietftsvwgMarten Seemannactiveidexistswg-lcTransport Options for UDP9829312024-03-21T21:18:13-07002024-03-21T21:18:13-0700Joseph TouchNew version available: <b>draft-ietf-tsvwg-udp-options-32.txt</b>new_revisionietftsvwgGorry Fairhurstactiveidexistswg-lc Transport protocols are extended through the use of transport header
options. This document updates RFC 768 (UDP) by indicating the
location, syntax, and semantics for UDP transport layer options
within the surplus area after the end of the UDP user data but
before the end of the IP length.
32Transport Options for UDP9829302024-03-21T21:18:13-07002024-03-21T21:18:13-0700Joseph TouchNew version accepted (logged-in submitter: Joseph Touch)new_submissionietftsvwgGorry Fairhurstactiveidexistswg-lcTransport Options for UDP9829292024-03-21T21:18:13-07002024-03-21T21:18:13-0700Joseph TouchUploaded new revisionnew_submissionietftsvwgGorry Fairhurstactiveidexistswg-lcZero Checksum for the Stream Control Transmission Protocol9821642024-03-20T01:04:38-07002024-03-20T01:04:38-0700Liz FlynnShepherding AD changed to Zaheduzzaman Sarkeradded_commentietftsvwgMarten SeemannZaheduzzaman Sarkeractivead-evalsub-pubDCCP Extensions for Multipath Operation with Multiple Addresses9806002024-03-18T00:06:06-07002024-03-18T00:06:06-0700Gorry FairhurstTag Revised I-D Needed - Issue raised by WGLC cleared.changed_documentietftsvwgGorry Fairhurstactiveidexistschair-wOperational Guidance on Coexistence with Classic ECN during L4S Deployment9803762024-03-17T21:09:37-07002024-03-17T21:09:37-0700Greg WhiteNew version available: <b>draft-ietf-tsvwg-l4sops-06.txt</b>new_revisionietftsvwgWesley Eddyactiveidexistswg-doc This document is intended to provide guidance in order to ensure
successful deployment of Low Latency Low Loss Scalable throughput
(L4S) in the Internet. Other L4S documents provide guidance for
running an L4S experiment, but this document is focused solely on
potential interactions between L4S flows and flows using the original
('Classic') ECN over a Classic ECN bottleneck link. The document
discusses the potential outcomes of these interactions, describes
mechanisms to detect the presence of Classic ECN bottlenecks, and
identifies opportunities to prevent and/or detect and resolve
fairness problems in such networks. This guidance is aimed at
operators of end-systems, operators of networks, and researchers.
06Operational Guidance on Coexistence with Classic ECN during L4S Deployment9803752024-03-17T21:09:37-07002024-03-17T21:09:37-0700Greg WhiteNew version accepted (logged-in submitter: Greg White)new_submissionietftsvwgWesley Eddyactiveidexistswg-docOperational Guidance on Coexistence with Classic ECN during L4S Deployment9803742024-03-17T21:09:36-07002024-03-17T21:09:36-0700Greg WhiteUploaded new revisionnew_submissionietftsvwgWesley Eddyactiveidexistswg-docHost to Network Signaling Use Cases for Collaborative Traffic Differentiation9799322024-03-17T05:16:30-07002024-03-17T05:16:30-0700Sridharan RajagopalanNew version available: <b>draft-rwbr-tsvwg-signaling-use-cases-02.txt</b>new_revisionnoneactiveidexists Host-to-network (and vice versa) signaling can improve the user
experience by informing the network which flows are more important
and which packets within a flow are more important without having to
disclose the content of the packets being delivered. The
differentiated service may be provided at the network (e.g., packet
discard preference), the sender (e.g., adaptive transmission or
session migration), or through cooperation of both the host and the
network.
This document lists use cases demonstrating the need for a mechanism
to share metadata about flows between a receiving host and its
networks to enable differentiated traffic treatment for packets sent
to the host. Such a mechanism is typically implemented using a
signaling protocol between the host and a set of network elements.
02Host to Network Signaling Use Cases for Collaborative Traffic Differentiation9799312024-03-17T05:16:30-07002024-03-17T05:16:30-0700Mohamed BoucadairNew version approvednew_submissionnoneactiveidexistsHost to Network Signaling Use Cases for Collaborative Traffic Differentiation9799292024-03-17T05:15:45-07002024-03-17T05:15:45-0700(System)Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" <kondtir@gmail.com>, Dan Wing <danwing@gmail.com>, Mohamed Boucadair <mohamed.boucadair@orange.com>, Sridharan Rajagopalan <sridharan.girish@gmail.com>new_submissionnoneactiveidexistsHost to Network Signaling Use Cases for Collaborative Traffic Differentiation9799282024-03-17T05:15:40-07002024-03-17T05:15:40-0700Sridharan RajagopalanUploaded new revisionnew_submissionnoneactiveidexistsDCCP Extensions for Multipath Operation with Multiple Addresses9794642024-03-16T09:21:40-07002024-03-16T09:21:40-0700Markus AmendNew version available: <b>draft-ietf-tsvwg-multipath-dccp-14.txt</b>new_revisionietftsvwgGorry Fairhurstactiveidexistschair-w DCCP communications as defined in [RFC4340] 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 the existing multipath
protocols, such as MPTCP, MP-DCCP provides specific support for non-
TCP user traffic (e.g., UDP or plain IP).
This document specifies a set of extensions to DCCP to support
multipath operations. Multipath DCCP provides the ability to
simultaneously use multiple paths between peers. 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.
14DCCP Extensions for Multipath Operation with Multiple Addresses9794632024-03-16T09:21:39-07002024-03-16T09:21:39-0700(System)New version approvednew_submissionietftsvwgGorry Fairhurstactiveidexistschair-wDCCP Extensions for Multipath Operation with Multiple Addresses9794622024-03-16T09:20:10-07002024-03-16T09:20:10-0700(System)Request for posting confirmation emailed to previous authors: Andreas Kassler <andreas.kassler@kau.se>, Anna Brunstrom <anna.brunstrom@kau.se>, Markus Amend <markus.amend@telekom.de>, Stephen Johnson <stephen.h.johnson@bt.com>, Veselin Rakocevic <veselin.rakocevic.1@city.ac.uk>, tsvwg-chairs@ietf.orgnew_submissionietftsvwgGorry Fairhurstactiveidexistschair-wDCCP Extensions for Multipath Operation with Multiple Addresses9794612024-03-16T09:20:10-07002024-03-16T09:20:10-0700Markus AmendUploaded new revisionnew_submissionietftsvwgGorry Fairhurstactiveidexistschair-w