[radext] Re: Gorry Fairhurst's Block on charter-ietf-radext-07-04: (with BLOCK)

[Alan DeKok <[e-mail]>]

On Jul 30, 2026, at 2:58 AM, Gorry Fairhurst via Datatracker <[e-mail]> wrote:
> I would like to understand more about this planned deliverable:
> * RADIUS Congestion Control draft to IESG - August 2026

  The term "congestion control" here does not refer to TCP or other transport protocol congestion control.  It refers to application-layer signalling of overload, etc.

  Similar signalling is already in Diameter:  https://datatracker.ietf.org/doc/html/rfc7683

  We're looking to add some application-layer signalling, as RADIUS is currently lacking it.  If the name "congestion control" is contentious, we should just rename the deliverable.

The current document which may be adopted by the WG is this one:

https://datatracker.ietf.org/doc/draft-janfred-radext-radius-congestion-control/

  If you look at the content, you'll see that the document doesn't add congestion control to RADIUS.  Instead, it allows servers to signal that specific users are being abusive, and should be blocked.   So the name is perhaps misleading to some used to transport-layer congestion control.

> Of course, I'd welcome consideration of congestion control into an IETF
> protocol, However - This charter item needs to either specify existing methods,

  RADIUS has absolutely no link-layer, or application-layer signalling.  It was designed in 1993.

  RADIUS is a bare-bones simple UDP request / response protocol.  If a packet is lost, the client might retransmit.  Or not.  Or it might send the packet to a different server.  There is no way for the server to signal anything back to the client.  The server either responds to a request, or discards the request.

  Given the tens of millions of production devices which use RADIUS, there is no reasonable prospect of adding anything like congestion control to the base protocol. 

> or to work with ICCRG to evaluate the safety and properties of the proposed new
> CC algorithm. I am not clear which is intended here. - Specification of a new
> CC RFC needs to be coordinated with CCWG.

  We are not defining a new transport-layer congestion-control protocol.  We are patching a 1993-era application protocol which has absolutely no signalling.  The proposal is to add a tiny bit of signalling, which is nowhere near what the CCWG sees as congestion control.

  I suggest that we rename the deliverable to describe what the I-D does.  "Add signalling in Access-Reject to allow systems to quench abusive users".

  Alan DeKok.