Partilhar via


IP Stacken og Autotuning

Kapittel fire om den nye IP Stacken... Som nevnt tidligere tenkte jeg å skrive om autotuning i den nye IP Stacken, det som totalt sett kanskje er den beste forbedring for "folk flest".

Begreper

Receive window (TCP) = Antall bytes i en minnebuffer som brukes til å motta innkommende data. Dette tallet blir gjort kjent for mottaker jevnlig, pr TCP segment. Å gjøre gjenværende plass i bufferet kjent for senderen er en mottaksside trafikkontroll funksjon, for å sikre at man ikke mottar mer data enn det som kan behandles/buffres. 

Bandwidth-delay product = Båndbredde ganget med round-trip tid

Application-rate =   I denne sammenheng: hvor fort en applikasjon kan ta imot data

RTT = Round-trip time

CTCP = Compund TCP

 

Litt historikk og bakgrunn
Når det gjelder XP og 2003 har de et statisk receive window som er basert på link-speed for det interface som benyttes. Dette kan konfigureres manuellt i registry, men man oppnår ikke mer dynamisk tilpassning av den grunn, kun en annen statisk grense.

For å senke/heve senderaten bruker XP kun data om hvor mange pakker som går tapt. Og et tap regnes som et sikkert tap uansett om RTT har gått opp midlertidig. XP senker da resolutt bruken av båndbredde og starter å sende pakker på nytt. Så forsøker XP gradvis å ta i bruk mer båndbredde igjen. (øker senderaten med ett TCP Segment pr bekreftede segment)

Problemet her er at det ikke varieres på mottagssiden med endrede nettverksforhold og at man på sendesiden ikke utnytter tilgjenglig båndbredde effektivt. Det var/er fint i miljøer med lite båndbredde (og lite delay), men fungerer ikke fullt så bra under de forholdene som blir mer og mer vanlige idag.

 

Håndtering i Windows Vista

Som sagt mange ganger allerede, Vista har en ny IP Stack og denne håndterer selvsagt denne utfordringen bedre og. I IP Stacken på Windows Vista blir nettverkstrafikken monitorert til enhver tid. Som nevnt tidligere vil f.eks. TCP Resend trigge en sjekk av default gateway sin tilstand. Windows Vista vil til enhver tid kalkulere den mest passende verdien for receive-window basert på to ting:

  • Bandwidth-delay product
  • Application receive rate

Dette gjør at Windows Vista tilpasser seg bedre på mottakssiden, kan bruke mer av båndbredden som er tilgjenglig / kan øke hastigheten for mottak av data.

 

Det var på mottakssiden, det må også gjøres litt på sendersiden for å utnytte det større/tilpassede receive-window. Dette gjøres ved å ta i bruk CTCP. CTCP øker mer aggresivt senderaten for tilkoblinger med stort receive-window eller bandwidth-delay produkt. CTCP bruker ellers vanlig pakketapsmonitorering, men også monitorering av variasjoner i forsinkelse (delay).

Den nye stacken er også raskere til å komme seg ut av retransmission-modus og er raskere til å ta i bruk mer båndbredde igjen.

 

Konklusjon/resultat

Resultatet blir at Windows Vista tar i bruk tilgjenglig båndbredde mye mer effektivt, tester viser en økning med 2-3 ganger bedre overføring mot en Windows 2003 server. En Longhorn server bruker samme IP Stack som Vista og kan dermed forventes å gi bedre overføring. Det er også en oppdatering for 2003 server for at denne skal fungere bedre sammen med Vista IP Stack, ikke påkrevd, men gir bedre hastighet. Selvsagt avhenging av hvordan resten av nettet er lagt opp.

QoS blir kanskje mer aktuellt for enkelte også, når mer bånbredde blir brukt vil man kanskje se et behov for å prioritere hvem/hva som bruker den. Den nye IP Stacken vil faktisk også gi en viss prioritering på klienten og ikke bare ute i nettet.

 

Mer info på Technet

 

Det neste jeg skal skrive om rundt IP Stack her blir forbedringer rundt trådløst. Antagelig til uka en gang. Også tenkt å få skrevet litt om nye Deployment løsninger og teknologi snart.