Date: Wed, 11 Sep 2019 08:18:03 -0400 From: Randall Stewart <rrs@netflix.com> To: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com> Cc: Lawrence Stewart <lstewart@netflix.com>, Michael Tuexen <tuexen@FreeBSD.org>, Jonathan Looney <jtl@netflix.com>, "freebsd-transport@freebsd.org" <freebsd-transport@freebsd.org>, "Cui, Cheng" <Cheng.Cui@netapp.com>, Tom Jones <thj@freebsd.org>, "bz@freebsd.org" <bz@freebsd.org>, "Eggert, Lars" <lars@netapp.com> Subject: Re: reno cwnd growth while app limited... Message-ID: <E86A08A0-CFB6-4292-ADBD-AEB2E1DAF64C@netflix.com> In-Reply-To: <CY4PR0601MB3715561F17C9C213ACFBB61586B10@CY4PR0601MB3715.namprd06.prod.outlook.com> References: <CY4PR0601MB3715561F17C9C213ACFBB61586B10@CY4PR0601MB3715.namprd06.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Interesting graph :) I know that years ago I had a discussion along these lines (talking = about burst-limits) with Kacheong Poon and Mark Allman. IIRR Kacheong said, at that time, sun = limited the cwnd to something like 4MSS more than the flight size (I could have that mixed = up though and it might have been Mark proposing that.. its been a while sun was still a company = then :D). On the other hand I am not sure that such a tight limit takes into = account all of the ack-artifacts that seem to be rabid in the internet now.. BBR took the approach of = limiting its cwnd to 2xBDP (or at least what it thought was the BDP).. which is more along the lines of = your .5 if I am reading you right. It might be something worth looking into but I would want to contemplate = it for a while :) R > On Sep 11, 2019, at 8:04 AM, Scheffenegger, Richard = <Richard.Scheffenegger@netapp.com> wrote: >=20 > Hi, > =20 > I was just looking at some graph data running two parallel dctcp flows = against a cubic receiver (some internal validation) with traditional ecn = feedback. > =20 > <image002.jpg> > =20 > =20 > Now, in the beginning, a single flow can not overutilize the link = capacity, and never runs into any loss/mark=E2=80=A6 but the snd_cwnd = grows unbounded (since DCTCP is using the newreno =E2=80=9Ccc_ack_received= =E2=80=9D mechanism). > =20 > However, newreno_ack_received is only to grow snd_cwnd, when = CCF_CWND_LIMITED is set, which remains set as long as snd_cwnd < snd_wnd = (the receiver signaled receive-window). > =20 > But is this still* the correct behavior? > =20 > Say, the data flow rate is application limited (ever n milliseconds, a = few kB), and the receiver has a large window signalled =E2=80=93 cwnd = will grow until it matches the receivers window. If then the application = chooses to no longer restrict itself, it would possibly burst out = significantly more data than the queuing of the path can handle=E2=80=A6 > =20 > So, shouldn=E2=80=99t there be a second condition for cwnd growth, = that e.g. pipe (flightsize) is close to cwnd (factor 0.5 during slow = start, and say 0.85 during congestion avoidance), to prevent sudden = large bursts when a flow comes out of being application limited? The = intention here would be to restrict the worst case burst that could be = sent out (which is dealt will differently in other stacks), to ideally = still fit into the path=E2=80=99s queues=E2=80=A6 > =20 > RFC5681 is silent on application limited flows though (but one could = thing of application limiting a flow being another form of congestion, = during which cwnd shouldn=E2=80=99t grow=E2=80=A6) > =20 > In the example above, growing cwnd up to about 500 kB and then = remaining there should be approximately the expected setting =E2=80=93 = based on the average of two competing flows hovering at aroud 200-250 = kB=E2=80=A6 > =20 > *) I=E2=80=99m referring to the much higher likelihood nowadays, that = the application itself pacing and transfer volume violates the design = principle of TCP, where the implicit assumption was that the sender has = unlimited data to send, with the timing controlled at the full = disgression of TCP. > =20 > =20 > Richard Scheffenegger > Consulting Solution Architect > NAS & Networking > =20 > NetApp > +43 1 3676 811 3157 Direct Phone > +43 664 8866 1857 Mobile Phone > Richard.Scheffenegger@netapp.com > =20 > =20 > <image004.jpg> >=20 > <image006.jpg> <image012.jpg> > #DataDriven > =20 > https://ts.la/richard49892 ------ Randall Stewart rrs@netflix.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E86A08A0-CFB6-4292-ADBD-AEB2E1DAF64C>