Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some notes about HTTP/3

blog.erratasec.com

Post reply on HN
Print view View original

61–70 of 181 posts

Re: Some notes about HTTP/3

#61

Post by piannucci »

aaaaaaaaaab wrote: post #56

Interesting comment under the post: >The problem is fairness in the presence of network congestion. To a large extent it depends on most TCP implementations using the same congestion control algorithm, or at least algorithms that have the same general behavior. Google's developed a new algorithm called BBR that is robust, but also unfair. When a TCP connection implementing the NewReno algorithm shares a congested lin…

Race to the bottom is one thing. Yes, so-called “TCP unfriendly” protocols will muscle out any protocol that reacts to probability p random packet drops by a one-over-root-p reduction in throughput. But that does NOT mean that BBR will fail to avoid congestive collapse. The one-over-root-p behavior is outdated and actually harmful on wireless links, anyway; it was designed for the assumption that all losses are congestive losses; but today, many losses are purely random and not an indicator of congestion. BBR and other modern TCP-unfriendly congestion control protocols are a necessary step. TCP-friendliness must die.

Re: Some notes about HTTP/3

#62

Post by Dylan16807 »

aaaaaaaaaab wrote: post #56

Interesting comment under the post: >The problem is fairness in the presence of network congestion. To a large extent it depends on most TCP implementations using the same congestion control algorithm, or at least algorithms that have the same general behavior. Google's developed a new algorithm called BBR that is robust, but also unfair. When a TCP connection implementing the NewReno algorithm shares a congested lin…

> and Internet brown-outs as in the 1980s and 1990s would come back.

That part definitely needs more justification. An algorithm playing badly with NewReno doesn't mean that we'd be worse off if every system switched to it.

Re: Some notes about HTTP/3

#63

Post by nly »

Is it me or does this part make no sense

> But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the well-known recv() function to receive a single packet at a time, you can call recvmmsg() to receive a bunch of UDP packets at once.

TCP is a streaming protocol, there are no datagrams to read one at a time. Nothing stops you from reading the entire kernel buffer (containing multiple HTTP messages) in to userspace in one syscall.

Re: Some notes about HTTP/3

#64

Post by richardwhiuk »

piannucci wrote: post #61
aaaaaaaaaab wrote: post #56

Interesting comment under the post: >The problem is fairness in the presence of network congestion. To a large extent it depends on most TCP implementations using the same congestion control algorithm, or at least algorithms that have the same general behavior. Google's developed a new algorithm called BBR that is robust, but also unfair. When a TCP connection implementing the NewReno algorithm shares a congested lin…

Race to the bottom is one thing. Yes, so-called “TCP unfriendly” protocols will muscle out any protocol that reacts to probability p random packet drops by a one-over-root-p reduction in throughput. But that does NOT mean that BBR will fail to avoid congestive collapse. The one-over-root-p behavior is outdated and actually harmful on wireless links, anyway; it was designed for the assumption that all losses are conge…

WiFi generally doesn't drop packets - it's usual failure mode is for latency to spike horribly for a clump of packets.

Re: Some notes about HTTP/3

#65

Post by nly »

I hope we get in-kernel implementations of QUIC at some point because having to find a portable third-party library for userspace sounds about as appealing as installing Winsock on Windows 95.

Re: Some notes about HTTP/3

#66

Post by denormalfloat »

Tuna-Fish wrote: post #18
meddlepal wrote: post #4

I feel like the adoption of HTTP/3 is going to be much much slower than HTTP/2... Besides Google Cloud do any of the major cloud providers have UDP load balancers?

The protocol has been designed so that both the endpoints of a stream can seamlessly change IP addresses. This ought to make load balancing easier?

While this is true, a lot of software is not prepared to have connections change IP address. Lot's of networking software works on the idea of a loop which assigns each connection (5-tuple) to a thread. If QUIC were to be more widely used, the association of the connection would have to be linked to the connection identifier in QUIC, which is different than the 5-tuple. Basically, any software that assumed 1 connection maps to 1 file descriptor, is going to have to be rewritten.

This also means the kernel, which could previously steer traffic to a connection onto a single core. Realistically, QUIC will need a BPF filter to inspect the connection identifier and steer to the same core in the event of an IP address change.

All this is to say: I don't think most software is ready for QUIC, even if the protocol allows for cool things.

Re: Some notes about HTTP/3

#67

Post by blitmap »

romed wrote: post #44
blitmap wrote: post #35

Earlier quoted context omitted.

Again, as someone who does not completely grok QUIC I am not dismissing it. I was hoping if some parameters were not exposed work would be put toward making these available through existing interfaces.

Linux network maintainers have repeatedly rejected attempts by Eric Dumazet and others to expose delack_min and other parameters to userspace. This is the kernel tyranny to which I refer. Notably many of the people whose proposals have been shot down by linux netdev are currently working on QUIC.

Somewhat related: I do hope userspace network stacks get easier to stand up (with strict testing). It would be nice to move an attack surface like that out of the kernel.

Re: Some notes about HTTP/3

#68

Post by bb88 »

X-Istence wrote: post #28
Tuna-Fish wrote: post #18

Earlier quoted context omitted.

The protocol has been designed so that both the endpoints of a stream can seamlessly change IP addresses. This ought to make load balancing easier?

Not unless you want to get through firewalls seamlessly. UDP "state" tracking is a thing, and if my firewall sees a UDP packet destined for it without knowing the remote IP address it's going to drop it.

If the client side changes it's IP address, it's a lot easier say than if the server side does. Typically because the server won't reject new UDP packets coming in from the internet.

The load balancer will route any ongoing sessions with the session id, and not the ip address.

Re: Some notes about HTTP/3

#69

Post by Dylan16807 »

tor_user wrote: post #53
zmanian wrote: post #52

Earlier quoted context omitted.

Tor doesn't support UDP so no HTTP/3 but one would expect most services would be available for the foreseeable future over HTTP/2 as well.

like websites without javascript?

Working without javascript requires development time. Running old versions of HTTP doesn't. Version 1.1 is going to be fully supported for a long time.

Re: Some notes about HTTP/3

#70

Post by TazeTSchnitzel »

nly wrote: post #63

Is it me or does this part make no sense > But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the well-known recv() function to receive a single packet at a time, you can call recvmmsg() to receive a bunch of UDP packets at once. TCP is a streaming protocol, there are no datagrams to read one at a time. Nothing stops you from reading the entire kernel buffer…

They're not talking about receiving TCP packets there.
Post reply on HN