Traffic management (should) only apply to Peer-2-Peer traffic (bittorrent) and Usenet NewsGroups traffic - both of these being identified by various little black boxes with flashing lights deep within the VM network infrastructure. To my knowledge, Netflix does not use any form of peer-to-peer traffic, so should not be subjected to any form of traffic shaping whatsoever, at least according to the published policies on these things.
Chances are that you're experiencing the same problems as many other fellow customers at the moment, that the VM network hubs in your area (where all the cable connections come together) are simply reaching their designed capacity (or have already exceeded it) and therefore everything suddenly slows down. In such cases, not only does traffic slow down (as we all have to take our turn) but the equipment gets overloaded and starts to simply drop 'packets' (as they are called) when they can't be processed. It is this 'packet loss' which really causes things to slow down.
Personally I've been monitoring packet loss of betwee 16-30% at peak times down here on the South Coast - which renders things almost unusable. I got faster connection speeds in the days of 56K modems (no joke!).
Traceroute is helpful for understanding where you packets go, but not for how well or quickly they get there. It is also unreliable
To get a better idea for yourself, take each hop (line) in your traceroute and note the IP address (eg 192.168.0.1). To each address in turn, use the ping (packet internet groper, in case you were interested!) command to check connectivity. On a windows box, obtain a command line (CMD) window, and type:
ping -n 50 a.b.c.d
where
'-n 50' tells it to ping 50 times (default is 4, not very helpful)
'a.b.c.d' is the IP address from each line of the traceroute.
Here's my example:
C:\Users\andrewb>ping -n 50 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=162ms TTL=51
... repeated 50 lines in total
Ping statistics for 8.8.8.8:
Packets: Sent = 50, Received = 33, Lost = 17 (34% loss),
Approximate round trip times in milli-seconds:
Minimum = 50ms, Maximum = 384ms, Average = 168ms
You are looking to see the 'Sent' and 'Received' being the same, with little variation betwen Minimum and Maximum round trip times. My example above, which is to the 'Google OPENDNS' service, is really BAD!
Go line by line, but remember that once the packet loss starts, it will affect all subsequent 'hops'. The hostname of the device on the line where trouble starts will give you a clue as to where the problem lies. In other words, if it includes 'network.virginmedia.net' then its within VM's network.
I hope this helps :-)
Andy
AndyBundy
-----------------
I don't work for VM. I do work for a large multi-national Telco and have spent fifteen years in WAN/LAN IP Networking, Network Management and IT Support.
