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

[Martin Duke <[e-mail]>]

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.

(2) Sec 7.1

RACK always marks the entire
   TSO blob lost...

unless, of course, some of them are sacked?

(3) sec 7.3
We have evaluated using the smoothed RTT (SRTT from
   [RFC6298 <https://tools.ietf.org/html/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.

Thanks for your work on this.

Martin