Code change:
5.2. <ins> An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to link buffering.  This cannot be assumed.  An internet Path can also include complex subnetworks where the minimum delay changes over various time scales, resulting in a non-stationary minimum delay. This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc.  It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes and where a node might then have to buffer data until an assigned transmission opportunity or when the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of operation).  Variation also arises when a higher priority diffserv traffic classic prompts the transmission by a lower class.  In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.  The Jitter from variation over short timescales might not be distinguishable similar from other effects. Proposals SHOULD be evaluated to ensure their operation is robust when there is a significant change in the minimum delay. 5.3. </ins> The "Internet of Things" (IoT) is a broad concept, but for congestion control purposes it is often associated with unique characteristics.

Related discussion:
text: Added first-cut of minimum delay text. Intended to
Delay based congestion control protocols are making an assumption that the observed RTT is the sum of a constant "min delay" and a variable queuing delay. This assumption may not be valid on wireless links, as delays vary when the distance between mobile endpoint and base station increases, or when changing transmission condition cause the radios to adopt different modulation and coding strategies. I suspect we also have these "variable delays" in satellite services, especially when using constellations of low orbit satellites. The state of the art is not very good. BBR for example recognizes its dependency on accurate estimate of the min RTT, but has to resort to some kind of periodic reset if measurements of RTT kept over RTT min for 10 seconds -- which is both quite long for some apps, and quite annoying for real time apps suffering a transmission issue every ten seconds. LEDBAT++ does something similar. I think these "variable delays" link are good candidates for "special case" links, to be mentioned in a separate section.
The variable delay part applies to most satellite broadband access using GEO also - not because of propagation usually, but more a result of radio resource sharing. It might well apply to some other technologies that use a shared capacity pool.
Min delay variation strikes me as a bit of a corner case -- perhaps it can be an optional case to evaluate. The other piece is delay variation is not always congestion -- this is IIUC very common in wireless and is part of that mandatory case.
In think this is something like: An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to link buffering. In this case, a congestion controller could reduce the sending rate to the point of minimum buffering while still preserving the maximum throughput. An internet Path can also include complex subnetworks where the minimum delay changes over various time scales. This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc. It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes and where a node might then have to buffer data until an assigned transmission opportunity. Variation also results when a higher priority diffserv traffic classic prompts the transmission by a lower class.