Mills@UDEL.EDU.UUCP (11/08/87)
Folks, This is a repeat of last month's announcement on a planned meeting of the Internet Architecture Task Force. Please note the meeting dates have been changed from the original 17-18 November to 17-18 December. The meeting place is unchanged. Please note also the revised and clarified wording in the announcement itself. The Internet Architecture Task Force (INARC) studies technical issues in the evolution of the Internet from its present architectural model to new models appropriate for very large, very fast internets of the future. It is organized as a recurring workshop where researchers, designers and implementors can discuss novel ideas and experiences without limitation to the architecture and engineering of the present Internet. The output of this effort represents advance planning for a next-generation internet, as well as fresh insights into the problems of the current one. The INARC is planning a two-day retreat/workshop for 17-18 December at BBN to discuss a fresh start on advanced internet concepts and issues. The agenda for this meeting will be to explore architecture and engineering issues in the design of a next-generation internet system. The format will consist of invited presentations on selected topics followed by a general discussion on related issues. Written contributions of suitable format and content will be submitted for publication in the ACM Computer Communication Review. In order to have the most stimulating discussion possible, the INARC is expanding the list of invitees to include any researchers with agenda to plow, axe to grind, sword to wield or any other useful instrument for that matter. While not a precondition for admission, participants are encouraged to contribute concise presentations, either written or oral (fifteen to thirty minutes), in electronic form to mills@udel.edu or in hardcopy form to Dr. David L. Mills Electrical Engineering Department University of Delaware Newark, DE 19716 (302) 451-6534 or 737-9211 Speakers will be selected on the basis of quality, relevance and interest. Every effort will be made to accomodate all participants that wish to attend; however, participants are asked to contact the chairman by electronic mail or telephone at least a week in advance to confirm their intention to attend. Following is a list of possible areas and issues of interest to the community. Readers are invited to submit additions, deletions and amendments. 1. How should the next-generation internet be structured, as a network of internets, an internet of internets or both or neither? Do we need a hierarchy of internets? Can/must the present Internet become a component of this hierarchy? 2. What routing paradigms will be appropriate for the new internet? Will the use of thinly populated routing agents be preferred over pervasive routing data distribution? Can innovative object-oriented source routing mechanisms help in reducing the impact of huge, rapidly changing data bases? 3. Can we get a handle on the issues involved in policy-based routing? Can a set of standard route restrictions (socioecononic, technopolitic or bogonmetric) be developed at reasonable cost that fit an acceptable administrational framework (with help from the Autonomous Networks Task Force)? How can we rationalize these issues with network control and access-control issues? 4. How do we handle the expected profusion of routing data? Should it be hierarchical or flat? Should it be partitioned on the basis of use, service or administrative organization? Can it be made very dynamic, at least for some fraction of clients, to support mobile hosts? Can it be made very robust in the face of hackers, earthquakes and martians? 5. Should we make a new effort to erase intrinsic route-binding in the existing addressing mechanism of the Internet IP address and ISO NSAP address? Can we evolve extrinsic binding mechanisms that are fast enough, cheap enough and large enough to be useful on an internet basis? 6. Must constraints on the size and speed of the next-generation internet be imposed? What assumptions scale on the delay, bandwidth and cost of the network components (networks and gateways) and what assumptions do not? 7. What kind of techniques will be necessary to accellerate reliable transport service from present speeds in the low megabit range to speeds in the FDDI range (low hundreds of megabits)? Can present checksum, window and backward-correction (ARQ) schemes be evolved for this service, or should we shift emphasis to forward-correction (FEC) and streaming schemes. 8. What will the internet switch architecture be like? Where will the performance bottlenecks likely be? What constraints on physical, link and network-layer protocols will be advisable in order to support the fastest speeds? Is it possible to build a range of switches running from low-cost, low-performance to high-cost, high-performance? 9. What form should a comprehensive congestion-control mechanism take? Should it be based on explicit or implicit resource binding? Should it be global in scope? Should it operate on flows, volumes or some other traffic characteristic? 10. Do we understand the technical issues involved with service-oriented routing, such as schedule-to-deadline, multiple access/multiple destination, delay/throughput reservation and resource binding? How can these issues be coupled with effective congestion-control mechanisms? 11. What will be the relative importance of delay-based versus flow-based service specifications to the client population? How will this affect the architecture and design? Can the design be made flexible enough to provide a range of services at acceptable cost? If so, can the internet operation setpoint be varied, automatically or manually, to adapt to different regimes quickly and with acceptable thrashing? 12. What should the next-generation internet header look like? Should it have a variable-length format or fixed-length format? How should options, fragmentation and lifetime be structured? Should source routing or encapsulation be an intrinsic or derived feature of the architecture? 13. What advice can we give to other task forces on the impact of the next-generation internet in their areas of study? What research agenda, if any, should we propose to the various NSF, DARPA and other agencies? What advice can we give these agencies on the importance, level of effort and probablity of success of the agenda to their current missions? Dave
Mills@UDEL.EDU (03/14/89)
WORKSHOP ON THE FUTURE OF THE INTERNET ARCHITECTURE AND PROTOCOLS
1-2 June 1989, University of Delaware
Sponsored by the Internet Architecture Task Force
and the Internet Activities Board
The Internet Activities Board (IAB) has been guiding and coordinating
the research and development activities of the DARPA/NSF Internet System
for several years. The Internet Architecture Task Force (INARC) of the
IAB has been asked to explore the inherent limitations in the existing
Internet architecture and supporting IP/TCP protocol suite and how the
lessons learned can be applied to future systems. The INARC will hold a
two-day workshop on 1-2 June 1989 at the University of Delaware to
explore these and related issues. While the emphasis of the workshop
will be on the past and future evolution of the Internet system,
specific issues relevant to other architectures, protocol suites and
migration strategies may be discussed as well.
Interested persons from all walks of network life are invited to attend.
Participants will be encouraged to present short briefings on specific
technical issues, including those suggested below, but this is not a
requirement for admission. While some participants may be invited on the
basis of their known expertise, biases and past vocalizations on these
issues, participants outside the IAB, INARC and their dependencies are
actively encouraged. In order to manage the local arrangements it is
necessary that participants register their intent to attend by
contacting the INARC chair:
David L. Mills
Electrical Engineering Department
University of Delaware
Newark, DE 19716
(302) 451-8247
mills@udel.edu
Areas of interest include, but are not limited to, the following:
1. Are the Internet architecture and protocols suitable for use on
very high-speed networks operating in the 1000 Mbps range and up?
If the network-level or transport-level protocols are not usable
directly, can they be modified or new ones developed to operate
effectively at these speeds?
2. Are the Internet addressing and gateway-routing algorithms adequate
for very large networks with millions of subscribers? If not, is it
possible to extend the addressing scope and/or develop new routing
paradigms without starting over from scratch?
3. Can the Internet model of stateless networks and stateful hosts be
evolved to include sophisticated algorithms for flow management,
congestion control and effective use of multiple, prioritized
paths? Can this be done without abandoning the estimated 60,000
hosts and 700 networks now gatewayed in the system?
4. Can the existing Internet of about 300 routing domains be evolved
to support the policy and engineering mechanisms for many thousands
of domains including education, research, commercial and government
interests? Can this be done with existing decentralized management
styles and funding sources? If not, what changes are needed and how
can they be supported, given practical limits on infrastructure
funding?