Málo kedy dochádza k hrdlu na tom istom mieste v oboch smeroch.
Príklad: optická prípojka 600/600. Pri meraní z mobilu cez wifi bude pri sťahovaní hrdlom wifi časť routra. Avšak pri uploade vzniká hrdlo práve na telefóne, pretože on riadi, čo pošle von a ako dlho čo podrží. To isté bude platné aj pri LTE, sťahovanie riadi eNB na sajte ale pri uploade to riadi telefón.
Doma mám wifi router s OpenWRT 18.06. Ako je známe, implementuje najnovšie výsledky z projektu bufferbloat.net a make-wifi-fast a tak to aj vyzerá. Pri sťahovaní je hrdlom a drží latenciu na pekných 54ms podľa testu, avšak opačný smer už riadi telefón na výstupe a tam vzniká 203ms latencia.
Ale čo ak ide o prípojku, kde sa hrdlom stáva shaping poskytovateľa? Pridajme si ako ďalší parameter do toho celého TCP congestion algortimy, t.j. algoritmy, ktoré majú za úlohu nájsť max. priepustnosť linky, nejak sa pobiť s ostatnými spojeniami na rovnakej linke atď. Je všeobecne známe že staré algoritmy Cubic/Reno sú nenásilné a ako indikáciu plnej linky považujú iba stratovosť paketov. Naproti tomu je algoritmus BBR, ktorý vyvíjal Google a je známy tým, že je agresívny, "fajnovo" zapĺňa buffre a okrem stratovosti berie do úvahy aj RTT.
A teda výsledok: ak si oshapujem mobil na 5M/5M s fifo frontov, pričom mobil pravdepodobne pri uploade používa Cubic/Reno ale náš firemný ookla server používa BBR, stane sa toto:
Agresívny BBR pri downloade "fajnovo" zaplní frontu a teda latenciu dvihne na 280ms, avšak Cubic/Reno z mobilu je "nenásilný" a teda latencia je 48ms.
No a teraz urobme to isté, ale shaping 5M/5M urobme s frontov SFQ. Proste rovnosť pred zákonom 😃
Toľko moja vsuvka 🙂
