<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/09/2013 01:30 PM, Luigi Rizzo
wrote:<br>
</div>
<blockquote
cite="mid:CA+hQ2+iSUoyCoqQY_cSq34rw3dTQ8oTC=SKDrpt4q6a=W02KyA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<font face="courier new,monospace"><br>
</font><br>
<div class="gmail_quote">On Fri, Aug 9, 2013 at 1:02 PM,
MUSCARIELLO Luca OLNC/OLN <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:luca.muscariello@orange.com" target="_blank">luca.muscariello@orange.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 08/09/2013 11:35 AM, Paolo Valente wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
>1) AFAIK, sch_drr.c is class-based queuing and not
per-flow queuing (correct me if I am wrong).<br>
</blockquote>
Certainly it is a classful queueing discipline. Just to
sync with you, what do you mean with per-flow as opposed
to class-based?<br>
Do you mean that the scheduler internally and autonomously
differentiates packets into distinct flows according to
some internal classification rule (as it is the case for
SFQ)?<br>
If so, then you are right.<br>
</blockquote>
<br>
</div>
Class-based queuing and flow-based queuing of course are
different things,<br>
but from your demo I got the impressions that you were using
class and flow<br>
interchangeably.<br>
<br>
In practice, I do not see when you would need 500 classes
while it might happen<br>
to have 500 flows (active and in progress ) on a link.<br>
<br>
</blockquote>
<div><br>
</div>
<div>think of an ISP that sells bandwidth to multiple customers.</div>
<div>Then you really want to have one class per customer,
instead</div>
<div>of imposing hard limits on each of them (leading to poor
use</div>
<div>of spare resources), or putting all of them in the same
bucket.</div>
</div>
</blockquote>
<br>
This indeed might happen in the BAS for ADSL users.<br>
<br>
<blockquote
cite="mid:CA+hQ2+iSUoyCoqQY_cSq34rw3dTQ8oTC=SKDrpt4q6a=W02KyA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<div>As a matter of fact, for almost a decade ISPs in various
places</div>
<div>have been using ipfw+dummynet (which includes qfq and other
schedulers)</div>
<div>to sell bandwidth to customers.</div>
</div>
</blockquote>
<br>
I only see the VPN market where this might happen (QoS in various
places),<br>
however queuing is not (hopefully) much deep in the network, and
ISPs (usually) <br>
rely on link over provisioning; so that classes never compete for
bandwidth <br>
(not in the back-haul nor in the transit).<br>
<br>
<blockquote
cite="mid:CA+hQ2+iSUoyCoqQY_cSq34rw3dTQ8oTC=SKDrpt4q6a=W02KyA@mail.gmail.com"
type="cite">
<div class="gmail_quote"><br>
<div>ipfw has some very cheap instructions to flexibly group
flows into classes,</div>
<div>even large numbers of them.</div>
</div>
</blockquote>
<br>
I know, and that's great. <br>
Maybe class is not anymore the right term in this case. It's an
aggregate of flows,<br>
do not know how to call it but not really a class.<br>
<br>
Cheers<br>
Luca<br>
<br>
<br>
<br>
</body>
</html>