Detaljno o Starlinku: Rad TCP-a kod satelitskih telekomunikacija

Digitalni komunikacioni sistemi uvek predstavljaju niz kompromisa u dizajnu. Maksimizacija jedne karakteristike sistema može narušiti druge, a različite komunikacione usluge mogu izabrati da optimizuju različite performanse na osnovu preseka ovih dizajnerskih odluka sa fizičkim karakteristikama komunikacionog medijuma. U ovom članku ćemo razmotriti Starlink uslugu [1] i kako TCP, osnovni transportni protokol Interneta, interaguje sa karakteristikama Starlink usluge.

Foto: Geoff Huston

Za početak, korisno je prisetiti se jednog malog pojma Njutonove fizike iz 1687. godine [2]. Na površini Zemlje, ako ispalite projektil horizontalno, on će pasti nazad na Zemlju zbog kombinacije efekata trenja atmosfere Zemlje i gravitacione sile Zemlje. Međutim, pretpostavljajući da Zemlja nema atmosferu koja izaziva trenje, ako ispalite ovaj projektil horizontalno dovoljno brzo, neće se vratiti na Zemlju, već će odleteti u svemir. Ako ste dovoljno visoko da izbegnete razne planine koje mogu biti na putu, postoji, međutim, kritična brzina pri kojoj će projektil biti uhvaćen gravitacijom Zemlje i neće ni pasti na zemlju ni odleteti u svemir (Slika 1).

Ova orbitalna brzina na površini Zemlje iznosi oko 40.320 km/s. Orbitalna brzina se smanjuje sa visinom, i na visini od 35.786 km iznad površine Zemlje, orbitalna brzina projektila u odnosu na tačku na površini rotirajuće Zemlje je 0 km/s. To je visina geosinhrone ekvatorijalne orbite, gde nam objekat u orbiti izgleda kao da stoji na fiksnom mestu na nebu.

Geosinhroni servisi

Geosinhroni sateliti su bili preferirani pristup u prvoj talasu satelitskih komunikacionih usluga. Svaki satelit je mogao „pokriti” celu hemisferu. Ako je satelit na ekvatorijalnoj ravni, tada se nalazi fiksnom položaju na nebu u odnosu na Zemlju, što je omogućavalo korišćenje velikih antena. Ove antene su bile sposobne da rade pri niskom odnosu signala i šuma, što je omogućavalo modulaciju signala korišćenjem kodiranja sa visokom gustinom diskretnih faza i amplituda, a što povećava kapacitet usluge.

Sve ovo mora biti izbalansirano sa manje povoljnim aspektima geosinhronih usluga. Razmatranje mešanja signala (crosstalk) između susednih satelita u geosinhronim orbitama koji koriste iste radio frekvencije rezultiralo je međunarodnim sporazumima koji zahtevaju razmak od 2° za geosinhroni sateliti koji koriste istu frekvenciju. Zbog toga je ovaj orbitalni slot ograničen resurs koji je limitiran na samo 180 satelita ako svi koriste K band (18 – 27 GHz) radio sisteme. Na svakoj tački na Zemlji postoji gornja granica kapaciteta signala koji mogu biti primljeni (i poslati) korišćenjem geosinhronih usluga.

Zavisno o tome da li je posmatrač na ekvatoru direktno ispod satelita ili dalje od ove tačke, geosinhroni orbitni satelit je udaljen između 35.760 i 42.664 km, pa će vreme putovanja signala do geosinhronog satelita i nazad biti između 238 ms i 284 ms u smislu vremena propagacije signala. U IP terminima, to je vreme putovanja tamo i nazad (round trip time) između 477 i 569 ms, na koje treba dodati vreme kodiranja i dekodiranja signala. Pored toga, postoji kašnjenje za prenos signala između krajnjih tačaka na zemlji (korisnik i destinacioni server) i zemaljskih stanica satelita (tzv. teleport-ovi). U praksi, uobičajeno iskustvo je round trip time od oko 660 ms za putanje na Internetu koje uključuju geosinhronu satelitsku uslugu.

Ovo produženo kašnjenje znači da krajnje tačke moraju koristiti velike bafera da bi držale kopiju svih nepotvrđenih podataka, kako to zahteva TCP protokol. TCP je protokol kontrolisan povratnim informacijama (feedback-governed), koristeći ACK pacing. Što je duže vreme putovanja, veće je kašnjenje povratne informacije, i sporiji je odgovor krajnjih tačaka na zagušenje ili dostupan kapacitet. Razmatranja o zagušenju dovode do uobičajene upotrebe velikih bafera u sistemima koji pokreću satelitske sisteme, što može dodatno pogoršati nestabilnost izazvanu zagušenjem. U kontekstu geosinhronih usluga, individualne TCP sesije su podložnije nestabilnosti i imaju duže vreme oporavka nakon događaja sa niskim protokom u poređenju sa njihovim kopnenim pandanima, kada takvi pandani postoje.

Servisi u Niskoj Zemljinoj orbiti

Potencijalni odgovor na nedostatke geosinhronih satelita je da se satelit dovede bliže Zemlji. Ovaj pristup ima nekoliko prednosti. Gvozdeno jezgro Zemlje koja se rotira stvara magnetsko polje, koje zarobljava energetske naelektrisane čestice Sunca i preusmerava ih kroz ono što se naziva „Van Alenov pojas”, čime odbija solarne zračenja. Ovo ne samo da omogućava Zemlji da zadrži svoju atmosferu, već takođe štiti elektroniku satelita u orbiti koji koriste orbitalnu visinu ispod otprilike 2.000 km od najgorih efekata solarnog zračenja (kao što su nedavne solarne oluje). Takođe je mnogo jeftinije lansirati satelite u nisku zemljinu orbitu, a ovih dana SpaceX to može učiniti koristeći ponovno-upotrebljive delove raketa.

Smanjena udaljenost između Zemlje i orbitnog satelita smanjuje kašnjenje u slanju signala do satelita i nazad, što može poboljšati efikasnost protokola transporta paketa od kraja do kraja koji uključuju takve satelitske sisteme.

Ova grupa orbitalnih visina, od oko 160 km do 2.000 km, zajedno se naziva Niska Zemljina orbita (LEO, od engleskog „Low Earth Orbit”) [4]. Cilj ovde je da se održi orbita satelita dovoljno visoko da spreči usporavanje prolaskom kroz gornje delove jonosfere Zemlje, ali ne toliko visoko da izgubi zaštitu od zračenja koju pruža unutrašnji Van Alenov pojas [5]. Na visini od 550 km, minimalno kašnjenje u propagaciji signala do dostizanja satelita i povratka sa površine Zemlje iznosi samo 3,7 ms.

Ali sve ovo nosi i neke druge probleme. Na visini od 550 km, orbitni satelit može biti viđen samo od malog dela Zemlje. Ako je minimalna efektivna elevacija za uspostavljanje komunikacije 25 stepeni iznad horizonta, tada je trag satelita krug sa poluprečnikom od 940 km, odnosno krug površine od 2M km². (Niže elevacije su moguće, ali što je duži segment puta kroz Zemljinu atmosferu, to se smanjuje odnos signala i šuma, kompromitujući dostupni kapacitet signala i povećavajući ukupno kašnjenje puta.) Da bi se obezbedila kontinuirana usluga bilo kojoj tački na površini Zemlje (510,1M km²), minimalni broj orbitnih satelita je 500. Upotreba konstelacije satelita implicira da LEO satelitska usluga nije jednostavan slučaj slanja signala do fiksne tačke na nebu i reflektovanja tog signala do neke druge zemaljske lokacije. Kontinuirana LEO satelitska usluga mora da preskače kontinuirani niz satelita dok prolaze iznad, i da prebacuje virtualnu putanju komunikacije na uzastopne satelite kako dolaze u vidokrug kako korisnika tako i određene zemaljske stanice korisnika.

Na visini od 550 km, satelit u orbiti se kreće sa relativnom brzinom od 27.000 km/h u odnosu na tačku na površini Zemlje i prolazi preko neba od horizonta do horizonta za manje od 5 minuta. Ovo ima neke implikacije za dizajn radio komponente usluge. Ako je konstelacija satelita dovoljno velika, sateliti su dovoljno blizu jedan drugom da nema potrebe za korišćenjem većih antena koje zahtevaju neki mehanizovani sistem za praćenje pojedinačnih satelita dok se kreću preko neba, ali ni to nije bez svojih nedostataka. Individualni carrier signal može biti početno uhvaćen kao slab signal (u relativnim terminima), a pojačava se kako se radio transponder satelita i zemaljska antena poklapaju, a zatim ponovo slabi kako satelit nastavlja svoje kretanje. Antene Starlink-a koriste phased array tehnologiju. Ovo omogućava anteni elektronsko usmeravanje promenom razlike u fazi između svakog segmenta antene. Ipak, ovo je relativno grubo usmeravanje, pa kvalitet signala nije konzistentan. To implicira stalno variranje odnosa signala i šuma (SNR) dok antena prati svaki satelit tokom njegovog prolaska nebom.

Izgleda da Starlink usluge koriste dinamičku kontrolu signala kao odgovor na ovo stalno variranje SNR-a. Predajnik stalno prilagođava modulaciju i kodnu šemu kako bi odgovarao trenutnom SNR-u, kako je opisano u IEEE 802.11ac standardu. Modulacija ovog signala koristi adaptivnu faznu amplitudnu modulaciju, i kako se SNR poboljšava, modulator može koristiti veći broj diskretnih tačaka koda u ovom faznom amplitudnom prostoru, čime se povećava efektivni kapacitet usluge dok se koristi konstantna frekvencija nosioca signala. Ono što ovo implicira je da satelitska usluga pokušava da radi sa maksimalnom efikasnošću prenosa, i da bi to postigla, predajnik stalno prilagođava svoju signalnu modulaciju kako bi iskoristio trenutni SNR od satelitskog sistema. Gornjem sloju protokola upravljanja, usluga prenosa se čini kao da ima konstantno varirajući kapacitet kanala i kašnjenje.

Ku-band downlink sa Starlink satelita ima ukupno 8 kanala koji koriste OFDMA multipleksiranje. Svaki kanal ima analogni propusni opseg širine 240 MHz. Svaki kanal je podeljen na frejmove, koji se dalje deli korišćenjem TDMA multipleksiranja na 302 intervala, svaki od 4,4 µs, što zajedno sa guard intervalom čini svaki frejm 1.333 µs, ili 750 frejmova u sekundi. Svaki frejm sadrži zaglavlje koje sadrži informacije o satelitu, kanalu i modulaciji [6]. Implikacija je da postoji contention do 1,3 ms pod pretpostavkom da je svakom aktivnom korisniku dodeljen bar jedan interval po frejmu.

Ostaju nam četiri glavna faktora koji doprinose varijabilnosti kapaciteta Starlink usluge, a to su:

• varijabilnost mogućnosti modulacije signala, što je direktna posledica variranja SNR-a signala,

• varijabilnost latencije zbog relativnog kretanja satelita i zemaljskih antena,

• potreba za redovnim prebacivanjem sa jednog na drugi satelit, i

• varijabilnost izazvana deljenjem zajedničkog satelitskog prenosnog medijuma sa drugim korisnicima, što dovodi do konkurencije za slotove.

Jedan način da se vidi kako ovi faktori varijabilnosti utiču na karakteristike usluge jeste redovno merenje kapaciteta usluge korišćenjem alata za merenje. Rezultati takvog testa merenja kapaciteta Starlink usluge prikazani su na slici 2. Ovde je test SpeedTest merenja [7], sproveden na četvorosatnoj osnovi u periodu od avgusta 2023. do marta 2024. godine. Usluga pokazuje srednju vrednost protoka od oko 120 Mbps za Download, sa pojedinačnim merenjima od maksimalno 370 Mbps odnosno minimalno 10 Mbps, i protok za Upload od 15 Mbps, sa varijacijama između 5 Mbps do 50 Mbps.

Foto: Geoff Huston

U Internet svetu, ping [8] je vrlo star alat, ali u isto vreme je i dalje veoma koristan, što verovatno objašnjava njegovu dugovečnost. Slika 3 prikazuje grafikon kontinuiranog (flood) pinga preko Starlink veze od terminala na strani korisnika do prve IP krajnje tačke iza Starlink zemaljske stanice za interval od 380 sekundi. („Flooding” ping šalje novi ping paket svaki put kada se paket primi sa udaljenog kraja).

Foto: Geoff Huston

Prva glavna karakteristika koja je vidljiva u ovim ping podacima je da se minimalna latencija redovno menja svakih 15 sekundi. To ukazuje da se ova promena korelira sa prebacivanjem Starlink korisničkog terminala na drugi satelit. To implicira da korisnička oprema „prati” svaki satelit u intervalu od 15 sekundi, što odgovara uglu praćenja od 11 stepeni ugla.

Druga karakteristika je da se gubici paketa javljaju redovno u trenucima prebacivanja između satelita, i ređe usled prepreka, pada kvaliteta signala ili zagušenja.

Foto: Geoff Huston

Treća karakteristika je značajan porast latencije u trenutku kada se korisnik dodeli drugom satelitu. Najgori slučaj u ovom skupu podataka je porast sa 30 ms na 80 ms.

Na kraju, unutar svakog intervala od 15 sekundi tokom kojeg traje praćenje jednog satelita, varijacija latencije je relativno visoka. Prosečna varijacija jitter-a između sukcesivnih RTT (Round-trip time) intervala je 6,7 ms. Pikovi latencije pri prebacivanju nameću dodatnih 30 ms do 50 ms, što ukazuje na prisustvo velikih bafera u sistemu da bi se prevazišli problemi povezani sa promenom satelita. Da bi se ilustrovalo ovo ponašanje veze, skup ping podataka je filtriran da bi se uklonili efekti dodeljivanja satelita u sekundi 283 i sekundi 298. (Slika 5).

Foto: Geoff Huston

Ukupna stopa gubitka paketa, kada se meri pomoću ping-ova u intervalu od 1 sekunde, tokom dužeg perioda, je nešto iznad 1%, kao dugoročna prosečna stopa gubitka.

Performanse TCP protokola

TCP [9] je primer protokola koji se može okarakterisati kao sliding window positive acknowledgement protocol. Pošiljalac zadržava kopiju svih podataka koji su prosleđeni u IP sloj sistema, i briše tu lokalnu kopiju poslatih podataka tek kada dobije pozitivnu potvrdu prijema (acknowledgement) od primaoca.

Varijante TCP-a zasnovane su na varijacijama u kontroli brzine kojom pošiljalac prenosi podatke u mrežu i varijacijama u odgovoru na gubitak podataka. Klasična verzija TCP-a koristi linearno povećanje veličine „sending window” (tzv. prozora za slanje) dok nema gubitka, i prepolovljava window kao odgovor na gubitak paketa. Ovo je RENO TCP kontrolni algoritam. Njegova upotreba u današnjem Internetu je uglavnom zamenjena CUBIC TCP kontrolnim algoritmom [10] koji koristi varirajuću stopu uvećanja window-a, pokušavajući da stabilizuje brzinu slanja na nivou neposredno ispod nagomilavanja paketa u queue tj. bafer (što na kraju dovodi do gubitka paketa).

U opštim terminima, postoji mali skup zajedničkih pretpostavki o karakteristikama mrežne putanje za takve TCP kontrolne algoritme:

• Postoji stabilan maksimalni kapacitet putanje, gde termin stabilnost opisuje situaciju u kojoj je dostupni kapacitet puta relativno konstantan tokom nekoliko RTT intervala.
• Količina jitter-a (varijacija u kašnjenju end-to-end odnosno od kraja do kraja) je niska u odnosu na RTT.
• Prosečna stopa gubitka paketa je niska. U slučaju gubitaka zbog zagušenja, TCP kontrolni algoritmi obično tumače gubitak paketa kao znak da su baferi u mreži popunjeni, pri čemu je gubitak indikacija prelivanja bafera.

Očigledno je, kao što smo napomenuli, da prva dva uslova ne moraju nužno važiti za end-to-end putanje koje uključuju i Starlink kao komponentu. Profil gubitka je takođe drugačiji. Postoji potencijal za gubitak paketa zbog zagušenja, što je slučaj kod bilo kog asinhronog packet-switched medijuma, ali postoji dodatna vrsta gubitaka koja može nastati zbog promene satelita, kao i usled degradacije radio signala.

TCP obično reaguje na takve okoline koristeći konzervativne izbore.

Procena RTT-a je ujednačena prosečna vrednost merenja RTT-a, kojoj se dodaje srednja devijacija pojedinačnih merenja u odnosu na ovu prosečnu vrednost. Za Starlink, sa relativno visokim nivoom individualne varijacije u merenjima RTT-a, to znači da TCP pošiljalac može raditi sa procenom RTT-a koja je viša od minimalnog RTT-a, što će rezultirati slanjem podataka brzinom koja je niža od dostupnog kapaciteta sistema end-to-end.

Pojava gubitka paketa koji nije uzrokovan zagušenjem takođe može umanjiti performanse TCP-a. Uobičajeno, gubitak će naterati pošiljaoca da brzo smanji svoj transmission window, pod pretpostavkom da ako je ovaj gubitak uzrokovan prepunjenim baferom, pošiljalac treba da omogući da se ovi baferi isprazne, nakon čega će nastaviti slanje smanjenom brzinom, što bi trebalo da obnovi koherentnost kontrolnog mehanizma (feedback control loop).

Kako ovo radi u praksi?

Slika 6 prikazuje detaljan pregled TCP CUBIC sesije preko Starlink prenosne veze. U prvih 2 sekunde vidljivo je ponašanje uvećanja brzine slanja TCP-a tokom slow start segmenta, gde se transmit window size udvostručava u svakom RTT intervalu, dostižući vrhunac od 240 Mbps za 2 sekunde. Zatim pošiljalac prelazi u režim brzog smanjenja transmit window-a u narednoj sekundi, smanjujući brzinu slanja na 50 Mbps u roku od jedne sekunde. U ovom trenutku, čini se da se CUBIC funkcija za sprečavanje zagušenja aktivira, i brzina slanja se povećava na 70 Mbps tokom narednih 5 sekundi. Postoji jedan slučaj gubitka paketa koji uzrokuje pad brzine slanja nazad na 40 Mbps u osmoj sekundi. Preostali deo grafika pokazuje isto ponašanje sporog uvećanja brzine slanja i povremenih smanjenja brzine što je tipično za CUBIC.

Ova CUBIC sesija je postigla prosečnu brzinu prenosa od oko 45 Mbps, što je znatno ispod najvišeg nominalnog kapaciteta veze od oko 250 Mbps, kako je naznačeno SpeedTest-om.

Foto: Geoff Huston

Starlink je deljeni medijum prenosa podataka, i performanse sistema tokom vremena kada se malo koristi (van pika - špica) značajno se razlikuju od performansi u piku (tokom špica). Slika 7 prikazuje CUBIC profil performansi tokom vremena van pika upotrebe.

Foto: Geoff Huston

Razlika u postignutoj brzini u vremenima između vremena tokom pika upotrebe (onpeak, u špicu) i van pika (offpeak, van špica) je prilično značajna, gde pritom brzina prenosa van pika dostiže nivo nekoliko puta veći od brzine prenosa u vremenima tokom pika. Faza slow start povećava brzinu do oko 200 Mbps u prvom sekundi. Zatim flow oscilira u drugoj sekundi, da bi se onda aktivirao mehanizam za izbegavanja zagušenja - ali dosta stabilnije - do četvrte sekunde. Ponašanje uvećanja window size kod CUBIC-a je vidljivo do dvanaeste sekunde, nakon čega flow oscilira oko 200 Mbps protoka tokom ostatka sesije.

Da li je razlika između ovih profila na slikama 6 i 7 rezultat aktivnog upravljanja protokom od strane Starlink opreme, ili rezultat načina na koji CUBIC postiže ravnotežu protoka sa drugim istovremenim protocima?

Možemo pokušati da odgovorimo na ovo pitanje korišćenjem drugog TCP protokola kontrole zagušenja koji ima potpuno drugačiji odgovor na zagušenje sa drugim istovremenim protocima.

Bottleneck Bandwidth and Round-trip propagation time Protocol (BBR) [11] je TCP algoritam za kontrolu zagušenja razvijen pre desetak godina u Google-u. BBR pokušava da pozicionira TCP flow na sam početak formiranja queue-a u mreži odnosno punjenja bafera, umesto da oscilira između stanja punih i praznih bafera (kako je slučaj sa većinom loss-based TCP algoritama za kontrolu zagušenja).

Nakratko, BBR pravi početnu procenu parametara latencije i propusnosti veze, i potom podstiče pošiljaoca da šalje po toj stopi u narednih 6 RTT intervala. Izgubljeni paketi se retransmituju bez promene brzine slanja. U sedmom RTT interval dolazi do povećanja brzine slanja za 25%, a istovremeno se end-to-end kašnjenje pažljivo meri u ovom intervalu. Kod poslednjeg RTT interval u ciklusu dolazi do smanjenje brzine slanja za 25% u odnosu na početnu brzinu, što izaziva namenjeno pražnjenju bilo kakvih bafera koji su se formirali u prethodnom RTT intervalu. Ako se end-to-end kašnjenje povećalo u intervalu povećane brzine slanja, originalna brzina slanja se održava. Ako povećanje transmit window-a nije uticalo na end-to-end kašnjenje, to ukazuje da veza ima dodatni kapacitet, pa se procena kašnjenja i propusnosti povećava za sledeći 8-RTT ciklus. (Postojale su nekoliko naknadnih revizija BBR protokola, ali u ovom slučaju koristimo originalnu (v1) verziju BBR.)

Rezultati testa performansi Starlink-a korišćenjem BBR su prikazani na slici 8.

Foto: Geoff Huston

Iz ovog testa, BBR je napravio početnu procenu propusnosti veze od oko 250Mbps. Ova procena je izgleda revidirana nakon 14 sekundi na oko 350Mbps, da bi se zatim smanjila na oko 200Mbps 15 sekundi kasnije, tokom poslednjih 10 sekundi ovog testa. Verovatno je da su ove promene rezultat BBR-ovog odgovora na prebacivanje na drugi satelit od strane Starlinka, gde je varijabilnost kašnjenja bila tumačena od strane BBR-a kao znak formiranja queue-ova, ili odsustva formiranja queue-ova, što je korišćeno za promenu BBR-ove procene propusnosti i kašnjenja za vezu.

Isti BBR test je izvršen u off-peak vremenu van špica, sa vrlo sličnim rezultatima (Slika 9).

Foto: Geoff Huston

Ako je BBR osetljiv na promene u latenciji, a latencija je tako promenljiva u Starlinku, zašto onda BBR ima bolje performanse u poređenju sa CUBIC?

Pretpostavljamo da ovde BBR ne uzima jedno merenje latencije, već meri round-trip vreme za sve pakete koji su poslati u tom sedmom intervalu, nakon što pošiljalac poveća svoju brzinu slanja na maksimalnu burst brzinu, i koristi minimalnu RTT vrednost kao ‘opterećenu’ RTT vrednost da bi odredio da li treba da prilagodi brzinu slanja. Dokle god su minimalni RTT nivoi dosledni, a, kao što je prikazano na slici 3, te minimalne vrednosti izgledaju dosledno kroz svaki 15-sekundni interval rasporeda, BBR će pretpostaviti da njegova brzina slanja ne izaziva formiranje mrežnih queue-ova i zadržaće svoju brzinu slanja.

Štelovanje protokola za Starlink

Starlink pruža prilično jedinstvenu uslugu prenosa podataka. Ima veoma visoku stopu jitter-a, stopu gubitka paketa od oko 1%-2% koja nije povezana sa zagušenošću mreže, i profil latencije koji se redovno menja svakih 15 sekundi. Iz perspektive TCP protokola, Starlink predstavlja neobično neprijateljsko okruženje za vezu, a starije varijante TCP algoritama, kao što je Reno TCP, koje brzo reaguju na gubitak paketa i sporo se oporavljaju, mogu veoma loše raditi kada se koriste preko Starlink konekcija.

Da li je moguće podesiti algoritam TCP-a kako bismo optimizovali njegove performanse preko veze koja sadrži Starlink komponentu?

Obećavajući pristup bi mogao da počne sa varijantom BBR-a. Razlog za izbor BBR-a je njegova sposobnost da zadrži stopu slanja uprkos pojedinačnim događajima gubitka paketa. Ako bismo optimizovali BBR za Starlink, može se primetiti da Starlink vrši prebacivanje satelita u redovnim intervalima od 15 sekundi, i ako se redovno povećanje brzine slanja u BBR-u dogodi u isto vreme kao i planirano prebacivanje satelita, BBR pošiljalac bi mogao da odloži svoje povećanje brzine slanja, održavajući trenutnu brzinu slanja tokom planiranog vremena prebacivanja.

Problem sa BBR-om je što, za verziju 1 ovog protokola, on može biti prilično agresivan u preuzimanju mrežnih resursa, što može uskraćivati kapacitet drugim istovremenim TCP sesijama koje ne koriste BBR. Jedan mogući odgovor je korišćenje istog 15-sekundnog tajmera za prebacivanje satelita sa verzijom 3 BBR protokola, koji je namenjen da bude manje agresivan pri radu sa istovremenim tokovima podataka.

Teoretski, bilo bi moguće prilagoditi CUBIC na sličan način, izvodeći popravku izgubljenog paketa korišćenjem Selektivnog Acknowledgement-a (SACK) [11] ako se gubitak paketa dogodi u vreme planiranog prebacivanja satelita. Dok je CUBIC pravedniji protokol u pogledu deljenja kapaciteta puta sa drugim istovremenim TCP sesijama, on ima tendenciju da reaguje konzervativno kada se suoči sa putanjama sa visokim jitter-om (kao što je slučaj kada putanja od kraja do kraja uključuje Starlink komponentu). Čak i sa određenom osetljivošću na planirana prebacivanja satelita, CUBIC je i dalje sklon smanjenoj efikasnosti u korišćenju mrežnih resursa.

Nešto drugačiji pristup bi mogao koristiti eksplicitno obaveštenje o zagušenju (ECN) [12]. Prednost takvog pristupa je što omogućava TCP sesiji da razlikuje slučaj kada visoka brzina slanja uzrokuje formiranje mrežnih queue-ova (kongestiju), dok tranzijentni događaj, kao što je prebacivanje satelita, uzrokuje gubitak paketa bez formiranja mrežnih queue-ova. ECN može omogućiti ponašanje kontrole toka koje je vrlo slično BBR-u.

Zaključci

Dok su raniji TCP kontrolni algoritmi, kao što je Reno, pokazali loše performanse na Starlink vezama, noviji TCP protokoli, kao što je CUBIC, rade efikasnije. Glavna TCP funkcija koja čini ove protokole održivim u kontekstima Starlink-a je korišćenje Selektivnog Acknowledgement-a [11], koji omogućava TCP kontrolnom algoritmu da razlikuje izolovani gubitak paketa od nivoa kongestije u mreži koji izazivaju gubitak.

TCP kontrolni protokoli koji pokušavaju da otkriju početak formiranja mrežnih queue-ova to mogu učiniti koristeći end-to-end tehnike detekcijom promena u end-to-end latenciji tokom povremenih perioda burst-a, kao što je BBR. Ovi protokoli moraju da funkcionišu sa pažljivom implementacijom svoje osetljivosti na latenciju, jer visoko nestabilna kratkoročna latencija viđena na Starlink vezama, u kombinaciji sa 15-sekundnim promjenama latencije, može zbuniti algoritam za detekciju početka formiranja queue-ova.

Bilo bi zanimljivo posmatrati ponašanje TCP protokola koji je svestan ECN-a ako bi ECN bio omogućen na Starlink ruterima. ECN ima potencijal da pruži jasan signal krajnjim tačkama o početku formiranja mrežnih queue-ova, što je različito od varijacije latencije.

Ovaj tekst je prevod teksta „A Transport Protocol’s View of Starlink” koji je napisao Geoff Huston. Original dostupan na linku: potaroo.net. Sadržaj reprodukovan uz dozvolu autora.

Izvori: