RACK not getting disabled

RACK not getting disabled

[hiren panchasara]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

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).

Here is what I did to disable rack:
net.ipv4.tcp_recovery = 0

I've also disabled metrics:
net.ipv4.tcp_no_metrics_save = 1 
And also flushed existing entries with 'ip tcp_metrics flush' just to be
on a safer side.

Not really relevant here but I've also switched to reno.

I am on: 4.10.0-33-generic
pcap: https://transfer.sh/mfoiN/reno_no_rack.pcap

What am I missing? I can provide any additional info.

Cheers,
Hiren

[-- Attachment #2: Type: application/pgp-signature, Size: 603 bytes --]

Re: RACK not getting disabled

[Eric Dumazet]

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).
> 
> Here is what I did to disable rack:
> net.ipv4.tcp_recovery = 0
> 
> I've also disabled metrics:
> net.ipv4.tcp_no_metrics_save = 1 
> And also flushed existing entries with 'ip tcp_metrics flush' just to be
> on a safer side.
> 
> Not really relevant here but I've also switched to reno.
> 
> I am on: 4.10.0-33-generic
> pcap: https://transfer.sh/mfoiN/reno_no_rack.pcap
> 
> What am I missing? I can provide any additional info.
> 
> Cheers,
> Hiren


A single SACK can contains enough information to trigger a retransmit.

If you absolutely want to see the old 3 dupack in action, you also want
to disable SACK.

Re: RACK not getting disabled

[hiren panchasara]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

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).
> > 
> > Here is what I did to disable rack:
> > net.ipv4.tcp_recovery = 0
> > 
> > I've also disabled metrics:
> > net.ipv4.tcp_no_metrics_save = 1 
> > And also flushed existing entries with 'ip tcp_metrics flush' just to be
> > on a safer side.
> > 
> > Not really relevant here but I've also switched to reno.
> > 
> > I am on: 4.10.0-33-generic
> > pcap: https://transfer.sh/mfoiN/reno_no_rack.pcap
> > 
> > What am I missing? I can provide any additional info.
> > 
> > Cheers,
> > Hiren
> 
> 
> A single SACK can contains enough information to trigger a retransmit.

Bah, right. FACK!
> 
> If you absolutely want to see the old 3 dupack in action, you also want
> to disable SACK.

I believe net.ipv4.tcp_fack = 0 would achieve that without disabling
sack.

Thanks for your help!
Cheers,
Hiren

[-- Attachment #2: Type: application/pgp-signature, Size: 603 bytes --]

Re: RACK not getting disabled

[hiren panchasara]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

On 09/18/17 at 02:29P, hiren panchasara 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).
> > > 
> > > Here is what I did to disable rack:
> > > net.ipv4.tcp_recovery = 0
> > > 
> > > I've also disabled metrics:
> > > net.ipv4.tcp_no_metrics_save = 1 
> > > And also flushed existing entries with 'ip tcp_metrics flush' just to be
> > > on a safer side.
> > > 
> > > Not really relevant here but I've also switched to reno.
> > > 
> > > I am on: 4.10.0-33-generic
> > > pcap: https://transfer.sh/mfoiN/reno_no_rack.pcap
> > > 
> > > What am I missing? I can provide any additional info.
> > > 
> > > Cheers,
> > > Hiren
> > 
> > 
> > A single SACK can contains enough information to trigger a retransmit.
> 
> Bah, right. FACK!
> > 
> > If you absolutely want to see the old 3 dupack in action, you also want
> > to disable SACK.
> 
> I believe net.ipv4.tcp_fack = 0 would achieve that without disabling
> sack.

Ah, what you probably meant was that this could still be < 3 dupacks
triggering loss-recovery based on reordering.

I believe I got what I was looking for.

Thanks a ton,
Hiren

[-- Attachment #2: Type: application/pgp-signature, Size: 603 bytes --]

Re: RACK not getting disabled

[Yuchung Cheng]

On Mon, Sep 18, 2017 at 2:29 PM, hiren panchasara
<hiren@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.

>> >
>> > Here is what I did to disable rack:
>> > net.ipv4.tcp_recovery = 0
>> >
>> > I've also disabled metrics:
>> > net.ipv4.tcp_no_metrics_save = 1
>> > And also flushed existing entries with 'ip tcp_metrics flush' just to be
>> > on a safer side.
>> >
>> > Not really relevant here but I've also switched to reno.
>> >
>> > I am on: 4.10.0-33-generic
>> > pcap: https://transfer.sh/mfoiN/reno_no_rack.pcap
>> >
>> > What am I missing? I can provide any additional info.
>> >
>> > Cheers,
>> > Hiren
>>
>>
>> A single SACK can contains enough information to trigger a retransmit.
>
> Bah, right. FACK!
>>
>> If you absolutely want to see the old 3 dupack in action, you also want
>> to disable SACK.
>
> I believe net.ipv4.tcp_fack = 0 would achieve that without disabling
> sack.
>
> Thanks for your help!
> Cheers,
> Hiren

Re: RACK not getting disabled

[hiren panchasara]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On 09/18/17 at 02:46P, Yuchung Cheng wrote:
> On Mon, Sep 18, 2017 at 2:29 PM, hiren panchasara
> <hiren@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?

Thanks for the clarification, Yuchung.

Cheers,
Hiren

[-- Attachment #2: Type: application/pgp-signature, Size: 603 bytes --]

Re: RACK not getting disabled

[Yuchung Cheng]

On Mon, Sep 18, 2017 at 2:55 PM, hiren panchasara
<hiren@strugglingcoder.info> wrote:
> On 09/18/17 at 02:46P, Yuchung Cheng wrote:
>> On Mon, Sep 18, 2017 at 2:29 PM, hiren panchasara
>> <hiren@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