[Cake] ack filter rrul result at 1000/100

[Sebastian Moeller]

Hi Dave,


> On Nov 16, 2017, at 05:28, Dave Taht <dave.taht at gmail.com> wrote:
> 
> This is a much saner test result[1], showing about a 20% improvement
> under the rrul_be test. I scaled back the topology to two instances of
> cake on the middlebox, shaping to 100mbits on one side and 10mbits on
> the other, and flipped filtering on or off. The win will improve more
> with upload/download ratios of ever worse than 10/1, and the rrul is
> not exactly a test of real traffic.
> 
> What other ratios are out there, particularly in the dsl world?

All over the place ;) the nominal ratios often are (taken from Deutsche Tekekom):
ADSL:
16/1			= 16/1
16/2.5 		= 6.4/1	(this is the default)
16/0.8 		= 20/1
according to https://en.wikipedia.org/wiki/G.992.5 some ISPs even do
20/0.768 		= 26/1
But these are the upper limits for those plans any many users will see less:
The extreme cases according to the contract would be (exemplary taken fro Deutsche Telekom):
6.016/0.288 	= 20.9/1
2.047.0.224 	= 2./1
16/0.704 		= 22.7/1
But note that these last cases are unrealistic as on ADSL-links the upstream tends to be more robust than the downstream, so the realistic downstream for the listed upstreams will be well below the listed values (otherwise the line needs to be checked for external noise sources, I guess).

VDSL2:
16/1 	= 16/1 (rare)
25/5 	= 5/1
50/10 	= 5/1
100/40 	= 2.5/1
SVDSL (VDSL2 AnnexQ):
estimated 250/40 = 6.25/1

On the DOCSIS side I see:
500/50 = 10/1 
400/25 = 16/1
200/12 = 16.7/1
100/6 = 16.7/1
32/2 = 16/1
(I just skip the extreme cases for VDSL


But at least in Germany most DOCISS ISPs actually allot more gross bandwidth than put in the contract, but I assume the ratios to not change too much. I also read in a cisco document that ACK filtering might be performed by some cable ISPs already...

In short I guess there should be quite a number of end users experiencing downstream/upstream asymmetries > 10/1, with 16/1 probably an important number (at least in Germany).

> 
> I can think of a few ways to get more acks to filter out, for example,
> not using the "sparse flow optimization" for acks.

	Not using GRO/GSO/TSO on sender and receiver ;)

Best Regards
	Sebastian

> 
> [1] it also turned out my test target box, an odroid c2, couldn't push
> more than 500mbits bidir in the first place.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rrul_be-2017-11-15T201221.312953.ack_filter_100Mbit_10Mbit.flent.gz
Type: application/x-gzip
Size: 83889 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20171116/8cfd1e31/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rrul_be-2017-11-15T201510.970394.no_ack_filter_100Mbit_10Mbit.flent.gz
Type: application/x-gzip
Size: 82641 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20171116/8cfd1e31/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rrul_be_-_ack-filter-100mbit-10mbit.png
Type: image/png
Size: 993708 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20171116/8cfd1e31/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: odroid_c2_limits.png
Type: image/png
Size: 66686 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20171116/8cfd1e31/attachment-0003.png>
-------------- next part --------------
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake