[RFE] QoS VLAN 802.1p Support

Bug #1505631 reported by vikram.choudhary
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Reedip

Bug Description

[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

Changed in neutron:
assignee: nobody → vikram.choudhary (vikschw)
Changed in neutron:
status: New → Confirmed
importance: Undecided → Wishlist
tags: added: ovs qos
Revision history for this message
Miguel Angel Ajo (mangelajo) wrote :

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

Revision history for this message
vikram.choudhary (vikschw) wrote :

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

Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

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

Changed in neutron:
status: Confirmed → Triaged
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

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?

Changed in neutron:
assignee: vikram.choudhary (vikschw) → nobody
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

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

Changed in neutron:
status: Triaged → Incomplete
Revision history for this message
Matt Kassawara (ionosphere80) wrote :

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.

Revision history for this message
vikram.choudhary (vikschw) wrote :

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

Revision history for this message
Miguel Angel Ajo (mangelajo) wrote :

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.

Revision history for this message
Miguel Angel Ajo (mangelajo) wrote :

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)

Reedip (reedip-banerjee)
Changed in neutron:
assignee: nobody → Reedip (reedip-banerjee)
description: updated
Changed in neutron:
status: Incomplete → New
summary: - QoS VLAN 802.1p Support
+ [RFE] QoS VLAN 802.1p Support
Changed in neutron:
status: New → Confirmed
Assaf Muller (amuller)
Changed in neutron:
assignee: Reedip (reedip-banerjee) → nobody
Revision history for this message
Assaf Muller (amuller) wrote :

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.

Reedip (reedip-banerjee)
Changed in neutron:
assignee: nobody → Reedip (reedip-banerjee)
Changed in neutron:
assignee: Reedip (reedip-banerjee) → Kannan Raman (kannanrc20)
status: Confirmed → In Progress
Revision history for this message
Kannan Raman (kannanrc20) wrote :

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

Changed in neutron:
status: In Progress → Confirmed
tags: added: rfe-postponed
removed: rfe
Revision history for this message
Na Zhu (nazhu) wrote :

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

Revision history for this message
Ihar Hrachyshka (ihar-hrachyshka) wrote :

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron-specs (master)

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

Revision history for this message
Reedip (reedip-banerjee) wrote :

Pulling it up for Pike

Changed in neutron:
assignee: Kannan Raman (kannanrc20) → Reedip (reedip-banerjee)
Revision history for this message
Reedip (reedip-banerjee) wrote :
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron-specs (master)

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers