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

[Yi Huang <[e-mail]>]

Hi Reese, thanks for the review! You can my answers inline (noted by [Yi]).

________________________________
From: tcpm <[e-mail]> on behalf of Reese Enghardt <[e-mail]>
Sent: Wednesday, April 27, 2022 11:18 AM
To: Michael Tuexen <[e-mail]>; tcpm IETF list <[e-mail]>
Subject: [EXTERNAL] Re: [tcpm] WGLC for draft-ietf-tcpm-hystartplusplus-04

Dear Michael, all,

I have done some testing of the FreeBSD implementation with NewReno, and
I have also read through draft-ietf-tcpm-hystartplusplus-04.

The document specifies Hystart++ precisely enough for me to understand
how it works, and I appreciate the brevity and clarity. I am in favor of
this document advancing.

I do have a couple of questions/comments, which I would appreciate to
see considered before publishing the document:

First of all, I realize this is TCPM, but is it still worth adding a
statement about the generality of the mechanism, as Hystart++ can also
be implemented for other transport protocols? Is Hystart++ expected to
be "compatible" with all congestion control algorithms? Please consider
adding a brief statement to the Abstract or Introduction.

[Yi]:
In my understanding, only the underlying congestion control algorithms matter.
If a CC has slow-start stage and it's window-based, then I don't see a problem
integrating Hystart. AFAIK, Hystart++ has been implemented by Quiche
(cloudfare's QUIC implementation). So, it at least works with QUIC.

In Section 1, it says "HyStart++ reduces packet loss and
retransmissions, and improves goodput in lab measurements and real world
deployments."
I think Hystart++ could potentially also help reduce queue delay for
some congestion controllers and a non-AQM bottleneck, is this correct?
If so, I think this point would be worth adding.
Are there any published testing results and/or more details on the
tested setup(s), network path conditions under which Hystart++ has been
tested, etc, that the authors are aware of, beyond the existing Section
5? If so, please add links to them here or in Section 5. Please also
consider adding a forward reference to Section 5 here.

[Yi]:
Hystart++ can potentially reduce queue delay because it mitigates
overshooting during slow-start. We tested Hystart++ with CSS (draft version 2-4)
on emulated networks that have latency jitters and from our lab resutls,
it outperformed Hystart++ without CSS (draft v1) and conventional slow-start.
We have not added this to the draft yet.

In Section 4.2, the document defines "windowEnd as a sequence number
initialized to SND.UNA". Why SND.UNA and not SND_MAX, i.e., the highest
sequence number that was sent? (I think the FreeBSD implementation
initializes it to tp->snd_max, which makes sense to me, therefore, I'm
wondering if the spec should say the same.)
I think initializing it to SND.UNA would still work, as SND.UNA would
probably be acked soon and then windowEnd would become SND.NXT. But in
my mind, it seems like this adds one very short round at the beginning,
perhaps unnecessarily. Please let me know if I'm missing anything here.

[Yi]:
Great catch. You are right and I double checked our code, and it turns out
we actually initialize windowEnd to SND.NXT. So, this is a typo.

For Section 5: Are there any particular network path characteristics for
which Hystart++ (with the recommended constants or others) is expected
to perform particularly well, or not so well? Are there any results for
higher capacity links such as 1 Gbps, any results specifically for
mobile links, etc? Please consider adding citations here.
If you are aware of any findings along these lines, or any guidance on
how to tune the constants in these cases, please consider adding a few
sentences here or in Section 4.3.

[Yi]:
Theoretically speaking, it tends to perform better when the bottleneck
buffer is deep. The algorithm relies on sensing RTT change, which is apparently
easier to build up on deep buffers. On shallow buffers, I'd expect Hystart++ to
perform as good as conventional slow-start. Regarding high capacity links, our lab
tests focus more on 100Mbps and below but we also tested 1Gbps and we saw
similar results. We will consider expanding Section 5 to include some lab results
for links with latency jitters and 1Gbps.



Thank you.

Best,
Reese


On 4/13/22 13:18, Michael Tuexen 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-tcpm-hystartplusplus-04.html&amp;data=05%7C01%7Chuanyi%40microsoft.com%7C2a0c7cc616e345ad550708da287a6858%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637866803621871696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=xlAH1SZUPdinz7tBBQ9%2Bhsf7d%2FVst8jDEWJb9BCeOy8%3D&amp;reserved=0
>
> Best regards
> Michael
>
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=05%7C01%7Chuanyi%40microsoft.com%7C2a0c7cc616e345ad550708da287a6858%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637866803621871696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=xVSMw2YZI5TdiRbpjR4ybTUVFcoaT4ivZwsLBJP%2FPG8%3D&amp;reserved=0

_______________________________________________
tcpm mailing list
[e-mail]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=05%7C01%7Chuanyi%40microsoft.com%7C2a0c7cc616e345ad550708da287a6858%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637866803621871696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=xVSMw2YZI5TdiRbpjR4ybTUVFcoaT4ivZwsLBJP%2FPG8%3D&amp;reserved=0