On Fri, Mar 11, 2011 at 5:23 PM, Andrew Deason <[email protected]> wrote: > 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).
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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
