DISCUSS and COMMENT: draft-ietf-radext-status-server

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 19 April 2010 16:25 UTC

Message-ID: <BLU137-W30DADD024EF4A551174538930B0@phx.gbl>
Content-Type: multipart/alternative; boundary="_39957140-d247-490a-96de-5f1c03b449f8_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org>
Subject: DISCUSS and COMMENT: draft-ietf-radext-status-server
Date: Mon, 19 Apr 2010 08:57:58 -0700
Importance: Normal
In-Reply-To: <20100419135854.3D26428C112@core3.amsl.com>
References: <20100419135854.3D26428C112@core3.amsl.com>
MIME-Version: 1.0
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk


> 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).
>

DISCUSS and COMMENT: draft-ietf-radext-status-ser… Bernard Aboba
DISCUSS and COMMENT: draft-ietf-radext-status-ser… Bernard Aboba