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"
>> 
>> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to