Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack

[Marcus Brinkmann]

At Sun, 07 Jan 2007 14:01:51 -0500,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> On Sat, 2007-01-06 at 19:20 +0100, Marcus Brinkmann wrote: 
> > Hi,
> > 
> > another approach would be to combine all the resources that a network
> > service needs into a single resource container, which is managed in a
> > way similar to space banks, but using a separate management service (a
> > "network bank"?) that can only be used by privileged system network
> > services responsible for implementing the scheduling policy (ie, it is
> > not general purpose).
> 
> This sounds like you intend to have all network buffers owned by the
> network subsystem. If so, you have re-invented denial of service.
> 
> Could you clarify whether this is the case?

I don't think so.  The effect of the proposal is intended to be the
following: Pages can be "tagged" so that they can be made opaque by
certain designated (and thus authorized) subsystems only.  Ownership
of the resource remains within the party who did the tagging.  I think
that this description catches the main idea.
 
> Also, can you give a principled argument for how much resource (i.e. how
> much memory) the network resource container should hold?

As much as the client is willing to delegate, from its reserve.  There
is a corresponding question for spacebanks (how large should the
reserve of a subspacebank be?)
 
> Finally, given that there is no statically correct answer to how much
> resource it should hold, can you justify why an unprincipled special
> purpose solution that implements the restrictions you object to in the
> space bank is in some way better than a principled, general-purpose
> solution?

I don't think that the proposal is any less principled than the space
bank design, rather, it is a logical extension.  The only difference
is that resource containers may be tagged to allow designated parties
to perform sensitive operations, like opaque allocation.

In fact, it seems to me that such an extension allows to implement
security policies that seem different to achieve without it.  For
example, if the ability to pin pages is a delegatable resource, one
could use such tagging to delegate pages that are only pinnable by a
trusted subsystem.

> > There is some hazard attached to having two "classes" of memory, but
> > the system could provide a service to move resources from one type of
> > contingent to the other according to some policy.  In a dynamically
> > configured system there need to be ways to rebalance contingents of
> > resources anyway, so that seems to be a small price to pay.
> 
> It is exactly the case of a dynamic system that most concerns me. The
> rebalancing you speak of is an intrinsically bad thing. What makes it
> necessary is the partitioning of memory, which was not technically
> motivated. The problem with this class of policy is that there is no
> generally correct choice of policy, and you find later that the initial
> policy will be required to add another policy. In short: policy begets
> policy. I have yet to see any policy for constrained resource of this
> type that is not subject to denial of resource attacks.
>
> The best solution here is simply to have the clients supply the storage,
> which guarantees that all incentives align against the attacker and in
> favor of the well-intentioned user.

As described above, in my proposal the client does supply the storage,
and any necessary rebalancing is necessary in either model.  For
example, in the Reloaded design, the application gives a subspacebank
to the TCP/IP stack, presumably one with a certain reserve.  The
allocation of the subspacebank and any adjustment to the reserve is
the required rebalancing.

[skipped question of transparency, as it is discussed elsewhere and
only tangential---the proposal seems to have independent merit]

> > Of course some of this could be implemented in a user's shell based on
> > the EROS spacebank and factored network stack model.  The interesting
> > question is if conflating resources into a bundle at the system level
> > allows for more optimisations or more efficient resource scheduling.
> > Any takers?
> 
> A page is a page is a page. Relabeling pages into classes only ensures
> that their management is more complicated. 

But a page is not a page is not a page if the quality of service
guarantees are different.  For example, a pinnable page is quite
unlike a flushable page.

And that does not even include considerations of higher-level resource
management policies like I/O bandwidth guarantees.  Memory scheduling
and processor time scheduling are by necessity highly correlated, and
the simplified resource models we use today just ignore these details.
I wonder how mch of your objection is applicable once expressible
resource management policies approach the complexity of desired
resource management policies.

Thanks,
Marcus