Network Working Group                                           R. Paulo
Internet-Draft                                                Apple Inc.
Intended status: Standards Track                          March 11, 2019
Expires: September 12, 2019


                  Exploring QUIC Connection Migration
                     draft-paulo-quic-migration-00

Abstract

   This document explores QUIC connection migration and suggests
   possible improvements.

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 September 12, 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.






Paulo                  Expires September 12, 2019               [Page 1]


Internet-Draft     Exploring QUIC Connection Migration        March 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Connection migration strategies . . . . . . . . . . . . . . .   2
     2.1.  Failover mode . . . . . . . . . . . . . . . . . . . . . .   2
     2.2.  Standby mode  . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Improvements to connection migration  . . . . . . . . . . . .   3
     3.1.  Dealing with loss and congestion  . . . . . . . . . . . .   3
     3.2.  Keeping the alternate path alive  . . . . . . . . . . . .   4
     3.3.  Estimating RTT  . . . . . . . . . . . . . . . . . . . . .   4
     3.4.  Migrating without data to send  . . . . . . . . . . . . .   4
     3.5.  Path validation privacy . . . . . . . . . . . . . . . . .   4
     3.6.  Path MTU discovery  . . . . . . . . . . . . . . . . . . .   5
     3.7.  Interaction with loss recovery  . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   This document explores QUIC connection migration in detail and
   suggests improvements.  Familiarity with QUIC as defined in
   [QUIC-TRANSPORT] is necessary.  For reference, QUIC considers
   PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID and PADDING frames
   as "probing frames".  All other frames are "non-probing frames"

2.  Connection migration strategies

   Protocols supporting multiple paths (such as MPTCP [RFC6824]) often
   have three modes of operation that we call failover, standby and
   aggregation.

   QUIC currently supports only the first two.

2.1.  Failover mode

   In failover mode, the networking stack monitors the quality of the
   connection or link and, when they are not operating normally, the
   QUIC connection is migrated to an alternative path.

   QUIC doesn't require any packets to be exchanged before migrating to
   a new path, so this migration is seamless.  However, if the new path
   hasn't been validated, there's less confidence that it will work.




Paulo                  Expires September 12, 2019               [Page 2]


Internet-Draft     Exploring QUIC Connection Migration        March 2019


2.2.  Standby mode

   In standby mode, the networking stack establishes and validates an
   alternative path shortly after establishing a connection on the main
   path.  When the link or the connection deteriorate, QUIC can switch
   to the alternative path.

   Even though QUIC connections can migrate without validation, this
   mode improves migration confidence and performance, as explained
   below.

3.  Improvements to connection migration

   In contrast with failover mode, applications operating in standby
   mode must ensure the alternative path is alive for a significant
   amount of time.

   The improvements described below apply only to standby mode because
   failover mode migrates to an alternative path quickly which doesn't
   give implementations enough time to determine the characteristics of
   the new path.

3.1.  Dealing with loss and congestion

   In the simplest case, when endpoints have no inflight packets, the
   connection migrates after the path has been validated.  In this case,
   the endpoints reset their congestion controller and don't have to
   deal with packet loss.  However, more commonly, connection migration
   happens when the main path is quickly losing quality but it's not
   completely unusable (i.e., not 100% packet loss) and there are plenty
   of packets inflight.  To better deal with packet loss, endpoints
   SHOULD process packets from both paths for a certain amount of time.
   Since the ACK frame is a non-probing packet, implementations can only
   acknowledge packets on the new path, but this acknowledgement SHOULD
   include packet numbers received on the previous path during
   connection migration.

   ACKs or other non-probing frames might be inflight to the server when
   the client decides to switch to an alternative path.  It's possible
   that the ACK on the previous path is delayed and arrives at the
   server after a non-probing frame has been delivered on the new path.
   This will create a situation where the server is switching back and
   forth between the two paths.  To avoid this problem, servers SHOULD
   not switch to sending on the previous path if they have received a
   larger packet number on the new path.  Similarly, clients MAY ignore
   path validation requests on a path they have deemed unreliable.





Paulo                  Expires September 12, 2019               [Page 3]


Internet-Draft     Exploring QUIC Connection Migration        March 2019


   If an endpoint decides to use a single congestion controller during
   migration, it will reset it during migration.  This is acceptable as
   the migration will require a new congestion feedback.  However, if
   the migration was spurious (due to an attacker or due to link quality
   policies), the endpoint should restore the previous congestion
   controller state.

3.2.  Keeping the alternate path alive

   Due to shorter NAT timeouts for UDP flows, QUIC connections typically
   exchange PING frames to maintain the NAT binding alive.  However, the
   PING frame is considered a non-probing frame, so it can't be used to
   maintain a NAT binding associated with an alternative path alive.

   To maintain this NAT binding alive, implementations MAY send periodic
   PATH_CHALLENGE frames.  Since a PATH_CHALLENGE triggers a
   PATH_RESPONSE, the NAT binding is refreshed on both directions.

3.3.  Estimating RTT

   Clients can compute the RTT of an alternative path by recording the
   time the PATH_CHALLENGE frame was sent and measuring the RTT when the
   corresponding PATH_RESPONSE frame is received.

   Servers can't use the client's PATH_CHALLENGE to measure the RTT, but
   since they will issue their own PATH_CHALLENGE, they can measure the
   RTT once they receive the respective PATH_RESPONSE.

   In standby mode, endpoints can follow the advice on the previous
   section to gather more RTT samples.

3.4.  Migrating without data to send

   If an implementation detects the link quality is not acceptable
   anymore, it can send a non-probing frame, such as a PING or ACK, to
   migrate the connection to the new path.

   This is especially useful for clients that are monitoring the link
   quality because they can react faster to last mile link problems.

3.5.  Path validation privacy

   To improve privacy, endpoints MAY randomly pad path validation
   packets (which include PATH_CHALLENGE and PATH_RESPONSE frames) to
   make it harder for observers to identify connection migrations.  This
   might be unnecessary when the path validation frames are bundled with
   other non-probing frames.




Paulo                  Expires September 12, 2019               [Page 4]


Internet-Draft     Exploring QUIC Connection Migration        March 2019


3.6.  Path MTU discovery

   To improve performance, endpoints MAY try to discover the alternative
   path's MTU before connection migration happens.  Endpoints can use
   the same method described in section 14.3 of [QUIC-TRANSPORT] but
   instead of using PING frames combined with PADDING frames, they can
   use PATH_CHALLENGE frames combined with PADDING frames.

3.7.  Interaction with loss recovery

   Since path probing sends QUIC packets that might not reach the
   server, implementations SHOULD avoid probing too many paths
   simultaneously to avoid issues with loss recovery, specifically with
   the re-ordering threshold.  The issue occurs when the number of
   probing packets that are lost is higher than kPacketThreshold and
   then the client sends a packet on the main path.  Once the ACK
   arrives, the loss recovery algorithm will assume the probing packets
   were lost and reduce the congestion window unnecessarily.  As a more
   general improvement, implementations SHOULD ignore lost path probing
   packets with regards to congestion window reductions.

4.  Security Considerations

   None.

5.  IANA Considerations

   None.

6.  Acknowledgments

   Christoph Paasch and Tommy Pauly.

7.  References

7.1.  Normative References

   [QUIC-TRANSPORT]
              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", draft-ietf-quic-
              transport-latest (work in progress).

7.2.  Informative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.




Paulo                  Expires September 12, 2019               [Page 5]


Internet-Draft     Exploring QUIC Connection Migration        March 2019


   [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>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <https://www.rfc-editor.org/info/rfc6824>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Author's Address

   Rui Paulo
   Apple Inc.
   One Apple Park Way
   Cupertino, California 95014
   United States of America

   Email: rpaulo@apple.com




























Paulo                  Expires September 12, 2019               [Page 6]