QUIC Multipath Negotiation Option
draft-huitema-quic-mpath-option-00

Document Type Active Internet-Draft (individual)
Author Christian Huitema 
Last updated 2020-10-20
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         C. Huitema
Internet-Draft                                      Private Octopus Inc.
Intended status: Standards Track                        October 20, 2020
Expires: April 23, 2021

                   QUIC Multipath Negotiation Option
                   draft-huitema-quic-mpath-option-00

Abstract

   The initial version of QUIC provides support for path migration.  In
   this draft, we argue that there is a very small distance between
   supporting path migration and supporting simulatneous traffic on
   multipath.  Instead of using an implicit algorithm to discard unused
   paths, we propose a simple option to allow explicit management of
   active and inactive paths.  Once paths are explicitly managed, pretty
   much all other requirements for multipath support can be met by
   appropriate algorithms for scheduling transmissions on specific
   paths.  These algorithms can be implemented on the sender side, and
   do not require specific extensions, except maybe a measurement of one
   way delays.

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 April 23, 2021.

Copyright Notice

   Copyright (c) 2020 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

Huitema                  Expires April 23, 2021                 [Page 1]
Internet-Draft            QUIC Multipath Option             October 2020

   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.  Path Management Requirement . . . . . . . . . . . . . . . . .   3
   3.  Path Management Extension . . . . . . . . . . . . . . . . . .   4
     3.1.  Path Management Support Transport Parameter . . . . . . .   4
     3.2.  PATH_IDENTIFICATION Frame (TBD) . . . . . . . . . . . . .   5
     3.3.  PATH_STATUS Frame (TBD) . . . . . . . . . . . . . . . . .   6
   4.  Sender side algorithms  . . . . . . . . . . . . . . . . . . .   6
     4.1.  Packet Numbers and Acknowledgements . . . . . . . . . . .   6
     4.2.  Congestion Control and Error Recovery . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The QUIC Working Group is debating how much priority should be given
   to the support of multipath in QUIC.  This is not a new debate.  The
   the QUIC transport [I-D.ietf-quic-transport] includes a number of
   mechanisms to handle multiple paths, including the support for NAT
   rebinding and for explicit migration.

   The processing of received packets by QUIC nodes only requires that
   the connection context can be retrieved using the combination of IP
   addresses and UDP ports in the IP and UDP headers, and connection
   identifier in the packet header.  Once the connection context is
   identified, the receiving node will verify if the packet can be
   successfully decrypted.  If it is, the packet will be processed and
   eventually an acknowledgement will inform the sender that it was
   received.

   In theory, that property of QUIC implies that senders could send
   packets using whatever IP addresses or UDP ports they see fit, as
   long as they carry a valid connection ID, and are properly encrypted.
   Senders can, indeed SHOULD, use the Path Challenge and Response
   mechanism to verify that the path is valid before sending packets,
   but even that is optional.  The NAT rebinding mechanisms, for
   example, rely on the possibility of receiving packets without a
Show full document text