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

[Richard Nelson]

Daniel Pittman wrote:
> 
> On Tue, 13 Nov 2001, Tyson Clugg wrote:
> 
> [...]
> 
> > Off the top of my head, isn't there a QOS field in the TCP/IP header
> > that is indicitave of the importance of the packet?
> 
> Not really. There is a type-of-service field that let's you ask for low
> latency, low cost or high bandwidth.


The old ToS definition is slowly disappearing in favour of the DiffServ
Code Point.  It is the same bits in the header, but it lets you mark
packets as belonging to specific classes.  There are a few predefined
classes or you can define your own.

> 
> > 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.
 
> > The real question is do routers acutally *use* this information when
> > doing packet scheduling, or do most routers simply fire the packets
> > out FIFO style?
> 
> FIFO, mostly.
> 
> > How can linux or any other OS be told what to do with important
> > packets?
> 
> The Linux TCP/IP scheduler is rumored to do multi-queue based on the TOS
> field by default, but I never saw evidence of it when I wandered around
> the code.

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

> 
> Empirical testing on slow links (when I still had them) showed this to
> be ineffective in the face of low bandwidth/high latency links, if it
> was active at all. Not that this is a surprise...
> 
> The alternate set of schedulers allow you to use TOS as a routing key
> and, thus, to apply different QOS rules to the various types.
> 
> 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.  Otherwise someone is going to tweak their app to
use the best performance class and steal some performance at the cost of
everybody else.  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.  

> 
> Then, that same machine can have a few buckets into which it tosses the
> packets. You will have trouble getting *really* good, fair filtering,
> though, in what experience I have.[2]
> 
> 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. 
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....

>         Daniel
> 
> Footnotes:
> [1]  ...or your firewall technology of choice.
> 
> [2]  I don't do this for a job or anything. :)
> 
> --
> Books won't stay banned. They won't burn. Ideas won't go to jail. In the
> long run of history, the censor and the inquisitor have always lost.
>         -- A.W. Grisold
> 
> --
> 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

--
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