Well, SFQ isn't specifically "better" for PPPoE vs. any other queue, as much as it's a more appropriate queue-type for queuing an individual connection that can become congested. Strictly speaking, a "default-small" queue, which is a PFIFO type, is fine for a PPPoE queue, too, if the amount of packets that can be queued is increased beyond the default of 10, which isn't enough for a higher speed service (like over 15-20 Mbps). However, FIFO as a scheduling mechanism isn't very effective and it allows a single flow to consume the entire queue, creating a poorer user experience. Once the queue is full, the last packet(s) in are dropped.

SFQ is a form of fair queuing which has up to 1024 classless sub-queues within it. It can queue up to 128 packets and split them into the sub-queues based on being a unique flow (unique combination of src/dst address and src/dst ports). Each of these 1024 sub-queues are then dequeued in a FIFO fashion, tail-dropping just those queues which are full. In this way, a single flow (say a game download from Akamai), can't consume the entire connection because it is being serviced by its own sub-queue. A VoIP call on the same connection would be in its own sub-queue and dequeued separately from the Akamai download. I'm not trying to imply there is QoS - there isn't, it's strictly trying to be "fair" in releasing packets (i.e. the "classless" part of its definition). To have QoS, would require the use of something that can apply priority based on the characteristics of the flow (i.e. an HTB).

In Mikrotik specifically, the PPPoE server allows queue-type as a choice when establishing what kind of queue to create. If using RADIUS authentication, which can provide attributes like rate-limit or address-list or other things, when the queue is created it will be of the type specified in the PPPoE server profile. If using DHCP with RADIUS, you can't specify the queue type - it will only be default-small, which by default is a PFIFO queue. If the settings for "default-small" are changed to be SFQ, then queues created from a RADIUS-authenticated DHCP lease where a simple queue is created will also get to take advantage of the SFQ type to provide a better experience for the end-user than a FIFO queue.

Preseem uses FQ_Codel queue type, which is a hybrid between SFQ and Codel. It combines the scheduling mechanism that SFQ affords, with QoS and other buffer management that Codel provides.

That's my 1.7 cents worth on the matter. Others probably have a better understanding of it.



Jesse DuPont

Owner / Network Architect
email: [email protected]
Celerity Networks LLC / Celerity Broadband LLC
Like us! facebook.com/celeritynetworksllc

Like us! facebook.com/celeritybroadband

 

On 2/15/21 9:37 AM, Adam Moffett wrote:

I have heard SFQ before, but I never heard why.  I'd like to be enlightened if anyone knows why.


On 2/15/2021 11:05 AM, Jesse DuPont wrote:
SFQ is right choice for a PPPoE session.


Jesse DuPont

Owner / Network Architect
email: [email protected]
Celerity Networks LLC / Celerity Broadband LLC
Like us! facebook.com/celeritynetworksllc

Like us! facebook.com/celeritybroadband

 

On 2/15/21 8:36 AM, Matt wrote:
For those using Mikrotik for a PPPoE server, what queue type are you using?





-- 
AF mailing list
[email protected]
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

Reply via email to