Doc.: IEEE 802.11-07/2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 1 How should we manage the process for the proposed VHT activity? Date:

Nov 2007

Andrew Myles (Cisco) et al

Slide 1

doc.: IEEE 802.11-07/2863r0

Submission

How should we manage the process for the proposed VHT activity?

Date: 2007-11-13

Name Company Phone E-mail

Andrew Myles Cisco +61 2 84461010 [email protected]

Darwin Engwer Nortel +1 408 4952588 [email protected]

Authors:

Nov 2007


Slide 2

doc.: IEEE 802.11-07/2863r0

Submission

The VHT activity could use a delayed “old way” process or a new “revolutionary” process

Situation – “what we agree on?”

• The 802.11 standard has historically developed using “design by committee” of amendments

Complication – “what is the problem?”

• The 802.11 WG methodology of “design by committee” of amendments is showing signs of stress

Key line – “what should we do in context of VHT?”

• At the very least, there is a good case to delay any work in a VHT TG if we decide to use the “old way”

• VHT is probably revolutionary, not evolutionary and so we should look for a “revolutionary” process

Nov 2007


Slide 3

doc.: IEEE 802.11-07/2863r0

Submission

The 802.11 standard has historically developed using “design by committee” of amendments

As an amendment to base standard

In a newbase standard

How does the 802.11 WG specify

new work?

“Design by committee”

“Codification of existing practice”

How does the 802.11 WG decide

what to standardise?

Today’s way Other options

Two of many possible dimensions

Nov 2007


Slide 4

doc.: IEEE 802.11-07/2863r0

Submission

The 802.11 WG methodology of “design by committee” of amendments is showing signs of stress

• Development of recent 802.11 amendments is taking too long; about twice as long as ratified amendments

• The risks associated with complexity are increasing along with the number of parallel amendments

• The current 802.11 standard document is becoming increasingly difficult to amend successfully

• The current 802.11 standard document is suffering from the adverse effects of “design by committee”

Nov 2007


Slide 5

doc.: IEEE 802.11-07/2863r0

Submission

Development of recent 802.11 amendments is taking too long; about twice as long as ratified amendments

In development

Approved

Data correct as of May 07;

the “red” estimates are even longer as

of Nov 07

Nov 2007


Slide 6

doc.: IEEE 802.11-07/2863r0

Submission

The risks associated with complexity are increasing along with the number of parallel amendments

Note: excluding rollups and recommended practices, eg 11F, 11ma/mb, 11T

Nov 2007


Slide 7

doc.: IEEE 802.11-07/2863r0

Submission

The current 802.11 standard document is becoming increasingly difficult to amend successfully

• The current 802.11 standard is huge (1,232 pages) & rapidly getting bigger (>2,500 pages)– The “big picture” is too big and it is impossible to review amendments in a

reasonable time against the base standard

• The current 802.11 standard is poorly structured and written– “Too many cooks spoil the broth”, particularly when the “cooks” are not

professional technical writers

• Much of the current 802.11 standard is not used and yet these unused features are intertwined with the features that are used

• Many aspects of the current standard are ambiguous and/or inconsistent– eg this is highlighted by comments in every LB

• Truly understanding the standard requires historical knowledge that is not written down and is disappearing as the stalwarts retire

Nov 2007


Slide 8

doc.: IEEE 802.11-07/2863r0

Submission

The current 802.11 standard is huge (1,232 pages) and rapidly getting bigger (>2,500 pages)

0

500

1000

1500

2000

2500

3000

802.11-1999 802.11-1999 +amendments

802.11-2007 +amendments

Pag

es

Base standard plus actual or likely amendments

Nov 2007


Slide 9

doc.: IEEE 802.11-07/2863r0

Submission

The 802.11 standard is suffering from the adverse effects of “design by committee”

The 802.11 WG, which mostly uses “design by committee”, often:

• Makes decisions very slowly– Note small number of ratified amendment in last 5 years

• Defines too many options that will never be used– Just look at all recent amendments (and the base standard)

• Negotiates compromises where everyone is “equally unhappy” but no one is “truly happy”

• Adds features that have nothing to do with the goal – ie like an “omnibus bill” in US Congress

• Attempts to satisfy too many contradictory interests at once– eg 802.11s with device, home, enterprise and municipal mesh

• …

Nov 2007


Slide 10

doc.: IEEE 802.11-07/2863r0

Submission

At the very least, there is a good case to delay any work in a VHT TG if we decide to use the “old way”

It is to early to start witting VHT text

• User requirements for VHT are still very unclear, with little experience from 802.11n yet, and any list of proposed requirements seem to cover the usual “I wish wireless was as good as a wire”

• The primary measure proposed for VHT is throughput (>1Gb/s) and yet the real answer is a actually a trade-off between throughput, density, range, power, spectrum efficiency etc, with the optimal trade-off dependent on the particular user scenario of interest

• Unlike the 802.11n case, which was always going to be MIMO, aggregation, etc at 2.4 & 5GHz, there are no obvious candidate technologies (or even agreed bands) for VHT

• All we know is that the 802.11n based approach probably does not scale and anything coming close to the “wish list” is likely to be revolutionary

Nov 2007


Slide 11

doc.: IEEE 802.11-07/2863r0

Submission

VHT is probably revolutionary, not evolutionary and so we should look for a “revolutionary process”

As amendment to base standard

In a newbase standard

How does the 802.11 WG specify new work?

“Des

ign

by

com

mitt

ee”

“Cod

ifica

tion

of

exis

ting

prac

tice”

Ho

w d

oes

th

e 80

2.11

WG

dec

ide

wh

at t

o s

tan

dar

dis

e? The “old way”

Provides opportunity to cull the “useless” stuff

but “design by committee” unlikely to

succeed doing it

Could be difficult to incorporate

something very new in old base

The “revolutionary”

way

Why revolutionary?

• VHT pushes the technology limits in many dimensions

• It is probably very different from today’s 802.11

• Necessary optimisations may result in different answers for each environment

Nov 2007


Slide 12

doc.: IEEE 802.11-07/2863r0

Submission

We could “codify existing practice” by being more disciplined but all previous attempts have failed

• We could use today’s 802.11 methods for standards development in a more disciplined way– Only accept proposals that are proven to work (& thus are complete)

– eg, no “research proposals” or “proposals I put together on the way here”

– Only accept proposals that are “in scope”– Avoid too many options

– aka, political compromises

• However, all attempts “do it right” in various 802.11 TG’s in the recent past have floundered– TGk & TGv provide interesting examples

• It seems unlikely the 802.11 WG can behave differently than in the past without a significant cultural change forced by …

Nov 2007


Slide 13

doc.: IEEE 802.11-07/2863r0

Submission

We could also “codify existing practice” by defining a new methodology more aligned with our goal

• The problem today is that the current methodology encourages immature proposals & starts the political process far too early

• The system should be changed to give people more time & motivation to propose “mature” solutions

• One way to do this is to only allow “complete” proposals after a time period appropriate to the scope and complexity of the task

• One practical definition of “complete” might require:– Proof the proposal works

– More than the usual hand waving– Even simulations are “usually doomed to show what you want then to show”– Demonstrations are the most convincing proof

– Complete detailed specifications in a form ready to be balloted– …

Nov 2007


Slide 14

doc.: IEEE 802.11-07/2863r0

Submission

One possibility for “codify existing practice” would be to allow 2-3 years for proposal development

Determine rough requirements

Issue RFP with appropriate deadline

Provide discussion forum

Evaluate solutions for completeness

Refine requirements

Standardise all complete solutions

Let the market decide

Notes

• Can’t define detailed VHT requirements when so little is known about the market or the technology – although we all like to speculate

• The requirements could include architectural constraints or approaches

Nov 2007


Slide 15

doc.: IEEE 802.11-07/2863r0

Submission






Refine requirements



Notes

• In the case of VHT an “appropriate” is probably 2-3 years to give interested parties time to develop sufficiently detailed & complete proposals

Nov 2007


Slide 16

doc.: IEEE 802.11-07/2863r0

Submission






Refine requirements



Notes

• The TG could meet during the 2-3 year RFP period to provide a forum to discuss issues, requirements and technologies

• The TG could host discussions on likely proposals to build understanding and support

Nov 2007


Slide 17

doc.: IEEE 802.11-07/2863r0

Submission






Refine requirements



Notes

• This step must be very disciplined – anything not truly complete must be rejected or we will fall back into the “old way”

Nov 2007


Slide 18

doc.: IEEE 802.11-07/2863r0

Submission






Refine requirements



Notes

• If there are no “complete proposals” one option is to refine requirements and try again

Nov 2007


Slide 19

doc.: IEEE 802.11-07/2863r0

Submission






Refine requirements



Notes

• Standards groups are usually terrible at picking between two or more imperfect solutions, eg .15.3a

• Unlikely more that 1-2 complete solutions will be proposed because of the required investment

Nov 2007


Slide 20

doc.: IEEE 802.11-07/2863r0

Submission






Refine requirements



Notes

• The market is the best place to decide which standard is the “best”

• There is plenty of precedent for this, even in 802

– 802.3 vs .12

– 802.11 IR, FH, DS

• This process does not take way the “pain” but it does avoid 5-10 years of bi-monthly meetings

Nov 2007


Slide 21

doc.: IEEE 802.11-07/2863r0

Submission

The VHT activity could use a delayed “old way” process or a new “revolutionary” process

Key messages

• Amending the current standard is becoming very difficult– => Should consider writing new

base standard

• “Design by committee” does not work well for complex problems that require difficult compromises at the leading edge of technology– => Need to explore ways to

“codify existing practice”

Next steps

• Lets not use the “old way” without actively choosing to do so over a “revolutionary way”

• The “revolutionary way” described is one possible solution but not the only one; lets think about alternatives

Nov 2007


Slide 22

doc.: IEEE 802.11-07/2863r0

Submission

Annex: a variety of additional questions were raised during the development of this presentation

• Won’t this process give the “winner” a head-start?– Yes, in the sense they would have been working on the proposal for a while– No, in the sense that they will need to work with others for the standard to be

successful, and no doubt at least some changes will be made during the standardisation process

• How do we maintain backward compatibility if we create a new base standard?– The new base standard would need to ensure co-existence with legacy

devices (assuming they operated in the same band)– There are many ways to do this including embedding an entire legacy

implementation in a VHT device

Nov 2007


Slide 23

doc.: IEEE 802.11-07/2863r0

Submission

Annex: a variety of additional questions were raised during the development of this presentation

• How will smaller stakeholders participate?– Probably by participating in consortiums

• Why will consortiums be any more successful than the “old way”– Maybe they will not be more successful– However, smaller size and aligned business goals will probably increase

possibility of success

Documents

Doc.: IEEE 802.11-07/2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 1 How should we manage the process for the proposed VHT activity? Date: