|
> From: lars.eggert@nokia.com > To: iesg@ietf.org > CC: radext-chairs@tools.ietf.org; draft-ietf-radext-status-server@tools.ietf.org > Date: Mon, 19 Apr 2010 06:58:54 -0700 > Subject: DISCUSS and COMMENT: draft-ietf-radext-status-server > > Discuss: > > 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 > responded? > > 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). > > Comment: > > 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). > |