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


Reply via email to