idnits 2.17.1 draft-finzi-priority-switching-scheduler-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 202 has weird spacing: '... queues pri...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2018) is 2012 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AF' is mentioned on line 220, but not defined == Missing Reference: 'AEF' is mentioned on line 564, but not defined == Missing Reference: 'UEF' is mentioned on line 567, but not defined == Missing Reference: 'CS0' is mentioned on line 576, but not defined -- Duplicate reference: RFC5865, mentioned in 'RFC5865', was also mentioned in 'Globecom17'. Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Baker 3 Internet-Draft 4 Intended status: Informational Finzi 5 Expires: April 25, 2019 TTTech Computertechnik AG 6 Frances 7 ISAE-SUPAERO 8 Kuhn 9 CNES 10 Lochin 11 Mifdaoui 12 ISAE-SUPAERO 13 October 22, 2018 15 Priority Switching Scheduler 16 draft-finzi-priority-switching-scheduler-04 18 Abstract 20 We detail the implementation of a network rate scheduler based on 21 both a packet-based implementation of the generalized processor 22 sharing (GPS) and a strict priority policies. This credit based 23 scheduler called Priority Switching Scheduler (PSS), inherits from 24 the standard Strict Priority Scheduler (SP) but dynamically changes 25 the priority of one or several queues. Usual scheduling 26 architectures often combine rate schedulers with SP to implement 27 DiffServ service classes. Furthermore, usual implementations of rate 28 scheduler schemes (such as WRR, DRR, ...) do not allow to efficiently 29 guarantee the capacity dedicated to both AF and DF DiffServ classes 30 as they mostly provide soft bounds. This means excessive margin is 31 used to ensure the capacity requested and this impacts the number of 32 additional users that could be accepted in the network. PSS allows a 33 more predictable output rate per traffic class and is a one fit all 34 scheme allowing to enable both SP and rate scheduling policies within 35 a single algorithm. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 25, 2019. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 1.1. Context and Motivation . . . . . . . . . . . . . . . . . 2 73 1.2. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 74 1.3. Priority Switching Scheduler in a nutshell . . . . . . . 3 75 2. Priority Switching Scheduler . . . . . . . . . . . . . . . . 5 76 2.1. Specification . . . . . . . . . . . . . . . . . . . . . . 5 77 2.2. Implementation with three traffic classes and one 78 controlled queue . . . . . . . . . . . . . . . . . . . . 9 79 2.3. Implementation with n controlled queues . . . . . . . . . 10 80 3. Usecase: benefit of using PSS in a Diffserv core network . . 12 81 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 12 82 3.2. New service offered . . . . . . . . . . . . . . . . . . . 14 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 87 6.2. Informative References . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 1.1. Context and Motivation 94 To enable DiffServ traffic classes and share the capacity offered by 95 a link, many schedulers have been developed such as Strict Priority, 96 Weighted Fair Queuing, Weighted Round Robin or Deficit Round Robin. 98 In the context of a core network router architecture aiming at 99 managing various kind of traffic classes, scheduling architectures 100 require to combine a Strict Priority (to handle real-time traffic) 101 and a rate scheduler (WFQ, WRR, ... to handle non-real time traffic) 102 as proposed in [RFC5865]. For all these solutions, the output rate 103 of a given queue often depends on the amount of traffic managed by 104 other queues. PSS aims at reducing the uncertainty of the output 105 rate of selected queues, we call them in the following controlled 106 queues. Additionally, compared to previous cited schemes, the 107 scheduling scheme proposed is simpler to implement as PSS allows to 108 both enable Strict Priority and Fair Queuing services; is more 109 flexible following the wide possibilities offered by this setting; 110 and does not require a virtual clock as for instance, WFQ. 112 1.2. Definitions and Acronyms 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 o AF: Assured Forwarding; 120 o BLS: Burst Limiting Shaper; 122 o DRR: Deficit Round Robin 124 o DF: Default Forwarding; 126 o EF: Expedited Forwarding; 128 o PSS: Priority Switching Scheduler; 130 o QoS: Quality-of-Service; 132 o FQ: Fair Queuing 134 o SP: Strict Priority 136 o WFQ: Weighted Fair Queuing 138 o WRR: Weighted Round Robin 140 1.3. Priority Switching Scheduler in a nutshell 141 _____________________ 142 | p_low[i] p_high[i] | 143 ------|_____________________| 144 sets() | ^ 145 _________|__ | 146 PSS controlled | | | | selects() 147 queue i ------------>| p[i]= v | | 148 | | credit[i] 149 . | . | ^ 150 . | . | | updates() 151 . | . | | 152 non-active | |------------------> output 153 PSS queue j ------------>| p[j] | traffic 154 | | 155 . | . | 156 . | . | 157 . | . | 158 |____________| 159 Priority Scheduler 161 Figure 1: PSS in a nutshell 163 As illustrated in Figure 1, the principle of PSS is based on the use 164 of credit counters (detailed in the following) to change the priority 165 of one or several queues. Each controlled queue i is characterized 166 by a current priority state p[i], which can takes two priority 167 values: {p_high[i], p_low[i]} where p_high[i] the highest priority 168 value and p_low[i] the lowest. This idea follows a proposal made by 169 the TSN Task group named Burst Limiting Shaper [BLS]. For each 170 controlled queue i, each current priority p[i] changes between 171 p_low[i] and p_high[i] depending on the associated credit counter 172 credit[i]. Then a Priority Scheduler is used for the dequeuing 173 process, i.e., among the queues with available traffic, the first 174 packet of the queue with the highest priority is dequeued. 176 The main idea is that changing the priorities adds fairness to the 177 Priority Scheduler. Depending on the credit counter parameters, the 178 amount of capacity available to a controlled queue is bounded between 179 a minimum and a maximum value. Consequently, good parameterization 180 is very important to prevent starvation of lower priority queues. 182 The service obtained for the controlled queue with the switching 183 priority is more predictable and corresponds to the minimum between a 184 desired capacity and the residual capacity left by higher priorities. 185 The impact of the input traffic sporadicity from higher classes is 186 thus transfered to non-active PSS queues with a lower priority. 188 Finally, PSS offers much flexibility as both controlled queues with a 189 guaranteed capacity (when two priorities are set) and queues 190 scheduled with a simple Priority Scheduler (when only one priority is 191 set) can conjointly be enabled. 193 2. Priority Switching Scheduler 195 2.1. Specification 197 For the sake of clarity and to ease the understanding of the PSS 198 algorithm, we consider the case where only one queue is a controlled 199 queue. This corresponds to three traffic classes EF, AF and DF where 200 AF is the controlled queue as shown in Figure Figure 2. 202 queues priority ___ 203 ________ | \ 204 EF--->|________|-----{1}----+ \ 205 | \ 206 ________ | \ 207 AF--->|________|-----{2,4}--+ PSS ---> 208 | / 209 ________ | / 210 DF--->|________|-----{3}----+ / 211 |___/ 213 Figure 2: PSS with three traffic classes 215 As previously explained, the PSS algorithm defines for the controlled 216 queue a low priority denoted p_low, and a high priority denoted 217 p_high associated to a credit counter denoted credit, which manages 218 the priority switching. Considering Figure 2, the priority p[AF] of 219 the controlled queue AF will be switched between two priorities where 220 p_high[AF] = 2 and p_low[AF] = 4. The generalisation of PSS 221 algorithm to n controlled queues is given in Section 2.3. 223 Then, each credit counter is defined by: 225 o a minimum level: 0; 227 o a maximum level: LM; 229 o a resume level: LR such as 0 <= LR < LR; 231 o a reserved capacity: BW; 233 o an idle slope: I_idle = C * BW, where C is the link output 234 capacity; 236 o a sending slope: I_send = C - I_idle; 238 The available capacity (denoted C) is mostly impacted by the 239 guaranteed capacity BW. Hence, BW should be set to the desired 240 capacity plus a margin taking into account the additional packet due 241 to non-preemption as explained below: 243 the value of LM can negatively impact on the guaranteed available 244 capacity. The maximum level determines the size of the maximum 245 sending windows, i.e, the maximum uninterrupted transmission time of 246 the controlled queue packets before a priority switching. The impact 247 of the non-preemption is as a function of the value of LM. The 248 smaller the LM, the larger the impact of the non-preemption is. For 249 example, if the number of packets varies between 4 and 5, the 250 variation of the output traffic is around 25% (i.e. going from 4 to 5 251 corresponds to a 25% increase). If the number of packets sent varies 252 between 50 and 51, the variation of the output traffic is around 2%. 254 The credit allows to keep track of the packet transmissions. 255 However, keeping track the transmission raises an issue in two cases: 256 when the credit is saturated at LM or at 0. In both cases, packets 257 are transmitted without gained or consumed credit. Nevertheless, the 258 resume level can be used to decrease the times when the credit is 259 saturated at 0. If the resume level LR is 0, then as soon as the 260 credit reaches 0, the priority is switched and the credit saturates 261 at 0 due to the non-preemption of the current packet. On the 262 contrary, if LR > 0, then during the transmission of the non- 263 preempted packet, the credit keeps on decreasing before reaching 0 as 264 illustrated in Figure 3. 266 Hence, the proposed value for LR is Lmax * BW, with Lmax the maximum 267 packet size of the controlled queue. With this value, there is no 268 credit saturation at 0 due to non-preemption. 270 A similar parameter setting is described in [Globecom17], to 271 transform WRR parameter into PSS parameters, also in the case of a 272 three classes DiffServ architecture. 274 The priority change depends on the credit counter as follows: 276 o initially, the credit counter starts at 0; 278 o the change of priority p[i] of controlled queue i occurs in two 279 cases: 281 * if p[i] is currently set to p_high[i] and credit[i] reaches LM; 283 * if p[i] is currently set to p_low[i] and credit[i] reaches LR; 285 o when a packet of the controlled queue is transmitted, the credit 286 increases (is consumed) with a rate I_send, else the credit 287 decreases (is gained) with a rate I_idle; 289 o when the credit reaches LM, it remains at this level until the end 290 of the transmission of the current packet (if any); 292 o when the credit reaches LR and the transmission of the current 293 packet is finished, in the abscence of new packets to transmit in 294 the controlled queue, it keeps decreasing at the rate I_idle until 295 it reaches 0. Finally, the credit remains to 0 until the start of 296 the transmission of a new packet. 298 Figure 3 and Figure 4 give two examples of credit and priority 299 changes of a given queue. First, Figure 3 gives an example when the 300 controlled queue sends its traffic continuously until the priority 301 changes (this traffic is represented with @ below the x-axis of this 302 figure). Then, the credit reaches LM and the last packet is 303 transmitted although the priority have changed. Other traffic is 304 thus sent (represented by o) uninterruptedly until the priority 305 changes back. Figure 4 illustrates a more complex behaviour. First, 306 this figure shows when a packet with a priority higher than p_high[i] 307 is available, this packet is sent before the traffic of queue i. 308 Secondly, when no traffic with a priority lower than p_low[i] is 309 available, then traffic of queue i can be sent. This highlights the 310 non-blocking nature of PSS and that p[i] = p_high[i] (resp. p[i] = 311 p_low[i]) does not necessarily mean that traffic of queue i is being 312 sent (resp. not being sent). 314 ^ credit 315 | | | 316 | p_high | p_low | p_high 317 LM |- - - - -++++++- - - - - - - |- - - -+++ 318 | +| |+ | + 319 |I_send + | | + I_idle | + 320 | + | | + | + 321 | + | | + | + 322 | + | | + | + 323 | + | | + | + 324 LR | + | | + |+ 325 0 |-+- - - -|- - |- - - - - - - +- - - - - > 326 | | time 327 @@@@@@@@@@@@@@@@oooooooooooooo@@@@@@@@@@ 329 @ controlled queue traffic 330 o other traffic 332 Figure 3: First example of queue credit evolution and priority 333 switching. 335 ^ credit 336 | | 337 | p_high | p_low 338 LM + - - - - - - - - - - - -++++ - - - - - - -+ 339 | +| |+ + 340 | ++ + | | + + 341 | + | + + | | + + 342 | ++ + | + | | + 343 | +| + + | | | | | 344 | + | + | | | | | 345 LR +--+--|-----|----|---|---|--|------|------- 346 0 +-+- -| - - |- - |- -|- -|- |- - - |- - - - > 347 | | | | | | time 348 @@@@@@oooooo@@@@@oooo@@@@@@@@oooooo@@@@@@@ 350 @ controlled queue traffic 351 o other traffic 353 Figure 4: Second example of queue credit evolution and priority 354 switching. 356 Finally, for the dequeuing process, a Priority Scheduler selects the 357 appropriate packet using the current priority values. In other 358 words, among the queues with packets enqueued, the first packet of 359 the queue with the highest priority is dequeued (usual principle of 360 SP). 362 2.2. Implementation with three traffic classes and one controlled queue 364 The new dequeuing algorithm is presented in the PSS Algorithm in 365 Figure 5 and consists in a modification of the standard SP. The 366 credit of the controlled queue and the dequeuing timer denoted 367 timerDQ are initialized to zero. The initial priority is set to the 368 highest value p_high. First, we compute the difference between the 369 current time and the time stored in timerDQ (line #3). The duration 370 dtime represents the time elapsed since the last credit update, 371 during which no packet from the controlled queue was sent, we call 372 this the idle time. Then, if dtime > 0, the credit is updated by 373 removing the credit gained during the idle time that just occurred 374 (lines #4 and #5). Next, timerDQ is set to the current time to keep 375 track of the last time the credit was updated (line #6). If the 376 credit reaches LR, the priority changes to its high value (lines #7 377 and #8). Then, with the updated priorities, SP algorithm performs as 378 usual: each queue is checked for dequeuing, highest priority first 379 (lines #12 and #13). When the queue selected is the controlled 380 queue, the credit expected to be consumed is added to the credit 381 variable (line #16). The time taken for the packet to be dequeued is 382 added to the variable timerDQ (line #17) so the transmission time of 383 the packet will not be taken into account in the idle time dtime 384 (line #3). If the credit reaches LM, the priority changes to its low 385 value (lines #18 and #19). Finally, the packet is dequeued (line 386 #22). 388 Inputs: credit, timerDQ, C, LM, LR, BW, p_high, p_low 389 1 currentTime = getCurrentTime() 390 3 dtime = currentTime - timerDQ 391 4 if dtime > 0 then: 392 5 credit = max(credit - dtime * C * BW, 0) 393 6 timerDQ = currentTime 394 7 if credit < LR and p = p_low then: 395 8 p = p_high 396 9 end if 397 10 end if 398 11 end for 399 12 for each priority level, highest first do: 400 13 if length(queue[i]) > 0 then: 401 15 if queue[i] is the controlled queue then: 402 16 credit = 403 min(LM, credit + size(head(queue[i])) * (1 - BW)) 404 17 timerDQ = currentTime + size(head(queue[i]))/C 405 18 if credit >= LM and p = p_high then: 406 19 p = p_low 407 20 end if 408 21 end if 409 22 dequeue(head(queue[i])) 410 23 break 411 24 end if 412 25 end for 414 Figure 5: PSS algorithm 416 PSS algorithm implements the following functions: 418 o getCurrentTime() uses a timer to return the current time; 420 o length(q) returns the length of the queue q; 422 o head(q) returns the first packet of queue q; 424 o size(f) returns the size of packet f; 426 o dequeue(f) activates the dequeing event of packet f. 428 2.3. Implementation with n controlled queues 430 The algorithm can be updated to support n controlled queues. In this 431 context, the credits of each queue i must be stored in the table 432 creditList[i]. Each controlled queue i has its own dequeuing timer 433 stored in the table timerDQList[i]. Likewise for each controlled 434 queue, LM[i], LR[i], BW[i], p_low[i] and p_high[i] are respectively 435 stored in LMList[i], LRList[i], BWList[i], p_lowList[i] and 436 p_highList[i]. A controlled queue i is characterized by p_lowList[i] 437 > p_highList[i] (as priority 0 is the highest priority for SP). The 438 current priority of a controlled queue is stored in p[i]. Each 439 controlled queue must have distinct priorities. 441 As an example, Figure Figure 6 extends Figure 2 to n controlled 442 queues. 444 queues prio ___ 445 ________ | \ 446 Admitted EF--->|________|-----{1}----+ \ 447 | \ 448 ________ | \ 449 Unadmitted EF--->|________|-----{2}----+ \ 450 | \ 451 ________ | \ 452 AF1-->|________|-----{3,6}--+ PSS ---> 453 | / 454 ________ | / 455 AF2-->|________|-----{4,7}--+ / 456 | / 457 ________ | / 458 DF--->|________|-----{5}----+ / 459 |___/ 461 Figure 6: PSS with three traffic classes 463 Inputs: creditList[], timerDQList[], C, LMList[], LRList[], 464 BWList[],p_highList[], p_lowList[] 465 1 for each queue i with p_highList[i] < p_lowList[i] do: 466 2 currentTime = getCurrentTime() 467 3 dtime = currentTime - timerDQList[i] 468 4 if dtime >0 then: 469 5 creditList[i] = 470 max(creditList[i] - dtime * C * BWList[i], 0) 471 6 timerDQList[i] = currentTime 472 7 if credit[i] < LRList[i] and p[i] = p_lowList[i] then: 473 8 p[i] = p_highList[i] 474 9 end if 475 10 end if 476 11 end for 477 12 for each priority level pl, highest first do: 478 13 if length(queue(pl)) > 0 then: 479 14 i = queue(pl) 480 15 if p_highList[i] < p_lowList[i] then: 481 16 creditList[i] = 482 min(LMList[i], 483 creditList[i] + size(head(i)) * (1 - BWList[i])) 484 17 timerDQList[i] = currentTime + size(head(i))/C 485 18 if creditList[i] >= LMList[i] 486 and p[i] = p_highList[i] then: 487 19 p[i] = p_lowList[i] 488 20 end if 489 21 end if 490 22 dequeue(head(i)) 491 23 break 492 24 end if 493 25 end for 495 Figure 7: PSS algorithm 497 The general PSS algorithm also implements the following function: 499 o queue(pl) returns the queue i associated to priority pl. 501 3. Usecase: benefit of using PSS in a Diffserv core network 503 3.1. Motivation 505 The DiffServ architecture defined in [RFC4594] and [RFC2475] proposes 506 a scalable mean to deliver IP quality of service (QoS) based on 507 handling traffic aggregates. This architecture follows the 508 philosophy that complexity should be delegated to the network edges 509 while simple functionalities should be located in the core network. 511 Thus, core devices only perform differentiated aggregate treatments 512 based on the marking set by edge devices. 514 Keeping aside policing mechanisms that might enable edge devices in 515 this architecture, a DiffServ stateless core network is often used to 516 differentiate time-constrained UDP traffic (e.g. VoIP or VoD) and 517 TCP bulk data transfer from all the remaining best-effort (BE) 518 traffic called default traffic (DF). The Expedited Forwarding (EF) 519 class is used to carry UDP traffic coming from time-constrained 520 applications (VoIP, Command/Control, ...); the Assured Forwarding 521 (AF) class deals with elastic traffic as defined in [RFC4594] (data 522 transfer, updating process, ...) while all other remaining traffic is 523 classified inside the default (DF) best-effort class. 525 The first and best service is provided to EF as the priority 526 scheduler attributes the highest priority to this class. The second 527 service is called assured service and is built on top of the AF class 528 where elastic traffic such as TCP traffic, is intended to achieve a 529 minimum level of throughput. Usually, the minimum assured throughput 530 is given according to a negotiated profile with the client. The 531 throughput increases as long as there are available resources and 532 decreases when congestion occurs. As a matter of fact, a simple 533 priority scheduler is insufficient to implement the AF service. TCP 534 traffic increases until reaching the capacity of the bottleneck due 535 to its opportunistic nature of fetching the full remaining capacity. 536 In particular, this behaviour could lead to starve the DF class. 538 To prevent a starvation and ensure to both DF and AF a minimum 539 service rate, the router architecture proposed in [RFC5865] uses a 540 rate scheduler between AF and DF classes to share the residual 541 capacity left by the EF class. Nevertheless, one drawback of using a 542 rate scheduler is the high impact of EF traffic on AF and DF. 543 Indeed, the residual capacity shared by AF and DF classes is directly 544 impacted by the EF traffic variation. As a consequence, the AF and 545 DF class services are difficult to predict in terms of available 546 capacity and latency. To overcome these limitations and make AF 547 service more predictable, we propose here to use the newly defined 548 Priority Switching Scheduler (PSS). 550 Figure 8 shows an example of the Data Plane Priority core network 551 router presented in [RFC5865] modified with a PSS. The EF queues 552 have the highest priorities to offer the best service to real-time 553 traffic. The priority changes set the AF priorities either higher 554 (3,4) or lower (6,7) than CS0 (5), leading to capacity sharing (CS0 555 refers to Class Selector codepoints 0 and is usually refered to DF as 556 explained in [RFC7657]). Another example with only 3 queues is 557 described in [Globecom17]. Thank to the increase predictability, for 558 the same minimum guaranteed rate, the PSS reserves a lower percentage 559 of the capacity than a rate scheduler. This leaves more remaining 560 capacity that can be guaranteed to other users. 562 prio ___ 563 | \ 564 Admitted EF------{p[AEF] = 1}--------+ \ 565 | \ 566 | \ 567 Unadmitted EF----{p[UEF] = 2}--------+ \ 568 | \ 569 | \ 570 AF1--{p_high[AF1]=3, p_low[AF1]= 6}--+ PSS ---> 571 | / 572 | / 573 AF2--{p_high[AF2]=4, p_low[AF2]= 7}--+ / 574 | / 575 | / 576 CS0------------{p[CS0] = 5}----------+ / 577 |___/ 579 Figure 8: PSS applied to Data Plane Priority (we borrow the syntax 580 from RCF5865) 582 3.2. New service offered 584 The new service we seek to obtain is: 586 o for EF, the full capacity of the output link; 588 o for AF the minimum between a desired capacity and the residual 589 capacity left by EF; 591 o for DF (CS0), the residual capacity left by EF and AF. 593 As a result, the AF class has a more predictable available capacity, 594 while the unpredictability is reported on the DF class. With good 595 parametrization, both classes also have a minimum rate ensured. 596 Parameterization and simulations results concerning the use of a 597 similar scheme for core network scheduling are available in 598 [Globecom17] 600 4. Security Considerations 602 There are no specific security exposure with PSS that would extend 603 those inherent in default FIFO queuing or in static priority 604 scheduling systems. However, following the DiffServ usecase proposed 605 in this memo and in particular the illustration of the integration of 606 PSS as a possible implementation of the architecture proposed in 608 [RFC5865], most of the security considerations from [RFC5865] and 609 more generally from the differentiated services architecture 610 described in [RFC2475] still hold. 612 5. Acknowledgements 614 This document was the result of collaboration and discussion among a 615 large number of people. In particular the authors wish to thank 616 David Black, Ruediger Geib, Vincent Roca for reviewing this draft and 617 Victor Perrier for the TUN/TAP implementation of PSS. At last but 618 not least, a very special thanks to Fred Baker for his help. 620 6. References 622 6.1. Normative References 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, 626 DOI 10.17487/RFC2119, March 1997, 627 . 629 6.2. Informative References 631 [BLS] Gotz, F-J., "Traffic Shaper for Control Data Traffic 632 (CDT)", IEEE 802 AVB Meeting , 2012. 634 [Globecom17] 635 Finzi, A., Lochin, E., Mifdaoui, A., and F. Frances, 636 "Improving RFC5865 Core Network Scheduling with a Burst 637 Limiting Shaper", Globecom , 2017, 638 . 640 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 641 and W. Weiss, "An Architecture for Differentiated 642 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 643 . 645 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 646 Guidelines for DiffServ Service Classes", RFC 4594, 647 DOI 10.17487/RFC4594, August 2006, 648 . 650 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 651 Services Code Point (DSCP) for Capacity-Admitted Traffic", 652 RFC 5865, DOI 10.17487/RFC5865, May 2010, 653 . 655 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 656 (Diffserv) and Real-Time Communication", RFC 7657, 657 DOI 10.17487/RFC7657, November 2015, 658 . 660 Authors' Addresses 662 Fred Baker 663 Santa Barbara, California 93117 664 USA 666 Email: FredBaker.IETF@gmail.com 668 Anais Finzi 669 TTTech Computertechnik AG 670 Schoenbrunner Strasse 7 671 Vienna 1040 672 Austria 674 Phone: 0043158534340 675 Email: anais.finzi@tttech.com 677 Fabrice Frances 678 ISAE-SUPAERO 679 10 Avenue Edouard Belin 680 Toulouse 31400 681 France 683 Email: fabrice.frances@isae-supaero.fr 685 Nicolas Kuhn 686 CNES 687 18 Avenue Edouard Belin 688 Toulouse 31400 689 France 691 Email: nicolas.kuhn@cnes.fr 692 Emmanuel Lochin 693 ISAE-SUPAERO 694 10 Avenue Edouard Belin 695 Toulouse 31400 696 France 698 Phone: 0033561338485 699 Email: emmanuel.lochin@isae-supaero.fr 701 Ahlem Mifdaoui 702 ISAE-SUPAERO 703 10 Avenue Edouard Belin 704 Toulouse 31400 705 France 707 Email: ahlem.mifdaoui@isae-supaero.fr