Date: Wed, 11 Sep 2019 12:04:19 +0000 From: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com> To: Randall Stewart <rrs@freebsd.org>, Lawrence Stewart <lstewart@netflix.com>, Michael Tuexen <tuexen@FreeBSD.org>, Jonathan Looney <jtl@netflix.com> Cc: "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: reno cwnd growth while app limited... Message-ID: <CY4PR0601MB3715561F17C9C213ACFBB61586B10@CY4PR0601MB3715.namprd06.prod.outlook.com>
next in thread | raw e-mail | index | archive | help
Hi, I was just looking at some graph data running two parallel dctcp flows agai= nst a cubic receiver (some internal validation) with traditional ecn feedba= ck. [cid:image002.jpg@01D568A9.CB143AC0] Now, in the beginning, a single flow can not overutilize the link capacity,= and never runs into any loss/mark... but the snd_cwnd grows unbounded (sin= ce DCTCP is using the newreno "cc_ack_received" mechanism). However, newreno_ack_received is only to grow snd_cwnd, when CCF_CWND_LIMIT= ED is set, which remains set as long as snd_cwnd < snd_wnd (the receiver si= gnaled receive-window). But is this still* the correct behavior? Say, the data flow rate is application limited (ever n milliseconds, a few = kB), and the receiver has a large window signalled - cwnd will grow until i= t matches the receivers window. If then the application chooses to no longe= r restrict itself, it would possibly burst out significantly more data than= the queuing of the path can handle... So, shouldn't 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 du= ring congestion avoidance), to prevent sudden large bursts when a flow come= s 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 different= ly in other stacks), to ideally still fit into the path's queues... RFC5681 is silent on application limited flows though (but one could thing = of application limiting a flow being another form of congestion, during whi= ch cwnd shouldn't grow...) In the example above, growing cwnd up to about 500 kB and then remaining th= ere should be approximately the expected setting - based on the average of = two competing flows hovering at aroud 200-250 kB... *) I'm referring to the much higher likelihood nowadays, that the applicati= on itself pacing and transfer volume violates the design principle of TCP, = where the implicit assumption was that the sender has unlimited data to sen= d, with the timing controlled at the full disgression of TCP. Richard Scheffenegger Consulting Solution Architect NAS & Networking NetApp +43 1 3676 811 3157 Direct Phone +43 664 8866 1857 Mobile Phone Richard.Scheffenegger@netapp.com<mailto:Richard.Scheffenegger@netapp.com> [Welcome to Data Driven]<https://datavisionary.netapp.com/>; <https://datavisionary.netapp.com/>; [Facebook]<https://www.facebook.com/NetApp?fref=3Dts>; [Twitter] <https://tw= itter.com/NetApp> #DataDriven https://ts.la/richard49892
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CY4PR0601MB3715561F17C9C213ACFBB61586B10>