Subject: [newtrk] (partial) myth of the IESG bottleneck

From: Keith Moore <[email-masked]>
Date: Tue, 30 Mar 2004 10:23:31 -0500

The mention of the IESG bottleneck reminds me of a discussion I was in 
several days ago about APIs used to communicate between nodes in 
large-scale computing clusters.  One statement stands out my memory.

"Application programmers always blame the communications network for 
delays," this guy said, "because when they do timing measurements they 
show a significant amount of time spent waiting for communication.  But 
the real problem is usually in the application.  Either the application 
doesn't reserve space for the expected data and post an asynchronous 
read request in advance, or the application doesn't balance the load 
well between nodes and the amount of time spent waiting is directly 
attributable to the need to synchronize between nodes with different 
amounts of work to do".

Okay, so that's a really geeky analogy.  The point is that the fact 
that there's a bottleneck that's happening in some place (say, IESG) 
does not mean that that place is the cause of the bottleneck.  And 
sometimes you can't fix that bottleneck without tweaking a different 
part of the system.

Trying to keep WGs from interfering with other WGs, or with other 
interests not represented by WGs, is a bit like synchronizing 
independent computations in a cluster (except that in IETF, all of the 
WGs are doing different things).  At present we are expecting all of 
the synchronization to be done by IESG.  There are clearly scaling 
limits to that approach.  If nothing else, any WG that causes IESG to 
spend a lot of time deliberating causes IESG to delay responding to 
other WG's requests - so even a few bad WGs gum up the works for 
everyone [*].  So moving some of this synchronization out of IESG is 
potentially a good idea.  However the WGs are not competent to judge 
whether their work is impacting other areas, or even to decide which 
areas their work might be impacting.  So we can't completely dispense 
with having some degree of oversight by people who are thinking in 
terms of the big picture rather than in terms of WG-specific goals.  
Some of the "synchronization delays" are inherent in the problem.

The other useful part of this analogy is that WGs must work to avoid 
stalls due to communications.  This means (among other things) making 
note of potential problems or conflicts as early as possible and making 
sure that they are resolved long before the design is frozen.

Keith

[*] Part of the answer might be to empower IESG to simply say "no" when 
a WG presents it with work that is incomplete, has not had the required 
level of review, has failed to address concerns identified by 
reviewers, or has failed to address basic requirements.  Right now we 
expect IESG to essentially solve the problem - by explaining in detail 
what it will take to fix the problem.  This causes delays for _all_ 
WGs.  Instead the IESG should simply say "You didn't do your homework.  
Come back when you have it done right".

Ideally of course this problem would be identified much earlier, by the 
supervising AD, who could then replace the WG Chair and/or take other 
corrective action.  This in turn requires giving WGs clear requirements 
about what kind of external review to get and at what intervals, how to 
respond to reviewers' comments, and how to keep track of unresolved 
issues.

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html