Re: Uneccesary slowness.

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 mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf