BDP_Frame Extension
draft-kuhn-quic-bdpframe-extension-03

Internet Engineering Task Force                                  N. Kuhn
Internet-Draft                                       Thales Alenia Space
Intended status: Standards Track                              E. Stephan
Expires: 24 April 2024                                            Orange
                                                            G. Fairhurst
                                                  University of Aberdeen
                                                              C. Huitema
                                                    Private Octopus Inc.
                                                         22 October 2023

                          BDP_Frame Extension
                 draft-kuhn-quic-bdpframe-extension-03

Abstract

   This document describes the BDP_FRAME extension for QUIC.  The frame
   enables the exchange of Congestion Control (CC) parameters related to
   the path characteristics between the receiver and the sender during a
   connection.  These CC parameters allow a receiver to prepare to use
   any additional capacity that is made available when using Careful
   Resume.  It also allows a receiver to request that previously
   computed CC parameters, are not used when the receiver has additional
   information about the current path or traffic that is to be sent.

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 24 April 2024.

Copyright Notice

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

Kuhn, et al.              Expires 24 April 2024                 [Page 1]
Internet-Draft             BDP_Frame Extension              October 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Three approaches  . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Using the BDP_FRAME . . . . . . . . . . . . . . . . . . .   3
     1.3.  Optimizing Client Requests  . . . . . . . . . . . . . . .   4
   2.  Notation and Terms  . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   3.  BDP_Frame . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Extension activation  . . . . . . . . . . . . . . . . . .   6
     3.2.  Using the CC parameters with Care . . . . . . . . . . . .   7
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Interoperability and Use Cases  . . . . . . . . . . . . .   8
     4.2.  Identifying the Path  . . . . . . . . . . . . . . . . . .   8
     4.3.  Example use of an Endpoint Token  . . . . . . . . . . . .   9
     4.4.  Security Related to use of the Endpoint Token . . . . . .  10
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     7.1.  Protecton from Malicious Receivers  . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   This document extends the Careful Resume method
   [I-D.ietf-tsvwg-careful-resume] to allow sender-generated CC
   parameters to be stored at the receiver.  Transfering the CC
   parameters to a receiver, can release the sender from needing to
   retain CC parameter state for each receiver.  This also allows a
   receiver to implement a policy that informs a sender whether the
   receiver desires the sender to reuse previously saved CC parameters.

   It defines the method to exchange the CC parameters between a QUIC
   receiver and the sender in an interoperable manner.  The process is
   outlined here:

Kuhn, et al.              Expires 24 April 2024                 [Page 2]
Internet-Draft             BDP_Frame Extension              October 2023

   1.  For an established connection, the current RTT, measured capacity
       and receiver Endpoint Token are computed and are respectively
       stored as the saved_rtt, saved_capacity and saved_endpoint_token.
       These are placed within a BDP_FRAME.  The sender also computes a
       secured hash over these CC parameters and sends this within the
       BDP_FRAME.

   2.  The receiver can read the non-encrypted portion of the BDP_FRAME
       parameters.  It cannot verify the hash and is not permitted to
       modify any CC parameters.

   3.  At a later time, the receiver sends the BDP-FRAME to the sender
       to re-use previously computed CC parameters.

   4.  Upon reception, the sender MUST verify the hash, and only use the
       CC parameters when valid.  This is to prevent a receiver from
       modifying the parameters.  The sender is able to utilise the CC
       parameters in a received BDP_FRAME when it is connected to the
       same endpoint.

1.1.  Three approaches

   This section reviews three approaches to implement the storage of CC
   parameters:

      (1) The saved CC parameters are stored at the sender ("Local
      storage") and are not sent to a receiver, this does not use a
      BDP_Frame;

      (2) The saved CC parameters are transmitted to the receiver in a
      BDP_FRAME, these can be used when reconnecting, but a receiver
      does not read the CC parameters;

      (3) The saved CC parameters are transmitted to a receiver in a
      BDP_Frame, which can use these when reconnecting.  The receiver
      can also read, but not modify, the CC parameters to accept or not
      the use of these parameters.

1.2.  Using the BDP_FRAME

   The use of the BDP_Frame is negotiated with the receiver.

   A sender can send a BDP_FRAME to the receiver with CC parameters that
   were collected during the Careful Resume Observe Phase.

Kuhn, et al.              Expires 24 April 2024                 [Page 3]
Internet-Draft             BDP_Frame Extension              October 2023

   The receiver can read the BDP_Frame content and later decide to send
   the BDP_FRAME back to the sender in the header of an Initial packet,
   or later in a connection.  This frame needs to be received during the
   Reconaisance Phase of a Careful Resume sender.

1.3.  Optimizing Client Requests

   Where the receiver is aware it is using a path with high Bandwidth-
   Delay Product (BDP), it can also adapt other protocol parameters to
   better utilize the available capacity, e.g., to estimate a larger
   size for the flow credit.

   Some designs of application do not use long-lasting transport
   connections.  Instead, they use a series of shorter connections,
   typically each using the same path.  This style of application can
   benefit when the receiver provides an estimate of the expected
   characteristics (e.g., to adapt the content of quality for a video
   application; or anticipate the time taken to complete the
   transmission of an object).  An example scenario considers a client
   using Dynamic Adaptive Streaming over HTTPS (DASH) that is unable to
   receive sufficient data to reach the desired video playback quality
   supported by the path, because for each video chunk, the transport CC
   method needs to independently determine the path capacity.  In this
   example, a lower transfer rate is safe, but could lead to an overly
   conservative requested rate when the rate is based on the transport
   performance (i.e., the client could fail to increase the requested
   quality of video chunks, or to fill buffers to avoid stalling
   playback or to send high quality advertisements).  These client
   requests could then be adapted based on the previously observed path
   characteristics, enabling a client to increase the requested quality
   of video chunks, to fill receiver buffers and avoid stalling
   playback.

2.  Notation and Terms

   *  BDP: Bandwdith Delay Product of the path (maximum path capacity);

   *  saved_capacity: The capacity preserved from a previous connection;

   *  saved_rtt: The preserved minimum RTT, corresponding to the minimum
      of a set RTT of measurements taken at the time when the
      saved_capacity was estimated;

   *  endpoint_token: An Endpoint Token for a receiver;

   *  secured hash: hash generated by the sender using a list of CC
      parameters that it selected.  The sender uses a private key to
      protect the hash.

Kuhn, et al.              Expires 24 April 2024                 [Page 4]
Internet-Draft             BDP_Frame Extension              October 2023

2.1.  Requirements Language

   The keywords "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.

   Variable-length integer encoding is defined in section 16 of
   [RFC9000].

3.  BDP_Frame

   This section describes the use of a new QUIC Frame, the BDP_FRAME.
   This can be utilized by the congestion controller in the Careful
   Resume method.

   Sending a BDP_FRAME is not be limited by flow control limits.  The
   sender and the receiver MAY send multiple BDP_FRAMEs in both 1-RTT
   and 0-RTT connections.  The rate of update SHOULD be limited (e.g.,
   much less frequent than once for several RTTs).

   The format of a BDP_FRAME is shown in Figure 1.

   BDP_FRAME {
     Type (i) = 0xXXX,
     Hash (...),
     Lifetime (i),
     Saved Capacity (i),
     Saved RTT (i),
     Saved Endpoint Token (...)
   }

                         Figure 1: BDP_FRAME Format

   This contains the following fields:

   *  Hash (secured_hash): The secured_hash is generated by the sender
      using CC parameters from the BDP_FRAME.  The sender encrypts the
      hash to prevent the receiver from reading it, and allow the sender
      bto verify that the contents were not changed.

   *  Lifetime (extension_lifetime): The extension_lifetime is a value
      in milliseconds, encoded as a variable-length integer.  This
      follows the design of a NewSessionTicket of TLS [RFC8446].  This
      represents the validity in time of this extension.

Kuhn, et al.              Expires 24 April 2024                 [Page 5]
Internet-Draft             BDP_Frame Extension              October 2023

   *  Saved capacity estimate (saved_capacity): The saved_capacity is a
      value in bytes, encoded as a variable-length integer.  The
      available capacity can be estimated for the previous connection by
      the sender.  Using the previous values of bytes_in_flight defined
      in [RFC9002] can result in overshoot of the bottleneck capacity,
      and ought to be used carefully.  It is advised to not only use the
      amount of bytes in flight, but also the goodput.

   *  Saved RTT (saved_rtt): The saved_rtt is a value in milliseconds,
      encoded as a variable-length integer.  The saved_rtt is set to the
      min_rtt.  NOTE: The min_rtt defined in [RFC9002], does not track a
      decreasing RTT: therefore the min_rtt reported might be larger
      than the actual minimum RTT measured during the 1-RTT connection.

   *  Saved Endpoint Token (saved_endpoint_token) : Note: The Endpoint
      Token is defined in [I-D.ietf-tsvwg-careful-resume], and is
      discussed in the context of this protocol exchange in a later
      section.

3.1.  Extension activation

   The receiver can accept the transmission of BDP_FRAMEs from the
   sender by using the enable_bdp transport extension.

   enable_bdp (0xTBD): in the 1-RTT connection, the receiver indicates
   to the sender that it wishes to receive BDP extension Frames.  The
   default value is 0.  In this specification, enable_bdp values larger
   than 3 are reserved for future, and the receipt of these values MUST
   be treated as a connection error of type TRANSPORT_PARAMETER_ERROR
   [RFC9000].

   *  0: Default value.  If the receiver does not send an enable_bdp
      parameter, the sender considers that the receiver does not
      support, or does not wish to activate, the BDP extension.

   *  1: The receiver indicates to the sender that it wishes to receive
      BDP_FRAMEs and activates the optimization.

   *  2: The receiver indicates that it does not wish to receive BDP
      Frames, but activates the optimization.

   *  3: The receiver indicates that it wishes to receive BDP_FRAMEs,
      but does not activate the optimization.

   This Transport Parameter is encoded as described in Section 18 of
   [RFC9000].

Kuhn, et al.              Expires 24 April 2024                 [Page 6]
Internet-Draft             BDP_Frame Extension              October 2023

   If the receiver activates the extension, it agrees to receive and
   read BDP_FRAMEs.  If the receiver activates the optimization, it
   allows the sender to utilise the previously computed CC parameters.
   A receiver could then perform session resumption optimization without
   actually reading the previous CC parameters.

3.2.  Using the CC parameters with Care

   Care is needed in the use of any temporal information to assure safe
   use of the Internet and to be robust to changes in traffic patterns,
   network routing and link/node failures.  There are also cases where
   using the CC parameters of a previous connection are not appropriate,
   and a need to evaluate the potential for malicious use of the method.
   The specification for the QUIC transport protocol [RFC9000] therefore
   notes "Generally, implementations are advised to be cautious when
   using previous values on a new path."

   Careful exploitation of the CC parameters is discussed in
   [I-D.ietf-tsvwg-careful-resume].

4.  Discussion

   A receiver using the BDP_FRAME extension has the choice of allowing
   the reuse of the previous CC parameters, or requesting the sender to
   not reuse these parameters.

   This extension MUST NOT provide an opportunity for the current
   connection to be a vector for an amplification attack.  The QUIC
   address validation process, used to prevent amplification attacks,
   SHOULD be performed [RFC9000].

   The CC parameters are measured by the sender by observing a previous
   connection to the same receiver.  During transmission, the BDP_Frame
   is protected by the mechanism that protects the exchange of the 0-RTT
   transport parameters.  For version 1 of QUIC, the this is protected
   using the mechanism that already protects the "initial_max_data"
   parameter.  This is defined in sections 4.5 to 4.7 of [RFC9001].  It
   provides a way for the sender to verify that the CC parameters
   proposed by the receiver are the same as those that the sender sent
   to the receiver during a previous connection.

   Although a BDP_Frame is encrypted on transmission, a receiver could
   modify the value of the received CC parameters.  The sender detects
   this by adding a secured hash over the CC parameters.  If the
   receiver modifies any CC parameter, the result of the hash would be
   different.  If a sender fails to veridy the secured hash, it MUST not
   use the CC parameters.

Kuhn, et al.              Expires 24 April 2024                 [Page 7]
Internet-Draft             BDP_Frame Extension              October 2023

   An example of an implementation where the sender computes an Endpoint
   Token that seeks to uniquely identify the receiver is provided in
   Section 4.3.  The implementation details are independent from the
   specification of BDP_Frame.

4.1.  Interoperability and Use Cases

   Four cases are identified where Careful Resume is not appropriate and
   using the saved CC parameters could increase congestion:

   1.  The network path has changed and the new path is different.  This
       might be evident from a change of local interface, a change in
       the client or sender IP address, or similar indication from the
       network.  The saved CC parameters are not appropriate.

   2.  The network path has changed, but the new path is not known to be
       different.  This case might be accompanied by a change in the
       RTT, or evident by loss observed at the start of the new
       connection.  This case could be detected in the Careful Resume
       Reconaissance Phase.  The saved CC parameters are not appropriate
       to the current path.

   3.  The network conditions have changed and it is discovered that the
       current capacity is less than the previously estimated bottleneck
       capacity.  Using the saved CC parameters would then increase
       congestion, and the flow needs to adjust to a lower safe rate.

   4.  The stored CC parameters are too old.  It is no longer reasonable
       to expect the path to have same characteristics, and the the
       saved CC parameters are not appropriate.

   In all these cases, a sender needs to return to the normal CC
   behavior.  The method can still be used to characterize the new path,
   enabling later flows to use the Careful Resume method.

4.2.  Identifying the Path

   In a simple network scenario, the sending endpoint could use the IP
   source address to identify a path.  This could work when one
   globally-allocated IP address is set per interface.  There are many
   cases where the IP address would not an acceptable to identify a
   path.  Section 8 of [RFC9040] describes cases where the IP address is
   not a suitable value when performing TCP control block sharing.  In
   general the IP address of the sender is made public in the network-
   layer header of IP packets.  When sharing internal state, [RFC6973]
   identifies relevant privacy considerations.

Kuhn, et al.              Expires 24 April 2024                 [Page 8]
Internet-Draft             BDP_Frame Extension              October 2023

   Examples of network uses where a source address is not a suitable
   endpoint token include:

   *  The sending endpoint might not be identifiable remotely from its
      IP address because a device on the network path translates the
      address using a form of NAT/NAPT.  In this case, a private IP
      address might be used, which does not identify a specific
      endpoint.

   *  In some cases, a sender can choose to vary the source address over
      time to avoid linkability in the observable IP header, e.g., when
      the source address embeds private information, such as an
      endpoint's MAC address/EIDID.

   Note: There are use-cases where for the purpose of identifying a
   path, the token does not need to be globally unique, but needs to be
   sufficiently unique to prevent attempts to misrepresent the path
   being used such as an attack on the congestion controller.  Using a
   smaller size of token can add to the ambiguity set, reducing this
   likability.

   NOTE: A different Endpoint Token is used for each direction of
   transmission.  A receiver might decide not to provide an Endpoint
   Token to a sender, to avoid exposing additional linkable information
   (but also preventing use of any mechanism that relies on the token).

4.3.  Example use of an Endpoint Token

   The sender computes an Endpoint Token that seeks to uniquely identify
   the path that it uses to communicate with the receiver (1) this is
   associated with the path information it sends.  The Endpoint Token
   ought to be encrypted to avoid sending linkable information
   observable to eavesdroppers on the path.  The receiver stores the
   path information together with the Endpoint Token, together with the
   sender's address/name (2).  When the receiver later wishes the sender
   to use the stored path information it returns the information to the
   sender (3) together with the Endpoint Token.  The sender recomputes
   the Endpoint Token and compares this with the received Endpoint Token
   before using the CC parameters.

   1.  The Sender transmits the Endpoint Token to the Receiver;

   2.  The Receiver holds an Endpoint Token;

   3.  The Receiver transmits the Endpoint Token to the Sender.

Kuhn, et al.              Expires 24 April 2024                 [Page 9]
Internet-Draft             BDP_Frame Extension              October 2023

4.4.  Security Related to use of the Endpoint Token

   A number of security-related topics have been identified concerning
   the potential exposure of the identity on the path.  This information
   can also be visible in the IP source address or higher-layer data,
   but can be hidden from a remote endpoint using methods such as MASQUE
   proxy.  When used to inform the transport system using a layered
   proxy, the transport endpoint token refers to the endpoints of the
   outer QUIC header, and hence the proxy itself, not the end-to-end
   communication relayed by the proxy.

   A sender might decide to not use this method if it has a strong
   requirement to prevent flows being linkable with previous flows to
   the same endpoint.  A decision not to provide an Endpoint Token
   necessarily prevents the sender from requesting the receiver to
   return path information to allow the same CC parameters to be re-
   used, potentially strengthening privacy but consequently eliminating
   any performance benefits.

5.  Acknowledgments

   The authors thank Gabriel Montenegro, Patrick McManus, Ian Swett,
   Igor Lubashev, Robin Marx, Roland Bless and Franklin Simo for their
   fruitful comments on earlier versions of this document.

   The authors particularly thank Tom Jones for co-authoring previous
   versions of this document.

6.  IANA Considerations

   {XXX-Editor note: Text is required to register the BDP_Frame and the
   enable_bdp transport parameter.  Parameters are registered using the
   procedure defined in [RFC9000].}

   TBD: Text is required to register the BDP_FRAME and the enable_bdp
   transport parameter.  Parameters are registered using the procedure
   defined in [RFC9000].

7.  Security Considerations

   Security considerations for the CC method are discussed in the
   Security Considerations section of Careful Resume.

7.1.  Protecton from Malicious Receivers

   The sender MUST check the integrity of the saved_rtt and
   saved_capacity parameters received from a receiver.

Kuhn, et al.              Expires 24 April 2024                [Page 10]
Internet-Draft             BDP_Frame Extension              October 2023

   There are several solutions to avoid attacks by malicious receivers:

   *  Solution #1 : The sender stores a local estimate of the capacity
      and RTT parameters as the saved_capacity and saved_rtt.

   *  Solution #2 : The sender sends the estimate of the capacity and
      RTT parameters to the receiver as the saved_capacity and saved_rtt
      in a block of CC parameters that is authenticated by the secure
      hash including local key information.  The parameters may be
      encryptedd and are not read by the rceeiver.  The receiver resends
      the same CC parameters for a new connection.  The sender can use
      its local key information to authenticate the CC parameters,
      without needing to keep a local copy of the parameters.

   *  Solution #3 : This approach is the same as above, except the
      receiver can read the saved_rtt and saved_capacity parameters and
      could enable a receiver to decide whether the new CC parameters
      are thought appropriate, based on receiver-side information about
      the network conditions, connectivity, or needs of the new
      connection.  The sender will verify that the receiver did not
      change the CC parameters inside the frame.

8.  References

8.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/info/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/info/rfc8174>.

   [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/info/rfc9000>.

8.2.  Informative References

Kuhn, et al.              Expires 24 April 2024                [Page 11]
Internet-Draft             BDP_Frame Extension              October 2023

   [I-D.ietf-tsvwg-careful-resume]
              Kuhn, N., Emile, S., Fairhurst, G., and C. Huitema,
              "Convergence of Congestion Control from Retained State",
              Work in Progress, Internet-Draft, draft-ietf-tsvwg-
              careful-resume-03, 28 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
              careful-resume-03>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/info/rfc6973>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9001]  Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
              QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
              <https://www.rfc-editor.org/info/rfc9001>.

   [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/info/rfc9002>.

   [RFC9040]  Touch, J., Welzl, M., and S. Islam, "TCP Control Block
              Interdependence", RFC 9040, DOI 10.17487/RFC9040, July
              2021, <https://www.rfc-editor.org/info/rfc9040>.

Appendix A.  Change Log

   This section to be rmeoved prior to publication.

      -00 Introduced session tickets and BDP_Frames

      -01 Reviewed receiver actions when a receiver holds CC parameters

      -02 Interim version to align with terminology in Careful Resume

      -03 Rewritten to align with Careful Resume and use the BDP_Frame
      method.  Removed annexe 1, and discussion of session tickets,
      prefering BDP Frames.

Authors' Addresses

   Nicolas Kuhn
   Thales Alenia Space

Kuhn, et al.              Expires 24 April 2024                [Page 12]
Internet-Draft             BDP_Frame Extension              October 2023

   Email: nicolas.kuhn.ietf@gmail.com

   Emile Stephan
   Orange
   Email: emile.stephan@orange.com

   Godred Fairhurst
   University of Aberdeen
   Department of Engineering
   Fraser Noble Building
   Aberdeen
   AB24 3UE
   United Kingdom
   Email: gorry@erg.abdn.ac.uk

   Christian Huitema
   Private Octopus Inc.
   Email: huitema@huitema.net

Kuhn, et al.              Expires 24 April 2024                [Page 13]