Re: [tcpm] [Last-Call] Genart last call review of draft-ietf-tcpm-rto-consider-14

[Benjamin Kaduk <[e-mail]>]

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