RE: Security draft issue (5) - Protection for shared RQ

John,

> The important item is to permit a specific application to create a Shared
RQ
> for use with it own clients.  If a specific application server has
100s-1000s
> of clients, it should not have to have separate RQ for each Client -
Server
> instance.  So as long as this is permitted, I do not have any important
> feelings about what is done with a generic Shared RQ handler.

I think this is in line with the intent of the proposed requirement
The intent is along the lines of what Caitlin wrote:

	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.

In other words, the proposed requirement for Shared RQ protection
in the Privileged Resource Manager is "MUST implement", not "MUST
use", not even for Non-Privileged applications. 

> Having said the above, I guess I do not feel that a Shared RQ needs
> to be in a privileged application, as long as it is only used by one
> application.  

I would agree, - this needs to be orthogonal to whether the application
is privileged or non-privileged, as there is no realistic way to stop
a non-privileged application that has an RQ from sharing it among multiple
clients, and no strong rationale that I can see for imposing that sort
of restriction.  In the other direction, a privileged app might want to
take advantage of the Privileged Resource Manager's Shared RQ protection
rather than implement it on its own, and there is no good reason to prohibit
that app from doing so.

NB: This requirement would also apply to shared completion queues.

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 protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of John
Hufferd
Sent: Saturday, April 24, 2004 6:38 PM
To: [email protected]; [email protected]
Subject: RE: [rddp] Security draft issue (5) - Protection for shared RQ



I think that Paul has stated the point very well (in the attached note and
his subsequent note), the purpose of Shared RQ was intended to be used by an
application server that had a set of similar clients.  This was assumed
because of the need to post buffers that were of some optimum size for the
Client to Server interaction.  Because of the probability of very different
buffering requirements --  I, for one, had not envisioned a privileged
resource manager that Shared an RQ as a general facility for "all comers".
However, I guess that having a particular implementation like that is OK,
though I am not convinced of its importance.   

The important item is to permit a specific application to create a Shared RQ
for use with it own clients.  If a specific application server has
100s-1000s of clients, it should not have to have separate RQ for each
Client - Server instance.  So as long as this is permitted, I do not have
any important feelings about what is done with a generic Shared RQ handler.


Having said the above, I guess I do not feel that a Shared RQ needs to be in
a privileged application, as long as it is only used by one application.   
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: [email protected] 


"Culley, Paul" <[email protected]> 
Sent by: [email protected] 
04/15/2004 06:21 AM To<[email protected]> 
cc
SubjectRE: [rddp] Security draft issue (5) - Protection for shared RQ







> 
>   (5) Need to address "protection for shared RQ" problem. 
> 
>   Scenario - server mis-implements resource management, bug in one
>   handler drags down others. E.g., a multiprotocol server with busted
>   filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP
>   should not impose non-uniform controls. 
> 
It should be noted that some of the authors do not expect shared receive
queues to be shared between applications.  Rather, a single application
that must talk to many peers or clients might utilize such a queue.  One
reason this is desirable is to limit the scope of "partial mutual trust"
to the application, another is that applications using a shared receive
queue must also have a clear understanding of the size of the buffers on
the queue.  Users of the SRQ must agree to the size of the largest
buffer used, or there will be a failure.  Disparate applications would
be unlikely to need the same general size of buffers, potentially
leading to an inefficient size of buffers being used.

If this usage model is agreed upon, I personally believe that the whole
SRQ overrun protection problem is ok as it is.


Paul R. Culley
HP Fellow
281-514-5543 

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