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

[Gorry Fairhurst <[e-mail]>]

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