Would the server be bases in U.S.A?
What if instead of a speed test server, we set up a network of volunteers who register their routers to something similar to pool.ntp.org (perhaps it could be called pool.speedtest.openwrt.org or something) except for speed tests. Each router configured to use at most a certain fraction of its bandwidth outgoing. A person who wants to run a test has a client that connects to a couple hundred of these and asks for a certain transfer of data, say 10MB. The daemon generates 10MB of random data with an RNG and sends it. At the same time the daemon responds to a certain number of pings per second per client... The daemon has rules to only allow speed tests at certain times of the day at certain bandwidths etc...
There could be a per-ip or per ipv6 prefix budget too. No more than 100MB per user per month or something like that... configurable.
Need to stop thinking about the world as "the big masters with servers" vs "all us plebes" 
Not really, in theory iperf allows to request differen tpacket sizes for UDP but so far I failed getting any "public" iperf3 server to actually honor those.
I also played around with adding and uncommenting the following to my router's custom firewall rules:
# special rules to allow MSS clamping for in and outbound traffic
# use ip6tables -t mangle -S ; iptables -t mangle -S to check
forced_MTU=216
# affects both down- and upstream, egress seems to require at least 216
#iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "custom: Zone wan MTU fixing" -j TCPMSS --set-mss ${forced_MTU}
#ip6tables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "custom6: Zone wan MTU fixing" -j TCPMSS --set-mss ${forced_MTU}
# DOWLOAD direction
#iptables -t mangle -A FORWARD -o pppoe-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "custom: Zone wan MTU fixing" -j TCPMSS --set-mss ${forced_MTU}
#ip6tables -t mangle -A FORWARD -o pppoe-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "custom6: Zone wan MTU fixing" -j TCPMSS --set-mss ${forced_MTU}
# UPLOAD direction does not work reliably
## egress still does not work, it does not really honor the given value, due to conntrack?
egress_forced_MTU=forced_MTU
#iptables -t mangle -A FORWARD -o br-lan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "custom: Zone wan MTU fixing" -j TCPMSS --set-mss ${egress_forced_MTU}
#ip6tables -t mangle -A FORWARD -o br-lan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "custom6: Zone wan MTU fixing" -j TCPMSS --set-mss ${egress_forced_MTU}
#iptables -t mangle -A FORWARD -i pppoe-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "custom: Zone wan MTU fixing" -j TCPMSS --set-mss ${egress_forced_MTU}
#ip6tables -t mangle -A FORWARD -i pppoe-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "custom6: Zone wan MTU fixing" -j TCPMSS --set-mss ${egress_forced_MTU}
That way the packetsize for any TCP based speedtest can be reduced, but not all speedtests play along nicely. Last but not least some of flent's tests recently learned to sent smaller than full MTU packets, but a) I have not tested that myself and b) you still need an open flent server. So the clam MSS hack in combination with fast.com or speedtests.net might still be your best bet.
Well, all you need is a public/known to you netperf/netserver host (ideally also running irtt), so a VPS might not be too hard to install and should be a perfect test reflector for a few dollars/EUR per month.
+10; Overhead really is not that critical if you overestimate it, and it should be reasonably simple to overestimate it 
DOCSIS 3.1 mandates a version of PIE with a latency target of either 10 or 15 milliseconds, but that is only for the upstream direction, there is no mandate in DOCSIS for the downstream direction (that might change in the future).
Yeah, as long as you don't pound it with bandwidth and use up your transfer. It's not too hard. You can do it with a digital ocean droplet for like $5/mo... again, assuming the included 1TB of transfer is sufficient... I have a GPON connection, and could fill that 1TB in 8000 seconds, so about 2 hrs of testing. That's about 4 mins a day.
Also it's not clear to me that a droplet actually would get 1Gbps to your VPS... you might need to negotiate with someone over there to get that kind of bandwidth. Linode for example by default limits VPS to something like 150 or 200Mbps under the assumption that for most people this is totally fine and more would be an error condition (though I think they're willing to lift this cap if you ask).
So it all comes down to what you want to do and how much bandwidth how many users etc.
I am gonna try lowering my WAN MTU and use some of the public servers.
At&t router/gateway <---> MiniGL BITW <---> WRT3200ACM <---> lan devices (192.168.0.1/24)
192.168.0.254 <---> 192.168.0.100 <---> 192.168.0.64
NO Double NAT 
Asking here for more visibility as it is related to SQM...
Given that the IETF seems to be leaning towards the implementation of L4S rather than SCE [1], if it were to be implemented, would this have any adverse effect on SQM/Cake/FQ_CoDel, and if so to what extent? With L4S, it also seems a bit off to me that an entire queue would be dedicated to certain traffic marked with a certain header. What's to stop me from marking all my packets as priority with L4S and ruin other people's/my ISPs day?
1 Like
Your ISP should have a policy. For example if you have say 100Mbps symmetric, they should be only letting you inject a fraction of that at high priority, maybe 10Mbps for example.
Thanks for the references though, I will read up, as I am not familiar with the L4S stuff.
1 Like
Well, the problem with L4S mostly is, that is has been demonstrated to not actually work reliably and robustly. It has seen little adversarial testing, and I fear it will not fare well once exposed to the wider internet. Currently there is not even a finished transport protocol that can/will use the L4S-AQM at all, so in all likelihood initially very little is going to change. And later, I predict that L4S will crash and burn, since the implementation behind it seems more based more on wishful thinking than solid engineering.
That said, if L4S signaling, against my pessimistic expectations, takes of, it should be possible to add matching ECN signaling for ECT(1) marked traffic to both fq_codel and to cake (well, for codel it is a bit weird, as codel is optimized for 1/sqrt(p) type signaling, while ECT(1) traffic is supposed to request 1/p type signaling, but that is just a bit unclean)
That is because Bob Briscoe both never understood flow fair queueing and simultaneously hates it with all his guts (probably because he does not understand what makes FQ a decent approach). And it is generally said, that a true FQ system is computationally too demanding to be done in silicon. But I do not buy this rationale, it simply has not been tried hard enough.
Nothing really, in fact due to the LL-queue being shallow it will be even easier to DOS other's using low-latency applications. I expect a new cottage industry of game-disruptor services to crop up (you need so little traffic to cause hick-ups in the LL-queue that such attacks might not eben register with the ISPs alarm/monitoring system). That is my point, L4S has not been subjected to any meaningful adversarial testing, yet. I would have thought that you do this kinds of testing before you over-hype and release your product onto the internet but apparently the L4S folks believe in release first test/fix later...
1 Like
That will not work, as L4S claims to work for both low-latency and high throughput. And it operates a shallow queue so relative small traffic bursts are sufficient to drive it into unhealthy territory, where it needs to drop packets ...
Keep in mind, that these slides, just as the L4S RFC's are not objective assessments of the situation/design, but rather biased....
1 Like
one positive outcome of that meeting is someone let slip their pie implementation was in pure software. DOCSIS permits alternate queuing algos and for years now I've hoped one of the two remaining chipset makers in that market would call.
Broadcom was in the room, intel, wasn't.
In more direct answer to your question, the existing deployment of fq_codel, cake, etc, will observe little impact from a wider deployment of an l4s-style redefinition of CE. FQ is robust against much foolishness.
There are definately side-effects on inbound shaping however.
It is totally feasible to modify fq_codel to have l4s style signalling also. The existing ce_threshold code can be modified to do it. That said, we (the loyal opposition), think repurposing the bit as they propose is a really crazy idea, but in order to win this fight, more folk, from more clued companies, need to start showing up at meetings and on the mailing list. (hint, hint)
1 Like
One of my biggest concerns is that nobody's tested superpackets (GRO) as yet. There's no p for 1/p.
1 Like
I am with you, L4S is way under-tested on the lab bench, all the talk about roll-out is massively pre-mature, and probably driven by someones desire to inflate quarterly numbers or something.
I incidentally find even looking at their code kind of toxic, but when I looked over sch_dualpi.c it had major problems. As best as I recall.
I think it was a shared queue limit between the two queues, meaning that overdriving either led to loss in the "classic" queue first.
they didn't handle gro
a byte limit per queue made more sense
they defaulted to disabling ecn not at all even though the pie spec suggested drop at 10% probability.
Honestly I lack to intestinal fortitude to look again. And I could be wrong.
Would not amaze me, the L4S approach has always consistently been, claim peaceful coexistence, but make sure L4S gets the lion's share of low latency and throughput... (The underlaying premise that latency and throughput are orthogonal is simply at odds with the reality of packet-based networking at small timescales, their solution, claim orthogonality, but implement a L4S-first approach; because they want to incentivize people to actually use the L4S queue, and what is easier than making the non-LL queue simply worse this is partly in jest, but only partly).