Názory k článku IPv6 Mýty a skutečnost, díl VII. - Podpora Multicast a anycast provozu

Nastesti.

Jednoduše. IOS od Cisca, ani jiná rozhraní pro konfiguraci síťových prvků, českou klávesnici nevyžaduje.

Můžete mi někdo vysvětlit, jak chcete provozovat (a instalovat) IPv6, když jste se ještě nenaučili, jak si úspěšně nainstalovat českou klávesnici? To hned člověk bere všechny Vaše řeči o IPv6 velmi věrohodně. Asi jako když já jsem několik týdnů škemral i systemáků, že přístup přes IPv6 je znatelně pomalejší než přes IPv4. To bylo věrohodných výmluv a odkazů, až jsem věc vyřešil tím, že jsem IPv6 na svém virtuálním počítači zakázal. Jako kdybych tady četl jejich pseudoodborná vysvětlování (samozřejmě také bez háčků a čárek).

Ad a) – A kdo to několikanásobné posílení kapacity infrastruktury zaplatí?

Ad b) – To stahují všichni najednou? A bez nějakého zabezpečení, že si tu aktualizaci může stáhnout kdokoli?

Akorát ukazujete, že by pak multicast chtěl opravdu každý – už tady padlo, že by se to používalo k šíření informací o stavu on-line hry, vy jste teď přišel s tím, že by se takhle šířil software, někdo další by určitě přišel s tím, že se takhle budou šířit RSS kanály… Představte si tu režii spojenou s miliony celosvětových multicastů.

a) sireni multicastu by melo fungovat uplne bezne a od kohokoli
b) je videt, ze vubec nemate ani tuseni, co se deje kdyz vyjde aktualizace nejake hry - stahuji ji miliony lidi, po jedine lince klidne muze bezet 1000x totez a v principu naprosto zbytecne

Představte si, že by si takhle o šíření multicastu v celém internetu požádal kde kdo, a pak by se tím šířila data k pár desítkám uživatelů (v tom lepším případě). Teda nešířila, protože režie s tím spojená by internet dávno položila. Využití téhle služby má význam, když podíl odběratelů přesáhne určitou kritickou hranici, na to nemá nějaká hra v životě šanci dosáhnout.

Az na to, ze zakaznik si prevazne nekupuje linku k providerovi, ale od nej ven

Jistě. V případě unicastu jsou si ale obě linky kapacitně rovny. Tok na vstupu (u klienta) a na výstupech (uplink konektivita) se rovná. Takže není nutno tohle rozlišovat. Někdy se řekne "garantovaná kapacita 1Gb/s - NIX, 100 Mb/s - nějaký transit". To je triviální ošetřit a měřit.

V případě multicastu ale dochází k multiplikaci toku na infrastruktuře operátora. V případě "1 multicast vs. tisíce unicastových", což bude obvyklé, máte pravdu - je to výhodné. Ale v případě "1 unicast vs. 1 multicast" je to problém, resp. je potřeba k definici služby přikročit jinak, zavést nějaká dodatečná omezení.

Skutečně pak už musíme mluvit o tom, že si kupuju konektivitu ven, a že se např. měří 95 percentil. A ten se neměří na mém interfacu, já ho vlastně vůbec měřit nemůžu a neovlivním ho. Musí se měřit jako součet "mých" toků na všech upstream rozhraních. Technicky není problém. Ale definovat to obchodně je trochu horší.

V nejhorsim mysletelnym pripade to vyjde nastejno jako unicast.

Konkrétně - dnes si kupuju 1000Mb/s okruh za fixních X měsíčně s tím, že je to vyhrazená kapacita do NIXu, pro tranzit je garantovaná kapacita např. 200Mb/s (může a nemusí chodit rychleji) + třeba 500 Mb/s do DE-CIX. Triviálně definovaná služba, snadno pochopitelná a realizovatelná. V nejhorším od mého providera odtéká 1000Mb/s - nějak rozdělených přes ty 3 uplinky.

Teď do toho povolím multicast. V nejhorším případě může téct 1000+200+500. Tj. to tedy nevyjde nastejno. Pokud by to byl trvalý stav, měla by taková služba být logicky dražší než předchozí (bez mcastu). Můžeme diskutovat, že v tomto případě je to extrém, že to nebude obvyklé, a v poměrech NIXu to nevadí. Nevím. A proto se ptám, jestli existuje analogická jiná situace, která je reálnější, a která je důvodem, proč multicast nebude asi obecně nasazen. Tento typ problémů bych očekával, že bude výraznější u Tier1 operátorů, ale tam nevím, jak jsou nakupované služby definovány a jestli by se takováhle situace musela extra řešit.

Az na to, ze zakaznik si prevazne nekupuje linku k providerovi, ale od nej ven + k nemu (muj ISP mi garantuje konektivitu do NIXu, nikoli na svuj switch), kde ta posledni mile ma vetsinou nasobky realne zakoupene kapacity a identifikovat traffic od zakaznika neni nijak zasadni problem.

Takze prekrocit zakoupenou kapacitu mu to nedovoli v zadnym pripade => plati to, ze ISP na tom muze leda usetrit.V nejhorsim mysletelnym pripade to vyjde nastejno jako unicast. (a ano, predpokladam ze ISP neni debil a ze ma konektivitu osetrenu jeste jinak nez fyzickou rychlosti rozhrani)

Totez plati pro ruzne specielni pripady jako trebas NIX, kde je jiste vyhodnejsi routovat jeden multicast stream nez tisice unicastovych.

Divate se spatne, pro ISP je to naopak vyhodny, protoze usetri.

Rekneme ze budete vysilat 1Mbit unicastem, ISP ma rekneme 10 linek kamsi a vy mate 100 zajemcu o vysilani. Pro jednoduchost predpokladejme, ze kazda linka vede k 10ti zajemcum => kazdou linku ISP zatizite 10Mbity provozu (vasich 100Mbit celkem).

Pokud provedete totez v multicastu, tak po kazde lince pobezi jen jediny Mbit misto deseti. Tudiz vy usetrite 99Mbit a ISP 90Mbit provozu.

To je právě škoda. Takhle si distribuovanou síť musím realizovat buď tak, že všichni prostě posílají všem, nebo pomocí úrovní kvality připojení, kdy jsou uzly, které posílají jednomu a ten to rozesílá spolu se svými daty a to na další uzly, které to třeba zase přeposílají dál.

Zajímavá služba, ale pro běžné použítí naprosto k ničemu. Jo, maximálně na to video

Nejefektivnější to je. Ale problém je v tom, jak takovou efektivnější službu účtovat.

Představme si ISP, který mě jako firmu připojí linkou o např. 100 Mb/s. ISP je připojen na několik upstream sítí - NIX, několik privátních peeringů, nějaký Tier1 operátor. A teď co se stane v okamžiku, kdy mě připojí: 1) bez multicastu to znamená, že zatížení všech upstream linek mu stoupne v součtu maximálně o 100 Mb/s; 2) budu-li mít možnost multicastu, pak můžu každou jednu upstream linku zároveň(!) zatížit těmi 100 Mb/s.

Evidentně při povoleném multicastu může nastat situace, že náklady na "stejnou" službu (100 Mb/s konektivita pro mě) jsou pro ISP větší než bez multicastu. Nebude-li to zanedbatelné, je třeba najít nějaký model zpoplatnění. A ptám se - je to vymyšleno, jsou s tím nějaké zkušenosti, nebo to je velký problém?

Slyšel jsem, že krom jiných potíží existuje pro tranzitní operátory jeden důležitý důvod, proč je multicast problematický - např. když mám u operátora (nebo v nějakém IXP) 1Gbps port, tak u unicastu funguje princip "co nateče, to vyteče" - tj. "můj" provoz na všech ostatních portech v součtu bude max. 1Gbps. V případě multicastu ale můj 1Gbps může operátorovi vyvolat v součtu několikanásobný tok na mnoha propojích k jiným operátorům/zá­kazníkům. Jak velký je/by byl tento problém v praxi? Resp. existuje na to nějaké řešení?

Jeden čas jsem si myslel, že bych na multicastu vyvinul protokol pro komunikaci v multiplayerové hře. Ovšem postupně jsem se dozvěděl že na IPv4 to bude docela problém. Prostě nemůžu si jen tak někde založit multicastovou skupinu a využít ji k zasílání updatů formou všichni všem.

Pochopil jsem to tak, že ani v IPv6 není nic takového možné?