Application-based QoS support with P4 and OpenFlow

Although Software Defined WANs are now widely deployed by several production networks, they are largely restricted to traffic engineering approaches based on layer 4 (L4) of the network protocol stack Quality-of-Service (QoS) improvements. However, the emergence of application protocols such as QUIC and HTTP/2 creates the need for an investigation of layer 5-based (L5) approaches in order to improve users’ Quality-of-Experience (QoE). This blog describes a prototype of a system that leverages the capabilities of flexible switches that incorporate protocol-independent packet processing in order to intelligently route traffic based on application headers. We use simultaneous file transfers as an example to show how applications such as ABR video streaming, GridFTP, or others can benefit from application header-based traffic engineering. Our prototype consists of a deployment on the Chameleon testbed, leveraging its SDN-enabled Corsa switches and Q-in-Q technology to efficiently orchestrate traffic at the core while software P4 switches are deployed at the edge to translate QoE requirements. In order to provide a single vantage point for our SDN experiments and structure them in repeatable fashion we use a Jupyter notebook technology integrated with the Chameleon testbed.

 

This work will be presented as a demo at LCN 2018, Chicago, IL. To read the full paper go here.

 

Note: This experiment uses the Bring-Your-Own-Controller (BYOC) feature provided by Chameleon. For more details on how to run SDN experiments with Chameleon click here.

 

Resources and Tools Required

  1. Bare-metal (8) - One Client, One Server, Two Cross Traffic, Two P4 switches, One controller and One Jupyter (All Ubuntu 16.04)
  2. Network
    • AL2S by Internet2
    • Two Corsa switches: TACC and UC

For more details and steps on how to setup the environment go here.

 

Experiment Procedure

In this experiment we will use two types of P4 rules: a Baseline rule which forwards all HTTP/2 streams on a single path and a Fast Path rule which differentiates between original and retransmitted segments using the Stream ID to direct retransmissions on a path with better QoS. We use VLAN tags, i.e., Q-in-Q technology to translate Stream IDs into VLAN tags after which a second VLAN tag is attached before the packet is forwarded along the appropriate 802.1Q circuit. This technology allows us to translate edge routing traffic engineering principles which we implement in Layer-5 into the core network to be interpreted as a Layer-2 VLan tag.

The procedure is as follows.

  1. Obtain Resources on Chameleon and perform the setup as explained here.
  2. Compile and build the following P4 binaries:
    • Run P4 switch - Baseline
    • Run P4 switch - Fast Path
  3. Repeat the above for the following experiment scenarios. Note that all settings below are for Circuit1 where we artificially emulate a "Slow Path". Circuit2 is a 10Gbps VLAN circuit.
    • Bandwidth =100Mbps, Delay=30ms
    • Bandwidth =100Mbps, Delay=90ms
    • Bandwidth =100Mbps, Delay=110ms
    • Bandwidth =100Mbps, Delay=30ms, Loss=0.05%

The performance improvement here is a measure of the improvement over the corresponding Baseline case, where original and retransmitted ABR segments are transmitted on the same path versus the case where retransmitted segments are sent over a Fast Path.

 

Until the advent of technologies like P4, it was only possible to perform traffic engineering for headers between L2-L4. With the flexible parser and pipeline that P4 provides, we have seen that L5 application-level headers can be used for performing traffic engineering which can improve overall throughput by upto 70% in some cases and reduce delay by upto 50% while using a better path for ABR video segment retransmission.

 

 


Add a comment

No comments