> This reverse traceroute is still helpful. The paths will be roughly the same, likely differing only in terms of which specific routers see your packet.
This is categorically incorrect. While the AS path is often the same, the actual peering points are almost always quite different. Most ASes use hot-potato routing - getting packets to the next AS at the closest peering point to the source of the traffic. (And even if cold-potato routing is used, that's still asymmetric). In addition if there are two options with the same AS-path-length hot-potato routing can lead to different AS paths. This can happen if there's two mutual transit providers between source and destination and various other situations.
FYI what you described is hot-potato routing: each AS gets rid of it as soon as possible.
You may think this is unfair, and yes, it is, but it's also quite logical when you consider you don't know where the packet is going in the destination AS. If you have a network spanning Berlin and Hamburg and the packet is going to a different network that also spans Berlin and Hamburg, and you interconnect at both points, and you don't know which city it's actually going to, handing it off at the closest interconnect doesn't risk round-tripping it for no good reason.
I'm interested in your definition of fairness that makes hot potato routing unfair.
In my mind, hot potato is fair, every packet gets treated the same, and (mostly) every provider does the same thing.
> it's also quite logical when you consider you don't know where the packet is going in the destination AS. If you have a network spanning Berlin and Hamburg and the packet is going to a different network that also spans Berlin and Hamburg, and you interconnect at both points, and you don't know which city it's actually going to, handing it off at the closest interconnect doesn't risk round-tripping it for no good reason.
There are ways to help with this, BGP MED (multi-exit discriminator) or path extention can help guide towards the best place to deliver traffic. But especially for last mile traffic, you do want it on the destination network sooner than later; if traffic is genetated in Berlin, and the ultimate destination is Hannover and the Hannover endpoint is connected to both Berlin and Hamburg on the destination network, delivering at Berlin provides a better experience than delivering to Hamburg, even though Hamburg is closer to Hannover, because the transit to Hamburg was unnecessary. And if the destination is only connected to Hamburg, delivering in Berlin works about the same as delivering in Hamburg (depending on capacity and use from Berlin to Hamburg on both networks).
There's certainly situations where having options would be nice, but having options makes things complex, so typical users can't really influence routing. If you have v4 and v6, you may find that routing differs between the two and that does give you a bit of a choice.
The unfairness of hot potato routing is that it aggressively tries to offload as much cost onto other companies as possible. It may be how business works but it's not really an ideal way to build a system.
Anecdotally, I've run a bunch of traceroutes and reverse traceroutes to different locations and they tend to follow the same AS paths — although sometimes the traceroute will surface more routing through your ISP (especially from college networks). In general you are correct, though, and I would love to explain more about hot-potato vs. cold-potato (and other interesting routing decisions) in the future. Either way, the results the reverse traceroute provides are good enough for the purposes of explaining the internet, IMO!
> "You may have noticed that the traceroute progressively loads in lines above the bottom line. Web pages can only load forward. Since I didn’t want to use any JavaScript, I did the hackiest thing possible: every time I update the traceroute display, I embed a CSS block that hides the previous iteration! Since browsers render CSS as the page is loading, this made it look like the traceroute was being edited over time."
> Seems like this hit the Hacker News front page again, and the server's having some trouble pinging all of you. Feel free to read the article, but if you want to see your tracereoute you might need to bookmark and check back tomorrow :)
> This isn’t actually a “time” as implied by a name — it’s a countdown! Every time a router forwards an ICMP packet along, it’s supposed to decrement the TTL number.
No, it's actually a time, it's just that it has a precision of 1 second.
RFC 791: "The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist."
It's like when your uncle squeezes you at Christmas. You're glad to see him again, but it's just a liiiitttleee... too... much... for... your... lungssss,.,.,.,
Hmm, after several seconds it gave up and displayed raw markup ... I'm not sure exactly why in this case, but ...
One of the major infelicities of the web is that CSS is specified to ignore truncation, and there is no way to fix this. Now think about what happens if something like `display: inline-block` gets truncated before the `-`.
I have old components on my personal site that used to do a similar trick for streaming data without JavaScript but between nginx buffering and cloudflare I have not been able to sort out getting it to actually work these days. Worked fine on Apache in 2005 lol
> This reverse traceroute is still helpful. The paths will be roughly the same, likely differing only in terms of which specific routers see your packet.
This is categorically incorrect. While the AS path is often the same, the actual peering points are almost always quite different. Most ASes use hot-potato routing - getting packets to the next AS at the closest peering point to the source of the traffic. (And even if cold-potato routing is used, that's still asymmetric). In addition if there are two options with the same AS-path-length hot-potato routing can lead to different AS paths. This can happen if there's two mutual transit providers between source and destination and various other situations.
(EDIT: fixed hot/cold mixup)
FYI what you described is hot-potato routing: each AS gets rid of it as soon as possible.
You may think this is unfair, and yes, it is, but it's also quite logical when you consider you don't know where the packet is going in the destination AS. If you have a network spanning Berlin and Hamburg and the packet is going to a different network that also spans Berlin and Hamburg, and you interconnect at both points, and you don't know which city it's actually going to, handing it off at the closest interconnect doesn't risk round-tripping it for no good reason.
> You may think this is unfair, and yes, it is
I'm interested in your definition of fairness that makes hot potato routing unfair.
In my mind, hot potato is fair, every packet gets treated the same, and (mostly) every provider does the same thing.
> it's also quite logical when you consider you don't know where the packet is going in the destination AS. If you have a network spanning Berlin and Hamburg and the packet is going to a different network that also spans Berlin and Hamburg, and you interconnect at both points, and you don't know which city it's actually going to, handing it off at the closest interconnect doesn't risk round-tripping it for no good reason.
There are ways to help with this, BGP MED (multi-exit discriminator) or path extention can help guide towards the best place to deliver traffic. But especially for last mile traffic, you do want it on the destination network sooner than later; if traffic is genetated in Berlin, and the ultimate destination is Hannover and the Hannover endpoint is connected to both Berlin and Hamburg on the destination network, delivering at Berlin provides a better experience than delivering to Hamburg, even though Hamburg is closer to Hannover, because the transit to Hamburg was unnecessary. And if the destination is only connected to Hamburg, delivering in Berlin works about the same as delivering in Hamburg (depending on capacity and use from Berlin to Hamburg on both networks).
There's certainly situations where having options would be nice, but having options makes things complex, so typical users can't really influence routing. If you have v4 and v6, you may find that routing differs between the two and that does give you a bit of a choice.
The unfairness of hot potato routing is that it aggressively tries to offload as much cost onto other companies as possible. It may be how business works but it's not really an ideal way to build a system.
ha yes thank you. I worked for a AS that mostly did cold-potato routing so grabbed the wrong term trying to describe the common case.
Anecdotally, I've run a bunch of traceroutes and reverse traceroutes to different locations and they tend to follow the same AS paths — although sometimes the traceroute will surface more routing through your ISP (especially from college networks). In general you are correct, though, and I would love to explain more about hot-potato vs. cold-potato (and other interesting routing decisions) in the future. Either way, the results the reverse traceroute provides are good enough for the purposes of explaining the internet, IMO!
I did a traceroute to how-did-i-get-here.net, and it went through a completely different network to the one they reported for the reverse.
Yup. Those paths are cached bidirectional.
> "You may have noticed that the traceroute progressively loads in lines above the bottom line. Web pages can only load forward. Since I didn’t want to use any JavaScript, I did the hackiest thing possible: every time I update the traceroute display, I embed a CSS block that hides the previous iteration! Since browsers render CSS as the page is loading, this made it look like the traceroute was being edited over time."
Love this
You can also do out-of-order HTML streaming without JavaScript using declarative shadow DOM. For example:
https://lamplightdev.com/blog/2024/01/10/streaming-html-out-...
oh yeah i saw this! newer than the website though :)
This is not my beautiful website.
This is not my beautiful home-page.
There are packets at the bottom of the network stack
And you may find yourself
Behind the keyboard of a large PC
And you may find your site in beautiful cloud, with a beautiful bounce rate.
And you may ask yourself
Well, how did ip route here?
Letting the bytes go by
Modulated signals flow
Typing in code you don’t understand
And if you haven't ever seen it before, run
and alsoNice! Dr. Horrible would be proud of this geeky tribute:
also
noice, got rick rolled
also
also
ssh watch.ascii.theater
> Seems like this hit the Hacker News front page again, and the server's having some trouble pinging all of you. Feel free to read the article, but if you want to see your tracereoute you might need to bookmark and check back tomorrow :)
> - Lexi, Nov 7, 3:16 PM PST
somewhat better now! added a bit more concurrency. lesson learned: use tokio next time
> This isn’t actually a “time” as implied by a name — it’s a countdown! Every time a router forwards an ICMP packet along, it’s supposed to decrement the TTL number.
No, it's actually a time, it's just that it has a precision of 1 second.
RFC 791: "The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist."
I thought this was going to play a Talking Heads song
letting the days go by
check the html :)
Nice!
Previous Show HN: from the dev in 2023:
https://news.ycombinator.com/item?id=38531604
I tried it out, and found out that my primary internet connection had failed, and I was on the backup due to a power outage earlier today. Useful!
The route less travelled.
Also, see:
Traceroute isn't real, or: Whoops! Everyone Was Wrong Forever: https://gekk.info/articles/traceroute.htm
Doesn't work. Traceroute showed only 1 hop.
Mine too. Maybe it's CGNAT.
Read the green text
Sometimes my 'You are here' top part reads,
And other times it reads, What's going on here? I found the provider but what's with the 50/50 swap? It seems to randomly alternate between the two.The text bellow the traceroute was wonderful to read. The tone of voice was very pleasant. Thank you for making this joyous educational website~
Doesn't seem to be working?
HN Hug of death ?
It's like when your uncle squeezes you at Christmas. You're glad to see him again, but it's just a liiiitttleee... too... much... for... your... lungssss,.,.,.,
The page started out working without JavaScript as it says, but then the replacement HTML was encoded as text:
(Edit: filed https://github.com/hackclub/how-did-i-get-here/pull/3.)I can't help it. The Once in a Lifetime link is tattooed on my brainstem.
I read this title and that opening bass line just starts flowing.
I instantly started having an existential crisis.
I thought this was going to be a review of life choices
The review of life choices happens in our heads when we click this link on the main HN page.
(sigh) I'm just thinking those thoughts right now.
Same as it ever was.
Hmm, after several seconds it gave up and displayed raw markup ... I'm not sure exactly why in this case, but ...
One of the major infelicities of the web is that CSS is specified to ignore truncation, and there is no way to fix this. Now think about what happens if something like `display: inline-block` gets truncated before the `-`.
I have old components on my personal site that used to do a similar trick for streaming data without JavaScript but between nginx buffering and cloudflare I have not been able to sort out getting it to actually work these days. Worked fine on Apache in 2005 lol
I see the trace route, but none is glowing green
So they blocked me by IP (I guess) and I didn't get there! Nice.
Or ICMP is blocked on your network
it's not loading for me. :'(
Now you must visit how-didnt-i-get-there.net
502
check again!
Hetzner, yuck.
Does it really exist if it's not a pile of AWS Lambdas?
Lambda is even more yuck.
Why is Hetzner yuck?
I am also curious why you think we are "yuck". --Katie (Hetzner)