[radext] Re: Gorry Fairhurst's Discuss on draft-ietf-radext-radiusdtls-bis-15: (with DISCUSS and COMMENT)

[Alan DeKok <[e-mail]>]

On Mar 5, 2026, at 1:29 PM, Gorry Fairhurst <[e-mail]> wrote:
> - I think a new revision could address these issues, and I'd be happy to work with the editors, if that is useful to find text - see comments below, marked [GF].

  I'll propose some changes via a GitHub PR.

  I'll address the biggest topics here: PMTUD and congestive collapse.

> [GF] I think this can be explained in a few sentences - but at the moment I don't understand from the I-D.

  I'll give some clarification, starting from the basics.

  RADIUS is a client-server protocol which runs at the application layer.  While a RADIUS proxy can receive and forward RADIUS traffic, it's doing so at the application layer.  For example, a system with one client, one proxy, and one server looks like this:

	client <--> proxy <--> server

  The difficulty here is that PMTUD runs at the IP layer, not at the application layer.  i.e. PMTUD for the "client <--> proxy" link is independent of PMTUD for the "proxy <--> server" link.

  In addition, there is no way in RADIUS to signal PMTU at the application layer, in a RADIUS packet.   RADIUS also does not allow for "too large" RADIUS packets to be fragmented at the application layer, across multiple RADIUS packets.

  So while a proxy can separately discover PMTU for all of the links it has, it has no way to share that information with the client, or with the server.  And if a proxy receives packets on the "client <--> proxy" link, but which are too large for the "proxy <--> server" link, the proxy has no way to fragment the packet, or signal the client to send smaller packets/

  Which means that while the client can do PMTUD for one link, it has no way of knowing if those packets will make it across the next link.  The proxy has no way of telling the client anything about the next link.

  The result is that when a proxy receives a packet that it can't forward, pretty much the only option is to discard it.

> [GF] The term "congestion collapse" is a pretty significant thing, inducing congestion is something that happens over shared paths.

  Common deployments of RADIUS use not  just one intermediate proxy, but multiple proxies.  These deployments include trees of proxies, where packets are forwarded repeatedly until they reach the destination.  For redundancy, each individual node in the tree may in fact be multiple servers in a fail-over or load-balancing pool.

  As noted above, RADIUS is a hop-by-hop protocol, with essentially no way to signal anything.  So it can't signal if packets are lost, links are down, etc.

  The possibility of congestive collapse comes in because proxies may need to retransmit packets due to loss, timeouts, etc.  If these retransmissions are the same packet, then these retransmissions provide for a linear increase in the number of packets.

  i.e. a lost packet results in the transmission of the same packet.

  If instead the retransmissions are new packets, then there is the possibility for an exponential increase in the number of packets.  One lost packet can result in multiple new packets being transmitted.

  Each proxy will see multiple new packets instead of one duplicate retransmission.  If there are problems forwarding those packets, then each of these multiple new packets will in turn result in multiple new packets: an exponential increase.

  i.e. one packet turns into 4.  Each of those 4 packets could turn into 4, resulting in 16 packets.  etc.

 Alan DeKok.