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 :
 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 : "...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  og Enabling Dynamic Buffer Limiting . Har andre firmer noget tilsvarende?

Se også 
 Datanet servicekvalitet, Traffic shaping, Multilayer switch.

Eksterne henvisninger 
 Sally Floyd: RED (Random Early Detection) Queue Management
 April 1998, RFC2309: Recommendations on Queue Management and Congestion Avoidance in the Internet , Original RFC2309
 RFC2001: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms , Original RFC2001
 TCP Congestion Control , Original RFC2581
 TCP Increasing TCP's Initial Window , Original RFC3390
 The Addition of Explicit Congestion Notification (ECN) to IP , Original RFC3168
 Linktionary term: Queuing
 Sally Floyd, Ratul Mahajan, David Wetherall: RED-PD: RED with Preferential Dropping

Datanet
Telekommunikation