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

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:tcpm-bounces@ietf.org] On Behalf Of Nicolas Kuhn
> Sent: Thursday, May 07, 2015 5:00 PM
> To: tcpm@ietf.org
> Subject: [tcpm] draft-ietf-tcpm-rtorestart-07
> 
> 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
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm