1 / 32

Internet2 Engineering Issues

Internet2 Engineering Issues. IBM T J Watson :: Hawthorne Guy Almes <almes@internet2.edu>. 25 July 2001. Internet2 Engineering Objectives. Provide our universities with superlative networking: Performance Functionality Understanding

bettsm
Download Presentation

Internet2 Engineering Issues

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. Internet2 Engineering Issues IBM T J Watson :: Hawthorne Guy Almes <almes@internet2.edu> 25 July 2001

  2. Internet2 Engineering Objectives • Provide our universities with superlative networking: • Performance • Functionality • Understanding • Make superlative networking strategic for university research and education

  3. Engineering:Advanced Functionality • Multicast • IPv6 • QoS • Measurements • Support for End-to-End Performance

  4. Internet2 Multicast • Multicast Working Group • Kevin Almeroth, Univ California Santa Barbara, chair • Encouraging more pervasive high-quality deployment of native IP multicast throughout the Internet2 infrastructure • Fighting fires • Keeping an eye on SSM • Clarifying the application story

  5. Internet2 Multicast Architecture • PIM-SparseMode • multicast routing within an Autonomous System • quite scalable • notion of rendezvous points • MBGP • between Autonomous Systems • MSDP • Source Discovery

  6. Longer-term WG Issues • Scalability (what happens if it does catch on?) • Exploring the role of Source-Specific Multicast

  7. Could SSM be Enough? • 'Classic' Multicast • Group <g> has global significance • A user creates, joins, sends to g • Others can join, then send to and/or listen to g • MBGP, PIM-SM, MSDP triad • Source Specific Multicast • Group <g> has local significance • A user 's' creates, sends to <s,g> • Others can subscribe to, then list to <s,g> • No need for MSDP (or allocation of <g> values)

  8. Implications of SSM • Simplify Multicast Routing / Addressing • No need for global class-D address allocation • No need for source discovery • Complicates 'few-to-few' applications • Define all the members of the application-level group • Both a burden and an opportunity • Allows better Security, Scalability • Requires new version of IGMP

  9. Multicast Summary • Full functionality supported now • Deployment steadily increasing • Some international peering, e.g., CA*net3 • Performance excellent • Scalability? • Applications?

  10. Internet2 IPv6 • IPv6 Working Group • Dale Finkelson, Univ Nebraska, chair • Build the Internet2 IPv6 infrastructure • Educate campus network engineers to support IPv6 • Explore the Motivation for IPv6 within the Internet2 community

  11. IPv6 Infrastructure • vBNS and Abilene both support IPv6 • Abilene IPv6 with IPv6/IPv4 • Four 'backbone' nodes: Cisco 7200 • Atlanta, Pittsburgh, Denver, and Indianapolis • Managed by the Abilene NOC • IPv6 WG: address allocation and engineering coordination

  12. Education / Training Goals • IPv6 hands-on workshop • Lincoln, Nebraska; 17 May 2001 • starting from scratch, build an IPv6 network, including routers, hosts, DNS tools and various transition tools, ending up with a functional IPv6 network fully interconnected to the global Internet. • Materials from this workshop will be available to enable gigaPoPs and others to use in their own workshops.

  13. Explore IPv6 Motivation • Why should our users, campus decision-makers, and community generally care about IPv6? • IPv6 preserves the classic end-to-end transparency of the Internet architecture • improved support for mobility • key for IPsec • key for the scalability of the Internet • The answers must be pragmatic.

  14. Engineering:End-to-End Performance

  15. The Current Situation • Our universities have access to an infrastructure of considerable capacity • examples of 240 Mb/s flows • End-to-end performance varies widely • but 40 Mb/s flows not always predictable • users don't know what their expectations should be • Note the mismatch

  16. Threats toEnd to End Performance • BW = C x packet-size / ( delay x sqrt(packet-loss ))(Mathis, Semke, Mahdavi, and Ott, CCR, July 1997) • Context: • Network capacity • Geographical distance • Aggressive application

  17. Threats toEnd to End Performance • Fiber problems • dirty fiber • dim lighting • 'not quite right' connectors

  18. Threats toEnd to End Performance • Fiber problems • Switches • horsepower • full vs half-duplex • head-of-line blocking

  19. Threats toEnd to End Performance • Fiber problems • Switches • Inadvertently stingy provisioning • mostly communication • happens also in international settings

  20. Threats toEnd to End Performance • Fiber problems • Switches • Inadvertently stingy provisioning • Wrong Routing • asymmetric • best use of Internet2 • distance

  21. Threats toEnd to End Performance • Fiber problems • Switches • Inadvertently stingy provisioning • Wrong Routing • Host issues • NIC • OS / TCP stack • CPU

  22. Perverse Result • 'Users' think the network is congested or that the Internet2 infrastructure cannot help them • 'Planners' think the network is underutilized, no further investment needed, or that users don't need high performance networks

  23. Promising Approaches • Work with key motivated users • 'Shining a flashlight' on the problem • Measurements • Divide-and-Conquer • Understanding Application Behavior • Getting it right the first time

  24. Internet2 End-to-End Performance Initiative • Very recently hired / deployed staff • Cheryl Munn-Fremon, initiative director • Russ Hobby, chief technical architect • George Brett, chief information architect • $1.5M budgeted by Internet2

  25. Internet2 End-to-End Performance Initiative • Distributed measurement infrastructure • Enable rapid effective understanding of why an instance of end-to-end performance is limited • Make the work of PERF participants rewarding • Enable initiation of tests by PERF participants • Teams of performance analysis specialists (PERF) • Dissemination of best practices

  26. Internet2 End-to-End Performance Initiative • Distributed measurement infrastructure • Teams of performance analysis specialists (PERF) • members at campuses, gigaPoPs, backbones • socially and technically coordinated • committed to effecting radical change • Dissemination of best practices

  27. Internet2 End-to-End Performance Initiative • Distributed measurement infrastructure • Teams of performance analysis specialists (PERF) • Dissemination of best practices • Identify key techniques, tools, and 'best practices' • Make them common • Work toward widespread / routine excellent user experiences • Improve the reputation / status of network engineers

  28. Anticipated Partners • NLANR: DAST, MOAT, and NCNE • Web100 Project • Abilene partners • Leading campuses and gigaPoPs • Internet2 corporate members

  29. Access to Key Resources • Optical telescopes in Hawaii • CRAFT Project • PACI Supercomputer Facilities • CERN

More Related