Cox clamping VPN traffic?

Tomas L. Byrnes tomb at byrneit.net
Sat Jan 26 07:02:15 UTC 2008


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 at merit.edu [mailto:owner-nanog at merit.edu] On 
> Behalf Of Justin M. Streiner
> Sent: Friday, January 25, 2008 10:32 PM
> To: nanog at 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
> 



More information about the NANOG mailing list