On Mon, Sep 18, 2017 at 2:55 PM, hiren panchasara <hi...@strugglingcoder.info> wrote: > On 09/18/17 at 02:46P, Yuchung Cheng wrote: >> On Mon, Sep 18, 2017 at 2:29 PM, hiren panchasara >> <hi...@strugglingcoder.info> wrote: >> > On 09/18/17 at 02:18P, Eric Dumazet wrote: >> >> On Mon, 2017-09-18 at 13:14 -0700, hiren panchasara wrote: >> >> > Hi all, I am trying to disable rack to see 3dupacks in action during >> >> > loss-detection but based on the pcap, I see that it's still trigger >> >> > loss-recovery on the first SACK (as if RACK is still enabled/active). >> just to be clear: 3-dupack (aka RFC3517) is still enabled with RACK >> enabled. I am experimenting a patch set to disable 3-dupack approach >> completely. > > So any incoming packet undergoes both checks right now to decide whether > to mark it lost based on 3-dupacks (and eventually rfc6675) and also > rack? Any insights into how they are working together would be great. > > Also whichever scheme detects loss first can kick connection into > loss-recovery, right? Yes. essentially we run both algorithms. the recovery starts when any packet is deemed lost
> > Thanks for the clarification, Yuchung. > > Cheers, > Hiren
