Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice

[Mark Allman <[e-mail]>]

Hi Tom!

I am going to re-arrange slightly and deal with the last one first.

> So I am conscious that the I-D comes out of the TCPM WG but it
> seems as if it tries to be all encompassing;

Yes; we have found the guidelines are broadly applicable.

> and I struggle to think of an application of the I-D which is not
> TCP until some standards body develops a new transport protocol;

SCTP, QUIC, DNS, ... all manner of UDP applications.  Several
things:

  - In fact, RFC8085 (on UDP usage) includes many of the same things
    (cribbed from this I-D in some cases, actually!).  So, I think
    your framing this as applying TCP guidance too widely is
    incorrect.

  - The WG chairs were conscious of this and explicitly got input
    from folks working in these other (non-TCP) areas, as well.

  - The WGLC was run in both tcpm and tsvwg.

So I do think this is quite a bit more widely applicable than TCP.
It did start its life as a TCP document, but grew in breadth as
folks have said "hey, that applies [here]" (e.g., most recently when
Jana noted this was quite applicable within QUIC).  It has been
developed and reviewed as pretty general for a while now.  I don't
think we're somehow trying to sneak something through that is
broader than it either should be or has been reviewed to be.

I'll say something quick about the rest of the things, but basically
I am happy to add bits of clarification and fix sloppy writing.

> When I got to "Within the standards process"

Will add "IETF".

> I see an underlying assumption that the network is unreliable and
> that the problem is packets discarded as a result of congestion.
> A common assumption but untrue in some cases.

If your network is reliable then I presume you won't be reading
documents about loss detection.  But, I dunno.

We can add a sentence to the intro to explicitly say we are
discussing unreliable networks if that helps.

> Likewise, I see an assumption that the recipient will always
> generate an acknowledgement when asked.  Again, untrue for some
> protocols so again an assumption I would like to see stated.

I don't think we *assume* this is *always* the case.  This is from
the document:

    Various mechanisms are used to detect losses in a packet stream.
    Often we use continuous or periodic acknowledgments from the
    recipient to inform the sender's notion of which pieces of data are
    missing.

Without details, there is an acknowledgment there that there are
different ways to detect loss other than continuous ACKs.  And, we
state "often we use" ACKs, which I think runs counter to your notion
that we "assume" "always".  So, I am not sure what you want here.

> Safety is mentioned many times; what is the danger?  I do not know and
> would like to be told (congestive collapse?).

Safety in a congestion, not security, sense.  I can add a quick
clarification on this.

> "protocols ultimately can only count on the passage of time
> without delivery confirmation " true for some networks, not true
> for others.

I struggle to think of a case where it doesn't apply.  There are for
sure cases where we code the stream so that we get probabilistically
damn close to ensuring delivery without a continuous stream of ACKs
for specific packets.  But, without some feedback ("delivery
confirmation") to the sender how could we ever be sure the data
arrived?

> I do see a steady if small increase in IETF protocols to detect
> and react to problems rather than waiting for someone else - like
> TCP - to notice and do something so again I am seeing an
> assumption.

I can't follow this.  I don't mean to disagree with your
characterization of IETF protocols, but I don't understand how
you're applying that statement to the document.

allman