On 08/04/2011 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? Read Stevens (and some Van Jacobson too!) :) - TCP is designed to hoover as much bandwidth as you've got and with the right window sizes it does it very well indeed. RED (and WRED) were very good at dealing with this in the past for simple TCP flow management but had a couple of issues that, atleast in my view, were manageable. But that was in the day of much more insane amounts of buffer management. For most folks these days the buffers in modern kit are so extreme this is something you never need to worry about and the reason for packet scheduling is about user experience and (backhaul) costs. >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? A vs B is never a useful discussion. Customer Type A is 90% of the world, who just do email, web and facebook, customer type B is the other 10% who do a lot of P2P, customer type B with a few dozen TCP sessions can use all the bandwidth to the point that customer type A gets really poor responsiveness. DPI lets you control this directionally, although its still slightly a blunt instrument in my view. >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. Nobody sensible wants to do any sort of traffic mangling at the core, it really breaks stuff and makes it hard to select and make sensible choices - the goal is not to let traffic you can't manage in at the point of entry but with the volume of PPP around in operators networks, particularly in the access space, operators tend to do traffic management at the distribution point or the point of handover. Depending on your customers requirement DPI can be useful here. Large parts of operators networks are not within their control, particularly in the access space and putting in DSLAMs with the intelligence to manage traffic is a very expensive thing to do when you are in the space of selling access at £5 a month. And even if you wanted to do that now I don't think you can even buy these sort of DSLAMs any more such is the drive for cheap access kit.
