How traffic shaping works, part 1

With all of the brou-ha-ha of the past couple of years surrounding Net Neutrality, and especially with a federal court ruling that the FCC had no grounds to enforce it, I thought that I would get into a bit about how traffic shaping works, which is at the heart of Net Neutrality.

Imagine that you have an email to send.  The email is a chunk of text and let’s say that we picture like the following diagram:

When anything goes out over the Internet these days, it does so using a technique called packet switching.  Packet switching is the process of sending a message over a connection that is not physically connected to each other (which contrasts it from circuit switching).  The message is transmitted over any number of hops and these hops are connected to each other, but not necessarily physically connected.  Thus, to get from Point A to Point B, if you send the same message multiple times, it could take different paths to get there:

The above diagram is my fictional diagram indicating a possible packet switching implementation where each circle is a node, or hop, along the way.  While it is certainly possible that Point A to Point B can follow the same path (indeed, there are protocols that do this), a regular packet switching implementation doesn’t require or guarantee this.

Furthermore, the entire message is divided up into little sub-messages called packets.  These packets are each sent from Point A, travel across the Internet and are reassembled at Point B.  The packets all have information for Point B on how to reassemble the message.  A sample packet might look like the following:

Each node along the path inspects the header, sees the sender IP address, the receiver IP address, and pushes it along to the next node.  Point B knows how to reassemble the entire message because of the packet number.  If an error occurs along the way, it can issue a message back to the sender at Point A to resend either the entire message or single packets.

The trailer is a sort of data integrity part of the packet and more of the more popular ones is the Cyclic Redundancy Check (CRC).  It detects errors by using mathematics to add up the various ones and zeroes, does some other math operations and compares to see whether the data inside the rest of the packet adds up to the checksum.  This is important because missing bits of data can change the interpretation of the message.  Suppose the above message was divided up into the following three packets:

However, due to noise on the line (it was routed through Manitoba during the summer and the routing lines have 38 million mosquitoes on them, people have swatted them away and during a weird coincidence for this particular message, it interfered with the transmission), certain parts of the message get changed:

For those of us who are more accustomed to hearing that first message, the second one gives us a false sense of hope.  A CRC check can prevent this because the digits would not add up to the proper checksum and the sender would be asked to send the packet again.

Anyhow, the point of all of this is that packets contain information that the transmission services look at in order to make routing decisions.  It contains some data, and then the end trailer contains pieces of information to ensure that the message accuracy is retained at the other end.