Internet2 Engineering Update

1. Internet2 Engineering Update • Guy AlmesInternet2 Chief Engineer<almes@internet2.edu> • Educom MeetingMinneapolis — 30 October 1997

2. Outline of the Talk • Internet2 Engineering Objectives • Working Groups • GigaPoP Progress • Four Key Engineering Issues • Large Delay-Bandwidth Products • Introducing Quality of Service • Improving Multicast Support • Introducing IPv6

3. Internet2 Engineering Objectives • Enable Advanced Applications • Strengthen the Universities in their Research / Education Missions • Pioneer Specific Technical Advances • Establish GigaPoPs as Effective Service Points

4. Applications and Engineering Applications Motivate Enables Engineering

5. Comments on Apps and Plumbing • Advanced applications transform high-speed plumbing into value • Advanced plumbing enables advanced applications • Profligate use of bandwidth, per se, does not make an application ‘advanced’ • Megalomaniac plumbing, per se, does not make the plumbing ‘advanced’

6. Comments on the UniversityResearch/Education Mission • Due to their teaching mission, universities scatter researchers • University faculty and students therefore have a disproportionate need to be able to collaborate at a distance

7. u u u u Sketch of Internet2 Architecture Interconnect: connects all the gigaPoPs to each other GigaPoPs: connect universities to the Interconnect and to other services Universities: upgrade their LANs to more than 500 Mb/s gigaPoP Interconnect u gigaPoP u gigaPoP gigaPoP u u u u gigaPoP

8. 1997 High-speed uncongested best-efforts IPv4 T3 and OC3 will be typical; some OC12 About 15 gigaPoPs; about 45 universities Introduction of Measurements 1998 Introduce Quality of Service Improve Multicast Support Introduce IPv6 1997 vs 1998 Sets of Aspirations

9. to address project-wide technical issues minimal constraint on natural diversity of gigaPoP technical choices complementary to groups such as the IETF Working Groups

10. IPv6: Dale Finkelson of Univ Nebraska Measurement: David Wasley of UCOP Multicast: Dave Meyer of Univ Oregon Network Mgmt: Mark Johnson of MCNC Quality of Service: Ben Teitelbaum (staff) Routing: Steve Corbato of Univ Washington Security: Peter Berger of Carnegie Mellon Topology: Paul Love (staff) Initial Working Groups

11. Oct-97

12. Nov-97

13. Dec-97

14. early 1998

15. Four Key Engineering Issues • Large Delay-Bandwidth Products • Introducing Quality of Service • Improving Multicast Support • Introducing IPv6

16. Large Delay-Bandwidth Products • As the product of delay and bandwidth grows: • The number of unacknowledged packets grows • It becomes more difficult to sustain a steady stream of data from end to end • Several consequences: • Need for direct physical paths • Tradeoff between buffering and variation in delay

17. Introducing Quality of Service • Technical: • End-to-end vs Intermediate • Host vs Proxies • Bandwidth, Delay parameters • Administrative: • Admission Control • Measurements • Authentication

18. Quality of Service Sketch B A • Does the QoS approach support the applications? • Are there implementations that work? Only one? • If cloud ‘A’ and cloud ‘B’ both implement QoS, does the combined A+B catenation implement QoS?

19. Improving Multicast Support • Current MBone community is small • Many advanced applications are naturally multicast • one to many (e.g., distance education) • few to few (e.g., graduate seminars or conferences) • Scaling is hard: • Optimize for transmission lines? • Optimize for packet forwarding?

20. IPv6 Issues • Initially this will appear to be an end in itself • We hope/expect that it will become an aid to solving other problems • Compact Routing Tables • Some help for QoS, IP options • Products will be available beginning 1997