| Internet-Draft | OOO Insensitive Traffic | January 2025 |
| Du | Expires 12 July 2025 | [Page] |
This document describes a kind of out-of-order insensitive traffic in the transport network, and the related load balancing mechanism for it.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
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 12 July 2025.¶
Copyright (c) 2025 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.¶
Load balancing (LB) in the network is important, which can make the link loads in the network similar so as to avoid potential partial congestion in the network. Two basic load balancing methods supported in the packet forwarding equipment are the per-packet LB, and the per-flow LB.¶
In the per-packet LB mechanism, when a flow comes, the packets of the flow will be distributed to the paths with the same cost in a round-robin manner. Hence, the load of the paths will be similar. However, the different paths may have different latencies to the destination, the packets in the flow will potentially be out-of-order when they arrive at the destination. For some applications, for example, the real time audio or video service, it is no recommended to use the per-packet LB mechanism.¶
In the per-flow LB mechanism, when a packet comes, some information in the packet header will be HASHed and the packet will be forwarded to a path accordingly if multiple paths with the same cost exist. The packets of the same flow will have the same HASH value so that no out-of-order will take place at the destination due to the per-flow LB.¶
In the current network, the network layer (IP layer) is not aware of the service requirement of the flow, i.e., it is not aware about whether the flow is out-of-order sensitive or insensitive. Therefore, in the current transport network, the per-flow LB will be enabled by default.¶
However, the result of the per-packet LB will normally be better than the per-flow LB. The result of the per-flow LB will depend on whether the sizes of the flows are even. If there are large flows and they are distributed to the same path because they have the same HASH value, the network may become partial congested.¶
In this situation, we may deploy an scheduler in the network, which can be aware of the network traffic status, and make some policy decision to do the traffic engineering for the network. It is a little complicated, and can only do the optimization after the congestion happens.¶
In this document, we propose some mechanisms to enable per-packet LB for specific flows, which can be regarded as a kind of precaution mechanism.¶
To enable the per-packet LB in the transport network, both the edge device and the forwarding device will be involved. The edge device may be the user's terminal or an edge router which can mark the packets of the users. The forwarding device is the device that along the path of the packet, which will receive the packets sent out by the edge device.¶
In the edge device, the specific traffic needs to be marked as out-of-order insensitive. Thus, each packet of the traffic would include a specific mark in its packet header when it is sent out by the edge device. By comparison, normal traffic will not be marked with the specific mark.¶
In the forwarding device, both the per-flow LB and the per-packet LB is enabled. The packets without the specific mark will be treated as usual, i.e., load balancing by using the per-flow LB mechanism, and the packets with the specific mark will be treated specifically. For example, we can do load balance for the packets by using the per-packet LB mechanism.¶
In this section, we will describe the considerations about the specific mark, which indicates that the packet is out-of-order insensitive.¶
In [RFC8622], a lower-effort traffic is proposed with a DSCP codepoint as "000001". The traffic is described as with a priority lower than the BE traffic, and a specific lower-than-BE transport protocol is developed for it [RFC6817].¶
The out-of-order insensitive traffic in this document has a different semantic meaning compared to the lower-effort traffic. Similarly, we can occupy a specific DSCP codepoint to mark the out-of-order insensitive packets. In details, the DSCP codepoint will be found in the ToS (Type of Service) field of the IPv4 header, or in the TC (Traffic Class) field of the IPv6 header. In this case, the DSCP codepoint would indicate both the QoS level and the out-of-order insensitive information.¶
Alternatively, we can also consider mark the out-of-order insensitive packets by using a specific bit in the packet header outside of the ToS/TC field. In this case, the meanings of the DSCP codepoints need not to be changed; however, a new place needs to be found to convey the specific bit.¶
TBD.¶
TBD.¶