Názory k článku Řízení toku algoritmem BBR: buldozer nebere ohledy na ostatní spojení
-
Vlastně to bude takový darwinovský přirozený výběr na internetových linkách. Silnější požere slabší a ti vyhynou...
Když se na to podívám z pohledu operátora, chci řízení toku na lince takové, aby se citili dobře i "slabší" zákazníci. Existuje už nějaká "ochrana", nějaké opatření, jakým udělat linku zpět spravedlivější jak pro uživatele BBR tak pro ostatní? Asi to nebude téma hned na zítřek, BBR budou volit postupně jednotlivci, ale jen do té doby, dokud ho nějaký velký OS nenastaví jako implicitní.
Co shapery? Nedá jim víc zabrat dělat svoji práci? U tradičního TCP congestion control bylo možné se aspoň trochu spolehnout, že "spojení spolupracuje".
A poslední, co mě napadá je, jak budeme řešit na koncích QoS? Tam záměrně naopak nasazujeme další buffery a zvedáme latenci, abychom mohli dát přednost paketům, které považujeme za prioritní. Nebudou QoS mechanismy na straně originátora i v destinaci tak trochu BBR "mírnit"?
-
Nejsem zastánce IPv6, jenom nenávidím NAT.
NAT je technicky vzato peklo. Na druhou stranu, nutnost NATU dostala k zákazníkům statefull firewally a v podstatě z nouze se stala ctnost. Při přechodu na IPv6 vzroste potřeba dobře nastavených firewallů; co dnes "admin" nebo BFU pokazí, to ještě pořád zachrání NAT - směr dovnitř má o překážku navíc. Po přechodu na IPv6 bude chyba admina nebezpečná, pustí provoz až na cílové zařízení.
Druhá věc je, že na NATU nám v postatě vadí jeho statefull charakter a nezvladatelnost udržovat state pro hafo spojení. Jenže: pokud chceme chránit provoz na IPv6, je smysluplným řešením OPĚT statefull firewall. Takže technologický posun bude jen o píď, aspoň co se týče koncového NATU.
-
NAT ale nemá s bezpečností nic společnýho!
Má. Je to v podstatě prvek pasivní bezpečnosti, ale jak jsem psal, z nouze ctnost.
Pokud je na NATU něco nepříjemného, tak jsou to conntrack tabulky, kterým se ale u moderního firewallu pro IPv6 stejně nevyhnete. Jestli je součástí conntracku ještě podsunutí cílové adresy, to už mi přijde jako malý detail.Byly doby, kdy se počítače připojovaly "na ostro" do internetu, měly i veřejnou IP adresu. Nebyly NATY. V té době byly průsery, např. Windows XP přes SP1 měly otevřený firewall a spoustu děr. Už v té době měli "výhodu" ti, kteří byli za NATEM, k nim se hrozby nedostaly.
Takže ano, NAT není prvek aktivní bezpečnosti, ale pasivně tak funguje. Pokud zmizí NAT, bude nutné zajistit, aby neselhal firewall.
-
Petr M (neregistrovaný)
Zatímco bude NAT, bude potřeba zaručit, aby neselhal firewal. Jaký je v tom rozdíl? NAT s blbě nastaveným firewallem se dá tak krásně prostřelit, že by ses divil.
I kdyby bezpečnosti přidal 10%, tak někteří "ajťáci" se chovají, jako kdyby to přidávalo minimálně 80% a na zabezpečení v LAN kašlou se slovy, že "je to za NATem, tam se nikdo nedostane". Žádný FW na zařízení, autentizace v LAN jenom pro rozpoznání uživatele, FW na zařízeních otevřený dokořán, pokud tam vůbec jsou. Pak se nakazí díky phishingu jeden stroj v LAN a dopadne to jako u Maersk.
Bezpečnost musí mít vrstvy, ale na router patří firewall na služby v LAN, který nechceš nabízet ven, jako CUPS, NFS, ... a zbytek by mělo řešit zařízení, tj. otevřeš přímo na komplu pro příchozí traffic jenom jenom porty, na kterých něco běží.
-
null null (neregistrovaný)
Jenom 10% nebo 5%? A některý se dá prostřelit? Tak to se na to klidně vys**** úplně ... Jak to nemá aspoň 50% vynechat ...
To je jako s tím vynucováním HTTPS v browserech: Kolik je lidí co lezou přes browser na "IoT"? Pár procent - kašlem na to, vynutíme HTTPS pro všechny. No to se ale těch pár procent na krabičku nedostane. Aha, tak to nebudeme vynucovat u nikoho. Ale ten zbytek to potřebuje, tak to vynutíme u všech, ale těch pár se tam nedostane, tak to nevynutíme u nikoho, ale těch co to potřebují je jenom pár .....
-
Ono by bylo fajn BRR hodit na IPv6 provoz a IPv4 nechat při starým. ISPíkům s IPv4 by všechno jelo jak doteď a kdo pokročil k modernějšímu systému, vyhraje...
V praxi se setkávám spíš s tím, že IPv6 různým poskytovatelům různě náhodně vypadává. Ono je to tím, že IPv6 je prostě tak trochu na druhé koleji. Když ISP sletí routování IPv4, začíná se makat okamžitě, protože "nejede nikdo". Když spadne IPv6, "svět se nezblázní". Ve skutečnosti to není pravda, když vypadne IPv6, uživateli přestanou náhodně fungovat služby a je otrávený. Jenže: tzv. sporadické nebo náhodné chyby opět nikdo nechce řešit s absolutní prioritou.
Jedinou šancí pro IPv6 je, aby na ni přecházeli velcí ISP. Čím víc lidí pojede výhradně na trasách IPv6-IPv6, tím citlivější bude svět i na malé výpadky.
BRR zavést na IPv6 by v tento moment moc nevyřešilo, IMHO je problém zatím někde jinde.
-
Petr M (neregistrovaný)
Proč ne? Skype není zákonem chráněný.
Pokud by velká firma, která doručuje hodně obsahu, takto preferovala 6ku (stačí na jejich straně, přijímač prostě bude odebírat data), "přetíží" páteř a hotovo. Lidi se začnou dožadovat 6ky u ISPíků, ti ji budou muset nastavit a pokud přijde někdo s VoIPem na 6ce jako náhradou za nefunkční Skype...
-
SB (neregistrovaný)
Ten článek a předpoklady BBR mi přijdou celé nějaké vadné (ale nejsem síťařem, takže mě opravte):
1. Představa, že stačí na začátku otestovat a nadále ignorovat stav linky při přenosu, nemůže fungovat, vytížení spojů a směrovačů po cestě se může z 1000 důvodů nepředvídatelně a rychle měnit.
2. Myšlenka detekovat ne zaplnění bufferu, ale již počátek jeho plnění (tj. detekce problému hned, ne až po jeho eskalaci), je určitě správná (přesun zpoždění frontou ze směrovačů na vysílač), nevidím důvod, proč by nešla použít u původních algoritmů.
3. Doteď jsem měl za to, že směrovače dokážou řídit pořadí zpracování příchozích paketů z několika směrů, pak představa, že jeden tok přijede buldozerem a ukradne si pro sebe celé pásmo, nedává smysl, vždyť by jej směrovač zaříznul. -
Jde o to, že BBR je proti starším způsobům agresivnější a dokáže rychleji a efektivněji vyplnit kapacitu linky.
Pak ale musí následovat druhé zamyšlení: co se stane, když budou BBR používat všichni. I na tuto otázku článek přináší odpověď. Kapacita bude využita efektivněji, než dnes a toky se rozdělí správně v poměru k počtu spojení.
směrovače dokážou řídit pořadí zpracování příchozích paketů z několika směrů, pak představa, že jeden tok přijede buldozerem a ukradne si pro sebe celé pásmo, nedává smysl, vždyť by jej směrovač zaříznul
"Čistý" router, bez QoS nebo bez shapingu tento problém neřeší. Vítězem jsou zcela náhodně ty packety, které se vejdou do bufferu, a poraženými jsou ty, které už ne. Router - ve svém úzkém pojetí - nic na tomto principu neovlivňuje.
K tomu, na co se ptáte, míří i můj první post v této diskusi. Tedy, jak to bude vypadat v praxi, ve které naopak QoS a shaping aplikujeme a vyžadujeme. Nedojde nakonec ke smytí celé výhody tohoto algoritmu na ovládání kongesce?
-
Filip JirsákStříbrný podporovatelPředstava, že stačí na začátku otestovat a nadále ignorovat stav linky při přenosu, nemůže fungovat
Podle toho, co je napsáno v článku, ale takhle BBR nefunguje, zjišťuje stav spojení průběžně (i když ne každým paketem).nevidím důvod, proč by nešla použít u původních algoritmů
Protože původní algoritmy posílají všechny pakety stejně „rychle“, tím pádem nedokážou poznat, zda je buffer prázdný nebo není. Původní algoritmy dokážou poznat přechod od částečně plného bufferu k plnému, možná by za dobrých podmínek dokázaly poznat přechod od průběžného posílání k bufferování – ale nedovedu si představit, že by to fungovalo za běžného provozu, kdy se pořád něco mění. -
Filip JirsákStříbrný podporovatel
Jedině kdybyste měl linku do internetu rychlejší, než co zvládne zpracovat váš počítač.
-
Jedině kdybyste měl linku do internetu rychlejší, než co zvládne zpracovat váš počítač.
To se v praxi stává. Např. od UPC (i dalších) jsou linky tak rychlé, že starší PC, byť s gigabitovou síťovkou, nejsou schopny datový tok zpracovávat.
Tento stav se historicky opakuje, byl při přechodu 10=>100, 100=>1G a dá se očakávat, že bude i při přechodu na multigigabit.
-
Filip JirsákStříbrný podporovatel
Jenže to pak neřeší žádná drahá rychlá paměť do PC, ale prostě aktuální PC. Pokud tu rychlost linky chcete používat z jednoho zařízení.
-
Filip JirsákStříbrný podporovatel
Nikoli, 1 Gbit/s dnes zvládají low-end počítače, nepotřebujete k tomu ty nejrychlejší paměti.
-
Nikoli, 1 Gbit/s dnes zvládají low-end počítače, nepotřebujete k tomu ty nejrychlejší paměti.
Tak to mají holt smůlu ti, kteří si koupili buďto low end před pár lety a stále ho používají. A taky smůlu mají ti, kteří nemají instalaci v ideálním stavu, jedou na rotačních discích a dělají víc práce a 1 Gbit přítoku dat nemají jak zpracovat. Pak už to totiž je o bufferech, a pokud ani ty nebudou stačit, tak mají holt smůlu.
A jsme znovu u toho, jestli technologie má sloužit, nebo buzerovat lidi.
-
Filip JirsákStříbrný podporovatel
Nikoli, jenom nechápete, co co jde.
Když má někdo počítač, který zvládá třeba jenom 300 Mbit/s, a bude mít internetovou přípojku 1 Gbit/s, tak ta data prostě bude přijímat rychlostí 300 Mbit/s. Takže žádné „mají holt smůlu“, žádná buzerace lidí, prostě mu to bude normálně fungovat tou rychlostí, jakou zařízení zvládne. A pokud bude mít na stejné přípojce další dvě zařízení, která budou taky umět těch 300 Mbit/s, tak dokonce i budou moci prakticky vytížit tu 1 Gbit/s linku.
-
Unknown (neregistrovaný)
"Nikoli, 1 Gbit/s dnes zvládají low-end počítače, nepotřebujete k tomu ty nejrychlejší paměti."
Zvladaji co?
- Ukladani dat do pameti? Mozna ano, ale za par vterin pamet zahltite (a proc vlastne?)
- Ukladani dat (treba na HDD)? To rozhodne ne
- Vykreslovani obsahu toku na screen? To zcela jiste ne -
Filip JirsákStříbrný podporovatel
Řeč byla o síťové komunikaci. Pokud příchozí datový tok 1 Gbit/s nedokážete zpracovat, tak je asi nesmyslné se snažit takové rychlosti docílit, a není to problém síťové komunikace, nemyslíte?
-
Filip JirsákStříbrný podporovatel
Jenže pak nemůžete v konkurenčním prostředí BBR "vyhrát" svůj kus pásma. Budete sežrán.
Nikoli.A připadá mi to evidentní, že to tak není – to jste si představoval, že by BBR fungovalo třeba na YouTube jedině tehdy, pokud by všichni uživatelé YouTube dokázali odebírat data přesně stejnou rychlostí, a jakmile by u někoho rychlost klesla, nedostal by nic? A jediný uživatel, který by se připojil k YouTube a dokázal by odebírat třeba 1,1 Gbit/s, prostě o málo více, než všichni ostatní, by celý YouTube prakticky vypnul a měl by ho jen pro sebe?
BBR vyhrává nad algoritmy, které při jakémkoli náznaku problémů rychle zpomalují – protože uvolněné místo hned zabere a nedovolí těm opatrným algoritmům znova narůst. Ale několik BBR spojení vedle sebe nemá problém, protože jsou všechna stejně „agresivní“.
-
A připadá mi to evidentní, že to tak není – to jste si představoval, že by BBR fungovalo třeba na YouTube jedině tehdy, pokud by všichni uživatelé YouTube dokázali odebírat data přesně stejnou rychlostí, a jakmile by u někoho rychlost klesla, nedostal by nic? A jediný uživatel, který by se připojil k YouTube a dokázal by odebírat třeba 1,1 Gbit/s, prostě o málo více, než všichni ostatní, by celý YouTube prakticky vypnul a měl by ho jen pro sebe?
Předně, já se s Vámi nehádám, jen nahlas přemýšlím, co se nastane a rád si přečtu názory.
Ano, máte pravdu, pokud druhá strana nebude ucpaná, tak asi nebude žádný negativní efekt znatelný - a to bude asi většinou. Problém by nastal, kdyby jedna strana (YouTube) měla blízko k zácpě a druhá strana (uživatel) nestíhala. Pak by byl uživatel asi v nevýhodě, protože by nestíhal být stejně agresivní.
Přemýšlím, jestli by byl "nestíhající" uživatel v nevýhodě i v případě, že by bylo ucpáno něco po cestě?
-
Filip JirsákStříbrný podporovatel
Já se s vámi nehádám, pouze opravuji vaše bludy.
Žádný nestíhající uživatel neexistuje.
Tok dat vždy řídí odesílající strana, příjemce jí maximálně může poskytovat nějakou nápovědu, kterou odesílatel může a nemusí brát v úvahu. Při streamování z YouTube může tedy být uživatel agresivní maximálně tak při posílání potvrzovacích paketů. Nenechte se zmást tím označím „agresivní“, které je použité jako metafora pro rozdíl jedné charakteristiky BBR v porovnání s Reno nebo Cubic. Vy jste to nesmyslně zveličil a píšete o tom pomalu jako kdyby pakety řízené BBR cestou napadaly a likvidovaly jiné pakety.
Když už musíte přemýšlet nahlas, tak buď přemýšlejte o algoritmu BBR tedy počítejte s vlastnostmi, který má tento algoritmus, a nebo si přemýšlejte o nějakém svém algoritmu s jinými vlastnostmi, pak ale jasně napište, že je to nějaký váš algoritmus.
-
Petr M (neregistrovaný)
Tak jinak.
BRR si měří, jak rychle se dají cpát data, než se začnou bufferovat, a pak tu rychlost drží. Pokud trasu nesdílí nikdo další a má řekněme 100Mbps síťovku na 250Mbps přípojce a dál k serveru je minimálně 40Gbps, tak prostě bude držet těch 100Mbps. Když za stejné situace bude gigová síťovka, tak se zastaví na 250Mbps.
Pokud se na stejné přípojce přidá další socket, tak začne při měření cpát data do bufferu a bude mít pomalý tok, protože traffic velikosti, kterou vygeneruje, jde do bufferu. Ale nejdou tam jeho pakety, ale i pakety původních spojení a začnou se zpožďovat ACKy. Takže ten první stroj zpomalí, druhý objeví volný místo (potvrzení zrychluje) a to místo si obsadí. Takže BRR s BRR se nějak dohodnou. Dopadne to, jako když máš na silnici zúžení a všichni respektují zip. Doprava se zpomalí, ale nikdo nestojí.
Problém nastane, když někdo přijede, nezná zip a začne čekat, až fronta z vedlejšího pruhu opadne. Ten potom (třeba na dálnici) vůbec nejede, protože čeká, kdo ho pustí.
ČLÁNKY DO MAILU