Architecture for Reliable Server Pooling
draft-ietf-rserpool-arch-12

Moved back to the WG for rehashing into a overview document rather than architecture one. This intends to provide a document that is easier to understand and provide an entry point into the whole RSERPOOL solution. New milestones for the whole document package is being created by WG chairs.

[Ballot discuss]
I believe that the issues raised by the following Gen-ART review by Harald Alvestrand are deep enough that RSERPOOL and its future should be referred to
the IAB for advice on how to proceed.

I've been puzzled for several years about the applicability of this
work in real deployments. It hasn't aroused significant interest
in the industry, least of all among hosting providers who would
presumably be the target users. Since RSERPOOL only solves the failover
problem at transport level, leaving reliability and session integrity
to the applications, it has no obvious advantages over current (IP
layer based) solutions to failover. It also has no particular
advantages for load balancing.

-------
From Harald:

The flaws include:

- No security architecture
- No identity architecture to base security on
- No client-locates-server architecture
- No monitoring architecture
- No transaction support architecture


Specific questions that are not answered by the architecture:

- How do the front-end servers get to agreement on which processing servers to put load onto? Is there feedback from the servers to the front-ends, apart from "up/down" indications?
- How do they handle state?
- Does the model support transactions? Any other integrity model?
- Are sessions sticky by default - so that second requests from the same client are *normally* sent to the same server, or does load-balancing happen per-request?
- Is the session mode from the users to the frontends the same as from the frontends to the servers? Always? Some of the time?
- What is the model for identity exchange between the servers, between the front-ends and between servers and front-ends? Do the users engage in any kind of identity exchange with the servers at all, or do they just deal with an "anonymous blob"?
- What is the model for a front-end going down, as seen from the users? How do they figure out which front-end to switch to?

Formalisms that should IMHO prevent publication:

- The -arch draft is normatively dependent on the ENRP and ASAP protocols. In fact, I'd claim that the architecture alone is incomprehensible; you need the details of the protocols.
Omitting them from the references list is a fatal error.

- The -comp document is trying to answer the question of "why can't you just use protocol X". As such, it's a shooting gallery for alternative candidates. It does not answer the question of "in which cases do you need rserpool".

Again, this has a normative dependency on the protocols.

- The -threat document is simply very badly done.
But again, it can't even be evaluated without the protocols, including the parts of the protocols (like identity handling) that aren't specified in the current protocol documents.

So this too is normatively dependent on the protocols.