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

[Richard Nelson]

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

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

Exactly.  There are some new experimental kinds of QoS that do not have
these requirements that might suit a collaborative/experimental type
network.  Internet 2 have started a Scavenger Service, a sort of less
than best effort service.  It works like a nice command in Unix and is
designed to allow large data file transfers in the "background" see
http://qbone.internet2.edu/qbss/    Also, there is the Alternative Best
Effort proposal that provides two equal services, one low delay higher
packet loss for real time services and one low loss higher delay for
data services, see http://www.abeservice.com/   The nice things about
these services is that the default is conventional FIFO best effort so
they still work if not every node implements them (although preferrably
the highly loaded links should), there is no better than best effort
service, so nothing to steal = no policing and the policies are very
simple as you don't have to decide who to give the better service to.
> 
> [...]
> 
> >> 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?

There are some predefined ones, Expedited Forwarding, a low latency
service, possibly with higher drop rate for real-time services and
Assured Forwarding, a better than best effort service given priority
when congestion occurs.  There are a number of grades of AF class.  In
addition there are a lot of unassigned DSCP values so that network
managers can create their own classes.

I don't think the limitations of the TOS flags definition was really the
small number of classes available.  I suspect that running more than
three or so classes on a network would lead to horrific complexity .  It
was more a case that there was no consistant definition of what the
flags actually meant and how they should be implemented.  The TOS bits
were individual flags that could be set independently and then they
conflicted,  I think from memory that if they were all set you had a
completely circular definition.  Anyway, with diffserv there are some
reasonably well defined implementation recommendations, CBQ and RED
mainly.
> 
> > 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.
> 
Complexity is the crux of Internet QoS.  The Internet is popular because
it is cheap and fast.  It is cheap and fast because it is simple 
(Cheap, Fast, Complex Service - choose any two).  Diffserv was designed
to be simple enough to be scalable, but even it may not be simple enough
in many situations.  


Richard.

>         Daniel
>

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