Subject: [iccrg] max RTT to seed RTO?

From: Michael Welzl <[email-masked]>
Date: Wed, 8 Nov 2017 10:27:33 +0100

Dear all,

I have a basic TCP question:

If the goal of the RTO is to figure out if packets are really gone from the path, wouldn’t the maximum RTT be a more reasonable value to work with than a smoothed average + variation?

Of course, this would have to be valid for a certain time window only, to allow for the RTT to become smaller, e.g. upon a routing change - but generally, if we want to be sure that there are no more packets in the network, I guess the right input is the maximum RTT ever seen + a little safety margin.

In fact, it seems to me so clear, simple and obvious that deriving the RTO from the max. RTT would be better than deriving it from SRTT + K*RTTVAR that I really wonder what I’m missing.
In particular, I don’t understand the idea behind smoothing as a filter function. Why is an EWMA meaningful here, as opposed to using a max? Sure, a max is prone to outliers, but if we measure them, they do happen, and we want the RTO to be safe in the face of such outliers.

Cheers,
Michael

---

From: "Ali C. Begen" <[email-masked]>
Date: Wed, 8 Nov 2017 13:48:52 +0300

> On Nov 8, 2017, at 12:27 PM, Michael Welzl <[email-masked]> wrote:
> 
> Dear all,
> 

Not necessarily. Max is really a corner case. You won’t be using the absolute max over the entire connection duration, you will have to pick something like the max among the last X packets or Y seconds. Smoothing gives you that automatically anyway.

Nobody argues EMWA is the best of the best but it mostly works. And any improvement on top of that, I doubt, will not have much impact on TCP tput.

I have seen people using inter-packet times to make better (faster) predictions if the incoming packet(s) was lost. That is another way of doing it.

-acbegen

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

---

From: Mark Handley <[email-masked]>
Date: Wed, 08 Nov 2017 11:26:49 +0000

Hi Michael,

The problem with MaxRTT is that it is a lagging estimator.  

Consider the most common case - a single TCP flow slowstarts into a
bottleneck link, eventually filling the buffer, getting a loss, and
switching to congestion avoidance mode.  As the cwnd builds during
slowstart, the RTT will increase.  Initially it will just be a bit
jittery as packets arrive at the slow link in pairs.  Then when the
delay-bandwidth product is exceeded, the RTT will grow pretty rapidly. 
MaxRTT will cause all packets sent during this RTT growth phase to time
out because it lags the actual RTT significantly at this point.  

What you need to avoid this is a measure that generally leads the RTT
when queues are growing.  You can argue about whether the current
mechanism is the best it could be, but the 4*RTT_var component of the
RTO generally grows fast enough to lead the actual RTT, so avoiding
unnecessary timeouts.  It might be instructive to run this in a
simulator and graph bottleneck queue delay and  RTO on the same time
axis to see how well it leads.  

Regards,
Mark

On Wed, Nov 8, 2017, at 09:27 AM, Michael Welzl wrote:
> If the goal of the RTO is to figure out if packets are really gone from
> the path, wouldn’t the maximum RTT be a more reasonable value to work
> with than a smoothed average + variation?
> 
> Of course, this would have to be valid for a certain time window only, to
> allow for the RTT to become smaller, e.g. upon a routing change - but
> generally, if we want to be sure that there are no more packets in the
> network, I guess the right input is the maximum RTT ever seen + a little
> safety margin.
> 
> In fact, it seems to me so clear, simple and obvious that deriving the
> RTO from the max. RTT would be better than deriving it from SRTT +
> K*RTTVAR that I really wonder what I’m missing.
> In particular, I don’t understand the idea behind smoothing as a filter
> function. Why is an EWMA meaningful here, as opposed to using a max?
> Sure, a max is prone to outliers, but if we measure them, they do happen,
> and we want the RTO to be safe in the face of such outliers.
> 
> Cheers,
> Michael
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 8 Nov 2017 12:41:45 +0100

Hi,

I asked because I’m in fact playing around with such timing variations in simulations right now. This answer is spot on - this was really, really helpful, thanks a lot!

Cheers,
Michael

> On Nov 8, 2017, at 12:26 PM, Mark Handley <[email-masked]> wrote:
> 
> Hi Michael,
>

---

From: "zhangyali (D)" <[email-masked]>
Date: Fri, 10 Nov 2017 07:56:03 +0000

Hi all,

Very happy to find out that RTO is still an interesting topic in TCP congestion control algorithm. In fact, I have some researches in datacenter, and an result is that the small flow's flow completion time will be deteriorated seriously if RTO is triggered since the RTO is 200ms which is several magnitudes of its transmission time. 

Now, in the academic circle, proactive congestion control has become a trend. Proactive congestion control means the bottleneck allocate the rate or swnd explicitly, and the senders will not need to probe network capacity which will not induce throughput suffers or congestion happens. I have do some simulations, and the effect is very amazing. I am very happy to share you with my findings, and do you think is this a opportunity to eliminate the congestion? Look forward to discuss with you in the upcoming meeting.

Best Regards,
Yali

-----邮件原件-----
发件人: iccrg [mailto:[email-masked]] 代表 Michael Welzl
发送时间: 2017年11月8日 19:42
收件人: Mark Handley <[email-masked]>
抄送: [email-masked]
主题: Re: [iccrg] max RTT to seed RTO?

Hi,

Cheers,
Michael

> MaxRTT will cause all packets sent during this RTT growth phase to 
> time out because it lags the actual RTT significantly at this point.
> 
>> If the goal of the RTO is to figure out if packets are really gone 
>> from the path, wouldn’t the maximum RTT be a more reasonable value to 
>> work with than a smoothed average + variation?
>> 
>> Of course, this would have to be valid for a certain time window 
>> only, to allow for the RTT to become smaller, e.g. upon a routing 
>> change - but generally, if we want to be sure that there are no more 
>> packets in the network, I guess the right input is the maximum RTT 
>> ever seen + a little safety margin.
>> 
>> In fact, it seems to me so clear, simple and obvious that deriving 
>> the RTO from the max. RTT would be better than deriving it from SRTT 
>> + K*RTTVAR that I really wonder what I’m missing.
>> In particular, I don’t understand the idea behind smoothing as a 
>> filter function. Why is an EWMA meaningful here, as opposed to using a max?
>> Sure, a max is prone to outliers, but if we measure them, they do 
>> happen, and we want the RTO to be safe in the face of such outliers.
>> 
>> Cheers,
>> Michael
>>