RFC6582

[Scheffenegger, Richard]

Hi Hiren,



I hope the xplot graph makes it through to you - LR ended at an odd ack packet; This is from a probing point near the client @ 10G line rate - where you can see the ack thinning, and the consumption of the entire rwnd during loss recovery.



The ACK thinning has cwnd at the end significantly smaller than ssthresh (cwnd/2) already, and using up the receive window during loss recovery will make "pipe" very small as well.



(I just spotted in this example the two initial SACKs, and five thereafter all seem to be exactly identical - another oddity...)



The session was set up with mss 8960, and a wscale=9. During the session rwin remained a constant 1024 (512kB).



Best regards,

  Richard



[cid:image002.png at 01D46849.349B20B0]



-----Original Message-----
From: hiren panchasara <hiren at strugglingcoder.info>
Sent: Samstag, 20. Oktober 2018 02:32
To: Scheffenegger, Richard <Richard.Scheffenegger at netapp.com>
Cc: freebsd-transport at freebsd.org
Subject: Re: RFC6582



On 10/19/18 at 06:55P, Scheffenegger, Richard wrote:

> Hi Hiren,

>

> I checked, the loss based modular ccs all seem to call newreno.cc.post_recovery or have identical code when flightsize (pipe) is < ssthresh.

>

> Lawrence asked me to upload a patch to

> https://reviews.freebsd.org/D17614

>

> I think that simple change is all what is needed for rfc6582 compliance (one more ;) ), but if you can double check in tcp_input.c once more (i didn?t see any more post recovery cwnd adjustment the other day), that would certainly be good!



You are right and it looks okay to me.



I wonder if you have an easy way to reprod this. Probably using packetdrill?



cheers,

Hiren