[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [manet] TCP Expected Throughput
Hi
>However, in UDP, dropped packets are not resent, so you have the
problem of incomplete propagation of information.
>For example, an optimal path might not be found in a route search due
to a dropped RREQ or RREP packet.
I thought that routing control messages are send at the IP level, not
from the application level, therefore not using any transport, neither
UDP nor TCP.
Am I correct?
Thank you
Gabi
-----Original Message-----
From: manet-bounces at ietf.org [mailto:manet-bounces at ietf.org] On Behalf
Of Mullen, John
Sent: Wednesday, September 07, 2005 5:03 PM
To: Li Li
Cc: manet at ietf.org
Subject: RE: [manet] TCP Expected Throughput
Hi Li Li
Case 1 I described below would apply to UDP transmissions, but not Case
2. So the situation would not seem as severe for UDP. However, in UDP,
dropped packets are not resent, so you have the problem of incomplete
propagation of information. For example, an optimal path might not be
found in a route search due to a dropped RREQ or RREP packet.
John P. Mullen, Ph.D.
(505) 646-2958
jomullen at nmsu.edu
-----Original Message-----
From: Li Li [mailto:li.li at crc.ca]
Sent: Wednesday, September 07, 2005 7:01 AM
To: Hakim.Badis at lri.fr; Mullen, John
Cc: manet at ietf.org; ehsan_ham at yahoo.com
Subject: RE: [manet] TCP Expected Throughput
I think these good insights on the drop of throughputs not only pertain
to the TCP transmissions, but are actually applicable to MANET in
general, including UDP transmissions? TCP probably makes it even worse
on the throughput due to the flow control and the retransmissions at the
transport layer?
li li
At 11:17 PM 9/2/2005 +0200, Hakim.Badis at lri.fr wrote:
>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
>
>
>
>_______________________________________________
>manet mailing list
>manet at ietf.org
>https://www1.ietf.org/mailman/listinfo/manet
Li Li, Ph.D
Communications Research Centre, Canada
3701 Carling Ave., P.O. Box 11490, Station H Ottawa, Ontario K2H 8S2
Tel: 613 990 5246
Email: li.li at crc.ca
_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet