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 <tcpm-bounces@xxxxxxxx> on behalf of The IESG
<iesg-secretary@xxxxxxxx>
Sent: 18 May 2020 15:15
To: IETF-Announce
Cc: tcpm@xxxxxxxx; draft-ietf-tcpm-rto-consider@xxxxxxxx;
tcpm-chairs@xxxxxxxx
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
last-call@xxxxxxxx mailing lists by 2020-06-01. Exceptionally,
comments may
be sent to iesg@xxxxxxxx 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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
