Re: [RAI] Making RAI work better
<Markus.Isomaki@nokia.com> Wed, 01 October 2008 09:34 UTC
Return-Path: <rai-bounces@ietf.org>
X-Original-To: rai-archive@optimus.ietf.org
Delivered-To: ietfarch-rai-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79ACC3A6C22; Wed, 1 Oct 2008 02:34:41 -0700 (PDT)
X-Original-To: rai@core3.amsl.com
Delivered-To: rai@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB563A6C1C for <rai@core3.amsl.com>; Wed, 1 Oct 2008 02:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ov2zshJKWDzl for <rai@core3.amsl.com>; Wed, 1 Oct 2008 02:34:38 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8417C3A6C14 for <rai@ietf.org>; Wed, 1 Oct 2008 02:34:38 -0700 (PDT)
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m919Yhhh012965; Wed, 1 Oct 2008 04:34:59 -0500
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Oct 2008 12:34:54 +0300
Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Oct 2008 12:34:54 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 01 Oct 2008 12:34:53 +0300
Message-ID: <C84E0A4ABA6DD74DA5221E0833A35DF30AE930BB@esebe101.NOE.Nokia.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0011FF7AF@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [RAI] Making RAI work better
Thread-Index: AckjbfK7ssEvNypHTLqb2zjXl6gXNAALX8ygAAIyVaA=
References: <552C9CF9-94FB-42D4-875F-0D2440951DCB@cisco.com><7C6C126D-71DA-4559-AEA4-581BCE82A7F8@softarmor.com><48E2E118.7050700@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D0011FF7AF@GBNTHT12009MSX.gb002.siemens.net>
From: Markus.Isomaki@nokia.com
To: john.elwell@siemens.com, adam@nostrum.com, dean.willis@softarmor.com
X-OriginalArrivalTime: 01 Oct 2008 09:34:54.0409 (UTC) FILETIME=[F5EB5B90:01C923A8]
X-Nokia-AV: Clean
Cc: rai@ietf.org
Subject: Re: [RAI] Making RAI work better
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rai-bounces@ietf.org
Errors-To: rai-bounces@ietf.org
Hi, Wrt. RAI originated technologies, standardization is an issue, but I'm actually much more worried on how long it takes for many important features/mechanisms to really hit the market, i.e. deployments or even just implementations. As we have seen in various interoperability discussions, the world is still full of problems that we have already kind of solved in standards, but unfortunately people are not using correctly. On the other hand, sometimes the market confusion clearly seems to stem from slowness in standardization. For instance ICE and SIP-outbound are things that we would have really needed a few years ago already. But now, most networks have taken different approaches (mostly SBC based hacks) and personally I can't anymore determine if ICE and SIP-outbound will make any difference or not (I hope they will). I mean, if running (== in use in real deployments) code was our guiding light for RAI, we might need to do a few things differently from how we are doing them currently. Just as an anecdote I could mention the MSRP NAT traversal discussion in SIMPLE, where I have been involved. MSRP relays are a nice thing, but if most of running code (deployments) are something else, it won't make sense to base our future work on them, but some other type of middlebox-traversal design. This concern is a bit off-the-topic here, but nevertheless very important for anyone working with RAI standards (and worrying about how they are put into use). I'm nowadays more inclined to support work that tries to fix existing problems (although this is quite boring) rather than doing some cool new stuff. Markus >-----Original Message----- >From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On >Behalf Of ext Elwell, John >Sent: 01 October, 2008 11:19 >To: Adam Roach; Dean Willis >Cc: rai@ietf.org >Subject: Re: [RAI] Making RAI work better > >Adam, > >I think you make good points. Theoretically the deliverable >dates should focus our attention on the ones with earlier >dates, but that doesn't seem to happen. Perhaps we should set >dates (i.e., achievable dates) only for a small number of >items per WG and push very hard to achieve those. I would not >want to throw out discussions on future topics altogether - >that is a recipe for stagnation - but due priority has to be >given to a small number of achievable targets. Others we can >keep in a pool and assign dates when resources become >available, i.e., when we have finished some other targets. If >technical difficulties arise with a particular deliverable, we >can of course delay that, and maybe promote something else to >take its place. > >As a participant, how these items are split between groups is >of less importance, but if Dean considers the chairs to be >overloaded (which I can believe), then by all means go for a >greater number of groups. > >The whole end-to-end process needs looking at, not just what >happens in the WG. To take a recent example, by my records >cc-transfer started WGLC in August 2005 and has only just gone >to IESG last call. I am sure there were delays from all >parties (WG members, WG chairs, editors and ADs), and I am >sure some valid technical concerns came up during that time. >But 3 years! > >John > >> -----Original Message----- >> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On >Behalf Of >> Adam Roach >> Sent: 01 October 2008 03:32 >> To: Dean Willis >> Cc: rai@ietf.org >> Subject: Re: [RAI] Making RAI work better >> >> I think the problem is that we're constantly increasing the >number of >> threads (documents) we're working on, while the number of CPU cores >> (key >> participants) remains fairly constant. We're CPU bound. >> Increasing the >> number of processes (working groups) so that they can each >have fewer >> threads in them (but still the same number of threads >> overall) doesn't >> change the fundamental problem that we're simply out of CPU cycles. >> >> Given that we don't know how to increase the number of processor >> cores, the only thing we can usefully play around with is thread >> scheduling. Do we throw all the threads on the processor cores at >> once, so that they all make progress all the time, but take five to >> ten years each to complete? Or do we strictly limit the number of >> threads so that each one completes fairly rapidly and gets >out of the >> way for the next one? >> >> I think the latter approach would be far more productive. >When I move >> between work items, I know I have to swap information back into my >> head to just have the context to think about the related >problems. For >> the past few years, most of my IETF work has been characterized by >> thrashing, in which I spend much more time re-learning the >context for >> a piece of work than I do actually thinking about the >problems related >> to that work. This is 100% because there's too much going >on, and it's >> all too tightly interconnected to focus on small niches. >> >> Robert has pointed out that we can never say "no," only say >"not now." >> I agree with this statement; however, I would go one step further to >> argue that we don't even say "not now" nearly often enough. >And we've >> become highly inefficient for it. >> >> /a >> >> Dean Willis wrote: >> > >> > The main problem we have with RAI is that some of our >> working groups >> > have dozens of documents. Both the brainspace of the WG and the >> > attentions of the management team (aka, Keith and I, for SIP) are >> > consumed with swapping between documents trying to give "fair" >> > treatment to all. Hence, the urgent is balanced against the >> important, >> > and we end up more and more fragmented. >> > >> > We have huge, eternal working groups that don't focus well. Our >> > meetings can't focus, our mailing lists can't focus, our >management >> > can't focus, and our participants can't focus. We're like >> > three-year-olds in a three-ring circus, too busy gawking at >> the other >> > clowns to get any work done. >> > >> > Several years ago, I proposed a reorganization (slides at >> > >> http://www.ietf.org/proceedings/06mar/slides/raiarea-3/sld1.htm). The >> > consensus at the time was simply to have more rigorous chairs. We >> > added Keith, who is quite a rigorous chair, and it >helped, but not >> > enough. We've also tried more organized chairs, like Mary, in >> > SIPPING. Again, this helped, but not enough. >> > >> > I maintain that what is needed is to reduce the size of a >> chair's job >> > so that it can be done well in a reasonable 4-6 hours per >> week, rather >> > than done badly with a workload more like 30 hours per week. The >> > easiest way to do this is to divide the problems up across more >> > chairs. Of course, getting rid of a few problems would help too. >> > >> > Towards this end, I recently suggested a reorganization (see >> > http://www.ietf.org/mail-archive/web/sip/current/msg23692.html). >> > >> > This reorg proposed replacing SIP and SIPPING with a couple >> of smaller >> > working groups with narrow charters, including (not nec. in >> this order): >> > >> > 1) RAI Maintenance: Essential corrections to existing RFCs. No >> > semantic or functional changes, just bug fixes. >> > >> > 2) SIP Draft Standard: Whatever is needed to move the SIP >> spec family >> > to draft standard >> > >> > 3) Real-Time Operations: Deals with the questions of how to do "x" >> > with SIP and related specs >> > >> > 4) Real-Time Policies: Session policies, SAML, etc. >> > >> > 5) real-Time Identity Expression, for which I proposed a charter: >> > http://www.ietf.org/mail-archive/web/sip/current/msg23899.html >> > >> > There are some other things that SIP is close to finishing >> and should >> > just be left there. I suspect the same is true of SIPPING. >> When done, >> > we close those nuthouses down. >> > >> > Big, complex documents that have a lot of things depending on them >> > belong in their own dedicated working groups with a dedicated >> > management team. >> > >> > Related sets of documents with tight interdependencies also >> belong in >> > their own working groups. For example, the SIP Consent >> Framework and >> > the half-dozen drafts detailing how to use contact-lists >> for various >> > SIP requests might have made for a reasonably chartered >> working group >> > with a reasonable 2-year lifespan. A working group that >> could actually >> > finish, go away, and free up resources for new work. >> > >> > Here's how I envision this working: If somebody dreams up >a new SIP >> > extension that does something the RTOps group can't figure >> out how to >> > do reasonably with what we have, then we run a BOF and see >if it is >> > worth working on. If so, then we charter a working group, >> If not, we >> > either pursue AD-sponsored individual informational >> (assuming it does >> > not need to be a STD track), or we don't work on it. If we >> have more >> > WGs than meeting slots, some WGs don't meet, and we don't >> charter new >> > ones until the schedule is relieved. >> > >> > >> > -- >> > Dean >> > >> > >> > >> > _______________________________________________ >> > RAI mailing list >> > RAI@ietf.org >> > https://www.ietf.org/mailman/listinfo/rai >> >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai >> >_______________________________________________ >RAI mailing list >RAI@ietf.org >https://www.ietf.org/mailman/listinfo/rai > _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai
- [RAI] Making RAI work better Cullen Jennings
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Adam Roach
- Re: [RAI] Making RAI work better Adam Roach
- Re: [RAI] Making RAI work better Peterson, Jon
- Re: [RAI] Making RAI work better Elwell, John
- Re: [RAI] Making RAI work better Lars Eggert
- Re: [RAI] Making RAI work better Markus.Isomaki
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Adam Roach
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Francois Audet
- Re: [RAI] Making RAI work better Ben Campbell
- [RAI] Persistence of Consensus [apologies to Salv… Ben Campbell
- Re: [RAI] Persistence of Consensus [apologies to … Mike Hammer (hmmr)
- Re: [RAI] Persistence of Consensus [apologies to … Ben Campbell
- Re: [RAI] Persistence of Consensus [apologies to … Mary Barnes
- Re: [RAI] Persistence of Consensus [apologies to … Henning Schulzrinne
- Re: [RAI] Persistence of Consensus [apologies to … Vijay K. Gurbani
- Re: [RAI] Persistence of Consensus [apologies to … Dan York
- Re: [RAI] Persistence of Consensus [apologies to … Peterson, Jon
- Re: [RAI] Making RAI work better Peterson, Jon
- Re: [RAI] Making RAI work better Dan York
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Greg Herlein
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Adam Roach
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Hisham Khartabil
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Miguel A. Garcia
- Re: [RAI] Persistence of Consensus [apologies to … Marshall Eubanks
- Re: [RAI] Persistence of Consensus [apologies to … Mary Barnes
- Re: [RAI] Making RAI work better Henry Sinnreich
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better -- categorizing … Markus.Isomaki
- Re: [RAI] Making RAI work better -- categorizing … Miguel A. Garcia
- Re: [RAI] Making RAI work better -- categorizing … Mary Barnes
- Re: [RAI] Making RAI work better - other SDOs Markus.Isomaki
- Re: [RAI] Making RAI work better Livingood, Jason
- Re: [RAI] Making RAI work better Livingood, Jason
- Re: [RAI] Persistence of Consensus [apologies to … Randall Gellens
- Re: [RAI] Making RAI work better DRAGE, Keith (Keith)
- Re: [RAI] Making RAI work better Henry Sinnreich
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Eric Burger
- Re: [RAI] Making RAI work better DRAGE, Keith (Keith)
- Re: [RAI] Making RAI work better Eric Burger
- Re: [RAI] Making RAI work better- or the SIP liqu… Richard Shockey
- Re: [RAI] Making RAI work better Richard Shockey
- Re: [RAI] Making RAI work better Peterson, Jon
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Brian Rosen
- Re: [RAI] Making RAI work better Ben Campbell
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Dan York
- Re: [RAI] Making RAI work better Brian Rosen
- Re: [RAI] Making RAI work better Brian Rosen
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Mike Hammer (hmmr)
- Re: [RAI] Making RAI work better Dan York
- Re: [RAI] Making RAI work better Francois Audet
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Mike Hammer (hmmr)
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Richard Shockey
- Re: [RAI] Making RAI work better Richard Shockey
- Re: [RAI] Making RAI work better Jean-Francois Mule
- Re: [RAI] Making RAI work better Gonzalo Camarillo
- Re: [RAI] Making RAI work better Spencer Dawkins
- Re: [RAI] Making RAI work better Henry Sinnreich
- Re: [RAI] Making RAI work better -- running code Markus.Isomaki
- Re: [RAI] Making RAI work better -- running code Mary Barnes
- Re: [RAI] Making RAI work better -- running code Eric Burger
- Re: [RAI] Making RAI work better -- running code Peter Saint-Andre
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better -- running code Marc Petit-Huguenin
- Re: [RAI] Making RAI work better -- running code Peterson, Jon
- Re: [RAI] Making RAI work better -- running code Dan Wing
- Re: [RAI] Making RAI work better Tom Taylor
- Re: [RAI] Making RAI work better -- running code Colin Perkins
- Re: [RAI] Making RAI work better Elwell, John
- Re: [RAI] Making RAI work better -- running code Gonzalo Camarillo
- Re: [RAI] Making RAI work better Gonzalo Camarillo
- Re: [RAI] Making RAI work better -- running code Marc Petit-Huguenin
- Re: [RAI] Making RAI work better -- running code Hannes Tschofenig
- Re: [RAI] Making RAI work better -- running code Henry Sinnreich
- Re: [RAI] Making RAI work better -- running code Gonzalo Camarillo
- Re: [RAI] Making RAI work better -- running code Henning Schulzrinne
- Re: [RAI] Making RAI work better Jonathan Rosenberg
- Re: [RAI] Making RAI work better Markus.Isomaki
- Re: [RAI] Making RAI work better Miguel A. Garcia
- Re: [RAI] Making RAI work better Gonzalo Camarillo
- Re: [RAI] Making RAI work better Hisham Khartabil
- Re: [RAI] Making RAI work better Livingood, Jason
- Re: [RAI] Making RAI work better Livingood, Jason
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Elwell, John