In a nutshell, I think you're right about comcast throttling, but not for the reasons you describe.
Warning: I breathe this stuff, so this is kinda technical. But so are you, so I think you'll follow.
The way traceroute works is to send packets with increasing TTL's. The TTL is measured in hops, and is there to prevent infinite loops: Every time a packet goes through a router, the TTL is decremented. The IP protocol specifies that when a router decrements a packet's TTL to zero, it sends a "TTL Exceeded" ICMP packet back to the source, which exposes the IP of the router. Traceroute uses (abuses...) this by first sending out a packet with a TTL of 1, causing the first router to send the error back, then with a TTL of two, causing the second router to send the error back, etc. This is how traceroute actually gets the IP addresses of the intermediate routers. Each listed time in the traceroute output represents a separate packet sent and error received, and each '*' represents a separate packet sent and no error received back at all. Traceroute sends three per TTL, and the TTL is listed as the first number of each row on the left.
Other than the first hop, there's zero difference between wifi and ethernet. They're both "frames" for IP (in this case, protocols 802.1 and 802.11), and they're completely stripped by the gateway and replaced with new frames, of whatever link-level protocol is being used between it and the next hop), when it passes the packet to the next router. Only IP packets get transferred unmolested, and as I mentioned even the TTL headers get changed in transit (and hence the IP header checksums, used for error-catching).
So, essentially, DNS can't screw up like this. You can see that all but 3 IP addresses were successfully looked up by checking the last column of the output and noticing that only three of them weren't resolved to names -- most likely because they don't have a reverse mapping in DNS, by design (as in, not an error condition). But, other than displaying the names for you to see, DNS isn't even involved in the traceroute process.
All that aside, the one thing that *is* different between wireless and wired is, well, the wire. If there are transmission issues with wireless, due to low power or inconsistent connection or whatever, that could cause traffic timing to be a bit different. That kind of "jitter" might cause comcast to throttle the packets that came in with that peculiar timing, but not ones that came in via the (very consistent) wired network. I've often found that plugging in my laptop (and therefore increasing the wireless card's power) or moving closer to the access point, increasing the wireless card's connection stability, has solved this problem.
Warning: I breathe this stuff, so this is kinda technical. But so are you, so I think you'll follow.
The way traceroute works is to send packets with increasing TTL's. The TTL is measured in hops, and is there to prevent infinite loops: Every time a packet goes through a router, the TTL is decremented. The IP protocol specifies that when a router decrements a packet's TTL to zero, it sends a "TTL Exceeded" ICMP packet back to the source, which exposes the IP of the router. Traceroute uses (abuses...) this by first sending out a packet with a TTL of 1, causing the first router to send the error back, then with a TTL of two, causing the second router to send the error back, etc. This is how traceroute actually gets the IP addresses of the intermediate routers. Each listed time in the traceroute output represents a separate packet sent and error received, and each '*' represents a separate packet sent and no error received back at all. Traceroute sends three per TTL, and the TTL is listed as the first number of each row on the left.
Other than the first hop, there's zero difference between wifi and ethernet. They're both "frames" for IP (in this case, protocols 802.1 and 802.11), and they're completely stripped by the gateway and replaced with new frames, of whatever link-level protocol is being used between it and the next hop), when it passes the packet to the next router. Only IP packets get transferred unmolested, and as I mentioned even the TTL headers get changed in transit (and hence the IP header checksums, used for error-catching).
So, essentially, DNS can't screw up like this. You can see that all but 3 IP addresses were successfully looked up by checking the last column of the output and noticing that only three of them weren't resolved to names -- most likely because they don't have a reverse mapping in DNS, by design (as in, not an error condition). But, other than displaying the names for you to see, DNS isn't even involved in the traceroute process.
All that aside, the one thing that *is* different between wireless and wired is, well, the wire. If there are transmission issues with wireless, due to low power or inconsistent connection or whatever, that could cause traffic timing to be a bit different. That kind of "jitter" might cause comcast to throttle the packets that came in with that peculiar timing, but not ones that came in via the (very consistent) wired network. I've often found that plugging in my laptop (and therefore increasing the wireless card's power) or moving closer to the access point, increasing the wireless card's connection stability, has solved this problem.
Reply
Reply
Leave a comment