The Ugliness of the Underlying Transport
The IETF-103 was a great experience for me. I am somehow new to the Internet Society and it is a great experience watching and participating in the discussions. I am - of course - mostly interested in developments around the Internet of Things and low power wireless. Coming from the alternative world of Bluetooth, where I landed as a result of my ultra practical approach to solving real world problems, it is very interesting to see how the same (or similar) problems are being discovered and attempted to be solved by people coming from the highly structured and cleanly layered world of wired networking.
Some highlights that were particularly encouraging to me came from the ROLL working group (ROLL stands for Routing Over Low power Lossy networks). For the 2nd time in a row I heard voices arguing along the lines: "this is radio, you cannot use the wired network paradigms here". So true. At Bluetooth mesh we have been designing for that since the inception. With the initial critique of "Bluetooth being a flood network and not using proper routing techniques". Which actually is the foundation of the success of Bluetooth mesh.
Bluetooth (and other radios in this category, such as 802.15.4) are half-duplex, which means when they transmit (or retransmit when relaying a message), they cannot receive anything, resulting in an inherent packet loss. Radio collisions also contribute to this loss. In the end we have - what is referred to as - a lossy network. And no matter how much "self-healing' and "properly routing" this network is, it will continue to be lossy. And due to limited bandwidth will saturate quickly. And the only way to balance the lossiness is redundancy. You need more (copies of) packets in the air or you need more nodes participating in a forwarding route. This is entirely different from the wired world, where an Ethernet switch can perfectly keep receiving incoming frames on one port while sending them over a second port: because the ports are isolated and per-link packet loss in negligible. This inherent wireless weakness can be balanced with the inherent strength of of the radio: multiple nodes can overhear the transmission and participate in forwarding the message. As long as the messages do not have the explicit "next hop" address (like they do in wired routing systems), they can easily travel along redundant multi-lane paths towards their destinations. ROLL has discovered that and they are happy with the design. Hint: we've been doing that in Bluetooth mesh, and multi-lane / multi-path delivery does work, bringing the reliability up to the "wired-like" numbers.
But it is not only the forwarding plane that needs to be properly architected. It is also the application layer. What has been very encouraging, the spirit of the Bluetooth's [distributed] application layer architecture, based on a pub-sub paradigm, aligns very nicely with the spirit of the ICN [Information - Centric Network] that is developed by the ICNRG.
Finally - one of the best comments I heard while in Bangkok was: "...for that to really work you need to expose all the ugliness of the underlying transport....". Sooo true. While layered approach is elegant, there is nothing performing better than the application aware of the nature and limitations of the layers below. For example: a mesh lighting control application may decide to transmit several delay-compoensated unacknowledged multicast messages in a row, to achieve perfectly synchronized group action. A brute-force alternative to that is a unicast / acknowledged scheme that some misleadingly call "reliable", which leads to delays and popcorn effects. It is like an experienced air traveler knows the airlines and airports and decides not to check her luggage, as she simply knows the layover is too short for the luggage to make it, especially in winter, when the arriving flight will likely be delayed due to de-icing. Relying on routes printed on a ticket is like relying on nice routes that join nodes in a mesh network on a PowerPoint slide. The reality is waaaay different and the experience and awareness of that will help you get to the destination. A nice slide of a mesh network does not guarantee at all the real world behavior.
Some highlights that were particularly encouraging to me came from the ROLL working group (ROLL stands for Routing Over Low power Lossy networks). For the 2nd time in a row I heard voices arguing along the lines: "this is radio, you cannot use the wired network paradigms here". So true. At Bluetooth mesh we have been designing for that since the inception. With the initial critique of "Bluetooth being a flood network and not using proper routing techniques". Which actually is the foundation of the success of Bluetooth mesh.
Bluetooth (and other radios in this category, such as 802.15.4) are half-duplex, which means when they transmit (or retransmit when relaying a message), they cannot receive anything, resulting in an inherent packet loss. Radio collisions also contribute to this loss. In the end we have - what is referred to as - a lossy network. And no matter how much "self-healing' and "properly routing" this network is, it will continue to be lossy. And due to limited bandwidth will saturate quickly. And the only way to balance the lossiness is redundancy. You need more (copies of) packets in the air or you need more nodes participating in a forwarding route. This is entirely different from the wired world, where an Ethernet switch can perfectly keep receiving incoming frames on one port while sending them over a second port: because the ports are isolated and per-link packet loss in negligible. This inherent wireless weakness can be balanced with the inherent strength of of the radio: multiple nodes can overhear the transmission and participate in forwarding the message. As long as the messages do not have the explicit "next hop" address (like they do in wired routing systems), they can easily travel along redundant multi-lane paths towards their destinations. ROLL has discovered that and they are happy with the design. Hint: we've been doing that in Bluetooth mesh, and multi-lane / multi-path delivery does work, bringing the reliability up to the "wired-like" numbers.
But it is not only the forwarding plane that needs to be properly architected. It is also the application layer. What has been very encouraging, the spirit of the Bluetooth's [distributed] application layer architecture, based on a pub-sub paradigm, aligns very nicely with the spirit of the ICN [Information - Centric Network] that is developed by the ICNRG.
Finally - one of the best comments I heard while in Bangkok was: "...for that to really work you need to expose all the ugliness of the underlying transport....". Sooo true. While layered approach is elegant, there is nothing performing better than the application aware of the nature and limitations of the layers below. For example: a mesh lighting control application may decide to transmit several delay-compoensated unacknowledged multicast messages in a row, to achieve perfectly synchronized group action. A brute-force alternative to that is a unicast / acknowledged scheme that some misleadingly call "reliable", which leads to delays and popcorn effects. It is like an experienced air traveler knows the airlines and airports and decides not to check her luggage, as she simply knows the layover is too short for the luggage to make it, especially in winter, when the arriving flight will likely be delayed due to de-icing. Relying on routes printed on a ticket is like relying on nice routes that join nodes in a mesh network on a PowerPoint slide. The reality is waaaay different and the experience and awareness of that will help you get to the destination. A nice slide of a mesh network does not guarantee at all the real world behavior.
Comments
Post a Comment