Re: [tcpm] RACK - variable explanation

[Ilpo Järvinen <[e-mail]>]

On Wed, 28 Nov 2018, Richard Scheffenegger wrote:
> Am 22.11.2018 um 17:16 schrieb Neal Cardwell:
> > On Thu, Nov 22, 2018 at 10:28 AM Felix Weinrank <[e-mail]>
> > wrote:
> > > 
> > > I don't completely understand the following check:
> > > 
> > >          If RACK.reordering_seen is FALSE:
> > >              If in loss recovery:  /* If in fast or timeout recovery */
> > >                  RACK.reo_wnd = 0
> > >                  Return
> > >              Else if RACK.pkts_sacked >= RACK.dupthresh:
> > >                  RACK.reo_wnd = 0
> > >                  return
> > > 
> > > The Draft says:
> > > "RACK.pkts_sacked" returns the total number of packets selectively
> > > acknowledged in the SACK scoreboard.
> > > 
> > > Whats the purpose of this check: RACK.pkts_sacked >= RACK.dupthresh
> > 
> > This is the traditional TCP Fast Retransmit heuristic, described in
> > https://tools.ietf.org/html/rfc5681 in section 3.2, and
> > https://tools.ietf.org/html/rfc6675 in section 5, and the older
> > https://tools.ietf.org/html/rfc2001 in section 3.
> 
> To be pedandic, only RFC3517 and RFC6675 would be applicable directly, as RACK
> requires SACK support.
> 
> Also, RFC6675 explicitly shortened the trigger condition from receiving 3
> DupACKs down to FACK > (dupthresh - 1)*SMSS. 

Where does that "FACK" part come from? Not from RFC6675 for sure. The 
condition given in RFC6675 requires at least that many bytes to be 
acknowledged by SACK blocks to trigger recovery, not just sequence 
distance like FACK does.

> That is, RFC6675 allows
> entering Loss Recovery on the first ACK(SACK), without waiting for any
> duplicate ACKs at all... Thus it is much more "aggressive", and I've seen two
> independent examples recently, where Receivers exploit this capability (and
> don't work well against a RFC3517 sender).
> 
> Earlier 3517 still needed 3 duplicate ACKs.
> 
> In that context, RACK takes a middle ground, as the receiver has to have seen
> dupthresh data segments, but the sender can enter loss recovery already, even
> when ACK loss, ACK compression or ACK thinning are prevalent in the return
> path.
> 
> (A single ACK, with an appropriate SACK block(s) is still sufficient to enter
> LR with RACK, but unlike 6675, positive proof that 3 packets got delivered is
> required).
> 
> Which is a Good Thing (TM) :)

RFC6675 algorithm requires a positive proof that at least 3 MSS sized 
packets were delirered. The algorithm just doesn't use dup ACK as a proxy 
for that but bases the decision on scoreboard details only. Maybe you're 
misreading the RFC6675 somehow?

-- 
 i.