Re: [tcpm] draft-ietf-tcpm-rack-05 review

[Martin Duke <[e-mail]>]

I think the proposed text is fine.

On Wed, Sep 4, 2019 at 5:55 PM Yuchung Cheng <[e-mail]> wrote:

> On Tue, Sep 3, 2019 at 3:31 PM Martin Duke <[e-mail]>
> wrote:
>
> <snip>


> > (3) sec 7.3
> >
> > We have evaluated using the smoothed RTT (SRTT from
> >    [RFC6298] RTT estimation) or the most recently measured RTT
> >    (RACK.rtt) using an experiment similar to that in the Performance
> >    Evaluation section.  They do not make any significant difference in
> >    terms of total recovery latency.
> >
> > If there is truly no difference, then why not use SRTT as the standard?
> > Every TCP implementation has to store this, while min_rtt is unneeded
> for many (most?) congestion controls.
> >
> > Alternatively, you could strengthen this paragraph to not sound like it
> makes no difference..
> That's a good point -- our experiment at Google servers indeed didn't
> show much difference. But I think it's still better to use min_RTT
> than SRTT. On buffer-bloat friendly C.C. the SRTT could be orders of
> magnitude longer than the actual paths' RTT -- in my opinion factoring
> this network queuing delay in reordering window is not a good idea. So
> how about adding
>
> 'While the experiment does not show a difference between min RTT and
> SRTT, SRTT is less desirable to size the reordering window as it
> includes network congestion or delayed ACKs effects."
>
>
>