Shaping a QoS. Karel Řeřicha Poslední revize:

Transkript

1 haing a Qo Karel Řeřicha oslední revize:

2 Mrs.

3 Mrs. B

4 Mrs. B

5 Mrs. B

6 Mrs. B

7 Mrs. B

8 Mrs. B

9 FIFO Mrs. Mrs. B

10 CoDel Mrs. Mrs. B

11 FQ, FQ Mrs. Mrs. B Mrs.

12 FQ_CoDel Mrs. Mrs. B Mrs.

13 rioritizace Mrs. absolutní B Mrs. Mrs.

14 rioritizace Mrs. oměrná B Mrs. Mrs.

15 Co dělá an Buffer? maká do roztrhání work conserving fifo, sfq, fq, codel, fq_codel B jede na normu work non-conserving htb, hfsc

16 - nedostatečná kaacita transortní sítě - nedostatečná kaacita oslední míle - efekt zahlcení řenosového média - efekt nerovnoměrného čerání řidělené kaacity v rámci jednotlivých datových toků - nekvalitní médium Qo - Quality of ervice - řízení datových toků v sítích s ředáváním aketů - ostuy, které zaručují, že daná internetová říojka bude mít co nejvyšší kvalitu za daných odmínek Kdy Qo oužít? - Úzká místa = šatně

17 Co s tím? - Lze rozšířit úzké místo? Rozšiřme ho! - Nasaďme Qo Metody Qo - alokace a řízení šířky a sdílení ásma - shaing - rioritizace rovozu - řízení rovozu

18 Jak to vyadá na řenosovém médiu - sítě s ředáváním rámců a aketů - data cestují v blocích - na většině běžně oužívaných médií jsou data ředávána maximální fyzickou rychlostí média

19 říklad okruhu - 1Gbs ethernet, 300Mbs rádio - ři rovozu 100Mbs dochází k výadkům aketů a nevíme roč?

20 Zahlcení bufferu - Rádio má malý buffer, data do něj cestují rychlostí 1Gbs a nestačí se rychlostí 300Mbs vysílat Řešení - Flow control - řijímací strana hlásí vysílací, že má lný buffer, a žádá o ozastavení vysílání - OZOR: řenos roblému dál

21 Buffer - co tam s akety? - když rázdný, tak nic :D - ozdržet vysílání - HAING - řeřazovat ořadí aketů - RIORITIZACE - zahodit akety - OLICING

22 olicing - droování aketů na vstuu - vysokorychlostní okruhy, nízké nároky na HW - nebudeme se zabývat :)

23 rioritizace - řeřazování aketů ve vysílacím bufferu - standardně buffery FIFO (fifo), žádná rioritizace, best effort - rioritizujeme rovoz nejvíce citlivý na zoždění a výadky - OZOR: ři rioritizaci nesmíme řehazovat akety v jednotlivých tocích

24 Exlicitní rioritizace - akety označeny už ři vysílání (nebo na cestě) - většinou bohužel absolutní (nedobře) TO - 3 bity recedence (riority), 5 bitů tye of service DC - Náhrada za TO (1998), 6 bitů, z toho rvní tři zětně komatibilní s recedence v TO

25 ECN - rozšíření DC o dva bity (2001) - okud uzel na konci konexe dostane aket s nastaveným ECN, zomalí vysílání v daném flow - dnes odorují všechny běžně dostuné oerační systémy - kromě shaingu nejzásadnější věc ro Qo, rotože v úzkém místě nastavíte dle otřeby ECN a snížení rychlosti vysílání aketů rovádějí komunikující uzly, tj. nejedná se o droování aketů či zvýšení latencí - FQ_CoDel má v sobě!!!

26 rioritizace - work conserving discilíny - akety rozděleny do toků, řidělování vysílací kaacity RIO - defaultně tři třídy, klasifikace aketů omocí filtrů, v každé třídě defaultně FIFO fronta FQ - rozdělení rovozu do jednotlivých FIFO front dle hashe hlavičky aketu, z front ak vysíláno round-robin - roblém se změnou hash funkce - řeřazení aketů v toku

27 CoDel - Controlled Delay - začíná roorcionálně droovat akety, jakmile délka fronty zůsobuje zoždění větší jak 5 ms FQ_CoDel - rozdělení rovozu do toků (def. 1024), v každém ak CoDel - aktuálně asi nejleší, co je možné nasadit - ři zalňování fronty nejdříve nastavuje ECN, až ak drouje

28 haing - work non-conserving discilíny - ozdržují vysílání aketů, i když je linka volná - hierarichické discilíny - klasifikace aketů do hierarchických tříd HTB - timer based, neřesná na rychlých linkách - nevhodné rozdělování zbývající šířky ásma u velmi rozdílných tříd

29 HFC - tři křivky, každá znamená úlně něco jiného - matoucí - Realtime - matoucí název, lze definovat všude, i když má smysl ouze u leaf tříd, chybí kontrola na overbooking - Link haring - je udávána v bs, i když vlastně vyjadřuje oměr sdílení řebytečné kaacity - Uer Limit - omezení jednotlivých tříd na maximální rychlost Výhody HFC: - velice řesná ve srovnání s HTB - každá křivka může mít dvě části, burst-delay-backlogged, možnost imlementace burstů - rioritizace omocí link sharing není absolutní - realtime křivka ro zaručenou kaacitu

30 raktická imlementace shaingu na Linuxu Klasifikace aketů - itables - aktulizace koírováním do usersace, lagy, není thread safe - nftables - náhrada itables, řeší nedostatky, datové struktury Na co dát ozor - omezení handles na 16bit, tj. max 65k tříd - nutná affinita NIC front na vyhrazená CU jádra, jinak jitter a říadně droy (Mikrotik?) - ro vyšší rychlosti vícenásobné NIC fronty, oužít offloading

31 l běžný shaing, kde se ouze secifikuje maximální rychlost, které může zákazník dosáhnout l graf ukazuje ouze jeden směr (naříklad download), druhý se chová obdobně l okud je celková kaacita linky větší, než součet maximální rychlosti obou zákazníků, tak to není roblém

32 l Linka je omezena na 50 Mbs, tj. okud ožadavky obou zákazníků na šířku ásma řekročí v součtu tuto mez, bude se reálná rychlost u obou oměrně snižovat. l Chybou je že zákazníkovi, který kontinuálně stahuje, tento systém rakticky vůbec neuškodí, zatím co zákazník, který jen občas otřebuje maximální rychlost, ji nikdy nedostane. l okud je maximální kaacita linky omezena shaingem, tak reálná situace odovídá grafu. okud je ale omezena technologií (roustnost WiFi, ethernetu ), ak dojde k řirozenému shaingu, kdy bude situace často mnohem horší v nerosěch druhého zákazníka (řirozený shaing neořezává jednotlivé zákazníky, ale jen celou linku, tj. zákazník, který vysílá data intenzivněji, dostane odstatně větší šířku ásma, než zákazník s ár tc konexemi).

33 l okud by nebyla využita riorita, tak oběma dvěma zákazníkům se rozdělí kaacita linky ve stejném oměru, tj. V tomto říadě by od třetí minuty měli oba dva zákazníci alokováno 25Mbs. l rotože ale má druhý zákazník nastavenu dvojnásobnou rioritu sdílení než rvní zákazník, tak v říadě řekročení kaacity linky se tato bude dělit v oměru 2:1 ve rosěch zákazníka s vyšší rioritou. l Velmi zjednodušeně lze říci, že okud oba zákazníci mají stejnou maximální rychlost a součet těchto rychlostí je vyšší než kaacita linky, tak v říadě rozdílných riorit si linku rozdělí v oměru těchto riorit. Naříklad okud má rvní zákazník rioritu 2 a druhý rioritu 5, rozdělí se linka na sedm dílů (2 + 5) a rvní zákazník dostane 2 díly a druhý 5 dílů. l riorita zde tedy neznamená absolutní rioritu (jako naříklad ve frontě), ale oměr sdílení. Tj. i zákazník s nízkou rioritou vždy nějakou linku dostane.

34 l Zákazník, který kontinuálně stahuje, bude o dvou minutách omezen na 10Mbs, na kterých ak zůstane do té doby, dokud na dostatečně dlouhý čas neřestane využívat linku. l Zákazník, který linku běžně oužívá, bude v říadě otřeby dosahovat maximální rychlosti. Nesmí ji ale dosahovat říliš často za sebou, jinak se mu bude délka burstu oměrně krátit. l Lze říci, že na burst si zákazník musí našetřit tím, že linku využívá méně, než je rychlost backlogged. V grafu je objem dat dán lochou od křivkami a locha burstu musí odovídat nebo být menší než locha ředchozího našetření. l Neovinný úkol: V tomto grafu je numerická chyba. Kdo ji rvní najde a vysvětlí, má u mne ochvalu a ivo.

35 l Zákazník rvní dvě minuty vyčeral burst, další čtyři minuty ale šetřil 10Mbs za minutu. Burst je ale o 40Mbs vyšší než backlogged, takže našetřil jen na jednu minutu burstu a ak mu linka sadne na backlogged. l Otázka: Jak dlouho bude trvat druhý burst, okud bude auza ve stahování dlouhá šest minut? l Otázka: Jak dlouho bude trvat druhý burst, okud bude auza ve stahování trvat deset minut?

36 l rvní zákazník začne stahovat burstem, rotože je na lince sám. Na začátku druhé minuty chce začít stahovat burstem druhý zákazník, ale rotože rvní má také burst a mají stejnou rioritu, linka se rozdělí v oměru 1:1. Tj. rvní oba zákazníci ojedou od druhé minuty 25 Mbs. rvnímu zákazníkovi se tak rodlouží druhá olovina burstu na dvě minuty, rotože ji čerá oloviční rychlostí. tejně tak druhý zákazník vyčerá rvní olovinu burstu za dvě minuty, oět oloviční rychlostí. Na začátku čtvrté minuty bude mít rvní zákazník vyčeraný burst a sadne na backlogged 10 Mbs. Druhý zákazník musí dobrat druhou olovinu burstu, což se mu ovede rychlostí 40 Mbs za minutu a čtvrt (roto je u něj v grafu áté minuty 20 Mbs jako růměr), a ak sadne na 10 Mbs.

37 l rvní zákazník začne stahovat burstem, rotože je na lince sám. Na začátku druhé minuty chce začít stahovat burstem druhý zákazník, ale rotože rvní má také burst, linka se rozdělí v oměru jejich riorit 2:1. Tj. rvní zákazník dostane 16,66 Mbs a druhý 33,33 Mbs. rvnímu zákazníkovi se tak rodlouží druhá olovina burstu na tři minuty, rotože ji čerá třetinovou rychlostí, a druhému zákazníkovi se rodlouží celý burst ze dvou na tři minuty, rotože ho čerá dvou třetinovou rychlostí. Oba tedy na začátku áté minuty budou mít vyčeraný burst a sadnou do backlogged. l amozřejmě i když má druhý zákazník dvojnásobnou rioritu v backlogged, jedou od áté minuty v backlogged oba 10 Mbs, rotože celkový součet jejich rychlostí není vyšší než roustnost linky.

38 Děkuji za ozornost :) odívejte se na I Gateway na říadně večer ivo