On 8 Apr 2011, at 21:30, Mo McRoberts <[email protected]> wrote: > On Fri, Apr 8, 2011 at 12:13, Adrian Kennard <[email protected]> wrote: > >> Biggest issue is the likes of bit-torrents. They are lots of separate >> tcp sessions so normal "full link" behaviour tends to balance between >> tcp sessions not between customers. > > Pardon the dense question, but: Why? > > Customer A is sending a bunch of packets, customer B is sending a > bunch of packets; why bother to introspect at the tcp/ip layer at all? > >> Something more aware of per-customer >> traffic levels and management is likely to be fairer, or something >> specific to the types of traffic like this that are "unfair" somehow. > > Right, so if you do the traffic management in the core network (and > I'm guessing it is), you're not going to have a clue what your > customers are doing (at least not without an awful lot of nasty remote > interrogation going on); what if you do it at the edge? Don't the > DSLAMs know what their own port throughput is? And the switches > they're connected to? and so forth? > > [W]FQ isn't exactly new-tech, and sticking stuff in the core to > mitigate issues at the edge seems an awful lot like 'medicine' from > the middle ages. > > M.
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? 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. Or is the major slowdown in uk infrastructure happening at the edge with the core running underutilised? mike
