| Internet-Draft | DUG-for-DetNet | October 2024 |
| Robitzsch & LM Contreras | Expires 24 April 2025 | [Page] |
This document provides the description of an Internet Protocol (IP) Version 6 (IPv6) extension header allowing DetNet routers to determine the relative importance between packets of the same flow, which enables gracefully dropping packets in case of congestion. This behaviour can for example be useful for media flows, where different application units can have very different impact on the quality of experience of the user. This document aims primarily at extending the DetNet IP Data Plane in an initial revision of this draft, and may be extended to Multi-Protocol Label Switching (MPLS) and MPLS over User Datagram Protocol (UDP)/IP data plane options in future revisions.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
AR Augmented Reality¶
ADU Application Data Unit¶
DUG Data Unit Group¶
IP Internet Protocol¶
IPv6 Internet Protocol Version 6¶
MPLS Multi-Protocol Label Switching¶
MTU Maximum Transmission Unit¶
QoE Quality of Experience¶
TLS Transport Layer Security¶
TLV Type Length Values¶
UDP User Datagram Protocol¶
VR Virtual Reality¶
XR eXtended Reality¶
Applications often send data which does not fit as payload into a single IP packet. As a result, a single Application Data Unit (ADU) is fragmented into smaller chunks with a maximum length of each chuck determined by the underlying computer network and its Maximum Transmission Unit (MTU). The set of packets that carry the entirety of a single ADU are hereby defined as a Data Unit Group (DUG). For high-throughput, low-latency applications such as Augmented Reality (AR) or Virtual Reality (VR) media applications, collectively called eXtended Reality (XR) applications, this can lead to situations where a single packet loss can lead to the loss of the whole ADU for the application. The same applies for closed-loop automation digital twinning applications that require a wide range of monitoring data of the real world to create the digital twin for on-demand decision making.¶
Since some ADUs are more important than others for the Quality of Experience (QoE) for the application user or the accurate performance of a digital twin, it can be useful for the network to be aware of the difference of importance between the ADUs, to be able to down-prioritise (or even drop) the least important packets in case of congestion.¶
Techniques have been developed in 5G (in 3GPP Release 18, [_3GPP-23.501]), to convey "XR metadata", including importance within the flow, associated with a "PDU Set" (i.e., set of packets transporting an ADU) to the network. The sending application determines the metadata and associates it with ADUs (e.g., within individual packets). The network uses the importance of packets to determine which packets to drop in case of congestion.¶
Within this document, the group of packets that transport a single ADU is designated as a "Data Unit Group" (DUG). The purpose of this document is to define a mechanism for conveying importance (within the flow) and related metadata of DUGs to DetNet routers, to make it available for enhanced queuing, shaping, scheduling, and pre-emption decisions.¶
This document aims primarily at extending the DetNet IP Data Plane [RFC8939] in an initial revision of this draft, and may be extended to Multi-Protocol Label Switching (MPLS) [RFC8964] and MPLS over User Datagram Protocol (UDP)/IP [RFC9566] data plane options in future revisions.¶
This document proposes the introduction of DUG as an extension to the IPv6 header. In order to comply with this requirement and to follow the guidelines on how to design IPv6 header extensions [RFC6564], [RFC8200], i.e., using Type Length Values (TLVs), a new IPv6 TLV is defined.¶
As the order of extension headers are fixed in IPv6, the DUG-related information is added to an appropriate IPv6 header option. The main purpose of the proposed DUG TLVs is for intermediate node to read the values and perform any DetNet queuing, shaping, scheduling, ordering or even dropping over them. Thus, the "Hop-by-Hop" options header is identified as the most appropriate one, as intermediate nodes shall process the DUG-related information.¶
The IPv6 header option is illustrated in Figure 1 and is a sequence in form of an unsigned integer number indicating the order of packets within a Data Unit Group. With each new packet, the sequence number is iterated by 1.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | DUG ID | Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| I |C|S|E| +-+-+-+-+-+-+-+-+
The set of values describe the DUG as follows:¶
DUG ID: an unsigned integer number identifying the DUG. The DUG ID of each new DUG is increased by 1 by the sender.¶
Sequence: an unsigned integer number indicating the order of packets within a DUG, starting from 0 and increased by 1 for each packet in the DUG.¶
D: This bit indicates the end of the DUG.¶
I: These four bits indicate the importance of this packet against other packets in the same DUG. Lower values indicate a higher importance and allow to prioritise packets in different DUGs. Importance may be derived from the application type or the sensitivity of applications when not receiving a DUG in their application.¶
C: A 1-bit field to indicate higher layer control plane packets. When reliable transport protocols are in use, e.g., TCP, or upper-layer control procedures take place, e.g., establishment of a TLS session, there is no ADU exchanged. However, these control packets are equally important to the delivery of an ADU and depending on their functionality in the communication sometime even more important than the ADU itself. This bit allows to tag these packets.¶
S: This 1-bit field indicates the start of a burst of packets within a DUG.¶
E: This 1-bit field indicates the end of a burst of packets within a DUG.¶
Additional padding may be needed to make the hop-by-hop options header a multiple of 8 bytes long.¶
A router can use DUG metadata to process packets belonging to the same traffic flow. For illustration, examples of such processing operations may include:¶
For increased reliability, DetNet routers may use one or more DUG header options to apply frame replication or different queuing techniques. For instance, the C or I flag can indicate higher importance of a packet or set of packets within the DUG, e.g., the establishment of a Transport Layer Security (TLS) session before the actual ADU is sent.¶
In case of congestion where some packets need to be dropped, the importance can be used to determine which packets to drop. This can include a subset of the entire DUG, identified by their DUG ID, within a DetNet flow.¶
Scheduling operations can use importance or other DUG metadata to determine which packet to send on which link. For example, the scheduler may forward packets on the same link used for other packets of the same DUG, to provide a consistent treatment. In another example, packets of higher importance may be forwarded over higher quality links.¶
The DUG concept described in this document is currently being implemented and validated in the SNS project PREDICT-6G [P6G], using temporary experimental values for the DUG sequence option and the DUG flag option¶
The DUG-enabled router implementation utilises Express Data Paths (XDP) hooks provided by the extended Berkley Filters (eBPF) implementation in the Linux kernel [eBPF]. The XDP hook implements the parsing of the IPv6 header and the DUG options as well as extended logging to feed packet treatment behaviours to the monitoring repository of a Digital Twin. Furthermore, the XDP hook implements a fixed cycle time to judge all arriving packets against and over which basic queuing and drop mechanisms can be applied.¶
Before testing the implementation, it was verified that the XDP hook has no negative impact on the actual networking performance of Linux. As reported in Section 2.2.7 in [P6G-D4.2], the hook without any packet treatment (only parsing an IPv6 header and with logging implemented) had no impact on neither UDP nor TCP measurements using iperf and plain IPv6 traffic.¶
To stress test the XDP hook and to provide measurement data to the Digital Twin to predict the impact on packet latency and jitter when admitting a new DetNet flow, a testbed of four nodes was created, as illustrated in Figure 2. Two clients are connected to a forwarder, which is then connected to a Server. All links operate at 1G and are dedicated PCIe network interface cards. The forwarder is equipped with three network interface cards.¶
To create congestion on the forwarder-to-server link, both clients (Client 1 and Client 2) send iperf-generated IPv6 traffic to the server. The clients also host a self-written client application that generates IPv6 traffic with the DUG header option. The DUG client applications inject two packets per second at the moment, signalling the start and the stop of a DUG.¶
------------
| Client 1 |
------------\
\
------------- ----------
| Forwarder |---| Server |
------------- ----------
/
------------/
| Client 2 |
------------
With both iperf clients configured to max out the forwarder-to-server link (940Mbps maximum UDP goodput), the XDP hook allows to report on DUG packets that are not processed within a cycle to the monitoring repository of the Digital Twin.¶
In the upcoming months, the XDP hook will be extended to be configurable from DetNet Controllers to read the priority field of the DUG flags and to prioritise a percentage of them if they are not being delivered with the configured XDP cycle time.¶
This memo describes metadata exposed in cleartext in the IPv6 header. This metadata is similar to metadata exposed in RTP header extensions such as [I-D.draft-ietf-avtext-framemarking]. There is a potential for some limited privacy leakage, which may be acceptable for some applications, as a tradeoff to improve the overall quality of experience for the application. For example, it may be possible to determine video keyframes and their frequency.¶
TODO: this memo may reserve one or more IPv6 Hop-by-Hop Options.¶
This work has been partially funded by the European Commission Horizon Europe SNS JU projects PREDICT-6G (GA 101095890) [P6G]. The following people contributed substantially to the content of this document and should be considered coauthors: Xavier de Foy, Abinaya Babu, and Muhammad Awais Jadoon.¶