De grootte van de buffer is niet relevant.
Je kan quality of service technieken voor IP grofweg in een 3tal technieken onderverdelen.
1. Policing
Er wordt niet met queues gewerkt, verkeer boven de ingestelde limiet wordt simpelweg gedropt.
Deze techniek is heel simpel en vereist geen complexe code. Het nadeel is dat je bij bijv TCP retransmissies krijgt en dus je bandbreedte niet optimaal meer gebruikt.
2. TCP-aware algoritmes
Hierbij wordt er gebruik gemaakt van een aantal eigenschappen van het TCP protocol. Een router waar het verkeer doorstroomt, kan zelf de window size van TCP connecties aanpassen om zo per flow een snelheidslimiet in te stellen. Dit klinkt mooi, maar in praktijk is dit een heel stuk complexer omwille van het feit dat je ook delays in rekening moet brengen. Het resultaat is dat je met deze aanpak geen nauwkeurige regeling kan doen.. enkel wat best-effort zonder garanties. Er zijn een aantal proprietaire algoritmes die deze aanpak (met wisselend succes) proberen te gebruiken.
Een andere techniek is Delayed-Ack. Hierbij worden de (upload) ack packetjes van een connectie vertraagd om zo tot een snelheidsregeling te komen in de download richting. Dit geeft betere en robuustere resultaten dan de window size adjustment technieken. Hiervan bestaat geen opensource code. Belangrijk is echter om te weten dat geen van deze technieken echt goed werkt zonder er ook een queueing systeem aan te hangen. Verder werken deze technieken niet met bijv udp of icmp verkeer.
3. Queueing
Hier werk je met queues. Binnenkomende packetjes worden in een wachtrij gestoken en worden tegen een ingestelde snelheid uit de wachtrij gehaald en verder doorgestuurd. Deze techniek wordt hoofdzakelijk gebruikt in linux TC. Om packetjes te dequeuen, zijn er verschillende algoritmes beschikbaar. Helaas zijn de beschikbare algoritmes in Linux vrij rudimentair en zijn de meer geavanceerdere algoritmes (die ook betere qos bieden) zoals STFQ, WF2Q+ niet standaard beschikbaar.
Als je enkel de standaard beschikbare algoritmes in rekening zou brengen, krijg je in praktijk de beste resultaten door HTB te combineren met SFQ. HTB om verkeer in klassen in te delen (voip, web, ssh,...) en SFQ om per klasse verkeer de dequeuen. Je kan genoeg voorbeeldjes vinden hierover met google
Een andere optie is om HFSC te gebruiken, maar dit is een stuje moeilijker op te zetten.
Qua plaats van de regeling:
Voor uploadverkeer klinkt het het meest logisch om dat te doen op je router (tussen je LAN en je WAN verbinding). Je hebt dan volledige controle over het verkeer dat jij uitstuurt.
Voor downloadverkeer is het ideaal om dat bij de ISP te doen voordat het verkeer naar jou wordt doorgestuurd. Maar in praktijk is het ook ook goed om dat op je router te doen en het verkeer enkel te limiteren naar je LAN. Omwille van de eigenschappen van het TCP protocol, zal de verbinding aan de WAN kant dan ook vertraagd worden zonder dat er retransmits zijn en heb je op die manier ook controle. Voor UDP verkeer werkt dit niet en daar kan je niets aan doen in de download richting.
Om de beste resultaten te krijgen, moet je de snelheden zo instellen dat er nergens anders queues worden opgebouwd in de rest van het netwerk. Je dient dus de snelheid van WAN naar LAN zo in te stellen dat deze net onder de snelheidslimiet ligt van je adsl of vdsl verbinding. Ook voor upload, stel je je eigen limiet in zodat deze net onder de beschikbare snelheid ligt.
