[tcpm] Spencer Dawkins' Yes on draft-ietf-tcpm-rtorestart-08: (with COMMENT)

["Spencer Dawkins" <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-tcpm-rtorestart-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for producing this. It looks helpful.

I had a few comments you might consider.

Overall - I'm reading "restart the RTO timer" and its variations as an
action that would *increase* the delay before retransmission, but that's
backwards - RTOR is an action that can *decrease* the delay before
retransmission. I suspect I'm not the only reader who would be confused
on this. The word "restart" is pervasive in this document (I counted 48
occurances, including page headers), so I can't reasonably ask about
using a different term, but I'm wondering if it would be clearer if the
abstract said something like 

OLD

The modification, RTO Restart (RTOR), allows the
   transport to restart its retransmission timer so that the effective
   RTO becomes more aggressive in situations where fast retransmit
   cannot be used.
   
NEW

The modification, RTO Restart (RTOR), allows the
   transport to restart its retransmission timer using a smaller delay,
   so that the effective 
   RTO becomes more aggressive in situations where fast retransmit
   cannot be used.

In the Introduction,

   Second, when a sender
   receives duplicate acknowledgments, or similar information via
   selective acknowledgments, the fast retransmit algorithm infers data
   loss and triggers a retransmission.
   
this is describing retransmission without any conditions. A couple of
sentences later, the text describes the conditions that trigger a
retransmission, so the paragraph gets it right in total, but it might be
clearer if this sentence said something like 

   Second, when a sender
   receives duplicate acknowledgments, or similar information via
   selective acknowledgments, the fast retransmit algorithm suspects
data
   loss and can trigger a retransmission.
   
In this sentence,

   Further experimentation is needed to
   determine this and thereby move this specification from experimental
   to proposed standard.
   
if you make other text changes, you might consider s/to proposed
standard/to the standards track/. In a perfect world, the specification
might advance beyond proposed standard, given deployment experience ...