Skip to main content

View Diary: The Internet is already not net neutral (61 comments)

Comment Preferences

  •  I think that you have misunderstood the timings (8+ / 0-)

    traceroute tries each hop three times and reports the roundtrip time for each try. It only tried the final destination once and the total round trip time was 49.597 ms.

    •  True tracert timings r measures of node latency... (0+ / 0-)

      Evidence that contradicts the ruling belief system is held to extraordinary standards, while evidence that entrenches it is uncritically accepted. -Carl Sagan

      by RF on Sat May 17, 2014 at 06:06:30 AM PDT

      [ Parent ]

    •  There are a couple issues with the traceroutes... (0+ / 0-)

      First, like you said, the time is at each hop. The total time is 49.597ms (round-trip)...not all the hops added up, which would be something like 300ms. That should probably be corrected, since even the US west coast to Australia is only 150ms round-trip.

      In that example, the traffic is also going somewhat far: DC to Atlanta to Dallas to Houston. (Hop 12, which claims to be at the Westin building at 2001 6th Ave in Seattle, a large peering point, is actually mislabeled: you can tell from the latency that it's also in Houston.) Comcast's network is pretty slow at getting from DC to Houston, but that's because they're using crappy fiber paths, not because they're purposefully slowing each hop down in this case. (I have seen traceroutes/mtrs where Comcast is overloaded at a peering point, which they ARE doing on purpose lately. Very different situation, though.)

      The second traceroute stops before it actually gets to the end. "g1-5-3-0.washdc-lcr-21.verizon-gni.net" is not Google. It's a Gigabit Ethernet interface on a Verizon router. (By naming convention, probably slot 1/5, port 3, with no vlan, thus "-0".) If I traceroute it from elsewhere to confirm, it goes to Verizon's network, not Google's. Were there extra filtered hops past that, or something? (The "* * *"ed ones.)

      It's certainly possible for Google to have a server 3 or 4 hops away from you, depending on where you are and where they peer. (The number of hops isn't that much important though; more hops tends to be slower, but not always.) The central point is correct of course: if you have money, you can pay for your content to be on a CDN and close to lots of users.

      This is a good diary, but it would be nice to see the technical details fixed up. :)

      •  Here's Comcast purposefully overloading peers: (2+ / 0-)
        Recommended by:
        catilinus, Gay CA Democrat

        I saved this one the other day to go with my other FCC complaint material. This is from my home connection to a random server in Europe I was trying to get to. But this is an example of REAL slowness in Comcast's network, on purpose, not just because a server is far away.

        Here's a Level3 blog post (really worth a read.) They don't name Comcast outright, but "Congestion that is permanent, has been in place for well over a year and where our peer refuses to augment capacity. Five of those congested peers are in the United States and one is in Europe. There are none in any other part of the world. All six are large Broadband consumer networks with a dominant or exclusive market share in their local market."

        You can see the % of lost packets go up from 0% to 15% when it goes from hop 6 to hop 7. That is because Comcast seems to be purposefully overloading their peering connections with Level3 and other providers.

        A "normal" % of packets being dropped is < 0.1% or so (some providers will claim 0.5% is okay.) Past 1 or 2%, you'll start seeing significant slowness, because packets have to be resent. More than 5% starts becoming unusable.

        6. he-2-5-0-0-cr01.newyork.ny.ibone.comcast.net        0.0%    79   18.8  19.5  15.7  27.5   2.5
         7. ae12.edge1.NewYork2.level3.net          16.5%    79   50.9  37.8  33.1  90.4   8.7
         8. vlan51.ebr1.NewYork2.Level3.net          15.4%    79  119.2 120.8 118.0 129.0   1.8
         9. ae-46-46.ebr1.NewYork1.Level3.net          15.4%    78  124.0 121.9 119.2 129.6   2.4
        A different view of the same thing. The "?" means a dropped packet, the ">" means a packet with high latency (compared to other packets.)

        This is a time-based view, with one column per second: the left column is about a minute ago, the right column is the most recent test.

        6. he-2-5-0-0-cr01.newyork.ny.ibone.comcast.net         ..........................................................
         7. ae12.edge1.NewYork2.level3.net         ..??..???.????....??.??...................................
         8. vlan51.ebr1.NewYork2.Level3.net         ?....>??.>...??????.???..................>..>...>>.......>
         9. ae-46-46.ebr1.NewYork1.Level3.net         ?.?.?.?.??>??.?...??.?>.>>>>...........>....>.>.......>...
        10. ae-42-42.ebr2.London1.Level3.net          >?.?>......?...>?.?.?.........>..>.>................>.....
        11. vlan101.ebr1.London1.Level3.net         ??.?>???.?.?..?.??.???..>>........>>..>..>......>...>.>>..
        (Some technical detail left out; it's not just icmp being dropped here.)
      •  I'm at the internet hub (0+ / 0-)

        Near Herndon, Virginia. We have hosting centers all over the place. I'm not surprised Google is three hops away.

        Thanks for the more detailed explanation of traceroute. I do software development, not network engineering, so my knowledge is not perfect.

        Many an insightful opinion and observation can be found on my blog Occam's Razor. UID: 875

        by Guy Noir on Sat May 17, 2014 at 06:06:58 PM PDT

        [ Parent ]

Subscribe or Donate to support Daily Kos.

Click here for the mobile view of the site