Subject: [tcpm] RFC 793 (bis) vs. rto-consider

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Wed, 29 Mar 2017 19:44:51 +0000

<chair hat off>

Maybe I should expand on what I have orally mentioned in the meeting:

draft-ietf-tcpm-rfc793bis-05 states:

   Because of the variability of the networks that compose an

   internetwork system and the wide range of uses of TCP connections the

   retransmission timeout (RTO) must be dynamically determined.

   The RTO MUST be computed according to the algorithm in [8], including
   Karn's algorithm for taking RTT samples.

The first sentence with "must" is taken from RFC 793. The second sentence with "MUST" seems to follow from the MUST in RFC 6298. In my reading of the standards, the current wording in 793bis correctly reflects the wording of TCP PS standards.

draft-ietf-tcpm-rto-consider-05 states:

        (a) In steady state the RTO SHOULD be set based on recent

            observations of both the FT and the variance of the FT.

            In other words, the RTO should be based on a reasonable

            amount of time that the sender should wait for delivery

            confirmation before retransmitting the given data.

        (b) FT observations SHOULD be taken regularly.

To me, this wording seems compatible with RFC 8085, i.e., the BCP for UDP.

When rto-consider was approved as TCPM WG item, both (a) and (b) was a MUST.

As individual contributor, I struggle with accepting a SHOULD in (a) and (b) as best current practice requirement for TCP. In TCP, the well-defined protocol mechanisms IMHO allow a MUST for both cases, and this is how I read the "must" in RFC 793.

Also, I believe that in this case the requirements for TCP can (well, must) be tighter than for UDP protocols. The difference is that for UDP protocols it cannot be guaranteed that the protocol allows regular FT observations. In TCP we know that this is possible. So why allowing a SHOULD for TCP?

So, I wonder if there could be a reasoning for applying these two SHOULD to TCP? Most notably, could there be any reason why a TCP implementation would not measure RTT "regularly"?

Any thoughts?

Michael

---

From: Mark Allman <[email-masked]>
Date: Wed, 29 Mar 2017 16:33:19 -0400

I think this is all a little too pedantic for me.

To my eye the difference between a "MUST" and a "SHOULD" is a good
reason.  That is, a "SHOULD" is in fact a "MUST" except when there
is a good reason to do something else.

So, do I have a handy (good) reason why TCP would not take an RTT
sample once per RTT?  No, not really.  So, I think it basically must
do so.

That said, we have done enough work tweaking the TCP RTO to know
that the world would not end if a sample was taken every other RTT
(in fact, this often happens naturally during periods of loss
because of Karn's algorithm).  And, in fact, the RTO performance
would be pretty much the same.  Is that my druthers?  No, not
really.  I'd like to see the once per RTT sampling in TCP.  But, if
someone came to me and said "for efficiency reasons in my lightbulb
TCP implementation I only take an RTT every other RTT" I would
probably shrug and go "seems fine".

Document wording aside: Do you think the once-per-RTT sampling in
TCP is so crucial that if an implementation did not adhere to it
that it would cause big problems (for the network or that
implementation)?

allman

--
https://www.icir.org/mallman/
@mallman_icsi

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Wed, 29 Mar 2017 21:06:37 +0000

The RFC 2119 wording is

SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

I really wonder if there would exist *any* valid reason for a TCP implementation not to measure the FT "regularly". 

The opposite to "regularly" is "not regularly". "not regularly" would e.g. to only measure the FT once during the lifetime of a connection. I cannot really think of particular circumstances where this would make sense in TCP.

For TCP, I think the SHOULD in rto-consider is not the right guidance (let alone that it clearly contradicts RFC 6298). But for UDP the SHOULD is probably appropriate as per RFC 8085. So it seems that I run into an inconsistency between my opinion for TCP and UDP, which in turn causes more formal follow-up issues.

Note that my comment is not about the measurement frequency and the MUST for once-per-RTT in RFC 6298. I would review this wording in a RFC6298bis.

Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Mittwoch, 29. März 2017 22:33
> To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider
> 
> 
> reason.  That is, a "SHOULD" is in fact a "MUST" except when there is a good
> reason to do something else.
> 
> So, do I have a handy (good) reason why TCP would not take an RTT sample
> once per RTT?  No, not really.  So, I think it basically must do so.
> 
> That said, we have done enough work tweaking the TCP RTO to know that
> the world would not end if a sample was taken every other RTT (in fact, this
> often happens naturally during periods of loss because of Karn's algorithm).
> And, in fact, the RTO performance would be pretty much the same.  Is that
> my druthers?  No, not really.  I'd like to see the once per RTT sampling in TCP.
> But, if someone came to me and said "for efficiency reasons in my lightbulb
> TCP implementation I only take an RTT every other RTT" I would probably
> shrug and go "seems fine".
> 
> Document wording aside: Do you think the once-per-RTT sampling in TCP is
> so crucial that if an implementation did not adhere to it that it would cause
> big problems (for the network or that implementation)?
> 
> allman
> 
> 
> --

---

From: Mark Allman <[email-masked]>
Date: Wed, 29 Mar 2017 22:48:21 -0400

>    carefully weighed before choosing a different course.

Right... like I said: the difference between a MUST and a SHOULD is
a good reason.  (At least when we're talking about things that don't
involve interoperability.)

> I really wonder if there would exist *any* valid reason for a TCP
> implementation not to measure the FT "regularly".  
> 
> The opposite to "regularly" is "not regularly". "not regularly"
> would e.g. to only measure the FT once during the lifetime of a
> connection. I cannot really think of particular circumstances
> where this would make sense in TCP. 

Look, that is just another point in the tradeoff space.  We looked
at it in [AP99].  It turns out this sort of "take first" approach
reduces the waiting time for needed retransmissions compared to
6298.  It also follows the fundamental tradeoff and does this at the
expense of increasing spurious retransmissions.  But, that is no
different than many changes one can make---and have been made in
running code (e.g., hacking at the EWMA gains or the variance
multiplier or whatever).  And, the take-first approach is sort of
middling.  It isn't particularly good or bad in either direction.
It certainly isn't ludicrous by any stretch.

Do I think this is a great spot in the tradeoff space?  Not really.
Would I want to say that implementations "MAY take a single RTT
measurement per connection"?  No, not really.  I think RTOs benefit
From taking regular RTT measurements and feeding those into an RTO
estimator.  But, will the world end if they don't?  Nope.  I would
certainly not make some categorical statement like there could never
be any valid reason to do this.  Certainly it'd be a simpler
implementation.  And, maybe for some things that is an over-riding
concern.

But, whether Michael or I or anyone would do this is absolutely
beside the point.  To me the question is whether we think the impact
of doing this is so egregiously bad that we are compelled to say
"never do it" it the strongest possible way.  Maybe Michael has
evidence I haven't seen, but I don't think we're anywhere even close
to that point.

> (let alone that it clearly contradicts RFC 6298)

I think "contradict" is the wrong word here.  It is different to be
sure.  But, the **POINT** of rto-consider is to be different and to
loosen things up.  If it wasn't different than 6298 then there
wouldn't be any point.

If you want things nice and tight then rto-consider probably runs
counter to your thinking for the entire nine pages.

And, if consensus is that we want precise and tight algorithms that
are well specified in formal language but divorced from reality, OK
(which is where we're at now, BTW).  I'll accept that.  I don't
agree with that notion.  But, I've been on the wrong side of
consensus before.  However, that is not at all my read of consensus.

allman

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 Mar 2017 23:33:12 -0700

> On Mar 29, 2017, at 12:44 PM, Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]> wrote:
> 
> So, I wonder if there could be a reasoning for applying these two SHOULD to TCP? Most notably, could there be any reason why a TCP implementation would not measure RTT “regularly”?

Overhead and complexity for small footprint devices. IMO SHOULD is sufficient. MUST needs to be reserved for protocol correctness or behavior truly hazardous to others.

Joe

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Thu, 30 Mar 2017 11:41:36 +0000

Since the context is a small footprint device (IoT and the like…): What happens if the device has a relatively simply TCP stack (no SACK…) and runs on a low-bandwidth shared medium channel (wireless) that has highly variable RTT?

If it measures the RTT once (to reduce complexity) and if that sample happens to be way below the average RTT, it can run repeatedly into spurious timeouts, no? Then the exponential backoff and congestion control kicks in, but if there are many of these devices (sensors…) on the medium, transmitting every message multiple times could be hazardous, no?

I think it comes down to the question if measuring the RTT more than once during a connection is needed for congestion control purposes, or not.

Since there has always been the “must” wording in RFC 793 (and it has been a MUST in rto-consider in many revisions as well), I am not sure if we can downgrade this now to SHOULD, e.g., without experimental data.

I think it is somehow inherently non-trivial to formally apply 2119 language when the statement is not really about protocol correctness and interoperability.

Michael

From: Joe Touch [mailto:[email-masked]]
Sent: Donnerstag, 30. März 2017 08:33
To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>
Cc: [email-masked]
Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider

On Mar 29, 2017, at 12:44 PM, Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]<mailto:[email-masked]>> wrote:
So, I wonder if there could be a reasoning for applying these two SHOULD to TCP? Most notably, could there be any reason why a TCP implementation would not measure RTT “regularly”?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Mar 2017 07:51:53 -0700

It comes down to what "regularly" means, e.g. vs "occasionally" or "more than just once". There is no measurement method that ensures avoiding false reporting except "continuous", could be excessive.

If you have a lot of iot devices and they all measure once, they would only cause a storm on spurious timeouts if they all got it wrong. I think the law of large numbers ought to work in your favor as long as you assume that the rtts measurements don't coincide - I.e., it's useful to decorrelate to avoid synchronization after a power recovery.

The issue of downgrading may drive this, but we should be clear that we don't know that MUST is really required.

Joe

> On Mar 30, 2017, at 4:41 AM, Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]> wrote:
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 30 Mar 2017 23:22:15 +0200

Hi,

(CC'ing the authors of CoCoA [1]...)

Hoping not to deviate too much from the main topic, I just wanted to
explain that in our work with CoCoA (which is used for CoAP over UDP), we
encountered issues in IoT experimental testbeds such as those described by
Michael.

RTT may experience high variance in different types of "typical" IoT
scenarios. Wireless links used in IoT are typically error-prone (due to
radio impairments such as multipath fading, interference, etc.) which may
lead to link layer retries that increase the RTT. Even wired links in IoT,
such as Power Line Communication ones, offer similar performance (for
different reasons).

In mesh networks, which are common in IoT, RTT variability increases.

Furthermore, some traffic patterns in IoT may complicate the scenario. 
Quite often, packet transmission is relatively infrequent. However,
several sensors may simultaneously detect some global event which needs to
be communicated, and a burst of messages will take place as a result
(increasing network load during that interval).

For these reasons, in CoCoA we have an "aging" mechanism for RTO estimates
that have not been updated for a while.

(We even have a 'weak' estimator in addition to a 'strong' estimator,
which may actually help improving the sometimes limited knowledge that a
'strong' estimator may obtain.)

Thanks,

Carles

[1] https://tools.ietf.org/html/draft-ietf-core-cocoa-01

> Since the context is a small footprint device (IoT and the like…): What
> happens if the device has a relatively simply TCP stack (no SACK…) and
> runs on a low-bandwidth shared medium channel (wireless) that has highly
> variable RTT?
>
> If it measures the RTT once (to reduce complexity) and if that sample
> happens to be way below the average RTT, it can run repeatedly into
> spurious timeouts, no? Then the exponential backoff and congestion control
> kicks in, but if there are many of these devices (sensors…) on the
> medium, transmitting every message multiple times could be hazardous, no?
>
> I think it comes down to the question if measuring the RTT more than once
> during a connection is needed for congestion control purposes, or not.
>
> Since there has always been the “must” wording in RFC 793 (and it has
> been a MUST in rto-consider in many revisions as well), I am not sure if
> we can downgrade this now to SHOULD, e.g., without experimental data.
>
> I think it is somehow inherently non-trivial to formally apply 2119
> language when the statement is not really about protocol correctness and
> interoperability.
>
> Michael
>
> On Mar 29, 2017, at 12:44 PM, Scharf, Michael (Nokia - DE/Stuttgart)
> <[email-masked]<mailto:[email-masked]>> wrote:
> So, I wonder if there could be a reasoning for applying these two SHOULD
> to TCP? Most notably, could there be any reason why a TCP implementation
> would not measure RTT “regularly”?
>
> Overhead and complexity for small footprint devices. IMO SHOULD is
> sufficient. MUST needs to be reserved for protocol correctness or behavior
> truly hazardous to others.
>
> Joe
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Fri, 31 Mar 2017 03:08:49 +0000

So Carles,

In many IOT scenarios, it is a "must" to measure RTT "frequently", even more frequent than other scenarios.
Do I get it right?

Thanks,

Emma (Xuesong)

-----Original Message-----
From: tcpm [mailto:[email-masked]] On Behalf Of Carles Gomez Montenegro
Sent: Friday, March 31, 2017 5:22 AM
To: Scharf, Michael (Nokia - DE/Stuttgart)
Cc: [email-masked]; [email-masked]; Joe Touch
Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider

Hi,

Hoping not to deviate too much from the main topic, I just wanted to explain that in our work with CoCoA (which is used for CoAP over UDP), we encountered issues in IoT experimental testbeds such as those described by Michael.

RTT may experience high variance in different types of "typical" IoT scenarios. Wireless links used in IoT are typically error-prone (due to radio impairments such as multipath fading, interference, etc.) which may lead to link layer retries that increase the RTT. Even wired links in IoT, such as Power Line Communication ones, offer similar performance (for different reasons).

Furthermore, some traffic patterns in IoT may complicate the scenario. 
Quite often, packet transmission is relatively infrequent. However, several sensors may simultaneously detect some global event which needs to be communicated, and a burst of messages will take place as a result (increasing network load during that interval).

For these reasons, in CoCoA we have an "aging" mechanism for RTO estimates that have not been updated for a while.

(We even have a 'weak' estimator in addition to a 'strong' estimator, which may actually help improving the sometimes limited knowledge that a 'strong' estimator may obtain.)

Thanks,

Carles

> Since the context is a small footprint device (IoT and the likeâ€¦): 
> What happens if the device has a relatively simply TCP stack (no 
> SACKâ€¦) and runs on a low-bandwidth shared medium channel (wireless) 
> that has highly variable RTT?
>
> spurious timeouts, no? Then the exponential backoff and congestion 
> control kicks in, but if there are many of these devices (sensorsâ€¦) 
> on the medium, transmitting every message multiple times could be hazardous, no?
>
> I think it comes down to the question if measuring the RTT more than 
> once during a connection is needed for congestion control purposes, or not.
>
> Since there has always been the â€œmustâ€ wording in RFC 793 (and it 
> has been a MUST in rto-consider in many revisions as well), I am not 
> sure if we can downgrade this now to SHOULD, e.g., without experimental data.
>
> language when the statement is not really about protocol correctness 
> and interoperability.
>
> Michael
>
> Sent: Donnerstag, 30. MÃ¤rz 2017 08:33
> So, I wonder if there could be a reasoning for applying these two 
> SHOULD to TCP? Most notably, could there be any reason why a TCP 
> implementation would not measure RTT â€œregularlyâ€?
>
> sufficient. MUST needs to be reserved for protocol correctness or 
> behavior truly hazardous to others.
>
> Joe

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Fri, 31 Mar 2017 15:02:30 +0000

For what it is worth, I have doubts that in IoT an RTT measurement has to be performed *more* frequently than mandated by the TCP standards, which require a measurement roughly once per RTT. But I have no data for this.

However, the discussion is whether there could be a reasonable use case for measuring the RTT *less* frequently. Examples for *less* would be to sample once-per-connection, once per minute, once per hour, etc. I have some doubts whether such a low frequency would be robust in the Internet, and I speculate that this violation of the TCP standards might not work well in certain IoT scenarios. I also doubt that there is a need for this even on low-end TCP stacks, since RTT measurement mostly comes for free in TCP. Note that for UDP protocols RTT measurements can be more challenging depending on the protocol design.

The issue is that the current version of the I-D rto-consider allows a lower frequency due to the use of the SHOULD. And this is different to my reading of RFC 793 and the standards-track specification of TCP, i.e., it is not consistent with the TCP standards. I admit that this is sort of the bureaucratic discussion but it matters specifically since we have wording on this in 793bis as well.

Michael

> From: tcpm [mailto:[email-masked]] On Behalf Of Gengxuesong
> (Geng Xuesong)
> Sent: Freitag, 31. März 2017 05:09
> To: Carles Gomez Montenegro <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Hoping not to deviate too much from the main topic, I just wanted to explain
> that in our work with CoCoA (which is used for CoAP over UDP), we
> scenarios. Wireless links used in IoT are typically error-prone (due to radio
> impairments such as multipath fading, interference, etc.) which may lead to
> link layer retries that increase the RTT. Even wired links in IoT, such as Power
> Line Communication ones, offer similar performance (for different reasons).
> 
> Quite often, packet transmission is relatively infrequent. However, several
> sensors may simultaneously detect some global event which needs to be
> communicated, and a burst of messages will take place as a result (increasing
> network load during that interval).
> 
> For these reasons, in CoCoA we have an "aging" mechanism for RTO
> estimates that have not been updated for a while.
> 
> (We even have a 'weak' estimator in addition to a 'strong' estimator, which
> may actually help improving the sometimes limited knowledge that a 'strong'
> estimator may obtain.)
> 
> Thanks,
> 
> Carles
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 Mar 2017 08:17:21 -0700

On 3/31/2017 8:02 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> However, the discussion is whether there could be a reasonable use case for measuring the RTT *less* frequently. Examples for *less* would be to sample once-per-connection, once per minute, once per hour, etc. 

And once per N current round-trips, or even 1/N of a round trip (for
some N, e.g., 2 or 3).

> The issue is that the current version of the I-D rto-consider allows a lower frequency due to the use of the SHOULD. And this is different to my reading of RFC 793 and the standards-track specifica…
793 didn't have 2119 language at all.

It's up to us to interpret what are MAY/MUST/SHOULD from the language
there, even when the language has may/must/should.

I hear the argument that "793 says must, so it needs to be MUST", but
that seems to be a blind decision.

We ought to be making thoughtful ones, including MUSTs only where
necessary. It's clear that RTTs need to be measured "frequently enough",
but it also seems like requiring that to be done for EVERY packet
exchanged is both very high and rarely what a minimal TCP actually does
(esp. given TS support is a MAY anyway).

Joe

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 31 Mar 2017 11:09:27 -0500

Hi all,

just to clarify this point:

> Am 30.03.2017 um 06:41 schrieb Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>:
> 

rto-cosnider does not change/update rfc793. rfc793 is still valid and is simply giving a more constraint specification for one specific protocol which does not contradict each other. (The other way around would but that’s not the case here).

However, maybe it would be good to refer to rfc793 and rfc6298 in rto-consider and make the reader award that these docs make an even strong recommendation for TCP.

Also, given there was a discussion now if the MUST, or actually must, for rfc793 is still appropriate, this is a question for 793bis (and not the rto-cosnider draft).

Mirja

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Fri, 31 Mar 2017 16:27:46 +0000

> been a MUST in rto-consider in many revisions as well), I am not sure if we
> can downgrade this now to SHOULD, e.g., without experimental data.
> 
> rto-cosnider does not change/update rfc793. rfc793 is still valid and is simply
> giving a more constraint specification for one specific protocol which does not
> contradict each other. (The other way around would but that’s not the case
> here).
> 
> However, maybe it would be good to refer to rfc793 and rfc6298 in rto-
> consider and make the reader award that these docs make an even strong
> recommendation for TCP.

This would work for me.
 
> Also, given there was a discussion now if the MUST, or actually must, for
> rfc793 is still appropriate, this is a question for 793bis (and not the rto-
> cosnider draft).

I agree - but we have to start reviewing 793bis anyway.

Michael

---

From: Mark Allman <[email-masked]>
Date: Fri, 31 Mar 2017 12:38:32 -0400

> If it measures the RTT once (to reduce complexity) and if that
> sample happens to be way below the average RTT, it can run
> repeatedly into spurious timeouts, no? Then the exponential
> backoff and congestion control kicks in, but if there are many of
> these devices (sensors…) on the medium, transmitting every message
> multiple times could be hazardous, no?

Harzardous?  No.  IMHO.

First, we have congestion control.  Nobody is suggesting we remove
that.  So, we will not collapse.

Second, if in fact the SHOULD is followed then I doubt the course
you suggest is possible because 2119 says that "the full
implications must be understood and carefully weighed before
choosing a different course".  I doubt there is an incentive for
implementers to create the situation you describe.

Third, let's be clear here ... we're saying an implementation SHOULD
take regular samples.  We are not saying "eh, if ya want" or "it is
not important to take regular samples" or any such thing.  In fact,
the draft explicitly calls out the case you are talking about and
notes that taking a single sample per connection "results in a
relatively poorly performing RTO mechanism".  So, to my mind we are
in fact warning people that they should be pretty careful if they
take this sort of approach.

Fourth, our old work on take-first doesn't suggest it is somehow
completely outrageous.

Fifth, the words in rto-consider say that one SHOULD not only
measure the RTT, but also the variance.  The variance cannot be
measured when we only have one sample, but if one initializes it
reasonably that helps the situation you describe.

There are many places in the tradeoff space that are suboptimal.
There are many ways to view "optimality".  And, there are many
disparate situations.  We know there is no one-size-fits-all.  So,
it seems the question boils down to whether this would in fact cause
a danger to the Internet.  We are a very long ways away from that
point here.  

The way I look at this is that there are two MUSTs [*] in
rto-consider that I would argue are critical and have to be MUSTs.
Those are (a) exponential backoff and (b) taking a timeout as an
indication of congestion and invoking some standard CC (unless we
figure out the loss is not congestion using some standard mechanism,
e.g., F-RTO).  Nothing else rises anywhere close to the level of
importance of these two requirements, IMO.  These are the only two
things that if violated would make me wince and worry a bit.  This
is the general vibe I got from Wednesday's meeting, as well.  That
doesn't mean everything else is unimportant or has no effect or we
shouldn't care about it.  But, it means that if we give some wiggle
room and someone gets it wrong it will not be dangerous.

allman

[*] The other MUST in the document is that the initial RTO MUST be
    at least 1sec.  I think after (a) and (b) above this is probably
    the most important thing so that flows do not start off too
    aggressively and also so they at least get one good RTT sample.
    But, this also isn't all that close to (a) and (b) in my mind
    and I could see making this a SHOULD, as well.  This is all sort
    of shades of grey.  And, I go back and forth on what my druthers
    are for the requirement level of the initial RTO, but what I
    have no doubt about is that it is not nearly as important as the
    other two bits.

---

From: Mark Allman <[email-masked]>
Date: Fri, 31 Mar 2017 12:41:07 -0400

Michael-

> The issue is that the current version of the I-D rto-consider
> allows a lower frequency due to the use of the SHOULD. And this is
> different to my reading of RFC 793 and the standards-track
> specification of TCP, i.e., it is not consistent with the TCP
> standards.

If it wasn't different we'd not need to write a new draft...

But, I completely disagree with your characterization of 793.  You
are torturing the words.  RFC 793 says:

  Because of the variability of the networks that compose an
  internetwork system and the wide range of uses of TCP connections
  the retransmission timeout must be dynamically determined.  One
  procedure for determining a retransmission time out is given here
  as an illustration.

First, the algorithm given is not **the** algorithm, but **an
example**.  It is called out as such.  (And, don't go and quote
793bis chapter and verse on me ... that is an effin' draft and I've
been around the block a few too many times to fall for that sort of
crapola.  We can make that say whatever is appropriate for it to
say.  And, that might be different than what it says at this exact
moment.)

Second, "must be dynamically determined" doesn't say what you claim
it says.  In particular it gives no time frame at all.  Is that
dynamic over the course of a single connection?  Over a day?  An
hour?  An RTT?  Once per connection could well fit in that we are
then not relying on a static timeout, but rather basing the timeout
on the conditions of the network path.  This is in fact dynamic.
So, you're just wrong in saying that 793 somehow says we "must"
sample at any particularly frequency.  Even the **example** given
doesn't say how often samples are taken.

Third, I agree that the wording in 6298 says TCP MUST use that
algorithm.  We can change that sentence.  I.e., to say the algorithm
is one possible algorithm that follows [rto-consider].  Again, the
goal is to **change** things, so this doesn't faze me one little
bit.  It's a sentence.  In a file.  It was not handed down as
etchings on a stone tablet.

> I admit that this is sort of the bureaucratic discussion but it
> matters specifically since we have wording on this in 793bis as
> well.

Yes- it is pedantic and bureaucratic.

I fully understand that documents like rto-consider are quite
unusual for the IETF and they run counter to our collective approach
and sensibilities, which generally favor crisp, formal, tight
specifications.  I have exactly those sensibilities, too.  And, in
fact, can remember writing RFC 2988 and applying some of those
sensibilities at the time when, e.g., Sally Floyd was pushing for a
little looser spec (although not nearly what rto-consider is).

However, I think a sign of a mature organization is the ability to
sometimes look around and decide that we have learned some things
From reality and can in fact let go of tight specs and crisp
formality where it is not required.  I think this in fact gives us
more credibility and makes, e.g., our MUSTs stronger because we are
not slapping them on everything in the name of conservativeness or
just-in-case.  I think a bunch of us think we're at that point with
the RTO.  I completely understand that you are not and completely
sympathize with your instincts and sensibilities.  But, I don't
think consensus is with you here.

allman

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 Mar 2017 09:45:53 -0700

On 3/31/2017 9:38 AM, Mark Allman wrote:
> importance of these two requirements, IMO. 
+1