> On 21. mar. 2015, at 00.47, David P. Reed <dpr...@reed.com> wrote: > > 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.
... or they're so early that there are not enough RTT samples for a meaningful RTT measure. > 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. > > Do the control theory. Well - the RTO calculation can easily go out of whack when there is some variation, due to the + 4*RTTVAR bit. I don't need control theory to show that, a simple Excel sheet with a few realistic example numbers is enough. There's not much deep logic behind the 4*RTTVAR AFAIK - probably 4 worked ok in tests that Van did back then. Okay though, as fine tuning would mean making more assumptions about the path which is unknown in TCP - its just a conservative calculation, and the RTO being way too large often just doesn't matter much (thanks to DupACKs). Anyway, sometimes it can - and then a dropped packet can be pretty bad. Cheers Michael > > On Mar 20, 2015, Michael Welzl <mich...@ifi.uio.no> wrote: > > On 20. mar. 2015, at 17.31, Jonathan Morton <chromati...@gmail.com> wrote: > > > On 20 Mar, 2015, at 16:54, Michael Welzl <mich...@ifi.uio.no> wrote: > > I'd like people to understand that packet loss often also comes with delay - > for having to retransmit. > > 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. > > 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 > https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 : > > *** > To get a sense of just how long the RTOs are in relation to > connection RTTs, following is the distribution of RTO/RTT values on > Google Web servers. [percentile, RTO/RTT]: [50th percentile, 4.3]; > [75th percentile, 11.3]; [90th percentile, 28.9]; [95th percentile, > 53.9]; [99th percentile, 214]. > *** > > 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... > > Cheers, > Michael > > > -- Sent with K-@ Mail - the evolution of emailing. _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
