Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice

[tom petch <[e-mail]>]

Mark

Yes, my comments ramble:-)  The underlying thread is that for me the
document lacks context, lacks assumptions, or at least ones explicit
enough for me to pick up.

When I got to
"Within the standards process"
I thought IEEE standards process? mmm no, but the absence of IETF is the
sort of detail that I find missing albeit trivial in this case.

I see an underlying assumption that the network is unreliable and that
the problem is packets discarded as a result of congestion.  A common
assumption but untrue in some cases.  If that is the basis of this I-D,
then I think that it needs spelling out up front.

Likewise, I see an assumption that the recipient will always generate an
acknowledgement when asked.  Again, untrue for some protocols so again an
assumption I would like to see stated.

Safety is mentioned many times; what is the danger?  I do not know and
would like to be told (congestive collapse?).

"protocols ultimately can only count on the passage of time without
delivery confirmation "
true for some networks, not true for others.  I do see a steady if small
increase in IETF protocols to detect and react to problems rather than
waiting for someone else - like TCP - to notice and do something so
again I am seeing an assumption.

Apologies for misquoting you on the figure of one second; yes you offer
a more nuanced guideline.  Yet again it makes me think this is about
e.g. web access with HTTP while other IETF protocols are dealing with
timescales an order or two of magnitude shorter.

So I am conscious that the I-D comes out of the TCPM WG  but it seems as
if it tries to be all encompassing; and I struggle to think of an
application of the I-D which is not TCP until some standards body 
develops a new
transport protocol; but even then it would only be applicable if the
underlying network had the assumed characteristics of IPv4.

Tom Petch

> ----- Original Message -----
> From: "Mark Allman" <[e-mail]>
> Sent: Thursday, May 28, 2020 6:09 PM
>>
>> I just want to quickly correct one thing here ...
>>
>>> [the draft] then recommends a minimum RTO of one second
>>
>> (a) It DOES NOT say this at all.  The document does not specify ANY
>>      minimum RTO.  The document does says this:
>>
>>          In the absence of any knowledge about the latency of a path,
>>          the initial RTO MUST be conservatively set to no less than 1
>>          second.
>>
>>      But, as soon as there is some notion (e.g., a RTT measurement)
>>      then there is knowledge and this no longer applies.  I.e., this
>>      is for the startup case where we are beginning transmission into
>>      an unknown network path.
>>
>> (b) If this is too hefty for some application, that's fine.  Do what
>>      we do now and get consensus to use something different.  Again,
>>      the document says:
>>
>>          The correct way to view this document is as the default
>>          case.
>>
>>          [...]
>>
>>          The requirements in this document may not be appropriate in
>>          all cases and, therefore, inconsistent deviations may be
>>          necessary (hence the "SHOULD" in the last bullet).  However,
>>          inconsistencies MUST be (a) explained and (b) gather
>>          consensus.
>>
>>      In other words, the worst case is the current case.
>>
>> I am not entirely sure I understand the remaining points in the
>> review as it's pretty rambling to me.  Certainly we use heartbeats
>> (in things like SCTP) and control packets (think TCP zero window
>> probes or keep-alives).  The document is very simply saying that if
>> these are used in some fashion we can also use them to measure FT
>> information.  That seems pretty reasonable to me and I can't figure
>> out what your complaint about that is.  Perhaps you could try again
>> so my pea brain can understand the complaint?
>>
>> Thanks!
>>
>> allman
>>
>>