Interesting Reading

This article was originally published October 24th, 1998!

Packetizing the network is very different from what some call the conversion of the network to ‘data’. Heck, the network has been all data now for twelve or thirteen years. The only part that isn’t one’s and zero’s is that last run of copper to the home. So packetizing is really what’s going on - the organization of the one’s and zero’s so that we can statistically multiplex and add clever intelligence to define and manage the types of traffic: traffic shaping based on class of service (CoS) and quality of service (QoS). So what does this have to do with the airline industry?

The simple answer is: a lot. See, the airline industry changed it’s entire approach to selling tickets around the time we saw deregulation and the hub system of airline travel come to fruition. Airlines began experimenting with overselling the number of seats on a plane in an attempt to insure the planes always left full. If you’ve noticed, they are getting pretty good at it too. This would mean that airlines would book some magical number of reservations knowing that a percentage of people did not show up for the flight. As prices came down, the significance of empty seats meant loss of profit. Packetizing the network brings us this same capability to oversubscribe bandwidth to users knowing that bursty data applications will not, in a manner of speaking, always show up for their reservation.

We can even take this similarity in purpose to another layer. In the airline industry, the Delta’s, American’s, and United’s all practice this overbooking of seats. If you reserve early and/or pay a higher fare, you even get a seat assignment. This is like a service guarantee not unlike constant bit rate (CBR) traffic service. These are class of service discriminators.

At Southwest Airlines, you don’t get a seat assignment. Service is on a first come, first served basis. Show up late, and you may have to wait for the next flight (which may only be 30 minutes later). The fares are considerably cheaper. This sounds like unspecified bit rate (UBR) service to me in the packet network world: cheaper and no guarantee of service. Sprint made this famous in Frame Relay as their ‘Zero CIR’ (no committed information rate commitment).

The similarity between airlines and the packet network is uncanny. The airlines have been very busy over the last years working out what the right overbooking levels are for certain flights. I witness this go just a little wrong when I travel out of Dallas/Fort Worth. "Ladies and Gentlemen", announces the check-in clerk, "we need a couple of volunteers to give up their seat for a $200 travel voucher." Sometimes this works sometimes it doesn’t. But their approach is fairly reliable and once the plane pushes back from the gate, no one cares anymore.

Like the airlines, the telephone service providers will need to develop the right math which helps them figure out what the appropriate oversubscription of the network works with the variety of types of traffic. They will also have to figure out what to do when things go a little wrong. Some service providers will opt for the Southwest Airlines approach. No guarantees, just lots of cheap flights.

Packet protocols have to give us the tools to accomplish this difficult set of issues. Truth is, that most of the WAN layer 2 protocols (Frame Relay and ATM) help considerably with a tool set to do this. P is promising solutions from new functionality which is finishing gestation in working groups. But the protocols can not do it alone. The airlines have complex management systems which attempt to solve the issues with as few small problems and vouchers as possible. Where is the telephone network management systems that will accomplish this? Perhaps a topic for a separate and more extensive discussion. Unquestionably, the telco and Internet service providers have a wonderful model in the airlines with which to begin the process of truly developing the answers they need to developing the right oversubscription rates in packetizing the network.



Comments powered by CComment

The nicest thing you can do is use these inks to support us!  Thank you!

Support our research!  Buy me a coffee :)

Support our research. Become a Patron!

Find by Tag

4G Networks 5G Networks 6in4 6LoWLAN 6LoWPAN 802.11 802.11ah 802.11ax 802.11ay 802.11az Addressing Analysis Ansible Architecture ARP AToM BGP Bloom's Taxonomy Broadband Cable cat CBRS CellStream Cellular Central Office Cheat Sheet Chrome Cisco Cloud Coloring Rules Computer Consulting CPI Customer Support Data Center Data Networking DHCPv6 DNS Docker Documentation Dublin-Traceroute dumpcap ECMP Ethernet Ethics Fragmentation G-MPLS Git GNS3 Google GQUIC Hands-On History Home Network ICMP ICMPv6 IEEE 802.11p IEEE 802.15.4 Interface Control Internet IoT IPsec IPv4 IPv6 IS-IS L2VPN L3VPN LDP Linux LLN LoL M-BGP MAC MAC OSx Macro Microsoft mininet Monitoring MPLS MTU Multicast My Room Name Resolution Netcat Netmiko NetMon netsh Networking Network Science nmap Npcap Online School OpenFlow OSPF OSPFv2 OSPFv3 OSX OTT Paris-Traceroute Parrot PIM pktmon PMTU Policy POTS POTS to Pipes PPP Profile Programming Project Management Protocol 41 PW3E Python QoS QUIC Remote Desktop Requirements RIP Routing RPL RSVP Rural SAS SDN Security Service Provider Small Business SONET Speed SS7 SSH SSL Subnetting SYSCTL T-Shark TCP TCP/IP Telco Telecom 101 Telecommunications Telephone termshark TLS Tools Traceroute Traffic Engineering Training Travel Tunnel Ubuntu Utility Video Virtualbox Virtualization VoIP VRF VXLAN Webex WEP Wi-Fi Wi-Fi 4 Wi-Fi 5 Wi-Fi 6 Wi-Fi 6/6E Windows Winpcap Wireless Wireless 5G Wireshark Wireshark Tip WLAN WPA2 Zenmap ZigBee Zoom

Support us by clicking:

Twitter Feed