submission doc.: ieee 802.11-11/0166r0january 2011 barbara staehle, uni würzburgslide 1barbara...

January 2011

Barbara Staehle, Uni Würzburg

Slide 1Submission

doc.: IEEE 802.11-11/0166r0

Barbara Staehle, Uni WürzburgSlide 1 Barbara Staehle, Uni Würzburg

Motivation for Extending the 802.11 Intra-Mesh Congestion Notification Element

Date: 2011-01-19

Name Affiliations Address Phone email Barbara Staehle University of

Würzburg Institute of CS Chair of Communication Networks

Am Hubland 97074 Würzburg

bstaehle et informatik dod uni-wuerzburg dod de

Dirk Staehle University of Würzburg Institute of CS Chair of Communication Networks

Am Hubland 97074 Würzburg

dstaehle et informatik dod uni-wuerzburg dod de

Michael Bahr Siemens AG Corporate Technology

Otto-Hahn-Ring 6 80200 München

bahr et siemens dod com

Authors:

January 2011


Slide 2Submission

doc.: IEEE 802.11-11/0166r0January 2011

Barbara Staehle, Uni WürzburgSlide 2

January 2011


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.

January 2011


Slide 3Submission

doc.: IEEE 802.11-11/0166r0

Simple Experiment

Januar 2011


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

48 Mbps

54 Mbps

48 Mbps

24 Mbps

12 Mbps

36 Mbps

36 Mbps

18 Mbps

36 Mbps

24 Mbps

1

2

3

4

5

6

7

8

9

10

G1

Mbps

6

9

12

18

24

36

48

54

communication possible

routing path

January 2011


Slide 4Submission

doc.: IEEE 802.11-11/0166r0

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


January 2011


Slide 5Submission

doc.: IEEE 802.11-11/0166r0December 2010


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).

January 2011


Slide 6Submission



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

January 2011


Slide 7Submission



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

Element ID

Length Destination Mesh STA Address

Congestion Notification Expiration Timer (AC_BK)

Congestion Notification Expiration Timer (AC_BE)

Congestion Notification Expiration Timer (AC_VI)

Congestion Notification Expiration Timer (AC_VO)

Octets: 1 1 6 2 2 2 2

Figure 7-95o135—Congestion Notification element format

January 2011


Slide 9Submission

doc.: IEEE 802.11-11/0166r0

YES, BUT NOT ALWAYS…Does this extension provide improvements?

January 2011


January 2011


Slide 10Submission

doc.: IEEE 802.11-11/0166r0

Simple Experiment


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

48 Mbps

54 Mbps

48 Mbps

24 Mbps

12 Mbps

36 Mbps

36 Mbps

18 Mbps

36 Mbps

24 Mbps

1

2

3

4

5

6

7

8

9

10

G1

Mbps

6

9

12

18

24

36

48

54

communication possible

routing path

January 2011


Slide 11Submission

doc.: IEEE 802.11-11/0166r0

1u 2u 3u 4u 5u 6u 7u 8u 9u 10u 1d 2d 3d 4d 5d 6d 7d 8d 9d 10d0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

[Mb

/s]

no CC

TCC

LSCC

PSCC

Per Flow Throughputs

January 2011


downlinkuplink

only feasible with extension

feasible without extension

no Congestion Control

January 2011


Slide 12Submission

doc.: IEEE 802.11-11/0166r0January 2011

• 40 mesh access points

• 1,2,3,4 mesh portals

Larger Topologies

1

2

3

4

5

67

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

G1

G2

G3

G4

Mb/s

6

9

12

18

24

36

48

54

1

2

3

4

5

67

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

G1

G2

G3

Mb/s

6

9

12

18

24

36

48

54

1

2

3

4

5

67

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

G1

G2

Mb/s

6

9

12

18

24

36

48

54

1

2

3

4

5

67

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

G1

Mb/s

6

9

12

18

24

36

48

54

January 2011


Slide 13Submission

doc.: IEEE 802.11-11/0166r0

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


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


node configuration

Submission

doc.: IEEE 802.11-10/1429r1January 2011January 2011

Barbara Staehle, Uni WürzburgBarbara Staehle, Uni Würzburg

Slide 14

5 10 15 20 25 30 35 40 45 500

2

4

6

8

10

12

14

16

network snapshot

thro

ug

hp

ut [

Mb

p/s

]

4 gateways, throughput, ordered by no CC throughput

no CCTCCLSCCPSCC

January 2011


Effects of IMCC on the Total Network Throughput

January 2011


each point = sum of all flow throughputs averaged over 3 runs

Submission



Slide 15

January 2011



January 2011


5 10 15 20 25 30 35 40 45 500

2

4

6

8

10

12

14

16

network snapshot

thro

ug

hp

ut [

Mb

p/s

]


no CCTCCLSCCPSCC

Submission



Slide 16

January 2011



January 2011


5 10 15 20 25 30 35 40 45 500

2

4

6

8

10

12

14

16

network snapshot

thro

ug

hp

ut [

Mb

p/s

]


no CCTCCLSCCPSCC

Submission



Slide 17

January 2011



January 2011


5 10 15 20 25 30 35 40 45 500

2

4

6

8

10

12

14

16

network snapshot

thro

ug

hp

ut [

Mb

p/s

]1 gateway, throughput, ordered by no CC throughput

no CCTCCLSCCPSCC

Submission



Slide 18

January 2011



January 2011


5 10 15 20 25 30 35 40 45 50-6

-5

-4

-3

-2

-1

0

1

2

network snapshot

thro

ughp

ut d

iffer

ence

to

no C

C [

Mbp

/s]


TCC

LSCCPSCC

Submission



Slide 19

January 2011



January 2011


5 10 15 20 25 30 35 40 45 50-8

-7

-6

-5

-4

-3

-2

-1

0

1

2

network snapshot

thro

ughp

ut d

iffer

ence

to

no C

C [

Mbp

/s]


TCC

LSCCPSCC

Submission



Slide 20

January 2011



January 2011


5 10 15 20 25 30 35 40 45 50-7

-6

-5

-4

-3

-2

-1

0

1

2

3

network snapshot

thro

ughp

ut d

iffer

ence

to

no C

C [

Mbp

/s]


TCC

LSCCPSCC

Submission



Slide 21

January 2011



January 2011


5 10 15 20 25 30 35 40 45 50-4

-3

-2

-1

0

1

2

network snapshot

thro

ughp

ut d

iffer

ence

to

no C

C [

Mbp

/s]

1 gateway, throughput, ordered by no CC throughput

TCC

LSCCPSCC

January 2011


Slide 22Submission

doc.: IEEE 802.11-11/0166r0

no CC TCC LSCC PSCC0

5

10

15to

tal t

hro

ug

hp

ut [

Mb

/s] 1 gateway


5

10

15

tota

l th

rou

gh

pu

t [M

b/s

] 2 gateways


5

10

15

tota

l th

rou

gh

pu

t [M

b/s

] 3 gateways


5

10

15

tota

l th

rou

gh

pu

t [M

b/s

] 4 gateways


January 2011


each bar = averaged over all topologies + all runs95% confidence intervals

January 2011


Slide 23Submission

doc.: IEEE 802.11-11/0166r0

Effects of IMCC on the Uplink Throughput

January 2011



1

2

3

4u

plin

k th

rou

gh

pu

t [M

b/s

] 1 gateway


1

2

3

4

up

link

thro

ug

hp

ut

[Mb

/s] 2 gateways


1

2

3

4

up

link

thro

ug

hp

ut

[Mb

/s] 3 gateways


1

2

3

4

up

link

thro

ug

hp

ut

[Mb

/s] 4 gateways

January 2011


Slide 24Submission

doc.: IEEE 802.11-11/0166r0

Effects of IMCC on the Downlink Throughput

January 2011



5

10d

ow

nlin

k th

rou

gh

pu

t [M

b/s

]

1 gateway


5

10

do

wn

link

thro

ug

hp

ut

[Mb

/s]

2 gateways


5

10

do

wn

link

thro

ug

hp

ut

[Mb

/s]

3 gateways


5

10

do

wn

link

thro

ug

hp

ut

[Mb

/s]

4 gateways

January 2011


Slide 25Submission

doc.: IEEE 802.11-11/0166r0

Effects of IMCC on the Uplink Fairness

January 2011


no CC TCC LSCCPSCC0

0.5

1u

plin

k fa

irn

ess

ind

ex

1 gateway

no CC TCC LSCCPSCC0

0.5

1

up

link

fair

ne

ss in

de

x

2 gateways

no CC TCC LSCCPSCC0

0.5

1

up

link

fair

ne

ss in

de

x

3 gateways

no CC TCC LSCCPSCC0

0.5

1

up

link

fair

ne

ss in

de

x

4 gateways

January 2011


Slide 26Submission

doc.: IEEE 802.11-11/0166r0

Effects of IMCC on the Downlink Fairness

January 2011


no CC TCC LSCCPSCC0

0.5

1d

ow

nlin

k fa

irn

ess

ind

ex 1 gateway

no CC TCC LSCCPSCC0

0.5

1

do

wn

link

fair

ne

ss in

de

x 2 gateways

no CC TCC LSCCPSCC0

0.5

1

do

wn

link

fair

ne

ss in

de

x 3 gateways

no CC TCC LSCCPSCC0

0.5

1

do

wn

link

fair

ne

ss in

de

x 4 gateways

January 2011


Slide 27Submission

doc.: IEEE 802.11-11/0166r0

Effects of IMCC on the Intra-Mesh Packet Loss

January 2011



2

4

6m

esh

loss

[Mb

/s]

1 gateway


2

4

6

me

sh lo

ss [M

b/s

]

2 gateways


2

4

6

me

sh lo

ss [M

b/s

]

3 gateways


2

4

6

me

sh lo

ss [M

b/s

]

4 gateways

January 2011


Slide 28Submission

doc.: IEEE 802.11-11/0166r0

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


January 2011


Slide 29Submission

doc.: IEEE 802.11-11/0166r0

Example where PSCC shows no Additional Benefit

January 2011


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,

18 Mbps

24 Mbps

18 Mbps

36 Mbps

24 Mbps

1

2

3

4

5

G1

Mb/s

6

9

12

18

24

36

48

54

1u 2u 3u 4u 5u 1d 2d 3d 4d 5d0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

[Mb

ps]

no CC

TCC

LSCC

PSCC

January 2011


Slide 30Submission

doc.: IEEE 802.11-11/0166r0

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

January 2011


Slide 31Submission

doc.: IEEE 802.11-11/0166r0

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)

January 2011


Slide 32Submission



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

submission doc.: ieee 802.11-11/0166r0january 2011 barbara staehle, uni würzburgslide 1barbara...

Documents