[j-nsp] cable modem/dsl/ftth bandwidth limiting

[Tom Storey]

An ISP I used to work for shaped/policed every single session at the
LNS, downstream towards the customer, to the maximum service speed of
their purchased plan.

If a customer suddenly becomes the target of a DoS attack, you dont
want hundreds or thousands of megabits flooding onto your expensive
and/or limited uplinks to your wholesale broadband suppliers and
potentially affecting all of your customers instead of just 1.

Also if a customer is provisioned for say 2mbit, and the provider
stuffs up and accidentally allows 20mbit, the customer still only gets
what they paid for, though I think that was very rare, and it was
mostly to protect from the above.

They used a number of different platforms (all Cisco) from 7200, to
10000, and now ASR1k.

Tom


On 19 June 2012 21:41, Chris Kawchuk <juniperdude at gmail.com> wrote:
> Not costly at all; when you think about scaling it to 20,000/30,000 subscribers per box.
>
> BRAS's (xDSL, PPPoE, PPPoA) have massive numbers of hardware queues, and shape/queue per individual subscriber. These boxes are designed to do this.
>
> Examples: Juniper E-series, Cisco ASR-Series, Juniper MX-series w/the "Q" cards, Redback SmartEdge 400/800, etc...
>
> You still need "something in the central network" anyways to aggregate all these individual connections from every scubscriber. It's a natural to perform this function there; and not at the CPE. Usually it's the link between the DSLAM/CMTS/GPON to the Customer that's congested anyways - As Jerry mentioned, why transport it just to drop it? May as well rate-limit it upstream before it hits the narrow-bandwidth portion of the link to the customer.
>
> - CK.
>
> On 2012-06-20, at 3:19 AM, Chris Evans wrote:
>
>>  performing bandwidth limits on a central network device
>> would be too costly to do.
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp