Out-of-order Insensitive Traffic In the Network

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 , 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 . 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.