[HN Gopher] QUIC Is Not a TCP Replacement
___________________________________________________________________
QUIC Is Not a TCP Replacement
Author : bleuarff
Score : 40 points
Date : 2022-09-26 14:03 UTC (8 hours ago)
(HTM) web link (systemsapproach.substack.com)
(TXT) w3m dump (systemsapproach.substack.com)
| rektide wrote:
| I see two main arguments, and neither quite makes sense to me.
|
| First, that TCP wasn't suitable for RPC based systems. Which can
| be true, but doesn't imply anything about the position that QUIC
| isn't ideal for reliable byte streams. Even though QUIC does
| great for RPC, there's plenty of possibility that QUIC does great
| for reliable byte streams.
|
| The second argument is that QUIC is complex, and the main
| argument seems to be:
|
| > _QUIC is doing a lot of work: its definition spans three RFCs
| covering the basic protocol (RFC 9000), its use of TLS (9001) and
| its congestion control mechanisms (9002)_
|
| In general, I think the decomposition of specs into different
| pieces is a huge win for clarity & understandability and implies
| little about how much "work" it is to implement.
|
| That QUIC integrates these three pieces reasonably elegantly,
| with clear boundaries between the aspects, shows how simple &
| conceptually well separated the pieces can be made.
|
| And then, TCP just doesn't cover encryption, which makes using
| TCP securely a whole new set of complexities & difficulties. TLS
| itself has a host of extensions & related RFCs that you may need
| to evaluate and implement, and you and some other shop may choose
| quite significantly different ways of setting up TLS between
| systems. QUIC isn't entirely free of _all_ these choices, but it
| is of some of them, and having the extra work built in is, in my
| view, less work in the long run.
|
| I'm left unconvinced that the requirements of TCP have anything
| special or notable over the requirements of QUIC, or that
| sticking to TCP in some cases has any real advantage or cause. It
| still feels to me like everything could switch to QUIC and we'd
| likely do better, & end up creating better systems.
| WorldMaker wrote:
| I think some of the argument you aren't seeing is in all the
| "narrow waist" implications and some of the links out from this
| article nearby that.
|
| The "narrow waist" concept was originally that the only
| protocol that the internet required every network to speak
| natively or directly was IP. TCP and UDP were intended to be
| two protocols among many at the next layer up, but through
| various factors and accidents things got ossified to just those
| two protocols at that layer and even that so much so that
| increasingly in the last few decades TCP/IP is seen as the
| "real internet" (the "waist" expanded).
|
| From that perspective QUIC looks like a hack: it's built at the
| next layer up (on top of UDP rather than a true peer among UDP
| and TCP) because building at the right layer level is "no
| longer allowed" (thanks to decades of firewalls, middleboxes,
| routers with bad assumptions baked in, etc).
|
| Those things that ossified TCP, though, are also many of the
| reasons that QUIC can't compete with TCP and that TCP _is_
| inherently special on the modern internet as one of only two
| "approved" protocols and something of a "last man standing"
| even among them. As an example, pointed to in that RFC list,
| QUIC has to define its own congestion control, and it's
| something of an application-level service. TCP has decades of
| congestion control tech in the wild, some of it baked
| incredibly low level into routers, so much so that a lot of it
| is just "automatic" and "magic". Applications don't need to do
| any work to opt-in to it. It's sad that that work is hard-coded
| specifically to TCP and only TCP and cannot be easily applied
| to new network protocols, but that's just the reality of the
| modern internet.
| gumby wrote:
| This is a wonderful and thoughtful essay. And TBH, despite having
| used RPC since before the TCP transition and still being
| frustrated (just a couple of months ago!) by doing RPC over TCP I
| never really twigged to the gain mismatch.
| AtNightWeCode wrote:
| People in general don't understand what TCP is. Drives my insane.
| In practice, is it even possible to replace anything else than
| web traffic with QUIC today?
| skyde wrote:
| yes Quic is not just HTTP. its a connection protocol
___________________________________________________________________
(page generated 2022-09-26 23:02 UTC)