draft-huitema-quic-mpath-option-00.txt

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



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


   preliminary Path Challenge.  However, in practice, the sender's
   choice of sending paths is limited by the path migration logic in
   [I-D.ietf-quic-transport].

   Path migration according to [I-D.ietf-quic-transport] is always
   initiated by the node in the client role.  That node will test the
   validity of paths using the path challenge response mechanism, and at
   some point decide to switch all its traffic to a new path.  The node
   in the server role will detect that data traffic (i.e., ack eliciting
   frames) is sent on a new path, and on detecting that, will switch its
   own traffic to that new path.  After that, client and server can
   release the resource tied to the old path, for example by retiring
   the connection identifiers, releasing the memory context used for
   managing per path congestion, or forgetting the IP addresses and
   ports associated with that path.  By sending data on a new path, the
   client provides an implicit signal to discard the old path.  If the
   client was to spread data on several paths, the server would probably
   become confused.

   This draft proposes an explicit mechanism for replacing the implicit
   signalling of path migration through data transmission, by means of a
   new PATH_OPTION frame.

2.  Path Management Requirement

   Implicit path management, as specified in [I-D.ietf-quic-transport],
   fulfills two goals: it direct a peers to switch sending through a new
   preferred path, and it allows the peer to release resources
   associated with the old path.  Explicit path management will have to
   fulfill similar goals: provide indications to the peer regarding
   preferred paths for receiving data; and, signal to the peer when
   resource associated with previous paths can be discarded.

   We cannot mandate that path management signals be always carried on
   the path that they affect.  For example, consider a node that wants
   to abandon a path through a Wi-Fi network because the signal strength
   is fading.  It will need to signal its peer to move traffic away from
   that path, but there is no guarantee that a packet sent through the
   old fading path will be promptly received.  It is much preferable to
   send such management signals on a different path, for example through
   a cellular link.  But if path management signals can be sent on
   arbitrary paths, they need to identify the path that they manage.

   Neither addresses nor connection identifiers are good identifiers of
   paths.  Because of NAT, addresses and ports can be changed during the
   transfer of packets from source to destination.  Multiple connection
   identifiers can be used over the lifetime of a path, and there is
   also no strict requirement that a given connection identifier be used



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


   on a single path.  On the other hand, one can imagine an inband "path
   identification" frame that establishes an identifier for a specific
   path.  That identifier can then be used in other path management
   frames.

   The path management frames provides directions on how to use existing
   paths.  We could imagine a number of variations, but the simplest one
   would be:

   o  Abandon a path, and release the corresponding resource.

   o  Mark a path as "available", i.e., allow the peer to use its own
      logic to split traffic among available paths.

   o  Mark a path as "standby", i.e., suggest that no traffic should be
      sent on that path if another path is available.

   We could also envisage marking a path as "preferred", suggesting that
   all traffic would be sent to that path, but the same functionality is
   achieved by marking only one path as available.

   There might be a delay between the moment a path is validated through
   the challenge response mechanism, identified using path
   identification frames, and managed using path management frames.
   During that delay, the following conventions apply:

   o  If a path is validated but no ack-eliciting frames or path
      management frames are received, the path is placed in the
      "standby" state.

   o  If ack-eliciting frames are received on a path before path
      management frames, the path is placed in the "available" state.

3.  Path Management Extension

   The path management extension is negotiated by means of the
   "enable_path_management" transport parameter.  When support is
   negotiated, the peers can send or receive the PATH_IDENTIFICATION and
   PATH_STATUS frames.

3.1.  Path Management Support Transport Parameter

   The use of the PATH_IDENTIFICATION and PATH_STATUS transport frame
   extension is negotiated using a transport parameter:

   o  "enable_path_management" (TBD)





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


   The "enable_path_management" transport parameter is included if the
   endpoint wants to receive or accepts PATH_IDENTIFICATION and
   PATH_STATUS frames for this connection.  This parameter is encoded as
   a variable integer as specified in section 16 of
   [I-D.ietf-quic-transport].  It can take one of the following three
   values:

   1.  I would like to send PATH_IDENTIFICATION and PATH_STATUS frames

   2.  I am able to process PATH_IDENTIFICATION and PATH_STATUS frames

   3.  I am able to process PATH_IDENTIFICATION and PATH_STATUS frames
       and I would like to send them.

   Peers receiving another value SHOULD terminate the connection with a
   TRANSPORT PARAMETER error.

   A peer that advertises its capability of sending PATH_IDENTIFICATION
   and PATH_STATUS frames using option values 1 or 3 MUST NOT send these
   frames if the other peer does not announce advertise its ability to
   process them by sending the enable_path_management TP with option 1
   or 3.

3.2.  PATH_IDENTIFICATION Frame (TBD)

   The PATH_IDENTIFICATION frames carry a single identifier, the path
   identifier. " PATH_IDENTIFICATION Frame { Path Identifier (i) } " The
   frame carries the identifier of the path over which it is received,
   as defined by the peer sending data on that path.  The identifier is
   a positive integer lower than 2^62.

   PATH_IDENTIFICATION frames are ACK-eliciting.

   Due to delays and retransmissions, several PATH_IDENTIFICATION frames
   may be received on the same path.  In that case, the identifier with
   the highest value is retrained for the path.  For example, if a node
   receives on the same path the identifiers 11, 17 and 13, the path
   will be identified by the number 17.

   If both peers have successfully negotiated the capability of sending
   path management frames, each peer will send its own identifier over
   the path.

   PATH_MANAGEMENT frames MUST only be sent in 1-RTT packets.  Receiving
   such frames in Initial, Handshake of 0-RTT packets is a transport
   violation.





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


3.3.  PATH_STATUS Frame (TBD)

   The PATH_STATUS frames carry three parameters: the identifier of the
   path being managed, the new status of the path, and a management
   sequence number.

   " PATH_STATUS Frame { Path Identifier (i), Path Status (i),
   Management Sequence Number (i) } "

   The path identifier SHOULD match the value sent in a previous
   PATH_IDENTIFICATION frame for an existing frame.  If no such value is
   found, the PATH_STATUS frame will be discarded.

   NAT rebinding and retransmissions could cause the same identifier to
   be received over different paths.  If that happens, PATH_MANAGEMENT
   frames will apply to all the paths sharing that identifier.

   PATH_STATUS frames are ACK-eliciting.

   Due to delays and retransmissions, PATH_STATUS frames may be received
   out of order.  If the Management Sequence Number is not greater than
   the previously received values for that path, the PATH_STATUS frame
   will be discarded.

   If the frame is accepted, the status of the path is set to the
   received Path Status, for which the authorized values are:

   0- Abandon 1- Standby 2- Available

   Receiving any other value is an error, which SHOULD trigger the
   closure of the connection with a reason code PROTOCOL VIOLATION.

   PATH_MANAGEMENT frames MUST only be sent in 1-RTT packets.  Receiving
   such frames in Initial, Handshake of 0-RTT packets is a transport
   violation.

4.  Sender side algorithms

   In this minimal design, the sender is responsible for scheduling
   packets transmission on different paths, preferably on "Available"
   paths, but possibly on "StandBy" paths if all available paths are
   deemed unusable.

4.1.  Packet Numbers and Acknowledgements

   The packet number space does not depend on the path on which the
   packet is sent.  ACK frames report the numbers of packets that have




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


   been received so far, regardless of the path on which they have been
   received.

   If senders decide to send packets on paths with different
   transmission delays, some packets will very probably be received out
   of order.  This will cause the ACK frames to carry multiple ranges of
   received packets.  Senders that want to control this issue may do so
   by dedicating sub-ranges of packet numbers to different paths.  We
   expect that experience on how to manage such ranges will quickly
   emerge.

4.2.  Congestion Control and Error Recovery

   Senders MUST manage per-path congestion status, and MUST NOT send
   more data on a given path than congestion control on that path
   allows.  This is already a requirement of [I-D.ietf-quic-transport].

   In order to implement per path congestion control, the senders
   maintain an association between previously sent packet numbers and
   the path over which these packets were sent.  When a packet is newly
   acknowledged, the delay between the transmission of that packet and
   its first acknowledgement is used to update the RTT statitics for the
   sending path, and to update the state of the congestion control for
   that path.

   Packet loss detection MUST be adapted to allow for different RTT on
   different paths.  For example, timer computations should take into
   account the RTT of the path on which a packet was sent.  Detections
   based on packet numbers shall compare a given packet number to the
   highest packet number received for that path.

   Acknowledgement delays are the sum of two one-way delays, the delay
   on the packet sending path and the delay on the return path chosen
   for the acknowledgements.  It is unclear whether this is a problem in
   practice, but this could motivate the use of time stamps
   [I-D.huitema-quic-ts] in conjunction with acknowledgements.

5.  Security Considerations

   TBD.  There are probably ways to abuse this.

6.  IANA Considerations

   This document registers a new value in the QUIC Transport Parameter
   Registry:

   Value: TBD (using value 0xe9a in early deployments)




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


   Parameter Name: enable_path_management

   Specification: Indicates support of the Path Management options.

   This document also registers 2 new values in the QUIC Frame Type
   registry:

   Value: TBD (using value 0x9a1 in early deployments)

   Frame Name: PATH_IDENTIFICATION

   Specification: Identification of the path over which a packet is
   sent.

   Value: TBD (using value 0x9a5 in early deployments)

   Frame Name: PATH_STATUS

   Specification: Identification of the path over which a packet is
   sent.

7.  Acknowledgements

8.  Normative References

   [I-D.huitema-quic-ts]
              Huitema, C., "Quic Timestamps For Measuring One-Way
              Delays", draft-huitema-quic-ts-03 (work in progress),
              August 2020.

   [I-D.ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", draft-ietf-quic-transport-31 (work
              in progress), September 2020.

Author's Address

   Christian Huitema
   Private Octopus Inc.
   427 Golfcourse Rd
   Friday Harbor  WA 98250
   U.S.A

   Email: huitema@huitema.net







Huitema                  Expires April 23, 2021                 [Page 8]