HTASC # 13 meeting MINUTES

Transcription

1 HTASC # 13 meeting MINUTES Meeting held at CERN 28/29 October 1999 Attendance Present: Alan Flavell (UK), Magdolna M. Zimanyi (H), Milos Lokajicek (CZ), Peter Chochula (SK), Nicanor Colino (E), Paolo Capiluppi (I), Christophorus Grab (CH), Tobias Haas (D), Jürgen Knobloch (CERN), Bjorn S. Nilsson (DK), Grzegorz Polok (P), David Kelsey (Chairman) Apologies: Kors Bos (N), Catherine Declercq (B) Absent: Gerhard Walzel (A), Ola Borrebak (Nor), Ion Siotis (G) Introduction Welcome by D. Kelsey. Organisational Matters: Minutes of HTASC 12 accepted with minor comments: Small comments by M. Lokajicek. Comment by J. Knobloch that 7e (differences between different LINUX flavours are "vanishing") is not correct. Actions: 13.1 D. Kelsey to discuss with E. Auge to bring all minutes on the WEB D. Kelsey to discuss with D. Jacobs to make all WEB material easily printable (PS/PDF) 12.1a closed 12.1b closed,transferred to c closed, Transferred to 12.4a ongoing 12.5 closed closed Comment by J. Knobloch: Action items collected at the end. D. Kelsey: Report from HEPCCC Steve Wolbers: Overview of computing at FERMILAB. Larry Price/Terry Disz: Overview of computing at ANL. E. Valente: Update on TEN-155 and European HEP networking. Phil DeMar: Research and Academic Networks in the US. John Womersley: FNAL plans for a CMS regional center. Jon Bakken: The ENSTORE project for mass storage. Don Holmgren: LINUX projects at FNAL. Actions on HTASC 53: Markup languages 61: Y2K

2 64: Videoconferencing: Discussion about the request from HEPCCC to show to the management how VC saves travelling expense. Roundtable discussion on the future standardization of computing platforms for HEP with a view to formulating a recommendation from HEPCCC Question from J. Knobloch: How do the recommendations get down to experiments? Discussion: Who should push this issue? Do we need a unique LINUX for HEP? Significant effort to come to a common recommendation. How can any recommendation be reinforced? How does one get all parties involved to agree on one solution? Summary: There is clearly a problem there but HEPCCC should decide how one should go about the problem since it may be mostly a political problem. Olivier Martin: Introduction to QoS See transparencies in Different definitions of QoS and ways to monitor QoS were discussed Two approaches proposed: Integrated services: Needs an RSVP protocol Differentiated services: newer simpler proposal thus much better chances to get deployed in some real internet service. J. Knobloch asks: Will all routers between two partners have to be modified to use this? ATM is far from dead, but has serious scaling difficulties. MPLS is promising. In the meantime community managed internets will remain the best solution. Complicated network topology need to careful monitoring. QoS experience at CERN: Weighted Fair Queuing (WFQ) worked well in the past. But not available on the high speed links. QoS mechanisms needed for VRVS (Considering to use RSVP or dedicated ATM VC), IP telephony (CERN, DESY, FNAL SLAC) Priority queueing is adequate, Video on demand services ICAIR diffserv capable IBM Video Charger Maximum TCP throughput under periodic packet loss: Formula proposed by Matt Mathis/PSC: (MSS/RTT)*(1/sqrt(p)) MSS: maximum segment size (1460 bytes in practice) QoS Monitoring: Various statistics available: Summary: Problem may not have a solution Pragmatic solutions exist but only in well-controlled environments Can HEP afford? Monitoring is essential! Tobias Haas: Network/Computer Security See transparencies in

3 Report on the progress on the security report. Current version (v2.0) is based on discussions in a working meeting at DESY in May and has since received further comments. The proposal is to present the report to HEPCCC in their next meeting. T. Haas agrees to travel to CERN and present the report on this occasion. Tiziana Ferrari: QoS A Definition of QoS was given: Quantitative: Delay, instantaneous delay variation, packet loss probability, throughput, maximum transfer unit MTU, priority Benefits: Manage congestion, congestion independent QoS parameters, traffic engineering. Within a single applications: differentiated treatment of streams Multiples applications Possible Solutions: Cell-based networks: ATM IP: RSVP and integrated services Heterogenous networks RSVP to ATN SVD mapping Differentiated services ATM disadvantages: Not widely deployed, no end-to-end connectivity, no native ATM applications, IP over ATM has overhead, few applications supporting traffic profile definition RSVP disadvantages: RSVP ATM mapping could be an interim solution Diffserv: Why diffserv? New technology at IETF Independent of layer 2 technology Interoperability between independent national research networks Scalability: No reservation state maintained in the routers Diffserv architecture: Use previously unused label in header: Sets up a service level agreement between application and customer Could be setup for instance in European networks using the flexible Domain structure of the protocol. Expedited Forwarding: Low loss, low latency, l ow jitter, garanteed bandwidth. Assured Forwarding: Scheduling: queue service policy for differentiated treatment of packets among queues Policing: Traffic which exceeds a given rate threshold is treated differently from conforming traffic. Congestion avoidance: Weighted random early discard

4 Case study: Remote control for CDF hardware of the trigger low packet loss, delay sensitive, burst tolerance Monitoring of quality and correctness Test network: INFN/CERN/UNI Stuttgart/SWITCH/ Equipment: Test workstations, traffic generators, ATM switches, cabletron ethernet switch, DS capable platforms: CISCO, IBM, LINUX, Cabletron More information at Diffserv: QoS Measurement: Comments Building blocks already supported by many vendors No changes to applications needed Diffserv goal: simplified approach to QoS for its support in backbones from today Good interim test results Diffserv still requires QoS support end-to-end Issues: Diffserv in production? (1 y) Tools for service monitoring Questions: Deployment of diffserv in HEP Driven by DANTE? Issues in diffserv deploymentin HEP Recommendations Pricing? Neil Geddes: Software Development in BaBar Introdution BaBar approved in 95, started in 99, DecidedtogoOO All core developers are physicist! Tools C++ (Only viable tool large OO project, but new, no standard, complicated) Lessons: Must have a core team of programmers with regular and frequent contact. Training needed since C++ and OO new to HEP. Methodology: Part of the training! Early prototyping (Close to Booch approach but not formalized) Development cycle in BaBar: 1995: Overall architecture 1996: Core functionality, analysis interface, no real alignment/calibration 1997: Mock data challenge I, alignment,calibration 1998: Mock data challenge II, performance

5 OO/C++ Problems: Fanatics. Complicated class hierarchy, inheritance C++ and OO are not the same Old Problems: Too few people, too little control, software is the last bastion of creativity (confusing physics with engineering) Dispersed collaboration with no money Predicting the future Conclusions: Physicists can read/use OO code! Babarhas4MioLOCC++and1-2MioLOCF77forGEANT PhysicistscanwriteC++ C++ is a difficult language but it is a sharp tool. Can reconstruct and analyze events (about 30% behind due to Objectivity) Wrote MDST format independent of Objectivity Good project management is necessary Developers are valuable: need to train and appreciate them Discussion: C. Grab: How many core developers? Answer: For reconstruction: about 6 people. Total effort man years for recon. 250 man years for total. Use ROOT IO as a means to circumvent Objectivity. Magdolna Zimanyi: How was the training done? Discussion on the QoS Talks Should encourage the testing. Express clear need to HEPCCC Maybe the HEP requests are special? (Good interactive response for terminals and remote control ) Windows 2000 Migration Group HEPCCC said it should be created. Whole list of people who want to join it. Should be renamed WINDOWS2000 coordination group. Dates of next years meetings 9/10 or 2/3 March (CERN) LDAP, Revisiting OO incl. Fermilab incl ROOT, WINDOWS2000 chairman, Tickets etc 8/9 June (Outside) 19/20 October (CERN) Topics: Regional Centers, Markup Languages, LDAP Possible speakers for Regional centers:? A. Flavell: PIPVIC2 Project (Piloting of IP Videoconferencing) JANET activity. Participants are Universities: Teaching activities with some research. HEP only a small part. Manchester, 2 London Us, Glasgow.

6 H323: originally designed for reliable channel. Problems with firewall. MBONE style tools: Supplied from UCL computer science department. Wide range of different kinds of meetings: Lectures, many-2-many, project meetings. Subjective monitoring and objective monitoring. Practical work is over and report is currently being drafted. This will be published by the end of the year. Most stressful meetings: the Friday project meetings: up to 15 participants broadcasting at 100 kb/s each. Too much for many of the workstations. Lead to improvements in the VIC tools. This will be very useful. The network for multicast has been reoriganized in the UK and also witin TEN155. Works well now within UK but not yet in the European context: Large packet loss. Seminars from CERN are not usable. Reports from the Home Countries G. Polok(P): network ok, many UNIXs. Start unification next year B. Nilsson (DK): no news C. Grab (CH): no complaints. Everybody has at least 34 Mb/s, US links upgraded to 34 Mb/s. N. Colino(E): Link to US recently upgraded, already saturated. Access to TEN155 WEB Cache. Connection of individual universities to Spanish research network. P. Capiluppi (I): GARBI network finalized soon (155 Mb/s backbone). New connection from Italy to US (40 Mb/s limit). Observation that some INFN institutes do not use their bandwidth but some universities completely saturate the bandwidth. Desktops will be funded through general infrastructure. M. Lokajicez (CZ): Better connection to TEN155 (Frankfurt), total of 45 Mb/s. Additional 16 Mb/s to US outside TEN155. Managed service to CERN brings improvement for interactive work but no improvement for FTP file transfers. Use bqs batch environment on LINUX. For Security firewalls are being installed. M. Zimanyi (H): Good connection to international lines to Vienna. Inside country still problems since institutes only have slow connections due to money problems. Soon upgrade for 11 universities and research institutes for at least 10 Mb/s or 34 Mb/s. Same also for KFKI. A. Flavell(UK): Serious concern that many particle physicists are working to improve computing environments. JANET network is generally very good. But some serious disruptions (RAL off for 3 days). TEN155 generally very good on the whole. But short period with very sluggish behaviour. Lines to USA very good at the moment. But connection to ESNET is not very good. Piloting a QoS on the US lines. This uncovered a problem with MAC software which failed with this. Currently investigating the requirements for the next major upgrade. University research is becoming a smaller part of JANET. Financing is not clear yet. Group of UK system managers successfully raised the profile of security. Useful mailing list.