Internett over parabol ?
Lars Engen
??
--
Lars Engen
http://members.xoom.com/larsengen/
---
Combine the worst elements from a lavatory cistern,
a bagpipe and a dead poodle and you would get something similar to the Fiat
Multipla
Espen Vestre
> Finnes det noen nettilbydere som har kommet med internett over parabol ennå
> ??
det er jo blitt lansert minst 1 gang i året de siste 6 årene, men det
blir ikke noe lurere av den grunn. Vel kan det være mulig å lage noen
asymmetriske løsninger hvor download skjer via parabol, men generell
internettilknytning via geostasjonær satelitt er og blir en særdeles
dårlig ide.
--
(espen)
Gunnar Liknes
> det er jo blitt lansert minst 1 gang i året de siste 6 årene, men det
> blir ikke noe lurere av den grunn. Vel kan det være mulig å lage noen
> asymmetriske løsninger hvor download skjer via parabol, men generell
> internettilknytning via geostasjonær satelitt er og blir en særdeles
> dårlig ide.
Det må være derfor universitetet i Tel-Aviv valgte en 45mbit satelitt
forbindelse til Universitet i Chigago istedenfor en landbasert løsning
ifbm tilknytningen til Internet II.
Internet over satelitt fungerer bra, men jeg skal kunne være enig i at
om online spilling er hoved poenget med forbindelsen, bør man
ikke velge en ren satelitt løsning.
For punkt til punkt forbindelser vil ofte satelittforbindelser være
bedre enn landbaserte løsninger, særlig interkontinentale
forbindelserog lukkede nett. For punkt til multipunkt vil nesten
alltid satelittløsninger være best.
Prøv å pinge en server i statene med 1500 bytes ping pakker, og
du vil få en RTT på mellon 450 og 700 ms. Med en satelitt-
forbindelse (mellom deg og serveren du pinger) ville du hatt
en fast RTT på ca 540ms.
Jeg er litt enig med deg i at for privatbrukere vil Internet over
parabol gi høyere RTT enn en landbasert tilknyntning i de
fleste tilfeller, og vil derfor være en dårligere løsning for
brukere av 'intensive' tjenester (spill f.eks.). Om hoved
bruken er filoverføringer vil imidlertid ikke en noe høyere
RTT spille noen rolle.
Gunnar
Lars Erik Gullerud
"Bjørn Mork" <bm...@dod.no> wrote in message
news:hvbsr1v...@spip.ws.nextra.no...
> "Gunnar Liknes" <gli...@online.no> writes:
>
> > Prøv å pinge en server i statene med 1500 bytes ping pakker, og
> > du vil få en RTT på mellon 450 og 700 ms. Med en satelitt-
> > forbindelse (mellom deg og serveren du pinger) ville du hatt
> > en fast RTT på ca 540ms.
>
>
> sunray2(bmork):~$ ping -s hobbes.nmsu.edu 1500 10
> PING hobbes.nmsu.edu: 1500 data bytes
> 1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=0. time=179. ms
> 1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=1. time=180. ms
[snip]
>
> (hobbes befinner seg i New Mexico, altså ganske langt fra der
> atlanterhavskablene ender opp)
La oss gå enda et skritt lenger, mesteparten av trafikken til Asia må krysse
både atlanterhavet, det amerikanske kontinent, og så stillehavet fra
vestkysten av USA:
PING sony.co.jp (202.238.80.18): 1500 data bytes
1508 bytes from 202.238.80.18: icmp_seq=0 ttl=229 time=306.143 ms
1508 bytes from 202.238.80.18: icmp_seq=1 ttl=229 time=305.968 ms
1508 bytes from 202.238.80.18: icmp_seq=2 ttl=229 time=306.362 ms
[snip]
og sony.co.jp er intet unntak, men jeg skal spare folket for nok en lang
traceroute.
Fortsatt omtrent halvparten av hva en satelittbasert forbindelse ville
prestert.
/leg
Bjørn Mork
> Internet over satelitt fungerer bra, men jeg skal kunne være enig i at
> om online spilling er hoved poenget med forbindelsen, bør man
> ikke velge en ren satelitt løsning.
>
> For punkt til punkt forbindelser vil ofte satelittforbindelser være
> bedre enn landbaserte løsninger, særlig interkontinentale
> forbindelserog lukkede nett. For punkt til multipunkt vil nesten
> alltid satelittløsninger være best.
>
> Prøv å pinge en server i statene med 1500 bytes ping pakker, og
> du vil få en RTT på mellon 450 og 700 ms. Med en satelitt-
> forbindelse (mellom deg og serveren du pinger) ville du hatt
> en fast RTT på ca 540ms.
Landbaserte linjer banker satellitt uansett avstand og pakkestørrelse.
sunray2(bmork):~$ ping -s hobbes.nmsu.edu 1500 10
PING hobbes.nmsu.edu: 1500 data bytes
1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=0. time=179. ms
1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=1. time=180. ms
1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=2. time=179. ms
1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=3. time=179. ms
1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=4. time=178. ms
1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=5. time=181. ms
1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=6. time=179. ms
1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=7. time=179. ms
1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=8. time=178. ms
1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=9. time=178. ms
----hobbes.nmsu.edu PING Statistics----
10 packets transmitted, 10 packets received, 0% packet loss
round-trip (ms) min/avg/max = 178/179/181
sunray2(bmork):~$ traceroute hobbes.NMSU.Edu
traceroute: Warning: Multiple interfaces found; using 148.122.207.142 @ hme0
traceroute to hobbes.NMSU.Edu (128.123.3.50), 30 hops max, 40 byte packets
[..]
8 ti01c03-ge3-1.ti.telenor.net (130.67.0.1) 2.718 ms 2.595 ms 2.549 ms
9 ti01c01-ge9-0-0.ti.telenor.net (130.67.61.199) 2.839 ms 5.912 ms 3.227 ms
10 nb01b01-ge5-0-0.nb.telenor.net (148.122.66.33) 3.789 ms 3.149 ms 3.044 ms
11 nb03b01-pos6-0-0.nb.telenor.net (148.122.65.14) 90.157 ms 89.859 ms 90.082 ms
12 sl-gw7-nyc-6-0-0.sprintlink.net (144.232.172.25) 96.890 ms 92.538 ms 91.245 ms
13 sl-bb12-nyc-3-3.sprintlink.net (144.232.7.81) 91.797 ms 90.618 ms 93.965 ms
14 sl-bb20-nyc-6-0.sprintlink.net (144.232.7.121) 93.730 ms 93.091 ms 94.851 ms
15 sl-bb22-rly-13-0.sprintlink.net (144.232.9.226) 104.096 ms 103.497 ms 103.356 ms
16 sl-bb20-sj-9-0.sprintlink.net (144.232.9.218) 158.592 ms 156.497 ms 158.078 ms
17 sl-bb20-ana-11-0.sprintlink.net (144.232.18.181) 152.488 ms 153.156 ms 152.569 ms
18 sl-gw12-ana-0-0-0.sprintlink.net (144.232.1.66) 153.756 ms 152.241 ms 153.272 ms
19 sl-nmsu-2-0-0.sprintlink.net (144.228.207.226) 168.610 ms 171.477 ms 174.875 ms
20 can-gate-fe1-0.NMSU.Edu (128.123.100.18) 167.808 ms 169.744 ms 169.154 ms
21 hobbes.NMSU.Edu (128.123.3.50) 169.897 ms 167.812 ms 171.780 ms
(hobbes befinner seg i New Mexico, altså ganske langt fra der
atlanterhavskablene ender opp)
Bjørn
Lars Erik Gullerud
"Gunnar Liknes" <gli...@online.no> wrote in message
news:6%rs6.1200$mh4....@news3.oke.nextra.no...
> For punkt til punkt forbindelser vil ofte satelittforbindelser være
> bedre enn landbaserte løsninger, særlig interkontinentale
> forbindelserog lukkede nett. For punkt til multipunkt vil nesten
> alltid satelittløsninger være best.
Punkt til multipunkt - ja. Enkelte spesielle løsninger - ja. Stort sett alt
annet, herunder generell internettilgang - nei. Min kollega Morten Reistad
har tidligere skrevet endel om dette bl.a. i denne gruppen, vi har tidligere
hatt en satelittbasert løsning i drift en god stund (72Mbit VSAT) og kjenner
ganske godt til begrensningene dette medfører.
> Prøv å pinge en server i statene med 1500 bytes ping pakker, og
> du vil få en RTT på mellon 450 og 700 ms. Med en satelitt-
[snip]
Sending 20, 1500-byte ICMP Echos to 198.133.219.25, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 160/161/180 ms
Hvordan fant du på de tallene dine egentlig? Hadde jeg levert 450ms (jeg vil
ikke engang SNAKKE om 700ms) til statene, uansett pakkestørrelse, hadde jeg
fått sparken. (Den aktuelle hosten her var forøvrig www.cisco.com, som
ligger omtrent midt på treet for vår del, gjennomsnittlig latency til USA
fra forskjellige leverandører i Norge varierer fra 120 til 220 ms avhengig
av destinasjon i USA og hvilke providere som sitter på siste stykket i USA)
> forbindelse (mellom deg og serveren du pinger) ville du hatt
> en fast RTT på ca 540ms.
Hadde du hatt en fast jordbasert forbindelse mellom deg og serveren du
pinger ville du hatt en akkurat like stabil (som regel MER stabil) latency
som med en satelittforbindelse. Hva har det med saken å gjøre? Har man en
internet-tilgang via satelitt har man typisk forbindelse med en (evt. fler)
jordstasjoner på gitte lokasjoner, på samme måte som man kan ha f.eks. en
vanlig SDH-basert forbindelse til gitte lokasjoner og aksessere resten av
Internet derfra. Jeg ser ikke helt hvor du vil hen med det resonnementet.
> Jeg er litt enig med deg i at for privatbrukere vil Internet over
> parabol gi høyere RTT enn en landbasert tilknyntning i de
> fleste tilfeller, og vil derfor være en dårligere løsning for
> brukere av 'intensive' tjenester (spill f.eks.). Om hoved
> bruken er filoverføringer vil imidlertid ikke en noe høyere
> RTT spille noen rolle.
Ikke korrekt. Satelitt er et typisk eksempel på "long fat pipe" syndromet.
Satelittbaserte overføringer rammes av de fleste TCP-implementasjoners max
window size. TCP-trafikk over satelitt vil bli "bursty" med mindre man tuner
TCP-stacken til de aktuelle maskiner manuelt. Hvorfor?
Med et TCP-vindu på 1000 bytes (for å gjøre det enkelt), så vil
avsendermaskin ha høy nok båndbredde tilgjengelig til å få 1000 bytes inn i
"pipeline" svært hurtig. Men grunnet høy latency vil den ikke motta noen ACK
fra mottaker før en god stund etter disse pakkene er "avlevert", og avsender
vil stoppe utsendelsen av ytterligere pakker. Når så ACK begynner å komme
tilbake fra mottaker vil avsender fortsette å sende, osv.
Dette medfører at man ikke får på langt nær utnyttet tilgjengelig kapasitet
til filoverføringer osv. (med mindre man har et svært høyt antall
individuelle TCP-sesjoner som sammenlagt utnytter ressursene). Løsninger på
dette er selvfølgelig mulig, ved å tune max window size slik at flere pakker
kan være "i transit" til enhver tid uten av avsender trenger å stanse opp,
men krever endel arbeid og må typisk optimiseres for individuelle forhold.
Og selv om justering av TCP-windows på LFP'er som f.eks. er lange
fiberstrekk fungerer svært godt, er satellittsamband langt mer sårbare for
overføringsfeil (til tross for error-correction i selve transmisjonslaget),
og f.eks. en CRC-feil når man har et høyt antall pakker i transit vil som
kjent føre til at alle påfølgende pakker må resendes, ikke bare den aktuelle
feilpakken, og ergo blir det svært forstyrrende for overføringen hver gang
det oppstår en feil.
En satelittløsning er heller ikke BILLIG. Se endel aktuelle priser i høyere
båndbreddesjikter i Morten Reistad's posting
news:95ekrr$p08$1...@oslo-nntp.eunet.no for litt info om dette. I korte trekk,
med unntak av lokasjoner der jordbasert kommunikasjon er begrenset eller
svært dyrt (Australia og deler av Asia er eksempler på lokasjoner der
satelitt er utbredt), er satelitt lite egnet til bruksområdet
Internet-tilgang, med unntak av spesielle tjenester som f.eks. newsfeeds.
Men for all del - har du noen hundre tusen å avse, så kan jeg skaffe deg en
pent brukt jordinstallasjon for VSAT, og telefonnummeret til KPN Satellite
hvor du kan bestille deg en forbindelse ut i verden for ytterligere noen
hundre tusen per år...
/leg
Gunnar Liknes
> "Gunnar Liknes" wrote in message
> news:6%rs6.1200$mh4....@news3.oke.nextra.no...
>
> > For punkt til punkt forbindelser vil ofte satelittforbindelser være
> > bedre enn landbaserte løsninger, særlig interkontinentale
> > forbindelserog lukkede nett. For punkt til multipunkt vil nesten
> > alltid satelittløsninger være best.
>
> Punkt til multipunkt - ja. Enkelte spesielle løsninger - ja. Stort sett alt
> annet, herunder generell internettilgang - nei. Min kollega Morten Reistad
> har tidligere skrevet endel om dette bl.a. i denne gruppen, vi har tidligere
> hatt en satelittbasert løsning i drift en god stund (72Mbit VSAT) og kjenner
> ganske godt til begrensningene dette medfører.
Tydeligvis ikke. Hvem leverte den satelittforbindelsen?
> > Prøv å pinge en server i statene med 1500 bytes ping pakker, og
> > du vil få en RTT på mellon 450 og 700 ms. Med en satelitt-
> [snip]
>
> Sending 20, 1500-byte ICMP Echos to 198.133.219.25, timeout is 2 seconds:
> !!!!!!!!!!!!!!!!!!!!
> Success rate is 100 percent (20/20), round-trip min/avg/max = 160/161/180 ms
>
> Hvordan fant du på de tallene dine egentlig? Hadde jeg levert 450ms (jeg vil
> ikke engang SNAKKE om 700ms) til statene, uansett pakkestørrelse, hadde jeg
> fått sparken. (Den aktuelle hosten her var forøvrig www.cisco.com, som
> ligger omtrent midt på treet for vår del, gjennomsnittlig latency til USA
> fra forskjellige leverandører i Norge varierer fra 120 til 220 ms avhengig
> av destinasjon i USA og hvilke providere som sitter på siste stykket i USA)
Tallene kom jeg frem til ved å prøve å pinge foskjellig servere i USA fra min
hjemme PC med Chello internet tilknytning. Jeg har tidligere funnet tilsvarende
verdier når jeg pinget fra min tidligere arbeidsplass hvor jeg satt på et
100 Mbit switchet Ethernet med en 2Mbit fast forbindelse til UUNETs node
i Stochholm som vi var neste alene om å bruke.
Eksempler:
Pinging 198.133.219.25 with 32 bytes of data:
Reply from 198.133.219.25: bytes=32 time=233ms TTL=235
Reply from 198.133.219.25: bytes=32 time=220ms TTL=235
Reply from 198.133.219.25: bytes=32 time=233ms TTL=235
Reply from 198.133.219.25: bytes=32 time=220ms TTL=235
Dette med standard 32 byte ping fra min hjemme PC, jeg fikk bare timeout
når jeg prøvde med 1500 byte.
Pinging www.schlumberger.com [192.23.80.15] with 1500 bytes of data:
Reply from 192.23.80.15: bytes=1500 time=563ms TTL=235
Reply from 192.23.80.15: bytes=1500 time=480ms TTL=235
Reply from 192.23.80.15: bytes=1500 time=481ms TTL=235
Reply from 192.23.80.15: bytes=1500 time=439ms TTL=235
Pinging www.verestar.com [63.103.134.110] with 1500 bytes of data:
Reply from 63.103.134.110: bytes=1500 time=275ms TTL=108
Reply from 63.103.134.110: bytes=1500 time=687ms TTL=107
Reply from 63.103.134.110: bytes=1500 time=631ms TTL=107
Reply from 63.103.134.110: bytes=1500 time=645ms TTL=108
> > forbindelse (mellom deg og serveren du pinger) ville du hatt
> > en fast RTT på ca 540ms.
>
> Hadde du hatt en fast jordbasert forbindelse mellom deg og serveren du
> pinger ville du hatt en akkurat like stabil (som regel MER stabil) latency
> som med en satelittforbindelse. Hva har det med saken å gjøre? Har man en
> internet-tilgang via satelitt har man typisk forbindelse med en (evt. fler)
> jordstasjoner på gitte lokasjoner, på samme måte som man kan ha f.eks. en
> vanlig SDH-basert forbindelse til gitte lokasjoner og aksessere resten av
> Internet derfra. Jeg ser ikke helt hvor du vil hen med det resonnementet.
Enig, for de fleste punkt til punkt til punkt forbindelser.
> > Jeg er litt enig med deg i at for privatbrukere vil Internet over
> > parabol gi høyere RTT enn en landbasert tilknyntning i de
> > fleste tilfeller, og vil derfor være en dårligere løsning for
> > brukere av 'intensive' tjenester (spill f.eks.). Om hoved
> > bruken er filoverføringer vil imidlertid ikke en noe høyere
> > RTT spille noen rolle.
>
> Ikke korrekt. Satelitt er et typisk eksempel på "long fat pipe" syndromet.
> Satelittbaserte overføringer rammes av de fleste TCP-implementasjoners max
> window size. TCP-trafikk over satelitt vil bli "bursty" med mindre man tuner
> TCP-stacken til de aktuelle maskiner manuelt. Hvorfor?
>
<snip begrunnelse>
Alle disse problemene løses ved å sette inn en protokoll konverter
(Tidligere feilaktig kalt TCP spoofing)
> En satelittløsning er heller ikke BILLIG. Se endel aktuelle priser i høyere
> båndbreddesjikter i Morten Reistad's posting
> news:95ekrr$p08$1...@oslo-nntp.eunet.no for litt info om dette. I korte trekk,
> med unntak av lokasjoner der jordbasert kommunikasjon er begrenset eller
> svært dyrt (Australia og deler av Asia er eksempler på lokasjoner der
> satelitt er utbredt), er satelitt lite egnet til bruksområdet
> Internet-tilgang, med unntak av spesielle tjenester som f.eks. newsfeeds.
Jeg sier ikke satelitt er generelt billigere enn kabel, men satelitt er i mange
tilfeller det.
Satelitt kommunikasjon utgjør 7% av omsetningen i verdens totale
telekommunikasjonsmarked. Dette tallet er ganske representativt for
de tilfeller hvor satelitt er den beste løsningen. Etterhvert som
bredbåndstjester tar av og 'Broadcast tjenester' smelter sammen med
'Internet tjenester' vil denne andelen øke.
> Men for all del - har du noen hundre tusen å avse, så kan jeg skaffe deg en
> pent brukt jordinstallasjon for VSAT, og telefonnummeret til KPN Satellite
> hvor du kan bestille deg en forbindelse ut i verden for ytterligere noen
> hundre tusen per år...
En pent brukt jordinstallasjon for VSAT er jeg faktisk veldig interressert i.
Telefonnummeret til KPN har jeg allerede (Også direkte nummeret til
Adm. Dir.), men jeg regner ikke dem for å være det beste alternativet
for noen som trenger satelittløsninger.
Vennlig Hilsen
Gunnar Liknes
Gunnar Liknes
> "Gunnar Liknes" writes:
> > Internet over satelitt fungerer bra, men jeg skal kunne være enig i at
> > om online spilling er hoved poenget med forbindelsen, bør man
> > ikke velge en ren satelitt løsning.
> >
> > For punkt til punkt forbindelser vil ofte satelittforbindelser være
> > bedre enn landbaserte løsninger, særlig interkontinentale
> > forbindelserog lukkede nett. For punkt til multipunkt vil nesten
> > alltid satelittløsninger være best.
> >
> > Prøv å pinge en server i statene med 1500 bytes ping pakker, og
> > du vil få en RTT på mellon 450 og 700 ms. Med en satelitt-
> > forbindelse (mellom deg og serveren du pinger) ville du hatt
> > en fast RTT på ca 540ms.
>
> Landbaserte linjer banker satellitt uansett avstand og pakkestørrelse.
>
> sunray2(bmork):~$ ping -s hobbes.nmsu.edu 1500 10
> PING hobbes.nmsu.edu: 1500 data bytes
> 1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=0. time=179. ms
> 1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=1. time=180. ms
> 1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=2. time=179. ms
Pinging 128.123.3.50 with 32 bytes of data:
Reply from 128.123.3.50: bytes=32 time=495ms TTL=234
Reply from 128.123.3.50: bytes=32 time=536ms TTL=234
Reply from 128.123.3.50: bytes=32 time=494ms TTL=234
Reply from 128.123.3.50: bytes=32 time=495ms TTL=234
Pinging 128.123.3.50 with 1500 bytes of data:
Reply from 128.123.3.50: bytes=1500 time=796ms TTL=234
Reply from 128.123.3.50: bytes=1500 time=426ms TTL=234
Reply from 128.123.3.50: bytes=1500 time=742ms TTL=234
Reply from 128.123.3.50: bytes=1500 time=727ms TTL=234
Gunnar
Morten Reistad
Lars Erik Gullerud <lars...@gullerud.net> wrote:
>
>"Gunnar Liknes" <gli...@online.no> wrote in message
>news:6%rs6.1200$mh4....@news3.oke.nextra.no...
>
>> For punkt til punkt forbindelser vil ofte satelittforbindelser være
>> bedre enn landbaserte løsninger, særlig interkontinentale
>> forbindelserog lukkede nett. For punkt til multipunkt vil nesten
>> alltid satelittløsninger være best.
>
>Punkt til multipunkt - ja. Enkelte spesielle løsninger - ja. Stort sett alt
>annet, herunder generell internettilgang - nei. Min kollega Morten Reistad
>har tidligere skrevet endel om dette bl.a. i denne gruppen, vi har tidligere
>hatt en satelittbasert løsning i drift en god stund (72Mbit VSAT) og kjenner
>ganske godt til begrensningene dette medfører.
Og 72mbit er omtrent det man får ut av én transponder med 8qpsk og
5/6 FEC; som er omtrent grensen for hva man klarer med skapelig store
paraboler. For en toveis lik benytter man da begge polarisasjonsplan
i samme transponder; dvs én full transponder.
>> Prøv å pinge en server i statene med 1500 bytes ping pakker, og
>> du vil få en RTT på mellon 450 og 700 ms. Med en satelitt-
>[snip]
>
>Sending 20, 1500-byte ICMP Echos to 198.133.219.25, timeout is 2 seconds:
>!!!!!!!!!!!!!!!!!!!!
>Success rate is 100 percent (20/20), round-trip min/avg/max = 160/161/180 ms
En enkelt satellittlink fra Norge via geostasjonær bane 34ø; og til
Sloterdijk utenfor Amsterdam ga en rtt på 576 ms. Og pakketapet var
i lendet 4-8 promille; på GODE dager. Og jevn er den heller ikke,
grunnet at det originalt er en bitfeilrate på rundt 4 x 10^2 (1
av 400 bit er feil); som ved feilkorreksjon bedres til 2 x 10^6.
Erfaringen min er at det heller er 6-8 x 10^5 som er realiteten.
Alt dette er veldig dårlig nytt for TCP.
>Hvordan fant du på de tallene dine egentlig? Hadde jeg levert 450ms (jeg vil
>ikke engang SNAKKE om 700ms) til statene, uansett pakkestørrelse, hadde jeg
>fått sparken. (Den aktuelle hosten her var forøvrig www.cisco.com, som
>ligger omtrent midt på treet for vår del, gjennomsnittlig latency til USA
>fra forskjellige leverandører i Norge varierer fra 120 til 220 ms avhengig
>av destinasjon i USA og hvilke providere som sitter på siste stykket i USA)
>> forbindelse (mellom deg og serveren du pinger) ville du hatt
>> en fast RTT på ca 540ms.
540 er direkte via geostasjonær satellitt på samme lengdegrad som
deg selv. Dette er sjelden tilfelle i praksis. Telecom-satellitter
er flytte ut fra de mest populære posisjonene (spesielt 12ø-5v og
områdene rundt 25-40v og 130-140v veldig opptatt).
>Hadde du hatt en fast jordbasert forbindelse mellom deg og serveren du
>pinger ville du hatt en akkurat like stabil (som regel MER stabil) latency
>som med en satelittforbindelse. Hva har det med saken å gjøre? Har man en
>internet-tilgang via satelitt har man typisk forbindelse med en (evt. fler)
>jordstasjoner på gitte lokasjoner, på samme måte som man kan ha f.eks. en
>vanlig SDH-basert forbindelse til gitte lokasjoner og aksessere resten av
>Internet derfra. Jeg ser ikke helt hvor du vil hen med det resonnementet.
Sending med satellitt fra USA er og underlagt egne regler; der man
må være en egen operatør; som ikke kan eies av noen LEC eller LD
operatør, eller kabeloperatør. Dette gjelder ikke interne amerikanske
samband. Derfor er det vanskelig å ta satellittveien til USA direkte
for tilkobling til Internetttet der.
Dette er helt riktig et stort problem. 'Vanlig' TCP kan ha et effektivt
vindu på 65536 minus én MTU; 64000 er vanlig brukt, ettersom 1500 er
vanligste begrensningen i Internettet. Med dette kan man i en RTT;
som med denne satellittlinken blir rund 650 ms; skrive 64000 bytes;
eller 43 pakker. Maksimal effektiv hastighet blir da 788 kilobit per
sesjon. Litt lite for en 72 megabit link.
Med skalerte vinduer i TCP kan man f.eks skalere med 16 (det meste
jeg har sett i praksis); og da blir det 64000 x 16 = 1024000; eller
682 pakker. Imidlertid blir én av hver 250 pakker borte; og man
må deretter resende en pakke. Maksimal rate blir dermed blir maksimal
oppnåelig hastighet rundt 4.6 megabit; grunnet støy. Hastigheten vil
og pendle vilt opp og ned ettersom det er pakker som blir borte.
Akkurat dette kan man oppleve i praksis dersom en satellittlink tar
over for en jordlink. Hvis en jordlink med en last på f.eks.. 30 megabit
faller ned og trafikken rerutes over satellitt ser man at trafikken
detter til godt under det halve; for eksemplet rundt 12 megabit; men
at det pendler vilt opp og ned fra 8 til 18 megabit over korte
intervaller på 1-2 sekunder. Min konklusjon er at satellittlinker
er lite egnet til en vanlig internettmiks med tcp/ip-trafikk.
>En satelittløsning er heller ikke BILLIG. Se endel aktuelle priser i høyere
>båndbreddesjikter i Morten Reistad's posting
>news:95ekrr$p08$1...@oslo-nntp.eunet.no for litt info om dette. I korte trekk,
>med unntak av lokasjoner der jordbasert kommunikasjon er begrenset eller
>svært dyrt (Australia og deler av Asia er eksempler på lokasjoner der
>satelitt er utbredt), er satelitt lite egnet til bruksområdet
>Internet-tilgang, med unntak av spesielle tjenester som f.eks. newsfeeds.
>
>Men for all del - har du noen hundre tusen å avse, så kan jeg skaffe deg en
>pent brukt jordinstallasjon for VSAT, og telefonnummeret til KPN Satellite
>hvor du kan bestille deg en forbindelse ut i verden for ytterligere noen
>hundre tusen per år...
BZZT. Euro. Vanlig leie av en full transponder er rundt 120.000 per mnd.
Jordstasjoner er vanligvis rundt 350.000 per stk; og så skal du
handle en link til interrettet. For rundt 200.000 per mnd kan du få
levert en slik link. Eks mva.
Dette egner seg VELDIG BRA som en krisebackup til store ISP'er; som
er lokalisert i land der det er mye single points of failures i
fibernettene. Hele Skandinavia var i denne kategorien inntil ganske
nylig; men mye av dette er løst nå.
Min arbeidsgiver har derfor en slik jordstasjon til salgs.
Kun seriøse henvendelser. :-)
-- Morten
Steinar Haug
| > Landbaserte linjer banker satellitt uansett avstand og pakkestørrelse.
| >
| > sunray2(bmork):~$ ping -s hobbes.nmsu.edu 1500 10
| > PING hobbes.nmsu.edu: 1500 data bytes
| > 1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=0. time=179. ms
| > 1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=1. time=180. ms
| > 1508 bytes from hobbes.NMSU.Edu (128.123.3.50): icmp_seq=2. time=179. ms
..
| Pinging 128.123.3.50 with 1500 bytes of data:
|
| Reply from 128.123.3.50: bytes=1500 time=796ms TTL=234
| Reply from 128.123.3.50: bytes=1500 time=426ms TTL=234
| Reply from 128.123.3.50: bytes=1500 time=742ms TTL=234
| Reply from 128.123.3.50: bytes=1500 time=727ms TTL=234
Følgelig slutter vi at det er høy forsinkelse i din Chello-baserte
Internet-tilknytning. Jeg kan bekrefte tallene til Bjørn Mork. Fra en
rimelig sentral maskin i UNINETT:
1480 bytes from 128.123.3.50: icmp_seq=0 ttl=242 time=166.917 ms
1480 bytes from 128.123.3.50: icmp_seq=1 ttl=242 time=166.649 ms
1480 bytes from 128.123.3.50: icmp_seq=2 ttl=242 time=165.948 ms
1480 bytes from 128.123.3.50: icmp_seq=3 ttl=242 time=166.054 ms
og fra Enitel:
1480 bytes from 128.123.3.50: icmp_seq=0 ttl=239 time=221.702 ms
1480 bytes from 128.123.3.50: icmp_seq=1 ttl=239 time=220.939 ms
1480 bytes from 128.123.3.50: icmp_seq=2 ttl=239 time=221.229 ms
1480 bytes from 128.123.3.50: icmp_seq=3 ttl=239 time=221.625 ms
Jeg synes det ser ut som du har grunn til å være misfornøyd med ditt
Chello-abonnement.
Jeg vil også anbefale deg å se på ping-tider (for 1500 byte pakker) fram
til sentrale maskiner i Norge (f.eks. sunsite.uio.no), bare for å se om
forsinkelsen ligger her i Norge.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
Steinar Haug
| Pinging www.schlumberger.com [192.23.80.15] with 1500 bytes of data:
|
| Reply from 192.23.80.15: bytes=1500 time=563ms TTL=235
| Reply from 192.23.80.15: bytes=1500 time=480ms TTL=235
| Reply from 192.23.80.15: bytes=1500 time=481ms TTL=235
| Reply from 192.23.80.15: bytes=1500 time=439ms TTL=235
Fra UNINETT:
1480 bytes from 192.23.80.15: icmp_seq=0 ttl=234 time=242.732 ms
1480 bytes from 192.23.80.15: icmp_seq=1 ttl=234 time=242.201 ms
1480 bytes from 192.23.80.15: icmp_seq=2 ttl=234 time=242.504 ms
1480 bytes from 192.23.80.15: icmp_seq=3 ttl=234 time=242.034 ms
Og fra Enitel:
1480 bytes from 192.23.80.15: icmp_seq=0 ttl=240 time=259.965 ms
1480 bytes from 192.23.80.15: icmp_seq=1 ttl=240 time=259.811 ms
1480 bytes from 192.23.80.15: icmp_seq=2 ttl=240 time=259.790 ms
1480 bytes from 192.23.80.15: icmp_seq=3 ttl=240 time=251.309 ms
| Pinging www.verestar.com [63.103.134.110] with 1500 bytes of data:
|
| Reply from 63.103.134.110: bytes=1500 time=275ms TTL=108
| Reply from 63.103.134.110: bytes=1500 time=687ms TTL=107
| Reply from 63.103.134.110: bytes=1500 time=631ms TTL=107
| Reply from 63.103.134.110: bytes=1500 time=645ms TTL=108
Fra UNINETT:
1480 bytes from 63.103.134.110: icmp_seq=1 ttl=113 time=125.689 ms
1480 bytes from 63.103.134.110: icmp_seq=2 ttl=113 time=126.074 ms
1480 bytes from 63.103.134.110: icmp_seq=3 ttl=113 time=125.669 ms
1480 bytes from 63.103.134.110: icmp_seq=4 ttl=113 time=124.928 ms
Og fra Enitel:
1480 bytes from 63.103.134.110: icmp_seq=0 ttl=112 time=124.099 ms
1480 bytes from 63.103.134.110: icmp_seq=1 ttl=112 time=122.106 ms
1480 bytes from 63.103.134.110: icmp_seq=2 ttl=112 time=123.317 ms
1480 bytes from 63.103.134.110: icmp_seq=3 ttl=112 time=122.348 ms
| Satelitt kommunikasjon utgjør 7% av omsetningen i verdens totale
| telekommunikasjonsmarked. Dette tallet er ganske representativt for
| de tilfeller hvor satelitt er den beste løsningen. Etterhvert som
| bredbåndstjester tar av og 'Broadcast tjenester' smelter sammen med
| 'Internet tjenester' vil denne andelen øke.
Jeg kan muligens være med på det for steder med lite utbygd infrastruktur.
Jeg tviler på om det vil være korrekt for f.eks. Vest-Europa eller USA.
Jarl Grøneng
news:990ear...@verdi.nethelp.no...
> ["Gunnar Liknes"]
>
> Jeg synes det ser ut som du har grunn til å være misfornøyd med ditt
> Chello-abonnement.
Går litt bedre fra Avidi:
Pinging 128.123.3.50 with 32 bytes of data:
Reply from 128.123.3.50: bytes=32 time=180ms TTL=240
Reply from 128.123.3.50: bytes=32 time=174ms TTL=240
Reply from 128.123.3.50: bytes=32 time=199ms TTL=240
Reply from 128.123.3.50: bytes=32 time=190ms TTL=240
Pinging 128.123.3.50 with 1500 bytes of data:
Reply from 128.123.3.50: bytes=1500 time=383ms TTL=240
Reply from 128.123.3.50: bytes=1500 time=356ms TTL=240
Reply from 128.123.3.50: bytes=1500 time=388ms TTL=240
Reply from 128.123.3.50: bytes=1500 time=393ms TTL=240
--
Jarl
Gunnar Liknes
Det kan godt være. Poenget i denne sammenhengen er imidlertid at
det fungerer veldig bra, selv om jeg har høy RTT. Argumentet med
at Internet ikke fungerer over satelitt på grunn av høy forsinkelse
holder derfor ikke.
Gunnar
Gunnar Liknes
> ["Gunnar Liknes"]
>
> | Satelitt kommunikasjon utgjør 7% av omsetningen i verdens totale
> | telekommunikasjonsmarked. Dette tallet er ganske representativt for
> | de tilfeller hvor satelitt er den beste løsningen. Etterhvert som
> | bredbåndstjester tar av og 'Broadcast tjenester' smelter sammen med
> | 'Internet tjenester' vil denne andelen øke.
>
> Jeg kan muligens være med på det for steder med lite utbygd infrastruktur.
> Jeg tviler på om det vil være korrekt for f.eks. Vest-Europa eller USA.
Kanskje Vest Europa, men i USA er nettopp Compaq, Microsoft og
et satelittfirma gått sammen om å etablere en satelittbasert internet
tjeneste. Planen er at Compaq skal levere PCer med satelitt kort
som standard for å gi denne tjenesten en 'flying start'.
I nær fremtid vil man kunne bestille spillefilmer over Internet. Dette
vil være en 'boust' for Internet over parabol da det landbaserte nettet
ikke vil kunne håndtere denne trafikken.
Dagens intenet og IPv4 takler ikke broadcast så veldig bra. En
tjeneste der la oss si 10.000 mennesker skal kunne se en
500 Mbyte film via internett vil ikke fungere.
Det vil imidlertid fungere over satelitt. Derfor er dagens broadcast
industri i full gang med å gå over til IP som protokoll for
satelitt TV. Jeg tror ikke det vil gå mange år før satelitt tunere
blir erstattet med set-top bokser som er integrert TV mottaker og
'Internett mottaker'.
Da vil hybrid løsninger (kombinert satelitt/landnett) være den eneste
naturlige bredbånds løsningen alle steder.
Det er tross alt kun en brøkdel av internet trafikken som er RTT
sensitiv. Ingen bredbåndstjenester er begrenset av høy forsinkelse.
En hybrid løsning der delay-sensitiv trafikk går over et landbasert
nett (som også vil være generell returkanal) og all annen nedlasting
skjer over satelitt vil derfor være en naturlig utvikling.
Gunnar
Gunnar Liknes
> Lars Erik Gullerud <lars...@gullerud.net> wrote:
> >"Gunnar Liknes" <gli...@online.no> wrote in message
> >news:6%rs6.1200$mh4....@news3.oke.nextra.no...
> >> For punkt til punkt forbindelser vil ofte satelittforbindelser være
> >> bedre enn landbaserte løsninger, særlig interkontinentale
> >> forbindelserog lukkede nett. For punkt til multipunkt vil nesten
> >> alltid satelittløsninger være best.
> >
> >Punkt til multipunkt - ja. Enkelte spesielle løsninger - ja. Stort sett alt
> >annet, herunder generell internettilgang - nei. Min kollega Morten Reistad
> >har tidligere skrevet endel om dette bl.a. i denne gruppen, vi har tidligere
> >hatt en satelittbasert løsning i drift en god stund (72Mbit VSAT) og kjenner
> >ganske godt til begrensningene dette medfører.
>
> Og 72mbit er omtrent det man får ut av én transponder med 8qpsk og
> 5/6 FEC; som er omtrent grensen for hva man klarer med skapelig store
> paraboler. For en toveis lik benytter man da begge polarisasjonsplan
> i samme transponder; dvs én full transponder.
En forbindelse basert på 8PSK (det heter ikke 8qpsk) og 5/6 FEC vil
gi en forferdelig dårlig forbindelse.
8PSK ble utviklet for å kunne implementere ATM forbindeser (155Mb)
på 72Mhz transpondere med gateway antenner i begge ender.
8PSK er veldig sensitiv for regndempning da degraderings kurven
(BER vs EbNo) er mye brattere enn fro QPSK. Når man i tillegg
har en såpass dårlig FEC rate som 5/6 vil dette kun fungere med
klar himmel i begge ender, med mindre man har veldig store
regnmarginer. I.o.m. at dere har brukt hele transponderen i
utgangspunktet er eneste muligheten for å øke regnmarginene å
bruke veldig store antenner i hver ende.
Om dere har brukt mindre enn 9,3m (Ku) eller 13m (C) antenner
i begge ender forstår jeg godt at du har fått et dårlig forhold til
Internett over satelitt. I tillegg har jeg forstått utifra resten av tråden
at dere ikke har gjort noe for å eliminere TCP protokollen og
begrensningene denne har med tanke på vindusstørrelse og
'slow start'.
Om man skal impementere en satelitt basert Internet forbindelse bør
man vite hva man gjør.
> >> Prøv å pinge en server i statene med 1500 bytes ping pakker, og
> >> du vil få en RTT på mellon 450 og 700 ms. Med en satelitt-
> >[snip]
> >
> >Sending 20, 1500-byte ICMP Echos to 198.133.219.25, timeout is 2 seconds:
> >!!!!!!!!!!!!!!!!!!!!
> >Success rate is 100 percent (20/20), round-trip min/avg/max = 160/161/180 ms
>
> En enkelt satellittlink fra Norge via geostasjonær bane 34ø; og til
>
> Sloterdijk utenfor Amsterdam ga en rtt på 576 ms. Og pakketapet var
> i lendet 4-8 promille; på GODE dager. Og jevn er den heller ikke,
> grunnet at det originalt er en bitfeilrate på rundt 4 x 10^2 (1
> av 400 bit er feil); som ved feilkorreksjon bedres til 2 x 10^6.
> Erfaringen min er at det heller er 6-8 x 10^5 som er realiteten.
>
> Alt dette er veldig dårlig nytt for TCP.
Dette har da ikke noe med satelitten å gjøre (utenom 576 ms RTT).
Man velger selv hvor høy BER man vil ha. Dette virker også som et
eksempel på at noen i sin iver etter å levere en billigere løsning enn
konkurrenten har redusert kvaliteten på linken til et nivå som er
på grensen av hva som vil fungere i det hele tatt.
At det er dårlig nytt for TCP er ikke noe argument da dere ikke burde
brukt TCP.
> >Hvordan fant du på de tallene dine egentlig? Hadde jeg levert 450ms (jeg vil
> >ikke engang SNAKKE om 700ms) til statene, uansett pakkestørrelse, hadde jeg
> >fått sparken. (Den aktuelle hosten her var forøvrig www.cisco.com, som
> >ligger omtrent midt på treet for vår del, gjennomsnittlig latency til USA
> >fra forskjellige leverandører i Norge varierer fra 120 til 220 ms avhengig
> >av destinasjon i USA og hvilke providere som sitter på siste stykket i USA)
>
> >> forbindelse (mellom deg og serveren du pinger) ville du hatt
> >> en fast RTT på ca 540ms.
>
> 540 er direkte via geostasjonær satellitt på samme lengdegrad som
> deg selv. Dette er sjelden tilfelle i praksis. Telecom-satellitter
> er flytte ut fra de mest populære posisjonene (spesielt 12ø-5v og
> områdene rundt 25-40v og 130-140v veldig opptatt).
Det er fremdeles mye ledig kapasitet på satelitter fra 15E til 15W.
> >Hadde du hatt en fast jordbasert forbindelse mellom deg og serveren du
> >pinger ville du hatt en akkurat like stabil (som regel MER stabil) latency
> >som med en satelittforbindelse. Hva har det med saken å gjøre? Har man en
> >internet-tilgang via satelitt har man typisk forbindelse med en (evt. fler)
> >jordstasjoner på gitte lokasjoner, på samme måte som man kan ha f.eks. en
> >vanlig SDH-basert forbindelse til gitte lokasjoner og aksessere resten av
> >Internet derfra. Jeg ser ikke helt hvor du vil hen med det resonnementet.
>
> Sending med satellitt fra USA er og underlagt egne regler; der man
> må være en egen operatør; som ikke kan eies av noen LEC eller LD
> operatør, eller kabeloperatør. Dette gjelder ikke interne amerikanske
> samband. Derfor er det vanskelig å ta satellittveien til USA direkte
> for tilkobling til Internetttet der.
Det er ikke vanskelig. Dere kan bare ikke eie antenne selv. På bakgrunn
av hva du skriver hvirker det som om dette er et mål for dere, og at
dere for å spare penger i så måte bruker antenner som er for små til formålet.
Da er det uansett en bedre løsning å leie plass på en større antenne som
noen andre driver.
[TCP problemer]
> Dette er helt riktig et stort problem. 'Vanlig' TCP kan ha et effektivt
> vindu på 65536 minus én MTU; 64000 er vanlig brukt, ettersom 1500 er
> vanligste begrensningen i Internettet. Med dette kan man i en RTT;
> som med denne satellittlinken blir rund 650 ms; skrive 64000 bytes;
> eller 43 pakker. Maksimal effektiv hastighet blir da 788 kilobit per
> sesjon. Litt lite for en 72 megabit link.
>
> Med skalerte vinduer i TCP kan man f.eks skalere med 16 (det meste
> jeg har sett i praksis); og da blir det 64000 x 16 = 1024000; eller
> 682 pakker. Imidlertid blir én av hver 250 pakker borte; og man
> må deretter resende en pakke. Maksimal rate blir dermed blir maksimal
> oppnåelig hastighet rundt 4.6 megabit; grunnet støy. Hastigheten vil
> og pendle vilt opp og ned ettersom det er pakker som blir borte.
>
> Akkurat dette kan man oppleve i praksis dersom en satellittlink tar
> over for en jordlink. Hvis en jordlink med en last på f.eks.. 30 megabit
> faller ned og trafikken rerutes over satellitt ser man at trafikken
> detter til godt under det halve; for eksemplet rundt 12 megabit; men
> at det pendler vilt opp og ned fra 8 til 18 megabit over korte
> intervaller på 1-2 sekunder. Min konklusjon er at satellittlinker
> er lite egnet til en vanlig internettmiks med tcp/ip-trafikk.
Som sagt. Dette lar seg enkelt løse vha en protokoll konverter. De
er ikke dyre, og vil eliminere alle TCP problemene.
Gunnar
Steinar Haug
| > Jeg synes det ser ut som du har grunn til å være misfornøyd med ditt
| > Chello-abonnement.
|
| Det kan godt være. Poenget i denne sammenhengen er imidlertid at
| det fungerer veldig bra, selv om jeg har høy RTT. Argumentet med
| at Internet ikke fungerer over satelitt på grunn av høy forsinkelse
| holder derfor ikke.
Jeg tror gjerne at det fungerer bra for *deg* med høy RTT. Jeg har
imidlertid, som flere andre her, vært med på å drifte nett med minst
ett satelitt-hopp, og opplevd signifikante mengder klager fra brukere.
Tilstrekkelig mange til at jeg er *veldig* glad jeg har lagt dette bak
meg, og til at jeg tviler sterkt på hvor representativ din påstand om
"Argumentet med at Internet ikke fungerer over satelitt på grunn av høy
forsinkelse holder derfor ikke" egentlig er.
Lars Erik Gullerud
>
> I nær fremtid vil man kunne bestille spillefilmer over Internet. Dette
> vil være en 'boust' for Internet over parabol da det landbaserte nettet
> ikke vil kunne håndtere denne trafikken.
>
> Dagens intenet og IPv4 takler ikke broadcast så veldig bra. En
> tjeneste der la oss si 10.000 mennesker skal kunne se en
> 500 Mbyte film via internett vil ikke fungere.
>
> Det vil imidlertid fungere over satelitt. Derfor er dagens broadcast
> industri i full gang med å gå over til IP som protokoll for
> satelitt TV. Jeg tror ikke det vil gå mange år før satelitt tunere
> blir erstattet med set-top bokser som er integrert TV mottaker og
> 'Internett mottaker'.
Og for at denne visjonen din skal ha være mulig å gjennomføre basert på IP,
er du nødt til å levere en tjeneste basert på multicast, der hver av disse
set-top boksene lytter til en multicast-stream sendt via satelitt. Ergo
kunne du oppnådd mye av det samme med multicast-baserte tjenester via
bakkenettet. Flere og flere store operatører implementerer nå multicast
fullt ut i sine nett. Jeg tror nok det landbaserte nettet fint vil kunne
håndtere også de nye tjenestene vi nå begynner å se mer og mer av, nemlig
ting som nettopp streaming av lyd & bilde. Båndbreddemarkedet viser kun en
trend, nemlig at prisene blir stadig lavere og lavere. Med det tempoet det
legges fiber i bakken om dagen, til tross for økonomiske nedgangstider i
data- og telekom-industrien, ville jeg neppe investert mye penger i et firma
som hadde som forretningsidé å levere satelittbaserte IP-tjenester i disse
dager...
> Det er tross alt kun en brøkdel av internet trafikken som er RTT
> sensitiv. Ingen bredbåndstjenester er begrenset av høy forsinkelse.
Faktisk er det en høyere og høyere andel av trafikken som er SVÆRT sensitiv
for RTT. Ting som VoIP/IP-telefoni, toveis videokonferanser, interaktive
tjenester, er i høy vekst. "Bredbåndstjenester" som du snakker om går også
mer og mer i retning av "on-demand" tjenester for individuelle brukere,
en-til-mange type sendinger blir sjeldnere og sjeldnere. Far vil sette seg
ned foran TV'en og se på dagsrevyen akkurat når det passer HAM, ikke når
TV-stasjonen tilfeldigvis fant ut at de skulle sende det. Her er det
begrenset å hente på broadcast(multicast)-baserte løsninger. Kun enkelte
"live events" legger stort press på nettet og kan med fordel implementeres
med multicast - og dette skjer i større og større grad.
> En hybrid løsning der delay-sensitiv trafikk går over et landbasert
> nett (som også vil være generell returkanal) og all annen nedlasting
> skjer over satelitt vil derfor være en naturlig utvikling.
No offense intended, men jeg må innrømme at jeg er lettet over at du ikke
jobber med nettplanlegging hos oss... Jeg holder en knapp på at
satelittmarkedet i økende grad vil gi tapt for landbaserte tjenester. Tiden
vil vise hvem som har rett.
/leg
Gunnar Liknes
> ["Gunnar Liknes"]
Jeg har også vært med på å drifte nett med satelitt hopp uten at vi
fikk noen klager på forsinkelsen. Men vår kundegruppe var nok
mindre kresne enn folk flest.
Om du følger med på 'klage og syte gruppen' til Chello, så klager de fleste
på alle bruddene, ikke den høye ping tiden. De som klager på ping tiden
er de som stort sett bruker Internett til spill. Disse trenger imidlertid ikke
stor båndbredde.
Jeg mener derfor hybrid løsninger vil komme mye mer fremover da disse
vil kunne skreddersys til å utnytte mulighetene som ligger både i
satelitt mediet og landbaserte medier.
Om man ser på tjenesten 'TV over Internet' vil man trenge minst 1024kbit/s
for å kunne se en film i 'sann tid' over internet. Om 10.000 brukere skal se
denne vil serveren den ligger på trenge en 10 Gbit/s internetforbindelse
for at det skal fungere. å bygge ut et landbasert nett for å håndtere
disse trafikk mengdene er bare tull.
Samme fimen kunne vært distribuert til så mange abbonenter som helst
på en 1Mb/s satelitt forbindelse.
Det samme gjelder mange bredbåndstjenster. RTT sensitiv trafikk vil
utgjøre veldig liten del av den totale trafikken når bredbåndstjenester
begynner å bli etablert. Det er derfor naturlig at mer og mer av internet
trafikken vil gå over satelitt, også til sluttbruker.
Gunnar
Lars Erik Gullerud
> Jeg mener derfor hybrid løsninger vil komme mye mer fremover da disse
> vil kunne skreddersys til å utnytte mulighetene som ligger både i
> satelitt mediet og landbaserte medier.
>
> Om man ser på tjenesten 'TV over Internet' vil man trenge minst 1024kbit/s
> for å kunne se en film i 'sann tid' over internet. Om 10.000 brukere skal
se
> denne vil serveren den ligger på trenge en 10 Gbit/s internetforbindelse
> for at det skal fungere. å bygge ut et landbasert nett for å håndtere
> disse trafikk mengdene er bare tull.
Et enkelt fiberpar klarer allerede med dagens teknologi å levere 40
DWDM-lambda'er á 10Gbit (STM-64/OC-192), og de fleste større stamnett er
allerede nå basert på minimum 2.5Gbit linker. Om 10.000 brukere skal se
nøyaktig den samme filmen *PÅ SAMME TID* så kan selve serveren nøye seg med
å levere _EN_ enkelt multicast-stream som så distribueres videre ut i nettet
og belastningen blir dermed fordelt ut til distribusjonspunktene hver enkelt
kunde henger på.
> Samme fimen kunne vært distribuert til så mange abbonenter som helst
> på en 1Mb/s satelitt forbindelse.
Forutsatt at alle abbonentene har lyst til å se denne filmen samtidig... hva
skjer med han som vil se den 10 minutter senere? Det er veien markedet
beveger seg i. On-demand.
> Det samme gjelder mange bredbåndstjenster. RTT sensitiv trafikk vil
> utgjøre veldig liten del av den totale trafikken når bredbåndstjenester
> begynner å bli etablert. Det er derfor naturlig at mer og mer av internet
Si meg, jobber du tilfeldigvis innen film/tv-bransjen, da du har slike
oppfatninger av hvilke tjenester internetbruken beveger seg mot? Ut i fra
reell statistikk fra et av Norge større IP-baserte backbone kan jeg nemlig
påpeke at det motsatte faktisk er tilfelle...
/leg
Bjørn Mork
> Om du følger med på 'klage og syte gruppen' til Chello, så klager de fleste
> på alle bruddene, ikke den høye ping tiden. De som klager på ping tiden
> er de som stort sett bruker Internett til spill. Disse trenger imidlertid ikke
> stor båndbredde.
Vel, jeg vet ikke om du var Chello-kunde i 1998 (det var vel fremdeles
Janco den gangen, men...) da linjene deres var levert av Eunet?
Sannsynligvis ikke. Da burde du i så fall husket den massive klagingen
over høy rtt hver gang satellittbackupen tok over utenlandsforbindelsen.
Du synes kanskje ikke 5-600 ms er så ille, men for de aller fleste er
en dobling (i beste fall) av rtt en ganske alvorlig degradering av
forbindelsen.
> Jeg mener derfor hybrid løsninger vil komme mye mer fremover da disse
> vil kunne skreddersys til å utnytte mulighetene som ligger både i
> satelitt mediet og landbaserte medier.
Jeg skjønner ikke helt hvor du vil hen. På en side vil du at IP skal
gå over satellitt, på en annen side vil du at man skal utnytte den
kringkastingsmuligheten som et delt medium tilbyr. Jeg synes nesten du
bør bestemme deg for det ene eller det andre.
> Om man ser på tjenesten 'TV over Internet' vil man trenge minst 1024kbit/s
> for å kunne se en film i 'sann tid' over internet. Om 10.000 brukere skal se
> denne vil serveren den ligger på trenge en 10 Gbit/s internetforbindelse
> for at det skal fungere. å bygge ut et landbasert nett for å håndtere
> disse trafikk mengdene er bare tull.
Dette har jo absolutt ingenting med om nettet er satellittbasert eller
landbasert. Det har kun med hvilke protokoller du bruker. Hvis du
bruker en broadcast-protokoll over satellittlinken kan du jo like
gjerne bruke den samme protokollen over et landbasert nett, ikke sant?
Satellittforbindelser (og radioforbindelser generelt) sliter med en
begrenset båndbredde i et delt medium, støyproblemer og store
forsinkelser. Det vil aldri bli konkurransedyktig annet enn ved svært
spesielle forhold som f.eks. at kabler er eksepsjonelt dyrt eller at
mobilitet er ønskelig. Just my 2 pecos.
Når det gjelder videostrømmene dine skal vi nok klare å få dem
gjennom nettet uten å måtte ha 10 Gbit/s piper overalt. Caching,
stream-splitting og multicast vil redusere båndbreddebehovet
betraktelig.
> Samme fimen kunne vært distribuert til så mange abbonenter som helst
> på en 1Mb/s satelitt forbindelse.
Ikke hvis det var en Internett-forbindelse satelliten ga deg. Da ville
du måtte brukt nøyaktig den samme båndbredden der som i en kablet
backbone.
> Det samme gjelder mange bredbåndstjenster. RTT sensitiv trafikk vil
> utgjøre veldig liten del av den totale trafikken når bredbåndstjenester
> begynner å bli etablert. Det er derfor naturlig at mer og mer av internet
> trafikken vil gå over satelitt, også til sluttbruker.
Neppe.
Bjørn
Gunnar Liknes
> "Gunnar Liknes" wrote
> > I nær fremtid vil man kunne bestille spillefilmer over Internet. Dette
> > vil være en 'boust' for Internet over parabol da det landbaserte nettet
> > ikke vil kunne håndtere denne trafikken.
> >
> > Dagens intenet og IPv4 takler ikke broadcast så veldig bra. En
> > tjeneste der la oss si 10.000 mennesker skal kunne se en
> > 500 Mbyte film via internett vil ikke fungere.
> >
> > Det vil imidlertid fungere over satelitt. Derfor er dagens broadcast
> > industri i full gang med å gå over til IP som protokoll for
> > satelitt TV. Jeg tror ikke det vil gå mange år før satelitt tunere
> > blir erstattet med set-top bokser som er integrert TV mottaker og
> > 'Internett mottaker'.
>
> Og for at denne visjonen din skal ha være mulig å gjennomføre basert på IP,
> er du nødt til å levere en tjeneste basert på multicast, der hver av disse
> set-top boksene lytter til en multicast-stream sendt via satelitt. Ergo
> kunne du oppnådd mye av det samme med multicast-baserte tjenester via
> bakkenettet. Flere og flere store operatører implementerer nå multicast
> fullt ut i sine nett. Jeg tror nok det landbaserte nettet fint vil kunne
> håndtere også de nye tjenestene vi nå begynner å se mer og mer av, nemlig
> ting som nettopp streaming av lyd & bilde. Båndbreddemarkedet viser kun en
> trend, nemlig at prisene blir stadig lavere og lavere. Med det tempoet det
> legges fiber i bakken om dagen, til tross for økonomiske nedgangstider i
> data- og telekom-industrien, ville jeg neppe investert mye penger i et firma
> som hadde som forretningsidé å levere satelittbaserte IP-tjenester i disse
> dager...
Dette er ikke et enten/eller scenario. Alle medier man kan bruke til IP trafikk
har sine fordeler, og alle vil bli brukt i økende grad fremover.
Verdens største satelittoperatør hadde en økning av Internet trafikk over
sine satelitter på 300% i fjor.
Du kan saste pengene dine hvor du vil, men satelittmarkedet er det segmentet
innen telekom som er i sterkest vekst og som i tillegg tjener penger.
Det er spådd at UMTS utbyggingen vil ta knekken på alle teleselskapene
i Europa med unntak av de fem største.
Dette skyldes en urealistisk forventning til dette markedet. De samme urealistiske
forventningene til 'bredbånds' markedet gjør at telekom selskaper og ISPer
nå kappest om å rulle ut mest mulig fiber på kortest mulig tid.
Jeg ville satset mine penger på selskaper som evner å utnytte potiensialene
som ligger i eksisterende infrastuktur,og som gjør det mulig å tilby 'bredbånd'
til flere kunder på kortere tid og for en billigere penge enn det de fleste legger
opp til i dag.
> > Det er tross alt kun en brøkdel av internet trafikken som er RTT
> > sensitiv. Ingen bredbåndstjenester er begrenset av høy forsinkelse.
>
> Faktisk er det en høyere og høyere andel av trafikken som er SVÆRT sensitiv
> for RTT. Ting som VoIP/IP-telefoni, toveis videokonferanser, interaktive
> tjenester, er i høy vekst. "Bredbåndstjenester" som du snakker om går også
> mer og mer i retning av "on-demand" tjenester for individuelle brukere,
> en-til-mange type sendinger blir sjeldnere og sjeldnere. Far vil sette seg
> ned foran TV'en og se på dagsrevyen akkurat når det passer HAM, ikke når
> TV-stasjonen tilfeldigvis fant ut at de skulle sende det. Her er det
> begrenset å hente på broadcast(multicast)-baserte løsninger. Kun enkelte
> "live events" legger stort press på nettet og kan med fordel implementeres
> med multicast - og dette skjer i større og større grad.
Dette kan løses med caching i set-top boksene.
> > En hybrid løsning der delay-sensitiv trafikk går over et landbasert
> > nett (som også vil være generell returkanal) og all annen nedlasting
> > skjer over satelitt vil derfor være en naturlig utvikling.
>
> No offense intended, men jeg må innrømme at jeg er lettet over at du ikke
> jobber med nettplanlegging hos oss... Jeg holder en knapp på at
> satelittmarkedet i økende grad vil gi tapt for landbaserte tjenester. Tiden
> vil vise hvem som har rett.
No offence taken. Kanskje du vil endre mening om noen år:)
Gunnar
PS: Hovedtyngden av Internet trafikk mellom USA og Kina ble lagt over
på en 155 Mbit satelittforbindelse i forgårs grunnet brudd på fiber-kabelen
over stillehavet.
Gunnar Liknes
> "Gunnar Liknes" writes:
> > Jeg mener derfor hybrid løsninger vil komme mye mer fremover da disse
> > vil kunne skreddersys til å utnytte mulighetene som ligger både i
> > satelitt mediet og landbaserte medier.
>
> Jeg skjønner ikke helt hvor du vil hen. På en side vil du at IP skal
> gå over satellitt, på en annen side vil du at man skal utnytte den
> kringkastingsmuligheten som et delt medium tilbyr. Jeg synes nesten du
> bør bestemme deg for det ene eller det andre.
Poenget er nettopp det motsatte. Man kan ikke velge det ene eller det andre.
En kombinasjon vil være den beste løsningen.
> > Om man ser på tjenesten 'TV over Internet' vil man trenge minst 1024kbit/s
> > for å kunne se en film i 'sann tid' over internet. Om 10.000 brukere skal se
> > denne vil serveren den ligger på trenge en 10 Gbit/s internetforbindelse
> > for at det skal fungere. å bygge ut et landbasert nett for å håndtere
> > disse trafikk mengdene er bare tull.
>
> Dette har jo absolutt ingenting med om nettet er satellittbasert eller
> landbasert. Det har kun med hvilke protokoller du bruker. Hvis du
> bruker en broadcast-protokoll over satellittlinken kan du jo like
> gjerne bruke den samme protokollen over et landbasert nett, ikke sant?
Nei. Satelitt er av natur et multicast (broadcast) medium. Landbaserte
nett er det ikke.
> Satellittforbindelser (og radioforbindelser generelt) sliter med en
> begrenset båndbredde i et delt medium, støyproblemer og store
> forsinkelser. Det vil aldri bli konkurransedyktig annet enn ved svært
> spesielle forhold som f.eks. at kabler er eksepsjonelt dyrt eller at
> mobilitet er ønskelig. Just my 2 pecos.
Mye av dette er tilfelle for rene satelitt løsninger.
> Når det gjelder videostrømmene dine skal vi nok klare å få dem
> gjennom nettet uten å måtte ha 10 Gbit/s piper overalt. Caching,
> stream-splitting og multicast vil redusere båndbreddebehovet
> betraktelig.
Caching vil helt riktig redusere båndbreddebehovet. Om du har
100 cache servere stående rundt i Norge vil den rimeligste
måten å oppdatere disse på være over satelitt.
Om du har noen tusen stående rundt om i Europa vil du ha enda
mer å hente på å benytte deg av en satelitt løsning for å oppdatere
cache serverene.
> > Samme fimen kunne vært distribuert til så mange abbonenter som helst
> > på en 1Mb/s satelitt forbindelse.
>
> Ikke hvis det var en Internett-forbindelse satelliten ga deg. Da ville
> du måtte brukt nøyaktig den samme båndbredden der som i en kablet
> backbone.
Er det bare i et landbasert nett du er tilhenger av caching?
Gunnar
Bjørn Mork
> Verdens største satelittoperatør hadde en økning av Internet trafikk over
> sine satelitter på 300% i fjor.
Siden du tydeligvis sitter på statistikken kunne det være interessant
å vite hvor stor andel av Internett-trafikken som går over
satellitt. Forsvinnende lite vil jeg tro.
> Du kan saste pengene dine hvor du vil, men satelittmarkedet er det segmentet
> innen telekom som er i sterkest vekst og som i tillegg tjener penger.
Hæ? Nå vil jeg gjerne vite hvilken klode vi snakker om. Hva kostet for
eksempel Iridium? Hvor mye inntekter har det generert? Det finnes et
stort marked for satellittkringkasting, men det kan man på sikt regne
med forsvinner i konvergensdragsuget.
> Det er spådd at UMTS utbyggingen vil ta knekken på alle teleselskapene
> i Europa med unntak av de fem største.
>
> Dette skyldes en urealistisk forventning til dette markedet.
Der er vi ihvertfall enige om noe.
> > "Bredbåndstjenester" som du snakker om går også
> > mer og mer i retning av "on-demand" tjenester for individuelle brukere,
> > en-til-mange type sendinger blir sjeldnere og sjeldnere. Far vil sette seg
> > ned foran TV'en og se på dagsrevyen akkurat når det passer HAM, ikke når
> > TV-stasjonen tilfeldigvis fant ut at de skulle sende det. Her er det
> > begrenset å hente på broadcast(multicast)-baserte løsninger. Kun enkelte
> > "live events" legger stort press på nettet og kan med fordel implementeres
> > med multicast - og dette skjer i større og større grad.
>
> Dette kan løses med caching i set-top boksene.
Right. Hva skulle den cache? Alle de titusen livekanalene du har
tilgjengelig fra hele verden eller måtte du stille den inn på "opptak"
av en bestemt kanal? Valget er mellom å kunne lagre 4 TB per time
eller å knapt nok konkurrere med analog teknologi fra 1980.
Bjørn
Bjørn Mork
> "Bjørn Mork" wrote
> > "Gunnar Liknes" writes:
>
> > > Jeg mener derfor hybrid løsninger vil komme mye mer fremover da disse
> > > vil kunne skreddersys til å utnytte mulighetene som ligger både i
> > > satelitt mediet og landbaserte medier.
> >
> > Jeg skjønner ikke helt hvor du vil hen. På en side vil du at IP skal
> > gå over satellitt, på en annen side vil du at man skal utnytte den
> > kringkastingsmuligheten som et delt medium tilbyr. Jeg synes nesten du
> > bør bestemme deg for det ene eller det andre.
>
> Poenget er nettopp det motsatte. Man kan ikke velge det ene eller det andre.
> En kombinasjon vil være den beste løsningen.
Det er en vill fantasi.
> > Dette har jo absolutt ingenting med om nettet er satellittbasert eller
> > landbasert. Det har kun med hvilke protokoller du bruker. Hvis du
> > bruker en broadcast-protokoll over satellittlinken kan du jo like
> > gjerne bruke den samme protokollen over et landbasert nett, ikke sant?
>
> Nei. Satelitt er av natur et multicast (broadcast) medium. Landbaserte
> nett er det ikke.
Jeg synes du bør kikke litt på tradisjonelle kabel-TV-nett. Tro meg,
de beytter ikke 50000 * 500 MHz båndbredde for å distribuere 500 MHz
med TV og radio til 50000 kunder.
Hvis du kan sende noe som broadcast eller multicast over satellitt kan
du også gjøre det over kabel.
> Caching vil helt riktig redusere båndbreddebehovet. Om du har
> 100 cache servere stående rundt i Norge vil den rimeligste
> måten å oppdatere disse på være over satelitt.
Nei. Det vil det defintivt ikke være. Preloading av cacher vil
riktignok være en av applikasjonene der rtt ikke spiller noen rolle,
men 100 satellittmottakere spredt utover landet er forhåpentligvis
ikke noe en ISP vil finne på å prøve på. Vanvittig opplegg.
Det vil heller neppe være aktuelt å preloade all data man ønsker å
tilby, og da er rtt et spørsmål igjen.
> Om du har noen tusen stående rundt om i Europa vil du ha enda
> mer å hente på å benytte deg av en satelitt løsning for å oppdatere
> cache serverene.
Hadde jeg hatt det, tror jeg _ikke_ jeg ville sovet godt.
> > > Samme fimen kunne vært distribuert til så mange abbonenter som helst
> > > på en 1Mb/s satelitt forbindelse.
> >
> > Ikke hvis det var en Internett-forbindelse satelliten ga deg. Da ville
> > du måtte brukt nøyaktig den samme båndbredden der som i en kablet
> > backbone.
>
> Er det bare i et landbasert nett du er tilhenger av caching?
Nei, slett ikke. Det vil f.eks. kunne hjelpe betraktelig på latency
ifm satellittlinker. Men poenget her var at hvis du klarer deg med
1Mb/s over satellittlinken så gjør du det på en kabel også.
Bjørn
Lars Erik Gullerud
> Dette er ikke et enten/eller scenario. Alle medier man kan bruke til IP
trafikk
> har sine fordeler, og alle vil bli brukt i økende grad fremover.
Absolutt. Det vil sikkert bli mer bruk av satelitt enn i dag, til områder
der ikke annet er tilgjengelig. Det du derimot har hevdet hittil er at
satelitt vil ta over for kabel som distribusjonsmedie også i, skal vi kalle
det "industrialiserte", deler av verden, da bakkenettet ikke vil ha nok
kapasitet. Og DET er riv ruskende galt. Alle medier VIL nok øke, men jeg
tror du vil se at økningen er LANGT lavere for satelittbasert IP enn andre
medier - så trafikkandelen blir forsvinnende liten, spesiellt i "vår" del av
verden.
> Dette skyldes en urealistisk forventning til dette markedet. De samme
urealistiske
> forventningene til 'bredbånds' markedet gjør at telekom selskaper og ISPer
> nå kappest om å rulle ut mest mulig fiber på kortest mulig tid.
>
> Jeg ville satset mine penger på selskaper som evner å utnytte
potiensialene
> som ligger i eksisterende infrastuktur,og som gjør det mulig å tilby
'bredbånd'
Ah. Men nettopp det at alle "kappes" om å rulle ut mest mulig fiber på
kortest mulig tid gjør nettopp at denne infrastrukturen nå FINNES svært
mange steder, og til en svært rimelig penge. Så hvorfor skal man da bruke
satelitt når man kan få fiber for en slikk og ingenting?
> > Faktisk er det en høyere og høyere andel av trafikken som er SVÆRT
sensitiv
> > for RTT. Ting som VoIP/IP-telefoni, toveis videokonferanser, interaktive
> > tjenester, er i høy vekst. "Bredbåndstjenester" som du snakker om går
også
> > mer og mer i retning av "on-demand" tjenester for individuelle brukere,
> > en-til-mange type sendinger blir sjeldnere og sjeldnere. Far vil sette
seg
> > ned foran TV'en og se på dagsrevyen akkurat når det passer HAM, ikke når
> > TV-stasjonen tilfeldigvis fant ut at de skulle sende det. Her er det
> > begrenset å hente på broadcast(multicast)-baserte løsninger. Kun enkelte
> > "live events" legger stort press på nettet og kan med fordel
implementeres
> > med multicast - og dette skjer i større og større grad.
>
> Dette kan løses med caching i set-top boksene.
Tull. Hvordan i huleste skal denne set-top boksen vite nøyaktig hva far har
lyst til å se på? Hvilken av kanalenes "dagsrevy" har far lyst til å se? Hva
om han ikke gidder, og vil se Baywatch istedet? Hvor mange peta, nei,
EXAbyte med data har du tenkt å cache???
> PS: Hovedtyngden av Internet trafikk mellom USA og Kina ble lagt over
> på en 155 Mbit satelittforbindelse i forgårs grunnet brudd på
fiber-kabelen
> over stillehavet.
Du ligger litt etter. Dette skjedde 9.februar og er fortsatt ikke utbedret.
Les:
http://www.cnn.com/2001/TECH/internet/02/09/asia.cable/index.html
/leg
Lars Erik Gullerud
> > > Om man ser på tjenesten 'TV over Internet' vil man trenge minst
1024kbit/s
> > > for å kunne se en film i 'sann tid' over internet. Om 10.000 brukere
skal se
> > > denne vil serveren den ligger på trenge en 10 Gbit/s
internetforbindelse
> > > for at det skal fungere. å bygge ut et landbasert nett for å håndtere
> > > disse trafikk mengdene er bare tull.
> >
> > Dette har jo absolutt ingenting med om nettet er satellittbasert eller
> > landbasert. Det har kun med hvilke protokoller du bruker. Hvis du
> > bruker en broadcast-protokoll over satellittlinken kan du jo like
> > gjerne bruke den samme protokollen over et landbasert nett, ikke sant?
>
> Nei. Satelitt er av natur et multicast (broadcast) medium. Landbaserte
> nett er det ikke.
IPv4 er av natur punkt-til-punkt basert (unicast), enten det går via
satelitt eller kabel i en grøft. Les denne setningen her og les den nøye:
- Du får ikke levert en datastrøm til multiple abbonenter simultant ved bruk
av unicast IPv4 -
...for da kreves det bruk av multicast (hint: området 224.0.0.0/4 ser
kanskje kjent ut?), og det kunne du likegjerne gjort via kabel og fått samme
løsning, UTEN å bruke 10Gbit/sec, som jeg allerede har påpekt.
Jeg tror ikke engang jeg gidder å komme med ytterligere kommentarer, for jeg
VET at tiden vil vise at du tar feil ang. utbredelsen av satelittbasert
internet, og jeg håper du husker denne tråden når det skjer. :)
/leg
Morten Reistad
Gunnar Liknes <gli...@online.no> wrote:
>"Morten Reistad" wrote
>> Lars Erik Gullerud <lars...@gullerud.net> wrote:
>> >"Gunnar Liknes" <gli...@online.no> wrote in message
>> >news:6%rs6.1200$mh4....@news3.oke.nextra.no...
>
>En forbindelse basert på 8PSK (det heter ikke 8qpsk) og 5/6 FEC vil
>gi en forferdelig dårlig forbindelse.
>
>8PSK ble utviklet for å kunne implementere ATM forbindeser (155Mb)
>på 72Mhz transpondere med gateway antenner i begge ender.
Skal ikke kverulere, men l˜sningen er ikke ren PSK. Og
båndbredden er akkurat det halve av det du beskriver. 72 mbit
over en 36 MHz transponder. 72MHz transpondere har helt andre
priser.
>8PSK er veldig sensitiv for regndempning da degraderings kurven
>(BER vs EbNo) er mye brattere enn fro QPSK. Når man i tillegg
>har en såpass dårlig FEC rate som 5/6 vil dette kun fungere med
>klar himmel i begge ender, med mindre man har veldig store
>regnmarginer. I.o.m. at dere har brukt hele transponderen i
>utgangspunktet er eneste muligheten for å øke regnmarginene å
>bruke veldig store antenner i hver ende.
Antennene er VSAT-max; noen mm under 3.8 meter.
>Om dere har brukt mindre enn 9,3m (Ku) eller 13m (C) antenner
>i begge ender forstår jeg godt at du har fått et dårlig forhold til
>Internett over satelitt. I tillegg har jeg forstått utifra resten av tråden
>at dere ikke har gjort noe for å eliminere TCP protokollen og
>begrensningene denne har med tanke på vindusstørrelse og
>'slow start'.
Hva da 'eliminere TCP'?
TCP er en av hovedingrediensene i internettet. Det er en meget
bra implementasjon av en vindusalgoritme. Andre protokoller
løser ikke det fundamentale problemet mht long fat pipe.
Man kan drive med diverse triks med høy hack-verdi; med
vindow-spoofing; SYN/SYNACK spoofing, etc. som gir endel
gevinst; som går direkte på bekostning av transparens,
skalerbarhet etc. Been there, done that, got the t-shirt.
>Om man skal impementere en satelitt basert Internet forbindelse bør
>man vite hva man gjør.
Og denne platen har jeg hørt fra satellittfolk i snart et tiår.
FUD. Masse fine ord; men når ting faktisk skal implementeres er det
en enorm hack-faktor. ALT må fin-tunes for at kostnadsrammene
skal holde.
Det er nemlig ett veldig fundamentalt problem her; og der er
kraftbudsjettet i selve satellitten. Det gjør at man vrir ting
akkurat så langt man kan. Det kryper dermed støy inn. Men bevares;
man er innenfor M.10xx normene for feilbit. Såvidt.
Ellers til FUD utspillet lenger opp:
Vi har vært gjennom bortimot alle moduleringsmetoder som fins.
Den som California Microwave kaller '8QPSK' er den som flytter
mest data.
>> >> Prøv å pinge en server i statene med 1500 bytes ping pakker, og
>> >> du vil få en RTT på mellon 450 og 700 ms. Med en satelitt-
>> >[snip]
>> >
>> >Sending 20, 1500-byte ICMP Echos to 198.133.219.25, timeout is 2 seconds:
>> >!!!!!!!!!!!!!!!!!!!!
>> >Success rate is 100 percent (20/20), round-trip min/avg/max = 160/161/180 ms
>>
>> En enkelt satellittlink fra Norge via geostasjonær bane 34ø; og til
>>
>> Sloterdijk utenfor Amsterdam ga en rtt på 576 ms. Og pakketapet var
>> i lendet 4-8 promille; på GODE dager. Og jevn er den heller ikke,
>> grunnet at det originalt er en bitfeilrate på rundt 4 x 10^2 (1
>> av 400 bit er feil); som ved feilkorreksjon bedres til 2 x 10^6.
>> Erfaringen min er at det heller er 6-8 x 10^5 som er realiteten.
>>
>> Alt dette er veldig dårlig nytt for TCP.
>
>Dette har da ikke noe med satelitten å gjøre (utenom 576 ms RTT).
>Man velger selv hvor høy BER man vil ha. Dette virker også som et
>eksempel på at noen i sin iver etter å levere en billigere løsning enn
>konkurrenten har redusert kvaliteten på linken til et nivå som er
>på grensen av hva som vil fungere i det hele tatt.
>
>At det er dårlig nytt for TCP er ikke noe argument da dere ikke burde
>brukt TCP.
Du sier vi burde brukt mye mere penger og ikke drevet med Internett.
Tror ikke du hadde forblitt ansatt mange ukene gjennom en budsjettprosess
i noen stor norsk ISP.
Det er et utsagn på linje med Erich Honeckers; der han meddelte
at folket ikke hadde regjeringens tillit.
>> >Hvordan fant du på de tallene dine egentlig? Hadde jeg levert 450ms (jeg vil
>> >ikke engang SNAKKE om 700ms) til statene, uansett pakkestørrelse, hadde jeg
>> >fått sparken. (Den aktuelle hosten her var forøvrig www.cisco.com, som
>> >ligger omtrent midt på treet for vår del, gjennomsnittlig latency til USA
>> >fra forskjellige leverandører i Norge varierer fra 120 til 220 ms avhengig
>> >av destinasjon i USA og hvilke providere som sitter på siste stykket i USA)
>>
>> >> forbindelse (mellom deg og serveren du pinger) ville du hatt
>> >> en fast RTT på ca 540ms.
>>
>> 540 er direkte via geostasjonær satellitt på samme lengdegrad som
>> deg selv. Dette er sjelden tilfelle i praksis. Telecom-satellitter
>> er flytte ut fra de mest populære posisjonene (spesielt 12ø-5v og
>> områdene rundt 25-40v og 130-140v veldig opptatt).
>
>Det er fremdeles mye ledig kapasitet på satelitter fra 15E til 15W.
Du nevner ikke prisen. Romsegmentene der er bortimot dobbel pris.
Det er helt riktig endel ledig 10-12W; men det er jo 21-24 grader feil i
forhold til Oslo. Liksom 34E er det.
>> Sending med satellitt fra USA er og underlagt egne regler; der man
>> må være en egen operatør; som ikke kan eies av noen LEC eller LD
>> operatør, eller kabeloperatør. Dette gjelder ikke interne amerikanske
>> samband. Derfor er det vanskelig å ta satellittveien til USA direkte
>> for tilkobling til Internetttet der.
>
>Det er ikke vanskelig. Dere kan bare ikke eie antenne selv. På bakgrunn
>av hva du skriver hvirker det som om dette er et mål for dere, og at
>dere for å spare penger i så måte bruker antenner som er for små til formålet.
>Da er det uansett en bedre løsning å leie plass på en større antenne som
>noen andre driver.
Det er nok mere enn det. Man kan ikke være operatør heller. Og for
at man skal kunne gjøre alle disse racer-hackene man MÅ gjøre for
å tune en satellittforbindelse så den funker så noenlunde med
Internett-trafikk MÅ man ha kontroll over endepunktene.
>[TCP problemer]
>
>> Dette er helt riktig et stort problem. 'Vanlig' TCP kan ha et effektivt
>> vindu på 65536 minus én MTU; 64000 er vanlig brukt, ettersom 1500 er
>> vanligste begrensningen i Internettet. Med dette kan man i en RTT;
>> som med denne satellittlinken blir rund 650 ms; skrive 64000 bytes;
>> eller 43 pakker. Maksimal effektiv hastighet blir da 788 kilobit per
>> sesjon. Litt lite for en 72 megabit link.
>>
>> Med skalerte vinduer i TCP kan man f.eks skalere med 16 (det meste
>> jeg har sett i praksis); og da blir det 64000 x 16 = 1024000; eller
>> 682 pakker. Imidlertid blir én av hver 250 pakker borte; og man
>> må deretter resende en pakke. Maksimal rate blir dermed blir maksimal
>> oppnåelig hastighet rundt 4.6 megabit; grunnet støy. Hastigheten vil
>> og pendle vilt opp og ned ettersom det er pakker som blir borte.
>>
>> Akkurat dette kan man oppleve i praksis dersom en satellittlink tar
>> over for en jordlink. Hvis en jordlink med en last på f.eks.. 30 megabit
>> faller ned og trafikken rerutes over satellitt ser man at trafikken
>> detter til godt under det halve; for eksemplet rundt 12 megabit; men
>> at det pendler vilt opp og ned fra 8 til 18 megabit over korte
>> intervaller på 1-2 sekunder. Min konklusjon er at satellittlinker
>> er lite egnet til en vanlig internettmiks med tcp/ip-trafikk.
>
>Som sagt. Dette lar seg enkelt løse vha en protokoll konverter. De
>er ikke dyre, og vil eliminere alle TCP problemene.
Jeg vil gjerne se dette i drift med ca 1500 nye tcp-flows per
sekund. Det er hva en middels stor norsk ISP har på sin
utlandslink.
Igjen; VI HAR GJORT ALT DETTE OG MERE TIL. Det bedrer problemet.
Men det har klare kostnader i form av andre effekter. Og det
skalerer ikke i det hele tatt.
Bruk lys i smalt glass istedet.
Morten Reistad
Gunnar Liknes <gli...@online.no> wrote:
>"Steinar Haug" wrote
>> ["Gunnar Liknes"]
>
>> | > Jeg synes det ser ut som du har grunn til å være misfornøyd med ditt
>> | > Chello-abonnement.
>> |
>> | Det kan godt være. Poenget i denne sammenhengen er imidlertid at
>> | det fungerer veldig bra, selv om jeg har høy RTT. Argumentet med
>> | at Internet ikke fungerer over satelitt på grunn av høy forsinkelse
>> | holder derfor ikke.
>>
>> Jeg tror gjerne at det fungerer bra for *deg* med høy RTT. Jeg har
>> imidlertid, som flere andre her, vært med på å drifte nett med minst
>> ett satelitt-hopp, og opplevd signifikante mengder klager fra brukere.
>> Tilstrekkelig mange til at jeg er *veldig* glad jeg har lagt dette bak
>> meg, og til at jeg tviler sterkt på hvor representativ din påstand om
>> "Argumentet med at Internet ikke fungerer over satelitt på grunn av høy
>> forsinkelse holder derfor ikke" egentlig er.
Jo, jeg har aldri benektet at internett over satellitt faktisk
virker. Som backup-kapasitet i tilfelle katastrofale linjebrudd
har jeg driftet et slikt system i nesten 6 år. Noen ganger var det
og i bruk til primære linjer; da utlandslinjer var 8 mnd etter
garantert bestillingsdato i levering. Men ikke mer om det, vi
har et rettsforlik om at vi ikke skal nevne leverandøren.
>Jeg har også vært med på å drifte nett med satelitt hopp uten at vi
>fikk noen klager på forsinkelsen. Men vår kundegruppe var nok
>mindre kresne enn folk flest.
En klage fra en kunde er en god ting, det betyr at de bryr seg,
og har en viss grad av tillit til at du makter å fikse problemet.
Ellers stemmer de bare med føttene, og velger en annen leverandør.
At man benytter satellitt til krisereserve aksepteres såvidt av
den kundegruppen jeg kjenner. Det betyr at de blir utsatt for den
noen timer hvert år.
En satellittforbindelse merkes nemlig tydelig. Ting går Treeegt.
Web-browsing lugger. Proxy-maskiner sliter plutselig tungt.
Men det virker jo fortsatt på et vis. Det er bedre enn et
linjebrudd. Forstyrrelsen er imidlertid stor nok til at det
er grunn til å sende en generell driftsmelding til alle kunder.
>Om du følger med på 'klage og syte gruppen' til Chello, så klager de fleste
>på alle bruddene, ikke den høye ping tiden. De som klager på ping tiden
>er de som stort sett bruker Internett til spill. Disse trenger imidlertid ikke
>stor båndbredde.
Jeg blander meg av prinsipp ikke inn i klagediskusjoner som angår
konkurrenter. Er og blir inhabil i saken. Jeg begrenser meg til
å korrigere direkte faktafeil.
Jeg finner imidlertid et generelt intrykk av at kommersielle tilbud
er 'for lite, for sent, for langsomt' i denne nyhetsgruppen.
>Jeg mener derfor hybrid løsninger vil komme mye mer fremover da disse
>vil kunne skreddersys til å utnytte mulighetene som ligger både i
>satelitt mediet og landbaserte medier.
>
>Om man ser på tjenesten 'TV over Internet' vil man trenge minst 1024kbit/s
>for å kunne se en film i 'sann tid' over internet. Om 10.000 brukere skal se
>denne vil serveren den ligger på trenge en 10 Gbit/s internetforbindelse
>for at det skal fungere. å bygge ut et landbasert nett for å håndtere
>disse trafikk mengdene er bare tull.
>Samme fimen kunne vært distribuert til så mange abbonenter som helst
>på en 1Mb/s satelitt forbindelse.
Her blander du sammen multicast og fysisk transport. Er ingenting
iveien for at et IP-nett kan benyttes til multicast selv uten disse
egenskapene i fysiske media. Faktisk er det en meget stor teknisk
utfordring å sette opp et IP-nett over satellitt som faktisk også
støtter multicast på IP-nivå. Vi vet, for dette har vi driftet i
5 år allerede. (hvis noen av dere har et news-innlegg fra perioden
mars 1995-august 2000 som har path ..!mcsun!nuug!.. eller
...!News.EU.net!Norway.EU.net!.. er det overveiende sannsynlig at
dette har passert over et slikt nett.)
Satellittforbindelsen i et slikt multicast-nett er mer i veien
enn den er til nytte.
Minner ellers om at min arbeidsgiver i disse dager setter i
drift et europeisk nett som faktisk har kapasiteter på flere titalls
gigabit; og at vi i år ruller ut et IP-nett med multiple 2.4G
linker; for senere oppgradering til 10G; og kan allerede idag ta
ordrer på 2.4G forbindelser.
>Det samme gjelder mange bredbåndstjenster. RTT sensitiv trafikk vil
>utgjøre veldig liten del av den totale trafikken når bredbåndstjenester
>begynner å bli etablert. Det er derfor naturlig at mer og mer av internet
>trafikken vil gå over satelitt, også til sluttbruker.
tror ikke det, jeg.
Kan du kanhende beskrive litt konkret hva slags løsning, hastighet
og oppetid du tilbyr over satellitt; med det utsagnet bør du slå andres
tall med god margin.
>Gunnar
>
>
Gunnar Liknes
> Gunnar Liknes <gli...@online.no> wrote:
> >Om dere har brukt mindre enn 9,3m (Ku) eller 13m (C) antenner
> >i begge ender forstår jeg godt at du har fått et dårlig forhold til
> >Internett over satelitt. I tillegg har jeg forstått utifra resten av tråden
> >at dere ikke har gjort noe for å eliminere TCP protokollen og
> >begrensningene denne har med tanke på vindusstørrelse og
> >'slow start'.
>
> Hva da 'eliminere TCP'?
>
> TCP er en av hovedingrediensene i internettet. Det er en meget
> bra implementasjon av en vindusalgoritme. Andre protokoller
> løser ikke det fundamentale problemet mht long fat pipe.
> Man kan drive med diverse triks med høy hack-verdi; med
> vindow-spoofing; SYN/SYNACK spoofing, etc. som gir endel
> gevinst; som går direkte på bekostning av transparens,
> skalerbarhet etc. Been there, done that, got the t-shirt.
Problemet med TCP og høy RTT er som du vet begrensninger
av throughput pga vindusstørrelsen og slow start.
Derfor bør man benytte en protokoll konverter om man skal
implementere en større Internet forbindelse over satelitt.
Ihht en test NASA har gjennomført på en OC-3 (156MBit)
viser at dette er en løsning som virker meget bra og som
skalerer utmerket.
Om dere ikke har fått det til, så har dere kanskje et dårlig design?
> >Om man skal impementere en satelitt basert Internet forbindelse bør
> >man vite hva man gjør.
>
> Og denne platen har jeg hørt fra satellittfolk i snart et tiår.
> FUD. Masse fine ord; men når ting faktisk skal implementeres er det
> en enorm hack-faktor. ALT må fin-tunes for at kostnadsrammene
> skal holde.
Det er derfor man må vite hva man gjør:) Det er faktisk ikke så veldig
vanskelig lenger.
> Det er nemlig ett veldig fundamentalt problem her; og der er
> kraftbudsjettet i selve satellitten. Det gjør at man vrir ting
> akkurat så langt man kan. Det kryper dermed støy inn. Men bevares;
> man er innenfor M.10xx normene for feilbit. Såvidt.
Har du problemer med for lite effekt, har du brukt for små antenner.
> Ellers til FUD utspillet lenger opp:
>
> Vi har vært gjennom bortimot alle moduleringsmetoder som fins.
> Den som California Microwave kaller '8QPSK' er den som flytter
> mest data.
/flisespikking
'Q' i QPSK står for quad som betyr 4. QPSAK har derfor 4 faseskift.
8PSK har 8 faseskift. 8QPSK gir ingen mening og det er ikke noe som
heter det. Men om C.M. bruker denne betegnelsen, så er det jo ikke
din feil.
/ end flisespikking.
16QAM vil flytte mere data enn 8PSK.
> Du sier vi burde brukt mye mere penger og ikke drevet med Internett.
> Tror ikke du hadde forblitt ansatt mange ukene gjennom en budsjettprosess
> i noen stor norsk ISP.
Jeg sier dere burde insatllert en protokoll konverter for å eliminere TCP
problemene.
Jeg sier også at det ville vært bedre å bruke like mye penger på en
45MBit forbindelse som virket enn å sløse bort de samme pengene
på en 72Mbit forbindelse som etter dine utsagn ikke virker.
Alternativt burde dere brukt noe mer penger på en større antenne.
Det er en liten kost i forhold til de løpende utgiftene til en 72mbit
forbindelse som ikke virker.
Gunnar
Gunnar Liknes
> "Gunnar Liknes" wrote in message
> news:9JTs6.1768$mh4....@news3.oke.nextra.no...
> > Nei. Satelitt er av natur et multicast (broadcast) medium. Landbaserte
> > nett er det ikke.
>
> IPv4 er av natur punkt-til-punkt basert (unicast), enten det går via
> satelitt eller kabel i en grøft. Les denne setningen her og les den nøye:
>
> - Du får ikke levert en datastrøm til multiple abbonenter simultant ved bruk
> av unicast IPv4 -
>
> ...for da kreves det bruk av multicast (hint: området 224.0.0.0/4 ser
> kanskje kjent ut?), og det kunne du likegjerne gjort via kabel og fått samme
> løsning, UTEN å bruke 10Gbit/sec, som jeg allerede har påpekt.
> Jeg tror ikke engang jeg gidder å komme med ytterligere kommentarer, for jeg
> VET at tiden vil vise at du tar feil ang. utbredelsen av satelittbasert
> internet, og jeg håper du husker denne tråden når det skjer. :)
Jeg skal ramme den inn:)
Gunnar
Steinar Haug
| > TCP er en av hovedingrediensene i internettet. Det er en meget
| > bra implementasjon av en vindusalgoritme. Andre protokoller
| > løser ikke det fundamentale problemet mht long fat pipe.
| > Man kan drive med diverse triks med høy hack-verdi; med
| > vindow-spoofing; SYN/SYNACK spoofing, etc. som gir endel
| > gevinst; som går direkte på bekostning av transparens,
| > skalerbarhet etc. Been there, done that, got the t-shirt.
|
| Problemet med TCP og høy RTT er som du vet begrensninger
| av throughput pga vindusstørrelsen og slow start.
|
| Derfor bør man benytte en protokoll konverter om man skal
| implementere en større Internet forbindelse over satelitt.
|
| Ihht en test NASA har gjennomført på en OC-3 (156MBit)
| viser at dette er en løsning som virker meget bra og som
| skalerer utmerket.
Som det har blitt påpekt - TCP er en av de viktigste komponentene i
Internettet. Det har blitt forsket på ulike typer forbedringer av TCP
i mange år - men de mest fundamentale forbedringene av TCP (slow start,
window probing, RTT estimering) er etterhvert en del år gamle. Utviklingen
stopper ikke der - slike ting som f.eks. SACK og ECN kommer for fullt.
Men det er ikke så ofte man får noe gratis, og det er antagelig ikke
tilfelle her heller. Hvis den omtalte protokoll-konverteren reelt sett
løste alle problemer relatert til høy RTT, vil jeg tro den var interessant
på mange andre områder enn bare satellittkommunikasjon. At den ikke er
tatt i bruk på mange andre områder der TCP brukes, gjør det naturlig å
anta det faktisk finnes noen sideeffekter.
| > Du sier vi burde brukt mye mere penger og ikke drevet med Internett.
| > Tror ikke du hadde forblitt ansatt mange ukene gjennom en budsjettprosess
| > i noen stor norsk ISP.
|
| Jeg sier dere burde insatllert en protokoll konverter for å eliminere TCP
| problemene.
Det kan virke som du tror en protokollkonverter løser alle problemer. Jeg
synes det høres ut som du ikke skjønner eller ikke *vil* skjønne det Morten
Reistad sier...
Gunnar Liknes
Protokollkonvertere er i bruk på andre områder også, men den spesielt
innen satcom de er populære, da det var dette de ble utviklet for.
Eksempler på selskaper som bruker èn av de tilgjengelige produktene:
ATC Teleports
AT&T Global Network Services
Belgacom
Boeing
Canada Public Works and Government Services
Caprock Communications
Centre National d'Etudes Spatiales (CNES)
Chevron
Comsat
Earthwatch
Echostar
Eutelsat
France Telecom
German Military
Gilat Communications
GMD
Heartland Information Services
Hughes Electronics
Informatique & Telematique
Intellicom
Intelsat
Kingston TLI
L3 Communications
Litton TASC
Local Communications Network
Loral Skynet
Lyman Brothers
Mitre
NASA
NASDA
Nortel Dasa
NTT Communications
OnSat Network Communications
Radyne ComStream
Riyadh Web
Royal Air Force
Satworks A/S
Sony
Tachyon
Teleglobe
Telesat
Total Fina Elf
TRW
US Air Force
US Army
US Navy
US State Deparment
Video Networks
Wam!Net
Warsun Communications
> | > Du sier vi burde brukt mye mere penger og ikke drevet med Internett.
> | > Tror ikke du hadde forblitt ansatt mange ukene gjennom en budsjettprosess
> | > i noen stor norsk ISP.
> |
> | Jeg sier dere burde insatllert en protokoll konverter for å eliminere TCP
> | problemene.
>
> Det kan virke som du tror en protokollkonverter løser alle problemer. Jeg
> synes det høres ut som du ikke skjønner eller ikke *vil* skjønne det Morten
> Reistad sier...
En protokollkonverter vil løse alle problemene med TCP. Derfor bruker de fleste
satelittoperatører disse i dag.
Gunnar