November 26, 2014

Nitty-Gritty of Net Neutrality: IP Headers

Thumbnail image for SAT-for-TechNotes.jpg
As both enterprises and consumers struggle with the concept of "Net Neutrality," one of the most basic and least discussed aspects is the question of exactly what is "neutral."  Or, more specifically, if neutrality is not maintained, then in what way(s) will one flow of traffic be distinguished from another?

We'll start with the most obvious component, the IPv4 and IPv6 headers.  As shown in the diagram, the most obvious and critical parts of the header are the destination and source address.  So the simplest and most obvious place to start is to discriminate based on who the sender and the recipient of traffic might be.  And, indeed, this has been assumed to be the logical starting place.


For instance, a service provider could make a deal with a company (e.g. Netflix) to give preferential treatment to its traffic, so long as the destination is on the same network.  This could allow special deals to be cut so the performance of streaming movies would be guaranteed, and, of course, a premium could be charged.  While this probably raises the hackles of consumers, this same type of preferential treatment for certain traffic types could possibly be quite attractive to enterprises as a premium service.

MAJOR CAVEAT: For all of the descriptions here, the non-neutral traffic is treated differentially only within a given network unless there are agreements with multiple providers.  (We'll discuss the complexity of net neutrality in a "network of networks" in a future TechNote.)

But what other parameters are at least available, whether used or not, simply in the header?

One obvious place is that there are six bits available in the Differentiated Services Code Point (DSCP) - commonly called DiffServ - field. This could be used for end-to-end designation of a particular traffic type, indicating that is might need special handling.  As an example, voice packets might need priority processing to lower latency.  However, these packets are also more likely to be "discard eligible" because voice algorithms are designed to deal with a relatively high amount of packet loss.  It's worth noting that even though the concept is well-documented, to my knowledge there are no standardized uses or widespread implementations of these codes.

While staying with the example of voice, there's yet another header element that could be used for traffic differentiation.  IPv6 adds the option of a "flow label" that would indicate that individual packets as a part of a flow would always take the same path through the network.  This could be of considerable help to ensure that packets arrive in the order that they were sent - something that is not guaranteed at the IP layer.  That said, this is really of minimal help since a) packets in a given flow tend to follow the same route for a long time unless a major event causes routing along a different path and b) upper layer protocols (such as TCP) tend to check for packet order anyhow.

A third method for differentiating traffic (and thus removing neutrality) simply - even in the IPv4 header - is the eight-bit "protocol" field.  Various protocols, such as TCP and UDP, already have standard assignments. Again, this is an opportunity to prioritize one traffic type over another, though at this point we don't know of any instances on the Internet where this is used.

Of course, the mechanism for handling the use of these additional header fields is pretty much unspecified as well.  Even though the source and destination addresses don't change (hence the large address space as compared to other technologies), the settings for these bits, especially DiffServ, could be made by any switch the traffic traverses.  It's much less likely that the protocol field would be changed.  

The bottom line is that for an Internet service that is provided over a single network, it's possible to have a large number of factors come into play that would remove neutrality from the net.  Saying that Net Neutrality will be removed from the Internet is one thing.  Defining exactly how this will be accomplished is another.


I hope that part of the Net Neutrality rules would ensure that certain parts of the headers not be changed by a transit service provider. Especially with reference to fields such as DiffServ and Flow labels, with some exceptions. I have seen many cases where an SP will remark the DSCP field in all network traffic from or to their main internet gateways to '0 or best effort'.

If the recommendations for DiffServ in RFC4594 were followed it would not be difficult to handle traffic according to the requirements of the application. SP routers have had mechanisms to handle real time traffic through priority/low latency queuing for years, and most newer routers have multiple levels of priority queues such that both voice (with packets typically less than 200 bytes) and real-time video with much larger packets can both be handled effectively, along with multiple other differentiated queues (e.g. connections to a business database versus browsing).

Net Neutrality is not a simple concept. Wholesale IP providers and ISPs can block certain traffic, and at times there are reasons to do this. From my experience working on international wholesale IP networks, most drops occur on peering interfaces due to the amount of traffic. Peering connections tend to be high cost, and small to medium ISPs have incentives to keep the pipes on these as full as possible, but due to the bursty nature of IP traffic they may tend to drop traffic during peak hours. I've seen conditions where drops at peak hour are consistently around 10 percent.

The place this occurs is on the upstream provider, so the ISP likely does not even know how much of this traffic is dropped and (partially at least) retransmitted from the source. The ISP is not "intentionally" dropping the traffic in this case, and a properly designed application should be able to recover.
Is this related to Net Neutrality? No, at least not directly, but it is one example of how the issue is not simple, and how it would be difficult, in some cases to verify that an ISP is intentionally dropping traffic.

BTW - the protocol field can be used to determine the type of protocol used, which may be associated to a type of traffic from a certain application. (Although an application may use multiple protocols). Generally, the field identifies the type of protocol, which is used to interpret any additional fields in headers defined by the protocol.

You could look at ViBE as a protocol that eventually obviates all of the headers and trailers and controls the scheduler which may be a more likely future consideration.

Leave a comment

Search Webtorials

Get E-News and Notices via Email




I accept Webtorials' Terms and Conditions.

Trending Discussions

See more discussions...

Featured Sponsor Microsites



Please note: By downloading this information, you acknowledge that the sponsor(s) of this information may contact you, providing that they give you the option of opting out of further communications from them concerning this information.  Also, by your downloading this information, you agree that the information is for your personal use only and that this information may not be retransmitted to others or reposted on another web site.  Continuing past this point indicates your acceptance of our terms of use as specified at Terms of Use.

Webtorial® is a registered servicemark of Distributed Networking Associates. The Webtorial logo is a servicemark of Distributed Networking Associates. Copyright 1999-2018, Distributed Networking Associates, Inc.