Hi Folks,
On Thu, Aug 28, 2014 at 12:39:09PM -0400, George Neville-Neil wrote: > Adrian, > > Can you put this into a Phabricator for review? > > Lars, > > How have you been testing this? Did the newcwv patch make its way into Phabricator? I don't think I would have seen if it did. > > On 27 Aug 2014, at 4:01, Eggert, Lars wrote: > > > Yep > > > > On 2014-8-27, at 9:53, Adrian Chadd <adr...@freebsd.org> wrote: > > > >> Ok. Is it the same patch you sent out in Feb? > >> > >> > >> -a > >> > >> > >> On 27 August 2014 00:43, Eggert, Lars <l...@netapp.com> wrote: > >>> Not as far as I know. > >>> > >>> Lars > >>> > >>> On 2014-8-27, at 9:39, Adrian Chadd <adr...@freebsd.org> wrote: > >>> > >>>> Is there a PR for it? > >>>> > >>>> > >>>> -a > >>>> > >>>> > >>>> On 27 August 2014 00:23, Eggert, Lars <l...@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 <adr...@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 <jo...@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 > >>>>>>>> should > >>>>>>>> still be useful? > >>>>>>> > >>>>>>> My newcwv patch is much more up to date than Aris's, but it is > >>>>>>> slightly > >>>>>>> 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=191520 > >>>>>>> > >>>>>>> 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 > >>>>>>> prefered. > >>>>>>> > >>>>>>>> On 2014-6-19, at 23:35, George Neville-Neil <g...@neville-neil.com> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> On 4 Feb 2014, at 1:38, Eggert, Lars wrote: > >>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> below are two patches that implement RFC6937 ("Proportional Rate > >>>>>>>>>> Reduction for TCP") and draft-ietf-tcpm-newcwv-00 ("Updating TCP > >>>>>>>>>> to support Rate-Limited Traffic"). They were done by Aris > >>>>>>>>>> Angelogiannopoulos for his MS thesis, which is at > >>>>>>>>>> https://eggert.org/students/angelogiannopoulos-thesis.pdf. > >>>>>>>>>> > >>>>>>>>>> The patches should apply to -CURRENT as of Sep 17, 2013. (Sorry > >>>>>>>>>> for the delay in sending them, we'd been trying to get some > >>>>>>>>>> feedback from committers first, without luck.) > >>>>>>>>>> > >>>>>>>>>> Please note that newcwv is still a work in progress in the IETF, > >>>>>>>>>> and the patch has some limitations with regards to the "pipeACK > >>>>>>>>>> Sampling Period" mentioned in the Internet-Draft. Aris says this > >>>>>>>>>> in his thesis about what exactly he implemented: > >>>>>>>>>> > >>>>>>>>>> "The second implementation choice, is in regards with the > >>>>>>>>>> measurement of pipeACK. This variable is the most important > >>>>>>>>>> introduced by the method and is used to compute the phase that the > >>>>>>>>>> sender currently lies in. In order to compute pipeACK the approach > >>>>>>>>>> suggested by the Internet Draft (ID) is followed [ncwv]. During > >>>>>>>>>> initialization, pipeACK is set to the maximum possible value. A > >>>>>>>>>> helper variable prevHighACK is introduced that is initialized to > >>>>>>>>>> the initial sequence number (iss). prevHighACK holds the value of > >>>>>>>>>> the highest acknowledged byte so far. pipeACK is measured once per > >>>>>>>>>> RTT meaning that when an ACK covering prevHighACK is received, > >>>>>>>>>> pipeACK becomes the difference between the current ACK and > >>>>>>>>>> prevHighACK. This is called a pipeACK sample. A newer version of > >>>>>>>>>> the draft suggests that multiple pipeACK samples can 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-unsubscr...@freebsd.org" > >>>>> > >>>>> > >>> -- Tom @adventureloop adventurist.me #pragma summon cthulhu :wq
pgps6xi2Ux6Do.pgp
Description: PGP signature
