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

On Tue, Sep 3, 2019 at 3:31 PM Martin Duke <martin.h.duke@gmail.com> wrote:
>
> Late in the day, but I have a few nits on this draft.
>
> (1) The definition of RACK.rtt in Sec 5.2 does not match the Step 2 pseudocode in Sec 6.2:
>
> "RACK.rtt" is the RTT of the most recently transmitted packet that
>    has been delivered (either cumulatively acknowledged or selectively
>    acknowledged) on the connection.
>
> 6.2 :
>
> If the ACK is not ignored as invalid, update the RACK.rtt to be the
>    RTT sample calculated using this ACK, and continue.
>
> ...
>
> RACK.rtt = rtt
>            If RACK_sent_after(Packet.xmit_ts, Packet.end_seq
>                               RACK.xmit_ts, RACK.end_seq):
>
> The definition implies that RACK.rtt should only be send if RACK_sent_after(), but IIUC this is not what the the text and pseudocode say.
Yes for catching this! we'll update that in our next rev.

>
> (2) Sec 7.1
>
> RACK always marks the entire
>    TSO blob lost...
>
> unless, of course, some of them are sacked?
Yes, the draft could be more specific. If the TSO blob is partially
sacked, Linux splits it and marks one sacked and the other lost.

>
> (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."


>
> Thanks for your work on this.
Thanks for the review!
>
> Martin
>
>
>
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm