August 19, 2014

The 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.

IP_Header.jpg

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.



Leave a comment

Search Webtorials

Get E-News and Notices via Email


  

 



  

I accept Webtorials' Terms and Conditions.

Trending Discussions

Featured Sponsor Microsites






















Archives

Notices

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.