Subject: [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3)

From: "Black, David" <[email-masked]>
Date: Wed, 15 Jun 2016 23:13:39 +0000

First off, I want to thank Mark for all the work invested in the -04 version of
this draft - in particular, the new scope statements (S.1 - S.6) in Section 2
are important clarifications of what this draft does and what it does not do,
so I'm pleased to see them, thank you.

As Mark noted, there have been some extensive offline conversations.
The purpose of this email is to surface one focal point of those conversations
so that we can get to and record some form of agreement on the public lists.

This concerns (R.3) in Section 2 of the -04:

    (R.3) Alternatively, future RTO mechanism implementations may be
          made directly against the requirements in Section 3 without
          another protocol-specific specification.

The focal point was ensuring that (R.3) does not conflict with (R.1) earlier in
Section 2:

    (R.1) RTO mechanisms that are currently standardized are not updated 
          or obsoleted by this document.  Implementations are free to
          use these existing specifications as they do now.

IMHO, all the participants in the offline discussion agree that the first sentence
of (R.1) is 100% correct as stated (e.g., as this draft does not propose to
update any RFCs).  In 20/20 hindsight, the offline discussion was mostly
about word choice and order in (R.3).

I think (R.3) is ok as is in -04, but it contains a small ambiguity (does "future"
modify "RTO mechanism" or "implementations"?) that would benefit from a
small editorial clarification to make it clear that "future" modifies "RTO
mechanisms":

    (R.3) Alternatively, implementations of future RTO mechanisms may be
          made directly against the requirements in Section 3 without
          another protocol-specific specification.

Thanks, --David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953     Cell: +1 (978) 394-7754
[email-masked]        
----------------------------------------------------

---

From: Mark Allman <[email-masked]>
Date: Thu, 16 Jun 2016 08:07:33 -0400

>           another protocol-specific specification.

I am fine with this wording and have made a note to use it in -05
(modulo any further comments that roll in, of course).

Thanks,
allman

--
http://www.icir.org/mallman/

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 17 Jun 2016 13:41:27 +0200

Hi Mark,

witting as an individual contributor. 

First of all, thanks for the update! I think it reads much better now. There are 2-3 MUST and SHOULD which we could further discuss, but I don’t think that is anything big and I’ll defer this to later.

I have a personal opinion on the point below (R-3). I think this point is just not needed. I say this not because I don’t agree with the statement but spelling this out in an RFC, to me, contradict the point of the RFC. I know this point is important for you but let me further explain. 

To me I don’t have a problem if people do implement something that is not standard conform. Especially in transport where there are a lot of things that don’t have interoperability problem, to me this is fully okay. Sometimes we in the IETF even pick up existing implementation and document them as informational, because we believe the implementation is good and having a stable reference will help others to do the right thing. 

However, when we make a recommend I think we should be clear. This is especially helpful for implementators who do not really have a good reason to do something different and just look for a general recommendation. 

Further I have to note that we do use the word SHOULD in cases where we know that there are good reason to deviate from the proposed recommendation. In such a case you could still claim to be standard conform (for what it is worth) even when you don’t follow the SHOULD.

However basically saying whatever you do is confirm with this specification, to me really contradicts the point of making a recommendation.

It’s simple if you follow all MUSTs and SHOULDs if case you don’t have a good reason to do something else, you are conform to the RFC, and otherwise you are simply not conform. That doesn’t say that you always when you implement something have to follow RFCs. That’s non-sense. Implementors are free to do what they want and we can’t stop them; we can only give reasonable recommendations.

My 2c...

Mirja

> Am 16.06.2016 um 14:07 schrieb Mark Allman <[email-masked]>:
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Mark Allman <[email-masked]>
Date: Fri, 17 Jun 2016 09:22:07 -0400

> I have a personal opinion on the point below (R-3). I think this
> point is just not needed. I say this not because I don’t agree
> with the statement but spelling this out in an RFC, to me,
> contradict the point of the RFC.

On the one hand, I can understand that opinion.  Why would we write
the RFC if we weren't going to allow these things and so why do we
have to say this?  And, if people think this is unnecessary I am
happy to nuke it.

However, let me sketch the lay of the land as I see it ....   It
seems the meat in this document can be used for different purposes.
And, we have seen opinions on each of these I think.  The document
could be used:

  (a) as input to future RTO specifications,

  (b) as input to future RTO implementations, or

  (c) as both (a) and (b)

My take is (c).  And, so (R.2) is meant to cover case (a), while
(R.3) is meant to cover case (b).

So, while I can see your point about not needing to say something
obvious, I am worried that eliding (R.3) will leave us in one of two
places:

  - In case (a) above.  I.e., because (R.2) discusses only
    specifications and not implementations and so a natural reading
    may well be that this document is meant to only help future
    standardization efforts.

  - Or, in some ambiguous state where clearly (a) holds (via (R.2)),
    but it is not explicit that this covers implementations, too,
    even if we think that it does since the text does not explicitly
    say that.  And, so we end up with confusion.

Does that make sense?  Am I worrying too much about explicitly
including implementations?

allman

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 17 Jun 2016 16:03:27 +0200

Again, my personal view is that the statement is not needed, and I find it rather confusing that helpful. Based my (limited) experience in (Linux) implementors community I would like to add that even though they are often not very active on ietf mailing lists and might not follow the RFC in their implementation, they still read the draft. So simply focusing on the actual recommendation in the doc (and the needed statements how this doc related to other docs in the RFC series) is sufficient for me and more clear.

Mirja

> Am 17.06.2016 um 15:22 schrieb Mark Allman <[email-masked]>:
> 
>

---

From: Mark Allman <[email-masked]>
Date: Fri, 17 Jun 2016 10:13:52 -0400

I am mulling this.  But, a question...

> So simply focusing on the actual recommendation in the doc (and
> the needed statements how this doc related to other docs in the
> RFC series) is sufficient for me and more clear.

I guess this is counter-intuitive to me as usually implicitness is a
less direct path to clarity than explicitness.

So, would you also then get rid of (R.2)?  So, we use (R.1) to state
how the doc relates to existing specs and then say nothing about the
future (about either specs or implementations).  To me that is at
least a more consistent path than retaining (R.2) and removing
(R.3).

But, I am still mulling ...

Thanks,
allman

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 17 Jun 2016 16:21:48 +0200

I find R-2 less problematic/confusing but also probably not needed. Especially seeing the SHOULD in there seems slightly weird to me. To me the better approach would be to simply use SHOULDs instead of (most of the) MUSTs in the latter text in the doc; and potentially add more text there that the SHOULD is a really strong SHOULD and there must be a good reason to deviate.

Mirja

> Am 17.06.2016 um 16:13 schrieb Mark Allman <[email-masked]>:
> 
>

---

From: Mark Allman <[email-masked]>
Date: Fri, 17 Jun 2016 13:09:04 -0400

I like to re-state things to see if I understand what is being
said.  So, let me see if I understand what you're suggesting (in
high level terms).

(This is about the RTO document in specific, but more broadly would
seem applicable to single-host algorithm specifications.)

You are starting from the fact that implementers are not beholden to
the RFCs in any tangible way.  And, also the fact that we don't have
any real recourse when the standards are not followed.  So, since
they don't feel constrained by the RFCs, we should approach RFCs in
the same way and not worry about constraints as much as giving our
best recommendations.  We hope our strong recommendations are
listened to and used.  But, if they are not, they are not and there
isn't anything we can do about them regardless of what we say people
"MUST" do.  I.e., the standards process should meet the implementers
where they are.

Is that roughly correct?

(In the above I mean to have no opinion, just trying to understand
your hit.  I may subsequently have an opinion and if I can somehow
get over my usual shyness I might then say it. :) )

allman

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 17 Jun 2016 18:27:35 +0000

With chair hat off...

> Again, my personal view is that the statement is not needed, and I find it rather confusing that helpful. Based my (limited) experience in (Linux) implementors community I would like to add that ev…

+1 on removing (R.3)

I do NOT support the current language in (R.3), as well as related wording on "implementations" elsewhere in the document.
 
For TCP, I am confused by how this wording relates to RFC 6298. For TCP, I fully agree that allowing more flexibility compared to RFC 6298 would be useful, and a new RFC 6298bis could reference a BCP draft-ietf-tcpm-rto-consider. However, I believe that guidance for TCP implementers belongs into a standards track document RFC 6298bis. The document draft-ietf-tcpm-rto-consider should focus on a set of requirements only. 

Sorry, I should have commented on that prior to working group adoption but I have focuses so far on the actual wording of the requirements, which are not really controversial (but see the note below).

I would add that I have some doubts on the MUST for exponential backoff but I have to further think about this. I personally believe that a retransmission timeout that only backs off after some attempts would also be reasonably safe. Also, a timer that would exponentially back off every second attempt would also work IMHO. I think the current MUST that disallows this is slightly too restrictive but I could not come up with something better today.

Please find below my review for -04, my comments are listed with [ms] below. I have provided alternative wording for most cases to avoid ambiguity.

Thanks

Michael

***** review of -04 *****

* Title

 "Retransmission Timeout Requirements"

[ms] I am fine with the new title.

* Abstract

[ms] OLD

    Ensuring reliable communication often manifests in a timeout and
    retry mechanism.  Each implementation of a retransmission timeout
    mechanism represents a balance between correctness and timeliness
    and therefore no implementation suits all situations.  This document
    provides high-level requirements for retransmission timeout schemes
    appropriate for general use in the Internet.  Within the
    requirements, implementations have latitude to define particulars
    that best address each situation.

[ms] NEW

    Ensuring reliable communication often manifests in a timeout and
    retry mechanism.  Each retransmission timeout mechanism represents
    a balance between correctness and timeliness. This document
    provides high-level requirements for retransmission timeout schemes
    appropriate for general use in the Internet.

* Section 1   Introduction

[ms] OLD

    The intent is to provide a safe
    foundation on which implementations have the flexibility to
    instantiate mechanisms that best realize their specific goals.

[ms] NEW

    The intent is to provide a foundation of requirements for retransmission
    timeout mechanisms that are considered safe for the global Internet.

* Section 2   Scope    
    
[ms] While somehow implicitly clear from the earlier use of the wording "global Internet", I believe that should be made more explicit in Section 2. Note that IETF protocols are used not only in the global Internet. This can be (S.0) or (S.7).

    (S.7) The requirements focus on communication over the global Internet.
          Retransmission timeout mechanisms in controlled environments separated
	    from the global Internet are outside the scope of this document.

          E.g., this document does address retransmission timers used in controlled
          environments such as nuclear power plants, airplanes, fabric automation,
          etc. This document does not address retransmission timers in real-time
          communication protocols for such environments.

[ms] OLD

    Additionally, the following statements detail the relationship of
    the requirements in this document to other specifications and
    implementations:

          This holds even in cases where the existing specification
          differs from the requirements in this document (e.g.,
          [RFC3261] uses a smaller initial timeout than this document
          specifies).  Existing standard specifications enjoy their own
          consensus which this document does not change.
    
    (R.2) Future standardization efforts that specify RTO mechanisms 
          SHOULD follow the requirements in this document.
          There may be reasons for future RTO mechanisms to deviate from
          the requirements in Section 3.  In these cases, we expect only
          that the standards process does so after reasonable
          deliberation and with good reason.

    (R.4) There will no doubt be cases where applying the requirements
          in this document directly is not possible due to the structure
          or operation of a protocol.  For instance, a case where a
          timeout is used to detect loss, but the loss is not repaired
          with a direct retransmission of the original data.  In these
          situations, an alternate specification is required.  We
          encourage such future efforts to leverage the spirit of the 
          requirements in this document to inform alternate
          specifications. 

[ms] NEW

    Additionally, the following statements detail the relationship of
    the requirements in this document to other specifications:

    (R.1) RTO mechanisms that are currently standardized are not updated 
          or obsoleted by this document.

          This holds even in cases where the existing specification
          differs from the requirements in this document (e.g.,
          [RFC3261] uses a smaller initial timeout than this document
          specifies).  Existing standard specifications enjoy their own
          consensus which this document does not change.
    
    (R.2) Future standardization efforts that specify RTO mechanisms 
          SHOULD follow the requirements in this document.
          There may be reasons for future RTO mechanisms to deviate from
          the requirements in Section 3.  In these cases, we expect only
          that the standards process does so after reasonable
          deliberation and with good reason.

    (R.3) There will no doubt be cases where applying the requirements
          in this document directly is not possible due to the structure
          or operation of a protocol.  For instance, a case where a
          timeout is used to detect loss, but the loss is not repaired
          with a direct retransmission of the original data.  In these
          situations, an alternate specification is required.  We
          encourage such future efforts to leverage the spirit of the 
          requirements in this document to inform alternate
          specifications.

[ms] ... albeit I think even more of this could be removed

* Section 4   Discussion

[ms] OLD

    Finally, we note that while allowing implementations to be more
    aggressive may in fact increase the number of needless
    retransmissions the above requirements fail safe in that they insist
    on exponential backoff of the RTO and a transmission rate reduction.
    Therefore, providing implementers more latitude than they have
    traditionally been given in IETF specifications of RTO mechanisms
    does not somehow open the flood gates to aggressive behavior.  Since
    there is a downside to being aggressive the incentives for proper
    behavior are retained in the mechanism.

[ms] NEW 

    The above requirements are safe from a network perspective in that they insist
    on exponential backoff of the RTO and a transmission rate reduction.

* Section 5 Security Considerations

[ms] This section is IMHO too short and a reference just to TCP is not sufficient for a protocol that shall be protocol-agnostic. I cannot provide better wording out-of-my-head but here are a couple of topics that have to be covered in this section:

(1) A discussion of the security implications if retransmission timeout mechanisms deviate from standardized retransmission mechanisms. For instance, not complying to protocol standards could trigger anomaly detection systems or this could be classified as an attack.

(2) A discussion that operational "safety" in controlled environments separated from the global Internet, such as nuclear power plants, airplanes, fabric automation, is not addressed by this document.

(3) A discussion whether retransmission timeout mechanisms, or deviations of them, can be used for finger-printing. (This may be very exotic but if an implementation uses a very unique initial RTO that could have pricacy implications.)

(4) ... possibly more, we may need input from security experts

***** review of -04 *****

---

From: Mark Allman <[email-masked]>
Date: Fri, 17 Jun 2016 14:59:59 -0400

Just one quick one that is easy to answer ...

> For TCP, I am confused by how this wording relates to RFC
> 6298.

This document does nothing to RFC6298.  I.e.,

That is, RFC6298 remains as it is now.  Implementers are free to use
the algorithm as it sits in RFC6298.

> For TCP, I fully agree that allowing more flexibility compared to
> RFC 6298 would be useful, and a new RFC 6298bis could reference a
> BCP draft-ietf-tcpm-rto-consider. However, I believe that guidance
> for TCP implementers belongs into a standards track document RFC
> 6298bis. The document draft-ietf-tcpm-rto-consider should focus on
> a set of requirements only.

I am not sure what you mean here.

So, we'd use rto-consider as a set of requirements.  And, then we'd
generate a 6298bis that is less specific than 6298.  So, e.g.,
instead of providing equations like this:

            RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'|
            SRTT <- (1 - alpha) * SRTT + alpha * R'
            RTO <- SRTT + max (G, K*RTTVAR)

and their corresponding parameter values, we'd just fall back to
some generic language like "use RTT samples and the variance of RTT
samples per [rto-consider] to compute an RTO"?  So, the document is
then a fuzzy re-statement of the [rto-consider] requirements instead
of a specific algorithm.

Something like that?

Or, do you just want a 6298bis that includes a statement at the top
that says "this algorithm follows the requirements in
[rto-consider]"?

Or, something else?  I can't envision how you view this as working. 

allman

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 17 Jun 2016 19:11:56 +0000

> > For TCP, I fully agree that allowing more flexibility compared to RFC 
> > 6298 would be useful, and a new RFC 6298bis could reference a BCP 
> > draft-ietf-tcpm-rto-consider. However, I believe that guidance for TCP 
> > implementers belongs into a standards track document RFC 6298bis. The 
> > document draft-ietf-tcpm-rto-consider should focus on a set of 
> > requirements only.

> I am not sure what you mean here.

6298bis would have a new (first) section with a MUST that applies the guidelines in [rto-consider] specifically to the TCP protocol, mandating that all TCP implementations MUST use retransmission timeout mechanisms matching this minimum set of requirements. This is relatively straightforward given that [rto-consider] is rather TCP-ish already. But for a number of requirements the actual TCP terminology and technology could be used.

And then the document would recommend with a MAY (or SHOULD) the algorithm in 6298 as default.

And I believe that such a proposed standard for TCP would be closer to what implementations actually do. 

(And I believe for SCTP it would also be a no-brainer to come up with something in TSVWG, but the SCTP experts would have comment on that.)

Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 17 Jun 2016 21:41:01 +0200

Hi Mark,

> Am 17.06.2016 um 19:09 schrieb Mark Allman <[email-masked]>:
> 

Roughly yes. I wouldn’t use the wording "implementers are not beholden to
the RFCs in any tangible way“ but anyway...

Even though your statement was scoped to single-host algos, I don’t want to let this stand in the room like this. Let me add a few things (that are more general and probably not important for the discussion on rto though). 

First, this is slightly different if interoperability is required. But even in this case, we can’t control what implementors are doing. However, I would say there is a natural incentive in this case to follow the spec because other it just won’t work. 

Then I would also like to say that the consequence of this thinking is not that RFCs are useless as anyway nobody will follow anyway. I know that is not was you were saying or thinking I assume. I just want to clearly state that there is an important role for RFCs to make recommendation; as I said implementors read RFC (even if they don’t follow).

And finally, the other important aspect is that this liberal approach in the Internet, where we of course depend to a certain extend on other people doing things right/not too wrong, is that enables innovation in the Internet and make the Internet to this great thing we have today. E.g if someone invents a complete new service that uses the Internet that might not fit our current recommendation. So this freedom is needed and deliberate.

With this more philosophical statement, I guess the only this that is left to say is:

Have a good weekend!
Mirja

---

From: Mark Allman <[email-masked]>
Date: Fri, 17 Jun 2016 15:50:18 -0400

> 6298bis would have a new (first) section with a MUST that applies
> the guidelines in [rto-consider] specifically to the TCP protocol,
> mandating that all TCP implementations MUST use retransmission
> timeout mechanisms matching this minimum set of requirements. This
> is relatively straightforward given that [rto-consider] is rather
> TCP-ish already. But for a number of requirements the actual TCP
> terminology and technology could be used. 
> 
> And I believe that such a proposed standard for TCP would be
> closer to what implementations actually do.  

We have been around this before, but for the public record ...

To me this is a bunch of work for, perhaps, epsilon gain.  We state
some high level requirements.  But, then we have to re-state the
high-level requirements after prepending a protocol name and only
then can an implementation can actually leverage the requirements.
Perhaps that forms a nice clean document progression.  But, man,
what a bunch of busy work that has no value add...

Rather, I think this document can be directly applied to both future
specifications and future implementations.  I don't yet have a
well-formed hit on whether we should directly state that in some
fashion (as the doc---perhaps clumsily---tries to do now) or leave
the requirements as our best thinking to be implicitly applied
however folks see fit (my understanding of Mirja's hit).

allman

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 17 Jun 2016 20:00:29 +0000

> And, we have seen opinions on each of these I think.  The document could be used:
>

In case there was any ambiguity: 

I do NOT support (b) or (c).

Specifically, I do not understand how [rto-consider] can foresee the requirements of future protocols not standardized by the IETF right now. The Internet is subject to permanent change. I conclude that the requirements outlined in this document cannot be considered "safe" for implementations of protocols in future, unknown environments.

The analysis what is "safe" has to be done on a per protocol basis, within the standardization process of that protocol, taking [rto-consider] as one input regarding the requirements in the global Internet at the time when the document was published.

Michael (with chair hat off)

---

From: Mark Allman <[email-masked]>
Date: Fri, 17 Jun 2016 16:16:06 -0400

> Roughly yes.

OK.  Then, I am going to mull this approach.  I view three things on
the table:

  - Mirja's approach: State the recommendations, but not explicitly
    what they apply to and as SHOULDs rather than MUSTs and then let
    people use them as they find useful.

  - Michael's approach: The requirements exist only to guide future
    specs.  And, implementations are explicitly not to leverage
    these directly.

  - Mark's approach: Somewhere in the middle, I guess.  State the
    recommendations, but also explicitly that they are for both
    future specs and future implementations.  (Clearly closer to
    Mirja and Michael.)

I am still thinking.  Others can chime in.  But, only if your name
starts with "M"... because naming conventions are important.

> First, this is slightly different if interoperability is
> required. But even in this case, we can’t control what
> implementors are doing. However, I would say there is a natural
> incentive in this case to follow the spec because other it just
> won’t work.  

(Yep.  This is why I scoped!)

> Then I would also like to say that the consequence of this
> thinking is not that RFCs are useless as anyway nobody will follow
> anyway. I know that is not was you were saying or thinking I
> assume. I just want to clearly state that there is an important
> role for RFCs to make recommendation; as I said implementors read
> RFC (even if they don’t follow).

Well, OK.  I understand what you're saying.

But, what I am struggling with here is that if we make some MUSTs
then we get a little something in return.  That sets an expectation.
And, if the FooBar implementation doesn't follow that expectation
and it causes problems then there is a lever to say "well, gee, we
said you needed to do something and you didn't".  FooBar does not
have to listen.  We cannot make them do something different.  But,
we get a little lever.  So, the question in my mind is whether we
get the same sort of leverage with your looser notion of "just state
the requirements" and "use SHOULDs".  And, I am thinking not.  I.e.,
we didn't say "do this" we said "do this unless you have a good
reason" and FooBar might think they have a good reason (e.g., "helps
my customers, so sorry about your's!").  We can still try to say
"well, we strongly recommended ...", but we're in a bit lesser
position.

The thing I am trying to form an opinion on is "how much lesser".
I.e., I have sort of convinced myself stronger statements are
better.  But, it might be that they are only epsilon better and so
ultimately it doesn't much matter.

Thanks,
allman

---

From: Mark Allman <[email-masked]>
Date: Fri, 17 Jun 2016 16:18:22 -0400

Applying "the future will be different" stops all work.  Period.

allman

> Specifically, I do not understand how [rto-consider] can foresee
> the requirements of future protocols not standardized by the IETF
> right now. The Internet is subject to permanent change. I conclude
> that the requirements outlined in this document cannot be
> considered "safe" for implementations of protocols in future,
> unknown environments. 
> 
> The analysis what is "safe" has to be done on a per protocol
> basis, within the standardization process of that protocol, taking
> [rto-consider] as one input regarding the requirements in the
> global Internet at the time when the document was published. 
>

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 17 Jun 2016 23:07:56 +0000

> then can an implementation can actually leverage the requirements.

Implementers can read the requirements in rto-consider right now.

What implementers cannot leverage right now is a statement about IETF consensus that for any protocol standardized in the IETF, any RTO algorithm, in all circumstances is always "safe" when it meets the requirements under the constraints stated in the document. And specifically implementers of protocols other than TCP cannot rely on that because a document first has to pass IETF last call and IESG approval before the IETF can state that the guidance it is indeed "best current practice".

> what a bunch of busy work that has no value add...

If [rto-consider] is IETF consensus, IMHO a 6298bis document would be a no-brainer in TCPM. Maybe I miss something, but that would be a candidate for a WGLC directly on the -00 version, given that we already review [rto-consider]. One added value of 6298bis is that it applies the generic wording in [rto-consider] specifically to the TCP. I believe that this is simpler to read for a TCP implementer than to reverse-engineer protocol-agnostic wording in a draft that gets longer and longer to be protocol-agnostic (and likely will have to be further extended when it hits IETF last call)? And, as a side note, my formal concerns would be addressed, since TCPM would have a document we can e.g. proceed on standards track.

So is your concern that nobody would invest cycles to author a 6298bis in TCPM? Or something equivalent e.g. for SCTP?

In summary, can we agree that if somebody volunteers to submit 6298bis, which references [rto-consider], my proposed wording for [rto-consider] actually has some gain ("epsilon" or more). Thus, in summary my proposal just sorts out everything in TCPM? Or what is then missing in TCPM?

Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Sat, 18 Jun 2016 01:25:41 +0200

Hi Mark,

just on this one point and then I go to sleep…

> Am 17.06.2016 um 22:16 schrieb Mark Allman <[email-masked]>:
> 

So SHOULD is the right usage here, because what you actually want to say is, do it expect you have a good reason. Yes, not everybody knows how to understand SHOULD correctly and there are even different opinion in the IETF. And what a good reason is, is even harder to define. So from my point the only practical solution is not using MUST but providing as much explanation as possible on when the SHOULD might not need to be follow and when it clearly should be followed. That’s often also not easy, I know. But that's the only way to make your point, also for people who are maybe less familiar with the language used in RFCs. Btw. there is no requirement to use this normative language. Actually this is only meant to help people understanding a document and its requirements more quickly. But effectively the message should still be clear even if the normative, upper-letter notation is ignored.

Mirja

---

From: Mark Allman <[email-masked]>
Date: Mon, 20 Jun 2016 10:44:56 -0400

> If [rto-consider] is IETF consensus, IMHO a 6298bis document would
> be a no-brainer in TCPM.

But, it isn't necessary.  RFC 6298 is a document about *one*
algorithm.  We could invent parallel algorithms.  And, write an RFC
that specifies each.  RFC 6298 just happens to be the only RTO we
have taken the bother to develop and write up.  So, RFC 6298 (or a
bis) doesn't have to convey all of our TCP RTO understanding.  It is
just one algorithm for doing it.

So, yeah, we can write a preamble to RFC 6298 that says "this agrees
with [rto-consider]", but that doesn't change the algorithm.  It
isn't a technical change at all.  It is more words in service of
what?  A tidy---by some definition---document progression is all I
can come up with.  It doesn't advance things in any meaningful way.

> One added value of 6298bis is that it applies the
> generic wording in [rto-consider] specifically to the TCP. I
> believe that this is simpler to read for a TCP implementer than to
> reverse-engineer protocol-agnostic wording in a draft that gets
> longer and longer to be protocol-agnostic (and likely will have to
> be further extended when it hits IETF last call)?

The whole thing hasn't really gotten much longer.  And, it is still
quite short.  And, I don't think that someone steeped in TCP will
have a difficult time reading the generic form of the requirements
there now.  These are not particularly foreign concepts we're
talking about.

> So is your concern that nobody would invest cycles to author a
> 6298bis in TCPM? Or something equivalent e.g. for SCTP? 

My concern is for doing work that just doesn't need to be done.  How
many times do you want to re-state the same thing?  TCP, SCTP.  What
about UDP?  I doubt you'll find the notions in 5405bis to be quite
right because they apply the rto-consider requirements to all
UDP-based protocols.  And, so, I think all the same arguments you're
making now would have to be applied there, too, and so we'll have to
go and write N more of these things for N UDP-based apps.  That's
saying the same thing a lot.  And, God forbid if we ever had to
change something...

The point is that except for document series tidiness I have seen no
reason to make these requirements only apply to future specs---and
not implementations---as you advocate.

allman

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 20 Jun 2016 15:29:49 +0000

> > If [rto-consider] is IETF consensus, IMHO a 6298bis document would be 
> > a no-brainer in TCPM.

> But, it isn't necessary.  RFC 6298 is a document about *one* algorithm.

This is not how I read RFC 6298. It already has a MUST in the abstract:

   This document defines the standard algorithm that Transmission
   Control Protocol (TCP) senders are required to use to compute and
   manage their retransmission timer.  It expands on the discussion in
   Section 4.2.3.1 of RFC 1122 and upgrades the requirement of
   supporting the algorithm from a SHOULD to a MUST.  This document
   obsoletes RFC 2988.

RFC 6298 does mention that other algorithms could exist, with the following wording:

   In some situations, it may be beneficial for a TCP sender to be more
   conservative than the algorithms detailed in this document allow.
   However, a TCP MUST NOT be more aggressive than the following
   algorithms allow.  This document obsoletes RFC 2988 [PA00].

But RFC 6298 does not have the notion of *one* algorithm.

So, in my reading, [rto-consider] contradicts quite explicitly the standards track specification of TCP. What do I miss here?

In my view RFC 6298 needs to be updated if TCPM believes that a TCP implementation fully compliant to IETF standards should be allowed to have other algorithms.

As mentioned already, I would support publishing a 6298bis for that purpose. I believe that it is important that TCPM standards track documents are (1) consistent and (2) well aligned with the major TCP implementations.

The following to me is a very straightforward and clean approach:

* [rto-consider] provides the general protocol-agnostic requirements, as specified in the wording of my review

* 5405bis applies it to UDP

* 6298bis applies it TCP and cleanly updates 6298 on standards track

* SCTP should be a low-hanging fruit as well

* Other protocols owned by other working groups have to review [rto-consider] and come to an own consensus anyway

And, possibly even more importantly, reading protocol-specific guidance should typically also be simpler for implementers since they don't have to guess how to apply generic wording to the specific protocol semantics.

In short, I am not aware of any relevant downside of that very clean approach.

Michael

---

From: "Black, David" <[email-masked]>
Date: Mon, 20 Jun 2016 16:30:16 +0000

Addressing solely this UDP item ...

>  What about UDP?  I doubt you'll find the notions in 5405bis to be quite
> UDP-based protocols.

The desired structure here (IMHO) is that the TCPM rto-consider draft
states the general principles, and the TSVWG rfc5405bis draft applies them
to UDP.  Then individual UDP-based protocol drafts are expected to follow
the guidance in rfc5405bis, or explain why there are good reasons for
doing otherwise.

> And, so, I think all the same arguments you're
> go and write N more of these things for N UDP-based apps.  

Not exactly - any UDP-based protocol RFC-to-be is going to have to
reference rfc5405bis, as I'd expect the TSV ADs to Discuss drafts that
don't ;-).  The resulting RTO considerations will show up in each main
protocol draft, not a small separate stand-alone draft.

In practice, we'll probably see more cross-area interaction to head off
this class of issue before it hits the IESG.  FWIW, draft-ietf-forces-interfelfb
is a recently-worked example in the area of congestion considerations,
and I do want to thank the responsible RTG AD (Alia) for noticing that
the congestion concerns could use a bit more attention, and encouraging
the draft authors to address them in advance of the draft going to the IESG.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Mark Allman
> Sent: Monday, June 20, 2016 10:45 AM
> To: Scharf, Michael (Nokia - DE)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3)
> 
>

---

From: Mark Allman <[email-masked]>
Date: Mon, 20 Jun 2016 12:54:02 -0400

> So, in my reading, [rto-consider] contradicts quite explicitly the
> standards track specification of TCP. What do I miss here? 

"Contradict" ... maybe.  In the strict sense of the word.  What it
says is that we have learned things and figured out that only a
subset of 6298 is necessary for network safety and so we can offer
flexibility in the areas that are not as important for network
safety.  But, it doesn't alter or call into question the algorithm
in 6298 and folks can readily use it as they always have.  But,
deviation from the precise details is also in some cases quite fine,
as well.

The usual thing we do is to learn and update things.  We increase
the initial cwnd recommendation (which obsoletes the previous
recommendation).  Or, we refine SACK-based loss recovery (which
obsoletes the old scheme with new thinking).  Or, whatnot.  But, in
this case we are saying simultaneously that (a) we can relax on the
details and (b) the details of this one existing spec are still
valid and fine.  This is different than our Usual Case, I think.
But, since we are not taking something and making it different or
better this is not the Usual Case.  We are saying is we have
learned:

  - that there are a class of specific RTO mechanisms that are safe
    and fine,

  - that there is no one-size-fits-all in the class and 

  - that the class includes the old thing so we cannot simply
    replace it

Instead of honing our view or changing our view we are broadening
our view.  And, this is (I guess) difficult.

On the rest, I could reply.  But, we know where each other stands at
this point and you and I don't need to continue to circle.  We
simply disagree.

allman

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 25 Jun 2016 15:06:59 +0100

https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-04

I have previously made many comments on the text in rev-03 of this 
draft, and after a careful read, I'd like to now note that in large 
part, rev -04 addresses my concerns regarding scope and applicability.

There still appears to be a global scope for the document as “ SHOULD” 
in (R.2), and then a nested “MUST” within that “SHOULD”. I see others 
have also noted this, but I'd prefer an AD or someone with more insight 
into RFC2119 to decide on this.

Likewise, I understand TCPM needs to decide upon the set of requirements 
for TCP, and TSVWG for SCTP and UDP.

That said, I'd thank Mark for his heavy work to make this more 
applicable. A small number of comments follow.

Gorry

--- Comments on draft-ietf-tcpm-rto-consider-04

Section 1.

This sentence is rather cumbersome to read:
OLD:
However, despite our best intentions and most robust mechanisms, the 
only thing we can truly depend on is the passage of time and therefore 
our ultimate backstop to ensuring reliability is a timeout and re-try 
mechanism.

Is it worth considering reordering the thoughts, say:
NEW:
However, despite our best intentions and most robust mechanisms, the 
ultimate backstop to ensuring reliability is a timeout and re-try 
mechanism, because the only thing we can truly depend on is the passage 
of time.
—
/a for/
OLD:
protocol-agnostic requirements for RTO mechanisms that provide a for 
network safety.
NEW:
OLD:
protocol-agnostic requirements for RTO mechanisms that provide network 
safety.
——
Section 2:
NiT: Is it worth replacing “must” with needs to, or deciding this 
actually is a requirement and then using RFC2119 MUST. I’d be happy 
either way, but don’t think “MUST” fits in this section either.
OLD:
independently. I.e., if host A communicates with hosts B and C, A must 
use independent RTOs for traffic sent to B and C.
NEW:
independently. I.e., if host A communicates with hosts B and C, A needs 
to use independent RTOs for traffic sent to B and C.
—
OLD:
"like UDP-based DNS []"
- missing reference.
---
OLD:
than the 1 second specified in [RFC6298]. While the implication of
these deviations from the standard may be more spurious retransmits
(per [AP99]), we are aware of no large scale problems caused by this
change to the minimum RTO.”

- I do not see the wisdom in the last clause. As an example there have 
been issues (albeit a time ago with a RTO less than 1 second being the 
default - I think in,one version of Solaris) that resulted in TCP having 
much degraded throughput over paths with a RTT greater than the RTO. A 
small initial RTO may still be a problem (e.g., when traffic after a 
failure is routed over a backup path), and I suggest this is not a case 
we should advocate. Indeed, this ID currently makes a requirement that: 
"RTO MUST be conservatively set to no less than 1 second”, which to me 
seems a correct interpretation of the RFC-series, so why does the 
sentence above appear to suggest otherwise?
---

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Sun, 26 Jun 2016 16:51:48 +0200

For the fellows not constantly following the Linux kernel maillinglist: we are
currently try to adjust Linux's TCP RTO behavior to implement a RFC 6298
compliant calculation[1]:

	https://www.mail-archive.com/[email-masked]/msg114487.html

We wrote an small document where we highlighted the current Linux
implementation, validated our 6298 compliant implementation and presented
measurements comparing both mechanisms:

	https://docs.google.com/document/d/1pKmPfnQb6fDK4qpiNVkN8cQyGE4wYDZukcuZfR-BnnM

Yuchung tested the modification in large scale at Googles web servers (HTTP,
HTTP2) and first results looks promising:

	https://www.mail-archive.com/[email-masked]/msg116052.html

Hagen

[1] some aspects of Linux differs too much to implement a 100% compliant RFC
6298 mechanism - especially the MinRTO definition differs.