Re: issue (5) - Protection for shared RQ - "Non-Privileged RDDP application"

On Apr 23, 2004, at 11:18 PM, [email protected] wrote:

> Since discussion on this has died down somewhat, let me attempt
> to close this issue.  Here's how I described the proposed shared
> RQ protection requirement in my last email, with a word added
> to acknowledge Caitlin's comment (*innocent*):
>
>   The proposed requirement is that the Privileged Resource Manager
>   contain code sufficient so that a non-RDDP application can be
>   converted to a Non-Privileged RDDP application without enabling
>   a DoS attack that disconnects *innocent* clients or having to
>   write inter-client receive resource protection code.
>
>

I fully agree that applications should not be expected to guarantee
deterministic response to shared-resource-overdraft alerts (such
as the per-endpoint "over limit" alarm with RDMAC SRQs).

However, I am not sure the "Non-Privileged" is the best term,
or at the minimum the scope of the privilege needs to be
clarified.

In my opinion, any application that feels it can provide deterministic
responses to shared-resource alerts should have the option of
doing so, as long as it is the owner of the shared resource.

The essential requirement is that the Privileged Resource
Manager (or the RNIC itself) handle these alerts until the
owner of the Shared Resource enables a different handler.

So the term "Non-privileged" is appropriate if it is clear that
it applies relative to the shared resource. What the OS
considers to be a non-privileged server could still be the
owner of a large shared receive queue. Such an application
should have the option of fielding the SRQ alerts itself,
or of having the Privileged Resource Manager do so.

The tricky terminology problem here is the scope of
"privilege" for the Privilege Resource Manager covers
all resources the RNIC has access to (typically system
wide).

Whether by adding language or changing terms, we
should be clear that a server does not need to be
placed in the kernel or run as root in order to take
full control over its SRQ.

There are at least some applications where proper
control over credits needs to be done on a session-wide
basis, as opposed to on a per-stream basis. Such rules
are typically very application specific, and should be
dealt with by the application itself.

I believe the intent is her to ensure that the vast
majority of applications, that naturally have per-
stream credits, are not also forced to either the
extreme of managing everything related to
shared resources itself or not using shared
resources at all.


--
Caitlin Bestler
http://asomi.com/