> From: email@example.com
> To: firstname.lastname@example.org
> CC: email@example.com; firstname.lastname@example.org
> Date: Mon, 19 Apr 2010 06:58:54 -0700
> Subject: DISCUSS and COMMENT: draft-ietf-radext-status-server
> Section 4.1., paragraph 2:
> > The client SHOULD also have a configurable global timer (Tw) that is
> > used when sending periodic Status-Server queries during server fail-
> > over. The default value SHOULD be 30 seconds, and the value MUST NOT
> > be permitted to be set below 6 seconds. If a response has not been
> > received within the timeout period, the Status-Server packet is
> > deemed to have received no corresponding Response packet, and MUST be
> > discarded.
> DISCUSS: I would like to discuss two issues with this design. First,
> since it is only RECOMMENDED to implement Tw and not REQUIRED, clients
> need not do so. How do clients without Tw decide that a server has not
> Second, there is no discussion on what rate clients should
> be using when *issuing* Status-Server queries. The current text allows
> a client to send Status-Server queries to the server at high rates,
> and does not require the client to reduce its sending rate when it
> receives no responses. In other words, there currently isn't any sort
> of congestion control. Has this been discussed by the working group?
> It seems like all the pieces are already there to implement a simple
> congestion control scheme: have clients issue at most one request per
> Tw (already implied by Section 4.3 text but not clearly stated
> anywhere), double Tw up to some conservative maximum when the server
> does not respond, restore the initial Tw when it does (Section 4.3
> again has some text that goes into that direction).
> Section 1812., paragraph 4:
> > The server MAY prioritize the handling of Status-Server packets over
> > the handling of other requests, subject to the rate limiting
> > described above.
> Without congestion control, implementing this MAY guarantees that the
> minimum amount of useful (= non-Status-Server) work will be done.
> Section 4.3., paragraph 3:
> > If no response is received to Status-Server packets, the RADIUS
> > client can initiate failover to another proxy. By continuing to send
> > Status-Server packets to the original proxy at an interval of Tw, the
> > RADIUS client can determine when the original proxy becomes
> > responsive again.
> This uses Status-Server messages as an overload detection mechanism.
> They need to be sent in a way that will back off the rate
> under overload, because otherwise the scheme can turn into an
> overload *generation* mechanism.
> Section 4.5., paragraph 17:
> > It is RECOMMENDED, therefore, that implementations desiring the most
> > benefit from Status-Server also implement server failover. The
> > combination of these two practices will maximize network reliability
> > and stability.
> If Status-Server messages are being sent in a way that is congestion
> controlled (i.e., the rate is reduced under overload).