RFC 1017
Network requirements for scientific research: Internet task force on scientific computing
RFC 1017: Network Requirements for Scientific Research 🎀
okay bestie, this one is giving requirements doc energy 💅 It's from the Network Working Group, written by Barry M. Leiner of RIACS, dated August 1987, and it was put together by the Internet Task Force on Scientific Computing. The original doesn't state a category, and it doesn't list anything it obsoletes or updates, so there's nothing to tick off there ✨
Status of This Memo ✨
ok so this one literally calls itself an "idea" paper 💡 It identifies what communication networks need to do for scientific research, and it proposes some specific areas for near term work plus some long term goals. Discussion is strongly encouraged, so come talk about it 🫶 And distribution of this memo is unlimited 🌈
Introduction 🦋
Computer networks are critical to scientific research 🔥 Parts of the scientific community are already using them to reach remote resources (like supercomputers and data at collaborators' sites) and to work together through things like electronic mail and shared databases. There's a big push to give these capabilities to the broad scientific community in a unified way, as this workshop shows 💜 And in the future, these capabilities will even be required in space, since the Space Station is becoming a real scientific research resource 🧚
The purpose of this paper is to identify the range of requirements for networks that support scientific research 🎀 Those requirements run from the basic connectivity provided by the links and switches of the network, through the basic network functions, up to the user services that are needed to make the interconnected network actually usable. The paper has four sections. Section 1 discusses the functions a user needs from a network. Section 2 discusses the requirements for the underlying link and node infrastructure. Section 3 proposes a set of specifications to achieve the functions on an end-to-end basis. Section 4 discusses a number of network-oriented user services that are needed in addition to the network itself. In each section, the discussion is split into two categories. The first covers near term requirements: the capabilities and functions that are needed today and for which technology is available to perform the function. The second covers long term goals: capabilities for which additional research is needed 🌸
This RFC was produced by the IAB Task Force on Scientific Computing, which is chartered to investigate advanced networking requirements that come out of scientific applications. Work reported here was supported in part by Cooperative Agreement NCC 2-387 from the National Aeronautics and Space Administration (NASA) to the Universities Space Research Association (USRA) 🏆
1. Network Functions 🌸
This section covers the functions and capabilities that networks, and especially internetworks, should be expected to support in the near term future 💫
Near Term Requirements 💖
There are lots of functions that are currently available to subsets of the user community. These functions should be made available to the broad scientific community ✨
User/Resource Connectivity 🔗
Obviously the first order of business in networking is providing interconnectivity between users and the resources they need 👑 The near term goal for internetworking should be to extend connectivity as widely as possible, i.e., to provide ubiquitous connectivity among users and between users and resources. Note that a network path existing between sites does not automatically mean that communities or resources using non-compatible protocol suites can interoperate. However, a minimal set of functions should be provided across the entire user community, independent of the protocol suite being used. These typically include electronic mail at a minimum, and file transfer and remote login capabilities must also be provided 📬
Home Usage 🏡
One condition that could really boost current scientific computing would be extending to the home the same level of network support that the scientist has in their office environment. As network access becomes more and more widespread, extending it to the home lets the user keep computing from home without dramatic changes to their work habits, rather than being based on limited access 🌈
Charging 💸
The scientific user should not have to worry about the costs of data communications any more than they worry about voice communications (their office telephone), so that data communications become an integral and low-cost part of our national infrastructure. This implies that charges for network services must NOT be volume sensitive and must NOT be charged back to the individual. Either of these conditions forces the user to consider network resources as scarce, which means they need their own attention to conserve them. That kind of attention to extraneous details not only detracts from the research, it fundamentally impacts the use and benefit that networking is meant to supply 😤 This does not require that networking usage be free. It should either be low enough cost that the individual does not have to be accountable for "normal" usage, or be managed in such a way that the individual does not have to be concerned with it on a daily basis 🧃
Applications 📱
Most applications that must be supported in an internetwork environment in the near term are essentially extensions of current ones. In particular:
Electronic Mail 📧 Electronic mail will increase in value as the extended interconnectivity provided by internetworking gives a much greater reachability of users 💌
Multimedia Mail 🎞 An enhancement to text-based mail that includes capabilities such as figures, diagrams, graphs, and digitized voice 🎨
Multimedia Conferencing 🎥 Network conferencing is communication among multiple people at the same time. Conferencing may or may not happen in "real time", which means all participants may not be required to be online at the same time. The multimedia supported may include text, voice, video, graphics, and possibly other capabilities 🍓
File Transfer 📂 The ability to transfer data files 📁
Bulk Transfer 📦 The ability to stream large quantities of data 🌊
Interactive Remote Login ⌨️ The ability to perform remote terminal connections to hosts 🖥️
Remote Job Entry 🗂️ The ability to submit batch jobs to remote hosts for processing and to receive the output 📤
Applications which need support in the near term but are NOT extensions of currently supported applications include:
Remote Instrument Control 🎛️ This normally presumes that there is a human in the "control loop". That condition relaxes the requirements on the (inter)network somewhat when it comes to response times and reliability. Timing would be presumed to be commensurate with human reactions, and reliability would not be as stringent as what's required for completely automatic control ⏱️
Remote Data Acquisition 🧪 This supports the collection of experimental data where the experiment is remotely located from the collection center. This requirement can only be satisfied when the bandwidth, reliability, and predictability of network response are sufficient. This cannot be supported in the general sense, because of the enormous bandwidth, very high reliability, and/or guaranteed short response time required for many experiments 🚨
These last two requirements are especially crucial when you think about remote experimentation like what will be performed on the Space Station 🚀
Capabilities ⚖️
The applications above could be best supported on a network with infinite bandwidth, zero delay, and perfect reliability. Unfortunately, even currently feasible approximations of those levels of capability can be very expensive. Therefore, it can be expected that compromises will be made for each capability and between them, with different balances struck on different networks. Because of this, the user must be given an opportunity to declare which capability or capabilities are of most interest, most likely through a "type-of-service" required declaration. Some examples of possible trade-offs:
File Transport normally requires high reliability primarily and high bandwidth secondarily. Delay is not as important 📦
Bulk Transport 🎬 Some applications, such as digitized video, might require high bandwidth as the most important capability. Depending on the application, delay would be second, and reliability would be of lesser importance. Image transfers of scientific data sometimes will invert the latter two requirements 🖼️
Interactive Traffic ⚡ This normally requires low delay as a primary consideration. Reliability may be secondary depending on the application. Bandwidth would usually be of least importance 💨
Standards 📜
The use of standards in networking is directed toward interoperability and the availability of commercial equipment. However, as stated earlier, full interoperability across the entire scientific community is probably not a reasonable goal for internetworking in the near term, because of the protocol mix now present. That is not to say, though, that the use of standards should not be pursued on the path to full user interoperability. In the context of near term goal support, standards include:
Media Exchange Standards 🖼️ Would allow the interchange of equations, graphics, images, and databases, as well as text 🔁
Commercially Available Standards 🛒 Plug-compatible, commercially available standards will allow a degree of interoperability prior to the widespread availability of the ISO standard protocols 🧩
Long Term Goals 🔮
In the future, the internetwork should be transparent communications between users and resources, and provide the additional network services required to make use of that communications. A user should be able to access whatever resources are available just as if the resource were in the office. The same high level of service should exist independent of which network one happens to be on. In fact, one should not even be able to tell that the network is there! 🫥✨
It is also important that people be able to work effectively while at home or when traveling. Wherever one may happen to be, it should be possible to "plug into" the internetwork and read mail, access files, control remote instruments, and have the same kind of environment one is used to at the office 🧳
Services to locate required facilities and take advantage of them must also be available on the network. These range from the basic "white" and "yellow" pages, providing network locations (addresses) for users and capabilities, all the way through to distributed databases and computing facilities. Eventually, this conglomeration of computers, workstations, networks, and other computing resources will become one gigantic distributed "world computer" with a very large number of processing nodes all over the world 🌍🌈💖✨
2. NETWORK CONNECTIVITY ✨
Okay bestie, section 2 is all about network connectivity, which just means being able to move packets from one point to another 📦💖. It's the foundation for everything else, so we have to get it right.
Quick heads up: this paper assumes packet switched networks are the preferred tech for a scientific computer network 🦋. Why? They can share the available link resources to connect tons of sites, and they handle "bursty" computer communication like a total queen 👑.
Note that this doesn't automatically mean functional interoperability 🙈, since the endpoints MAY be using incompatible protocols. So this section is about shared links and interconnected networks giving us a possible path 🛤️, and the next section is about actually using those paths for functional connectivity 🫶.
Here we talk about why we need these network paths for a wide set of users and resources, and what those paths are like 🌸. Like the other sections, this one is split into two categories: stuff we think we can totally do with the tech and implementations we have right now ✅, and stuff that still needs research 🔬.
Near Term Objectives
Right now there's a whole bunch of networks serving the scientific community: Arpanet, MFEnet, SPAN, NASnet, and the NSFnet backbone 🌈. There's a loose link between each network and the disciplines it serves, but honestly these networks are organized more around Federal funding 💸. And while a lot of them are interconnected, there's still a LOT of room for sharing these resources more 👀.
So in the near term there are two major requirement areas: connectivity based on discipline and user community, and effective use of adequate networking resources 💜.
Discipline Connectivity
Scientists in a particular community or discipline need access to lots of common resources, and they need to talk to each other 🧚. Like, the quantum physics research crowd gets funding from a bunch of Federal sources, but they do their research inside a scientific discourse that often overlaps several disciplines 🔭. Because networks are usually set up around the funding source, that connectivity has been blocked in the past 😭.
NSFnet is a big step forward 🎀. Its whole philosophy is acting as an interconnectivity network between supercomputer centers and between state, regional, and therefore campus networks. This move toward interconnected networks, at least at the packet transport level, MUST be continued, so a scientist can connect their local computing equipment to the computing and other resources they need, no matter where the funding came from 🦋.
Obviously, actually using those resources depends on getting access permission from the controlling organization 🔐. For example, using a supercomputer will require permission and some allocation of computing resources 🖥️. But the lack of network access SHOULD NOT be the thing that limits resource use 💅.
Communication Resource Sharing
The scientific community is always going to be short on bandwidth and connections 😩. Some requirements (like graphic animation from supercomputers) push even the most advanced long-haul networks to their limits 🥵. And as more and more scientists need network connections, providing them on a network-centric basis is going to get harder and harder 🫠.
BUT, the communication links (like leased lines and satellite channels) that form the underlying topology of the various networks span, in aggregate, a super broad range of scientific community sites 🛰️. So if the networks could share these links in an effective way, two things could happen:
- The need to add links just to support a particular network topology change would be decreased, and
- New user sites could be connected more readily.
Existing tech (namely the DARPA-developed gateway system based on the Internet Protocol, IP) gives us an effective method for doing this sharing 🎉. By using IP gateways to connect the various networks, and by arranging suitable cost-sharing, the underlying connectivity would be greatly expanded, and both of the above objectives achieved ✨.
Expansion of Physical Structure
Unfortunately, just interconnecting the various networks does not increase the bandwidth available 😤. It MAY allow for more effective use of that available bandwidth, but a sufficient number of links with adequate bandwidth MUST be provided to avoid network congestion 🚧. This already happened on the Arpanet: the network got used more and more without a matching expansion in the trunking and topology, which led to congestion and consequent degradation in performance 📉.
So it's necessary to augment the current physical structure (links and switches) in two ways: by increasing the bandwidth of the current configuration, and by adding additional links and switches where appropriate 🏗️.
Network Engineering
One of the major deficiencies in the current system of networks is the lack of overall engineering 😬. Each of the networks is generally well supported, but there's woefully little engineering of the overall system 🙃. As the networks get interconnected into a larger system, this need is going to get way more severe 💀. Examples of areas where engineering is needed are:
- Topology engineering-deciding where links and switches should be installed or upgraded. If the interconnection of the networks is achieved, this will often involve deciding which networks need to be upgraded, as well as deciding where in the network those upgrades SHOULD take place 🗺️.
- Connection Engineering-when a user site wants to be connected, figuring out which node of which network is the best for that site, considering things like existing node locations, available bandwidth, and expected traffic patterns to/from that site 🔌.
- Operations and Maintenance-keeping an eye on the operation of the overall system and figuring out corrective actions when failures happen 🔧.
Support of Different Types of Service
Several different end user applications are already in place, and they put different demands on the underlying structure 🎮. For example, interactive remote login needs low delay, while file transfer needs high bandwidth 💨. So when installing additional links and switches, it's important to give care to providing a mix of link characteristics 🧩. High bandwidth satellite channels MAY be appropriate for broadcast applications or graphics, while low delay will be REQUIRED to support interactive applications 🛰️.
Future Goals
Significant expansion of the underlying transport mechanisms will be REQUIRED to support future scientific networking 🔮. These expansions will be both in size and performance, so we're talking big upgrades, bestie 🚀.
Bandwidth
Bandwidth requirements are climbing higher thanks to advances in computer technology and the proliferation of that tech 📈. As high performance graphics workstations team up with supercomputers, and real-time remote robotics and experimental control become a reality, bandwidth needs keep growing 🤖. Plus, as the number of sites on the networks increases, so does the aggregate bandwidth requirement 🌐.
BUT, at the same time, the underlying bandwidth capabilities are also increasing. Satellite bandwidths of tens of megabits are available, and fiber optics technologies are providing extremely high bandwidths in the range of gigabits ✨. So it's essential that the underlying connectivity take advantage of these advances in communications to increase the available end-to-end bandwidth 💅.
Expressway Routing
As higher levels of internet connectivity show up, there's going to be a whole new set of problems related to lowest hop count and lowest delay routing metrics 🛣️. The assumed internet connectivity can easily present situations where the highest speed, lowest delay route between two nodes on the same net goes through a route on another network 🏎️.
Picture two sites at opposite ends of the country, both on the same multipoint internet, where their network is also gatewayed to some other network with high speed transcontinental links ✈️. The routing algorithms MUST be able to handle these situations gracefully 💜, and they become even more important when handling global type-of-service routing 🌍.
3. NETWORK SPECIFICATIONS ✨
To achieve the end-to-end user functions we talked about in section 2, it isn't enough to just provide the underlying connectivity from the last section 🫶. The network MUST provide a certain set of capabilities on an end-to-end basis 💖. In this section we get into the network specifications that are REQUIRED to do that 📋.
Near Term Specifications
In the near term, the requirements on the networks come in two parts 🎀. First, the networks need to provide the functions that permit full interoperability. Second, the internetwork MUST address the additional requirements that come up when networks, users, and resources get connected 🔗.
Interoperability
A first-order requirement for scientific computer networks (and computer networks in general) is that they be interoperable with each other, as we talked about in the connectivity section 🤝. A first step to make this happen is using IP. IP lets individual networks built by different agencies combine resources and cut costs by avoiding needless duplication of network resources and their management 💰.
However, use of IP does not provide end-to-end interoperability. There MUST also be compatibility of higher level functions and protocols 🧩. At a minimum, while commonly agreed upon standards (like the ISO developments) are still in the works, methods for interoperability between different protocol suites MUST be developed 🛠️. That would give us interoperability for functions like file transfer, electronic mail, and remote login 📧. The emphasis, however, SHOULD be on developing agreement within the scientific community on using a standard set of protocols 🤓.
Access Control
The design of the network SHOULD include adequate methods for controlling access to the network by unauthorized personnel 🚪. This especially includes access to network capabilities that are reachable via the commercial phone network and public data nets 📞. For example, terminal servers that let users dial up via commercial phone lines SHOULD have adequate authentication mechanisms in place to keep out unauthorized individuals 🔐.
However, it SHOULD be noted that most hosts reachable via such networks are also reachable via other "non-network" means, like directly dialing over commercial phone lines ☎️. The purpose of network access control is not to ensure isolation of hosts from unauthorized users, and hosts SHOULD NOT expect the network itself to protect them from "hackers" 💀.
Real talk: the network is not your bodyguard, so hosts have to protect themselves too 🙈
Privacy 🔐
okay so the network should protect the data moving through it in a way that matches how sensitive that data is 🫶. the scientific requirements for privacy of data on networks don't justify a huge pile of resources here, so it's not a top priority 💅. BUT nothing in the network design should block link level or end-to-end encryption, or other methods that can get added later ✨. like, the examples are KG-84A link encryptors on MILNET and the Fig Leaf DES-based end-to-end encryption box that DARPA made 🔒.
Accounting 📊
the network should have solid accounting procedures so you can track how much network stuff gets used 🧾. this matters for managing the network, and especially for managing the connections to other networks 🌐. when you use the accounting database properly, the people running the network can figure out the "flows" of data and spot bottlenecks in network resources 👀. it's also useful for tracking down intrusions, and for having an audit trail if someone is maliciously abusing the network 🕵️♀️. higher level services, like terminal serving, should get tracked for the same reasons too 💜.
Type of Service Routing 🚦
type of service routing is lowkey necessary, because not all network activity needs the same resources, and there's a huge opportunity to cut back on the expensive stuff 🤑. like, interactive traffic such as remote login needs low delay so the network doesn't bottleneck the user trying to get work done 🙈. but interactive traffic can have a pretty small bandwidth compared to file transfer and mail, which aren't response time critical 📬. without type of service routing, you'd have to size network resources for the biggest user and make everything feel nice for the most finicky user 😤. that's a big cost problem, because high-delay links, like satellite links, can't be used for interactive traffic even though they save a lot of money compared to terrestrial links 🛰️. with type of service routing in the network gateways, plus proper software in the hosts to use it, overall performance can get a glow-up and you can save a sizable amount of money 🤩. and since the IP protocol already has provisions for this kind of routing, changing existing implementations doesn't require a major change to the underlying protocol implementations 🔧.
Administration of Address Space 🏠
local administration of network address space is essential, bestie 🗝️. it lets hosts get added to the network quickly and keeps the load off backbone network administrators 🙌. a distributed name to address translation service has similar perks too ✨. the DARPA Name Domain system that's currently used on the Internet is a suitable implementation of that kind of name to address translation system 💖.
Remote Procedure Call Libraries 📚
so that distributed network utilities can easily talk to each other in a standard way, a standard Remote Procedure Call (RPC) library must be deployed 🎀. the computer industry has led the research community when it comes to RPC implementations, but current ones tend to be compatible within the same type of operating system and NOT across operating systems 😭. still, a portable RPC implementation that can be standardized would give a major boost to writing operating system independent network utilities 🚀. if somebody designs a new RPC mechanism from scratch, it must have enough capabilities to lure implementors away from current standards 💅. otherwise, it makes more sense to modify an existing standard that's already close to the mark in capabilities, with vendors on board so implementations exist for all the major operating systems in use on the network 🫶.
Remote Job Entry (RJE) 🖨️
the capabilities of standard network RJE implementations are inadequate, even though they're implemented all over the place among major operating systems 🙃. RJE gives off dated vibes, like punch cards, but the concept is still valid and science users love it as a way to interact with supercomputers 🧠. all the major supercomputer manufacturers support RJE access in their operating systems, but a lot of them don't generalize well into the Internet domain 💀. an RJE standard built for 2400 baud modem access from a card reader may not be easily modifiable for use on the Internet 📠. still, being able to submit a job from one host and have its output delivered to a printer attached to a different host would be welcomed by most science users 🥹. and if that capability interoperates with existing RJE packages, the whole system gets a large amount of extra flexibility 🌈.
Multiple Virtual Connections 🔗
having multiple network connections open from a user's workstation to remote network hosts is an invaluable tool, and it seriously boosts user productivity 💅✨. the network design should not place limits on this, whether procedural or otherwise 🙅♀️.
Network Operation and Management Tools 🧙♀️
right now, internet technology needs people who are, as the trade calls them, network "wizards" to properly operate and manage networks 🪄. these people are a scarce resource to begin with, and wasting them on day to day operational issues takes away from progress in the more developmental areas of networking 😩. the big reason for this is that a good chunk of the knowledge needed to run and manage a network has never been written down concisely, because networks like this were mainly used as a research tool and not as an operational resource 📖. usage has changed, but the technology hasn't caught up to the new reality that a wizard may not be nearby when a problem pops up 😬. so, to make sure the network can flexibly expand in the future, new tools need to be developed that let non-wizards monitor network performance, figure out trouble spots, and implement repairs or 'work-arounds' 🛠️💖.
4. USER SERVICES 🌸
the user services of the network are a key part of making it directly useful to scientists ✨. without the right user services, network users split into artificial subclasses based on how sophisticated they are at picking up network skills 😔. flexible information dissemination levels the playing field, so the network works just as well for different kinds of users 🫶.
Near Term Requirements ⭐
in the near term, the focus is on providing the services that let users take advantage of the functions the interconnected network provides 🦋.
Directory services 📖✨
Okay bestie, a huge chunk of networking is basically directory stuff 📖. The user needs to reach resources on the network, and they need a name or an address to do it. Like, where do we even start 😭
White Pages
The network needs to give us ways to look up the names and addresses of people and hosts on the network 🔍. Flexible searches should be possible on multiple aspects of the directory listing 💅. Some of these services are normally transparent to the user, and the user/host name to address translation is one example 🫥.
Yellow Pages
Other kinds of information lookup are based on cataloging and classification of information about resources on the networks 📚🌈. This is the yellow pages energy, iykyk 💛.
Information Sharing Services
This section is giving sharing is caring 🫶. Let's get into it.
Bulletin Boards
Okay, the bulletin board is the one-to-many version of email 📣💌. It's a forum for discussion and interchange of information 💬. Accessibility is network-wide, depending on how the particular bulletin board is defined 🌐.
Currently SMTP and UUCP are used to transport postings for many bulletin boards, but any similar electronic mail transport can be swapped in without changing the underlying concept 🔁. An effectively open-ended recipient list is the recipient of a message, and that message then counts as a bulletin board posting 🫧. There's a convention for which transport protocols get used for a particular set of bulletin boards 📜.
The user agent used to access the Bulletin Board may vary from host to host 💻. Some host resources on the network step through the symbolic mail address of the Bulletin Board, expanding it into its constituent parts, and they also relay postings as a service to the network 🪄. Tied to all of this is maintaining the lists used to distribute the postings. That includes answering requests from Bulletin Board readers and host Bulletin Board managers, plus drawing the right conclusions from recurring automatically generated or error messages that come back from distribution attempts 🧹✨.
Community Archiving
Much information can be shared over the network 🗂️. At some point, though, each particular information item reaches the stage where it's no longer appropriate to keep it online and accessible 🕰️. When a file moves to offline storage, a network can give its hosts a big economy 💸 if information of interest to several of them only needs to be stored offline once. Procedures then exist for querying and retrieving from the set of offline stored files 🔎.
Shared/distributed file system
It should be possible for a user on the network to look at a broadly defined collection of information on the network as one useful whole 🧩. To make that happen, standards for accessing files remotely are necessary 📂. These standards should include means for random access to remote files, similar to what's generally used on a single computer system 💾.
Distributed Databases and Archives
As more scientific disciplines computerize their data archives and catalogs, mechanisms will have to be provided to support distributed access to these resources 🔬. Fundamentally new kinds of collaborative research will become possible when such resources and access mechanisms are widely available 🚀✨.
Resource Sharing Services
When sharing the resources or services available on the network, certain ancillary services are needed depending on the resource 🤝.
Legalities of Interagency Research Internet ⚖️
To make the multiply-sponsored internetwork feasible, the federal budget will have to recognize that some usage outside a particular budget category may occur 🏛️. This permits cross-utilization of agency-funded resources 🔄. For example, NSFnet researchers would be able to access supercomputers over NASnet 🖥️.
In return, the total cost to the government will be significantly reduced because of the benefits of sharing network and other resources, rather than duplicating them 💰🫶.
Standards 📏
In order for the networking needs of scientific computing to be met, new standards are going to evolve 🌱. It's important that they be tested under actual use conditions, and that feedback be used to refine them 🧪.
Since the standards for scientific communication and networking are to be experimented with, they are more dynamic than those in other electronic communication fields 🌀. It's critical that the resources of the network be spent on promulgating experimental standards and on maximizing the range of the community using them 📣. To this end, sharing the results of the testing is important 🫶.
User-oriented Documentation 📘
The functionality of the network should be available widely, without the costly need to refer requests to experts for formulation 🙋♀️. A basic information facility in the network should therefore be developed 🧭. The network should be self-documenting via online help files, interactive tutorials, and good design 💻. In addition, concise, well-indexed and complete printed documentation should be available 🖨️.
CONCLUSION 🎀
In this paper, we have tried to describe the functions required of the interconnected national network to support scientific research 🔭. These functions range from basic connectivity all the way through to the provision for powerful distributed user services 🌈.
Many of the goals described in this paper are achievable with current technology 💅. They require coordination of the various networking activities, agreement to share costs and technologies, and agreement to use common protocols and standards in the provision of those functions 🤝. Other goals require further research, and there the coordination of efforts and sharing of results will be key to getting those results to the scientific user 🧑🔬.
For these reasons, we welcome the initiative represented by this workshop, where government agencies join forces to provide the best network facilities possible in support of scientific research 👑🫶.
APPENDIX 🧚
Internet Task Force on Scientific Computing
Rick Adrion University of Massachusetts
Ron Bailey NASA Ames Research Center
Rick Bogart Stanford University
Bob Brown RIACS
Dave Farber University of Delaware
Alan Katz USC Information Science Institute
Jim Leighton Lawrence Livermore Laboratories
Keith Lantz Stanford University
Barry Leiner (chair) RIACS
Milo Medin NASA Ames Research Center
Mike Muuss US Army Ballistics Research Laboratory
Harvey Newman California Institute of Technology
David Roode Intellicorp
Ari Ollikainen General Electric
Peter Shames Space Telescope Science Institute
Phil Scherrer Stanford University📦 where this page comes from
- ietf: rfc1017 1987-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms