Subject: [core] RFC7252 - PROBING_RATE

From: Achim Kraus <[email-masked]>
Date: Sun, 4 Jul 2021 12:08:29 +0200

Hi list,

I spent some time on redesign and cleanup the configuration in
Eclipse/Californium. Doing so I currently struggling at the
PROBING_RATE:

4.7.  Congestion Control

(https://datatracker.ietf.org/doc/html/rfc7252#section-4.7)

 > Unless this is modified by
 > additional congestion control optimizations, it MUST be chosen in
 > such a way that an endpoint does not exceed an average data rate of
 > PROBING_RATE in sending to another endpoint that does not respond.

4.8.  Transmission Parameters

(https://datatracker.ietf.org/doc/html/rfc7252#section-4.8)

 > ACK_TIMEOUT       | 2 seconds
 > MAX_RETRANSMIT    | 4
 > PROBING_RATE      | 1 byte/second

With both, sending a CON request, e.g. about 20 bytes, and receiving no
message back for the ACK_TIMEOUT, sending again 20 byte short after
these 2s seems to violate the PROBING_RATE. Or may consider, a special
definition of "average data rate". Assuming, that a "normal CON
transfer" will then take 62 and sends the 20 bytes 5 times results in
1,6 bytes/second.

So:
Is there a intention to limit the bytes, which may be used for such a
first request (e.g. 12 bytes will comply to the limit)?
Or should a quiet phase be considered based on that calculation after
that (e.g. 38s with the 20 bytes)?

best regards
Achim Kraus

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 4 Jul 2021 13:31:20 +0200

On 4. Jul 2021, at 12:08, Achim Kraus <[email-masked]> wrote:
> these 2s seems to violate the PROBING_RATE.

Outside millibit networks, any packet instantaneously exceeds the default value of PROBING_RATE.
So this is indeed meant as an average value over time — an application should not send a sustained rate of more than about 1 B/s to a peer endpoint that might not be reachable (“into thin air”).

> Or may consider, a special

Indeed, the value chosen for the default PROBING_RATE was oriented after the average rate in which CON retries are sent.

Grüße, Carsten

---

From: Achim Kraus <[email-masked]>
Date: Mon, 5 Jul 2021 09:46:18 +0200

Hi Carsten,

Thanks for your answer!

best regards
Achim