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

[Gorry Fairhurst <[e-mail]>]

On 04/03/2026 23:52, Alan DeKok wrote:
>   Not the author(s), but I may be able to clarify some points.

Thanks Alan

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

>
> On Mar 4, 2026, at 9:32 AM, Gorry Fairhurst via Datatracker <[e-mail]> wrote:
>> ...
>> ### S 6.2.3 - DISCUSS
>> “In order to avoid congestive collapse, it is RECOMMENDED that...”
>> - I would like to discuss why this is only recommended, why its this not
>> required if it contributes to congestion. At least I expected some careful
>> explanation of why this “SHOULD” might be deviated from in specific usage.
>   We have ~30 years of existing deployments which don't follow this practice for UDP, and ~15 years of existing deployments for TLS transport.  The WG didn't want to mark existing implementations as non-conformant.
>
>   From discussions in the WG, there aren't many good reasons to deviate from these recommendations.  But there was no consensus to make it mandatory.
[GF] There's a presentation piece here that should bed worked-out to 
explain why congestion might result and then to explain what the 
recommendation is, I'm sure that can be done.
>
>> ### S 6.4 - DISCUSS
>> “Note that PMTU
>>   discovery can only discover the PMTU of the current RADIUS hop and a
>>   RADIUS client has no reliable way to discover the PMTU across the
>>   whole RADIUS proxy chain.  Further discussion of this topic is
>>   outside of the scope of this document.”
>> - I am trying to figure out what the above text really means, and why this is
>> an issue: I wonder if this is more of a concern when there is a proxy from a
>> TCP to UDP, or one from UDP to TCP. When a large packet is sent from UDP to
>> TCP?
>   PMTU issues can come up when UDP transport is used anywhere in a proxy chain.  If it's all TCP, then there aren't issues.
>
>   Since the RADIUS protocol is tied to one client-server link, there is no way to do PTMU discovery past the "next hop" server.  The RADIUS protocol also has no provisions for negotiation of pretty much anything, too.
>
>   So a client is stuck doing PMTUD on its link to the local server.  And then ???? who knows what happens after that.
[GF] I think this can be explained in a few sentences - but at the 
moment I don't understand from the I-D.
>
>> - presumably a proxy from a TCP stream will simply segment to the
>> Min(PMTU,SMSS) and hence the larger TLS record can be varied, whereas from TCP
>> to UDP the proxy might be limited by the UDP datagram size. Of course, a proxy
>> between two UDP “connections” would need some way of determining a useful PMTU
>> across both paths. ... I think I do not understand what actually the issue?
>   TCP will automatically segment things, we're not worried about that.
>
>   While the proxy can do PMTUD on both links (inbound and outbound), that doesn't help.  The client which sends packets to the proxy can't do PMTUD on the outbound link.  And the proxy can't inform the client of any PMTUD it's done for the outbound link.
>
[GF] An explained example would seem helpful?
>> ### S 6.2.3 - Comment
>> “In order to avoid congestive collapse, it is RECOMMENDED that RadSec
>>   clients which originate Accounting-Request packets (i.e., not
>>   proxies) do not include Acct-Delay-Time ([RFC2866], Section 5.2) in
>>   those packets.”
>> - I expect this point is important, but I do not think the text is currently
>> correct, this does not *avoid* congestion collapse, maybe the intention is to
>> say this reduces the probability of collapse?
>   Perhaps:
>
> 	In order to avoid contributing to congestive collapse, ...
>
>   i.e. the bad behaviour creates congestive collapse where none existed before.
>
[GF] The term "congestion collapse" is a pretty significant thing, 
inducing congestion is something that happens over shared paths.
>> ### S 6.2.3 - Comment
>> “this duplication contributes to congestive collapse of the
>>   network, if one or more RADIUS proxies performs retransmission to the
>>   next hop for each of those packets independently.”
>> - I expect the described effect is important, but I also do not think the text
>> is correct. i.e.: I cannot see that *automatically* results in congestion, nor
>> in congestion collapse! I would suggest that this “contributes to traffic and
>> can induce congestion, which could contribute to congestion collapse”, or
>> something similar?
>   It doesn't result in congestion, but it definitely contributes to it, and makes congestion more likely.
>
[GF] "can contribute to congestion" is a good set of words.
>> ### S 6.4 - Comment
>> “While a RADIUS client has
>>   limited to no possibilities to reduce the size of an outgoing RADIUS
>>   packet without unwanted side effects, it gives the RADIUS client the
>>   possibility to determine whether or not the RADIUS packet can even be
>>   sent over the connection.”
>> - This may be related to my “DISCUSS” (sorry), but I do not yet see what that
>> would be an issue when the proxy connects onward over TCP, QUIC or similar
>> transport.
>   It's not the proxy, it's the client.
[GF] I still do not understand what is intended here.
>   Alan DeKok.
>
Best wishes,

Gorry