SLAC to CERN RTT AnomaliesLes Cottrell. Page created: May 23 2003.
Central Computer Access | Computer Networking | Network Group | ICFA-NTF Monitoring
Looking in more detail at the traceroute, it appears the lower latency path is via link to Deutsche Telekom at PAIX. This is confirmed by a traceroute from an Internet2 router in Sunnyvale having pretty much identical latency to the ESnet path.
Apparently Stanford has a direct connection to PAIX in Palo Alto, where they peer with Deutsch Telekom/DTAG (and likely others as well). DT apparently has a direct link between PAIX and their router in Geneva (CIXP-gw20.GVA.CH.net.DTAG.DE). It is not clear how this connection is routed, but it shows a round-trip latency of well under 170msec (probably close to 150msec), which is amazing for a link from the Bay Area to Geneva. Note by contrast, that ESnet is using the CERN link between Chicago (STARLIGHT) and Geneva and it shows a RT latency of well over 200msec.
So when we route through Stanford we are using this very low-latency DT link directly to Geneva and via ESnet (and I2) you will use the longer latency CERN link through Chicago.
In principle ESnet could turn up peering with DT in PAIX and prefer it over the connection through STARLIGHT as the preferred route to CERN, but that seems to have other drawbacks. One possible drawback is that from the PingER measurements the path from SLAC to CERN appears to have a generally higher packet loss.