SLAC logo

Comparison of ihep.ac.cn with cas.ac.cn March-April 2001 Network logo

Les Cottrell. Page created: March 19, 2001.

Central Computer Access | Computer Networking | Network Group | ICFA-NTF Monitoring
SLAC Welcome
Highlighted Home
Detailed Home
Search
Phonebook

Introduction

On March 19, 2001 Les Cottrell received the following email from a colleague at IHEP in Beijing, China.

Dear Les,

    The Chinese Academy of Science will cut our dedicated line
between KEK and IHEP. I have informed KEK. Dr. Yukio Karita
has tested and compared the route from KEK to IHEP and from
KEK to CAS. The latter is much worth than the former. I worry
about the status of the new route from SLAC to IHEP. Would you
please to trace the routes from SLAC to CAS and compare it with
the route from SLAC to IHEP (Now, via the KEK to IHEP) ?
Thanks a lot.

Best Regards,

Chuansong

Earlier Chuansong had sent email to Yukio Karita of KEK Japan (the IHEP link connects directly from IHEP to KEK via a fiber).
>   It is what a pitty to us that I have to tell you an information
>that the Dedicated line between KEK and IHEP will be lost before
>the end of June. It is because the cost of the line. The Network
>Center of the Academy of Science will give us a 2Mbps bandwidth
>DDN line, the cost is much lower than this line.
>
>   I know that this line is a bridge which directly connect IHEP to KEK
>and the world. It has satisfied us for many years in the scientific research
>and international collaboration. We like it. But the things can not come
>back. The directors of the Academy of Science have decided to cut it.
>
>   We thank KEK very much for so many years help, both in
>financial support and in technical support.
>
>Best Regards,
>
>                          Chuansong

Packet Losses

Packet loss from flora.slac.stanford.edu to www.ihep.ac.cn < 1 in 100 packets:
----www.ihep.ac.cn PING Statistics----
103 packets transmitted, 102 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 339/902/3387

Packet loss from flora.slac.stanford.edu to www.cas.ac.cn about 10%
----www.cas.ac.cn PING Statistics----
103 packets transmitted, 92 packets received, 10% packet loss
round-trip (ms)  min/avg/max = 429/464/515
It is apparent that at the time of the measurements, CAS was much worse than IHEP. With the CAS packet loss email is OK, web access is tedious, FTPs will often completely fail, interactive access (telnet, ssh) will be almost impossible (see the Network Monitoring Tutorial for more ideas on impact of losses etc.)

Yukio Karita of KEK also made some traceroute and ping measurements from KEK to CAS and IHEP, which confirm the above differences and poor performance of the KEK - CAS link.

To ensure that the losses were not caused by ICMP rate limiting, we also used synack from SLAC to use the TCP session opening syn and syn/ack response for the web port (80) on www.cas.ac.cn to measure the RTT and losses.

***** Round Trip Statistics of SYN-ACK to www.cas.ac.cn (Port = 80) ******
100 packets transmitted, 91 packets received, 9.00 percent packet loss
round-trip (ms) min/avg/max = 463.135/1600.969/4311.713 (std = 1438.009)
 (median = 890.625)      (interquartile range = 129.084)
 (25 percentile = 853.625)       (75 percentile = 982.709)
Ping measurements made 2 minutes later indicated reasonable agreement:
----www.cas.ac.cn PING Statistics----
100 packets transmitted, 87 packets received, 13% packet loss
round-trip (ms)  min/avg/max = 436/699/954

Routes

The IHEP traceroute and the CAS traceroute indicate that the IHEP route is more direct. The dns.edu.cn traceroute is different from both of the others.

Pingroute

Pingroute to www.cas.ac.cn would appear to indicate the losses start at the CERNET routers. Some of the above losses in pinging the routers maybe due to routers deprecating pings aimed directly at them, however, I believe they are correct in pointing to the onset of problems as being in CERNET. In particular note the 100% losses for large pings followed by much lower losses may indicate that the routers with the high losses are deprecating responding to pings aimed at them. It is also noteworthy that the losses widely vary from time to time, so it is possible that we were just lucky when pinging the 159.226.254.70 and 159.226.2.10 nodes.

The RTT and losses between SLAC and CAS (shown below) measured with 1 64 byte ping/second over a period of 10 hours starting at 20:16:29, 3/19/01 PST shows that the losses and RTTs are very variable. The summary for this period shows that the average loss was 19%. However, there were long periods with no loss at all.

----www.cas.ac.cn PING Statistics----
36000 packets transmitted, 28878 packets received, 19% packet loss
round-trip (ms)  min/avg/max = 147/464/10499
RTT & loss between SLAC & CAS

PingER long term data

We were not monitoring cas.ac.cn from PingER at the time of the initial email, but we were monitoring dns.edu.cn. Comparing the long term packet loss and RTT for Jan 1 thru March 18, 2001 with the same for with IHEP it can be seen that IHEP has much lower packet loss. Whether this is relevant (i.e. is it reasonable to compare cas.ac.cn with dns.edu.cn) will need to be evaluated. To help with a more direct comparison we added www.cas.ac.cn to the PingER monitoring.

Some early PingER results showing RTT and loss seen between SLAC and KEK, SLAC and IHEP and SLAC and CAS for the period covering the one second ping measurements from SLAC to CAS shown above indicate that losses to KEK are good, to IHEP are good to acceptable and to CAS are very poor to bad.

Summary March 19, 2001

At the moment the service levels seen by www.cas.ac.cn are unacceptable to do any real collaboration with the SLAC and ESnet. Given the upcoming CHEP in Beijing later this year, unless something dramatic is done to improve performance on the CAS.ac.cn to ESnet link then it will reflect very badly on Chinese academic networking.

Resolution

On April 1, 2001, Hualin Qian sent the following email:

Dear Dr. Cottrell and Karita,

We have received the result of the tests that you have done on 
May 19, 2001. And we found that the route from SLAC or KEK to
the www.cas.ac.cn is not correct. Because a new Internet 2 link
from Tsin-Hua university, via STAR TAP, to abilene was installed
since the beginning of March. This new 10Mbps link will be shared
by CERNET and CSTNet, but only for some research and development
use, not for all the hosts of the two networks. When Tsin-Hua
University announces our IP to the abilene, they included the
host www.cas.ac.cn and many other hosts as well, making these
hosts do not go through our normal international links, but going
through the CERNET, STAR TAP and Abilene instead.

The performance of CERNET depicted in "Average Round Trip Time and
Packet Loss Measured from slac.stanford.edu to dns.edu.cn" is
very poor. But our CSTNet is good. If the traffic going through
the CERNET, it will be surely very poor. This should not be the case
for IHEP use.

Now we have asked them to correct this situation. Please do the
same tests (traceroute and ping) again and send the result to
us.
Ping and traceroutes from xxx.cas.ac.cn to SLAC indicated that the losses were now less than 1%. Yukio Karita confirmed the performance by making ping and traceroute measurements from KEK to ww.cas.ac.cn. Similar results were obtained from SLAC where the loss was measured to be less than 0.05%. A PingER plot of the losses and RTTs indicates that performance improved dramatically around 2pm GMT March 30th.

The pipechar path characteristic measurement is unable to get beyond hop 23. As far as that goes it indicates that the bottleneck is 10mbps starting in the APAN network.

I do not understand why the traceroute from KEK should be going via the US, that certainly will introduce considerable extra delay. Comparing the traceroute from CAS to SLAC with the route SLAC to CAS it appears the routes are quite asymmetric (the * * *) is since the SLAC internal routers are in private address spaces. The route from SLAC to CAS is quite tortuous going via CalREN2/Internet 2 (in California) to Chicago STARTAP and thence to China. Going to Chicago and back adds about 80 msec to the route. The current route to ihep is more direct going from SLAC to Sunnyvale (about 5 5 miles away in Silicon Valley) across to KEK/Japan and thence to IHEP, however the round trip time is worse.


Page owner: Les Cottrell