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!
allmanAttachment:
signature.asc
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
