[MLB-WIRELESS] Packet scheduling [aka: What do people want to dowith the wirele ss connection?]

[Daniel Pittman]

On Tue, 13 Nov 2001, Richard Nelson wrote:
> Daniel Pittman wrote:
>> On Tue, 13 Nov 2001, Tyson Clugg wrote:

[...]

>> > Don't most apps already set this to appropriate values?
>> 
>> No, never.
> 
> You can get some apps that do this, but mostly they are specially
> patched versions for research purposes. "Never" is to all intents
> true.

Well, I believe that there must have been some codebase out there that
used the TOS field and the security level field in practice. I never
worked on code old enough to touch it, though. ;)

[...]

> Linux is FIFO by default as are all best effort routers. AFAIK the old
> TOS based scheduling has never been implemented.

That makes a lot of sense. I didn't think I had missed something, but
it's nice to have it confirmed.

[...]

>> If you want to use it, though, you will need to use netfilter[1] to
>> mangle packets to carry the right TOS when they hit the border of the
>> network.
> 
> This is the main problem with Diffserv (or ToS) queueing networks. 
> Even if your apps did set the DSCP correctly you would still have to
> do this kind of filtering and marking on every single interface into
> the network for policing reasons. 

Well, it does depend a little on what sort of network you envision and
what level of reliability you need.

If I were running a wireless network[1], I wouldn't be making any
promise other than to give a best effort service...

> Otherwise someone is going to tweak their app to use the best
> performance class and steal some performance at the cost of everybody
> else. 

..and I would happily refuse service to hostile users on the network.
Actually, I would probably just throw them into their own token bucket
and throttle their service through my parts of the network all to heck,
but that's neither here nor there.

> This problem of having to install filtering on every single interface
> has somewhat slowed the deployment of Diffserv and probably would make
> it impractical for a collaborative effort network.

That's the real problem. You need a coherent policy across the entire
network, not to mention support for the queue policies on all routing
nodes[2] in the tree...

[...]

>> Note that you can do exactly the same thing by using the firewall
>> mark as a routing key under netfilter, giving you some thousands of
>> different types of service, not just three.
> 
> There are 6 bits available for marking DSCPs that gives you 64
> classes. 

Ah, cool. That's nice. I wondered if the silly limit on classes that the
TOS implementation had would go away. So, there are a set of well
defined classes in there already, such that you could just use the
standard diffserv classes on a network?

> If you want to do the thousands option you have to do the filtering at
> core nodes as well as ingress nodes. Maybe a wireless network doesn't
> have core nodes in the traditional sense. You also have to managed
> thousands of classes....

Given that I didn't know you could step aside from the TOS limit of
three classes plus "normal", FWMark seemed useful because it lifted an
otherwise arbitrary limitation and let you do QOS on a protocol basis
rather than a more limited TOS basis.

DiffServ sounds like if fixes that without the complexity, which is
nice.

        Daniel


Footnotes: 
[1]  Which, I confess, I am not.

[2]  I assume that anyone sane is running a routed, not bridged, network
     -- if they want diffserv and friends, anyway.

-- 
Fortune rarely accompanies anyone to the door.
        -- Balthasar Gracian

--
To unsubscribe, send mail to minordomo at melbwireless.dyndns.org with a subject of 'unsubscribe melbwireless'  
Archive at: http://melbwireless.dyndns.org/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
IRC at: au.austnet.org #melb-wireless