Skip to main content

Enhancing Transport Protocols over Satellite Networks

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Tom Jones , Gorry Fairhurst , Nicolas Kuhn , John Border , Emile Stephan
Last updated 2022-04-28 (Latest revision 2021-10-25)
Replaces draft-kuhn-quic-4-sat
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


IETF transport protocols such as TCP, SCTP and QUIC are designed to function correctly over any network path. This includes networks paths that utilise a satellite link or network. While transport protocols function, the characteristics of satellite networks can impact performance when using the defaults in standard mechanisms, due to the specific characteristics of these paths. [RFC2488] and [RFC3135] describe mechanisms that enable TCP to more effectively utilize the available capacity of a network path that includes a satellite system. Since publication, both application and transport layers and satellite systems have evolved. Indeed, the development of encrypted protocols such as QUIC challenges currently deployed solutions, for satellite systems the capacity has increased and commercial systems are now available that use a range of satellite orbital positions. This document follows the terminology proposed in [I-D.irtf-panrg-path-properties] to describe the current characterises of common satellite paths. This document also describes considerations when implementing and deploying reliable transport protocols that are intended to work efficiently over paths that include a satellite system. It discusses available network mitigations and offers advice to designers of protocols and operators of satellite networks.


Tom Jones
Gorry Fairhurst
Nicolas Kuhn
John Border
Emile Stephan

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)