Tuesday, June 4, 2013

Philosophy (Installment 3 of a series)

In the previous installments I discussed the assimilation of communications and computation, the spectrum linking hardware and software, and how to virtualize communications functionalities. This installment is all about configurability and programmability.

I entitled this blog entry philosophy, since philosophy is literally the "love of knowledge", and generally deals with what we can learn about the world about us and how best to function in this world. Indeed epistemology is concerned with the nature of knowledge and ontology deals with the nature of existence itself.
Knowledge concerning the surrounding world is often indispensable for the proper functioning of communications devices. For example, a transmitter must know the frequency on which to transmit and the modulation scheme to use. An IP host needs to know the destination address to which to send packets, and the protocol to use. But how do communications devices acquire this knowledge?
Let’s start by envisioning a network element that functions out-of-the-box without any configuration options. We can say that such a network element is “zero-touch”. For example, fiber converters, hubs and repeaters, and even simple learning bridges are essentially zero-touch. Devices can be zero-touch simply because they are very limited in functionality. Or they can be flexible and sophisticated but still zero-touch because they are capable of learning all they need to know from their environment. Paradoxically zero-touch devices are either exceedingly dumb or exceedingly intelligent.
Many devices designed to be used by unsophisticated end-users, such as televisions and cellphones, hypothetically function without being set up. But this is obviously an over-simplification of the true situation. Modern televisions have remote controls that only the tech-savvy can handle (Is the set-top box connected to HDMI-1 or 2?  Which of the five supported aspect ratio options is best for HD?). Cellphone users are often stymied when they need to change time-zone or select a network. Configuring home WiFi routers is a task well beyond the capabilities of most mortals (Does my ISP use EoPPP, or L2TP or PPTP? Should my WiFi security be based on WPA or WPA2 with LEAP or PEAP? How does one set up port blocking? What exactly is an 802.11 beacon anyway?)
Early Ethernet switches were essentially zero-touch; they learned everything they needed to know by conversing with each other; when they didn’t know how to handle a frame they simply flooded it and observed the consequences. But then along came VLANs and one needed to configure which VIDs were to be admitted/emitted for each port (or to dictate “admit all”) as well as the default VLAN identifier for untagged frames. And the situation has gotten a lot worse since then. Ethernet OAM requires defining and configuring MEPs and MIPs, MEF services bring with them a complex set of bundling and bandwidth profile parameters, configuring 1X authentication can be a nightmare even for experts, and a PhD may be insufficient qualifications to correctly set up multicast. And this is before MEF’s new bandwidth sharing feature!
Routers rely on a strong standardized control plane, and should thus be much simpler to set up, right ?  Ever heard of Cisco CareerCertifications? There are five levels of certification (Entry, Associate, Professional, Expert, and Architect) along with targeted certifications for in seven different subject areas (Routing and Switching, Design, Network Security, Service Provider, Storage Networking, Voice, and Wireless). All that just to configure a router…
So we have communications devices that should be zero-touch, but in practice may require extensive configuration. This configuration may be manual and local (historically via a textual “CLI” interface but more recently via a GUI), or may be network-wide via a sophisticated network management system (NMS).
Of course, if configuration is so complex, you may be wondering why manufacturers can’t simply pre-configure their network elements so that the user can just turn them on and use them. Unfortunately, this is rarely, if ever, possible, due to the dynamic environments in which network elements are required to function.
If we want things to stay as they are, things will have to change.
Giuseppe Tomasi di Lampedusa (in The Leopard)
So we have seen zero-touch devices, and those that require basic configuration. The second step on the road towards full programmability is to enable a single device to combine the capabilities of multiple conventional devices, and then to configure it to function as any or all of these devices. For example, we could embed the functionalities of a L2 switch, a L3 router, and a L4 NAT in a single box, and then select whichever functionality needed in a particular instance. We could even opt to simultaneously activate many functionalities, provided that they are performed in the appropriate order.
This second step is precisely what an OpenFlow switch offers. A single device can match L2 header fields (SA, DA, EtherType, VLAN ID, VLAN priority), or L3 header fields (SA, DA, protocol number, DSCP, ECN), or L4 header fields (source and destination ports) and perhaps MPLS header fields (label, S-bit), and any combination thereof. However, in reality OpenFlow is more limited than just implied, in that the matching criterion is constrained to be exact match with bitmasks. A true combined L2-L4 device would be able to perform longest prefix match and port range match; but these limitations can be overcome at the expense of replicating flows.
A short digression (well, rant) is now in order. While such a combined device is advantageous in that it saves shelf space, power, and inventory carrying costs, it suffers from a major drawback. In today’s world of distinct devices, each device processes only that part of the packet for which it is intended, with the hardware limitation imposing opaqueness to the rest of the packet. Thus layering enforces intrinsic scoping which not only indicates clean design (similar to data abstraction in software) but also secures business interests. Once a single device can observe, act upon, and modify arbitrary fields, the ensuing layer violations can wreak havoc with service provision. Client layers could compel server layers to incorrectly forward packets or could hide traffic from billing systems. Lower layers could divert traffic to hostile destinations, or modify messages in transit. And such mayhem is not necessarily due to deliberate hacking, it will necessarily arise from simple errors in configuration. It is somewhat surprising that such flaunting of clean layering is proposed by academics in the name of data abstraction. Rant over.
The third step on the road to full programmability is a device consisting of lego blocks of useful functionalities. One could imagine a farm of general matchers (exact match, range match, regular expression match), a collection of rewrite modules, and a set of forwarding engines, all of which could be flexibly interconnected. Such a device can provide true DPI, as compared to the relatively shallow packet inspection of the previous step. Many network processors and some IDS systems are designed according to this philosophy.
At the far end of the spectrum sits the general purpose computer. Reminiscent of the zero-touch communications device with which we started, it too is supposed to function out-of-the-box. However, this functioning is limited (e.g., displaying a desktop). We purchase a computer entirely due to our expectation that it to be completely reprogrammed to perform any task, (well, at last if it has the required interfaces to the outside world – it can’t make coffee if it doesn’t have access to water and coffee grinds). In fact, once purchased we tend to forget about the computer (or smartphone) altogether. It becomes merely a platform for hosting applications, which are the products in which we are really interested.
The general purpose CPU is truly stronger than even the lego block model in that it can perform arbitrary calculations on arbitrary fields and make arbitrary forwarding decisions. For example, we could program a CPU to multiply the MAC source address by the IP destination address, xor the result with the last 10 bytes in the packet, take the hyperbolic sine of this, quantize to two bits, and use this result to forward to one of four output ports. Presumably this generality could also be used for something even more useful.
In the Apology, Plato tells how the Delphic Oracle declares that no-one is wiser than Socrates. Socrates, believing the oracle but knowing that he was ignorant of knowledge, goes out to discover what the oracle meant. He visits people he initially believes to possess wisdom - politicians, poets, and craftsman. After failing to uncover true wisdom in any of these, he comes to the conclusion that whatever wisdom he has derives from his knowledge that he knows nothing.
Truly a zero-touch philosophy!