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

From: Nicolas Kuhn <[email-masked]>
Date: Thu, 7 May 2015 16:59:32 +0200

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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 18 May 2015 09:21:54 +0000

Authors,

These (mostly editorial) comments are the only WGLC comments for draft-ietf-tcpm-rtorestart-07 that I am aware of. Could you please discuss how to address them?

Thanks

Michael

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Nicolas Kuhn
> Sent: Thursday, May 07, 2015 5:00 PM
> To: [email-masked]
> Subject: [tcpm] draft-ietf-tcpm-rtorestart-07
> 
> Hi all,
> 
> - “ 3 RTO Restart Overview” -> should it not be “3- RTO Overview and
> rationale of RTOR “ or something equivalent ?
> The first paragraph finishes with “Hence,  in most situations, the time
> before a retransmission is triggered is equal to "RTO + RTT”.”
> for the discussion section (at this stage of the reading, the reader
> still does not know exactly what RTOR is actually doing).
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Anna Brunstrom <[email-masked]>
Date: Thu, 21 May 2015 11:43:26 +0200

Hi Nicolas,

Thanks a lot for your comments!
See inline for how we suggest to address them.

> I have some minor comments on the document.

We will change the wording to clarify that the effective RTO becomes 
more aggressive, not the actual RTO calculation. The retransmission 
scheme does not change.

We will apply this clarification also in other parts of the document.

The aim of the paragraph is to introduce both possible gains and 
drawbacks with the scheme early in the document, and then address these 
in more detail later, but we agree that it contains too much detail at 
this point in the document.

As part of the material in this paragraph has been inserted as a result 
of earlier reviews our suggested resolution is to not completely remove 
the paragraph, but to compress it and remove details that are hard to 
understand without knowing the details of the algorithm.

> It is confusing, as you do not actually present RTOR.

Yes, your proposed title is better and we will change the title accordingly.

> 5- conclusion on “hence, RTO+RTT is common for application limited traffic”
>

We will try to rearrange the material in line with your proposed 
outline. However as the section is not so long, we think that explicit 
sections may not be needed.

Agreed, we will move the text.

This value was chosen to only enable RTOR when the use of fast 
retransmit for loss recovery isn’t possible. We will try and clarify 
this further in the text.

Unless you (or anyone else) have further comments on the proposed 
changes, we will submit a new version with the updates discussed above 
next week.

Thanks again for your comments.

Anna