[HN Gopher] Timeliness without datagrams using QUIC
___________________________________________________________________
Timeliness without datagrams using QUIC
Author : wofo
Score : 141 points
Date : 2024-06-23 09:40 UTC (13 hours ago)
(HTM) web link (quic.video)
(TXT) w3m dump (quic.video)
| forrestthewoods wrote:
| It mentions that the video game industry uses UDP but then fails
| to further address that use case. So, should competitive shooter
| video games switch to QUIC? Is that even supported across all the
| various gaming platforms?
| swiftcoder wrote:
| > It mentions that the video game industry uses UDP but then
| fails to further address that use case
|
| Video games tend to use UDP for the same reason everyone else
| mentioned does: timeliness. You want the most recent position
| of the various game objects _now_ , and you don't give a shit
| about where they were 100ms ago.
|
| The proposed solution of segmenting data into QUIC streams and
| mucking with priorities should work just fine for a game.
|
| > Is that even supported across all the various gaming
| platforms?
|
| QUIC itself is implemented in terms of datagrams, so if you
| have datagrams, you can have QUIC.
| chrisfarms wrote:
| > Video games tend to use UDP for the same reason everyone
| else mentioned does: timeliness. You want the most recent
| position of the various game objects now, and you don't give
| a shit about where they were 100ms ago.
|
| This is only true for games that can replicate their entire
| state in each packet.
|
| There are many situations where this is infeasible and so you
| may be replicating diffs of the state, partial state, or even
| replicating the player inputs instead of any state at all.
|
| In those cases the "latest" packet is not necessarily enough,
| the "timliness" property does not quite cover the
| requirements, and like with most things, it's a "it depends".
| swiftcoder wrote:
| With those requirements raw datagrams also don't fit the
| bill, so you'll need to build some sort of reliable stream
| abstraction over UDP (with optional unreliable delivery for
| the state which you can replicate quickly)... and now we're
| closing in on QUIC territory
| CJefferson wrote:
| I thought QUIC promised you get your data eventually? In that
| case it wouldn't be great for games, because you usually
| don't want packets that got dropped, as the next packet will
| replace it anyway?
| swiftcoder wrote:
| > I thought QUIC promised you get your data eventually?
|
| QUIC optionally promises you that, you are free to opt out.
| For example, take a look at the
| QUIC_SEND_FLAG_CANCEL_ON_LOSS flag on Microsoft's QUIC
| implementation.
| Tuna-Fish wrote:
| But the proposed solution provides no value over datagrams,
| while it has plenty of downsides.
|
| Let me rephrase the problem here for a simple FPS game:
|
| The entire world state (or, the subset that the client is
| supposed to know about) is provided in each packet sent from
| the server. The last few actions with timestamps are in each
| packet sent from the client. You always want to have the
| latest of each, with lowest possible latency. Both sides send
| one packet per tick.
|
| You do not want retransmission based on the knowledge that a
| packet was lost (the RTT is _way_ too long for the
| information that a packet was lost to ever be useful, you
| just retransmit everything every tick), you do not want
| congestion control (total bandwidth is negligible, and if
| there is too much packet loss to maintain what is required,
| there is no possible solution to maintain sufficient
| performance and you shouldn 't even try), and none of the
| other features talked about in the post add anything of
| value, either.
|
| It reads like someone really likes QUIC, it fit well into
| their problems, and they are a bit too enthusiastic about
| evangelizing it.
| swiftcoder wrote:
| In practice most games _also_ need reliable side channels
| for control messages /chat/etc, and so they end up building
| optional reliable streams over UDP... and at the end of
| this path lies something that looks a lot like a (less
| thoroughly designed/tested) version of QUIC
| forrestthewoods wrote:
| My spidey sense is that almost all games used a custom
| UDP solution. I could be wrong! I made a Twitter poll to
| try and get info.
|
| You're right that a custom reliable UDP solution is going
| to wind up QUIC-like. On the other hand it's what games
| have been doing for over 20 years. It's not particularly
| difficult to write a custom layer that does exactly what
| a given project needs.
|
| I don't enough about QUIC to know if it adds unnecessary
| complexity or not.
| paradox460 wrote:
| Tribes, and various quake mods, used to use a TCP side
| channel for chat and control messages. Tribes famously
| used irc, and you could connect to a tribes server with
| any irc client to chat with your friends in game
| intelVISA wrote:
| No, QUIC is mostly for Google to enforce E2E advertisment.
| Retr0id wrote:
| QUIC is implemented in userspace, it doesn't need platform
| support beyond the basic networking stack.
| blueflow wrote:
| What should be based on datagrams:
|
| - Local discovery (DHCP, slaac, UPnP, mDNS, tinc, bittorrent)
|
| - Broadcasts (Local network streaming)
|
| - Package encapsulation (wireguard, IPSec, OpenVPN, vlan)
| promiseofbeans wrote:
| Hey I'm sure you're right, but as someone with less low-level
| networking expertise, I was wondering if you could explain why
| you'd want datagrams for these use-cases?
| swiftcoder wrote:
| Local discovery is itself based on broadcast/multicast, both
| of which only work over UDP (TCP doesn't provide any
| mechanism for broadcast streams).
| blueflow wrote:
| TCP is a back & forth between two hosts and thus cant do
| "shouting blindly into the network" things. That rules out
| local discovery and media broadcast.
|
| Package encapsulation is bad over TCP because if the
| encapsulated data is TCP itself, you have congestion control
| twice. On congested networks, this results in extra slowdowns
| that can make the connection unusable.
| Hikikomori wrote:
| And games.
| swiftcoder wrote:
| The whole point of the article is that you don't _need_ to go
| all the way down to raw datagrams to achieve the kind of low
| latency that is needed for things like games
| /VOIP/livestreaming
| eru wrote:
| It totally depends on the kind of game.
| ajb wrote:
| One missing from your list is real-time media. Retransmission,
| or even just buffering for reordering, adds latency so it's
| better to take the hit of a loss with error correction or
| packet-loss-concealment
| promiseofbeans wrote:
| We use straight UDP datagrams for streaming high-frequency sensor
| data. One of our R&D people built a new system that uses quic and
| solves most of our problems with out-of-order delivery. We still
| use datagrams over UDP for everything because we have to support
| some 3rd party sensors out of the box without adapters, and UDP
| is all they can do.
| jcelerier wrote:
| Also pretty much every media art system in the world just uses
| OSC over UDP
| jesprenj wrote:
| And ArtNet also over UDP.
| Almondsetat wrote:
| Yeah, high frequency sensor data was on my mind too. Do you
| have any figures on the power saved wrt TCP?
| songbird23 wrote:
| what language was the system build with? thats super cool!
| Joel_Mckay wrote:
| "solves most of our problems"
|
| Indeed, until the problems it creates begin to feature.
|
| Have a great day =3
| asdefghyk wrote:
| Maybe ... never use on a congested network.
|
| or Never use on a network where congestion is above a certain
| level
|
| or Never us on a network where this parameter is above a certain
| level - like network latency
|
| or only use on a LAN not a WAN ....?
| swiftcoder wrote:
| Unless you are building software for a pre-established
| intranet, how do you predict ahead of time whether your
| software will run on congested networks?
|
| Most end-user software ends up running on a variety of
| oversubscribed wifi and cell networks
| smcameron wrote:
| > how do you predict ahead of time whether your software will
| run on congested networks?
|
| One thing you can do is build in "bad network emulation" into
| your software, allowing the various pieces to drop packets,
| delay packets, reorder packets, etc. and make sure it still
| behaves reasonably with all this garbage turned up.
| ot wrote:
| LAN can be oversubscribed too, even if your switches have
| sufficient capacity you can have short packet bursts that fill
| up the queues. You cannot assume reliable delivery.
| FpUser wrote:
| I use UDP for my desktop game like software with clients all over
| the world to propagate anonymized state. It needs no encryption
| as the transmitted data has zero value to any third party. It
| needs no reliability since dropped packets would be handled by
| predictive filter with practical reliability that is way more
| than needed.
|
| So why the F.. would I bother with anything else?
| aarmot wrote:
| Because author of the article likes to be edgy and parrot the
| deep truth he learned yesterday - that TCP is "reliable" and
| UDP is not.
|
| The reality, of course, is somewhat different and muddy. For
| example, if you have network outage following later by a
| software crash or a reboot, then all the TCP buffer worth of
| data (several kilobytes or upto some megabytes - depends on
| your tuning) is mercilessly dropped. And your application
| thinks that just because you used TCP the data must have been
| reliably delieved. To combat this you have to implement some
| kind of serializing and acking - but the article scoffs us that
| we are too dumb to implement anything besides basic stream /s
|
| I'm not arguing that TCP is useless, just that UDP has its
| place and we - mere mortals - can use is too. Where
| appropriate.
| Lerc wrote:
| The thing is, when you need that low latency, you don't want
| most of the features of more robust streams.
|
| When you are using UDP the correct way to handle out of order
| delivery is to just ignore the older packet. It's old and
| consequently out of date.
|
| Figuring out how to solve any mess caused by mistransmission
| necessarily has to be done at the application level because
| that's where the most up to date data is.
| ben0x539 wrote:
| The author (disclaimer: former coworker) has likely learned
| about UDP before yesterday because he's been complaining
| about TCP for years.
| vitus wrote:
| > Because author of the article likes to be edgy and parrot
| the deep truth he learned yesterday
|
| I will point out that "author of the article" is one of the
| core contributors in the IETF Media-over-QUIC working group
| (which is an effort to standardize how one might build these
| real-time applications over QUIC) and has been working in the
| real-time media protocols space for 10+ years.
|
| The author recognizes that the title is clickbait, but the
| key point of the article is that you probably don't want to
| use raw UDP in most cases. Not that UDP is inherently bad
| (otherwise he wouldn't be working on improving QUIC).
| ralferoo wrote:
| You might want some form of encryption or message signing to
| prevent spoofed packet injection. Just because the data might
| not have value to a third party, knowing that the data is
| legitimate has value to you.
| FpUser wrote:
| Arguments like this should have practical value for business.
| For my business the value is zilch. It is simply not worth it
| for the hacker to mess with my packet server. I've been
| running it for 10 years with 0 complaints. And the worst they
| can do is to temporarily annoy few people. And yes I
| implement simple proprietary form packet of signing. It took
| me whole few minutes to develop.
| ralferoo wrote:
| Many games are popular targets for griefers or DDOS
| attacks, not because the attacker gains anything of value
| from the attack (and many of them aren't actually hackers,
| they just download the tools written by others), but
| instead they do it solely for the perverse happiness they
| get from knowing that they ruined someone else's day / hour
| / minute.
|
| Possibly you just haven't seen this problem yet because
| your game isn't high-profile enough for them to bother with
| and it doesn't provide enough amusement for them to get a
| kick out of it.
| FpUser wrote:
| It is game like by tech used but is not really a game.
| Unlikely to be noticed. When IF it ever does I'll worry
| about it the, Not too difficult as there are libs just
| for that. For now my simple signing works like a charm.
| ggm wrote:
| Quic is implemented over UDP. It's literally running over
| datagrams.
| ot wrote:
| Everything at some layer has to run over datagrams, since
| that's what IP is.
|
| This is literally the point of the article: if you want to
| create a protocol over raw datagrams, you have to implement a
| lot of things that are very hard to get right, so you should
| just use QUIC instead, which does them for you.
| ggm wrote:
| "You" is doing all the hard work. Apps should use reliable
| sessions and transport, almost all the time? No disagree. The
| exceptions are understood. But don't pretend the substrate is
| that reliable data stream. "We" have to construct it almost
| always. We do reliable for you, over UDP.
|
| I don't do this stuff any more, but I worked on OSI transport
| and remote operations service mapped to UDP and other
| protocols back in the 80s
| PhilipRoman wrote:
| IMO stream abstractions make it too convenient to write fragile
| programs which are slow to recover from disconnections (if they
| do at all) and generally place too many restrictions on the
| transport layer. Congestion control is definitely needed but
| everything else seems questionable.
|
| In a datagram-first world we would have no issue bonding any
| number of data links with very high efficiency or seamlessly
| roaming across network boundaries without dropping connections.
| Many types of applications can handle out-of-order frames with
| zero overhead and would work much faster if written for the UDP
| model.
| CJefferson wrote:
| Out of interest, what kind of applications are you thinking of?
| What systems are common written using TCP, that could switch to
| UDP?
|
| Clearly websites, audio and video generally don't work with
| out-of-order frames -- most people don't want dropped audio and
| video.
|
| Some video games are happy to ignore missed packets, but when
| they can they are already written in UDP.
| ansgri wrote:
| Any data block that must be fully received before processing
| comes to mind (e.g. websites' html), just request
| retransmission of parts that didn't make it in first pass.
| Funnily enough it's (realtime) video and audio that already
| uses UDP due to preferring timely data to complete data.
|
| On the contrary, for me it's hard to imagine video game with
| missed packets as the state can get out of sync too easily,
| you'll need eventual consistency via retransmission or some
| clever data structures (I know least about this domain
| though)
| smcameron wrote:
| I'm not expert in this area, but my understanding is that
| for latency sensitive video games, on the client side,
| state is predicted between updates, e.g. the state may be
| updated via the network, at say, roughly 10Hz (probably
| faster, but probably less than 60Hz), but updated locally
| at 60Hz via interpolation, dead reckoning and other
| predictive/smoothing heuristics, a few missed updates just
| means a bit more prediction is used. "State" is not usually
| transmitted as one lump "frame" at a time, but rather per-
| game unit (per spaceship, asteroid, robot, or whatever is
| in the game) or per some-small-group of units. When some
| updates are delayed too long, you might get some visible
| artifacts, "rubber-banding", "teleportation" or "warping",
| etc. often lumped together by players under the umbrella
| term "lag". For out-of-order packets, older packets might
| be dropped as newer packets may already have been applied
| to the state of some game units (typically there's some
| timestamps or monotonically increasing counter associated
| with state updates for each unit used by the
| prediction/interpolation/smoothing heuristics) and the
| state is usually represented in absolute terms rather than
| relative terms (e.g. (x,y) = (100,100), rather than x+=10,
| y+=10, so that any update may be applied in isolation.)
| CJefferson wrote:
| Many video games just transmit the whole state the player
| should be able to see every tick. While some games send a
| diff of some kind, sometimes that turns out to not be worth
| it. This is particularly true in the games which care most
| about lag (think mario kart, or street fighter and
| friends).
| eru wrote:
| > Congestion control is definitely needed but everything else
| seems questionable.
|
| Even congestion control can be optional for some applications
| with the right error correcting code. (Though if you have a
| narrow bottleneck somewhere in your connection, I guess it
| doesn't make too much sense to produce lots and lots more
| packages that will just be discarded at the bottleneck.)
| debugnik wrote:
| As mentioned in the article, this doesn't handle the case of
| buffer bloat: packets all eventually arrive rather than being
| dropped, but increasingly late, and only backing off can help
| reduce the latency.
| Aurornis wrote:
| > In a datagram-first world we would have no issue bonding any
| number of data links with very high efficiency or seamlessly
| roaming across network boundaries without dropping connections.
| Many types of applications can handle out-of-order frames with
| zero overhead and would work much faster if written for the UDP
| model.
|
| So your argument is that software isn't written well because
| TCP is too convenient, but we're supposed to believe that a
| substantially more complicated datagram-first world would have
| perfectly robust and efficient software?
|
| In practice, moving to less reliable transports doesn't make
| software automatically more reliable or more efficient. It
| actually introduces a huge number of failure modes and
| complexities that teams would have to deal with.
| sunk1st wrote:
| It's true that a stream-oriented abstraction puts constraints
| on the communication channel that don't exist for a datagram
| oriented protocol.
| bitcharmer wrote:
| This is a narrow way of looking at UDP applications. The whole
| HFT, low-latency fintech world is built on top of datagrams.
| Using TCP would be pure the worst choice possible.
| AtlasBarfed wrote:
| Is that because they mostly use dedicated links and intranets?
|
| A lot of Enterprise messaging is based on UDP, I think on the
| presumption that corporate networks are just simply going to be
| a lot more reliable
| adunk wrote:
| This may seem like a minor nit, but I think there is a problem
| with using the term "unreliable" to describe UDP. The more
| commonly used term, and IMHO better term, is "best-effort" [1].
| UDP makes its best effort to deliver the datagrams, but the
| datagrams may be dropped anyway. But it does not make UDP
| inherently unreliable.
|
| [1] https://en.wikipedia.org/wiki/Best-effort_delivery
| vitus wrote:
| IMO "best-effort" is euphemistic and confusing to people
| outside of this space, even (especially?) to native English
| speakers. (I would probably have described UDP as "reasonable
| effort" and TCP as "best effort", if not for the existing
| terminology.)
|
| I recall my computer networking professor describing this as
| "Best-effort means never having to say you're sorry". In
| practice, best-effort does not mean you try your hardest to
| make sure the message gets from A to B, it means that you made
| _an_ effort. Router in the path was congested? Link flap
| leading to blackholing on the order of 50ms before fast reroute
| kicks in? Oh well, we tried.
|
| Meanwhile, TCP's reliable delivery will retry several times and
| will present an in-order data stream to the application.
|
| Reliable vs unreliable might be bad terminology, but I don't
| think best-effort is any better.
|
| My experience with unreliable systems is that they're great
| something like 95% of the time, and they're great for raw
| throughput, but there are many cases where that last 5% makes a
| huge difference.
| eru wrote:
| The question is 'who deals with dropped packages'? In TCP,
| the answer is: 'the protocol'. In UDP the answer is 'the next
| layer of abstraction' (eg the app or some library).
|
| You can build a 'reliable' protocol on top of UDP, and still
| not get TCP.
|
| Eg if you want to transfer a large file that you know up
| front, then TCP's streaming mechanism doesn't make too much
| sense. You could use something like UDP to send the whole
| file from A to B in little chunks once, and at the end B can
| tell A what (numbered) chunks she's missing.
|
| There's no reason to hold off on sending chunk n+1 of the
| file, just because chunk n hasn't arrived yet.
| vitus wrote:
| > There's no reason to hold off on sending chunk n+1 of the
| file, just because chunk n hasn't arrived yet.
|
| Congestion control comes to mind -- you don't necessarily
| know what rate the network supports if you don't have a
| feedback mechanism to let you know when you're sending too
| fast. Congestion control is one of those things where sure,
| you can individually cheat and possibly achieve better
| performance at everyone else's expense, but if everyone
| does it, then you'll run into congestive collapse.
|
| > You can build a 'reliable' protocol on top of UDP, and
| still not get TCP.
|
| I agree -- there are reliable protocols running on top of
| UDP (e.g. QUIC, SCTP) that do not behave exactly like TCP.
| You don't need an in-order stream in the described use case
| of bulk file transfer. You certainly don't need head-of-
| line blocking.
|
| But there are many details and interactions that you and I
| wouldn't realize or get right on the first try. I would
| rather not relearn all of those lessons from the past 50+
| years.
| lxgr wrote:
| TCP kind of supports that with selective acknowledgements
| these days, I think.
| vitus wrote:
| SACKs have been in TCP for 25-30 years now (Widely
| adopted as part of New Reno, although RFC 2018 proposed
| the TCP option and implementation back in 1996).
|
| That said, the typical reason why TCP doesn't send packet
| N+1 is because its congestion window is full.
|
| There is a related problem known as head-of-line blocking
| where the application won't receive packet N+1 from the
| kernel until packet N has been received, as a consequence
| of TCP delivering that in-order stream of bytes.
| atombender wrote:
| Is there a popular protocol that uses this scheme today?
| I've often thought that this would be a superior way to
| transfer/sync data. and have always wondered why it wasn't
| common.
|
| The closest I can think of is the old FSP protocol, which
| never really saw wide use. The client would request each
| individual chunk by offset, and if a chunk got lost, it
| could re-request it. But that's not quite the same thing.
| kazinator wrote:
| The term "best effort delivery" in networking is a weasel term
| that is no better than "unreliable". It should probably be
| burned.
|
| "Effort" generally refers to some sort of persistence in the
| face of difficulty. Dropping a packet upon encountering a
| resource problem isn't effort, let alone best effort.
|
| The way "best effort" is used in networking is quite at odds
| with the "best efforts" legal/business term, which denotes
| something short of a firm commitment, but not outright flaking
| off.
|
| Separately from the delivery question, the checksums in UDP
| (and TCP!) also poorly assure integrity when datagrams _are_
| delivered. They only somewhat improve on the hardware.
| lxgr wrote:
| > Dropping a packet upon encountering a resource problem
| isn't effort, let alone best effort
|
| The dropping part isn't the effort; the forwarding part is.
|
| > the checksums in UDP (and TCP!) also poorly assure
| integrity when datagrams are delivered.
|
| That's true, but it's becoming less of a problem with
| ubiquitous encryption these days (at least on WAN
| connections).
| IshKebab wrote:
| > but the datagrams may be dropped anyway
|
| That's what I thought "unreliable" meant? I can't really tell
| what misconception you are trying to avoid.
| kbolino wrote:
| I think the issue is that there's a stigma around UDP,
| largely borne from not using it effectively. I'm not sure
| this is the right way to address the stigma though.
|
| Ultimately, TCP vs UDP per se is rarely the right question to
| ask. But that is often the only configuration knob available,
| or at least the only way to get away from TCP-based protocols
| and their overhead is to switch over to raw UDP as though it
| were an application protocol unto itself.
|
| Such naive use of UDP contributes to the stigma. If you send
| a piece of data only once, there's a nontrivial chance it
| won't get to its destination. If you never do any
| verification that the other side is available,
| misconfiguration or infrastructure changes can lead to all
| your packets going to ground and the sender being completely
| unaware. I've seen this happen many times and of course the
| only solution (considered or even available in a pinch) is to
| ditch UDP and use TCP because at least the latter "works".
| You can say "well it's UDP, what did you expect?" but
| unfortunately while that may have been meant to spur some
| deeper thought, it often just leads to the person who hears
| it writing off UDP entirely.
|
| Robust protocol design takes time and effort regardless of
| transport protocol chosen, but a lot of developers give it
| short shrift. Lacking care or deeper understanding, they
| blame UDP and eschew its use even when somebody comes along
| who does know how to use it effectively.
| IshKebab wrote:
| What kind of stigma is there around UDP? I have never heard
| of this and I have never seen anyone use UDP expecting it
| to be reliable.
|
| I think the biggest mistake people make with UDP protocols
| is allowing traffic amplification attacks.
| lll-o-lll wrote:
| We've been calling it "unreliable" transport since the 80's,
| and that's what it is. Want your packets to get there? TCP.
| Don't care much? UDP.
|
| Oversimplified.
|
| Best effort is a dumb term. There's no effort.
| eptcyka wrote:
| TCP wont always deliver your packets anyway , but it does
| have a mechanism of timing out if a party believes the other
| party did not receive something. UDP just means that if one
| cares for their data to be received, they must verify it
| themselves.
| eru wrote:
| Yes, it's not so much 'reliable' or 'best effort', rather
| the difference is 'which part of your software stack should
| deal with dropped packages'?
| 13415 wrote:
| That's in my opinion what reliable / unrealiable mean in
| this context.
|
| reliable = it either succeeds or you get an error after
| some time, unreliable = it may or may not succeed
|
| I concur with the people who think "best effort" is not a
| good term. But perhaps TCP streams are not reliable enough
| for TCP to be rightly called a reliable stream protocol. As
| it turned out, it's not really possible to use TCP without
| a control channel, message chunking, and similar mechanisms
| for transmitting arbitrary large files. If it _really_
| offered reliable streams that would its primary use case.
| convolvatron wrote:
| the designers of link layers and protocol implemntations, the
| army of operators who test signals, insteall repeaters,
| configure routers and hold conferences about how to manage
| the global routing system would disagree.
|
| best effort implies 'no, we're not going to be climb that
| curve and get try to get to 100% reliability, because that
| would actually be counterproductive from an engineering
| perspective, but we're going to go to pretty substantial
| lengths to deliver your packet'
| lxgr wrote:
| In a way, TCP is just about as reliable as UDP, but at a
| different layer: TCP will either forward your entire stream
| of data in order and without gaps, or it won't. UDP does the
| same, but on the per-datagram level.
|
| Reliability is arguably more of a statement about the
| availability metrics of your underlying network; it doesn't
| seem like a great summary for what TCP does. You can't make
| an unreliable lower layer reliable with any protocol magic on
| top; you can just bundle the unreliability differently (e.g.
| by trading off an unreliability in delivery for an
| unreliability in timing).
| coldtea wrote:
| This sounds like the problem is the term "best-effort" (hand
| wavy, what's the measure of effort? What's "the best" effort?).
|
| In the end, best-effort is just saying "unreliable" in a
| fussier way.
|
| > _But it does not make UDP inherently unreliable._
|
| Isn't that exactly what it does make it?
|
| If that's not it, then what woud an actual "inherently
| unreliable" design for such a protocol be? Calling an RNG to
| randomly decide whether to send the next packet?
| vince14 wrote:
| Fire-and-forget?
| justin66 wrote:
| There's nothing intuitive about what "best effort" means, but
| if you know anything about udp and tcp you know which is
| "reliable."
|
| > UDP makes its best effort
|
| TCP tries really hard, too, you know.
| JackSlateur wrote:
| Network is nothing but datagrams.
| dale_glass wrote:
| IMO one of the worst mistakes made in IP development was not
| having made a standard protocol for the one thing that pretty
| much everyone seems to want:
|
| A reliable, unlimited-length, message-based protocol.
|
| With TCP there's a million users that throw out the stream aspect
| and implement messages on top of it. And with UDP people
| implement reliability and the ability to transmit >1 MTU.
|
| So much time wasted reinventing the wheel.
| supriyo-biswas wrote:
| There's Homa[1].
|
| [1] https://github.com/PlatformLab/Homa
| H8crilA wrote:
| Sorry for a useless comment but now I feel so stupid for never
| noticing that pretty much everything done on TCP is actually
| message exchange, not streams. The mismatch is indeed so
| unfortunate.
| eru wrote:
| Well, you often have some dependency between messages. Some
| re-orderings don't matter, but some do.
|
| If you just keep everything in the same order, then you never
| have to worry about any re-ordering.
|
| I can see why people picked streams as the one-size-fits-
| all-(but-badly) abstraction.
| tliltocatl wrote:
| Because worse is better and if you try to be everything you
| (don't) get OSI. Also because everyone loves serial ports
| and dialup modems and TCP just emulates a serial port over
| packet network. And it wasn't supposed to be one-size-fits-
| all, rather <<let us have telnet while we figuring out the
| rest>> but then ossification happend.
| iainmerrick wrote:
| Is it really that unfortunate? What's the big downside?
|
| There's a bit of reinvention needed, sure, but adding a
| framing layer is about the easiest task in networking. If you
| want a standard way of doing it, these days you can use a
| WebSocket.
|
| _Edit to add:_ oh, I see, you want reliable but unordered
| messages. That would definitely be useful sometimes, but
| other times you do want ordering. If you don't need ordering,
| isn't that pretty much what QUIC does?
| p_l wrote:
| SCTP did both reliable/unreliable and ordered/unordered,
| with QUIC arguably being at least a bit inspired by it, but
| going over UDP because internet is broken.
|
| EDIT: Internet being broken is also why there's a grease
| extension for QUIC
| taneq wrote:
| What would 'reliable but unordered' even mean? What's the
| difference between a dropped message and one that's just
| late?
| saurik wrote:
| The difference is whether you get to process the ones
| which came after first or you must wait for the
| retransmission of the earlier ones. FWIW, SCTP provides
| for this difference.
| Aurornis wrote:
| > I feel so stupid for never noticing that pretty much
| everything done on TCP is actually message exchange, not
| streams.
|
| This generalization isn't true at all. Streaming data over
| TCP is extremely common in many applications.
|
| When you download a large file, you're streaming it to disk,
| for example.
|
| I guess you could get pedantic and argue that an entire
| stream of something is actually one large message, but that's
| really straining the definitions.
| tliltocatl wrote:
| You are looking for SCTP.
| lxgr wrote:
| Which you will absolutely not get past pretty much any
| middleboxes, unless you encapsulate it in UDP.
| Ekaros wrote:
| Now I wonder. Do we have any actual streaming use of TCP, with
| purely streaming protocol.
| eru wrote:
| Yes. When your messages need to be received and processed in
| the same order they are sent, then a stream is a good (or
| good enough) abstraction.
|
| For most applications some re-orderings of messages don't
| matter, and others would need special handling. So as a one-
| size-fits-all-(but-badly) abstraction you can use a stream.
|
| > Do we have any actual streaming use of TCP, with purely
| streaming protocol.
|
| But to give you a proper answer: the stream of keyboard
| inputs from the user to the server in Telnet (or SSH).
| Ekaros wrote:
| Opens up the question that if you have "messages" are you a
| stream anymore? Can your stream of messages start mid
| message for example? Surely a stream can have this happen.
| Or are you instead messages send over a stream. In which
| case abstraction of stream instead of reliable message
| transportation is bit weird.
|
| Wouldn't each input be a single albeit too short message?
| But this level of granularity really makes little sense...
| nyc_pizzadev wrote:
| High quality VOD (ie streaming a 4K movie). HTTP block file
| systems, each block needs to be streamed reliably to fulfill
| the read() call plus read ahead.
| Ekaros wrote:
| For VOD can I just open connection and send single message
| and then stream will continue forever? And HTTP is message
| oriented protocol. I can't just send infinite length HTTP
| message. Which would be processed as it arrives or can I?
| Meaning can I upload something not that small like terabyte
| of video data over HTTP?
| nyc_pizzadev wrote:
| Yes for everything. In HTTP1 it's a chunked response, in
| H2+ it's just a bunch of data frames. This is how low
| latency HLS video works.
| hansvm wrote:
| Think about what the feature (potentially) buys you:
|
| (1) zero-copy, zero-allocation request processing
|
| (2) up to a 2x latency reduction by intermingling networking
| and actual work
|
| (3) more cache friendliness
|
| (4) better performance characteristics on composition
| (multiple stages which all have to batch their requests and
| responses will balloon perceived latency)
|
| If you have a simple system (only a few layers of
| networking), low QPS (under a million), small requests
| (average under 1KB, max under 1MB), and reasonable latency
| requirements (no human user can tell a microsecond from a
| millisecond), just batch everything and be done with it. It's
| not worth the engineering costs to do anything fancy when a
| mid-tier laptop can run your service with the dumb
| implementation.
|
| As soon as those features start to matter, streaming starts
| to make more sense. I normally see it being used for cost
| reasons in very popular services, when every latency
| improvement matters for a given application, when you don't
| have room to buffer the whole request, or to create very
| complicated networked systems.
| jzwinck wrote:
| Here is a good message framing protocol built on TCP:
| https://www.nasdaq.com/docs/SoupBinTCP%204.0.pdf
|
| If you want large messages just redefine the length from 16 to
| 32 bits.
|
| It's been used for millions of messages per day for 25 years
| and hasn't been changed in a long time.
|
| Admittedly it isn't as common as TCP and that's a shame. But
| it's out there, it's public, it's minimal and it makes sense.
| eru wrote:
| > SoupBinTCP guarantees that the client receives each
| sequenced message generated by the server in the correct
| order, [...]
|
| This protocol guarantees too much. It's still a stream.
| jzwinck wrote:
| You quoted the part about sequenced messages. Look at the
| part about unsequenced messages right after that. It has
| both.
| ajb wrote:
| Actually, the mistake in IP was in not encrypting the next
| layer, so that networks can block transport protocol innovation
| by filtering anything other than TCP and UDP. This is the
| mistake that quic has fixed.
| Ekaros wrote:
| I think that one can be forgiven for pure lack of processing
| power... We forget just how under powered even host machines
| were and how resource hungry encryption is...
| d-z-m wrote:
| QUIC still runs over UDP. Are you referring to MASQUE?
| ajb wrote:
| I should perhaps have said "works round" rather than fixes
| - yes, it has to run over UDP but the quic team had an
| explicit goal of not allowing the network to interfere
| further : see sec 3.3 and 7.5 of
| https://dl.acm.org/doi/pdf/10.1145/3098822.3098842
|
| This now means that innovations based on Quic can occur
| mycall wrote:
| Since both QUIC and UDP are transport layers, does this
| mean that once switches and ISPs start supporting QUIC
| along side UDP and TCP, that a new version of QUIC can be
| released which doesn't require UDP?
| ajb wrote:
| Switches don't need to change anything to support QUIC,
| precisely because it uses UDP. So, the deployment of QUIC
| doesn't involve any _technical_ changes that would enable
| a version of QUIC that worked directly over IP. It 's
| possible that the defeat of middleboxes would change the
| _motivation_ of ISPs to filter out alternate protocol
| numbers, meaning that there might be less resistance to
| getting them to allow that in the future - but doing so
| is still a big exercise.
|
| Also, the overhead of a UDP packet is 8 bytes total, in 4
| 16-bit fields:
|
| - source port
|
| - dest port
|
| - length
|
| - checksum
|
| So, we can save a max of 8 bytes per packet - how many of
| these can we practically save? The initial connection
| requires source and dest ports, but also sets up other
| connection IDs so _theoretically_ you could save them on
| subsequent packets (but that 's pure speculation, with
| zero due diligence on my part). It would require
| operational changes and would make any NATs tricky (so
| practically only for IPv6) Length and checksum _maybe_
| you can save - QUIC has multiple frames per UDP datagram
| so there must be another length field there (anyway, IETF
| is busily inventing a UDP options format on the basis
| that the UDP length field is redundant to packet length,
| so can be used to point at an options trailer). QUIC has
| integrity protection but it doesn 't seem to apply to all
| packet types - however I guess a checksum could be
| retained for those that don't only.
|
| So in sum maybe you could save up to 8 bytes per packet,
| but it would still be a lot of work to do so (removing
| port numbers especially)
| DoneWithAllThat wrote:
| This was absolutely not feasible at the time IP was being
| developed. There simply wasn't enough computational power
| available or good encryption algorithms invented yet. And you
| can make a reasonable argument that that's not the
| responsibility of that layer of the stack.
| LtWorf wrote:
| Encryption without authentication is rather useless. Just
| slows things down for no advantage.
| jan_k_ wrote:
| WebSocket?
| paulgb wrote:
| WebSocket is over TCP, so still ordered. I think by message-
| based GP is talking not only about message framing (which
| WebSocket provides) but also reliable out-of-order delivery.
| ori_b wrote:
| When does a long out of order delay look like a packet
| loss?
|
| Is it possible for an out of order packet to get delayed by
| a millisecond? A second? A minute? An hour?
|
| Have you written code to be robust to this?
| paulgb wrote:
| Other people have probably thought about it more than I
| have, but the way I see it working is that a set of
| unacked messages are stored on each end of the
| connection. When a connection receives a message, it acks
| it by ID. When acks come out of the order the client sent
| them in (or after a timeout period), it re-sends the
| packet that may have dropped.
|
| If every message is getting dropped, the set of unacked
| messages fills up and the connection stops accepting
| messages from the application, similar to TCP in that
| situation.
|
| I mostly work with TCP so haven't had to deal with
| unreliable channels generally, but I do use a similar
| approach at the application level for reliable delivery
| across reconnects.
| ori_b wrote:
| My point is that a lost message looks the same as an
| arbitrary delay.
| p_l wrote:
| That's because TCP evolved as, essentially, abstraction of
| serial port.
|
| And due to various political & cultural & industrial lobbying,
| more flexible but complex on their face approaches (OSI) were
| rejected.
|
| TCP meant you could easily attach a serial terminal to a
| stream, a text protocol meant you could interact or debug a
| protocol by throwing together a sandwich, an undergrad, and a
| serial terminal (coffee too if they do a good job). You could
| also in theory use something like SMTP from a terminal attached
| over a TIP (which provided dial-in connection into ARPAnet
| where you told the TIP what host and what port you wanted).
|
| If you look through some of the old protocol definitions you'll
| note that a bunch of them actually refer to simplest mode of
| TELNET as base.
|
| Then in extension of arguably the same behaviour that blocked
| GOSIP mandate we have pretty much reduced internet to TCP, UDP,
| and bits of ICMP, because you can't depend on plain IP
| connectivity in a world of NAT and broken middleboxes.
| throwaway7ahgb wrote:
| Correct on the reliable UDP.
|
| I've seen a few implementations of a reliable UDP messaging
| stream (using multicast or broadcast). It uses a sequencer to
| ensure all clients receive the correct message and order.
|
| It can be extremely fast and reliable.
| taneq wrote:
| If it guarantees delivery and preserves order, what's the
| difference vs. TCP?
| colanderman wrote:
| Delimited messages vs. stream.
| FpUser wrote:
| I have implemented publish/subscribe middleware in the 90s
| using UDP and reliable IP multicast. It was not too hard to do
| and had taken me about two month. Yes I did reinvent the wheel
| but it had numerous positive sides: a) It added
| yet another area of expertise to my portfolio. b) I did
| it because it was needed to facilitate another product in the
| company where I worked. The alternative at the time would be
| paying $350,000 for middleware from Vendor-X. Not acceptable.
| c) Vendor-X people noticed us, loved what we did and made us a
| partner to resell their middleware and we've made a ton of
| money on deployment, configuring and consulting services.
| _zoltan_ wrote:
| libfabric implements msg on top of TCP, among others. I love
| that I can just switch between TCP and RDMA without any code
| change.
| thomashabets2 wrote:
| > The bytes within each stream are ordered, reliable, and can be
| any size; it's nice and convenient. Each stream could be a video
| frame [...] But you can tell the QUIC stack to focus on
| delivering important streams first. The low priority streams will
| be starved, and can be closed to avoid wasting bandwidth.
|
| Is the author saying that with QUIC I can send a "score update"
| for my game (periodic update) on a short-lived stream, and
| prevent retransmissions? I'll send an _updated_ "score update" in
| a few seconds, so if the first one got lost, then I don't want it
| to waste bandwidth retransmitting. Especially I don't want it
| retransmitted _after_ I 've sent a newer update.
| gnfargbl wrote:
| I think you're looking for RFC 9221, "An Unreliable Datagram
| Extension to QUIC."
| swiftcoder wrote:
| You don't need datagrams for this. You can set the stream to
| discard itself as soon as packet loss is detected
| mjw_byrne wrote:
| Silly clickbait title, which the author even admits up front.
|
| UDP and TCP have different behaviour and different tradeoffs, you
| have to understand them before choosing one for your use case.
| That's basically it. No need for "Never do X" gatekeeping.
| g15jv2dp wrote:
| My apologies if the star in front of "never" was added to the
| title in the last ten minutes after you posted your comment.
| But that star is clearly there to indicate "fine print ahead";
| in a title, it's pretty obvious that it means that the article
| is _not_ about to "gatekeep" people out of UDP. (In fact, at
| the end of the article, the author suggests to use QUIC which,
| you guessed it, is based on UDP.)
| tliltocatl wrote:
| Most of TCP woes comes from high-bandwith latency-sensitive stuff
| like HFT and video, but TCP isn't particularly good for low-
| bandwidth high-latency networks either (e. g. NB-IoT with 10
| seconds worst case RTT):
|
| - TCP will waste roundtrips on handshakes. And then some extra on
| MTU discovery.
|
| - TCP will keep trying to transmit data even if it's no longer
| useful (same issue as with real-time multimedia).
|
| - If you move into a location with worse coverage, your latency
| increases, but TCP will assume packet loss due to congestion and
| reduce bandwidth. And in general, loss-based congestion control
| just doesn't work at this point.
|
| - Load balancers and middleboxes (and HTTP servers, but that's
| another story) may disconnect you randomly because hey, you
| haven't responded for four seconds, you are probably no longer
| there anyway, right?
|
| - You can't interpret the data you've got until you have all of
| it - because TCP will split packets with no regards to data
| structure. Which is twice as sad when all of your data would
| actually fit in 1200 bytes.
| eru wrote:
| And TCP wants to pretend that all your data arrives as a linear
| stream one after the other; and keeps you from seeing package
| n+1, if you haven't received package n, yet.
|
| That's useful for some things, but often you can make use of
| package n+1, even when package n hasn't arrived, yet.
|
| For example, when you are transferring a large file, you could
| use erasure encoding to just automatically deal with 5% package
| loss. (Or you could use a fountain code to deal with variable
| packet loss, and the sender just keeps sending until the
| receiver says "I'm done" for the whole file, instead of ack-ing
| individual packages.
|
| Fountain codes are how deep space probes send their data back.
| Latency is pretty terrible out to Jupiter or Mars.)
| Aurornis wrote:
| > And TCP wants to pretend that all your data arrives as a
| linear stream one after the other;
|
| That's one of the reasons people use TCP.
|
| > For example, when you are transferring a large file, you
| could use erasure encoding to just automatically deal with 5%
| package loss.
|
| It's never that simple. You can't just add some erasure
| coding and have it automatically solve your problems. You now
| have to build an entire protocol around those packets to
| determine and track their order. You also need mechanisms to
| handle the case where packet loss exceeds what you can
| recover, which involves either restarting the transfer or a
| retransmission mechanism.
|
| The number of little details you have to handle quickly
| explodes in complexity. Even in the best case scenario, you'd
| be paying a price to handle erasure coding on one end, the
| extra bandwidth of the overhead, and then decoding on the
| receiving end.
|
| That's a lot of complexity, engineering, debugging, and
| opportunities to introduce bugs, and for what gain? In the
| file transfer example, what would you actually gain by
| rolling your own entire transmission protocol with all this
| overhead?
|
| > Fountain codes are how deep space probes send their data
| back. Latency is pretty terrible out to Jupiter or Mars.)
|
| Fountain codes and even general erasure codes are not the
| right tool for this job. The loss of a digital packetized
| channel across the internet is very different than a noisy
| analog channel sent through space.
| sgt wrote:
| Is NB-IoT actually being used these days? I remember it was
| hyped up but then the buzz disappeared.
| tliltocatl wrote:
| It definitely does, at least in Europe, not sure how things
| are on the other side of the pond. For the user equipment
| there is no real advantage over LTE-M, actually is LTE-M
| better for our case (send a single packet a day and go to
| sleep). But then I don't see the picture from the operator
| side, maybe the radio savings actually matter for them. Some
| operators either don't have LTE-M at all or don't allow PSM
| on LTE-M because screw you that's why. On NB-IoT PSM is
| mandatory at least. And yes, LoRa/Sigfox/other non-cellular
| LPWAN might technically be better IF you provide the base
| stations. Nobody wants to do that. With cellular you can just
| mail the device and cross your fingers the operators haven't
| misconfigured roaming.
| sgt wrote:
| That's quite interesting. And the promised battery
| lifespans of NB-IoT device, did it hold some truth? In the
| beginning we heard about 10 year life spans for simple well
| designed devices.
| jjoonathan wrote:
| We have millions of devices in the field older than that
| on the same D-cell LiSOCl2 battery they shipped with.
| Some of them even take magnetic measurements with powered
| excitation!
| tliltocatl wrote:
| You'll have to wait 10 years to see. But on paper it does
| (we aim for 15) and we have devices in field for some
| three years.
|
| But for the "simple well-designed" - the problem is, the
| whole thing is a black box for application developer, and
| not a bugless one. So much of the "well-designed" part is
| to figure out when is the right time to pull modem's
| proverbial power cord. If you don't, it'll gladly eat up
| your battery in 48 hours after a cell handover goes wrong
| with no warning.
| jjoonathan wrote:
| In my corner of the world (electric/water/gas utilities), we
| had been using proprietary techniques that matched the "NB-
| IoT" description for 20 years, and they weren't new then. It
| was fun to watch the public dialogue walk the same path for a
| while and rediscover some of the main tricks, but there were
| other important tricks left untouched (broadcast firmware
| downloads, highly compressed debug logs, low power clock
| synchronization so that you can do timeslots for ultra low
| power, mesh heuristics) probably because they were a massive
| pain in the rear and the people who would have risen to the
| occasion saw that the major ecological niches were already
| occupied by players who got in 30 years ago when this all
| became viable. (Disclaimer: I didn't actively chase down NB-
| IoT talks so I might just have been missing these things.)
|
| If your market is large enough that managing your own
| infrastructure is attractive (vs cellular), you were also
| able to afford a few EEs and RF guys 30 years ago, and your
| needs are already met by a competitive ecosystem of players
| who have been walking this path for a long time. It doesn't
| leave much to compete on except price, and you don't want to
| compete on price.
| nabla9 wrote:
| The choice is not UDP vs TCP.
|
| UDP adds minimum over raw sockets so that you don't need root
| privileges. Other protocols are build on top of UDP.
|
| It's better to use existing not-TCP protocols instead of UDP when
| the need arises instead of making your own. Especially for
| streaming.
| ozim wrote:
| Great in depth article from what seems really a person who knows
| that stuff.
| nyc_pizzadev wrote:
| One thing not mentioned often is that a lot of networks will drop
| UDP packets first when encountering congestion. The thinking is
| that those packets will not re-transmit, so it's an effective
| means to shed excess traffic. Given we now have protocols that
| aggressively re-transmit on UDP, I wonder how that has changed
| things. I do seem to remember QUIC having re-transmit issues (vs
| HTTP1/2) years ago because of this.
| cenriqueortiz wrote:
| Nahhh. While most of the applications/cases will be using
| session-based connections, there are uses for using datagrams
| directly -- don't be afraid. Yes, you will have to take care of
| many more details yourself. And as a side line, it is a great way
| of learning the low level aspects of networking.
| ddtaylor wrote:
| The SteamNetworkingMessages API for game development does a
| good job of making this available if you want it without caring
| about the internals for that use case.
| Anon_Admirer wrote:
| Hope this one gets captured by quackernews - can't wait to see
| its description.
| TuringNYC wrote:
| >> The common wisdom is: >> >> use TCP if you want reliable
| delivery >> >> use UDP if you want unreliable delivery >> What
| the *(& does that mean? Who wants unreliability?
|
| I dont agree with the premise of this article, UDP isnt for
| unreliability, it provides a tradeoff which trades speed and
| efficiency and provides best-efforts instead of guarantees.
|
| It makes sense depending on your application. For example, if I
| have a real-time multi-player video game, and things fall behind,
| the items which fell behind no longer matter because the state of
| the game changed. Same thing for a high-speed trading application
| -- I only care about the most recent market data in some
| circumstances, not what happened 100ms ago.
| alexey-salmin wrote:
| That's basically what the article says if you keep on reading.
| It states the "common wisdom" at first to disagree with it.
| opheliate wrote:
| That isn't the premise of the article, that is the "common
| wisdom" the author corrects as the article goes on. The author
| goes on to list video games as an example of where UDP makes
| sense, as well as live video.
| 20k wrote:
| I feel like this article misses why people avoid TCP like the
| plague, and why people use UDP for many applications
|
| 1. Routers do all kinds of terrible things with TCP, causing high
| latency, and poor performance. Routers do not do this to nearly
| the same extent with UDP
|
| 2. Operating systems have a tendency to buffer for high lengths
| of time, resulting in very poor performance due to high latency.
| TCP is often seriously unusable for deployment on a random
| clients default setup. Getting caught out by Nagle is a classic
| mistake, its one of the first things to look for in a project
| suffering from tcp issues
|
| 3. TCP is stream based, which I don't think has ever been what I
| want. You have to reimplement your own protocol on top of TCP
| anyway to introduce message frames
|
| 4. The model of network failures that TCP works well for is a bit
| naive, network failures tend to cluster together making the
| reliability guarantees not that useful a lot of the time.
| Failures don't tend to be statistically independent, and your
| connection will drop requiring you to start again anyway
|
| 5. TCP's backoff model on packet failures is both incredibly
| aggressive, and mismatched for a flaky physical layer. Even a
| tiny % of packet loss can make your performance unusable, to the
| point where the concept of using TCP is completely unworkable
|
| Its also worth noting that people use "unreliable" to mean UDP
| for its promptness guarantees, because reliable = TCP, and
| unreliable = UDP
|
| QUIC and TCP actively don't meet the needs of certain
| applications - its worth examining a use case that's kind of
| glossed over in the article: Videogames
|
| I think this article misses the point strongly here by ignoring
| this kind of use case, because in many domains you have a
| performance and fault model that are simply not well matched by a
| protocol like TCP or QUIC. None of the features on the protocol
| list are things that you especially need or even can implement
| for videogames (you really want to encrypt player positions?). In
| a game, your update rate might be 1KB/s - absolutely tiny. If
| more than N packets get dropped - under TCP _or_ UDP (or quic) -
| because games are a hard realtime system you 're screwed, and
| there's nothing you can do about it no matter what protocol
| you're using. If you use QUIC, the server will attempt to send
| the packet again which.... is completely pointless, and now
| you're stuck waiting for potentially a whole queue of packets to
| send if your network hiccups for a second, with presumably
| whatever congestion control QUIC implements, so your game lags
| even more once your network recovers. Ick! Should we have a
| separate queue for every packet?
|
| Videogame networking protocols are built to tolerate the loss of
| a certain number of packets within a certain timeframe (eg 1
| every 200ms), and this system has to be extremely tightly
| integrated into the game architecture to maintain your hard
| realtime guarantees. Adding quic is just overhead, because the
| reliability that QUIC provides, and the reliability that games
| need, are not the same kind of reliability
|
| Congestion in a videogame with low bandwidths is _extremely_
| unlikely. The issue is that network protocols have no way to know
| if a dropped packet is because of congestion, or because of a
| flaky underlying connection. Videogames assume a priori that you
| do not have congestion (otherwise your game is unplayable), so
| all recoverable networking failures are 1 off transient network
| failures of less than a handful of packets by definition. When
| you drop a packet in a videogame, the server may _increase_ its
| update rate to catch you up via time dilation, rather than in a
| protocol like TCP /QUIC which will reduce its update rate. A well
| designed game built on UDP tolerates a slightly flakey
| connection. If you use TCP or QUIC, you'll run into problems.
| QUIC isn't terrible, but its not good for this kind of
| application, and we shouldn't pretend its fine
|
| For more information about a good game networking system, see
| this video: https://www.youtube.com/watch?v=odSBJ49rzDo, and it
| goes over pretty in detail why you shouldn't use something like
| QUIC
| lxgr wrote:
| > 1. Routers do all kinds of terrible things with TCP, causing
| high latency, and poor performance. Routers do not do this to
| nearly the same extent with UDP
|
| What things are you thinking of here?
|
| > 2. Operating systems have a tendency to buffer for high
| lengths of time, resulting in very poor performance due to high
| latency.
|
| Do they? I can only think of Nagle's algorithm causing any
| potential buffering delay on the OS level, and you can
| deactivate that via TCP_NODELAY on most OSes.
|
| > 5. TCP's backoff model on packet failures is both incredibly
| aggressive, and mismatched for a flaky physical layer. Even a
| tiny % of packet loss can make your performance unusable, to
| the point where the concept of using TCP is completely
| unworkable
|
| That's a property of your specific TCP implementation's
| congestion control algorithm, nothing inherent to TCP. TCP BBR
| is quite resistant to non-congestion-induced packet loss, for
| example [1].
|
| > If you use QUIC, the server will attempt to send the packet
| again which.... is completely pointless
|
| Isn't one of QUIC's features that you can cancel pending
| streams, which explicitly solves that issue? In your
| implementation, if you send update type x for frame n+1, you
| could just cancel all pending updates of type x if every update
| contains your complete new state.
|
| [1] https://atoonk.medium.com/tcp-bbr-exploring-tcp-
| congestion-c...
| dicroce wrote:
| I wonder if this guy thinks video GOPs should all be hundreds of
| frames long because P frames are so much smaller than I frames
| and since in his world we NEVER use an unreliable network you
| might as well.
| karmakaze wrote:
| TL;DR - use QUIC _(should have just looked at the domain name)_
| dragonfax wrote:
| I've seen UDP used for great effect in video streaming.
| Especially timely video streaming such as cloud gaming. When
| waiting a late packet is no longer useful.
| gary_0 wrote:
| I wonder if the DiffServ[0] bits in IPv6 could be another way to
| prevent bufferbloat from affecting real-time datagrams? Or are
| they like IPv4's ToS[1] bits, which I think were never
| implemented widely (or properly) enough for any software to
| bother with?
|
| [0] https://en.wikipedia.org/wiki/Differentiated_services
|
| [1] https://en.wikipedia.org/wiki/Type_of_service
| ta1243 wrote:
| Used high numbers of UDP packets over intercontinental internet
| links for mission critical applications for 15 years. 20mbit of
| UDP carrying RTP. Loss on a given flow is quite rare, and the
| application helps (via duplication, or retransmits)
|
| As time has progressed increased from nothing to fec to dual-
| streaming and offset-streaming to RIST and SRT depending on the
| criticality.
|
| On the other hand I've seen people try to use TCP (with rtmp) and
| fail miserably. Never* use TCP.
|
| Or you know, use the right tool for the right job.
| dang wrote:
| I've attempted to replace the clickbait title* using terms from
| the article itself, but if someone can suggest a more
| representative phrase from the article, we can change it again.
|
| (* in keeping with the HN's title guideline: " _Please use the
| original title, unless it is misleading or linkbait_ " -
| https://news.ycombinator.com/newsguidelines.html)
| kierank wrote:
| Imagine Ethernet was designed like this and you had to implement
| mandatory congestion control and other cruft. The layer of the
| stack that has knowledge of the content should be implementing
| the congestion control.
___________________________________________________________________
(page generated 2024-06-23 23:00 UTC)