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

[Per Hurtig <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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:[e-mail]] On Behalf Of Scharf, Michael
>> (Michael)
>> Sent: Monday, May 18, 2015 11:22 AM
>> To: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Cc: [e-mail]
>> 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:[e-mail]] On Behalf Of Nicolas Kuhn
>>> Sent: Thursday, May 07, 2015 5:00 PM
>>> To: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm