Undgåelse af datanet-trafikforstoppelse

Fra Wikipedia, den frie encyklopædi
Gå til: navigation, søg

Datanet-trafikforstoppelse er når netkort, netudstyr eller værters (en. hosts) portkøer bliver fyldt op og normalt "løber over" (datapakkerne tabes, "slettes"). Dette resulterer i forsinkelse og forsinkelsesvariation for forbindelsesorienterede flows (f.eks. tcp), da der først går et lille stykke tid før det "konkluderes" at en given pakke er tabt og en kopi genfremsendes. Da kopien bliver sendt et lille stykke senere, er dette ophave til forbindelsesorienterede flows pakkers forsinkelse og forsinkelsesvariation.

Undgåelse af datanet-trafikforstoppelse opnås ved at sørge for, at portkøerne forbliver mindre fyldt, midlet over 1 sekund. Dette kaldes Active Queue Management (AQM). Det hjælper ikke at lave ultrakorte køer, da det blot vil gøre, at de endnu lettere løber over. Portkøerne skal have en vis længde for at absorbere mindre "pakkebølger" (en. bursts). Dette gælder især trafik, som bliver forsinket mere end 0,5 sekund pga. afstanden mellem f.eks. USA, Asien eller Japan – og Danmark.

Dette at signalere til de 2 værter, der kommunikerer sammen, ved enten at slette datapakker eller signalere eksplicit (ECN, Explicit Congestion Notification) via datapakkens 2 ECN-bits i DS field, der ellers ville have været slettet, får værterne til at skrue sendehastigheden lidt ned i den givne trafikretning.

Fordele ved Active Queue Management[redigér | redigér wikikode]

Følgende fordele kommer fra IETF's April 1998, RFC2309: Recommendations on Queue Management and Congestion Avoidance in the Internet:

Forstoppelsesårsager[redigér | redigér wikikode]

TCP/IP congestion avoidance synkronisering og TCP/IP genoptræning[redigér | redigér wikikode]

Forbindelsesorienterede flows, f.eks. TCP, måler på/registrerer fejl, tab og forsinkelse, og justerer sendehastigheden efter forholdene.

TCP's automatiske congestion avoidance og TCP/IP genoptræning giver dog problemer, når mange samtidige TCP-flows får slettet datapakker ved port kø tail-drop (eng. queue tail-drop). Alle flows, der oplever port kø tail-drop, vil starte en TCP genoptræning samtidigt (eng. TCP global synchronization).

Andre årsager[redigér | redigér wikikode]

Logiske (software) og fysiske (hardware) flaskehalse:

  • Netudstyr der ikke kan formidle/processere datapakkerne hurtigt nok. Dette forårsager overløb af en indgående port kø.
  • Netudstyr der ikke kan afsætte datapakkerne hurtigt nok. Dette forårsager overløb af en udgående port kø. Herunder:
    • halv dupleks (eng. half duplex) – link kollisionerne forårsager forsinkelsesvariationer (eng. jitter), fordi portens portkøers pakker forsinkes for hver kollision med backoff-tiden.
    • Port kø "flow"-control IEEE 802.3x er slået til, hvilket også forårsager forsinkelsesvariationer (eng. jitter), fordi portens portkøers pakker forsinkes. (kilde: "...Hewlett-Packard points out that quality of service is a better way to handle potential congestion, and Cabletron and Nortel note that QoS features can't operate properly if a switch sends [faktisk reagerer på IEEE 802.3x] pause frames....")

Teknologiske løsninger[redigér | redigér wikikode]

RED og WRED[redigér | redigér wikikode]

En løsning er anvendelsen af RED (eng. Random Early Detection eller Random Early Discard) på netudstyrs port køen. På netudstyr med flere port køer bør WRED (eng. Weighted Random Early Detection) anvendes. RED signalerer indirekte til sender og modtager ved at slette få tilfældigt udvalgte datapakker, f.eks. når port køens gennemsnitlige længde er over 50% fyldt og efter en eller anden kurve slette flere og flere pakker, når den gennemsnitlige kølængde nærmer sig 100%. port køens gennemsnitslængde beregnes over ca. 1 sek.

Resultatet af de "tilfældigt" slettede datapakker er, at TCP/IP skruer ned for sendehastigheden, når den oplever tilstrækkelig med tab. P2P anvender f.eks. FTP, som også anvender TCP/IP.

Andre flows registrerer tabene på anden vis.

IP-telefoni (VoIP) kan kun tåle mindre pakketab, ellers kommer der udfald i lyden og derfor skal denne trafiktype have højere QoS f.eks. ved at placere VoIP trafik i en højere prioriteret og kortere portkø.

IP ECN[redigér | redigér wikikode]

En endnu bedre måde er anvendelse af IP ECN (eng. Explicit Congestion Notification). IP ECN kræver, at de to hosts signalerer, at de respekterer ECN. Med denne metode sættes en ECN bit i de få tilfældigt udvalgte datapakker, der med RED/WRED algoritmen skulle have været slettet.

flowbased-RED/WRED[redigér | redigér wikikode]

Noget netudstyr er udstyret med porte, der kan følge med i hver enkelt flow (flowbased-RED/WRED) og kan derfor signalere til de flows, der fylder for mange pakker i køen eller fylder for meget i båndbredde. Fordelen med flowbased-RED/WRED er, at båndbredden fordeles ligeligt mellem alle flows.

Cisco AQM: Dynamic buffer limiting (DBL)[redigér | redigér wikikode]

Firmaet Cisco er gået skridtet videre og har, bl.a. i deres Catalyst 4000 serie med engine IV og V mulighed for at klassificere alle forbindelsesorienterede flows i "aggressive" (dårlige) og "adaptive" (gode). I reeltid sørger engine IV og V for, at ingen flows fylder portkøerne op over længere tid. DBL kan benytte IP ECN i stedet for pakketabssignalering. Se afsnittene i: Active Queue Management og Enabling Dynamic Buffer Limiting. Har andre firmer noget tilsvarende?

Se også[redigér | redigér wikikode]

Eksterne henvisninger[redigér | redigér wikikode]