Subject: [tcpm] Adopting RTO Restart

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 12 Nov 2012 16:01:02 +0200

Hi,

In the TCPM meeting last week there was a clear consensus for adopting RTO restart (draft-hurtig-tcpm-rtorestart-03) as a working group item, targeted for Experimental RFC. Here is a proposal for a new milestone item:

Aug 2013  Submit document on restarting the RTO timer to the IESG for publication as an Experimental RFC

Any comments or objections about the milestone?

We discussed the issue of Std Track vs. Experimental a bit during the meeting, but did not have a clear consensus call on that. My reading of the discussion is that there would be room for experimentation to understand the effect that the proposed change might have on the likelihood of spurious RTOs. Therefore the proposed milestone currently is for Experimental. As discussed in the meeting, if during the progress it turns out that more experimentation is not necessary, we may, by WG consensus, change the intended status accordingly. Is this a fair plan for people?

- Pasi

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 12 Nov 2012 08:58:08 -0800

> Any comments or objections about the milestone?
Instead of another RFC, how about a bis of rfc6298? it seems a small
modification on re-arming the RTO timer.

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 12 Nov 2012 17:08:09 +0000

I'd be also interested as to why 6298 suggests the use of an even more conservative RTO timer, by restarting not with the last sent (and unacknowledged) packet, but with the last received ACK...

If the basis for using RTO was well funded, being more conservative than the necessary RTO shouldn't be necessary.

If for some reason RTO is not calculated properly, or too short etc, IMHO that needs addressing, rather than stipulating the RTO to start one RTT late...

But RTTM hasn't been looked at in a long time, unfortunately... (I.e. to build better / more robust models that produce near an optimal RTO timer).

So, I think a -bis (and standards track) may be more suited, too?

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yuchung Cheng
> Sent: Montag, 12. November 2012 17:58
> To: Pasi Sarolahti
> Cc: tcpm; Michael Welzl
> Subject: Re: [tcpm] Adopting RTO Restart
> 
> > In the TCPM meeting last week there was a clear consensus for adopting
> RTO restart (draft-hurtig-tcpm-rtorestart-03) as a working group item,
> targeted for Experimental RFC. Here is a proposal for a new milestone
> item:
> >
> > We discussed the issue of Std Track vs. Experimental a bit during the
> meeting, but did not have a clear consensus call on that. My reading of
> the discussion is that there would be room for experimentation to
> understand the effect that the proposed change might have on the
> likelihood of spurious RTOs. Therefore the proposed milestone currently is
> for Experimental. As discussed in the meeting, if during the progress it
> turns out that more experimentation is not necessary, we may, by WG
> consensus, change the intended status accordingly. Is this a fair plan for
> people?
> >
> > - Pasi
> >

---

From: Michael Welzl <[email-masked]>
Date: Mon, 12 Nov 2012 19:05:16 +0100

Hi,

We authors of draft-hurtig-tcpm-rtorestart-03 agree with that.

Cheers,
Michael

On Nov 12, 2012, at 3:01 PM, Pasi Sarolahti wrote:

> Hi,
>
> In the TCPM meeting last week there was a clear consensus for  
> adopting RTO restart (draft-hurtig-tcpm-rtorestart-03) as a working  
> group item, targeted for Experimental RFC. Here is a proposal for a  
> new milestone item:
>
> We discussed the issue of Std Track vs. Experimental a bit during  
> the meeting, but did not have a clear consensus call on that. My  
> reading of the discussion is that there would be room for  
> experimentation to understand the effect that the proposed change  
> might have on the likelihood of spurious RTOs. Therefore the  
> proposed milestone currently is for Experimental. As discussed in  
> the meeting, if during the progress it turns out that more  
> experimentation is not necessary, we may, by WG consensus, change  
> the intended status accordingly. Is this a fair plan for people?
>
> - Pasi
>

---

From: Mark Allman <[email-masked]>
Date: Tue, 13 Nov 2012 21:52:04 -0500

> Any comments or objections about the milestone?

This seems like a good idea to me.

allman

---

From: Mark Allman <[email-masked]>
Date: Tue, 13 Nov 2012 21:58:36 -0500

> I'd be also interested as to why 6298 suggests the use of an even more
> conservative RTO timer, by restarting not with the last sent (and
> unacknowledged) packet, but with the last received ACK... 

I am not sure what your suggestion is here.

The general idea behind restarting on an ACK of previously unACKed data
is that the connection is making progress and so lets keep the RTO out
of the way.

More generally ...

If the WG couldn't reach consensus on making this PS then I can't see
rolling this into a 6298bis.

That said, I would be fine with the tweak going PS.  And, rolling it
into a 6298bis seems OK in principle to me.

And, even more generally ...

We should *get out of this business* of trying to optimize the hell out
of the RTO.  I.e.,

  http://www.icir.org/mallman/papers/draft-allman-tcpm-rto-consider-01.txt

We can all imagine a bazillion different small tweaks.  As long as the
RTO adheres to some basic principles, none of these little things
matters much.  Maybe they help in some cases.  They certainly do not
hurt. 

allman

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 13 Nov 2012 19:21:49 -0800

> matters much.  Maybe they help in some cases.  They certainly do not
Nod. Linux for example uses a different estimator, different min-RTO,
different sampling frequency, plus another X tweaks.

I think this should go directly to the bis because it's just one sentence:
"When re-arming the RTO, the implementation can choose to offset the
time elapsed since SNDUNA has been last transmitted to improve
performance, if such an information is available". That's it!

---

From: Mark Allman <[email-masked]>
Date: Tue, 13 Nov 2012 22:29:15 -0500

> different sampling frequency, plus another X tweaks.

And, the world hasn't blown up.

> I think this should go directly to the bis because it's just one
> sentence: "When re-arming the RTO, the implementation can choose to
> offset the time elapsed since SNDUNA has been last transmitted to
> improve performance, if such an information is available". That's it!

If I had my druthers we'd do it right and put in place the higher level
considerations.

But, that doesn't necessarily make Yuchung wrong.

allman

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 14 Nov 2012 18:24:43 +0100

> We should *get out of this business* of trying to optimize 
> the hell out of the RTO.  I.e.,
> 
>   
> We can all imagine a bazillion different small tweaks.  As 
> long as the RTO adheres to some basic principles, none of 
> these little things matters much.  Maybe they help in some 
> cases.  They certainly do not hurt. 

For what it is worth (I might have said this earlier): I have refered to this draft more than once already, specifically in discussions on RTO design for UDP-based TCP-ish protocols. There are quite a number of them in the IETF...

I do think that this document would indeed be a useful output of TCPM in order to provide general guidance esp. for non-TCP protocols. It is probably independent of other documents.

Michael (chair hat off)

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 14 Nov 2012 23:59:16 +0200

> into a 6298bis seems OK in principle to me.

I see RTO restart adoption and revising RFC 6298 as separate steps. And adopting draft-hurtig-tcpm-rtorestart is what we had consensus call about last week. Even if RTO restart progresses as Experimental, I think we can later adopt a new draft-allman-tcpm-rfc6298bis for PS working group item at any time when people are ready to agree so, and that draft could include ideas from the RTO restart document. Right?

Maybe between those two steps we should get better understanding if similar benefits could be achieved with small adjustments to RFC 6298 without additional branches or variables, and if not, why not? Or are there some special cases that cause problems without the "nr of outstanding < 4" condition? (Personally, I'm not a big fan of adding new special conditions or state variables to RTO logic if those could be avoided)

- Pasi