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í?
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?
Jo, tak... To je zajímavá otázka :-)
Pokud bych s tím měl jako provider problém, tak by multicast pustil asi pouze jedním upstreamem a tím pádem bych si to vyřešil :-)
No a pokud bych to chtěl řešit nějak jinak, tak bych to asi řešil smlouvou se zákazníkem, účtovat by se dalo třeba podle NetFlow dat.
Obavam se, ze doslo k nejakemu zmateni. Ja IPv6 provozuju vsude tam, kde to jde :-)
Co se podpory hacku a carek tyce, berte to jako vrtoch internetoveho starika. Kdysi jsem udelal verejny prisliv, ze zacnu psat do for s hacky a carkami pote, co CZ.NIC zprovozni v domene .cz IDN. A zatim jsem tento zamer nezmenil.
Bohuzel neznam ani vasi sit ani vase systemaky, tudiz se nemuzu moc vyjadrit k Vasemu postoji k nim a jejich odpovedi na Vase pozadavky :-(
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.
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.
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.
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).