[radext] Re: Review of draft-janfred-radext-radius-congestion-control-01

[Alan DeKok <[e-mail]>]

On Jul 6, 2026, at 7:18 AM, Fabian Mauchle <fabian.mauchle=[e-mail]> wrote:
> Some (not quite so) early feedback of draft-janfred-radext-radius-congestion-control-01
> 
> >3.1 Proxy-Capability Attribute
> > When a capable RADIUS proxy receives a RADIUS packet with the Proxy-
> > Capability Attribute, the RADIUS Proxy SHOULD add its own capabilities
> > to the Attribute if the capability is not yet included.
> 
> I think this should also state:
> the RADIUS Proxy MUST record the capabilities it received from the client (before adding its own). This is later used to determine the enforcing instance.

  There were some discussions last year in IETF Montreal that the Proxy-Capabilities might not be needed:

https://mailarchive.ietf.org/arch/msg/radext/6oD0udsrCqalOiaYnSQ6liFnrQA/

> Response-Delay
> > 3.2 Response-Delay Attribute
> > 3.4.2.1 Response-Delay
> 
> Neither the attribute definition nor the processing of it clearly defines from which point the delay is measured. I.e. delay between the original request and the response, or between reception of the response and forwarding of the response.
> I would personally opt for the former, to avoid adding up the delay in case multiple instances are (erroneously) enforcing.

  I think it should be a minimum delay between the reception of the original request, and when the response is sent. 

> It should also state whether the delay should be matched exactly or more like a minimum delay.

  Probably "at least" this delay, but not "a lot more" than this delay.

> In general, my first thought was: but this could make the id-exhaustion problem much worse - but does it really?
> A home server can already delay the response (and I hear some already do this today), then that id is blocked along the whole proxy chain. Adding the response-delay mechanism can't make this any worse. In contrast it can help by pushing the blocked id down the proxy chain freeing up the ids on proxies in between.
> I think this logic (if its actually correct) should be explained somewhere in detail.

  I agree.

> > 3.4.2.2 Request-Block
> > In order to avoid servers from blocking legitimate traffic by setting
> > the block-filter to arbitrary values, the Request-Block is always
> > dependent on the attributes of the original RADIUS requests.
> 
> I would clearly state (here and in the subsequent paragraphs) that it is dependent on the attribute **values** of the original request.

  Yes.

  Alan DeKok.