[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: qos routing



Hi Kannan,

	I was afraid when I read your mail. Now I have made new discoveries,
and new doubts appeared.

> > From: Luis Henrique Maciel Kosmalski Costa <[email protected]>
> > Date: Tue, 07 Apr 1998 14:10:02 -0300
> 
> > 	My problem is as follows. I modified the DV dynamic routing 
> > scheme in ns, which is implemented in otcl. My intention was to mesure 
> > the efficiency of the new possibles routing schemes indirectly, by 
> > means of the quantity of packets lost when a link goes down and the 
> > routing algorithm has to recalculate the routes. Best algorithms would
> > adapt faster, and the packet loss would be smaller.
> 
> Currently, there is no mechanism to dynamically assign costs to the links.
> When a node initialises its routing, it uses the cost of the link
> as the metric.  If you want to change that to use observed
> loss as the metric, you need additional mechanisms to feed that metric 
> to the routing protocol instances at each node.
> 
> Each route agent on a node has an array of rtPeer objects, one
> per peer agent that it distributes routing to.  That peer object
> stores the metric to reach that peer.  
> Check the ns documentation
> (http://www-mash.cs.berkeley.edu/ns/ns-documentation.html)
> for the rtPeer objects.
> It also has some notes on how that could be changed as well.

	The question of assigning more metrics to each link I have accomplished
already. I read the documentation, and modified some of ns code to support 
three metrics to each link. I also modified the dynamic routing scheme (ie,
Local, Direct and DV routing) to take into account the three metrics. 
	Now, I have three routes to each destination, and the classifier will 
take into account the traffic class (which I haven't defined yet) to send the 
packets. But the classifier is already modified.

> 
> > 	But what I observed is that the processing put into the 
> > procedure compute-routes in DV has no influence in the packet loss. I
> > couldn't explain why. Fact: the routine $ns now returns the same 
> > time in the begining and at the end of DV compute-routes.
> 
> Since there is no notion of node compute time currently in ns, 
> there is no model for packet loss due to lack of routes while
> routes are being computed.  You need to add the routines
> to appropriately model the problem you wish to address.

	Now, let I tell you what I observed. Packet drops are allways 
constant. I made the following test: when the link falls down, the routine
intf-changed is called, and calls the "compute-routes" routines. Then the 
routes are re-computed.
	I put a delay on that call to compute-routes. Result: the routes are 
installed with a greater delay. It produces no new packet drops. But there 
exists packets that are lost. They appear with + sign on out.tr, but there 
are no correspondants "-" or "r's". So, they are lost.
	My conclusion: packet drops are registred only for packets which 
were on the link (link queue) when the link goes down. The packets which are 
sent on that link, when it is down, don't appear as drops. They just appear
with the enque sign (+) on output.
	Am I right? If I am, I think I can simulate this increasing delays 
as the routes processing increases. It will then be converted in packet 
losses.

> 
> > 	Can anyine give me any tips of what is happening? Your help is
> > very appreciated.
> 
> Hope this helps,
> 
> 
> Kannan
> 
> --
> [email protected]
> http://www.isi.edu/~kannan
> 

	Thanks for your help,

	LuisH

-- 
=======================================================================
Luis Henrique Maciel Kosmalski Costa		      [email protected]

GTA - Grupo de Teleinformatica e Automacao - COPPE / UFRJ
Research Interests: QoS Routing and Multimedia Applications.
WWW - http://www.gta.ufrj.br/~luish
Tel. (021) 260-5010 r. 239
=======================================================================