---

Hej gruppe.

Nogen der har et indtryk af sikkerheden overordnet set i streaming
protokoller? Vil det f.eks. uden videre være muligt at kapre sådan en
"forbindelse" (pakkestrøm) ved at lukke af for afsenderens pakker, og f.eks.
indsætte sine egne nyheder i stedet for CNNs...?! Eller anvendes en eller
anden form for authentifikation, f.eks. kryptering?

TIA, Morton

---

Morton Christiansen wrote:
> Vil det f.eks. uden videre være muligt at kapre sådan en
> "forbindelse" (pakkestrøm) ved at lukke af for afsenderens pakker, og
> f.eks. indsætte sine egne nyheder i stedet for CNNs...?! Eller anvendes en
> eller anden form for authentifikation, f.eks. kryptering?

Du kan som udgangspunkt ikke gøre det, medmindre den protokol, der bygger
ovenpå UDP er dårlig. Jeg vil dog gerne tro, at en del UDP-baserede
protokoller er dårlige, og disse vil så kunne hackes afhængigt af, hvor
dårlige de er lavet. Nogle behøver nok ikke engang at man afbryder
forbindelsen til den oprindelige afsender - man skal bare sende sine pakker
timet korrekt.

Kryptering vil nok sjældent bruges på UDP, da kryptering tilføjer latency,
og årsagen til at man bruger UDP er ofte fordi man vil nedbringe latency.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>Kryptering vil nok sjældent bruges på UDP, da kryptering tilføjer latency,
>og årsagen til at man bruger UDP er ofte fordi man vil nedbringe latency.

Det var måske rigtigt for nogle år siden. En almindelig pc har i
dag intet problem med at (de)kryptere i realtid. Den ekstra tid
vil være minimal i forhold til de problemer med pakketab og lang
transmissionstid, man kan komme ud for.

Igen er det et spørgsmål om hvorvidt det er nødvendigt. Risikoen
for (og følgerne af), at nogen ændrer CNNs nyheder undervejs er
så lille, at de få ekstra Watt strømforbrug til kryptering er en
ekstremt dårlig investering

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Det var måske rigtigt for nogle år siden. En almindelig pc har i
> dag intet problem med at (de)kryptere i realtid.

Øh? Problemet med latency er, at krypterede data bliver forsinket i
transmissionen. Jeg snakker ikke om CPU kraft.

Vi kan her tage lidt almindelige eksempler på pakkestørrelser:

Hvis du sender en 100 byte pakke, så ankommer den hurtigere end en 200 byte
pakke, især når vi snakker modems m.v. 100 bytes tager mindst 23
millisekunder at putte igennem en 33.6kbps forbindelse. En fordobling til
200 bytes øger altså latency med 23 millisekunder. Det lyder måske ikke af
meget, men f.eks. er en meget anvendt pakkestørrelse på spillet Tribes 2 på
400 bytes, og de fleste Counter-Strike spillere kender nok problemet, når
latency er over 100ms...

I øvrigt - hvis man sender en UDP pakke på 100 bytes, og gerne vil have
svar, om den er modtaget, og hvis den ikke er modtaget, så vil man gerne
sende den igen, så skal latency for alle transmissioner frem og tilbage
lægges sammen for at man får den reelle tidsforskel.

Når man bruger UDP, så lægger man ofte en anden protokol ovenpå. Det er ikke
altid, næsten sjældent, at man optimerer protokolstakken helt ned på
UDP-pakke størrelse. Hvis man lægger kryptering på, og ikke lægger den helt
nede i UDP-pakkens niveau, vil det ofte betyde, at en UDP-pakke ikke kan
bruges til noget før den næste UDP-pakke ankommer. Det er det værste
eksempel.

Hvis man lægger krypteringen på hver UDP-pakke, så skal hver UDP-pakke også
dekrypteres hver for sig samt indeholde alle nødvendige oplysninger til
dekryptering. Da vi kan antage, at pakkerne i forvejen er komprimeret
optimalt, vil det øge pakkens størrelse. Og selv om man har en hurtig
processor, så vil hver 1600 CPU clocks i håndteringen af en pakke medføre
en ekstra latency på 1ms for en 1,6GHz processor. Jeg ved ikke, hvor god
performance kryptering har nutildags, men hvis man skal se noget video,
ville 1ms extra latency komme på en 400byte pakke på en 1,6GHz CPU hvis der
blev brugt 4 clock-cycles per byte. Det samme gælder for både modtager og
afsender.

Fra min 1,3GHz Linux maskine har jeg en ping på 14ms til Tiscali's DNS
servere. Det giver en UDP latency på 7ms. Lad os antage, at computeren i
den anden ende har en 1,6GHz processor. Hvis man her vil undgå en 25%
forøgelse af latency på en 400byte UDP pakke, skal der med andre ord bruges
mindre end 4 clock-cycles per byte i det tidsrum, hvor der krypteres. De 4
clock-cycles inkluderer både CPU kraft brugt på kryptering og evt.
fremvisning af video.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>Øh? Problemet med latency er, at krypterede data bliver forsinket i
>transmissionen. Jeg snakker ikke om CPU kraft.

De bliver ikke forsinket mere end ukrypteret data.

>Hvis du sender en 100 byte pakke, så ankommer den hurtigere end en 200 byte
>pakke, især når vi snakker modems m.v. 100 bytes tager mindst 23
>millisekunder at putte igennem en 33.6kbps forbindelse. En fordobling til
>200 bytes øger altså latency med 23 millisekunder.

Kryptering gør ikke nødvendigvis datamængden større. Faktisk gør
den datamængden mindre i en del tilfælde (GPG pakker f.eks. data
samtidig med krypteringen).

>I øvrigt - hvis man sender en UDP pakke på 100 bytes, og gerne vil have
>svar, om den er modtaget, og hvis den ikke er modtaget, så vil man gerne
>sende den igen, så skal latency for alle transmissioner frem og tilbage
>lægges sammen for at man får den reelle tidsforskel.

De fleste streamingprotokoller ønsker ikke at modtage tabte
pakker. Det får slutresultatet til at stoppe. Ønsker man at
styre pakketab, er UDP en seriøst dårlig løsning - hvorfor
opfinde TCP igen?

>Hvis man lægger krypteringen på hver UDP-pakke, så skal hver UDP-pakke også
>dekrypteres hver for sig samt indeholde alle nødvendige oplysninger til
>dekryptering. Da vi kan antage, at pakkerne i forvejen er komprimeret
>optimalt, vil det øge pakkens størrelse.

Hvorfor det? Der er ingen grund til at have headere med i selve
datastrømmen. Den skal bare være en datastrøm med et indeks på,
som er en selvstændig enhed i forhold til krypteringen.

>Og selv om man har en hurtig
>processor, så vil hver 1600 CPU clocks i håndteringen af en pakke medføre
>en ekstra latency på 1ms for en 1,6GHz processor. Jeg ved ikke, hvor god
>performance kryptering har nutildags, men hvis man skal se noget video,

Netværks-latencies måles i hundreder af milisekunder - især hvis
vi snakker dit 33,6 kbps eksempel. Selv en 486'er kan følge med
til dekryptering i realtid af den mængde data.

Din pointe omkring afsenderen er dermed reel nok. Der skal helt
klart hardwareløsninger til, hvis streams skal krypteres enkeltvis
(men hvem siger, de skal det?)

Mvh.
   Klaus.

---

Klaus Ellegaard skrev:

>De fleste streamingprotokoller ønsker ikke at modtage tabte
>pakker. Det får slutresultatet til at stoppe. Ønsker man at
>styre pakketab, er UDP en seriøst dårlig løsning - hvorfor
>opfinde TCP igen?

Fordi TCP er langsom. Den starter langsomt og skruer op, men
hastigheden går igen på minimum ved en tabt pakke.

UDP kører fuld hammer hele tiden, og hvis man selv bygger
pålideligheden ovenpå, har man en bedre protokol. Jeg gætter på
at det er den metode, kombineret med en buffer, de fleste
programmer bruger til distribueret radio og video.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> writes:

>Fordi TCP er langsom. Den starter langsomt og skruer op, men
>hastigheden går igen på minimum ved en tabt pakke.

Det kommer da an på hvordan du beder din stak om at opføre sig.

>UDP kører fuld hammer hele tiden, og hvis man selv bygger
>pålideligheden ovenpå, har man en bedre protokol. Jeg gætter på
>at det er den metode, kombineret med en buffer, de fleste
>programmer bruger til distribueret radio og video.

Hvordan vil du bygge en pålidelighed, der ikke kører efter det
ekstremt sløve ACK-efter-hver-pakke - men alligevel er hurtigere
end TCP med passende window-settings?

Mvh.
   Klaus.

---

Klaus Ellegaard skrev:

>>Fordi TCP er langsom. Den starter langsomt og skruer op, men
>>hastigheden går igen på minimum ved en tabt pakke.

>Det kommer da an på hvordan du beder din stak om at opføre sig.

Det har vi ikke lært at man kan.

>>UDP kører fuld hammer hele tiden, og hvis man selv bygger
>>pålideligheden ovenpå, har man en bedre protokol. Jeg gætter på
>>at det er den metode, kombineret med en buffer, de fleste
>>programmer bruger til distribueret radio og video.

>Hvordan vil du bygge en pålidelighed, der ikke kører efter det
>ekstremt sløve ACK-efter-hver-pakke - men alligevel er hurtigere
>end TCP med passende window-settings?

ACK(100) er samtidig ACK for 0-99 (skal jeg *virkelig* slå op i
min netværksbog og beskrive de forskellige metoder?). Der er jo
en buffer, så det gør ikke noget at man skal gribe lidt langt
tilbage hvis der mangler en pakke.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen <nospamfor@lundhansen.dk> writes:

>ACK(100) er samtidig ACK for 0-99 (skal jeg *virkelig* slå op i
>min netværksbog og beskrive de forskellige metoder?). Der er jo
>en buffer, så det gør ikke noget at man skal gribe lidt langt
>tilbage hvis der mangler en pakke.

Rigtigt, men igen afhængig af den latency og den bufferstørrelse,
du kan acceptere, risikerer du, at streamen går i stå. Da vil det
ofte være bedre for UDP-protokoller at smide den ene pakke ud -
og blot fortsætte uden den.

Hvis du f.eks. mister pakker svarende til 20 sekunders video, er
det betydeligt bedre bare at glemme dem, end at begynde at samle
op.

Afhængig af hvad det er, man streamer, naturligvis. I modsætning
til downloading er streaming jo ikke en garanti for, at du får
hele indholdet ned - og ej heller at du får det ned i en ensartet
kvalitet hele vejen igennem.

Det er snarere dét, der er relevant i forhold til UDP-valget, end
det er pakketabet. TCP opgiver definitivt i nogle sammenhænge,
mens UDP har lettere ved at overleve (fordi der ikke er nogen
egentlig datastrøm i selve protokollaget) og skifte spor undervejs.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> De bliver ikke forsinket mere end ukrypteret data.

Forsinkelse bør måles fra input af ukrypterede data indtil data bliver vist
hos brugeren. I spil er det dermed tidsforsinkelsen mellem at en spiller
trykker på museknappen til at de andre spillere kan se, at han har trykket.
Og her er krypteringsdelen et af de led, som data skal igennem.

> Kryptering gør ikke nødvendigvis datamængden større. Faktisk gør
> den datamængden mindre i en del tilfælde

Ikke hvis data er pakket i forvejen. I øvrigt så er en pakning af data også
noget, der øger latency i alle dele bortset fra selve transmissionsdelen.

> Ønsker man at styre pakketab, er UDP en seriøst dårlig løsning

Nej. UDP's største fordel er hurtig opkobling samt muligheden for mere
intelligent håndtering af pakketab. Hvis du i TCP taber en IP pakke,
gensendes den uanset hvad. Ved UDP kan du på en intelligent måde vælge, om
du vil gensende data, og hvis du gør, hvilke data du egentlig vil gensende.

Hvis du f.eks. vil sende video, og modtageren ikke får en pakke til
opdatering af øverste højre hjørne, så ville det være mest fornuftigt at
sende en up-to-date opdatering af øverste højre hjørne frem for en gammel
opdateringspakke til den skærmregion.

>> Da vi kan antage, at pakkerne i forvejen er komprimeret
>>optimalt, vil det øge pakkens størrelse.
> Hvorfor det? Der er ingen grund til at have headere med i selve
> datastrømmen.
> Den skal bare være en datastrøm med et indeks på,

Det har du ret i. Indekset skal selvflg. så være et byteindeks relativt til
afsenderens datastrøm.

> Netværks-latencies måles i hundreder af milisekunder - især hvis
> vi snakker dit 33,6 kbps eksempel.

Nå - det er nyt for mig. Som sagt har jeg UDP latency (halv ping tid) på
under 10ms ud på internettet, under 60 til USA osv., og jeg sidder på en
ganske almindelig ADSL linie. Fra min webserver har jeg 5ms til webservere
fra andre udbydere. Dengang jeg kørte ISDN kørte jeg også UDP latencies på
under 30. Jeg har aldrig mødt nogen med UDP latency på hundreder af
millisekunder. Det ville jo svare til ping tider på 400ms og opefter... Du
må have en ekstrem dårlig internet opkobling.

Lad os antage, at du har "hundreder af millisekunder" i UDP latency. Så vil
en fuldt cachet hjemmeside med 10 billeder, hentet med http/1.1, tage:

2x200ms=0,4s for DNS opslag
4x200ms=0,8s for at starte hentning af html-delen
10x2x200ms=4s for at starte hentning af billederne

Alt i alt 5,2 sekunder for at vise en fuldt cachet side.

Jeg gad ikke vide, hvor lang tid det ville tage at hente en sådan side, hvis
den ikke ligger i din cache...

> Selv en 486'er kan følge med
> til dekryptering i realtid af den mængde data.

"realtid" er et meget dårligt begreb i denne forbindelse. Det betyder typisk
at "der er cpu kraft nok til at systemet kan håndtere data i den hastighed
de kommer". Det har normalt INTET med latency at gøre - en 486 vil typisk
bare forsinke videosignalet nok til at det virker, dvs. øge latency.

Det er også derfor, at en Athlon kører webserver så mange gange hurtigere
end en 486 - begge kan gøre det i "realtid" og har CPU kraft nok, men
Athlon'en har bare mindre tidsforsinkelse på udførsel af opgaven.

> klart hardwareløsninger til, hvis streams skal krypteres enkeltvis
> (men hvem siger, de skal det?)

Hvad snakker du om?

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>Ikke hvis data er pakket i forvejen. I øvrigt så er en pakning af data også
>noget, der øger latency i alle dele bortset fra selve transmissionsdelen.

Jep. Men hvis du kører med en 33,6 kbps linje, hvad er så den
største flaskehals: pakningen eller linjen? (Nej, der er ikke
noget absolut svar på det, men i de fleste tilfælde vil den
største flaskehals være linjen).

>> Ønsker man at styre pakketab, er UDP en seriøst dårlig løsning

>Hvis du f.eks. vil sende video, og modtageren ikke får en pakke til
>opdatering af øverste højre hjørne, så ville det være mest fornuftigt at
>sende en up-to-date opdatering af øverste højre hjørne frem for en gammel
>opdateringspakke til den skærmregion.

Er der rent faktisk nogen streaming-systemer, der har kapacitet til
den slags?

>> Netværks-latencies måles i hundreder af milisekunder - især hvis
>> vi snakker dit 33,6 kbps eksempel.

>Nå - det er nyt for mig. Som sagt har jeg UDP latency (halv ping tid) på
>under 10ms ud på internettet, under 60 til USA osv., og jeg sidder på en
>ganske almindelig ADSL linie.

Din ADSL-linje kører 33,6 kbps?

1 sekund / 33600 b/s = 0,0000298 s/b
0,0000298 s/b * 8 b/B * 1024 B = 0,244 s = 244 ms

Det tager altså 244 ms at sende 1 KB over en 33,6 kbps forbindelse.
Det er i øvrigt ikke engang 1 KB data - det er 1 KB rå data, hvori
der også skal være plads til protokol-overhead, ekstra PPP-pakker
og whatnot. Det reelle tal ligger nok nærmere 300 ms.

>Du må have en ekstrem dårlig internet opkobling.

På hvilket grundlag kan du udtale dig om det?

>Det er også derfor, at en Athlon kører webserver så mange gange hurtigere
>end en 486 - begge kan gøre det i "realtid" og har CPU kraft nok, men
>Athlon'en har bare mindre tidsforsinkelse på udførsel af opgaven.

Realtid omkring streaming må indikere, at hvis man afspiller en
streamet udgave af en film, der varer 2 timer, så varer det også
2 timer at afspille den. Det er uinteressant hvilken CPU-type,
der er involveret, så længe den bare opfylder minimumskravet.

>> klart hardwareløsninger til, hvis streams skal krypteres enkeltvis
>> (men hvem siger, de skal det?)

>Hvad snakker du om?

Afsenderens CPU-kraft er en endelig størrelse. Streaming trækker
hårdt på CPU-kraften alene - skal den også kryptere, får den et
problem. Hvis vi altså snakker kommerciel streaming og ikke en
én-til-én-løsning.

Nå, skal vi ikke droppe denne diskussion? Den er ikke on-topic
længere.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Jep. Men hvis du kører med en 33,6 kbps linje, hvad er så den
> største flaskehals: pakningen eller linjen?

Det kommer meget an på, hvad du pakker og hvordan du gør det. Hvis du pakker
noget, der ikke kan pakkes, og du dermed øger pakkestørrelsen, så bruger du
mere tid på at overføre det pakkede format. Pakning kan også øge latency,
hvis udpakning ikke kan foretages før en større mængde er hentet end man
ellers ville have hentet for at få fat i den ønskede information. Men det
er da rigtigt, at for komprimerbare data over en vis mængde per pakke er
pakning noget, der kan nedsætte latency på en pakke på en 33.6kbps
forbindelse med moderne PC udstyr.

> Er der rent faktisk nogen streaming-systemer, der har kapacitet til
> den slags?

Jeg er ikke klar over, hvad du mener, men der er en del forskellige
protokoller til f.eks. videooverførsel tilgængelige, og mange af dem kan
finde ud af at tilpasse deres båndbreddeforbrug efter forholdene. Ved brug
af UDP kan jeg ikke se, at det kan ske på anden vis end at de reagerer på
pakketab, dvs. at UDP modtageren fortæller afsenderen om pakketab, og at
afsenderen så reagerer intelligent på dette.

> Din ADSL-linje kører 33,6 kbps?

Nej - 2Mbps/512kbps. Hvorfor spørger du?

> Det tager altså 244 ms at sende 1 KB over en 33,6 kbps forbindelse.
> Det er i øvrigt ikke engang 1 KB data - det er 1 KB rå data, hvori
> der også skal være plads til protokol-overhead, ekstra PPP-pakker
> og whatnot. Det reelle tal ligger nok nærmere 300 ms.

Det reelle tal for hvad? Overførsel af en 1Kbyte pakke? Hvorfor har du
regnet det ud - hvad har det med diskussionen om UDP latency at gøre?

>>Du må have en ekstrem dårlig internet opkobling.
> På hvilket grundlag kan du udtale dig om det?

Fordi du snakker om latency's der er gigantisk meget højere end de fleste
mennesker har på deres internet opkoblinger.

> Realtid omkring streaming må indikere, at hvis man afspiller en
> streamet udgave af en film, der varer 2 timer, så varer det også
> 2 timer at afspille den.

Enig. Men her snakker vi latency, og ikke evnen til at afspille en UDP
stream. Du kan sagtens afspille en UDP stream i realtid med gigantisk
latency. Men hvis man gør det, kunne man ligesågodt bruge TCP, da der så
udelukkende er tale om at få skidtet overført på en eller anden måde.

> Afsenderens CPU-kraft er en endelig størrelse. Streaming trækker
> hårdt på CPU-kraften alene - skal den også kryptere, får den et
> problem. Hvis vi altså snakker kommerciel streaming og ikke en
> én-til-én-løsning.

Jeg har ingen anelse om, hvad du snakker om. Min maskine belastes stort set
ikke CPU-mæssigt af at afspille noget, der er streamet, og jeg kan ikke se
hvad "kommercielt" har med latency at gøre?!?!? Hvad mener du med en
"en-til-en" løsning? Mener du kommunikationsformen? UDP er normalt altid
noget der har en enkelt afsender og en enkelt modtager. De fleste internet
udbydere supporterer ikke multi-cast, såvidt jeg ved.

> Nå, skal vi ikke droppe denne diskussion?

Det er du velkommen til.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>> der også skal være plads til protokol-overhead, ekstra PPP-pakker
>> og whatnot. Det reelle tal ligger nok nærmere 300 ms.

>Det reelle tal for hvad? Overførsel af en 1Kbyte pakke? Hvorfor har du
>regnet det ud - hvad har det med diskussionen om UDP latency at gøre?

Det er relevant for den proces, der hedder serialization. Uden
en grundig forståelse af, hvordan og hvor hurtigt data sendes
via et givent link, er det ret omsonst at diskutere performance
og latency.

>>>Du må have en ekstrem dårlig internet opkobling.
>> På hvilket grundlag kan du udtale dig om det?

>Fordi du snakker om latency's der er gigantisk meget højere end de fleste
>mennesker har på deres internet opkoblinger.

Hvad har min internetopkobling med "de fleste menneskers" at
gøre? Hvad er gennemsnitsbåndbredden da for "de fleste"?

>> Afsenderens CPU-kraft er en endelig størrelse. Streaming trækker
>> hårdt på CPU-kraften alene - skal den også kryptere, får den et
>> problem. Hvis vi altså snakker kommerciel streaming og ikke en
>> én-til-én-løsning.

>Jeg har ingen anelse om, hvad du snakker om. Min maskine belastes stort set
>ikke CPU-mæssigt af at afspille noget, der er streamet, og jeg kan ikke se
>hvad "kommercielt" har med latency at gøre?!?!?

Hvis afsenderen skal streame 20.000 streams på én gang, har det
meget stor betydning, om de enkelte streams skal krypteres eller
ej. Hvis det derimod er en én-til-én-stream (maskinen derhjemme
der streamer en MP3-stream til én anden maskine), er det nærmest
ligegyldigt.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Hvad har min internetopkobling med "de fleste menneskers" at
> gøre? Hvad er gennemsnitsbåndbredden da for "de fleste"?

De fleste har i hvert fald UDP latencies under 100ms. Jeg kender ikke til
nogen dansk internet udbyder, der ville akceptere de latency værdier, du
opgiver.

> Hvis afsenderen skal streame 20.000 streams på én gang, har det
> meget stor betydning, om de enkelte streams skal krypteres eller
> ej.

Ja - men er det ikke en anden diskussion? Det hele startede med UDP
streaming sikkerhed, og mit argument er, at man normalt bruger UDP i stedet
for TCP, hvis man vil nedbringe latency. En af årsagerne er, at man så kan
styre pakketransporten bedre, og at kryptering i et sådan system normalt
ikke giver meget mening og at man ved anvendelse af kryptering ofte
ligesågodt kan bruge TCP. Der er vel ingen, der siger, at dette her ikke
drejer sig om en videokonference mellem to personer?

Men i øvrigt - hvis vi taler masseudsendelse af en prefabrikeret stream, så
er det rimeligt oplagt at bruge TCP. TCP går bedre igennem mange routere,
og en prefabrikeret stream må normalt gerne forsinkes en anelse. Og hvis
man laver individuel pakkestyring, båndbreddestyring og UDP, så stiller man
samtidigt nogle krav til udformningen af den fælles prefabrikerede stream,
der måske gør den mindre komprimeret? Der er på masseudsendelser sjældent
brug for den lave latency, som man har brug for i en videokonference, og på
videokonferencer (og lign.) har man ofte også bedre styr på
netværksopsætningen.

I øvrigt kan jeg oplyse om, at man også kan lave avanceret pakkestreaming på
TCP forbindelser. Det fungerer på den måde, at man lægger en protokol oven
på TCP'en, hvor alle pakker er tidsstemplet. Modtageren melder så tilbage,
hvordan tingene er, og afsenderen forsøger så at pakke mere eller mindre
detaljerede oplysninger til afsendelse. Dette er selvflg. ekstremt følsomt
over for pakketab, idet en enkelt tabt pakke kan give en ekstremt høj
latency på opdateringer, til gengæld virker det gennem NAT routere. Metoden
bruges især til spil, men det er mit indtryk at den også bruges til
adskillige videokonference systemer. Efterhånden har de fleste internet
udbydere ikke pakketab på TCP.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>> Hvad har min internetopkobling med "de fleste menneskers" at
>> gøre? Hvad er gennemsnitsbåndbredden da for "de fleste"?

>De fleste har i hvert fald UDP latencies under 100ms. Jeg kender ikke til
>nogen dansk internet udbyder, der ville akceptere de latency værdier, du
>opgiver.

Det er fysisk umuligt ikke at acceptere den slags tider på lav-
hastigheds-forbindelser. Med ISDN ligger serialization af 1 KB
rå data omkring 128 ms. Det er først, når man kommer op i ADSL-
hastigheder, at de falder til under 30 ms.

>> Hvis afsenderen skal streame 20.000 streams på én gang, har det
>> meget stor betydning, om de enkelte streams skal krypteres eller
>> ej.

>Ja - men er det ikke en anden diskussion? Det hele startede med UDP
>streaming sikkerhed, og mit argument er, at man normalt bruger UDP i stedet
>for TCP, hvis man vil nedbringe latency.

Jeg har stadig ikke set nogen teknisk redegørelse for, at TCP -
hvis man ser bort fra slowstart, som alligevel er irrelevant på
grund af den initielle buffering - er langsommere end UDP.

>En af årsagerne er, at man så kan styre pakketransporten bedre,
>og at kryptering i et sådan system normalt ikke giver meget
>mening og at man ved anvendelse af kryptering ofte ligesågodt
>kan bruge TCP.

Du kan styre pakketransporten selv. Om det er bedre eller ej,
er helt afhængig af applikationens behov for komplette data,
og om du kan opfinde en effektiv protokol.

Hvilke egenskaber gør TCP bedre omkring kryptering? Og hvis
du har et problem med TCPs pakkehåndtering i streaming uden
kryptering, hvorfor bliver det problem så væk MED kryptering?
Hvilke egenskaber ved selve streamingen er ændret?

Husk på at streaming er et koncept, hvor man sikrer, at man
kan afspille den pågældende video uden afbrydelser, selvom
båndbredde og pakketab ændrer sig radikalt undervejs.

>Der er vel ingen, der siger, at dette her ikke
>drejer sig om en videokonference mellem to personer?

Jo, hele tråden handler om ændring af CNNs streamede nyheder.
Mig bekendt leverer CNN ikke nyheder via videokonferencer?

>I øvrigt kan jeg oplyse om, at man også kan lave avanceret pakkestreaming på
>TCP forbindelser.

Hvilket er det, jeg har sagt fra starten. Prøv lige at følge lidt
med i den tråd, du skriver i

>Dette er selvflg. ekstremt følsomt over for pakketab, idet en
>enkelt tabt pakke kan give en ekstremt høj latency på opdateringer,

Nej, ikke hvis du styrer din TCP-stak ordentligt.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Det er fysisk umuligt ikke at acceptere den slags tider på lav-
> hastigheds-forbindelser.

Det kommer an på, hvad du måler.

> Med ISDN ligger serialization af 1 KB
> rå data omkring 128 ms.

Hvis man forsøger at få lav latency, sender man jo ikke 1kbyte pakker, vel?

> Jeg har stadig ikke set nogen teknisk redegørelse for, at TCP -
> hvis man ser bort fra slowstart, som alligevel er irrelevant på
> grund af den initielle buffering - er langsommere end UDP.

Hmmm... der er mange måder at måle hastighed på - hvis du skal overføre en
stor fil bør man for internettets skyld bruge TCP, men når vi snakker
tidsforsinkelse er der mange måder at UDP kan være hurtigere end TCP på.
Jeg vil gerne give et eksempel: I TCP skal de ankomme i samme rækkefølge.
Det betyder, at en pakke bliver sat i kø hvis en anden pakke er forsinket -
det sker ikke ved UDP.

> Du kan styre pakketransporten selv. Om det er bedre eller ej,
> er helt afhængig af applikationens behov for komplette data,
> og om du kan opfinde en effektiv protokol.

Det glæder mig at vi er enige på dette punkt

> Hvilke egenskaber gør TCP bedre omkring kryptering?

Hvad mener du? Hvis du mener, om TCP giver krypteringen fordele, så kender
jeg ikke noget til det. Men hvis du mener, om krypterede forbindelser kan
have fordele af at bruge TCP frem for UDP, så er der en gigantisk fordel
ved TCP: Evnen til at passere en NAT router. F.eks. bruger ssh
TCP-forbindelser. Jeg er i tvivl om, hvor du vil hen med spørgsmålet - så
spørg mere præcist hvis jeg ikke har svaret dig præcist nok.

> Og hvis
> du har et problem med TCPs pakkehåndtering i streaming uden
> kryptering, hvorfor bliver det problem så væk MED kryptering?

TCP ændrer sig jo ikke om du bruger kryptering eller ej - men UDP's fordele
bliver mindre i de fleste tilfælde, hvor der krypteres. Og da man ofte skal
bestemme sig for TCP eller UDP, vil flere vælge TCP, når UDP mister sine
fordele.

> Jo, hele tråden handler om ændring af CNNs streamede nyheder.

Det kunne forklare, at vi snakker forbi hinanden. Jeg læste Morton's
"f.eks." som betydende "for eksempel".

> Hvilket er det, jeg har sagt fra starten. Prøv lige at følge lidt
> med i den tråd, du skriver i

Hold dig til emnet eller skriv i dk.snak.mudderkastning. Når jeg henter film
fra "f.eks. CNN", så henter jeg med TCP, og det vil jeg også tro at de
fleste andre gør. Når Morton angiver UDP streaming som subject, så går jeg
ud fra, at han netop fravælger en diskussion omkring TCP og helst vil have
en diskussion om sikkerheden i transmission med UDP pakker.

Jeg anser ikke CNN's videoer som værende det eneste, der skal diskuteres
her. Som du vil kunne se i mine indlæg, taler jeg generelt om UDP streaming
protokoller, inkl. video, lyd, simulationer/spil osv.

Det er derfor også det, du bør forholde dig til, når du besvarer mine indlæg
- det giver ikke mening at besvare mine indlæg ud fra, at de kun omhandler
CNN.

>>Dette er selvflg. ekstremt følsomt over for pakketab, idet en
>>enkelt tabt pakke kan give en ekstremt høj latency på opdateringer,
> Nej, ikke hvis du styrer din TCP-stak ordentligt.

Hvordan kan du forhindre en TCP forbindelse i at gensende en tabt pakker med
forældet information?

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>> Det er fysisk umuligt ikke at acceptere den slags tider på lav-
>> hastigheds-forbindelser.

>Det kommer an på, hvad du måler.

Vi snakker specifikt om serialization her.

>> Med ISDN ligger serialization af 1 KB
>> rå data omkring 128 ms.

>Hvis man forsøger at få lav latency, sender man jo ikke 1kbyte pakker, vel?

Det er sådan set underordnet. Latency for en given datamængde
stiger, jo mindre pakker du sender (overhead).

>Hmmm... der er mange måder at måle hastighed på - hvis du skal overføre en
>stor fil bør man for internettets skyld bruge TCP, men når vi snakker
>tidsforsinkelse er der mange måder at UDP kan være hurtigere end TCP på.

Man skal bruge TCP for nettets skyld? Nettet er komplet ligeglad.
Stakken er sådan set også ligeglad. Om noget skal det være TCP med
en justeret window size, så forsinkelser på pakketab negligeres -
men det er udelukkende for at optimere hastigheden for brugerens
skyld.

>Jeg vil gerne give et eksempel: I TCP skal de ankomme i samme rækkefølge.
>Det betyder, at en pakke bliver sat i kø hvis en anden pakke er forsinket -
>det sker ikke ved UDP.

De bliver ikke sat i kø. De ryger bare ind i vinduet, og TCP
sørger selv for at stykke dem sammen i den rigtige rækkefølge.
Kun hvis vinduet bliver fyldt pånær én pakke, er der basis for
noget forsinkelse. Men det er der også workarounds til i et
vist omfang.

>> Hvilke egenskaber gør TCP bedre omkring kryptering?

>TCP ændrer sig jo ikke om du bruger kryptering eller ej - men UDP's fordele
>bliver mindre i de fleste tilfælde, hvor der krypteres. Og da man ofte skal
>bestemme sig for TCP eller UDP, vil flere vælge TCP, når UDP mister sine
>fordele.

UDPs fordel er, at de enkelte pakker er uafhængige af hinanden. Den
fordel bliver hverken større eller mindre, hvis indholdet krypteres.
Det kan være, at nogle eksterne omstændigheder gør, at TCP er bedre
til at sikre transmissionen. Men hvis du har problemer med at få
TCP til at virke i streaming-sammenhænge, må TCP anses for lige
uegnet - hvadenten du bruger kryptering eller ej.

>Jeg anser ikke CNN's videoer som værende det eneste, der skal diskuteres
>her. Som du vil kunne se i mine indlæg, taler jeg generelt om UDP streaming
>protokoller, inkl. video, lyd, simulationer/spil osv.

Spil streamer ikke. Streaming er transmission af noget multimedie-
værk, der afpasser datamængden efter de aktuelle omstændigheder.

Det vil sige, at hvis du sidder på en 2 Mbps forbindelse, får du
din streamede video med 2 Mbps datarate. Begynder du at downloade
parallelt med streamingen, opdager protokollen dette, og videoen
kommer nu ned med 1 Mbps (eller hvad der nu er plads til - hvilket
afhænger af din download, window-settings, netværksperformance og
117 andre ting). Der kommer ingen afbrydelser i din video, selvom
der sker ret radikale ændringer med de transmitterede data.

Hvis du pludselig får et pakketab på 4%, justerer streamingen sin
transmission efter det - f.eks. ved at justere pakkestørrelsen,
bufferstørrelsen, codec'en eller hvad den nu har mulighed for.

Jeg kender ingen spil, der fungerer på den måde?

>>>Dette er selvflg. ekstremt følsomt over for pakketab, idet en
>>>enkelt tabt pakke kan give en ekstremt høj latency på opdateringer,
>> Nej, ikke hvis du styrer din TCP-stak ordentligt.

>Hvordan kan du forhindre en TCP forbindelse i at gensende en tabt pakker med
>forældet information?

Det kan jeg ikke. Men jeg kan minimere den tid, der går, fra en
pakke bliver væk undervejs, til den gensendes. Dermed minimeres
et eventuelt flowstops (hej Andreas) varighed også. Hvis det da
ikke bliver helt væk.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Vi snakker specifikt om serialization her.

Vær venligst opmærksom på, at "serialization" kan bruges på mange ting, og
at en lærebog, som du har læst, ikke har patent på ordet. Jeg tvivler
stærkt på, at du får mange med på at mene, at serialization i streaming
sammenhæng ikke kan betyde andet end noget, der har med pakker i minimum
1kbyte størrelsen at gøre.

> Det er sådan set underordnet. Latency for en given datamængde
> stiger, jo mindre pakker du sender (overhead).

Vrøvl. Latency falder, jo mindre pakken er. Latency er tidsforsinkelsen, og
verden er indrettet således, at jo mindre pakken er, jo mindre tid tager
det at sende den. Pakkestørrelsen er jo netop ofte et kompromis mellem lav
latency og høj båndbredde.

> Man skal bruge TCP for nettets skyld? Nettet er komplet ligeglad.

Internettets routere er normalt konfigureret, så der ikke opstår pakketab på
TCP forbindelser. Det sker ved at antallet af TCP-forbindelser er
begrænset, og ved at en TCP-forbindelse normalt har et maksimalt pakker ude
ad gangen. Herved er der også sat en maksimal størrelse på den buffer, der
skal til på en router, for at der ikke opstår pakketab. TCP forbindelser
har desuden den egenskab, at man nemt kan sniffe på en forbindelse, og se,
hvor mange TCP forbindelser der er gang i.

Man kan selvfølgelig godt håndtere UDP på en måde, som fungerer ligesådan
mht. styring af trafikmængden, men ofte indgår pakketab som en del af
styringen af UDP båndbredden, og UDP er heller ikke så gennemskuelig som
TCP når vi snakker netværksovervågning.

> en justeret window size, så forsinkelser på pakketab negligeres -

Hvad er et forsinket pakketab?

> De bliver ikke sat i kø. De ryger bare ind i vinduet, og TCP
> sørger selv for at stykke dem sammen i den rigtige rækkefølge.

Hvis afsenderen sender TCP pakkerne 1,2,3,4,5 og din maskine så modtager
pakkerne 1,2,4,5,3 - vil du så påstå, at din applikation modtager pakke 4
så snart den er ankommet, eller vil du mene at du modtager pakke 3 før
pakke 4?

Jeg gav bare udtryk for, at TCP modtager pakkerne i samme rækkefølge som de
er afsendt, hvilke ikke kan undgå at give større latency end hvis det samme
skete med UDP.

> UDPs fordel er, at de enkelte pakker er uafhængige af hinanden.

Det er en af fordelene - der er andre, delvist afledte fordele.

> Den fordel bliver hverken større eller mindre, hvis indholdet krypteres.

Enig, så længe du kigger på den ene fordel.

> Spil streamer ikke.

Det er en definitionssag. Spilleservere leverer en realtids strøm af data,
som på klienten omdannes til et videobillede. Strømmen tilpasser sig
pakketab og båndbredde. Jeg er godt klar over, at kompressionsmetoden er
meget specifik for en special virtuel verden, men jeg kan strengt taget
ikke se nogen anden forskel mellem det og et spil. Fik du nogensinde set
Tribes 2 TV? Hjemmesiden er desværre nedlagt, men resumeet fra google er:

"Streams a live Tribes 2 game to others by transferring the filmers demo to
a high bandwidth server which then viewers can connect to and watch the
demo as i..."

Det er et system der gør, at en kamp mellem to klaner kan ses af mange
mennesker næsten samtidigt med at kampen afvikles.

> Det vil sige, at hvis du sidder på en 2 Mbps forbindelse, får du
> din streamede video med 2 Mbps datarate.

Så falder CNN helt klart uden for din definition hehe

> Jeg kender ingen spil, der fungerer på den måde?

Tribes 2? Den gør det endda over TCP på en ret intelligent måde.

>>Hvordan kan du forhindre en TCP forbindelse i at gensende en tabt pakker
>>med forældet information?
> Det kan jeg ikke. Men jeg kan minimere den tid, der går, fra en
> pakke bliver væk undervejs, til den gensendes.

Ideen i UDP er jo netop at man kan lave det så de pakker, der tabes, ikke
gensendes, men at man sender mere opdaterede pakker i stedet. Det har jeg i
øvrigt skrevet flere gange før i denne tråd, og den mekanisme gør netop at
man kan nøjes med mindre båndbredde til det samme i forhold til TCP, og at
latency bliver mindre, målt som tiden fra en handling til at handlingen
optræder hos brugeren.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>Vær venligst opmærksom på, at "serialization" kan bruges på mange ting, og
>at en lærebog, som du har læst, ikke har patent på ordet.

Serialization er et specifikt begreb, der handler om clocking af
data på et givent transmissionsmedie. Så der er ikke noget at tage
fejl af, uanset hvilken lærebog man måtte have læst.

>> Det er sådan set underordnet. Latency for en given datamængde
>> stiger, jo mindre pakker du sender (overhead).

>Vrøvl. Latency falder, jo mindre pakken er.

Ja, for den enkelte pakke. Ikke for datamængden.

>> Man skal bruge TCP for nettets skyld? Nettet er komplet ligeglad.

>Internettets routere er normalt konfigureret, så der ikke opstår pakketab på
>TCP forbindelser.

Dokumentation?

Fordelen er - om noget - at TCP-streams undgår en tur forbi RSPen
i de større routere.

>Det sker ved at antallet af TCP-forbindelser er
>begrænset, og ved at en TCP-forbindelse normalt har et maksimalt pakker ude
>ad gangen. Herved er der også sat en maksimal størrelse på den buffer, der
>skal til på en router, for at der ikke opstår pakketab.

Routere har ikke buffere på den måde. De har lokale tabeller, men
de er uafhængige af datamængden og antal pakker undervejs.

>> en justeret window size, så forsinkelser på pakketab negligeres -

>Hvad er et forsinket pakketab?

Forsinkelser *som følge* af pakketab (hvor vinduet fyldes ud pånær
en pakke eller to, så det ikke kan flytte).

>Hvis afsenderen sender TCP pakkerne 1,2,3,4,5 og din maskine så modtager
>pakkerne 1,2,4,5,3 - vil du så påstå, at din applikation modtager pakke 4
>så snart den er ankommet, eller vil du mene at du modtager pakke 3 før
>pakke 4?

De kan komme i rækkefølgen 5, 3, 1, 2, 4 uden at det generer
nogen nævneværdigt. Jeg modtager dem i den rækkefølge, de kommer,
og får mit vindue til at glide, når det er muligt.

>Jeg gav bare udtryk for, at TCP modtager pakkerne i samme rækkefølge som de
>er afsendt,

Og det er forkert.

>> Spil streamer ikke.

>"Streams a live Tribes 2 game to others by transferring the filmers demo to
>a high bandwidth server which then viewers can connect to and watch the
>demo as i..."

Det er jo også en multimediestrøm? Altså ikke kommunikation mellem
to spillere om de tos positioner i forhold til hinanden. Dette går
altså netop ind under min definition.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Så der er ikke noget at tage
> fejl af, uanset hvilken lærebog man måtte have læst.

Serialization er et begreb, der dækker processen at lade et objekt streame
sine data, dvs. skrive sine data til et objekt uden random access på en
måde, så objektet kan regenereres ud fra disse data. Hvis du har en anden
definition, så har du læst en anden bog, og så er begrebet ikke entydigt.

>>Internettets routere er normalt konfigureret, så der ikke opstår pakketab
>> på TCP forbindelser.
> Dokumentation?

Prøv det selv... så finder du hurtigt ud af det.

> Routere har ikke buffere på den måde. De har lokale tabeller, men
> de er uafhængige af datamængden og antal pakker undervejs.

Du må meget gerne fremlægge dokumentation for, at routere ikke lægger
indkommende pakker i en buffer, samt at routere til meget store
trafikmængder ikke har større buffere end routere til små trafikmængder.

>>Hvad er et forsinket pakketab?
> Forsinkelser *som følge* af pakketab

Hvordan hænger det sammen, at du både snakker om negligering af forsinkelser
som følge af pakketab, samt at der ikke kan opstå forsinkelser som følge af
pakketab som jeg mener der kan?

> Det er jo også en multimediestrøm? Altså ikke kommunikation mellem
> to spillere om de tos positioner i forhold til hinanden.

Tja - kald det bare en multimediestrøm. Det er, såvidt jeg ved, præcist
samme kommunikation som når to spillere spiller med hinanden, og bruger
dermed ikke video-relaterede metoder, men det kan man vel derfor godt
kaldes en multimediestrøm hvis du vil. Datamængden er gigantisk meget
mindre end hvis det var video, der blev overført, og billedkvaliteten er
den samme som hvis man selv havde spillet. Du kan ikke se Tribes 2 TV
streams uden at starte selve spillet og have streaming funktionen
aktiveret.

>>pakkerne 1,2,4,5,3 - vil du så påstå, at din applikation modtager pakke 4
>>så snart den er ankommet, eller vil du mene at du modtager pakke 3 før
>>pakke 4?
> De kan komme i rækkefølgen 5, 3, 1, 2, 4 uden at det generer
> nogen nævneværdigt. Jeg modtager dem i den rækkefølge, de kommer,
> og får mit vindue til at glide, når det er muligt.

Hvis du seriøst mener, at en TCP forbindelse ikke garanterer at data
ankommer på samme måde som de blev afsendt, så kan jeg ikke rigtig tage dig
seriøst længere. Det ville jo betyde at ens Web-browser fik html-koden i
tilfældig rækkefølge. Enten har du et kommunikationsproblem, eller også har
du misforstået noget. Du må meget undskylde den personlige udmelding fra
min side, men det er svært at diskutere emnet, når en så fundamental ting
kan debatteres.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>> Så der er ikke noget at tage
>> fejl af, uanset hvilken lærebog man måtte have læst.

>Serialization er et begreb, der dækker processen at lade et objekt streame
>sine data,

I ISP-verdenen dækker det udelukkende over at clocke en flok
data over et medie (Ethernet, serielt link eller whatnot). Det
er den relevante diskussion her.

Hvad har serialization med streaming at gøre? Der er intet behov
for det i processen som sådan - serveren kan jo være ligeglad med,
hvordan data kommer frem, og hvordan det clockes. Den skal bare se
på det feedback, den måtte få.

>> Routere har ikke buffere på den måde. De har lokale tabeller, men
>> de er uafhængige af datamængden og antal pakker undervejs.

>Du må meget gerne fremlægge dokumentation for, at routere ikke lægger
>indkommende pakker i en buffer, samt at routere til meget store
>trafikmængder ikke har større buffere end routere til små trafikmængder.

Store routere har ikke buffere som sådan, for de router ikke
data centralt. De relevante buffere findes på linjekortene og
er afhængige af linjekortenes art og performance. Der er ikke
tale om routere som sådan men derimod om switching af sessioner
(ikke enkeltpakker) direkte mellem linjekortene.

Derfor har selve routeren ikke det store behov for at kigge på
den enkelte TCP-session, når den først har fundet ud af, hvor
sessionen skal fra og til (linjekort-mæssigt). Det klares ofte
ved handshaket - resten af sessionen bliver derfor switchet og
ikke routed.

>Hvordan hænger det sammen, at du både snakker om negligering af forsinkelser
>som følge af pakketab, samt at der ikke kan opstå forsinkelser som følge af
>pakketab som jeg mener der kan?

Forsinkelsens "impact" afhænger af de egenskaber, du har givet
din IP-stak. Især af vinduernes størrelser. Hvis de bliver sat
nogenlunde fornuftigt i forhold til applikationen, kan jeg ikke
se, at man kan komme ud for nogen nævneværdige forsinkelser. I
tilfældet med en arbejdsstation er MxU- og window size-værdier
sat til et kompromis mellem interaktivitet og volumen. Det er
naturligvis det første, man ændrer på, hvis man skal streame
eller på anden måde udnytte stakken til et specifikt formål.

>> De kan komme i rækkefølgen 5, 3, 1, 2, 4 uden at det generer
>> nogen nævneværdigt. Jeg modtager dem i den rækkefølge, de kommer,
>> og får mit vindue til at glide, når det er muligt.

>Hvis du seriøst mener, at en TCP forbindelse ikke garanterer at data
>ankommer på samme måde som de blev afsendt, så kan jeg ikke rigtig tage dig
>seriøst længere.

Det mener jeg, ja. Hvordan data *ankommer* til modtageren er helt
ligegyldigt. De enkelte pakker kan nemt tage forskellige veje (én
pakke fra USA via Mexico til Spanien, derfra via syv forskellige
ISP'er i Frankrig, via Tyskland og Sverige til Danmark, mens den
næste tager den direkte tur fra USA via England til Danmark. Pakke
2 ankommer derfor til modtageren lang tid før pakke 1).

Det er formålet med sliding window-princippet i TCP. Hvordan de
enkelte pakker ankommer til modtageren, er underordnet, så længe
TCP blot får fyldt vinduet ud, inden det skubbes.

Det er basisviden, når man snakker TCP, og det er dén parameter,
det først og fremmest er relevant at se på, når vi snakker om at
optimere protokollen til specifikke formål.

Uden en grundig forståelse af dét, er det omsonst at snakke mere
om TCP og hvordan det fungerer i praksis.

>Det ville jo betyde at ens Web-browser fik html-koden i
>tilfældig rækkefølge.

Nej, det sørger TCP for at rette op på i *modtagerens* ende. Det er
forholdsvis sjældent, at pakkerne kommer frem til modtageren i den
rigtige rækkefølge ude i den virkelige verden.

TFTP er et eksempel på en UDP-protokol, der benytter ACK af hver
pakke til at sikre, at pakkerne ankommer i den rigtige rækkefølge.
Det ses tydeligt af protokollens performance, hvorfor den metode er
rigtig dårlig. Dermed naturligvis ikke sagt, at seriel ACKing er
den eneste løsning med UDP - så langt fra. Det er bare det store
skrækeksempel.

Mvh.
   Klaus - 8 års erfaring med IP i carrier-grade netværk.

---

Klaus Ellegaard wrote:
> I ISP-verdenen dækker det udelukkende over at clocke en flok
> data over et medie (Ethernet, serielt link eller whatnot).

Nu siger du, at serialization udelukkende dækker over dette. Jeg forstår din
formulering sådan, at du ikke mener at det kan dække over andet. Du har
tidligere sagt at "Streaming er transmission af noget multimedieværk, der
afpasser datamængden efter de aktuelle omstændigheder. Det vil sige, at
hvis du sidder på en 2 Mbps forbindelse, får du din streamede video med 2
Mbps datarate. "

Du har desuden sagt, at CNN's videoformidling var streaming, selv om de
aldrig kan komme op på 2Mbps på min 2Mbps linie.

Kan du se, at det er hamrende svært at diskutere, når du skifter
definitionerne ud og siger at der kun findes den definition?

Jeg kan i øvrigt fortælle, at man i telekommunikation ofte bruger "stream" i
forbindelsen med de data, der ankommer i en TCP forbindelse. Du kan få lidt
dokumentation her (søg efter ordet stream på hver side):

http://www.ethereal.com/docs/user-guide/x2417.html
http://www.csm.ornl.gov/~dunigan/netperf/parallel.html
http://radio.userland.com/discuss/msgReader$5759#5834

Faktisk er den konkurrerende implementation til sockets noget, der hedder
noget med streams (jeg kan dog ikke lige huske den præcise betegnelse). Min
pointe var bare at fortælle, at streams og streaming kan betyde andet end
"CNN video", som du tidligere har defineret debatten her til at omhandle.

> Store routere har ikke buffere som sådan, for de router ikke
> data centralt. De relevante buffere findes på linjekortene og

Hvis du tager alle liniekort ud af en router, har du så stadigvæk en
fungerende router? Nej vel?

>>Hvis du seriøst mener, at en TCP forbindelse ikke garanterer at data
>>ankommer på samme måde som de blev afsendt, så kan jeg ikke rigtig tage
>>dig seriøst længere.
> Det mener jeg, ja.

Suk. Du modsiger jo alle lærebøger på området, held og lykke med det. For
eksempel:

http://support.baynetworks.com/library/tpubs/html/router/soft1200/117358AA/B_32.HTM

TCP Features
Since IP does not always guarantee reliable transfer of data, TCP implements
several reliability features to ensure that data arrives at its destination
uncorrupted AND IN THE ORDER SENT. Table 2-1 describes these features.

> Det er formålet med sliding window-princippet i TCP.

Hvis du er i tvivl, så kender jeg godt TCP, jeg er trods alt civilingeniør
inden for telekommunikation og har kørt netværk siden 1993. Jeg er heller
ikke i tvivl om, at du har haft en god lærebog i TCP, og har lært alt om
sliding windows osv.

Men du har en dybt mærkelig måde at bruge terminologien på, hvor du har
meget svært ved at sætte dig ind i, at andre måske bruger terminologien en
anelse anderledes end du har lært.

Det er simpelthen grundlærdom, at "TCP sikrer rækkefølgen af data". Jeg er
dybt chokeret over, at nogen med erhvervserfaring i netværk vil modsige
dette og bekræfte at være uenig med dette.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>Kan du se, at det er hamrende svært at diskutere, når du skifter
>definitionerne ud og siger at der kun findes den definition?

Det mener jeg ikke, jeg gør. Men der er ingen grund til at fortsætte,
når emnet er ved at være off-topic og vi ikke kan finde ud af hvilket
lag, vi snakker om.

Dem, jeg har snakket med om tråden, er helt tilfredse med min
anvendelse af terminologi og de lag, jeg bevæger mig på. Så jeg
kan ikke se, at der er noget problem med det, jeg skriver.

Mvh.
   Klaus.

---

On Mon, 14 Jul 2003 09:10:20 +0200, "Lars B. Dybdahl"
<Lars@dybdahl.dk> wrote:

> Det er simpelthen grundlærdom, at "TCP sikrer rækkefølgen af
> data". Jeg er dybt chokeret over, at nogen med erhvervserfa-
> ring i netværk vil modsige dette og bekræfte at være uenig
> med dette.

Hvis man mener, at TCP sikrer, at pakkerne *kommer frem* (til
endeudstyret) i den rette rækkefølge, altså som de blev afsendt,
så tager man fejl. Det har TCP ingen indflydelse på.

Hvis man derimod mener, at strømmen af pakker eksponeres for L5 i
endeudstyret i den rette rækkefølge, så er det en lidt anden sag.

Jeg tror, uenigheden (og forvirringen) kommer af ovenstående.

-A
--
http://www.hojmark.org/

---

Asbjorn Hojmark wrote:
> Hvis man mener, at TCP sikrer, at pakkerne *kommer frem* (til
> endeudstyret) i den rette rækkefølge, altså som de blev afsendt,
> så tager man fejl. Det har TCP ingen indflydelse på.

Enig.

> Hvis man derimod mener, at strømmen af pakker eksponeres for L5 i
> endeudstyret i den rette rækkefølge, så er det en lidt anden sag.

Enig.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

In article <3f11cbf1$0$5135$edfadb0f@dread11.news.tele.dk>, Lars B. Dybdahl wrote:

>> Så der er ikke noget at tage
>> fejl af, uanset hvilken lærebog man måtte have læst.
>
> Serialization er et begreb, der dækker processen at lade et objekt streame
> sine data, dvs. skrive sine data til et objekt uden random access på en

Indrømmet, i har fundet den forkerte gruppe til det, men det er altså
netværk i diskuterer, så der dækker den definition næppe. Ellers kunne
vi vel også begynde at tale om samlebånd på fabrikker når vi taler
serialization.

>>>Internettets routere er normalt konfigureret, så der ikke opstår pakketab
>>> på TCP forbindelser.
>> Dokumentation?
>
> Prøv det selv... så finder du hurtigt ud af det.

Det er noget sludder, de kraftige backbone-routere bekymrer sig ikke om
hvilken protokol, der er tale om, faktisk er de hurtigste liniekort som
regel ikke engang konfigureret til at køre andet end FIFO-queueing.

>> Routere har ikke buffere på den måde. De har lokale tabeller, men
>> de er uafhængige af datamængden og antal pakker undervejs.
>
> Du må meget gerne fremlægge dokumentation for, at routere ikke lægger
> indkommende pakker i en buffer, samt at routere til meget store
> trafikmængder ikke har større buffere end routere til små trafikmængder.

Hvorfor skulle det specifikt gøre at TCP ikke oplever pakketab.

> Hvis du seriøst mener, at en TCP forbindelse ikke garanterer at data
> ankommer på samme måde som de blev afsendt, så kan jeg ikke rigtig tage dig

De behøver netop ikke at ankomme på samme måde, det er stakkens ansvar
at reorganisere dem.

--
Andreas Plesner Jacobsen | A day for firm decisions!!!!! Or is it?

---

Andreas Plesner Jacobsen wrote:
> Det er noget sludder, de kraftige backbone-routere bekymrer sig ikke om
> hvilken protokol, der er tale om, faktisk er de hurtigste liniekort som
> regel ikke engang konfigureret til at køre andet end FIFO-queueing.

Det var også, hvad jeg gik ud fra. Og eftersom at der ikke opstår pakketab
lokalt med TCP forbindelser, må de fleste mennesker internet opkoblingerne
også have en buffer der er stor nok til TCP vinduet.

Mit gæt er, at de fleste UDP pakker tabes på slutbrugeropkoblingen.

> Hvorfor skulle det specifikt gøre at TCP ikke oplever pakketab.

Det samme gælder UDP. Men når man skal designe en router til at den ikke
skal have pakketab, så giver det ikke meget mening at designe efter UDP
trafik, da den kan opføre sig ret uforudsigeligt. De største routere er
designet efter, hvordan store trafikmængder opfører sig, men mindre routere
er da helt klart designet efter, at rimelige mængder TCP trafik ikke må
give pakketab.

F.eks. giver TDC's speedstream routere ikke pakketab, selv om man kobler
flere PC'ere på og surfer løs. Men sætter man 60 PC'ere på, og surfer løs,
knækker de fuldstændigt sammen og giver meget høje pakketab. Hvordan har
Speedstream folkene regnet den ud? Jo, de har tænkt over, hvor kraftig
routeren skal være for at holde til en vis mængde TCP belastning. De kan
ikke regne det ud fra UDP belastning, da UDP per definition er udefineret
mht. hvor stor routeren skal være

Altså: Pakketabet er selvflg. det samme for UDP og TCP, men TCP er mere
anvendeligt når man skal lave deterministiske beregninger på
routerkapacitet, hvis man ikke har trafikdata, det skal passe til.

> De behøver netop ikke at ankomme på samme måde, det er stakkens ansvar
> at reorganisere dem.

Vi snakker udelukkende om ankomst til applikationen - ikke IP pakkernes
ankomst til protokolstakimplementationen.

Mit argument er, at uanset hvilken rækkefølge IP pakkerne ankommer i, så vil
f.eks. en HTTP strøm ankomme i den rigtige rækkefølge. Og fordi TCP sikrer,
at rækkefølgen bevares, vil den være nødt til at tilbageholde data fra at
blive videregivet til applikationen, hvis IP pakkerne kommer i forkert
rækkefølge. Klaus formulerer sig på en måde, så jeg kommer i stor tvivl om,
hvorvidt han er enig. Det lyder som om at du er enig.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>Det var også, hvad jeg gik ud fra. Og eftersom at der ikke opstår pakketab
>lokalt med TCP forbindelser, må de fleste mennesker internet opkoblingerne
>også have en buffer der er stor nok til TCP vinduet.

Computere, ja.

Routere, nej.

>> Hvorfor skulle det specifikt gøre at TCP ikke oplever pakketab.

>Det samme gælder UDP. Men når man skal designe en router til at den ikke
>skal have pakketab, så giver det ikke meget mening at designe efter UDP
>trafik, da den kan opføre sig ret uforudsigeligt.

Routere er ikke designet efter en specifik type trafik - faktisk er
store routere ikke klar over, hvad det egentlig er, de forwarder.
Med nogle få forbehold.

>De største routere er designet efter, hvordan store trafikmængder
>opfører sig,

Nej, de er designet efter de fysiske interfaces, de har eller kan
have.

>men mindre routere er da helt klart designet efter, at rimelige
>mængder TCP trafik ikke må give pakketab.

Nej, de er designet efter de fysiske interfaces, de har eller kan
have.

>F.eks. giver TDC's speedstream routere ikke pakketab, selv om man kobler
>flere PC'ere på og surfer løs. Men sætter man 60 PC'ere på, og surfer løs,
>knækker de fuldstændigt sammen og giver meget høje pakketab.

Det skyldes ikke routeren. Det skyldes det fysiske interface.

Hvorfor vil du have, at routeren skal behandle TCP-trafik? Den
skal gøre præcist det samme med TCP-trafik som med UDP-trafik
og alt andet: holde grabberne væk fra payload og forwarde den
ud på den rette linje. Det er routerens *eneste* opgave. Uanset
om det er en Speedstream eller en multi-million kroners GSR.

>Hvordan har Speedstream folkene regnet den ud? Jo, de har tænkt
>over, hvor kraftig routeren skal være for at holde til en vis
>mængde TCP belastning.

Nej, pånær NAT-modulet aner routeren basalt set ikke, at der er
tale om TCP-trafik.

>> De behøver netop ikke at ankomme på samme måde, det er stakkens ansvar
>> at reorganisere dem.

>Vi snakker udelukkende om ankomst til applikationen - ikke IP pakkernes
>ankomst til protokolstakimplementationen.

Nej, vi snakker om latency og pakketab - det har intet med selve
applikationen at gøre, når vi snakker TCP vs. UDP.

>Mit argument er, at uanset hvilken rækkefølge IP pakkerne ankommer i, så vil
>f.eks. en HTTP strøm ankomme i den rigtige rækkefølge. Og fordi TCP sikrer,
>at rækkefølgen bevares, vil den være nødt til at tilbageholde data fra at
>blive videregivet til applikationen, hvis IP pakkerne kommer i forkert
>rækkefølge.

Det er jo det, jeg siger

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Routere er ikke designet efter en specifik type trafik

Det bliver voip router producenterne kede af at høre. Jeg tror også at TDC
skal have fat i deres Speedstream router leverandør igen, hvis det passer -
hehe.

> Nej, de er designet efter de fysiske interfaces, de har eller kan
> have.

Snakker vi kravspecifikationer, tekniske parameter, eller fysisk design a la
Georg Jensen? Snakker vi routere generelt eller udelukkende ISP backbone
routere?

> Nej, de er designet efter de fysiske interfaces, de har eller kan
> have.

Mærkeligt nok så foretrækker jeg en Prestige 310 fremfor en Speedstream. Den
er bedre til at håndtere større trafikmængder på den samme ADSL
forbindelse. Men det må jo efter dit udsagn så være fuldstændigt
tilfældigt.

> Det skyldes ikke routeren. Det skyldes det fysiske interface.

Fysisk interface kan jeg ikke læse på anden vis end "det stik, som man
sætter ledningen ind i". Interface er jo en snitflade og har derfor per
definition ikke elektronik i sig. Eksempler på interfaces: RS232, Ethernet,
IrDa, USB osv.

Jeg kunne gætte på, at du mener "interfacekort", dvs. en elektronikkort,
hvorpå interfacet forefindes - men i så fald ville der jo kun være tale om
routere, hvor den slags forefindes, og da vi lige nu snakker om ADSL
routere, må jeg antage, at du med interface mener opkoblingen til ADSL
modem'et. Da Zyxel og Speedstream bruger samme interface, er din udtalelse
ikke korrekt.

Men jeg går ud fra, at det skyldes at du fik fejlformuleret dig.

> Hvorfor vil du have, at routeren skal behandle TCP-trafik?

Jeg har aldrig sagt, at routeren skal kende til, om trafikken indeholder
TCP, bortset fra ved NAT. Men jeg vil meget gerne have min router til at
transportere alle IP pakker rundt, uanset indhold.

> Nej, vi snakker om latency og pakketab - det har intet med selve
> applikationen at gøre, når vi snakker TCP vs. UDP.

Latency defineret som tidsforskellen mellem at der sker noget i den ene ende
af forbindelsen til at brugeren i den anden ende ser det. Det kræver, at
informationen passerer alle OSI lag, inkl. applikationslaget. Jeg har
defineret det mange gange - er det fordi du simpelthen ikke læser, hvad jeg
skriver?

>> Og fordi TCP sikrer, at rækkefølgen bevares, vil den være nødt til at
>> tilbageholde data fra atblive videregivet til applikationen, hvis IP
>> pakkerne kommer i forkertrækkefølge.
> Det er jo det, jeg siger

Lige præcist dette har du modsagt:

>>Hvis du seriøst mener, at en TCP forbindelse ikke garanterer at data
>>ankommer på samme måde som de blev afsendt
>Det mener jeg, ja.

Og grundlaget for det hele var, at jeg sagde, at tilbageholdelsen af data
fra at ankomme til applikationen fordi rækkefølgen skulle bevares, var en
tidsforsinkelse, som man ikke finder magen til i UDP. Hvilket du benægtede
på et tidspunkt, og på et andet tidspunkt omtalte som var det et faktum.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

Lars B. Dybdahl wrote:
>
> Jeg har aldrig sagt, at routeren skal kende til, om trafikken indeholder
> TCP, bortset fra ved NAT. Men jeg vil meget gerne have min router til at
> transportere alle IP pakker rundt, uanset indhold.

Hvordan skal vi så læse:

-cut-
Internettets routere er normalt konfigureret, så der ikke opstår pakketab på
TCP forbindelser. Det sker ved at antallet af TCP-forbindelser er
begrænset,...
-cut-

Som du skrev ?

--
Don't waste space

---

Thomas Corell wrote:
>> Jeg har aldrig sagt, at routeren skal kende til, om trafikken indeholder
>> TCP, bortset fra ved NAT. Men jeg vil meget gerne have min router til at
>> transportere alle IP pakker rundt, uanset indhold.
> Hvordan skal vi så læse:
> -cut-
> Internettets routere er normalt konfigureret, så der ikke opstår pakketab
på
> TCP forbindelser. Det sker ved at antallet af TCP-forbindelser er
> begrænset,...
> -cut-

Du skal ikke læse det sådan, at routeren lægger nogen begrænsning på
antallet, hvis det er den del, du er i tvivl om.

Du skal læse det sådan, at hvis du f.eks. har en router der skal håndtere
opkobling fra 100 samtidige brugere, og at disse brugere i 99,9% af tiden
vil have en trafikmængde svarende til mindre end 9000 alm. TCP forbindelser
fra en Winsock med default parametre åben, så kunne det være fornuftigt at
designe routeren til at kunne håndtere den mængde IP pakker der svarer
dertil.

Du kan også læse det sådan, at hvis en NAT router til en ISP skal kunne
fungere uden pakketab i 99,9% af tiden hos brugerne, så vil router
producenten sandsynligvis kigge en hel del på, hvilken type trafik som
ISP'en ønsker skal køre bedst, og hvad brugerne rent faktisk benytter. Her
er TCP-forbindelser det, som de fleste brugere benytter og ofte vurderer en
ISP ud fra. Personligt ville jeg ikke sable en ISP ned, hvis deres TCP
forbindelser er suverænt gode, men deres UDP ikke fungerer alt for godt, af
den simple årsag, at jeg ikke kender nogen, der er afhængig af en god UDP
forbindelse ud i verden.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

In article <3f126b42$0$5147$edfadb0f@dread11.news.tele.dk>, Lars B. Dybdahl wrote:
>
> Du skal læse det sådan, at hvis du f.eks. har en router der skal håndtere
> opkobling fra 100 samtidige brugere, og at disse brugere i 99,9% af tiden
> vil have en trafikmængde svarende til mindre end 9000 alm. TCP forbindelser
> fra en Winsock med default parametre åben, så kunne det være fornuftigt at
> designe routeren til at kunne håndtere den mængde IP pakker der svarer
> dertil.

Jeg forstår overhovedet ikke din vægt på TCP, fx har jeg
SSH-forbindelser, der knap har en pakke i timen og anden bulk-trafik der
brager derudaf med >100Mbps.

--
Andreas Plesner Jacobsen | I must have slipped a disk -- my pack hurts!

---

Andreas Plesner Jacobsen wrote:
> Jeg forstår overhovedet ikke din vægt på TCP, fx har jeg
> SSH-forbindelser, der knap har en pakke i timen og anden bulk-trafik der
> brager derudaf med >100Mbps.

SSH kører også TCP.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

Lars B. Dybdahl wrote:
>
> Personligt ville jeg ikke sable en ISP ned, hvis deres TCP
> forbindelser er suverænt gode, men deres UDP ikke fungerer alt for godt, af
> den simple årsag, at jeg ikke kender nogen, der er afhængig af en god UDP
> forbindelse ud i verden.

DNS ?

--
Don't waste space

---

Thomas Corell wrote:
>> den simple årsag, at jeg ikke kender nogen, der er afhængig af en god UDP
>> forbindelse ud i verden.
> DNS ?

Hehe... jeg tænkte på at kommentere netop DNS, men jeg ville nok ikke
beregne en ADSL router's kapacitet ud fra, hvor meget DNS trafik, den
skulle transportere. Hvis bare ADSL routeren er stor nok til al
TCP-trafikken, så er den også stor nok til en del UDP ting, og i hvert fald
god nok til DNS. I de mest dækkende brugerprofiler er der flere TCP
opkoblingerne end DNS forespørgsler.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

Lars B. Dybdahl wrote:
>
> Hvis bare ADSL routeren er stor nok til al
> TCP-trafikken, så er den også stor nok til en del UDP ting, og i hvert fald
> god nok til DNS. I de mest dækkende brugerprofiler er der flere TCP
> opkoblingerne end DNS forespørgsler.

Tro mig, hvis der er noget der kan gøre den jævne bruger arrig, og dømme
forbindelsen til Internettet ustabil, så er det hvis de ikke får
(hurtigt) svar på deres dns-query's.

--
Don't waste space

---

Thomas Corell wrote:
> Tro mig, hvis der er noget der kan gøre den jævne bruger arrig, og dømme
> forbindelsen til Internettet ustabil, så er det hvis de ikke får
> (hurtigt) svar på deres dns-query's.

Enig

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

Thomas Corell wrote:
> Hvordan skal vi så læse:

Du kan også læse det på den måde, at:

- Der er sjældent pakketab på de fleste internet routere.
- Antallet af TCP forbindelser er begrænset.

Jeg er enig i, at min oprindelige formulering var kluntet. Det, jeg forsøgte
at pointere, var at oprettelsen af en ekstra TCP forbindelse vha.
almindelige programmeringsmetoder som udgangspunkt ikke kan få en
veldimensioneret router til at give pakketab, hvorimod oprettelse af en
ekstra UDP forbindelse godt kan, da man ved UDP selv styrer antallet af
udgående pakker. Dette har selvflg. mest relevans der, hvor de mindste
routere forefindes, hvilket ofte er hos slutbrugeren - det kunne f.eks.
være en Speedstream router, for at tage et eksempel.

Når jeg her bruger "Speedstream" og "veldimensioneret router" i samme
afsnit, så er det faktisk fordi jeg mener det. En veldimensioneret enhed er
efter min mening den minimale løsning, der løser en given opgave. Så selv
om speedstream er utrolig uegnet til mange formål, kan den godt være
veldimensioneret til visse formål.

Men for at komme tilbage til, hvorfor jeg overhovedet kommer ind på den
slags, er for det netop er muligheden for at applikationen kan styre
antallet af pakker og indholdet i disse pakker, der gør, at UDP ofte har en
fordel, når det gælder om at få overført en bestemt information til en
anden bruger på kortest mulig tid, også selv om man ser bort fra TCP
opkoblingstiden.

Jeg er godt klar over, at pakketab normalt er så lille, at det ikke betyder
det store, og at ankomstrækkefølge ofte er så fornuftig, at forskellen
mellem TCP og UDP ikke er uhyggelig stor, men f.eks. har jeg en god
bekendt, som bor på Philippinerne, og de har en del af internet udbyderne
ca. 15-20% pakketab ud af landet, og her betyder det en hel del, om en
tabt, forældet pakke skal sendes igen, eller om man bare sender en ny med
nyt indhold. Han administrerer i øvrigt en del Linux maskiner i Danmark
vha. ssh og kunne godt tænke sig lidt mindre pakketab Her vil jeg
påstå, at mere RAM i routerne kunne reducere pakketabet (på bekostning af
latency, selvflg.), fordi jeg vurderer at den største trafikmængde kører
TCP, og dermed får begrænset deres transmissionshastighed pga.
vinduestørrelsen. UDP trafikken er mere udefinerbar.

Jeg kan her nævne, at Windows 2000 som default bruger 16kbyte TCP window
størrelse, men max. kan skalere op til 128kbyte automatisk. Nu opgaven til
publikum: Hvor meget RAM skal man bruge i en FIFO buffer for at denne
buffer kan transportere 1000 TCP forbindelser fra Windows 2000 maskiner?

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>Jeg kan her nævne, at Windows 2000 som default bruger 16kbyte TCP window
>størrelse, men max. kan skalere op til 128kbyte automatisk. Nu opgaven til
>publikum: Hvor meget RAM skal man bruge i en FIFO buffer for at denne
>buffer kan transportere 1000 TCP forbindelser fra Windows 2000 maskiner?

Hvis de 1000 forbindelser forventer samlet at kunne sende med 100
Mbps effektiv datarate i 24 timer ud mod en 2 Mbps ADSL-router,
skal FIFO-bufferen være ( 98 Mbps / 8 b/B ) * 86400 s = 1 TB.
Forudsat at de altså holder pause efter det døgn, så den kan nå
at få tømt sin buffer.

Hvis de 1000 forbindelser derimod forventer at kunne sende lidt
keepalive-pakker, burde et par kilobytes være rigeligt.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Hvis de 1000 forbindelser forventer samlet at kunne sende med 100
> Mbps effektiv datarate i 24 timer ud mod en 2 Mbps ADSL-router,
> skal FIFO-bufferen være ( 98 Mbps / 8 b/B ) * 86400 s = 1 TB.

Interessant udregning. Jeg sidder på et 100mbps netværk lige nu op mod en
2Mbps adsl router, og selv om jeg downloader alt det, jeg kan, så får jeg
ingen pakketab på ydersiden af routeren. Eftersom at pakkerne ikke
forsvinder, og eftersom at min router ikke har 1 Terabyte hukommelse - hvor
gemmes pakkerne så?

Er du sikker på, at du ikke lige har overset et eller andet?

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>Er du sikker på, at du ikke lige har overset et eller andet?

Dit eksempel er det omvendte af mit.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Hvis de 1000 forbindelser forventer samlet at kunne sende med 100
> Mbps effektiv datarate i 24 timer ud mod en 2 Mbps ADSL-router,
> skal FIFO-bufferen være ( 98 Mbps / 8 b/B ) * 86400 s = 1 TB.
> Forudsat at de altså holder pause efter det døgn, så den kan nå
> at få tømt sin buffer.

O.k. - lad os vende det om. Jeg sidder på en 100Mbps internet opkobling og
ftp uploader en fil til en ftp-server, der sidder på en 2Mbps ADSL linie.
Da der ikke foretages retransmissioner af ip pakker, og ADSL routeren ikke
har 1Terabyte hukommelse - gider du så forklare, hvor pakkerne bliver
opbevaret?

Din udregning er ganske enkelt forkert. Sådan, som du har sat det op, ville
du få samme resultat ved 1 TCP forbindelse, og du ville faktisk med den
udregning bevise, at det stort set ikke kan lade sig gøre at download en
fil på en 2Mbps internet opkobling der er større end routerens interne
buffer. Du kan modbevise din egen udregning ved at downloade en stor fil.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>> Hvis de 1000 forbindelser forventer samlet at kunne sende med 100
>> Mbps effektiv datarate i 24 timer ud mod en 2 Mbps ADSL-router,

>O.k. - lad os vende det om. Jeg sidder på en 100Mbps internet opkobling og
>ftp uploader en fil til en ftp-server, der sidder på en 2Mbps ADSL linie.

Forudsætningerne er ikke de samme. Din forventede datarate er ikke
100 Mbps men 2 Mbps.

>Din udregning er ganske enkelt forkert.

Det er dit eksempel, der ikke passer med forudsætningerne for min
udregning.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>>Din udregning er ganske enkelt forkert.
> Det er dit eksempel, der ikke passer med forudsætningerne for min
> udregning.

Jeg gik da stærkt ud fra, at din udregning relaterer sig til min opgave, som
netop tog udgangspunkt i en pæn TCP implementering.

Hvis ikke - hvad var så formålet med udregningen?

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>Hvis ikke - hvad var så formålet med udregningen?

At basere den på datamængde, som du er så glad for, i stedet for det
fysiske interfaces kapacitet.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
>>Hvis ikke - hvad var så formålet med udregningen?
> At basere den på datamængde, som du er så glad for, i stedet for det
> fysiske interfaces kapacitet.

Jeg har ikke angivet nogen datamængde. Hvad var pointen med din udregning?

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>> At basere den på datamængde, som du er så glad for, i stedet for det
>> fysiske interfaces kapacitet.

>Jeg har ikke angivet nogen datamængde. Hvad var pointen med din udregning?

At fortælle at der kun er én ting, der har relevans for bufferens
størrelse: det fysiske interfaces karakteristik. Intet som helst
andet overhovedet. Ikke noget med datamængder, ikke noget med en
maskines window-size, ikke noget med trafiktyper, intet andet.
Overhovedet.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> At fortælle at der kun er én ting, der har relevans for bufferens
> størrelse: det fysiske interfaces karakteristik. Intet som helst
> andet overhovedet.

Hvordan kommer de 1 Terabyte ind i billedet i den sammenhæng?

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>> At fortælle at der kun er én ting, der har relevans for bufferens
>> størrelse: det fysiske interfaces karakteristik. Intet som helst
>> andet overhovedet.

>Hvordan kommer de 1 Terabyte ind i billedet i den sammenhæng?

Det var et forsøg på at illustrere, at det ikke giver mening at
beregne bufferen ud fra behovet for 1000 sessioner, som du angav.

Min beregning viste, at du havde brug for "et sted mellem nogle
få kilobytes og en terabyte".

I øvrigt vil dender store buffer ikke virke i praksis alligevel.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> Det var et forsøg på at illustrere, at det ikke giver mening at
> beregne bufferen ud fra behovet for 1000 sessioner, som du angav.

Det lykkedes ikke særlig godt - jeg kan i hvert fald ikke se sammenhængen
mellem 1 Terabyte og en router, man kan købe for penge.

> Min beregning viste, at du havde brug for "et sted mellem nogle
> få kilobytes og en terabyte".

Det kan beregnes bedre. Router-producenterne bruger ikke terninger til at
beregne router kapaciteter med.

> I øvrigt vil dender store buffer ikke virke i praksis alligevel.

Enig.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

Lars B. Dybdahl wrote:
> Klaus Ellegaard wrote:
>> Hvis de 1000 forbindelser forventer samlet at kunne sende med 100
>> Mbps effektiv datarate i 24 timer ud mod en 2 Mbps ADSL-router,
>> skal FIFO-bufferen være ( 98 Mbps / 8 b/B ) * 86400 s = 1 TB.
>
> Interessant udregning. Jeg sidder på et 100mbps netværk lige nu op mod en
> 2Mbps adsl router, og selv om jeg downloader alt det, jeg kan, så får jeg
> ingen pakketab på ydersiden af routeren. Eftersom at pakkerne ikke
> forsvinder, og eftersom at min router ikke har 1 Terabyte hukommelse - hvor
> gemmes pakkerne så?

Hvor længe kan din klient sende med 100 Mbps ? (hint læs hvad Klaus
skriver).

--
Don't waste space

---

Thomas Corell <intheNOSPAMnews@corell.dk> writes:

>Hvor længe kan din klient sende med 100 Mbps ? (hint læs hvad Klaus
>skriver).

Man kan argumentere for, at det skal være en SHDSL-router, for
det er vist svært at sende mere end 512 kbps op på en ADSL

Bortset derfra er den nu rigtig nok.

Mvh.
   Klaus.

---

Thomas Corell wrote:
> Hvor længe kan din klient sende med 100 Mbps ? (hint læs hvad Klaus
> skriver).

Mit argument er, at en pæn TCP stak som den i Windows 2000, med anvendelse
af 16-128kbyte vinduer, ikke kan sende 100Mbps mod en 2Mbps router i
længere tid, og at der derfor ikke er brug for 1Terabyte.

Fejlen i Klaus's regnestykke er, at han snakker om 100Mbps effektiv datarate
imod en 2Mbps router over længere tid med vinduestørrelser på op til
128kbps. Disse tal hænger ikke sammen, og virkeligheden viser jo også, at
de ikke gør.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

In article <3f127523$0$5139$edfadb0f@dread11.news.tele.dk>, Lars B. Dybdahl wrote:
>
> Jeg er enig i, at min oprindelige formulering var kluntet. Det, jeg forsøgte
> at pointere, var at oprettelsen af en ekstra TCP forbindelse vha.
> almindelige programmeringsmetoder som udgangspunkt ikke kan få en
> veldimensioneret router til at give pakketab, hvorimod oprettelse af en
> ekstra UDP forbindelse godt kan, da man ved UDP selv styrer antallet af
> udgående pakker. Dette har selvflg. mest relevans der, hvor de mindste
> routere forefindes, hvilket ofte er hos slutbrugeren - det kunne f.eks.
> være en Speedstream router, for at tage et eksempel.

Det har intet at gøre med om det er TCP eller UDP, den eneste årsag til
at det fungerer sådan er at du her tager udgangspunkt i en pæn
implementation af TCP, UDP kan SAGTENS opføre sig på samme måde, men der
er det op til applikationen at håndtere dette.
Routerne er fortsat fuldstændig ligeglade med om det er TCP eller UDP,
og det er derfor IKKE det der er grunden til at du ikke oplever
pakketab, men en korrekt implementation af en backoff-algoritme.

> Men for at komme tilbage til, hvorfor jeg overhovedet kommer ind på den
> slags, er for det netop er muligheden for at applikationen kan styre
> antallet af pakker og indholdet i disse pakker, der gør, at UDP ofte har en
> fordel, når det gælder om at få overført en bestemt information til en
> anden bruger på kortest mulig tid, også selv om man ser bort fra TCP
> opkoblingstiden.

Nej, UDP har en fordel, når du har brug for selv at styre din
ack/backoff-algoritme eller når du kan acceptere pakketab; hvis du
kender de parametre du arbejder inden for kan en veltunet TCP-stack gøre
det meget bedre.

--
Andreas Plesner Jacobsen | The 357.73 Theory:
| Auditors always reject expense accounts
| with a bottom line divisible by 5.

---

Andreas Plesner Jacobsen wrote:
> Det har intet at gøre med om det er TCP eller UDP, den eneste årsag til
> at det fungerer sådan er at du her tager udgangspunkt i en pæn
> implementation af TCP, UDP kan SAGTENS opføre sig på samme måde

Jamen - vi er da helt enige. Men eftersom at de fleste brugere netop
anvender en pæn TCP implementation, mener jeg stadigvæk, at fremgangsmåden
er gyldig. Tænk på, at mange ISP'ere i starten ikke kunne finde ud af at
supportere hverken Macintosh eller Linux - hvorfor skulle deres routere så
kunne håndtere upæne TCP implementationer? Husk, at det her er
markedsføring og ikke særlig meget teknik.

> Routerne er fortsat fuldstændig ligeglade med om det er TCP eller UDP,
> og det er derfor IKKE det der er grunden til at du ikke oplever
> pakketab, men en korrekt implementation af en backoff-algoritme.

Jeg er fuldstændig enig.

>> slags, er for det netop er muligheden for at applikationen kan styre
>> antallet af pakker og indholdet i disse pakker, der gør, at UDP ofte har
> Nej, UDP har en fordel, når du har brug for selv at styre din
> ack/backoff-algoritme eller når du kan acceptere pakketab

Bortset fra "Nej," er jeg fuldstændig enig med dig i dette.

> kender de parametre du arbejder inden for kan en veltunet TCP-stack gøre
> det meget bedre.

Jeg er i tvivl om, hvad du mener med "veltunet TCP-stack". Lad os tage et
eksempel, der er ofte nemmere at diskutere ud fra et eksempel.

En videoafspiller modtager første portion data fra serveren. Den beslutter
sig til at påbegynde afspilningen ca. 0,2 sekunder efter modtagelsen af
denne. Efter 1 sekund spilletid finder afspilleren ud af, at ikke alle
nødvendige data er ankommet rettidigt. Hvad gør afspilleren så? Hvis vi
kører UDP, vil afspilleren kunne lave statistik over det første sekunds
forløb, der fortæller, om en forøgelse af tidsforsinkelsen fra 0,2 sekunder
til f.eks. 0,5 sekunder ville reducere pakketabet, målt som "procent pakker
der ikke ankommer hurtigt nok til at kunne blive afspillet til tiden". Hvis
ja, øges tidsforsinkelsen til 0,5 sekunder, hvis nej, så bliver
tidsforsinkelsen ved 0,2 sekunder med den billedforringelse, der nu engang
måtte være.

En sådan applikation kunne f.eks. blive programmeret op mod Winsock i
Windows - på den måde ville den være rimelig porterbar over i andre
operativsystemer.

Lad os nu antage, at vi har 20% pakketab, men at alle pakker, der ikke
tabes, ankommer lynhurtigt, f.eks. med 100ms forsinkelse.

UDP løsningen ville her konkludere, at der ikke er grund til at øge
tidsforsinkelsen fra 0,2 sekunder til 0,5 sekunder, og ville holde den lave
tidsforsinkelse. En normal TCP opkobling over winsock giver data i den
rækkefølge de blev sendt. Det betyder, at en modtagelse af pakkerne 1,2,4,5
ville give en retransmission af pakke 3, og pakke 4 og 5 ville blive
forsinket fordi pakke 3 skal leveres først til applikationen.
Applikationens statistik vil så muligvis vise, at hvis man øgede
tidsforsinkelsen så meget, at en retransmission af pakke 3 kan nås, så
ville pakke 4 og 5 være til tiden.

TCP afspilleren vil med andre ord have større pakketab (defineret som antal
pakker der kommer for sent) ved 0,2 sekunder, og øge til 0,5 sekunder,
hvorimod UDP afspilleren vil blive ved 0,2 sekunder.

Dette eksempel passer meget godt med min oprindelige påstand om, at UDP vil
være i stand til at arbejde med lavere tidsforsinkelser i visse tilfælde.

Du må meget gerne pointere eventuelle fejl i ovenstående eksempel, hvis du
finder nogen. Er dette eksempel noget, hvor begrebet "veltunet TCP stak"
finder anvendelse? Hvis ja, så er jeg meget interesseret i at vide, hvordan
en veltunet TCP stak kan få eksemplet til at performe med lige så lille
tidsforsinkelse som UDP løsningen, uden tab af billedkvalitet.

Hilsen,

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

Lars B. Dybdahl skrev:

> Jeg kan her nævne, at Windows 2000 som default bruger 16kbyte TCP
> window størrelse, men max. kan skalere op til 128kbyte automatisk.

"Microsoft Windows 2000 TCP/IP Implementation Details"

<URL:
http://www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/tcpip_implement.asp >

Side 31:

"The receive window size defaults to a value calculated as follows:

The first connection request sent to a remote host advertises a receive
window size of 16 KB (16,384 bytes).

Upon establishing the connection, the receive window size is rounded up
to an increment of the maximum TCP segment size (MSS) that was negoti-
ated during connection setup.

If that is not at least four times the MSS, it is adjusted to 4 * MSS,
with a maximum size of 64 KB unless a window scaling option (RFC 1323)
is in effect.

For Ethernet, the window is normally set to 17,520 bytes (16 KB rounded up
to twelve 1460-byte segments.)"

...

"To improve performance on high-bandwidth, high-delay networks,
scalable windows support (RFC 1323) has been introduced in Windows
2000. This RFC details a method for supporting scalable windows by
allowing TCP to negotiate a scaling factor for the window size at
connection establishment. This allows for an actual receive window of
up to 1 gigabyte (GB)."

---

On Mon, 14 Jul 2003 11:17:24 +0200, Lars B. Dybdahl wrote:
>
>
> Jeg er godt klar over, at pakketab normalt er så lille, at det ikke betyder
> det store, og at ankomstrækkefølge ofte er så fornuftig, at forskellen
> mellem TCP og UDP ikke er uhyggelig stor, men f.eks. har jeg en god
> bekendt, som bor på Philippinerne, og de har en del af internet udbyderne
> ca. 15-20% pakketab ud af landet, og her betyder det en hel del, om en
> tabt, forældet pakke skal sendes igen, eller om man bare sender en ny med
> nyt indhold. Han administrerer i øvrigt en del Linux maskiner i Danmark
> vha. ssh og kunne godt tænke sig lidt mindre pakketab Her vil jeg
> påstå, at mere RAM i routerne kunne reducere pakketabet (på bekostning af
> latency, selvflg.), fordi jeg vurderer at den største trafikmængde kører
> TCP, og dermed får begrænset deres transmissionshastighed pga.
> vinduestørrelsen. UDP trafikken er mere udefinerbar.
>
Der kan være mange grunde til dette tab. (i tilfældig rækkefølge)
1) (Alt) for lille kapacitet på en linie.
1a) Man kan ikke forvente at andre traffiktyper end TCP vil throttle ved
pakketab.
2) For simple metode til at droppe pakker (tail drop)
3) Input drop pga buffermangel da buffere er hængt op andre steder.
4) For lille cpu kapacitet til til den valgte konfiguration/konfigurering.
5) Linier med fejl.


3) Kunne i princippet være løst med mere RAM men det var i det pågældende
tilælde ikke muligt da det var noget dedikeret RAM, der manglede. Og
routeren havde ikke CPU nok til at køre en mere fornuftig køalgoritme
mod den kunde, som overbelastede sin linie.

De øvrige problemer kan absolut ikke løses med RAM.

/hjj

---

Hans Jørgen Jakobsen wrote:
> De øvrige problemer kan absolut ikke løses med RAM.

I øvrigt er RAM ikke en fornuftig løsning på trafikproblemet her - det er
den indkommende trafikmængde, der skal styres.

Lars.

--
GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>Og grundlaget for det hele var, at jeg sagde, at tilbageholdelsen af data
>fra at ankomme til applikationen fordi rækkefølgen skulle bevares, var en
>tidsforsinkelse, som man ikke finder magen til i UDP. Hvilket du benægtede
>på et tidspunkt, og på et andet tidspunkt omtalte som var det et faktum.

Vi taler forbi hinanden. Så kan det ikke betale sig at diskutere.

Mvh.
   Klaus.

---

In article <3f125320$0$5137$edfadb0f@dread11.news.tele.dk>, Lars B. Dybdahl wrote:
>
>> Hvorfor skulle det specifikt gøre at TCP ikke oplever pakketab.
>
> Det samme gælder UDP. Men når man skal designe en router til at den ikke
> skal have pakketab, så giver det ikke meget mening at designe efter UDP
> trafik, da den kan opføre sig ret uforudsigeligt. De største routere er
> designet efter, hvordan store trafikmængder opfører sig, men mindre routere
> er da helt klart designet efter, at rimelige mængder TCP trafik ikke må
> give pakketab.

Hvis du skulle designe en router til ikke at give pakketab ville du give
den flere gigabyte buffer, det gør man ikke, ergo er routere ikke
designet til ikke at give pakketab. Routere er blot et redskab i en
netværksdesigners værktøjskasse, det må være op til ham at sikre at den
trafik hans netværk nu skal bære bliver overført på bedst mulige måde
(og det er ikke nødvendigvis kun minimalt pakketab der er det eneste
succeskriterie)

> F.eks. giver TDC's speedstream routere ikke pakketab, selv om man kobler
> flere PC'ere på og surfer løs. Men sætter man 60 PC'ere på, og surfer løs,
> knækker de fuldstændigt sammen og giver meget høje pakketab. Hvordan har
> Speedstream folkene regnet den ud? Jo, de har tænkt over, hvor kraftig
> routeren skal være for at holde til en vis mængde TCP belastning. De kan
> ikke regne det ud fra UDP belastning, da UDP per definition er udefineret
> mht. hvor stor routeren skal være

Øeh, nej? En IP-pakke er en IP-pakke for en router, den laver ikke
beregninger på hverken TCP eller UDP-sessioner (med mindre der
selvfølgelig er sat noget QoS op)

> Altså: Pakketabet er selvflg. det samme for UDP og TCP,

Ja. Som udgangspunkt.

> men TCP er mere anvendeligt når man skal lave deterministiske
> beregninger på routerkapacitet, hvis man ikke har trafikdata, det skal
> passe til.

Nej, overhovedet ikke, routerkapacitet måles i pakker per sekund, og det
er fuldstændig uden betydning om det er TCP og UDP (eller andre
protokoller, ESP og ICMP eksempelvis)

>> De behøver netop ikke at ankomme på samme måde, det er stakkens ansvar
>> at reorganisere dem.
>
> Vi snakker udelukkende om ankomst til applikationen - ikke IP pakkernes
> ankomst til protokolstakimplementationen.

Jeg gjorde ikke, og det ser heller ikke ud til at Klaus gjorde.

--
Andreas Plesner Jacobsen | Questionable day.
| Ask somebody something.

---

Andreas Plesner Jacobsen wrote:
> Hvis du skulle designe en router til ikke at give pakketab ville du give
> den flere gigabyte buffer, det gør man ikke, ergo er routere ikke
> designet til ikke at give pakketab.

Selvflg. vil du altid kunne give en router pakketab ved at belaste den godt
nok. Men mener du at en router ikke er designet kapacitetsmæssigt til det
formål, den skal bruges? Og mener du ikke at pakketab under normalt brug er
uønsket? Alle de routere, jeg har oplevet, giver ikke pakketab ved
almindelig brug. Det kan umuligt være tilfældigt.

> En IP-pakke er en IP-pakke for en router, den laver ikke
> beregninger på hverken TCP eller UDP-sessioner (med mindre der
> selvfølgelig er sat noget QoS op)

Helt enig. Men som produktionsingeniør ville jeg personligt da helt klart
prøve at beregne, hvordan jeg kan opnå best mulig trafikhåndtering hos
kunden, inden jeg sætter en produktion af 100.000 routere i gang. Hvordan
ville du regne det ud?

>> men TCP er mere anvendeligt når man skal lave deterministiske
>> beregninger på routerkapacitet, hvis man ikke har trafikdata, det skal
>> passe til.
> Nej, overhovedet ikke, routerkapacitet måles i pakker per sekund, og det
> er fuldstændig uden betydning om det er TCP og UDP (eller andre
> protokoller, ESP og ICMP eksempelvis)

Igen - hvordan ville du beregne den nødvendige kapacitet i en router, hvis
du f.eks. skulle vinde licitationen om at levere routere til TDC ADSL?

>> Vi snakker udelukkende om ankomst til applikationen - ikke IP pakkernes
>> ankomst til protokolstakimplementationen.
> Jeg gjorde ikke, og det ser heller ikke ud til at Klaus gjorde.

Så læser I ikke hvad jeg skriver.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

In article <3f125f74$0$5171$edfadb0f@dread11.news.tele.dk>, Lars B. Dybdahl wrote:

>> Hvis du skulle designe en router til ikke at give pakketab ville du give
>> den flere gigabyte buffer, det gør man ikke, ergo er routere ikke
>> designet til ikke at give pakketab.
>
> Selvflg. vil du altid kunne give en router pakketab ved at belaste den godt
> nok. Men mener du at en router ikke er designet kapacitetsmæssigt til det
> formål, den skal bruges? Og mener du ikke at pakketab under normalt brug er
> uønsket? Alle de routere, jeg har oplevet, giver ikke pakketab ved
> almindelig brug. Det kan umuligt være tilfældigt.

Som jeg skrev: Man ville proppe tonsvis af ram i en router, hvis man
ville sikre at den ikke tabte pakker (så kunne den holde på dem indtil
interfacet var ledigt) - det gør man ikke, for så virker
feedback-mekanismerne i tcp og venner ikke, og multimedia-streams bliver
fyldt med jitter og forsinkelser, da pakkerne først ankommer når de er
ubrugelige.

>> En IP-pakke er en IP-pakke for en router, den laver ikke
>> beregninger på hverken TCP eller UDP-sessioner (med mindre der
>> selvfølgelig er sat noget QoS op)
>
> Helt enig. Men som produktionsingeniør ville jeg personligt da helt klart
> prøve at beregne, hvordan jeg kan opnå best mulig trafikhåndtering hos
> kunden, inden jeg sætter en produktion af 100.000 routere i gang. Hvordan
> ville du regne det ud?

Hvordan ville du finde ud af, hvilke trafiktyper TDCs 100k kunder har?

>>> men TCP er mere anvendeligt når man skal lave deterministiske
>>> beregninger på routerkapacitet, hvis man ikke har trafikdata, det skal
>>> passe til.
>> Nej, overhovedet ikke, routerkapacitet måles i pakker per sekund, og det
>> er fuldstændig uden betydning om det er TCP og UDP (eller andre
>> protokoller, ESP og ICMP eksempelvis)
>
> Igen - hvordan ville du beregne den nødvendige kapacitet i en router, hvis
> du f.eks. skulle vinde licitationen om at levere routere til TDC ADSL?

Det gør man som regel med målinger ved pakker med forskellige
pakkestørrelser. Det tal man opgiver er som regel pps ved 64-byte
pakker.

>>> Vi snakker udelukkende om ankomst til applikationen - ikke IP pakkernes
>>> ankomst til protokolstakimplementationen.
>> Jeg gjorde ikke, og det ser heller ikke ud til at Klaus gjorde.
>
> Så læser I ikke hvad jeg skriver.

Eller også skriver du ikke hvad du mener.

--
Andreas Plesner Jacobsen | I owe the public nothing.
|    -- J.P. Morgan

---

Andreas Plesner Jacobsen wrote:
> Som jeg skrev: Man ville proppe tonsvis af ram i en router, hvis man
> ville sikre at den ikke tabte pakker (så kunne den holde på dem indtil
> interfacet var ledigt) - det gør man ikke, for så virker
> feedback-mekanismerne i tcp og venner ikke, og multimedia-streams bliver
> fyldt med jitter og forsinkelser, da pakkerne først ankommer når de er
> ubrugelige.

Enig.

> Hvordan ville du finde ud af, hvilke trafiktyper TDCs 100k kunder har?

Jeg ville lave nogle standard profiler og teste op imod dem. En typisk
standard profil ville være en person, der e-mailer og browser. Her er der
tale om ganske få TCP forbindelser. En anden profil ville være en bruger
med flere computere, koblet sammen i netværk, med forskellige services
kørende. Her ville jeg muligvis spørge markedsføringsafdelingen, om
almindelige, gængse P2P filsharing programmer bør køre fornuftigt eller ej
- især udenlandske ISP'ere har det med at være meget sure hvis kunderne
bruger P2P programmer.

> Det gør man som regel med målinger ved pakker med forskellige
> pakkestørrelser. Det tal man opgiver er som regel pps ved 64-byte
> pakker.

Den slags kan man kun bruge, hvis man har en ide om, hvor stor pakker man
vil putte igennem - med andre ord hvis man har lidt kendskab til ens
trafik. Og det er det, jeg mente med "designet til trafik".

>>>> Vi snakker udelukkende om ankomst til applikationen - ikke IP pakkernes
>>>> ankomst til protokolstakimplementationen.
>>> Jeg gjorde ikke, og det ser heller ikke ud til at Klaus gjorde.
>> Så læser I ikke hvad jeg skriver.
> Eller også skriver du ikke hvad du mener.

Jeg kan citere mig selv et par gange, hvor det burde gå ret tydeligt frem,
at tiden i protokolstakken skal medregnes:

> da kryptering tilføjer latency

> Forsinkelse bør måles fra input af ukrypterede data indtil data bliver
> vist hos brugeren.

> I øvrigt så er en pakning af data også noget, der øger latency i alle dele
> bortset fra selve transmissionsdelen.

> en 486 vil typisk bare forsinke videosignalet nok til at det virker, dvs.
> øge latency

> Og selv om man har en hurtig processor, så vil hver 1600 CPU clocks i
> håndteringen af en pakke medføre en ekstra latency på 1ms for en 1,6GHz
> processor.

> Pakning kan også øge latency

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

Andreas Plesner Jacobsen wrote:

> Som jeg skrev: Man ville proppe tonsvis af ram i en router, hvis man
> ville sikre at den ikke tabte pakker (så kunne den holde på dem indtil
> interfacet var ledigt) - det gør man ikke, for så virker
> feedback-mekanismerne i tcp og venner ikke, og multimedia-streams bliver
> fyldt med jitter og forsinkelser, da pakkerne først ankommer når de er
> ubrugelige.

Jeg er da rimeligt sikker på at TCP reagerer på delay og jitter.

--
Hroi, som sikkert er totalt ude af kontekst

---

Hroi Sigurdsson <hroi@asdf.dkk> writes:

>Jeg er da rimeligt sikker på at TCP reagerer på delay og jitter.

Det er netop det, Andreas skriver

Mvh.
   Klaus.

---

In article <3f158f41$0$2691$7bd3bdf7@nntp03>, Hroi Sigurdsson wrote:
>
>> Som jeg skrev: Man ville proppe tonsvis af ram i en router, hvis man
>> ville sikre at den ikke tabte pakker (så kunne den holde på dem indtil
>> interfacet var ledigt) - det gør man ikke, for så virker
>> feedback-mekanismerne i tcp og venner ikke, og multimedia-streams bliver
>> fyldt med jitter og forsinkelser, da pakkerne først ankommer når de er
>> ubrugelige.
>
> Jeg er da rimeligt sikker på at TCP reagerer på delay og jitter.

Hvor tit er multimedia-streams TCP? ;)

--
Andreas Plesner Jacobsen | To refuse praise is to seek praise twice.

---

Andreas Plesner Jacobsen wrote:
> Hvor tit er multimedia-streams TCP? ;)

Som regel... eftersom at de fleste bredbåndsbrugere ikke kan modtage UDP
streams.

Lars.

--
GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>> Hvor tit er multimedia-streams TCP? ;)

>Som regel... eftersom at de fleste bredbåndsbrugere ikke kan modtage UDP
>streams.

TDC sidder på næsten hele markedet for bredbånd i Danmark, og der
er ikke nogen problemer med TDCs løsninger og UDP-streaming. Dog
er visse protokoller skrevet så ringe, at de ikke kan NATes, men
det er bagateller i den store helhed.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> TDC sidder på næsten hele markedet for bredbånd i Danmark, og der
> er ikke nogen problemer med TDCs løsninger og UDP-streaming. Dog
> er visse protokoller skrevet så ringe, at de ikke kan NATes, men
> det er bagateller i den store helhed.

Kan du give et link til info om, hvilke krav en UDP stream skal opfylde, for
at den kan køre igennem en Speedstream router? Nu kører jeg selv Zyxel på
min hjemme-ADSL, så jeg har ikke gode erfaringer med UDP udover hvis jeg
udpeger en port til at pege på en bestemt intern IP adresse.

Lars.

--
GnuPG nøgle: http://dybdahl.dk/lars/gpg/

---

"Lars B. Dybdahl" <Lars@dybdahl.dk> writes:

>> TDC sidder på næsten hele markedet for bredbånd i Danmark, og der
>> er ikke nogen problemer med TDCs løsninger og UDP-streaming. Dog
>> er visse protokoller skrevet så ringe, at de ikke kan NATes, men
>> det er bagateller i den store helhed.

>Kan du give et link til info om, hvilke krav en UDP stream skal opfylde, for
>at den kan køre igennem en Speedstream router?

Nej, jeg kender ikke produktet. Men der er intet problem i at køre
UDP-encapsulated VPN, når jeg er på besøg hos folk med en standard
TDC-løsning med Speedstream-router. Samme folk har ingen problemer
med spil og deslige.

Mvh.
   Klaus.

---

On Sun, 13 Jul 2003 23:15:39 +0200, "Lars B. Dybdahl"
<Lars@dybdahl.dk> wrote:

> Serialization er et begreb, der dækker processen at lade et objekt streame
> sine data, dvs. skrive sine data til et objekt uden random access på en
> måde, så objektet kan regenereres ud fra disse data. Hvis du har en anden
> definition, så har du læst en anden bog, og så er begrebet ikke entydigt.

Den mest almindelige brug af 'serialization delay' i datakommuni-
kation er den tid det tager L3-udstyr at transmittere en given
datamængde på et givent medie. Det kaldes serialisering, fordi
udstyret egentlig behandler pakker men sender dem i et bitstrøms-
medie.

Der er sikkert andre anvendelser af ordet, især i andre sammen-
hænge[1], men ovenstående er i min erfaring[2] altså ubetinget
den mest anvendte, og det ser ud til at passe meget godt med,
hvad Klaus mener.

Som sædvanlig skal man læse i kontext, og lige her var den altså
datakommunikation, og så er det ret entydigt.

-A
[1] Jeg kan se, at du refererer til objekter, hvor det rigtig nok
bruges lidt anderledes.
[2] Jeg hørte det første gang, i den betydning, for 15+ år siden.
--
http://www.hojmark.org/

---

"Morton Christiansen" <morton@it.edu> wrote in message
news:7DJPa.17050$Kb2.873666@news010.worldonline.dk...
> Hej gruppe.
>
> Nogen der har et indtryk af sikkerheden overordnet set i streaming
> protokoller? Vil det f.eks. uden videre være muligt at kapre sådan en
> "forbindelse" (pakkestrøm) ved at lukke af for afsenderens pakker, og
f.eks.
> indsætte sine egne nyheder i stedet for CNNs...?! Eller anvendes en
eller
> anden form for authentifikation, f.eks. kryptering?

Da man andetsteds i tråden er gået agurk med latenstider, vil jeg her
være så kedelig at komme med nogle tider der stammer fra et faktisk
fungerende system:

downsampler: 1,9 ms (15 samples @ 8kHz)
Sample block: 15,6 ms (125 samples @ 8kHz)
**Hash: 20 uS (126 byte @ 6MB/s)
**Krypt: 21 uS (128 byte @ 6MB/sek)
pakken er herefter 128 byte + 8 UDP + 20 IP + 14 ethernet = 170
De 3 byte er sekvensnummer-lsb (8 bit) samt 2 byte hash. Dette kan synes
lidt, men giver god nok sandsynlighed for at afsløre fusk.
Det pakkes i 3,5 ATM celler, 212 byte på linjen = 13560 byte/sek, ok.
212 bytes på 128k upstream: 1,7 ms
transmission: 6 ms
212 bytes på 256k downstream: 0,8 ms
**Krypt: 21 uS (128 byte @ 6MB/sek)
**Hash: 20 uS (126 byte @ 6MB/s)
Jitter buffer: 5 ms
upsampler: 1,9 ms
-------
total 33 ms

(ovenstående er hugget fra min notefil, der kan være fejl i den. Hash er
MD5, krypt er Blowfish)

Som det ses udgør krypt/hash 0,3% af tiden, det er målt mellem to K6-233
maskiner.
Som det også kan ses kommer halvdelen af forsinkelsen fra, at jeg ikke
kan sende en pakke før jeg har dataene
Så jeg vil da håbe folk tilføjer et sikkerhedslag. Nogen vil sikkert
undlade det, men så er begrundelsen enten at de er dovne, eller at
serveren ikke har overskud til at foretage RSA eller DH, ikke at det
tilføjer for megen forsinkelse

/Kasper

---

Kasper Pedersen wrote:
> Så jeg vil da håbe folk tilføjer et sikkerhedslag. Nogen vil sikkert
> undlade det, men så er begrundelsen enten at de er dovne, eller at
> serveren ikke har overskud til at foretage RSA eller DH, ikke at det
> tilføjer for megen forsinkelse

Enig - det sidste gav jeg også Klaus ret i.

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

GnuPG nøgle: http://dybdahl.dk/lars/gpg/