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

The content of this I-D puzzles me, a bit as if an academic paper had
been removed from its context and allowed to float away.

It talks of  'Within the standards process ...' which the rest of the
I-D implies is the IETF Standards process but it then recommends a
minimum RTO of one second which would be a catastrophe for some IETF
protocols which must detect failure in 10 milli-second so that repair is
effected within 50.

There are many references to safety so I looked at the Security
Considerations to see what the dangers are; none.  I am unclear what
these references to safety mean. What is the danger, what is the threat?

" When this time period passes without delivery confirmation the sender
concludes the data was lost in transit...." or the response was lost or
the response was witheld.  I hope that you never get an e-mail delivery
confirmation from me because while the protocol includes it, I will
always configure my MUA to suppress it; breach of security.

"Some protocols use keepalives, heartbeats or other messages to exchange
control information."  I struggle to think of an example of this.  On
the other hand, it came as a surprise to one protocol designer that when
he removed the plug on his connection, literally, nothing happened.
Layer 2 did not tell layer 3, layer 3 did not tell layer 4 and the
application was blissfully unaware, typical of the IETF protocol stack.
Ok failure detection is out of scope but I see heartbeat as primarily
for that purpose and have recommended it on a number of occasions.  (In
a similar vein, some IETF protocols are simplex so the best that can be
done is to add a heartbeat so that the urgent alarm, when it comes, has
a better chance of getting through). I find it hard to draw a hard 
distinction between failure detection and
loss detection.

I am ignorant of the technology encountered in server farms nowadays but
wonder if there is a degree of spoofing there, of ACK being generated at a
front end giving an illusion of a shorter FT, like a recursive resolver
but more so.

Overall the flavour I have is a document about TCP over the
ever-unreliable IP and lacking more general application.  TCP already 
has a rich literature of documents about timeout.  Not wrong, but
likely to be useful to the designer(s) of a new layer four protocol.

Tom Petch

>> ________________________________________
>> From: tcpm <[e-mail]> on behalf of The IESG
> <[e-mail]>
>> Sent: 18 May 2020 15:15
>> To: IETF-Announce
>> Cc: [e-mail]; [e-mail];
> [e-mail]
>> Subject: [tcpm] Last Call: <draft-ietf-tcpm-rto-consider-14.txt>
> (Requirements for Time-Based Loss Detection) to Best Current Practice
>>
>>
>> The IESG has received a request from the TCP Maintenance and Minor
> Extensions
>> WG (tcpm) to consider the following document: - 'Requirements for
> Time-Based
>> Loss Detection'
>>    <draft-ietf-tcpm-rto-consider-14.txt> as Best Current Practice
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
> final
>> comments on this action. Please send substantive comments to the
>> [e-mail] mailing lists by 2020-06-01. Exceptionally,
> comments may
>> be sent to [e-mail] instead. In either case, please retain the
> beginning
>> of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>      Many protocols must detect packet loss for various reasons (e.g.,
> to
>>      ensure reliability using retransmissions or to understand the
> level
>>      of congestion along a network path).  While many mechanisms have
>>      been designed to detect loss, protocols ultimately can only count
> on
>>      the passage of time without delivery confirmation to declare a
>>      packet "lost".  Each implementation of a time-based loss detection
>>      mechanism represents a balance between correctness and timeliness
>>      and therefore no implementation suits all situations.  This
> document
>>      provides high-level requirements for time-based loss detectors
>>      appropriate for general use in the Internet.  Within the
>>      requirements, implementations have latitude to define particulars
>>      that best address each situation.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/
>>
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>>