4 ms·
Congestion control is largely orthogonal to transport protocol design. You can basically slap the general shape of any congestion control algorithm onto whateve
by Veserv 3y ago
Congestion 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.
- Karellen 3y ago> It was historically done in software, though these days it is largely done in the drive microcontrollers directly. It's still software on the drive microcontrollers, though. The only difference is it's software you can't see, reason about, upgrade, improve, or fix.
- RiverCrochet 3y agoIf a modern "one-shot" tape drive encounters an error during write, it will write the data again as the tape is moving. You lose a little bit of total capacity, but the data will still get written. This is why you always plan to write a little less than the full capacity of your tape. Newer LTOs may behave a little differently, I haven't kept up with newer stuff here.
- londons_explore 3y agoBuuuut.... If you're running a big web-app (eg. tiktok) you have a business incentive to not be fair. If your servers can push more data down the users slow internet connection, your service will get better load times, while competitors services sharing the same network link (ie. your brother in the next door bedroom on youtube) will stutter and lose users.
- Spivak 3y agoYou can already do that with TCP so it's not that big of a change.
- Karrot_Kream 3y agoI'm not sure what you mean. If you're talking about video delivery, TikTok is using HLS, so the client is initiating the download. Are you saying that the server will attempt to multiplex across QUIC streams and overwhelm the client?
- londons_explore 3y agoThe server can deliberately send packets down those QUIC streams faster than the protocol would normally. Typically that results in the client getting their download faster, but harming other users on the network (whose downloads slow down)
- Karrot_Kream 3y agoThat doesn't make any sense to me. What do you mean by "on the network"? Is your claim that using UDP will somehow saturate a shared circuit between multiple subscribers? What's stopping the switch from just dropping excess packets for one destination?
- londons_explore 3y ago> your claim that using UDP will somehow saturate a shared circuit between multiple subscribers? Yes. And it isn't specific to UDP. Basically any file transfer will keep going faster till at least one network segment is saturated. At that point, if the server keeps sending data a little faster than a regular congestion control algorithm would allow, you will cause packets from other users streams to be dropped.