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

[Gorry Fairhurst <[e-mail]>]

On 06/06/2026 02:15, Alan DeKok wrote:
> On Jun 5, 2026, at 4:37 PM, Jan-Frederik Rieckers <[e-mail]> wrote:
>> I'm not sure which parts of RFC8085 we can reference here that would add value to this document.
>>  From what I read, there is little guidance on implementation and more on how to design a UDP-based protocol. Since we are using an existing UDP-based protocol (RADIUS) and only extending it, there is not much that we can do without significantly changing the way RADIUS behaves.
>    RFC 8085 has some recommendations for applications using UDP.  But there are issues when applying those recommendations to RADIUS, or even other UDP protocols such as DHCP or DHCPv6.
>
>    For example, the document discusses "flows" of UDP packets.  There are aren't "flows" in RADIUS, or in DHCP.
>
>    The document also distinguishes "high data-volume" applications from "Low data-volume" applications.    It's not clear which one applies to RADIUS.  But if we look at low-volume, the document says this:
>
>> 3.1.3. Low Data-Volume Applications
>> Applications that at any time exchange only a few UDP datagrams with
>> a destination SHOULD still control their transmission behavior by not
>> sending on average more than one UDP datagram per RTT to a
>> destination.
>    Except that in RADIUS (and DHCP), the sending of datagrams is triggered by external events.  So the RADIUS application does not (and can not) limit its transmission behavior to any one "high volume" or "low volume" regime.
>
>    Maybe we can refer to specific sections of RFC 8085.  But event the discussion of rate limiting is wrong or misleading for RADIUS:
>
>> Even low data-volume UDP flows may benefit from packet pacing, e.g.,
>> an application that sends three copies of a packet to improve
>> robustness to loss is RECOMMENDED to pace out those three packets
>> over several RTTs, to reduce the probability that all three packets
>> will be lost due to the same congestion event (or other event, such
>> as burst corruption).
>    RADIUS doesn't send 3 copies of a packet at the same time.  If a RADIUS server is sending bursts of traffic, it's because there is a sudden burst of users who are asking for network access.
>
>    Some of the recommendations in RFC8085 are actively harmful for RADIUS.  Others cannot be implemented in RADIUS.  I don't see many sections of RFC 8085 which directly apply to RADIUS.
>
>    RFC8085 is intended to deal with applications which use UDP to send streams / flows of packets, so that the application has finer-grained control over the rate limiting, RTT handling, and retransmission.  i.e. applications which use UDP as a replacement for TCP.  RADIUS isn't in this category, and neither is DHCP, DHCPv6, or DNS.
>
>    As a result, I think that a general reference to follow RFC 8085 is likely to be misleading and / or wrong.
>
>    Alan DeKok.
>
I saw this email and then realised I had not directly responded to your 
text on my comment.

So I think the remaining question was if there was useful insight in 
RFC8085.  I take your point that the base protocol is already UDP, and 
this is not calling for a redesign of that.

I'd also agree that RFC 8085 doesn't provide much help, so not 
referencing is fine with me. (Maybe it should be updated to include more 
on this type of use, but that is certainly another story...)

Best wishes,

Gorry