Home / Blogs

Traffic Management: An Undefined Term

Patrik Fältström

In Europe yet another package is discussed, and it includes issues related to what I guess one could call Network Neutrality. And, as usual, at the end of the game, texts are negotiated that does not have much meaning in reality. Negotiations on what words imply, while I as an engineer have absolutely no idea what either of the parties actually mean. What they want. Or rather, it is sort of possible to understand the overall goals for some of the parties, but the problem is still that the words they discuss are not really related to the goals.

Let's take "traffic management" for example. What I think people are discussing are the following things, and more:

1. Should by law access to certain services and content be prohibited? This implies blocking traffic although a connection is not full, and if the answer to this is yes the followup questions are of course: who decides what should be blocked, who is blocking and who is auditing. And if someone is responsible to block something, is it the same party that have to detect (and therefore inspect all traffic), or is it enough to be able to react? And of course whether an ISP have ability to block at all, and when.

My personal view here is that traffic to some destination must be possible to block, after a decision by law enforcement agencies. Auditing process must be trustworthy so that it can be verified that the decision on blocking had the planned value (specifically compared to the impact it has on the ability for anyone to choose who they want to communicate with). I am against any ideas where someone is responsible for services they do not provide, like having an ISP be responsible for content that is passed around, and it is wrong to impose anything that requires inspection of traffic. To require the ability to react is OK. Further, providers of networks must be able to block traffic in cases where traffic is disturbing the operations of the network itself.

2. Should a provider of access be able to differentiate traffic so that if a connection is full, what traffic comes through is not selected randomly? And if they can, on what basis? What type of traffic it is, or depending on who is communicating? And if this is possible, how transparent does it have to be for the consumers?

My view here is that I personally would not be interested in buying access from an ISP that did not have policies in place for differentiation between different types of traffic, for example by the use of diffserv at well known bottlenecks. I am also interested in having access providers being able to innovate and come up with new products where for example they charge more if one uses tons of bandwidth (lots of providers tell me about 4% of the users uses 85% of the available bandwidth) etc. But I am against having my access provider (for example) selecting what providers of services I in reality can buy services from (by locking out providers competing with providers of their choice).

This description of course did not make things easier to understand I guess, but to some degree that is my point. This is complicated, and without clear discussions on major design principles like these. If one looks at some discussions, it is as clear as mud what they talk about. One can read between the lines what they want, but they must spill the beans, and negotiations should take place regarding the overall principles, not the final detailed text.

Here is for example two suggestions of text that have been floating around… and you can see in the difference how hard it might be to decide what implications either of the texts has:

Art. 2 ea) USD "Traffic management policies" means the procedures put in place by the provider of a public electronic communications service or network in order to measure and control traffic on a network link so as to avoid filling the link to capacity or overfilling the link, which might result in network congestion and poor performance.

Art. 2 ea) USD "Traffic management policies" means the procedures put in place by the provider of a public electronic communications service or network in order to measure and control traffic through its network facilities so as to prevent or mitigate the effects of network congestion, to ensure efficient and reliable performance and to optimize customer quality of service.

Easy?

By Patrik Fältström. Visit the blog maintained by Patrik Fältström here.

Related topics: Access Providers, Broadband, Net Neutrality, Policy & Regulation, Telecom

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

Yes, that part is easy compared to Joe xx  –  Mar 30, 2009 8:39 PM PST

Yes, that part is easy compared to ...

What do you do when companies do the inevitable?  That is use these well meant schemes as tools to do such things as stamp out the competetion, work for the RIAA, or sell data behind user's back for marketing purposes.

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

MarkMonitor to Exhibit at Internet Tech Policy Exhibition and Reception to be Held on Capitol Hill

Verisign to Award New Infrastructure Research Grants

Afilias Says "No" to SOPA

Breaking the DNS: Another Look at How SOPA Could Be Destructive

An Interview with DotConnectAfrica's Executive Director, Sophia Bekele

Neustar Names Joe Pasqua to Head Neustar Labs

ICANN's COI plus the EBERO: A Recipe to Create Failed Domain Name Registries

Interactive Investor Interviews Antony Van Couvering and Peter Dengate Thrush

SPECIAL: Updates from the ICANN Meetings in Singapore

President Obama Names Neustar President and CEO Lisa Hook to NSTAC

Digital Hollywood Taps Domain Name Expert Ben Crawford for Insight on New Internet Policy

Verisign CEO to Serve on President Obama's National Security Telecommunications Advisory Committee

Brussels and the Month Afterwards: Celebrations, New gTLD and Security and Stability Issues Ahead

SPECIAL: Updates from the ICANN Meetings in Brussels

A Summary and Analysis of ICANN's Public Comment Period on Dot-XXX

Our Response to ICANN Re: The Dot-XXX Top-Level Domain

ICANN and Accountability: Time to Walk the Walk

72 Confirmed Talks - If You're Attending, Now is the Time to Register

SPECIAL: Updates from the ICANN Meetings in Nairobi

ICANN and Cybersecurity: Hot Topics at The First Ever .ORG Forum

Hot Topics

Afilias

DNSSEC

Sponsored by
Afilias
Neustar UltraDNS

DNS

Sponsored by
Neustar UltraDNS
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines
dotMobi

Mobile

Sponsored by
dotMobi
Verisign

Security

Sponsored by
Verisign