Doc.: IEEE 802.11-05/0386r1 Submission March 2006 Floyd Backes, AutoCell Laboratories, Inc. Reasons...

March 2006

Floyd Backes, AutoCell Laboratories, Inc.

doc.: IEEE 802.11-05/0386r1

Submission

Reasons Why TGV Must Agree on Algorithms to Go Along the With Protocols It Specifies

Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <[email protected]> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <[email protected]>.

Date: 2006-03-06

Name Company Address Phone email Floyd Backes AutoCell 1.978.264.4884 [email protected]

Mike Montemerro Siemens 1.905.363.6413 michael.montemurro@ siemens.com

Authors:

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

AbstractAbstract

This presentation makes the case for TGV agreeing on specifications for the algorithms that make use of the protocol enhancements adopted to support Load Balancing and Automatic Channel Selection.

Some examples are cited, as well as a discussion of what things can go wrong when a network is deployed that does not have as part of its constituent components, the intelligence necessary to ensure stable and predictable behavior.

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

Overview

• The difference between a protocol and an algorithm

• Examples of why both are needed

• Conclusions

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

Simple Example of the Difference between a Protocol and an Algorithm

• Traffic Signal– Protocol:

• Red means Stop• Green means Go

– Algorithm:• Signal Red in one direction whenever green is signaled in the opposite

direction• Algorithm must have the property that intersecting traffic flows are

never signaled green at the same time

• Protocol is not useful (indeed, dangerous) without the traffic signal control system following a known algorithm

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

Example Routing Architecture

• Standards group adopts a “libertarian” approach– Defines a common protocol– Leaves the routing algorithm up to the vendors

• Protocol rules– Links may be assigned costs– Routers advertise both:

• Hops to destination• Cost to destination

• Routing Algorithm– Left up to the vendor– Interoperability attained through “common protocol”

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


• Vendor “LC, Inc.” decides:– Our algorithm will be designed to forward packets over the least

cost path

• Vendor “SP, Inc.” decides:– Our algorithm will be designed to forward packets over the

shortest path

• Both vendors meet the standard because they both advertise both cost and hops in the protocol

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


• Customer A buys their routers from LC

• Customer B buys their routers from SC

• Customers A & B merge their companies

• The CIO of A&B, Inc. is told “We must expand our network, but we can save money by re-using the LC and SP routers we already own, which after all - both meet the standard”

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


A&C, Inc. builds the following network:

LC

SP SP SP

LC

SPUser Bob

User Alice

Cost = 5

Cost = 100

Cost = 5

Cost = 5 Cost = 5

Cost = 100

Cost = 5

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


Routers populate their routing tables with Alice’s reachability:

LC

SP SP SP

LC

SPUser Bob

User Alice

Cost = 5

Cost = 100

Cost = 5

Cost = 5 Cost = 5

Cost = 100

Alice Alice

Alice

Cost = 5Alice

Alice

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


Bob’s packets to Alice loop:

LC

SP SP SP

LC

SPUser Bob

User Alice

Cost = 5

Cost = 100

Cost = 5

Cost = 5 Cost = 5

Cost = 100

Alice Alice

Alice

Cost = 5Alice

Alice

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

What happened?

• Protocol was defined to carry enough information to make routing decisions

• Since no algorithm was specified, the system behavior was irrational because there was no shared definition of what to do with the information that was conveyed by the protocol.

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

The Fighting Neighbors

• Another libertarian standards group defines a protocol to facilitate channel selection– Add information elements to beacons that list things like

• Output Power

• Channel capability

– Leaves the channel selection algorithm up to the vendors

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


• Vendor QC, Inc. designs its algorithm to always pick the Quietest Channel

• Vendor FN, Inc. designs its algorithm to always pick the channel with the Fewest Number of heard APs

• In this story, there are only 3 non-overlapping channels, 1, 2, and 3.

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


b

d

e

c

f

3

2

1

1

2

• Left hand neighbor deploys 5 APs purchased from QC, Inc.

• They pick their channels based on the “Quietest Channel” Algorithm

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


b

d

e

c

f

3

2

1

1

2

• Right Hand neighbor buys an AP from FN, Inc. and deploys it

• It picks channel 3 based on the “Fewest Number” algorithm, since it can “hear” all the APs in the buildinga 3

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


b

d

e

c

f

2

2

1

1

2

• This chases Left Hand neighbor’s AP b off of channel 3 and on to channel 2, based on its Quietest Channel Algorithm

a 3

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


b

d

e

c

f

2

3

1

1

3

• This chases Left Hand neighbor’s APs c and e to channel 3 based on the Quietest Channel algorithm

a 3

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


b

d

e

c

f

2

3

1

1

3

• This causes Right Hand neighbor’s AP to move to channel 2 based on its Fewest Number algorithm

a 2

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


b

d

e

c

f

3

3

1

1

3

• This causes Left Hand neighbor’s AP b to move to Channel 3

a 2

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


b

d

e

c

f

3

2

2

1

2

• Left Hand neighbor’s APs c and e move to channel 2

• The cycle is complete• The cycle continues

indefinitely

a 2

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

Complexities Introduced by 802.11n

• 802.11n may utilize either 20 MHz or 40 MHz channels

• What criteria is used to decide which APs may utilize wide channels and which must use narrow channels?

• Rational admission control policies must be imposed to herd non-HT capable STAs away from at least some of the HT capable APs

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

Load Balancing

• Easy to construct similar examples of non-stable deployments

• Non-Stable conditions will exist if the criteria used to decide to move a STA from AP A to AP B are not the same as the criteria used to decide to move a STA from AP B to AP A

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

Load Balancing

• Trivially easy to to get this wrong

• If STAs and APs don’t agree on the load balancing algorithm it won’t work (i.e. oscillates or “ping pongs”)

• This is the case in most existing WLAN controllers today

• Defining protocols to request STAs to move to another BSS DOES NOT SOLVE THE PROBLEM– STA can follow the standard and ping pong

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

Load Balancing With No Standard Algorithm

• Controller and both APs all purchased from the same vendor

• Software running in non-AP STAs is from a different vendor

a

b

1

2

3

4

x

Con

trol

ler

z

= non-AP STA

= AP

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


• Controller decides to load balance STA 4 to AP aa

b

1

2

3

4

x

Con

trol

ler

z

= non-AP STA

= AP

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


• Controller decides to load balance STA 4 to AP a

• Sends a load balancing request to STA 4, which the STA honors

a

b

1

2

3

4

x

Con

trol

ler

z

= non-AP STA

= AP

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


• The RF distance to AP a relative to the location of STA 4 is above the STA’s threshold to causes it to background scan for a closer AP

a

b

1

2

3

4

x

Con

trol

ler

z

= non-AP STA

= AP

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


• The RF distance to AP a relative to the location of STA 4 is above the STA’s threshold to causes it to background scan for a closer AP

• STA 4 finds a “closer” AP (b) and comes back

a

b

1

2

3

4

x

Con

trol

ler

z

= non-AP STA

= AP

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


• Controller load balances STA 4 off to AP aa

b

1

2

3

4

x

Con

trol

ler

z

= non-AP STA

= AP

March 2006


doc.: IEEE 802.11-05/0386r1

Submission


• STA 4 comes back to AP b

• The cycle is complete, repeats indefinitely

a

b

1

2

3

4

x

Con

trol

ler

z

= non-AP STA

= AP

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

But This Can Be Solved!

• “I know, let’s limit the number of times the STA will bounce to eliminate ‘ping pong’”!

• Sounds like an Algorithm, although a pretty lame one…

March 2006


doc.: IEEE 802.11-05/0386r1

Submission

Conclusion

• If the boundaries of the system encompass the protocol, algorithms must be defined to ensure that the system does what it is designed to do.

• It is essential for correct operation of the system that Algorithms be defined for Channel Selection and Load Balancing

Doc.: IEEE 802.11-05/0386r1 Submission March 2006 Floyd Backes, AutoCell Laboratories, Inc. Reasons...

Documents

Transcript of Doc.: IEEE 802.11-05/0386r1 Submission March 2006 Floyd Backes, AutoCell Laboratories, Inc. Reasons...