[AFS3-std] Re: rx throtll counts in rx-debug-peers (was: Re: Re: Request for new fields in rx_statistics)

[Andrew Deason]

On Wed, 09 Mar 2011 14:59:18 -0500
Michael Meffie <mmeffie@sinenomine.net> wrote:

> I would like to claim two of 10 spares in the rx_debugPeer structure
> to report the rx throttle counts.  The two new fields would be,
> 
>    afs_uint32 nDelayedConnAborts;
>    afs_uint32 nDelayedCallAborts;
> 
> This would allow us to help track peers which are being delayed
> aborts.  I am still of the opinion that an over all counter would
> be helpful as a general metric, however at least having per peer
> counts would allows us to better identify the peers being shunned.
> 
> With the list members' consent, I could publish Nickolai Zeldovich's
> rx-spec in RFC format with the rx-debug structures.

I've had conversations with a few people about this today, so I wanted
to raise the question here: do the debug fields belong in an AFS-3
standard? After discussing this a bit, it seems more appropriate for the
debug packet payload to be defined as an implementation-specific blob.
Since the fields often involve statistics and states, etc, that are
clearly implementation-specific (RX call structure state, allocation
statistics, and arguably "throttling", etc).

However, that does not preclude a specification, which raises another
question: can/should we publish OpenAFS-specific standards? If we make
I-Ds that clearly demarcate themselves as for OpenAFS and not AFS-3 in
general, it would seem valuable as a standard specification for these
kinds of things. The same thing could go for the Ubik voting/beacon
protocols, cmdebug, and other things that so far have appeared to be
considered "internal" to OpenAFS, but still travel over the wire.

-- 
Andrew Deason
adeason@sinenomine.net