Minutes interim-1994-iab-09 1994-12-07
minutes-interim-1994-iab-09-19941207-00

IAB Open Meeting

Reported by Abel Weinrib/Intel

An on-line copy of these and other IAB minutes are available from http://www.iab.org/documents/IABmins.

Not All RFCs are Standard

The open meeting of the Internet Architecture Board at the San Jose IETF started out with a presentation by Jon Postel on “Not All RFC are Standard.” The issue is that there are a number of grades of RFC (Informational, Experimental, Proposed/Draft/Standard, Historic) and people get confused about which do and which do not describe Internet standards. The status of an RFC is usually clearly stated on the front page and in the RFC index, this does not help the naive user who does not have a copy of the document and may incorrectly believe that all RFCs describe standards. Jon discussed the reasons that a single RFC series is considered valuable, and then went on to describe the proposed fix, which is to encourage the use of the STD number rather than the RFC number when referencing an Internet standard. An advantage of this practice is that the STD number does not change as the standard goes through revisions, whereas the RFC(s) describing the standard will change. User education is an important part of this; in addition, Jon is in the preliminary stages of using WWW technology to create a standards directory with hypertext links to the relevant RFCs. The need for user education was highlighted by the fact that no one in the room knew what STD 5 is.

Commercialization of the Internet

The second presentation, prepared by Yakov Rekhter and Lixia Zhang and presented by Lixia, discussed the commercialization of the Internet. Lixia described the Internet environment of the past, where it is going now, and made some suggestions about what the IETF should do about it. Up until recently, the Internet made the transition from a research testbed to a tool used and depended upon by the research and education community. Now, the Internet is undergoing a rapid transition to a public facility open for use by all. The applications, the user community, and the infrastructure are all becoming commercialized at the same time. The IETF continues to provide technical solutions to support Internet development and growth, but the rapid transition is also raising many non-technical issues that must be addressed (but it is not yet clear by whom). The technical issues that must be addressed include better understanding the requirements from commercial users on network security, network management, accounting and billing and support for electronic commerce, as well as continuing to make progress on routing over multi-provider interconnections, introducing support for integrated services, and so on.

Routing in a Multi-Provider Internet

Yakov Rekhter gave a presentation on “Routing in a Multi-Provider Internet.” He described the current environment as one in which multiple network service providers are driven by diverse and sometimes conflicting goals. There is no central control over service providers, they often compete with each other, and they do not always coordinate effectively with each other. However, Internet-wide connectivity is possible only with a degree of cooperation and coordination. Yakov then went on to discuss routing requirements. Open questions include which are the most important requirements and who is to bear the cost of supporting the requirements. Scalability is a critical issue in routing, with a system that scales linearly with the number of providers one possibility. The talk ended with some other issues, such as other routing issues (multicast, mobile hosts) and the impact of a multi-provider Internet on other areas, such as network management.

There was considerable discussion following Yakov’s talk questioning the desirability of provider-based addressing for IPv6. Other topics included who “owns” the address space, how to financially compensate the registries so that they can continue to operate (one suggestion was to charge for queries to the registry rather than for storage of the information), and the specter of regulation of Internet service providers.

The Internet Service Model

The final presentation was by Christian Huitema, who asked the question “The Internet Service Model: should we upgrade it?”. He described the current model, which provides connectivity (“IP over everything”) and best effort service with simple gateways and end-to-end controls. The current challenge is to control the service to support applications with more stringent real-time requirements, and to control the usage to avoid the risk of congestion. Proposed solutions include resource reservation with admission control to provide some form of service guarantees, fair queueing to isolate the “bad guys,” fair policing to punish the “bad guys,” and bandwidth sharing that enforces various policies. Christian ended his talk by raising a number of issues for debate, including what the service model should become, what router requirements should become, and so on.

Routing in a Multi-Provider Internet

Yakov Rekhter

IBM Research Division T.J. Watson Research Center

yakov@watson.ibm.com

December 2, 1994

Current Environment

• Multiple Network Service Providers (NSPs) driven by diverse and sometimes even conflicting goals and objectives:

  Mission oriented NSPs (e.g. NSI)

  Commercial NSPs (e.g. Alternet, PSI, etc…)

  An NSP may constrain reselling connectivity

  An NSP may be subject to regulations

  Wide variations in the scope of geographical coverage

Current Environment (cont.)

• No centralized control over NSPs
• NSPs don’t alway coordinate with each other
• Competition among NSPs

Current Environment (cont.)

• Despite the diversity among NSPs, Internet-wide connectivity requires certain degree of cooperation and coordination among NSPs.
• Need to balance the NSPs’ goals and objectives against public interest of Internet-wide connectivity and subscribers’ choices.

Routing Requirements

• Conceptual taxonomy
  • Source preferences
  • Destination preferences
  • Transit traffic constraints
• Wide variability with respect to the degree of control
• What are the most important requirements ?

Routing Requirements(cont.)

• Support for a routing requirement doesn’t come for free.
• Who bears the cost ?
  • ideally should be shifted towards the entity that instigates the requirement
  • an organization shouldn’t unilaterally impose burden on other organizations
  • need to perform cost/benefit analysis associated with a requirement
• Ability of an organization to instantiate its routing requirements in a more or less central (to the organization) fashion

Scalability

• Ability to scale – key requirement for the Internet routing system

  – CPU, memory, bandwidth

  – human resources
  + System that scales linearly with the number of networks or even sites

  – unacceptable today (CIDR is the best proof )

  – unlikely to be acceptable in the future
  + Can we operate with a system that scales linearly with the number of providers ?

  – how does the number of providers grow with the number of sites ?

Scalability(cont.)

• Scalability implies information aggregation/abstraction
  • Need to impose minimum preconditions
  • Need to limit the amount of required inter-provider coordination

• Information aggregation/abstraction implies losses of information

  – impact on route optimality

  – impact on the ability to find a route
  + Aggregation/abstraction implies certain homogeneity

  – needs to be balanced against potential diversity of routing requirements

Scalability(cont.)

• Overhead due to routing requirements and its impact on scalability
• Need to explore mechanisms to acquire routing information “on demand”

Hierarchical Routing

• CIDR is a realization of hierarchical routing
• To provide routing information reduction Network layer addresses must be “topologically significant”

• Changes in the network topology may require changes in the IP addresses (“renumbering”)

  – changing providers

  – need tools to facilitate renumbering
  + Multi-layer hierarchy allows to recapture routing entropy
  + Hierarchical addresses are not a MUST

  – large organizations can have their own address prefixes carried through the Internet

Encapsulation

• Allows an entity to create a “virtual” IP overlay
• Where is the source address (outer or inner header) ?
• Where is the destination address (outer or inner header) ?
  • What is the semantics of transit policies ?
  • What is the semantics of source preferences ?
  • What is the semantics of destination preferences ?

Routing Information Sharing

• Internet-wide coordination is going to be more and more difficult to achieve
• Sharing information about organization’s routing requirements could benefit stability and consistency of Inter-wide routing
• Role of Routing Registries

Conclusions

• Presented some, but not all, of the issues

  – multicast routing ?

  – routing in presence of mobile hosts ?

  – routing in presence of large shared media (e.g. ATM) ?
  + Impact of multi-provider Internet goes beyond routing (e.g. network management)
  + Need to understand interaction among all the areas involved from a system-wide perspective

Commercialization of the Internet

Commercialization of the Internet

Yakov Rekhter & Lixia Zhang

IAB Open Meeting

DEC’94 IETF
- What we’ve had in the past
- Where the Internet is going today
- What IETF should do

What We’ve Had in the Past

• The ARPANET days
• Creation of the Internet
  • Design of TCP/IP architecture
• NSFNET days
  • A transition from a research sandbox to an infrastructure for production use by R&E community

Where the Internet Is Going Today

• The Internet is undergoing a rapid transition from an R&E infrastructure to a public facility
• As we move from one stage to the next, network requirements change rapidly and significantly
  • E.g. security
• Commercialization started when the first commercial traffic crossed the Internet

Commercialization of the Internet

• Commercialization of applications

  We’re not the only one who found the Internet useful
  + Commercialization of user community
  + Commercialization of the infrastructure (service providers)
  + These three forces interact, creating a positive feedback that further accelerate the process

Why All These Changes?

• We (IETF) made this happen

  1 New technology development by government sponsored research

  ARPANET, early days of the Internet2 Technology mature
  
  NSFNET backbone was built as an infrastructure for research/educational use3 Technology transfer
  
  As commercial providers picking up the technology, NSF started buying services for research&educational use4 Market development
  
  End users buy services directly from commercial providers (with gov. subsidy to R&E community)
  

Non-Technical Issues

• IETF has been providing technology solutions to Internet development and growth

• Commercialization, however, also brought up many new and important non-technical issues. e.g.:

  • • trademark wars over DNS names

  • copyright issue of various electronic documents

  • Question: on whose agenda lay these non-technical problems?

What IETF Should Do during this commercialization

• Applaud the change: the Internet finally grown up!
• Facilitate the change: continue to provide the technology for further Internet growth & development
• Extend the Internet service to multicast-capable integrated services
• Routing over multi-provider interconnections
• Better understand the requirements from commercial users
  • network security
  • network management of multi-provider interconnections
  • accounting and billing mechanisms
  • electronic commerce
  • ……
• Maintain a system-wide perspective of overall architecture

We Have a lot to Accomplish