Subject: RE: [manet] QoS issues in MANETs

From: Harpreet Arora <[email-masked]>
Date: Sat, 27 Apr 2002 19:08:37 -0400

Hi,

The Insignia approach does seem to be a good approach for QoS in MANETs, but 
it is based on per flow guarantees, not per class, and thus can have the same 
problems associated with Intserv model like scalability and implementation 
issues. Each flow reserves resources at every node it passes through. THe FQMM 
simply suggests that the highest class gets per flow provisioning, while the 
lower classes get per class provisioning, so in essence the model adds the 
complexity of the two models. And it does not suggest any means of 
implementing the model in MANETs. The basic issue still remains of which node 
will mark the packets so that the subsequent nodes can process them 
accrodingly. If the source node does that job, then there is a good chance 
that the node can misbehave and use a DSCP corresponding to a high priority 
PHB even when it does not need to. In that case, who does the policing to stop 
the flow?

thanks,
Harpreet

>===== Original Message From [email-masked] =====
>Good answer,
>Also, I'd to refer you to the INSEGNIA model, which provides a vihcle of 
handling traffic between two nodes. The other model which provided some 
enhancements to traditional DiffServ is the FQMM.
>
>Always try to distinguish signalling from the model. FQMM represent a model, 
INSEGNIA is a model with it's own signaling approach. dRSVP is an ammendment 
to RSVP.
>
>Ingress, and egress could be anynode. Ingress are always nodes initiating 
traffic. Egress are those submitting traffic to different domain.
>
>
>Yasser
>Carleton University
>
>-----------------------------------------------------------------
>Hi Arora,
>
>Actually, diffserv pretty much acknowledges that every "core" node can just
>as easily also be an "edge" node, and may therefore have to worry about such
>complexities as access control from edge hosts. There is no attempt to
>prevent core nodes from being edge nodes.
>
>But diffserv does not get into any sort of signaling or access control
>mechanisms between diffserv nodes and edge user hosts. People have mentioned
>possible signaling mechanisms for use in diffserv nets, such as the RSVP
>PATH and RESV messages. But always, such discussions were cut short on the
>list, because they are not germaine to diffserv itself.
>
>What diffserv offers is really a set of per-hop behaviors that every
>diffserv node has to support as it routes diffserv-labeled packets. These
>PHBs, when aggregated across a diffserv routing domain, create so-called
>"per domain behaviors" for aggregated diffserv paths. That's it, pretty
>much. And the MIB/PIB needed for diffserv node management, of course.
>
>It seems difficult to be able to support diffserv routes with any sort of
>stability if the hops of any "aggregated path" come and go frequently, but I
>suppose this could make for an interesting research project!
>
>Bert
>[email-masked]
>
>
>> -----Original Message-----
>> From: Harpreet Arora [mailto:[email-masked]]
>> Sent: Friday, April 26, 2002 2:50 PM
>> To: manet
>> Subject: [manet] QoS issues in MANETs
>> Importance: High
>>
>>
>> Hi,
>>
>> I am interested in finding the feasibility of a
>> differentiated services model
>> for MANETs. WHile thinking about the implementation of
>> diffserv in MANETs, I
>> came across the follwing problem : diffserv aims to push the
>> complexity to the
>> edge of the network, by dividing the network into edge and
>> core nodes. How can
>> we do this in a MANET? Specifically, how can we differentiate
>> the network of
>> nodes into edge and core nodes? Since the nodes are mobile, I
>> feel that every
>> node should have the capability of acting as an edge node,
>> which would mark,
>> meter and police the packets, and also as a core node, which
>> would simply
>> forward the packets on the basis of the DSCP. The nodes can
>> assume either
>> functionality depending on the situation. But what node assumes what
>> functionality is the question. Any suggestions?
>>
>> Harpreet
>> Research Assistant
>> ECE Department, Drexel University
>> Philadelphia, PA-19104
>>
>> ********************************************************************
>> A dream is just a dream. A goal is a dream with a plan and a deadline.
>>
>> A candle brightens the world around it. Unfortunately, it
>> creates a shadow of its own. It still serves the purpose it
>> is meant for.
>> **********************************************************************
>>
>>
>> _______________________________________________
>> manet mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/manet
>>
>
>
>
>
>See Dave Matthews Band live or win a signed guitar
>http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/
splash.asp
>
>_______________________________________________
>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: Seoung-Bum Lee <[email-masked]>
Date: Tue, 30 Apr 2002 21:30:07 -0400 (EDT)

Granted INSIGNIA is a stateful approach for per-flow QoS
but the state explosion issue for wireless ad hoc networks is
nowhere near as pressing as core Internet (considering the
size of the network and the size of routing tables of MANET
routing protocols). Therefore I do not think the issue of
maintaining per-flow state in ad hoc networks is as critical as
the Internet.

Moreover, in practice, INSIGNIA admits and maintains finite
number of 'high-priority' flows (best-effort flows are not maintained)
through concept of soft-state. When a node carries too many
high-priority flows (or states) and can not be handled,  INSIGNIA
simply ignores/discards additional high-priority flows (and those
denied ones will be treated as best effort flows).  So, our definition
of 'resources' are not limited to 'bandwidth' but includes others like
'buffer-occupancy', 'computational-power' and etc., ... anything that
throttles the end-to-end QoS and INSIGNIA operations.

-Seoung-Bum Lee-

> >http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/

Best Regards,

-----------------------------------------------------
 Seoung-Bum Lee

 COMET Group, Columbia University
 e-mail : [email-masked]
 http://www.comet.columbia.edu/~sbl
  
 * Push your limits!
-----------------------------------------------------

---

From: Seoung-Bum Lee <[email-masked]>
Date: Tue, 30 Apr 2002 21:30:07 -0400 (EDT)

-Seoung-Bum Lee-

Best Regards,

  
 * Push your limits!