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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
