Erőforrás-kezelés maghálózatokban "csomag-színezéssel"

Erőforrás-kezelés maghálózatokban "csomag-színezéssel" Laki Sándor, PhD ELTE IK Információs Rendszerek Tanszék lakis@elte.hu Az Emberi Erőforrások Minisztériuma ÚNKP-17-4 kódszámú Új Nemzeti Kiválóság Programjának támogatásával készült

Emlékeztető INTERNETES FORGALMAK

Internetes forgalmak TCP Csomagvesztés alapú Csomagvesztés = torlódás (túlterhelés) Reszponzív Csomagvesztés esetén a küldési ráta csökkentése Nem valós idejű Nem skálázható viselkedés Toródás ténye a fontos UDP Általában VoIP vagy video Nem reszponzív, de limitált erőforrás igény Csomagvesztésre kevésbé érzékeny Más: QUIC, BBR,

cwnd Jellegzetes TCP viselkedés 4 ssthresh Csomagvesztés Timeout Timeout Slow Start Time Torlódási ablak (cwnd) ~ küldési ráta A TCP mindig csomagdobást kényszerít ki

Internetes forgalmak TCP Csomagvesztés alapú Csomagvesztés = torlódás (túlterhelés) Reszponzív Csomagvesztés esetén a küldési ráta csökkentése Nem valós idejű Nem skálázható viselkedés Toródás ténye a fontos UDP Általában VoIP vagy video Nem reszponzív, de limitált erőforrás igény Valós idejű Csomagvesztésre kevésbé érzékeny Más: QUIC, BBR, DCTCP, TCP Prague,

VÁRAKOZÁSI SOROKRÓL

Router data plane Processor control plane Line card Line card Switching Fabric Line card Line card Line card Line card

Receive Line Cards (Interface Cards, Adaptors) Packet handling Packet forwarding Buffer management Link scheduling Packet filtering Rate limiting Packet marking Measurement to/from link lookup to/from switch Transmit

Packet Switching and Forwarding 4 Link 1, ingress Choose Egress Link 1, egress Link 2 Link 1 R1 4 Link 3 Link 4 Link 2, ingress Link 3, ingress Choose Egress Choose Egress Link 2, egress Link 3, egress Link 4, ingress Choose Egress Link 4, egress

Problémák a várakozási sorok kezelésénél Ütemezés Melyik csomagot küldjük ki? Hogyan jelöljük a fairséget? Prioritások? Dobási politika Mikor kell csomagot eldobni? Melyik csomagot dobjuk el? Cél: egyensúly az átvitel és a késleltetés között Nagy pufferek minimalizálják a csomagdobást, azonban nagy késleltetést okoznak (azaz nagyobb RTT, hosszabb slow start, )

FIFO Scheduling and Drop-Tail Hozzáférés a link-hez: first-in first-out sor Csomagokat csak érkezéskor különböztetjük meg Hozzáférés a puffer területhez: drop-tail stratégia Ha a sor tele van, akkor dobjuk el a beérkező csomagot

Csomag vesztés löketekben A TCP csomagvesztés alapú Csomag vesztés = torlódás A TCP AI fázisa mindenképp csomagvesztést idéz elő Drop-tail stratégia csomagvesztési löketekhez vezet Torlódás: számos csomag tele sorba érkezik Szinkronizáció: Számos folyam egyszerre veszít csomagot

Lassú visszacsatolás Csak akkor van visszacsatolás, ha a puffer tele lett akkor is ha az már egy ideje töltődik Az egyre hosszabb puffer egyre nagyobb RTT-t ad lassítja a torlódás detektálását és a reagálást Jobb lenne a korábbi visszajelzés 1-2 kapcsolat lelassítása még a torlódás előtt (AQM RED, PIE, PI2, CoDEL, PVPIE, stb.)

ÜTEMEZÉSEKRŐL ÉS ERŐFORRÁS MEGOSZTÁSRÓL

First-in first-out Egyszerű, de kötött FIFO ütemezés Például, ha két fajta forgalmunk van Voice over IP alacsony késleltetést igényel E-mail nem érzékeny a késésre A VoIP forgalom mégis várakozik az emailek mögött

Szigorú prioritásos ütemezés (Strict Priority) Több prioritási szint Mindig a legnagyobb prioritású forgalomból küldünk, ha van ilyen Izoláció a legnagyobb prioritású forgalomnak Mintha dedikált vonala lenne Kis késleltetés Alacsony prioritású forgalmak kiéheztetése

Súlyozottan Fair Ütemezés (WFQ) Weighted fair scheduling Több sor a forgalmi osztályokhoz Minden sorhoz a sávszélesség egy adott részét rendeljük Sorok rotálása egy adott kis időskálán 50% red, 25% blue, 25% green 17

Súlyozottan Fair Ütemezés (WFQ) Non-work conserving Minden folyam legfeljebb a hozzárendelt súly szerint részesül az erőforrásból Work conserving Extra forgalom küldése a nem üres sorból, ha a többi üres Magasabb teljes kihasználtság Bájtok és nem csomagok számának nyilvántartása WFQ max-min fairséget eredményez Maximalizálja a folyamok minimum rátáját 18

Implementációs kérdések FIFO Egy sor, triviális ütemezés Strict priority Külön sor minden prioritási szinthez, egyszerű ütemező Weighted fair scheduling Külön sor minden forgalmi osztályhoz, és sokkal komplexebb ütemezés 19

Egyszerű csomag jelölés a végekhez közel, de bonyolult sorok és ütemezés a routerekben

Egyszerű csomag jelölés a végekhez közel, de bonyolult sorok és ütemezés a routerekben

CSINÁLJUK FORDÍTVA, AVAGY CORE-STATELESS MÓDON

Jó skálázódás elosztott megvalósítás Egyszerű ütemezés, pusztán a csomag jelölés alapján

Per Packet Value (PPV) PPV is a Resource Sharing framework, which allows a wide variety of detailed and flexible policies; enforces those policies under all possible offered traffic combinations; and scales well with the number of flows The proposed framework Resource sharing policies for all situations by Throughput-Value Functions (TVF) Packet Marker at the edge of the network Resource Nodes (e.g. routers) aim at maximizing the total transmitted Packet Value. This maximization results in implementing the policies, without the need for any flow awareness. Packet Marker Resource Node Policy Node Desired Resource Sharing is defined by PV only

Per Packet Value The Packet Value represents the gain of the operator when the packet is delivered. It expresses the relative importance of one packet to another. [Value/bit] The aim of the network, and every Resource Node within is to maximize the total Value of the transmitted packets. The Congestion Threshold Value separates the packets with PVs that get transmitted from the ones that get dropped (at a Resource Node) resulting from the combination of available capacity, amount of offered traffic and the Packet Value composition of the offered traffic increases as the congestion increases The framework complements E2E Congestion Control PPV enforces fairness, only low controlled loss has to be provided by E2E Congestion Control (to avoid the dead packet problem) Even incompatible CCs can coexist in a network implementing PPV

Value Curves Flow value curve From Service Value concept by Kristina Zetterberg et al. flow value PPV curve Suitable to mark packets (see later) PPV Log PPV curve Used throughout the remainder of this presentation log(ppv) derivative Log-log thput thput log(thput) Tells the value of a flow if it gets x kbits/sec Tells the increase in value if the flow gets an extra 1 bit/sec Just easier to work with.

Throughput-Value Functions (TVF) The TVF is the derivative of the Utility Function It defines the desired throughput of a flow of a class for all Congestion Threshold Values Flow calculus can be used calculate the ideal Congestion Threshold Value

TVF PPV Traffic #2 Traffic #1 Low congestion PPOV thrshld thput 1 thput 2 2x PPOV (thput i log( throughput) ) i PPOV thrshld thput i C

TVF PPV Traffic #3 Traffic #2 Traffic #1 Target: maximize realized operator value Resource sharing policy: Allow packets with marking above PPOV thrshld Drop packets with marking below PPOV thrshld Find PPOV thrshld where the total throughput coresponding to PPOV thrshld is maximal. High congestion PPOV thrshld Low congestion PPOV thrshld thput 1 thput 2 thput 3 PPOV (thput i log( throughput) ) i PPOV thrshld thput i C

Time [ms] Filter yellow and red Value Per packet OV Packet Marking example Filtering 2 flows of the same class simple TVF Example simple per packet OV curve Original Source 1 Source 2 Filtered to 1 Mbps Source 1 Source 2 1000 100 Bitrate [kbps] Value Color 200 1000 800 100 3000 10 10000 1 6 10 1 0 5000 10000 15000 1 Mbps throughput [kbps] Bitrate [kbps] Source 1 2 Mbps Source 2 6 Mbps Bottleneck 1 Mbps Filter by Value 1 Mbps

PPV Scheduler Goal: maximize the total transmitted Packet Value The simplest algorithm is to always serve packets with highest PV first Non-practical for typical flows as it results in out of order delivery A simple FIFO implementation is possible, when the queue becomes full drop the packet with the smallest Packet Value first If different packets have different resource demands that can be taken to account when maximizing the total transmitted Packet Value Packet Values cannot be directly compared, but must be normalized by the cost of their transmission (r) We define the Effective Packet Value of a packet as its Packet Value divided by its transmission cost (r)

Throughput [kbps] 2000 4000 6000 8000 GOLD and SILVER TCP 1-1, 2-2, 4-4, 8-8 flows Gold (B) Silver (C) Desired 0 20 40 60 80 100 120 Time [s]

Throughput [kbps] 0 2000 4000 6000 8000 3x 10 MBPS UDP + TCP flows In the same queue Gold (B) Silver (C) Background (D) Desired 0 50 100 PPV off 150 Tail drop Time [s]

Recent results and future plans Delay Aware Resource Node paper is currently under review meeting different delay requirements, while still maximizing total transmitted PV among Delay Classes PPV-aware AQM 1 published paper and another paper is currently under review avoiding buffer bloating, Congestion Control independent behavior Multi-layer virtulization paper is currently under review Remarking packets at the boundary of virualization domains Feedback of Congestion Threshold Value Usable for admission control by comparing CTV to the throughput-pv profile of the new flow Load Balancing equalizing the CTV among links By moving traffic from high CTV links to low CTV links Resource Balancing e.g. spectrum, power or processing resources are increased to the access(es) where the Effective Congestion Threshold Value is higher Network Value Maximization create simple algorithms, which can approximate NUM in a practical, highly dynamic case Network-wide PPV

Coexisting incompatible CCs (CSAQM: PVPIE-reloaded)

Coexisting incompatible CCs (PVPIE-reloaded)

Q&A