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

[Anna Brunstrom <[e-mail]>]

Hi Nicolas,

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

On 2015-05-07 16:59, Nicolas Kuhn wrote:
> 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.

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 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.
>
> #############################################################

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.

>
> - “ 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.

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

>
> 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
>

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.

> #############################################################
>
> 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).
>

Agreed, we will move the text.

> #############################################################
>
> 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.
>

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

> Regards,
>
> Nicolas
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm