Subject: RE: [manet] MAC queuing delay

From: "Mullen, John P. (Contractor)" <[email-masked]>
Date: Tue, 9 Jul 2002 10:35:33 -0600

Hi,

This is one down side of large queue capacities.  Wireless nets will undergo
throughput foldover, in which higher loads lead to lower throughput, at high
loads, such as you have here.  The primary cause is higher rates of data
collisions at points of congestion.  The large queues permit the load to be
stored in the net itself, usually directly upstream of the congestion
points.  As the packets are retransmitted, the local data collision problem
is aggravated, leading to more retransmissions and collisions, etc.  The
trick to traffic management is to try to avoid this cascading effect of
increasing data collisions.

If the protocol supports windowing, packets will be held at the source when
the system is congested, rather than at the intermediate nodes.  This
reduces retransmissions by not placing the packets on the web when it is
overloaded.  In addition, it distributes the packets differently, so many
are not immediately upstream of the congestion point.  If, in addition, the
source nodes employ a priority and urgency system, lower priority and highly
urgent messages will time out and never appear on the net.

This would be, of course, managed at the higher OSI levels, rather than the
MAC layer, though input form the MAC layer may be used.

John Mullen

-----Original Message-----
From: Vikram Kanodia [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 9:44 AM
To: Imad AAD
Cc: Kaixin Xu; Yougu Yuan; [email-masked]; Xiaowen (Jason) Liu
Subject: Re: [manet] MAC queuing delay

delay of couple of seconds in high load scenarios (total offered load ~
80% capacity, number of nodes > 25) is consistent with what we observed in
some of our ns simulations. We traced the cause back to mainly, large
number of collissions (in the heavy load case) leading to queue buildup at
the interface queue (the queue length was set to a large value in our case
to avoid dropping) leading to high delay.

-Vikram

> 
> 
> On Mon, 8 Jul 2002, Kaixin Xu wrote:
> 
> 
> > The default values of IEEE 802.11 are 1) short retry limit 7 . 2) The
> > minimal backoff time is 31 slots and 3) the maximum backoff time is 1023
> > slots 4) the slot is 20us for DHSS and 50us for FHSS. So, the longest
> > backoff time would be (31+63+127+255+511+1023+1023+1023)*20us = 82 ms.
If
> > you then consider the time the backoff timer is suspended when the node
> > sensing the media is busy and the time for transmitting the RTS  and
time
> > for waitting CTS timeout several times, blah, blah. I think hundreds of
ms
> > delay is not rare. However, if you get delay in several seconds, that
should
> > not be common.
> 
> Hi,
> 
> You should also consider the packet retransmissions' effect on delays.
> 
> long delays are common as long you have several collisions and
> retransmissions, e.g. your scenario.
> 
> The average delay a packet observes (in a single hop, can be generalized
> for multi-hop of course) is:
> (avrg successful pkt. transmission delay) x (avrg number of pkts in the
queue)
> 
> the average number of packets in the queue is high in your simulations
> (~100)
> 
> due to high collisions and retransmissions (+ IFSs + increasing backoffs),
> the "average successful packet transmission delay" is considerably high
too,
> so it's not weird to observe delays of several seconds.
> 
> hope it helps,
> 
> imad
> 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet
> 

-- 

Department of ECE, Rice University | 713 348 3786 (O)| 713 664 5650(H)
WWW: http://www.ece.rice.edu/~kanodia 

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

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

---

From: Vikram Kanodia <[email-masked]>
Date: Tue, 9 Jul 2002 11:45:23 -0500 (CDT)

True and well put if I may say so :). 

Also, some sort of priority scheduling at the MAC layer can help alleviate
the problem. More to the point, any scheduling algorithm which can reduce
the net number of collisions (and thereby reducing retransmissions) will
help. Check out our Mobicom 2001 paper: 
    
Distributed Multi-Hop Scheduling with Delay and Throughput Constraints, 
    V. Kanodia, C. Li, A. Sabharwal, B. Sadeghi, and E. Knightly. 
    In Proceedings of ACM MOBICOM 2001, Rome, Italy, July 2001. 

Also, any sort of queue management (Diffserv? the new proposed
E-DCF ? coupled with admission control ?) may
help insulate the higher priority flows from queue overload due to
bursty/higher-input-load best effort flows.

While at this point, can someone tell me what is teh existing status of
the IEEE 802.11e working group. Has the proposal for EDCF been finalised ?

-Vikram

--

---

From: Vikram Kanodia <[email-masked]>
Date: Tue, 9 Jul 2002 11:45:23 -0500 (CDT)

-Vikram

--