republican-creole
site Search:


 
    All Forums Hot Topics Gallery






how-to block ads


 
Search Topic:
Share Topic
Post a:
Post a:
AuthorAll Replies


Qumahlin
Never Enough Time
Premium,MVM
join:2001-10-05
united state

reply to anon123456

Re: Finally

said by anon123456 :

ARP or DHCP broadcasts would stop at the router and not be forwarded onto the cable modem.
Um, the modem receives the traffic BEFORE the router. The modem is the gateway device..not the router. The traffic would not be forwarded on to your PC's but it is still hitting the modem and your router as well.

No this traffic most likely won't be counted, but the one post about 60Kbps sec in arps is something that is a fluke and typically a "storm" of that size would be killed by other management software in place at the CMTS level if it continued for more than a few minutes.

Notice the user said it caused his overall speeds to crash when it was happening, it's not a normal occurence


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

said by Qumahlin:

Um, the modem receives the traffic BEFORE the router. The modem is the gateway device..not the router. The traffic would not be forwarded on to your PC's but it is still hitting the modem and your router as well.
Right.

said by Qumahlin:

No this traffic most likely won't be counted, but the one post about 60Kbps sec in arps is something that is a fluke and typically a "storm" of that size would be killed by other management software in place at the CMTS level if it continued for more than a few minutes.
Who knows? We're just guessing here. It will be interesting to see how close they get. The screen shots from the news article showed the summer months -- so I've got to wonder whether all this time spent now on something apparently there for a while is about looking at and fixing the accuracy of an existing system.

said by Qumahlin:

Notice the user said it caused his overall speeds to crash when it was happening, it's not a normal occurence
IIRC, his area was coming back up from some kind of problem. I'm really not worried about ARP alone, or DHCP broadcasts, or munged packets, or any single thing. The combination of problems of monitoring "delivery" in a best-effort system like the Internet may cause some different results in different environments -- a one-size-fits-all system is unlikely to get it right, we'll be talking about this a lot.

Continuing to focus on perfecting metered Internet, we are continuing to underline the fact that broadband with Comcast sometimes involves a choice between expensive, bursty, boosty, laggy, lossy, limited cable ISP service and a cheaper, unlimited, "fast-enough" alternative (with its "we suck even harder" customer service in my Verizon DSL area).

If Comcast's anti-congestion plan that it's rolling out is truly effective, why do we need caps? Why not go back to unlimited?
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...


anothercomment

@anonymouse.org

said by funchords:

If Comcast's anti-congestion plan that it's rolling out is truly effective, why do we need caps? Why not go back to unlimited?
Not sure I am the fish you are looking for, but I do have some ISP experience and will bite on that baited question...

Because congestion management is to manage unexpected congestion in a fair way. Upgrades on the network still happen as per the business plan in an organized way around expected growth. Otherwise you would have to run congested all the time.

Usage management is to manage the situation where this now becomes expected requiring unexpected upgrades to the network outside the business plan. Since the business plan justifies upgrades, new speeds and price points, you want to ensure you distribute the costs in a "fair" way across a user base.

Since studies show that top "unlimited expecting" users will consume all available bandwidth they are given, their cost of carry exceed their revenue provided. Summary: 1 manages unexpected congestion (to keep networks fair) and one managed unexpected growth (to keep costs fair).

The idea is either to find a "good" cap and grow with it, or charge to offset the cost of usage as is done under commercial terms. You don't have to like it, you can continue to argue against it, but there is plenty of Internet history showing this method and it is reality.


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

Thanks for the kind and thoughtful reply

said by anothercomment :

Because congestion management is to manage unexpected congestion in a fair way. Upgrades on the network still happen as per the business plan in an organized way around expected growth. Otherwise you would have to run congested all the time.

Usage management is to manage the situation where this now becomes expected requiring unexpected upgrades to the network outside the business plan. Since the business plan justifies upgrades, new speeds and price points, you want to ensure you distribute the costs in a "fair" way across a user base.
It appears that the business plan is to grow available bandwidth slower than typical Internet growth trends. Assuming 250 GB was the right amount for October 2008, we should have a cap of 275 GB now.

But who cares if I use 500 GB if I use them when nobody else is competing for them? If I am successful and avoid transmitting my massive data spew during signs of congestion, then my use of 500 GB is -- by definition -- not only within the business plan but within the existing system.

And if I'm unsuccessful, then Comcast's "sloppy-seconds" bandwidth management takes hold and I can't harm normal users anyway -- under that plan, I am not entitled to any bandwidth and any that I do get is bonus.

As a result, one way or the other, we don't need a cap.

Since studies show that top "unlimited expecting" users will consume all available bandwidth they are given,
Study or not, the notion is wrong on its face. Most users only use 3 GB (we are repeatedly told), despite having much more at their disposal and having the service that was not sold with limits.

(We've never seen such a study. ISPs have quoted this amount without explanation or qualification. My guess is that my idle computers probably consume 3GB/mo.)

their cost of carry exceed their revenue provided.
It's silly to look at this in any level other than the aggregate, otherwise you create the situation where the owner of an all-you-can-eat buffet is running a secret per-plate tally and kicking out customers when they exceed his hidden business plan. (That's not a shot at Comcast -- as they have now disclosed that they have done something like this for years. That's not about fairness, that's about fairer dealing.)

Summary: 1 manages unexpected congestion (to keep networks fair) and one managed unexpected growth (to keep costs fair).
I hold that the "15+15 and out" plan really does both. Aggregators (Aggregaters?) don't pay by consumption, they pay by the width of the pipe which Comcast controls. Those costs are, by definition, fixed. As the heavy users force it toward full, Comcast deprioritizes their traffic which allows others to remain unimpacted.

There's zero need for a cap.

The idea is either to find a "good" cap and grow with it,
A cap that grows at some guaranteed minimum rate with adjustments to match actual Internet growth trends would be very good for users and innovators. Right now, we probably have VC's sitting on the sidelines because who wants to invest in projects that might hit the cap?

or charge to offset the cost of usage as is done under commercial terms.
That's another angle. But let's not stop there. What about families of 5 users or more -- why can't they buy a second allocation of 250 GB or 70%-70%-out for their home? (AT&T's and RoadRunner's trials of 150GB/mo and 40GB/mo are actually the best examples of this problem. 250 GB is still a lot of bandwidth.)

You don't have to like it, you can continue to argue against it, but there is plenty of Internet history showing this method and it is reality.
This is the first we've brought up history. If you'd like, we can go there. We did struggle with this in the past and how we handled it is very illuminating and useful.

Nice reply, thanks!
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...

Friday, 01-Jun 00:55:47 Terms of Use & Privacy | feedback | contact | Hosting by nac.net - DSL,Hosting & Co-lo
over 12.5 years online © 1999-2012 dslreports.com.
Most commented news this week
Hot Topics