(sigh) I'm just thinking those thoughts right now.
tracepath -m60 bad.horse
openssl s_client -connect signed.bad.horse:443 -servername signed.bad.horse ssh funky.nondeterministic.computer > tracepath -m60 bad.horse
[...]
16: bad.horse 81.233ms asymm 10
19: he.rides.across.the.nation 85.365ms asymm 11
20: he.got.the.application 96.067ms asymm 13
23: it.needs.evaluation 112.377ms asymm 15
24: a.heinous.crime 114.826ms asymm 17
25: a.show.of.force 120.842ms asymm 18
26: bad.horse 133.089ms asymm 20ssh watch.ascii.theater
ssh terminal.shopBehind the keyboard of a large PC
Well, how did ip route here?
Love this
https://lamplightdev.com/blog/2024/01/10/streaming-html-out-...
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)
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.
> - Lexi, Nov 7, 3:16 PM PST
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 `-`.
<noscript>
<style>#strYQt8 { display: none; }</style>
<div id='stro29i'>
…
Host ASN Network Region
123-456-789-101.static.kc.net.uk AS19905 UltraDDoS Protect Global
Host ASN Network Region
123-456-789-101.static.kc.net.uk AS12390 Kingston Communications Europe
I read this title and that opening bass line just starts flowing.
Traceroute isn't real, or: Whoops! Everyone Was Wrong Forever: https://gekk.info/articles/traceroute.htm
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."
ChrisArchitect•3mo ago
https://news.ycombinator.com/item?id=38531604