Re: [Cake] Getting Cake to work better with Steam and similar applications

[Andy Furniss <adf.lists@gmail.com>]

Jonathan Morton wrote:
> 
>> On 1 May, 2017, at 14:32, Andy Furniss <adf.lists@gmail.com> 
>> wrote:
>> 
>> Well it seems distance is important for BBR. It seems to have a 
>> design whereby your rtt to the server determines how badly it will 
>> bork your latency. Unlike cubic it doesn't take loss/ecn as a hint 
>> to get out of its exponential phase, which is IMHO not a friendly 
>> thing to do, I mean didn't they think people have to share 
>> connections :-(
>> 
>> Playing with a sim, something like dash that grabs a meg waits
>> then gets another with a new connection needs crazy amount of back
>> off to avoid borking latency every chunk. The amount of disruption 
>> getting worse the higher the RTT of the TCP.
> 
> Just to be sure - are you running sch_fq on the egress interface(s) 
> of the BBR sender?  If not, *you are not running BBR*.  BBR needs
> the pacing functionality of sch_fq to work correctly.
> 

No, I was trying to pretend that the flow was not local (though looking
I see sch_fq can handle routed).

Reading random high level descriptions of BBR I didn't see it mentioned.

I did read that bbr tries to probe 2x rtt, which is what I see in a pure
buffer.

Does google/valve/every bbr user run it?

I mean Dendari is clearly having issues with valve. I can't really test
latency properly with steam on my real wan as my ISP does QOS.

I'll try to cook up another sim, but will probably run out of interfaces.