Progress Report. Project title: Resource optimization in hybrid core networks with 100G systems

Transcription

1 Progress Report DOE award number: DE-SC Name of the recipient: University of Virginia Project title: Resource optimization in hybrid core networks with 100G systems Principal investigator: Malathi Veeraraghavan Date of report: Mar. 25, 2010 Period covered by the report: Dec. 1, 2009-Feb. 28, 2010 Comparison of the actual accomplishments with the goals and objectives established for the period and reasons why the established goals were not met. The goals for this quarter, as stated in the 1Q report, were to complete a first draft of a hybrid network architecture document, complete a first-phase software implementation of the Offline Flow Analysis Tool (OFAT), complete a revised version of the HYNES architecture document, and make a presentation at the ESCC meeting, Feb. 3-4, All four goals were accomplished in this quarter. A discussion of what was accomplished under these goals during this reporting period, including major activities, significant results, major findings or conclusions, key outcomes or other achievements. This section should not contain any proprietary data or other information not subject to public release. If such information is important to reporting progress, do not include the information, but include a note in the report advising the reader to contact the Principal Investigator or the Project Director for further information. 1 Activities First draft of Hybrid architecture document completed: The term hybrid network is defined as a single integrated network that supports multiple types of services, e.g., IP-routed datagram and virtual circuit services. Three functions in hybrid networks: dynamic capacity allocation, traffic engineering, and protection/recovery mechanisms, are addressed in this document. The document is available on the documents page of the project web site: Hybrid Network Traffic Engineering Software (HNTES) architecture document completed: Based on comments received on our Dec HYNES document, we revised the software architecture, renamed the system HNTES, and completed the document. This is also posted on the project web site. This is the basis for our prototype software development. Software development team created: Zhenzhen Yan, a Ph.D. student, will be the lead software developer and system integrator. Two undergraduate students, Jared Harding and Tian Lu, have registered for independent study courses, under which they will develop components of the HNTES software. Jared is implementing the flow-monitoring module, and Tian is implementing the MFDB. 1

2 Phase 1 OFAT software released: Zhenzhen Yan completed implementation of the Phase 1 Offline Flow Analysis Tool (OFAT). This tool is implemented in the R statistical programming language, and also uses shell scripts. The software was provided to ESnet for their testing. The HNTES document describes the purpose of this software in detail. A detailed OFAT architecture document is posted on the project web site. Presentation at the ESCC meeting, Feb. 3-4, 2010, Salt Lake City: A talk on hybrid network architectures was presented at the ESCC meeting. The definition of hybrid networking, the use of integrated or separate networks, and different usage scenarios for hybrid networks were presented. The feedback received was incorporated in the hybrid network architecture document (see item 1 of this report). Flow length prediction: An accurate prediction of flow lengths is a critical component of the HNTES solution. A three-track methodology was developed consisting of (i) Netflow data analysis, (ii) human-knowledge mining from network requirements workshop reports and escience project web sites, and (iii) in-depth analysis of communication patterns of applications, such as GridFTP, bbcp, scp, sftp. This method was applied to Internet2 data. Unidata, GridFTP, and SCP flows were found to be key generators of long flows. Statistical characterization of long flows was also done. HNTES software development for Tabletop/LIMAN testbed experiments: The flow monitoring module implementation is well under-way. The pcap library is used to capture packets. A C++ program is being implemented to extract flow identifiers from captured packets, and look up flows in the MFDB. TCP sockets will be used to send MFDB-extracted information to the IDCinterface module, which then interacts with the IDC. The second component under development is the IDC-interface module. The OSCARS Java Client API was obtained, and certificates created for testing against the ESnet provided test IDC and notification broker. Finally, the MFDB was implemented using Microsoft SQL, and a C# program was implemented to upload an ASCII file containing the set of to-be-monitored flow identifiers with durations to this database. This is being ported to MySQL and C++ for a Linux implementation. 2 Findings Of the long flows identified through an analysis of Internet2 Netflow data, i.e., flows of duration 10 minutes or longer, a significant percentage of the flows could be explained by correlating source and destination IP addresses with those of data transfer servers used by large escience projects, such as Teragrid, ESG, etc. For example, the NP community machines were sources or destinations for ~30% of the long flows identified in the CHIC Internet2 router in one 5-day period. Maximum length of flows found in the CHIC and LOSA Internet2 routers in one 5-day analysis was 7.5 hours. Therefore the flow record concatenation algorithm needs to consider only consecutive-day Netflow files. While the set of flows identified as long was approximately 0.01% of the total number of flows, these long flows contributed to approximately 5% of the bytes. Three problems were identified: First, in mining human knowledge, we found that often computer clusters are used for data transfers with batch-mode job submission (e.g., using qsub). Most escience web sites provide the IP addresses of front-end nodes of their clusters, but the back-end data nodes are the ones that carry out the actual data transfers. Therefore, 2

3 communication is required with site administrators to obtain a complete set of IP addresses of data transfer server interfaces. A second problem is that address anonymization makes it difficult to perform flow record concatenation to determine true flow lengths. Given that Netflow sampling rates are only 1-in-100 packets, gaps can arise in the packet timestamps reported in flow records, making concatenation difficult. The third problem is that many of the flow identifiers of long flows are also shared by short flows. One solution is to have the flow-monitoring module of HNTES wait for a certain duration to check for sustained data packets on a flow before initiating circuit setup. Need for ESnet Netflow data analysis as a complement to prototyping effort: Ideally, an analysis of ESnet Netflow data should be carried out to estimate the returns on investment, i.e., percent of bytes that are candidates for virtual circuits, before the HNTES technology can be considered for deployment on ESnet. While the tabletop testbed/liman prototype testing can serve as a proof of concept for HNTES, and answer questions related to user performance, for example, how is TCP performance impacted by live route changes, only a network-wide Netflow data analysis can help us understand the feasibility and benefits/costs of deploying the HNTES solution. Therefore, we request the support of DOE in obtaining ESNet Netflow data. Cost Status. Show approved budget by budget period and actual costs incurred. If cost sharing is required break out by DOE share, recipient share, and total costs. Please see attached file. Schedule Status. List milestones, anticipated completion dates and actual completion dates. If you submitted a project management plan with your application, you must use this plan to report schedule and budget variance. You may use your own project management system to provide this information. The 3Q portion of the schedule submitted in Oct is listed below: Date Milestone Status Apr. 1, 2010 Software design Traffic analysis preliminary results Completed Feb. 28, 2010 Pending the procurement of ESnet Netflow data Next quarter deliverables: By the end of the next quarter, May 31, 2010, the following deliverables will be completed: HNTES flow-monitoring module implementation HNTES IDC-interface module implementation HNTES MFDB implementation Preliminary analysis of Internet2 Netflow data 3

4 Design of the initialization module and router-control interface module, and plans for using the tabletop testbed assuming it is available from June-Oct Progress on organizing a special journal issue on the topic of hybrid networking. Any changes in approach or aims and reasons for change. Remember significant changes to the objectives and scope require prior approval by the contracting officer. Actual or anticipated problems or delays and actions taken or planned to resolve them. Problems/delays are anticipated in obtaining ESnet/site Netflow data. As a starting point, we provided ESnet with our statistical analysis programs (R and shell scripts) so that ESnet personnel can execute these programs on collected Netflow data and automatically fill in the Monitored Flow Data Base, as described in the HNTES architecture document. Any absence or changes of key personnel or changes in consortium/teaming arrangement. None A description of any product produced or technology transfer activities accomplished during this reporting period, such as: A. Publications (list journal name, volume, issue); conference papers; or other public releases of results. B. Web site or other Internet sites that reflect the results of this project. UVA Hybrid Networking Project web site was created: Collaboration web site for project participants to post documents, discuss issues in an online forum, archive s, etc. The password-protected site is: C. Networks or collaborations fostered. We have sent the OFAT software to Chris Tracy, ESnet, for a data analysis of ESnet Netflow data. We also interacted with Phil de Mar, FNAL, and Linda Winkler, ANL, to obtain general feedback on our approach. D. Technologies/Techniques. E. Inventions/Patent Applications 4

5 F. Other products, such as data or databases, physical collections, audio or video, software or netware, models, educational aid or curricula, instruments or equipment. 5