Subject: [tcpm] Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 7 Apr 2016 09:55:23 +0000

I have read -02 and I have run into an issue with the new text therein. 

I think we should ensure that the content of this document is applicable to protocols that run over the Internet but that are not standardized by the IETF. For instance, UDP-based gaming protocols would come into my mind.

I think the current wording in -02 is overly restrictive:

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

I think it is sufficient to have a mechanism to detect non-congestion events. To me, it does not matter whether this mechanism is standardized by the IETF. The standardization may not even be possible if that mechanism is tightly tied into a non-IETF protocol. Also, "standardization" seems to exclude informational/experimental RFCs and I am not sure if I agree that they should be excluded here.

The following wording also seems to implicitly assume that IETF standards are used as basis of a protocol:

    A non-goal of this document is to in any way specify individual
    deviations from current IETF standardized RTO specifications that
    any particular implementation may exhibit.  Rather, we provide a set
    of over-arching guidelines that all RTO mechanisms should follow.

This wording makes sense for TCP. But, again, I'd prefer a wording that applies to all protocols running over the Internet no matter whether the protocol mechanics use IETF standards as basis, or not.

Michael (with chair hat off)

---

From: Mark Allman <[email-masked]>
Date: Thu, 07 Apr 2016 09:10:06 -0400

Hi Michael!

I am having a difficult time understanding these points.  My high
order bits ...

  - This is an effort within the standards process and so setting it
    in that context seems fine to me.

  - The guidelines certainly could apply to protocols outside the
    IETF's purview and I'd be fine with others using them (and in
    fact would hope they would).  However, that to me doesn't
    suggest we loosen the language.

>         a non-congestion event (e.g., packet corruption).

Let's be clear: This document does not change the state of things.
For context, the whole guideline you snipped from is:

    (4) Retransmission timeouts MUST be taken as indications of
        congestion in the network and the sending rate adapted using a
        standard mechanism (e.g., TCP collapses the congestion window to
        one segment [RFC5681]).

        This ensures network safety.

        An exception is made to this rule if an IETF standardized
        mechanism is used to determine that a particular loss is due to
        a non-congestion event (e.g., packet corruption).  In such a
        case a congestion control action is not required.  Additionally,
        RTO-triggered congestion control actions may be reversed when a
        standard mechanism determines that the cause of the loss was not
        congestion after all.

Guideline (4) says nothing new.  I.e., the state of the standards is:

  (a) loss is assumed to indicate congestion
  (b) congestion results in a load reduction
  (c) if we have agreed on some mechanism to refute (a) then we can
      skip (b) 

That is the state of the standards.  This document is consistent
with reality in this respect but does not change it.  This is the
state of things with or without this document.

> I think it is sufficient to have a mechanism to detect
> non-congestion events.

This changes the state of the world.  I.e., here is my mechanism for
detecting non-congestion loss:

  - when we detect loss, roll random number R in [0.0,1.0]
  - if R >= 0.95 decide loss is congestion-based, else decide the
    loss is non-congestion-based

Why 0.95?  Because I just *know* 95% of the losses are not related
to congestion of course!  And, Yes, I Am Just That Damn Smart.

I think we'd all agree that is a stupid mechanism.  But, by
suggesting it is sufficient for any-old-mechanism to exist to
determine the difference between congestion and non-congestion
losses we have to be OK with my stupid mechanism or any other
crackpot idea that someone cooks up.  I Am Not OK With That.

> To me, it does not matter whether this mechanism is standardized
> by the IETF. The standardization may not even be possible if that
> mechanism is tightly tied into a non-IETF protocol.

OK, fine.  But, these are cases where someone is already operating
outside the standards process.  And, that may well be fine.  But, I
don't see how that is going to de-rail someone from using the
guidelines in this document.

> Also, "standardization" seems to exclude
> informational/experimental RFCs and I am not sure if I agree that
> they should be excluded here.

True- these are excluded.  But, that is the reality of the world.
I.e., strictly speaking these shouldn't be used by TCP or SCTP or
whatever either.  If you think they are OK for wide-spread use then
it seems to me that the right path is to get them on the standards
track.  The wrong path seems to just say anything goes.

> The following wording also seems to implicitly assume that IETF
> standards are used as basis of a protocol: 
> 
>     A non-goal of this document is to in any way specify
>     individual deviations from current IETF standardized RTO
>     specifications that any particular implementation may exhibit.
>     Rather, we provide a set of over-arching guidelines that all
>     RTO mechanisms should follow.
> 
> This wording makes sense for TCP. But, again, I'd prefer a wording
> that applies to all protocols running over the Internet no matter
> whether the protocol mechanics use IETF standards as basis, or
> not. 

Again, I do not follow.  The intent here---although I am not sure I
like the words now that I am reading them---is to say that the
document is not meant as a change to individual RTO mechanisms
already standardized.  E.g., the document will not be specifying new
SRTT gains in TCP's RTO.  I would not have thought that to be
controversial.

allman

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 7 Apr 2016 14:13:05 +0000

OK, I'll try again: I think it would make sense that an implementer e.g. of an UDP-based gaming protocol would be able to ensure that his protocol fulfills the requirements in this BCP ... even if that protocol does not use any protocol semantic in any standardized IETF transport protocol (e.g., TCP, SCTP, ...), and even if this (hypothetical) protocol may never show up in the IETF standards process.

Not all protocols and algorithms running in the general Internet are specified in IETF standards track documents. But hopefully an implementer would still understand that it would be useful to implement an RTO mechanism fulfilling these requirements. The simple remedy is not to insist on IETF standardized mechanisms in the document, but just describe the required basic functionality at a high-level. That's what I suggest. The document is actually meets those objectives very well, except in the few paragraphs in which the word "standardized" shows up.

Michael

---

From: Mark Allman <[email-masked]>
Date: Thu, 07 Apr 2016 10:28:34 -0400

You did not address my counter-points.

> OK, I'll try again: I think it would make sense that an
> implementer e.g. of an UDP-based gaming protocol would be able to
> ensure that his protocol fulfills the requirements in this BCP
> ... even if that protocol does not use any protocol semantic in
> any standardized IETF transport protocol

What about this document makes you think someone working on some
non-IETF protocol would not be able to follow the guidelines?

allman

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 7 Apr 2016 15:02:08 +0000

Regarding:

This excludes non-IETF standardized methods to detect non-congestion events. For the RTO mechanism it does not matter whether the mechanism that can detect a non-congestion event is standardized by the IETF or not. That mechanism could also be done in IEEE, ITU-T, or elsewhere, provided that it works (which will be the actual problem, not what SDO standardizes it).

Also, in my reading a non-IETF protocol may not be able to fulfill the following rule if it cannot implement F-RTO or some of the TCP-ish SACK mechanisms, which is (out-of-my-head, sorry if I miss something) the only standardized mechanism the IETF has:

        Additionally,

I think somebody could design a protocol that cannot use F-RTO. With a narrow understanding of "standardized" even Eifel Detection (RFC 3522) is not allowed because it is only experimental. Mandating "standardization" in this sentence does even make less sense to me than in the previous example.

Removing the words "standardized" and "IETF standardized" should sort this out.

Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 07, 2016 4:29 PM
To: Scharf, Michael (Nokia - DE)
Cc: [email-masked] Extensions
Subject: Re: Applicability of draft-ietf-tcpm-rto-consider-02 to non-IETF protocols 

> OK, I'll try again: I think it would make sense that an implementer 
> e.g. of an UDP-based gaming protocol would be able to ensure that his 
> protocol fulfills the requirements in this BCP ... even if that 
> protocol does not use any protocol semantic in any standardized IETF 
> transport protocol

What about this document makes you think someone working on some non-IETF protocol would not be able to follow the guidelines?

allman

---

From: Mark Allman <[email-masked]>
Date: Thu, 07 Apr 2016 12:01:36 -0400

> This excludes non-IETF standardized methods to detect
> non-congestion events.

I agree.  But, the (inconvenient) reality here is that non-IETF
standardized methods to detect non-congestion events are already
excluded by the standards!  Not because of this document.  On the
contrary, this document simply reflects current reality in this
space.  This document is not a congestion control document and does
not seek to make changes to congestion control.

You don't have to like reality.  Maybe you think there is a document
akin to this one for detecting non-congestion losses.
I.e., a set of guidelines that if followed would allow one to
determine a loss is not congestion-based and therefore to prevent a
congestion reaction.  If so, please write that document and we can
talk about it.  But, that is not this document.

> Removing the words "standardized" and "IETF standardized" should

I do not support that approach.  That is a backdoor change to
congestion control.  It is beyond the scope of this document.  And,
if it should be done at all it should be done in the full light of
day and not buried in this document.

allman

---

From: Jonathan Looney <[email-masked]>
Date: Thu, 7 Apr 2016 16:07:42 +0000

>Removing the words "standardized" and "IETF standardized" should sort this out.

My 2 cents:

I think you're suggesting we walk a fine line between being clear that we are not changing existing IETF specs (by allowing any mechanism whatsoever), while also making this generalized enough to be widely useful. I agree that would be good, if possible.

What about instead having a general statement that we must use IETF mechanisms when applied to IETF protocols, or something like that?

Jonathan

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 7 Apr 2016 17:34:08 +0000

> I think you're suggesting we walk a fine line between being clear that
> we are not changing existing IETF specs (by allowing any mechanism
> whatsoever), while also making this generalized enough to be widely
> useful. I agree that would be good, if possible.
> 
> What about instead having a general statement that we must use IETF
> mechanisms when applied to IETF protocols, or something like that?

Yes, this something like that would work for me.

In general, I think that this discussion shows that a better applicability statement is needed, e.g., in the introduction. That could be an appropriate place to add such a sentence. Then, the the actual requirements could be limited to technical mechanisms.

I believe this document should more explicitly distinguish ...

(a) Applicability to TCP implementations not necessarily following the standards-track RFCs for RTO calculation

(b) Applicability to RTO calculation in IETF protocols other than TCP having standards-track specifications

(c) Applicability to RTO calculations in any other protocol running in the Internet

Within our charter, TCPM can publish normative specifications for (a). Regarding (b), TCPM's mandate is limited since there are existing proposed standard RFCs for IETF protocols that are not fully compliant to this list of requirements. This is the reality. Therefore, it seems to me that this document needs a more explicit statement of the form "This document does not intend to change any existing IETF standard". (c) seems to be another area in which this document can be useful but if a protocol is not standardized in the IETF we cannot make assumptions how the RTO mechanism, loss recovery, etc. internally works. For (c) a remainder that a protocol needs further mechanisms for congestion control could be added, too.

Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 25 Apr 2016 19:57:29 +0100

On SCTP....

I've looked at the above ID and see it mentions SCTP alongside TCP.

If this ID does apply to SCTP, then I'd suggest the document editor 
(Mark) gets some inputs from those who maintain the SCTP specs to make 
sure the language is also correct for SCTP.

It would be wise to also post a note about the new version of the ID to 
TSVWG, where SCTP is normally discussed, to get feedback there. The 
final decision on what to do with SCTP really should come from TSVWG, 
although I'd expect recommendations for TCP to also apply to SCTP 
(unless there is a good reason).

Gorry