Presentation is loading. Please wait.

Presentation is loading. Please wait.

Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 1Barbara Staehle, Uni WürzburgSlide 1Barbara Staehle, Uni Würzburg.

Similar presentations


Presentation on theme: "Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 1Barbara Staehle, Uni WürzburgSlide 1Barbara Staehle, Uni Würzburg."— Presentation transcript:

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


Download ppt "Submission doc.: IEEE 802.11-11/0166r0January 2011 Barbara Staehle, Uni WürzburgSlide 1Barbara Staehle, Uni WürzburgSlide 1Barbara Staehle, Uni Würzburg."

Similar presentations


Ads by Google