Date: Wed, 27 Aug 2014 00:53:35 -0700 From: Adrian Chadd <adrian@freebsd.org> To: "Eggert, Lars" <lars@netapp.com> Cc: Tom Jones <jones@sdf.org>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Patches for RFC6937 and draft-ietf-tcpm-newcwv-00 Message-ID: <CAJ-Vmo=ogFcwmiKF7WiWW2Z77CwsZ0Ypx0Z2d02OW0igidj1kQ@mail.gmail.com> In-Reply-To: <3ABE6D0D-1D98-425B-BDAD-8D1B9026AD8F@netapp.com> References: <259C9434-C6FE-42EA-823D-ECB024DBF3D7@netapp.com> <B7145157-9A03-4053-BFCC-627633E20122@neville-neil.com> <814E0886-1B6B-4316-8BAB-684DAFDE1983@netapp.com> <20140826145517.GD12732@gmail.com> <CAJ-Vmo=TsqAKUrV3BRAk1bX9E1zKq7j5og5CHv4PEz-9sqXpAA@mail.gmail.com> <76D986F7-72A8-4ABE-8731-064C6C77A56F@netapp.com> <CAJ-VmokSzvGyUnSkakrgxizQ1xXOMQgzrXKQMTUuFAZOMG0W=g@mail.gmail.com> <3ABE6D0D-1D98-425B-BDAD-8D1B9026AD8F@netapp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok. Is it the same patch you sent out in Feb? -a On 27 August 2014 00:43, Eggert, Lars <lars@netapp.com> wrote: > Not as far as I know. > > Lars > > On 2014-8-27, at 9:39, Adrian Chadd <adrian@freebsd.org> wrote: > >> Is there a PR for it? >> >> >> -a >> >> >> On 27 August 2014 00:23, Eggert, Lars <lars@netapp.com> wrote: >>> It would be great if people could also review Aris' PRR patch - RFC6937= has been out for a while. >>> >>> Lars >>> >>> >>> >>> >>> On 2014-8-26, at 20:09, Adrian Chadd <adrian@freebsd.org> wrote: >>> >>>> Hi! >>>> >>>> I'm going to merge Tom's work in a week unless someone gives me a >>>> really good reason not to. >>>> >>>> I think there's been enough work and discussion about it since the >>>> first post from Lars in Feburary and enough review opportunity. >>>> >>>> >>>> -a >>>> >>>> >>>> On 26 August 2014 07:55, Tom Jones <jones@sdf.org> wrote: >>>>> On Tue, Aug 26, 2014 at 02:43:49PM +0000, Eggert, Lars wrote: >>>>>> Hi, >>>>>> >>>>>> the newcwv patch is probably stale now with Tom Jones' recent patch = based on >>>>>> a more up-to-date version of the Internet-Draft, but the PRR patch s= hould >>>>>> still be useful? >>>>> >>>>> My newcwv patch is much more up to date than Aris's, but it is slight= ly >>>>> different in implementation. I have had a few suggestions from Adrian= , but he >>>>> couldn't comment on how it relates to the tcp internals. >>>>> >>>>> There is a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D19= 1520 >>>>> >>>>> The biggest difference in structure between mine and Aris's patch is = the use of >>>>> tcp timers. It would be good to hear if my approach or Aris's is pref= ered. >>>>> >>>>>> On 2014-6-19, at 23:35, George Neville-Neil <gnn@neville-neil.com> w= rote: >>>>>> >>>>>>> On 4 Feb 2014, at 1:38, Eggert, Lars wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> below are two patches that implement RFC6937 ("Proportional Rate R= eduction for TCP") and draft-ietf-tcpm-newcwv-00 ("Updating TCP to support = Rate-Limited Traffic"). They were done by Aris Angelogiannopoulos for his M= S thesis, which is at https://eggert.org/students/angelogiannopoulos-thesis= .pdf. >>>>>>>> >>>>>>>> The patches should apply to -CURRENT as of Sep 17, 2013. (Sorry fo= r the delay in sending them, we'd been trying to get some feedback from com= mitters first, without luck.) >>>>>>>> >>>>>>>> Please note that newcwv is still a work in progress in the IETF, a= nd the patch has some limitations with regards to the "pipeACK Sampling Per= iod" mentioned in the Internet-Draft. Aris says this in his thesis about wh= at exactly he implemented: >>>>>>>> >>>>>>>> "The second implementation choice, is in regards with the measurem= ent of pipeACK. This variable is the most important introduced by the metho= d and is used to compute the phase that the sender currently lies in. In or= der to compute pipeACK the approach suggested by the Internet Draft (ID) is= followed [ncwv]. During initialization, pipeACK is set to the maximum poss= ible value. A helper variable prevHighACK is introduced that is initialized= to the initial sequence number (iss). prevHighACK holds the value of the h= ighest acknowledged byte so far. pipeACK is measured once per RTT meaning t= hat when an ACK covering prevHighACK is received, pipeACK becomes the diffe= rence between the current ACK and prevHighACK. This is called a pipeACK sam= ple. A newer version of the draft suggests that multiple pipeACK samples c= an be used during the pipeACK sampling period." >>>>>>>> >>>>>>>> Lars >>>>>>>> >>>>>>>> >>>>>>>> [prr.patch] >>>>>>>> >>>>>>>> [newcwv.patch] >>>>>>> >>>>>>> Apologies for not looking at this as yet. It is now closer to the = top of my list. >>>>>>> >>>>>>> Best, >>>>>>> George >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Tom >>>>> @adventureloop >>>>> adventurist.me >>>>> >>>>> :wq >>>>> _______________________________________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org= " >>> >>> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=ogFcwmiKF7WiWW2Z77CwsZ0Ypx0Z2d02OW0igidj1kQ>