[RFE] QoS VLAN 802.1p Support

[vikram.choudhary]

[Overview]
The IEEE 802.1p signaling standard defines traffic prioritization at Layer 2 of the OSI model. Layer 2 network devices, such as switches, that adhere to this standard can group incoming packets into separate traffic classes.The 802.1p standard is used to prioritize packets as they traverse a network segment (subnet).When a subnet becomes congested, causing a Layer 2 network device to drop packets, the packets marked for higher priority receive preferential treatment and are serviced before packets with lower priorities.

The 802.1p priority markings for a packet are appended to the MAC header.On Ethernet networks, 802.1p priority markings are carried in Virtual Local Area Network (VLAN) tags. The IEEE 802.1q standard defines VLANs and VLAN tags. This standard specifies a 3-bit field for priority in the VLAN tag, but it does not define the values for the field. The 802.1p standard defines the values for the priority field. This standard defines eight priority classes (0 - 7). Network administrators can determine the actual mappings, but the standard makes general recommendations. The VLAN tag is placed inside the Ethernet header, between the source address and either the Length field (for an IEEE 802.3 frame) or the EtherType field (for an Ethernet II frame) in the MAC header. The 802.1p marking determines the service level that a packet receives when it crosses an 802.1p-enabled network segment.

[Proposal]
Existing QoS [1]_ framework can be extend for supporting VLAN priority.
This requirement mainly focus provider networks.
Note: For the tenant network it can only work if the traffic is segmented via VLANs and does nothing for other type of segmentation.

[Benefits]
- Enhancement to the existing QoS functionality.

[What is the enhancement?]
- Add VLAN tagging support to the QoS extension for provider's network.
- Add additional command lines for realizing Vlan tag support.
- Add OVS support.

[Related information]
[1] QoS
   https://review.openstack.org/#/c/88599/
[2] Specification
    https://blueprints.launchpad.net/neutron/+spec/vlan-802.1p-qos

[Miguel Angel Ajo (mangelajo)]

In my opinion this change is very similar to the DSCP rfe [1]. We could handle both in parallel, or , in series. The advantage of doing this after DSCP, is, based on the similarities, we could use the learnings from implementing DSCP to implement this better from the start.

Personally I believe we may do this after DSCP is ready for the reason stated above, within Mitaka if we finish DSCP soon, otherwise on N.

[1] https://bugs.launchpad.net/neutron/+bug/1468353

[vikram.choudhary (vikschw)]

@Ajo: I have no issues with this. Actually, its a nice suggestion and will wait for DSCP for completion.

[Armando Migliaccio (armando-migliaccio)]

To be discussed, because we need the full picture as to whether QoS support in Neutron is these days.

[Armando Migliaccio (armando-migliaccio)]

That said, I am not sure I see the value of this effort if we limit QoS support for Neutron to QoS on the hypervisor, shouldn't dscp suffice?

[Armando Migliaccio (armando-migliaccio)]

Defining a tenant API that exposes QoS capability that is inherently associated with the underlying segmentation technology may be problematic. If this was limited to provider networks, it might be a sensible thing to do, but the intended scope as originally submitted by the author is unclear on this regard. Please provide more input.

More details can be found on [1].

[1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-01-12-15.00.log.html

[Matt Kassawara (ionosphere80)]

Long story short, 802.1p provides QoS at layer-2 and DSCP provides QoS at layer-3. Operators may utilize one or both of these in their network infrastructure, so we should ultimately support both of them. However, in comparison to DSCP, end-to-end QoS using 802.1p requires VLAN provider and project/tenant networks. Using VLAN provider networks and overlay project/tenant networks requires mapping 802.1p to DSCP values, likely implementing DSCP on the overlay itself rather than the traffic within it. The most difficult part for both mechanisms... determining the extent of which to expose QoS to projects/tenants.

[vikram.choudhary (vikschw)]

I agree that this requirement make more sense for the provider network

[Miguel Angel Ajo (mangelajo)]

Ok, from my point of view, this RFE makes sense from the point of view of provider networks.

It does not make sense for tenant networks themselves, because in that case, it will only work
if your tenant traffic is segmented via VLANs, and will silently do nothing if your tenant network
is using any other kind of segmentation.

Given comments #5, #6 & #7, we can consider this spec once the DSCP support is completed, I'd say
N cycle, if everything goes as planned.

[Miguel Angel Ajo (mangelajo)]

Btw, vikram, could you update the RFE description to match those last comments?.

Could you also remove the ECN command line reference?, I believe that's unrelated (unless I'm missing something)

[Assaf Muller (amuller)]

http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2016-06-16.log.html#t2016-06-16T22:04:43

The summary is that seeing as how the QoS team considers this low priority and the work hasn't started, we'd need to find contributors and reviewers for the O cycle and the discussion would have to resume then.

[Kannan Raman (kannanrc20)]

Please someone help me, How to test this scenario using iperf ?.

[Na Zhu (nazhu)]

@Miguel, now the DSCP implementation is completed in N cycle, will this RFE considered in O cycle?

[Ihar Hrachyshka (ihar-hrachyshka)]

@Na Zhu, Ocata is a short cycle where we don't target any new features. QoS subteam definitely has some technical debt to close (enhanced validation, refactoring notification_driver into something driven by core plugin, ...) before we consider new features.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/392023

[Reedip (reedip-banerjee-deactivatedaccount)]

Pulling it up for Pike

[Reedip (reedip-banerjee-deactivatedaccount)]

Updates : http://eavesdrop.openstack.org/meetings/neutron_qos/2017/neutron_qos.2017-01-31-15.02.log.html

[OpenStack Infra (hudson-openstack)]

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/392023

[Lajos Katona (lajos-katona)]

this bug is inactive for ~5years, I close it now