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

1. How should we manage the process for the proposed VHT activity? • Authors: • Date: 2007-11-13 Andrew Myles (Cisco) et al

2. 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 Andrew Myles (Cisco) et al

3. The 802.11 standard has historically developed using “design by committee” of amendments Today’s way Other options As an amendment to base standard How does the 802.11 WG specify new work? In a newbase standard “Design by committee” How does the 802.11 WG decide what to standardise? “Codification of existing practice” Two of many possible dimensions Andrew Myles (Cisco) et al

4. 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” Andrew Myles (Cisco) et al

5. Development of recent 802.11 amendments is taking too long; about twice as long as ratified amendments Data correct as of May 07; the “red” estimates are even longer as of Nov 07 In development Approved Andrew Myles (Cisco) et al

6. 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 Andrew Myles (Cisco) et al

7. 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 Andrew Myles (Cisco) et al

8. The current 802.11 standard is huge (1,232 pages) and rapidly getting bigger (>2,500 pages) Base standard plus actual or likely amendments Andrew Myles (Cisco) et al

9. 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 • … Andrew Myles (Cisco) et al

10. 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 Andrew Myles (Cisco) et al

11. VHT is probably revolutionary, not evolutionary and so we should look for a “revolutionary process” How does the 802.11 WG specify new work? • 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 As amendment to base standard In a newbase standard The “old way” Provides opportunity to cull the “useless” stuff but “design by committee” unlikely to succeed doing it “Design by committee” How does the 802.11 WG decide what to standardise? Could be difficult to incorporate something very new in old base The “revolutionary” way “Codification of existing practice” Andrew Myles (Cisco) et al

12. 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 … Andrew Myles (Cisco) et al

13. 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 • … Andrew Myles (Cisco) et al

14. One possibility for “codify existing practice” would be to allow 2-3 years for proposal development Determine rough requirements • 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 Issue RFP with appropriate deadline Provide discussion forum Refine requirements Evaluate solutions for completeness Standardise all complete solutions Let the market decide Andrew Myles (Cisco) et al

15. One possibility for “codify existing practice” would be to allow 2-3 years for proposal development Determine rough 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 Issue RFP with appropriate deadline Provide discussion forum Refine requirements Evaluate solutions for completeness Standardise all complete solutions Let the market decide Andrew Myles (Cisco) et al

16. One possibility for “codify existing practice” would be to allow 2-3 years for proposal development Determine rough 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 Issue RFP with appropriate deadline Provide discussion forum Refine requirements Evaluate solutions for completeness Standardise all complete solutions Let the market decide Andrew Myles (Cisco) et al

17. One possibility for “codify existing practice” would be to allow 2-3 years for proposal development Determine rough requirements • Notes • This step must be very disciplined – anything not truly complete must be rejected or we will fall back into the “old way” Issue RFP with appropriate deadline Provide discussion forum Refine requirements Evaluate solutions for completeness Standardise all complete solutions Let the market decide Andrew Myles (Cisco) et al

18. One possibility for “codify existing practice” would be to allow 2-3 years for proposal development Determine rough requirements • Notes • If there are no “complete proposals” one option is to refine requirements and try again Issue RFP with appropriate deadline Provide discussion forum Refine requirements Evaluate solutions for completeness Standardise all complete solutions Let the market decide Andrew Myles (Cisco) et al

19. One possibility for “codify existing practice” would be to allow 2-3 years for proposal development Determine rough 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 Issue RFP with appropriate deadline Provide discussion forum Refine requirements Evaluate solutions for completeness Standardise all complete solutions Let the market decide Andrew Myles (Cisco) et al

20. One possibility for “codify existing practice” would be to allow 2-3 years for proposal development Determine rough 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 Issue RFP with appropriate deadline Provide discussion forum Refine requirements Evaluate solutions for completeness Standardise all complete solutions Let the market decide Andrew Myles (Cisco) et al

21. 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 The VHT activity could use a delayed “old way” process or a new “revolutionary” process Andrew Myles (Cisco) et al

22. 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 Andrew Myles (Cisco) et al

23. 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 Andrew Myles (Cisco) et al