Forum Ljud, bild och kommunikation Nätverk och uppkoppling Tråd Inlägg

TCP slow start och fast retransmit

1
Skriv svar
Permalänk
Medlem
●

TCP slow start och fast retransmit

Hej!

Skulle behöva hjälp att förstå hur tcp slow start och fast retransmit hanterar packet losses. Om jag har att tcp implementerar fast retransmit, har en sstresh som är 8 från början, en timeout period på 300ms och att paket 3 är lost. Då ritade jag såhär:

Är det rätt? Jag tänker att cwnd ökas med 1 för varje ACK så har skrivit det till vänster där. Fast retransmit är ju att efter 3 duplicate ACK vet den att något är lost, så då retransmittar den paket 3 där och kör på de andra direkt efter eftersom de inte blev ACKade. Sen efter timeout periioden sätter jag cwnd till 1 och ökar den med 1 varje gång jag skickar nya paket bara. Är det rätt tänkt? Det jag är högst osäker på är hur många paket som skickas i slutet av timeouten där, har 5 just nu där. Kan säga att B är servern och A klienten men det kanske är uppenbart.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem
●

Det enda jag kan tänka mig inte stämmer är att den inte skickar ett ACK för varje paket, utan att den skickar ett ACK per window size. Så om 5 paket ingår i en window size och kommer fram hela och fina, svaras med en ACK för hela window sizen, där ACK har seq numret för paket5 + 1.

Om paket 3 av 1-5 inte kom fram, kommer mottagare skicka ett ACK att den tagit emot fram till och med paket2, för att visa att paket1 och 2 kom fram, men att efter dem blev det kaoz. Window size kommer då halveras och nya packet från paket3 och framåt skickas ut.

Jag är dock rostig på min TCP, så jag kan ha fel.

Visa signatur

CCNP R/S + SPCOR, NSE7 (emeritus)

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Jag tror att Vipers är inne på rätt spår. Därför finns även Selective ACK som en TCP option. I det fallet ACKar man de paket som kommit fram och inte hela window size. Nackdelen med att ACKa hela window size är att om det första av tio paket kommit fram måste samtliga skickas om. Vid Selective ACK kan man alltså slippa skicka om paket 2-10 som kommit fram korrekt.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av vipers:

Det enda jag kan tänka mig inte stämmer är att den inte skickar ett ACK för varje paket, utan att den skickar ett ACK per window size. Så om 5 paket ingår i en window size och kommer fram hela och fina, svaras med en ACK för hela window sizen, där ACK har seq numret för paket5 + 1.

Om paket 3 av 1-5 inte kom fram, kommer mottagare skicka ett ACK att den tagit emot fram till och med paket2, för att visa att paket1 och 2 kom fram, men att efter dem blev det kaoz. Window size kommer då halveras och nya packet från paket3 och framåt skickas ut.

Jag är dock rostig på min TCP, så jag kan ha fel.

Gå till inlägget
Skrivet av Talisker00:

Jag tror att Vipers är inne på rätt spår. Därför finns även Selective ACK som en TCP option. I det fallet ACKar man de paket som kommit fram och inte hela window size. Nackdelen med att ACKa hela window size är att om det första av tio paket kommit fram måste samtliga skickas om. Vid Selective ACK kan man alltså slippa skicka om paket 2-10 som kommit fram korrekt.

Gå till inlägget

Googlade lite mer och tror jag fått till rätt nu här:

Antar att jag använder TCP reno här. Då ökas cwnd exponentiellt i början eftersom det är slow start. Sen efter massa duplicate acks är den kvar vid 4, då den bara ökar för varje non-duplicate ACK. Då retransmittar jag 4 paket där(ska inte vara 5 som jag ritat såg jag nu). Sen sätts sstresh till cwnd/2=8/4=2 och cwnd sätts till hälften av tidigare cwnd värdet.

Någon som kan bekräfta om jag tänker rätt och har rätt?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Det låter rätt men var ett bra tag sen jag gjorde CCNA grejer. Men tänker man på förr i tiden när folk hade modem(inte adsl) så kunde man se t.ex att hastigheten började på typ 3kb/s och sedan räknade upp till 5kb/s pga just det du förklarar när man laddade ned. Men idag med höga hastigheter så är det oftast ingenting man ser.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●

Försöker du beskriva detta rent teoretisk eller försöker du förstå dig på beteende hos en existerande implementation som du sniffat trafiken för?

Frågar då nyare specifikationer (RFC5681) kommer använda ett cwnd på 3 om du kör med normal MTU på 1500.

Även om det är en väldigt gammal implementation (1999, RFC2581) så kommer cwnd typiskt starta på 2.

I den specifikation när initial cwnd var ett 1 är från 1997, RFC2001.

Annars ser det helt rätt ut. Saker som faktiskt congestion-algoritm styr vad ssthresh och vad man sätter cwnd till när man tror att något tappats, finns en lång rad sådan men Reno och "new" Reno är väldigt vanliga.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av VexedRelic:

Det låter rätt men var ett bra tag sen jag gjorde CCNA grejer. Men tänker man på förr i tiden när folk hade modem(inte adsl) så kunde man se t.ex att hastigheten började på typ 3kb/s och sedan räknade upp till 5kb/s pga just det du förklarar när man laddade ned. Men idag med höga hastigheter så är det oftast ingenting man ser.

Gå till inlägget
Skrivet av Yoshman:

Försöker du beskriva detta rent teoretisk eller försöker du förstå dig på beteende hos en existerande implementation som du sniffat trafiken för?

Frågar då nyare specifikationer (RFC5681) kommer använda ett cwnd på 3 om du kör med normal MTU på 1500.

Även om det är en väldigt gammal implementation (1999, RFC2581) så kommer cwnd typiskt starta på 2.

I den specifikation när initial cwnd var ett 1 är från 1997, RFC2001.

Annars ser det helt rätt ut. Saker som faktiskt congestion-algoritm styr vad ssthresh och vad man sätter cwnd till när man tror att något tappats, finns en lång rad sådan men Reno och "new" Reno är väldigt vanliga.

Gå till inlägget

Okej tack! Alltså är en uppgift där man ska rita upp hur slow starten ser ut, och man får vilket packet som tappas, sstresh och hur många payload paket som ska skickas totalt och att den ska använda fast retransmit. Så har en likadan uppgift typ med andra siffor som ser ut såhär: http://puu.sh/gIsgp/30f5ae1164.png

Bara för att dubbelkolla så att jag verkligen förstår, är detta rätt för de där siffrorna man får där? Har inte ritat upp de sista paketen och teardown men hade inte plats men den ökar cwnd med 1 i slutet bara.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●

Ok, så det är ett segment som initial cwnd + ursprungliga Reno (verkar rimligt i en uppgift för att förenkla).

Ser helt rätt ut med reservation för att jag inte är helt med på hur du definierar paket 3 i din första post: "paket 3 är lost".

Vid förlust av paket sätter man ssthresh till halva cwnd när paketet förlorades, vilket du gjort (men är som sagt inte helt med på vilket som är paket 3, är det paket 3 i den "bursten"?). Sedan är det slow-start upp till cwnd når ssthresh.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Ok, så det är ett segment som initial cwnd + ursprungliga Reno (verkar rimligt i en uppgift för att förenkla).

Ser helt rätt ut med reservation för att jag inte är helt med på hur du definierar paket 3 i din första post: "paket 3 är lost".

Vid förlust av paket sätter man ssthresh till halva cwnd när paketet förlorades, vilket du gjort (men är som sagt inte helt med på vilket som är paket 3, är det paket 3 i den "bursten"?). Sedan är det slow-start upp till cwnd når ssthresh.

Gå till inlägget

På min första post så är det paket 3 som tappas bort. Då kommer man sen köra fast retransmit på den och då märker sändaren efter 3 duplicate ACK att något har gått fel, då retransmittar den. Så i uppgiften får man att paket 3 tappas bort, sen får man rita upp hur konsekvensen av det blir liksom.

För en annan kompis sade att efter timeouten sätts cwnd till halva cwnd som den var tidigare, och sen ökar cwnd bara med 1 eftersom det då är congestion avoidance. Så är nog inte slow start igen efter fast retransmit.

Redigera
Citera flera Citera
1
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara