<html><head></head><body>I think this is because there are a lot of packets in flight from end to end meaning that the window is wide open and has way overshot the mark. This can happen if the receiving end keeps opening it's window and has not encountered a lost frame. That is: the dropped or marked packets are not happening early eniugh.<br clear="none">
<br clear="none">
Evaluating an RTO measure from an out of whack system that is not sending congestion signals is not a good source of data, unless you show the internal state of the endpoints that was going on at the same time.<br clear="none">
<br clear="none">
Do the control theory.<br clear="none"><br clear="none"><div class="gmail_quote">On Mar 20, 2015, Michael Welzl <michawe@ifi.uio.no> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k10mail"><br clear="none"></pre><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">On 20. mar. 2015, at 17.31, Jonathan Morton <chromatix99@gmail.com> wrote:<br clear="none"><br clear="none"><br clear="none"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">On 20 Mar, 2015, at 16:54, Michael Welzl <michawe@ifi.uio.no> wrote:<br clear="none"><br clear="none">I'd like people to understand that packet loss often also comes with delay - for having to retransmit.</blockquote><br clear="none">Or, turning it upside down, it’s always a win to drop packets (in the service of signalling congestion) if the induced delay exceeds the inherent RTT.</blockquote><br clear="none">Actually, no: as I said, the delay caused by a dropped packet can be more than 1 RTT - even much more under some circumstances. Consider this quote from the intro of <a shape="rect" href="https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01">https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01</a> :<br clear="none"><br clear="none">***<br clear="none">To get a sense of just how long the RTOs are in relation to<br clear="none">connection RTTs, following is the distribution of RTO/RTT values on<br clear="none">Google Web servers. [percentile, RTO/RTT]: [50th percentile, 4.3];<br clear="none">[75th percentile, 11.3]; [90th percentile, 28.9]; [95th percentile,<br clear="none">53.9]; [99th percentile, 214].<br clear="none">***<br clear="none"><br clear="none">That would be for the unfortunate case where you drop a packet at the end of a burst and you don't have TLP or anything, and only an RTO helps...<br clear="none"><br clear="none">Cheers,<br clear="none">Michael<br clear="none"><br clear="none"></blockquote></div><br clear="none">-- Sent with <b><a shape="rect" href="https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2">K-@ Mail</a></b> - the evolution of emailing.</body></html>