Engineering Papers⌕ Search

SEARCH · Engineering Papers

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.

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

At least 37 records · Page 2

Mobile-ip Aeronautical Network Simulation Study

NASA is interested in applying mobile Internet protocol (mobile-ip) technologies to its space and aeronautics programs. In particular, mobile-ip will play a major role in the Advanced Aeronautic Transportation Technology (AATT), the Weather Information Communication (WINCOMM), and the Small Aircraft Transportation System (SATS) aeronautics programs. This report presents the results of a simulation study of mobile-ip for an aeronautical network. The study was performed to determine the performance of the transmission control protocol (TCP) in a mobile-ip environment and to gain an understanding of how long delays, handoffs, and noisy channels affect mobile-ip performance.

Ivancic, William D.↗

Survey of Header Compression Techniques

This report provides a summary of several different header compression techniques. The different techniques included are: (1) Van Jacobson's header compression (RFC 1144); (2) SCPS (Space Communications Protocol Standards) header compression (SCPS-TP, SCPS-NP); (3) Robust header compression (ROHC); and (4) The header compression techniques in RFC2507 and RFC2508. The methodology for compression and error correction for these schemes are described in the remainder of this document. All of the header compression schemes support compression over simplex links, provided that the end receiver has some means of sending data back to the sender. However, if that return path does not exist, then neither Van Jacobson's nor SCPS can be used, since both rely on TCP (Transmission Control Protocol). In addition, under link conditions of low delay and low error, all of the schemes perform as expected. However, based on the methodology of the schemes, each scheme is likely to behave differently as conditions degrade. Van Jacobson's header compression relies heavily on the TCP retransmission timer and would suffer an increase in loss propagation should the link possess a high delay and/or bit error rate (BER). The SCPS header compression scheme protects against high delay environments by avoiding delta encoding between packets. Thus, loss propagation is avoided. However, SCPS is still affected by an increased BER (bit-error-rate) since the lack of delta encoding results in larger header sizes. Next, the schemes found in RFC2507 and RFC2508 perform well for non-TCP connections in poor conditions. RFC2507 performance with TCP connections is improved by various techniques over Van Jacobson's, but still suffers a performance hit with poor link properties. Also, RFC2507 offers the ability to send TCP data without delta encoding, similar to what SCPS offers. ROHC is similar to the previous two schemes, but adds additional CRCs (cyclic redundancy check) into headers and improves compression schemes which provide better tolerances in conditions with a high BER.

Ishac, Joseph↗

ISS and STS Commercial Off-the-Shelf Router Testing

This report documents the results of testing performed with commercial off-the-shelf (COTS) routers and Internet Protocols (IPs) to determine if COTS equipment and IP could be utilized to upgrade NASA's current Space Transportation System (STS), the Shuttle, and the International Space Station communication infrastructure. Testing was performed by NASA Glenn Research Center (GRC) personnel within the Electronic Systems Test Laboratory (ESTE) with cooperation from the Mission Operations Directorate (MOD) Qualification and Utilization of Electronic System Technology (QUEST) personnel. The ESTE testing occurred between November 1 and 9, 2000. Additional testing was performed at NASA Glenn Research Center in a laboratory environment with equipment configured to emulate the STS. This report documents those tests and includes detailed test procedures, equipment interface requirements, test configurations and test results. The tests showed that a COTS router and standard Transmission Control Protocols and Internet Protocols (TCP/IP) could be used for both the Shuttle and the Space Station if near-error-free radio links are provided.

Ivancie, William D.↗

Low Latency and High Data Rate (LLHD) Scheduler: A Multipath TCP Scheduler for Dynamic and Heterogeneous Networks

The scheduler is a crucial component of the multipath transmission control protocol (MPTCP) that dictates the path that a data packet takes. Schedulers are in charge of delivering data packets in the right order to prevent delays caused by head-of-line blocking. The modern Internet is a complicated network whose characteristics change in real-time. MPTCP schedulers are supposed to understand the real-time properties of the underlying network, such as latency, path loss, and capacity, in order to make appropriate scheduling decisions. However, the present scheduler does not take into account all of these characteristics together, resulting in lower performance. We present the low latency and high data rate (LLHD) scheduler, which successfully makes scheduling decisions based on real-time information on latency, path loss, and capacity, and achieves around 25% higher throughput and 45% lower data transmission delay than Linux’s default MPTCP scheduler.

97 MATHEMATICS AND COMPUTING↗

Network traffic control for multi-homed end-hosts via SDN

Software-defined networking (SDN) is an emerging technology of efficiently controlling and managing computer networks, such as in data centres, wide-area networks, as well as in ubiquitous communication. In this study, the authors explore the idea of embedding the SDN components, represented by SDN controller and virtual switch, in end-hosts to improve network performance. In particular, the authors consider load balancing across multiple network interfaces on end-hosts with different link capacity scenarios. The authors have explored and implemented different SDN-based load-balancing approaches based on OpenFlow software switches, and have demonstrated the feasibility and the potential of this approach. The proposed system has been evaluated with MultiPath transmission control protocol (MPTCP). Furthermore, the proposed results demonstrated the potential of applying the SDN concepts on multi-homed devices resulting in an increase in achieved throughput of 55% compared to the legacy single network approach and 10% compared to the MPTCP.

97 MATHEMATICS AND COMPUTING↗

Design and performance of AI agents interfacing with an atomic layer deposition tool

In this work, we introduce the design of an atomic layer deposition (ALD) reactor augmented with an AI interface for autonomous materials synthesis. Our modular design encapsulates the particularities of the hardware behind a Python interface that communicates with the ALD control software via transmission control protocol. This interface is compatible with model context protocol interfaces used in agentic frameworks. We have integrated our tool with a simple AI agent that leverages a large language model to transform user-supplied queries into ALD processes that are then run in our reactor. Our approach uses a JavaScript object notation schema to encode ALD processes. Our experimental results show that the AI interface does not impose a significant overhead to our control software, at least within our fastest 10 ms scale. We also carried out a detailed evaluation of the agent performance using leading models in two classes of tasks: basic instruction and process discovery tasks, where the agent is presented with a target material and needs to identify the correct ALD process compatible with the reactor configuration. Despite the simplicity of our agent design, we observed that most of the advanced models excelled at the instruction tasks. However, only recent models, such as o1, o3, GPT-5, and Claude Opus 4, performed well in process discovery tasks. We also observed significant variability in the response for the hardest challenges. While the results obtained are promising, we identify areas where AI research could improve the performance of agents for ALD.

47 OTHER INSTRUMENTATION↗

Telescience capability for the Sondre Stromfjord, Greenland, incoherent-scatter radar facility

SRI International (SRI) operates an upper-atmospheric research facility in Sondre Stromfjord (Sondrestrom), Greenland. In the past, the facility's remote location and limited logistical support imposed constraints on the research that could be carried out at the site. Campaigns involving multiple instruments were often constrained due to limited space, and experiments requiring coordination with other geographically separated facilities, though possible, were difficult. To provide greater access to the facility, an electronic connection between Sondrestrom and the mainland U.S.A. was established, providing access to the National Science Internet. SRI developed telescience software that sends data from the incoherent scatter radar at the Sondrestrom facility to SRI's offices in Menlo Park, California. This software uses the transmission control protocol (TCP/IP) to transmit the data in near real time between the two locations and the X window system to generate displays of the data in Menlo Park. This is in contrast to using the X window system to display data remotely across a wide-area network. Using CP to transport data over the long distance network has resulted in significantly improved network throughput and latency. While currently used to transport radar data, the telescience software is designed and intended for simultaneous use with other instruments at Sondrestrom and other facilities. Work incorporating additional instruments is currently in progress.

Zambre, Yadunath B.↗

Integration of the White Sands Complex into a Wide Area Network

The NASA White Sands Complex (WSC) satellite communications facility consists of two main ground stations, an auxiliary ground station, a technical support facility, and a power plant building located on White Sands Missile Range. When constructed, terrestrial communication access to these facilities was limited to copper telephone circuits. There was no local or wide area communications network capability. This project incorporated a baseband local area network (LAN) topology at WSC and connected it to NASA's wide area network using the Program Support Communications Network-Internet (PSCN-I). A campus-style LAN is configured in conformance with the International Standards Organization (ISO) Open Systems Interconnect (ISO) model. Ethernet provides the physical and data link layers. Transmission Control Protocol and Internet Protocol (TCP/IP) are used for the network and transport layers. The session, presentation, and application layers employ commercial software packages. Copper-based Ethernet collision domains are constructed in each of the primary facilities and these are interconnected by routers over optical fiber links. The network and each of its collision domains are shown to meet IEEE technical configuration guidelines. The optical fiber links are analyzed for the optical power budget and bandwidth allocation and are found to provide sufficient margin for this application. Personal computers and work stations attached to the LAN communicate with and apply a wide variety of local and remote administrative software tools. The Internet connection provides wide area network (WAN) electronic access to other NASA centers and the world wide web (WWW). The WSC network reduces and simplifies the administrative workload while providing enhanced and advanced inter-communications capabilities among White Sands Complex departments and with other NASA centers.

Boucher, Phillip Larry↗

An Evaluation of TCP with Larger Initial Windows

Transmission Control Protocol (TCP's) slow start algorithm gradually increases the amount of data a sender injects into the network, which prevents the sender from overwhelming the network with an inappropriately large burst of traffic. However, the slow start algorithm can make poor use of the available band-width for transfers which are small compared to the bandwidth-delay product of the link, such as file transfers up to few thousand characters over satellite links or even transfers of several hundred bytes over local area networks. This paper evaluates a proposed performance enhancement that raises the initial window used by TCP from 1 MSS-sized segment to roughly 4 KB. The paper evaluates the impact of using larger initial windows on TCP transfers over both the shared Internet and dialup modem links.

Allman, Mark↗

High-Speed TCP Testing

Transmission Control Protocol (TCP) is the underlying protocol used within the Internet for reliable information transfer. As such, there is great interest to have all implementations of TCP efficiently interoperate. This is particularly important for links exhibiting long bandwidth-delay products. The tools exist to perform TCP analysis at low rates and low delays. However, for extremely high-rate and lone-delay links such as 622 Mbps over geosynchronous satellites, new tools and testing techniques are required. This paper describes the tools and techniques used to analyze and debug various TCP implementations over high-speed, long-delay links.

Brooks, David E.↗

ACTS 118x: High Speed TCP Interoperability Testing

With the recent explosion of the Internet and the enormous business opportunities available to communication system providers, great interest has developed in improving the efficiency of data transfer over satellite links using the Transmission Control Protocol (TCP) of the Internet Protocol (IP) suite. The NASA's ACTS experiments program initiated a series of TCP experiments to demonstrate scalability of TCP/IP and determine to what extent the protocol can be optimized over a 622 Mbps satellite link. Through partnerships with the government technology oriented labs, computer, telecommunication, and satellite industries NASA Glenn was able to: (1) promote the development of interoperable, high-performance TCP/IP implementations across multiple computing / operating platforms; (2) work with the satellite industry to answer outstanding questions regarding the use of standard protocols (TCP/IP and ATM) for the delivery of advanced data services, and for use in spacecraft architectures; and (3) conduct a series of TCP/IP interoperability tests over OC12 ATM over a satellite network in a multi-vendor environment using ACTS. The experiments' various network configurations and the results are presented.

Brooks, David E.↗

ACTS 118x Final Report High-Speed TCP Interoperability Testing

With the recent explosion of the Internet and the enormous business opportunities available to communication system providers, great interest has developed in improving the efficiency of data transfer using the Transmission Control Protocol (TCP) of the Internet Protocol (IP) suite. The satellite system providers are interested in solving TCP efficiency problems associated with long delays and error-prone links. Similarly, the terrestrial community is interested in solving TCP problems over high-bandwidth links. Whereas the wireless community is interested in improving TCP performance over bandwidth constrained, error-prone links. NASA realized that solutions had already been proposed for most of the problems associated with efficient data transfer over large bandwidth-delay links (which include satellite links). The solutions are detailed in various Internet Engineering Task Force (IETF) Request for Comments (RFCs). Unfortunately, most of these solutions had not been tested at high-speed (155+ Mbps). Therefore, the NASA's ACTS experiments program initiated a series of TCP experiments to demonstrate scalability of TCP/IP and determine how far the protocol can be optimized over a 622 Mbps satellite link. These experiments were known as the 118i and 118j experiments. During the 118i and 118j experiments, NASA worked closely with SUN Microsystems and FORE Systems to improve the operating system, TCP stacks. and network interface cards and drivers. We were able to obtain instantaneous data throughput rates of greater than 520 Mbps and average throughput rates of 470 Mbps using TCP over Asynchronous Transfer Mode (ATM) over a 622 Mbps Synchronous Optical Network (SONET) OC12 link. Following the success of these experiments and the successful government/industry collaboration, a new series of experiments. the 118x experiments. were developed.

Ivancic, William D.↗

Traffic Management in ATM Networks Over Satellite Links

This report presents a survey of the traffic management Issues in the design and implementation of satellite Asynchronous Transfer Mode (ATM) networks. The report focuses on the efficient transport of Transmission Control Protocol (TCP) traffic over satellite ATM. First, a reference satellite ATM network architecture is presented along with an overview of the service categories available in ATM networks. A delay model for satellite networks and the major components of delay and delay variation are described. A survey of design options for TCP over Unspecified Bit Rate (UBR), Guaranteed Frame Rate (GFR) and Available Bit Rate (ABR) services in ATM is presented. The main focus is on traffic management issues. Several recommendations on the design options for efficiently carrying data services over satellite ATM networks are presented. Most of the results are based on experiments performed on Geosynchronous (GEO) latencies. Some results for Low Earth Orbits (LEO) and Medium Earth Orbit (MEO) latencies are also provided.

Goyal, Rohit↗

A Simulation Study of Paced TCP

In this paper, we study the performance of paced TCP, a modified version of TCP designed especially for high delay- bandwidth networks. In typical networks, TCP optimizes its send-rate by transmitting increasingly large bursts, or windows, of packets, one burst per round-trip time, until it reaches a maximum window-size, which corresponds to the full capacity of the network. In a network with a high delay-bandwidth product, however, Transmission Control Protocol's (TCPs) maximum window-size may be larger than the queue size of the intermediate routers, and routers will begin to drop packets as soon as the windows become too large for the router queues. The TCP sender then concludes that the bottleneck capacity of the network has been reached, and it limits its send-rate accordingly. Partridge proposed paced TCP as a means of solving the problem of queueing bottlenecks. A sender using paced TCP would release packets in multiple, small bursts during a round-trip time in which ordinary TCP would release a single, large burst of packets. This approach allows the sender to increase its send-rate to the maximum window size without encountering queueing bottlenecks. This paper describes the performance of paced TCP in a simulated network and discusses implementation details that can affect the performance of paced TCP.

Kulik, Joanna↗

Leo Satellite Communication through a LEO Constellation using TCP/IP Over ATM

The simulated performance characteristics for communication between a terrestrial client and a Low Earth Orbit (LEO) satellite server are presented. The client and server nodes consist of a Transmission Control Protocol /Internet Protocol (TCP/IP) over ATM configuration. The ATM cells from the client or the server are transmitted to a gateway, packaged with some header information and transferred to a commercial LEO satellite constellation. These cells are then routed through the constellation to a gateway on the globe that allows the client/server communication to take place. Unspecified Bit Rate (UBR) is specified as the quality of service (QoS). Various data rates are considered.

Foore, Lawrence R.↗

On the Effective Evaluation of TCP

Understanding the performance of the Internet's Transmission Control Protocol (TCP) is important because it is the dominant protocol used in the Internet today. Various testing methods exist to evaluate TCP performance, however all have pitfalls an that need to be understood prior to obtaining useful results. Simulating TCP is difficult because of the wide range of variables, environments, and implementations available. Testing TCP modifications in the global Internet may not be the answer either: testing new protocols on real networks endangers other people's traffic and, if not done correctly, may also yield inaccurate or misleading results. In order for TCP research to be independently evaluated in the Internet research community there is a set of questions that researchers should try to answer. This paper attempts to list some of those questions and make recommendations as to how TCP testing can be structured to be provide useful answers.

Allman, Mark↗

On the Performance of TCP Spoofing in Satellite Networks

In this paper, we analyze the performance of Transmission Control Protocol (TCP) in a network that consists of both satellite and terrestrial components. One method, proposed by outside research, to improve the performance of data transfers over satellites is to use a performance enhancing proxy often dubbed 'spoofing.' Spoofing involves the transparent splitting of a TCP connection between the source and destination by some entity within the network path. In order to analyze the impact of spoofing, we constructed a simulation suite based around the network simulator ns-2. The simulation reflects a host with a satellite connection to the Internet and allows the option to spoof connections just prior to the satellite. The methodology used in our simulation allows us to analyze spoofing over a large range of file sizes and under various congested conditions, while prior work on this topic has primarily focused on bulk transfers with no congestion. As a result of these simulations, we find that the performance of spoofing is dependent upon a number of conditions.

Ishac, Joseph↗

Evaluation of Swift Start TCP in Long-Delay Environment

This report presents the test results of the Swift Start algorithm in single-flow and multiple-flow testbeds under the effects of high propagation delays, various slow bottlenecks, and small queue sizes. Although this algorithm estimates capacity and implements packet pacing, the findings were that in a heavily congested link, the Swift Start algorithm will not be applicable. The reason is that the bottleneck estimation is falsely influenced by timeouts induced by retransmissions and the expiration of delayed acknowledgment (ACK) timers, thus causing the modified Swift Start code to fall back to regular transmission control protocol (TCP).

Lawas-Grodek, Frances J.↗