Vlákno názorů k článku Proč nebyla Lupa včera dostupná ze sítě UPC? od Trident - Zapominate dodat: - vyhotoveni projektu plus nasledne upravy dle...

Zapominate dodat:
- vyhotoveni projektu plus nasledne upravy dle jednani viz. nize
- koordinace s jinymi majiteli dle mapy inzenyrskych siti
- dojednani prelozek kolidujicich siti a nasmlouvani mezi kravataky
- zamereni geodety
no na neco jsem urcite zapomnel nebot je toho celkem dost
Jenom stavebni projekt ke schvaleni muze lezet dele nez 4 mesice na stavebnim urade!
Cili jenom samotny papirovani a naklady s tim spojene jsou balik. A to jeste nikdo nekopnul do zeme!

Proto vzdycky nadavam co za ichtyla co dela projekt na vymenu plynovych trubek v cele ulici, ale nedomluvi se s mistnim ISP aby treba prihodili chranicku s optikou.

Coz o to frajer muzu byt a legislativu ignorovat jen pokud jsem ochoten jit do rizika ze mi kombajn preryje nezakresleny kabel a pokud podle mapy siti neprekopnu nekomu sit/produktovod.
Totiz i v pripade bezdratovych pojitek muze velice snadno dojit k zastineni stavbou nebo jako v mem pripade satelitni antenou. Ochranne pasmo RR trasy totiz malym isp pytlikum nic nerika.

To ze dotazeni kabelu na sidliste nic nestoji to snad nemuze rict ani "prazak" ktery ma "vodu ze zdi a elektrinu ze zasuvky".

I kdyby... 99us je nejaky velky problem? :-)

Dovolil jsem si ji zanedbat. Na potvrzeni faktu, ze zpozdeni aktivniho prvku je max. v radu desitek mikrosekund to staci - nebo ne? ;-)

Tak z pingu nize jsem Vam demonstroval RTT ~ 800 mikrosekund. Pres osm viditelnych hopu, devaty je ten cilovy server. Predpokladam, ze Vam nebude cinit urcit si prumerne zpozdeni boxu pri znalosti faktu, ze kazdy paket jde tam i zpet... ;)

Aktualne ze serveru v Masteru na server v UPC...

20 packets transmitted, 20 received, 0% packet loss, time 19059ms
rtt min/avg/max/mdev = 0.807/0.842/0.869/0.033 ms

Vidite tam nejaky zasadni problem? Me tech 800 mikrosekund v souctu cele trasy (pres Dial) prijde z pohledu rtt naprosto v pohode... vam snad ne?

Tak to nevim, zpozdeni nad touto hodnotou nejak nepozoruji:

64 bytes from info.nix.cz (195.47.235.3): icmp_seq=1 ttl=90 time=0.949 ms
64 bytes from info.nix.cz (195.47.235.3): icmp_seq=2 ttl=90 time=0.958 ms
64 bytes from info.nix.cz (195.47.235.3): icmp_seq=3 ttl=90 time=0.971 ms

Jiste, ze traceroute neni uplne spolehlivy udaj, o tom se nepru. Nicmene informativni udaje poskytuje a ty pro nejakou zakladni predstavu v danem pripade postaci.

Ja samozrejme nemohu vedet, jakou vzdalenost mate momentalne na mysli :-) Posledni informace, urcujici delku trasy, byla, cituji "když cesta optikou přes republiku trvá max. 0.2ms". Samozrejme, ze tam ty smerovace nejake marginalni zpozdeni vytvori, ale opravdu chcete povazovat za degradaci sluzby to, ze namerite po Praze odezvu ne 0.7, ale 0.9 ms?

Jiste. A tam to jsou ty desitky, ve vyjimecnych pripadech stovky mikrosekund, coz je oproti zpozdeni na kabelech na delsich trasach zcela zanedbatelne. Jestli chcete dukaz, zkuste si traceroute nekam po Evrope (alespon tak 500 km, at tu latenci muzete videt i pouhym okem) a pak porovnavejte umisteni jednotlivych hopu a rozdily v odezvach. Dokonce se muzete dockat i toho, ze v traceroute budete mit na vzdalenejsi router o neco malo mensi latenci nez na router blizsi... :-)

A on nekdo tvrdi, ze CRS-1 je spickovy box z hlediska latence? Naopak, se slozitosti (a velikosti bufferu ta latence poroste), tedy tech 100 us bych povazoval za mezni hodnoty i pro nizsi rady.

Dukazem z opacneho konce produktoveho spektra budiz pomerne jednoduchy L2/L3 switch od Aristy s vyrobcem udavanou latenci 600 - 1200 nanosekund.

Ale porad jsme radove na max. desitkach mikrosekund. Zadna tragedie se nekona...

Naucte se pocitat a udelejte si nejaka realna mereni. Jinak se o tom vubec nema vyznam bavit.

no, tak se naucte trochu pocitat :-)

jednak c = 300 000 km/s, coz je 300 km/ms. pokud to merite pingem nebo traceroutem, musite pocitat dvojnasobek, protoze se pocita cesta packetu tam i zpatky. To jsme na 150 km/ms. Pak tu mame takovou hezkou vlastnost sklenenych vlaken, jimiz se nesiri signal rychlosti c, ale c/index lomu, pricemz index lomu u skla je 1.4 - 1.9, v optickych kabelech nastesti spise nekde kolem te nizsi hodnoty... To jsme na nejakych 100 km/ms. Pripoctete si kompenzaci disperze a to, ze kabely nejdou uplne rovne, spis ze jdou vetsinou poradnou oklikou a jsme na realnych cislech, coz je nejakych 80 km/ms...

Tak, ted uz se mozna nebudete tak nevedome usmivat... :-)

To, ze cesta optikou pres republiku trva max 0.2 ms, vas oponent rozhodne nepsal, to mu vkladate do ust vy (coz je z hlediska seriozni diskuse celkem tezky faul a mel byste se za nej stydet). Psal, ze pres jeden box ten packet projde za pomerne kratkou dobu, ja bych si jej dovolil doplnit v tom, ze ta doba je tak kratka, ze ji vas pocitac ani nedokaze spolehlive zmerit...

(a ano, "ty milisekundy" odezvy se berou zejmena v dalkovych optickych kabelech, po nichz ovsem diskutovany traffic vubec nejde)

To nic nemeni na faktu, ze je fuk, zda ty tri prvky vidim, protoze bezi v rezimu Layer3 routeru, nebo nevidim, protoze bezi jako Layer2 switche (popr. MPLS, ktere je nekde mezi L2 a L3). To zpozdeni vytvori tak jako tak. V ramci jedne aglomerace pujde max. o stovky mikrosekund rozdilu a je uplne jedno, zda puvodcem zmeny je switch pridany do cesty ve vlastni siti, nebo router v jinem autonomnim systemu...

Nejvetsi polozkou je prave to dotazeni kabelu na sidliste. Zvlast kdyz se musi zakopat, a zaves neprojde. Samozrejme, bavime se o legalnim polozeni kabelu, ne o cernych stavbach nerespektujicich platnou legislativu, jak maji nekteri "frajeri" ve zvyku.

No jestli natažení "drátu" ani provoz nic nestojí a od UPC každý uteče, tak proč už dávno nejsou všechna sídliště zadrátována jinými operátory?

Že by to bylo proto, že je to ve skutečnosti jinak?

Pocet hopu nevypovida o latenci. Jak uz jsem Vam jednou rekl, to jestli sitovy prvek v traceroute vidite ci nikoliv zalezi ciste na designu te dane konkretni site. Kazdy sitovy prvek nejakou latenci vklada bez ohledu na to, zda jej v traceroute vidite ci nikoliv, vliv ma samozrejme i rychlost sireni signalu.
Nicmene v tomto konkretnim pripade k zadnemu dramatickemu Vami naznacovanemu zhorseni dojit nemohlo a nedoslo, jednoduse proto, ze provoz zustal fyzicky stale v Praze, mozna dokonce v ramci tehoz telehouse. Nevim, proc do toho hned tahate Australii, zkuste se prosim nejprve seznamit se skutecnym stavem veci, nez budete zase mudrovat... ;) A resit mikrosekundove rozdily je opravdu nesmysl...

Ehm ... kolik stoji zasitovani sidliste per user? 00 nic? A nevsim sem si, ze by UPC melo kabelove site jinde, az na par koupenych vyjimek.

Jaky sou naklady na provoz toho kusdratu? Zjevne taky 00nic, support neposkytuje UPC taky zadnej ...

A mimochodem, pokud se uz nejaky naivista najde a dotahne do lokality svuj kabel, tak je zajimave, jak dobre 30% lidi utece od UPC hned a ten zbytek postupne.

Ale, to je pro me novinka ze kvalita/parametry linky nejsou ovlivnovany pocty hopu ... hmm, tak ja si tech par Gbibit poslu pres australii, bude to mit sice latenci 500ms, ale co, to o kvalite nerozhoduje ... Sak pres australii ty site vidim taky, tak proc ne.

Pocty hopu v traceroute pocitaji mozna tak gamesnici, bezni lidi kolikrat ani nevedi, co to traceroute je. Stejne tak provozovatel velke site pocet hopu neresi - z pohledu kvality sluzby je to nezajimave kriterium, navic zalezi na designu site jako takove - to ze sitovy prvek v traceroute nevidite jeste nedokazuje, ze tam neni...

Zkuste chvili pracovat v nejake velke firme s tisicovkami zamestnancu, pokud mozno mezinarodni... to co popisujete se v ruznych obmenach najde v kazdem velkem korporatu.

Zrejme... mozna byste si mel udelat vylet do Prahy do jejich HQ :)

Nikdo nemá všechny zdroje ve své síti. Ostatně pro AS 6830 čtu na http://www.peeringdb.com/view.php?asn=6830 Traffic Ratios Balanced

Vyvážená? To si možná myslíte Vy, druhá strana si může myslet něco jiného.

Uvědomte si jeden zásadní rozdíl - zákazník UPC většinou těžko přejde k jinému ISP, protože nikdo jiný nebude investovat takové sumy peněz na dotažení kabelů ke koncovým zákazníkům. Zatímco vaši zákazníci se můžou do jiného hostingu přesunout velice snadno. Mimo jiné proto, že natažení pár metrů optiky nic nestojí.

Ale to je celkem jedno, co si kdo myslí, hlavní je to, že se každý snaží minimalizovat náklady a pak závisí jen na vyjednávacích schopnostech a síle.

Jestliže je to tak (nevím), že je pro UPC výhodnější platit tranzit než peeringovou linku, tak nemají žádný důvod se připojovat přes ten peering. Naopak pro MI je ten tranzit mnohem dražší a tak ten důvod má. Takovou situaci perfektně řeší platba MI UPC ve výši, která se vybalancuje tak, aby peering UPC už nevycházel méně výhodně, než tranzit, a přitom aby to bylo pro MI stále výhodné. Tedy win-win.
Nemůžete jenom lízat smetanu.

Jasne, az na ten detail, ze jeden ma o par hopu navrch a vi buh co tam kde v ceste je a co tam je kde nastaveno a jake toky tam tecou, ze.

Dle mych (velmi internich) informaci je jakakoli cinnost kolem siti v UPC vsechno, jen ne organizovana.

Viz napr vymena funkcniho DHCP "zadarmo" za nefunkcni bastl (tusim loni/predloni) za spoustu penez na zaklade toho, ze se managorum libily obrazecky.

Situace, pri jedna ruka nevi co dela druha je pak naprosto bezna vec - napr situace kdy vam na te parodii na support tvrdi, ze vase linka funguje, nacez diky kolegovi zjistim, ze v oblasti je nefunkcnich nekolik ulic ...

Jiste, ale zrejme jej prakticky nikdo nevyuziva, jinak by nemuseli resit problem peeringu s ostatnimi - ostatne ono se neni cemu divit, kdyz zajistuji konektivitu jak zajistuji.

Opakuji to stale a je to i v clanku.

Pristupovy ISP ma svoje zakazniky, co pristupuji k Internetu a vyuzivaji obsah, prevazne obsahovy ISP napr. MAI ma sve zakazniky s obsahem v DC a je rad za navstevnost. A ted kdo ma komu za co platit v pripade vzajemneho peeringu jedna-li se pouze o narodni CZ data?

Podle naseho nazoru je situace vyvazena a to by mely odrazet i podminky peeringu...

UPC zrovnatak nepeeruje - at uz v NIXu, nebo naprimo - se vsemi sitemi, kde je ve vyznamnejsim meritku hostovan nejaky obsah. Oni alternativu meli v podobe peeru s Dialem, tak asi nemeli duvod neco extra resit...

Mam dva peery do dvou siti, oba na 10Gbps rozhrani. Jedna ze siti je viditelna z obou rozhrani. Po kazdem neco tece. Kdyz aritmeticky sectu toky na obou rozhranich, vyjde mi ze mi postaci jedno 10Gbps rozhrani, tudiz muzu jedno rozhrani usetrit a pouzit jinde, kde je vic potreba. Kde je ten pruser...? ;-)

A to si opravdu myslite, ze u UPC zadne servery hostovane nejsou? ;) UPC server hosting take nabizi...

Tohle bych osobne videl nasledovne:

Zodpoveny admin se pokousel nezodpovednemu managorovi vysvetlit, ze to bude pruser. Nezodpovedny managor stale tupe opakoval ze ne a ne, ze to ma odpojit, nacez to dal adminovy jako prikaz. No a admin si rek, OK, at si to pekne vyzerou, tipnem to vecer, kdy to nikdo resit nebude a rano budou rvat lidi.

Vsak UPC nic nebrani spustit vlastni hosting a hostovat si sluzby, o ktery maj zakaznici zajem.

Nebudu zverejnovat veskere casy, znovu ale rikam, ze finalni potvrzeni depeeringu prislo s velmi kratkym casovym usekem dopredu, obrazek si muzete udelat podle casu dosle nabidky, ktery jsem jiz zverejnil a i toto povazuji za kratky cas pred odpojenim.

Opet opakuji, nevedeli jsme jak situace bude dlouho trvat, proto jsme tak technicky reagovali.

MAI se snazil najit reseni, UPC pouze vyckavala...

Znovu rikam, jde zde o princip, protoze UPC neni jediny pristupovy ISP u nas ..

Ty casy odpojeni bych az tak neresil, to mohlo byt proste tak, ze zodpovedny admin se k reseni ticketu treba driv nedostal a deadline mel danou...

Tech nekolik dnu nemelo byt zvelicenim skutecne situace, ale maximalni predpoklad pro MAI pro vypocet vicenakladu ktere to muze zpusobit

A vzdy veci kolabuji v 10 vecer ci podobne silenem case, ale stacilo to resit rano nikoliv okamzite nesmyslnym oriznutim kapacity alternativni trasy, nechat sebou cloumat emocema, pocitem ublizenosti ci cimkoliv jinym je proste neprofesionalni.

Mimochodem me UPC omylem ustrelilo konektovitu ve ctvrtek v bajecnych 12:13:14, do jedne jsme to vyresili a v sobotu vecer to nekdo aktivni zkousel nejak upravovat a spadlo to pro zmenu ve 22:15:10, takove veci se prece nam vsem stavaji a vdycky musi byt na prvnim miste zakaznici.

Ten problem trval cca 12 hodin, ne nekolik dnu. Pak uz k nejake naprave doslo (byt asi ne zcela dle predstav MAI) doslo. Zas bych se drzel objektivnich faktu a nezvelicoval. Navic v deset vecer se obecne tyhle veci resi hure. Jasne, meli lepe informovat, ale to je debata z jineho soudku :) Jasne, doslo k podceneni rizik - ale to se obcas stane kazdemu.

upozornim, ze toto je muj prvni prispevek, ac se to tak podle diskuze nezda ...
Inu, nevyhoda "anonymnich" diskuzi... muzeme jen spekulovat, kdo se tedy podepsal za Vas, co si myslim ja si necham pro sebe :)

Argumenty UPC o neplneni podminek peeringu jsou maskovani kroku pred verejnosti, tyto podminky si UPC upravuje pole potreby a nam je jinkdy nepredlozilo.
Ne, to je moje soukroma spekulace, kterou jsem do diskuzi vypustil sam :) Peering policy si upravuje kazdy prubezne, neni to nic neobvykleho. Je otazkou, nakolik jde o ucelovy bic a nakolik o plosne aplikovane kriteria.

vyuzilo silnejsi pozice tak, by data MAI tekla vyhradne do tranzitu
S Dialem myslim stale peeruji. Myslim, ze to mohla byt i jejich technicka motivace - vase AS videli "zpoza rohu" i od jineho peering partnera v Praze, stejne jako Vas. Nektere velke site s timto argumentem i peering navazat systematicky odmitaji - at uz formalne ve svych policy, nebo v reakci na explicitni zadost o propojeni.

Jediny krok, ktery jsme mohli okamzite ucinit je, snizit technicky propustnost pro data UPC pres zahranici, netusili jsme v case, jak dlouho situace bude trvat, aby cca 7Gbps provozu neteklo drazsi destinaci, a zacali hledat dlouhodobejsi reseni.
No, a snizeno to bylo prave az moc brutalne :) Jasne, to je Vase vec - ale trosku me zarazily jednostranne zpravy, ktere se prakticky okamzite zacly sirit. A ty informace (z odkazu) dotycni nemohli mit ze sve hlavy... jen tam bylo zamlcen predchozi neuspech v jednani a jakoby to melo vybudit dojem, ze UPC konalo zkratkovite ze dne na den... na druhou stranu si vazim toho, ze jste verejne vystoupil a ty informace doplnil. Cimz z toho vzniknul nudny (byt neprijemny) depeering ;)

Nebudu holandany podezirat z toho ze by mysleli na sve zakazniky, neb je pravidelne nasiraji nesmyslnymy vymysly jako napriklad corporatem narizeny prechod na Derby, odpojovani platicich zakazniku{opa­kovane} na zaklade chyb v administrative, atp., ale v tomhle jsou nejspis nevinne protoze postupovali vicemene standardne a predpokladali ze to nebude mit vliv na zakazniky, protoze normalni je mit vzdy zalozni cesty byt kapacitne slabsi coz by omezilo kvalitu, nikoliv dostupnost sluzeb.
Ale druha strana to pojala tak ze je lepsi vykaslat se na zakazniky obou stran a nedat radove tisice kc navic za drazsi cestu po nekolik dnu.
Fyzicky kapacita dostupna byla, vzdy se nasmlouvavaji nasobky realneho trafficu a stacil par telefonu.nebo mailu na vyrizeni docasne zalozni cesty. Ve finale to nemuselo stat navic nic protoze stejne nakonec museli tyhle kapacity nasmlouvat dlouhodobe.
Hlavni problem je v postupu MAI nikoliv UPC.
Stacilo chtit situaci korektne vyresit a dohodli by se s UPC ci jinym partnerem bez ztraty hvezdicky.

"byly by servery hostované u M.I. přístupné pro uživatele UPC nebo nebyly?"
" odpověď asi bude "Ano"."

Samozrejme... Na takto polozenou otazku se totiz jinak, nez "Ano", odpovedet neda... :-)

My se taky dohodneme, všechno chce svůj čas :o)

Ten obrovsky skok v utery neni zpusoben depeeringem MAI, ale tim, ze do agregovaneho grafu UPC se dostaly i data puvodniho Sloane, ktera drive byla vedena odelene.

Problematika toho, kdo by mel platit komu se resi uz pekne dlouho. Drive to byly poskytovatele obsahu, kteri si nechavali platit. Jenze pak jejich zisky sli nahoru, zatimco na vlastni konektivite se vydelava stale hur a hur... DC je nekde mezi obema a osobne nebudu rozporovat Vas nazor, ze ty naklady budou zhruba podobne. K cemu se ale asi smeruje je vytazeni penez z poskytovatelu obsahu... a treba i pres ty DC, kterym poskytovatele obsahu plati za sve pripojeni - a tyto si rozumne rozdelit mezi provozovateli DC a provozovatelich pristupovych siti...

To jim zase krivdite. Nejaka omezena dostupnost tam byla. Problem je, ze s 80% packetlossem se TCP vyrovnava ponekud hure a vetsina jeho implementaci drive vyhnila na timeout, nez doslo k doruceni kyzeneho obsahu...

Vyse dva zmineni se nakonec nejak dohodli. A nutno rict, ze ku prospechu veci, data z Telie do Cogentu uz nebezi az do Ameriky, ale otoci se ve Frankfurtu.

Jenze UPC zadna data pres Jizni Ameriku nedorucovalo. Poslalo je v Praze na Dial, se kterymi ma take primy peer. Me je taky jedno, zda data dorucuju na peer A ci peer B. Snazim se u toho jen zohlednovat delku cesty a uzit tu co mozna nejkratsi dostupnou, coz myslim UPC udelalo take.

Takže jste to vyřešili tak, že místo aby byla omezená dostupnost, tak nebyla žádná :-) Jsem si jistý, že to všechny zákazníky, kteří si zaplatili za garanci dostupnosti, opravdu potěšilo.

- chapu ze vas to nezajima, ale toto byl argument k polemice, kdo by komu mel platit za obsah, protoze podle naseho nazoru investicne a provozne je srovnateleny provoz DC a pristupove site

- pokud chcete byt konkretnejsi, UPC zacalo 30 dnu predem prezkoumavat podmoniky peeringu, ne ze by primo peering vypovedelo a ve 23:39 31.08.2011 dorazila jejich prvni obchodni nabidka ...

- pokud jste dobre cetl co jsem napsal, casove jsme netusili, jak dlouhou dobu zabere realizace nahradni trasy za perimy peering zalohovany NIXem, tak jsme omezili data, toto uz jsme vysvetloval z technickeho a obchodniho hlediska v predchozim prizpevku. Nejaka media nas opravdu nezajimala, pokud bychom chteli situaci dale hrotit, tak bychom v omezenem provozu cekali na reakci UPC, naopak jsme do rekonfiguraci smerovani u Dialu pustili data do nich. Pouze jsem konstatoval, ze UPC bylo pod tlakem zakazniku a medii, protoze mi to sami sdelili.

Resite situaci, ktera vubec nenastala, naopak nastalo, ze jsme vec resili a chteli resit, protoze narozdil od UPC prodavame sluzbu s garanci dostupnosti.

Zeptám se úplně jednoduše: Kdyby UPC provedlo to, co provedlo, a Master Internet nereagoval nijak, byly by servery hostované u M.I. přístupné pro uživatele UPC nebo nebyly? Odpověď pro mě určuje pachatele.

Článek a některé komentáře (použití Opera Turbo nebo TORu) mě vede k závěru, že odpověď asi bude "Ano".

Všimněte si, že se vůbec nezabývám tím, proč došlo k ukončení peeringu. To je obchodní záležitost mezi UPC a M.I. a mě do toho nic není, i kdybych snad měl možnost se k nějakým objektivním faktům dostat.

Záložní session byly v NIXu s dostatečnou rezervou kapacity, takže data by tekla tam. UPC ale ukončilo spojení i v NIXu.

Ale, ale to jsou mi silná slova. Cogent a Telia taky skončili ? Že jsem si nevšimnul.

Co by dělal MAI v okamžiku, kdy by na té peeringové lince k UPC došlo k poruše - závada portu(ů) na směrovači, fyzické narušení trasy apod.? Taky by došlo na: "snizit technicky propustnost pro data UPC pres zahranici, netusili jsme v case, jak dlouho situace bude trvat, aby cca 7Gbps provozu neteklo drazsi destinaci, a zacali hledat dlouhodobejsi reseni"?

Od datacentra očekávám redundantní síť v tom smyslu, že když kterákoliv trasa vypadne, bude síť schopna tento provoz okamžitě(!) vykrýt jinudy. A ne že víc než jednotky hodin budou některé části internetu nedostupné, protože by to teklo drahou linkou a dohaduje se na rychlo jiná...

Zvláště pak, pokud mi DC prodává garantovanou konektivitu do zahraničí. Ať pak UPC považují za zahraničí, ale ať to jede apoň tak, a ne že vůbec.

Pro mě je tohle jasné mínus pro Master při rozhodování o výběru českého DC.

Pokud dobře čtu tak šlo hlavně o to aby data nešla tranzitem.
UPC si ze své pozice klidně může doručovat data přes Jižní Ameriku.

Je to jako když voláte na zpoplatněné číslo a nemůžete se tomu hovoru vyhnout :-) tak ho aspoň přiškrtíte.

Když to beru logicky být na straně UPC tak nevymejšlím takový kraviny - pokud k tomu nemám závažný důvod. (třeba nějakej je - nevím - stejně nám ho neřeknou).

Bejt na straně MAI udělám naprosto to samé co udělali.

Někdo by to uměl řešit lépe? Sem s tím :-) jsem zvědavost sama.

To že jeden vydírá druhého je jasné, nicméně odpojení bylo ze strany UPC.

"Jak UPC musi investovat do tras, tak i MAI musi investovat do vystavby datacenter."

- me, jako zakaznika, nezajima, jake ma kdo naklady. Pokud se MAI a UPC nedohodli na podminkach peeringu, je na obou stranach, aby si zajistily nahradni trasu. Faktem zustava, ze UPC ji melo a MAI zcela zamerne ne.

"UPC ucinilo prvni krok a to, ze se rozhodlo s nami ukoncit privatni peering ve velmi kratkem case"

- nepochybne tomuto kroku predchazelo nekolikamesicni jednani a asi i nejake ultimatum. Jenom hodne naivni clovek by veril, ze to probehlo ze dne na den. A cirou nahodou presne s koncem mesice.

"Jediny krok, ktery jsme mohli okamzite ucinit je, snizit technicky propustnost pro data UPC pres zahranici, netusili jsme v case, jak dlouho situace bude trvat, aby cca 7Gbps provozu neteklo drazsi destinaci, a zacali hledat dlouhodobejsi reseni. S UPC jsme samozrejme byli v kontaktu, i ti zacali vnimat tlak zakazniku a medii a postupne upravovali sve podminky. Situace ustala, kdyz MAI postupne uvolnil provoz po rekonfiguraci site a site svych partneru a UPC dale netrapi."

- takze MAI umyslne omezil propustnost, aby nemusel za data platit. A vyvinul medialni tlak na UPC, aby ze svych podminek ustoupila.

Myslim, ze vetsina lidi si udela obrazek, kdo ve skutecnosti bral zakazniky jako rukojmi.

Jeste si dovolim rekaci, koho si koho bral za rukojmi.

Podle naseho nazoru UPC sve zakazniky, protoze za sebe vypovedelo funkcni primy peering a nehlede na nasledky pro sve zakazniky s kvalitou sluzby, slo do tohoto rizika a sledovalo pouze obchodni cile. UPC bylo o nasich nutnych technickych krocich samozrejme dopredu infomovano.

Zdravim zde vsechny diskutujici,

upozornim, ze toto je muj prvni prispevek, ac se to tak podle diskuze nezda ...

Rad bych uvedl nektera tvrzeni na pravou miru, MAI UPC nikdy za peering v ramci NIXu neplatila. UPC se rozhodla zpoplatnit CZ data od MAI v ramci CR na urovni cen levnejsiho zahranicniho transitu, je to obchodni vec, nasi zahranicni partneri nam potvrdili, ze UPC jinak provozuje v zahranici peering bez omezeni. Argumenty UPC o neplneni podminek peeringu jsou maskovani kroku pred verejnosti, tyto podminky si UPC upravuje pole potreby a nam je jinkdy nepredlozilo.

UPC ucinilo prvni krok a to, ze se rozhodlo s nami ukoncit privatni peering ve velmi kratkem case a v obchodnim sporu vyuzilo silnejsi pozice tak, by data MAI tekla vyhradne do tranzitu, jehoz cena je vyrazne vyssi, a tim na nas tlacila k zakoupeni sluzby primo u UPC.

Jediny krok, ktery jsme mohli okamzite ucinit je, snizit technicky propustnost pro data UPC pres zahranici, netusili jsme v case, jak dlouho situace bude trvat, aby cca 7Gbps provozu neteklo drazsi destinaci, a zacali hledat dlouhodobejsi reseni. S UPC jsme samozrejme byli v kontaktu, i ti zacali vnimat tlak zakazniku a medii a postupne upravovali sve podminky. Situace ustala, kdyz MAI postupne uvolnil provoz po rekonfiguraci site a site svych partneru a UPC dale netrapi.

Technicky se nam situace nelibi, ale UPC behem doby snizene propustnosti stale trvala na svem, MAI se snazil najit alternativu tak, aby zodpovedne dostal svym zavazkum. Vetsina nasich zakazniku situaci chape.

Cely spor neni o radove tisice euro mesicne, dnes jiz take vyuzivame komercni sluzbu, ale o koncepci, zda by obsah mel platit za pristup pro zakaznika nebo naopak. Pro obsahare je jediny zroj prijmu reklama a pristupovy ISP by takto mel prijmy dva, na strane klienta a obsahu. Jak UPC musi investovat do tras, tak i MAI musi investovat do vystavby datacenter.

P.Vosmera