Apples an oranges here.  We as providers are paying for dedicated bandwidth,
not shared.  Shared connections are a different beast altogether, and I
really would assume that's what we're talking about when we go rate-limiting
ANYTHING.  Dedicated connections should be able to do whatever they want.

Because they are paying for it, and you are not losing money on that
customer.

Mark Nash
UnwiredOnline.Net
350 Holly Street
Junction City, OR 97448
http://www.uwol.net
541-998-5555
541-998-5599 fax

----- Original Message ----- 
From: "Mike Hammett" <[EMAIL PROTECTED]>
To: "WISPA General List" <wireless@wispa.org>
Sent: Monday, November 19, 2007 10:48 AM
Subject: Re: [WISPA] Vuze / Comcast / Peer to Peer / FCC


> I've been a firm believer in that the last mile can shoot themselves in
the
> foot if they like, but the next company up in the chain must be neutral.
> Level 3, AT&T, Cogent, Verizon, NTT, etc. should not be doing anything on
> their end for their wholesale markets....  again, if they have retail end
> users, do whatever they want.
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
> ----- Original Message ----- 
> From: "Matt Larsen - Lists" <[EMAIL PROTECTED]>
> To: "WISPA General List" <wireless@wispa.org>
> Sent: Monday, November 19, 2007 12:03 PM
> Subject: Re: [WISPA] Vuze / Comcast / Peer to Peer / FCC
>
>
> > This is not a black or white position - take the time to read the Vuze
> > petition and focus specifically on the last two pages where they outline
> > the goals of what they want to achieve.   Then take some time and look
at
> > what Comcast did to Bit Torrent - they specifically broke the
application.
> > What Vuze is asking for is pretty reasonable - the ability to run their
> > applications without undue interference.
> > If you back Comcast, you are backing the ability for YOUR backbone
> > provider to break the applications you run on their network.   The Vuze
> > petition is the position that should be backed, IMHO.
> >
> > Matt Larsen
> > vistabeam.com
> >
> >
> > George Rogato wrote:
> >> I'm not buying it.
> >> Yes, we as service providers have a right to determine th service level
> >> agreements we want to set for the price we decide.
> >>
> >> A consumer has always believed that they have an unlimited do anything
> >> they want with our connection mentality.
> >>
> >> We on the other hand have always had terms of service that nullify the
> >> anything you want unlimited mentality.
> >>
> >> If we are in disagreement with Comcast's position, then what are we
> >> really saying?
> >>
> >> We would be saying, "anything goes", we have no control, we can't rate
> >> limit.
> >>
> >> The free market system, does not tie the hands of the isp, but rather
> >> allows us each to set our own service levels and terms of service, and
> >> compete based on our own service offerings.
> >>
> >> To restrict an isp from making a decision, is in no way the free market
> >> system, but rather the regulated system.
> >>
> >> I'm with Comcast on this. I do not want to be regulated. Let me live or
> >> die on the way I decide to run my network.
> >>
> >> Thanks Eje for bringing this to our attention.
> >>
> >> My recommendation is to back Comcast.
> >> George
> >>
> >> Clint Ricker wrote:
> >>> Sam and Matt, very well said.
> >>>
> >>> To the rest: If you are petitioning the FCC in union with the cable
> >>> companies and telcos, you are screwing your future and help your
> >>> competition.  You can't win by the rules that they make.  The network
> >>> neutrality battle could potentially change the service provider
> >>> economics
> >>> enough in very positive directions for you.  This is a
> >>> politically-charged
> >>> enough topic that something interesting may actually happen on this :)
> >>>
> >>> First of all, get more customers!  With enough customers, the
> >>> oversubscription on bandwidth becomes much better--you can fit
thousands
> >>> and
> >>> thousands of resi customers in a 100Mb/s pipe without dropping, but
> >>> about
> >>> 10-20 in a 5Mb/s pipe.   With enough customers, the bandwidth cost per
> >>> customer comes down to almost nothing.  If you need to limit a couple
of
> >>> outlying customers (the ones using 3Mb/s all the time), sure, go
ahead.
> >>> But
> >>> don't hate bit torrent or any other protocol :)  Bit Torrent bandwidth
> >>> costs
> >>> _exactly_ the same price as http bandwidth.
> >>>
> >>> I really don't agree with a business philosophy that fundamentally
sees
> >>> it
> >>> as a bad thing if people are actually using your service :).  Embrace
it
> >>> and
> >>> figure out how to make it profitable (hint--spend more time getting
new
> >>> customers and less time trying to shave costs).   The bandwidth math
is
> >>> MUCH
> >>> better with 1,000 customers than a hundred and MUCH better with 10,000
> >>> than
> >>> a 1,000.
> >>>
> >>> To everyone thinking that there needs to be "network neutrality"
> >>> requirements for big guys, but little guys should be allowed to block:
> >>> do
> >>> you really want to send the message to your (potential) customers:
> >>> hey--my
> >>> competition will let you run the service you want, I won't.
> >>>
> >>> This is an opportunity to actually get ahead of the game and have a
leg
> >>> up
> >>> on your competition.  Here are the facts as I see them (applies to the
> >>> residential market only):
> >>>
> >>> 1. The cost of bandwidth for telcos and MSOs is really extremely low
on
> >>> a
> >>> per customer basis.  The bulk of their cost--and why this is a big
issue
> >>> for
> >>> them--is the cost of getting that bandwidth to the customer.  For
these
> >>> guys, the major cost is in the transport networks: fiber buildout is
> >>> extremely expensive, transport gear is incredibly expensive, etc.
WISPs
> >>> have ridiculously cheap transport networks and, with enough scale,
don't
> >>> really pay much more for bandwidth.  If you get scale, your bandwidth
> >>> costs
> >>> also drop.  In other words, once you hit a certain scale, your cost of
> >>> delivering service becomes much less than your competition.
> >>> 2. You can't compete on price with a telco/mso doing triple play.  The
> >>> economics aren't there.  You don't offer video.  Your customers want
> >>> video.
> >>> They want to be able to watch House and CSI and Dancing with the
Stars.
> >>> This means that even if they keep you for Internet access, they will
> >>> sign up
> >>> for television service.  They will then, every month, get offers for
> >>> bundled
> >>> video + data services (and sometimes voice) for prices that you can't
> >>> compete with.
> >>> 3. Your competitors can't compete in price without subsidizing their
> >>> network
> >>> buildout with revenue from overpriced, monopolistic telephony and
video
> >>> solutions.  If/When the Internet becomes _the_ medium for delivering
> >>> this,
> >>> you can adapt to that by...the end of this week.  Your competition
will
> >>> take
> >>> years and years to get to this point and fight it every step of the
way.
> >>>> From a revenue / cost standpoint, they simply cannot survive in such
an
> >>> environment.
> >>>
> >>> However, if people use Joost and Vuze and whatall, then they can use
> >>> YOUR
> >>> connection and no longer have a need to get their video services
> >>> elsewhere.
> >>> Embrace this.  Advertise this.  Help your customers find video
services
> >>> online.  Make a portal for this.  Start mailing your customers (and
your
> >>> competitor's customers!) and saying "Bob's Internet: includes over
> >>> 10,000
> >>> video channels for free" and "Bob's three step guide to saving $800
per
> >>> year: (step 1: get Bob's Internet, step 2: Tell your cable company
> >>> "bye-bye"
> >>> step 3: Enjoy 10,000 video channels on Bob's Internet Access).
> >>>
> >>> Get your customers thinking: "I can watch CSI and so forth on the
> >>> Internet".  You take a data customer away from a cable company...big
> >>> deal.
> >>> You get a community converted to watching their video on the Internet
> >>> and
> >>> the math changes DRASTICALLY in your favor.  You are trying to compete
> >>> using
> >>> a business model that revolves around a $30-$40 average monthly
revenue
> >>> per
> >>> customer against providers who have $100-$250 average monthly revenue
> >>> per
> >>> customer.  Attack that!  They simply can't afford to be profitable on
a
> >>> single pipe / single service model--you can.
> >>>
> >>> Remember, the late 90s were a golden era for independent ISPs because
> >>> they
> >>> got ahead of the curve.  Most of you are, quite bluntly, behind the
> >>> curve
> >>> now.  This is an opportunity to get ahead of the curve
> >>>
> >>> Comment on this to the FCC--just comment in favor of Network
Neutrality.
> >>> Believe it or not, you will do MUCH better under this model than your
> >>> competition because it very much favors your business model and is
> >>> incredibly harmful to your competitor's business model.  If you
question
> >>> my
> >>> math, feel free to contact me offl-list--there are some specifics that
> >>> I'm
> >>> not willing to discuss in a public forum.
> >>>
> >>> Thanks,
> >>> Clint Ricker
> >>> -Kentnis Technologies
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Nov 18, 2007 10:44 PM, Matt Larsen - Lists <[EMAIL PROTECTED]>
> >>> wrote:
> >>>
> >>>> My strong feeling is that the free market approach is by far the best
> >>>> approach to the Network Neutrality/Network Management.  If Comcast
> >>>> wants
> >>>> to degrade the service to their customers, then that is an
opportunity
> >>>> for the other providers in the market - they are essentially
degrading
> >>>> their own service, especially if they are doing it in a way that
> >>>> "breaks" specific applications.   In markets where there is a
monopoly
> >>>> or duopoly  and both providers engage in purposefully breaking
specific
> >>>> applications, leaving the customer with no choices, the market
> >>>> condition
> >>>> is a result of poor regulatory policy - not poor network management.
> >>>> Competition will take care of that problem.  The few remaining
> >>>> independent ISPs have this as one of the few potential advantages
that
> >>>> they can bring to the table - a truly different type of service, with
> >>>> the concerns of the provider and the customer in balance and
> >>>> appropriate
> >>>> for both parties.  The issue that Vuze seems to be taking is that
> >>>> breaking of applications is unacceptable, but good network management
> >>>> is
> >>>> fine, as long as it doesn't discriminate against specific
applications
> >>>> or protocols.
> >>>>
> >>>> I do take issue with the characterization of Vuze/BitTorrent as being
a
> >>>> "parasite" on our networks.   They are not forcing the customer to
use
> >>>> them for content - our customers paid for connectivity to the
Internet,
> >>>> and should be able to use that connectivity for whatever they want
to,
> >>>> in a way that does not degrade the performance of the network.   It
is
> >>>> the responsibility of the network operator to deploy the network is a
> >>>> way to deliver appropriate levels of service,  establish clear
> >>>> definitions of the different levels of service and communicate the
> >>>> differences to the customers so that they know what they are getting.
> >>>> I
> >>>> personally love Vuze, I use it to get my favorite Showtime shows and
> >>>> also for downloading OS images and software updates.  Using it for
> >>>> these
> >>>> purposes doesn't harm or degrade my network and is a very appropriate
> >>>> set of uses for me or any other user on my network.  It does help
that
> >>>> I
> >>>> have optimized the software to use a limited number of connections,
and
> >>>> have also optimized my network to ensure that no customers are able
to
> >>>> open an excessive number of connections to use it.   This not a
> >>>> violation of "Network Neutrality" or an example of "Intentional
> >>>> Degradation" to an application.   It is optimization.  It is also the
> >>>> responsibility of companies like Vuze to make sure that their
software
> >>>> is optimized for good performance as well - it is in their best
> >>>> interest.
> >>>>
> >>>> Bit Caps are not necessarily the answer, as it introduces levels of
> >>>> billing complexity and doesn't always represent the best solution.
If
> >>>> there is extra capacity on the network, and the provider's backbone
> >>>> connection is not subject to bit caps or usage-based billing, then
bit
> >>>> caps are not needed because the economic cost of extra bits is
> >>>> inconsequential.   However, too many have taken this too far, leading
> >>>> to
> >>>> the idea that "bits are free", which is total B.S.   There is always
an
> >>>> underlying foundational cost of infrastructure connectivity, and that
> >>>> cost needs to be taken into consideration.   The "free bits" exist in
> >>>> the netherland of non-peak hours and the interval between a backbone
> >>>> connection that is too large and one that is saturated.  Free bits
> >>>> represent a place for innovation, and some providers are doing just
> >>>> that, with open downloads and service level upgrades during off-peak
> >>>> hours.   But not all bits are free.
> >>>>
> >>>> In conclusion, I don't think that the Vuze petition is too far off
the
> >>>> mark.   Someone SHOULD be raising a stink about what Comcast is
doing -
> >>>> it goes beyond prudent network management and right into anti-trust
> >>>> type
> >>>> behavior.
> >>>>
> >>>> Matt Larsen
> >>>> vistabeam.com
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Anthony Will wrote:
> >>>>> Here is some food for thought,
> >>>>>
> >>>>> We may want to approach this issue with a free market approach.  We
> >>>>> may want to emphasize that the free market can and will self
regulate
> >>>>> this behavior.  If Comcast is discouraging their customers from
> >>>>> operating this type of software, that creates an opportunity for
> >>>>> another operator to move into the area that does not. We do have to
> >>>>> keep in the back of our mind that the main issue for us as wireless
> >>>>> operators is that P2P solutions create an burden on our systems not
so
> >>>>> much for bandwidth but on the amount of connections that are created
> >>>>> by this type of software.  One P2P application that goes wild with
> >>>>> 2000+ connctions can bring an AP to its knees thus effecting 50 -
200
> >>>>> other customers on that same AP.
> >>>>> We may also want to empathize that his type of "distributed" content
> >>>>> if allowed to continue likely will lead to bit caps or other types
of
> >>>>> metered solutions for customers.  Vuze and other "content" providers
> >>>>> are looking to use our infrastructure to implement their business
> >>>>> plans without paying for that distribution, with the minor exception
> >>>>> of a one time "seeding" of that contact to the Internet.  This is in
> >>>>> my opinion as close to theft as you can get without crossing the
> >>>>> line.  The only recourse that operators will have is to implement a
> >>>>> bit cap (by the way this is common in almost every other part of the
> >>>>> world) in order to fund the increased infrastructure needed to carry
> >>>>> these content providers products for them.  Ultimately the customer
is
> >>>>> the one that is going to have to pay for this and other
organizations
> >>>>> bypassing of the reasonable cost for the distribution of THEIR
> >>>>> content.
> >>>>> Of course we would also want to put in there the reality that the
vast
> >>>>> majority of the content provided by P2P is the illegal distribution
of
> >>>>> copywrited materials.
> >>>>>
> >>>>> Looking forward to the discussion,
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
>
>>>> -----------------------------------------------------------------------
---------
> >>>>
> >>>> 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/
> >>>>
> >>>
> >>>
>
>>> ------------------------------------------------------------------------
--------
> >>>
> >>> 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/
> >>
> >>
> >>
>
>> -------------------------------------------------------------------------
-------
> >>
> >> 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/
> >>
> >
> >
> >
>
> --------------------------------------------------------------------------
------
> > 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/
> >
>
>
>
> --------------------------------------------------------------------------
------
> 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/
>




--------------------------------------------------------------------------------
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/

Reply via email to