Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “transport protocols”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS1991

TCP Packet Trace Analysis

Examination of a trace of packets collected from the network is often the only method available for diagnosing protocol performance problems in computer networks. This thesis explores the use of packet traces to diagnose performance problems of the transport protocol TCP. Unfortunately, manual examination of these traces can be so tedious that effective analysis is not possible. The primary contribution of this thesis is a graphical method of displaying the packet trace which greatly reduce, the tediousness of examining a packet trace. The graphical method is demonstrated by the examination of some packet traces of typical TCP connections. The performance of two different implementations of TCP sending data across a particular network path is compared. Traces many thousands of packets long are used to demonstrate how effectively the graphical method simplifies examination of long complicated traces. In the comparison of the two TCP implementations, the burstiness of the TCP transmitter appeared to be related to the achieved throughput. A method of quantifying this burstiness is presented and its possible relevance to understanding the performance of TCP is discussed.

Shepard, Timothy J.↗
NASA NTRS1978

Packet telemetry - A possible standard protocol for spacecraft data handling

Packetized telemetry-handling offers an opportunity to standardize major portions of the spacecraft-to-ground interface for future NASA missions. An end-to-end packet transport protocol is proposed which enables delivery of telemetry data from a remote space sensor to a ground-based user with virtually no project-unique intermediate processing. This paper reviews the possibility of creating a single telemetry format standard for both deep-space and near-earth missions. The proposed standard addresses the greatest NASA problem of the coming decade - cost - by allowing telemetry streams from many inflight spacecraft to be handled on the ground by common, simple, multimission processing elements.

Greenberg, E.↗
NASA NTRS1997

Study and Simulation of Enhancements for TCP (Transmission Control Protocol) Performance Over Noisy, High-Latency Links

The designers of the TCP/IP protocol suite explicitly included support of satellites in their design goals. The goal of the Internet Project was to design a protocol which could be layered over different networking technologies to allow them to be concatenated into an internet. The results of this project included two protocols, IP and TCP. IP is the protocol used by all elements in the network and it defines the standard packet format for IP datagrams. TCP is the end-to-end transport protocol commonly used between end systems on the Internet to derive a reliable bi-directional byte-pipe service from the underlying unreliable IP datagram service. Satellite links are explicitly mentioned in Vint Cerf's 2-page article which appeared in 1980 in CCR [2] to introduce the specifications for IP and TCP. In the past fifteen years, TCP has been demonstrated to work over many differing networking technologies, including over paths including satellites links. So if satellite links were in the minds of the designers from the beginning, what is the problem? The problem is that the performance of TCP has in some cases been disappointing. A goal of the authors of the original specification of TCP was to specify only enough behavior to ensure interoperability. The specification left a number of important decisions, in particular how much data is to be sent when, to the implementor. This was deliberately' done. By leaving performance-related decisions to the implementor, this would allow the protocol TCP to be tuned and adapted to different networks and situations in the future without the need to revise the specification of the protocol, or break interoperability. Interoperability would continue while future implementations would be allowed flexibility to adapt to needs which could not be anticipated at the time of the original protocol design.

Shepard, Timothy J.↗
NASA NTRS2003

Architecture and System Engineering Development Study of Space-Based Satellite Networks for NASA Missions

Traditional NASA missions, both near Earth and deep space, have been stovepipe in nature and point-to-point in architecture. Recently, NASA and others have conceptualized missions that required space-based networking. The notion of networks in space is a drastic shift in thinking and requires entirely new architectures, radio systems (antennas, modems, and media access), and possibly even new protocols. A full system engineering approach for some key mission architectures will occur that considers issues such as the science being performed, stationkeeping, antenna size, contact time, data rates, radio-link power requirements, media access techniques, and appropriate networking and transport protocols. This report highlights preliminary architecture concepts and key technologies that will be investigated.

Ivancic, William D.↗
NASA NTRS2023

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.0

Delay Tolerant Networking (DTN) has been identified as a key technology to enable and facilitate the development and growth of future space networks. Classically, space communications networks are collections of disparate links that are manually managed either point-to-point or use space relays. The accelerating accessibility of space enables a new scaling of space nodes, yet both the manual management of configurations and scheduling and the lack of structure connecting links precisely prohibit scaling. This challenge gives rise to newer and larger classes of communications needs that are met by DTN, which must overcome the disconnection, disruption, latency, and mobility featured in space communications systems. DTN joins the underlying links as an overlay, and can be made to communicate over any protocol stack. The core actions of DTN are store, carry, and forward, where data are stored instead of dropped if there is no immediately available outduct. It does this by taking the DTN unit of data, bundles, and providing necessary layers to adapt these bundles to the underlying transport protocols of choice; these are called convergence layers. DTN's Bundle Protocol (BP) can then be used on top of terrestrial protocol stacks, such as TCP/IP, as well as protocols for space, such as LTP/AOS, all in the same network. For emphasis it is noted that bundles can be of essentially any size, and hence this convergence to lower layers of choice is necessary. Existing DTN implementations have operated in constrained environments with limited resources, resulting in low data speeds. However, as various technologies have advanced, data transfer rates and efficiency have advanced, which has pushed the need for a DTN implementation for ground systems and for spacecraft that is performance-oriented in order to not impose an unnecessary bottleneck. High-rate Delay Tolerant Networking (HDTN) takes advantage of modern hardware platforms to substantially reduce latency and improve throughput compared to today’s DTN operations. The HDTN implementation maintains interoperability with existing deployments of DTN that conform to IETF RFCs 4838, 5050, and 9171. At the same time, HDTN defines a new data format better suited to higher-rate operation. It defines and adopts a massively parallel pipelined and message-oriented architecture, allowing the system to scale gracefully as its resources increase. HDTN’s architecture also supports hooks to replace various processing pipeline elements with specialized hardware accelerators. This offers improved Size, Weight, and Power (SWaP) characteristics while reducing development complexity and cost.

Delay Tolerant Networking↗
NASA NTRS2024

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.3.0

Delay Tolerant Networking (DTN) has been identified as a key technology to enable and facilitate the development and growth of future space networks. Classically, space communications networks are collections of disparate links that are manually managed either point-to-point or use space relays. The accelerating accessibility of space enables a new scaling of space nodes, yet both the manual management of configurations and scheduling and the lack of structure connecting links precisely prohibit scaling. This challenge gives rise to newer and larger classes of communications needs that are met by DTN, which must overcome the disconnection, disruption, latency, and mobility featured in space communications systems. DTN joins the underlying links as an overlay, and can be made to communicate over any protocol stack. The core actions of DTN are store, carry, and forward, where data are stored instead of dropped if there is no immediately available outduct. It does this by taking the DTN unit of data, bundles, and providing necessary layers to adapt these bundles to the underlying transport protocols of choice; these are called convergence layers. DTN's Bundle Protocol (BP) can then be used on top of terrestrial protocol stacks, such as TCP/IP, as well as protocols for space, such as LTP/AOS, all in the same network. For emphasis it is noted that bundles can be of essentially any size, and hence this convergence to lower layers of choice is necessary. Existing DTN implementations have operated in constrained environments with limited resources, resulting in low data speeds. However, as various technologies have advanced, data transfer rates and efficiency have advanced, which has pushed the need for a DTN implementation for ground systems and for spacecraft that is performance-oriented in order to not impose an unnecessary bottleneck. High-rate Delay Tolerant Networking (HDTN) takes advantage of modern hardware platforms to substantially reduce latency and improve throughput compared to today’s DTN operations. The HDTN implementation maintains interoperability with existing deployments of DTN that conform to IETF RFCs 4838, 5050, and 9171. At the same time, HDTN defines a new data format better suited to higher-rate operation. It defines and adopts a massively parallel pipelined and message-oriented architecture, allowing the system to scale gracefully as its resources increase. HDTN’s architecture also supports hooks to replace various processing pipeline elements with specialized hardware accelerators. This offers improved Size, Weight, and Power (SWaP) characteristics while reducing development complexity and cost.

Delay Tolerant Networking↗
NASA NTRS2011

Asynchronous Message Service Reference Implementation

This software provides a library of middleware functions with a simple application programming interface, enabling implementation of distributed applications in conformance with the CCSDS AMS (Consultative Committee for Space Data Systems Asynchronous Message Service) specification. The AMS service, and its protocols, implement an architectural concept under which the modules of mission systems may be designed as if they were to operate in isolation, each one producing and consuming mission information without explicit awareness of which other modules are currently operating. Communication relationships among such modules are self-configuring; this tends to minimize complexity in the development and operations of modular data systems. A system built on this model is a society of generally autonomous, inter-operating modules that may fluctuate freely over time in response to changing mission objectives, modules functional upgrades, and recovery from individual module failure. The purpose of AMS, then, is to reduce mission cost and risk by providing standard, reusable infrastructure for the exchange of information among data system modules in a manner that is simple to use, highly automated, flexible, robust, scalable, and efficient. The implementation is designed to spawn multiple threads of AMS functionality under the control of an AMS application program. These threads enable all members of an AMS-based, distributed application to discover one another in real time, subscribe to messages on specific topics, and to publish messages on specific topics. The query/reply (client/server) communication model is also supported. Message exchange is optionally subject to encryption (to support confidentiality) and authorization. Fault tolerance measures in the discovery protocol minimize the likelihood of overall application failure due to any single operational error anywhere in the system. The multi-threaded design simplifies processing while enabling application nodes to operate at high speeds; linked lists protected by mutex semaphores and condition variables are used for efficient, inter-thread communication. Applications may use a variety of transport protocols underlying AMS itself, including TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and message queues.

Burleigh, Scott C.↗
NASA NTRS1992

Scalable parallel communications

Coarse-grain parallelism in networking (that is, the use of multiple protocol processors running replicated software sending over several physical channels) can be used to provide gigabit communications for a single application. Since parallel network performance is highly dependent on real issues such as hardware properties (e.g., memory speeds and cache hit rates), operating system overhead (e.g., interrupt handling), and protocol performance (e.g., effect of timeouts), we have performed detailed simulations studies of both a bus-based multiprocessor workstation node (based on the Sun Galaxy MP multiprocessor) and a distributed-memory parallel computer node (based on the Touchstone DELTA) to evaluate the behavior of coarse-grain parallelism. Our results indicate: (1) coarse-grain parallelism can deliver multiple 100 Mbps with currently available hardware platforms and existing networking protocols (such as Transmission Control Protocol/Internet Protocol (TCP/IP) and parallel Fiber Distributed Data Interface (FDDI) rings); (2) scale-up is near linear in n, the number of protocol processors, and channels (for small n and up to a few hundred Mbps); and (3) since these results are based on existing hardware without specialized devices (except perhaps for some simple modifications of the FDDI boards), this is a low cost solution to providing multiple 100 Mbps on current machines. In addition, from both the performance analysis and the properties of these architectures, we conclude: (1) multiple processors providing identical services and the use of space division multiplexing for the physical channels can provide better reliability than monolithic approaches (it also provides graceful degradation and low-cost load balancing); (2) coarse-grain parallelism supports running several transport protocols in parallel to provide different types of service (for example, one TCP handles small messages for many users, other TCP's running in parallel provide high bandwidth service to a single application); and (3) coarse grain parallelism will be able to incorporate many future improvements from related work (e.g., reduced data movement, fast TCP, fine-grain parallelism) also with near linear speed-ups.

Maly, K.↗
NASA NTRS1994

TOPS On-Line: Automating the Construction and Maintenance of HTML Pages

After the Technology Opportunities Showcase (TOPS), in October, 1993, Langley Research Center's (LaRC) Information Systems Division (ISD) accepted the challenge to preserve the investment in information assembled in the TOPS exhibits by establishing a data base. Following the lead of several people at LaRC and others around the world, the HyperText Transport Protocol (HTTP) server and Mosaic were the obvious tools of choice for implementation. Initially, some TOPS exhibitors began the conventional approach of constructing HyperText Markup Language (HTML) pages of their exhibits as input to Mosaic. Considering the number of pages to construct, a better approach was conceived that would automate the construction of pages. This approach allowed completion of the data base construction in a shorter period of time using fewer resources than would have been possible with the conventional approach. It also provided flexibility for the maintenance and enhancement of the data base. Since that time, this approach has been used to automate construction of other HTML data bases. Through these experiences, it is concluded that the most effective use of the HTTP/Mosaic technology will require better tools and techniques for creating, maintaining and managing the HTML pages. The development and use of these tools and techniques are the subject of this document.

Jones, Kennie H.↗
NASA NTRS2006

SpaceWire Plug and Play

The ability to rapidly deploy inexpensive satellites to meet tactical goals has become an important goal for military space systems. In fact, Operationally Responsive Space (ORS) has been in the spotlight at the highest levels. The Office of the Secretary of Defense (OSD) has identified that the critical next step is developing the bus standards and modular interfaces. Historically, satellite components have been constructed based on bus standards and standardized interfaces. However, this has not been done to a degree, which would allow the rapid deployment of a satellite. Advancements in plug-and-play (PnP) technologies for terrestrial applications can serve as a baseline model for a PnP approach for satellite applications. Since SpaceWire (SpW) has become a de facto standard for satellite high-speed (greater than 200Mbp) on-board communications, it has become important for SpW to adapt to this Plug and Play (PnP) environment. Because SpW is simply a bulk transport protocol and lacks built-in PnP features, several changes are required to facilitate PnP with SpW. The first is for Host(s) to figure out what the network looks like, i.e., how pieces of the network, routers and nodes, are connected together; network mapping, and to receive notice of changes to the network. The second is for the components connected to the network to be understood so that they can communicate. The first element, network topology mapping & change of status indication, is being defined (topic of this paper). The second element describing how components are to communicate has been defined by ARFL with the electronic data sheets known as XTEDS. The first element, network mapping, is recent activities performed by Air Force Research Lab (ARFL), Naval Research Lab (NRL), NASA and US industry (Honeywell, Clearwater, FL, and others). This work has resulted in the development of a protocol that will perform the lower level functions of network mapping and Change Of Status (COS) indication required by Plug 'n' Play over SpaceWire. This work will be presented to the SpaceWire working group for standardization under European Cooperation for Space Standardization (ECSS) and to obtain a permanent Protocol ID (see SpaceWire Protocol ID: What Does it Mean to You; IEEE Aerospace Conference 2006). The portion of the Plug 'n' Play protocol that will be described in this paper is how the Host(s) of a SpaceWire network map the network and detect additions and deletions of devices on a SpaceWire network.

Rakow, Glenn↗
NASA NTRS2008

Ad Hoc Selection of Voice over Internet Streams

A method and apparatus for a communication system technique involving ad hoc selection of at least two audio streams is provided. Each of the at least two audio streams is a packetized version of an audio source. A data connection exists between a server and a client where a transport protocol actively propagates the at least two audio streams from the server to the client. Furthermore, software instructions executable on the client indicate a presence of the at least two audio streams, allow selection of at least one of the at least two audio streams, and direct the selected at least one of the at least two audio streams for audio playback.

Macha, Mitchell G.↗
NASA NTRS2012

On Applications of Disruption Tolerant Networking to Optical Networking in Space

The integration of optical communication links into space networks via Disruption Tolerant Networking (DTN) is a largely unexplored area of research. Building on successful foundational work accomplished at JPL, we discuss a multi-hop multi-path network featuring optical links. The experimental test bed is constructed at the NASA Glenn Research Center featuring multiple Ethernet-to-fiber converters coupled with free space optical (FSO) communication channels. The test bed architecture models communication paths from deployed Mars assets to the deep space network (DSN) and finally to the mission operations center (MOC). Reliable versus unreliable communication methods are investigated and discussed; including reliable transport protocols, custody transfer, and fragmentation. Potential commercial applications may include an optical communications infrastructure deployment to support developing nations and remote areas, which are unburdened with supporting an existing heritage means of telecommunications. Narrow laser beam widths and control of polarization states offer inherent physical layer security benefits with optical communications over RF solutions. This paper explores whether or not DTN is appropriate for space-based optical networks, optimal payload sizes, reliability, and a discussion on security.

Hylton, Alan Guy↗
NASA NTRS2014

Ad Hoc Selection of Voice over Internet Streams

A method and apparatus for a communication system technique involving ad hoc selection of at least two audio streams is provided. Each of the at least two audio streams is a packetized version of an audio source. A data connection exists between a server and a client where a transport protocol actively propagates the at least two audio streams from the server to the client. Furthermore, software instructions executable on the client indicate a presence of the at least two audio streams, allow selection of at least one of the at least two audio streams, and direct the selected at least one of the at least two audio streams for audio playback.

Macha, Mitchell G.↗
NASA NTRS2012

A Performance Evaluation of NACK-Oriented Protocols as the Foundation of Reliable Delay- Tolerant Networking Convergence Layers

Delay-Tolerant Networking (DTN) is an active area of research in the space communications community. DTN uses a standard layered approach with the Bundle Protocol operating on top of transport layer protocols known as convergence layers that actually transmit the data between nodes. Several different common transport layer protocols have been implemented as convergence layers in DTN implementations including User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Licklider Transmission Protocol (LTP). The purpose of this paper is to evaluate several stand-alone implementations of negative-acknowledgment based transport layer protocols to determine how they perform in a variety of different link conditions. The transport protocols chosen for this evaluation include Consultative Committee for Space Data Systems (CCSDS) File Delivery Protocol (CFDP), Licklider Transmission Protocol (LTP), NACK-Oriented Reliable Multicast (NORM), and Saratoga. The test parameters that the protocols were subjected to are characteristic of common communications links ranging from terrestrial to cis-lunar and apply different levels of delay, line rate, and error.

Iannicca, Dennis↗
NASA NTRS1982

Analysis of physical exercises and exercise protocols for space transportation system operation

A quantitative evaluation of the Thornton-Whitmore treadmill was made so that informed management decisions regarding the role of this treadmill in operational flight crew exercise programs could be made. Specific tasks to be completed were: The Thornton-Whitmore passive treadmill as an exercise device at one-g was evaluated. Hardware, harness and restraint systems for use with the Thornton-Whitmore treadmill in the laboratory and in Shuttle flights were established. The quantitative and qualitative performance of human subjects on the Thorton-Whitmore treadmill with forces in excess of one-g, was evaluated. The performance of human subjects on the Thornton-Whitmore treadmill in weightlessness (onboard Shuttle flights) was also determined.

Coleman, A. E.↗
NASA NTRS1985

An empirical study of distributed application performance

A major reason for the rarity of distributed applications, despite the proliferation of networks, is the sensitivity of their performance to various aspects of the network environment. It is demonstrated that distributed applications can run faster than local ones, using common hardware. It is also shown that the primary factors affecting performance are, in approximate order of importance: speed of the user's workstation, speed of the remote host (if any), and the high-level (above the transport level) protocols used. In particular, the use of batching, pipelining, and structure in high-level protocols reduces the degradation often experienced between different bandwidth networks. Less significant, but still noticeable improvements result from proper design and implementation of the underlying transport protocols. Ultimately, with proper application of these techniques, network bandwidth is rendered virtually insignificant.

Lantz, K. A.↗
NASA NTRS2002

Mobile Router Technology Development

Cisco Systems and NASA have been performing joint research on mobile routing technology under a NASA Space Act Agreement. Cisco developed mobile router technology and provided that technology to NASA for applications to aeronautic and space-based missions. NASA has performed stringent performance testing of the mobile router, including the interaction of routing and transport-level protocols. This paper describes mobile routing, the mobile router, and some key configuration parameters. In addition, the paper describes the mobile routing test network and test results documenting the performance of transport protocols in dynamic routing environments.

Ivancic, William D.↗