NNSquad - Network Neutrality Squad

NNSquad Home Page

NNSquad Mailing List Information

 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ NNSquad ] Re: U. of Colorado: Comcast now resetting wide range of TCP traffic


On Sun, Apr 06, 2008 at 06:15:29PM -0700, Lauren Weinstein wrote:
> First-hand reports or other additional info on this are welcome.  

There has been discussion over the weekend which may be related to this
on NANOG, Dave Farber's IP list and the Internet Storm Center's blog.

On NANOG, Steve Bellovin (who I believe is in the NY/NJ area) reported TCP
issues starting Saturday morning from his home connection.  Ted Fischer
reported similar issues from NJ.  Michael Sinatra reported issues from
San Francisco but noted that they seemed corrected.

Steve's blog entry on this is here:

	http://www.cs.columbia.edu/~smb/blog/2008-04/2008-04-06.html

On the IP list, Mark Laubach and Ronald Riley reported problems in
California and Michigan.  There's also been a statement published from
a Comcast person that claims there was a PA/NJ routing issue.  That
statement does not address differential treatment of UDP and TCP traffic.
(I see that Steve has noted in his blog that he's asked that very
question of the Comcast person and awaits an answer.)

The ISC has been coy about details, but I know they have at least
one report about Comcast issues in Maryland, because I filed it while
attempting to figure out why my relatives' connection had gone wonky.
My observation was that traceroutes into Comcast succeeded with UDP, but
stalled with TCP.  Both followed the same path, so I don't think anything
tricky was being done with UDP vs. TCP routing.  Those relatives were
unable to connect to a non-Comcast mail server with POP or SMTP and had
intermittent issues with a number of web sites.  Here's an example
of UDP vs. TCP traceroutes; for those unfamilar with local geography,
"Towson" and "White Marsh" are Baltimore suburbs.

	With UDP:

	 [...]
	 4  bnap.coretel.net (198.32.188.20)
	 5  323n-200e.coretel.net (209.163.107.46)
	 6  g4-0-0-304-phla-snd-rtr01-c7507.coretel.net (69.72.1.181)
	 7  ge2-7.br01.phl02.pccwbtn.net (63.218.31.25)
	 8  68.86.89.53 (68.86.89.53)
	 9  te-8-1-ar02.capitolhghts.md.bad.comcast.net (68.86.90.86)
	10  po-10-ar01.whitemarsh.md.bad.comcast.net (68.87.129.138)
	11  po-90-ar02.whitemarsh.md.bad.comcast.net (68.86.252.218)
	12  68.85.175.30 (68.85.175.30)
	13  te-9-2-ur02.newtowson.md.bad.comcast.net (68.87.129.134)
	14  ge-6-2-ur01.newtowson.md.bad.comcast.net (68.86.252.5)
	 [...]

	That traceroute completed successfully.   But with TCP:

	 [...]
	 4  bnap.coretel.net (198.32.188.20)
	 5  323n-200e.coretel.net (209.163.107.46)
	 6  g4-0-0-304-phla-snd-rtr01-c7507.coretel.net (69.72.1.181)
	 7  ge2-7.br01.phl02.pccwbtn.net (63.218.31.25)
	 8  68.86.89.53  33.809 ms  33.658 ms  33.686 ms
	 9  * * *
	10  * * *

---Rsk