how-to block ads
|
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
 ·Verizon Online DSL
 ·Skype
3 edits |  SoHo QoS in the age of ISP Throttling
Both Comcast and AT&T seem to be indicating that they will start throttling connections under various congested conditions. (Edit for clarification: AT&T's plan is an actual throttle, Comcast's is a prioritization bias against heavier users of upload bandwidth.)
One of my concerns about this are applications and appliances that pre-configure themselves by doing a speed test when activated. When the available upload bandwidth drops, the upload bandwidth that such programs think they are holding in reserve remains the amount used in the QoS algorithms, but now the actual amount available is less.
For example, using a QoS engine by Ubicom, the DGL-4300 router does an upload speed test upon power up. Because the actual bandwidth ceiling may be throttled significantly lower than the ceiling determined during that speed test, the QoS features of the device may fail to adequately control lower-priority traffic.
What I don't have a sense for is how "big" of an impact this problem potentially is for. I don't have a VOIP hardware device myself. I do have the aforementioned router. I am also aware of a couple of other applications that choose video codecs based on detected bandwidth, and there are some apps that periodically retest during use.
So I'm posting this here to try and get a better idea of the size of this problem. VOIP users and providers and fans are the most likely to have a good handle on "the state of the state of the art" -- so please post your thoughts in reply.
Thanks
Robb Topolski
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
| |
christcorp
Premium
join:2001-05-21
Cheyenne, WY
 ·Bresnan Online
·VOIPo
| I don't think you'll really have a problem. I too use the Ubicom hardware QOS chip instead of firmware QOS. I use a Zyxel and a trendnet. Both use the ubicom. If you have any idea at how much your ISP might be throttling, you can simply unclick the AUTOMATIC bandwidth for upload and manually put in the amount they have throttled to. Another thing to consider is that most, if any, throttling an ISP does, is usually on the DOWNLOAD bandwidth. That's because of all the mega downloads such as streaming videa, mp3, files, etc... Very few people upload a lot. Those who do, usually have servers, and have other options. So I doubt you're going to see that throttling affects you.
And as far as throttling the download, well you have absolutely no control whatsoever over QOS on the download packets anyway, so it doesn't matter if they throttle or not. 1st packet in gets processed first because your router can not SEE INTO THE FUTURE and therefor has no idea if the next packet is voip, email, surfing, etc.... Therefor 1st in is 1st out. The best you can hope for is QOSing the outgoing packets. This will allow the person on the other end of the phone call to hear you fine. The incoming might still be a little choppy if you are downloading, streaming, etc... but you can control that by simply NOT DOWNLOADING/STREAMING while making a phone call. You can easily hit the pause button on any download. Also, QOSing the outgoing does have a SMALL affect on the incoming for regular surfing, because it will delay the ACKs that are being received. That will assist a little, but not on any streaming.
Either way, you should be fine if they throttle because it's probably not going to be affecting your UPLOAD. And that's all the QOS your router is doing anyway. And if you find they ARE throttling the upload, simply uncheck the auto block and manually put in a conservative amount of bandwidth to work with. I.e. if you normally have 896kb of upload and they are throttling the upload; go manual and put in 512kb. That would be safe. later... Mike.... | |
edmidor
6th Kyu
join:2008-05-19
Montreal, QC | reply to funchords
They must do some kind of packet introspection to throttle only P2P traffic. I don't think anything else is affected. | |
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
1 edit | reply to funchords
Thanks to the two that have already replied.
In both cases (Comcast and AT&T), the ISPs are currently indicating that throttling may be applied to uploads AND downloads. My interest applies only to the upload side.
With AT&T, the throttling will be applied to traffic of all types (not just "P2P"). Comcast is similarly calling their plan "protocol agnostic" but they also purport to be trying to avoid impacting "real-time" traffic (such as VOIP).
Using the method described by AT&T, users will know the minimum expected upload speed (the speed if throttled).
Comcast has characterized their minimum expectation less clearly, calling it similar to "really good DSL". (We should be getting an update to these plans pretty soon now, which is one reason I'm trying to get a feel for this now.)
Thanks for the inputs so far -- keep it coming...
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
| |
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
3 edits | reply to funchords
said by funchords  :One of my concerns about this are applications and appliances that pre-configure themselves by doing a speed test when activated. When the available upload bandwidth drops, the upload bandwidth that such programs think they are holding in reserve remains the amount used in the QoS algorithms, but now the actual amount available is less. That's the same thing as setting the cruise control in your car based on the posted speed limit, and not dealing with the actual traffic conditions.
The bottom line is that regardless of what ISP you use, end-user QoS is only effective when the point of congestion is at your broadband termination device. For anything upstream you have no deterministic way to effect any kind of meaningful edge-QoS strategy. Most VoIP solutions as they are implemented right now have no stream quality signaling; it's a blind flood of RTP packets with the assumption that everything is received at the destination properly. In theory, it's possible that SIP could be extended to signal back periodic mean opinion score data on the received RTP stream so that the sender can take appropriate traffic control actions. This would either require the use of an integrated ATA/Router, or a smart router that can decypher the SIP notification and make QoS / outbound throttle changes accordingly.
The obvious problem with this type of solution is if the problem is way outside of your control, say peering congestion between Carrier A and Carrier B in your network path, the net effect could be that your other traffic could be throttled into the ground trying to improve the delivery quality of an RTP stream that you have absolutely no possible chance of improving.
said by funchords :In both cases (Comcast and AT&T), the ISPs are currently indicating that throttling may be applied to uploads AND downloads. My interest applies only to the upload side. With AT&T, the throttling will be applied to traffic of all types (not just "P2P"). Comcast is similarly calling their plan "protocol agnostic" but they also purport to be trying to avoid impacting "real-time" traffic (such as VOIP). Comcast has characterized their minimum expectation less clearly, calling it similar to "really good DSL". (We should be getting an update to these plans pretty soon now, which is one reason I'm trying to get a feel for this now.) After months of being beaten into submission Comcast is finally publishing details about their network management goals and practices here: »www.comcast.net/networkmanagement/
In particular, there's a slide deck that gives an overview of their new QoS (*not* throttling) approach that Robb is referring to here: »downloads.comcast.net/docs/Comca···0528.pdf
If you read through the slide deck they call out one of their motivations for implementing these systems is to try and address complaints from VSPs like Vonage that their subscribers were having troubles with Comcast. Based on the posts I've read in the VoIP forums here over the last few years, I believe that argument is at least plausible.
Comcast's approach is to place the traffic of all of their customers in a priority DOCSIS queue initially. When the cable DOCSIS channel reaches points of saturation, the top talkers on the network will be singled out and their traffic will be remarked as best effort. The effect is that the traffic of the average light user will be given packet delivery priority over that of heavier users of the network.
That gets down to the fundamental understanding of what QoS is; it's not some magical holy grail of networking that makes everything work perfectly. If you want to give priority to something, you need to negatively impact something else. Using a rough application of the 80/20 rule, we're talking about giving the 80% of users who are generating 20% of the traffic a slight edge over the 20% of users who consume the other 80% of capacity. The traffic of heavy users is not strictly rate limited, and will only be slight-to-moderately impacted by the demands of the light users on the channel.
The light users get first shot at channel capacity, the TCP flows of heavy users balance out on all remaining capacity in the best effort queue.
It's a utilitarian approach to get the best performance to the largest number of people possible, but ultimately there are going to be folks who will not get everything they want out of the system. And that, my friend, is just a fact of life on any shared service. | |
christcorp
Premium
join:2001-05-21
Cheyenne, WY
·Bresnan Online
·VOIPo
| reply to funchords
It's not necessarily true that Voip is a BLIND FLOOD of packets. Remember, Voip doesn't use TCP for their traffic. Voip uses UDP. 1)TCP resends packets if there's errors. With voip, that is useless because of the "Real Time" factor requirement. 2)UDP has much less overhead, and it therefor allows for better latency time for voip packets. So, while the UDP and TCP are on the same highway of bandwidth, UDP isn't following exactly the same as TCP and your surfing/email traffic. | |
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN | The retransmission for RTP happens at Layer7. We can all thank the cellular phone industry for introducing "Can you repeat that? You cut out for a second there." into the public vernacular. | |
edmidor
6th Kyu
join:2008-05-19
Montreal, QC
| reply to funchords
said by funchords :With AT&T, the throttling will be applied to traffic of all types (not just "P2P"). Comcast is similarly calling their plan "protocol agnostic" but they also purport to be trying to avoid impacting "real-time" traffic (such as VOIP). I apologize for my slowness, but here in wild white north we used to hear that the very purpose of throttling is to limit P2P traffic that eats 90% of the available bandwidth. What’s the point to throttle ALL traffic? It doesn’t make sense – it’s simpler to officially reduce max speed for users… What am I missing? | |
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
| Again -- the question I am asking is very specific.
I don't want to argue the pros or cons of throttling or the best vs. worst way to throttle.
With two large ISPs affecting available bandwith in a way differently than before, what QoS-type products will be affected and in what ways?
People are using QoS products to ensure delay-sensitive communications (VOIP and gaming, for example) get through their home network and on to the Internet before non-sensitive traffic. These devices do a calculation, based partly on automatically or manually configured uplink speed for the connection. That calculation probably presumes some normal congestion effects, but their method probably doesn't presume throttling.
If the risk is high that throttling will affect VOIP and gaming communications on a large scale, then the providers and product vendors and their customers are going to need to figure out what to do so that things continue to work well for them.
That's why I'm starting this conversation, and it starts with figuring out who is affected and how bad it might be.
Thanks
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
| |
B
Premium,MVM
join:2000-10-28
| And isn't that calculation already adversely affected in its accuracy by stuff like PowerBoost that temporarily implies a much larger pipe than is actually available in a sustained fashion?
Not answering you, just chiming in. 
-- B
--
In a realm outside causality and function | |
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
| said by B :And isn't that calculation already adversely affected in its accuracy by stuff like PowerBoost that temporarily implies a much larger pipe than is actually available in a sustained fashion? Yes -- this is a good example. Thank you!
This thread explains how Powerboost causes Apple's iChat AV to think the link has more bandwidth than it actually does, and so the program chose the video settings based on the short-term PowerBoost speed and not the eventual speed that could be maintain when PowerBoost ended.
Robb
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
| |
B
Premium,MVM
join:2000-10-28
| I believe you, but I read through that thread and didn't see an explanation that matches yours. They were mostly complaining about ComCast blaming Apple, but no specific identification of iChat as doing the pre-test you describe.
I hate to say it, but I wonder whether the onus in this case is on the application developers to stop trying to be so darned clever about gauging available bandwidth. I mean, yeah, going from a perceived 20 Mbps to an actual 3 Mbps is quite a leap, but if they just optimized for broadband, period (let's say, 2 Mbps to 100 Mbps, not a huge range) instead of hogging that perceived pipe, we'd be better off. After all, a quiet pipe can be congested very quickly, and then where does that hoggy application go?
The alternative, of course, is to rework things on the fly as available bandwidth changes. That's what I thought all modern apps were already doing.
-- B
--
In a realm outside causality and function | |
-
|
