[AFS3-std] Re: abort packet format

[Andrew Deason]

On Wed, 09 Mar 2011 12:44:28 -0500
Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> Ugh.  You want to permanently allocate a bit in all abort packets to
> mean "you're being throttled", even though that bit would have meaning
> in combination with one specific error code?
> 
> It seems to me the correct way to make "you're being throttled"
> something the client can tell is by adding an error code that means
> that.

No, the throttling behavior I believe we are discussing is for any error
code. "You're being throttled" can happen because any kind of abort is
being generated too quickly. Informally: "that vnode doesn't exist, stop
asking for it so much" or "you don't have permission to access that,
stop trying to do it so much".

And also, it's not a bit allocated for every abort packet. If there's no
throttling going on, you an just not send that bit, and everything's the
same. Provided we say "assume the bit is 0 if it's not there" or
whatever. But if we specify anything after that bit, yeah, there'd be
the overhead there.

> Providing additional information in abort packets seems reasonable, but
> let's think carefully about how to do it.
> 
> Is the "reason code" you propose simply a sub-error-code, which means
> you have a table of possible reasons for every possible error code?

I believe at least the throttling case ia orthogonal to the error code.
I'm not sure what other reasons could be, though, so I'm not sure about
others.

I think "reason code" might be a bit misleading... it's not _why_ we're
getting the error, it's just more information.

> Does it have application- or call-specific meaning?

No. "Too many aborts" seems Rx-level to me. But the upper layers would
probably need to be the ones getting this information and doing
something with it.

> Is it implementation-dependent?

For throttling specifically, I'd consider it an optional part of the
protocol. Right now it's implementation-specific since there's nothing
on the wire that matters whether it's happening or not. But it's
dependant on the implementation (and in OpenAFS, administrator
configuration) how and whether it happens at all.

> Is it intended to be something that clients can examine to decide how
> to behave, or is it purely to provide additional information to
> humans?

I think this could be useful to be machine-readable, as it can tell the
client to back off, or try another way. As a hypothetical example, a
client could switch InlineBulkStatus from FetchStatus if it detected it
was getting throttled. Of course, it could just try InlineBulkStatus in
the first place, so that doesn't make a _lot_ of sense, but it just came
to mind...

> What about a human-readable message?
> And if we do that, what about internationalization?

Maybe. We could do both; after the error code we could have a sequence
of {32-bit code, nul-terminated string} tuples providing more
information. Or standardize the strings so they are effectively codes.

-- 
Andrew Deason
adeason@sinenomine.net