Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Fairness? It seems noone gives a shit about it. Most consumers want their data now. I have ETTH 100Mbit (with is very fast to my standards) and I can tell the difference between day, evening and weekend just by pinging my nodes. RTT is stable offhours, but in normal day jitter kicks in. It sad to see RTT jump from 9 to 90ms over major IX. Everything seems to be overbooked horribly.

I know that Internet is best effort network (ATM, anyone remember it?) but Im sure I would preffer slower but more stable internet.



ISP overprovisioning is a completely different issue from fair congestion control algorithms... every device involved can be using totally fair congestion control algorithms and an overprovisioned network will still see degraded performance. I mean that's literally the point of fair congestion control algorithms, make it so that the overprovisioned network still works and everyone's performance degrades roughly evenly!


Slower by how much?

Would 90ms be ok for you?

There you have it!

If you don't want to accidentally get used to 9ms, just add a traffic shaper on your end to slow down your network.

You can't change the fact that during peak activity there are so many people who send so many packets and saturate the bandwidth in such a way that the current fair congestion protocols allocate you the bandwidth and latency profile you observe.


Oh, belive me, I have very decent QoS on my side. Using combination of HTB and sfq+pfifo for traffic. I can download/upload and jitter wont go more than 2ms.

Problem is on ISP side. They seems to have over provisioned network that cannot handle peak loads. Oh well, here we go, everyone selling 300-1000Mbit connections on left and right.

You also seems to confuse bandwith with ping (rtt). Thats not related. I would be happy with 10Mbit connection that have stable RTT.


Latency and bandwidth are not completely unrelated.

When you saturate the available bandwidth you simply cannot send more packets through the same channel so the only option is to queue (or drop and resend later), which means the packet will be delivered later.

You seem to be describing a severe congestion at the ISP side due to your ISP not having enough bandwidth to handle their peak load. Surely, they could work smarter and selectively shape the traffic so that they drop the traffic you think is less important than yours but a) they may have crappy traffic shaping infrastructure b) they may not agree with your characterization of traffic priorities and they will rather not throttle video streaming or whatnot.

EDIT: my point is that it's very hard to actually know what's the cause for the high latency unless you actually work for the ISP. Several causes can have the same observables


That's probably due to the absence of an effective AQM as the bottleneck, rather than the transport protocols being unfair. See https://datatracker.ietf.org/doc/html/rfc7567 for the current best practice


ISPs usually don't perform congestion control by simply dropping packets (and hoping that the affected flows will scale down fairly).

At the edge (where congestion is most likely), they'll usually enforce some type of QoS or just round-robin scheduling, which means whatever greedy congestion control algorithm you use, you'll at most be able to hog 1/N of the available throughput.

If the congestion happens further inside the ISPs backbone, the solution is usually to upgrade that component instead.

Where fairness can matter is inside a home network: If the upstream router doesn’t do anything about it, it is possible for a greedy flow to force out other competing flows. But you don’t need any fancy non-TCP protocols for that: Just open tons of TCP flows. The solution there is to yell at your roommates to stop the torrenting immediately, you have an important Zoom call, damnit!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: