BitTorrent swarms have a deadly bite on broadband nets

Wed Oct 24 14:09:45 UTC 2007

Brian:

I do operate a DOCSIS network as part of my job, so I do have an inkling in
regards to its network design. =)

"For a 30 Mbps Docsis 2.0 configuration, you need to have a 6.4MHz
widechannel with 64qam modulation."  You don't *need* to operate at that
wide or high a modulation for DOCSIS 2.0, though it's advantageous.  In
speaking with a Motorola SE on this, he's seen very few MSOs operate their
upstream at 6.4 MHz/64-QAM, though that's they're goal.  The modulations
between 16-QAM and 64-QAM are generally being avoided.

It's my understanding that the same MSOs who are moving toward the channel
bonding of DOCSIS 3.0 are also doing digital simulcast and/or digital
switching, because of those spectrum concerns.  This makes moving toward
channel bonding a concerted effort on their part.  If they are successful, I
think they can achieve sufficient speeds in comparison to fiber -- at least
they are in a better position than those doing FTTN or FTTC, just as
SBC/BellSouth.

BTW, in N.A. it's a 6 MHz wide carrier, not 6.4 MHz.

Regards,

Frank

-----Original Message-----
From: Brian Raaen [mailto:braaen at zcorum.com] 
Sent: Wednesday, October 24, 2007 7:53 AM
To: frnkblk at iname.com
Cc: nanog at nanog.org
Subject: Re: BitTorrent swarms have a deadly bite on broadband nets

Dear Frank,
        As representing a network service provider who works with affiliates
with
cable, DSL, fiber, and wireless networks I think I can help you answer some
of your questions.  Our company supports many cable company, and since I
started working here is March I have learned much about cable.  First the
speeds listed are for the optimal configuration (which requires a clean
cable
plant and free bands).

        In a Docsis 1.x environment you only get 10.240 Mbps if you are
using a 3.2
MHz wide channel and using 16qam modulation.  My experience is that many of
the affiliate networks I work with do not have that configuration.  I have
been working with one provider upgrading them from a 1.6 MHz qpsk config to
3.2 MHz 16qam (in Docsis 1.x you only have qpsk and 16qam modulation types.)

        For a 30 Mbps Docsis 2.0 configuration, you need to have a 6.4MHz
wide
channel with 64qam modulation.  64qam is more sensitive to noise than 16qam
and much more sensitive than qpsk.  Also the 6.4MHz channel is wider and
eats
up spectrum realestate, particularly if you use more than one upstream
frequency.  The other problem with using 6.4MHz upstreams is that any Docsis
1.x modems that you still have out there will not work at all with it, and
all modems on that node must be Docsis 2.0.  If a provider uses a 3.2MHz
channel with 64qam they can let a docsis 1.x 16qam subchannel coexist on the
same frequency.  Using a 3.2MHz channel with 64qam only gives a theoretical
(not counting overhead) limit of 15.360 Mbps.

        Docsis 3.0 acheives most of its speed by bonding channels together.
Note
that each downstream channel is a possible TV channel, and the cable company
will have to determine the value of using a given channel for TV or data.
Docsis 2.0/3.0 also can use 128qam, but many modems do not support it nor
are
many cable plants clean enough either.

        You mentioned upstreams and ports.  Cable unlike DSL is a shared
resorce
meaning that the 10 Mbps or 30 Mbps upstream is shared by everyone on the
node.  Also note that the 27Meg/45Meg downstream is shared by all users
connected to that downstream.  Many CMTS's are in a 1:4 or 1:6 configuration
which means that there are 4 or 6 upstreams to every downstream.  Remember
that everyone in that node shares the bandwidth.  What I normally see as a
general limit is about 500-1000 customers per blade. That means that there
are between 83-250 people per upstream port.  If the speed was distributed
evenly (an not over subscribed) each person would get at most 180Kbps down
and  120Kbps up.

        Docsis 3.0 will help with speeds, but providers may not want to give
up TV
channels for extra data speeds.  While many cable systems have more room for
uploads, many others do not.  When an older configuration works most people
are reluctant to change, and many cable technicians do not like locating and
troubleshooting noise issues.

        Sorry for making things muddy, but cable is not the best long-term
solution
for speed.  Fiber to the home/node is much more attractive and quite a few
people are offering it.

--
Brian Raaen
Network Engineer
braaen at zcorum.com

On Tuesday 23 October 2007 23:46, Frank Bulk wrote:
>
> We're living in a DOCSIS 1.1 and 2.0 world, which gives us 40 down, 9 up
in
> a best case.  Considering that there are ~4 upstream ports for every
> downstream port, the MSOs are already operating their network in a 40:36
or
> almost 1:1 ratio.  It's just that upstream is a much more precious item
that
> that they can't afford to fill up on a particular node, and most people
find
> download speeds much more important most of the time.
>
> We'll talk about DOCSIS 3.0 in a year from now and see how it's being
> deployed.
>
> Frank
>
> -----Original Message-----
> From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On Behalf Of
Leo
> Bicknell
> Sent: Tuesday, October 23, 2007 11:05 AM
> To: Joe Provo
> Cc: nanog at merit.edu
> Subject: Re: BitTorrent swarms have a deadly bite on broadband nets
>
> In a message written on Tue, Oct 23, 2007 at 10:34:00AM -0400, Joe Provo
> wrote:
> > While I expect end-users to miss the boat that providers use stat-mux
> > calculations to build and price their networks, I'm floored to see the
> > sentiment on NANOG.  No edge provider of geographic scope/scale will
> > survive if 1:1 ratios were built and priced accordingly. Perhaps the
> > M&A colonialism era is coming to a close and smaller, regional nation-
> > states... erm last-mile providers will be the entities to grow with
> > satisfied customers?
>
> I'm not sure NANOGers are missing the boat, just bemoaning the
> economics of the situation and some companies choices.
>
> As an example, if I believe http://en.wikipedia.org/wiki/DOCSIS (as I'm
> no cable export):
>
> DOCSIS 1.x, 10.24Mbps upstream.  With this providers regularly offered
>             384-768k upload speeds to customers.
>
> DOCSIS 3.0, 122Mbps upstream.  That's about 12x.  Applying the 12x to
>             the original upload speed that's 4.6-9.2Mbps upload speed
>             per user.
>
> And yet, today most of the major national providers don't over more
> than 1Mbps of upload speed in their fastest packages.
>
> Perhaps the real issue here is that broadband providers don't have
> enough diversity in their products.  Picking on an unnamed cable
> provider and looking at their web site I can get:
>
>    4M down, 384k up.  $39.
>    6M down, 768k up.  $49.
>    8M down, 768k up.  $59.
>
> That's their entire portfolio of residential services.  How about
> a $99 package with 10M down, 3M up?  How about $5 per meg download,
> $20 per meg upload, pick any combination of speeds you want where
> both are under 20Mbps?
>
> And why-o-why are they still giving me modems?  Is not the stack
> of 5 that I already have enough waste?  How much of my service
> charge goes to replacing equipment over and over because it's "how
> they work".  (For instance I moved, and got a new modem with the
> new install, same make and model as the old modem, which they didn't
> want back.)
>
> So, while NANOGers may float the idea of 1:1, what I think really honks
> them off is that the current standard (4M down, 384k up) is 1:10, and I
> think they feel it's time it became more like 1:4 (4M down, 1M up), and
> that seems to be completely within reach of the technology.  Which
> leaves the only thing holding it up being big company management and
> marketing.
>
> I will point out, one of the smaller providers on the Wikipedia page
> under US, CableVision, is said to have 30Mbps down 5Mbps up.  That's
> 1:6, at a heck of a lot higher speeds.  I think most people here would
> be quite happy with that offering.
>
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
>
>
>