Re: Quality of Service in GNOME

[Samuel Abels <newsgroups debain org>]

On Fr, 2005-09-16 at 17:43 -0400, Mark Drago wrote:
> On Fri, 2005-09-16 at 23:06 +0200, Samuel Abels wrote:
> > Are there any plans to implement network traffic prioritization in
> > GNOME? What I mean is a just-works, configuration-free solution, in
> > which applications (indirectly) indicate a traffic type to the
> > kernel-level scheduler/queue. For example, give the application that has
> > currently focus a higher network priority, or make that VoIP application
> > work perfectly even if you have a few downloads/bittorrent running, etc.
> 
> The default queuing discipline on Linux is pfifo_fast.

I admit I did not look into that queueing mechanism before, expecting
the default to be a single FIFO queue. However I looked into it now and
I conclude that for desktop users this mechanism does in most cases not
provide any advantage over a FIFO queue.

For those (like me) who want to get familiar with fifo_fast quickly:

fifo_queue is a triple strict priority queue: queue 1 is always served
before queue 2, and queue 0 has strict priority over queue 1. As the
name says, packet reordering does never happen.
This mechanism has obvious disadvantages (higher priority queue cause
stagnation) and can also causes jitter.

Also, it is mostly ineffective for desktop use. For example, downloading
a file in Nautilus, this caused web browsing in Epiphany to stagnate or
at least slow down painfully - obviously because both traffic types end
up in the same FIFO queue, and in FIFO a higher percentage of packets is
dropped from lower traffic streams. It is entirely good behaviour that
none of the applications modifies the ToS bit though - firstly, they are
similar types of traffic, and secondly, if Nautilus (=gnome-vfs)
requested a lower priority, it might be stagnated by, for example, a
running bittorent client.

In summary, by using the default queueing mechanism of Linux, getting
QoS "right" is still not possible:

- three FIFO queues are not enough, in most desktop use cases it
performs just like a single FIFO queue would
- fifo_fast is not fair
- FIFO queues don't handle jitter well
- fifo_fast provides no traffic shaping mechanism
(- fifo_fast allows no bandwidth reservation)

Still, the stagnation is only partly the scheduler's fault. Regardless
of the queueing mechanism, Epi should have a higher traffic priority *if
it is the window that currently has focus*.

The Linux kernel also supports SFQ, which is a little better, though an
optimal queueing mechanism for desktop use would probably be a weighted
fair queue with an additional priority queue with a bandwidth limit.

However, even that mechanism would benefit greatly from good, dynamic
ToS settings but that does not work if applications do not set the ToS
correctly. 

> It might be
> nice to expose this easily in our networking APIs though.

Yes, things like "give the application that has focus a higher priority,
but do not stagnate others" could be implemented only through a
combination of a better scheduler and a common API that obeys the rules
that the desktop environment may enforce on an application.

-Samuel