[LARTC] SFQ clarification

[Gregory Maxwell greg@linuxpower.cx]

<PRE>On Fri, Feb 09, 2001 at 05:38:18PM -0800, Don Cohen wrote:
&gt;<i> <A HREF="http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html">http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html</A>
</I>&gt;<i> 9.2 Stochastic Fairness Queueing 
</I>&gt;<i> says:
</I>&gt;<i>  SFQ however cannot determine interactive flows from bulk ones -- one
</I>&gt;<i>  usually needs to do the selection with CBQ before, and then direct the
</I>&gt;<i>  bulk traffic into SFQ.  
</I>&gt;<i> 
</I>&gt;<i> I don't understand this.  You want to give preference to the non-bulk
</I>&gt;<i> traffic, right?  And this is what you get if you just put it all into
</I>&gt;<i> the same SFQ, right?  All the small flows get fast service and the 
</I>&gt;<i> large flows fairly share what's left.  That seems like what you want.
</I>&gt;<i> So it's true that SFQ does not distinguish bulk from interactive flows
</I>&gt;<i> but there's no need to.
</I>
No, in the context of network queue management bulk means non-interactive,
batch might be a better word. 

SFQ classfies packets by computing hash(shost,dhost,sport,dport,proto,seed)
where hash produces an output of 0-1023. The system then creates 1024 queues
(virtually) and pulls a single packet from each one in a round-robin fashion.
(roughly)

Thus each of these 1024 buckets gets an equal chance at bandwidth. As the
number of flows approaches 1024 the probability of two flows ending up in
the same bucket approaches 100%. Two flows in the same bucket fight over
bandwidth as do flows in a classic tail-drop router.  At a regular interval
the 'seed' is changed to cause differnt flows to be batched togeather.

Notice above I said, 'equal chance' at bandwith. That doesn't mean equal
bandwidth. Consider 3 active buckets, one with your slogin text, two with
outbound file transfers. It will transmit one character (perhaps, depends on
nagle) of your slogin, then two ~1500byte file transfer packets, then
another few bytes of telnet, then it has to wait for another two 1500byte
file transfer packets. Not exactly fair..

So SFQ is only fair when all the needs are simmlar..

So, the preferable queue arrangement could be something like something like:

             1[TBF]-[TOS: Minimize delay]
[eth]-[PRIO]/2[SFQ]-[EVERYTHING ELSE]
            \3[SFQ]-[TOS: Lowest cost]

The TBF on the minimize delay is just prudence to prevent 'wow, if I check
minimize delay I can transfer big files FAST'

Unfortunatly, Linux currently doesn't have any SF red queues (or SFB) which
would have improved performance over SFtail-drop (which is what SFQ is).
Additionally, Linux doesn't allow you do specify the hash size for your SFQ,
which could make it less useful in some situations.


</PRE>