I agree, see below.
On 07/06/2020 18:11, Benjamin Kaduk wrote:
On Sat, Jun 06, 2020 at 08:19:52AM +0100, Gorry Fairhurst wrote:
Please see below.
On 05/06/2020 17:43, Mark Allman wrote:
=============
(3) Each time the RTO is used to detect a loss, the value of the RTO
MUST be exponentially backed off such that the next firing
requires a longer interval. The backoff SHOULD be removed after
either (a) the subsequent successful transmission of
non-retransmitted data, or (b) an RTO passes without detecting
additional losses. The former will generally be quicker. The
latter covers cases where loss is detected, but not repaired.
A maximum value MAY be placed on the RTO. The maximum RTO MUST
NOT be less than 60 seconds (as specified in [RFC6298]).
This ensures network safety.
SB> This does not work in OAM applications.
Well, OK, get consensus to do something different---which is
completely fine. I think retransmission timers have shown
themselves to be crucial for preventing collapse and, again, as a
default I think this is our best advice.
It should be applicable for OAM applications that use a path across the
Internet that can change, and certainly could be bad advice for
controlled environment. It's actually not new, BCP: 145 also speaks of
backoff.
Minor issues:
"By waiting long enough that we are unambiguously
certain a packet has been lost we cannot repair losses in a timely
manner and we risk prolonging network congestion."
I have a concern here that the emphasis is on classical
operation. We are beginning to see application to run over the
network where the timely delivery of a packet is critical for
correct operation of even SoL. As a BCP the text needs to
recognise that the scope and purpose of IP is changing and that
classical learning and rules derived from them may not apply.
Also if not ruled out of scope earlier we need to be clear at this
point that things like BFD have different considerations.
Isn't BFD is a link protocol between adjacent systems?
Well, your "link" can be a virtual (tunnel) link that traverses paths that
share traffic with non-local traffic, e.g., as in draft-ietf-bfd-vxlan.
-Ben
I agree "tunnels" are everywhere - if it's a tunnel, then the path may
cross the Internet, and the considerations concerning path congestion
and RTT variation should be relevant.
If it's known to be link-local or within a "controlled environment" then
one could choose different constants.
I'll expect Mark can propose some appropriate words.
Gorry
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
