Internet2 Engineering and University Researchers Nacogdoches Guy Almes 30 March 2001

Outline of Talk A Internet2 Engineering / Infrastructure A Advanced Functionality: • Multicast as a normative service • IPv6, QoS A Issues in End-to-End Performance A Practical support for university researchers

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

The End to End Challenge A Support advanced networking end to end A Performance • 100 Mb/s across the country normative • several multiples possible in some cases A Functionality • Multicast • Quality of Service • IPv6 • Measurements

Abilene core November 2000 Seattle Kansas City Denver Cleveland New York Atlanta Houston Sacramento Los Angeles Indianapolis Washington

Abilene Connections by (roughly) Mar-2001

International Peering STAR TAP APAN/TransPAC, CA*net3, IUCC, RENATER, REUNA, SURFnet, SINET, TAnet2 CERnet, (HARnet) OC12 New York DANTE*, JANET, NORDUnet, SURFnet CA*net3 Seattle CA*net3, (AARnet) Sunnyvale (SINET) Los Angeles SingAREN, SINET Miami (REUNA, RNP2, RETINA) OC3-12 El Paso (CUDI) San Diego CUDI

Advanced Functionality A Multicast A IPv6 A QoS

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

'Classic Model' Native IP Multicast A Steve Deering's Stanford PhD thesis A Notion of a multicast group • Denoted as a class-D IP address • User can create and join • Any member of the group can send • All members of the group receive A These 'g' values have global significance A Allocation and Routing are hard

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

Issues on the Campus A IGMP • support join, leave by users • host communicates with its first-hop router A PIM-SM, MSDP, etc. • becoming well understood A Optimization of switched ethernets

Short-term WG Issues A Encouraging deployment and applications A Pressing router/software vendors for specific needed improvements A Improving the set of tools for network management, e.g., Matt Davy of Indiana Univ A Fighting Fires, e.g., recent MSDP storms

Multicast Applications A 'few to few' applications • vic/vat: Video/Audio-conferencing • Access Grid A Streaming media • ResearchTV at Univ Washington • Concerts, music via Univ Oregon A 'one to many' file transfers • digital fountain etc

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

Could SSM be Enough? A 'Classic' Multicast • Group 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 A Source Specific Multicast • Group has local significance • A user 's' creates, sends to • Others can subscribe to, then list to • No need for MSDP (or allocation of values)

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

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

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

IPv6 Infrastructure A vBNS IPv6 with IPv6/ATM A Abilene IPv6 with IPv6/IPv4 • Four 'backbone' nodes: Cisco 7200 " Atlanta, Pittsburgh, Denver, and Indianapolis • Managed by the Abilene NOC A IPv6 address allocation and engineering coordination

Education / Training Goals A IPv6-only 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. A Other dissemination ideas

Explore IPv6 Motivation A Why should our users, campus decision- makers, and community generally care about IPv6? • we like Steve Deering • 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 A The answers must be pragmatic.

Internet2 QoS A Quality of Service Working Group • Ben Teitelbaum, Internet2 staff, chair A QBone Premium Service A Scavenger Service A Architectural and ad-hoc projects

QBone Premium Service A For a given bit/second rate, minimize: • Delay and variation in delay, and • Loss A And support • Interoperability of separately designed/managed IP networks (e.g., Abilene, gigaPoP, ESnet, campus) • Interoperability of different (compliant) equipment A This is hard and very important

Scavenger Service A Suppose there were a less-than-best- efforts IP service within Internet2? • users can mark their packets LBE • best-efforts traffic generally routed before LBE traffic • what bottom-feeding applications would emerge? • much easier than Premium Service

Architecture and Ad-hoc Projects A Architecture • Critique Premium Service etc as other ideas emerge • Study economic issues associated with QoS A Ad-hoc Projects • (Purely) pragmatic applications of QoS techniques to important yet congested international links • Test efficacy of Premium Service for proposed advanced applications

Issues in End-to-End Performance

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

What are our Aspirations?  Candidate Answer #1: Switched 100BaseT + Well-provisioned Internet2 networking ® 80 Mb/s A But user expectations and experiences vary widely

What are our Aspirations? A Candidate Answer #2: Lower user expectations and minimize complaining phone calls A There is a certain appeal I suppose...

What are our Aspirations? A Candidate Answer #3: Raise expectations, encourage aggressive use, deliver on performance/functionality to key constituencies. A Not the easy way, but necessary for success

Why should we Care? A "We" as the university community. A "We" as campus networking specialists. A "We" as networking professionals. A "We" as the (broad) Internet2 project. A Low aspirations are dangerous to us.

End to End Performance Initiative A Goal: • To create a ubiquitous, predictable, and well- supported environment in which Internet2 campus network users have routinely successful experiences in their development and use of advanced Internet applications, by focusing resources and efforts on improving performance problem detection and resolution throughout campus, regional, and national networking infrastructures.

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

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

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

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

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

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

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

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

Internet2 End-to-End Performance Initiative A Distributed measurement infrastructure A Teams of performance analysis specialists (PERTs) A Dissemination of best practices

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

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

Internet2 End-to-End Performance Initiative A Distributed measurement infrastructure A Teams of performance analysis specialists (PERTs) A 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

Defining End-to-End Success Metrics A Identify core applications / services • high-performance TCP • VoIP / videoconferencing • pervasive native IP multicast A Scope • How pervasive is it supported across the campus? A Timeliness • When are these metrics achieved?

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

Initiative Phases A 1 st Gear • Preparation, planning, early experiments A 2 nd Gear: Early Adopters Phase • Partner with selected 'early adopters' • Develop PERTs, Measurement Infrastructure, etc. • Build tools, resources, and best practices A 3 rd Gear: Dissemination • Increasingly pervasive PERTs, infrastructure

Initiative Timeline A Ongoing search for an Initiative Director A Planning Meeting: 9-Jan-01 A Design Team Report: 28-Feb-01 A Unveil Report: Spring Member Meeting A Issue Call for Partners: May-01

Internet2 Measurements A Measurement Working Group • Matt Zekauskas, Internet2 Staff A Define architecture: • Usage • Active Measurements of Performance • Passive Measurements A Uniform Access to Results A Contributing to Measurement Infrastructure for the E2EPerf

Applications for Measurements A End-to-end Performance Debugging A Verification of QoS Performance Characteristics A Support for Operations A Forward engineering of new infrastructure A Supporting research, e.g., by university computer scientists

Active Measurements within Abilene Surveyors with: Active delay/loss measurements Ad hoc throughput tests

Application to Performance Debugging

Divide and Conquer A Systematically identify/isolate the network segment at fault A Can we make this systematic and (eventually) automated?

Access to Key Resources A Optical telescopes in Hawaii A CRAFT Project A PACI Supercomputer Facilities A CERN

Working Groups as Opportunities A We intend the WGs to be effective as: • means for interested engineers to 'sink their teeth into' hard Internet2 engineering problems • means for disseminating best practices etc to the Internet2 membership A New Engineering Area of Internet2 web site due up by 14-Feb-01

Internet2 and Stephen F Austin A Can we defeat distance as a barrier to: • human collaboration? • effective access to key instruments / data sources? A For very large research universities, this is somewhat important, but it is key for smaller ones!

Applications Communities A General notion: distributed sets of researchers who collaborate at a distance • High Energy Physics (CERN, MIT, Caltech) • Space Physics & Aeronomy Research Collaboratory • Geospatial Information Systems community A These groups explore why advanced Internet2 infrastructure is important