Hacker News Reader

Comment by likeabbas | Hacker News Reader

Doesn't HTTP3 solve this with QUIC?

QUIC could be a candidate, RPC over UDP/IP is definitely the direction proposed by Ousterhout. He has a few specific TCP things he's listed as being undesirable and frankly I'm not sure how QUIC stacks up on.

- Bandwidth sharing (“fair” scheduling) - Sender-driven congestion control

See: https://arxiv.org/pdf/2210.00714.pdf (pdf download)

No, HTTP3 is not a message passing protocol. Its a proto remote file access protocol with a rich data channel designed by people who really didn't want it to be a file access protocol.

It does until you try to tcpdump :/

1) It's not TCP

2) It's a PITA on a 'trusted' network because there is not "encryption off" mode

Those are very solvable problems. I work with non-TCP traffic in pcaps very often and while I agree encrypted traffic is annoying to deal with sometimes because of the extra step it can be solved with good tooling.

tcpdump works fine with it, and any other ethernet or IP based protocol despite the commands name, it's just 2) that's a problem (for certain perspectives of what is a problem).

As long as governments attack networks with impunity, it’s a mistake to trust them.

See this well-known slide from the PRISM leaks as a reminder of this: https://upload.wikimedia.org/wikipedia/commons/f/f2/NSA_Musc...

Its a question of choosing when and how you encrypt.

For internal datacentre traffic, it depends on the value of the data. But you will need to do application level encryption.

For links between datacentres, encrypting links based on rules is a sensible and not horrifically challenging thing to do. If you're big enough to have to worry about the volume of encrypted traffic, then you have rules based bandwidth priorities.

for virtually everyone else, just use wireguard or some other VPN with encryption.

Reply on news.ycombinator.com