Transport and Services Working Group (tsvwg) Internet Drafts


      
 Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP
 
 draft-ietf-tsvwg-ecn-encap-guidelines-22.txt
 Date: 05/12/2023
 Authors: Bob Briscoe, John Kaippallimalil
 Working Group: Transport and Services Working Group (tsvwg)
The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking among IP layer and lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. This document is included in BCP 89 and updates the single paragraph of advice to subnetwork designers about ECN in Section 13 of RFC 3819, by replacing it with a reference to the whole of this document.
 Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
 
 draft-ietf-tsvwg-rfc6040update-shim-23.txt
 Date: 05/12/2023
 Authors: Bob Briscoe
 Working Group: Transport and Services Working Group (tsvwg)
RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols that use such shim header(s) and updates the specifications of those that do not mention ECN propagation (that is RFC 2661, RFC 3931, RFC 2784, RFC 4380 and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Teredo and AMT). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe.
 Transport Options for UDP
 
 draft-ietf-tsvwg-udp-options-32.txt
 Date: 21/03/2024
 Authors: Joseph Touch
 Working Group: Transport and Services Working Group (tsvwg)
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.
 A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
 
 draft-ietf-tsvwg-nqb-22.txt
 Date: 16/02/2024
 Authors: Greg White, Thomas Fossati, Ruediger Geib
 Working Group: Transport and Services Working Group (tsvwg)
This document specifies characteristics of a Non-Queue-Building Per- Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best- effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building microflows. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.]
 Operational Guidance on Coexistence with Classic ECN during L4S Deployment
 
 draft-ietf-tsvwg-l4sops-06.txt
 Date: 17/03/2024
 Authors: Greg White
 Working Group: Transport and Services Working Group (tsvwg)
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.
 Datagram Transport Layer Security (DTLS) over Stream Control Transmission Protocol (SCTP)
 
 draft-ietf-tsvwg-dtls-over-sctp-bis-07.txt
 Date: 23/10/2023
 Authors: Magnus Westerlund, John Mattsson, Claudio Porfiri
 Working Group: Transport and Services Working Group (tsvwg)
This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol to protect user messages sent over the Stream Control Transmission Protocol (SCTP). It is an improved alternative to the existing RFC 6083. DTLS over SCTP provides mutual authentication, confidentiality, integrity protection, and partial replay protection for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to give communications privacy and to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. This document is an improved alternative to RFC 6083 and removes the 16 kbytes limitation on protected user message size by defining a secure user message fragmentation so that multiple DTLS records can be used to protect a single user message. It further contains a large number of security fixes and improvements. It updates the DTLS versions and SCTP-AUTH HMAC algorithms to use. It mitigates reflection attacks of data and control chunks and replay attacks of data chunks. It simplifies secure implementation by some stricter requirements on the establishment procedures as well as rekeying to align with zero trust principles.
 DCCP Extensions for Multipath Operation with Multiple Addresses
 
 draft-ietf-tsvwg-multipath-dccp-14.txt
 Date: 16/03/2024
 Authors: Markus Amend, Anna Brunstrom, Andreas Kassler, Veselin Rakocevic, Stephen Johnson
 Working Group: Transport and Services Working Group (tsvwg)
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.
 Datagram PLPMTUD for UDP Options
 
 draft-ietf-tsvwg-udp-options-dplpmtud-11.txt
 Date: 04/01/2024
 Authors: Gorry Fairhurst, Tom Jones
 Working Group: Transport and Services Working Group (tsvwg)
This document specifies how a UDP Options sender implements Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPLPMTUD) as a robust method for Path Maximum Transmission Unit discovery. This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across the network path. It also provides a way to allow the application to periodically verify the current maximum packet size supported by a path and to update this when required.
 Zero Checksum for the Stream Control Transmission Protocol
 
 draft-ietf-tsvwg-sctp-zero-checksum-08.txt
 Date: 20/02/2024
 Authors: Michael Tuexen, Victor Boivie, Florent Castelli, Randell Jesup
 Working Group: Transport and Services Working Group (tsvwg)
The Stream Control Transmission Protocol (SCTP) uses a 32-bit checksum in the common header of each packet to provide some level of data integrity. If another method used by SCTP provides already the same or a higher level of data integrity, computing this checksum does not provide any additional protection, but does consume computing resources. This document provides a simple extension to SCTP allowing to save these computing resources by using zero as the checksum in a backwards compatible way. It also defines how this feature can be used when SCTP packets are encapsulated in Datagram Transport Layer Security (DTLS) packets.
 Convergence of Congestion Control from Retained State
 
 draft-ietf-tsvwg-careful-resume-07.txt
 Date: 16/02/2024
 Authors: Nicolas Kuhn, Stephan Emile, Gorry Fairhurst, Raffaello Secchi, Christian Huitema
 Working Group: Transport and Services Working Group (tsvwg)
This document specifies a cautious method for IETF transports that enables fast startup of congestion control for a wide range of connections. It reuses a set of computed congestion control parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are stored, allowing them to be later used to modify the congestion control behavior of a subsequent connection. It describes assumptions and defines requirements for how a sender utilizes these parameters to provide opportunities for a connection to more rapidly get up to speed and rapidly utilize available capacity. It discusses how use of the method impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate.
 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
 
 draft-ietf-tsvwg-rfc4895-bis-02.txt
 Date: 04/03/2024
 Authors: Michael Tuexen, Randall Stewart, Peter Lei, Hannes Tschofenig
 Working Group: Transport and Services Working Group (tsvwg)
This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. This document obsoletes RFC 4895.


data-group-menu-data-url="/group/groupmenu.json"> Skip to main content

Transport and Services Working Group (tsvwg)

WG Name Transport and Services Working Group
Acronym tsvwg
Area Web and Internet Transport (wit)
State Active
Charter charter-ietf-tsvwg-07 Approved
Status update Show Changed 2019-02-05
Document dependencies
Additional resources GitHub
Issue tracker
Wiki
Zulip Stream
Personnel Chairs Gorry Fairhurst, Marten Seemann
Area Director Zaheduzzaman Sarker
Mailing list Address tsvwg@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/tsvwg
Archive https://mailarchive.ietf.org/arch/browse/tsvwg/
Chat Room address https://zulip.ietf.org/#narrow/stream/tsvwg

Charter for Working Group

The Transport and Services Working Group (TSVWG) is the forum for development and publication of RFCs dealing with transport-layer topics that are not in scope of an existing working group or do not justify the formation of a new working group.

A non-exhaustive list of transport topics includes mechanisms that deal with packetization and reassembly, ports, maximum transmission unit discovery, reordering, congestion control, loss detection and recovery, queue management, explicit congestion notification, multihoming, stream multiplexing, and quality of service (including DSCP and RSVP). Transport-layer protocols include TCP, QUIC, SCTP, UDP, and DCCP. TSVWG maintains these protocols and mechanisms in the absence of a specialized working group.

The TSVWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones, with the approval of the responsible AD.

The currently active TSVWG work items mostly fall under the following topics:

(A) Maintenance and extension of the Stream Control Transmission Protocol
(SCTP), User Datagram Protocol (UDP), and Datagram Congestion Control Protocol (DCCP), as these do not have dedicated working groups.

(B) Explicit Congestion Notification (ECN), as the working group improves existing directives for tunnelling and observes the recently launched experiment with Low Latency, Low Loss, and Scalable Throughput (L4S).

(C) Maintenance of IP Differentiated Services (DiffServ) mechanisms, which involves mostly advisory documents on the use of DiffServ in specific application scenarios. Other work items related to DiffServ require Area Director approval.

Work in TSVWG must satisfy four conditions:
(1) WG consensus on the suitability and projected quality of the proposed work item.
(2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule.
(3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item.
(4) Agreement by the AD, who, depending on the scope of the proposed work item, may decide that an IESG review of adoption is needed first.

Milestones

Date Milestone Associated documents
Mar 2025 Submit "DTLS over SCTP" as a Proposed Standard RFC draft-ietf-tsvwg-dtls-over-sctp-bis
Dec 2024 Submit "User Ports for Experiments " for publication as a Proposed Standard RFC. draft-ietf-tsvwg-usr-exp
Nov 2024 Submit "Operational Guidance for Deployment of L4S in the Internet" as an Informational RFC draft-ietf-tsvwg-l4sops
Jul 2024 Submit "Careful convergence of congestion control from retained state" for publication as a Proposed Standard RFC. draft-ietf-tsvwg-careful-resume
Mar 2024 Submit " DCCP Extensions for Multipath Operation with Multiple Addresses" as a Proposed Standard RFC draft-ietf-tsvwg-multipath-dccp
Dec 2023 Submit "A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services" as a Proposed Standard RFC draft-ietf-tsvwg-nqb
Dec 2023 Submit " Transport Options for UDP" as a Proposed Standard RFC draft-ietf-tsvwg-udp-options
Dec 2023 Submit "Datagram PLPMTUD for UDP Options" for publication as a Proposed Standard RFC. draft-ietf-tsvwg-udp-options-dplpmtud

Done milestones

Date Milestone Associated documents
Done Submit 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' as a BCP RFC draft-ietf-tsvwg-ecn-encap-guidelines
Done Submit 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' as a Proposed Standard RFC draft-ietf-tsvwg-rfc6040update-shim

1 new milestone currently in Area Director review.