> On 20. mar. 2015, at 17.31, Jonathan Morton <[email protected]> wrote: > > >> On 20 Mar, 2015, at 16:54, Michael Welzl <[email protected]> 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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
