 gaforcesUnited We Stand, Divided We Fall
join:2002-04-07
Santa Cruz, CA
1 edit | Sounds like blocking If they only accept packets from local peers, that effectively makes those packets unavailable for the peers from other networks ...
That is violating network neutrality and stinks of proprietary network technology.
--
Vista ~ Less functional every day! |
|
 Matt3All noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | said by gaforces:If they only accept packets from local peers, that effectively makes those packets unavailable for the peers from other networks ... That is violating network neutrality. The article says in the lab, their torrent received 58% of the total data from local, on-net clients. They're not refusing anything.
This is a brilliant way to avoid net neutrality issues, increase the performance of bittorrent downloads for their end users, and save the ISP money. |
|
|
|
gaforcesUnited We Stand, Divided We Fall
join:2002-04-07
Santa Cruz, CA | Ok, I'm kind of skeptical of this but I'll withhold further comment till we get more information.
It sounds too good to be true ...
--
Vista ~ Less functional every day! |
|
patcat88
join:2002-04-05
Jamaica, NY
kudos:1 | reply to Matt3
said by Matt3:This is a brilliant way to avoid net neutrality issues, increase the performance of bittorrent downloads for their end users, and save the ISP money. What about pirated content? Will this only specific infohases (torrents), or only specific DRMed, proprietary p2p clients controlled by Big Media?
The only thing thats this sounds like it will be used for is WOW updates and other corporations that see p2p as a way to increase their profits by offloading distribution charges (fat internet connections) to others. |
|
| reply to Matt3
Comcast uses sandvine not because of peering issues but due to the bandwidth limitations of DOCSIS 1.0/1.1 on the upstream. They would most definitely care if you still saturated your connection since it could potentially impact other subscribers when you eat up all the upstream bandwidth for your node (the traffic still has to go back to the headend and to the ibone...) |
|
 RadioDocYeah, like it matters.Premium,ExMod 2000-03
join:2000-05-11
La Grange, IL
kudos:2
 ·AT&T Midwest
| reply to gaforces
Blocking is the ISP preventing peers from connecting (a la Comcast). This is a client protocol which seeks out peers which are closest, preferably on the same local network, and is not controlled by ISP packet inspection, spoofing or filtering.
Big difference. Huge in fact. Massive.
--
Toolmaster of La Grange. |
|
 funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | reply to gaforces
said by gaforces:Ok, I'm kind of skeptical of this but I'll withhold further comment till we get more information. It sounds too good to be true ... This was exactly my first response.
My second response: as long as users are free to choose, then who cares? If it's better, users will flock to it. If it's not, then they'll ignore it.
So, TEN THUMBS UP TO VERIZON.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
"We don't throttle any traffic," -Charlie Douglas, Comcast spokesman, on this report. |
|
funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | reply to Anon123
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.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
"We don't throttle any traffic," -Charlie Douglas, Comcast spokesman, on this report. |
|
| 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. |
|
 espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2
 ·Vitelity VOIP
| reply 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. |
|
funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | said by espaeth: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.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
"We don't throttle any traffic," -Charlie Douglas, Comcast spokesman, on this report. |
|
funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | reply to espaeth
said by espaeth: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.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
"We don't throttle any traffic," -Charlie Douglas, Comcast spokesman, on this report. |
|
espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2 Reviews:
·Vitelity VOIP
| reply 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. |
|
funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | said by espaeth: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?
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
"We don't throttle any traffic," -Charlie Douglas, Comcast spokesman, on this report. |
|
funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6
1 edit | reply to espaeth
said by espaeth: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.)
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
"We don't throttle any traffic," -Charlie Douglas, Comcast spokesman, on this report. |
|
espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2 Reviews:
·Vitelity VOIP
| reply 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. |
|
