Re: [aqm] floating a draft charter

[MUSCARIELLO Luca OLNC/OLN <[e-mail]>]

On 06/05/2013 03:19 PM, Jim Gettys wrote:
>
> On Wed, Jun 5, 2013 at 4:44 AM, Luca MUSCARIELLO 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>     AFAIK, Chipcos for home gateways (Broadcom, Ikanos, Intel),
>     network processors (Cavium),
>     but also Cisco, Juniper and Alcatel-Lucent make a difference
>     between class based queuing and
>     dropping algorithms. The first is implemented everywhere in
>     different ways and I do not think
>     there would be relevant work to do there (except for HTB in Linux
>     which is really bad in terms
>     of performance, IMHO).
>
>     Dropping algorithms is used frequently as a term to describe AQM,
>     e.g. in CLI based configuration
>     systems you may find (in commercial Linux based products) SFQ
>     among the dropping algorithms.
>
>     It is clearly an abuse of language but common practice.  I
>     unfortunately agree with Dave, and we discussed about
>     that in Paris, that chipcos do not take care about flow based
>     queue management (typically withing a given class).
>     Only Linux  does that, but many products make use of Linux only
>     for the slow path while the fast path is managed in hardware.
>
>     Deploying QoS (including de-bloating in QoS) based on Linux is
>     soon broken by the trend to distribute packet processing
>     in dedicated processing units and  chipco ignore completely queue
>     management there.
>     Anytime I ask whether the chip implements deficit round round
>     robin the answer is "of course!" and in the
>     end it  turns out to be *modified* deficit round robin, i.e. class
>     based queuing with up to say 64 queues.
>     Which is not what I am looking for.
>
>     One solution would be to move everything to software, but the cost
>     of the chip that guarantees the same switching
>     throughput is much higher.
>
>
> There are two points I'll react to in this statement:
>
>     1) performance: in the edge of the network, the SOC's used are 
> already very fast and more than fast enough to support algorithms such 
> as fq_codel (much faster than one's wireless or broadband connection).
>
> The existence proofs are running code in OpenWrt on commodity home 
> router SOC's. And when I asked Eric Dumazet about fq_codel 
> performance, he said I could quote him as it taking 2% of a modern x86 
> CPU core at 10G speed.  This was the point at which I got more than 
> moderately excited about this class of algorithms. CPU's are not what 
> they were in the 1980's and 1990's, and we have to get over that and 
> move on.

For what concerns performance, I am thinking about the following kind of 
home gateway.
A triple play offer (voice, Internet, TV)  deployed using a MIPS based 
gateway.
It incorporates 4 Gigabit Ethernet ports, wifi @2.5GHz b/g/n, wifi @5GHz 
a/n,
of course USB, SATA for your local storage.
It must support FTTH and xDSL, IPv4/6 plus some software like samba, DLNA.

For instance:
http://www.ikanos.com/products/communications-processors/fusiv-vx185183/

Packet processing is distributed in hardware to let the central unit 
take care of other stuff.
Do not think to have a multi-core Intel processor there.

You can implement your packet scheduling in hardware (micro code, 
software in the end)
but it is *not* an open environment. You code your queuing now, the 
environment evolves
and nobody maintains your code which is broken as the micro-code evolves.

So the problem is not really software/hardware but open/closed and 
re-usability
(Linux matters not only because it is open but also because it is used 
everywhere).


>
> So if hardware assist is not assisting, we don't have to use it, and 
> it may encourage hardware people to "get it right" the next generation.
>
>    2) most application's performance is now bound by latency, and not 
> bandwidth.  Your web browsing doesn't get appreciably faster adding 
> bandwidth, but improving the latency, even if there is not competing 
> traffic, does improve performance, not to mention improving everything 
> across the board and for most things getting us out of the impossible 
> to configure QOS morass we're in.
>
> As I said, what may be feasible or advisable to do at what point in 
> the network may vary: I don't think this group will *mandate* much at 
> all, but describing what can be used where for best effect is worth a 
> lot, and *possibly* mandating a "first, do no harm" algorithm, even if 
> far from ideal in many circumstances, to prevent no AQM being present 
> at all, which is a headache in today's network.
>
> We're going to have a large number of different drop and queuing 
> algorithms over the coming years, I predict.

Yes, I hope. But if you want them deployed I suspect we'll wait to have 
either open hardware
or to have *true* FQ  in the chip of home gateways. Also because most of 
the delay is measured
in the user's home uplink. Having everything in software is easy and 
useful but does not cover
most of the current market.

Best regards
Luca