David Simplot-Ryl | 1 Sep 01:04 2005
Picon

CFP FAWN 2006, Pisa, Italy, March 2006: extended deadline

Apologies in advance if you receive multiple copies of this CFP.

----------------------------------------------------------------------
                   CALL FOR PAPERS -- FAWN 2006
                   1st International Workshop On
      Foundations And Algorithms For Wireless Networking

                     In conjunction with Fourth Annual
IEEE International Conference on Pervasive Computing and Communications

                     Pisa, Italy, March 13, 2006
                     http://ares.insa-lyon.fr/fawn2006/
----------------------------------------------------------------------

SCOPE
-----

Mobile computing   and communications devices   will  have an enormous
impact on   our lifestyle over  the  next  several  decades.  Wireless
connectivity with mobility support is an important enabling technology
for  pervasive  computing and     communications.  The  emergence   of
multi-hop wireless network (wireless ad hoc networks, sensor networks)
and The mobility of distributed computing components raise a number of
interesting, and difficult theoretical and algorithmic issues and will
play a   key  role in  development  and   progress of these   emerging
paradigms.

FAWN 2006 is devoted to algorithms, theory and modeling in the context
of mobile and wireless computing and networking.  It is intended to be
a  lively meeting,  covering many  of  the algorithmic aspects of this
(Continue reading)

Richard Han | 1 Sep 01:43 2005
Picon

CFP IEEE/CreateNet SecureComm 05, Sept 5-9, Athens, Greece

Dear Colleague,

  Please find attached the call for participation for the First
  IEEE/CreateNet International Conference on Security and Privacy for
  Emerging Areas in Communication Networks (SecureComm 2005) to be held
  in Athens, Greece from Sep. 5-9, 2005.

  The conference program consists of 32 full papers and 20 short
  papers, keynote and invited talks, and a panel. In addition, there
  are four workshops on related topics. The complete information is
  available on the website: www.securecomm.org

  Note that Early Conference Registration Ends August 25, 2005!
  Discounted Hotel Reservation Rates end September 1, 2005.

  We apologize if you receive multiple copies of this message. Please
  feel free to distribute this to colleagues who might be interested.

regards,

SecureComm 2005 Organizing  Committee

    ***************************************************************
             CALL FOR PARTICIPATION

       First IEEE/CreateNet International Conference on Security
        and Privacy for Emerging Areas in Communication Networks

        Athens, Greece / Hotel Amarilia / 5 - 9 September, 2005
               www.securecomm.org
(Continue reading)

Philippe Jacquet | 1 Sep 11:51 2005
Picon
Picon

Re: CDS robustness research repport

Hello, Richard,

Thank you for your comment and results. You made very interesting 
remarks. It was already pointed out by Dai and Wu that neighbor 
designated algorithms are more robust.

MPR based CDS uses only two hop information as well as MPR selection in 
OLSR, no need of three hop information. It is  a little less efficient 
than MPR flooding but as resilient and does not need last hop 
identification for broadcasting data, this is why it is in our SMURF 
draft for data broadcast.

"Rule k" algorithm is originally from Dai and Wu, this is a 
generalization of previous rule k=1,2,3 algorithms of Wu Li that are 
very heavy on computation, k=infinity is more efficient and easier to 
implement. It also needs two hop information as with MPR. I think your 
MDR algorithm is a kind of adaptation of rule k=infinity.

I was not aware of the stretch factor effect, this is an interesting 
remark.

Best regards,
Philippe
Richard Ogier | 1 Sep 19:51 2005
Picon
Picon

Re: CDS robustness research repport

Philippe,

Philippe Jacquet wrote:

> Hello, Richard,
>
> Thank you for your comment and results. You made very interesting 
> remarks. It was already pointed out by Dai and Wu that neighbor 
> designated algorithms are more robust.
>
> MPR based CDS uses only two hop information as well as MPR selection 
> in OLSR, no need of three hop information.

This is often misunderstood, so I will explain more clearly.
You need to specify what you mean by "2-hop information",
i.e., 2-hop information with respect to which node?
Each node selects its MPRs based on 2-hop information (with respect
to itself). But (with offline pruning) each node decides whether it
is a CDS node based on the MPR selection of its neighbors, which in
turn depends on the 2-hop information for each neighbor.
Thus, the decision of whether a given node becomes a CDS node
depends on 3-hop information with respect to the node itself.
This is the tradeoff, so it is important to understand this.
Do you agree?  If not, then please explain.

BTW, I wanted to add something to my previous message.
The MDR selection algorithm in my draft selects MDRs persistently,
which is important for the stability of adjacencies.
In order to modify the OSPF-MDR extension to use an MPR-based
CDS, it would be necessary to use a *persistent* MPR selection
(Continue reading)

Hasan Holandi | 2 Sep 21:50 2005
Picon

TCP Expected Throughput

Dear All,
 
I have a very trivial (but important to me) question:
 
Basically, I would like to know when we have a 4 hop ad hoc network with a 2 Mb/s channel, what is the expected throughput?? Will that be also 2Mb/s (which of course in reality would be much less due to MAC contention) or it would be 500 Kb/s?? In other words if i have file size of 16Mb, theoretically will it take 8 sec or 32 sec?? 
 
I would appreciate if can clarify this issue with your response.
 
Hass

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www1.ietf.org/mailman/listinfo/manet
Mullen, John | 2 Sep 22:41 2005

RE: TCP Expected Throughput

If you have a MANET, expected throughput will be considerably less than the channel capacity.  How much less will depend on several factors.  Here are two:
 
1. Retransmissions for forwarding. Suppose you have A B C D and A is sending a message consisting of two packets to D via B and C.  First, A sends the first packet  to B.  Then B sends it to C.  During this time, A will sense B's carrier and not send the second packet.  Then, C sends to D.  Even if A does not sense C's signal, any attempt to send the second packet would fail, due to a data collision at B.  Hence, A will not be able to send the second packet for about three times the nominal transmission time for the first packet.  Also, while this is going on, other nodes in the vicinity won't be able to use the channel, either.  Depending on traffic patterns, node density and node configuration, this could easily cut your effective channel capacity by two thirds.
 
2. Retransmission for errors.  In a MANET, the effective range is the result of a stochastic balance between the likelyhood of success transmittion and the probability of selecting a node during a search.  Because of fine-grained variations in signal strength due to fading, a packet may be lost at any distance.  However, as distance increases, the probability of having to retransmit a randomly dropped packet increases.  If the maximum number of MAC retries is fairly high, the protocol is likely to stick with a poor link, compensating by retransmitting packets, rather than switching to a better path.  If this is the case, you could lose a significant fraction of your capacity due to retransmission of dropped packets. 
 
In short, the throughput is what you get, depending on a number of factors.  I would say that 500 Kb/s is not a surprising figure, though it might be possible to do a bit better.
 

John P. Mullen, Ph.D.
(505) 646-2958
jomullen <at> nmsu.edu
 

 

From: manet-bounces <at> ietf.org [mailto:manet-bounces <at> ietf.org] On Behalf Of Hasan Holandi
Sent: Friday, September 02, 2005 1:51 PM
To: manet <at> ietf.org
Subject: [manet] TCP Expected Throughput

Dear All,
 
I have a very trivial (but important to me) question:
 
Basically, I would like to know when we have a 4 hop ad hoc network with a 2 Mb/s channel, what is the expected throughput?? Will that be also 2Mb/s (which of course in reality would be much less due to MAC contention) or it would be 500 Kb/s?? In other words if i have file size of 16Mb, theoretically will it take 8 sec or 32 sec?? 
 
I would appreciate if can clarify this issue with your response.
 
Hass

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www1.ietf.org/mailman/listinfo/manet
Hakim.Badis | 2 Sep 23:09 2005
Picon

RE: TCP Expected Throughput

Hi;

> If you have a MANET, expected throughput will be considerably less than
> the channel capacity.  How much less will depend on several factors.
> Here are two:
>
> 1. Retransmissions for forwarding. Suppose you have A B C D and A is
> sending a message consisting of two packets to D via B and C.  First, A
> sends the first packet  to B.  Then B sends it to C.  During this time,
> A will sense B's carrier and not send the second packet.  Then, C sends
> to D.  Even if A does not sense C's signal, any attempt to send the
> second packet would fail, due to a data collision at B.  Hence, A will
> not be able to send the second packet for about three times the nominal
> transmission time for the first packet.  Also, while this is going on,
> other nodes in the vicinity won't be able to use the channel, either.
> Depending on traffic patterns, node density and node configuration, this
> could easily cut your effective channel capacity by two thirds.
>
> 2. Retransmission for errors.  In a MANET, the effective range is the
> result of a stochastic balance between the likelyhood of success
> transmittion and the probability of selecting a node during a search.
> Because of fine-grained variations in signal strength due to fading, a
> packet may be lost at any distance.  However, as distance increases, the
> probability of having to retransmit a randomly dropped packet increases.
> If the maximum number of MAC retries is fairly high, the protocol is
> likely to stick with a poor link, compensating by retransmitting
> packets, rather than switching to a better path.  If this is the case,
> you could lose a significant fraction of your capacity due to
> retransmission of dropped packets.
>
> In short, the throughput is what you get, depending on a number of
> factors.  I would say that 500 Kb/s is not a surprising figure, though
> it might be possible to do a bit better.

If you see the work of  Gupta and kumar, as the number of nodes per unit
area increases, the throughput per source-to-destination (S–D) pair
decreases approximately like 1/sqrt(n). This is the best performance
achievable even allowing for optimal scheduling, routing, and relaying of
packets in the networks and is a somewhat pessimistic result. The number
of hops in a typical route is of order sqrt(n). So, 500Kb/s is conform to
the model. But this is not a

>
>
> John P. Mullen, Ph.D.
> (505) 646-2958
> jomullen <at> nmsu.edu
>
>
>
>
> ________________________________
>
> From: manet-bounces <at> ietf.org [mailto:manet-bounces <at> ietf.org] On Behalf
> Of Hasan Holandi
> Sent: Friday, September 02, 2005 1:51 PM
> To: manet <at> ietf.org
> Subject: [manet] TCP Expected Throughput
>
>
> Dear All,
>
> I have a very trivial (but important to me) question:
>
> Basically, I would like to know when we have a 4 hop ad hoc network with
> a 2 Mb/s channel, what is the expected throughput?? Will that be also
> 2Mb/s (which of course in reality would be much less due to MAC
> contention) or it would be 500 Kb/s?? In other words if i have file size
> of 16Mb, theoretically will it take 8 sec or 32 sec??
>
> I would appreciate if can clarify this issue with your response.
>
> Hass
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _______________________________________________
> manet mailing list
> manet <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>
Hakim.Badis | 2 Sep 23:17 2005
Picon

RE: TCP Expected Throughput

Hi;

> If you have a MANET, expected throughput will be considerably less than
> the channel capacity.  How much less will depend on several factors.
> Here are two:
>
> 1. Retransmissions for forwarding. Suppose you have A B C D and A is
> sending a message consisting of two packets to D via B and C.  First, A
> sends the first packet  to B.  Then B sends it to C.  During this time,
> A will sense B's carrier and not send the second packet.  Then, C sends
> to D.  Even if A does not sense C's signal, any attempt to send the
> second packet would fail, due to a data collision at B.  Hence, A will
> not be able to send the second packet for about three times the nominal
> transmission time for the first packet.  Also, while this is going on,
> other nodes in the vicinity won't be able to use the channel, either.
> Depending on traffic patterns, node density and node configuration, this
> could easily cut your effective channel capacity by two thirds.
>
> 2. Retransmission for errors.  In a MANET, the effective range is the
> result of a stochastic balance between the likelyhood of success
> transmittion and the probability of selecting a node during a search.
> Because of fine-grained variations in signal strength due to fading, a
> packet may be lost at any distance.  However, as distance increases, the
> probability of having to retransmit a randomly dropped packet increases.
> If the maximum number of MAC retries is fairly high, the protocol is
> likely to stick with a poor link, compensating by retransmitting
> packets, rather than switching to a better path.  If this is the case,
> you could lose a significant fraction of your capacity due to
> retransmission of dropped packets.
>
> In short, the throughput is what you get, depending on a number of
> factors.  I would say that 500 Kb/s is not a surprising figure, though
> it might be possible to do a bit better.

If you see the work of  Gupta and kumar, as the number of nodes per unit
area increases, the throughput per source-to-destination (S–D) pair
decreases approximately like 1/sqrt(n). This is the best performance
achievable even allowing for optimal scheduling, routing, and relaying of
packets in the networks and is a somewhat pessimistic result. The number
of hops in a typical route is of order sqrt(n). So, 500Kb/s is conform to
the model. But this is not a rule, throughput depends on many factors:
interference, buffer size, traffic patterns, node density , etc. and it is
is difficult to determine the realy throughput.

>
> John P. Mullen, Ph.D.
> (505) 646-2958
> jomullen <at> nmsu.edu
>
>
>
>
> ________________________________
>
> From: manet-bounces <at> ietf.org [mailto:manet-bounces <at> ietf.org] On Behalf
> Of Hasan Holandi
> Sent: Friday, September 02, 2005 1:51 PM
> To: manet <at> ietf.org
> Subject: [manet] TCP Expected Throughput
>
>
> Dear All,
>
> I have a very trivial (but important to me) question:
>
> Basically, I would like to know when we have a 4 hop ad hoc network with
> a 2 Mb/s channel, what is the expected throughput?? Will that be also
> 2Mb/s (which of course in reality would be much less due to MAC
> contention) or it would be 500 Kb/s?? In other words if i have file size
> of 16Mb, theoretically will it take 8 sec or 32 sec??
>
> I would appreciate if can clarify this issue with your response.
>
> Hass
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _______________________________________________
> manet mailing list
> manet <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>

Hakim
gokina | 5 Sep 14:49 2005

Link layer measurements in MANET

Hi,
Please let me know if any body is doing research on link layer measurements in MANET or Sensor Networks. 

Thanks,
Gokina.



_______________________________________________
manet mailing list
manet <at> ietf.org
https://www1.ietf.org/mailman/listinfo/manet
remith m rajan | 5 Sep 21:44 2005

manets implementattion in ns2

 
hello,
 
can anyone give me the source for the ns2 source codes for mobile adhoc networks.
thanks
with rgds
remith
iit delhi



_______________________________________________
manet mailing list
manet <at> ietf.org
https://www1.ietf.org/mailman/listinfo/manet

Gmane