Subject: [manet] Re: manet digest, Vol 1 #325 - 8 msgs

From: Imran Alvi <[email-masked]>
Date: Tue, 04 Feb 2003 02:42:01 -0500

I have joined group recently I was studying about protocols which have less overhead and better QoS performance over wireless LAN, can ATM (on MAC Layer) fullfill the requiremnts of QoS in MANETS?.

Regards
Imran Alvi

> Send manet mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/manet
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of manet digest..."
> 
> 
> Today's Topics:
> 
>    1. RE: my doubts about QoS in ad hoc networks (Scott Corson)
>    2. RE: my doubts about QoS in ad hoc networks (Shaiful)
>    3. RE: my doubts about QoS in ad hoc networks (Xiaoning He)
>    4. RE: my doubts about QoS in ad hoc networks (Xiaoning He)
>    5. Buffer size in Wireless LAN (Liaw, Yong Shyang - LIAYS001)
>    6. Error simulating with AODV, DSR and TORA ([email-masked])
>    7. Re: Error simulating with AODV, DSR and TORA (Alvin Valera)
>    8. Re: Error simulating with AODV, DSR and TORA ([email-masked]> )
> 
> --__--__--
> 
> Message: 1
> From: Scott Corson <[email-masked]>
> To: "'Manish Karir'" <[email-masked]>,
>    "'Liaw, Yong Shyang - LIAYS001'"
> 	 <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>
> Subject: RE: [manet] my doubts about QoS in ad hoc networks
> Date: Thu, 30 Jan 2003 14:50:38 -0500
> 
> <snip>
> 
> > If some one has good ideas on how to do this study or has done this 
> > study, please enlighten the rest of us.  
> 
> I have some ideas...  See below.
> 
> > 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.
> 
> One of the near-term goals of the IRTF group will be to specify just what>  it
> is we are looking for in a protocol, and how its performance should be
> quantified.
> 
> > 
> > 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"
> 
> To study a protocol, a set of protocol-independent "black box" criteria a> re
> necessary.  For example, I don't care what the protocol is, but I do care
> how my data traffic is delivered (xput, latency, possibly other metrics).
> At this level of analysis, you don't care *how* a protocol does what it
> does.  You only measure *what* is does; i.e. the effectiveness of data
> routing based on some set of criteria.  These need to be defined, along w> ith
> test cases, etc.
> 
> Beyond that, one can delve into various levels of "white box" testing on > a
> protocol class or individual protocol basis.  For example, certain
> performance criteria may be valid for "proactive" protocols (e.g. HELLO
> protocol overhead), but not for reactive and vice versa.  Other criteria > may
> only apply to a given protocol.  
> 
> I think control packet overhead as a metric in isolation is relatively
> useless.  It says little about the effectiveness of routing (the ultimate
> black box measure).  It is meaningful only upon close inspection of what > is
> happening with a given protocol, to understand its inner workings, to
> improve it, etc.
> 
> Once we nail down the set of this year's mtg dates, I'll post the IRTF
> webpage, the mailing list and a lot of this kind of discussion is welcome
> there.
> 
> -Scott
> 
> --__--__--
> 
> Message: 2
> Date: Thu, 30 Jan 2003 16:29:30 -0800 (PST)
> From: Shaiful <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: [manet] RE: my doubts about QoS in ad hoc networks
> 
> Hi,
> 
> Forgive me for my ignorance of 802.16.  But do you
> have any support for your statement that 802.16 works
> much better than 802.11 for point-to-point connection?
> This is just like saying PPP is better than ethernet
> over cross-cable.  Or TCP/IP is worst than specialised
> protocol for intranet communication. It just doesn't
> make sense to me.  Can you enlighten us about this
> matter.
> 
> Thanks,
> 
> Regards,
> Shaiful
> 
> xiaoning wrote:
> 
> For me, ad-hoc is only a term used to emphasize
> infrastructureless network. It is independent of
> moving speed. To one extreme, if all nodes are fixed,
> I
> didn't see why QoS can not be provided. 802 WLAN may
> not work, but point-to-point wireless such as 802.16
> may work very well. To another extreme, if all nodes
> are moving as fast as they want, that requires further
> study and I think that's the case implied in this
> mailing list and in your question. Even in your
> scenario, how you place the nodes, what kind of
> interference exists around you will definitely affect
> your result. Furthermore, besides the military usage
> and emergence usage, there are still
> many other scenarios which ad-hoc network can be used.
> Under those scenarios, 802.11 WLAN is not the best
> choice.
> 
> In short, I think QoS for ad-hoc network is something
> important in the future. But it heavily depends on the
> assumptions and scenarios.
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> --__--__--
> 
> Message: 3
> From: "Xiaoning He" <[email-masked]>
> To: "'Shaiful'" <[email-masked]>, <[email-masked]>
> Date: Thu, 30 Jan 2003 16:32:30 -0800
> Subject: [manet] RE: my doubts about QoS in ad hoc networks
> 
> I am sorry I didn't make my comment clear enough. My point is that the
> test results are technology and network setup specific.
> 
> In general, I believe the QoS is something we have to do for the ad-hoc.
> 
> Xiaoning He, Ph.D
> Research Engineer
>  
> NTT-DoCoMo USA Labs
> 181 Metro Drive, Suite 300
> San Jose, CA 95110
>  
> Email: [email-masked]
> Phone: +1 (408) 451-4737
> Fax:   +1 (408) 573-1090
>  
> 
> -----Original Message-----
> From: Shaiful [mailto:[email-masked]] 
> Sent: Thursday, January 30, 2003 4:30 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: my doubts about QoS in ad hoc networks 
> 
> Hi,
> 
> Forgive me for my ignorance of 802.16.  But do you
> have any support for your statement that 802.16 works
> much better than 802.11 for point-to-point connection?
> This is just like saying PPP is better than ethernet
> over cross-cable.  Or TCP/IP is worst than specialised
> protocol for intranet communication. It just doesn't
> make sense to me.  Can you enlighten us about this
> matter.
> 
> Thanks,
> 
> Regards,
> Shaiful
> 
> xiaoning wrote:
> 
> For me, ad-hoc is only a term used to emphasize
> infrastructureless network. It is independent of
> moving speed. To one extreme, if all nodes are fixed,
> I
> didn't see why QoS can not be provided. 802 WLAN may
> not work, but point-to-point wireless such as 802.16
> may work very well. To another extreme, if all nodes
> are moving as fast as they want, that requires further
> study and I think that's the case implied in this
> mailing list and in your question. Even in your
> scenario, how you place the nodes, what kind of
> interference exists around you will definitely affect
> your result. Furthermore, besides the military usage
> and emergence usage, there are still
> many other scenarios which ad-hoc network can be used.
> Under those scenarios, 802.11 WLAN is not the best
> choice.
> 
> In short, I think QoS for ad-hoc network is something
> important in the future. But it heavily depends on the
> assumptions and scenarios.
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> 
> 
> 
> --__--__--
> 
> Message: 4
> From: "Xiaoning He" <[email-masked]>
> To: "'Shaiful'" <[email-masked]>, <[email-masked]>
> Date: Thu, 30 Jan 2003 16:33:42 -0800
> Subject: [manet] RE: my doubts about QoS in ad hoc networks
> 
> That's also the why I use "May" in my previous email.
> 
> Xiaoning He, Ph.D
> Research Engineer
>  
> NTT-DoCoMo USA Labs
> 181 Metro Drive, Suite 300
> San Jose, CA 95110
>  
> Email: [email-masked]
> Phone: +1 (408) 451-4737
> Fax:   +1 (408) 573-1090
>  
> 
> -----Original Message-----
> From: Shaiful [mailto:[email-masked]] 
> Sent: Thursday, January 30, 2003 4:30 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: my doubts about QoS in ad hoc networks 
> 
> Hi,
> 
> Forgive me for my ignorance of 802.16.  But do you
> have any support for your statement that 802.16 works
> much better than 802.11 for point-to-point connection?
> This is just like saying PPP is better than ethernet
> over cross-cable.  Or TCP/IP is worst than specialised
> protocol for intranet communication. It just doesn't
> make sense to me.  Can you enlighten us about this
> matter.
> 
> Thanks,
> 
> Regards,
> Shaiful
> 
> xiaoning wrote:
> 
> For me, ad-hoc is only a term used to emphasize
> infrastructureless network. It is independent of
> moving speed. To one extreme, if all nodes are fixed,
> I
> didn't see why QoS can not be provided. 802 WLAN may
> not work, but point-to-point wireless such as 802.16
> may work very well. To another extreme, if all nodes
> are moving as fast as they want, that requires further
> study and I think that's the case implied in this
> mailing list and in your question. Even in your
> scenario, how you place the nodes, what kind of
> interference exists around you will definitely affect
> your result. Furthermore, besides the military usage
> and emergence usage, there are still
> many other scenarios which ad-hoc network can be used.
> Under those scenarios, 802.11 WLAN is not the best
> choice.
> 
> In short, I think QoS for ad-hoc network is something
> important in the future. But it heavily depends on the
> assumptions and scenarios.
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> 
> 
> 
> --__--__--
> 
> Message: 5
> From: "Liaw, Yong Shyang - LIAYS001" <[email-masked]>
> To: [email-masked]
> Subject: [manet] Buffer size in Wireless LAN
> Date: Fri, 31 Jan 2003 17:08:46 +1030
> 
> Hi,
> 
> What shall be the buffer size for wireless LAN (802.11) Mac layer? I have>  seen
> that it has been set to 4MByte in the DSR model in Opnet. Is this a reaso> nable
> value (in WLAN network card)?
> 
> Thank in advance.
> 
> --__--__--
> 
> Message: 6
> From: [email-masked]
> To: [email-masked]
> Date: Fri, 31 Jan 2003 11:36:08 +0100 (CET)
> Subject: [manet] Error simulating with AODV, DSR and TORA
> 
> This message is in MIME format.
> 
> ---MOQ1044009368649427ca7e46218a0bc9bff12af99112
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 8bit
> 
> Hi,
> 
> I have sent a possible bug report to the NS mailing list, but since no on> e was
> able to give me a reply, perhaps someone in this mailing list is interest> ed.
> 
> Results of dozens of simulations using AODV, DSR and TORA in ns2.1b9a (2.> 1b8
> too) show that these protocols do not behave correctly when there are 802> .11
> broken links.
> 
> When looking at the overall results of simulations with many nodes, the e> ffect I
> describe is not evident. It is necessary to look at a single flow to see > that  
> nodes fail to quickly detect broken links, making the re-routing process > last
> too long. This effect does not exist when using other protocols like OLSR>  or
> Hello-driven AODV since they do not use link-layer info.
> 
> The files I attach show this problem clearly in a very simple scenario
> 
> Please help!
> 
> Best regards, 
> 
> _________________________________________________
> Carlos Miguel Tavares de Araújo Cesariny Calafate
> Polytechnic University of Valencia
> e-mail: [email-masked]
> http://reptar.grc.upv.es/~calafate/
> Tel: +34 963879703 ext. 77977
> _________________________________________________
> 
> ---MOQ1044009368649427ca7e46218a0bc9bff12af99112
> Content-Type: application/x-tcl; name="testlimit.tcl"; name="testlimi> t.tcl"
> Content-Disposition: inline; filename="testlimit.tcl"
> Content-Transfer-Encoding: base64
> 
> 
> CgojID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09P
> T09PT09PT09PT09PT09PT09PT0KIyBEZWZpbmUgb3B0aW9ucwojID09PT09PT09PT09PT09PT
> 09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0
> KCnNldCB2YWwoY2hhbikgICAgICAgQ2hhbm5lbC9XaXJlbGVzc0NoYW5uZWwKc2V0IHZhbChw
> cm9wKSAgICAgICBQcm9wYWdhdGlvbi9Ud29SYXlHcm91bmQKc2V0IHZhbChuZXRpZikgICAgI
> CBQaHkvV2lyZWxlc3NQaHkKc2V0IHZhbChtYWMpICAgICAgICBNYWMvODAyXzExCnNldCB2YW
> woaWZxKSAgICAgICAgUXVldWUvRHJvcFRhaWwvUHJpUXVldWUKc2V0IHZhbChsbCkgICAgICA
> gICBMTApzZXQgdmFsKGFudCkgICAgICAgIEFudGVubmEvT21uaUFudGVubmEKc2V0IHZhbCh4
> KSAgICAgICAgICAgICAgMTUwMCAgICAgICAgICAgIDsjIFggZGltZW5zaW9uIG9mIHRoZSB0b
> 3BvZ3JhcGh5CnNldCB2YWwoeSkgICAgICAgICAgICAgIDE1MDAgICAgICAgICAgICA7IyBZIG
> RpbWVuc2lvbiBvZiB0aGUgdG9wb2dyYXBoeQpzZXQgdmFsKGlmcWxlbikgICAgICAgICA1MCA
> gICAgICAgICAgICA7IyBtYXggcGFja2V0IGluIGlmcQpzZXQgdmFsKHNlZWQpICAgICAgICAg
> ICAxLjAKc2V0IHZhbChhZGhvY1JvdXRpbmcpICAgQU9EVgpzZXQgdmFsKG5uKSAgICAgICAgI
> CAgICA2ICAgICAgICAgICAgIDsjIGhvdyBtYW55IG5vZGVzIGFyZSBzaW11bGF0ZWQgCnNldC
> B2YWwoY3ApICAgICAgICAgICAgICJjYnItbjQ4LXMxLW00OC1yNS4wIiAgICAgIDsjcGFkcm9
> uIGRlIGNvbmV4aW9uZXMKc2V0IHZhbChzYykgICAgICAgICAgICAgInNjZW4tbGltaXQyIiAg
> ICAgOyAjZXNjZW5hcmlvIGRlIHRyYWZpY28gCnNldCB2YWwoc3RvcCkgICAgICAgICAgIDUwL
> jAgICAgICAgICAgICAgOyMgc2ltdWxhdGlvbiB0aW1lCnNldCB2YWwodHJmaWxlKSAgICAgIC
> AgIG91dC50cgpzZXQgdmFsKG5hbWZpbGUpICAgICAgICBvdXQubmFtCnNldCB2YWwocmFuZG9
> tX21vYmlsaXR5KSAgIEZBTFNFCgojID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQojIE1haW4gUHJvZ3JhbQojI
> D09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT
> 09PT09PT09PT09PT09PT0KCiMKIyBJbml0aWFsaXplIEdsb2JhbCBWYXJpYWJsZXMKIwoKIyB
> zZXQgcmFuZG9tIG51bWJlciBnZW5lcmF0b3IgCm5zLXJhbmRvbSAwCgojdXNpbmc6IE1hYyBz
> ZXQgYmFuZHdpZHRoXyAxMU1iCgojIGNyZWF0ZSBzaW11bGF0b3IgaW5zdGFuY2UKCnNldCBuc
> 18JCVtuZXcgU2ltdWxhdG9yXQoKI3RyYWNlIGZpbGUgZm9ybWF0CgokbnNfIHVzZS1uZXd0cm
> FjZQoKCiMgc2V0dXAgdG9wb2dyYXBoeSBvYmplY3QKCnNldCB0b3BvCVtuZXcgVG9wb2dyYXB
> oeV0KCiMgY3JlYXRlIHRyYWNlIG9iamVjdCBmb3IgbnMgYW5kIG5hbQoKc2V0IHRyYWNlZmQJ
> W29wZW4gJHZhbCh0cmZpbGUpIHddCnNldCBuYW10cmFjZSAgICBbb3BlbiAkdmFsKG5hbWZpb
> GUpIHddCgokbnNfIHRyYWNlLWFsbCAkdHJhY2VmZAokbnNfIG5hbXRyYWNlLWFsbC13aXJlbG
> VzcyAkbmFtdHJhY2UgJHZhbCh4KSAkdmFsKHkpCgojIGRlZmluZSB0b3BvbG9neQokdG9wbyB
> sb2FkX2ZsYXRncmlkICR2YWwoeCkgJHZhbCh5KQoKCiMKIyBDcmVhdGUgR29kCiMKc2V0IGdv
> ZF8gW2NyZWF0ZS1nb2QgJHZhbChubildCgojCiMgZGVmaW5lIGhvdyBub2RlIHNob3VsZCBiZ
> SBjcmVhdGVkCiMKCiNnbG9iYWwgbm9kZSBzZXR0aW5nCgokbnNfIG5vZGUtY29uZmlnIC1hZG
> hvY1JvdXRpbmcgJHZhbChhZGhvY1JvdXRpbmcpIFwKICAgICAgICAgICAgICAgICAtbGxUeXB
> lICR2YWwobGwpIFwKICAgICAgICAgICAgICAgICAtbWFjVHlwZSAkdmFsKG1hYykgXAogICAg
> ICAgICAgICAgICAgIC1pZnFUeXBlICR2YWwoaWZxKSBcCiAgICAgICAgICAgICAgICAgLWlmc
> UxlbiAkdmFsKGlmcWxlbikgXAogICAgICAgICAgICAgICAgIC1hbnRUeXBlICR2YWwoYW50KS
> BcCiAgICAgICAgICAgICAgICAgLXByb3BUeXBlICR2YWwocHJvcCkgXAogICAgICAgICAgICA
> gICAgIC1waHlUeXBlICR2YWwobmV0aWYpIFwKICAgICAgICAgICAgICAgICAtY2hhbm5lbFR5
> cGUgJHZhbChjaGFuKSBcCgkJIC10b3BvSW5zdGFuY2UgJHRvcG8gXAoJCSAtYWdlbnRUcmFjZ
> SBPTiBcCiAgICAgICAgICAgICAgICAgLXJvdXRlclRyYWNlIE9OIFwKICAgICAgICAgICAgIC
> AgICAtbWFjVHJhY2UgT0ZGIFwKICAgICAgICAgICAgICAgICAtbW92ZW1lbnRUcmFjZSAgT0Z
> GCgoKIwojICBDcmVhdGUgdGhlIHNwZWNpZmllZCBudW1iZXIgb2Ygbm9kZXMgWyR2YWwobm4p
> XSBhbmQgImF0dGFjaCIgdGhlbQojICB0byB0aGUgY2hhbm5lbC4gCgpmb3Ige3NldCBpIDB9I
> HskaSA8ICR2YWwobm4pIH0ge2luY3IgaX0gewoJc2V0IG5vZGVfKCRpKSBbJG5zXyBub2RlXQ
> p9CgojCiMgRGVmaW5lIGFnZW50IGNvbm5lY3Rpdml0eQojCgpwdXRzICJMb2FkaW5nIGNvbm5
> lY3Rpb24gcGF0dGVybi4uLiIKI3NvdXJjZSAkdmFsKGNwKQoKIyBEZWZpbmUgdGVzdCBjb25u
> ZWN0aW9ucwoKCnNldCB1ZHBfKDApIFtuZXcgQWdlbnQvVURQXQokbnNfIGF0dGFjaC1hZ2Vud
> CAkbm9kZV8oMCkgJHVkcF8oMCkKc2V0IG51bGxfKDApIFtuZXcgQWdlbnQvTnVsbF0KJG5zXy
> BhdHRhY2gtYWdlbnQgJG5vZGVfKDMpICRudWxsXygwKQpzZXQgY2JyXygwKSBbbmV3IEFwcGx
> pY2F0aW9uL1RyYWZmaWMvQ0JSXQokY2JyXygwKSBzZXQgcGFja2V0U2l6ZV8gMTI4CiRjYnJf
> KDApIHNldCBpbnRlcnZhbF8gMC4wMQokY2JyXygwKSBzZXQgcmFuZG9tXyAwCiRjYnJfKDApI
> GF0dGFjaC1hZ2VudCAkdWRwXygwKQokbnNfIGNvbm5lY3QgJHVkcF8oMCkgJG51bGxfKDApCi
> Ruc18gYXQgMjAuMCAiJGNicl8oMCkgc3RhcnQiCgoKCiMgCiMgRGVmaW5lIG5vZGUgbW92ZW1
> lbnQgbW9kZWwKIwoKaWYgeyR2YWwocmFuZG9tX21vYmlsaXR5KX0gewogICAgcHV0cyAiUmFu
> ZG9tIG1vYmlsaXR5IG9uIgogICAgCiAgICAjU3RhcnQgUmFuZG9tIG1vdGlvbgogICAgZm9yI
> HtzZXQgaSAwfSB7JGkgPCAkdmFsKG5uKSB9IHtpbmNyIGl9IHsKCSRub2RlXygkaSkgcmFuZG
> 9tLW1vdGlvbiAxCQk7IyBlbmFibGUgcmFuZG9tIG1vdGlvbgoJJG5vZGVfKCRpKSBzdGFydAo
> gICAgfQoKfSBlbHNlIHsKICAgICMgCiAgICAjIERlZmluZSB0cmFmZmljIG1vZGVsCiAgICAj
> CiAgICBwdXRzICJSYW5kb20gbW9iaWxpdHkgb2ZmOiBMb2FkaW5nIHNjZW5hcmlvIGZpbGUuL
> i4iCiAgICBzb3VyY2UgJHZhbChzYykKfQoKCgoKIyBEZWZpbmUgbm9kZSBpbml0aWFsIHBvc2
> l0aW9uIGluIG5hbQoKZm9yIHtzZXQgaSAwfSB7JGkgPCAkdmFsKG5uKX0ge2luY3IgaX0gewo
> KICAgICMgMjAgZGVmaW5lcyB0aGUgbm9kZSBzaXplIGluIG5hbSwgbXVzdCBhZGp1c3QgaXQg
> YWNjb3JkaW5nIHRvIHlvdXIgc2NlbmFyaW8KICAgICMgVGhlIGZ1bmN0aW9uIG11c3QgYmUgY
> 2FsbGVkIGFmdGVyIG1vYmlsaXR5IG1vZGVsIGlzIGRlZmluZWQKICAgIAogICAgJG5zXyBpbm
> l0aWFsX25vZGVfcG9zICRub2RlXygkaSkgMjAKfQoKCiMKIyBUZWxsIG5vZGVzIHdoZW4gdGh
> lIHNpbXVsYXRpb24gZW5kcwojCmZvciB7c2V0IGkgMH0geyRpIDwgJHZhbChubikgfSB7aW5j
> ciBpfSB7CiAgICAkbnNfIGF0ICR2YWwoc3RvcCkuMCAiJG5vZGVfKCRpKSByZXNldCI7Cn0KC
> iRuc18gYXQgICR2YWwoc3RvcCkuMDAwMiAicHV0cyBcIk5TIEVYSVRJTkcuLi5cIiA7ICRuc1
> 8gaGFsdCIKCiNwdXRzICR0cmFjZWZkICJNIDAuMCBubiAkdmFsKG5uKSB4ICR2YWwoeCkgeSA
> kdmFsKHkpIHJwICR2YWwoYWRob2NSb3V0aW5nKSIKI3B1dHMgJHRyYWNlZmQgIk0gMC4wIHNj
> ICR2YWwoc2MpIGNwICR2YWwoY3ApIHNlZWQgJHZhbChzZWVkKSIKI3B1dHMgJHRyYWNlZmQgI
> k0gMC4wIHByb3AgJHZhbChwcm9wKSBhbnQgJHZhbChhbnQpIgoKcHV0cyAiU3RhcnRpbmcgU2
> ltdWxhdGlvbi4uLiIKJG5zXyBydW4KCgoKCgo=
> 
> 
> ---MOQ1044009368649427ca7e46218a0bc9bff12af99112
> Content-Type: application/octet-stream; name="scen-limit2"; name="sce> n-limit2"
> Content-Disposition: inline; filename="scen-limit2"
> Content-Transfer-Encoding: base64
> 
> 
> CiRub2RlXygwKSBzZXQgWF8gMTAwLjAKJG5vZGVfKDApIHNldCBZXyAyNTAuMAokbm9kZV8oM> Ckg
> c2V0IFpfIDAuMDAwMDAwMDAwMDAwCiRub2RlXygxKSBzZXQgWF8gMjUwLjAKJG5vZGVfKDEpI> HNl
> dCBZXyA0NTAuMAokbm9kZV8oMSkgc2V0IFpfIDAuMDAwMDAwMDAwMDAwCiRub2RlXygyKSBzZ> XQg
> WF8gNTAwLjAKJG5vZGVfKDIpIHNldCBZXyA0NTAuMAokbm9kZV8oMikgc2V0IFpfIDAuMDAwM> DAw
> MDAwMDAwCiRub2RlXygzKSBzZXQgWF8gNjUwLjAKJG5vZGVfKDMpIHNldCBZXyAyNTAuMAokb> m9k
> ZV8oMykgc2V0IFpfIDAuMDAwMDAwMDAwMDAwCiRub2RlXyg0KSBzZXQgWF8gMjQ5LjAKJG5vZ> GVf
> KDQpIHNldCBZXyA0NS4wCiRub2RlXyg0KSBzZXQgWl8gMC4wMDAwMDAwMDAwMDAKJG5vZGVfK> DUp
> IHNldCBYXyA1MDAuMAokbm9kZV8oNSkgc2V0IFlfIDUwLjAKJG5vZGVfKDUpIHNldCBaXyAwL> jAw
> MDAwMDAwMDAwMAoKCiMkbnNfIGF0IDI0LjUwMDAwMDAwMDAwMCAiJG5vZGVfKDIpIHNldGRlc> 3Qg
> MjUwLjAgNTAuMCAxMDAuMCIKIyRuc18gYXQgMjUuMDAwMDAwMDAwMDAwICIkbm9kZV8oMSkgc> 2V0
> ZGVzdCAyNDkuMCAxNDk5LjAgMTAwLjAiCgokbnNfIGF0IDI0LjAwMDAwMDAwMDAwMCAiJG5vZ> GVf
> KDQpIHNldGRlc3QgMjUwLjAgNTAuMCAxMDAwLjAiCiRuc18gYXQgMjUuMDAwMDAwMDAwMDAwI> CIk
> bm9kZV8oMikgc2V0ZGVzdCAxNDk5LjAgMTQ5OS4wIDEwMDAuMCIK
> 
> 
> ---MOQ1044009368649427ca7e46218a0bc9bff12af99112--
> 
> 
> --__--__--
> 
> Message: 7
> Date: Fri, 31 Jan 2003 04:39:40 -0800 (PST)
> From: Alvin Valera <[email-masked]>
> Subject: Re: [manet] Error simulating with AODV, DSR and TORA
> To: [email-masked], [email-masked]
> 
> Hi Carlos Miguel,
> 
> I performed many simulations in ns-2.1b8 specifically
> on the reaction of routing protocols to link failures.
> I haven't encountered your problem, though.
> 
> Could it be that the delay in detecting a link failure
> is due to link layer retransmissions? In 802.11, as
> far as ns-2.1b8 is concerned, a sender retries several
> times (I could not remember the exact value) before
> informing the routing protocol that a data packet is
> undeliverable?
> 
> Another possible reason is congestion. In my studies,
> I encountered many instances where 802.11 reports a
> link layer failure even though the receiver is within
> range. This is due to the fact that in highly
> congested environment, the MAC of the sender may fail
> to acquire the channel or complete the
> RTS-CTS-DATA-ACK.
> 
> 
> Best regards,
> Alvin
> 
> --- [email-masked] wrote:
> > Hi,
> > 
> > I have sent a possible bug report to the NS mailing
> > list, but since no one was
> > able to give me a reply, perhaps someone in this
> > mailing list is interested.
> > 
> > Results of dozens of simulations using AODV, DSR and
> > TORA in ns2.1b9a (2.1b8
> > too) show that these protocols do not behave
> > correctly when there are 802.11
> > broken links.
> > 
> > When looking at the overall results of simulations
> > with many nodes, the effect I
> > describe is not evident. It is necessary to look at
> > a single flow to see that  
> > nodes fail to quickly detect broken links, making
> > the re-routing process last
> > too long. This effect does not exist when using
> > other protocols like OLSR or
> > Hello-driven AODV since they do not use link-layer
> > info.
> > 
> > The files I attach show this problem clearly in a
> > very simple scenario
> > 
> > Please help!
> > 
> > Best regards, 
> > 
> > _________________________________________________
> > Carlos Miguel Tavares de Araújo Cesariny Calafate
> > Polytechnic University of Valencia
> > e-mail: [email-masked]
> > http://reptar.grc.upv.es/~calafate/
> > Tel: +34 963879703 ext. 77977
> > _________________________________________________
> > 
> 
> > ATTACHMENT part 2 application/x-tcl
> name=testlimit.tcl; name=testlimit.tcl
> 
> 
> > ATTACHMENT part 3 application/octet-stream
> name=scen-limit2; name=scen-limit2
> 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> --__--__--
> 
> Message: 8
> From: [email-masked]
> To: Alvin Valera <[email-masked]>
> Subject: Re: [manet] Error simulating with AODV, DSR and TORA
> Date: Fri, 31 Jan 2003 16:08:54 +0100 (CET)
> Cc: [email-masked]
> 
> Hi Alvin,
> 
> Thank you for your comments on this subject.
> 
> My opinion is that, since I created a very simple scenario with just 6 on> es and
> 1 traffic flow, we can't blame collisions for the behaviour observed. Als> o, it's
> true that the sender retries several times (I think 4 times), but I guess>  that
> 10 or 20 seconds to detect a broken link is too much, don't you? If link-> level
> aware protocols were supposed to behave that bad, we would conform to jus> t
> sending "Hellos"!
> 
> It's curious to notice that the problems are not the same for all: the wo> rst
> performance can be seen with DSR but TORA suddenly stops sending packets > and
> everything is still!
> 
> Please comment the "ns-random 0" line and you'll see exactly what I see.
> 
> Best regards,
> 
> Carlos
> 
> 
> 
> Mensaje citado por: Alvin Valera <[email-masked]>:
> 
> > Hi Carlos Miguel,
> > 
> > I performed many simulations in ns-2.1b8 specifically
> > on the reaction of routing protocols to link failures.
> > I haven't encountered your problem, though.
> > 
> > Could it be that the delay in detecting a link failure
> > is due to link layer retransmissions? In 802.11, as
> > far as ns-2.1b8 is concerned, a sender retries several
> > times (I could not remember the exact value) before
> > informing the routing protocol that a data packet is
> > undeliverable?
> > 
> > Another possible reason is congestion. In my studies,
> > I encountered many instances where 802.11 reports a
> > link layer failure even though the receiver is within
> > range. This is due to the fact that in highly
> > congested environment, the MAC of the sender may fail
> > to acquire the channel or complete the
> > RTS-CTS-DATA-ACK.
> > 
> > 
> > Best regards,
> > Alvin
> > 
> 
> 
> _________________________________________________
> Carlos Miguel Tavares de Araújo Cesariny Calafate
> Becário de la Universidad Politécnica de Valencia
> e-mail: [email-masked]
> http://reptar.grc.upv.es/~calafate/
> Tel: +34 963879703 ext. 77977
> _________________________________________________
> \\\\\\\"In an open world without walls and fences who needs Windows and
> Gates?\\\\\\\"
> 
> 
> --__--__--
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet
> 
> 
> End of manet Digest

_______________________________________________________
Buy phone cards and save at http://www.vnphonecards.com
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet