QUIC for SATCOM
draft-kuhn-quic-4-sat-02
Internet Engineering Task Force N. Kuhn
Internet-Draft CNES
Intended status: Informational G. Fairhurst
Expires: May 6, 2020 University of Aberdeen
J. Border
Hughes Network Systems, LLC
E. Stephan
Orange
November 3, 2019
QUIC for SATCOM
draft-kuhn-quic-4-sat-02
Abstract
QUIC has been designed for use across Internet paths. Initial
designs of QUIC have focussed on common deployment scenarios for web
traffic and have not focussed on the performance when using a path
with a large Bandwidth-Delay Product (BDP). A path can combine
satellites network segment together with a wide variety of other
network technologies (Ethernet, cable modems, WiFi, cellular, radio
links, etc): this complicates the characteristics of the end-to-end
path. One example of such a scenario occurs when a satellite
communication (SATCOM) system is used to provide all or a part of the
end-to-end path. If this is not addressed, the end-to-end quality of
experience can be degraded.
This memo identifies the characteristics of a SATCOM link that impact
the operation of the QUIC transport protocol and proposes current
practice to ensure acceptable protocol performance.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2020.
Kuhn, et al. Expires May 6, 2020 [Page 1]
Internet-Draft QUIC 4 SAT November 2019
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Operating over a path with a large BDP . . . . . . . . . . . 3
3. TCP Split Solution . . . . . . . . . . . . . . . . . . . . . 5
4. Mechanisms that improve the performance of QUIC for SATCOM . 5
4.1. Getting up to speed . . . . . . . . . . . . . . . . . . . 5
4.2. Maximum window . . . . . . . . . . . . . . . . . . . . . 6
4.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. ACK ratio . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The end-to-end performance of an application using an Internet path
can be impacted by the Bandwidth-Delay Product (BDP) of the links and
network devices forming the path. For instance, the page load time
for a complex page can be much larger when the path includes a
satellite link. A significant contribution to this reduced
performance arises from the initialisation and design of transport
mechanisms. QUIC's default congestion control is based on TCP
Show full document text