Subject: [ippm] Proposed changes to default settings in the Capacity metric load adjustment algorithm

From: "MORTON JR., AL" <[email-masked]>
Date: Tue, 3 Aug 2021 22:00:58 +0000

IPPM,

I want to point out that some recent results conducted by others encouraged us to test some additional values for seq error threshold and a wider value range of values for consecutive errored status (during feedback intervals).  We discovered that we would like to revise the default values to make the load adjustment a little less-sensitive to non-congestion-related loss and protect the fast ramp-up from ending prematurely. For example, a very short burst of lost packets spanning the boundary between two feedback intervals is currently sufficient to end fast ramp-up.

The current table in 8.1 contains:
+--------------+-------------+--------------+-----------------------+
| Parameter    | Default     | Tested Range | Expected Safe Range   |
|              |             | or values    | (not entirely tested, |
|              |             |              | other values NOT      |
|              |             |              | RECOMMENDED)          |
+--------------+-------------+--------------+-----------------------+
...
+--------------+-------------+--------------+-----------------------+
| sequence     | 0           | 0, 100       | same as tested        |
| error        |             |              |                       |
| threshold    |             |              |                       |
+--------------+-------------+--------------+-----------------------+
| consecutive  | 2           | 2            | Use values >1 to      |
| errored      |             |              | avoid misinterpreting |
| status       |             |              | transient loss        |
+--------------+-------------+--------------+-----------------------+

The revised table rows would look like this:

+--------------+-------------+--------------+-----------------------+
| Parameter    | Default     | Tested Range | Expected Safe Range   |
|              |             | or values    | (not entirely tested, |
|              |             |              | other values NOT      |
|              |             |              | RECOMMENDED)          |
+--------------+-------------+--------------+-----------------------+
...
+--------------+-------------+--------------+-----------------------+
| sequence     | 10          | 0,1,5,10,100 | same as tested        |
| error        |             |              |                       |
| threshold    |             |              |                       |
+--------------+-------------+--------------+-----------------------+
| consecutive  | 3           | 2,3,4,5      | Use values >1 to      |
| errored      |             |              | avoid misinterpreting |
| status       |             |              | transient loss        |
+--------------+-------------+--------------+-----------------------+

Somehow, persistent non-congestion-related loss had mostly eluded our previous tests. But our goal has been to provide default values that will work in automated testing run by anyone in any implementation or circumstances - not just ~expert users and those who run the udpst utility.

So we'd like to change default values for:

  seq error threshold         from 0 to 10
  consecutive errored status  from 2 to  3

and update our tested range/values column as well.

Al

---

From: Martin Duke <[email-masked]>
Date: Thu, 12 Aug 2021 10:48:33 -0700

Hello IPPM,

If you have any comments about this change, please send them to this list
no later than 24 August.

On Tue, Aug 3, 2021 at 3:01 PM MORTON JR., AL <[email-masked]> wrote:

> IPPM,
>
> I want to point out that some recent results conducted by others
> encouraged us to test some additional values for seq error threshold and a
> wider value range of values for consecutive errored status (during feedback
> intervals).  We discovered that we would like to revise the default values
> to make the load adjustment a little less-sensitive to
> non-congestion-related loss and protect the fast ramp-up from ending
> prematurely. For example, a very short burst of lost packets spanning the
> boundary between two feedback intervals is currently sufficient to end fast
> ramp-up.
>
> Somehow, persistent non-congestion-related loss had mostly eluded our
> previous tests. But our goal has been to provide default values that will
> work in automated testing run by anyone in any implementation or
> circumstances - not just ~expert users and those who run the udpst utility.
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 25 Aug 2021 15:02:21 -0700

I haven’t seen any feedback here, but I think the change makes sense.

Al, I think you should be good to go ahead with this.

Best,
Tommy

> On Aug 12, 2021, at 10:48 AM, Martin Duke <[email-masked]> wrote:
> 
> Hello IPPM,
> 
> If you have any comments about this change, please send them to this list no later than 24 August.
> 
> On Tue, Aug 3, 2021 at 3:01 PM MORTON JR., AL <[email-masked] <mailto:[email-masked]>> wrote:
> IPPM,
>

---

From: <[email-masked]>
Date: Thu, 26 Aug 2021 06:22:27 +0800 (CST)

Hi, Martin et al.,

my apologies for the late response.

I've reviewed the proposed changes in the default values. I agree that these changes make the out-of-box capacity measurement less sensitive to an occasional non-congestion-related loss of packets while preserving the algorithm's fast ramp-up behavior. Clearly, a win-win update. I support it.

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: MartinDuke
To: MORTON JR., AL;
CC: [email-masked];IPPM Chairs;[email-masked];
Date: 2021/08/12 10:49
Subject: Re: [ippm] Proposed changes to default settings in the Capacity metric load adjustment algorithm

_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

Hello IPPM,

IPPM,

 

 

 Al

---

From: Martin Duke <[email-masked]>
Date: Fri, 27 Aug 2021 13:08:23 -0700

yes, let's make the change and proceed.

Thanks

On Wed, Aug 25, 2021 at 3:22 PM <[email-masked]> wrote:

> I've reviewed the proposed changes in the default values. I agree that
> these changes make the out-of-box capacity measurement less sensitive to an
> occasional non-congestion-related loss of packets while preserving the
> algorithm's fast ramp-up behavior. Clearly, a win-win update. I support it.
>
>
> Regards,
>
> Greg Mirsky
>
>
> 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D
> Institute/Wireline Product Operation Division
>
>
>
> *Sender: *MartinDuke
> *To: *MORTON JR., AL;
> *CC: [email-masked];IPPM Chairs;[email-masked];
> *Date: *2021/08/12 10:49
> *Subject: **Re: [ippm] Proposed changes to default settings in the
> Capacity metric load adjustment algorithm*

---

From: "MORTON JR., AL" <[email-masked]>
Date: Fri, 27 Aug 2021 20:35:15 +0000

Martin/Greg/Tommy,

Thanks, I’ll move the editing ahead with our designated RFC Editor ASAP, probably next week sometime.  There are some additional questions (from Lynne B) that I need to dig-up and answer...

Al

From: Martin Duke <[email-masked]>
Sent: Friday, August 27, 2021 4:08 PM
To: Greg Mirsky <[email-masked]>
Cc: MORTON JR., AL <[email-masked]>; [email-masked]; IPPM Chairs <[email-masked]>; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] Proposed changes to default settings in the Capacity metric load adjustment algorithm

Thanks

On Wed, Aug 25, 2021 at 3:22 PM <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Martin et al.,

Regards,

Greg Mirsky

E: [email-masked]<mailto:[email-masked]>
www.zte.com.cn<https://urldefense.com/v3/__http:/www.zte.com.cn/__;!!BhdT!2YQp5UNHfqfzgA6kr4d9r7E2BCtWVflhNiLafOlh3sNMUiY6NclIr11fmyYB$>
Original Mail
Sender: MartinDuke
To: MORTON JR., AL;
CC: [email-masked]<mailto:[email-masked]>;IPPM Chairs;[email-masked]<mailto:[email-masked]>;
Date: 2021/08/12 10:49
Subject: Re: [ippm] Proposed changes to default settings in the Capacity metric load adjustment algorithm
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ippm__;!!BhdT!2YQp5UNHfqfzgA6kr4d9r7E2BCtWVflhNiLafOlh3sNMUiY6NclIrxo6FkP8$>
Hello IPPM,

On Tue, Aug 3, 2021 at 3:01 PM MORTON JR., AL <[email-masked]<mailto:[email-masked]>> wrote:
IPPM,

Al