Subject: RE: [manet] my doubts about QoS in ad hoc networks

From: "Liaw, Yong Shyang - LIAYS001" <[email-masked]>
Date: Wed, 29 Jan 2003 09:13:40 +1030

Hi,

Are there any WLAN (IEEE 802.11) card/AP that can support Qos well in MANET?

I tend to agree with Ankur that MANET cannot gurantee Qos because of the
unreliability (& unpredictability) of the links. In MHO, the best MANET can do
is to provide differentiation of services (i.e. one stream has a higher prority
than another), which may still result in significant packet losses, and still
may not give you the Qos required for a given application (i.e. video).
Usually, there is when the application has to adapt to the network resource
available (i.e. reduce the quality of video).

> -----Original Message-----
> From: Yang Xiao [mailto:[email-masked]]
> Sent: Wednesday, 29 January 2003 6:56
> To: Ankur Jain; [email-masked]
> Subject: Re: [manet] my doubts about QoS in ad hoc networks
> 
> 
> Ankur
> 
> Your testbed may depend on some WLAN cards/AP from particular
> companies.
> Those WLAN cards/AP cannot support QoS well.
> 
> Conclusions from such experiments should be not used as judgments for
> QoS enabled Ad hoc networks in a near future.
> 
> Regards
> 
> Yang
> 
> --- Ankur Jain <[email-masked]> wrote:
> > Hello everybody,
> > 
> > I have some doubt about QoS after doing experiments on the testbed
> > for ad
> > hoc networks.
> > 
> > In our experiments, we placed the nodes strategically so that they
> > are on
> > the periphery of the radio range of each other. Then we started the
> > packets
> > transfer and asked the nodes to move about their position. Our
> > results show
> > that the wireless link is so unstable that sometimes 50% of packets
> > get
> > lost.  Fifty percent is such a high figure for packet loss. I
> > repeated the
> > experiments many times but the loss percantage varied from 
> 5% to upto
> > 70%.
> > We conducted the expts. in the office environment so there was some
> > interference with the office's wireless LAN and other RF expts
> > running
> > nearby.
> > 
> > I wanted to ask that if we can't even ensure connectivity in such a
> > small
> > region, how will we guarantee QoS over any infrastructure-less
> > network. If
> > there is some fixed infrastructure then we can give some 
> assurance of
> > QoS
> > over some no. of hops. But I don't think that we can fully guarantee
> > to
> > provide specified bandwidth in real ad hoc networks - be it a
> > militray
> > application or in emergency situations and the network containing
> > hundreds
> > of nodes. And in case of fairs/sports events, I think the network
> > won't even
> > work with 802.11b due to hidden node / exposed node problem where
> > many nodes
> > are in the radio range of each other.
> > 
> > I think right now the definition of QoS over ad hoc network is not
> > clear. Is
> > there any proposal of including QoS in IRTF. Doing QoS tests in
> > simulators
> > won't give the actual scenario. Has anybody done QoS 
> experiments with
> > the
> > actual testbed (with wireless links) for ad hoc networks. I 
> am really
> > anxious to know their results. Please give me some pointers if there
> > are any
> > papers on this.
> > 
> > Best Regards
> > Ankur
> > 
> > 
> > 
> > 
> > 
> > ----- Original Message -----
> > From: Rex Buddenberg <[email-masked]>
> > To: Pablo Serrano Yáñez-Mingot <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Monday, January 27, 2003 11:05 PM
> > Subject: Re: [manet] QoS on ad-hoc networks - when and why?
> > 
> > 
> > > On Sat, 2003-01-25 at 07:31, Pablo Serrano Yáñez-Mingot wrote:
> > >
> > > > But I don't think 'emergency services' fit into a
> > > > 'QoS provisioning scenario', because it should be
> > > > considered an 'overlay network', and not a true
> > > > mobile ad hoc network.
> > > >
> > >
> > > Any real world scenario of any scale will be a mixture of
> > infrastructure
> > > and MANET.  I can't imagine a practical standalone MANET of any
> > size.
> > > So yes, there will be a fixed infrastructure -- that the fire
> > > departments use on a daily basis and for both operational and
> > > non-operational traffic.
> > > In the event of a catastrophe (the large forest fire example) a
> > couple
> > > things happen:
> > > - some fixed infrastructure is damaged
> > > - the existing fire department resources may need to extend
> > > connectivity into unplanned places so you have ad hoc buildout.
> > > - the local fire department is augmented with assets that surge
> > into
> > > the area.  A lot more ad hot (freudian sic... hoc) buildout.
> > > - as the fire progresses and assets move, the topology of the ad
> > hoc
> > > part of the network will surely change.  Similarly, the places
> > where the
> > > ad hoc portions of the network connect to the fixed 
> portions can be
> > > expected to change too.
> > >
> > >
> > > > I mean: in emergency situation, a new ad hoc network
> > > > should be deployed (I think).
> > >
> > > If you have any experience with either military or emergency
> > services,
> > > you should have develope antibodies that say: 'the last thing you
> > should
> > > do in the face of a crisis is reorganize'.  The order of battle
> > should
> > > be the same as the order of sailing (Nelson).
> > >
> > > You won't have a previously
> > > > installed services, because there won't be what I called
> > > > 'multipurpose ad hoc networks'.
> > >
> > > All emergency services outfits I've ever dealt with have 
> previously
> > > installed services that they use daily -- this is a Good Thing
> > since the
> > > crew knows how the stuff works.
> > >
> > >  All traffic on the
> > > > network will be the same (from my point of view) in
> > > > terms of priorities.
> > >
> > > Don't agree, but easy to go overboard.  There will be urgent
> > traffic and
> > > there will be not so urgent traffic.
> > > But sorting this into more than about 4 bins represents such a
> > > departure from KISS that you get in real trouble.  One outfit I'm
> > > working with (government, of course) is looking at 64 levels of
> > priority
> > > since they have 6 bits to work with ... aaack.
> > > These comments are to substantive traffic (I need the next water
> > drop
> > > over here).  They are not directed at the network convergence
> > traffic,
> > > which may indeed be single priority.
> > >
> > > >
> > > > Also, in emergency situation you will need a reliable
> > > > authentication system, so as to only authorized nodes
> > > > are given a 'premium services' (this is why I envision
> > > > an overlay network, and not a network with QoS support)
> > >
> > > Take a look at the IETF diff-serv exercise that ended last year. 
> > The
> > > hard lessons learned there:
> > > - the QoS control cures may be worse than the disease
> > > - departure from KISS has severe consequences.
> > > Note that the need for authentication assumes the need for QoS
> > control.
> > > - attempts to diddle with the DS byte open DoS attack vectors.
> > >
> > > Second, take a look at the IEPREP working group in IETF.  Lotsa
> > cruft in
> > > the archive, but the basics are 1) overprovision the fixed network
> > and
> > > pre-empt the QoS control problem there.  2) Yes, if 
> you're going to
> > > provide _any_ kind of premium service, you're going to need an
> > > authentication system to prevent abuse (by both insiders and
> > > outsiders).
> > > >
> > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > manet mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/manet
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > manet mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/manet
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet
> 
> 
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Manish Karir <[email-masked]>
Date: Wed, 29 Jan 2003 11:48:39 -0500

As I see it, I think there is a strong need for theoretical work that 
can provide guidelines or rought rules of thumb than can tell us what 
happens across the whole scale of mobility.

You have static networks on one side and highly mobile(what does that 
even mean) on the other.  At what point do things start to break down. 
Be it QoS, or routing, or even basic packet forwarding. As one goes from 
a static network to a completely chaotic system, we go from a system 
where routing can be used to a system where only broadcast will work.

If some one has good ideas on how to do this study or has done this 
study, please enlighten the rest of us.  Without that protocols for, 
routing, QoS, security etc. lack meaning, if you cannot at the same time 
specify which range of mobility they operate under.

Perhaps one of the tasks for the irtf might be to publish a common set 
of metrics that should be presented for every new protocol.  It is not 
sufficient to simply present a protocol and describe how it works. 
There should be a checklist that evey proposer of a new protocol should 
have to fulfill before submitting their work.

But ofcourse before we get to that point we first have to figure out 
what the word "mobility" means...is it random walk?, random waypoint, 
etc, what speed does it imply??.  Without this common set of metrics we 
can propose protocols well into the next century, and accomplish little.

I know there is some work on common metrics, for example control packet 
overhead seems to have emerged as a "must have" metric in any study. 
This is probably a good metric, but once again, total meaningless, 
unless put in the perspective of mobility.  the actual metric should be: 
"control overhead given that our scenario is xxxxx on the mobility scale"

Please note I do not mean to criticise anyones work, I'm speaking in 
generics here.

manish