On Wed, 09 Mar 2011 14:59:18 -0500 Michael Meffie <[email protected]> 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 [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
