Ted,
I like your queuing theory formulation. A couple of easy things follow from looking at it that way.
1. Burstiness should result in temporary queuing, but it shouldn't result in continuously growing queues. It's relatively easy to separate out the effects of insufficient capacity from burstiness. I think these effects are usually given in terms of the first and second moments, i.e. average time to get through the queue and variance.
2. There's enough data available to allow someone -- not me -- to do a little parameter fitting to one of the standard queuing models.
3. It would be interesting to get some estimates from the relevant parties such as the RFC Editor, IESG ADs, et al as to how much time they think it should take to process an individual document through their part of the system, assuming no interference or queuing effects. That would give the optimal time for processing a document and provide a baseline for understanding the queueing effects and/or other issues such as extra work for poor writing, waiting for normative references, down time for vacations, sick leave and day job, etc. (My intuition is that it shouldn't take more than about 2 days to get through each part of the process if nothing else were in the way. Except for burstiness and waiting for completion from authors, if the system were running smoothly, documents really should move that quickly. All else is a symptom something is amiss. And the numbers for the current system suggest (to me) that things are amiss big time.)
Steve
Ted Hardie wrote:
At 10:12 AM -0400 5/21/05, Dave Crocker wrote:
The only way to make sure deliveries of product -- in this case, IETF
documents -- are timely is to decide when they are needed by and set firm
deadlines. The IETF currently does not do that. Instead, we leave everything
open-ended.
This gives the unfortunate impression that setting firm deadlines is all it takes
to get product out. This is contrary to my experience, and I suspect nearly
everyone else's. I assume this is not what Dave meant, but that he is simply
pointing out the usefulness of having a deadline in planning, allocation of
resources, and setting up follow-on activity.
I'd like to suggest, though, that a better model for the problem is queuing.
At the moment, every "packet" (document) emitted by IETF working groups
and every document reviewed for the RFC Editor ultimately goes through the
same queue, which is not allowed to drop any item. The traffic is bursty
and the resources used for processing the packets have priority interrupts
for other tasks (in the individuals: day jobs, family life; for the group:
appeals, other critical IETF business).
That the queue depth gets longer should be no surprise. That moving
things around in the queue starts to happen is no surprise, even though
moving them takes energy that could have been otherwise spent on throughput.
Making deadlines ever firmer creates priority interrupts or causes more
energy to be expended in queue management instead of throughput.
My personal belief is that we need to implement multiple queues instead. If the IETF continues to believe that reviewing RFCs for end-runs is valuable, okay; let's select individuals who can undertake that review, and get it out of the "make standards" queue. I've pushed that idea before; I stopped because the simpler solution (ensure that there are sufficiently different publication avenues for standards and RFC editor documents) seemed to be gaining support and that pushed even the development of the new queue to the RFC Editor.
The fundamental idea, though, remains: important to the IETF does not mean "needs to pass through the IESG". regards, Ted Hardie
PS. I almost got through the whole email without saying "functional differentiation".
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf