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

From: tom petch <[email-masked]>
Date: Thu, 28 May 2020 11:37:54 +0000

Looking at this takes me back.

The format of the references is not one I have seen in a long time, likewise the running footing, the front matter and the placing of the Abstract while Terminology is also from a bygone age.  Ah, I see that the I-D is a decade old - all is explained but I do think that an update is called for.

Tom Petch

________________________________________
From: tcpm <[email-masked]> on behalf of The IESG <[email-masked]>
Sent: 18 May 2020 15:15
To: IETF-Announce
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [tcpm] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice

The IESG has received a request from the TCP Maintenance and Minor Extensions
WG (tcpm) to consider the following document: - 'Requirements for Time-Based
Loss Detection'
  <draft-ietf-tcpm-rto-consider-14.txt> as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-06-01. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

    Many protocols must detect packet loss for various reasons (e.g., to
    ensure reliability using retransmissions or to understand the level
    of congestion along a network path).  While many mechanisms have
    been designed to detect loss, protocols ultimately can only count on
    the passage of time without delivery confirmation to declare a
    packet "lost".  Each implementation of a time-based loss detection
    mechanism represents a balance between correctness and timeliness
    and therefore no implementation suits all situations.  This document
    provides high-level requirements for time-based loss detectors
    appropriate for general use in the Internet.  Within the
    requirements, implementations have latitude to define particulars
    that best address each situation.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: tom petch <[email-masked]>
Date: Thu, 28 May 2020 17:32:17 +0100

The content of this I-D puzzles me, a bit as if an academic paper had
been removed from its context and allowed to float away.

It talks of  'Within the standards process ...' which the rest of the
I-D implies is the IETF Standards process but it then recommends a
minimum RTO of one second which would be a catastrophe for some IETF
protocols which must detect failure in 10 milli-second so that repair is
effected within 50.

There are many references to safety so I looked at the Security
Considerations to see what the dangers are; none.  I am unclear what
these references to safety mean. What is the danger, what is the threat?

" When this time period passes without delivery confirmation the sender
concludes the data was lost in transit...." or the response was lost or
the response was witheld.  I hope that you never get an e-mail delivery
confirmation from me because while the protocol includes it, I will
always configure my MUA to suppress it; breach of security.

"Some protocols use keepalives, heartbeats or other messages to exchange
control information."  I struggle to think of an example of this.  On
the other hand, it came as a surprise to one protocol designer that when
he removed the plug on his connection, literally, nothing happened.
Layer 2 did not tell layer 3, layer 3 did not tell layer 4 and the
application was blissfully unaware, typical of the IETF protocol stack.
Ok failure detection is out of scope but I see heartbeat as primarily
for that purpose and have recommended it on a number of occasions.  (In
a similar vein, some IETF protocols are simplex so the best that can be
done is to add a heartbeat so that the urgent alarm, when it comes, has
a better chance of getting through). I find it hard to draw a hard 
distinction between failure detection and
loss detection.

I am ignorant of the technology encountered in server farms nowadays but
wonder if there is a degree of spoofing there, of ACK being generated at a
front end giving an illusion of a shorter FT, like a recursive resolver
but more so.

Overall the flavour I have is a document about TCP over the
ever-unreliable IP and lacking more general application.  TCP already 
has a rich literature of documents about timeout.  Not wrong, but
likely to be useful to the designer(s) of a new layer four protocol.

Tom Petch

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

---

From: "Mark Allman" <[email-masked]>
Date: Thu, 28 May 2020 13:10:47 -0400

I just want to quickly correct one thing here ...

[the draft] then recommends a minimum RTO of one second

(a) It DOES NOT say this at all.  The document does not specify ANY
    minimum RTO.  The document does says this:

        In the absence of any knowledge about the latency of a path,
        the initial RTO MUST be conservatively set to no less than 1
        second.

    But, as soon as there is some notion (e.g., a RTT measurement)
    then there is knowledge and this no longer applies.  I.e., this
    is for the startup case where we are beginning transmission into
    an unknown network path.

(b) If this is too hefty for some application, that's fine.  Do what
    we do now and get consensus to use something different.  Again,
    the document says:

        The correct way to view this document is as the default
        case.

        [...]

        The requirements in this document may not be appropriate in
        all cases and, therefore, inconsistent deviations may be
        necessary (hence the "SHOULD" in the last bullet).  However,
        inconsistencies MUST be (a) explained and (b) gather
        consensus.

    In other words, the worst case is the current case.

I am not entirely sure I understand the remaining points in the
review as it's pretty rambling to me.  Certainly we use heartbeats
(in things like SCTP) and control packets (think TCP zero window
probes or keep-alives).  The document is very simply saying that if
these are used in some fashion we can also use them to measure FT
information.  That seems pretty reasonable to me and I can't figure
out what your complaint about that is.  Perhaps you could try again
so my pea brain can understand the complaint?

Thanks!

allman

---

From: "Mark Allman" <[email-masked]>
Date: Thu, 28 May 2020 13:09:41 -0400

[...]

Thanks!

allman

---

From: tom petch <[email-masked]>
Date: Fri, 29 May 2020 12:29:50 +0100

Mark

Yes, my comments ramble:-)  The underlying thread is that for me the
document lacks context, lacks assumptions, or at least ones explicit
enough for me to pick up.

When I got to
"Within the standards process"
I thought IEEE standards process? mmm no, but the absence of IETF is the
sort of detail that I find missing albeit trivial in this case.

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 that is the basis of this I-D,
then I think that it needs spelling out up front.

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.

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

"protocols ultimately can only count on the passage of time without
delivery confirmation "
true for some networks, not true for others.  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.

Apologies for misquoting you on the figure of one second; yes you offer
a more nuanced guideline.  Yet again it makes me think this is about
e.g. web access with HTTP while other IETF protocols are dealing with
timescales an order or two of magnitude shorter.

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; 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; but even then it would only be applicable if the
underlying network had the assumed characteristics of IPv4.

Tom Petch

> ----- Original Message -----
> From: "Mark Allman" <[email-masked]>
> Sent: Thursday, May 28, 2020 6:09 PM
>>

---

From: "Mark Allman" <[email-masked]>
Date: Fri, 29 May 2020 08:45:17 -0400

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.

> 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

---

From: tom petch <[email-masked]>
Date: Sat, 30 May 2020 12:35:19 +0100

> From: "Mark Allman" <[email-masked]>
> Sent: Friday, May 29, 2020 1:45 PM
>
>> Hi Tom!
>>

  Mark
  This is good to hear but I wish that more detail of this was in the I-D.
  I have followed a number of Transport AD review of xxxx-over-UDP and it
  was always about the need for flow control but never with the sort of
  techniques that TCP uses, usually just a requirement for a statement on
  rate limiting by the sender so if there are xxxx-over-UDP which measure
  RTO and lost packets and act accordingly, then that would be excellent
  to hear about.  I know of none (and yes I am familiar with RFC8085) so
  including non-TCP examples would counter the impression I have got that
  this is TCP!   SCTP I have always seen as son-of-TCP and so not much
  different in this context.  QUIC I have yet to encounter.  As it stands,
  the example of DNS caching server stands out to me as an example of
  broader application, of the I-D in general; I would value more such
  concrete examples. And below ...

>> documents about loss detection.  But, I dunno.

  No, I am being unclear.  It is the 'packets are lost due to congestion
  and that is THE problem' that I see as the unstated assumption for this
  and many IETF documents.  Is it correct? Often, perhaps, but I struggle
  to recall anyone testing the hypothesis and there is growing use of IETF
  protocols over different kinds of networks where the problem is e.g.
  interference and packet corruption so the recommended techniques will
  give the user a worse experience - the corrupt packet needs
  re-transmitting as soon as the interference is over and backing off the
  flow rate is bad news for the user.  And below...

>> Safety in a congestion, not security, sense.  I can add a quick

  Yes please, this is an example of what I generically refer to as a
  lack of context, that for me safety is usually something quite
  different in an I-D.  And below ..

>> you're applying that statement to the document.

It comes back to the assumption of a unreliable network, unreliable for
any reason, not just congestion.  An alternative approach is to make the
network reliable and this I see as a strong interest of WG such as TEAS,
CCAMP, MPLS and such like.  A statement up front about the assumption of
unreliability would address this.

Tom Petch

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 31 May 2020 11:54:01 -0700

> information.  That seems pretty reasonable to me and I can't figure

There was a quote from the document: "Some protocols use keepalives,
heartbeats or other messages to exchange control information."
A naive reading of this text is that it is discussing ways to exchange
control information, and giving specific examples of keepalives and
heartbeats as messages used to exchange control information (while admitting
the existence of other such messages).  This is as surprising to me as it
is to Tom -- keepalives and heartbeats do not, in my experience, contain
control information!

Your follow-up discussion suggests that the intent is to say that "some
protocols use regular/periodically/frequently exchanged messages, such as
for keepalives, heartbeats, or control-information exchange" and to
leverage that traffic for FT purposes.  I suggest that this be clarified in
the text of the document.

Thanks,

Ben