On Thu, May 9, 2013 at 2:39 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:

> * Dave Taht | 2013-05-09 13:55:18 [-0700]:
>
> >While this appears to make a great deal of sense
> >
> >http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01
> >
> >and just landed in
> >
> >
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6ba8a3b19e764b6a65e4030ab0999be50c291e6c
> >
> >I was intrigued by several of the pieces of data that drive this stuff
> >
> >Measurements on Google Web servers show that approximately 70% of
> >   retransmissions for Web transfers are sent after the RTO timer
> >   expires, while only 30% are handled by fast recovery.  Even on
> >   servers exclusively serving YouTube videos, RTO based retransmissions,
> >
> >96% of the timeout episodes occur without any preceding duplicate ACKs or
> >other indication of losses at the sender
>
> Btw: Nandita introduced a new MIB entry: LINUX_MIB_TCPLOSSPROBES.
>
> $ nstat -a | grep TCPLossProbes
>
> will show fired probes.
>
>
>
I have to admit that the 96% figure strongly suggests some degree of
bufferbloat in the tested mix here. I am curious however as to what other
causes there might be, ranging from tcp bugs to glitches in the matrix?

>
> Hagen
>
>


-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html