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

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 1 Jun 2015 11:15:23 +0200

Hi,

Please accept the following - overdue - comments:

General comments on SCTP applicability of the specification:
------------------------------------------------------------------------------

The document is inconsistent in its description of the SCTP aspects
of the proposed algorithm.

Section 1 and general:

The document does say, in the end of Section 1, that the focus of the
document is on TCP "with validity also for SCTP".
However if so, then I think this paragraph should have been the first
paragraph in section 1 rather than the last.
I think that it is confusing that the Abstract (and the title) speaks about
TCP and SCTP, but the introduction text speaks about TCP only.

I think that it would be better for the text of section 1 to be augmented to
speak about TCP _&_ SCTP. With the final paragraph
then telling that in the remaining part of the documents, the focus would be
on TCP (if this is the intend).

(We have the SCTP API section in the end. Not sure how this fits with the
notion of only providing details for TCP)

Alternatively, if the present "TCP only" introduction is kept, I think that
it would be relevant to emphasize in the final paragraph of section 1, that
what has been described above in section 1, is common to TCP and SCTP
(except possibly for the exact word  "dupacks" - but I think one could get
around that).

Still even with the above clarifications, it is unclear to me what the
status of this document is vis-a-vis SCTP.  The detailed SCTP socket API
description is there,
but some of the crucial implementation aspects - e.g. section 5.3., is TCP
only.

But perhaps such inconsistency is ok for experimental ?

Section 3:

The contents of this section is common to TCP and SCTP except for the term
segment which is TCP particular and which would be a packet in SCTP.

Section 4:

Here there is a reference to "similar update to  RFC4960", but at the same
time the word segment is used and further the section 5.3. discussion is
TCP only.

Detailed on Section 7:
---------------------------
As far as I can tell this is exactly what we would like to have for SCTP.

Thanks,

BR, Karen

PS:  It turns out that some SCTP implementations may send two packets right
after RTO thus applying the "allowed to breach CWND with PMTU-1" logic also
immediately following RTO-timeout. This has impact of how delay_ack impacts
the loss recovery time (refer to discussion in section 5.1).  I believe that
the intent is to have  this eventually be clarified to be incompliant
behavior (also of SCTP), but SCTP then of course has the option to ask for
immediate SACK in this situation, which then again changes the impact of
delay_ack. There also exist SCTP implementations which rigorously follows
TCP semantics and which thus do not breach the CWND right after RTO (only
after receipt of first ACK after RTO) and which today does not deploy the
Immediate SACK extension. For such the delay_ack impact is the RTO loss
recovery as for TCP. The latter behavior is the right RFC4960 implementation
(at least I would argue that), but possibly not the "right" future SCTP
implementation.

>-----Original Message-----
>From: tcpm [mailto:[email-masked]] On Behalf Of Scharf, Michael
>(Michael)
>Sent: Monday, May 18, 2015 11:22 AM
>To: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Cc: [email-masked]
>Subject: 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:[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,
>>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpm

---

From: Per Hurtig <[email-masked]>
Date: Thu, 18 Jun 2015 08:59:31 +0200

Hi Karen,

We agree that SCTP seems forgotten in the document. We have now re-writen the introduction to address both TCP and SCTP. We also end the introduction saying that the rest of the document will focus on TCP, with an exception for Section 7 (the SCTP API). If we were to describe RTOR for TCP and SCTP without violating any terminology (for any of the protocols) we believe that the document would be unnecessarily long and very hard to read.

Cheers,
Per

> On 01 Jun 2015, at 11:15, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> Hi,
>

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 18 Jun 2015 09:29:00 +0200

Hi,

Thanks for taking my comments into consideration !

I think the described approach with a common TCP&SCTP introduction sounds
good
and given that I agree that it is viable to leave the SCTP details out.

BR, Karen

>From: tsvwg [mailto:[email-masked]] On Behalf Of Per Hurtig
>Sent: Thursday, June 18, 2015 9:00 AM
>To: Karen Elisabeth Egede Nielsen
>Cc: [email-masked]; Scharf, Michael (Michael); tsvwg; Michael Welzl;
>[email-masked]
>Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rtorestart-07
>
>Hi Karen,
>
>We agree that SCTP seems forgotten in the document. We have now re-
>writen the introduction to address both TCP and SCTP. We also end the
>introduction saying that the rest of the document will focus on TCP, with
>an
>exception for Section 7 (the SCTP API). If we were to describe RTOR for TCP
>and SCTP without violating any terminology (for any of the protocols) we
>believe that the document would be unnecessarily long and very hard to
>read.
>
>
>Cheers,
>Per
>
>> The document is inconsistent in its description of the SCTP aspects of
>> the proposed algorithm.
>>
>> Section 1 and general:
>>
>> I think that it is confusing that the Abstract (and the title) speaks
>> about TCP and SCTP, but the introduction text speaks about TCP only.
>>
>> I think that it would be better for the text of section 1 to be
>> augmented to speak about TCP _&_ SCTP. With the final paragraph then
>> telling that in the remaining part of the documents, the focus would
>> be on TCP (if this is the intend).
>>
>> (We have the SCTP API section in the end. Not sure how this fits with
>> the notion of only providing details for TCP)
>>
>> Alternatively, if the present "TCP only" introduction is kept, I think
>> that it would be relevant to emphasize in the final paragraph of
>> section 1, that what has been described above in section 1, is common
>> to TCP and SCTP (except possibly for the exact word  "dupacks" - but I
>> think one could get around that).
>>
>> status of this document is vis-a-vis SCTP.  The detailed SCTP socket
>> API description is there, but some of the crucial implementation
>> aspects - e.g. section 5.3., is TCP only.
>>
>> The contents of this section is common to TCP and SCTP except for the
>> term segment which is TCP particular and which would be a packet in SCTP.
>>
>> Section 4:
>>
>> Here there is a reference to "similar update to  RFC4960", but at the
>> same time the word segment is used and further the section 5.3.
>> discussion is TCP only.
>>
>>
>> Detailed on Section 7:
>> PS:  It turns out that some SCTP implementations may send two packets
>> right after RTO thus applying the "allowed to breach CWND with PMTU-1"
>> logic also immediately following RTO-timeout. This has impact of how
>> delay_ack impacts the loss recovery time (refer to discussion in
>> section 5.1).  I believe that the intent is to have  this eventually
>> be clarified to be incompliant behavior (also of SCTP), but SCTP then
>> of course has the option to ask for immediate SACK in this situation,
>> which then again changes the impact of delay_ack. There also exist
>> SCTP implementations which rigorously follows TCP semantics and which
>> thus do not breach the CWND right after RTO (only after receipt of
>> first ACK after RTO) and which today does not deploy the Immediate
>> SACK extension. For such the delay_ack impact is the RTO loss recovery
>> as for TCP. The latter behavior is the right RFC4960 implementation
>>> ietf-tcpm-rtorestart-07 that I am aware of. Could you please discuss
>>> how to address them?
>>>
>>> Thanks
>>>
>>> Michael
>>>
>>>
>>>
>>>> The RTO is not aggressive ; but the retransmission scheme ruled by
>>>> RTO expirations is.
>>>> 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 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
>>>>
>>>>
>>>