[Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

[Michael Welzl]

> On 21. mar. 2015, at 00.47, David P. Reed <dpreed at 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 <michawe at ifi.uio.no> wrote:
> 
> On 20. mar. 2015, at 17.31, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
> 
> On 20 Mar, 2015, at 16:54, Michael Welzl <michawe at 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.