Internet DRAFT - draft-quic-coding
draft-quic-coding
NWCRG I. Swett
Internet-Draft Google
Intended status: Standards Track M. Montpetit
Expires: May 3, 2018 Triangle Video
V. Roca
INRIA
October 30, 2017
Network Layer Coding for QUIC: Requirements
draft-quic-coding-00
Abstract
This document presents the motivation and requirements for the use
of Network Level Packet Erasure Coding to improve the performance of
the QUIC protocol that is proposed a new transport protocol. The
document does not specify a specific code but lists the salient
features that a code should have in order to deal with know loss
patterns on QUIC paths.
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 3, 2018.
Copyright Notice
Copyright (c) 2017 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
Swett, et al. Expires May 3, 2018 [Page 1]
Internet-Draft QUIC and NC October 2017
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. QUIC Background . . . . . . . . . . . . . . . . . . . . . . . 3
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
10. Security Considerations . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Revision information . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
In addition, while most of the the terminology in this document is
conform to the taxonomy presented in [[NC-Taxonomy]] for clarity and
comparison with existing QUIC documents we continue to use the word
packet to indication the entity that will be encoded vs. symbol in
the taxonomy document.
NOTE: while using drafts in references is not compliant with IETF/
IRTF rules they will be replaced by RFCs as they become available.
2. Introduction
The QUIC (Quick UDP-based Internet Connection)protocol is currently
being proposed as new transport protocol than multiplexes connections
over UDP. The major elements have been defined and are being
implemented by the QUIC IETF working group [QUIC-WG] including wire
format, connection establishment, stream multiplexing, stream and
connection-level flow control, and data encryption [numerous draft
references]. This document addresses an outstanding element of the
QUIC protocol, namely how to account and correct for packet losses at
Swett, et al. Expires May 3, 2018 [Page 2]
Internet-Draft QUIC and NC October 2017
the network layer that will have a very negative impact on transport
delay, throughput and reliability. This document presents the
salient features and requirements for a network coding (NC) protocol
to provide the QUIC packet loss recovery it requires. NC provides a
structured, algebraic mechanism to recover lost packets based on a
vast heritage of Forward Error Correction (FEC) and has shown better
performance of packet recovery than XORs or repetition codes to deal
with the losses in the Internet. The Network Coding taxonomy
document [[NC-Taxonomy]] contains an overview of top NC concepts.
Note: we need a small NC draft that explains how it works.
3. QUIC Background
This section will completed in a future version. For the needs of
the current document we need to know that the QUIC packet format
contains a unique packet identifier (ID) and a connection ID.
Details will be obtained from [[QUIC-Connect]] and [[QUIC-Trans]]
4. Motivation
The QUIC protocol from its early implementations, wanted to address
packet losses in the Internet as they can greatly impact protocol
performance and impact the performance congestion control mechanisms
[[QUIC-Loss]]. For example TCP goodput goes below 20% with 3% loss
[are there any other references besides the famous Mathis curve?].
In this section we review the motivations behind the use of a network
coding approach to reduce the impact of packet losses on QUIC. It is
important to note that we limit the sources of the losses to IP layer
and above and losses in lower layers are addressed by other
standardization organization.
It is known (is it?) that the main sources of losses in the Internet
include (but are not limited to):
o Queuing losses across multiple flows
o Intermittent timeouts
o Connection losses
o Residual physical or MAC layer losses
o Misrouting
o other?
The main feature of all the patterns associated with the loss events
above is the fact that losses appear in clusters (burst or correlated
losses). Hence they are not the 'random losses' that can be
recovered by non structured mechanisms like XOR or repetitions codes
even with high overhead or simple block codes with fixed window
sizes. Hence because of the correlated losses, the first requirement
for a good code for QUIC is one that allows variable window sizes
Swett, et al. Expires May 3, 2018 [Page 3]
Internet-Draft QUIC and NC October 2017
that allow to vary with the size of the burst. That will be better
suited to recover the losses with statistically approximately the
same overhead as the average packet loss without limitations on the
loss pattern.
5. Architecture
In order to define the potential NC solution, a detailed architecture
is necessary. Hence, the main QUIC/NC architecture topics to be
addressed includes the following (each will become a subsection in
the future).
o Type of connection: while unicast and/or multicast/broadcast
communications are possible over QUIC it is assumed that an
initial implementation will be limited to unicast.
o Addressing single source flow or multiple flows: at the the coding
level, if there is a multiplexing on top of the coding level,
already managed by QUIC machinery, it may be totally transparent.
We can assume that individual packets and connections can be
individually identified.
o Use of feedback: since the code will need to deal with correlated
losses can it benefit from feedback to manage the window as
opposed to a fully unidirectional source-destination mechanism.
This will allow not to lose any packet part of a current
generation before the loss burst ends (we need a reference on
window growth and maximum size)
o Minimization of latency:Latency is key for the solution design.
This includes reducing extra delay due to encoding/decoding at the
ingress, egress and intermediate nodes (middleboxes) especially on
delay sensitive paths. At the same time long bandwidth-delay
product networks coding should reduce the overall end-to-end delay
experienced by an application significantly by minimizing the
effect of packet losses and retransmission on TCP congestion
control and throughput.
o Throughput aspects: it is expected that the QUIC flows will
include high throughput flows, very low throughput flows and mixed
sizes flows.
o Interactions with other functionalities: Interactons with
congestion control and encryption will also be key. Directions
will be taken from [[QUIC-Loss]] and [[QUIC-TLS]] and other
relevant documents
o Code changes and future proofing: any protocol designed within
QUIC should be able to maybe use more than one code to change
codes easily by without major impact this is to address different
network conditions or improve performance if a new code was to be
developed. It is assumed that the code remain the same for the
full QUIC session lifetime but that within a session at least for
Swett, et al. Expires May 3, 2018 [Page 4]
Internet-Draft QUIC and NC October 2017
the beginning it should be possible to turn off the coding to
prevent catastrophic congestion collapse for example.
6. Use-cases
Note: this will be detailed in the next version of the document
7. Requirements
The initial requirements for the QUIC NC are presented below. This
list will help to chose the best solution amongst existing codes.
Requirements:
o Simplicity/low complexity: both encoding and decoding operations
should be simple and ass little complexity to the QUIC operations;
the use of systematic coding will be encouraged.
o Low overhead: the NC overhead to compensate for all losses should
be as close as possible to the average loss on the path as to not
create additional congestion condition.
o In network coding: there should be ways to create additional coded
symbols inside the network either directly or via partial or full
decoding.
o Multipath: there should be ways to take advantage of multipath
communications for example to send packets and coded symbols on
different paths to reduce delay and overhead on some delay or loss
sensitive paths.
o Licensing/IPR: the solution should be license/patent free.
8. Next Steps
Besides adding the sections missing in the document based on future
discussion it is proposed to define a strawman architecture based on
existing codes and using the standard APIs being developed in the RG.
9. IANA Considerations
XX RFC ED - PLEASE REMOVE THIS SECTION XXX
This memo includes no request to IANA.
10. Security Considerations
Security: While NC will not impact security in itself it will be
important to verify how NC interacts with current encryption used in
QUIC and presented in [[QUIC-TLS]].
Swett, et al. Expires May 3, 2018 [Page 5]
Internet-Draft QUIC and NC October 2017
11. References
11.1. Normative References
[NC-Taxonomy]
Abramson, B. and et. al., "Network Coding Taxonomy",
Internet-draft draft-irtf-nwcrg-network-coding-taxonomy-
05.txt, July 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363,
DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>.
11.2. Informative References
[QUIC-Connect]
Roskind, J., "QUIC: Quick UDP Internet Connections", URL
https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-
saqsQx7rFV-ev2jRFUoVD34/preview#.
[QUIC-Loss]
Iyengar, J. and I. Swett, "QUIC Loss Detection and
Congestion Control", Internet-draft draft-iyengar-quic-
loss-recovery-06.txt, September 2017.
[QUIC-Overview]
"QUIC Overview",
URL https://datatracker.ietf.org/wg/quic/about/.
[QUIC-TLS]
Thomson, M. and R. Harrison, "Using Transport Layer
Security (TLS) to Secure QUIC", Internet-draft -06.txt,
September 2017.
[QUIC-Trans]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Internet-draft draft-ietf-quic-
transport-06.txt, September 2017.
Swett, et al. Expires May 3, 2018 [Page 6]
Internet-Draft QUIC and NC October 2017
Appendix A. Revision information
XXX RFC-Ed please remove this section prior to publication.
Authors' Addresses
Ian Swett
Google
Cambridge, MA
USA
EMail: ianswett@google.com
Marie-Jose Montpetit
Triangle Video
Boston, MA
USA
EMail: marie@mjmontpetit.com
Vincent Roca
INRIA
Grenoble
France
EMail: vincent.roca@inria.fr
Swett, et al. Expires May 3, 2018 [Page 7]
