4 ms·

I don't think QUIC is a good example. If you realistically want to do something on the internet you absolutely have to use either TCP or UDP. There's no choice

by nsteel 2y ago

I don't think QUIC is a good example. If you realistically want to do something on the internet you absolutely have to use either TCP or UDP. There's no choice in it. But within the confines of your datacenter you can do whatever you want. Including re-inventing the wheel to be square-shaped if that fits better.

fidotron 2y ago
I legitimately couldn’t tell if the poster was sarcastic. Overpromotion of QUIC is verging on meme territory.
- Alex4386 2y ago
  My point was It is "worse than QUIC". What I really wanted to say was even "QUIC" (the garbo protocol decided to "encrypt" flow-control stuff) did that and decided to go on a UDP
  - Alex4386 2y ago
    Also they are the company which decided to ditch CANbus on their cars. This protocol itself is already a clown.
londons_explore 2y ago
Even if your training computer is fully within your control, occasionally you'll want to run your protocols over the internet for example to test a node in a remote location, debug some problem, etc. If you have requirements the internet cannot meet (eg. "latency must be <500us for correctness"), then it limits what you can do.
- fidotron 2y ago
  Do you run PCI over the internet to test boards remotely?
  - londons_explore 2y ago
    No, but thats a bit of a pain. If it could run over the internet, I'd be able to use standard tooling (eg. wireshark to see what messages are being sent to debug my driver). I'd be able to connect to a PCI card on another machine remotely and have it 'just work', albeit with poor performance. There's a lot you lose by inventing your own protocol, and you lose even more if your protocol can't be tunnelled over IP.
    - ethbr1 2y ago
      That's what engineering is though: losing things you care less about in exchange for gaining things you care more about. Your point about being able to reach the Internet probably isn't as important of a design goal as some latency ceiling within their cluster.

by nsteel 2y ago

fidotron 2y ago

I legitimately couldn’t tell if the poster was sarcastic. Overpromotion of QUIC is verging on meme territory.

Alex4386 2y ago
My point was It is "worse than QUIC". What I really wanted to say was even "QUIC" (the garbo protocol decided to "encrypt" flow-control stuff) did that and decided to go on a UDP
- Alex4386 2y ago
  Also they are the company which decided to ditch CANbus on their cars. This protocol itself is already a clown.

londons_explore 2y ago

Even if your training computer is fully within your control, occasionally you'll want to run your protocols over the internet for example to test a node in a remote location, debug some problem, etc. If you have requirements the internet cannot meet (eg. "latency must be <500us for correctness"), then it limits what you can do.

fidotron 2y ago
Do you run PCI over the internet to test boards remotely?
- londons_explore 2y ago
  No, but thats a bit of a pain. If it could run over the internet, I'd be able to use standard tooling (eg. wireshark to see what messages are being sent to debug my driver). I'd be able to connect to a PCI card on another machine remotely and have it 'just work', albeit with poor performance. There's a lot you lose by inventing your own protocol, and you lose even more if your protocol can't be tunnelled over IP.
  - ethbr1 2y ago
    That's what engineering is though: losing things you care less about in exchange for gaining things you care more about. Your point about being able to reach the Internet probably isn't as important of a design goal as some latency ceiling within their cluster.