Subject: Re: [manet] QoS over a wireless Ad Hoc network

From: Fred Baker <[email-masked]>
Date: Mon, 08 Jul 2002 18:23:56 -0700

At 01:53 PM 6/27/2002 +0100, John Peter Tapsell wrote:
>   I'm trying to find any information on whether I could get QoS over an 
> Ad-Hoc network.

Sorry I'm looking into this late. As someone mentioned, QoS in any network 
has issues, and in an ad hoc network there are more. It is largely a 
question of what you want, what radio technologies you are looking at, and 
what information you have available.

Someone said that diffserv gives you N layers of priority and that's it. 
That is incorrect, from a number of perspectives, and reflects a complete 
misunderstanding of diffserv. If you're looking at diffserv as an 
architecture, I'd suggest that you look at RFC 2474/2475 for a good 
understanding. For a proposed generalized diffserv configuration, you might 
take a look at 
http://www.ietf.org/internet-drafts/draft-ietf-ieprep-packet-marking-policy-00.txt, 
for which there is an update at 
ftp://ftpeng.cisco.com/fred/ieprep/Marking.html

You will notice that there is only one place where we use priority in a 
diffserv configuration: where the application requires management of 
latency or jitter; the key applications for this are in voice and perhaps 
video. Elastic applications, especially those that use short sessions (a 
large percentage) don't require that; they require rate management, not 
jitter management.

Probably the most important single question is your radio environment. If 
you are using a radio technology in which the speakers must vie for access, 
there are interesting questions of whether two stations that cannot hear 
each other can interfere from the perspective of a third station. Most 
radio technologies have interesting problems in transmission physics - 
water, dirt, and stone can materially get in the way, and often appear to 
do so randomly. So your most fundamental QoS issues are not issues of 
message ordering, and cannot be solved by changing that ordering.

Of those that can in fact be changed by message ordering, it seems to me 
that the difficult ones are exacerbated by a radio technology that treats 
the radio as a shared medium like an Ethernet.  The problem there is that 
in a shared environment, the bandwidth or latency guarantees that one seeks 
to make are dependent not only on the availability of bandwidth and my own 
use of it (which is fairly trivial to solve), but on the behavior of 
others. Even if everyone was only allowed to send one message per time 
unit, there is no guarantee that they won't all do so just at the instant 
that I need to be first in line. The way to solve that, generally, involves 
some form of central scheduler which knows the specific needs of every 
application running on every device, and also of the transit traffic, and 
doles out permission as needed. Think deeply about what the words "mobile" 
and "ad hoc" mean, and I think you'll agree that this is a non-starter in 
this kind of network.

All of which is *not* to say that guarantees of bandwidth, latency, or 
reliability are impossible, but to say that they are truly difficult in the 
general case, and even in specific cases have issues.

You might find Charlie Perkins QoS-on-AODV draft interesting reading. It 
has a couple of issues, which I have advised him of in private mail - 
notably, it has the originator say that he wants a certain bandwidth with a 
certain worst case delay, but conveys no sense of what the interval is over 
which the rate is measured. Parekh and Gallager indicate that to perform 
the calculation of the worst case delay that a data stream will experience 
end to end, one needs to know both the rate and the burst size of the data 
stream, and then it is only predictable if the application injects at most 
that rate *and* each hop en route does something predictable with the 
packet stream. But it at least allows us to characterize the feasibility of 
a path. It has the same scaling issues that RFC 2205 RSVP has.

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Fred Baker <[email-masked]>
Date: Mon, 08 Jul 2002 18:23:56 -0700