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]