[AFS3-std] Re: abort packet format

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF35C2A9408099D0B75851905
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

While I have no objections to discussions regarding extending the RX
abort packet format, I agree with Jeffrey Hutzelman that we need to
understand what we intend to do with it.  I do not believe that
extending the packet format to describe "throttling" is a good idea.

Throttling is not an error code nor is it a reason.  The RX abort packet
is already returning the error code which describes why the request
failed.  Throttling is an OpenAFS specific implementation behavior that
is used to prevent a client from eating up too much of the server side
resources since OpenAFS at present doesn't have a better mechanism of
prioritizing client requests and has a limited number of transactions
that can be processed simultaneously.

=46rom my perspective, knowing that a packet was delayed due to throttlin=
g
is only of use to humans that are attempting to debug what is believed
to be poor OpenAFS file server performance to a client.

I do not believe that a cache manager that is aware it is being
throttled would do anything differently.  The cache manager is issuing
RPCs to the file server because an application is performing an action
that the cache manager cannot satisfy locally.  If the cache manager
knew it was being throttled, what should it do differently?

Should it begin failing requests locally without sending them to the
file server?

Should it locally begin throttling the "bad" application?

The most common cause of throttling is a result of a cache manager that
is issuing individual FetchStatus RPCs which can fail instead of
InlineBulkStatus RPCs which never fail.  Personally I do not see why the
client that issues the individual FetchStatus RPCs should be punished
for a directory full of access denied errors when the InlineBulkStatus
issuer is not.

Throttling is a very blunt instrument and instead of making it a part of
the RX wire protocol I believe that OpenAFS should figure out an
alternate method of prioritizing its resources.

Jeffrey Altman


--------------enigF35C2A9408099D0B75851905
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQIcBAEBAgAGBQJNd8WLAAoJEPd6c1WStpoEI6sP/17imzaG4WyJu0ee9kjt6zlx
DmKW2OW3Pp07UMQX1iftOyYrn4cSxn7zKObH6+KMBKxrXMQ5sDQUJhROJr3aJGKD
kqUk08/btMv6OSZiMf29TAlUV9Ro3W3D4JiHN87T1tfrW4o/ddzZ0j+4cuNjSPae
VgoO3tqdiEv3n2a6nvuuTh6wrOOfGqfrQ1t5rXliG/ql7eGEOACRyIIgsUA1yN1W
y49ifB+MjAoS6hmTCFyvmu7JT3A26GNj9IUIAvuJIjvqjYDzFmkCE3qZmYD4k5sZ
yDY/l5AraZCaBALmOGko//lFTZWUHovKmsSaLvfypVRMJa9OaEX34Qyyzv5K4iCF
2gCN+sgSQ1yk/U6uUPMa6M80iDcOsy1KuidFDzcg00pCiaweKf0sXqRKnOffBNH5
rW5gBTfslje54Q1dOyNkYtXTYwcIE1H+PtlBOtJ4N2kcg4LMNzYPmiL8Ij6Wtm6j
Hi0t/+Eq0drVQuPXQUy8UHAejH0hnIMQElNxr5Nr3i6hA8iYaZqUgTP1kc7ju+4a
azygjuyuvcGYsd9IzPub733X/AUzPHWCD9XE6n4tX8L+dCeN7hosYAXgzr22ieU7
quna3EMthw6xy1SoO9gxQEqs3h/D4pQQggLeqh8q45QtIVAIY8EYZyheua23mZCN
QOSbZDVjSstUeNloa30w
=Wz7j
-----END PGP SIGNATURE-----

--------------enigF35C2A9408099D0B75851905--