[governance] Net neutrality: Definitions

SAMUELS,Carlton A carlton.samuels at uwimona.edu.jm
Tue Aug 17 10:53:00 EDT 2010


Great job on this, Karl!  I tried to add to the pool in a previous post but I feared some of it would have been too deeply 'techie'. So I resorted to cover this with a label: "telecommunications companies have always had preferred customers and show preference in business-like practical ways".

Carlton

-----Original Message-----
From: Karl Auerbach [mailto:karl at cavebear.com]
Sent: Monday, August 16, 2010 4:30 PM
To: governance at lists.cpsr.org
Subject: Re: [governance] Net neutrality: Definitions


Just so that we have something solid to chew on when talking about net
neutrality, here are some of the concrete ways in which I see that
providers can "engineer" (or "bias") the traffic that flows.

This list is only a tiny portion of the ways that providers can "tune"
their networks.  I'm not trying here to be exhaustive, merely illustrative.

My goal here is to suggest that when we talk about net neutrality that
we ought to be able to draw clear lines from general principles to
concrete things done by providers, and, importantly, vice versa.

  - In VoIP the choice of codec can have a big impact.  And some human
languages suffer greater codec degradation than do others.  Just as one
of my favorite singers' voice was used to tune the MP3 parameters the
languages of the US and western Europe tend to have been used when
creating the codecs most typically used for VoIP.  With those codecs
vowel-rich languages tend to work better and those languages with sharp
consents tend to suffer because the rise-time/attack of those sounds are
frequently chopped or softened.  Asian languages tend to suffer.  And
I've often wondered whether African click languages become
incomprehensible, particularly when the provider not only uses a vowel
oriented coded but also uses the technique of removing packets that
contain mostly silence.

  - Protocol based routing - this is very often done to segregate VoIP
traffic onto paths that are not carrying big (i.e. long serialization
time) packets of HTTP and its ilk.  And some traffic, particularly
backup jobs and the like, are not harmed by being routed via
inexpensive, but slow, geosynchronous satellite paths.

  - Protocol based queue priority - routers are usually filled with
queues of packets that are waiting to be sent on an outgoing interface.
  These queues can get long.  And they can overflow.  And there are
often several queues waiting for a single physical interface.  The order
in which packets are inserted into queues (FIFO or preference based),
the queue that is selected for insertion, the queues that get preference
when the interface becomes empty (fair queueing, round-robin, etc), the
drop policy (tail drop, random drop, RED, protocol-sensitive drop [e.g.
don't drop TCP ACK or FIN packets]) are all among the knobs and dials
available to a provider.

  - Aggregate limits - providers may allow up to a given amount of
traffic within a certain time period and then penalize any overrun.

                --karl--



____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance

Translate this email: http://translate.google.com/translate_t
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance

Translate this email: http://translate.google.com/translate_t


More information about the Governance mailing list