Subject: RE: [manet] Quality of Service for Ad hoc On-Demand Distance Vector Routing

From: "Frank Li" <[email-masked]>
Date: Mon, 20 Oct 2003 15:10:21 +0200

Hi,

More typos found here. 

Sec. 2. If, ..., that node MUST transmit a (an) ICMP QoS_LOST ...

Sec. 3. N      If qos Profile Type is zero, .... Otherwise, if (if), ...

Sec. 9. The ICMPv6 ... to live up to th (the) QoS ...

Questions on Sec. 5: 

If recent history indicates that neighboring
   transmissions will likely interfere with the node's ability to carry
   out the indicated bandwidth specification, then the node SHOULD NOT
   rebroadcast the RREQ.

Is this RREQ message discarded? How does the source node know that its RREQ is discarded? 

Exact mechanisms for estimating neighborhood
   traffic levels are beyond the scope of this document.  Additional
   signaling and protocols may be defined in the future in order to
   obtain a higher probability of collecting the necessary neighborhood
   bandwidth utilization information.

Are there any mechanisms for estimating neighborhood traffic levels at present? Any existing signaling or protocols with respect to this point now? 

Question on Sec. 6.

A node that agrees to satisfy delay constraints has to measure the
   average time it is currently requiring to forward a data packet,
   including processing time, average queuing delays and propagation
   delays.

Is back-off time included in the average queuing delays? Note a packet may experience both queuing delay due to packet(s) in front of it and back-off delay due to contention from other nodes.  

Thanks for any clarification. 

Best regards
Frank

-----Original Message-----
From: Marcin Michalak [mailto:[email-masked]]
Sent: 20. oktober 2003 12:07
To: Mobile Ad Hoc IETF working group
Subject: Re: [manet] Quality of Service for Ad hoc On-Demand Distance
Vector Routing

On 19 Oct 2003 at 23:37, Charles E. Perkins wrote:

> 
> Hello folks,
> 
> There is a new revision for the abovementioned draft.
> It is available at the following URL:
> 	http://people.nokia.net/charliep/txt/aodvid/qos.txt
> and will soon be available as an Internet Draft
> (individual submission).  Of course, this is a
> very difficult area, generally, and so in order
> to get the control signaling right but leave room
> for a much more general parameter request mechanism,
> a "QoS Object" format is defined in the draft to
> allow for future possibilities.
> 
> Regards,
> Charlie P.
Hello,
 I read the draft and it should work ;-)
A small typo in the introduction: 'When a source (is) needs a route'
Otherwise OK.
 What I'm not understanding completely is how the flows are 
distinguished from each other. I see that there's the triplet:
- source IP address
- destination IP address
- Session ID
 But if we have 2 different flows between same source/destination 
pair, let's say one with QoS requirements, the other one without: how 
are they sent? I may not understand the mechanism completely, but I 
thought when the route is established the routing packets are not 
sent anymore, so where is the session ID carried?
 I'd be grateful for the clarification.
  Regards,
   Marcin
----------------------------------------------------------
Marcin Michalak		Research Engineer
Mobile: +41 79 330 83 51	Telscom AG		

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

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