diff --git a/mqtt.md b/mqtt.md
index f75fc31..67c51f5 100644
--- a/mqtt.md
+++ b/mqtt.md
@@ -3,6 +3,92 @@ RSMP 4 is expected to be build on top of [MQTT](https://mqtt.org/), a protocol p
 
 MQTT is based on a publish-subscribe model with a broker in the middle and topics as a flexible way to route and filter message.
 
+## Why MQTT?
+
+RSMP were designed and developed about 15 years ago. Over the years RSMP has
+been regularly updated to include more features since more desired use cases has
+been identified.
+
+As the RSMP specification has evolved the limitations of some of its original
+designed choices has gotten more apparent. This includes several aspects of the
+protocol.
+
+### Performance
+
+By default, RSMP sends all data as human readable JSON. Although it's great for
+troubleshooting, it also means that each RSMP packet is quite large and uses a
+relativity high amount of network traffic.
+
+Each packet transmitted needs to be acknowledged, not just on the underlying TCP
+layer, but also on the RSMP layer using "MessageAck". This leads to a high
+amount of network roundtrips increasing network traffic and latency.
+
+RSMP has built in support for buffering to compensate for unreliable networks.
+Up to 10000 messages must be buffered in the equipment and sent upon connection
+reestablishment. But since RSMP doesn't prioritize any messages and all messages
+needs to be sent using the FIFO-principle it means that all buffered messages
+needs to delivered before the most recent messages can be transmitted. This
+means it may take a long time between connection establishment and receiving the
+current state of the equipment - especially if the connection is slow.
+
+### Management
+
+RSMP doesn't have any concept of auto discovery of the connected equipment and
+requires a relative large amount of configuration in order to work correctly.
+
+In order to support communicating with multiple supervisors, each controller
+needs to independently establish connection to each supervisor, including
+keeping track of all associated connection related parameters. The controllers
+also need to implement access control to prevent any management system to send
+arbitrary commands.
+
+To mitigate performance related issues regarding buffering, the controller needs
+to be configured not to buffer unneeded message types. This configuration needs
+to be done for each controller.
+
+Updating RSMP to adress these issues is possible, but not backwards compatible.
+A better use of our efforts is to rely on existing standards where these issues
+already are addressed.
+
+### Design of MQTT
+
+MQTT is well known and established in the industry with many well proven
+implementations in use.
+
+MQTT introduces a concept of QoS which ensures a higher level of robustness of
+message delivery, partially replacing the need of buffering data which is part
+of the current specification.  Any further need to transfer historical data can
+be implemented separately where needed.
+
+Instead of using a traditional client-service architecture MQTT uses broker in
+the middle. The use of a broker solves several issues that currently exists in
+RSMP. It solves performance issues since publishing and subscriptions can be
+handled independently of each other. It also handles management issues since the
+equipment doesn't need to keep track of communicating with several management
+systems. Access control can be managed by the broker.
+
+MQTT also has mature and proven standard software libraries and simulators which
+is readily available.
+
+Adopting MQTT in RSMP means that we can focus on the content of the messages
+instead of the transport mechanisms.
+
+#### Scalability
+
+By leveraging load balancing, MQTT could distribute the communication load across
+multiple brokers, potentially enhancing system performance under heavy traffic.
+The ability to broadcast messages to groups of devices using topic hierarchies
+might further optimize message delivery. These features could contribute to better
+management of system load and improve overall resilience, ensuring uninterrupted
+communication even under failure or high-demand scenarios.
+
+```mermaid
+graph LR;
+  MQTT1<--->MQTT2;
+  MQTT1<--->MQTT3;
+  MQTT2<--->MQTT3;
+```
+
 ## MQTT Broker
 In MQTT, clients all connect to the broker, which routes messages according to which topics are used when subscribing and publishing: