Šta je novo?

Yunet optika - mts

Ništa, skupljamo dokaze onda, pravimo svakodnevne testove i screen shotove sa ratel i drugih merenja...
 
Malo analiza i edukacije kroz moju analizu problema, uz par pretpostavki.

U ISP svetu i celom internetu u suštini, ništa nije garantovano, i zato je internet prilično jeftin način za prenos informacija.

YuNet je izuzetno jednostavan primer kako ISP funkcioniše i kada iz odličnog ISP-a prelazite u "prihvatljiv" ISP, i kada prelazite u užasno loš ISP...

Pretpostavke bazirane na ponudi za pristup mts optičkoj mreži ka korisnicima kažu mi:
  • YuNet je na strani ka korisnicima povezan na 4 lokacije u Srbiji sa Telekomom: BG, NS, NI, KG
  • Svaka od lokacija ima svojih 40Gbps linka ka korisnicima kroz Telekom GPON
  • Ukupan kapacitet ka korisnicima je 160Gbps

Ovo je samo jedna strana - mreža YuNet-a ka korisnicima.

Sada prelazimo na to kako YuNet "izlazi" na internet.

YuNet je autonomni sistem 8771 na internetu (izvinjavam se na malo više tehničkom žargonu).

BGP kaže sledeće:
1790018872534.webp
Odnosno, AS8771 (YuNet) ima samo jednog upstream peer-a (provajdera), a to je AS8400 - Telekom Srbija.

YuNet nema nikakve peering-e sa drugim provajderima, nije povezan na SOX, jedini upstream provajder mu je Telekom Srbija. (donekle i logično jer je Telekom 80% vlasnik YuNeta).

Po RATEL izveštaju, YuNet je na oko 0.4% tržišta po broju korisnika. To je negde između 5.000 i 10.000 korisnika.

Odličan ISP je onaj ISP koji ima dovoljno kapaciteta da izdrži vršnu potrošnju svih korisnika, i preko toga nekoliko puta maksimalni paket koji prodaju (ako je 1Gbps, onda u rezervi, 3-4-5-6Gbps preko potrošnje u piku). Odličan ISP ima dodatne rute povezivanja ka popularnim CDN-ovima, lokalno keširanje popularnih sadržaja itd itd...

"Prihvatljiv" ISP je onaj ISP koji ima dovoljno kapaciteta da izdrži vršnu potrošnju svih korisnika, u smislu da popularni CDN-ovi rade bez prepunjavanja kapaciteta, a neki manje važni servisi ipak budu blizu kapaciteta linkova, pa samo neke manje popularne stvari ne rade baš idealno...

Loš ISP je onaj ISP koji nema dovoljno kapaciteta da izdrži vršnu potrošnju svih korisnika, koristi samo jednog upstream peer-a.

Šta su problemi sa YuNet-om trenutno:
  • YuNet koristi samo jednog upstream provajdera - Telekom Srbija (samo po sebi nije ogroman problem)
  • YuNet korisnici po pravilu TV gledaju kroz OTT platforme*
  • YuNet nema kapacitet na linku ka internetu za vršnu potrošnju

* zašto pominjem OTT i naglašavam ga?

OTT Live TV je jedna od najgorih stvari koja se desila internetu i celoj priči distribucije TV sadržaja, jer se svaki stream za svaki uređaj pojedinačno dostavlja do svakog korisnika.
OTT Live TV zbog lenjosti, veće kompatibilnosti sa pametnim televizorima, licenciranju kodeka, koristi prastari H264 kodek u 99% slučajeva
Svaki pojedinačni OTT stream za full HD je oko 6Mbps. Poređenja radi, uz VP9 i AV1 kodeke YouTube troši 2Mbps za 1080p stream.

Ako YuNet ima 8000 korisnika recimo, a ukupno 40Gbps ka Telekomu (na strani izlaza ka internetu), to je u proseku 5Mbps po korisniku. To nije ogroman problem, jer je standardno korišćenje interneta "skokovito", apsolutno je retko da svi korisnici koriste internet u isto vreme, na brzinama 500Mbps sve što skidate ide brzo, vi vremenski link ne zauzimate uopšte dugo, preklapanja sa drugim korisnicima nema mnogo, sve se "pegla", i sa tim linkom bi svaki korisnik mogao da prenese prosečno po 1.6TB mesečno... Ali...

U današnje vreme video striminga preko OTT platformi, ova računica apsolutno pada u vodu.

Ako se na YuNetu aktivira 6000 uređaja u vršnom terminu koji gledaju OTT TV po 6Mbps, to je 6Mbps * 6000 = 36000Mbps, odnosno 36Gbps samo za OTT TV.

Ako YuNet ima ukupno 40Gbps ka Telekomu - kao jedinom upstream provajderu (što je vrlo moguće), 90% celokupnog linka ide samo na OTT TV. Za sav ostali saobraćaj ostaje po 0.5Mbps prosečno po korisniku, što je apsolutno smešno. Zato se sav taj saobraćaj "bori" za svoje "parče" protoka i sve se raspada.

Ako bi YuNet aktivirao još jedan 40Gbps link ka telekomu, OTT za ovaj proj korisnika bi bio pokriven sa oko 1/2 linka a ostalo bi prosečno po 5Mbps po korisniku za sav ostali internet saobraćaj što bi radilo odlično u 99% vremena.

Kako je YuNet stari provajder, oni imaju oko 65000 dostupnih javnih IPv4 adresa u svom AS-u, te imaju potencijal za dalju ekspanziju, ali bi morali baš dobro da isplaniraju svoju povezanost sa upstream provajderom/ima.
 
Tako je, svaka čast na postu!
I ja sam pisao yunet-u mail sa problemom. I znaju za problem. Siguran sam da ce resiti pitanje kada...
Al neki korisnici telekoma srbije na optici imaju isti problem u periodu od ~20-23h
 
@poglavicas
Pitanje: Zašto ja nemam problema, a nisam light user?
Radi torent skoro non-stop sa pristojnim protokom, gledam tv stream preko move aplikacije baš u to problematično vreme i nemam problema, sin piči igrice preko strima wifi povezan i isto nema problema (a imao je dok je bio sbb, isto se kačio na wifi).
Protok preko SOX-a je i meni krš, ali nemam potrebu da idem preko njega, pa da li to znači da praktično korisnici koji se kače na EON grcaju sa protokom, a ja ne, pošto ne gledam EON?
 
Negde si već sam sebi dao odgovor. Ukratko ti ne koristiš nijedan servis koji prolazi kroz zagušenu rutu u tom trenutku, Eon zahteva single conection ka domaćem CDN-u i SBB serveru koji puca u večernjim satima.

Torent saobraćaj je P2P peer-to-peer i koristi stotine ili hiljade konekcija istovremeno raspoređenih širom sveta, pa ruteri iza upravljanje saobraćajem kod provajdera drugačije tretiraju taj protok.

Zagušenje na Yu netu pogađa tačno određene rute, protokole i servise. Zato recimo EON, HBO, Netflix rade poprilično loše dok Move radi ok.

Ali nemoj da te zavara to, uradi uveče i single conection ka Yunet serveru, i on je poprilično zagušen, nek dodaju još par stotina korisnika i eto problema ako budu sedeli skrštenih ruku.
 
Interesantno je da uveče imam problem sa sporijim otvaranjem upravo ovog foruma, mislio sam da je generalno tako i sa ostalim ip, ali nije, sve ostalo radi besprekorno, neki drugi domaći forumi i domaći portali, dok bench forum uvek štuca u to neko vreme, 20-24h.
 
Sve i jedan nas operater je bogu plakati ukljucujuci i taj lokalni peering centar tzv. SOX. Mozda nesto moze da ponudi TS u pro domenu i tu se prica zavrsava. Kucni i biznis korisnici su tretirani kao ovce za sisanje (ili svinje u lokalnom slucaju)
 
Trebalo bi da bude manji račun za toliko dana koliko se ima problemi.
 
Ljudi, YuNet nema niti jednu posebnu rutu osim glavne kroz Telekom.
Iz YuNet-a sav saobraćaj prolazi kroz taj jedan link do Telekoma, a onda dalje ka servisima na internetu kao i kod drugih korisnika telekoma.
Taj jedan link je očigledno vrlo verovatno 40Gbps po mojim proračunima.

Kada se kapacitet veze prepuni, switchevi ili ruteri na oba kraja krenu da odbacuju (drop-uju) pakete.

Kad to krene da se dešava, na scenu stupaju TCP congestion control algoritmi.
Osnovni u širokoj upotrebi su RENO i CUBIC. Oni su nastali "na brzinu" u trenutku kad je prvi put internet potpuno stao zbog prepunjenih linkova.
RENO se danas mnogo manje koristi jer nije prilagođen uopšte za brze preko okeanske veze, i u idealnim uslovima teško može da ostvari par stotina megabita iz USA do Evrope.
CUBIC je ubedljivo naj češči congestion control algoritam za TCP veze danas.

TCP očekuje povratnu informaciju da je paket isporučen (ACK). TCP uz CUBIC kreće polako (slow start) i eksponencionalno povećava broj paketa poslatih bez potvrde prijema. Povećava dok god se ne desi više od jednog neisporučenog paketa. Kada dva paketa od poslatih van maksimalno dozvoljenog broja poslatih bez potvrde ne budu isporučeni, CUBIC smanji dozvoljeni broj poslatih paketa bez potvrde za pola. Treći izgubljeni paket smanjuje na još pola, četvrti na još pola i brzo dolazimo do užasno malog broja dozvoljenih poslatih paketa bez potvrde, tj brzina prenosa drastično opadne. To kao rezultat ima skoro pa instant rasterećenje zauzetog linka.

Google je razvio dva nova congestion control algoritma: BBR i BBR2. Njihova karakteristika je da gledaju razliku u kašnjenju paketa kao osnovni znak popunjenosti linka, a packet loss kao sekundarni. Kada detektuju problem, ne smanjuju odmah na pola, nego na poslednje ostvarenu brzinu koja je radila bez gubitaka.

HTTP/3 (QUIC) protokol implementira BBR ili BBR2 u samoj serverskoj i klijentskoj aplikaciji, pa ne zavisi od operativnog sistema.

Kada se dešava gubitak paketa (bilo zbog popunjenosti ili tehničkih problema na linku), TCP window se mnogo sporije povećava ako je server sa koga prenosite podatke dalje, odnosno imate veću latenciju ka serveru.

EON ne radi dobro zato što on koristi HTTP (TCP) sa CUBIC congestion control algoritmom na serveru, pri čemu celokupan strim ide kroz jednu TCP vezu uz HTTP keep alive. Ako postoji packet loss, brzina prenosa kroz tu jednu TCP konekciju će opasti poprilično, čak do nivoa manjeg od 6Mbps, pa neće biti moguće prenositi sliku i zvuk u maksimalnom kvalitetu već će sistem ukapirati da mora da obori kvalitet.

Da se ovo ne desi, apsolutno sav internet saobraćaj kroz taj link bi bio potpuno zaglavljen.
 
Radio sam malu dijagnostiku, pustim sa moje strane (mts gpon) trace do IP adrese korisnika YuNet-a.

Analizirao sam svaki ruter na putu i tačno zaključio između koja dva je link Telekom - YuNet.

Radim ping sa paketima veličine 1400b (ako nekoga baš zanima mogu da objasnim zašto), intervalom 0.1s i sa 1000 paketa.

Sa Telekom strane se nalazi ruter sa IP adresom: 212.200.7.75 koji je pretpostavljam 40Gbps optičkim ethernetom povezan sa ruterom na YuNet strani.
Statistike ping-a za ovaj ruter sa strane Telekoma u ovom trenutku:
Kod:
--- 212.200.7.75 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 100488ms
rtt min/avg/max/mdev = 7.423/8.646/37.763/2.607 ms
1000 paketa veličine 1400b poslatih, 1000 paketa primljenih, nema izgubljenih.

Sa YuNet strane tog linka se nalazi ruter sa IP adresom 194.247.197.50 - ovaj je na drugoj strani pretpostavljam 40Gbps optičkog ethernet-a.
Statistike ping-a za ovaj ruter sa strane Telekoma u ovom trenutku:
Kod:
--- 194.247.197.50 ping statistics ---
1000 packets transmitted, 998 received, 0.2% packet loss, time 100523ms
rtt min/avg/max/mdev = 7.037/10.915/128.153/11.251 ms, pipe 2
1000 paketa veličine 1400b poslatih, 998 paketa primljenih, 2 izgubljena.

Neko bi reko, šta je 0.2%, 2 od 1000? To je ipak prilično. Uveče bude i 1% loss.

Maksimalna veličina jednog paketa je 1500B, što znači da za prenetih 100MB, vi prenesete 66000 paketa. Ako je 0.5% izgubljenih, vama se u toku tog transfera izgubi 330 paketa, što znači 300 puta će brzina prenosa pasti, te se povćavati nakon toga ako je CUBIC u upotrebi. Ako je loss blizu 1% što sam video sinoć, brzina prenosa u samo 100MB će pasti 600 puta, te se povćavati nakon toga, ali će transfer baš sporo ići.
 
Od kada su poceli da se dasavaju ovi problemi i da li ima nade da ce biti reseni uskoro?
Pitam jer razmisljam da se prebacim na YUnet sa ex Orion optike.
 
Nazad
Vrh Dno