5 ms·
TCP is also concerned with fairness (after Van Jacobson's famous paper[1]). We've long known that you can batter data through the network at speed if you don't
by rwmj 3y ago
TCP is also concerned with fairness (after Van Jacobson's famous paper[1]). We've long known that you can batter data through the network at speed if you don't care about other users. How does QUIC preserve fairness?
[1] https://inst.eecs.berkeley.edu/~cs162/fa23/static/readings/jacobson-congestion.pdf https://inst.eecs.berkeley.edu/~cs162/fa23/static/readings/j...
- bheadmaster 3y agoAccording to this random document I found on the internet [0], in section 7., QUIC implements a congestion control system similar to TCP New Reno. [0] https://quicwg.org/base-drafts/rfc9002.html https://quicwg.org/base-drafts/rfc9002.html
- hlandau 3y agoMore precisely - it suggests one. Just like for TCP (see the myriad number of algorithms available for Linux's TCP stack) you can choose whatever congestion control strategy you want.
- Borg3 3y agoFairness? 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.
- mort96 3y agoISP 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!
- ithkuil 3y agoSlower 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.
- Borg3 3y agoOh, 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.
- ithkuil 3y agoLatency 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
- ajb 3y agoThat'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 https://datatracker.ietf.org/doc/html/rfc7567 for the current best practice
- lxgr 3y agoISPs 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!
- Veserv 3y agoCongestion control is largely orthogonal to transport protocol design. You can basically slap the general shape of any congestion control algorithm onto whatever transport protocol you want. Their interaction is largely at the level of: “How easy does the protocol make it to estimate the data channel parameters?”, “What happens in the event of congestion-related failures (packet loss, delay, reorder, etc)?”, and “How do you efficiently recover and adapt to the new channel parameters?” In all of these regards QUIC is quite a bit better than TCP.
- actionfromafar 3y agoAll this QUIC talk makes me think of tape backups. Wonder if a tape backup could be devised which was inspired by network congestion algorithms - i.e. if a section of bad tape was discovered, the same data would get "resent" - to tape! Until it read back correctly (by a read head just behind the write head). This way, the overall tape data density could be increased even if it would mean occasional dropouts. Maybe this is already how modern tape drives work?
- Veserv 3y agoTransparently remapping good storage over bad storage to deal with faulty sectors is standard practice in hard disk drives and solid state drives. It was historically done in software, though these days it is largely done in the drive microcontrollers directly. Tape drives almost certainly use similar techniques.
- HankB99 3y agoWikipedia confirms that IBM introduced this in 1958. > Separate read/write heads providing transparent read-after-write verification.
- actionfromafar 3y agoThere's a general IBM theme of "whatever tech we come up with", IBM did it first, a very long time ago, they have their own name for it, and everyone else "discovers" it years or decades later.
- 01HNNWZ0MV43FF 3y agoIt seems like a bug in the middlebox if it requires all end points to cooperate and doesn't throttle anyone. I thought the point of congestion control was to slow down pointless sending when an overloaded middle box is dropping our packets and saying "buddy take the hint", not to actually yield to other traffic? The network tells us how much capacity we have, trying to push more would just increase our own stream's packet loss. ... Right?