>> There should be a knob in the kernel to transparently replace TCP with
>> MP-TCP, but I couldn't find one.
> There is, sorta. Specifically, a BPF hook that can override the protocol
> (added in kernel 6.6):
>
> https://lore.kernel.org/all/cover.1692147782.git.geliang.t...@suse.com/
So we're
Hi,
For those of you who don't remember, MP-TCP is an extension to TCP that
implements multipath, and can be used both for fast roaming (redundancy)
and for bandwidth aggregation. MP-TCP is able to cross NATs, and it can
reliably detect that TCP extensions are being corrupted by middleboxes and
> quic takes over
Now if only thay had gotten the layering right... such a terrible wasted
opportunity.
(SCTP forever!)
-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
>> I'm not sure how that could happen at boot time, it would need to
>> happen whenever a DHCPv4 lease changes. This implies that the router
>> might need to renumber if the ISP changes its allocation, and there are
>> no renumbering procedures for IPv4 (I'm not sure if anyone implements
>> RFC
> But my point is that the OpenWrt router has no way to predict what
> address/subnet will be assigned to its WAN port.
In principle, the ISP should assign either a global address, or an address in
the range 100.64.0.0/10 (RFC 6598). This range was deliberately chosen to
not collide with RFC
> (h++ps://github.com/network-quality/draft-ietf-ippm-responsiveness).
There's quite a few good ideas in this draft, but the one that I find
intriguing is reporting RTT values in RPM (units of 1/60 Hz) rather than
milliseconds.
I wonder how well this works. I'll experiment with undergrads.
--
> what apps do you have on the phone and what are they configured to update?
> that will make a huge difference.
It's not about my phone, it's about that of the author of the blog.
> 'idle' probably isn't nearly as passive as you think it is.
My personal phone is almost completely idle when I'm
Hi Dave!
> https://nickvsnetworking.com/mobile-ipv6-tax/
« This means my Android phone consumes 4.5 MB of cellular data in an hour
while sitting on the desk, with 16,889 packets in/out. »
So even discounting the headers, the phone receives 70 Commodore C64 worth
of data when idle. Every
> POISED was the result.
Could somebody please explain?
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
Hi Mikael,
> If it's not hw accelerated, it sucks.
Fortunately, that hasn't been true in a long time. Two data points.
The WND3700v2/WNDR3800, which is now over ten years old, can easily
forward 400Mbit/s NATed IPv4 (max-sized packets) in software. To be fair,
it can saturate 1Gbit/s with
> Recently Ryan Mounce added ack filtering cabilities to the cake qdisc.
> The benefits were pretty impressive at a 50x1 Down/Up ratio:
If I read this posting right, you're only measuring bulk performance.
What about interactive traffic, when there's only one or two data segments in
flight at a
> The better solution would of course be to have the TCP peeps change the
> way TCP works so that it sends fewer ACKs.
Which tends to perturb the way the TCP self-clocking feedback loop works,
and to break Nagle.
> In the TCP implementations I tcpdump regularily, it seems they send one
> ACK per
> In a previous life I did some work on the optimization (by remote
> proxying) of the SMB protocol used by Samba [...] Eventually we said
> the heck with it, and sat Samba on top of a different protocol entirely,
The audience are waiting with held breath for more details.
-- Juliusz
> Many would kill for a 10:1 DOCSIS connection. 50:1 is not rare, and I
> have personally been subscribed to a near 100:1 service.
Some people should not be allowed to design networks.
> The DOCSIS shaper deals with ethernet frames so 58 / 1518 bytes.
Could you please point me to details of the
> I can buy 300/10 megabit/s access from my cable provider.
Don't!
> If I understand correctly, DOCSIS has ~1ms sending opportunities
> upstream. So sending more than 1kPPS of ACKs is meaningless, as these ACKs
> will just come back to back at wire-speed as the CMTS receives them from
> the
>> I'm lost here. What exact problem is the ACK hack supposed to work
>> around? Ridiculous amount of asymmetry in the last-hop WiFi link, or
>> outrageous amounts of asymmetry in a transit link beyond the last hop?
> My understanding is that the issue that gave rise to this discussion was
>
> It might be preferred to modify EDCA parameters to reduce media access
> latencies for TCP acks rather than spoof them.
I'm lost here. What exact problem is the ACK hack supposed to work
around? Ridiculous amount of asymmetry in the last-hop WiFi link, or
outrageous amounts of asymmetry in a
>> It does increase single-flow TCP throughput by up to a factor of two,
>> though... Which everyone knows is the most important benchmark number ;)
> Were you always as cynical as I am?
(Giggle)
Dave, you've always underestimated Toke ;-)
___
Bloat
> Because the USB protocol
Jonathan, Dave,
Can you tell us a few words about SDIO Wifi modules? Do they have the
same issues? What's the latency like?
-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
> TL;DR - they seem to have all the elements in place to measure the
> latency during transfers. If they fix some of these problems, they'll
> have a winner.
No easy way to do both v4 and v6 tests -- you need to manually remove your
IPv6 default route in order to test v4.
-- Juliusz
>> Oh, and of course HAS is in itself a hack to work around badly managed
>> queues in the network. In a nicely fairness queued world, we could do
>> away with HAS entirely and just, y'know, stream things at the desired
>> rate...
Perhaps I'm missing something -- how do you to pick the right rate
> http://the-edge.taht.net/post/starttls_considered_helpful/
Did you bounce mail when the first MX contacted didn't do STARTTLS, or did
you bounce when none of the MXes for a domain supported it? In other
words, did you treat lack of STARTTLS as a transient or permanent error?
-- Juliusz
That was fun.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
I'm currently away from home, and using a 3G modem for Internet access.
I've found out that both NetworkManager and wvdial/pppd setup the
interface to use pfifo_fast (with a qlen of a mere 3 packets!). Setting
fq_codel manually appears to work fine, but needs to be redone every time
the modem has
What distro are you on?
Debian. (One machine stable, one testing.)
There's a sysctl to set the default qdisc: net.core.default_qdisc.
$ sysctl -a | grep default_qdisc
net.core.default_qdisc = pfifo_fast
Set this to fq_codel and you should be good to go.
Is that safe? I'm thinking
Debian. (One machine stable, one testing.)
Right. Don't know if there's already an effort to convince the Debian
devs to switch the default...
Please file a bug against the procps package (which owns the sysctl.conf
file). Just send a mail describing the issue and the proposed fix to
It also appeared to show that transmission chose one and only one of the
ipv6 addresses available on this box.
Yes. My code explicitly binds the UDPv6 socket to a single address.
I've just been informed by a reliable source that Vuze's mldht plugin
does not suffer from this issue -- it
To add to what my honourable prelocutors have said, µTP, which is used by
modern BitTorrent implementations, uses the LEDBAT congestion control
algorithm, which is based on delay. The fact that LEDBAT is crowded out
by Reno is a desirable feature in this case -- you do want your BitTorrent
amount of buffering depends on the kernel latency, and hence should be
better done by the kernel itself.
Unless you have thousands of tcp flows maybe, where (unswapable) kernel
memory becomes a precious resource.
Thanks, that makes sense.
-- Juliusz
[Removed bloat-devel from the CC]
[1] Already sent data [...]
[2] Not sent data.
[...]
While NOTSENT_LOWAT is able to restrict (2) only, avoiding filling write
queue when/if no drops are actually seen.
Thanks for the explanation, Eric.
Do you have any concrete examples where this has
[Removed AQM from CC.]
4) *All* the traffic was udp. (uTP)
Yes, modern BitTorrent implementations prefer µTP to TCP. Unfortunately,
the implementation of µTP in Transmission doesn't perform PMTUD, and gets
packet sizes wrong most of the time. (Yes, I spoke about this to Arvid.
No, he
I am curious if anyone has tried this new socket option in appropriate apps,
I'm probably confused, but I don't see how this is different from setting
SO_SNDBUF. I realise that's lower in the stack, but it should have
a similar effect, shouldn't it?
-- Juliusz
Free.fr (Proxad) is certainly much better than other ISPs -- they've been
the first to give sort-of-native (6rd) IPv6 to the masses. However,
there's one thing that annoys me -- they have two distinct CPEs, the
classic FreeBox (which I have) and the FreeBox Revolution (which is
slightly less
1) The core flaw in the work was that they targeted really long RTTs
(100ms) where here we are working in a range of RTTs, mostly shorter.
Yeah. They were doing experiments with LTE, which has pretty horrendous
latency. (As in driving around Cambridge with an LTE modem and collecting
packet
Evidence of a quiet crisis in science is mounting.
Nothing new here -- confirmation bias and society pressures have always
been the two main problems of science. To quote Richard Feynman:
One example: Millikan measured the charge on an electron by an
experiment with falling oil drops, and
The conclusion of the thread was amusing, in that with the new
sch_fq scheduler with a single hardware queue (and a string
of fixes over the past year for tcp small queues and tso offloads),
performed as well as the multi queue implementation...
On a 1Gb/s link.
-- Juliusz
Dave Taht wrote:
http://www.spinics.net/lists/netdev/msg264935.html
Hat off to vijay and the pie folk at cisco who shepherded the code
through 5 releases to get it upstream!
Excellent. Somebody please update
http://en.wikipedia.org/wiki/Active_queue_management
Is any experimental data
http://cs.ucsb.edu/~laradeek/Secon13.pdf
Do you understand why ARAMIS with training performs so much better than
Minstrel in the
20 MHz interferer case?
--jch
___
Bloat mailing list
Bloat@lists.bufferbloat.net
The promise of fq_codel is that we can get rid of our prioritising
hacks -- if we need that kind of features, then fq_codel has
failed.
Is that really true? given enough concurrent flows, critical flows
might be delayed purely be the round robin scheduling of equally
worthy packets in
I think that the WNDR3800 should be able to push a gigabit, even with NAT.
No, it tops out at about 330Mbit/sec currently with no firewall rules,
no nat.
Full-size frames? That sucks. (And thanks for the hard data.)
No. aqm-scripts can't push 110KB/sec through *HTB*.
Typo?
The rate
Perhaps you should push your system to OpenWRT?
There is still some work going on to streamline the gui.
Fair enough. That's important.
there are less features in the aqm-scripts for prioritizing packet
types than qos-scripts.
I wouldn't bother much with that. The promise of fq_codel is
I note that openwrt's qos-scripts still do not do ipv6 properly, and I think
cerowrt's aqm system is better in most respects, and it's easy to
include on an openwrt system.
Perhaps you should push your system to OpenWRT?
-- Juliusz
___
Bloat mailing
Dear all,
Baptiste Jonglez' memoir about his work on an RTT-based metric for the
Babel routing protocol, in English, is available from
http://www.pps.univ-paris-diderot.fr/~jch/research/rapport-jonglez-2013.pdf
Pretty figures are in Section 5 and Appendix C. I'm particularly keen
on Figures
---BeginMessage---
Hi,
While experimenting with the RTT-aware branch of babeld, I ran into an
odd but interesting behaviour: between two given hosts reachable over
the Internet, the RTT is more stable inside a GRE tunnel than outside.
I've measured the RTT between the two hosts (with a simple
While experimenting with the RTT-aware branch of babeld, I ran into an
odd but interesting behaviour: between two given hosts reachable over
the Internet, the RTT is more stable inside a GRE tunnel than outside.
The RTT is around 300 ms for both kinds of packets. GRE packets have
virtually no
But it is hard, and the delay based algorithms are fundamentally
flawed because they see reverse path delay and cross traffic as false
positives.
I'm not sure what you mean. All modern delay-based congestion
algorithms that I am aware of use one-way delay as an indicator of
congestion, not
All modern delay-based congestion algorithms that I am aware of use
one-way delay as an indicator of congestion, not RTT.
It depends on what you define as modern [...] Vegas? Yeah-TCP? Nope.
Vegas is some 20 years old, if memory serves. I'm not familiar with Yeah-TCP.
(TCP-LP and LEDBAT
There is an API to set ECN on UDP packets.
setsockopt() IP_TOS, with val = 2
Interesting, I didn't realise that. Is it also possible to read the ECN
bits?
-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
Doesn't work on ingress presently, if you are using ifb (I can be wrong).
?
-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
however they assume a lot of prior knowledge. I'd like to set up mesh
networking where I simply add routers to extend the mesh.
I would suggest that you use an ordinary Linux distribution to set up
your first AHCP server, following the instructions in the upstream ahcpd
readme[1]. Once you've
It really seems that ECN support could be added generically for all
qdiscs that currently do packet drop. Creating a generic mark_or_drop
function is easy.
As hinted in a previous message -- please don't. Every qdisc must be
examined individually to check if it is suitable for ECN.
Consider
So there have been no packets dropped and there is no backlog and the
path is clean all the way to the Internet without any congestion in my
network (the path is currently about 5 times bigger than current
bandwidth utilization and is 10GigE all the way from the switch to
which the server is
And the irony is that the lower speed is specifically chosen for
multicast in order to make sure all clients in range can hear them
reliably.
It was my understanding that it was done for compatibility with older
devices, since 2 Mbit/s is the fastest rate supported by pre-B
spread-spectrum
Internet (100Mbps ethernet capped to 70Mbps by the ISP):
tc qdisc add dev eth4 parent 1:3 handle 13: sfb hash-type source limit 100
target 10 max 15 penalty_rate 60
And on the internal interfaces (1Gbps ethernet) to clients like this:
tc qdisc add dev ${DEV} parent 50:20 handle 52: sfb
Result - 130+Mbit performance on iperf on the lan (up from 60Mbit),
which is still pretty low
Are you seeing high CPU load in interrupt context? (Run top.)
-- Juliusz
___
Bloat mailing list
Bloat@lists.bufferbloat.net
Are you seeing high CPU load in interrupt context? (Run top.)
Yes. 99% sirq.
Could be due to a simplistic Ethernet driver. If you have the time and
energy, you may want to ask on dev.openwrt.org.
-- Juliusz
___
Bloat mailing list
ecn is not being negotiated on tcp connections to SA(??),
That's unfortunately pretty common. A common practice is to clear any
priority information in packets coming into your network; unfortunately,
a lot of routers clear the whole DSCP byte, including the ECN bits.
-- Juliusz
SFB is also in this release, but lacking good scripts for it...
SFB is supposed to be self-tuning, so it should be enough to say
something like:
#!/bin/sh
set -e
if=${1:-eth0}
tc -s qdisc del root dev $if 2/dev/null || true
tc -s qdisc add dev $if root handle 1: tbf ...
tc -s
regretablly the SFB patches to tc didn't make this release of 'bismark
captown', just the SFB kernel backport to 2.6.37.6.
You probably already know that -- but you do *not* need to patch tc in
order to run SFB with the default parameters. (You need to patch tc if
you want to run SFB with
59 matches
Mail list logo
