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

["Fred Reimer" <freimer@ctiusa.com>]

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature