Undgåelse af datanet-trafikforstoppelse

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

Følgende fordele kommer fra IETF's April 1998, RFC2309: Recommendations on Queue Management and Congestion Avoidance in the Internet Arkiveret 3. april 2003 hos Wayback Machine:

  • Der tabes færre datapakker end uden Active Queue Management (AQM).
  • Dataforbindelsen fyldes bedre ud, da muligheden for TCP global synchronization reduceres.
  • Datapakke forsinkelse (eng. delay) og forsinkelsesvariation (eng. jitter) minskes.
  • Dataforbindelsens portkøs garanterede båndbredde fordeles mere ligeligt mellem forbindelsesorienterede flows (selv uden flowbased- RED, WRED).

Forstoppelsesårsager

TCP/IP congestion avoidance synkronisering og TCP/IP genoptræning

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

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 Arkiveret 10. marts 2005 hos Wayback Machine: "...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

RED og WRED

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

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

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)

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 Arkiveret 21. august 2008 hos Wayback Machine og Enabling Dynamic Buffer Limiting Arkiveret 21. august 2008 hos Wayback Machine. Har andre firmer noget tilsvarende?

Se også

Eksterne henvisninger