280 likes | 398 Views
What comes next in Internet infrastructure: quality of service, IPv6, and more. Brian E Carpenter Program Director, Internet Standards & Technology, IBM Co-Chair, Differentiated Services WG, IETF Previous Chair, Internet Architecture Board, IETF October 2000. Topics.
E N D
What comes next in Internet infrastructure: quality of service, IPv6, and more Brian E Carpenter Program Director, Internet Standards & Technology, IBM Co-Chair, Differentiated Services WG, IETF Previous Chair, Internet Architecture Board, IETF October 2000
Topics • How the network used to be, how it is, and how it needs to be. • Is there an integration strategy for QOS? • What QOS solutions do we have? • What’s still missing for QOS? • IPv6 • Tactical solutions today • Conclusion
How the network used to be • IP addresses were plentiful • All packets flowed “best effort” unchanged end to end • Reliability and security depended (by design) only on the two end systems of a session. • Loss caused by congestion was corrected by TCP; TCP slowed down automatically to reduce congestion. • Real time (UDP) services collapsed during congestion.
How the network is today • Addresses are scarce • Widespread use of Network Address Translators (NAT) means that packets are changed by the network. NATs are the enemy of end to end functionality and end to end security, and a management nightmare. • Security via firewalls • Packets are blocked • Sessions intercepted by gateways, proxies, and “level 4” switches • Packets are hijacked • Transparency is lost & congestion is chronic.
How the network needs to be • Congestion is inherent both during the growth phase (engineers cannot keep up) and the stable phase (marginal cost effect). Therefore, Quality of Service technology is essential. • Some transparency is gone for ever, but we have to get rid of the NATs. Therefore, IPv6 is essential.
QOS Integration: Almost everything is connected to almost everything else • Routing affects performance • Addressing affects routing • Choice of ISP affects addressing • ISP performance affects choice of ISP • Performance affects user behavior • User behavior affects load • Load affects congestion • Congestion affects performance • Performance affects web sites visited • Web sites visited affect web site survival • …
Traffic engineering ISP profitability User behavior Routing topology Addressing Which ISP? ISP performance Web sites visited Protocols used Web site performance Site profitability Congestion Load QOS technology
What strategies have any chance? • Since everything is connected to everything, and the interactions are non-linear, it is very unlikely that we can design an integrated solution with any assurance that it will succeed. • We need some guiding principles, but apart from that we have to focus on highly modular technology and an evolutionary approach. • There isn’t going to be an architecture blueprint any time soon.
Some guiding principles (1) • Single points of failure are bad. Single points of failure hidden inside the network are even worse. • Make it so that communication fails only when one or both end-systems fail. • Routes and routers must be redundant • Minimize dependencies such as firewalls, proxies, applications gateways, & translation/transcoding boxes. • If functionality is distributed, allow for automatic fallback to other copies.
Some guiding principles (2) • Simple, scaleable solutions are better than complex, monolithic ones. • Minimize use of options • Minimize dependencies • Minimize need for per-flow state information
Some guiding principles (3) • There’s too much fog on the Internet today, caused by chronic shortage of address space and the resulting use of ambiguous (“private”) addresses and temporary addresses. You’re never quite sure what you’re talking to or where it is. • This makes rational QOS policy management hard. • The only known way to get more addresses any time soon is to deploy IPv6.
One service class per microflow Integrated Services RSVP
A few pre-defined service classes Differentiated services
One model of a policy system Policy information model
Summary of QOS components • Integrated Services / RSVP • Differentiated Services • DiffServ/IntServ integration • QOS support at lower layers (ATM, 802, MPLS) • SNMP, COPS, MIBs and PIBs • LDAP, policy information model
Missing QOS components (1) • Receiver capability- how does sender or QOS system know what a receiver can absorb in a DiffServ environment? • Generally, how does an application discover end-to-end QOS requirement? • API for DiffServ as well as IntServ. • Robust mechanism for path QOS discovery.
Missing QOS components (2) • Inter-domain QOS signalling • Traffic Engineering for QOS; QOS routing redux. • Congestion control for real-time flows. • Generally agreed QOS measurement/accounting techniques. • Field experience, best current practices, inter-ISP QOS SLAs.
IPv6 • Increased size of address space (128 bits) • Simplified autoconfiguration of addresses • Improved support for site renumbering • Strong security (IPsec) mandatory to implement • Increased flexibility for supporting new options • Simplified header format for fast processing • Simplified Mobile IP design
Tactical solutions today (1) • QOS not deployed Network is congested move data nearer to user replicate data in edge servers Content Distribution Networks such as Akamai network appliances (future) distributed e-business applications. • In this area the open Internet will lead and drive the enterprise market.
Tactical solutions today (2) • Network is not transparent “Walled Garden” model (such as i-Mode or WAP) proxy, server, and content adaptation boxes. • Network is not transparent cannot deploy network level security use transport level or applications level security.
Not mentioned… • MMPLS – new technology for path switching through IP carrier infrastructure • OOptical switching – will this just speed up the backbone, or will it replace the “everything over IP” mantra? • GGRID computing and other approaches to peer-to-peer computing – will client/server cease to dominate?
Conclusions • No grand plan for QOS; no single, integrated architecture that suits all QOS-dependent applications. • Basic QOS tools are defined but several integration mechanisms are still missing. • The time for IPv6 is about 2 years away. • Meanwhile, Silicon Valley continues to get rich with pragmatic short-term solutions.