NNSquad - Network Neutrality Squad

NNSquad Home Page

NNSquad Mailing List Information

 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ NNSquad ] Re: Richard Bennett on Comcast and Fairness (from IP)


Fred,

What you present is certainly not the most offensive of options. I don't generally have a problem with services that are billed without concern to the origin, destination or content of packets and this tri-class service doesn't really violate that.

That said, this isn't what is being asked for at a regulatory level. We're being asked to let ISPs create application classes based upon the type of traffic, and who is communicating. Instead of priority/normal/scavenger we're getting VoIP/Web/Torrent.

The question is one of whether this technology can be deployed neutrally, and whether it will lead to an incentive to neglect the 'normal' class to drive demand for priority class traffic.

K


Fred Reimer wrote:
I think you're missing a key understanding of QoS.  That is, for the traffic
that is tagged as high priority you only get a limited bandwidth.  Say
128Kbps.  That would allow you to make a VoIP call, for instance.  Then you
have your "normal" traffic, which again is capped at some rate, say 1Mbps.
And finally you have a scavenger class that is not capped.  So if you go
over your rate for high priority traffic the non-conforming traffic is
either dropped or retagged by the ISP to the medium priority tag.  In most
enterprises with QoS configurations it is dropped, because only VoIP or
other RTP traffic is allowed in the high priority class, and the network is
designed with a specific load requirement.  Anything above that and someone
obviously screwed up somewhere.  For medium priority traffic, non-conforming
traffic would be retagged as scavenger (never just dropped).  And scavenger
class could use as much bandwidth that they can pump down the wire.

So what are the results?  Well, there is no "personal" QoS and "network" QoS
if you understand how QoS actually works.  With DiffServ QoS is a per-hop
behavior.  We are not talking about IntServ here.  So you can "personally"
tag all of your bit torrent traffic as high priority to your hearts content.
However, there is a published policy by the ISP that says you only have so
much guaranteed bandwidth of high-priority traffic, and they will drop or
retag anything over that rate.  Same thing with normal priority traffic.  So
if you tag your packets correctly then you'd be able to make your VoIP call
(High), browse the web (medium), and use bit torrent (scavenger/low) all at
the same time.  And someone down the street who attempts to make all of
their bit torrent traffic as high or medium priority would not effect your
traffic (because it would be retagged or dropped due to bandwidth
restrictions).

Now, the ISP's pipes are going to be at 100% utilization constantly, so it
may makes things a bit more difficult for them to manage.  They can't just
look at utilization, because it is a meaningless statistic now.  They would
actually have to do some provisioning to make sure that they can handle
concurrent high priority traffic for all of their users.  That would be the
minimum bandwidth required.  They would also have to look at statistics for
retagging of user traffic and such.

This would be the only interference or modification of end-users' traffic by
an ISP, other than normal protocol modifications such as TTL decrements,
etc., that I would support.  And it is important to note that the ISP
doesn't get to decide what is high priority and what is not.  They only
publish a contracted level of service and police their network to those
bandwidth levels.  It is the end user who can feel free to make their own
decision as to what the appropriate priority to put on various different
traffic.

And there need be no increased cost to the users.  Yes, there will be more
management required by the ISP's, but they can stop wasting their time and
ticking off their customers by messing around with DPI and other
technologies and just run a dang network.  Users are not charged by the GB,
and they are never "cut off" after a certain amount of traffic.  I'd welcome
different "levels" of offerings by the ISP's, to be strictly limited to the
various values for the bandwidth limits in the scheme.  So, for instance,
someone paying $40 per month may get the 128K/1Mbps limits, while someone
paying $60 a month may get 256K/3Mbps limits.  You are, however, able to
suck down, or transmit, as much traffic as you possibly can.

And that would be the ideal situation for me.  Let the ISP's overprescribe
all they want.  They won't be able to offer competitive plans if they don't
build their network properly, and we can't force them to build their network
capacity.  And if you are going to purposefully overprescribe a network you
have to have something like QoS in place or your performance is going to go
all to hell.  I don't think that is something that the ISP's have grasped
yet.

All of this would of course make our job easier in policing the ISP's.  It
would be trivial to write applications that did tests to make sure that
traffic you tag as high priority is in fact transmitted with high priority
(it arrives at its destination still tagged appropriately) and that no
traffic is dropped up to the published rate.  The others would be a little
more difficult to detect, but at least we wouldn't be stuck in the situation
that we are now, with ISP's thinking (probably legally correctly) that they
can do anything they want because their contract says so.  For this reason,
I'd welcome the FCC forcing ISP's to implement QoS (but I have no illusions
that they would get it right or that ISP's would not try and use the process
for unfair advantage or to try and squeeze more money out of customers).


Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc.

P.S. The QoS I use as an example is just an example.  ISP's would of course
be free to create as many classes as they want.  The essential classes would
be the priority class, the scavenger class, and any number of other classes
in between.


-----Original Message-----
From: nnsquad-bounces+freimer=ctiusa.com@nnsquad.org [mailto:nnsquad-
bounces+freimer=ctiusa.com@nnsquad.org] On Behalf Of Kevin McArthur
Sent: Wednesday, January 16, 2008 4:20 PM
To: richard@bennett.com
Cc: nnsquad@nnsquad.org; Lauren Weinstein
Subject: [ NNSquad ] Re: Richard Bennett on Comcast and Fairness (from IP)

I'll respond to the comments on my reply.

"I agree, Kevin, that as a matter of principle it's not the network's
job to "determine the value of bits", but I disagree that all bits are
therefore of equal value. We all know that some information is more
valuable to us personally than other information, and we're quite good
at sorting it all out. I propose that we communicate our own
determination to the network, and require it to convey bits (packets,
really) at the priorities we've specified. This is what we do in WiFi
networks with WME enabled, maintain separate priority queues for four
types of data, and it works quite well, and with no Telco in the picture.
"

You're mixing personal QoS which can occur at a residential router and
network QoS. We have personal technology, it works, anyone can go down
to a retailer and get a QoS router. Where your logic breaks down is
where your QoS preferences as a network user interfere with mine.

My priorities are not my neighbors priorities and they're certainly not
my ISPs. If I communicate that my bittorrent download is priority, can
we expect that an ISP will just accept that? If not, will they want to
bill for that 'priority' and will that not lead to the type of
competition differentials we're currently seeing for VoIP products in
Canada. The ISPs charging 'thinly veiled VoIP tax[es]' so that competing
services continue to work?

Some Questions:

Do you propose that we create a gradient of bandwidth pricing?
Would top priority bandwidth cost more?
Isn't this the two-tier scenario, and highly prejudicial to the poor?
Wouldn't this discourage the development of new media services that
require both high bandwidth and low latency?
Wouldn't this give a distinct competitive advantage to the ISP over
third-party competitors?
Doesn't this work as as a disincentive to create faster networks, as if
the normal pipe is purposefully broken or neglected, then all users will
be forced onto the priority pipe and therefore generate more revenue for
carriers?

Is it not just cheaper, easier and more socially fair that the carriers
be required to build their network's capacity in ratio to overall usage
so that all applications and participants get the best possible service?

The business of packet priority is not a technical one, it is instead a
social question of considerable consequence.

Kevin McArthur



Richard Bennett wrote:
A few responses to some of the remarks on my article posted on
NNSquad, for the mutual benefit and what-not.

Kevin McArthur wrote:
It is not the purpose of a network to determine the value of bits,
nor is it right to treat any bit as better than another. A text
message might be really important to someone else, but my ability to
watch a streaming news report is really important to me. Which one
will the carrier prioritize? This isn't a determination they can
make, nor is it one where the value of the transmission can be
determined by the number or amount of bits traveling.
I agree, Kevin, that as a matter of principle it's not the network's
job to "determine the value of bits", but I disagree that all bits are
therefore of equal value. We all know that some information is more
valuable to us personally than other information, and we're quite good
at sorting it all out. I propose that we communicate our own
determination to the network, and require it to convey bits (packets,
really) at the priorities we've specified. This is what we do in WiFi
networks with WME enabled, maintain separate priority queues for four
types of data, and it works quite well, and with no Telco in the
picture.
Barry Gold wrote:
But even if the "excessive" user _were_ "blocking the line to
the...buffet" (presumably by filling the local loop up with his
packets), dropping packets is a useful solution. The ISP can (or
should be able to) program the cable modem to drop the packets before
they ever get on the local loop -- right there in the user's
house/apartment/business. Or if the user owns the modem, the ISP can
put a minimal router with usage control at the point where the wire
emerges from the user's building, or where it connects to the main
cable at the utility pole or undergound system.
As others have pointed out, the DOCSIS cable modem carrier doesn't
have the ability to instruct the user's modem to drop packets rather
than attempt to transmit them. Dropping packets also has no immediate
effect on the load on the local segment caused by BitTorrent
handshakes. Packet drop reduces the load on a segment caused by an
ongoing stream of TCP traffic, but it does nothing to reduce load
caused by SYN responses when the SYNs are coming from outside the
segment.

Andy Richardson wrote:
They can go in several different directions:
(1) upgrade their infrastructure to handle the traffic
(2) lower prices to make up for lower network performance
(3) lose customers until the problem basically fixes itself
(4) establish tiers of access w/ easily understood caps, charging
more for heavier access
(5) implement a shady scheme of network shaping and undocumented
caps until the market matures and rome burns, see option 3.
In fact, Comcast at least is doing all the above. Later this year,
they're rolling out an upgrade to 130/100 Mb/s service, which will
presumably complement the existing offerings, which include 4 and 6
Mb/s residential and a commercial service where it's OK to run
servers. The current flap over Comcast comes from people with want to
operate servers (BitTorrent Seeder is simply a server) in violation of
the TOS for residential accounts. Buy a commercial account and you can
seed to your heart's content.

RB