Earlier quoted context omitted.
[flagged]
[flagged]
[flagged]
HTTP/2 and HTTP/3 explained
111–120 of 155 posts
Re: HTTP/2 and HTTP/3 explained
#112Earlier quoted context omitted.
Here's a third option: the five month old anonymous HN account claiming to know what the H2 designers were thinking of is wrong. How would you compare the likelihood of that to your two options? The main problem you're talking of is head of line blocking due to packet loss. But packet loss as a congestion signal is nowhere near as common as people think, and that was already the case during the original SPDY design w…
> The main problem you're talking of is head of line blocking due to packet loss. But packet loss as a congestion signal is nowhere near as common as people think Surely packet loss due to poor signal quality is rather common over mobile networks and that packet loss still affects TCP's congestion window. Admittedly anecdotal, but I just connected to a 5G network with low signal strength and it certainly seems to be…
It isn't. Or at least wasn't back in the UMTS / early LTE era that's being discussed; I got out of that game before 5G.
The base stations and terminals are constantly monitoring the signal quality and adjusting the error correction rate. A bad signal will mean that there's more error correction overhead, and that's why the connection is slower overall.
Second,the radio protocol doesn't treat data transmissions as a one-and-done deal. The protocols are built on the assumption of a high rate of unrecoverable transmission errors. Those rates would be way too high for TCP to be able to function, so retransmissions are instead baked in at the physical protocol level. The cellular base station will basically buffer the data until it's been reliably delivered or until the client moves to a different cell.
And crucially, not only is the physical protocol reliable but it's also in-sequences. A packet that wasn't received successfully shows up just as one (radio) roundtrip latency blip during which no data at all shows up at the client, not as packet loss or reordering that would be visible to the TCP stack on either side.
Other error cases you'd get are:
- Massive amounts of queueing, with the queues being per-user rather than per-base station (we measured up to a minute of queueing in testing). The queue times would translate directly to latency, completely dominating any other component.
- A catastrophic loss of all in-flight packets at once, which we believed was generally caused by handover from one cell to another.
Re: HTTP/2 and HTTP/3 explained
#113Earlier quoted context omitted.
> The main problem you're talking of is head of line blocking due to packet loss. But packet loss as a congestion signal is nowhere near as common as people think Surely packet loss due to poor signal quality is rather common over mobile networks and that packet loss still affects TCP's congestion window. Admittedly anecdotal, but I just connected to a 5G network with low signal strength and it certainly seems to be…
It isn't. Or at least wasn't back in the UMTS / early LTE era that's being discussed; I got out of that game before 5G. The base stations and terminals are constantly monitoring the signal quality and adjusting the error correction rate. A bad signal will mean that there's more error correction overhead, and that's why the connection is slower overall. Second,the radio protocol doesn't treat data transmissions as a o…
Everyone who is using a phone knows that what you are saying is not true. Otherwise we would not experience dropped calls, connection resets and mobile data being unavailable. Mobile networks are unreliable and you can't paper it over with some magic on TCP or HTTP2/3 level.
EDIT: better yet, anyone can just use network tools on their smartphone to see for themselves that mobile networks do drop TCP packets, UDP packets and ICMP packets very freely. Just check yourself!
Re: HTTP/2 and HTTP/3 explained
#114Earlier quoted context omitted.
It isn't. Or at least wasn't back in the UMTS / early LTE era that's being discussed; I got out of that game before 5G. The base stations and terminals are constantly monitoring the signal quality and adjusting the error correction rate. A bad signal will mean that there's more error correction overhead, and that's why the connection is slower overall. Second,the radio protocol doesn't treat data transmissions as a o…
Everyone who is using a phone knows that what you are saying is not true. Otherwise we would not experience dropped calls, connection resets and mobile data being unavailable. Mobile networks are unreliable and you can't paper it over with some magic on TCP or HTTP2/3 level. EDIT: better yet, anyone can just use network tools on their smartphone to see for themselves that mobile networks do drop TCP packets, UDP pack…
Huh? I'm not talking about papering over it on the TCP or HTTP/2 level. I'm talking about the actual physical radio protocols, and my message could not be more explicit about it.
If you don't understand something, it'd be more productive to ask questions than just make shit up like that.
Re: HTTP/2 and HTTP/3 explained
#115Earlier quoted context omitted.
Everyone who is using a phone knows that what you are saying is not true. Otherwise we would not experience dropped calls, connection resets and mobile data being unavailable. Mobile networks are unreliable and you can't paper it over with some magic on TCP or HTTP2/3 level. EDIT: better yet, anyone can just use network tools on their smartphone to see for themselves that mobile networks do drop TCP packets, UDP pack…
Huh? I'm not talking about papering over it on the TCP or HTTP/2 level. I'm talking about the actual physical radio protocols, and my message could not be more explicit about it. If you don't understand something, it'd be more productive to ask questions than just make shit up like that.
You made a claim that packet loss in mobile networks is not a common occurrence. This claim is patently wrong and anyone with a smartphone can see for themselves.
Re: HTTP/2 and HTTP/3 explained
#116Earlier quoted context omitted.
Seeing early QUIC development not account for the DDoS potential of choosing UDP makes it pretty clear that networking is not top-of-mind.
Are you saying there's ddos potential because UDP itself doesn't have a connection handshake? There's still one on top of UDP. The initial packet could be forged, but so could one from TCP (a SYN flood).
SYN flood cookies are probably older than me at this point
Re: HTTP/2 and HTTP/3 explained
#117Earlier quoted context omitted.
Huh? I'm not talking about papering over it on the TCP or HTTP/2 level. I'm talking about the actual physical radio protocols, and my message could not be more explicit about it. If you don't understand something, it'd be more productive to ask questions than just make shit up like that.
You made a claim that packet loss in mobile networks is not a common occurrence. This claim is patently wrong and anyone with a smartphone can see for themselves.
In reality it's quite hard for somebody to observe that themselves using just their smartphone. The only way they can do it is by getting a packet trace, which they won't have the permissions to capture on the phone, nor the skill to interpret. (Ideally they'd want to get packet traces from multiple points in the network to understand where the anomalies are happening, but that's even harder.)
In principle you could observe it from some kind of OS level counters that aren't ACLd, but in practice the counters are not reliable enough for that.
Now, the things like "calls dropping" or "connections getting reset" that you're calling out have nothing to do with packet loss. It's pretty obvious that you're not very technical and think that all error conditions are just the same thing and you can just mix them together. But what comes out is just technobabble.
Re: HTTP/2 and HTTP/3 explained
#118Earlier quoted context omitted.
You made a claim that packet loss in mobile networks is not a common occurrence. This claim is patently wrong and anyone with a smartphone can see for themselves.
In reality it's quite hard for somebody to observe that themselves using just their smartphone. The only way they can do it is by getting a packet trace, which they won't have the permissions to capture on the phone, nor the skill to interpret. (Ideally they'd want to get packet traces from multiple points in the network to understand where the anomalies are happening, but that's even harder.) In principle you could…
Modern mobile networks use exactly the same protocol to carry voice and data. Because voice is just data. When your call is fading or being intermittent then the packets are being dropped. In such situation packets of your mobile data for instance a web page being loaded by a browser are also being dropped. Mobiles drop packets left and right when reception deteriorates or there are too many subscribers trying to use the shared radio channel. And HTTP2 or 3 can't do much about it because it's not magic, if you lose data you need to retransmit it which TCP and HTTP/1.1 can do just as well. BTM UMTS which you claim you were so professionally involved in also uses converged backbone and carries both data and voice the same way so you should have know it already lol :)
Re: HTTP/2 and HTTP/3 explained
#119Earlier quoted context omitted.
Then HTTP[23] are significantly more costly to implement, they are a mistake then. Nothing to brag about then.
We should have stayed in Gopher.
Even HTTP1.0 is fairly enough and dead simple to implement.
Usually, just a bunch of planned obsolescence fan boys.
Re: HTTP/2 and HTTP/3 explained
#120Earlier quoted context omitted.
That's a pretty silly take. You're basically asserting that implementation difficulty is always the main priority, and there can never be any worthwhile tradeoffs that could offset that complexity. But in reality, the world probably only needs a few dozen H3 implementations, just like there are only tens of production TCP stacks. But those implementations will be used by billions of people, hundreds of billions of ma…
Enter IPv6. Same arguments, it's 'only' a matter of implementation. 30 years later still most of the implementations are worse than IPv4.
At least IPv6 is reasonably scaled for our world which IPv4 was never meant to be (The abomination of NAT).