Re: [uknof] Consumer broadband packet scheduling
Is the main purpose of traffic shaping not to relieve congestion in the core/backhaul. To do this in the dslam would require it to know about packet drop some way upstream from it. If the dslam is overcontended then it would make sense to control traffic there but which is the greater problem? fair point — but by the same token it doesn't follow necessarily to move all of the traffic management into the core if backhaul is a problem, to my uneducated eyes… depends where exactly the congestion's occurring, as you say, especially if that means you're then reliant on slightly “interesting” mechanisms in order to achieve it. Identify the congested links and identify the traffic type then either apply queuing downstream of it (in the case of p2p) or utilise cdn to move popular content closer to the eyeballs. why “in the case of p2p”? what if a bunch of people are doing whacking great HTTP or RTSP transfers that's causing overcontention? CDN only helps in some scenarios, and has some “interesting” economic angles. consider... customer A has a P2P session (e.g., Spotify, or a multiplayer game) consuming a modest amount of bandwidth. customer B has an RTSP stream pulling a couple of megabits a second. in times of contention, which one would get penalised? Or is the major slowdown in uk infrastructure happening at the edge with the core running underutilised? AIUI (and if anyone's got information to the contrary, I'd be glad to hear it — this is a fishing expedition…), more-or-less… the edge is harder/more expensive to beef up. M.
Re: [uknof] Consumer broadband packet scheduling
On 8 Apr 2011, at 22:28, Mo McRoberts m...@nevali.net wrote: Is the main purpose of traffic shaping not to relieve congestion in the core/backhaul. To do this in the dslam would require it to know about packet drop some way upstream from it. If the dslam is overcontended then it would make sense to control traffic there but which is the greater problem? fair point — but by the same token it doesn't follow necessarily to move all of the traffic management into the core if backhaul is a problem, to my uneducated eyes… depends where exactly the congestion's occurring, as you say, especially if that means you're then reliant on slightly “interesting” mechanisms in order to achieve it. Identify the congested links and identify the traffic type then either apply queuing downstream of it (in the case of p2p) or utilise cdn to move popular content closer to the eyeballs. why “in the case of p2p”? what if a bunch of people are doing whacking great HTTP or RTSP transfers that's causing overcontention? CDN only helps in some scenarios, and has some “interesting” economic angles. consider... customer A has a P2P session (e.g., Spotify, or a multiplayer game) consuming a modest amount of bandwidth. customer B has an RTSP stream pulling a couple of megabits a second. in times of contention, which one would get penalised? M. I suppose one of the problems that p2p (be it bittorrent or VOIP) causes is that it tends to fill the upstream as well as the downstream pipe as opposed to the customer with a large http stream where only acks are being sent back. I suspect that when the BB infrastructure was being provisioned then it was assumed that almost all data would be flowing towards eyeballs and little would be coming back. This probably explains the vast majority of home offerings having much smaller upstream speeds even when it isn't dictated by the technology eg FTTP I also suspect that the methods of determining customer flows are so significant in terms of hardware requirements that it is easier to do it on a well specified core router/switch and therefore also easier to manage than placing the necessary intelligence to gather the information at the edge and transmitting it to the noc then sending back the necessary changes to the edge in real time. mike
