Complex Systems & Autonomic Networks, Part 2: The map is not the territory

“The map is not the territory”

“The word is not the thing … The map is not the territory … The only usefulness of a map depends on similarity of structure between the empirical world and the map…”
- Alfred Korzybski, Science and Sanity

‘The father of general semantics, Alford Korzybski stated, “A map is not the territory it represents, but if correct, it has a similar structure to the territory, which accounts for its usefulness”. What this means is that our perception of reality is not reality itself but our own version of it, or our “map”’.
[- recapped from Korzybski by Rex Steven Sikes]

---

Deeper Look at Frame Relay Billing Example:

Remember our parallel test of database association and aggregator association (The New Telecom Ecosystem, Part 6). A problem with both approaches was their reliance on a virtual information model; external meta-data to determine which endpoint of a frame relay access circuit matched which other endpoint to form the virtual circuit.

Probability of the data: This data needed to be verified as part of another process of inputting or verifying data. If this processes generated bad information, our derived billing record for a day’s usage of a frame relay circuit was also incorrect. So a better design would have linked “a process to verify the endpoints were the endpoints of the same circuit”, by going to the network for the data, at the same time as the usage information was collected. Best, some transactional method would be used to link the verification of endpoints and the collection of usage information, as occurring in the same small fraction of time and as atomically linked actions. When doing this, the aggregator design became “near-real-time” in binding information. Precision of the data was insured to a great degree.

The probability of the model: But a great 18th century thinker Thomas Bayes once described a formula for reality. I paraphrase this as “The probability of the data being true is adjusted by the probability of the model.” A simple way of seeing the significance of this is that if the model is wrong, there is a very good chance the data associations made from the model are also wrong. It so happens that in the frame relay billing model above, the model is an abstraction of an external fabricated idea, and also application of the older “circuit” language, onto a newer network design and quite different network protocols - the model has no real, direct relationship to the network. This billing model was based on the older notion of a circuit (a continuous pipe for passing data information signals). Frame relay as a product was supplanting Private Line (T1 and T3 or E1) communications systems. In Private Line, the notion of a circuit is much closer to physical reality (but still not exactly correct). However this was not so in frame relay.

First of all, frame relay was a point-to-multiple-point addressing protocol (not a transmission protocol). As built, frame relay networks tended to ignore the “multi-point”, so frame relay became at once an access circuit implementation and a network defined by using switches/routers that were marketed as Frame Relay. Every provider’s frame relay product was architected as (A) point-to-point access circuits of customer to network cloud, (B) a way of passing packets across the cloud, and (C) another endpoint access circuit. This came to be called a “virtual circuit”. In the original MCI Frame Relay implementation, the cloud was actually one of the earliest and largest OSPF-routed commercial IP networks.

So in our billing data model, there never was an actual circuit between the two customer endpoints. So there is no way to validate, against the network, the endpoints of the data. In reality, the association of the endpoints was at the abstract product level - not in the network. Certainly packets entered at one customer endpoint and exited at another, but they never followed any contiguous circuit path. So if we measured a packet going in at the origin end, we had no way of associating that with any specific packet going out the destination end [except externally by an identity label in the packet.] Still, the virtual circuit idea made a kind of sense to customers; enough so we, as telecom service providers, could bill them and receive payment.

Today, this packet-in/packet-out problem manifests in a new and twisted way. How can you tell that the packet coming out one side of a network is the same packet as what went in the origin side of a network? Leaving aside quantum mechanics and information theory which we will ignore, this is one crux of the NETWORK DATA SECURITY issue.

This example explains how expectations that are applied to networks and OSS distort the ability of current telecom professionals to really see the network. If they are not actually seeing the network for what it is, how can they expect to make it do what they want? If you are putting energy, time, and resources into solving a problem which is not congruent with the actual network, of course the results will not be what are expected and everyone will be quite frustrated.

Performance reports and billing: This external circuit model was applied to Frame Relay performance reports and billing. The counts and classifications of packets were made internal to the switches; these were not consistently defined, or more exactly, were defined for traffic management reasons and not based on service provider product-driven definitions. Traffic counts for performance, pulled from traffic management parts of the MIB (Management Information Base) were done via different internal mechanisms than the packet counts for billing. I cannot begin to tell you how much time and resources were wasted explaining why these Frame Relay bills and Frame Relay performance reports never match up. This made customers very unhappy.

Inventory: This external circuit model was applied to inventory. The concept of a customer’s virtual network was completely the artifact of meta-data in product inventories. There were no distinguishing characteristics in a network that ever separated customer traffic, one from another.

Circuit utilization: This external circuit model was even applied by some to traffic management models and network design. This was particularly troubling when it came to calculating circuit utilization and applying this to determining how much space was left in a customers virtual network. TDM circuits had a straightforward way of considering utilization, how many of the intervals in which data could be placed on the wire, was data placed on the wire. The intervals were of constant rate amount so the more that were filled the better the economic performance of the circuit.

But virtual circuits (imaginary to start with) did not perform this way. They were deeply dependent on queue buffers. I will not go in to the why here, but it turns out that virtual circuits perform best when there is a backlog of packets waiting in the queue and when the total size of the packets shipped in a time interval is significantly below the computation of circuit bandwidth times time (see good-put and traffic management). Yet we reported Frame Relay virtual circuit utilization just like TDM utilization. Then the customers would get upset that they were not getting their money’s worth when virtual circuits were running at only 60-70%, when in fact, this was the optimum utilization rate to get the most packets from one side of the network to the other.

Dropped packets: Packets are dropped in queue services; the protocol is designed for this. As part of traffic management, packets are assigned a priority, based on QoS/CIR and then dropped preferentially by that priority. But “dropping things” has a bad normative language value, so we biased the customer perceptions against the service, just by how a normal technical operation was casually named. As a result, among customers and even telcom executives, there was a surprisingly large degree of suspicion that the networks were badly designed; because “any packets dropped” was bad engineering or operations. When marketing executives sought someone to punish for the dropped packets, battles erupted between Operations and Engineering because each truthfully claimed “I’ve done nothing wrong,” and erroneously concluded “it must be him”.

Indeed, some customers came to believe that telecom service providers were dishonest and bought external probe products to check the networks themselves - but these probes used the same fallacious model and inappropriate language, validating what was actually a falsehood. The cumulative loss of trust in service providers and networks was a deeply troubling trend with extraordinarily large, later negative externalities.

Eventually, Frame Relay performance reports, filled with packet counts and utilization % for virtual circuits, got to be so large they could not even be emailed to customers. When customers got them they needed days to review them. So they bought external software from third party vendors, just to rank and order the reports to tell them which circuits were in trouble. Even through data was passing fine from one place to another. I am personally angry at how much money was spent unproductively on performance reports; and at how dishonest the performance reporting vendors were in selling to customer fears based on problem utilization rates and dropped packets. And throughout all this, the network worked very well, as long as you did not poll for billing or performance information too often.

Remember Olympic traffic classes (Bronze, Silver, and Gold)? These three distinct traffic classes were not generated by setting parameters in the Frame Relay switches. In fact, in some cases, these were just separate network installations with better or worse network performance. In one case, a company merger dictated that a network with lower QoS was labeled as a higher Olympic grade service. Another case, the lower Olympic class network, with cheaper prices to customers, cost more to operate than the higher class network by the same provider. It cost more to send a packet for cheaper returns than to send a packet on the higher class network. It was difficult for telecom companies to discover this about themselves, because the visualization of the product model had business precedence above the network dynamics; the product definition obscured the actual economics and performance of the networks. Because the product model said Gold is better than Bronze, it must be so…

PS: The proper billing model for Frame Relay (IMHO) would have been to charge based on access circuit capacity (specifically TDM capacity when a TDM access circuit into the cloud). Nothing more. Everything else should have been a tunable parameter used to get the best good-put (packet count delivered to the other side) possible. Specifically, no billing or product mention of CIR; always set CIR at the optimal point of the good-put packet transfer calculation. The customer should never have been confused by providing too much information about engineering matters.

Wedge Greene is a consultant for LTC International.