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: "Mark Allman" <[email-masked]>
Date: Mon, 01 Jun 2020 07:41:40 -0400

> 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.

I tend to bin packets as either "data" or "control", which is
probably why the sentence reads like it does.  However, we don't
have to figure out who is right here.  I think the intent of the
document is to say one can scrape a FT sample from a non-data
exchange.  That is the important part and doesn't seem to be an
issue.  I have made a note to say that more directly.

Thanks,
allman

---

From: "Mark Allman" <[email-masked]>
Date: Mon, 01 Jun 2020 08:14:34 -0400

Thanks,
allman

---

From: "Mark Allman" <[email-masked]>
Date: Fri, 05 Jun 2020 08:51:55 -0400

Hi Tom!

Sorry for the long RTT .... I had a deadline earlier this week and
am still trying to dig out.

>  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?

Well, yes, I agree with the first part of the sentence.  However, I
disagree that is somehow an unstated assumption.  The document says:

    (4) Loss detected by the RTO mechanism MUST be taken as an
        indication of network congestion and the sending rate adapted
        using a standard mechanism (e.g., TCP collapses the congestion
        window to one segment [RFC5681]).

That seems pretty explicit to me.  And, yes, I fully understand loss
happens for non-congestion reasons.  But, as a default---which this
document is---I think this guideline is on firm ground.

> A statement up front about the assumption of unreliability would
> address this.

I have added a note and will note in the intro that we take the
pessimistic (but realistic) assumption that the network is
unreliable and/or unknown.  Clearly if that is not the case one
could land somewhere else.

Thanks!

allman

---

From: "tom petch" <[email-masked]>
Date: Fri, 5 Jun 2020 16:53:27 +0100

---- Original Message -----
From: Mark Allman [email-masked]
Sent: 05/06/2020 13:51:55

Hi Tom!

That seems pretty explicit to me.  And, yes, I fully understand loss
happens for non-congestion reasons.  But, as a default---which this
document is---I think this guideline is on firm ground.
<tp>
Mark, that is what I am questioning, that by default loss implies congestion.  Historically true for the IETF but I think that there are a growing number of cases where it is not true as in a post I saw on another WG list this week where a document was saying that loss MUST NOT be taken as an indication of congestion so the MUST in this I-D I find too strong.   I am saying that there are a number of places in the document where congestion is assumed to be the cause.  Thus 4(i) has
'when a network is already congested' which I think should be 'if the network is already congested' or the next paragraph about 'cause congestion control ' or in s.5 'detecting loss carries a requirement to invoke a congestion response'; no, only if the network is of a kind where loss is due to congestion, not other networks.
As Stewart put it better than I, this is BCP and so could be used wrongly 

---
New Outlook Express and Windows Live Mail replacement - get it here:
https://www.oeclassic.com/

against protocols where it is inappropriate because the scope of this I-D appears to be so broad.
Tom Petch

Thanks!

allman

---

From: "Mark Allman" <[email-masked]>
Date: Fri, 05 Jun 2020 12:16:57 -0400

> Mark, that is what I am questioning,

well ...

> that by default loss implies congestion.  Historically true for
> the IETF but I think that there are a growing number of cases
> where it is not true as in a post I saw on another WG list this
> week where a document was saying that loss MUST NOT be taken as an
> indication of congestion so the MUST in this I-D I find too
> strong.

OK.  So, I am not sure what to do here.  I will say several things ...

(1) I believe that as a general, default the document is quite right
    in specifying a congestion response and exponential backoff.

(2) I believe consensus of the WGs has been the same as my notion in
    (1) for some time now.  So, even setting aside (1), I am not
    sure I feel like I have carte blanche to change this.

(3) I do not believe loss always means congestion and I do not
    believe assuming such is always correct or should always be
    done.  I don't think I know anyone who thinks that.  So, the
    document explicitly says that is fine, just go get consensus
    that some other approach is fine.  (And, that should be
    happening regardless of this document, so I am not sure what the
    big deal is here.)

So, basically, I am not sure what to do here.  Maybe one of the ADs
can help.  Or, maybe we can set this aside and I can do the things I
told you I'd do and a little extra framing will make this better.  I
am all ears for advice here.

(BTW, I have a half response to Stewart, as well.  I am not ignoring
his review.  I am just behind.)

allman

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 5 Jun 2020 17:29:13 +0100

> On 5 Jun 2020, at 17:16, Mark Allman <[email-masked]> wrote:
> 
> 
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

A good example of congestion free transient loss is a link failure repaired 50ms later by FRR.

- Stewart

---

From: tom petch <[email-masked]>
Date: Mon, 8 Jun 2020 08:26:59 +0000

From: tcpm <[email-masked]> on behalf of Mark Allman <[email-masked]>
Sent: 05 June 2020 17:16

well ...

<tp>
Mark, what I would like to see is a statement up front, Introduction or just after, along the lines that the document (mostly?) assumes that loss is due to congestion which has historically been the case in the Internet and is likely still largely the case in the Internet and the recommendations here are designed to reduce that congestion .  but that there will be networks where loss is not due to congestion in which case the recommendations here MAY adversely affect the performance of the network.
I would not give an example but if one is needed, then it would be loss caused by a burst of interference where backing off simply slows down the rate unnecessarily.

Tom Petch

allman

---

From: Martin Duke <[email-masked]>
Date: Thu, 11 Jun 2020 13:43:48 -0700

Tom,

does draft-15 address your concerns?

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt

On Mon, Jun 8, 2020 at 1:28 AM tom petch <[email-masked]> wrote:

> Mark, what I would like to see is a statement up front, Introduction or
> just after, along the lines that the document (mostly?) assumes that loss
> is due to congestion which has historically been the case in the Internet
> and is likely still largely the case in the Internet and the
> recommendations here are designed to reduce that congestion .  but that
> there will be networks where loss is not due to congestion in which case
> the recommendations here MAY adversely affect the performance of the
> network.
> I would not give an example but if one is needed, then it would be loss
> caused by a burst of interference where backing off simply slows down the
> rate unnecessarily.
>
> Tom Petch
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: tom petch <[email-masked]>
Date: Fri, 12 Jun 2020 09:47:48 +0000

From: Martin Duke <[email-masked]>
Sent: 11 June 2020 21:43

Tom,

Martin

yes it does.  The new first paragraph makes a world of difference to me.
I omitted to mention some editorial issues before.

Terminology the boiler plate is out of date

s,2
This document is different from from ...

Requirements
would be easier to refer to if they were R1, R2a or some such

a reference for DNS recursive resolver would be good

EWMA needs  expanding on first use

Tom Petch

On Mon, Jun 8, 2020 at 1:28 AM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: tcpm <[email-masked]<mailto:[email-masked]>> on behalf of Mark Allman <[email-masked]<mailto:[email-masked]>>
Sent: 05 June 2020 17:16

well ...

<tp>

Tom Petch

allman

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

---

From: "Mark Allman" <[email-masked]>
Date: Fri, 12 Jun 2020 08:59:28 -0400

> Terminology the boiler plate is out of date

???

> This document is different from from ...

fixed

> would be easier to refer to if they were R1, R2a or some such

i didn't make a change here; editorial discretion, i guess

> a reference for DNS recursive resolver would be good

fixed

> EWMA needs  expanding on first use

fixed

i can push these to a new version whenever.  i'll wait to hear
stewart's response to martin before doing so, however.

thanks,
allman

---

From: t petch <[email-masked]>
Date: Fri, 12 Jun 2020 16:46:35 +0100

<tp>

try  2140bis s.2 para 1
793bis needs updating too

Tom Petch

---

From: "Mark Allman" <[email-masked]>
Date: Fri, 12 Jun 2020 13:40:00 -0400

(i was confused because i wouldn't call these 'terminology' or
'boilerplate' ... ugh ...)

> try  2140bis s.2 para 1

yeah, i guess i can add an additional cite to draft

???

793 nor 793bis is cited, so nothing to update here

allman

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Jun 2020 19:58:55 +0200

On 2020-06-12, at 19:40, Mark Allman <[email-masked]> wrote:
> Signed PGP part

The text you want to use is on page 3 of RFC 8174, which now is BCP 14 together with RFC 2119.

> 793 nor 793bis is cited, so nothing to update here

No, but 793bis also uses the old boilerplate (totally unrelated comment).

(Tom: When making comments to a draft, it helps to do those in a way that can be understood by the authors.)

Grüße, Carsten

---

From: "Mark Allman" <[email-masked]>
Date: Fri, 12 Jun 2020 14:05:55 -0400

> BCP 14 together with RFC 2119.

oh.  thank you for clearing that up.

> (Tom: When making comments to a draft, it helps to do those in a
> way that can be understood by the authors.)

+1

---

From: Joseph Touch <[email-masked]>
Date: Fri, 12 Jun 2020 12:38:03 -0700

> On Jun 12, 2020, at 10:58 AM, Carsten Bormann <[email-masked]> wrote:
> 

Agreed; I think the comment about 2140bis is a suggestion to copy the text out of that draft - not to cite the draft. But the text in our draft IS just the one verbatim from RFC 8174 as indicated.

Joe