Internet DRAFT - draft-gage-quicmp-pathmodel

draft-gage-quicmp-pathmodel







QUIC Working Group                                               W. Gage
Internet-Draft                                              Unaffiliated
Intended status: Standards Track                        11 November 2023
Expires: 14 May 2024


               An Alternate Path Model for Multipath QUIC
                     draft-gage-quicmp-pathmodel-00

Abstract

   The path model used in the current MPQUIC draft binds a connection
   identifier to a path.  In fact, the sequence number of a connection
   identifier is used as an implicit path identifier.  This has a number
   of consequences that may cause MPQUIC to diverge from the principles
   of RFC9000.  One of these consequences, for example, is to associate
   each connection with a different application data packet number space
   rather than maintaining a single application data packet number space
   across all connections as defined in RFC9000.

   This document proposes a different path model for Multipath QUIC
   using explicit path identifiers, enabling a multipath management
   framework that retains the principles and operations of RFC9000.

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 14 May 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Gage                       Expires 14 May 2024                  [Page 1]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Multipath Management  . . . . . . . . . . . . . . . . . . . .   4
   3.  Path Identification . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  (Sidebar) Comparison to MPQUIC-DRAFT  . . . . . . . . . .   5
     3.2.  (Sidebar) Use of multiple application data packet number
           spaces  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  High-level Overview . . . . . . . . . . . . . . . . . . . . .   6
   5.  Path Activation and Removal . . . . . . . . . . . . . . . . .   7
     5.1.  Path Activation . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Path Removal  . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Path Maintenance  . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Path Transmission Status  . . . . . . . . . . . . . . . .   8
     6.2.  Path Congestion Control . . . . . . . . . . . . . . . . .   9
     6.3.  Path RTT Measurements . . . . . . . . . . . . . . . . . .   9
   7.  Packet Scheduling . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Packet Loss Detection and Recovery  . . . . . . . . . . . . .  10
   9.  Multipath Frame Types . . . . . . . . . . . . . . . . . . . .  10
     9.1.  MULTIPATH_CHALLENGE . . . . . . . . . . . . . . . . . . .  11
     9.2.  MULTIPATH_RESPONSE  . . . . . . . . . . . . . . . . . . .  11
     9.3.  MULTIPATH_STATUS  . . . . . . . . . . . . . . . . . . . .  11
     9.4.  MULTIPATH_STATUS_ACK  . . . . . . . . . . . . . . . . . .  11
     9.5.  MULTIPATH_ABANDON . . . . . . . . . . . . . . . . . . . .  11
     9.6.  MULTIPATH_ABANDON_ACK . . . . . . . . . . . . . . . . . .  12
     9.7.  MULTIPATH_BINDING . . . . . . . . . . . . . . . . . . . .  12
     9.8.  MULTIPATH_ECN . . . . . . . . . . . . . . . . . . . . . .  12
     9.9.  MULTIPATH_MAX_DATA  . . . . . . . . . . . . . . . . . . .  12
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     11.1.  New QUIC transport parameters  . . . . . . . . . . . . .  13
     11.2.  New QUIC frame types . . . . . . . . . . . . . . . . . .  13
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     12.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14



Gage                       Expires 14 May 2024                  [Page 2]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


1.  Introduction

   Architecturally, one may consider two models for multi-path
   operations: model (A) is a collection of uni-path QUIC constructs
   while model (B) is a uni-path QUIC construct operating over a
   collection of paths.

   Model (A) is like multipath TCP [MPTCP] and appears to be the model
   of the current MPQUIC design [MPQUIC-DRAFT].  Model (B) is like a TCP
   connection operating over a layer 2 link aggregation group [LAG].  In
   (B), a TCP segment can be transmitted in an IP datagram over any of
   the links in the LAG.

   If we apply the principles of (B) to Multipath QUIC, then path
   management is distinct from connection management.  Conceptually the
   Multipath QUIC stack is an [RFC9000] entity sitting on top of a path
   management entity with a shim entity between them to direct a QUIC
   packet over one of the available paths.

   This document proposes a QUIC multipath model similar to (B).

   In the proposed model, a QUIC packet can be sent over any of the
   available (and unrestricted) paths.  Since connection identifiers are
   independent of path, a QUIC packet received over any path is
   processed in the same way as a packet received over the single path
   construct of [RFC9000] - i.e. there is a single application data
   packet number space and an ACK received over any path contains
   unambiguous packet numbers.  While congestion control must clearly be
   path-specific, connection management, key management and packet loss
   recovery are not path-specific.

1.1.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Terminology

   This document uses the following terminology:

   session:  a collection of QUIC connections and paths used to exchange
      QUIC packets between two endpoints.

   TBC:  to be completed




Gage                       Expires 14 May 2024                  [Page 3]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


   TBD:  to be determined

2.  Multipath Management

   Connection migration to a new path is already supported in [RFC9000].
   A goal of multipath QUIC is to provide multiple paths that can be
   simultaneously active and to explicitly manage the use of paths.

   Similar to [MPQUIC-DRAFT], this proposal is based on several basic
   design points:

   *  Re-use the mechanisms of [RFC9000] as much as possible.  In
      particular, this proposal uses path validation based on [RFC9000]
      and re-uses all of the connection management, key management and
      loss recovery procedures of [RFC9000].

   *  Use the same packet header formats as [RFC9000] to avoid
      differences between multipath and non-multipath traffic over a
      particular path.

   *  Do not modify frame formats defined in [RFC9000]; if necessary,
      define new frame types for multipath-specific operations.

   Multipath QUIC requires changes to the path management mechanisms
   specified in Section 9 of [RFC9000]:

   *  allow simultaneous transmission of non-probing frames on multiple
      paths;

   *  continue using an existing path even if non-probing frames have
      been received on another path;

   *  manage the removal of paths that have been abandoned or lost.

   In addition, multipath QUIC may require changes to several QUIC path-
   specific procedures described in [RFC9002]:

   *  congestion control;

   *  RTT measurements;

   *  PMTU discovery.









Gage                       Expires 14 May 2024                  [Page 4]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


3.  Path Identification

   A path may be associated with the 4-tuple of an IP/UDP datagram
   (source IP address, destination IP address, source UDP port, and
   destination UDP port).  However, this document explicitly assigns an
   identifier to each path to decouple path management from the 4-tuple
   of the IP/UDP datagram used to transport a QUIC packet.

   A path identifier is an integer that is unique across all paths
   associated with a session.  The initial (default) path (i.e. the path
   used for the exchange of QUIC initial and handshake packets) is
   implicitly assigned the path identifier (PathID) zero (0).  New path
   identifiers MUST increase monotonically.  A path identifier assigned
   to one path MUST NOT be reused as the identifier for a different path
   within the session.

   If the 4-tuple associated with a QUIC connection changes without the
   use of multipath validation (Section 5.1), this is considered a
   passive migration event (e.g. due to a NAT rebinding) and is outside
   the scope of this document - i.e. it is already covered by [RFC9000].

   QUIC connections exist and are managed independently of paths.  An
   outgoing QUIC packet may be transmitted over any of the available and
   active paths, subject to any constraints that may have been placed on
   path usage by either of the QUIC endpoints (Section 6.1).  Similarly,
   an incoming QUIC packet received over any path will be processed
   according to [RFC9000], as though it had been received over a uni-
   path transport between the QUIC endpoints.

3.1.  (Sidebar) Comparison to [MPQUIC-DRAFT]

   [MPQUIC-DRAFT] does not use explicit path identifiers; instead, a
   connection identifier is used as an implicit path identifier with
   several consequences:

   *  a connection is bound to a specific path;

   *  there can be be only one connection per path.

   In addition, QUIC packet loss and recovery in [MPQUIC-DRAFT] is
   performed separately for each path.  To simplify implementation,
   [MPQUIC-DRAFT] introduces the concept of multiple application data
   packet number spaces with a different number space for each
   connection (path).  This is in contrast to [RFC9000] where there is a
   single application data packet number space.






Gage                       Expires 14 May 2024                  [Page 5]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


3.2.  (Sidebar) Use of multiple application data packet number spaces

   One consequence of the use of multiple packet number spaces is that
   it may be difficult to use [MPQUIC-DRAFT] in combination with a QUIC-
   aware UDP proxy [QUIC-PROXY].

   If the proxy is operating in forwarding mode, an uplink QUIC short
   header packet received over a (virtual) CID on the network segment
   between the proxy and a client is mapped to a destination CID on the
   network segment between the proxy and a server.  Nothing else in the
   QUIC packet is changed and parts of the QUIC packet header -
   including the packet number - are protected by a header protection
   key known only to the client and server.

   If multipath QUIC is used between the proxy and client, and uni-path
   QUIC [RFC9000] is used between the proxy and server, then a change in
   the path between proxy and client cannot affect the packet numbering.
   In other words, multipath QUIC would need to preserve the packet
   numbering spaces defined by [RFC9000] and not introduce a new set of
   packet number spaces that would prevent interop with [RFC9000]
   compliant servers.

4.  High-level Overview

   The multipath extensions to QUIC proposed in this document enable the
   simultaneous use of different paths to exchange non-probing QUIC
   frames.  This differs from [RFC9000] where the connection migration
   procedure selects only one path to exchange non-probing frames.

   A multipath QUIC session between peers starts with a standard QUIC
   handshake over an initial (default) path.  As indicated by [RFC9000],
   an endpoint MUST NOT attempt to activate a new path before the
   handshake is confirmed.  The peers use a new enable_multipath
   transport parameter during the handshake to negotiate the use of
   multipath capabilities.  A new max_active_paths transport parameter
   limits the maximum number of active paths that can be used between
   the peers.

   To add a new path to an existing multipath QUIC session, a client
   starts a path validation on the chosen path.  A new path can only be
   used to transport non-probing frames once the path has been validated
   using mechanisms similar to those described in Section 8 of
   [RFC9000].  New MULTIPATH_CHALLENGE and MULTIPATH_RESPONSE frames are
   used to validate the path and to assign an identifier to the path.  A
   new MULTIPATH_STATUS frame may be used to control use of a path and a
   new MULTIPATH_BINDING frame may be used to bind a QUIC connection
   identifier to a specific set of paths.




Gage                       Expires 14 May 2024                  [Page 6]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


   A new MULTIPATH_ABANDON frame may be used to abandon a path between
   peers, preventing further use of that path to exchange QUIC packets.
   A MULTIPATH_ABANDON frame includes the identifier assigned to the
   path to be abandoned, allowing the frame to be forwarded over any of
   the (allowable) paths active at the time of transmission.

   The multipath operations described in this document do not change the
   basic operations described in [RFC9000].  In particular, none of the
   following procedures described in [RFC9000] are affected by the use
   of multiple paths:

   *  connection management (e.g. the use of NEW_CONNECTION_ID frames
      and subsequent rotation of connection identifiers);

   *  key management (e.g. use of key phase bit) and derivation of AEAD
      parameters;

   *  packet loss detection and loss recovery (e.g. using type 0x02 ACK
      frames without ECN counts).

   However, changes to [RFC9002] procedures are required to deal with
   path-dependent characteristics such as path MTU size, RTT and
   congestion.  For example, a new MULTIPATH_ECN frame may be used to
   provide path-specific ECN information.

5.  Path Activation and Removal

   TBC.

5.1.  Path Activation

   operation overview:

   *  to initiate communications over a new path, an endpoint sends a
      MULTIPATH_CHALLENGE frame (Section 9.1) containing a new path
      identifier (PathID) and an unpredictable payload.

   *  the frame is encapsulated (in a QUIC packet) in an IP/UDP datagram
      where the 4-tuple of the datagram corresponds to the new path.

   *  discovery of the peer endpoint IP address and UDP port is outside
      the scope of this document.

   *  the peer confirms used of the new path by responding with a
      MULTIPATH_RESPONSE frame (Section 9.2) that echoes the received
      PathID and payload.





Gage                       Expires 14 May 2024                  [Page 7]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


   *  if the initiating endpoint does not receive a confirming
      MULTIPATH_RESPONSE frame, it may transmit a new
      MULTIPATH_CHALLENGE frame using the same (or a different) IP/UDP
      4-tuple but with a new PathID and a different payload.

   TBC.

5.2.  Path Removal

   operation overview:

   *  to terminate communications over an established path, an endpoint
      sends a MULTIPATH_ABANDON frame (Section 9.5) containing the
      PathID of the path to be abandoned.

   *  if the endpoint does not receive a MULTIPATH_ABANDON_ACK frame
      (Section 9.6) in response, the MULTIPATH_ABANDON frame may be
      retransmitted over the same or a different path.

   *  the MULTIPATH_ABANDON and MULTIPATH_ABANDON_ACK frames may be
      transmitted over any path that is active (and allowable) at the
      time of transmission.

   TBC.

6.  Path Maintenance

   TBC.

6.1.  Path Transmission Status

   operation overview:

   *  an initiating endpoint may send an initiator MULTIPATH_STATUS
      frame (Section 9.3) to inform its peer of the desired status of a
      path.

   *  if the peer agrees with the status change, the peer should respond
      with a MULTIPATH_STATUS_ACK frame (Section 9.4) that echoes the
      sequence number and status of the corresponding MULTIPATH_STATUS
      frame.

   *  if the peer does not agree with the status change, the peer should
      respond with a new responder MULTIPATH_STATUS frame (Section 9.3)
      to inform the initiator of its desired status of the path.  The
      path status sequence number in the new MULTIPATH_STATUS frame MUST
      be greater than the path status sequence number in the initiator
      MULTIPATH_STATUS frame.



Gage                       Expires 14 May 2024                  [Page 8]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


   *  an endpoint may also send a MULTIPATH_BINDING frame (Section 9.7)
      to bind a QUIC connection identifier to a specific path or set of
      paths.

   *  the MULTIPATH_STATUS, MULTIPATH_STATUS_ACK and MULTIPATH_BINDING
      frames may be transmitted over any path that is active (and
      allowable) at the time of transmission.

   TBC.

6.2.  Path Congestion Control

   operation overview:

   *  congestion control is applied per path, as described in Section 7
      of [RFC9002].

   *  QUIC packets sent on one path do not affect the congestion state
      of another path.

   *  an endpoint may send a MULTIPATH_ECN frame (Section 9.8) to its
      peer to report ECN information received over a path.

   *  an endpoint may send a MULTIPATH_MAX_DATA frame (Section 9.9) to
      limit the number of bytes-in-flight allowed on a path.

   *  the MULTIPATH_ECN and MULTIPATH_MAX_DATA frames may be transmitted
      over any path that is active (and allowable) at the time of
      transmission.

   TBC.

6.3.  Path RTT Measurements

   TBC.

7.  Packet Scheduling

   operation overview:

   *  a QUIC packet may be scheduled for transmission over a given path
      only if:

      -  the path state is not "paused" or "closed";

      -  the destination connection identifier has not been bound to
         another path (Section 9.7);




Gage                       Expires 14 May 2024                  [Page 9]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


      -  transmission of the packet does not increase the number of
         bytes-in-flight beyond the congestion window of the path
         (Section 6.2)

   *  if more than one path is eligible for transmission of a packet,
      the algorithm used to select the path is beyond the scope of this
      document.  An implementation may, for example, use the precedence
      value provided in a MULTIPATH_CHALLENGE, MULTIPATH_RESPONSE or
      MULTIPATH_STATUS frame.

   *  a precedence value is an integer that may be used to differentiate
      between paths when scheduling the transmission of a QUIC packet:

      -  in general, a path with a higher precedence value is preferred
         over a path with a lower precedence value;

      -  multiple paths may be assigned the same precedence value;

      -  congestion control may override precedence to allow
         transmission over a less congested path;

      -  a precedence value of zero (0) may be used to indicate that the
         path is in a "standby" mode and should not be selected unless
         no other path is available.

   TBC.

8.  Packet Loss Detection and Recovery

   operation overview:

   *  QUIC senders use acknowledgements to detect lost packets and a PTO
      to ensure acknowledgements are received.

   *  loss detection through acknowledgements is the same as described
      in Section 6.1 of [RFC9002].

   *  loss detection through PTO requires derivation of a PTO period
      that accommodates the different RTT that may be experienced over
      different paths (Section 6.3).

   TBC.

9.  Multipath Frame Types

   TBC.





Gage                       Expires 14 May 2024                 [Page 10]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


9.1.  MULTIPATH_CHALLENGE

      MULTIPATH_CHALLENGE Frame {
        Type (i) = Type_mpChallenge,
        PathID (i),
        Initiator precedence (i),
        Data (64),
      }

   TBC.

9.2.  MULTIPATH_RESPONSE

      MULTIPATH_RESPONSE Frame {
        Type (i) = Type_mpResponse,
        PathID (i),
        Responder precedence (i),
        Data (64),
      }

   TBC.

9.3.  MULTIPATH_STATUS

      MULTIPATH_STATUS Frame {
        Type (i) = Type_mpStatus,
        PathID (i),
        Path Status sequence number (i),
        Path Status (i),
        [Initiator precedence (i)]
       }

   TBC.

9.4.  MULTIPATH_STATUS_ACK

      MULTIPATH_STATUS_ACK Frame {
        Type (i) = Type_mpStatusAck,
        PathID (i),
        Path Status sequence number (i),
        Path Status (i),
        [Responder precedence (i)]
       }

   TBC.

9.5.  MULTIPATH_ABANDON




Gage                       Expires 14 May 2024                 [Page 11]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


      MULTIPATH_ABANDON Frame {
        Type (i) = Type_mpAbandon,
        PathID (i),
        Reason Code (i)
      }

   TBC.

9.6.  MULTIPATH_ABANDON_ACK

      MULTIPATH_ABANDON_ACK Frame {
        Type (i) = Type_mpAbandonAck,
        PathID (i)
      }

   TBC.

9.7.  MULTIPATH_BINDING

      MULTIPATH_BINDING Frame {
        Type (i) = Type_mpBinding,
        PathID (i),
        CID sequence number (i)
       }

   TBC.

9.8.  MULTIPATH_ECN

      MULTIPATH_ECN Frame {
        Type (i) = Type_mpECN,
        PathID (i),
        ECN counts (..)
      }

   TBC.

9.9.  MULTIPATH_MAX_DATA

      MULTIPATH_MAX_DATA Frame {
        Type (i) = Type_mpMaxData,
        PathID (i),
        Maximum data (i)
      }

   TBC.





Gage                       Expires 14 May 2024                 [Page 12]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


10.  Security Considerations

   TBD.

11.  IANA Considerations

11.1.  New QUIC transport parameters

   *  enable_multipath

   *  max_active_paths

   TBC.

11.2.  New QUIC frame types

   *  Type_mpChallenge

   *  Type_mpResponse

   *  Type_mpStatus

   *  Type_mpStatusAck

   *  Type_mpBinding

   *  Type_mpAbandon

   *  Type_mpAbandonAck

   *  Type_mpECN

   *  Type_mpMaxData

   TBC.

12.  References

12.1.  Normative References

   [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/rfc/rfc2119>.

   [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/rfc/rfc8174>.



Gage                       Expires 14 May 2024                 [Page 13]

Internet-Draft         MPQUIC Alternate Path Model         November 2023


   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [RFC9002]  Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
              and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
              May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.

12.2.  Informative References

   [LAG]      Wikipedia, "Link aggregation", 18 October 2023,
              <https://en.wikipedia.org/wiki/Link_aggregation>.

   [MPQUIC-DRAFT]
              Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema,
              C., and M. Kühlewind, "Multipath Extension for QUIC", Work
              in Progress, Internet-Draft, draft-ietf-quic-multipath-06,
              23 October 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-quic-multipath-06>.

   [MPTCP]    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/rfc/rfc6824>.

   [QUIC-PROXY]
              Pauly, T., Rosenberg, E., and D. Schinazi, "QUIC-Aware
              Proxying Using HTTP", Work in Progress, Internet-Draft,
              draft-ietf-masque-quic-proxy-00, 17 August 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-masque-
              quic-proxy-00>.

Acknowledgements

   The authors would like to thank (manyfolks) for their input and
   contributions.

Author's Address

   Bill Gage
   Unaffiliated
   Ottawa
   Canada
   Email: billgage.ietf@gmail.com






Gage                       Expires 14 May 2024                 [Page 14]