Feature Overview 

OSP QoS Support

Egress QoS capability involves traffic classification based on DSCP and five tuples and traffic shaping or enforcement of the policy to honor CIR (Committed Information Rate) and PIR (Peak Information Rate) together with Peak Burst Size. The enforcement point of the Egress QoS is typically at the point of contention or congestion so that high-priority traffic gets preferential treatment and the low-priority traffic is dropped where the aggregate traffic exceeds the egress interface capability. The CIR value of the Egress QoS policy provides guaranteed bandwidth for the specified traffic class where as PIR provides the maximum allowed traffic rate beyond the CIR for the given traffic class. 

Use Case

Telco Service Provider wants to configure the Egress QoS policy to guarantee a minimum bandwidth for a given traffic class. Any traffic rate beyond the CIR and below the PIR should get preferential treatment using established traffic shaping mechanisms.  Users should be able to apply QoS policy at each of the individual contention/congestion points in the host including virtual and physical interfaces. Additionally, an E2E QoS paradigm should be enabled at the host level for the given traffic class. Multiple traffic classes must be supported along with traffic classification and traffic shaping capability. 

Egress QoS is currently supported for OVS and OVS-DPDK but not at the NIC level. To achieve E2E Egress QoS capability NIC level support is a must. 

Goals

Support Egress QoS policy support at the NIC level

Requirements 

Done - Acceptance Criteria 

Validation of E2E QoS support for OVS-DPDK deployment with RHOSO. 

(1) Ability to configure Egress QoS policy at the NIC

(2) Egress QoS policy enforcement at the NIC. Test traffic must include multiple traffic classes. Verify maximum traffic does not exceed PIR defined for the traffic class

Documentation Considerations 

New feature support as GA for Egress Qos Policy (maximum bandwidth / PIR). Documentation required for Users guide and Release notes.

Team Sign Off (Completion while in Planning status)

• All required Epics (known at the time) are linked to the this Feature
• All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
• Add - Reviewers name, Team Name
• Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
• Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone

• …