O co tedy jde? Začněme trochu zeširoka a podívejme se pod lupou na jeden aspekt provozu sítí, které snad všichni denně používají. Pokud jste s fungováním TCP/IP obeznámeni do detailu, jistě prominete nepřesnosti v zájmu srozumitelného podání tématu.
Když se zahltí linka
Když se někdy kolem roku 1986 spustila první 32kbps linka toho, co dnes nazýváme internet, velmi záhy se zjistilo, že při zahlcení linky dochází k rapidnímu nárůstu zpoždění a ztrátě propustnosti.
Na vině byla prvotní implementace TCP/IP, která prostě při ztrátě paketu jeho vysílání neustále opakovala. Proto byla už v roce 1992 zavedena první opatření pro řízení zahlcování (tzv. Congestion Control). Mezi ně patří měření časů „round-trip“ (RTT), různé timery, slow starty, fast starty, ale i v různých situacích zmiňovaná dynamická změna velikosti TCP okna.
Přes to všechno se již před časem ukázalo, že je potřeba další mechanismus detekce, resp. informace o zahlcení. A tak byl v roce 2001 standardizován mechanismus ECN (Explicit Congestion Notification), protože výpadky paketů v TCP spojení stále způsobovaly problémy v přenosu – nárůst zpoždění a nevyužívání plné kapacity linek, což je zvláště na tlustých linkách drahý špás. V závislosti na technologii a použitých technikách správy front může jít o ztrátu třeba až poloviny kapacity.
Do té doby se totiž na systém, kterým provoz prochází skrz internet, pohlíželo jako na černou skříňku, jejíž chování nelze explicitně ovlivňovat, protože nemá žádný způsob, jak informovat ostatní o úzkém hrdle na lince.
Pro ECN ale moc volných bitů v IP hlavičce nalezeno nebylo – jen dva, tedy pouhé čtyři kombinace. ECN tak krom informace, že zařízení je schopné s ECN pracovat, umožňuje poslat ještě informaci CE – Congestion Experienced. To je v podstatě informace o tom, že zařízení došlo místo v bufferu (v podstatě se jedná o ekvivalent informace, že došlo k zahození paketu). Tím je dosaženo toho, že zdroj dat je informován o počínajícím zahlcení.
Aktuální reakce na základě tohoto příznaku je víceméně stejná jako na ztrátu paketu – tedy „půlení“ rychlosti (i když v RFC 8511 z roku 2018 je navrhován složitější mechanismus reakce) – zařízení zpomalí odesílání dat na polovinu a tak je problém vyřešen… nebo vlastně není.
Půlení je zbytečně drastické
S narůstajícími požadavky na využití linek, a především stabilitu „pingu“ (v uvozovkách proto, že většina síťových prvků odbavování ICMP upřednostňuje, takže použití pro měření RTT se tak stává problematické), se totiž ukázalo, že takové „půlení“ rychlosti je příliš drastické a situace vyžaduje jemnější řešení. Jinak vznikají na linkách různé oscilace, jak ve využití kapacity, tak v RTT.
Poznámka: Malá odbočka k bufferům – před časem se zdálo jako dobrý nápad vybavit každé zařízení bufferem na procházející data. Bohužel, každý buffer způsobuje zpoždění, a ne jen to, stejně jako zácpy na silnicích, může způsobovat další vedlejší efekty, včetně drastického poklesu propustnosti. Proto přibližně v roce 2011 vznikla iniciativa bufferbloat.net snažící se upozorňovat na „přemíru bufferování“.
Tím se dostáváme do současnosti. Zahlcování je totiž věc, která se aktuálně řeší. Problém číslo jedna ale je, kde vzít v hlavičce IP paketu bity k tomu, aby se taková informace dala přenášet.
Technická shoda již víceméně panuje v tom, že se využije ECN bitů, které díky absenci reálných implementací nejsou ještě masově využívány – což je krásná ukázka toho, že nic není neměnné a všechny rezervované bity jednou dojdou – i v IP hlavičkách. Některé bity s obměnou technologií mění svůj význam.
Větší neshoda panuje v tom, jak je využít. Zjednodušeně se dá říci, že existují dva soupeřící přístupy. Jeden se nazývá L4S (Latency, Low Loss, Scalable Throughput) a již delší dobu jej prosazují někteří větší síťoví hráči. Novější přístup se nazývá SCE (Some Congestion Experienced) a prosazují jej spíše příznivci open-source.
L4S proti SCE
Důvody neshod jsou celkem prosté – L4S redefinuje využití ECN způsobem ne zcela kompatibilním s původní definicí ECN (jejíž implementace víceméně nyní probíhá) a zavádí jakousi druhou kastu zařízení, která podporují L4S skrz DCTCP. Ta pak jsou schopna reagovat na signalizaci o velikosti bufferu a přizpůsobovat jí svou rychlost.
Oponenti však krom problémů se zpětnou kompatibilitou poukazují například na to, že algoritmy použité pro L4S jsou pravděpodobně zatíženy patenty firmy Alcatel-Lucent nebo na to, že L4S implementace v podstatě umožňuje koncovým zařízením podvrhovat informaci o ECN a tím se uměle dostávat do „rychlejšího“ odbavovacího pruhu. Implementace je pak náročnější i na prostředky v síťových prvcích, kvůli implementaci dvojích front (druhá fronta má sloužit k odbavování zařízení, která podporují L4S).
Naproti tomu mechanismus SCE jde cestou evoluce a zcela zachovává zpětnou kompatibilitu s ECN. Zjednodušeně se dá říci, že zavádí pulsní modulaci rychlosti, využitím posledního nevyužitého přechodu jednoho z ECN bitů (ECT(1)) – čím více přijde paketů s nastaveným příznakem SCE, tím více by měl odesílatel zpomalit. V případě zásadních problémů se stále zachovává posílání CE jako příznaku „teď už je to opravdu vážné“. Nevýhodou je, že díky využití pouhého půlbitu, už nezbývá žádné místo na informaci typu „zařízení podporuje SCE“.
V praxi by to ale neměl být problém, protože prostě zařízení buď SCE bude rozumět a použije jej, nebo podporuje alespoň CE a bude reagovat na něj. Pokud ani to ne, použije se TCP okno. Prvotní implementace SCE vykazuje v experimentech slušné výsledky stabilizace toku a RTT.
Experimenty a diskuse
L4S má za sebou jistě delší vývoj, nicméně oba přístupy musí prokázat svou životaschopnost experimenty a testováním v různých podmínkách. Pokud si přečtete alespoň část diskusí či samotných RFC, zjistíte, že tato jedna změna je navázána na množství dalších témat jako je AQM (Active Queue Management), potřebuje úpravy i v TCP a podobně. Dál je například potřeba udělat nástroje, které dané schopnosti simulují a testují, takže to opravdu nekončí sepsáním RFC k jednomu půlbitu.
Nutno říci, že ani jeden z návrhů zatím není tak daleko, aby byl hned standardizován a víme, že některé standardy vznikají i desítky let. Nicméně princip fungování RFC (Request For Comment) je takový, že se vznášejí komentáře a námitky, navrhují vylepšení a podobně. Proto i toto téma potřebuje svou publicitu, aby se mu věnovali zainteresovaní. Nakonec jde o (aktuálně) poslední volný bit v IP hlavičce a o to, zda bude moci existovat i svobodná implementace lepšího řešení zahlcování sítí.
Odkazy
- datatracker.ietf.org/wg/tsvwg/documents/
- datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/
- datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/
- trac.ietf.org/trac/tsvwg/report/1
- datatracker.ietf.org/doc/draft-morton-tsvwg-sce/
- lwn.net/Articles/783673/
- youtu.be/FDK88vdE5r0
- www.bufferbloat.net/projects/
ČLÁNKY DO MAILU