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

["David P. Reed" <dpreed@reed.com>]

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

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.

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.

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

[-- Attachment #2: Type: text/html, Size: 2998 bytes --]