Download presentation
Presentation is loading. Please wait.
Published byRyan Loxley Modified over 10 years ago
1
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 1Barbara Staehle, Uni WürzburgSlide 1Barbara Staehle, Uni Würzburg Motivation for Extending the 802.11 Intra- Mesh Congestion Notification Element Date: 2011-01-19 Authors:
2
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 2 January 2011 Barbara Staehle, Uni WürzburgSlide 2 January 2011 Barbara Staehle, Uni Würzburg Abstract This presentation provides the motivation for the extension of the Congestion Notification element described in IEEE 802.11-10/1429r1 and IEEE 802.11- 10/1428r2. It contains results clarifying if, how, and where such an extension allows additional beneficial CC algorithms and performance improvements. The presentation addresses CID 1314.
3
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 3 Simple Experiment Januar 2011 Barbara Staehle, Uni WürzburgSlide 3 APP TCP / UDP IP Mesh LLC Mesh MAC PHY 5 Mb/s down, 1 Mb/s up CBR UDP IP Mesh LLC RTS/CTS 6, 9, 12, 18, 24, 36, 48, 54 Mb/s @ 2.4GHz node configuration heavy congestion communication possible routing path
4
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 4 Considered IMCC Algorithms TCC (Total Congestion Control) –receivers of Congestion Control Notification Frame (CCNF) stop all transmissions LSCC (Link Selective Congestion Control) –receivers of Congestion Control Notification Frame (CCNF) stop all transmissions to the sender of CCNF PSCC (Path Selective Congestion Control) –receivers of Congestion Control Notification Frame (CCNF) stop all transmissions to the sender of the CCNF that are destined to the destination given in the contained Congestion Notification elements (CNE). Congestion Notification elements are indirectly propagated –since receiver of CCNF stops some transmissions, it might become congested itself –if receiver of CCNF gets congested it will send a CCNF as well. January 2011 Barbara Staehle, Uni WürzburgSlide 4
5
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 5 December 2010 Barbara Staehle, Uni Würzburg Congestion Situation A Link selective congestion control is helpful in the situation depicted below: C is not able to forward packets from mesh STA B fast enough over link (C,D) and consequently sends a Congestion Notification element to mesh STA B. This causes B to apply local rate control as specified in 11C.11 in order to avoid a waste of mesh resources. In turn, B can not forward the packets from A fast enough and will send a Congestion Notification element to mesh STA A. Despite the congestion detected at mesh STA B, E is still allowed to send packets to mesh STA B, as there is no congestion for link (B,A).
6
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 6 December 2010 Barbara Staehle, Uni Würzburg Congestion Situation B The Congestion Notification element described in 7.3.2.99 of D7.0 does, however, NOT support a path selective congestion control which would be necessary to avoid the waste of mesh resources in the situation depicted below. Due to the same reasons as before, B has to use the Congestion Notification element to cause A to apply local rate control as specified in 11C.11 in order to avoid a waste of mesh resources. However, B could still forward packets from mesh STA A to mesh STA E. In order to avoid an unnecessary throughput reduction by the congestion control, the Congestion Notification element has to indicate that A should apply rate control only to packets destined for D and not for packets with mesh destination E. This was not possible in D7.0 but is possible with the extension of the format of the Congestion Notification element in D8.0
7
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 7 December 2010 Barbara Staehle, Uni Würzburg Congestion Notification element extension of D8.0 Extend the format of the Congestion Notification element with the mesh destination in order to indicate which path causes the congestion. “The Destination Mesh STA Address field is represented as a 48-bit MAC address and is set to the address of the mesh destination for which the intra-mesh congestion control shall be applied. It is set to the broadcast address if the intra- mesh congestion control shall be applied to all destinations.” (i.e. broadcast address = functionality as in D7.0) multiple Congestion Notification elements in a single Congestion Control Notification frame additions to 11C.11.2 Congestion Control Signalling Protocol to accommodate extension full proposed normative text in 11-10/1428r2
8
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 8 Requirements of the CC Algorithms TCC –monitoring of MAC layer sending buffer –effort O(1), in the example one variable LSCC –buffer monitoring on per incoming link basis –effort O(node degree), in the example up to 3 variables PSCC –buffer monitoring on per end-to-end flow basis –worst case effort O(#nodes ^2), in the example up to 16 variables –extension of CNE January 2011 Barbara Staehle, Uni WürzburgSlide 8
9
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 9 YES, BUT NOT ALWAYS… Does this extension provide improvements? January 2011 Barbara Staehle, Uni WürzburgSlide 9
10
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 10 Simple Experiment Barbara Staehle, Uni WürzburgSlide 10 APP TCP / UDP IP Mesh LLC Mesh MAC PHY 5 Mb/s down, 1 Mb/s up CBR UDP IP Mesh LLC RTS/CTS 6, 9, 12, 18, 24, 36, 48, 54 Mb/s @ 2.4GHz node configuration heavy congestion communication possible routing path
11
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 11 Per Flow Throughputs January 2011 Barbara Staehle, Uni WürzburgSlide 11 downlinkuplink only feasible with extension feasible without extension no Congestion Control
12
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 12 January 2011 40 mesh access points 1,2,3,4 mesh portals Larger Topologies
13
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 13 Simulation Setup 40 mesh access points, 1,2,3,4 mesh portals, static routing 50 x 4 randomly generated network snapshots = station locations 3 runs of 30 sec duration per network snapshot constant traffic pattern, static routing small variances for runs in one topology 95% confidence intervals not shown as near to 0 BUT: variances between the topologies January 2011 Barbara Staehle, Uni WürzburgSlide 13 300 kb/s down, 100 kb/s up CBR UDP IP Mesh LLC RTS/CTS 6, 9, 12, 18, 24, 36, 48, 54 Mb/s @ 2.4GHz January 2011 Barbara Staehle, Uni Würzburg node configuration
14
Submission doc.: IEEE 802.11-10/1429r1January 2011January 2011 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni WürzburgSlide 14 January 2011 Barbara Staehle, Uni WürzburgSlide 14 Effects of IMCC on the Total Network Throughput January 2011 Barbara Staehle, Uni Würzburg each point = sum of all flow throughputs averaged over 3 runs
15
Submission doc.: IEEE 802.11-10/1429r1January 2011January 2011 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni WürzburgSlide 15 January 2011 Barbara Staehle, Uni WürzburgSlide 15 Effects of IMCC on the Total Network Throughput January 2011 Barbara Staehle, Uni Würzburg
16
Submission doc.: IEEE 802.11-10/1429r1January 2011January 2011 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni WürzburgSlide 16 January 2011 Barbara Staehle, Uni WürzburgSlide 16 Effects of IMCC on the Total Network Throughput January 2011 Barbara Staehle, Uni Würzburg
17
Submission doc.: IEEE 802.11-10/1429r1January 2011January 2011 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni WürzburgSlide 17 January 2011 Barbara Staehle, Uni WürzburgSlide 17 Effects of IMCC on the Total Network Throughput January 2011 Barbara Staehle, Uni Würzburg
18
Submission doc.: IEEE 802.11-10/1429r1January 2011January 2011 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni WürzburgSlide 18 January 2011 Barbara Staehle, Uni WürzburgSlide 18 Effects of IMCC on the Total Network Throughput January 2011 Barbara Staehle, Uni Würzburg
19
Submission doc.: IEEE 802.11-10/1429r1January 2011January 2011 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni WürzburgSlide 19 January 2011 Barbara Staehle, Uni WürzburgSlide 19 Effects of IMCC on the Total Network Throughput January 2011 Barbara Staehle, Uni Würzburg
20
Submission doc.: IEEE 802.11-10/1429r1January 2011January 2011 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni WürzburgSlide 20 January 2011 Barbara Staehle, Uni WürzburgSlide 20 Effects of IMCC on the Total Network Throughput January 2011 Barbara Staehle, Uni Würzburg
21
Submission doc.: IEEE 802.11-10/1429r1January 2011January 2011 Barbara Staehle, Uni WürzburgBarbara Staehle, Uni WürzburgSlide 21 January 2011 Barbara Staehle, Uni WürzburgSlide 21 Effects of IMCC on the Total Network Throughput January 2011 Barbara Staehle, Uni Würzburg
22
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 22 Effects of IMCC on the Total Network Throughput January 2011 Barbara Staehle, Uni WürzburgSlide 22 each bar = averaged over all topologies + all runs 95% confidence intervals
23
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 23 Effects of IMCC on the Uplink Throughput January 2011 Barbara Staehle, Uni WürzburgSlide 23
24
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 24 Effects of IMCC on the Downlink Throughput January 2011 Barbara Staehle, Uni WürzburgSlide 24
25
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 25 Effects of IMCC on the Uplink Fairness January 2011 Barbara Staehle, Uni WürzburgSlide 25
26
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 26 Effects of IMCC on the Downlink Fairness January 2011 Barbara Staehle, Uni WürzburgSlide 26
27
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 27 Effects of IMCC on the Intra-Mesh Packet Loss January 2011 Barbara Staehle, Uni WürzburgSlide 27
28
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 28 Situation-dependent Additional Benefit of PSCC Large tree-like traffic patterns (access networks) non-tree routing structures (intra-mesh traffic) large networks heterogeneous traffic demands Small small networks where every transmission contends with the bottleneck link January 2011 Barbara Staehle, Uni WürzburgSlide 28
29
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 29 Example where PSCC shows no Additional Benefit January 2011 Barbara Staehle, Uni WürzburgSlide 29 5 Mb/s down, 1 Mb/s up CBR UDP IP Mesh LLC RTS/CTS 6, 9, 12, 18, 24, 36, 48, 54 Mbps @ 2.4GHz node configuration bottleneck link,
30
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 30 Summary PSCC (based on the extension of the Congestion Notification element) provides improvements about TCC and LSCC in many cases. PSCC is always at least as good as TCC and LSCC PSCC provides better fairness than TCC and LSCC degree of improvement depends on topology and traffic pattern
31
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 31 CID 1314 comment: The congestion control signalling is modified without having enough justification (such as simulation results). The benefit of the proposed method needs to be shown. Otherwise, the newly proposed scheme should be removed. commenter‘s proposed resolution: As in comment resolution: The modifications of the congestion notification element have been justified by doc 11- 11/xxxx. No changes have to be made to the draft. resolution code: Reject. (because no changes to draft)
32
Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 32 December 2010 Barbara Staehle, Uni Würzburg References Desheng Fu, Barbara Staehle, Rastin Pries, Dirk Staehle, „On the Potential of IEEE 802.11s Intra-Mesh Congestion Control“, MSWiM, October 2010, Bodrum, Turkey 11-10/1429r1, B.Staehle, D. Staehle, M. Bahr: Proposed change to 802.11 Intra-Mesh Congestion Notification Element, December 2010 11-10/1428r2, M. Bahr, B. Staehle, D. Staehle, D. Harkins: „Destination Address in Congestion Notification“, December 2010 IEEE 802.11s Draft Standard D7.03 IEEE 802.11s Draft Standard D8.0
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.