[tcpm] draft-ietf-tcpm-rtorestart-07

[Nicolas Kuhn <[e-mail]>]

Hi all, 

I had a look at this draft-ietf-tcpm-rtorestart-07 draft. 
I have some minor comments on the document. 

#############################################################

- "The RTO Restart (RTOR) mechanism described in this document makes the
   RTO slightly more aggressive when the number of outstanding segments
   is too small for fast retransmit to work, in an attempt to enable
   faster loss recovery for all segments while being robust to
   reordering."

The RTO is not aggressive ; but the retransmission scheme ruled by RTO expirations is. 
I would recommend to rephrase that. 

#############################################################

- “   The RTO Restart (RTOR) mechanism described in this document makes the
   RTO slightly […] highly varying RTTs, e.g. mobile networks."

This whole paragraph comes to early in the document, as the reader has no clear 
idea about what RTOR is actually doing. I propose to add that in a dedicated sub-
section in Section 5.

#############################################################

- “ 3 RTO Restart Overview” -> should it not be “3- RTO Overview and rationale of RTOR “ or something equivalent ?
It is confusing, as you do not actually present RTOR. 

Also, in this section 3:
The first paragraph finishes with “Hence,  in most situations, the time before a retransmission is triggered is equal to "RTO + RTT”.” 
But the example to illustrate it comes after - I think things should moved around to:
1- introduce the classic RTO 
2- explain the rationale of classic RTO
3- example to show that RTO+RTT is common
4- more parameters could affect that (2 outstanding segments; other factors)
5- conclusion on “hence, RTO+RTT is common for application limited traffic"

I would propose to introduce a ToC for this section 3:

3- RTO Overview and rationale of RTOR
  3-1. Experienced RTO is RTO+RTT
  3-2. RTO safety margin
  3-3. Rationale of RTOR: when fast retransmit is not possible

#############################################################

Section 4 : should focus on the description of the algorithm only. 

I would keep 
“ 
This approach makes the RTO more
   aggressive than the standardized approach in [RFC6298] but still
   conforms to the requirement in [RFC6298] that segments must not be
   retransmitted earlier than RTO seconds after their original
   transmission.
"

for the discussion section (at this stage of the reading, the reader still does not know exactly what RTOR is actually doing). 

#############################################################

Section 4: "it will prevent RTOR
   from being more aggressive and potentially causing RTOs instead of
   fast retransmits.”

More aggressive than what ? Has the "four" being experimentally obtained ?
I think more discussion is required on this parameter. 

Regards, 

Nicolas