7 ms·

Ugh. The point of MQTT is that it's simple! It's trivial to implement on even 8-bit microcontrollers. Adding MQTT messaging to embedded stuff is a joy and even

Ugh. The point of MQTT is that it's simple! It's trivial to implement on even 8-bit microcontrollers. Adding MQTT messaging to embedded stuff is a joy and even setting up a broker is a piece of cake. It's fantastic. HTTP/3 isn't simple! It's a huge pain in the ass! Why would anyone want to do this to themselves on embedded‽ The only answer I can come up with is, "it let's us keep doing things the way we've always done them... With web servers."

belter 5y ago
The authors do mention in their findings that: "...While QUIC has been proven by different researchers to be more advantageous than TCP for MQTT traffic, our hypothesis was that further gains may be found through a pure H3 solution. The reasoning behind this hypothesis was rooted in QUIC’s original design intent and various optimizations specifically for carrying HTTP traffic. This turned out to be the case for performance, but posed a trade-off for resource consumption. ... Performance indicators were investigated in addition to network and device level overhead. MQTT-over-QUIC was found to put marginally less strain over the network than H3, but H3 offered a key performance savings of 1-RTT in the time to first data frame..."
- pantalaimon 5y ago
  What about CoAP? It supports DTLS too.
baybal2 5y ago
> HTTP/3 isn't simple! It's a huge pain in the ass! Why would anyone want to do this to themselves on embedded‽ Why would anyone want to do it on desktop? Let alone server-server APIs? HTTP 2 and 3 are spec monstrosities, which currently, effectively don't work. HTTP 2 is for example slower than HTTP 1.1 over modern TLS even on near perfect connections. HTTP 3 seems to be even slower in real world use. I strongly believe Google fudged its "real world trial data" to push W3C to adopt it.
- slver 5y ago
  Sometimes when you come up with a tidbit that the entire world of experience contradicts, it's healthy to stop and think "wait, am I full of shit?" Of course, you may not be full of shit, but let's say the odds are you are. What "real world data" you have to contradict Google's and basically everyone's personal experience? I have sites that are unbearable over HTTP/1.x and instant over HTTP/2. But maybe I was fooled by Google.
  - mnahkies 5y ago
    I think QUICs design around handling network switches is a primary advantage. Devices are not static anymore and tolerating a switch from WiFi to mobile etc is a big plus
- driverdan 5y ago
  > HTTP 2 is for example slower than HTTP 1.1 over modern TLS even on near perfect connections. > > HTTP 3 seems to be even slower in real world use. [citation needed]
- vitus 5y ago
  > HTTP 2 and 3 are spec monstrosities A valid concern. > which currently, effectively don't work. Citation needed. > HTTP 2 is for example slower than HTTP 1.1 over modern TLS even on near perfect connections. H2 attempts to solve a number of problems present in HTTP 1.1 when your connection _isn't_ perfect -- head-of-line (HOL) blocking comes to mind, although since it still uses a single TCP connection, it's not a complete solution. It also provides header compression which can yield significant performance wins (bandwidth usage, latency if it reduces RTTs, CPU usage although this is always a mixed bag with compression). H3 solves the transport-layer HOL blocking issue, and has a number of other RTT-reducing features (e.g. removing the need for TCP 3-way handshake -> TLS handshake -> actual sending of requests by mandating the use of TLS, which admittedly can have performance impacts compared to, say, unencrypted HTTP/1.1). It does have a number of aspects which could negatively impact performance depending on your use case (e.g. userspace congestion control, always-on encryption). If you're dealing with small resources without HTTP pipelining where individual HTTP requests can and will complete in 1 RTT (and parallelization is limited because of dependencies between resources, e.g. a HTTP page contains an iframe which contains a js file which fetches an image), then your end-user latency will be dominated by the number of RTTs imposed by the underlying transport. And even if you include pipelining (assuming a non-buggy implementation, which inherently limits concurrency in order to reap its benefits), then you're still subject to HOL blocking, both request- and connection-level, which is problematic in moderate loss scenarios (wifi, mobile).
detaro 5y ago
"trivial to implement" if you don't need encryption. Which you kinda do most of the time. Not everything runs in the design constraints of an 8bit micro. It would also be nice if you'd at least pretend to engage with the arguments in the paper, instead of making up imagined reasons.
- ori_b 5y ago
  It's also trivial to tunnel an unencrypted protocol over TLS. https://man.openbsd.org/tls_connect.3 https://man.openbsd.org/tls_connect.3 Or even https://www.stunnel.org/ https://www.stunnel.org/
  - scoopertrooper 5y ago
    But that’s negate many of the benefits of quic!
  - SV_BubbleTime 5y ago
    I ran into a lot of difficulty when dealing with devices that needed a bridge to access the internet. So device doesn’t have a tcp stack and requires a socket-like connection to an intentional-man-in-the-middle. Implementing payload end to end encrypted MQTT was easy enough. Any thoughts on TLS for that scenario? At best I could have a simulated socket, but always to an untrusted middle man.
    - SV_BubbleTime 5y ago
      Turns out ONE answer is that DTLS is TLS for datagram connections (ie: UDP) and it’s pretty easy to forward along UDP packets at a proxy (as there is no need at all to track what sent or needs a retry). It should be noted (if anyone reads this) that DTLS has protections and reliability on packets to establish the connection, but once it’s established it just goes back to being UDP although now encrypted, so you need to be ok with losses. If you need messaging on top of that, CoAP adds in the counters and retries and reliability to UDP. Making UDP a little more like TCP but features to get this are one level higher in the CoAP packet. It’s a little weird, but gets you relatively reliable request/response HTTP-like (CoAP CONFIRMATION) and also event driven async MQTT-like (NON-CONFIRMATION). So that’s pretty cool. Although near for me as GCP and Azure support CoAP but for some reason Amazon seems to refuse to and I’m locked in to Amazon for other reasons.
rurban 5y ago
Exactly. I'm always sceptical of protocols where the header size is 3x bigger than my body. I just implemented MQTT via NB-IoT, and I had to remove the subscribe receive part. My other custom protocol fits into a single TCP frame, which fits into about 5 radio frames, I think. Of course I compress the hell out of it, and for MQTT clients I just put a small MQTT bridge on the host translating the body. The battery should last 10 years afterall, and TCP costs 95% of all power. The less packets, the longer it lasts. With http/3 I would give it 2 years max. And much more dropped packets. I'm also pretty sure that I don't have the ram for http/3
liquidise 5y ago
> ‽ Amazing what one can learn[0] on a Sunday morning in unexpected places. 0: https://en.wikipedia.org/wiki/Interrobang https://en.wikipedia.org/wiki/Interrobang
- belter 5y ago
  "The rise and fall of the interrobang" :-) https://www.economist.com/the-economist-explains/2014/10/01/the-rise-and-fall-of-the-interrobang https://www.economist.com/the-economist-explains/2014/10/01/...
- mtwittman 5y ago
  Also good[0]. 0:https://99percentinvisible.org/episode/interrobang/ https://99percentinvisible.org/episode/interrobang/
Matthias247 5y ago
Http/3 is actually simple if you just look at that one and don’t include quic itself. It’s far easier than http/2 since the transport layer does the multiplexing, and just defines some simple header and body frames on top which are imho not harder to decode than looking for a `\r\n\r\n` in http 1. the main challenge is Header encoding via qpack which is mostly overwhelming someone with encoding options (Huffman, static tables, dynamic tables on another stream, etc…). But at least one can now opt out of supporting dynamic tables without losing interoperability
dheera 5y ago
I want a DDS implementation on microcontrollers. I really want them to be able to speak ROS2. That would be the ultimate awesomeness, since it needs no broker/server/master, devices on a network can just discover and talk to each other in a decentralized fashion.
- im_down_w_otp 5y ago
  Doesn't this exist? Isn't that the whole point of RTI's "Micro Edition" or whatever they call it.
  - dheera 5y ago
    I think I saw one for STM32 but they're hard to work with. Really looking for one that works on ESP32 ...

belter 5y ago

The authors do mention in their findings that: "...While QUIC has been proven by different researchers to be more advantageous than TCP for MQTT traffic, our hypothesis was that further gains may be found through a pure H3 solution. The reasoning behind this hypothesis was rooted in QUIC’s original design intent and various optimizations specifically for carrying HTTP traffic. This turned out to be the case for performance, but posed a trade-off for resource consumption. ... Performance indicators were investigated in addition to network and device level overhead. MQTT-over-QUIC was found to put marginally less strain over the network than H3, but H3 offered a key performance savings of 1-RTT in the time to first data frame..."

pantalaimon 5y ago
What about CoAP? It supports DTLS too.

baybal2 5y ago

> HTTP/3 isn't simple! It's a huge pain in the ass! Why would anyone want to do this to themselves on embedded‽ Why would anyone want to do it on desktop? Let alone server-server APIs? HTTP 2 and 3 are spec monstrosities, which currently, effectively don't work. HTTP 2 is for example slower than HTTP 1.1 over modern TLS even on near perfect connections. HTTP 3 seems to be even slower in real world use. I strongly believe Google fudged its "real world trial data" to push W3C to adopt it.

slver 5y ago
Sometimes when you come up with a tidbit that the entire world of experience contradicts, it's healthy to stop and think "wait, am I full of shit?" Of course, you may not be full of shit, but let's say the odds are you are. What "real world data" you have to contradict Google's and basically everyone's personal experience? I have sites that are unbearable over HTTP/1.x and instant over HTTP/2. But maybe I was fooled by Google.
- mnahkies 5y ago
  I think QUICs design around handling network switches is a primary advantage. Devices are not static anymore and tolerating a switch from WiFi to mobile etc is a big plus
driverdan 5y ago
> HTTP 2 is for example slower than HTTP 1.1 over modern TLS even on near perfect connections. > > HTTP 3 seems to be even slower in real world use. [citation needed]
vitus 5y ago
> HTTP 2 and 3 are spec monstrosities A valid concern. > which currently, effectively don't work. Citation needed. > HTTP 2 is for example slower than HTTP 1.1 over modern TLS even on near perfect connections. H2 attempts to solve a number of problems present in HTTP 1.1 when your connection _isn't_ perfect -- head-of-line (HOL) blocking comes to mind, although since it still uses a single TCP connection, it's not a complete solution. It also provides header compression which can yield significant performance wins (bandwidth usage, latency if it reduces RTTs, CPU usage although this is always a mixed bag with compression). H3 solves the transport-layer HOL blocking issue, and has a number of other RTT-reducing features (e.g. removing the need for TCP 3-way handshake -> TLS handshake -> actual sending of requests by mandating the use of TLS, which admittedly can have performance impacts compared to, say, unencrypted HTTP/1.1). It does have a number of aspects which could negatively impact performance depending on your use case (e.g. userspace congestion control, always-on encryption). If you're dealing with small resources without HTTP pipelining where individual HTTP requests can and will complete in 1 RTT (and parallelization is limited because of dependencies between resources, e.g. a HTTP page contains an iframe which contains a js file which fetches an image), then your end-user latency will be dominated by the number of RTTs imposed by the underlying transport. And even if you include pipelining (assuming a non-buggy implementation, which inherently limits concurrency in order to reap its benefits), then you're still subject to HOL blocking, both request- and connection-level, which is problematic in moderate loss scenarios (wifi, mobile).

detaro 5y ago

"trivial to implement" if you don't need encryption. Which you kinda do most of the time. Not everything runs in the design constraints of an 8bit micro. It would also be nice if you'd at least pretend to engage with the arguments in the paper, instead of making up imagined reasons.

ori_b 5y ago
It's also trivial to tunnel an unencrypted protocol over TLS. https://man.openbsd.org/tls_connect.3 https://man.openbsd.org/tls_connect.3 Or even https://www.stunnel.org/ https://www.stunnel.org/
- scoopertrooper 5y ago
  But that’s negate many of the benefits of quic!
- SV_BubbleTime 5y ago
  I ran into a lot of difficulty when dealing with devices that needed a bridge to access the internet. So device doesn’t have a tcp stack and requires a socket-like connection to an intentional-man-in-the-middle. Implementing payload end to end encrypted MQTT was easy enough. Any thoughts on TLS for that scenario? At best I could have a simulated socket, but always to an untrusted middle man.
  - SV_BubbleTime 5y ago
    Turns out ONE answer is that DTLS is TLS for datagram connections (ie: UDP) and it’s pretty easy to forward along UDP packets at a proxy (as there is no need at all to track what sent or needs a retry). It should be noted (if anyone reads this) that DTLS has protections and reliability on packets to establish the connection, but once it’s established it just goes back to being UDP although now encrypted, so you need to be ok with losses. If you need messaging on top of that, CoAP adds in the counters and retries and reliability to UDP. Making UDP a little more like TCP but features to get this are one level higher in the CoAP packet. It’s a little weird, but gets you relatively reliable request/response HTTP-like (CoAP CONFIRMATION) and also event driven async MQTT-like (NON-CONFIRMATION). So that’s pretty cool. Although near for me as GCP and Azure support CoAP but for some reason Amazon seems to refuse to and I’m locked in to Amazon for other reasons.

rurban 5y ago

Exactly. I'm always sceptical of protocols where the header size is 3x bigger than my body. I just implemented MQTT via NB-IoT, and I had to remove the subscribe receive part. My other custom protocol fits into a single TCP frame, which fits into about 5 radio frames, I think. Of course I compress the hell out of it, and for MQTT clients I just put a small MQTT bridge on the host translating the body. The battery should last 10 years afterall, and TCP costs 95% of all power. The less packets, the longer it lasts. With http/3 I would give it 2 years max. And much more dropped packets. I'm also pretty sure that I don't have the ram for http/3

liquidise 5y ago

> ‽ Amazing what one can learn[0] on a Sunday morning in unexpected places. 0: https://en.wikipedia.org/wiki/Interrobang https://en.wikipedia.org/wiki/Interrobang

belter 5y ago
"The rise and fall of the interrobang" :-) https://www.economist.com/the-economist-explains/2014/10/01/the-rise-and-fall-of-the-interrobang https://www.economist.com/the-economist-explains/2014/10/01/...
mtwittman 5y ago
Also good[0]. 0:https://99percentinvisible.org/episode/interrobang/ https://99percentinvisible.org/episode/interrobang/

Matthias247 5y ago

Http/3 is actually simple if you just look at that one and don’t include quic itself. It’s far easier than http/2 since the transport layer does the multiplexing, and just defines some simple header and body frames on top which are imho not harder to decode than looking for a `\r\n\r\n` in http 1. the main challenge is Header encoding via qpack which is mostly overwhelming someone with encoding options (Huffman, static tables, dynamic tables on another stream, etc…). But at least one can now opt out of supporting dynamic tables without losing interoperability

dheera 5y ago

I want a DDS implementation on microcontrollers. I really want them to be able to speak ROS2. That would be the ultimate awesomeness, since it needs no broker/server/master, devices on a network can just discover and talk to each other in a decentralized fashion.

im_down_w_otp 5y ago
Doesn't this exist? Isn't that the whole point of RTI's "Micro Edition" or whatever they call it.
- dheera 5y ago
  I think I saw one for STM32 but they're hard to work with. Really looking for one that works on ESP32 ...