SEARCH · Search NASA

Results for “transmission control protocol”

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.

SourceResearch connectionFrom yearThrough year

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

At least 19 records

All sources NASA NTRS DOE OSTI

NASA NTRS1998

Using Transmission Control Protocol in the Trans-Pacific High Definition Video Satellite Communication Experiment - the Next Test

Ths paper describes a future Transmission Control Protocol (TCP) test which was planned as a part of the Trans-Pacific High Definition Video Satellite Communications Experiment. The TCP test portion of the Trans-Pacific High Definition Video Satellite Communications Experiment intends to examine the correlation between the underlying assumptions of come TCP algorithms and the performance shortfalls observed when the algorithms are used in a stellite-based environment, and to make experimental changes to existing TCP variants to study the effects of the modifications.

global information infrastructure (GII) satellites↗

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 NTRS2016

Marshall Space Flight Center Telescience Resource Kit

Telescience Resource Kit (TReK) is a suite of software applications that can be used to monitor and control assets in space or on the ground. The Telescience Resource Kit was originally developed for the International Space Station program. Since then it has been used to support a variety of NASA programs and projects including the WB-57 Ascent Vehicle Experiment (WAVE) project, the Fast Affordable Science and Technology Satellite (FASTSAT) project, and the Constellation Program. The Payloads Operations Center (POC), also known as the Payload Operations Integration Center (POIC), provides the capability for payload users to operate their payloads at their home sites. In this environment, TReK provides local ground support system services and an interface to utilize remote services provided by the POC. TReK provides ground system services for local and remote payload user sites including International Partner sites, Telescience Support Centers, and U.S. Investigator sites in over 40 locations worldwide. General Capabilities: Support for various data interfaces such as User Datagram Protocol, Transmission Control Protocol, and Serial interfaces. Data Services - retrieve, process, record, playback, forward, and display data (ground based data or telemetry data). Command - create, modify, send, and track commands. Command Management - Configure one TReK system to serve as a command server/filter for other TReK systems. Database - databases are used to store telemetry and command definition information. Application Programming Interface (API) - ANSI C interface compatible with commercial products such as Visual C++, Visual Basic, LabVIEW, Borland C++, etc. The TReK API provides a bridge for users to develop software to access and extend TReK services. Environments - development, test, simulations, training, and flight. Includes standalone training simulators.

Wade, Gina↗

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 NTRS2000

A History of the Improvement of Internet Protocols Over Satellites Using ACTS

This paper outlines the main results of a number of ACTS experiments on the efficacy of using standard Internet protocols over long-delay satellite channels. These experiments have been jointly conducted by NASAs Glenn Research Center and Ohio University over the last six years. The focus of our investigations has been the impact of long-delay networks with non-zero bit-error rates on the performance of the suite of Internet protocols. In particular, we have focused on the most widely used transport protocol, the Transmission Control Protocol (TCP), as well as several application layer protocols. This paper presents our main results, as well as references to more verbose discussions of our experiments.

Allman, Mark↗

NASA NTRS2018

Improving Scientific Payload Communication Over Multiple, Low-Capacity Links

Communication is an important part of every airborne science mission. It provides a means for a large group of ground-based scientists to monitor and adjust experiments aboard aircraft that often cannot support a large number of passengers. In some cases, such as unmanned aircraft, communication becomes critical to a successful mission. Existing communication systems require the use of multiple, low-capacity channels, or links, to handle the capacity requirements of the scientists. Current communication solutions attempt to balance performance and reliability, but ultimately suffer from some critical design flaws that limit the ability of the system to handle additional links. We show how adding resources to the current system results in decreased performance and reliability. We explore the use of a new communication protocol, MultiPath Transmission Control Protocol, to make better use of multiple communication links and propose a total system capable of scaling to any number of channels efficiently and dynamically. The tools developed to support and measure this solution are also detailed.

MPTCP↗

NASA NTRS2001

The Behavior of TCP and Its Extensions in Space

The performance of Transmission Control Protocol (TCP) in space has been examined from the observations of simulation and experimental tests for several years at National Aeronautics and Space Administration (NASA), Department of Defense (DoD) and universities. At New Mexico State University (NMSU), we have been concentrating on studying the performance of two protocol suites: the file transfer protocol (ftp) running over Transmission Control Protocol/Internet Protocol (TCP/IP) stack and the file protocol (fp) running over the Space Communications Protocol Standards (SCPS)-Transport Protocol (TP) developed under the Consultative Committee for Space Data Systems (CCSDS) standards process. SCPS-TP is considered to be TCP's extensions for space communications. This dissertation experimentally studies the behavior of TCP and SCPS-TP by running the protocol suites over both the Space-to-Ground Link Simulator (SGLS) test-bed and realistic satellite link. The study concentrates on comparing protocol behavior by plotting the averaged file transfer times for different experimental configurations and analyzing them using Statistical Analysis System (SAS) based procedures. The effects of different link delays and various Bit-Error-Rates (BERS) on each protocol performance are also studied and linear regression models are built for experiments over SGLS test-bed to reflect the relationships between the file transfer time and various transmission conditions.

Wang, Ruhai↗

NASA NTRS1990

Issues in designing transport layer multicast facilities

Multicasting denotes a facility in a communications system for providing efficient delivery from a message's source to some well-defined set of locations using a single logical address. While modem network hardware supports multidestination delivery, first generation Transport Layer protocols (e.g., the DoD Transmission Control Protocol (TCP) (15) and ISO TP-4 (41)) did not anticipate the changes over the past decade in underlying network hardware, transmission speeds, and communication patterns that have enabled and driven the interest in reliable multicast. Much recent research has focused on integrating the underlying hardware multicast capability with the reliable services of Transport Layer protocols. Here, we explore the communication issues surrounding the design of such a reliable multicast mechanism. Approaches and solutions from the literature are discussed, and four experimental Transport Layer protocols that incorporate reliable multicast are examined.

Dempsey, Bert J.↗

NASA NTRS1996

Use of CCSDS and OSI Protocols on the Advanced Communications Technology Satellite

Although ACTS (Advanced Communications Technology Satellite) provides an almost error-free channel during much of the day and under most conditions, there are times when it is not suitable for reliably error-free data communications when operating in the uncoded mode. Because coded operation is not always available to every earth station, measures must be taken in the end system to maintain adequate throughput when transferring data under adverse conditions. The most effective approach that we tested to improve performance was the addition of an 'outer' Reed-Solomon code through use of CCSDS (Consultative Committee for Space Data Systems) GOS 2 (a forward error correcting code). This addition can benefit all users of an ACTS channel including those applications that do not require totally reliable transport, but it is somewhat expensive because additional hardware is needed. Although we could not characterize the link noise statistically (it appeared to resemble uncorrelated white noise, the type that block codes are least effective in correcting), we did find that CCSDS GOS 2 gave an essentially error-free link at BER's (bit error rate) as high as 6x10(exp -4). For users that demand reliable transport, an ARQ (Automatic Repeat Queuing) protocol such as TCP (Transmission Control Protocol) or TP4 (Transport Protocol, Class 4) will probably be used. In this category, it comes as no surprise that the best choice of the protocol suites tested over ACTS was TP4 using CCSDS GOS 2. TP4 behaves very well over an error-free link which GOS 2 provides up to a point. Without forward error correction, however, TP4 service begins to degrade in the 10(exp -7)-10(exp -6) range and by 4x10(exp -6), it barely gives any throughput at all. If Congestion Avoidance is used in TP4, the degradation is even more pronounced. Fortunately, as demonstrated here, this effect can be more than compensated for by choosing the Selective Acknowledgment option. In fact, this option can enable TP4 to deliver some throughput at error rates as high as 10(exp -5).

Chirieleison, Don↗

NASA NTRS1990

The Xpress Transfer Protocol (XTP): A tutorial (expanded version)

The Xpress Transfer Protocol (XTP) is a reliable, real-time, light weight transfer layer protocol. Current transport layer protocols such as DoD's Transmission Control Protocol (TCP) and ISO's Transport Protocol (TP) were not designed for the next generation of high speed, interconnected reliable networks such as fiber distributed data interface (FDDI) and the gigabit/second wide area networks. Unlike all previous transport layer protocols, XTP is being designed to be implemented in hardware as a VLSI chip set. By streamlining the protocol, combining the transport and network layers and utilizing the increased speed and parallelization possible with a VLSI implementation, XTP will be able to provide the end-to-end data transmission rates demanded in high speed networks without compromising reliability and functionality. This paper describes the operation of the XTP protocol and in particular, its error, flow and rate control; inter-networking addressing mechanisms; and multicast support features, as defined in the XTP Protocol Definition Revision 3.4.

Sanders, Robert M.↗

NASA NTRS1990

The Xpress Transfer Protocol (XTP): A tutorial (short version)

The Xpress Transfer Protocol (XTP) is a reliable, light weight transfer layer protocol. Current transport layer protocols such as DoD's Transmission Control Protocol (TCP) and ISO's Transport Protocol (TP) were not designed for the next generation of high speed, interconnected reliable networks such as fiber distributed data interface (FDDI) and the gigabit/second wide area networks. Unlike all previous transport layer protocols, XTP is being designed to be implemented in hardware as a VLSI chip set. By streamlining the protocol, combining the transport and network layers, and utilizing the increased speed and parallelization possible with a VLSI implementation, XTP will be able to provide the end-to-end data transmission rates demanded in the high speed networks without compromising reliability and functionality. This tutorial briefly describes the operation of the XTP protocol and in particular, its error, flow and rate control; inter-networking addressing mechanisms; and multicast support features, as defined in the XTP Protocol Definition Revision 3.4.

Sanders, Robert M.↗

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 NTRS2021

Characterization Study of TestBed Infrastructure Performance in a Distributed Simulation Environment: Baseline Analysis

Characterization of the performance of Air Traffic Management Exploration (ATM-X) TestBed integration environment has been investigated and documented for one system configuration for progressively increasing traffic. Several statistical parameters were used to assess the performance of the TestBed distributed system such as mean, standard deviation, skewness, and kurtosis of latency, and update rate for aircraft state messages that are transmitted through the simulated system under investigation. It is necessary to assess the performance characteristics of distributed systems in terms of the indicated statistical parameters mentioned above. It is critical to verify the system performance with respect to a researcher’s required system performance. Computer host specifications are documented in terms of Central Processing Unit (CPU) clock speed and core count. Transmission Control Protocol/ Internet Protocol (TCP/IP) message protocol was used for data transmission. The system network topology also contributes to the latency and update rate variations from the one imposed by the data source. The motivation for selecting the TestBed infrastructure as the focus of this study can be attributed to the number of services and capabilities it provides that help simplify the process of preparing and conducting a simulation. These capabilities include an easy to use GUI for simulation configuration, access to TestBed library by the end-user of other simulation software components, a modular adapter paradigm that allows simple connectivity of external software to TestBed, connectivity with other simulation laboratories, and a Software Development Kit (SDK) for quicker development. Two types of traffic generators, Air Traffic Generator (ATG) and Multi Aircraft Control System (MACS) were used to generate messages that were injected into the TestBed distributed environment. Eight different air traffic scenarios with progressively increasing loads were generated for each air traffic simulator. The corresponding air traffic loads between the two simulators had an identical number of aircraft per scenario, but different flight plans. It was observed that the performance of MACS degraded for air traffic scenarios containing more than 200 aircraft (37.5 KB/s nominal throughput). However, ATG performed adequately under all tested air traffic loads up to 1200 aircraft (225. KB/s nominal throughput). The tests show that MACS exhibits better latency performance with smaller aircraft loads when compared to ATG. The tests also show that the TestBed infrastructure successfully transmits 1200 aircraft without significant degradation of its performance. From the latency trends for both MACS and ATG, it is clear that as aircraft load increases, the latency in the system increases as well as its standard deviation. Likewise, the trends for the update data rate for both MACS and ATG show that as the aircraft load increases, so does the standard deviation and mean of the update rates which can be attributed to the performance of MACS and ATG applications. The analysis of the results of this study have proven that the overall system performance is dependent on the individual performance of each system component that is connected to TestBed, which subsequently propagates into the system. All TestBed characterization tests were conducted in SimLabs at NASA Ames Research Center in November 2019. This study addresses the need for a baseline TestBed characterization, and the results will serve as a reference for more complex simulation systems.

Air Traffic Management simulations↗

NASA NTRS1999

Web Transfer Over Satellites Being Improved

Extensive research conducted by NASA Lewis Research Center's Satellite Networks and Architectures Branch and the Ohio University has demonstrated performance improvements in World Wide Web transfers over satellite-based networks. The use of a new version of the Hypertext Transfer Protocol (HTTP) reduced the time required to load web pages over a single Transmission Control Protocol (TCP) connection traversing a satellite channel. However, an older technique of simultaneously making multiple requests of a given server has been shown to provide even faster transfer time. Unfortunately, the use of multiple simultaneous requests has been shown to be harmful to the network in general. Therefore, we are developing new mechanisms for the HTTP protocol which may allow a single request at any given time to perform as well as, or better than, multiple simultaneous requests. In the course of study, we also demonstrated that the time for web pages to load is at least as short via a satellite link as it is via a standard 28.8-kbps dialup modem channel. This demonstrates that satellites are a viable means of accessing the Internet.

Allman, Mark↗

NASA NTRSDate not supplied

Next Steps: Laying the Groundwork for Bundle Protocol v7

Delay/Disruption Tolerant Networking (DTN) is a networking model and protocol suite that extends the terrestrial internet to the challenging communication environments of space. These environments are typically subject to frequent disruptions, which can cause delays or errors. DTN protects data transmission by wrapping data into bundles (similar to Internet Protocol packets), storing them until a connection can be established between two nodes (similar to terrestrial routers or computers), and forwarding them to their destinations. Bundle Protocol (BP) is responsible for generating those bundles and creates the transport layer of DTN, much like how Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) create the transport layer of the Internet Protocol. BPv6 is the current, accepted version of the Bundle Protocol standard. However, recent missions and test implementations have revealed missing components and areas for improvement in the standard. Using lessons learned from NASA missions and gathering inspiration from the Internet Protocol, BPv7 is intended to be a more robust Bundle Protocol that improves upon its predecessor and increases the technology readiness level of the DTN architecture. The DTN Standard Interface Design team, a sub-team of the DTN Infusion Project at the Goddard Space Flight Center, worked to create a dictionary of terms for bundle components and functional decomposition of the protocol. These efforts aided in the standardization of BP interfaces, something missing from BPv6, and supported parallel network management and configuration work. This standardization will ultimately contribute to LunaNet (a lunar communications and navigation architecture that will bring networking, positioning, navigation, timing and science services to the Moon), the Solar System Internet (SSI), and expand crewed and uncrewed space exploration opportunities.

DTN↗

NASA NTRSDate not supplied

Next Steps: Laying the Groundwork for Bundle Protocol v7

dtn↗

NASA NTRS1999

Internet Protocol Enhanced over Satellite Networks

Extensive research conducted by the Satellite Networks and Architectures Branch of the NASA Lewis Research Center led to an experimental change to the Internet's Transmission Control Protocol (TCP) that will increase performance over satellite channels. The change raises the size of the initial burst of data TCP can send from 1 packet to 4 packets or roughly 4 kilobytes (kB), whichever is less. TCP is used daily by everyone on the Internet for e-mail and World Wide Web access, as well as other services. TCP is one of the feature protocols used in computer communications for reliable data delivery and file transfer. Increasing TCP's initial data burst from the previously specified single segment to approximately 4 kB may improve data transfer rates by up to 27 percent for very small files. This is significant because most file transfers in wide-area networks today are small files, 4 kilobytes or less. In addition, because data transfers over geostationary satellites can take 5 to 20 times longer than over typical terrestrial connections, increasing the initial burst of data that can be sent is extremely important. This research along with research from other institutions has led to the release of two new Request for Comments from the Internet Engineering Task Force (IETF, the international body that sets Internet standards). In addition, two studies of the implications of this mechanism were also funded by NASA Lewis.

Ivancic, William D.↗

NASA NTRS2007

TCP Performance Enhancement Over Iridium

In support of iNET maturation, NASA-JPL has collaborated with NASA-Dryden to develop, test and demonstrate an over-the-horizon vehicle-to-ground networking capability, using Iridium as the vehicle-to-ground communications link for relaying critical vehicle telemetry. To ensure reliability concerns are met, the Space Communications Protocol Standards (SCPS) transport protocol was investigated for its performance characteristics in this environment. In particular, the SCPS-TP software performance was compared to that of the standard Transmission Control Protocol (TCP) over the Internet Protocol (IP). This paper will report on the results of this work.

distributed systems↗