Subject: Re: RE: [manet] help on 802.11

From: "Peter Pham" <[email-masked]>
Date: Mon, 22 Sep 2003 23:36:11 +0950

Dear all 
Thank you very much for your response. 

I know how to turn on/off RTS/CTS in ns2. However, I have another question. By setting the RTSThreshold to a large value, we "at the beginning" can permanently turn on/off RTS/CTS. However, I really want to control the transmission of RTS/CTS "on the fly", i.e. I can turn on/off RTS/CTS whenever I want (depending on the traffic condition, and the status of the other nodes). Is this possible in NS2 ???...

>From my understanding, I just add another control flag and turn on/off the flag and modify the code so that in addition of checking the RTSThreshold, it will check for that flag before transmitting RTS/CTS...

However, I am worried that it will desrupt the operation of 802.11.  
Can anyone shed any light on this please. 

Peter Pham

-----Original Message-----
From: "Frank Li" <[email-masked]>
To: "Apichet Chayabejara" <[email-masked]>
Date: Mon, 22 Sep 2003 09:31:30 +0200
Subject: RE: [manet] help on 802.11

Hi Apichet, Pham,

If you set the RTSThreshold to a NOT-very large value, packets smaller that this value will be sent without RTS/CTS while larger packets will still be using RTS/CTS in the same network.  

Frank

-----Original Message-----
From: Apichet Chayabejara [mailto:[email-masked]]
Sent: 21. september 2003 01:32
To: [email-masked]
Cc: Peter Pham
Subject: Re: [manet] help on 802.11

Dear Pham,

IEEE 802.11 only applies RTS/CTS handshakes to frames larger than
RTSThreshold. So an easy way to turn it of is to set the RTSThreshold to a
very large value. You may have to take a look in mac-802_11.h.

Hope it helps.
Apichet.

----- Original Message ----- 
From: "Peter Pham" <[email-masked]>
To: <[email-masked]>
Sent: Monday, September 15, 2003 9:56 AM
Subject: [manet] help on 802.11

Hi  all

I am working on the effect of RTS and CTS of 802.11 in ad hoc network using
NS2. I read some papers and their results on the effect or RTS/CTS are
controversial...Some said having RTS/CTS improved the performance. Others
said the opposite.

Can anyone tell me how to turn on/off the RTS/CTS operation in 802.11.

>From my understanding through the first look of the code, there is no
mechanism. However, I might be wrong...If this is the case, what can I do to
turn it off...

Cheers
Peter Pham
Peter Phuc Pham
University of South Australia
Institute for Telecommunication Research
Phone: 61-883023869
Email: [email-masked]
WWW:   www.itr.unisa.edu.au/~ppham

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

Peter Phuc Pham
University of South Australia
Institute for Telecommunication Research
Phone: 61-883023869
Email: [email-masked]
WWW:   www.itr.unisa.edu.au/~ppham

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

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 22 Sep 2003 18:17:09 +0200 (CEST)

> --__--__--
>
> Message: 4
> Subject: Re: RE: [manet] help on 802.11
> To: [email-masked], [email-masked]
> CC: [email-masked]
> Date: Mon, 22 Sep 2003 23:36:11 +0950
>
> Dear all=20
> Thank you very much for your response.=20
>
> I know how to turn on/off RTS/CTS in ns2. However, I have another question.=
>  By setting the RTSThreshold to a large value, we "at the beginning" can =
> permanently turn on/off RTS/CTS. However, I really want to control the tr=
> ansmission of RTS/CTS "on the fly", i.e. I can turn on/off RTS/CTS whenev=
> er I want (depending on the traffic condition, and the status of the othe=
> r nodes). Is this possible in NS2 ???...

Since each packet at L2 is independent from the others RTS/CTS can be
adjusted "on the fly".

>
> >From my understanding, I just add another control flag and turn on/off the =
> flag and modify the code so that in addition of checking the RTSThreshold=
> , it will check for that flag before transmitting RTS/CTS...
>
Yes.. you have to change the code!

> However, I am worried that it will desrupt the operation of 802.11. =20
I don't think so, if your coding is correct MAC won't be desrupted>

Ciao
                            Luigi

> Can anyone shed any light on this please.=20

> If you set the RTSThreshold to a NOT-very large value, packets smaller that=
>  this value will be sent without RTS/CTS while larger packets will still =
> be using RTS/CTS in the same network. =20
>
> Frank
>
> ----- Original Message -----=20
> mechanism. However, I might be wrong...If this is the case, what can I do t=
> o
> turn it off...
>
> Cheers
> Peter Pham
> Peter Phuc Pham
> --__--__--
> Message: 5
> To: "Christophe Jelger" <[email-masked]>
> cc: [email-masked], [email-masked]
> Reply-To: [email-masked]
> From: [email-masked]
> Subject: Re: [manet] Comments on draft-jelger
> Date: Mon, 22 Sep 2003 08:08:28 -0700
>
>
> Christophe,
>
>  > Just to quickly reply to your comment below (part of your previous email).
>  > I'm afraid that your point is not correct, as with our proposal we don't use
>  > the gateway information to create a default route with reactive protocols.
>  > It is stated in the draft that we don't use a default route with reactive
>  > protocols because it prevents the protocol from being reactive (there is a
>  > default route!) and, as you state, it can prevent the use of shortest-path
>  > route.
>
> That's fine for reactive routing. I was focusing on proactive routing,
> where you *do* propose using the gateway information to maintain
> a default route.
>
> <snip>
>
>  > For proactive the problem does not exist, as a node will have a view of the
>  > entire adhoc topology and will use the direct route to join an adhoc node
>  > with a different prefix (i.e. there will a /128 route for this destination
>  > in the routing table).
>
> I wasn't sure whether you wanted to allow direct (intra-manet) routing
> between nodes in different prefix islands, so my paragraph that you
> refer to considers both cases. Here is the paragraph again:
>
>  > I would like to make a few more points. Your method (which uses a
>  > DSDV-like protocol to select a gateway and maintain prefix continuity)
>  > results in default routing that does not use the min-hop path to the
>  > default gateway (since the min-hop path might use intermediate nodes
>  > having a different prefix), and therefore is not consistent with a
>  > proactive min-hop routing protocol, UNLESS the routing protocol is
>  > restricted to finding routes only within each prefix island.
>  > For example, to reach a manet node in another prefix island (even if
>  > the other node is only 2 hops away), your method would send the packet
>  > to the default gateway. I think this is contrary to previous discussions
>  > on the manet list (e.g., if there is a manet node 2 hops away, the
>  > packet should be routed along a 2-hop path within the manet, even if
>  > the node has a different prefix).
>
> Although it may not have been clear, the example given in the last part
> of the paragraph assumes that direct routing is allowed only between
> nodes in the same prefix island (the "UNLESS" clause), so of course
> it is not valid if direct routing is allowed between different
> prefix islands.
>
> But the first part of the paragraph states that if direct routing is
> allowed between different prefix islands (the negation of the "UNLESS"
> clause), then your method of maintaining a default route for *proactive*
> routing is not consistent with the routes computed by the proactive
> routing protocol itself, since the proactive routing protocol will
> compute the min-hop path to the gateway, even if this path includes
> intermediate nodes that belong to a different prefix island.
>
> I'm not sure whether this inconsistency will cause any serious problems,
> but one way to avoid it, as I discussed in my previous email, is to
> simply let the routing protocol disseminate gateway information and
> maintain default routes to gateways (as in OSPF).
>
> (If the goal is to have a common gateway discovery mechanism for both
> proactive and reactive routing, I also discussed that in my previous
> email, but the gist is that, since the proactive routing protocol
> should already provide such a mechanism, it does not make sense to
> provide another such mechanism that can be used with both proactive
> and reactive routing, unless this common mechanism is already part of
> the proactive routing protocol.)
>
> Regards,
> Richard
>
>
>
>
> --__--__--
>
> End of manet Digest

------------------------------------>
Luigi Iannone -  Laboratoire D'Informatique Paris 6
   e.mail:      [email-masked]
   Tel:         +33 (0)1 44 27 88 48