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

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

Hi Stewart!

Thanks for the feedback.  Sorry for the long RTT.  I had a recent
deadline and am now trying to dig out.

> Major issues:
>
> As far as I can see this text only applies to exchanges between
> applications and network support applications such as
> DNS. I.e. this is targeted at layer 4 and above. Given the
> religious nature of BCPs in the eyes of some reviewers, and to
> prevent endless explanations by those that design routing
> protocols, OAM and other lower layer sub-system I think there
> needs to a scoping text in block capitals at the at the very start
> of the documnet.

I am not entirely sure what you're suggesting here.  Per note to
Tom, I am going to add a few words to the intro.  Maybe that will
help.  I think it's unlikely I'll use block capitals! :-)

> =========
>
>       - 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.
>
> SB> That can be quite an onerous obligation  and provide scope for
> SB> endless argument when reviewers are not domain experts in the
> SB> protocol being designed.

This was added because another reviewer thought it was for sure
necessary.

I guess I don't understand why you'd call this 'an onerous
obligation' since presumably you'd do it anyway without this
document.  Are we ramming things through without consensus?  If not
(my assumption), (b) is no sweat.  Are we ramming things through
without thought?  If not (my assumption), (a) is straightforward and
hopefully is being done anyway.  In other words, I don't understand
the complaint here because if you don't want to use the guidelines
then that is fine, but in going through the standard process to
define a loss detector you'll end up meeting this bullet.  Even if
this document doesn't get published or didn't exist our documents
should still be meeting this bullet.

> =======
>
>           While there are a bevy of uses for timers in protocols---from
>           rate-based pacing to connection failure detection and
>           beyond---these are outside the scope of this document.
>
> SB> I am not sure what that means for the applicability of this
> SB> document.

This was added at some point along the way because someone thought
something like rate-based pacing could be covered by the guidelines
and the intent is to say it is not.  I have zero love for this bit
and would happily remove it, but am loathe to do so because the old
comment will then come back.

> =========
>
>     (1) As we note above, loss detection happens when a sender does not
>         receive delivery confirmation within an some expected period of
>         time.  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.
>
> SB> This issue may be addressed by the scoping text, but 1s is no
> SB> use when you are trying to detect sub 50ms of packet loss in
> SB> the infrastructure.

We have to start somewhere when we know nothing.

I think in my thread with Tom we hit upon this notion that the
document is really about sort of arbitrary, unknown and therefore
presumed unreliable networks.  I am going to add some words to this
effect.  Does this help?

Again, for specific environments where things are more nailed down
and known, deviations are fine and explicitly OK.  But, as a general
default I think saying "when you don't know anything < 50msec is
cool" is unlikely to be appropriate.  Well, no, I think it would be
quite inappropriate, actually.

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

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

I am going to suggest we revisit this after I hack out a little
extra text for the intro.  You can see if that helps.

> ==========
>
>       "- This document does not update or obsolete any existing RFC.
>         These previous specifications---while generally consistent with
>         the requirements in this document---reflect community consensus
>         and this document does not change that consensus."
>
> I think it needs to be clear that adherence to this RFC is not
> required for minor updates and extensions to existing RFCs. Having
> seen minor routing extension held up by security concerns related
> to underlying protocols rather than the extension itself there is
> a lot of sensitivity on this point in some quarters of the IETF.

Um.  Do you have suggested words?  I am not much of a protocol
lawyers (thankfully!), but I am not really conjuring the case you're
concerned about.  Something like ...

  (1) RFC XXXX was published 10 years ago and violates
      rto-consider.
  (2) We want to do a XXXXbis.
  (3) The bis has to then explain why it's cool to violate
      rto-consider.

... ?

I would say if XXXX has a loss detector that had consensus and has
been in use for a while it'd be pretty easy to get consensus for
XXXXbis that we can still use it as it has worked fine.

> It might be useful to make it clear that there are some
> applications that would prefer no data to late data.

This document is about loss detection, not what one does after
detecting.  So, we do say ...

    However, as discussed above, the detected loss need not be
    repaired

I am happy to re-enforce this point.  Text suggestions welcome.

> Nits/editorial comments:
>
> The terminology section confuses ID-nits - I think it should be a
> section in its own right later in the document.

Yeah- id-nits as it is run when submitting doesn't flag this.  It
was flagged by someone else in LC.  Because I am old school it's
hard to renumber everything and so I was just leaving this for the
rfc-ed to do something reasonable here.

> The following nits issues need looking at
>
>   == Missing Reference: 'RFC5681' is mentioned on line 377, but not defined
>
>   == Unused Reference: 'RFC3940' is defined on line 515, but no explicit
>      reference was found in the text
>
>   == Unused Reference: 'RFC4340' is defined on line 519, but no explicit
>      reference was found in the text
>
>   == Unused Reference: 'RFC6582' is defined on line 540, but no explicit
>      reference was found in the text

I will fix all these.  Again, I was trusting the id-nits when I
submitted and these were not flagged (or, if they were it wasn't in
a way that foisted them on my screen).  But, they're easy fixes, so
thanks!

allman

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 6 Jun 2020 08:19:52 +0100

Please see below.

> comment will then come back.
I think Mark is correct, there are many transport uses of timers, and 
calling out a small number of other uses was important to scope this 
withing the transport discussions, even if it just says "timers also do 
other stuff".
> quite inappropriate, actually.

This is I think a natural discussion based on a different perspective. 
The 1 second initial starting value for a transport path has been there 
for a long time, and transport reviewers will frequently quote this be 
it for transport:  SCTP, TCP, or for UDP-based apps (BCP: 145 Sect 
3.1.1). I'd expect this is about the assumed starting position for an 
Internet path.

True if we're talking about a link between adjacent peers, this is 
something very different.

> 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.
>> point that things like BFD have different considerations.
Isn't BFD is a link protocol between adjacent systems?
> .... ?
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 7 Jun 2020 10:11:36 -0700

> 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 8 Jun 2020 10:19:17 +0100

I agree, see below.

> share traffic with non-local traffic, e.g., as in draft-ietf-bfd-vxlan.

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 8 Jun 2020 13:46:39 +0100

> On 5 Jun 2020, at 17:43, Mark Allman <[email-masked]> wrote:
> 
> 
> Hi Stewart!
> 

In the text the discussion and examples and base learning seem to derive
From the transport layer.

RTT issues apply to other aspects of the Internet, and you either need to
analyse and discuss them in the same depth and apply your conclusions accordingly
Or you need to explicitly exclude them

What I am hoping we can do is to prevent a single focus review of the 
Internet operations giving rise to endless discussions and argument when
Legitimate designs are proposed for other aspects.

The antithesis of the big I internet is a service provider domain where
Different considerations often apply.

> document.  

Not necessarily. There is a lot of experience in how to run the layers
Below transport.

> Are we ramming things through without consensus?

Well if it impacts Int and Routing and there has not been widespread 
Review there the answer is yes. You are getting pushback from a
GenARt reviewer that happens to be a specialist in the lower layers
So arguably the process is working, but wider review is always better,

>  If not

Yes, but having seen far too many religious standoffs between the areas
Over the years, it would be nice not to create the basis for more such
Events.

> comment will then come back.

Perhaps a more precise definition is required. It is rather general.

> quite inappropriate, actually.

As you may gather my concern is that by making this a catch all position
You catch too much and put a burden of work on too many other groups.
 
If you are talking about L4 and above in the big I Internet I am not concerned, 
But as written it has a much larger scope and that concerns me.

> default I think this is our best advice.

No, I think you need to show that you have discussed this with other
Groups before imposing it on them.

> extra text for the intro.  You can see if that helps.

OK, let’s see the new text.

> XXXXbis that we can still use it as it has worked fine.

I have seen a number of cases where minor changes to protocols became 
Hostage to the ambitions of others to make a fundamental change 
And I hope we can avoid this here.

> I am happy to re-enforce this point.  Text suggestions welcome.

OK

> rfc-ed to do something reasonable here.

I run ID-nits in verbose mode before submission. This partially
A matter of respect for reviewers and the editors, and partly because I
Figure that the more errors you deal with the easier it is to find the 
Important errors that may mask.

> a way that foisted them on my screen).  But, they're easy fixes, so

Thanks

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 8 Jun 2020 13:57:37 +0100

> On 6 Jun 2020, at 08:19, Gorry Fairhurst <[email-masked]> wrote:
> 
> Please see below.
> 
> I think Mark is correct, there are many transport uses of timers, and calling out a small number of other uses was important to scope this withing the transport discussions, even if it just says "timers also do other stuff".

If the scope of this is explicitly transport and above I have no issues.

If it has a greater scope the scope of study and recommendations really needs to increase accordingly.

> This is I think a natural discussion based on a different perspective. The 1 second initial starting value for a transport path has been there for a long time, and transport reviewers will frequently quote this be it for transport:  SCTP, TCP, or for UDP-based apps (BCP: 145 Sect 3.1.1). I'd expect this is about the assumed starting position for an Internet path.
> 
> True if we're talking about a link between adjacent peers, this is something very different. 
> 

We do multi-hop OAM in RTG to hold the infrastructure together.

Again, my point is that if the scope is L4 and above I have no issue, but the scope seems to be wider.

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

A common standard rule in OAM type situation is three fast packets and then back-off.

> Isn't BFD is a link protocol between adjacent systems?

No, not always, you can have multiple-hop BFD.

This is infrastructure and not user data and there is a school of though that in data planes where
The same data path is used for both control and user data, the user data is sacrificial to maintaining
The infrastructure. The reason that you do backoff in these cases is not to avoid congestion but
Instead to avoid overloading the control peer, i.e. the route processor in the peer router.

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 8 Jun 2020 13:59:53 +0100

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

Clarifying that would help with many of the issues that I am concerned about.

Stewart

---

From: "Mark Allman" <[email-masked]>
Date: Mon, 08 Jun 2020 15:52:16 -0400

Hi Stewart, et.al.!

I just submitted a new version of rto-consider.  Please ask the
datatracker for diffs between this and rev -14.  The highlights:

  - The diffs with the last rev are here: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt

  - All small comments addressed.

  - I think we all agree that this is not a one-size-fits-all
    situation.  Rather, this document is meant to be a default case.
    So, the main action of this rev is to make that point more
    clearly.  The first paragraph in the intro is new.  Also, there
    are some more words fleshing out the context more in section 2.
    In particular, more emphatically making the point that other
    loss detectors are fine for specific cases.

  - The first paragraph in the intro also makes clear we adopt the
    loss == congestion model (as that is the conservative default,
    not because it is always true).

  - I made one other change that wasn't exactly called for, but
    seems like an oversight.

    Previously guideline (4) said loss MUST be taken as an
    indication of congestion and some standard response taken.  But,
    this guideline has an explicit exception for cases where we know
    the loss was caused by some non-congestion event.  Guideline (3)
    says you MUST backoff.  But, it did not have this exception for
    cases where we can tell the cause.  But, I think based on the
    spirit of (4), (3) should also have these words.  So, I added
    them.

    Also, I swapped (3) and (4) because it seemed more natural in
    re-reading to first think about taking congestion action and
    then dealing with backoff.  I think the ordering is a small
    thing, but folks can yell and I'll put it back if there is
    angst.

Please take a look and let me know if this helps things along or
not.

allman

---

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

Stewart,

do we need more cycles for this, or is draft-15 sufficient to address your
concerns?

On Mon, Jun 8, 2020 at 12:52 PM Mark Allman <[email-masked]> wrote:

>   - The diffs with the last rev are here:
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 17 Jun 2020 10:20:53 -0700

Hi Stewart,

If there are no further objections, I'm going to declare consensus.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Jun 2020 18:46:08 +0100

Please give me until tomorrow and I will take a look.

Life has been a bit busy here,

Stewart

On 17 Jun 2020, at 18:20, Martin Duke <[email-masked]> wrote:

Hi Stewart,

Stewart,

do we need more cycles for this, or is draft-15 sufficient to address your concerns?

Hi Stewart, et.al.!

seems like an oversight.

them.

angst.

not.

allman

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Jun 2020 11:00:15 +0100

> On Thu, Jun 11, 2020 at 1:45 PM Martin Duke <[email-masked] <mailto:[email-masked]>> wrote:
> Stewart,
> 
> On Mon, Jun 8, 2020 at 12:52 PM Mark Allman <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Stewart, et.al <http://et.al/>.!
> 
>   - The diffs with the last rev are here: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt <https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt>

In the general case, delay across a
    network path depends not only on distance, but also a number of
    variable components such as the route and the level of buffering in
    intermediate devices.

Its is more the contending/conflicting traffic rather than the buffering, or perhaps the time spent in queues, but “buffering” is a link a transport colloquial term.

Since our wide-area network paths are best
    effort, packet loss is a regular occurrence. 

No the best effort Internet experiences this. There ate many well engineered WAN that do not.

What I am not seeing is clearer text that distinguishes between user traffic and “engineering” traffic that is used to make the network work, and between the end to end traffic and traffic within an AS that may be there for other purposes (high value service also offered by the provider) and WANs that are well engineered.

Perhaps we could include a clearer disclaimer regarding the non-best-effort-internet-end-to-end traffic?

You have some text on this down in section 2 but it is a bit buried.

Perhaps something early on of the form: This document is specially concerned with end to end behaviour over the best effort Internet. As noted in section 2 it may not me applicable to other types of WAN, or to the  traffic used in affecting the operation of the Internet itself.

 An exception to this rule is if an IETF standardized mechanism
        determines that a particular loss is due to a non-congestion
        event (e.g., packet corruption).  

That is a bit heavy. It should be “a protocol” there than an IETF standardarized mechanism. The IETF does not have a monopoly on pre-blessing protocols before they are deployed.

>     loss detectors are fine for specific cases.

As I note above from a routing and packet transport (as opposed to the transport layer) perspective I think we should more clearly recognise at the beginning the fact that this is for the worst case network, not for well engineered (WAN and DC) networks  and the mechanisms fundamental to the operation of the network itself.

>     spirit of (4), (3) should also have these words.  So, I added

In some cases you cannot tell the cause, but it is more important to ignore the loss. OAM being a particularly good example.

> Please take a look and let me know if this helps things along or

We are getting there, but I would ask that you take the transport hat off and look again from an infrastructure and packet transport perspective.

Best regards

Stewart

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 18 Jun 2020 12:01:12 +0100

See a few comments (marked GF) from the perspective of other transport 
RFCs, in case this helps you find text...

-------- Forwarded Message --------
Subject: 	Re: [tcpm] Genart last call review of 
draft-ietf-tcpm-rto-consider-14
Date: 	Thu, 18 Jun 2020 11:00:15 +0100
From: 	Stewart Bryant <[email-masked]>
To: 	Martin Duke <[email-masked]>
CC: 	tcpm <[email-masked]>, Review Team <[email-masked]>, Mark Allman 
<[email-masked]>, Last Call <[email-masked]>, Stewart Bryant 
<[email-masked]>, tom petch <[email-masked]>, 
[email-masked]

> On 17 Jun 2020, at 18:20, Martin Duke <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Hi Stewart,
>

*In the general case, delay across a network path depends not only on 
distance, but also a number of variable components such as the route and 
the level of buffering in intermediate devices.*

Its is more the contending/conflicting traffic rather than the 
buffering, or perhaps the time spent in queues, but “buffering” is a 
link a transport colloquial term.

GF: The word being sought might be "queueing" (I think that buffering is 
thought of as memory- and hence max queue).

*Since our wide-area network paths are best effort, packet loss is a 
regular occurrence. *

No the best effort Internet experiences this. There ate many well 
engineered WAN that do not.

What I am not seeing is clearer text that distinguishes between user 
traffic and “engineering” traffic that is used to make the network work, 
and between the end to end traffic and traffic within an AS that may be 
there for other purposes (high value service also offered by the 
provider) and WANs that are well engineered.

Perhaps we could include a clearer disclaimer regarding the 
non-best-effort-internet-end-to-end traffic?

Perhaps something early on of the form: This document is specially 
concerned with end to end behaviour over the best effort Internet. As 
noted in section 2 it may not me applicable to other types of WAN, or to 
the  traffic used in affecting the operation of the Internet itself.

GF: Actually, I do think a well-engineering WAN can be in scope of your 
spec. The two wrods I was expecting were "controlled environment" or 
"pre-provisioned" capacity, these might not see the same oath 
properties. A DC is typically regarded in transport specs as a 
"controlled environment".

*An exception to this rule is if an IETF standardized mechanism 
determines that a particular loss is due to a non-congestion event 
(e.g., packet corruption). *

That is a bit heavy. It should be “a protocol” there than an IETF 
standardarized mechanism. The IETF does not have a monopoly on 
pre-blessing protocols before they are deployed.

GF: Unsure myself what is needed - isn't this guidance for design of 
protocol mechansims?

>             loss detectors are fine for specific cases.

As I note above from a routing and packet transport (as opposed to the 
transport layer) perspective I think we should more clearly recognise at 
the beginning the fact that this is for the worst case network, not for 
well engineered (WAN and DC) networks  and the mechanisms fundamental to 
the operation of the network itself.

>             spirit of (4), (3) should also have these words.  So, I added

In some cases you cannot tell the cause, but it is more important to 
ignore the loss. OAM being a particularly good example.

>         Please take a look and let me know if this helps things along or

We are getting there, but I would ask that you take the transport hat 
off and look again from an infrastructure and packet transport perspective.

Best regards

Stewart

On 18/06/2020 11:00, Stewart Bryant wrote:
>
>
>> On 17 Jun 2020, at 18:20, Martin Duke <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Stewart,
>>
> *In the general case, delay across a network path depends not only on 
> distance, but also a number of variable components such as the route 
> and the level of buffering in intermediate devices.*
>
> Its is more the contending/conflicting traffic rather than the 
> buffering, or perhaps the time spent in queues, but “buffering” is a 
> link a transport colloquial term.
>
>
> *Since our wide-area network paths are best effort, packet loss is a 
> regular occurrence. *
>
> What I am not seeing is clearer text that distinguishes between user 
> traffic and “engineering” traffic that is used to make the network 
> work, and between the end to end traffic and traffic within an AS that 
> may be there for other purposes (high value service also offered by 
> the provider) and WANs that are well engineered.
>
> Perhaps we could include a clearer disclaimer regarding the 
> non-best-effort-internet-end-to-end traffic?
>
> Perhaps something early on of the form: This document is specially 
> concerned with end to end behaviour over the best effort Internet. As 
> noted in section 2 it may not me applicable to other types of WAN, or 
> to the  traffic used in affecting the operation of the Internet itself.
>
>
> *An exception to this rule is if an IETF standardized mechanism 
> determines that a particular loss is due to a non-congestion event 
> (e.g., packet corruption). *
>
> That is a bit heavy. It should be “a protocol” there than an IETF 
> standardarized mechanism. The IETF does not have a monopoly on 
> pre-blessing protocols before they are deployed.
>
>
>
>>
> As I note above from a routing and packet transport (as opposed to the 
> transport layer) perspective I think we should more clearly recognise 
> at the beginning the fact that this is for the worst case network, not 
> for well engineered (WAN and DC) networks  and the mechanisms 
> fundamental to the operation of the network itself.
>
>>
> In some cases you cannot tell the cause, but it is more important to 
> ignore the loss. OAM being a particularly good example.
>
>>
> We are getting there, but I would ask that you take the transport hat 
> off and look again from an infrastructure and packet transport 
> perspective.
>
> Best regards
>
> Stewart
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Jun 2020 13:56:51 +0100

> On 18 Jun 2020, at 12:01, Gorry Fairhurst <[email-masked]> wrote:
> 
> 
> 
> See a few comments (marked GF) from the perspective of other transport RFCs, in case this helps you find text...
> 
> Subject:	Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
> From:	Stewart Bryant <[email-masked]> <mailto:[email-masked]>
> To:	Martin Duke <[email-masked]> <mailto:[email-masked]>
> CC:	tcpm <[email-masked]> <mailto:[email-masked]>, Review Team <[email-masked]> <mailto:[email-masked]>, Mark Allman <[email-masked]> <mailto:[email-masked]>, Last Call <[email-masked]> <mailto:[email-masked]>, Stewart Bryant <[email-masked]> <mailto:[email-masked]>, tom petch <[email-masked]> <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> 
> 
> 
>> On 17 Jun 2020, at 18:20, Martin Duke <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Stewart,
>> 
> GF: The word being sought might be "queueing" (I think that buffering is thought of as memory- and hence max queue).

SB> Queuing ins the word, thank you.
> GF: Actually, I do think a well-engineering WAN can be in scope of your spec. The two wrods I was expecting were "controlled environment" or "pre-provisioned" capacity, these might not see the same oath properties. A DC is typically regarded in transport specs as a "controlled environment".

SB> That works for me as well.

> GF: Unsure myself what is needed - isn't this guidance for design of protocol mechansims?

SB> .. and if that is the case the words used in the text are way over the top, and may actually cause harm to innocent protocols.
SB> There is a bunch of concern in the industry that the IETF is now too illiberal and such words fuel that concern.

Best regards

Stewart

---

From: "Mark Allman" <[email-masked]>
Date: Thu, 18 Jun 2020 09:32:15 -0400

Last comment first ...

> We are getting there, but I would ask that you take the transport
> hat off and look again from an infrastructure and packet transport
> perspective.

I don't view this as looking at it from a transport
vs. infrastructure perspective.

And, I am not disagreeing with your perspective.  My take is that
the nub of what you're saying is that there are cases where we know
something about the network.  And, that something let's us design a
more savvy loss detection and response scheme.  E.g., because the
link / path is known to be short and so using an initial RTO of 1sec
is too long.  E.g., because the cause of loss is known or can be
safely assumed to not be congestion.  And, I think that view is both
correct and reasonable.

However, ...

(0) I do not view that view as inconsistent with this document at
    all.

(1) Because there are cases where we know more doesn't make a set of
    default requirements for the general case when we don't
    understand the path any less valid.

(2) The document explicitly says alternates are fine modulo the
    usual consensus.  I.e., in cases where we have more information
    we can do things differently.  And, the cost of that is no
    different than the cost today (i.e., specifying it and gaining
    consensus).

So, my view is that this all boils down to making it clear that this
is not somehow THE (best) way to do time-based loss detection for
all cases.  Rather, following the guidelines with result in a
safe-for-general-use loss detector.

> buffering, or perhaps the time spent in queues, but “buffering” is
> a link a transport colloquial term.

Per this and Gorry's note, I will tweak this to use queuing, as that
is what I meant.

> You have some text on this down in section 2 but it is a bit buried.

OK, let me see if I can foreshadow this a bit more and/or pull some
from section 2 to earlier.

> [...]
> In some cases you cannot tell the cause, but it is more important
> to ignore the loss. OAM being a particularly good example.

First, I don't think I can readily change this without going against
the consensus the document has already gathered.  (I.e., this is not
about the intro, framing, context, etc. bits, but the actual meat of
the technical stuff.)

Second, you are right that the IETF does not have a monopoly, but
that doesn't make the statement in the document the wrong thing to
say.

Third, I doubt I should change it.  The problem here from the
standpoint of a set of default guidelines is that we'd like a
mechanism to determine the cause of loss to **actually work** before
it's OK to avoid a congestion control response.  If a standardized
mechanism is used then we have some confidence that the mechanism
has been vetted as reasonable.  If the mechanism is not standardized
then we have no idea if it actually works or if it is some
ill-conceived scheme that is badly broken.  In this latter case, I
don't think we want to bless this approach as OK within the default.
It may be OK, but it should get some consensus that it is OK.

allman

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Jun 2020 15:18:05 +0100

Here is how we should proceed.

We make as much progress as we can agree on which will clear some of the issue below.

For any remaining issues for which you have wider consensus but where we cannot agree, I modify my review and the IESG decides how they wish to proceed.

I am prepared to be in the rough but I have a duty to draw attention to concerns.

Best regards

Stewart

> On 18 Jun 2020, at 14:32, Mark Allman <[email-masked]> wrote:
> 
> 
> Last comment first ...
>

---

From: "Mark Allman" <[email-masked]>
Date: Thu, 18 Jun 2020 13:43:17 -0400

> For any remaining issues for which you have wider consensus but
> where we cannot agree, I modify my review and the IESG decides how
> they wish to proceed.

yep - sounds good.  i am going to try to flesh out the intro
paragraph a little more with some of the stuff from section 2.  but,
outside that i am not sure what to do.  i'll get a new version sent
out in a day or a few.

thanks,
allman

---

From: "Mark Allman" <[email-masked]>
Date: Fri, 19 Jun 2020 11:02:49 -0400

I just posted a new version of rto-consider (-16).  The document,
diffs, etc. can be found here:

  https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/

I fixed a few nits that had been pointed out throughout the
document.

The main work in this rev is in the first two paragraphs of the
intro.  I honed these based on the discussion with Stewart and
Gorry.  Well, "honed" might ultimately look like "rewrote" even if
that wasn't the process or exactly my intention. :) I tried to pull
some of the notions from later in the document up here to the front
of the document, as requested.  In particular, I brought forward the
notion of this document as a default and not as a one-size-fits-all.
I hope this addresses the concerns to a large extent.

I also want to make a meta point here, which is clearly about this
document, but also I think much more widely applicable.  I continue
to believe that the Internet has grown to what it is in no small
part because at many crucial points we chose generality over
optimality.  I do not believe we should shun generality---either in
terms of protocol development or the lessons we have learned.  That
doesn't mean we cannot acknowledge places where more pointed
solutions may be appropriate.  It doesn't mean we can't accommodate
different and non-general approaches in things like guidelines and
requirements.  But, I think it'd be a pity if we couldn't write
general documents because there are cases where they will be
suboptimal or not applicable.  There are always such cases.  And, if
that is the gate, we're going to design a network we won't much care
for, I think.  IMHO.  FWIW.

allman

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 19 Jun 2020 16:59:34 +0100

One minor nit on the new text, the term "controlled environment" is used 
elsewhere in the RFC series in transport-related documents to describe 
what you name "constrained environment".

Gorry

---

From: Martin Duke <[email-masked]>
Date: Fri, 19 Jun 2020 11:58:00 -0700

Hi Stewart,

I'm going to ship draft-16 to the IESG today. Any last concerns beyond the
stated differences from WG consensus?

Yoshi, please update the shepherd writeup to cover the flavor of this
discussion.

On Thu, Jun 18, 2020 at 7:18 AM Stewart Bryant <[email-masked]>
wrote:

> For any remaining issues for which you have wider consensus but where we
> cannot agree, I modify my review and the IESG decides how they wish to
> proceed.
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 19 Jun 2020 14:21:51 -0700

OK. if there're no further opinions, I will do it.
--
Yoshi