Hacker News Reader

Comment by PinguTS | Hacker News Reader

Actually, even TCP is going to be replaced. I just want to remind the initial work of Google on QUIC, which now has become some standard. It is based on UDP and re-defining TCP features based on UDP together with cryptography and by allowing IP changes to allow moving clients.

View on HN

And yet, even with QUIC and a brand new Google phone on a Google wifi network and a Google Fi cell connection, I still can't walk away from my house and have a video call migrate from wifi to 5G without the audio glitching and dropping frames.

All the mobility benefits of QUIC mean nothing when the rest of the software stack isn't designed to let it work.

that's never going to be a seamless transition. the fact the transition happens automatically is a marvel in itself

It 100% could be. Changes you'd need are:

* Android lets an application talk over both wifi and 5G at the same time.

* Android exposes information about signal strength on a per packet basis, so that the application can decide at some point that too many packets are too close to not being received, so it's time to send data over 5G in addition. It should also expose data about packet retransmissions at the physical layer (ie. collisions and backoff times due to another device using the media).

* When the 5G data flow is established and channel parameters like delay and loss are characterized, then stop sending data over wifi.

* And since this process never involved delaying any data by a roundtrip, nor any packet loss, there is no need to drop any frames.

Note that the cell network has been able to handoff voice calls from one cell tower to another without glitches since the 80's!.

I think the factor you're missing is that the WiFi and 5G connections may have substantially different latencies to the other person. Going from a lower-latency to a higher-latency connection will always involve audio dropping out and video pausing. And in the opposite direction, it's preferable to skip over a few frames in order to reduce latency, rather than maintain higher latency.

I wonder if you don't see this with cell phones because the latency is generally identical, or if it's just less noticeable with audio than with video? I guess I'd also wonder if cell towers really do hand off without glitches, since there always seem to be glitches when you're driving, but you don't have the slightest idea whether they're from tall buildings or interference or Bluetooth or handoffs or what, or even on your end or the other person's end.

Video conferencing has latency in the 300ms - 1000ms range[1]. The actual network component of that is pretty small. And video conferencing software already has logic for time stretching/compression to handle variable latency - typically they'll speed up or slow down gaps between words and sentences.

[1]: https://www.mdpi.com/2076-3417/12/24/12884

Actually no -- things like FaceTime are more like 90 ms, while other common products like Zoom and Meet are around 150-200. These are minimums with somebody in your own city. This is actually from my own testing in the past, where FaceTime was the clear winner, since Apple seems to care a lot about latency and its software is custom written for its own hardware.

But networks absolutely can add major latency, have you never had a slow Zoom call? It's because of congestion building up and radio interference, not Zoom's software. That's what leads to things like 1,000 ms latency, which makes back and forth conversation very difficult. Moderate-to-major perceptible latency issues in conversation are always because of the network.

And yes some products do time stretching but that's also what people often call glitches because it's very weird.

> that's never going to be a seamless transition.

Why not? It is not obvious to me why a seamless transition is impossible?

Isn't the whole point of TCP that individual packets can take different paths over different networks and when they reach the destination they can be sequenced? Why should changing the network disrupt the individual packets from traveling independently?

There are several things that make this difficult. Much of the difficulty relates to the device changing it's network address. Seamless transition requires that the application can:

- Find the new address; i.e. Cell provider vs. Residential/Business ISP - Associate the new address with the same flow - Duplicate packets and reassemble them, or change to "better" path interface.

On both android and iOS, a regular app can't choose to send packets over both 5G and wifi at the same time. Thats needed to setup a new connection while still using the old one.

I was pretty sure that android and iOS both have apis for apps to choose between 'whatever is best', 'wifi preferred' and 'cellular preferred'?

I don't know the details, but some iOS network apis (Network Kit?) allow you to set a required interface type somehow. https://developer.apple.com/documentation/network/nwparamete...

Never is a long time. QUIC isn't great for this, because while it has IP address flexibility, it's not designed to have multiple paths simultaneously active.

If you design for this use case, you can make it work today; especially since the user is on a video call and only asking for the audio to be glitchless. Sending audio over both wifi and cell is possible and simple and would solve audio at the expense of double the audio bandwidth. More bandwidth efficient methods are left to the reader.

TCP is fine and isn't going anywhere. QUIC is an overengineered contraption that only exists to serve more ads. SSH doesn't need it. Postgres doesn't need it. Nobody needs QUIC except Google.

QUIC is not without defects, I'm with you there, but almost almost any "web-scale" company dealing with a lot of cellular connections would disagree with your statement. Uber, Verizon, Cloudflare, Meta, Fastly, among others, some of which have reported very significant latency reductions.

> SSH doesn't need it.

SSH's "master" mode connection sharing would benefit from QUIC / HTTP/3 head of line blocking elimination just as much as browsers would. Run a heavy rsync using connection sharing with an interactive session and you'll notice the interactive sessions latency suffering noticably.

Long-lived SSH connections would benefit from QUIC / HTTP/3 session survivability.

Reply on news.ycombinator.com