docs/design/specs/High-Priority-Traffic-Path.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3
   4 ==========================================
   5 High Priority Traffic Path
   6 ==========================================
   7
   8 https://wiki.opnfv.org/display/ovsnfv/OVSFV+Requirement+-+High+Priority+Traffic+Path
   9
  10 Problem description
  11 ===================
  12
  13 A network design may need to adequately accommodate multiple classes of traffic, each
  14 class requiring different levels of service in critical network elements.
  15
  16 As a concrete example, a network element managed by a service provider may be
  17 handling voice and elastic data traffic. Voice traffic requires that the end-to-end
  18 latency and jitter is bounded to some numerical limit (in msec) accuracy in order to ensure
  19 sufficient quality-of-service (QoS) for the participants in the voice call.
  20 Elastic data traffic does not impose the same demanding requirements on the network
  21 (there will be essentially no requirement on jitter. For example, when downloading a
  22 large file across the Internet, although the bandwidth requirements may be high there
  23 is usually no requirement that the file arrives within a bounded time interval.
  24
  25 Depending on the scheduling algorithms running on the network element,
  26 frames belonging to the data traffic may get transmitted before frames
  27 belonging to the voice traffic introducing unwanted latency or jitter.
  28 Therefore, in order to ensure deterministic latency and jitter characteristics
  29 end-to-end, each network element through which the voice traffic traverses
  30 must ensure that voice traffic is handled deterministically.
  31
  32 Hardware switches have typically been designed to ensure certain classes
  33 of traffic can be scheduled ahead of other classes and are also
  34 over-provisioned which further ensures deterministic behavior when
  35 handling high priority traffic. However, software switches (which includes
  36 virtual switches such as Open vSwitch) may require modification in order
  37 to achieve this deterministic behavior.
  38
  39 Use Cases
  40 ---------
  41
  42 1. Program classes of service
  43
  44 The End User specifies a number of classes of service. Each class of service
  45 will be represented by the value of a particular field in a frame. The class
  46 of service determines the priority treatment which flows in the class will
  47 receive, while maintaining a relative level of priority for other classes and
  48 a default level of treatment for the lowest priority class of service. As
  49 such, each class of service will be associated with a priority. The End User
  50 will associate classes of service and priorities to ingress ports with the
  51 expectation that frames that arrive on these ingress ports will get
  52 scheduled following the specified priorities.
  53
  54 Note: Priority treatment of the classes of service cannot cause any one of
  55 the classes (even the default class) from being transferred at all. In other
  56 words, a strict priority treatment would likely not be successful for serving
  57 all classes eventually, and this is a key consideration.
  58
  59 2. Forward high priority network traffic
  60
  61 A remote network element sends traffic to Open vSwitch. The remote network
  62 element, indicates the class of service to which this flow of traffic belongs
  63 to by modifying a pre-determined but arbitrary field in the frame as specified
  64 in Use Case 1. Some examples include the Differentiated Services Code Point
  65 (DSCP) in an IP packet or the Priority Code Point (PCP) in an Ethernet frame.
  66 The relative priority treatment that frames get processed by Open vSwitch can be guaranteed by the
  67 values populated in these fields when the fields are different. If the fields
  68 are the same, ordering is not deterministic.
  69
  70 For example: Packet A is sent with a DSCP value of 0 and packet B is sent
  71 with a value of 46; 0 has a lower priority than 46. Packet A arrives
  72 before packet B. If Open vSwitch has been configured as such, Packet
  73 B will be transmitted before Packet A.
  74
  75 Proposed change
  76 ===============
  77
  78 TBD
  79
  80 Alternatives
  81 ------------
  82
  83 TBD
  84
  85 OVSDB schema impact
  86 -------------------
  87
  88 TBD
  89
  90 User interface impact
  91 ---------------------
  92
  93 TBD
  94
  95 Security impact
  96 ---------------
  97
  98 TBD
  99
 100 Other end user impact
 101 ---------------------
 102
 103 TBD
 104
 105 Performance Impact
 106 ------------------
 107
 108 TBD
 109
 110 Other deployer impact
 111 ---------------------
 112
 113 TBD
 114
 115 Developer impact
 116 ----------------
 117
 118 TBD
 119
 120 Implementation
 121 ==============
 122
 123 Assignee(s)
 124 -----------
 125
 126 Who is leading the writing of the code? Or is this a blueprint where you're
 127 throwing it out there to see who picks it up?
 128
 129 If more than one person is working on the implementation, please designate the
 130 primary author and contact.
 131
 132 Primary assignee:
 133   <email address>
 134
 135 Other contributors:
 136   <email address>
 137
 138 Work Items
 139 ----------
 140
 141 TBD
 142
 143 Dependencies
 144 ============
 145
 146 TBD
 147
 148 Testing
 149 =======
 150
 151 In order to test how effectively the virtual switch handles high priority traffic
 152 types, the following scheme is suggested.::
 153
 154                    +---------------------------+         Ingress Traffic Parameters
 155                    |                           |         +-------------------------------------------+
 156                    |                           |
 157                    |                           |         Packet Size: The size of the Ethernet frames
 158                    |                           |
 159                    |                           |         Tmax: RFC2544 Max. Throughput for traffic of
 160                    |                    PHY0   <-------+ "Packet Size"
 161                    |                           |
 162                    |                           |         Total Offered Rate: The offered rate of both
 163                    |                           |         traffic classes combined expressed as a % of
 164                    |                           |         Tmax
 165                    |                           |
 166                    |                           |         Ingress Rates are expressed as a percentage
 167                    |                           |         of Total Offered Rate.
 168                    |                           |
 169                    |                           |         Class A:
 170                    |             OVS           |         Ethernet PCP = 0 (Background)
 171                    |            (BR0)          |         Ingress Rate      : rate_ingress_a(n) Mfps
 172                    |                           |
 173                    |                           |         Class B:
 174                    |                           |         Ethernet PCP = 7 (Highest)
 175                    |                           |         Ingress Rate      : rate_ingress_b(n) Mfps
 176                    |                           |
 177                    |                           |         Egress Traffic Measurements
 178                    |                           |         +-------------------------------------------+
 179                    |                           |         Class A:
 180                    |                           |         Egress Throughput : rate_egress_a(n) Mfps
 181                    |                           |         Egress Latency    : max_lat_egrees_a(n) ms
 182                    |                           |         Egress Jitter     : max_jit_egress_a(n) ms
 183                    |                    PHY1   +------->
 184                    |                           |         Class B:
 185                    |                           |         Egress Throughput : rate_egress_b(n) Mfps
 186                    |                           |         Egress Latency    : max_lat_egrees_b(n) ms
 187                    +---------------------------+         Egress Jitter     : max_jit_egress_b(n) ms
 188
 189
 190 Open vSwitch is configured to forward traffic between two ports agnostic to the
 191 traffic type. For example, using the following command:
 192
 193 ovs-ofctl add-flow br0 in_port=0,actions=output:1
 194
 195 The test will be carried out with the functionality to enable high-priority
 196 traffic enabled and disabled in order to guage the change in performance for
 197 both cases.
 198
 199 Two classes of traffic will be generated by a traffic generator. In the example
 200 above, the classes are differentiated using the Ethernet PCP field. However,
 201 another means for differentiating traffic could be used, depending the
 202 prioritization scheme that is developed.
 203
 204 Tests should be performed for each combination of:
 205
 206 * Packet Sizes in (64, 512)
 207 * Total Offered Rate in (80, 120, 150)
 208 * rate_ingress_b(n) / rate_ingress_a(n) in (0.1, 0.2, 0.5)
 209
 210 For each set, the following metrics should be collected for each traffic
 211 class over a specified time period:
 212
 213 Egress Throughput (Mfps)
 214 Maximum Egress Latency (ms)
 215 Maximum Egress Jitter (ms)
 216
 217 Documentation Impact
 218 ====================
 219
 220 TBD
 221
 222 References
 223 ==========
 224
 225 Please add any useful references here. You are not required to have any
 226 reference. Moreover, this specification should still make sense when your
 227 references are unavailable. Examples of what you could include are:
 228
 229 * Links to mailing list or IRC discussions
 230
 231 - http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-December/007193.html
 232 - http://ircbot.wl.linuxfoundation.org/meetings/opnfv-ovsnfv/2016/opnfv-ovsnfv.2016-03-07-13.01.html
 233
 234 * Links to relevant research, if appropriate
 235
 236 - https://wiki.opnfv.org/download/attachments/5046510/qos_mechanisms.pdf?version=1&modificationDate=1459187636000&api=v2
 237
 238 * Related specifications as appropriate
 239
 240 * Anything else you feel it is worthwhile to refer to
 241
 242
 243 History
 244 =======
 245
 246 Optional section intended to be used each time the spec
 247 is updated to describe new design, API or any database schema
 248 updated. Useful to let reader understand what's happened along the
 249 time.
 250
 251 .. list-table:: Revisions
 252    :header-rows: 1
 253
 254    * - Release Name
 255      - Description
 256    * - Colorado
 257      - Introduced