Pretty sure it's not a fragmentation or Black-Hole routing (MTU/MSS) issue, since the traffic ran fine for nearly 6 hours before being clamped, and then, after being quiescent for about 6 hours, ran fine until completion. An MTU/Fragmentation issue would show up much faster than that. I've troubleshot those, and they show up pretty much any time you try to do a large transfer, as a lost connection. Post complaining and opening a trouble ticket, and after a sheepish call from Cox engineering that dids't protest too much that they did no such thing, all is well. We changed nothing on any of the endpoints. Methinks someone accidentally applied a policy to ALL connections on a given CMTSS/Router, as opposed to just the residential ones. That's just conjecture, but my experience correlates with enough others to note that carriers are, stealthily, pushing out traffic shaping and rate limiting, sometimes with unintended consequences for non P2P services. Keep your eyes open, and let's keep all these carriers honest!
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Justin M. Streiner Sent: Friday, January 25, 2008 10:32 PM To: nanog@nanog.org Subject: RE: Cox clamping VPN traffic?
On Fri, 25 Jan 2008, Tomas L. Byrnes wrote:
The throttling I am talking about occurred on business class service which is rated at 16Mbps/2Mbps and is NOT cheap. I'd love to know what the throttling mechanism Comcast uses is, as Cox swears up and down that they have no such thing in place. That both got throttled to the EXACT SAME, non multiple of a DS0, is just a bit too coincidental for me.
If it was some sort of trunk capacity or mux issue, I would expect the BW I was left with to be a multiple of 64Kbps or 1.544 Mbps, not some odd-ball number like 43Kbps.
Could it be that the provider is silently inserting RSTs into live flows? This is not unheard of and would have the capability to send throughput into the toilet.
Before walking down that road, however, are you sure you're not dealing with an MTU/TCP-MSS/DF bit issue?
jms