At 3/29/2011 11:15 PM, RickG wrote:
Fred, I respectfully disagree.
I'm glad to see that we have a good discussion going here, and it's
not a flamefest or anything.
First off, applications being run on my network ARE my business.
Many apps can have detrimental effect on it and therefore I have a
right and responsibility to say what can run on it.
Let's set that aside for a moment...
Secondly, priority bits simply cost more to provide and tax the
network more than non-priority. Everyone expects their high priority
apps (video/voice) to be first in line without delays and that's
really what all the fuss is about.
I entirely agree. My original note, if you look carefully, said that
priority and other higher-than-BE QoS *should* cost extra. Lack of a
good charging model is one reason why we have a big BE Internet and
not much else. But I'd like to see one.
BTW, entertainment video is much more tolerant than voice. It can
use retransmission and buffering, or find other strategies to
cope. Real-time video (telepresence) is the bear.
Meanwhile, we have been focusing on raw usage but that is only a
part of the equation. Just billing for monthly overages does not
consider daily peak usage times.
I don't object to time-of-day pricing either. One rough example:
"Usage midnight to six, not counted. Usage 6AM to 9AM, counted half."
In fact, in questioning many customers, they would be happy to pay a
premium for a high-priority, low latency connection for certain
apps. Heck, I can even see premiums for usage based on the time of
day but that may be pushing it. This may sound extreme but everyone
laughed at me back in 1997 when I bought an Allot box for UBB.
BTW:While economic optimization is good, network optimization is
better. Over the years, I've seen fast networks and slow networks,
I'd pay more any day to be on a fast network.
Sure. But if your network is capacity-constrained, or the cost of
capacity is particularly high somewhere, then you have to make do
with what you have. Which is why you care what apps are run.
I am one of those old-timers who thinks that the Computer II decision
was one of the smartest moves the FCC ever made. It literally made
the ISP industry possible, and its revocation in 2005 directly
created the "network neutrality" kerfuffle. CI II banned LECs from
dealing in the upper layers; any "enhanced" services had to be on a
fully separated basis. So it was literally against the law for the
telco to ask what the application (in the "layer 7" sense) was. But
it could certainly offer services with optional QoS features that
were optimized for different applications. So it might offer a CBR
service (voice-optimized) and a BE (UBR) service
(Internet-optimized). But if somebody ran voice over a BE service,
that was their own issue, not the telco's.
On the other hand, the ISP is explicitly not a common carrier, and
thus has the right to be more specific. ISPs are above that
boundary, not below. So sure, as an ISP, you should have the right
to sell "applications". There is no bright line between ISP and ASP,
or between ISP and time-sharing service. (That ancient business has
been revived under the moniker "cloud".) So sure, you can do DPI if
you want, provided that you do it in a way that respects customer
privacy. Note that I do not think that DPI should go all the way in
to the payload, as some systems do, or ferret out "value" from
transactions, etc., as some vendors propose. I call that "wiretapping".
However, I'll quote R. Milhouse Nixon here and suggest that in most
cases, you can do it, "but it would be wrong". The reason is that
the value proposition that customers want from the Internet is one of
flexibility and openness. They probably don't want their "ISP" to be
a mail-and-web service, although that's what Blackberries usually get
(in exchange for unmetered usage of those applications). While I am
not one who believes that "all innovation happens at the edge", I
don't want edge innovations to be blocked in the middle.
So the best compromise I can see is to price one's menu of services
in a manner that reflects cost, with some averaging to make it more
palatable. And then you can ignore what people do with the bits they
buy. They will have incentives to behave economically.
I'm also an advocate of widespread encryption, and am doing my part
to make encryption of user traffic the rule, rather than the
exception, over the next few years. (See the Pouzin Society stuff
for more details.) That will utterly break DPI. But it will work
with explicit QoS options, so there is no excuse that the network
will have to snoop the application in order to know what QoS to
deliver (the IMS approach).
On Tue, Mar 29, 2011 at 2:28 PM, Fred Goldstein
<<mailto:fgoldst...@ionary.com>fgoldst...@ionary.com> wrote:
At 3/29/2011 01:20 PM, RickG wrote:
I still say there needs to be more than just caps. There needs to
be a matrix of billing by priority such as video at .03/meg, file
transfer at .02, email at .01, etc. Heck, perhaps HD can be .05 and
SD at .03? (Prices are just for arguments sake)
Well, no, there doesn't. Applications are none of the network's
business. That's one reason why DPI is evil.
HOWEVER, I am not opposed to appliation-agnostic billing for usage,
by QoS. It is perfectly reasonable for a network to charge for
usage that imposes a cost. And while the teevee fiends are sure,
just certain, that 300 GB/month imposes precisely zero cost on the
network, I doubt many WISPs would agree. Especially rural ones who
have to pay for backhaul, or who have multi-hop networks.
IP, of course, is one-size-fits-all, with QoS being rare. Hence
caps and overage charges are a way to do cost averaging for the
majority (since people hate billing for usage), while still hitting
the heaviest users. Block pricing (like wireless, having say 10,
50, and 150 GB/month plans, plus overage) also works. And if you go
beyond plain old IP and do have a QoS-enabled protocol, then
lower-loss or delay-limited (or whatever) traffic should carry a
premium. Regardless of what it's used for. Then the applications
could adapt to the pricing. This leads towards economic optimization.
On Tue, Mar 29, 2011 at 11:50 AM, Bret Clark
<<mailto:bcl...@spectraaccess.com>bcl...@spectraaccess.com > wrote:
I know this is Canada, but I can just see some congressman here in the
US one day bitch about not being able to cleaning watch the "Jackass 3"
movie from Netflix and demanding that all service providers get rid of
bandwidth quotas and throttling by introducing a new bill.
On 03/29/2011 11:26 AM, Matt wrote:
>
<http://arstechnica.com/tech-policy/news/2011/03/data-caps-claim-a-victim-netflix-streaming-video.ars>http://arstechnica.com/tech-policy/news/2011/03/data-caps-claim-a-victim-netflix-streaming-video.ars
>
>
--
Fred Goldstein k1io fgoldstein "at" <http://ionary.com>ionary.com
ionary
Consulting <http://www.ionary.com/>http://www.ionary.com/
<tel:%2B1%20617%20795%202701>+1 617 795 2701
--------------------------------------------------------------------------------
WISPA Wants You! Join today!
<http://signup.wispa.org/>http://signup.wispa.org/
--------------------------------------------------------------------------------
WISPA Wireless List: <mailto:wireless@wispa.org>wireless@wispa.org
Subscribe/Unsubscribe:
<http://lists.wispa.org/mailman/listinfo/wireless>http://lists.wispa.org/mailman/listinfo/wireless
Archives:
<http://lists.wispa.org/pipermail/wireless/>http://lists.wispa.org/pipermail/wireless/
--
-RickG
--------------------------------------------------------------------------------
WISPA Wants You! Join today!
http://signup.wispa.org/
--------------------------------------------------------------------------------
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
--
Fred Goldstein k1io fgoldstein "at" ionary.com
ionary Consulting http://www.ionary.com/
+1 617 795 2701
--------------------------------------------------------------------------------
WISPA Wants You! Join today!
http://signup.wispa.org/
--------------------------------------------------------------------------------
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
