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

[Tom Keiser]

On Fri, Mar 11, 2011 at 5:23 PM, Andrew Deason <adeason@sinenomine.net> wro=
te:
> 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. =A0The two new fields would be,
>>
>> =A0 =A0afs_uint32 nDelayedConnAborts;
>> =A0 =A0afs_uint32 nDelayedCallAborts;
>>
>> This would allow us to help track peers which are being delayed
>> aborts. =A0I 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).

My vote is the debug packet contents are implementation-private, much
akin to xstat, cmdebug, 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.
>

As one of the people Andrew spoke with about this earlier today, I'd
like to second this proposal.  Even if we merely use the I-D
format--yet publish via our own OpenAFS-specific document submission
stream--I think there would be a lot of value in formalizing the
process of changing/documenting OpenAFS-specific behavior.

Cheers,

-Tom