SE514313C2 - Förbättringar av, eller med avseende på, datapaketförmedling - Google Patents

Förbättringar av, eller med avseende på, datapaketförmedling

Info

Publication number
SE514313C2
SE514313C2 SE9901236A SE9901236A SE514313C2 SE 514313 C2 SE514313 C2 SE 514313C2 SE 9901236 A SE9901236 A SE 9901236A SE 9901236 A SE9901236 A SE 9901236A SE 514313 C2 SE514313 C2 SE 514313C2
Authority
SE
Sweden
Prior art keywords
drop
precedence
profile
levels
max
Prior art date
Application number
SE9901236A
Other languages
English (en)
Other versions
SE9901236L (sv
SE9901236D0 (sv
Inventor
Ulf Bodin
Original Assignee
Telia Ab
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telia Ab filed Critical Telia Ab
Priority to SE9901236A priority Critical patent/SE514313C2/sv
Publication of SE9901236D0 publication Critical patent/SE9901236D0/sv
Priority to AT00919246T priority patent/ATE477645T1/de
Priority to EEP200100523A priority patent/EE04980B1/xx
Priority to PCT/SE2000/000665 priority patent/WO2000060817A1/en
Priority to EP00919246A priority patent/EP1171977B1/en
Priority to DK00919246.9T priority patent/DK1171977T3/da
Priority to US09/926,280 priority patent/US7139281B1/en
Priority to ES00919246T priority patent/ES2349159T3/es
Priority to DE60044805T priority patent/DE60044805D1/de
Publication of SE9901236L publication Critical patent/SE9901236L/sv
Publication of SE514313C2 publication Critical patent/SE514313C2/sv
Priority to NO20014498A priority patent/NO332566B1/no

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q11/00Selecting arrangements for multiplex systems
    • H04Q11/04Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0421Circuit arrangements therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/29Flow control; Congestion control using a combination of thresholds
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/30Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13103Memory
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13164Traffic (registration, measurement,...)
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13166Fault prevention
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13174Data transmission, file transfer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196Connection circuit/link/trunk/junction, bridge, router, gateway
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389LAN, internet

Description

20 25 30 35 514 313 2 finns inkluderad i ”the Assured Forwarding (AF) per-hop behaviour (PHB) group", se: (1998), Assured Forwarding PHB november 1998.
- Hainanen J. et al.
Group, IETF DRAFT, AF kan användas för att erbjuda differentiering bland ”rate”-anpassningsbara applikationer som reagerar på t.ex. applikationer som använder TCP. förlust av datapaket, Trafiken för varje användare märkes (tagged) som inom, eller utanför, deras tjänsteprofiler. Paket märkta som inom profil tilldelas en lägre förlustpreferens (drop precedence) än de som är märkta som utanför profil.
Dessutom kan ett paket inom en användares profil märkas med en av ett flertal ”drop precedence”-nivåer. För närvarande finns tre ”drop precedence”-nivåer för AF PHB-gruppen.
Ett flertal ”drop precedence”-nivåer kan skapas med en aktiv köhanteringsteknik (AQM) En fördelaktig egenskap hos FIFO-köer är att paket sänds i som tillämpas på en FIFO-kö. samma ordning som de anländer. Sålunda undviks återställande av ordning (reordering) av paket, vilket kan minska prestandan hos en TCP-förbindelse. Dessutom är FIFO- köer lämpliga för höghastighetslänkar eftersom de kan implementeras effektivt.
Två kända AQM-tekniker är RIO, se: - Clark D. och Fang W. (1997), Allocation of Best Effort Delivery Service, Explicit 1997, och WRED, se: Technical Specification from Cisco (1998), Distributed Weighted Random Early Detection; 1998, 10 20 25 30 514 315 3 Normalt styrs prioriterad trafik, som kommer in i ett nätverk, för att undvika överbelastning. När sådan trafik styrs på lämpligt sätt finner man att RIO och WRED erbjuder en absolut kvantifierbar differentiering. Emellertid kan dessa tekniker orsaka ”utsvältning” (starvation) av lägre prioriterad trafik om denna styrning misslyckas. Dvs. trafik märkt med annan än den högsta prioriterade ”drop precedence”-nivån kan drabbas av ”utsvältning”.
Misslyckande med styrning av trafik kommer att inträffa beroende på bristande precision i tillträdesstyrning (admission control) och ändringar i topologi. Till exempel kan mätningsbaserad tillträdesstyrning oavsiktligt acceptera trafik som orsakar en tillfällig överbelastning tills detta tillstånd upptäcks. Dessutom kan styrsystemet, eller signalprotokollet, misslyckas med att anpassa sig tillräckligt snabbt till ändringar i nätverksdirigeringstopologi_ Trafikkonditionerare (traffic conditioners) kan därför ej omkonfigureras innan överbelastning inträffar. Sålunda är det fördelaktigt om den AQM-teknik som används kan förhindra ”utsvältning” vid varje belastning.
RIO kan konfigureras att förhindra ”utsvältning”, men strikt hierarki mellan ”precedence”-nivåer kan ej garanteras under perioder av överbelastning. Dvs. trafik märkt med den högst prioriterade ”drop precedence”-nivån kan erfara en större ”drop rate” än trafik märkt med en lägre prioriterad nivå. En sådan konfiguration med RIO är därför inte tillràdlig. En köteknik bör inte endast förhindra ”utsvältning”, den bör också bevara en strikt hierarki mellan ”precedence”-nivåer vid varje belastning. 10 15 20 25 30 35 514 313 4 En köteknik som skapar ett flertal ”drop precedence”- nivåer kan anses vara belastningstålig om den kan uppfylla de följande kraven vid varje belastning: - förhindra ”utsvältning” av lågprioriterad trafik, dvs. få en tjänlig del av den tillgängliga bandbredden; lágprioriterad trafik måste alltid och - bibehålla en strikt hierarki mellan ”precedence”- nivåer - dvs. trafik som använder en viss ”precedence”-nivå måste alltid erfara mindre ”drop”-sannolikhet än trafik som använder en lägre prioriterad ”drop precedence”-nivå.
WRED kan uppfylla dessa krav på belastningstålighet när den konfigureras för att erbjuda en relativ differentiering. En relativ differentiering betyder, till exempel, att ett TCP-flöde ges två gånger genomströmningen TCP-flöde med samma RTT. garantier ges endast åt ett flöde i förhållande till av ett annat, mindre prioriterat, Dvs. ett annat. En absolut differentiering, å andra sidan, erbjuder kvantifierbara gränser för genomströmning, förlust och/eller fördröjningsjitter. Detta slag av differentiering kan ge ett TCP-flöde en absolut kvantifierad genomströmning, oberoende av den genomströmning andra TCP- flöden kommer att erfara.
Det kan antas att absolut differentierbara tjänster är mer önskvärda för många användare än relativa tjänster, eftersom de är mer förutsägbara. Hos en absolut tjänst, är kvalitén på en viss kommunikationssession känd på förhand.
Denna förkunskap är värdefull vid t.ex. val av en optimal nivå på redundanskodning. Hos en relativ tjänst måste kodningsnivån baseras på heuristik, eller realtidsmätningar. 10 15 20 25 30 35 514 313 5 Varken RIO, eller WRED, kan uppfylla kraven på belastningstàlighet, som anförts ovan, när de anordnar för en absolut differentiering. Den föreliggande uppfinningen anordnar emellertid för en ny köteknik, WRED med trösklar (WRED with Thresholds - WRT). uppfinningen, dvs. WRT, är att den, utan omkonfigurering, Fördelen med den föreliggande anordnar för en absolut differentiering, om prioriterad trafik styrs på lämpligt sätt, och en relativ differentiering i andra fall. Sålunda kan WRT anses vara belastningstàlig enligt den definition som anförts ovan.
Belastningståligheten hos WRT kan undersökas med hjälp av simuleringar. Simuleringarna fokuseras på det kvalitativa uppförandet hos WRT under olika grader av överbelastning, snarare än dess kvantitativa uppförande vid en viss belastning. Simuleringar som jämför WRT med RIO och WRED visar att WRT erbjuder likvärdig differentiering med dessa funktioner. Sålunda är det troligt att andra simuleringsstudier av RIO och WRED som ger kvantitativa resultat kan tillämpas för WRT.
För konstruktion av ”end-to-end”-tjänster, är belastningstàlighet fördelaktig av flera orsaker. För det första behöver trafikstyrning inte vara så exakt och/eller kan en större del prioriterad trafik tillåtas i ett nätverk. Dessutom kan misslyckande med att styra denna prioriterade trafik ej åstadkomma någon ”utsvältning” (starvation).
Ett mål med den föreliggande uppfinningen är att anordna för en köteknik som skapar ett flertal ”drop precedence”-nivåer som kan hindra ”utsvältning” av làgprioriterad trafik. 10 15 20 25 30 35 514 313 6 Ytterligare ett mål med den föreliggande uppfinningen är att anordna för en köteknik som skapar ett flertal ”drop precedence”-nivåer och som kan bibehålla en strikt hierarki bland ”precedence”-nivåer - dvs. trafik som använder en viss ”precedence”-nivå måste alltid erfara mindre "drop"- sannolikhet än trafik som använder en lägre prioriterad ”drop precedence”-nivå.
Enligt en första aspekt av den föreliggande uppfinningen anordnas för en metod för aktiv köhantering, för att hantera prioriterad trafik i ett datapaketförmedlingssystem, anpassad till anordnad differentiering mellan trafik som härrör från "rate"- anpassningsbara applikationer som reagerar på förlust av datapaket, i vilken trafik tilldelas en, av åtminstone två, ”drop precedence”-nivåer, karakteriserad av att ”utsvältning” av lågprioriterad trafik förhindras medan samtidigt en strikt hierarki mellan ”precedence”-nivåer bibehàlles, för. och absolut differentiering av trafik anordnas Enligt en andra aspekt av den föreliggande uppfinningen anordnas för en metod för aktiv köhantering, för att hantera prioriterad trafik i ett datapaketförmedlingssystem, anpassad till anordnad differentiering mellan trafik som härrör från "rate"- anpassningsbara applikationer som reagerar på förlust av datapaket, i vilken trafik tilldelas en, av ett flertal ”drop precedence”-nivåer, karakteriserad av att en modifierad RIO, ItRIO, kombinerad med WRED, ett flertal tröskelnivàer, för genomsnittlig kölängd, används, så att skapas, genom att tillämpa olika ”drop”-sannolikheter för varje ”precedence-nivå, och genom att sätta alla maximala tröskelnivåer till samma värde. 10 20 25 30 35 514 313 7 Absolut differentiering kan anordnas för om prioriterad trafik styrs fullt ut, och relativ differentiering kan anordnas för i andra fall. Åtminstone två ”drop precedence”-nivåer kan anordnas för, inom profil och utanför profil, där ett paket märkt som inom profil kan omklassificeras som utanför profil när en ”drop”-sannolikhet tilldelad paketet är större än en ”drop”-sannolikhet beräknad från den genomsnittliga kölängden för paket inom profil, och ett paket märkt som utanför profil kan förkastas när en ”drop”-sannolikhet tilldelad paketet är större än en ”drop”-sannolikhet beräknad för den genomsnittliga kölängden för paket utanför profil.
Ett maximalt tröskelvärde för den genomsnittliga kölängden för paket utanför profil, max_th_out, och ett maximalt tröskelvärde för den genomsnittliga kölängden för paket inom profil, max_th_in, kan anordnas för, och max_th_out kan sättas till ett större värde än max_th_in.
En omgång tröskelparametrar, max_th_in, min_th_in, och max_p_in, kan användas istället för READ-parametrar, för att bestämma huruvida ett paket inom profil bör märkas som ett paket utanför profil.
Nämnda flertal tröskelvärden, max_th#, kan sättas till samma värde.
Tre ”drop precedence”-nivåer kan anordnas för, och en genomsnittlig kölängd för varje "drop precedence”-nivå kan beräknas baserad på paket märkta med denna nivå, och paket märkta med en högre ”drop precedence”-nivå.
En unik tröskel kan tilldelas var och en av de två högst prioriterade preferensnivåerna, där nämnda unika trösklar används för att bestämma när ett paket skall 15 20 25 30 35 514 313 8 märkas med en lägre ”precedence”-nivå, och en relativ differentiering bland nämnda tre nivåer kan anordnas för när den genomsnittliga kölängden för de två högst prioriterade ”precedence”-nivåerna överstiger båda trösklarna.
Fler än tre ”drop precedence”-nivåer kan anordnas för, och en genomsnittlig kölängdsparameter kan användas för varje ”drop precedence”-nivå med associerade trösklar min_th# och max_p#s. Åtta ”drop precedence”-nivåer kan anordnas för.
En enda minimumtröskel, th_in, kan anordnas för, för alla ”drop precedence”-nivåerna så att inga paket förloras om den genomsnittliga kölängden är mindre än th_in.
Enligt en tredje aspekt av den föreliggande uppfinningen anordnas för en metod för aktiv köhantering för att hantera prioriterad trafik i ett paketförmedlingssystem, anpassad till anordnad differentiering mellan trafik som härrör från "rate"- anpassningsbara applikationer som reagerar på paketförlust, i vilken trafik tilldelas en, av åtminstone en första och en andra, ”drop precedence”-nivå, nämligen inom profil och utanför profil, karakteriserad av att: - en genomsnittlig kölängd, avg_ql, beräknas; - minimumtrösklar, min_th_in och min_th_out, för paket inom profil, respektive paket utanför profil, och en maximumtröskel, max_th, tilldelas; - alla paket bibehàlles med sina ursprungligen tilldelade ”drop precedence”-nivåer, så länge den 10 20 25 30 514 313 9 genomsnittliga kölängden är mindre än, eller lika med, en tröskel th_in; - en ”drop”-sannolikhet, bestämd av den genomsnittliga kölängden, tilldelas varje paket; - alla paket bibehålles så länge avg_ql är mindre än th_in; och - paket ”droppas/tappas” enligt deras tilldelade ”drop”-sannolikhet; och av att max_p_out är större än max_p_in, där max_p_out är den maximala ”drop”-sannolikheten för paket som är märkta som utanför profil, och max_p_in är den maximala ”dro ”-sannolikheten för aket som är märkta som inom P profil.
Nämnda metod kan tillämpas på en FIFO-kö.
Nämnda metod kan inkludera stegen att: - ett paket förloras om avg_ql, när paketet anländer, är >max_th; - för ett paket märkt som inom profil, beräknas avg_ql_in, och om avg_ql_in>th_in och min_th_in behàlles, nämnda paket enligt värdet på Pin. - för ett paket märkt som utanför profil, om min_th_out eller behàlles, nämnda paket enligt värdet på Pout. 10 15 20 25 30 35 514 313 10 Ett flertal ”drop precedence”-nivåer, fler än två, kan användas och en genomsnittlig kölängd kan hämtas för varje ”drop precedence”-nivå.
Nämnda max_th för varje ”drop precedence”-nivå kan sättas till samma värde.
Tre ”drop precedence”-nivåer kan anordnas för, och en genomsnittlig kölängd kan beräknas för varje ”drop precedence”-nivå baserad på paket märkta med denna nivå, och paket märkta med en högre ”drop precedence”-nivå.
En unik tröskel kan tilldelas var och en av de två högst prioriterade ”drop precedence”-nivåerna, där nämnda unika trösklar används för att bestämma när ett paket skall märkas med en lägre ”drop precedence”-nivå, och en relativ differentiering kan anordnas för mellan nämnda tre nivåer när den genomsnittliga kölängden för de två högsta ”drop precedence”-nivåerna överstiger båda trösklarna.
Fler än tre ”drop precedence”-nivåer kan anordnas för, och en genomsnittlig kölängdsparameter kan användas för varje ”drop precedence”-nivå med associerade trösklar min_th#s och max_p#s. Åtta ”drop precedence”-nivåer kan anordnas för.
En enda minimumtröskel, th_in, kan anordnas för, för alla ”precedence”-nivåer, så att inga paket förloras om den genomsnittliga kölängden är mindre än th_in.
Enligt en fjärde aspekt av den föreliggande uppfinningen anordnas för ett telekommunikationssystem för överföring av paketförmedlad data, karakteriserad av att nämnda telekommunikationssystem använder en metod för aktiv köhantering, så som beskrivits i något av tidigare stycken. 10 20 25 30 35 514 313 ll Nämnda telekommunikationssystem kan vara ett Internet.
Enligt en femte aspekt av den föreliggande uppfinningen anordnas för en router för användning i ett telekommunikationssystem så som beskrivits i något av föregående stycken, karakteriserad av att nämnda router använder en metod för aktiv köhantering så som beskrivits i något av föregående stycken.
Utförandeformer av uppfinningen kommer nu att beskrivas, genom exempel, med hänvisning till de bifogade figurerna, i vilka: Figur 1 illustrerar RED-tekniken.
Figur 2 illustrerar WRED-tekniken.
Figur 3 illustrerar RIO-tekniken.
Figur 4 illustrerar WRED konfigurerad att erbjuda en absolut differentiering.
Figur 5 illustrerar WRED konfigurerad att erbjuda en relativ differentiering.
Figur 6 illustrerar WRT-tekniken i den föreliggande uppfinningen.
Figur 7 listar en pseudokod för WRT.
Figur 8 illustrerar ett simuleringsarrangemang.
Figur 9 är en tabell som visar bandbreddsallokeringsgränser i ItRIO.
Figur 10 visar karakteristiken för RIO och ItRIO. 10 20 25 W 35 Figur Figur Figur Figur Figur WRT. 11 12 13 14 15 514 313 12 visar karakteristiken för WRBD och WRT. visar ItRIO vid stor överbelastning. visar ItRIO vid begränsad överbelastning. visar RIO vid begränsad överbelastning. visar belastningstålighet för RIO, ItRIO och En förteckning över de förkortningar som används i denna patentbeskrivning visas nedan för att underlätta förståelsen av den föreliggande uppfinningen: AF: AQM: CS: DiffServ: EF: FIFO: IETF: IP: ISP: Assured Forwarding Aktiv köhantering (Active Queue Management) Class Sector Differentierade tjänster (Differentiated Services) Expedited Forwarding Först in/först ut (First In First Out) Internet Engineering Task Force Internetprotokoll (Internet Protocol) Internetoperatör 10 20 25 30 35 514 313 13 (Internet Service Provider) ItRIO: Belastningstålig RIO (Load Tolerant RIO) PHB: Per Hop Behaviour RED: Random Early Detection RIO: RED In and Out RTT: Round Trip Time TCP: Transmissionsstyrningsprotokoll (Transmission Control Protocol) TSW: Time Sliding Window UDP: Användardatapaketprotokoll (User Datagram Protocol) WRED: Viktad RED (Weighted RED) WRT: WRED med trösklar (WRED with Thresholds) Huvudavsikten med AQM-tekniker är att minska den genomsnittliga kölängden i routrar. Detta ger mindre fördröjning, undviker att flöden utestängs och, optimalt, minskar antalet paket som förloras i överbelastade (congested) routrar. Dessutom kan AQM användas för att implementera tjänstedifferentiering mellan olika flöden, t.ex. TCP-flöden. En fördel med AQM är att en enda FIFO-kö kan användas för all trafik som hör till dessa flöden.
Detta är en fördel om ändring av återställande av 10 15 20 25 30 35 514 513 14 ordningsföljden (reordering) för paket inom flöden skall undvikas. Det bör observeras att i FIFO-köer sänds paket i samma ordning som de anländer.
WRED och RIO är två exempel på användningen av AQM för att uppnå tjänstedifferentiering. WRED och RIO är båda utökningar av RED, som kortfattat beskrives nedan.
RED föreslogs ursprungligen 1993 av Floyd och Jacobson, se: - Floyd S. och Jacobson V. (1993), Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, augusti 1993; och rekommenderas nu för användning i Internet, se: - Braden B. et al (1998), Recommendations on Queue Management and Congestion Avoidance in the Internet, IETF RFC 2309, april 1998.
RED tillåter en router att förlora paket innan någon kö mättas. Flöden som reagerar (responsible flows) kommer då att pruta på sina anspråk, i god tid, vilket resulterar i kortare genomsnittliga köstorlekar. Detta är önskvärt av flera skäl. Köfördröjningen kommer att minska, vilket är bra för applikationer som t.ex. interaktiva spel. En annan fördelaktig egenskap hos RED är att ”packet drops” ej (bursts). för att TCP-flöden hamnar i långsam startfas beroende på inträffar i skurar Detta minskar sannolikheten ett flertal i följd förlorade paket. RED uppnår detta genom ”dropping” av paket med en viss sannolikhet beroende på den genomsnittliga kölängden (avg_ql), se Figur 1. 10 15 20 25 30 35 514 313 15 Dessvärre beror den optimala konfigurationen för RED på trafikmönster och karakteristik. Om det, till exempel, finns ett stort antal TCP-flöden i en kö, behöver RED bli ”aggressiv” för att uppnå sitt mål, dvs. max_p måste sättas högt. Annars är det troligt att kön kommer att växa mot sitt gränsvärde och till slut kommer att uppföra sig som en endast ett litet kan en alltför aggressiv RED vanlig ”tail-drop queue”. Om, andra sidan, antal flöden finns i en kö, minska utnyttjandet av länken i fråga. Anpassad RED (adaptive RED), se: Kandlur D.; Saha D. och Shin K.
Techniques for Eliminating Packet Loss in Congested TCP/IP Networks, Technical Report, november 1997, Feng W., (1997), University of Michigan, är ett försök att lösa detta konfigurationsproblem.
Emellertid löser denna teknik inte problemet om en stor mängd av trafik härrör från applikationer som ej reagerar på nätverksöverbelastning, t.ex. realtidsapplikationer som använder UDP, eller kortvariga http-överföringar som använder TCP.
WRED, definierad och implementerad av Cisco, och RIO, föreslagen och utvärderad med simuleringar av Clark och Fang, är två AQM-tekniker definierade för tjänstedifferentiering i IP-nätverk. De är båda baserade på RED och erbjuder differentiering genom hantering av förlustpreferens (drop precedence).
Med WRED kan åtta olika ”drop precedence”-nivåer konfigureras. Var och en av dessa nivåer konfigureras med en separat omgång RED-parametrar - se Figur 2. RIO, å andra sidan, har endast två omgångar RED-parametrar. Sålunda kan i dess grundversion två ”drop precedence”-nivåer skapas, dvs. en nivå för paket märkta som inom profil (in profile), 10 15 20 25 30 35 514 313 16 och en annan nivå för paket märkta som utanför profil (out of profile).
Den huvudsakliga skillnaden mellan RIO och WRED är att RIO använder två genomsnittliga kölängder för att beräkna ”drop”-sannolikheter, medan WRED endast använder en. WRED beräknar sin genomsnittliga kölängd (avg_ql) baserad på alla paket som finns i kön. RIO gör detta också, men dessutom beräknar den en separat genomsnittskölängd för paket i den kö som är märkt som inom profil (av_ql_in), se Figur 3.
Det finns en klar skillnad mellan absolut och relativ differentiering mellan ”drop precedence”-nivåer. I detta sammanhang innebär absolut differentiering att en viss ”precedence”-nivå erbjuder en kvantifierbar gräns (bound) för förlust. Dvs. trafik som använder en speciell nivå Sålunda kan ett TCP- flöde ges en absolut kvantifierad genomströmning oberoende garanteras en ”maximum loss rate”. av den genomströmning andra TCP-flöden kommer att erfara.
En maximal gräns för förlust (bound on loss) kan endast erbjudas trafik som styrs på lämpligt sätt. Dvs. den ”rate” med vilken prioriterade paket anländer i nätverket måste begränsas för att säkerställa att ”drop rate” aldrig överskrider gränsen. Följaktligen är trafikstyrning nödvändig för att skapa absolut differentiering av tjänster.
En relativ differentiering erbjuder inte några kvantifierbara förlustgränser (bounds on loss). Istället definieras ”drop rate” för varje ”precedence”-nivå i förhållande till någon annan nivå. Till exempel kan en ”precedence”-nivå erbjuda halv ”drop rate” av någon annan nivå. Ur dessa ”drop rates”, definierade i förhållande till 10 zov 25 30 35 514 313 17 varandra, kan en differentiering i genomströmning uppnås mellan TCP-flöden.
När en absolut differentiering av trafik som använder en viss ”drop precedence”-nivå stöds, kan trafik som använder andra ”precedence”-nivåer drabbas av ”utsvältning”. Detta problem kan uppstå om trafik som använder den absoluta nivån styrs otillräckligt. Dvs. hastigheten för inkommande trafik (arrival rate) som skall ges en absolut förlustgräns överstiger det värde vid vilken nätverket kan stödja denna gräns.
WRED och RIO kan konfigureras för stödja en absolut differentiering. För att skapa en sådan differentiering kräver dessa inställningar en lämplig styrning av trafik med användning av den ”precedence”-nivå som endast stöder absolut differentiering. Dvs. trafik som använder andra ”precedence”-nivåer behöver inte styras.
Med WRED stöds absolut differentiering genom att max_th# sättes till separata värden. Dessutom måste max_p#s och min_th#s sättas för att säkerställa att högre prioriterade paket alltid erfar lägre ”drop”-sannolikhet än lägre prioriterade paket. Ett exempel på en sådan konfigurering med två ”drop precedence”-nivåer visas i Figur 4.
Med detta slag av konfigurering anordnas för en maximal gräns för förlust om av_ql aldrig blir större än max_thl, se: - Braden R. et al (1997), Resource Reservation Protocol (RSVP) - Version 1 Functional Specification, IETF RFC 2205, september 1998.
För att undvika ”utsvältning” av trafik 20 25 30 35 514 315 18 märkt med ”precedence”-nivå noll, får emellertid av_ql ej överstiga max_th0. Lämplig trafikstyrning behövs därför för att erbjuda absolut differentiering av tjänster i WRED.
När RIO används för att skapa en absolut differentiering, bör max_th_in sättas till lika med, eller större än, max_th_out. Annars kommer trafik märkt som inom profil att råka ut för en högre ”drop rate” än trafik märkt som utanför profil. Detta skulle bryta den strikta hierarkin mellan ”drop precedence"-nivåer. Följaktligen är en sådan konfigurering inte tillràdlig.
Konfigureringen av RIO som visas i Figur 3 kan användas för att erbjuda en absolut differentiering. Till exempel erbjuds en maximal förlustgräns om avg_ql_in aldrig blir större än max_th_in. Emellertid kan, som med WRED, ”utsvältning” av lägre prioriterad trafik, dvs. trafik märkt som utanför profil, förekomma om högre prioriterad trafik ej styrs på lämpligt sätt. I RIO måste denna styrning säkerställa att avg_ql aldrig överstiger max_th_out.
Varken WRED eller RIO kan uppfylla kraven på belastningstàlighet när de konfigureras för att stödja absolut differentiering. Prioriterad trafik måste styras på lämpligt sätt för att undvika ”utsvältning” av lägre prioriterad trafik, och för att säkerställa att en strikt hierarki bibehålles mellan ”drop precedence”-nivåer. WRED kan emellertid uppfylla dessa krav när den konfigureras att erbjuda en relativ differentiering mellan ”precedence”- nivåer.
En relativ differentiering kan skapas med WRED om alla max_th#s sättes lika. Den differentiering som erbjuds beror på vilka värden som sättes på min_th#s och max_p#s. Dessa 20 25 30 35 514 313 19 parametrar måste sättas för att garantera en strikt hierarki mellan ”drop precedence”-nivåerna.
Med den inställning av WRBD som visas i Figur 5, kommer trafik som använder ”precedence”-nivå ett att erfara hälften av den ”drop rate” som trafik som använder ”precedence”-nivå noll erfar. Detta förhållande kan emellertid endast bibehållas vid måttlig överbelastning.
Dvs. endast en liten del av trafiken kommer från applikationer som ej reagerar pà nätverksöverbelastning, t.ex. realtidsapplikationer som använder UDP, eller kortvariga http-överföringar som använder TCP.
När den del av trafik som kommer från applikationer som ej reagerar på nätverksöverbelastning blir större, blir överbelastningen värre. Om överbelastningen blir tillräckligt stor, kommer kön slutligen att uppföra sig precis som en ”tail-drop queue”. Den exakta relativa differentieringen som anordnas för beror på såväl trafikkarakteristik som på konfigurationen av WRED.
RIO kan ej konfigureras för att erbjuda en relativ differentiering. Detta eftersom RIO använder en separat variabel (av_ql_in) för att beräkna sannolikheten, Pin, för ”dropping” av ett paket märkt som inom profil som anländer i kön. Denna separata variabel innehåller inte någon information om antalet paket i kön märkta som utanför profil. Beräkningen av Pin kan därför ej relateras till sannolikheten Put för ”dropping” av paket om det har märkts som utanför profil.
Den föreliggande uppfinningen omfattar en ny köteknik som, utan omkonfigurering, anordnar för en absolut differentiering om den prioriterade trafiken styrs pà lämpligt sätt, och en relativ differentiering i andra fall.
Denna teknik, viktad RED med trösklar (Weighted RED with 10 20 25 30 35 514 313 20 Thresholds ~ WRT> WRED. konstrueras genom att kombinera RIO med från RIO, att beräkna tvâ separata genomsnittliga kölängder. Istället Den föreliggande uppfinningen lånar, idén för att förkasta paket markerade som inom profil när avg_ql_in överstiger max_th_in - se Figur 3, behandlas emellertid dessa paket som om de vore märkta som utanför profil. Detta betyder att max_th_in kan, och bör, sättas lägre än max_th_out för att undvika ”utsvältning”. Med denna ändring kan tekniken stödja absolut differentiering så länge som av_ql_in ej överstiger max_th_in. Denna teknik stöder en differentiering motsvarande den som stöds av RIO.
Om avg_ql_in ej överstiger max_th_in, kommer det inte att bli någon differentiering överhuvudtaget. Kötekniken kommer då att uppföra sig som RED. För enkelhetens skull kommer denna teknik att benämnas belastningstålig RIO (ItRIO).
Det antal parametrar som finns i ItRIO kan minskas genom användning av en tröskel istället för en omgång RED- parametrar, nämligen max_th_in, min_th_in och max_p_in för att besluta när ”inom-paket” skall behandlas som om de vore märkta som utanför profil. Denna förenkling förväntas inte ha några märkbara effekter på ItRIO:s uppförande. Detta beror på att ”random early congestion”-signaleringen kommer att baseras på de RED-parametrar som är associerade med av_ql för paket märkta som inom och utanför profil. Hos RIO är denna signalering baserad på RED-parametrar associerade och RED- parametrar associerade med av_ql för paket märkta som inom med av_ql, för paket märkta som utanför profil, profil.
För att uppnå en relativ differentiering när avg_ql_in överstiger max_th_in, behövs en teknik för att tillämpa olika ”drop”-sannolikheter för varje preferensnivà. Som tidigare avhandlats, anordnar WRED för detta när alla 10 20 25 30 35 514 313 21 max_th#s sättes lika. Genom att sålunda kombinera ItRIO med WRED erhålles denna egenskap i köteknik hos den föreliggande uppfinningen. För kötekniken i den föreliggande uppfinningen får max_th#s ej sättas skilda från varandra. Detta eftersom en sådan inställning kan åstadkomma ”utsvältning” av trafik som använder lägre prioriterade preferensnivåer.
Det kombinerade systemet, WRT, kan användas för att skapa en relativ differentiering mellan åtta ”precedence”- nivåer när av_ql_in överstiger th_in. Emellertid används för denna beskrivning endast två av dessa nivåer vilka för enkelhetens skull kallas ”inom” (in)- respektive ”utanför” (out)-nivå. WRT visas i Figur 6.
Figur 7 visar hur WRT med två ”drop precedence”-nivåer kan implementeras. Implementeringen har i grunden samma komplexitet som en implementering av RIO.
För AF PHB-gruppen specificeras tre ”drop precedence”- nivåer. För att skapa dessa tre nivåer, måste WRT utökas med stöd för en extra ”drop precedence”-nivå. Detta innebär att WRT måste utökas med ytterligare en tröskel associerad med en extra genomsnittlig kölängd. Sålunda beräknas en separat genomsnittlig kölängd för var och en av de tre ”drop precedence”-nivåerna, baserad på paket märkta med denna nivå och varje annat paket märkt med någon högre prioriterad nivå.
En unik tröskel tilldelas var och en av de två högst prioriterade ”precedence”-nivåerna. Dessa trösklar används för att besluta när paket måste behandlas som om de vore märkta med en lägre prioriterad ”precedence”-nivå. Tröskeln för den högsta nivån måste sättas till ett lägre värde än tröskeln för den näst högsta nivån (den ordning i vilken 10 15 20 25 30 35 514 313 22 trösklarna sättes definierar prioritetsordningen mellan ”precedence”-nivåerna).
När den genomsnittliga kölängden för de två högst prioriterade nivåerna överstiger båda trösklarna, anordnas för en relativ differentiering mellan de tre ”drop precedence”-nivåerna. Den relativa differentieringen beror på hur min_th# och max_p# konfigureras för var och en av dessa nivåer och den aktuella belastningen av trafik som ej reagerar (irresponsible traffic).
Närhelst det behövs kan WRT utökas till att stödja fler ”drop precedence”-nivåer genom att lägga till extra genomsnittliga kölängdsvariabler med associerade trösklar, min_th#s och max_p#s.
Belastningstàligheten för ItRIO och WRT kan uppskattas genom att använda simuleringar. Simuleringarna kan göras med en nätverkssimulator (ns), se: - UCB/LBNL/VINT Network Simulator - ns (1998). (version 2) Detta gör det möjligt att visa att ItRIO kan erbjuda en differentiering som är likvärdig med den som erbjuds av RIO, och att WRT kan erbjuda samma differentiering som WRED.
De simuleringar som visas nedan gör möjligt att undersöka det kvalitativa uppförandet av WRT under olika grader av överbelastning. Dessutom kan det visas, genom att jämföra WRT med RIO och WRED, att WRT kan erbjuda samma differentiering som dessa tekniker.
För att utföra utvärderingen används en enkel simuleringsuppsättning. En topologi med tio värddatorer 10 20 25 30 35 514 313 23 (SO, W, S9), som ansluter till sina respektive destinationer (RO, Denna länk, Pl-P2 är en flaskhals på 30 Mbit/s med 20 ms fördröjning, M; R9) via en gemensam länk, används. se Figur 8.
Den AQM-teknik som utvärderas tillämpas på kön ansluten till flaskhalslänken. Varje värddator (host) har tio TCP Reno-anslutningar till sina respektive destinationer. Genomströmningen för vart och ett av dessa TCP-flöden mäts över 16 simulerade sekunder. Varje simulering går emellertid igenom en initieringsfas på tre till fyra simulerade sekunder, innan dessa mätningar initieras. Detta för att låta kön stabilisera sig innan uppförandet hos de AQM-tekniker som skall utvärderas observeras. TCP-anslutningarna initieras slumpmässigt inom den första simulerade sekunden, Alla dessa anslutningar har samma RTT (40 ms).
(TSW) för var och en av de tio värdarna, En ”time sliding window rate estimator” används för att märka paket som inom profil upp till en viss "rate". Sålunda tillämpas en profil för alla tio TCP-anslutningarna vid var och en av värddatorerna. Det finns två olika metoder att märka paket baserade på den ”rate” som beräknas (rate estimated) med TSW. Den första metoden är mer generell och kan tillämpas på sammanlagd (aggregated) TCP-trafik såväl som på individuella TCP-anslutningar. Den andra metoden bör endast användas för individuella anslutningar, men är då mer effektiv om estimatorn placeras nära den sändande värden.
Eftersom estimatorn tillämpas på en ansamling av tio TCP- anslutningar är den första metoden mera lämplig för de simuleringar som här beskrivs.
I den första metoden skall fönsterstorleken sättas till ett stort värde, dvs. storleksordningen på en TCP- sågtand från 66 till 133 procent av den hastighet som 10 15 20 25 30 35 514 313 24 specificeras i tjänsteprofilen. Ett alltför litet fönster kan orsaka att den sammanlagda genomströmningen blir mindre än den som specificeras i profilen. Å andra sidan, med ett alltför stort fönster kan den trafik som är märkt som inom profil bli mer skuraktig. Följaktligen kan fönsterstorleken påverka den genomströmning som upplevs av individuella TCP- flöden och ”rate”-variationen för paket märkta som inom profil som anländer till kärnroutrar. Tyvärr innebär detta att det blir ett ”cirkelberoende” mellan tidslängden hos en sågtand och fönsterstorleken. Dessutom kommer längden på en sågtand att variera eftersom paket kan förloras slumpmässigt i nätverket. En lämplig fönsterstorlek för en viss TCP-anslutning är därför svår att välja baserad enbart på kända parametrar. Sålunda kan det bli nödvändigt att anpassa fönsterstorleken baserad på realtidsmätning av varje individuellt TCP-flöde.
För alla simuleringarna sättes fönsterstorleken till 300 ms. Detta värde väljes på basis av följande argument.
Antag att målhastigheten för en viss TCP-förbindelse sättes till 500 kbit/s. RTT:n är 80 ms, genomsnittliga köfördröjningen, och den genomsnittliga inkluderande den paketstorleken sättes till 8000 bit i simuleringarna. Denna TCP-förbindelse kommer då att ha fem paket ”på gång” (on the fly), storleken fem datapaket i genomsnitt. Optimalt kommer då i genomsnitt, och ett överbelastningsfönster av antalet paket ”på gång” och storleken på att variera mellan l,33x5 och = 3,35 paket.
Eftersom TCP ökar sitt överbelastningsfönster med ett överbelastningsfönstret 0,55x5. Variationen är sålunda 0,67x5 datasegment, motsvarande nyttolasten för ett paket, som mest för varje RTT, är tidslängden för en TCP-sågtand 3,35x0,08 = 0,268 s.
För att utföra en utvärdering av egenskaperna hos ItRIO och WRT i jämförelse med RIO och WRED, observeras den 10 15 20 25 30 35 514 313 25 genomsnittliga genomströmningen som erfars av TCP-källor som sänder alla sina nedströmspaket märkta som inom profil, dvs. dessa källor har profiler för ”unlimited rate”. Detta jämförs med den genomsnittliga genomströmningen som erfars av andra TCP-källor som sänder alla sina paket märkta som utanför profil, dvs. källor med ”zero rate”-profiler.
Antalet TCP-källor med ”unlimited rate”-profiler varieras mellan 10 och 90 procent i steg om 10. Resultaten ritas i kurvdiagram med den genomsnittliga genomströmningen som y- axeln, och procenten av källor med ”unlimited rate”-profil som x-axeln. Figur 10 visar resultaten för RIO och ItRIO.
RIO är, i denna simulering, konfigurerad med max_th_in och min_th_in sättes till 100 paket, max_th_out till 200 paket, och min_th_out till 100 paket. Följaktligen är värdet max_p_in ej relevant (eftersom max_th_in och min_th_in är lika). Parametern max_p_out sättes till 5 procent. ItRIO har samma konfiguration, dvs. de parametrar som finns i båda dessa tekniker sättes till samma värden.
Parametern th_in i ItRIO sättes till 100 paket.
Det framgår av Figur 10 att ItRIO erbjuder samma differentiering som RIO när antalet flöden med ”unlimited rate”-profiler är mindre än 57 procent. Över denna belastning uppför sig ItRIO som RED, emedan RIO ej längre bibehåller den strikta prioritetsordningen mellan in- och ut-preferensnivåerna. Sålunda kan ItRIO stödja absolut differentiering utan risk att ge en lägre tjänstekvalitet för trafik märkt som inom profil än som ges till trafik med en lägre prioritet.
Figur 11 visar resultaten för WRED och WRT. WRED konfigureras, i denna simulering, med max_th0 och max_th1 sättes till 200 paket min_th0 och min_thl till 100 paket max_p0 till 5 procent, och max_pl till 2,5 procent.
Parametrarna för de andra sex ”precedence”-nivåerna är ej 15 20 25 30 35 514 315 26 relevanta eftersom endast nivå noll och ett används (nivå ett tillämpas på trafik märkt som inom profil, och nivå noll på trafik märkt som utanför profil). De parametrar som finns i båda teknikerna sättes till samma värde. Parametern max_th i WRT sättes till 100 paket.
I Figur ll kan ses att WRT erbjuder en relativ differentiering när antalet flöden med ”unlimited rate”- profiler överstiger 50 procent. Denna differentiering är densamma som den som erbjuds med WRED. När antalet flöden med ”unlimited rate”-profiler är mindre än 50 procent, erbjuder WRT samma differentiering som RIO och ItRIO.
Med denna konfiguration uppför sig WRT följaktligen som RIO och ItRIO om antalet flöden med ”unlimited rate”- profiler är mindre än 50 procent, och annars som WRED.
Detta betyder att WRT bibehåller den strikta hierarkin mellan ”drop precedence”-nivåer oberoende av belastning.
Baserat på dessa observationer kan slutsatsen dras att WRT kan användas för att skapa en absolut differentiering om den prioriterade trafiken styrs på lämpligt sätt, och annars en relativ differentiering.
Att tillåta källor att ha ”unlimited rate”-profiler representerar en extrem situation av överbelastning eftersom den enda ”tillträdesstyrningen” (admission control) som finns baseras på antalet flöden. Detta kan betraktas som ett ”värsta fall”-scenario när styrning av den samlade trafiken märkt som inom profil helt har misslyckats. Simulering med detta slag av överbelastning ger en indikering på hur känslig differentieringen är för olika antal TCP-källor som använder ”unlimited rate”- profiler.
För att undersöka differentieringskänsligheten, tillämpas en gemensam profil med 5 Mbit/s på tio procent av 10 15 20 25 30 35 514 313 27 alla TCP-flöden, alla flöden från värd S9. Källorna med ”unlimited rate”-profiler varierar mellan 0 och 80 dvs. procent. Följaktligen går denna kurva från 0 till 90 procent av flöden med "non-zero rate”-profiler, istället för från 10 till 90 procent som i de tidigare kurvorna.
Detta är för att visa den genomströmning som flödena från S9 skulle haft om det inte fanns någon överbelastning, dvs. det finns inga TCP-källor alls med ”unlimited rate”- profiler. ItRIO används med samma konfiguration som i den simulering som presenteras i Figur 9.
Figur 12 visar hur den genomsnittliga genomströmningen som erfars av de tio styrda TCP-källorna försämras med ett ökande antal flöden som använder ”unlimited rate”-profiler.
De styrda TCP-källorna är de med en gemensam ”rate”-profil' på 5 Mbit/s. Det framgår att några, ej styrda, TCP-källor ej förorsakar någon större försämring i genomströmning som Detta att flödena med ”unlimited rate”- erfars av de TCP-källor som delar 5 Mbit/S-profilen. förutsätter, emellertid, profiler reagerar på nätverksöverbelastningssignalering, dvs. förlust av paket. Applikationer som ej reagerar (irresponsible applications) skulle orsaka att denna försämring skulle bli mycket mera drastisk.
Som ovan nämnts, erbjuder ItRIO och WRT samma differentiering som RIO, om avg_ql_in aldrig överstiger th_in. Frågan är då vid vilken belastning detta kommer att inträffa för en bestämd trafikdistribution och konfiguration med dessa tekniker. Denna fråga kan studeras genom att utföra en omgång upprepade simuleringar. Genom dessa simuleringar kan den maximala mängd bandbredd som kan allokeras utan att orsaka att av_ql_in blir större än th_in, bestämmas.
Förutom att variera ”target rate” i TSW-rate, används samma konfiguration som i simuleringen av ItRIO som visas i W 20 25 30 ä 514 313 28 Figur 10. Tabellen som visas i Figur 9 visar ”maximum rates” för två olika inställningar av th_in, dvs. % och % av max_th (parametern max_th sättes till 200 paket). För var och en av dessa inställningar simuleras tre scenarier, med 30, rate”-profiler. 40 och 50 procent av alla flöden som har ”non-zero De tabeller som visas i Figur 9 visar hur bandbreddallokeringsgräns beror på inställningen av th_in i förhållande till max_th. För dessa simuleringar resulterar inställningar av th_in på ä och ä av max_th_out i en bandbreddallokeringsgräns nära % och % av respektive länkhastighet. förväntas hålla för varje konfiguration med ItRIO och varje Detta förhållande kan emellertid inte möjlig trafikbelastning. Detta beroende på att bandbreddallokeringsgränsen kommer att bero på variationen av av_ql_in. Ju större denna variation är, desto mindre bandbredd kan allokeras utan risk att avg_ql_in överstiger th_in, estimatorn och konfigurationen av den genomsnittliga (RIO, ItRIO, eller WRT) påverkar variationen av av_ql_in. Sålunda kan den exakta Sådana saker som fönsterstorleken i TSW-rate- kölängdsestimatorn i kötekniken gränsen endast hittas med realtidsmätningar. Icke desto mindre kan en grov uppskattning/värdebestämning av bandbreddallokeringsgränsen för en viss länk ändå göras, baserad endast på konfigurationen av ItRIO.
Den differentiering som erbjuds när mängden bandbredd som allokeras varieras, istället för antalet TCP-källor som använder ”unlimited rate”-profiler, kan studeras genom att undersöka det genomsnittliga genomflödet som erfars av lO TCP-källor som delar en ”rate”-profil på 5 Mbit/s. Den totala mängden bandbredd som allokeras varieras mellan 5 Mbit/s och 30 Mbit/s.
TCP-källor som använder en "non-zero rate”-profil mellan Dessutom varieras det totala antalet 10 20 25 30 35 514 313 29 30, 50 och 70 procent. ItRIO konfigureras på samma sätt som i den simulering som presenteras i Figur 10.
Av Figur 13 framgår att de tio TCP-källor som använder den gemensamma ”rate”-profilen på fem Mbit/s får mer än 500 kbit/s genomströmning, i genomsnitt, om den totala mängden bandbredd som allokeras är mindre än 15 Mbit/S, dvs. 2 länkhastigheten. När mer bandbredd allokeras, beror differentieringen på antalet TCP-källor som har ”non-zero rate”-profiler. Med denna konfiguration bevarar ItRIO den strikta hierarkin mellan in- och ut-preferensnivåerna, om detta antal är mindre än 50 procent. Om det finns mer än 50 procent av TCP-källorna med ”non-zero rate”-profiler, som RED. För jämförelse RIO uppför sig ItRIO, som förväntas, simuleras RIO med samma belastning, se Figur 14. konfigureras på samma sätt som den simulering som presenteras i Figur 10.
Genom att jämföra Figurerna 13 och 14 kan man se att RIO erbjuder en liknande differentiering som ItRIO, om den totala mängden bandbredd som allokeras är mindre än 15 Mbit/s. Dessutom erbjuder dessa två tekniker en liknande differentiering om antalet TCP-källor som har ”non-zero rate”-profiler är 50 procent, eller mindre.
När emellertid antalet TCP-källor med ”non-zero rate”- profiler är 70 procent och RIO används, erfar TCP-källor med har ”non-zero rate”-profiler mer genomströmning, i genomsnitt, än de tio anslutningarna som delar en 5 Mbit/s -”rate”-profil. Detta uppförande kan också observeras i Figur 10.
För att studera skillnaden mellan RIO, ItRIO och WRT, när antalet TCP-förbindelser som har ”non-zero rate”- profiler som överstiger 50 procent, simuleras WRT med 70 procent av de förbindelser som använder "non-zero rate”- 10 15 20 25 30 35 514 313 30 profiler. Resultaten från denna simulering visas i Figur 15.
Som förväntas av Figurerna 10 och ll, bevarar endast WRT den strikta hierarkin mellan ”drop precedence”- nivåerna. RIO misslyckas helt med att bevara denna hierarki, och ItRIO uppför sig som RED när den allokerade bandbredden överstiger 20 Mbit/s. Följaktligen är WRT den enda köteknik av dessa tre som kan uppfylla kraven på belastningstålighet.
De simuleringar som beskrivs ovan visar att WRT, utan omkonfigurering, anordnar för en absolut differentiering om den prioriterade trafiken styrs på lämpligt sätt, och annars en relativ differentiering. Varken RIO, eller WRED, kan anordna för detta med en enda konfigurering. Den absoluta differentiering WRT erbjuder, visas vara samma som för RIO, när mängden prioriterad trafik styrs under en viss gräns och den relativa differentieringen visas vara densamma som för WRED. Bandbreddallokeringsgränsen för när differentieringen växlar från att vara absolut till relativ kan grovt beräknas/värdebestämmas baserat på konfigureringen av WRT. Emellertid kommer den verkliga bandbredden som kan allokeras att vara mindre än den som beräknats, om avg_ql_in har en icke försumbar variation.
Det bör observeras att dessa resultat förutsätter att endast långvarig (long lived) TCP-trafik finns i den kö som hanteras av WRT. "Glupsk” UDP-trafik och/eller kortvarig TCP-trafik kan påverka uppförandet av WRT. Varje negativ påverkan av sådan trafik kan förväntas ha en liknande påverkan på RIO och WRED.
Under konstruerandet av absolut kvantifierbar ”end-to- end”-differentiering av tjänster baserade på ”drop precedence”-nivåer, måste trafikstyrning vara exakt för att 10 15 20 25 30 35 514 313 31 garantera att denna differentiering anordnas för hela tiden. Dessutom kan det vara nödvändigt att hålla den del av trafiken som använder en absolut tjänst liten för att _ erbjuda en sådan garanti. Klart är att om endast mycket lite trafik kan ges en tjänst som denna, är den totala fördelen med absoluta tjänster begränsad.
Emellertid gör WRT:ns belastningstålighet absoluta tjänster baserade på ”drop precedences” mer robust.
”Utsvältning” kan ej uppkomma vid någon belastning.
Följaktligen är nätverket mer robust mot fel i trafikstyrning. Beroende på robustheten hos WRT, är det sannolikt att användningstiden för absoluta tjänster som baseras på ”drop precedences” blir kortare. Dessutom kan mer trafik som använder sådana absoluta tjänster tillåtas i nätverket utan risk för ”utsvältning”.
En annan positiv effekt av belastningståligheten hos WRT är att trafikstyrning inte behöver vara så exakt som hos andra AQM-tekniker, t.ex. WRED, eller RIO. En mindre exakt, kanske mätningsbaserad, styrteknik kan garantera att en absolut differentiering erbjuds större delen av tiden.
Om denna styrning misslyckas, garanteras en relativ differentiering, som ett minimum, om WRT används.
RIO och WRED stöder en absolut kvantifierbar differentiering mellan ”drop precedence”-nivåer när prioriterad trafik styrs på lämpligt sätt. Om, emellertid, denna styrning misslyckas, kan dessa tekniker åstadkomma ”utsvältning” av lägre prioriterad trafik. Sådana misslyckanden inträffar beroende på brister i tillträdesstyrning och ändringar i topologi. kan undvikas med WRED, om ”Utsvältning” (starvation) den konfigureras för att erbjuda en relativ 10 20 514 313 32 differentiering. Emellertid är absolut differentiering av tjänster fortfarande nödvändig.
För att erbjuda en absolut differentiering mellan ”precedence”-nivåer utan att riskera ”utsvältning”, anordnar den föreliggande uppfinningen för en ny teknik - WRT. Simuleringar har visat att WRT, utan omkonfigurering, anordnar för en absolut differentiering, om den prioriterade trafiken styrs på lämpligt sätt, och annars en relativ differentiering.
Den absoluta differentiering som WRT erbjuder visas vara densamma som för RIO, när mängden prioriterad trafik styrs under en viss gräns, och den relativa differentieringen visas vara densamma som för WRED. Sålunda kan WRT anordna för varje differentiering som RIO och WRED kan erbjuda. Dessutom kan ”end-to-end”~tjänster, som lovar en absolut differentiering större delen av tiden, och en relativ differentiering som ett minimum, konstrueras med WRT. RIO och WRED är otillräckliga för att konstruera sådana tjänster.

Claims (24)

W H 20 25 30 35 514 313 33 PATENTKRAV
1. En metod för aktiv köhantering, för att hantera prioriterad trafik i ett datapaketförmedlande system, anpassad till anordnad differentiering mellan trafik som härrör från ”rate”-anpassningsbara applikationer som i vilken trafik tilldelas en, av åtminstone två, förlustprioritetsnivåer (drop reagerar på förlust av datapaket, precedence), k ä n n e t e c k n a d av att uteslutning av lågprioriterad trafik förhindras medan, samtidigt, en strikt hierarki mellan prioritetysnivåer bibehålles, och absolut differentiering av trafik anordnas för, att absolut differentiering anordnas för, om prioriterad trafik styrs fullt ut, och relativ differentiering i andra fall.
2. En metod för aktiv köhantering, för att hantera prioriterad trafik i ett datapaketförmedlande system, anpassad till anordnad differentiering mellan trafik som härrör från ”rate”-anpassningsbara applikationer som i vilken trafik tilldelas ”drop precedence”-nivåer, reagerar på förlust av datapaket, en, av ett flertal, k ä n n e t e c k n a d av att en modifierad RIO, kombinerad med WRED, för genomsnittlig kölängd, ItRIO, används så att ett flertal tröskelnivåer, skapas, genom att tillämpa olika ”drop”-sannolikheter för varje ”precedence”- nivå, och genom att sätta alla maximala tröskelnivåer till samma värde.
3. En metod, enligt antingen patentkrav 2, k ä n n e t e c k n a d av att absolut differentiering anordnas för, om prioriterad trafik styrs fullt ut, och relativ differentiering i andra fall.
4. En metod, enligt något av patentkraven 1 till 3, 10 20 25 30 35 _. u. . . _. .. .. n., .r H .. -«. ,. 1 . . . 1 <1 « , .. .\. . _. . . . f 1 « « . - . .. .- _ .1 r«« . f. f 1 .- . . . . .z f ~- -< . f < - . .. <1 :z H < e <1 34 k ä n n e t e c k n a d av åtminstone två ”drop precedence”-nivåer, inom profil och utanför profil, av omklassificering av ett datapaket, märkt som inom profil, till utanför profil, när en ”drop”-sannolikhet som tilldelas paketet är större än en ”drop”-sannolikhet som beräknas från den genomsnittliga kölängden för paket inom profil, och av att förkasta ett paket märkt som utanför profil när en ”drop”-sannolikhet tilldelad paketet är större än en ”drop”-sannolikhet beräknad från den genomsnittliga kölängden för paket utanför profil.
5. En metod, k ä n n e t e c k n a d av ett maximalt tröskelvärde för den genomsnittliga enligt patentkrav 4, kölängden för paket utanför profil, max_th_out, och ett maximalt tröskelvärde för den genomsnittliga kölängden för paket inom profil, max_th_in, och av att max_th_out sättes till ett större värde än max_th_in.
6. En metod, patentkraven 3 till 5, när det är beroende av patentkrav 2, enligt patentkrav 2, eller något av k ä n n e t e c k n a d av att en omgång tröskelparametrar, max_th_in, min_th_in och max_p_in, används istället för RED-parametrar, för att bestämma om ett paket inom profil skall märkas som utanför profil.
7. En metod, k ä n n e t e c k n a d av att nämnda flertal tröskelvärden, max_th#, sättes till enligt patentkrav 6, samma värde.
8. En metod, enligt patentkrav 6, eller 7, k ä n n e t e c k n a d av tre ”drop precedence”-nivåer, och av att en genomsnittlig kölängd för varje ”drop precedence”-nivå beräknas baserad på paket märkta med denna nivå och paket märkta med en högre ”drop precedence”-nivå. k ä n n e t e c k n a d
9. En metod, enligt patentkrav 8, 10 20 25 30 35 514 513 35 av att en unik tröskel tilldelas var och en av de två högst prioriterade ”precedence"-nivåerna, där nämnda unika trösklar används för att bestämma när ett paket skall märkas med en lägre ”precedence”-nivå, och genom att anordna för en relativ differentiering mellan nämnda tre nivåer när den genomsnittliga kölängden för de två högsta ”precedence”-nivåerna överstiger båda trösklar.
10. En metod, enligt patentkrav 9, k ä n n e t e c k n a d av att fler än tre ”drop precedence”-nivåer anordnas för, och en genomsnittlig kölängdsparameter används för varje ”drop precedence"-nivå med associerade trösklar min_th_#s och max_p#s.
11. ll. En metod, enligt patentkrav 10, k ä n n e t e c k n a d av åtta ”dro recedence”-nivåer. P P
12. En metod, enligt antingen patentkrav 10, eller ll, k ä n n e t e c k n a d av en enda minimumtröskel, th_in, för alla ”precedence”-nivåer, så att inga paket ”droppas” om den genomsmittliga kölängden är mindre än th_in.
13. En metod för aktiv köhantering, för att hantera prioriterad trafik i ett datapaketförmedlande system, anpassad till anordnad differentiering mellan trafik som härrör från ”rate”-anpassade applikationer som reagerar på förlust av datapaket, i vilken trafik tilldelas en, av åtminstone en första och andra, ”drop precedence”-nivå, nämligen inom profil och utanför profil, k ä n n e t e c k n a d av att: - en genomsnittlig kölängd, avg_ql, beräknas; - minimumtrösklar, min_th_in och min_th_out, för paket inom profil, respektive paket utanför profil, och en maximumtröskel, max_th, tilldelas; N 20 25 30 35 . < < . . _ 514 313 36 - alla paket bibehålles med deras ursprungligen tilldelade ”drop precedence”-nivåer, så länge den - genomsnittliga kölängden är mindre än, eller lika med, en tröskel th_in; - en ”drop”-sannolikhet, bestämd av den genomsnittliga kölängden, tilldelas varje paket; - alla paket bibehålles så länge avg_ql är mindre än th_in; och - paket ”dropped/tappas” enligt deras tilldelade ”drop”-sannolikhet; och av att max_p_out är större än max_p_in, där max_p_out är den maximala ”drop”-sannolikheten för paket som är märkta som utanför profil, och max_p_in är den maximala ”drop”-sannolikheten för paket som är märkta som inom profil.
14. k ä n n e t e c k n a d av att nämnda metod tillämpas på en FIFO-kö. En metod, enligt patentkrav 13,
15. En metod, enligt patentkrav 13, eller 14, k ä n n e t e c k n a d av att: - ett paket ”is dropped” om avg_ql, när paketet anländer, är >max_th; - för ett paket märkt som inom profil, beräknas avg_ql_in, och beräknas Pin om avg_ql_in > th_in och min_th_in < avg_ql, och nämnda paket ”is eller behàlles, dropped”, enligt värdet på Pin. w 15 20 25 30 35 514 313 37 - för ett paket märkt som utanför profil, beräknas Pout om min_th_out < avg_ql, och ”is dropped", eller behàlles, nämnda paket enligt värdet på Pout.
16. k ä n n e t e c k n a d av att ett flertal ”drop En metod, enligt något av patentkraven 13 till 15, precedence”-nivåer, flera än två, används, och av att en genomsnittlig kölängd hämtas för varje ”drop precedence”- nivå.
17. k ä n n e t e c k n a d av att max_th för varje En metod, enligt något av patentkraven 15, eller 16, ”drop precedence”-nivå sättes till samma värde.
18. En metod, enligt antingen patentkrav 16, eller 17, k ä n n e t e c k n a d av tre "drop precedence”-nivåer, och av att en genomsnittlig kölängd för varje ”drop precedence”-nivå beräknas baserad på datapaket märkta med denna nivå, och datapaket märkta med en högre ”drop precedence”-nivå.
19. En metod, enligt patentkrav 18, k ä n n e t e c k n a d av en unik tröskel tilldelas var och en av de två högst prioriterade ”precedence”-nivåerna, där nämnda unika trösklar används för att bestämma när ett datapaket skall märkas med en lägre ”precedence”-nivå, och av att en relativ differentiering anordnas för mellan nämnda tre nivåer när den genomsnittliga kölängden för de två högsta ”precedence”-nivåerna överstiger båda trösklar. 20. k ä n n e t e c k n a d av att fler än tre ”drop En metod, enligt patentkrav 19, precedence”-nivåer anordnas för, och en genomsnittlig 15
20. 25 . . . . . . 514 315 38 kölängdsparameter för varje ”drop precedence”-nivå används med associerade trösklar min_th#s och max_p#s.
21. En metod, k ä n n e t e c k n a d av åtta ”drop precedence”-nivåer. enligt patentkrav 20,
22. En metod, enligt antingen patentkrav 20, eller 21, k ä n n e t e c k n a d av en enda minimumtröskel, th_in, för alla ”precedence”-nivåer så att inga paket förloras om den genomsnittliga kölängden är mindre än th_in. 23. Ett telekommunikationssystem för överföring av paketförmedlad data, k ä n n e t e c k n a t av att nämnda telekommunikationssystem använder en metod för aktiv köhantering enligt något av patentkraven 1 till 22.
23. Ett telekommunikationssystem enligt patentkrav 23, k ä n n e t e c k n a t av att nämnda telekommunikationssystem är ett Internet.
24. En router för användning i ett telekommunikationssystem enligt antingen patentkrav 23, eller 24, använder en metod för aktiv köhantering enligt något av patentkraven 1 till 12. k ä n n e t e c k n a d av att nämnda router 514 315 %,=¥1t%«ëÅl%lli~;;; it;% 3% Parametern max_p_out är större än max_p_in, där max_- p_out är den maximala ”drop”-sannolikheten för paket som är markerade som utanför profil, och max_p_in är den maximala ”drop”-sannolikheten för paket som är markerade som inom profil.
SE9901236A 1999-04-07 1999-04-07 Förbättringar av, eller med avseende på, datapaketförmedling SE514313C2 (sv)

Priority Applications (10)

Application Number Priority Date Filing Date Title
SE9901236A SE514313C2 (sv) 1999-04-07 1999-04-07 Förbättringar av, eller med avseende på, datapaketförmedling
DE60044805T DE60044805D1 (de) 1999-04-07 2000-04-07 Verfahren, system und router zur aktiven warteschl
EP00919246A EP1171977B1 (en) 1999-04-07 2000-04-07 Method, system and router providing active queue management in packet transmission systems
EEP200100523A EE04980B1 (et) 1999-04-07 2000-04-07 Meetod aktiivse j„rjekorrahalduse tagamiseks prioriteetse liikluse haldamiseks pakettedastuses ja sidessteem
PCT/SE2000/000665 WO2000060817A1 (en) 1999-04-07 2000-04-07 Method, system and router providing active queue management in packet transmission systems
AT00919246T ATE477645T1 (de) 1999-04-07 2000-04-07 Verfahren, system und router zur aktiven warteschlangenverwaltung in paketübertragungssystemen
DK00919246.9T DK1171977T3 (da) 1999-04-07 2000-04-07 Fremgangsmåde, system og router, der tilvejebringer aktiv køadministration i pakketransmissionssystemer
US09/926,280 US7139281B1 (en) 1999-04-07 2000-04-07 Method, system and router providing active queue management in packet transmission systems
ES00919246T ES2349159T3 (es) 1999-04-07 2000-04-07 Procedimiento, sistema y encaminador para proporcionar una gestión de cola activa en sistemas de transmisión de paquetes.
NO20014498A NO332566B1 (no) 1999-04-07 2001-09-17 Fremgangsmate, system og ruter for aktiv kostyring i telekommunikasjonssystemer

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
SE9901236A SE514313C2 (sv) 1999-04-07 1999-04-07 Förbättringar av, eller med avseende på, datapaketförmedling

Publications (3)

Publication Number Publication Date
SE9901236D0 SE9901236D0 (sv) 1999-04-07
SE9901236L SE9901236L (sv) 2000-10-08
SE514313C2 true SE514313C2 (sv) 2001-02-12

Family

ID=20415132

Family Applications (1)

Application Number Title Priority Date Filing Date
SE9901236A SE514313C2 (sv) 1999-04-07 1999-04-07 Förbättringar av, eller med avseende på, datapaketförmedling

Country Status (10)

Country Link
US (1) US7139281B1 (sv)
EP (1) EP1171977B1 (sv)
AT (1) ATE477645T1 (sv)
DE (1) DE60044805D1 (sv)
DK (1) DK1171977T3 (sv)
EE (1) EE04980B1 (sv)
ES (1) ES2349159T3 (sv)
NO (1) NO332566B1 (sv)
SE (1) SE514313C2 (sv)
WO (1) WO2000060817A1 (sv)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7215637B1 (en) 2000-04-17 2007-05-08 Juniper Networks, Inc. Systems and methods for processing packets
US7688727B1 (en) * 2000-04-17 2010-03-30 Juniper Networks, Inc. Filtering and route lookup in a switching device
EP1220493A1 (en) 2000-12-28 2002-07-03 Alcatel Marker device and related method
US6831891B2 (en) * 2001-03-06 2004-12-14 Pluris, Inc. System for fabric packet control
EP1249972A1 (en) * 2001-04-09 2002-10-16 Telefonaktiebolaget L M Ericsson (Publ) Method of controlling a queue buffer
GB2372172B (en) 2001-05-31 2002-12-24 Ericsson Telefon Ab L M Congestion handling in a packet data network
US7349336B2 (en) * 2002-06-04 2008-03-25 Lucent Technologies Inc. Random early drop with per hop behavior biasing
WO2004004275A1 (en) * 2002-06-27 2004-01-08 Nokia Corporation Self-adaptive scheduling method and network element
GB2395856A (en) * 2002-11-26 2004-06-02 King S College London Method for reducing packet congestion at a network node
JP4080911B2 (ja) * 2003-02-21 2008-04-23 株式会社日立製作所 帯域監視装置
US7372814B1 (en) * 2003-02-27 2008-05-13 Alcatel-Lucent Network system with color-aware upstream switch transmission rate control in response to downstream switch traffic buffering
ES2229917B1 (es) * 2003-07-15 2006-07-01 Diseño De Sistemas En Silicio, S.A. Procedimiento de gestion dinamica de recursos de sitemas de telecomunicaciones en funcion de la calidad de servicio y del tipo de servicio.
US7391722B2 (en) * 2004-02-17 2008-06-24 Alcatel Lucent Method and system for determining link congestion
US7567508B2 (en) 2005-05-23 2009-07-28 Cisco Technology, Inc. Method and system for providing delay bound and priortized packet dropping
WO2008001580A1 (fr) * 2006-06-29 2008-01-03 Nec Corporation Dispositif de communication et procédé
US8238361B2 (en) * 2006-12-18 2012-08-07 Telefonaktiebolaget Lm Ericsson (Publ) Scheduling and queue management with adaptive queue latency
US7697532B2 (en) * 2007-02-08 2010-04-13 Corrigent Systems Ltd. Frame concatenation with drop precedence assignment
KR101075724B1 (ko) * 2007-07-06 2011-10-21 삼성전자주식회사 통신 시스템에서 패킷 전송 속도 제한 장치 및 방법
JP4704500B2 (ja) * 2007-07-27 2011-06-15 富士通株式会社 パケット処理装置
US7756044B2 (en) * 2008-07-31 2010-07-13 Microsoft Corporation Inverse multiplexing heterogeneous wireless links for high-performance vehicular connectivity
US20100027563A1 (en) * 2008-07-31 2010-02-04 Microsoft Corporation Evolution codes (opportunistic erasure coding) platform
US20100064072A1 (en) * 2008-09-09 2010-03-11 Emulex Design & Manufacturing Corporation Dynamically Adjustable Arbitration Scheme
GB2478277B (en) * 2010-02-25 2012-07-25 Skype Ltd Controlling packet transmission
CN102469510A (zh) * 2010-11-11 2012-05-23 中兴通讯股份有限公司 用于3g网络视频传输的内容感知主动队列管理方法
US8593972B2 (en) * 2011-09-29 2013-11-26 Cisco Technology, Inc. Method to verify a drop probability curve
US8824328B2 (en) * 2012-02-29 2014-09-02 Infosys Limited Systems and methods for optimizing the performance of an application communicating over a network
WO2013132213A1 (en) 2012-03-09 2013-09-12 British Telecommunications Public Limited Company Signalling congestion
US9473974B2 (en) 2012-05-30 2016-10-18 The University Of Hong Kong Enhancing AQM to combat wireless losses
US9680760B2 (en) * 2013-07-16 2017-06-13 Cisco Technology, Inc. Adaptive marking for WRED with intra-flow packet priorities in network queues
US9948561B2 (en) * 2015-04-14 2018-04-17 Cisco Technology, Inc. Setting delay precedence on queues before a bottleneck link based on flow characteristics
CN105425590B (zh) * 2015-12-31 2018-01-09 河南科技大学 一种基于改进免疫算法的pid主动队列管理方法
CN109787922B (zh) * 2017-11-13 2020-08-21 中国移动通信集团公司 一种获取队列长度的方法、设备及计算机可读存储介质
CN114531399B (zh) * 2020-11-05 2023-09-19 中移(苏州)软件技术有限公司 一种内存阻塞平衡方法、装置、电子设备和存储介质
CN113590030B (zh) * 2021-06-30 2023-12-26 济南浪潮数据技术有限公司 一种队列调度方法、系统、设备以及介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4323405A1 (de) 1993-07-13 1995-01-19 Sel Alcatel Ag Zugangskontrollverfahren für einen Pufferspeicher sowie Vorrichtung zum Zwischenspeichern von Datenpaketen und Vermittlungsstelle mit einer solchen Vorrichtung
FI951278A0 (fi) 1995-03-17 1995-03-17 Finland Telecom Oy Foerfarande och arrangemang foer att behaerska en buffert i ett ATM-naet
US6092115A (en) 1997-02-07 2000-07-18 Lucent Technologies Inc. Method for supporting per-connection queuing for feedback-controlled traffic
US6252848B1 (en) * 1999-03-22 2001-06-26 Pluris, Inc. System performance in a data network through queue management based on ingress rate monitoring

Also Published As

Publication number Publication date
EP1171977B1 (en) 2010-08-11
ATE477645T1 (de) 2010-08-15
NO20014498D0 (no) 2001-09-17
EP1171977A1 (en) 2002-01-16
SE9901236L (sv) 2000-10-08
ES2349159T3 (es) 2010-12-28
NO20014498L (no) 2001-12-06
WO2000060817A1 (en) 2000-10-12
EE04980B1 (et) 2008-02-15
EE200100523A (et) 2002-12-16
US7139281B1 (en) 2006-11-21
NO332566B1 (no) 2012-10-29
DK1171977T3 (da) 2010-12-06
SE9901236D0 (sv) 1999-04-07
DE60044805D1 (de) 2010-09-23

Similar Documents

Publication Publication Date Title
SE514313C2 (sv) Förbättringar av, eller med avseende på, datapaketförmedling
Feng et al. BLUE: A new class of active queue management algorithms
EP2195973B1 (en) Methods and apparatus for providing congestion information
US8717893B2 (en) Network stabilizer
EP1249103A2 (en) Domain based congestion management
WO2003045028A1 (en) Method and system for handling network congestion
Bodin et al. Load-tolerant differentiation with active queue management
US8264957B1 (en) Control of preemption-based beat-down effect
Abbas et al. A stateless fairness-driven active queue management scheme for efficient and fair bandwidth allocation in congested Internet routers
Andrikopoulos et al. A fair traffic conditioner for the assured service in a differentiated services internet
Li et al. Providing flow-based proportional differentiated services in class-based DiffServ routers
Kamra et al. Fair adaptive bandwidth allocation: a rate control based active queue management discipline
Mohammed et al. Active queue management for congestion control: Performance evaluation, new approach, and comparative study
Zhu et al. Weighted fair bandwidth sharing using scale technique
Pauwels et al. A multi-color marking scheme to achieve fair bandwidth allocation
Kumhar Performance Analysis of AQM Algorithms in Network Congestion Control.
Li et al. A novel core‐stateless ABR‐like congestion avoidance scheme in IP networks
Krasser et al. Online traffic engineering and connection admission control based on path queue states
Menth Efficiency of PCN-based network admission control with flow termination
Vivanco et al. Bandwidth brokering and dynamic resource allocation in DiffServ domains for heterogeneous applications
Thiruchelvi et al. An adaptive congestion control mechanism for unresponsive flows
Rao et al. Stability analysis of compound TCP with adaptive virtual queues
Joo et al. Assuring drop probability for delay-insensitive traffic in a differentiated service network
Curado et al. Queue Management and QoS Routing for Traffic Differentiation.
Kamra et al. Fair adaptive bandwidth allocation: a rate control based

Legal Events

Date Code Title Description
NUG Patent has lapsed