Posts by MarkelHill 3 publicly visible posts • joined 17 Jan 2018
Doesn't this show that the infrastructure monopoly that Telstra once enjoyed was a big source of their profits? In other words they were milking the country - as all monopolies do.
All of which confirms that natural monopolies should never be placed in the hards of private companies. We should remember this when a future govt. attempts to privatise NBNCo.
On or about 2002 a similar failure occurred at Yahoo when a new MX was added that inadvertently exceeded the max UDP packet size and thus caused all DNS queries to fall back to TCP.
The sudden influx of huge numbers of TCP connections swamped the DNS servers such that our update mechanisms failed when we attempted a reversion. We couldn't even ssh into them to make a manual fix. Furthermore the servers also stopped responding to UDP queries!
We had to get our data-centre folk to disconnect each server from the network so they could log in at the console and apply a manual fix to unwind the mess.
While no mail should have been lost it caused queries to *.yahoo.com to timeout for a number of hours so presumably many millions of dollars of lost ad revenue during that time.
Unsurprisingly the instigator of the change lost their DNS update privileges but they did keep their job and went on to become a VP.
tl;dr I see no fundamental advantage to QUIC that can't be achieved with existing protocols (possibly with some comparatively minor optimisations in the kernel or API layers).
QUIC is a hugely complicated protocol. The amount of code needed to implement it is enormous (look at the Chrome open source repo for an idea of the client-side cost). That suggests the benefits should be very apparent and significant to justify the cost and risk. However..
1. The multiplexing benefit mostly replaces multiple sockets implemented in the kernel with multiple "streams" implemented in user-space.
But there is no fundamental reason why the cost/state of a TCP socket is higher than the cost/state of QUIC stream - after all, they more or less do the same thing. In the old days sockets were expensive but that is no longer true as kernels improve and memory becomes cheap.
2. There are very few if any high-performance friendly APIs for QUIC such as select(), epoll(), kqueue() or libev/libevent at a higher layer. This significantly hinders adoption in existing applications.
3. In some ways QUIC is anti-thetical to high-performance programming and multi-core CPUs.
You essentially need to funnel all of a QUIC connection's traffic thru a dispatching thread to farm out stream traffic. This implies user-space driven context-switching costs. No such implementation model is forced on you when using separate sockets.
As a simple example, adapting Apache's httpd server to QUIC would incur significant performance costs and application complexity.
5. In many regards QUIC is no different from SCTP (RFC4960), so why not use or incrementally improve SCTP? Google have invested enormously in QUIC. If that effort had been directed at an SCTP++ we would have seen a fantastic improvement by now that would be readily available to a much larger development community.
Admittedly a number of these criticisms could be addressed by moving QUIC into the kernel, but that seems to go against the philosophy of the QUIC proponents. But even then are you merely re-implementing a variant of SCTP?
For my money, enhance SCTP and present SCTP streams as sockets to applications and you have a ready-to-go QUIC alternative at about 1/100th the cost.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
