ADSL: co se stalo? (2.)

Včera ráno uspořádal Český Telecom pracovní setkání s novináři na téma ADSL. Asi jsem nebyl sám, kdo očekával, že se vyjádří především k současným stížnostem mnoha uživatelů, kterým se stalo to samé, co v srpnu při prvním pokusu o zapnutí agregace (efektivní rychlost jejich přípojek velmi rapidně klesla). A také že na to nějak konkrétně zareaguje.

Připomeňme si, jak Český Telecom zareagoval v srpnu:

Důvodem pozastavení agregace je skutečnost, že při jejím uplatnění v reálném provozu na službách s nižšími rychlostmi (například současná základní varianta 192/64 kb/s) se v některých případech skutečná rychlost dostávala pod úroveň akceptovatelnou zákazníky. ‚Cílem Českého Telecomu je zajištění očekávaných parametrů pro zájemce o tuto službu, což za současných podmínek nebylo možné u všech skupin zákazníků,‘ uvedl Vladan Crha, tiskový mluvčí Českého Telecomu.

Nyní ale, na situaci, která je (alespoň podle mého názoru) principiálně stejná a neméně závažná, Český Telecom reaguje odlišně. Žádné pozastavení agregace očividně nechystá.

Včerejší setkání s novináři mělo na programu hlavně informace o aktuálních číslech (počty objednávek, počty realizovaných přípojek) a rámcové představy o dalším rozvoji (výběr dodavatele technologií, způsob výběru dalších lokalit k pokrytí). Zazněla zde zajímavá čísla, ke kterým se vrátím v zítřejším článku – ale o agregaci se mluvilo až v diskusi.

Kde je chyba?

V diskusi o agregaci padaly různé výroky. Například konstatování o tom, že dopady znovuzapnuté agregace na uživatele jsou různé, že Český Telecom nemá zájem zhoršovat službu, ale také že hodlá optimalizovat své náklady. Službu bez agregace by mohl poskytovat, ale vyžadovalo by to prý další významné investice do jeho páteřní sítě.

Pokud jde o to hlavní, tedy o příčiny současných problémů a o jejich řešení, pak zde jsem nezaznamenal žádný náznak toho, že by Český Telecom připouštěl nějakou chybu na své straně. Natož že by hodnotil situaci stejně kriticky jako v srpnu (pokles „pod úroveň akceptovatelnou zákazníky“) a chystal se agregaci zase vypnout. Místo toho jsme si vyslechli úvahy o tom, že zákazníci by měli mít šanci si zvolit takový produkt, jaký vyhovuje jejich potřebám. Dokonce v tom smyslu, že vůbec nezáleží na použité technologii (zda ADSL nebo něco jiného), ale na tom, jakou kvalitu služby si uživatel kupuje.

Abych dále nechodil kolem horké kaše: reakci Českého Telecomu na současné problémy ADSL jsem pochopil tak, že příčinou je struktura a chování zákazníků jednotlivých ISP, a zákazníci by si měli své problémy řešit právě se svými ISP. Jestliže Český Telecom nyní jedná s ISP a řeší vzniklou situaci, tak je to prý hlavně o tom, jak vhodněji upravit strukturu zákazníků a jimi používaných produktů. Co to může znamenat, si raději domyslete sami.

Nepřímo zazněl i poukaz na to, že problém se objevuje hlavně u těch ISP, kteří „nekopírují“ fair usage policy stanovenou Českým Telecomem (zpoplatnění nadlimitních dat). Skutečnost, že třeba u Nextry si na problémy stěžují výlučně uživatelé již konvergovaných (zrychlených) linek, byla vysvětlován tím, že u tohoto ISP prý již migrovala většina stahovačů.

Kde je chyba?

Předchozí řádky asi moc nenadchly ty uživatele ADSL, které problémy s výrazným propadem rychlosti (a často i nárůstem pingu) již potkaly. Nedávají totiž moc šancí a vyhlídek na zlepšení. Přesto se pokusím o něco málo optimismu.

V diskusi o dopadech agregaci totiž zaznělo i to, že mezi Telecomem a jednotlivými ISP probíhá také „ladění mnoha různých parametrů“. To by mohlo nasvědčovat tomu, že i přes silácká prohlášení ve stylu „chyba není na naší straně“ stále ještě dochází k hledání a odstraňování technických problémů, které Telecom nepřiznává – a že jejich vyřešení by mohlo situaci přeci jen zlepšit.

V minulém článku o ADSL jsem vyjádřil názor, že za nejpravděpodobnější považuji chybu v implementaci, ale nikoli plošnou, nýbrž jen „někde“. Dnes si to dovolím trochu rozvést a upřesnit. Jde přitom o konkrétní způsob implementování agregace v páteřní síti Českého Telecomu (a podotýkám, že jde o mou spekulaci).

O tom, jak je agregace v síti Českého Telecomu přesně realizována, se ví jen velmi málo. Záchytným bodem může být alespoň to, co je psáno ve velkoobchodní nabídce: že agregace bude realizována technikou CAR (Committed Access Rate) firmy Cisco. Co když je příčina všech problémů právě ve volbě této techniky a způsobu jejího fungování? Před prvním i druhým zapnutím agregace musel mít Český Telecom v ruce úplné statistiky o všech relevantních datových tocích, a tak si mohl spočítat, jak velký efekt by zavedení agregace mělo teoreticky přinést. Podobně jednotliví ISP znají datové toky generované jejich zákazníky, a i z nich by si měli umět odvodit teoretický výsledný efekt. Proč se nyní skutečný efekt tolik rozchází s deklarovaným očekáváním? Není to náhodou kvůli tomu, že agregace skrze mechanismus CAR sice omezuje „objem“ přenášených dat na síťové vrstvě (IP paketů) tak, jak by teoreticky měla, ovšem na přenosový protokol TCP (využívaný například protokolem HTTP) má výrazně horší vliv – tedy že snižuje jeho propustnost podstatně více, než by měla?

Teď se omlouvám méně technicky orientovaným čtenářům, ale bez malé exkurze do odbornějších partií to nepůjde: CAR je technika charakteru tzv. policingu, nikoli charakteru shapingu. Fakticky to znamená, že „nadbytečné“ pakety jednoduše zahazuje (zatímco shaping se snaží nejprve různě „formovat“ datový tok, třeba určitým pozdržením těch paketů, které právě nejdou přenést). Obě techniky se uplatňují na úrovni síťové vrstvy (tj. zahazují nebo zdržují IP pakety), a ovlivňují tudíž chování protokolu IP. Pro fungování aplikací, používaných uživateli, je ale podstatný také vliv, který to má na protokoly vyšších vrstev – zejména na protokol TCP na transportní vrstvě, jenž je využíván i aplikačním protokolem HTTP (v rámci služby WWW).

Protokol TCP je ovšem velmi „propracovaný“ protokol, který se snaží průběžně adaptovat na změny v přenosovém zpoždění a pravidelnosti doručování jednotlivých IP paketů. Díky tomu se dokáže celkem snadno a efektivně vyrovnat s vlivem skutečného shapingu. Mnohem hůře se ale vyrovnává s důsledky policingu, které se projevují výpadky jednotlivých IP paketů. Protokol TCP interpretuje každý výpadek (ztrátu) IP paketu jako důsledek zahlcení, přechází z kontinuálního potvrzování na jednotlivé, a následně teprve postupně přechází zpět na kontinuální potvrzování. Jinými slovy a s větším zjednodušením: když narazí na ztracený paket, prudce šlápne na brzdu, a pak se zase pomalu a opatrně rozjíždí. Když mu CAR takto čas od času (nebo častěji) zahodí nějaký paket, není těžké si domyslet, že celkový „přenosový výkon“ protokolu TCP poklesne, a to třeba i dosti výrazně. No a příčina dnešních problémů může být právě v tom, jak výrazně, resp. jak rychle klesá „výkon“ protokolu TCP s četností ztrát IP paketů. Co když to je tak, že třeba několik málo procent zahozených IP paketů způsobí, že celkový „výkon“ protokolu TCP klesne o celé desítky procent?

V odborné literatuře je tento problém popsán a prostudován. Případné zájemce mohu odkázat třeba na tuto studii, která uvádí konkrétní závislost mezi četností výpadků a chování protokolu TCP a konstatuje, že „výkon“ TCP je extrémně citlivý i na velmi nízkou četnost výpadků IP paketů (méně jak pět procent). To by pak vysvětlovalo i pozorování mnoha uživatelů, kteří zjistili, že různé download manažery dokáží z agregované linky „vymáčknout“ více než třeba obyčejný browser. Mohou totiž různě optimalizovat chování protokolu TCP, který používají ke stahování. Především by to ale mohlo vysvětlovat to nejpodstatnější: proč se někde agregace neprojevuje téměř vůbec, a jinde tak drasticky. Pokud je totiž vztah mezi četností výpadků (zahazování) IP paketů a degradací chování protokolu TCP silně nelineární, což je, pak stačí, aby se „zátěž“ generovaná zákazníky určitého ISP pohybovala někde kolem „bodu zlomu“, kde se tato nelinearita projevuje nejvíce. Pokud je jen málo pod tímto bodem, pak se chování protokolu TCP mění jen velmi málo – ale pokud zátěž naroste, třeba jen nepatrně, může to vyvolat již velmi rapidní degradaci přenosových schopností protokolu TCP.

Řešením může být vhodné „vyladění“ parametrů techniky CAR (která skutečně umožňuje nastavovat řadu různých parametrů a celých strategií, podle kterých dochází k zahazování IP paketů v rámci tzv. policingu). Snad se právě na tomto pracuje (viz zmínka o „ladění parametrů“).

Dalším řešením by samozřejmě bylo použít místo techniky policingu (CAR) vhodnější techniku shapingu, která je obecně šetrnější vůči protokolu TCP. Bohužel ale platí, že shaping je provozně náročnější než policing, tj. Český Telecom by s ním měl více nákladů než nyní s policingem.