Subject: Re: [tsvwg] Some comments on draft-ietf-tcpm-rto-consider-03

From: Mark Allman <[email-masked]>
Date: Wed, 15 Jun 2016 14:21:06 -0400

Hi Gorry!

Responses to Gorry's lengthy feedback (thanks!) inline.  Also, I
have issued an -04 that takes into account this feedback and offline
conversations with Gorry, David and others.  It is available now:

The whole draft has undergone some editing, but sections 1 & 2 could
use some review.  (Although the entire document is short, so if you
can, please look it over.)

https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/
http://www.icir.org/mallman/pubs/All16a/

Comments, please!

allman

> * Introduction/Scope.

Re-worked substantially.

> * Comments on the recommendations
> 
> - Some of these comments relate I think to assumptions about TCP
> specifics, that could be generalised, or may be handed in the
> introduction.
> 
> (1)
> "the
> RTO MUST be conservatively set to no less than 1 second."
> - If this is TCP or SCTP, then RTO is defined. If more is intended
> RTO needs to have been defined.

New intro defines it.

> " For instance, consider a DNS request from a client to a
> resolver. When the request can be served from the resolver's
> cache the FT likely well approximates the network RTT between
> the client and resolver. However, on a cache miss the resolver
> will have to request the needed information from authoritative
> DNS servers, which will non-trivially increase the FT and
> therefore the FT between the client and resolver does not well
> match the network-based RTT between the two hosts."
> 
> - If the transport is assumed as DNS/UDP, this needs to be said in
> the example, up until this point the ID only discusses TCP and
> clearly DNS/TCP does not have this concern.

Yes, implicit assumption of UDP.  Now explicit.  Good catch.
Thanks. 

> " (b) FT observations MUST be taken regularly."

I have re-factored the text a bit in -04.  You might like it better.
I think it reads better.  Although the intent did not change.

> - The language below seems inappropriate in a MUST clause, I think
> this implies it is a SHOULD, and the exception conditions do need to
> be discussed, since the period isn't stated, how is this normative
> requirement to be interpreted?

I guess I don't follow.  I read this as "you MUST take FT samples
regularly" and "regularly SHOULD be once / RTT (or as often as you
exchange data if less frequently than once / RTT".  I.e., the MUST
and the SHOULD are about different things.  I tried to make the
words more clearly delineate this in -04.

> - Maybe this text needs clarification: The current wording
> requirement could be read to contradict RFC5405, that avoids against
> sending UDP probes and traffic when an application is idle. This
> needs more careful explanation. Even for TCP/SCTP, I would not
> advocate requiring keep-alive or heartbeat packets as suggested by
> "the requirement that the FT be sampled continuously throughout the
> lifetime of a connection."

See below (where you return to this issue).

> "For the purpose of this
> requirement, we state that FT samples SHOULD be taken at
> least once per RTT or as frequently as data is exchanged and
> ACKed if that happens less frequently than every RTT."
> and later:
> " Hence, this once-per-RTT sampling requirement is explicitly
> a "SHOULD" and not a "MUST".
> 
> " However, we also recognize that it may not always be
> practical to take a FT sample this often in all cases."
> 
> -I agree with the “SHOULD” from the perspective of TCP, some methods
> respond more slowly to congestion that TCP, and sample less
> often. How does this relate to the various repair mechanisms in RTP?
> (they also can have timers and retransmit) - are these counter
> examples where the SHOULD does not apply?

This isn't about how often we respond to congestion.  That is
orthogonal to this document.  We are trying to schedule
retransmissions.  So, what we really want to know---and I think this
is now better defined in the intro text you have seen---is how long
we should await delivery confirmation before tripping a retransmit.
That confirmation could be dictated by the network RTT.  Or, be
longer than that depending on protocol operation.  That is why the
document uses "FT" and not "RTT".  So, I am not sure where you're
going here with the congestion responses.

> “(c) FT samples used in the computation of the RTO MUST NOT be
> ambiguous.”
> 
> - I read this requirement is on the samples. That's not
> correct. Maybe it should be
> more like:
> "An RTO algorithm MUST NOT use FT samples that are ambiguous when
> calculating the RTO."

I changed it to this in -04:

        (d) An RTO mechanism MUST NOT use ambiguous FT samples.

( (c) is now something else---see below---and so this changed to (d) )

> - I wonder if section 3 could also talk about other ways to measure
> RTTs when not sending data, such as keepalive and SCTP heartbeat
> messages.

We don't always care about measuring RTTs.  So, we have to be
careful here, but I have added a 2(c) in section 3 on this topic.
It says:

        (c) FT observations MAY be taken from non-data exchanges.

            Some protocols use keepalives, heartbeats or other messages
            to exchange control information.  To the extent that the
            latency of these transactions mirrors data exchange, they
            can be leveraged to take FT samples within the RTO
            mechanism.  Such samples can help protocols keep their RTO
            accurate during lulls in data transmission.  However, given
            that these messages may not be subject to the same delays as
            data transmission, we do not take a general view on whether
            this is useful or not.

> "The backoff may be removed
> after the successful transmission of non-retransmitted data."
> 
> - The "may" appears to be protocol permission, can it be "MAY”?

I think this comes from 6298 wording---which I just checked and is
not in protocol permission language.  I think you're correct here.
I have changed it in -04 to be more precise all the way around:

        The backoff SHOULD be removed after the successful repair of
        the lost data and subsequent transmission of
        non-retransmitted data.

> " A maximum value MAY be placed on the RTO provided it is at least
> 60 seconds (a la [RFC6298])."
> 
> - To me, there seem to be two requirements here:
> 
> " A maximum value MAY be placed on the RTO. The maximum MUST NOT exceed
> 60 seconds (as in [RFC6298])."

Sounds reasonable.  And, especially so since you mis-understood it
and translated it wrong! :)

The version in -04 is ...

        A maximum value MAY be placed on the RTO.  The maximum RTO MUST
        NOT be less than 60 seconds (a la [RFC6298]).

> (4) "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)."
> 
> - NiT: I wonder if this can be mis-cited? There are as yet no specs
> in the space published in the RFC series. Could we be more careful
> on endorsing this work, and say perhaps that "exceptions could be
> made to this rule if an IETF standardized ... .

Good call.  I made this change.

> "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."
> 
> - Examples from the RFC series exist, and would be good. E.g. Eifel
> or something else?

I added an "(e.g., [RFC5682])".  Good call.

> - Is this the place to define "spurious", since this is used later.

Hm.  I was trying to figure out how to cleanly wedge that in, but I
couldn't find something I liked.  Instead I tweaked the intro at the
first use of "spurious".

> " We note that research has shown the tension between the
> responsiveness and correctness of retransmission timeouts seems to
> be a fundamental tradeoff [AP99]."
> - I think this paper is about TCP, and I think the tension is clear
> for protocols like TCP.

I added a note.

> "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'd like to argue that a lower RTO can reduce performance for
> paths where this RTO can be set below the RTT. Such paths do exist,
> and middleboxes sometimes split TCP connections to overcome this
> issue. I think at least the ID should note the issue, even if it
> claims that these paths are somehow accommodated within the
> guidance.

I do not quite understand this.  I am not conjuring a case where the
timeout could ever be less than the RTT.  

A middlebox can split the TCP connection so we end up with two
connections A<->M and M<->B.  Are you considering the "RTT" to be
A<->B and are then saying A can actually retransmit based on the
A<->M delay?  Sure.  But, in this case I am not sure how A's TCP
will ever know the A<->B "RTT".  For non-TCP protocols that have a
higher layer delivery confirmation mechanism that comes from B I
could see this.  However, in this case, I am not sure how we'd know
to retransmit on A<->M timescales.

Basically I am confused here.  I am happy to address this if you can
explain to me what you mean.

> * Standards status and RFC 2119 recommendations.
> 
> "nor limit future standardization of specific RTO mechanisms."
> - I'd need advice, but I thought BCPs did exactly this. Paraphrasing
> slightly, the purpose of the RFC5405 was to impose default
> constraints that future RFCs have to justify their choices
> against. That's limiting. The MUSTs are real requirements and the
> SHOULD strong desirables. The feedback we have to the RFC5405.bis is
> to stengthen more SHOULDs to MUSTs - I'm going to speak to my ADs
> before I agree to any of these. But if the IESG agree, then I think
> that is what BCP status is about.
> 
> Scope (a) I don’t disagree, unless the community explicity updates a
> spec a new BCP doesn't change old RFCs.
> 
> Scope (v) - To me seems weird. Because it seems to set a "SHOULD"
> over the entire document, and that document contains MUSTs. I can't
> see how an RFC can have a "SHOULD-MUST", but likely the ADs can
> advise during WGLC.

(This has all been removed / changed in a big way.  So, I am not
commenting on it.)

> I worry the following can be cited elsewhere as compliance of a
> protocol or mechanism by the IETF, when really I think this is
> intended to define an acceptable RTO response. Some tightening of
> the language would seem appropriate:
> 
> "RTO mechanisms that are not standardized but adhere to the
> requirements in the following section are deemed consistent with
> the standards. "
> - sounds dangerously wide when cited as text - I was presuming the
> document intended "are deemed consistent with
> the standards in the RTO behaviour" - or something, I presume you
> don't want people to cite this RFC saying their new protocol foo-bar
> is "consistent with IETF standards" because it does this.
> 
> "an implementation is considered standards compliant"
> - I quibble again here on language, because I don't think this is
> true generally of the protocol, only true of their RTO response.

(This has all been removed / changed in a big way.  So, I am not
commenting on it.)

> "In other words, the requirements in this document can be viewed as
> specifying the default properties of an RTO mechanism."
> - This seems like an informational statement that could be cited as
> a contradiction to the RFC2119 text unless worded carefully? This
> sort of text needs AD advice if kept.
> 
> "Specifications can more concretely nail down specifics within these
> defaults or work outside the defaults as necessary."
> - The same comment on the second half of this sentence.

I removed the word "default" from the document.  I think the last
paragraph of the intro better addresses things now.

> "That is, this document's
> stance is to not limit the community's ability to make exceptions
> to the requirements herein for particular cases."
> - If this is BCP, I think this needs to be tighter, I don't think
> any ID can expect to automatically make exceptions to a BCP, by
> simply saying "the WG decided differently" if you want that, then I
> think this document needs to be INFO (I'm not the Chair or AD for
> the document). If it's BCP, I'd expect the consensus to set the best
> current practice and the ADs to block new RFCs with at least a
> DISCUSS to work out why WG XXX was going against what has been IETF
> consensus.

I don't think you can go info and make the same sort of
requirements.

I don't really disagree with what you say.  I.e., I would expect
that if this were a BCP that it would be taken into account when
designing RTOs.  And, if something wanted to be more aggressive or
do something outside the requirements that this be done explicitly
with the BCP text as context.  I.e., I would expect that the WG
would consider this and have an answer for why the deviation is OK
far before it hits the IESG.

> "However,
> implementations that fall within the defaults do not require
> explicit specifications to be considered consistent with the
> standards."
> - I could not parse this sentence, it sounds like it could be
> normative language without a keyword.

Text is gone in -04.

> Section 3:
> 
> "We now list the requirements that SHOULD apply when designing
> retransmission timeout (RTO) mechanisms."
> - this seems to scope a "MUST" with a preceding "SHOULD". I question
> if this is allowed in a BCP.

I understand what is meant.  But, it is not important enough in this
instance to argue about, IMO, and so I nuked the SHOULD normative
language from the beginning of section 3.