ADSL: jak bude fungovat agregace od nového roku?

V pátek jsem zde na Lupě psal o rychlostech, kterých skutečně dosahují ADSL přípojky v ČR. Klíčovým faktorem, který o těchto efektivních (skutečně dosahovaných) přenosových rychlostech rozhoduje, je kromě velikosti a charakteru zátěže také konkrétní způsob, jakým je agregace řešena. Jak tomu bylo a dosud je u nás, je stále zakryto určitou rouškou nejasností, neurčitostí či přímo tajemství (viz předchozí články, ADSL: co se stalo? a ADSL: co se stalo? (2.)). V zásadě ale lze říci, že až dosud měl agregaci plně pod kontrolou Telecom, a alternativní operátoři a ISP neměli možnost ovlivnit fungování agregačních mechanismů. Právě toto by se ale mělo od nového roku změnit. Nová velkoobchodní nabídka totiž přichází s úplně jiným způsobem řešení agregace, který přenechává iniciativu při řešení agregace na straně "přeprodejců", poskytujících internetovou konektivitu. Nebude to ovšem tím způsobem, o kterém jsem psal v nedávném článku (ADSL: kdo oddělí vlky od oveček?), tedy na principu VPN (virtuálních privátních sítí).

Podstatu nového řešení si lze představit takto: dosud byly všechny pakety (od všech uživatelů daného providera, v rámci stejné služby a stejného agregačního bodu) "dávány na jednu hromadu" (tj. řazeny do jedné fronty), a Telecom na tuto frontu uplatňoval příslušnou agregaci, s využitím tzv. traffic policingu, či tzv. traffic shapingu. Jinými slovy: veškerý provoz (v rámci služby, providera a agregačního bodu) si byl roven, a Telecom na něj aplikoval určité restrikce (při nedostatku kapacit některé pakety eliminoval, ať už tím či oním způsobem).

Nové řešení, definované v nejnovější velkoobchodní nabídce, má být následující: Telecom bude každému providerovi (v rámci konkrétní služby a v každém agregačním bodě) poskytovat dvě fronty, do kterých bude možné řadit příchozí pakety: frontu s vyšší prioritou a frontu s nižší prioritou. Pokud budou kapacity stačit, bude Telecom přenášet provoz z obou front bez omezení. Pokud se začne nedostávat kapacit, budou přednostně přenášeny pakety z fronty s vyšší prioritou (zatímco pakety ve frontě s nižší prioritou budou čekat, až na ně nějaká kapacita zbude). V případě zaplnění kterékoli z front budou další příchozí pakety jednoduše zahazovány, tím nejméně inteligenntním způsobem. Pro odborněji laděné čtenáře: dojde k tzv. tail-dropu, s tím že mechanismy RED (Random Early Detection), případně WRED (Weighted RED), které by totéž dělaly výrazně inteligentněji, nejsou implementovány. Podrobnosti např. v materiálech Cisco.

Na samotných providerech, poskytujících internetovou konektivitu, pak bude to, aby pakety svých zákazníků označovali příznakem vyšší nebo nižší priority, a tím rozhodovali o způsobu jejich zpracování.

Co to fakticky znamená, není těžké nahlédnout: Telecom zcela eliminoval "propracované" techniky shapingu a policingu, snažící se předcházet zahlcení, a nahradil je nejjednodušší možnou technikou (co je "navíc", to se zahodí). Zavedením dvou front s různou prioritou, s tím že jedna má absolutní přednost před druhou, pak dal providerů možnost (a vlastně i povinnost) rozhodovat o tom, který provoz bude zahazován přednostně.

Jde tedy o řešení, které jistým způsobem umožňuje providerů rozlišovat mezi "vlky a ovečkami", v tom smyslu jak jsem o něm psal v článku "ADSL: kdo oddělí vlky od oveček". Má však některé významné odlišnosti od mechanismu VPN (virtuálních privátních sítí), který jsem ve zmíněném článku uváděl jako možné řešení. Rozdíl je například v tom, že pomocí VPN by bylo mělo možné oběma skupinám uživatelů vyhradit určitou přenosovou kapacitu, o kterou by se společně dělili (tj. vlci by dohromady dostali něco, ovečky také něco, ale vzájemně by si z toho "neukrajovali"). V případě dvou prioritních front by ovečky měly dostat tu s prioritou vyšší. Jelikož by ale tato fronta měla mít absolutní prioritu, znamená to, že vlkům by nešlo nic vyhradit. Dostalo by se na ně až v případě, pokud by požadavky všech oveček dohromady nevyčerpaly dostupnou kapacitu, a zbytek by tak byl dostupný i vlkům.

Na první pohled to vypadá vcelku spravedlivě a rozumně: provideři budou moci standardně zařazovat své uživatele mezi ovečky (tj. jejich požadavky řadit do fronty s vyšší prioritou), a teprve když "k něčemu dojde" (uživatel poruší providerem definovaný Fair Use Policy, překročí objemový limit atd.), bude dotyčný uživatel zařazen mezi vlky (a jeho požadavky budou řazeny do fronty s nižší prioritou, kde nemohou předběhnout žádnou ovečku). Problém však vidím v technické rovině, zejména ve způsobu eliminace "nadbytečných" paketů v obou frontách. Bude-li to skutečně děláno tím nejméně inteligentním způsobem (tail-drop, tj. co je "navíc", je zahozeno), který nebere v úvahu fungování protokolů vyšších vrstev (zejména protokolu TCP), dojde i při malém procentu zahazovaných paketů k rapidnímu poklesu celkové propustnosti. Vlci pak nepřenesou prakticky nic, ale problém může být i s ovečkami, protože jakmile se ani ty nevejdou (dohromady) se svými požadavky do fronty s vyšší prioritou, budou i jejich požadavky kráceny nejméně inteligentním způsobem, což se i jim může projevit dramatickým poklesem efektivní rychlosti.

Celkově si to dovolím zhodnotit tak, že jde o řešení, které umožňuje providerům, aby zabránili vlkům v okrádání oveček o přenosovou kapacitu. Jde tedy o významný krok k narovnání nepřirozeného stavu, kdy "zlý" je poskytovatel velkoobchodní služby a nikoli ten, kdo poskytuje službu koncovému zákazníkovi. Nový mechanismus se dvěma prioritními frontami nejen umožní providerů, aby "zlý" byli oni, ale dokonce je k tomu bude nutit.

Na druhou stranu ani nové řešení neumožňuje garantovat určitou minimální přenosovou rychlost ani samotným ovečkám, a při vyšší momentální aktivitě oveček může způsobovat zbytečné plýtvání přenosovými kapacitami (kvůli neefektivnosti transportních protokolů při "náhodných" ztrátách síťových paketů).

Jak to ale skutečně dopadne, ukáže až čas. Zatím se mi nepodařilo získat od žádného z providerů jeho názor na nové řešení agregace, jeho hodnocení či dokonce předpověď reálných dopadů, takže vše jsou zatím jen mé spekulace.