Subject: [rddp] issue (5) - Protection for shared RQ - closure attempt

From: [email-masked]
Date: Fri, 23 Apr 2004 16:18:34 -0400

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'm going to try to close this issue by doing two things:
a) With my WG chair hat on, I'm going to say that solving
	this shared RQ resource protection problem is a
	requirement on the rddp WG's output.  This is a fairly
	fundamental system robustness issue, even within
	a single application.
b) I'm going to call WG rough consensus on the above proposed
	requirement as the WG's solution to the problem.  This is
	called over Paul Culley's objections.
Further comments (including objections) to these two items should
be posted to the list, but please be clear about whether each
comment/message is about a) or b) or both.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Sat, 24 Apr 2004 08:58:09 +0300

>   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/