how-to block ads
|
Share Topic
 |
 |
|
|
|
 perki
join:2008-12-01
Santa Maria, CA
1 edit |  Wouldn't it be cool if they upped the cap
| |
|   EGThe wings of lovePremium
join:2006-11-18
Union, NJ
kudos:9 | Re: Wouldn't it be cool if the upped the cap said by perki:For people with speeds 16 Megs and higher. Maybe raise it to 300-400 gigs or eliminate throttling all together for people paying more. Unfortunately, that wouldn't alleviate any possible congestion issues for all of the subs on a local segment.
It doesn't matter if some are paying more than others, all will suffer.
Only additional capacity can help. | |
| |  funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | Re: Wouldn't it be cool if the upped the cap said by EG:said by perki:For people with speeds 16 Megs and higher. Maybe raise it to 300-400 gigs or eliminate throttling all together for people paying more. Unfortunately, that wouldn't alleviate any possible congestion issues for all of the subs on a local segment. It doesn't matter if some are paying more than others, all will suffer. Only additional capacity can help. It's very true that only additional capacity is the solution to congestion. Otherwise, we're just reshuffling the demand and denying some of it.
But alleviating any possible congestion issues has never been the goal of the Internet. Minimizing them, responding to them -- yes. In fact, these challenges are really fun to solve and create pretty cool inventions (like efficient codecs).
This is Comcast's decision to make, but if it were my opinion that made the difference, I think that they should "up the cap" -- at a rate that doubles it every two years or faster. Otherwise, it just dies here.
I think that it makes sense that a cap should be proportionate to the tiers. With a 250 GB cap, this service is theoretically useful up to continuous service of 750 Kbps AT EVERY TIER. So how fast do I want to read my email? What can I do at 50 Mbps that isn't just as satisfying at 22 Mbps -- brag?
What's this all about, really? Most of all, I want to be excited about broadband again and I just can't. This ISN'T just a Comcast thing (it's an industry thing) but I have Comcast or Verizon here so I can't help but talk about Comcast. Verizon DSL is -- well, Verizon DSL. It works. It's not going anywhere fast -- Zzzzzz. But, guess what?, neither is Comcast! Oh, they've caffeinated the rabbit but it's still as crippled and fenced in as it was before the jet engines.
Slowski Turtle without limits or Caffeinated Rabbit on a leash -- who will win the race? Neither one gets me very excited.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon -- KJ7RL
... Should we pay those who are "too big to fail" more money to ensure they stay that way? ... | |
| | |  DarkLogixTexan and ProudPremium
join:2008-10-23
Baytown, TX
kudos:3 | Re: Wouldn't it be cool if the upped the cap I think they need to focus on adding capacity and peering with more ISP's in more places
workout a QOS based Cap (say EF gets 64kbps and 00 gets unlimited but EF gets higher priority)(Or since they're doing data per month EF gets 64kbit * 60sec * 60min * 24hours *28~31 days)
that way VoIP would work just fine and Gaming cound use a slightly lower QOS dscp
now you could then workout nice caps for each protocal within reason and if you don't want your data caped it just gets lower priority | |
| | | | funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | Re: Wouldn't it be cool if the upped the cap AWESOME. I've been asking for something like that for nearly a year. | |
| | | | | DarkLogixTexan and ProudPremium
join:2008-10-23
Baytown, TX
kudos:3 | Re: Wouldn't it be cool if the upped the cap Ya it would be perfect but I doubt it'll ever happen | |
| | | | | |  pflogBueller? Bueller?Premium,MVM
join:2001-09-01
El Dorado Hills, CA
kudos:3 | Re: Wouldn't it be cool if the upped the cap said by DarkLogix:Ya it would be perfect but I doubt it'll ever happen Of course not, it'd cost them a lot of money to implement and maintain. Even if it's better for both the end user AND their network "health". 
--
He who is not contented with what he has, would not be contented with what he would like to have. -Socrates | |
| | | | | | |  espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2
 ·Vitelity VOIP
| Re: Wouldn't it be cool if the upped the cap To be fair, this would only work in the upstream direction, and only if the cable modem you are using supported the feature set.
The downstream direction is a lost cause because all of the data is coming in from the Internet. The ToS bits are reset to all 0's by default unless honoring DSCP values is explicitly configured on an interface. For example, on Cisco hardware unless you explicitly add "mls qos trust dscp" to an interface all packets will be remarked to 0's on ingress.
Nifty idea, but impractical for implementation. | |
| | | | | | | | DarkLogixTexan and ProudPremium
join:2008-10-23
Baytown, TX
kudos:3 | Re: Wouldn't it be cool if the upped the cap The idea would only be for Comcast to have the DSCP QOS inplace withing their network so if you have lag its the fault of another network not them
next I'm guessing most home routers currently reset to 0 (which would put people in the low priority w/o the 250 cap) but if ISPs were to put to gather a standard then I'm sure consumer routers would in time add the ability to perserve or ever set the dscp bit
but comcast only supports computer connected directly to the router anyway so why should they care if someone's home router doesn't make use of it | |
| | | | | | | | | funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | Re: Wouldn't it be cool if the upped the cap said by DarkLogix:but comcast only supports computer connected directly to the router anyway so why should they care if someone's home router doesn't make use of it EXACTLY. Worst case scenario -- under this idea, some users' traffic will be treated as all "best effort" because their router doesn't have the latest firmware. But even that would be under the users' control, not the ISPs control.
(And I'm even for the idea that ISPs could, as a value-added service, add an OPTIONAL DPI-enabled QoS classifier. When I mentioned that, one Comcast guy I know just about fell out of his chair. But if it's optional, and it helps the non-technical user do something that's both good for him and good for the network, then why not?)
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon -- KJ7RL
... Do something! ... | |
| | | | | | | | | | DarkLogixTexan and ProudPremium
join:2008-10-23
Baytown, TX
kudos:3 | Re: Wouldn't it be cool if the upped the cap Ya and if it catches on then we could have an internet with DSCP reaching end-to-end one day
Have the ietf lay out a standard that all teir 1 ISP's and below are to follow and gaming would be faster VoIP would work better over the internet and it would all be neutral and as it should be | |
|
| | | | | | | funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | said by espaeth:To be fair, this would only work in the upstream direction, Which is where the felt pain is and only if the cable modem you are using supported the feature set. If Comcast or TWC was to light this up on their network, cable modems would have the feature (if they don't already -- I've never had anyone raise that objection and I've been making this suggestion since last spring).
The ToS bits are reset to all 0's by default unless honoring DSCP values is explicitly configured on an interface. For example, on Cisco hardware unless you explicitly add "mls qos trust dscp" to an interface all packets will be remarked to 0's on ingress. "mls qos trust dscp" costs how much compared to all that intrusive proprietary sniffing hardware that can only guess at priority?
Nifty idea, but impractical for implementation.
Totally practical, cheap, vetted and ready.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon -- KJ7RL
... Do something! ... | |
| | | | | | | | | DarkLogixTexan and ProudPremium
join:2008-10-23
Baytown, TX
kudos:3
3 edits | Re: Wouldn't it be cool if the upped the cap said by funchords:said by espaeth:To be fair, this would only work in the upstream direction, Which is where the felt pain is and only if the cable modem you are using supported the feature set. If Comcast or TWC was to light this up on their network, cable modems would have the feature (if they don't already -- I've never had anyone raise that objection and I've been making this suggestion since last spring). The ToS bits are reset to all 0's by default unless honoring DSCP values is explicitly configured on an interface. For example, on Cisco hardware unless you explicitly add "mls qos trust dscp" to an interface all packets will be remarked to 0's on ingress. "mls qos trust dscp" costs how much compared to all that intrusive proprietary sniffing hardware that can only guess at priority? Nifty idea, but impractical for implementation.
Totally practical, cheap, vetted and ready. Ditto
And if I were to make the standard it would be something like this
E0-EF (VoIP use each customer IP is to be capped at 64kbps for all data matching this butthis data is to have the top prioriy) (this gives each use space to have 16 VoIP lines on one public IP)(and on a business account w/ 5 statics 80Lines although that might start to push it but if a business needs more than 16 they should get a channalized t1 anyway)
then step down the priority as you get closer to 00 and have 4 web surfing traffic ranges a few Gaming ranges some HD streaming ranges with the Caps being per second for some and per month for others (to give enough space to time critical data and enough data/month to downloads
Fast surf (w/100GB cap)
Medium Surf (w/200GB cap)
Large Surf (w/500GB cap)
and unlimited (w/ no cap but slower experiance) | |
| | | | | | | | | | funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | Re: Wouldn't it be cool if the upped the cap Generally agreed!
said by DarkLogix:4 web surfing traffic ranges a few Gaming ranges some HD streaming ranges with the Caps being per second for some and per month for others Hahahaha! Hold on, cowboy!
Actually, we'll all have different view on this. Let's start with a couple and grow from there. There are already some good definitions out there, and I think it would be good to embrace one set. »tools.ietf.org/html/rfc4594 (not a standard) is a good place to read.
I would avoid mixing the behaviors and today's uses too much because the uses would change over time.
I, personally, would probably only really use 4 -- many schemes I've seen have 4 or 8. My fav four --
•Expedited Forwarding (for near-as-possible real-time VOIP, Gaming Joysticks, alarms, synchro) -- a small upload quota that is "fastest fast."
•Assured Forwarding (for some baseline streaming data rate) -- upload traffic in this class under XX Mbps gets priority over traffic in this class over that amount. So if the network is congested, streaming data can work at some minimal "floor" enough to gradually build a buffer but if the sender is annihilating a router at a very high rate, all the excess can be dropped. Today's uses would be camera chatting.
•Best Effort (the default) -- this is the normal behavior (and it's where excess traffic over one of the above quotas gets reassigned to). Even this upload traffic could be generously capped, but if that quota is exceeded, the traffic should not be treated at a lower priority. It should either be dropped or face overage charges or get a warning call or something else, as not all applications can be expected to work at less-than Best Effort treatment. Best-effort must remain the default baseline for Internet traffic.
•Less-than Best Effort (a scavenger class, only uses slack bandwidth) -- on a voluntary basis, some traffic can be purposefully put in a low-cost "background" priority so that it never interferes with someone's prime-time traffic needs. This is similar to using a low-priority CPU "nice" level. In exchange for using this low-priority queue, traffic in this class should not be subject to a quota or a cap.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon -- KJ7RL
... Do something! ... | |
| | | | | | | | | | DarkLogixTexan and ProudPremium
join:2008-10-23
Baytown, TX
kudos:3 | Re: Wouldn't it be cool if the upped the cap ya those were just some ideas
DSCP has 00-EF (256) possible settings so just 4 might be a bit small
but maybe divide the 256 into 4 genral catagorys
VoIP at the top (64kbps is good enough for one line
but this is a starting point not anywhere near the final standard
My first thought is to make 15 ranges (use the first hex digit to show which range and the 2nd to show which sub-sub catagory
so
the ranges could be
e, d, c, b (Expedited Forwarding ranges)(VoIP, Gaming, Synchro, Alarms, and internal ping conectivity test)
a, 9, 8, 7 (Assured Forwarding ranges)
6, 5, 4, 3 (Best Effort Ranges)
2, 1, 0 (Less-than Best Effort Ranges)
I agree with what you said but think all 255 possible DSCP bit combos should be thought of so that the top can be narrowed down to prevent being taken advantage of | |
| | | | | | | | | | funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | Re: Wouldn't it be cool if the upped the cap said by DarkLogix:I agree with what you said but think all 255 possible DSCP bit combos should be thought of so that the top can be narrowed down to prevent being taken advantage of We could go on forever.   We're painting the house before we've bought it, however. 
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon -- KJ7RL
... Do something! ... | |
| | | | | | | | | | DarkLogixTexan and ProudPremium
join:2008-10-23
Baytown, TX
kudos:3 | Re: Wouldn't it be cool if the upped the cap ya oh well It could be great but the ISPs will likely never do it
something I've heard more and more offten its it makes too much sense | |
|
| | | | | | | | | | Currently there are more issues with downstream port capacity than upstream.
Usually a market has a few returns to play with and implement virtual node splits. Downstream channels are usually much harder to come by... | |
| | | | | | | | | | funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | Re: Wouldn't it be cool if the upped the cap said by anon123 :
Currently there are more issues with downstream port capacity than upstream.
Usually a market has a few returns to play with and implement virtual node splits. Downstream channels are usually much harder to come by...
If that's the case (and surprising if it is), then congestion handling is still on the senders side of things. Hopefully Comcast isn't mucking with that too much in some unusual way.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon -- KJ7RL
... Do something! ... | |
|
| | | | | | | | espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2 Reviews:
·Vitelity VOIP
| said by funchords:said by espaeth:The ToS bits are reset to all 0's by default unless honoring DSCP values is explicitly configured on an interface. For example, on Cisco hardware unless you explicitly add "mls qos trust dscp" to an interface all packets will be remarked to 0's on ingress. "mls qos trust dscp" costs how much compared to all that intrusive proprietary sniffing hardware that can only guess at priority? Trusting DSCP values is a hack of a solution in that it will only benefit those who are savvy enough to upgrade their equipment to take advantage of it.
said by funchords:Totally practical, cheap, vetted and ready. The same thing has been said about IPv6 -- look how well we're doing with that migration.
History indicates the level of change you are proposing is unrealistic. In 2003, Netgear released 4 router models that effected a Denial of Service attack on the University of Wisconsin NTP servers. By late summer the firmware was patched to fix both the SNTP bug and the server selection, but there were 707,147 products distributed with this bug.
Firmware updates are cheap and easy to deploy, yet by the end of June 2006 (3+ years later) the University of Wisconsin's NTP server was still seeing 300k+ unique IPs from Netgear hardware per day.
Source:»pages.cs.wisc.edu/~plonka/netgear-sntp/
The solution you propose requires revision to EVERY SINGLE WORKSTATION CONFIGURATION attached to any provider's network. End-users aren't going to get that done -- and if I were bored I could stack this post with countless examples just from Internet examples alone. (case in point: how many SQL Slammer hits do you still get on your firewalls?)
There is a reason that every industry researcher (ie, Burton Group, Gartner Group) states that network-based traffic identification and tagging is the definitive best practice. End-station marking trials have failed in corporate environments where the entire environment starts out under control (standard server builds, standard workstation images) -- unless all software developers support the markings *AND* accurately represent their classification everything starts to fall apart. The only place in corporate environments where end-station marking every got any entrenchment is with IP phones, but only because the configurations of the phones are centrally managed and cannot be changed by the end user (and hence can be trusted to have accurate representation of priority into the network). That's actually one of a few reasons for having voice traffic on a separate VLAN in corporate environment: to be able to trust DSCP markings on the interface facing the phone while resetting and re-assigning markings to workstation traffic on ingress. | |
| | | | | | | | | | funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | Re: Wouldn't it be cool if the upped the cap This is bordering on the silly.
The solution you propose requires revision to EVERY SINGLE WORKSTATION CONFIGURATION attached to any provider's network.
...
unless all software developers support the markings *AND* accurately represent their classification everything starts to fall apart False.
If they're not upgraded, they do what they do today -- "best effort." That's "backward compatibility" and it's a pretty standard way of introducing a new capability into an existing system.
And if the preferred DSCP markings are limited by a quota, then who cares how I use mine? I can use it to make several hours of phone calls or 5 minutes of uploading before they're consumed. My choice. I'm in control. Nobody's business but mine. But here's the advantage to the network: If I do "abuse" my allocation, my ability to capitalize the network will be quickly gone. It's self-policing!
There is a reason that every industry researcher (ie, Burton Group, Gartner Group) states that network-based traffic identification and tagging is the definitive best practice. Up is not down and green is not blue.
Hardly all researchers say we need or expect or ought to have ISP doing automatic QoS on the open Internet. The FCC heard plenty of expert testimony explaining that such antics had no place. There are plenty of supporters within the population of Internet researchers and founders supporting Net Neutrality: a far greater number of informed researchers support NN than oppose it.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon -- KJ7RL
... Do something! ... | |
| | | | | | | | | | espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2 Reviews:
·Vitelity VOIP
| Re: Wouldn't it be cool if the upped the cap said by funchords:If they're not upgraded, they do what they do today -- "best effort." That's "backward compatibility" and it's a pretty standard way of introducing a new capability into an existing system. You're worried about light users being given automatic priority over that of heavy issues, but you don't see any issue at all if people are able to prioritize their traffic over the average user on the channel that won't have any kind of DSCP marking.
So I guess anyone who doesn't want to spend money to upgrade their machine from Windows98/Me and their broadband hardware to support DSCP value preservation through NAT can just suck it as long as your apps benefit?
said by funchords:And if the preferred DSCP markings are limited by a quota, then who cares how I use mine? I can use it to make several hours of phone calls or 5 minutes of uploading before they're consumed. My choice. I'm in control. Nobody's business but mine. But here's the advantage to the network: If I do "abuse" my allocation, my ability to capitalize the network will be quickly gone. It's self-policing! I think you're confused on how QoS works. You can do shaping by setting a ceiling, but that's not the typical approach in implementation. In a common QoS deployment you have "fall-through" between the queues -- so say you allocate 100kbps to an EF queue, if you exceed 100kbps you don't get cut off, your traffic simply falls down to the next lower priority queue. It's also important to note that if there is no queuing due to congestion then there is no differentiation in how the traffic is handled based on marking. If you "abuse" your allocation you don't see any downside whatsoever -- any traffic you stuff into that queue will get timeslot priority over the other suckers who are having everything marked into default.
said by funchords:Hardly all researchers say we need or expect or ought to have ISP doing automatic QoS on the open Internet. The FCC heard plenty of expert testimony explaining that such antics had no place. Interesting how none of that testimony came from people who have actually operated a network of reasonable scale or have any experience in real-world QoS implementations.
said by funchords:There are plenty of supporters within the population of Internet researchers and founders supporting Net Neutrality: a far greater number of informed researchers support NN than oppose it. Again, it's ironic that you would bring up Net Neutrality here because the QoS system you are proposing is the opposite of being traffic neutral. To be fully neutral you get what you get -- my DSL ISP (Embarq) does that, and let me tell you how freaking awesome that is.
»Whats Wrong With This Picture???
»Embarq should be Embarassed!
»Hickory NC ping problems
Clearly staying network neutral is great for the average customer. | |
| | | | | | | | | | funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:6 | Re: Wouldn't it be cool if the upped the cap As long as nobody gets too generous with the allocations, then yes, I'm fine with introducing DSCP in this manner even though some might not want to upgrade. They shouldn't find themselves impacted. But it can also be eased in to provide a transition time, I'm not sure it's necessary but I'll keep an open mind.
said by espaeth:Again, it's ironic that you would bring up Net Neutrality here because the QoS system you are proposing is the opposite of being traffic neutral. To be fully neutral you get what you get -- my DSL ISP (Embarq) does that, and let me tell you how freaking awesome that is. You're too smart to swallow that bilge. People who proclaim that NN prevents ISPs from following consumers end-to-end forwarding requests is a trick from politics -- far below what I expected from you.
There is nothing non-neutral or anti-NN about what I'm proposing. You seem to be fighting with me for the sake of fighting with me.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon -- KJ7RL
... Do something! ... | |
| | | | | | | | | | espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2 Reviews:
·Vitelity VOIP
| Re: Wouldn't it be cool if the upped the cap said by funchords:There is nothing non-neutral or anti-NN about what I'm proposing. You seem to be fighting with me for the sake of fighting with me. I'm just trying to keep up with the spin.
It's interesting to see that now differential treatment of traffic classifies as neutral. So if an ISP sets up a rule that gives priority to VoIP traffic that's bad, but if they setup DSCP and people mark their VoIP traffic into a higher queue that's good.
I don't see how anybody could possibly get lost in this logic. | |
| | | | | | | | | | DarkLogixTexan and ProudPremium
join:2008-10-23
Baytown, TX
kudos:3 | Re: Wouldn't it be cool if the upped the cap its neutral because if all carriers do it then no one carrier will have an unfair edge
an ISP gives "their" VoIP priority thats not but if the ISP allows al VoIP to have priority then thats neutral | |
|
| |
|
