sfx2000
Part of the Furniture
(I'm posting this as it seems to be a big forum issue at the moment, many seem to get confused about this)
QOS classifying and scheduling at a high level really comes down to this...
Queue - 3 parameters. N1, D, and N2. Where:
So we build a queue.... let's say VOIP # this is just an example, and I'm trying to make this really simple
(Note - N1 can never exceed N2, FWIW, if that's not obvious)
Repeat this as needed for different traffic types...
We build many queues - based on 4 basic classifiers - VOIP, Video, Best Effort, Background - now we can tag queues based on ports (ethernet), ports (applications), even MAC/IP addresses. Queues define the priority, on a single LAN, or even across multiple LAN's, as they can be hierarchal, and we can score them accordingly...
Most QoS classifiers - even DPI and SPI, do similar things - but it's the scheduling of the Queues that is special, whether it is fq_codel, codel, hfsc, pirq, cbs, etc...
It really comes down to requested bandwidth, delay, and available bandwidth - that's why in many consumer grade routers, it's really import to set the limits on the WAN side - as the classifiers on the LAN side are pretty much asymmetric in many cases...
Notice, this is all a whitelist approach, but generally QoS is just that - reserve, not limit...
I use these four app flows for WiFi, but there are additional application flows spec'ed out across IEEE/IETF/3GPP/3GPP2...
QOS classifying and scheduling at a high level really comes down to this...
Queue - 3 parameters. N1, D, and N2. Where:
N1 = bandwidth needed in d time
N2 = max bandwidth for the queue
D = delay(in milliseconds)
N2 = max bandwidth for the queue
D = delay(in milliseconds)
So we build a queue.... let's say VOIP # this is just an example, and I'm trying to make this really simple
N1 = 96oo bps (let's say EVRC voice codec)
N2 = 64,000 bps (PCM audio)
D = 80 mSec (cdma framing time)
This means that we want in D time, N1 traffic gets served without checking N2, and then we check N2 to see if the limit has been reached and /or continue, else, we check to see if there is more bandwidth. If there is no more bandwidth, then the Queue priority seizes the required bandwidth and moves on...N2 = 64,000 bps (PCM audio)
D = 80 mSec (cdma framing time)
(Note - N1 can never exceed N2, FWIW, if that's not obvious)
Repeat this as needed for different traffic types...
We build many queues - based on 4 basic classifiers - VOIP, Video, Best Effort, Background - now we can tag queues based on ports (ethernet), ports (applications), even MAC/IP addresses. Queues define the priority, on a single LAN, or even across multiple LAN's, as they can be hierarchal, and we can score them accordingly...
Most QoS classifiers - even DPI and SPI, do similar things - but it's the scheduling of the Queues that is special, whether it is fq_codel, codel, hfsc, pirq, cbs, etc...
It really comes down to requested bandwidth, delay, and available bandwidth - that's why in many consumer grade routers, it's really import to set the limits on the WAN side - as the classifiers on the LAN side are pretty much asymmetric in many cases...
Notice, this is all a whitelist approach, but generally QoS is just that - reserve, not limit...
I use these four app flows for WiFi, but there are additional application flows spec'ed out across IEEE/IETF/3GPP/3GPP2...