Vlákno názorů k článku
Čeká nás rychlostní mýtné na informační dálnici?

Kdyz tak mlati tim, ze pro nektere sluzby (jako VoIP) je zapotrebi nizsi latence, proc ne ? Kdo by si priplatil, dostane nizsi latenci. Dulezite ovsem je, aby ten kdo si nepriplati dostal ty same parametry co ma ted - ktere, jak je videt v praxi, jsou na VoIP pouzitelne. A rozhodne zakazat oblibene triky na tema uplneho blokovani "nevyhovujiciho" provozu.

To co mě děsí je blokování "nevyhovujícího" provozu - jsem-li poskytovatel připojení, nebo nedej bože vlastník některého z vyhledavačů - budu samozřejmě chtít blokovat svou konkurenci, a to třeba i inzerenty, kteří jsou u konkurence a né u mě. Tím je přinutím utratit nějaký bakšiš i u mě.
Z hlediska uživatele je to ale hrůza. Budu muset prolézat všechny vyhledavače, abych našel to co hledám, a to se ještě budu bát, že mi obsah zakáže můj poskytovatel připojení.

Vzhledem k tomu, jak funguji soucasne smerovace si dokazu jen tezko predstavit, ze byste dostal NIZSI latenci.

Spis to bude tak, ze budete mit latenci vyssi a kdyz si priplatite, dostanete latenci takovou, jaka je dnes.

Je samozrejme otazkou, KDO si priplati. U Google, Yahoo!, Seznamu ci dalsich klient/server aplikaci je jista sance na to, ze zaplati oni. Kdo ale zaruci, ze ze kdyz si priplatim, dostanu mensi latenci pro VoIP k nejakemu kamosi na Novem Zelande, kdyz data pobezi pres 10 operatoru?

Pochopitelne je taky otazkou, podle ceho se bude merit. Napriklad v soucasne dobe nemaji ISP zadna certifikovana meridla na to, kolik dat uzivatele prenesli. Presto uplatnuji FUP ci platbu za data. Nepodeziram ISP, ze data falsuji, nicmene v CR maloobchodne na vahu nemuze prodavat nikdo, kdo tu vahu nema certifikovanou ...

Jak by jste implementoval takove certifikovane meridlo?

Ja bych ho neimplementoval. Ja bych prestal zpoplatnovat podle prenesenych bajtu ... Asi jsem starej neprizpusobivej prudivej internetovej dedek. Tento nazor mam uz peknych par let a nemyslim, ze se jeste bude nejak vyvijet :-)

Nejste neprizpusobivej dedek. V jednoduchosti je sila. Jsem tehoz nazoru. Pocitani dat je zbytecnej technickej a administrativni overhead. Je tam spousta kritickych prvku, nadela se more chyb a stejne ani pak to nefunguje dobre. Proste bych akorat zavedl rozliseni priorit a prodaval bych agregovany pripojky o xmbitech
Delsi dobu mi jedno vrta hlavou. Provideri to nezavadej protoze si stezuji ze maji taky svy datovy limity. Do tohodle nevidim pac nejsem provider, ale pripada mi to jako blbost nebo hodne blbe uzavrena smlouva. Jak to teda je? Je to jenom vymluva?

Pokud ja vim, ISP nakupuji vyhradne konektivitu z bodu A do bodu B, v nekterych pripadech ani to ne, pronajmou si vlakno(nebo vice vlaken) a co si na ne daji za koncove zarizeni, to tam maji.

Lokalni ISP to delaji spis tak, ze nakoupi konektivitu do NIXu a k ni byva pribalena v nejakem pomeru (trebas 1/10) konektivita do zahranici.

=> ano, datove limity jsou svym zpusobem vymluva, ISP je omezen vyhradne "tloustkou" kabelu (ktera samozrejme omezuje maximalni mnozstvi prenesenych dat).

Co je lokalni ISP? Myslite preprodejce bez ASu?

Vase odpoved vsem ISP muze byt nasledujici: Pokud jste opravdovy ISP, nakupujete konektivitu podle gigabitu za sekundu, nikoliv gigabajtu za mesic.

Asi proto, ze nedelas retail ISP :-) Typicky zakaznik ma tyto parametry:

1) Chce, aby kdyz pracuje, tak aby to chodilo rychle
2) Moc toho nestahne (= linku vyuzije prumerne na zlomek jeji kapacity)
3) Chce aby to moc nestalo

Takova je poptavka. A nabidka na ni je sice rychla linka, ale s omezenym prenosem. To je nutne pro dodrzeni parametru 3. Pokud nekdo limit nechce, samozrejme si muze zaplatit linku bez limitu, ISP bude jen rad :-)

Michale, prosim precti si kontext diskuse. Nebavim se o tom, co je soucasna podoba trhu, ale co je na ni spatne.

ISP meri neco, co je vyplod powerpointoveho inzenyrstvi. Uz jsem sice dlouho neslysel, ze by se po nahrani nove verze IOSu zmenil stav counteru o 20% (bez toho, ze na druhe strane jsou porad stejna data), na druhou stranu zadne overene meridlo na data neexistuje.

No a ja pisu, proc to neni spatne :-)

ISP prodavaji linku o urcite rychlosti. Presto nevim o tom, ze by meli certifikovana meridla na jeji rychlost. Telekomunikacni operatori pocitaji hovory na cas. Presto pochybuji, ze ta ustredna by byla certifikovana, ze ho meri dobre. Atp.

No pamatuju si kamery/fotaky, pocitadla a zaznam pro fakturaci... - na zaklade toho slo dohledat chybu a uspesne reklamovat... v dnesnim digitalnim svete naprosto pofidernim a nikym nedefinovanym "prenosem" dat je to uplne k "censored".

Videl ste nekdy pocitadlo v telefoni ustredne ? Ne ? Ja ano, teda z dost velke vzdalenosti, bliz nas totiz nepustili a i zamestnanci se tomu radsi vyhybali. Kdyby totiz doslo k nejakemu problemu a zjistilo se, ze se v tom nekdo rejpal, tak to samo vsechno zaplati. A ty pocitadla byly samozrejme pravidelne kontrolovana a testovana. Pokud vim, existuji primo normy ktere musi takove pocitadlo v telefoni ustredne splnovat.

Jak je zajisteny ze pri prenosu udaju z pocitadla se nepridaji naky informace. Je to podepsany tim pocitadlem? Certifikuje pocitadlo nejaka nadrazena autorita nad telefonicou? A vubec jak pocitadlo ziskava udaje k uctovani?Neni tady skulinka?

Mne to prijde podobne, jako treba policejni radar. Musi to mit atest/certifikat. Musi to byt minimalne tamper-evident (pokud ne tamper-resistent). Musi to mit audit trail pro pripad reklamace.

Pokud se vam neco nelibi, reklamujte. V pripade pevne telefonni linky existuje CTU, ktere ma pravo auditu. V pripadech jinych by to mohla byt policie nebo soudni znalec, co ja vim.

Precti si svoji smlouvu, zjistis, ze Ti neprodavaji zadnou garantovanou rychlost :-)

Co se tyce novych softswitchu tak tam se moc neorientuju, nicmene minuty dokazaly digitalni ustredny merit docela presne ...

Minuty ano... ale sekundy uz na tom byly hure a nejlepe bylo, kdyz se zacaly vyskytovat rozdily v tom, co si mysli tva pobocka a co si mysli ustredna operatora... +- sekunda je nekdy zatracene drahy spas... zejmena pri vyuctovani a tisicich hovorech podobneho charakteru.

I proto posilaly nektere ustredny tarifni impulsy :-)

Velmi snadno, zakladem je stanovit, co chci vlastne merit, v nasem pripade dejme tomu pocet prenesenych bytu na IP vrstve (vcetne hlavicek). Pak muze kdokoli postavit takove zarizeni a nekdo, vetsinou nejaky zkusebni ustav, overi, ze to meridlo opravdu meri co ma a to i pri ruznych extremnich situacich.

No a dalsi podstatnou veci je, ze do meridla NELZE zadnym zpusobem zasahnout tak, aby to nebylo poznat - toto je zasadni problem soucasneho mereni a kdyby se nekdo soudil se svym ISP, tak ten nema v ruce zhola nic, jelikoz to co meri, casto ani nemeri, ale odhaduje ze vzorku a navic to muze kdykoli kdokoli jakkoli upravit, aniz by bylo mozne to zjistit.

Tudiz je v zajmu obou stran, aby mereni bylo overitelne.

Fakt si nedokazu predstavit jak tohle v praxi implementovat aby to bylo neprustrelny a flexibilni.
To by musela byt zapeceteny routery a databaze. A nesmelo by se do toho sahat. Nebo nejaky blackboxy pres ktery by to vsechno slo a ten by se pod lipnul nejakej podpis jako to maj luxusni meraky na kabelaz.
Porad ale nekde po ceste to muzu osulit. Fakt nevim. Vsechno co mi napada ma nejakou slabinu.

Nj, ale pak to nemuze byt prodejnim artiklem. Jak muzu prodavat neco, co nedokazu ani odmerit ?

Si predstavte, ze prijdete do uzenarstvi, v lepsim pripade siroko daleko neni zadne jine, vidite ceduly "1kg / 50Kc", ale ja vam to 1kg odvazim zpusobem, ze hodim sisku na stul a bywoko kus odriznu.

A protoze by ste si trebas nahodou moh stezovat, tak Vam jeste dam podepsat, ze vlastne vubec nerucim za to, ze vam navazim spravne, platit budete predem a kdyz obcas zaplatite a salam nebude, nemate narok na nic.

Presne takhle to dneska funguje s "internetem" v cechach.

Stydim se, sem prase a neumic cesky napsal jsem to co jsem napsal :).

A pravena to je spravna odpoved, ze kdyby se uz konecne na to ISP vykaslaly, ze by to bylo jen ku prospechu i rozvoji veci (vcetne raketoveho snizeni zisku nekterych hracu, ale i ceny technologii)... Ano na dnesni datove toky nejsou regulerni meridla, fine - souhlasim, tak proc to mnozstvi ISP "meri" a na zaklade toho fakturuje?

Nepochopil jste tajemstvi meho navrhu. Nizsi latence by byla samozrejme zajistovana tim, ze by ISP nakoupily dalsi HW. Pokud by to neudelali, nemeli by pravo nabizet nadstandardni sluzby.

Proc mate dojem, ze by nakoupeni dalsiho HW nejak snizilo latenci? :-)

Spojeni ma minimalni latenci v pripade, ze je realizovano dvoubodovym spojem s repeatery. Realna spojeni jsou pomalejsi protoze:
1) Nejsou vyhrazene. Cas od casu se neco zahodi a musi se poslat znova, coz samozrejme zvysi latenci. (A BTW, vyhrazenost kapacity je vec o kterou muzou mit VoIP sluzby jeste vetsi zajem nez o latenci, a jde zajistit proste prevedenim vyhrazeneho provozu na nove prikoupenou kapacitu - coz beru jako novy kabel a tedy HW).
2) Nejsou prime. Misto z A do B vedou nejdrive z A do C a pote z C do B. Lze resit natazenim noveho kabelu mezi A a B, tedy novym HW.
3) Na ceste jsou aktivni prvky pomalejsi nez repeatery. Samozrejme router nemuze byt nikdy tak rychly jako repeater, ale IMHO je mozne nakoupit novy, drazsi a rychlejsi router.
4) Aktivnich prvku na ceste je prilis mnoho. Krome reseni v bodu 2 myslim, ze jsou rezervy zpusobene tim, ze se nekolik kusu HW nahradi jednim drazsim.

Bozicku :-)

Mozna se pohybujete v oblasti nejakych WiFi ci garazovych operatoru, kde skutecne k nejakym pretizenim okruhu ci zahazovani paketu dochazi, nicmene tady se bavime o velkych a rozumne spravovanych sitich. Kdysi v davnych internetovych dobach byly podnikany ruzne kroky se selmostroji pod spolecnym vzyvanim modly jmenem QoS, nicmene vyhral americky pristup (dostatecne tlusta trubka resi vse). Jednim z duvodu, proc QoS de facto chciplo, byla "drobna" prekazka v tom, ze se operatori nedokazali dohodnout na tom, odkud kam se vlastne QoS garantuje. QoS muzete vzyvat maximalne ve vlstni siti (ale i to je z velke casti powerpointove inzenyrstvi) :-)

Mira zahazovani je nezavisla na poctu okruhu - tedy pokud pracujeme v profesionalnim prostredi.

V pripade, ze pracujeme s vetsim mnozstvim okruhu, mame vetsi problemy se smerovacimi protokoly. Tyto problemy jsou technicke (rychlost konvergence, velikost smerovacich tabulek), ale i organizacni (nastavovani smerovaci politiky).

Mate pravdu v tom, ze smerovac neni tak rychly jako opakovac. Nicmene, ve smerovaci obvykle konci vic nez dva datove okruhy, zatimco v opakovaci konci prave dva. Jejich funkce je proste rozdilna a je to podobne, jako byste chtel pracku nahradit lednici, protoze zere mene proudu.

Ale jinak hezke teorie, vitejte ve svete skutecneho Internetu :-)

Mimochodem, porad pisete o nejakych bodech A, B nebo C. Nicmene napriklad VoIP je z hodne velke casti o Peer-To-Peer sitovani. Budu ja mit z domova jedenmilionsestsetdevadesatdvatisictristadvacetpet (ci vice) ruznych datovych okruhu ke vsem SIP telefonum, ktere jsou pripojeny do site?

Mimochodem, zkuste si traceroute z Vasi site nekam do San Jose. Zjistite, ze latence smerovacu nebude ten hlavni problem. Tedy pokud nevisite na nejake garazove siti.

Nenavrhoval jsem nahradit smerovac opakovaci. Jen jsem konstatoval, ze pocet smerovacu, jakoz i jejich nizka kvalita, muze zvysovat latenci. I kdyz uznavam, ze na paterni siti jsme patrne na technologickem maximu.

Samozrejme ze nebudete mit milion dratu az domu, to je extrem. Nicmene pokud cesta povede pres 10 bodu (s vetsim poctem propojeni) misto pres 20, bude nizsi latence.

# traceroute -m 50 www.ci.san-jose.ca.us
traceroute to 156.39.1.80 (156.39.1.80), 50 hops max, 40 byte packets
 1  ---.chello.upc.cz (89.176.-----)  5.663 ms  4.173 ms  5.799 ms
 2  ---.chello.upc.cz (86.49.----)  6.292 ms  5.567 ms  4.860 ms
 3  1hopsem-v101.dkm.cz (62.24.68.73)  8.453 ms  5.313 ms  5.137 ms
 4  cz-prg01a-ra2-ge0-0-0-v20.aorta.net (213.46.172.9)  6.743 ms  6.335 ms  6.618 ms
 5  at-vie01a-rd1-pos-1-0-0.aorta.net (213.46.160.53)  13.015 ms  11.611 ms  10.689 ms
 6  at-vie15a-rd1-ge-15-0.aorta.net (213.46.173.138)  18.249 ms  12.071 ms  11.881 ms
 7  213.46.160.249 (213.46.160.249)  34.517 ms  32.034 ms  31.588 ms
 8  213.46.183.78 (213.46.183.78)  31.801 ms  31.648 ms  32.229 ms
 9  amsxnl.sbcglobal.net (195.69.145.135)  120.533 ms  121.701 ms  127.167 ms
10  bb1-p5-0.amsxnl.sbcglobal.net (151.164.41.232)  117.099 ms  114.711 ms  114.059 ms
11  bb2-p9-0.hrndva.sbcglobal.net (151.164.41.208)  125.564 ms  154.706 ms  125.873 ms
12  core2-p5-0.chrnva.sbcglobal.net (151.164.243.137)  131.413 ms  127.500 ms  132.580 ms
13  core1-p8-0.crhnva.sbcglobal.net (151.164.188.21)  142.238 ms  128.077 ms  128.640 ms
14  core1-p11-0.crcloh.sbcglobal.net (151.164.240.121)  165.703 ms  212.519 ms  219.639 ms
15  core1-p3-0.crchil.sbcglobal.net (151.164.188.181)  189.459 ms  236.418 ms  268.879 ms
16  core2-p1-0.crchil.sbcglobal.net (151.164.188.30)  141.921 ms  143.085 ms  142.489 ms
17  core1-p11-0.crkcmo.sbcglobal.net (151.164.240.117)  156.488 ms  154.239 ms  155.485 ms
18  core1-p5-0.crdnco.sbcglobal.net (151.164.42.22)  165.685 ms  204.762 ms  165.594 ms
19  core1-p11-0.crskut.sbcglobal.net (151.164.243.245)  178.843 ms  175.559 ms  176.378 ms
20  core1-p3-0.crsfca.sbcglobal.net (151.164.243.238)  187.975 ms  189.134 ms  190.173 ms
21  bb1-p12-2.snfcca.sbcglobal.net (151.164.243.118)  189.535 ms  213.519 ms  191.761 ms
22  ded1-g1-3-0.snfcca.sbcglobal.net (151.164.243.94)  189.893 ms  210.297 ms  189.417 ms
23  VIP-CALNET-The-City-of-San-Jose-1048315.cust-rtr.pacbell.net (216.102.161.78)  199.413 ms  197.579 ms  203.175 ms
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
31  * * *
32  * * *
33  * * *
34  * * *
35  * * *
36  * * *
37  * * *
38  * * *
39  * * *
40  * * *
41  * * *
42  * * *
43  * * *
44  * * *
45  * * *
46  * * *
47  * * *
48  * * *
49  * * *
50  * * *

No to nam moc nereklo, tak jina adresa ...

# traceroute -m 40 www.sjsu.edu
traceroute: Warning: www.sjsu.edu has multiple addresses; using 130.65.3.107
traceroute to ares.sjsu.edu (130.65.3.107), 40 hops max, 40 byte packets
 1  ----.chello.upc.cz (89.176.-----)  6.548 ms  9.290 ms  5.545 ms
 2  ------.chello.upc.cz (86.49.----)  5.426 ms  4.773 ms  5.955 ms
 3  cz-prg01a-ra1-ge0-0-0-v10.aorta.net (213.46.172.5)  67.583 ms  6.777 ms  6.965 ms
 4  de-fra01a-rd2-pos-2-0.aorta.net (213.46.160.29)  29.693 ms  29.782 ms  24.279 ms
 5  de-fra01a-rd1-pos-5-0.aorta.net (213.46.179.5)  24.644 ms  27.693 ms  24.904 ms
 6  de-fra01a-ri1-ge-2-0-0.aorta.net (213.46.179.18)  25.403 ms  25.047 ms  36.500 ms
 7  213.46.179.22 (213.46.179.22)  33.775 ms  35.005 ms  36.236 ms
 8  ge-3-3-0-0.fftcr4.Frankfurt.opentransit.net (193.251.241.201)  37.075 ms  33.543 ms  35.063 ms
 9  so-0-1-0-0.loncr4.London.opentransit.net (193.251.154.89)  46.025 ms  43.696 ms so-0-2-0-0.loncr4.London.opentransit.net (193.251.242.138)  41.868 ms
10  po3-0.loncr3.London.opentransit.net (193.251.242.217)  41.941 ms po2-0.loncr3.London.opentransit.net (193.251.242.21)  41.801 ms  42.328 ms
11  po10-0.ashcr1.Ashburn.opentransit.net (193.251.240.182)  114.678 ms  114.013 ms  140.397 ms
12  so-5-0-0-0.loacr2.LosAngeles.opentransit.net (193.251.240.250)  180.223 ms  175.206 ms  174.296 ms
13  ge2-23.fr1.lax.llnw.net (193.251.250.210)  191.550 ms  191.423 ms  195.842 ms
14  cenic.ge2-5.fr1.lax.llnw.net (69.28.144.154)  196.802 ms  192.148 ms  197.147 ms
15  dc-lax-dc1--lax-dc2-ge--1.cenic.net (137.164.22.2)  192.427 ms  191.576 ms  191.679 ms
16  dc-sac-dc1--lax-dc1-pos.cenic.net (137.164.22.127)  194.716 ms  192.703 ms  194.282 ms
17  dc-oak-dc1--csac-dc1-ge.cenic.net (137.164.22.110)  233.244 ms  323.978 ms  217.460 ms
18  dc-oak-dc2--oak-dc1-p2p-2.cenic.net (137.164.22.195)  195.045 ms  193.644 ms  194.056 ms
19  dc-csusanjose-egm--svl-dc1.cenic.net (137.164.40.74)  196.166 ms  204.107 ms  194.970 ms
20  130.65.11.158 (130.65.11.158)  194.320 ms  195.969 ms  199.912 ms
21  130.65.11.161 (130.65.11.161)  194.766 ms  194.577 ms  195.488 ms
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
31  * * *
32  * * *
33  * * *
34  * * *
35  * * *
36  * * *
37  * * *
38  * * *
39  * * *
40  * * *

No, a ? Nejdele to trva z Londyna do Ashburnu a z Ashburnu do LA, mozna bych mohl najit i geograficke lokace v tom prvnim pripade ... myslite ze ty dlouhe hopy by nesly vyresit novym, lepsim HW ? (BTW tipuji ze se jedna bud o transatlanticky kabel nebo o prenos pres druzici).

LOL! Přes družici... Je vidět že jsi odborník! Myslím že ti kolega vysvětlil problém dostatečně.

Nejdele to trva z Londyna do Ashburnu a z Ashburnu do LA, mozna bych mohl najit i geograficke lokace v tom prvnim pripade ... myslite ze ty dlouhe hopy by nesly vyresit novym, lepsim HW ?

Tachyonovy prenos zatim nikdo nevymyslel :-)

Sakrys ze bych si to spocital ? Kolik je vzdusnou carou z Londyna do Ashburnu ...

Prislo mi, ze to je vic nez vyzaduje omezeni rychlosti svetla, ale je pravda ze ten rozdil nebude tak velky, uvazime-li ze trasa kolem cele zemekoule trva celych 134ms (za predpokladu ze je kulata) ...

Jinak, na druzici s geostacionarnim orbitem by to trvalo 120ms (a dalsich 120ms zpatky), takze ty druzice leda kdyby geostacionarni nebyly ...

Jasne ze je to vic, nicmene nejvetsi cast zpozdeni _NENI_ na smerovacich.

No nekdy by pomohly lepsi routy ... treba ze site chello routa do US nejdriv vyleze z "lokalni" prazske site, dalsi hop je v holandsku (!!), pak dalsi je Viden v Rakousku (proc to nemuze jit do rakouska primo a dela to pres 1500km okruh pres holandsko?) a pak to miri do francie a pres ocean.

Takze z chello tam pak mam ping 150 a z "garazove site" kde jsem ted tam mam ping 120 (teda pokud zrovna neni vypadek nebo sit neucpou stahovaci :) - tam to z holandska jde do anglie a pak do statu a ne klickou pres rakousko

Takze casto za to musou blbe navrzeny routy ktery vedou pres pul evropy ...

Hm Hm ... Nekdy by pomohlo nespolehat na to, co IP adrese rekne RIPE. Skutecnost je takova, ze chello ma okruhy do Frankfurtu a Vidne. Takze se provoz do Nizozemi dostane, ale az nasledne :-)

Smerovaci politika je vec, ktera je nezavisla na tom, kolik penez vybirate od uzivatelu. Castecne se da sice vylepsit, nicmene zrovna v tomto pripade Vas penize od uzivatelu nepomohou (chello to klidne muze smerovat pres Frankfurt).

Napriklad ja ted z jedne ceske site chodim na f.root-servers.net do Amsterdamu, zatimco z jine site se dostanu na prazske anycastove zrcadlo.

Ehm... A na rychlost linky snad certifikovana meridla maji?

Co je to rychlost linky? :-)

Prece to, co ISP prodavaji, ne? ;-)