1 / 33

Report to HEPCCC March 17, 2000 Matthias Kasemann, FNAL

Report to HEPCCC March 17, 2000 Matthias Kasemann, FNAL. Related URL’s. ICFA-SCIC Homepage http://www.hep.net/ICFA/index.html Cern -> Scientific Committees -> ICFA -> ICFA Standing Committee on International Connectivity ICFA-NTF Homepage http:/nicewww.cern.ch/~davidw/icfa/icfa-ntf.html

crwys
Download Presentation

Report to HEPCCC March 17, 2000 Matthias Kasemann, FNAL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Report to HEPCCCMarch 17, 2000Matthias Kasemann, FNAL HEPCCC M.Kasemann, FNAL

  2. Related URL’s • ICFA-SCIC Homepage • http://www.hep.net/ICFA/index.htmlCern -> Scientific Committees -> ICFA -> ICFA Standing Committee on International Connectivity • ICFA-NTF Homepage • http:/nicewww.cern.ch/~davidw/icfa/icfa-ntf.html • ICFA-NTF July’98 Report • http://nicewww.cern.ch/~davidw/icfa/July98Report.html HEPCCC M.Kasemann, FNAL

  3. ICFA meeting, Vancouver, 1998 • ICFA received the final report of the Networking Task Force (ICFA-NTF). • Decision: create a Standing Committee on Interregional Connectivity (ICFA-SCIC). • Committee members represent major HEP user communities and laboratories. • Focus should be on intercontinental connectivity HEPCCC M.Kasemann, FNAL

  4. Charge to ICFA-SCIC: • Make recommendations to ICFA concerning the connectivity between America, Aisia and Europe. • As part of the process of developing theserecommendations, the committee should • monitor traffic, • keep track of technology developments, • periodically review forecasts of future bandwidth needs, and • provide early warning of potential problems. • Create subcommittees when necessary to meet the charge. • The chair of the committee should report to ICFA once a year, at its joint meeting with laboratory directors. HEPCCC M.Kasemann, FNAL

  5. The chair is appointed directly by ICFA.  Each of the major user laboratories, CERN, DESY, FERMILAB, KEK and SLAC, should appoint one member each.  ECFA, DPF jointly with IPP, and ACFA, should appoint two members each.  ICFA will appoint one member from theRussian federation and one member from South America.  ICFA-SCIC membership: HEPCCC M.Kasemann, FNAL

  6. The representatives from the laboratories are: Manuel Delfino, (CERN),Michael Ernst (DESY),Kasemann (Fermi) (chair),Yukio Karita (KEK),Richard Mount (SLAC). The North American user representatives are: Harvey Newman (USA),Dean Karlen (Canada). For Russia: new member ECFA has nominated: Frederico Ruggieri (INFN Frascati),Denis Linglin (IN2P3, Lyon). ACFA has nominated: Prof. Rongsheng Xu (Computer Center, IHEP China) Prof. HwanBae Park (Korea University) For South America:Sergio F. Novaes (University de S.Paulo) ICFA-SCIC membership: HEPCCC M.Kasemann, FNAL

  7. ICFA-SCIC meetings: • April 15. - 16. at FNAL. • Main topics: • review charge to SCIC, • review work of ICFA-NTF( a lot of it overlaps with SCIC charge), • define priorities and projects, • organize work (and subgroups). • Video Conference on July 6, 1999. • Topics: • update on status of network connectivity • working group plans • action items HEPCCC M.Kasemann, FNAL

  8. Bandwidth Growth Observation/Prediction • Technology Tracking and Cost Model will be performed by the ICFA SCIC Committee HEPCCC M.Kasemann, FNAL

  9. Bandwidth Requirements for HENP • Several sources of information have been used to estimate the bandwidth requirements: • ICFA NTF Questionnaire on Computing and Networking Needs • Computing Technical Proposals and Reports • Scaling according to computing and local area network (LAN) speeds • Scaling according to the data rate to storage, and to the accumulated data volume • Bandwidth available at Homes • Bandwidth available on the Mass Market • Bandwidth required for Physicists' Tasks (Reconstruction, interactive Analysis, Remote Collaboration,…) • Scaling according to the speed of major links common in national and research networks HEPCCC M.Kasemann, FNAL

  10. Year 1998 2000 2005 0.05 - BW Utilized Per Physicist 0.2 - 2 0.8 - 10 0.25 (and Peak BW Used) (2 - 10) (10 - 100) (0.5 - 2) BW Utilized by a University 0.25 - 10 34 - 622 1.5 - 45 Group BW to a Home-laboratory 34 - 622 - 1.5 - 45 or Regional Centre 155 5000 BW to a Central Laboratory 155 - 2500 - 34 - 155 Housing One or More Major 622 10000 Experiments 622 - BW on a Transoceanic Link 1.5 - 20 34-155 5000 ICFA Network Task Force Bandwidth Requirements Estimate (Mbps) See http://l3www.cern.ch/~newman/icfareq98.html HEPCCC M.Kasemann, FNAL

  11. ICFA SCIC meeting: Nov. 13, 1999 • Invited UK representative: Richard Hughes-Jones • Topics discussed: • Status reports from Canada, CERN, DESY, France, Italy, Japan, UK. • Wide Area networks end-to-end performance measurements for video and file transfer show need for application tuning. • Quality of Service for National Research Networksand monitoring results. • Plans for Video system (VRVS project) for higher quality and extended compatibility to video clients. HEPCCC M.Kasemann, FNAL

  12. Impact of loss on applications • Email • fairly insensitive to quality, may be delayed but keeps retrying for days and eventually gets through • Web • usually has human but expectations are low, performance often more limited by server, human present so can retry • Bulk file transfer • unattended, if > 10-12% loss connections can time out • Interactive telnet, voice • very time & loss sensitive • E.g. telnet/ssh loss of > 3% severely impacts typing ability Importance of loss/performance HEPCCC M.Kasemann, FNAL

  13. PingER Performance • Measurements from • 28 monitors in 15 countries • Over 500 remote hosts • 72 countries (covers all 56 PDG booklet countries) • Over 1200 monitor-remote site pairs • Over 50% of HENP collaborator sites are explicitly monitored as remote sites by PingER project • Atlas (37%), BaBar (68%), Belle (23%), CDF (73%), CMS (31%), D0 (60%), LEP (44%), Zeus (35%), PPDG (100%), RHIC(64%) HEPCCC M.Kasemann, FNAL

  14. Results: Top level view - Aug-99 ~ 2000 pairs in 56 countries % packet loss between regions Monitoring region Remote region Poor (2.5-5%) V. poor (5-12%) Good (0-1%) Acceptable (1-2.5%) Bad (> 12%) Within region (on diagonal) good to acceptable HEPCCC M.Kasemann, FNAL

  15. European performance from U.S. HEPCCC M.Kasemann, FNAL

  16. E. Eur-ope Loss Albania Most v.poor to bad Baltic States from US are v. poor Bulgaria Croatia, Macedonia, Slovenia poor to bad Croatia Czech R. Estonia Albania & Romania good Latvia Czech republic & Slovakia better than most, also Bulgaria Lithuania Macedonia CH, DE, & UK have better connections to Russia than most, within Russia OK Romania Slovakia Slovenia Good Accept Poor V. poor Bad HEPCCC M.Kasemann, FNAL

  17. Russia ESnet – NSk good, ESnet – ITEP & IHEP improved with new satellite Canada & Edu bad all over DESY, CERN improved to acceptable to ITEP, IHEP, NSK with new satellite, Dubna still v. poor to bad, UK poor to ITEP & NSK KEK good to NSk, v. poor to ITEP HEPCCC M.Kasemann, FNAL

  18. Monitor site Beacon site (~10% sites) HENP country Not HENP Not HENP & not monitored 200 ms 650ms 1% loss 7% loss 10% loss Europe seen from U.S. HEPCCC M.Kasemann, FNAL

  19. India / Mumbai / TIFR Just added as beacon site ESnet acceptable, Brazil, E. Europe/Russia poor to bad Got better for Japan (KEK & RIKEN), ESnet, W. Europe in Oct-99, but now worse again (5 days in Nov) Stanford vs. CMU & SLAC, possibly BBN-CW peering HEPCCC M.Kasemann, FNAL

  20. E. Asia Poor (2.5-5%) V. poor (5-12%) Good (0-1%) Acceptable (1-2.5%) Bad (> 12%) Japan good to acceptable to N. America & W. Europe S. America poor to all E. Asia Hong Kong & China similar (v. different routes) HEPCCC M.Kasemann, FNAL

  21. 10% loss 3.6% loss 0.1% loss 250ms 640 ms 450 ms Asia seen from U.S. HEPCCC M.Kasemann, FNAL

  22. S. America Poor (2.5-5%) V. poor (5-12%) Good (0-1%) Acceptable (1-2.5%) Bad (> 12%) Generally poor to bad Argentina is bad with everyone Within Brazil & within Colombia, & Brazil to Colombia is acceptable Columbia looks like to be the best HEPCCC M.Kasemann, FNAL

  23. 4% Loss 170 ms 220 ms 700ms 2% Loss 350 ms Latin America, Africa & Australasia HEPCCC M.Kasemann, FNAL

  24. Middle East • SLAC-Israel big change ~Sep 5 • RTT went from 250 msec (E3 via London) to 620 msec • Loss went from 6% to 1% • ESnet peers with Israel at Chicago STAR-TAP (T3 satellite to Israel) • 9 hops • Iran (chapar.ipm.ac.ir) • RTT 1000 msec. • 11% loss • ESnet - ATT (NY) - Unisource (NL) - archway • 13 hops HEPCCC M.Kasemann, FNAL

  25. Bulk transfer - Performance Trends Bandwidth TCP < 1460/(RTT * sqrt(loss)) HEPCCC M.Kasemann, FNAL Note: E. Europe NOT catching up

  26. Problem areas - summary • Germany was bad with .ca & .edu yet good with ESnet. DESY improved to poor/acceptable in Aug with dedicated 3.5Mbps PVC to US/Canada R&E, apart from Carleton • Russia (W) bad to .ca & .edu, good to ESnet, mixed to Europe, poor to .jp. Dubna worse than others. ITEP/IHEP better since new satellite • Former E. block generally poor to bad • China/Hong Kong poor to very poor with most • S. America poor to very poor • India poor HEPCCC M.Kasemann, FNAL

  27. Monitoring results: summary(1) • Performance is getting better • Within Western NRENs things are good • Good enough even for VoIP in terms of RTT, jitter, loss • Internet reliability • in some cases is beginning to approach that specified in phone company frame-relay contracts, but still has a way to go to meet phone company standards of 99.999% • Improving QoS requires some combination of: • Increased bandwidth, but even keeping pace with growing requirements takes constant upgrades and investment • Managed/reserved bandwidth works today in several cases • Diff Serv has big potential but it is still a research topic HEPCCC M.Kasemann, FNAL

  28. Monitoring results: summary(2) • International performance from US to sites outside W. Europe, Japan, Korea is generally poor to bad • Transoceanic, needs special care, peering is critical • E. Europe, Russia, China, India, S. America performance is where N. America & W. Europe were 4 years ago and may not be improving as fast so the discrepancy is likely to increase. HEPCCC M.Kasemann, FNAL

  29. Report on immediate problem areas: • One particular problem area is the outlying regions (outside the developed regions of the world, W. Europe, N. America and Japan) • who have poor connectivity (and may be falling further behind) and yet are delivering important contributions to HEP. • In many cases the countries need an enabler to push the Internet connectivity for the NREN. • ICFA members are closer to the level that can have an impact on the political representatives in the regions. HEPCCC M.Kasemann, FNAL

  30. VRVS summary • Principal Investigator: Caltech and ESnet • Collaborators: CERN, Internet2/UCAID • The Virtual Rooms Videoconferencing System namely called VRVS has been put in production since early 1997. • It provides a low cost, bandwidth-efficient, extensible tool for videoconferencing and collaborative work over networks within the High Energy and Nuclear Physics communities and to some extent within Research and Education at large. HEPCCC M.Kasemann, FNAL

  31. VRVS Current & future • VRVS is now a production system: • As of today, more than 1937 machines from 1253 different users are registered into the system. • During year 1999, 872 Multipoint Conferences has been Conducted (Total 2325 Hours). • More than 3000 point to point connection established. • 7 Virtual Rooms are available for World Wide Conferences in addition to the 4 available for each Continent (America only, Europe only, Asia only). • VRVS Future evolution/integration (R&D) • Deployment and support of VRVS. • High Quality video and audio (MPEG1, MPEG2,..). • Shared applications, environment and workspace. • Integration of H.323 I.T.U Standard into VRVS. • Quality of Service (QoS) over the network. • Documentation and user-configuration recommendations. • Improved security, authentication and confidentiality. HEPCCC M.Kasemann, FNAL

  32. ICFA-SCIC would like to point out: • How can we help to improve the network situation of a poorly connected and spend limited amount of money? • Suggested goal: • HENP members of the country should participate in R&D project with a western Lab/experiment that requires video conferencing for all collaborators to participate in, this will help to drive the requirement. • LHC detector production+ quality control, communication to production site • fully participate in LHC meetings and working groups from home institutes, publications of “schools” • contribution to collaborative software development (à la VRVS) with special emphasis on low bandwidth requirements. HEPCCC M.Kasemann, FNAL

  33. ICFA-SCIC would like to recommend: • Suggested goal (‘ctd): • This proposal needs to be acceptable to the country, which requires pre-discussion with the country. • Video conferencing rooms and tools must be more widely available (at center (CERN, DESY, FNAL, SLAC) and remote) • low entrance cost for VRVS on desktop and conference rooms • Establish a 2Mbps line to the country. HEPCCC M.Kasemann, FNAL

More Related