Re: [tcpm] [EXTERNAL] Re: WGLC for draft-ietf-tcpm-hystartplusplus-04

[Yi Huang <[e-mail]>]

Thanks Yuchung for the review. We will update the draft as you suggested to point out that Windows has been using L=8.

Thanks,
Yi
________________________________
From: tcpm <[e-mail]> on behalf of Yuchung Cheng <ycheng=[e-mail]>
Sent: Tuesday, May 3, 2022 1:02 PM
To: Neal Cardwell <ncardwell=[e-mail]>
Cc: Michael Tuexen <[e-mail]>; tcpm IETF list <[e-mail]>
Subject: [EXTERNAL] Re: [tcpm] WGLC for draft-ietf-tcpm-hystartplusplus-04

Small suggestions to be more precise on actual implementation

5. Deployments and Performance Evaluations
As of the time of writing, HyStart++ as described in draft versions 01 through 04 was default enabled for all TCP connections in the Windows operating system for over three years with an actual L = 8. The original Hystart has been default-enabled for all TCP connections in the Linux operating system using the default congestion control module CUBIC ([RFC8312]) for a decade with an infinite L.

Personally I think having the "L" ABC constraint would hinder hystart performance.It's maybe too late to modify the actual algorithm hence I ask the implementation description can be more precise.

On Mon, May 2, 2022 at 8:00 AM Neal Cardwell <ncardwell=[e-mail]<mailto:[e-mail]>> wrote:
On Wed, Apr 13, 2022 at 4:19 PM Michael Tuexen <[e-mail]<mailto:[e-mail]>> wrote:
>
> Dear all,
>
> this e-mail starts the working group last call for draft-ietf-tcpm-hystartplusplus-04.
>
> The WGLC runs until Friday, May 6th 2022.
>
> Please send any comments, including indications to support this document,
> to the TCMP mailing list by then.
>
> The ID is available at
> https://www.ietf.org/archive/id/draft-ietf-tcpm-hystartplusplus-04.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-tcpm-hystartplusplus-04.html&data=05%7C01%7Chuanyi%40microsoft.com%7C652fe3c4895a4ded3cc808da2d3ff791%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637872050044195261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MEVVjoajdO53CQU0r3M5rkOYW6cDeSbGT5jZG8OO2L4%3D&reserved=0>
>
> Best regards
> Michael

I am generally supportive of this draft advancing, but do want to put
a word in about the application-limited issue Randall mentioned again
earlier in this thread. After the algorithm exits slow start, it seems
like it is likely to oscillate between:

(a) application-limited periods that cause low RTT samples and a
re-entry into slow start ("if current round's minRTT drops below
baseline indicating that HyStart exit was spurious"), and then

(b) non-application-limited periods that will cause a re-exit of
slow-start and re-entry into CSS.

It seems like the algorithm should either be adjusted to avoid this,
or this expected oscillation dynamic should be documented.

best regards,
neal

_______________________________________________
tcpm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tcpm<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=05%7C01%7Chuanyi%40microsoft.com%7C652fe3c4895a4ded3cc808da2d3ff791%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637872050044195261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lFrEP6iIOAPYgZIEiampkSJUzOtYEm64FiOk1WOA16Q%3D&reserved=0>