Presentation is loading. Please wait.

Presentation is loading. Please wait.

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:

Similar presentations


Presentation on theme: "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:"— Presentation transcript:

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

2 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 2 The VHT activity could use a delayed “old way” process or a new “revolutionary” process Situation – “what we agree on?” The standard has historically developed using “design by committee” of amendments Complication – “what is the problem?” The 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

3 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 3 The standard has historically developed using “design by committee” of amendments As an amendment to base standard In a new base standard How does the WG specify new work? “Design by committee” “Codification of existing practice” How does the WG decide what to standardise? Today’s wayOther options Two of many possible dimensions

4 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 4 The WG methodology of “design by committee” of amendments is showing signs of stress Development of recent 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 standard document is becoming increasingly difficult to amend successfully The current standard document is suffering from the adverse effects of “design by committee”

5 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 5 Development of recent 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

6 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 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

7 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 7 The current standard document is becoming increasingly difficult to amend successfully The current 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 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 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

8 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 8 The current standard is huge (1,232 pages) and rapidly getting bigger (>2,500 pages) Base standard plus actual or likely amendments

9 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 9 The standard is suffering from the adverse effects of “design by committee” The 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 s with device, home, enterprise and municipal mesh …

10 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 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 n 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 n 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 n based approach probably does not scale and anything coming close to the “wish list” is likely to be revolutionary

11 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 11 VHT is probably revolutionary, not evolutionary and so we should look for a “revolutionary process” As amendment to base standard In a new base standard How does the WG specify new work? “Design by committee” “Codification of existing practice” How does the WG decide what to standardise? 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 Necessary optimisations may result in different answers for each environment

12 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 12 We could “codify existing practice” by being more disciplined but all previous attempts have failed  We could use today’s 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 TG’s in the recent past have floundered –TGk & TGv provide interesting examples It seems unlikely the WG can behave differently than in the past without a significant cultural change forced by …

13 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 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 –…

14 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 14 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

15 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 15 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 In the case of VHT an “appropriate” is probably 2-3 years to give interested parties time to develop sufficiently detailed & complete proposals

16 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 16 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 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

17 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 17 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 This step must be very disciplined – anything not truly complete must be rejected or we will fall back into the “old way”

18 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 18 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 If there are no “complete proposals” one option is to refine requirements and try again

19 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 19 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 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

20 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 20 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 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 – IR, FH, DS This process does not take way the “pain” but it does avoid 5-10 years of bi-monthly meetings

21 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 21 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

22 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 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

23 doc.: IEEE /2863r0 Submission Nov 2007 Andrew Myles (Cisco) et alSlide 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


Download ppt "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:"

Similar presentations


Ads by Google