dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
46

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

funchords to Anon123

MVM

to Anon123

Re: Sounds like blocking

said by Anon123 :

Comcast uses sandvine not because of peering issues but due to the bandwidth limitations of DOCSIS 1.0/1.1 on the upstream.
BZZT, sorry Mr. Anonymous, but you know that is not true.

Comcast already provisions the modem, and can control the upload speed dynamically (as evidenced by upload PowerBoost).

They use Sandvine because it injects forged packets that make it difficult for consumers to notice that Comcast was not delivering the upload bandwidth that they were obligated to provide. Meanwhile, they could still "appear" to compete with FIOS and DSL when clearly, they they have an inferior product.

Anon123
@comcast.net

Anon123

Anon

Yes they can control the upload speed up to what 16QAM currently handles (~10mb). But with cable's toplogy you know that 10mb is split across anywhere from 250-1000 homes.

Since CDV requires available upstream bandwidth as well you start to run into a problem with limited resources and want to make sure you're upstream bandwidth isn't being eaten by P2P connections that can sometimes stay connected for days at a time.

When DOCSIS 2.0/3.0 rolls out I think it will be less of an issue since you'll have 3x as much bandwidth per upstream. Some people will probably disagree but there is no throttling on the downstream at this point and new modulation profiles will make the upstreams bandwidth potential look a lot more like the download bandwidths potential.

SpaethCo
Digital Plumber
MVM
join:2001-04-21
Minneapolis, MN

SpaethCo to funchords

MVM

to funchords
said by funchords:

BZZT, sorry Mr. Anonymous, but you know that is not true.
Actually, he was absolutely accurate with that statement.
said by funchords:

Comcast already provisions the modem, and can control the upload speed dynamically (as evidenced by upload PowerBoost).
Powerboost doesn't adjust the upstream speed in the way you are suggesting. It's a fixed ruleset: Transmit at {x} bits per second for {y} bytes, after which rate-limit to {z} bits per second until traffic falls below {#} bits per second.
said by funchords:

They use Sandvine because it injects forged packets that make it difficult for consumers to notice that Comcast was not delivering the upload bandwidth that they were obligated to provide.
They used Sandvine to solve a problem with upstream congestion resulting from P2P flows that exceed the carrying capacity of their current DOCSIS network implementation. Outside of P2P applications, traffic demand of that level would not be seen on broadband networks.

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

funchords

MVM

said by SpaethCo:
said by funchords:

Comcast already provisions the modem, and can control the upload speed dynamically (as evidenced by upload PowerBoost).
Powerboost doesn't adjust the upstream speed in the way you are suggesting. It's a fixed ruleset: Transmit at {x} bits per second for {y} bytes, after which rate-limit to {z} bits per second until traffic falls below {#} bits per second.
Right -- but that ruleset is applied at the headend (it has to be, since PowerBoost is enabled based on node conditions as well as individual conditions).

That's why I said what I said. It's sadly ironic. They didn't need Sandvine's injected RST's at all -- they have everything they need to constrict the upload on a spigot-by-spigot basis right at the headend.
funchords

funchords to SpaethCo

MVM

to SpaethCo
said by SpaethCo:
said by funchords:

They use Sandvine because it injects forged packets that make it difficult for consumers to notice that Comcast was not delivering the upload bandwidth that they were obligated to provide.
They used Sandvine to solve a problem with upstream congestion resulting from P2P flows that exceed the carrying capacity of their current DOCSIS network implementation. Outside of P2P applications, traffic demand of that level would not be seen on broadband networks.
Examples of upload flows of capacities equal to P2P file sharing:

1. Security cameras
2. Remote backups
3. Slingbox (and similar)
4. Any FTP upload, including mirroring
5. Participating in an H.323 or similar videoconferencing
6. Hotspot or hotel security using a personal proxy or VPN server
7.
8.

SpaethCo
Digital Plumber
MVM
join:2001-04-21
Minneapolis, MN

SpaethCo to funchords

MVM

to funchords
said by funchords:

Right -- but that ruleset is applied at the headend (it has to be, since PowerBoost is enabled based on node conditions as well as individual conditions).
I think you're reading too much logic into how it actually works. In order to avoid collisions on the upstream channel, DOCSIS 1.1+ systems use TDMA to dole out time slices to cable modems who request them so that they can transmit. You basically end up with a "bucket" of timeslots to dole out based on the TDMA configuration. The size of each timeslot is a function of the upstream channel capability (9megabit on DOCSIS 1.x systems) divided by the number of timeslots per second the CMTS is capable of jmanaging.

The timeslots in the bucket get divided equally amongst every device requesting a time slot up to the rate limit they are provisioned for. So for Powerboost you will be allowed to grab 2mbps worth of timeslots as long as there are sufficient timeslots in the bucket, and after {x} number of bytes you will be scaled back to a maximum of 384kbps or 768kbps worth of timeslots from the bucket.

Keep in mind that all this is a highly specific instruction set baked into an ASIC to maintain performance. The more complicated the instruction set, the more expensive the ASICs are to produce so network manufacturers try to keep things as simple as possible. The various conditions you refer to really boil down to the two simple resources: free timeslots in the bucket, and the limit of how many timeslots can be allocated to each modem every second. When enough CPE devices start requesting time slots the division of the bucket of resource across all modems is less than the powerboost rate, and can even be less than the non-boost max limit.
said by funchords:

That's why I said what I said. It's sadly ironic. They didn't need Sandvine's injected RST's at all -- they have everything they need to constrict the upload on a spigot-by-spigot basis right at the headend.
Well, sort of. The "dials and knobs" you have to work with are pretty limited overall on hardware-based network routing equipment. They would pretty much be limited to throttling the speed of the entire pipe as the CMTS doesn't have the smarts to perform the same heuristical analysis as the Sandvine appliance, and there is no way for Sandvine to inject information into the control plane to let the CMTS know which packets to throttle. The interaction would basically need to be the same as the provisioning system that handles establishing the parameters of your connection if you upgrade or downgrade service. So basically they could set it up that if you max your upload for more than {t} amount of time, they will reprovision your upstream connection to {x} kbps. Making that many configuration changes can be risky, and would likely present a greater risk to the overall stability of the network than the current Sandvine implementation.

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

funchords

MVM

said by SpaethCo:

They would pretty much be limited to throttling the speed of the entire pipe as the CMTS doesn't have the smarts to perform the same heuristical analysis as the Sandvine appliance, and there is no way for Sandvine to inject information into the control plane to let the CMTS know which packets to throttle.
Last item first: invent one.

As for the rest of the quote -- at that particular moment, do we care that it throttles the speed of a customer's connection? Wouldn't it be more neutral (not to mention less surreptitious, less privacy invasive, more in keeping with Internet Standards) to manage upon an account overall rather than to pick on a protocol in use on the account?
funchords

1 edit

funchords to SpaethCo

MVM

to SpaethCo
said by SpaethCo:
said by funchords:

Right -- but that ruleset is applied at the headend (it has to be, since PowerBoost is enabled based on node conditions as well as individual conditions).
I think you're reading too much logic into how it actually works.
Absolutely I am -- on purpose. Richard Bennett actually gave me this idea, because he was arguing about the inability for an MSO to dynamically cap or throttle users at the cablemodem end. He totally failed to mention the head-end, which prompted me to ask "what about the head-end?"

In short, his answer was that it could work -- it's just not what happened. Here Comcast (et al) ignored a tremendous opportunity and used Sandvine instead. (I'm still of the thought that Sandvine was some senior-manager's decision and it lacked the consensus of the senior engineers that I know work for Comcast.)

SpaethCo
Digital Plumber
MVM
join:2001-04-21
Minneapolis, MN

SpaethCo to funchords

MVM

to funchords
said by funchords:

Last item first: invent one.
It wouldn't do you any good.. not in the near term. In order for that to work you'd need to have a Sandvine-like device that was a blade in the Cisco CMTS chassis so that it could interact directly with the control plane. Also, control plane hooks would need to be written which would require new hardware. You're basically talking about a multi-million dollar forklift upgrade that wouldn't actually create additional capacity -- there would be no gain other than a more "gentle" way of dealing with P2P throttling.
said by funchords:

As for the rest of the quote -- at that particular moment, do we care that it throttles the speed of a customer's connection?
You'd still need to do the heuristical discovery of P2P traffic, you'd have to find a way harness that data and interface with the provisioning system to adjust the configuration of the CMTS.

Doable? Sure. More expensive than Sandvine? At least an order of magnitude more expensive.