doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc5634.txt b/doc/rfc/rfc5634.txt
new file mode 100644
index 0000000..1731116
--- /dev/null
+++ b/doc/rfc/rfc5634.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                       G. Fairhurst
+Request for Comments: 5634                               A. Sathiaseelan
+Category: Experimental                            University of Aberdeen
+                                                             August 2009
+
+
+    Quick-Start for the Datagram Congestion Control Protocol (DCCP)
+
+Abstract
+
+   This document specifies the use of the Quick-Start mechanism by the
+   Datagram Congestion Control Protocol (DCCP).  DCCP is a transport
+   protocol that allows the transmission of congestion-controlled,
+   unreliable datagrams.  DCCP is intended for applications such as
+   streaming media, Internet telephony, and online games.  In DCCP, an
+   application has a choice of congestion control mechanisms, each
+   specified by a Congestion Control Identifier (CCID).  This document
+   specifies general procedures applicable to all DCCP CCIDs and
+   specific procedures for the use of Quick-Start with DCCP CCID 2, CCID
+   3, and CCID 4.  Quick-Start enables a DCCP sender to cooperate with
+   Quick-Start routers along the end-to-end path to determine an allowed
+   sending rate at the start of a connection and, at times, in the
+   middle of a DCCP connection (e.g., after an idle or application-
+   limited period).  The present specification is provided for use in
+   controlled environments, and not as a mechanism that would be
+   intended or appropriate for ubiquitous deployment in the global
+   Internet.
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 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 in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                      [Page 1]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................4
+   2. Quick-Start for DCCP ............................................5
+      2.1. Sending a Quick-Start Request for a DCCP Flow ..............5
+           2.1.1. The Quick-Start Interval ............................5
+      2.2. Receiving a Quick-Start Request for a DCCP Flow ............6
+           2.2.1. The Quick-Start Response Option .....................7
+      2.3. Receiving a Quick-Start Response ...........................8
+           2.3.1. The Quick-Start Mode ................................8
+           2.3.2. The Quick-Start Validation Phase ....................9
+      2.4. Procedure When No Response to a Quick-Start Request .......10
+      2.5. Procedure When a Packet Is Dropped While Using
+           Quick-Start ...............................................11
+      2.6. Interactions with Mobility and Signaled Path Changes ......11
+      2.7. Interactions with Path MTU Discovery ......................12
+      2.8. Interactions with Middleboxes .............................12
+   3. Mechanisms for Specific CCIDs ..................................13
+      3.1. Quick-Start for CCID 2 ....................................13
+           3.1.1. The Quick-Start Request for CCID 2 .................13
+           3.1.2. Sending a Quick-Start Response with CCID 2 .........13
+           3.1.3. Using the Quick-Start Response with CCID 2 .........13
+           3.1.4. Quick-Start Validation Phase for CCID 2 ............14
+           3.1.5. Reported Loss or Congestion While Using
+                  Quick-Start ........................................14
+           3.1.6. CCID 2 Feedback Traffic on the Reverse Path ........15
+      3.2. Quick-Start for CCID 3 ....................................15
+           3.2.1. The Quick-Start Request for CCID 3 .................15
+           3.2.2. Sending a Quick-Start Response with CCID 3 .........15
+           3.2.3. Using the Quick-Start Response with CCID 3 .........16
+           3.2.4. Quick-Start Validation Phase for CCID 3 ............17
+           3.2.5. Reported Loss or Congestion during the
+                  Quick-Start Mode or Validation Phase ...............17
+           3.2.6. CCID 3 Feedback Traffic on the Reverse Path ........18
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                      [Page 2]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+      3.3. Quick-Start for CCID 4 ....................................18
+           3.3.1. The Quick-Start Request for CCID 4 .................18
+           3.3.2. Sending a Quick-Start Response with CCID 4 .........18
+           3.3.3. Using the Quick-Start Response with CCID 4 .........18
+           3.3.4. Reported Loss or Congestion While Using
+                  Quick-Start ........................................19
+           3.3.5. CCID 4 Feedback Traffic on the Reverse Path ........19
+   4. Discussion of Issues ...........................................19
+      4.1. Overrun and the Quick-Start Validation Phase ..............19
+      4.2. Experimental Status .......................................19
+   5. IANA Considerations ............................................20
+   6. Acknowledgments ................................................20
+   7. Security Considerations ........................................20
+   8. References .....................................................21
+      8.1. Normative References ......................................21
+      8.2. Informative References ....................................21
+
+1.  Introduction
+
+   The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a
+   transport protocol for congestion-controlled, unreliable datagrams,
+   intended for applications such as streaming media, Internet
+   telephony, and online games.
+
+   In DCCP, an application has a choice of congestion control
+   mechanisms, each specified by a Congestion Control Identifier (CCID)
+   [RFC4340].  There are general procedures applicable to all DCCP CCIDs
+   that are described in Section 2, and details that relate to how
+   individual CCIDs should operate, which are described in Section 3.
+   This separation of CCID-specific and DCCP general functions is in the
+   spirit of the modular approach adopted by DCCP.
+
+   Quick-Start [RFC4782] is an experimental mechanism for transport
+   protocols specified for use in controlled environments.  The current
+   specification of this mechanism is not intended or appropriate for
+   ubiquitous deployment in the global Internet.
+
+   Quick-Start is designed for use between end hosts within the same
+   network or on Internet paths that include IP routers.  It works in
+   cooperation with routers, allowing a sender to determine an allowed
+   sending rate at the start and at times in the middle of a data
+   transfer (e.g., after an idle or application-limited period).
+
+   This document assumes the reader is familiar with RFC 4782 [RFC4782],
+   which specifies the use of Quick-Start with IP and with TCP.  Section
+   7 of RFC 4782 also provides guidelines for the use of Quick-Start
+
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                      [Page 3]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+   with other transport protocols, including DCCP.  This document
+   provides answers to some of the issues that were raised by RFC 4782
+   and provides a definition of how Quick-Start must be used with DCCP.
+
+   In using Quick-Start, the sending DCCP end host indicates the desired
+   sending rate in bytes per second, using a Quick-Start option in the
+   IP header of a DCCP packet.  Each Quick-Start-capable router along
+   the path could, in turn, either approve the requested rate, reduce
+   the requested rate, or indicate that the Quick-Start Request is not
+   approved.
+
+   If the Quick-Start Request is approved (possibly with a reduced rate)
+   by all the routers along the path, then the DCCP receiver returns an
+   appropriate Quick-Start Response.  On receipt of this, the sending
+   end host can send at up to the approved rate for a period determined
+   by the method specified for each DCCP CCID, and not exceeding three
+   round-trip times.  Subsequent transmissions will be governed by the
+   default CCID congestion control mechanisms for the connection.  If
+   the Quick-Start Request is not approved, then the sender must use the
+   default congestion control mechanisms.
+
+   DCCP receivers are not required to acknowledge individual packets (or
+   pairs of segments) as in TCP.  CCID 2 [RFC4341] allows much less
+   frequent feedback.  Rate-based protocols (e.g., TCP-Friendly Rate
+   Control (TFRC) [RFC5348], CCID 3 [RFC4342]) have a different feedback
+   mechanism than that of TCP.  With rate-based protocols, feedback may
+   be sent less frequently (e.g., once per Round-Trip Time (RTT)).  In
+   such cases, a sender using Quick-Start needs to implement a different
+   mechanism to determine whether the Quick-Start sending rate has been
+   sustained by the network.  This introduces a new mechanism called the
+   Quick-Start Validation Phase (Section 2.3).
+
+   In addition, this document defines two more general enhancements that
+   refine the use of Quick-Start after a flow has started (expected to
+   be more common in applications using DCCP).  These are the Quick-
+   Start Interval (Section 2.1.2), and the reaction to mobility triggers
+   (Section 2.6).
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                      [Page 4]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+2.  Quick-Start for DCCP
+
+   Unless otherwise specified, DCCP end hosts follow the procedures
+   specified in Section 4 of [RFC4782], following the use specified for
+   Quick-Start with TCP.
+
+2.1.  Sending a Quick-Start Request for a DCCP Flow
+
+   A DCCP sender MAY use a Quick-Start Request during the start of a
+   connection, when the sender would prefer to have a larger initial
+   rate than allowed by standard mechanisms (e.g., [RFC5348] or
+   [RFC3390]).
+
+   A Quick-Start Request MAY also be used once a DCCP flow is connected
+   (i.e., in the middle of a DCCP flow).  In standard operation, DCCP
+   CCIDs can constrain the sending rate (or window) to less than that
+   desired (e.g., when an application increases the rate at which it
+   wishes to send).  A DCCP sender that has data to send after an idle
+   period or application-limited period (i.e., where the sender has
+   transmitted at less than the allowed sending rate) can send a Quick-
+   Start Request using the procedures defined in Section 3.
+
+   Quick-Start Requests will be more effective if the Quick-Start Rate
+   is not larger than necessary.  Each requested Quick-Start Rate that
+   has been approved, but was not fully utilized, takes away from the
+   bandwidth pool maintained by Quick-Start routers that would be
+   otherwise available for granting successive requests [RFC4782].
+
+   In contrast to most TCP applications, many DCCP applications have the
+   notion of a natural media rate that they wish to achieve.  For
+   example, during the initial connection, a host may request a Quick-
+   Start Rate equal to the media rate of the application, appropriately
+   increased to account for the size of packet headers.  (Note that
+   Quick-Start only provides a course-grain indication of the desired
+   rate that is expected to be sent in the next RTT.)
+
+   When sending a Quick-Start Request, the DCCP sender SHOULD send the
+   Quick-Start Request using a packet that requires an acknowledgement,
+   such as a DCCP-Request, DCCP-Response, or DCCP-Data.
+
+2.1.1.  The Quick-Start Interval
+
+   Excessive use of the Quick-Start mechanism is undesirable.  This
+   document defines an enhancement to RFC 4782 to update the use of
+   Quick-Start after a DCCP flow has started, by introducing the concept
+   of the Quick-Start Interval.  The Quick-Start Interval specifies a
+   period of time during which a Quick-Start Request SHOULD NOT be sent.
+   The Quick-Start Interval is measured from the time of transmission of
+
+
+
+Fairhurst & Sathiaseelan      Experimental                      [Page 5]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+   the previous Quick-Start Request (Section 2.1).  The Quick-Start
+   Interval MAY be overridden as a result of a network path change
+   (Section 2.6).
+
+   When a connection is established, the Quick-Start Interval is
+   initialized to the Initial_QSI.  The Initial_QSI MUST be at least 6
+   seconds (larger values are permitted).  This value was chosen so that
+   it is sufficiently large to prevent excessive router processing over
+   typical Internet paths.  Quick-Start routers that track per-flow
+   state MAY penalize senders by suspending Quick-Start processing of
+   flows that make Quick-Start Requests for the same flow with an
+   interval less than 6 seconds.
+
+   When the first Quick-Start Request is sent, the Quick-Start Interval
+   is set to:
+
+   Quick-Start Interval = Initial_QSI;
+
+   After sending each subsequent Quick-Start Request, the Quick-Start
+   Interval is then recalculated as:
+
+   Quick-Start Interval = max(Quick-Start Interval * 2, 4 * RTT);
+
+   Each unsuccessful Quick-Start Request therefore results in the
+   Quick-Start Interval being doubled (resulting in an exponential
+   back-off).  The maximum time the sender can back off is 64 seconds.
+   When the back-off calculation results in a larger value, the sender
+   MUST NOT send any further Quick-Start Requests for the remainder of
+   the DCCP connection (i.e., the sender ceases to use Quick-Start).
+
+   Whenever a Quick-Start Request is approved (at any rate), the Quick-
+   Start Interval is reset to the Initial_QSI.
+
+2.2.  Receiving a Quick-Start Request for a DCCP Flow
+
+   The procedure for processing a received Quick-Start Request is
+   normatively defined in [RFC4782] and summarized in this paragraph.
+   An end host that receives an IP packet containing a Quick-Start
+   Request passes the Quick-Start Request, along with the value in the
+   IP Time to Live (TTL) field, to the receiving DCCP layer.  If the
+   receiving host is willing to permit the Quick-Start Request, it
+   SHOULD respond immediately by sending a packet that carries the
+   Quick-Start Response option in the DCCP header of the corresponding
+   feedback packet (e.g., using a DCCP-Ack packet or in a DCCP-DataAck
+   packet).
+
+
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                      [Page 6]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+   The Rate Request field in the Quick-Start Response option is set to
+   the received value of the Rate Request in the Quick-Start option or
+   to a lower value if the DCCP receiver is only willing to allow a
+   lower Rate Request.  Where information is available (e.g., knowledge
+   of the local Layer 2 interface speed), a Quick-Start receiver SHOULD
+   verify that the received rate does not exceed its expected receive
+   link capacity.  The TTL Diff field in the Quick-Start Response is set
+   to the difference between the received IP TTL value (Hop Limit field
+   in IPv6) and the Quick-Start TTL value.  The Quick-Start Nonce in the
+   Response is set to the received value of the Quick-Start Nonce in the
+   Quick-Start option (or IPv6 Header Extension).
+
+   The Quick-Start Response MUST NOT be resent if it is lost in the
+   network [RFC4782].  Packet loss could be an indication of congestion
+   on the return path; in which case, it is better not to approve the
+   Quick-Start Request.
+
+   If an end host receives an IP packet with a Quick-Start Request with
+   a requested rate of zero, then this host SHOULD NOT send a Quick-
+   Start Response [RFC4782].
+
+2.2.1.  The Quick-Start Response Option
+
+   The Quick-Start Response message must be carried by the transport
+   protocol using Quick-Start.  This section defines a DCCP Header
+   option used to carry the Quick-Start Response.  This header option is
+   REQUIRED for end hosts to utilize the Quick-Start mechanism with DCCP
+   flows.  The format resembles that defined for TCP [RFC4782].
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Type=45      |  Length=8     | Resv. | Rate  |   TTL Diff    |
+   |               |               |       |Request|               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Quick-Start Nonce                     | R |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 1.  The Quick-Start Response Option
+
+   The first byte of the Quick-Start Response option contains the option
+   kind, identifying the DCCP option (45).
+
+   The second byte of the Quick-Start Response option contains the
+   option length in bytes.  The length field MUST be set to 8 bytes.
+
+
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                      [Page 7]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+   The third byte of the Quick-Start Response option contains a four-
+   bit Reserved field, and the four-bit allowed Rate Request, formatted
+   as in the IP Quick-Start Rate Request option [RFC4782].
+
+   The fourth byte of the DCCP Quick-Start Response option contains the
+   TTL Diff.  The TTL Diff contains the difference between the IP TTL
+   and Quick-Start TTL fields in the received Quick-Start Request
+   packet, as calculated in [RFC4782].
+
+   Bytes 5-8 of the DCCP option contain the 30-bit Quick-Start Nonce and
+   a 2-bit Reserved field [RFC4782].
+
+2.3.  Receiving a Quick-Start Response
+
+   On reception of a Quick-Start Response packet, the sender MUST report
+   the approved rate, by sending a Quick-Start Report of Approved Rate
+   [RFC4782].  This report includes the Rate Report field set to the
+   Approved Rate, and the QS Nonce set to the QS Nonce value sent in the
+   Quick-Start Request.
+
+   The Quick-Start Report of Approved Rate is sent as an IPv4 option or
+   IPv6 header extension using the first Quick-Start Packet or sent as
+   an option using a DCCP control packet if there are no DCCP-Data
+   packets pending transmission.
+
+   The Quick-Start Interval is also reset (as described in Section
+   2.1.1).
+
+   Reception of a Quick-Start Response packet that approves a rate
+   higher than the current rate results in the sender entering the
+   Quick-Start Mode.
+
+2.3.1.  The Quick-Start Mode
+
+   While a sender is in the Quick-Start Mode, all sent packets are known
+   as Quick-Start Packets [RFC4782].  The Quick-Start Packets MUST be
+   sent at a rate not greater than the rate specified in the Quick-
+   Start Response.  The Quick-Start Mode continues for a period up to
+   one RTT (shorter, if a feedback message arrives acknowledging the
+   receipt of one or more Quick-Start Packets).
+
+   The procedure following exit of the Quick-Start Mode is specified in
+   the following paragraphs.  Note that this behavior is CCID-specific
+   and the details for each current CCID are described in Section 3.
+
+
+
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                      [Page 8]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+2.3.2.  The Quick-Start Validation Phase
+
+   After transmitting a set of Quick-Start Packets in the Quick-Start
+   Mode (and providing that no loss or congestion is reported), the
+   sender enters the Quick-Start Validation Phase.  This phase persists
+   for a period during which the sender seeks to affirm that the
+   capacity used by the Quick-Start Packets did not introduce
+   congestion.  This phase is introduced, because unlike TCP, DCCP
+   senders do not necessarily receive frequent feedback that would
+   indicate the congestion state of the forward path.
+
+   While in the Quick-Start Validation Phase, the sender is tentatively
+   permitted to continue sending using the Quick-Start rate.  This phase
+   normally concludes when the sender receives feedback that includes an
+   acknowledgment that all Quick-Start Packets were received.
+
+   However, the duration of the Quick-Start Validation Phase MUST NOT
+   exceed the Quick-Start Validation Time (a maximum of 2 RTTs).
+   Implementations may set a timer (initialized to the Quick-Start
+   Validation Time) to detect the end of this phase.  There may be scope
+   for optimization of timer resources in an implementation, since the
+   Quick-Start Validation period temporarily enforces more strict
+   monitoring of acknowledgements than normally used in a CCID (e.g., an
+   implementation may consider using a common timer resource for Quick-
+   Start Validation and a nofeedback timer).
+
+   An example sequence of packet exchanges showing Quick-Start with DCCP
+   is shown in Figure 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                      [Page 9]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+                      DCCP Sender                     DCCP Receiver
+   Quick-Start      +----------------------------------------------+
+   Request/Response | Quick-Start Request -->                      |
+                    |                    <-- Quick-Start Response  |
+                    | Quick-Start Approve -->                      |
+                    +----------------------------------------------+
+                    +----------------------------------------------+
+   Quick-Start      | Quick-Start Packets -->                      |
+   Mode             | Quick-Start Packets -->                      |
+                    |                  <-- Feedback A from Receiver|
+                    |               (acknowledging first QS Packet)|
+                    +----------------------------------------------+
+                    +----------------------------------------------
+   Quick-Start      | Packets -->                                  |
+   Validation Phase |                  <-- Feedback B from Receiver|
+                    |                (acknowledging all QS Packets)|
+                    +----------------------------------------------
+                    +----------------------------------------------+
+   DCCP             | Packets -->                                  |
+   Congestion       |                  <-- Feedback C from Receiver|
+   Control          |                                              |
+
+           Figure 2.  The Quick-Start Mode and Validation Phase
+
+   On conclusion of the Validation Phase (Feedback B in the above
+   figure), the sender expects to receive assurance that it may safely
+   use the current rate.  A sender that completes the Quick-Start
+   Validation Phase with no reported packet loss or congestion stops
+   using the Quick-Start rate and continues to adjust its rate using the
+   standard congestion control mechanisms.  For example, if the DCCP
+   sender was in slow-start prior to the Quick-Start Request, and no
+   packets were lost or ECN-marked (Explicit Congestion Notification)
+   since that time, then the sender continues in slow-start after
+   exiting Quick-Start Mode until the sender sees a packet loss, or
+   congestion is reported.
+
+2.4.  Procedure When No Response to a Quick-Start Request
+
+   As in TCP, if a Quick-Start Request is dropped (i.e., the Request or
+   Response is not delivered by the network) the DCCP sender MUST revert
+   to the congestion control mechanisms it would have used if the
+   Quick-Start Request had not been approved.  The connection is not
+   permitted to send a subsequent Quick-Start Request before expiry of
+   the current Quick-Start Interval (Section 2.1.1).
+
+
+
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 10]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+2.5.  Procedure When a Packet Is Dropped While Using Quick-Start
+
+   A lost or ECN-marked packet is an indication of potential network
+   congestion.  The behavior of a DCCP sender following a lost or ECN-
+   marked Quick-Start Packet or a lost feedback packet is specific to a
+   particular CCID (see Section 3).
+
+2.6.  Interactions with Mobility and Signaled Path Changes
+
+   The use of Quick-Start may assist end hosts in determining when it is
+   appropriate to increase their rate following an explicitly signaled
+   change of the network path.
+
+   When an end host receives a signal from an upstream link/network
+   notifying it of a path change, the change could simultaneously impact
+   more than one flow, and may affect flows between multiple endpoints.
+   Senders should avoid responding immediately, since this could result
+   in unwanted synchronization of signaling messages, and control loops
+   (e.g., a synchronized attempt to probe for a larger congestion
+   window), which may negatively impact the performance of the network
+   and transport sessions.  In Quick-Start, this could increase the rate
+   of Quick-Start Requests, possibly incurring additional router load,
+   and may result in some requests not being granted.  A sender must
+   ensure this does not generate an excessive rate of Quick-Start
+   Requests by using the method below:
+
+   A sender that has explicit information that the network path has
+   changed (e.g., a mobile IP binding update [RFC3344], [RFC3775])
+   SHOULD reset the Quick-Start Interval to its initial value (specified
+   in Section 2.1.1).
+
+   The sender MAY also send a Quick-Start Request to determine a new
+   safe transmission rate, but must observe the following rules:
+
+   - It MUST NOT send a Quick-Start Request within a period less than
+     the initial Quick-Start Interval (Initial_QSI) since it previously
+     sent a Quick-Start Request.  That is, it must wait for at least a
+     period of Initial_QSI after the previous request, before sending a
+     new Quick-Start Request.
+
+   - If it has not sent a Quick-Start Request within the previous
+     Initial_QSI period, it SHOULD defer sending a Quick-Start Request
+     for a randomly chosen period between 0 and the Initial_QSI value in
+     seconds.  The random period should be statistically independent
+     between different hosts and between different connections on the
+     same host.  This delay is to mitigate the effect on router load of
+     synchronized responses by multiple connections in response to a
+     path change that affects multiple connections.
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 11]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+   Hosts do not generally have sufficient information to choose an
+   appropriate randomization interval.  This value was selected to
+   ensure randomization of requests over the Quick-Start Interval.  In
+   networks where a large number of senders may potentially be impacted
+   by the same signal, a larger value may be desirable (or methods may
+   be used to control this effect in the path change signaling).
+
+2.7.  Interactions with Path MTU Discovery
+
+   DCCP implementations are encouraged to support Path MTU Discovery
+   (PMTUD) when applications are able to use a DCCP packet size that
+   exceeds the default Path MTU [RFC4340], [RFC4821].  Quick-Start
+   Requests SHOULD NOT be sent with packets that are used as a PMTUD
+   Probe Packet, since these packets could be lost in the network
+   increasing the probability of loss of the request.  It may therefore
+   be preferable to separately negotiate the PMTU and the use of Quick-
+   Start.
+
+   The DCCP protocol is datagram-based and therefore the size of the
+   segments that are sent is a function of application behavior as well
+   as being constrained by the largest supported Path MTU.
+
+2.8.  Interactions with Middleboxes
+
+   A Quick-Start Request is carried in an IPv4 packet option or IPv6
+   extension header [RFC4782].  Interactions with network devices
+   (middleboxes) that inspect or modify IP options could therefore lead
+   to discard, ICMP error, or DCCP-Reset when attempting to forward
+   packets carrying a Quick-Start Request.
+
+   If a DCCP sender sends a DCCP-Request that also carries a Quick-
+   Start Request, and does not receive a DCCP-Response to the packet,
+   the DCCP sender SHOULD resend the DCCP-Request packet without
+   including a Quick-Start Request.
+
+   Similarly, if a DCCP sender receives a DCCP-Reset in response to a
+   DCCP-Request packet that also carries a Quick-Start Request, then the
+   DCCP sender SHOULD resend the DCCP-Request packet without the Quick-
+   Start Request.  The DCCP sender then ceases to use the Quick-Start
+   Mechanism for the remainder of the connection.
+
+   A DCCP sender that uses a Quick-Start Request within an established
+   connection and does not receive a response will treat this as non-
+   approval of the request.  Successive unsuccessful attempts will
+   result in an exponential increase in the Quick-Start Interval
+   (Section 2.1.1).  If this grows to a value exceeding 64 seconds, the
+   DCCP sender ceases to use the Quick-Start Mechanism for the remainder
+   of the connection.
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 12]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+3.  Mechanisms for Specific CCIDs
+
+   The following sections specify the use of Quick-Start with DCCP CCID
+   2, CCID 3, and for DCCP with TFRC-SP as specified in CCID 4.
+
+3.1.  Quick-Start for CCID 2
+
+   This section describes the Quick-Start mechanism to be used with DCCP
+   CCID 2 [RFC4341].  CCID 2 uses a TCP-like congestion control
+   mechanism.
+
+3.1.1.  The Quick-Start Request for CCID 2
+
+   A Quick-Start Request MAY be sent to allow the sender to determine if
+   it is safe to use a larger initial cwnd.  This permits a faster
+   start-up of a new CCID 2 flow.
+
+   A Quick-Start Request MAY also be sent for an established connection
+   to request a higher sending rate after an idle period or
+   application-limited period (described in Section 2.1).  This allows a
+   receiver to use a larger cwnd than allowed with standard operation.
+
+   A Quick-Start Request that follows a reported loss or congestion
+   event MUST NOT request a Quick-Start rate that exceeds the largest
+   congestion window achieved by the CCID 2 connection since the last
+   packet drop (translated to a sending rate).
+
+3.1.2.  Sending a Quick-Start Response with CCID 2
+
+   A receiver processing a Quick-Start Request uses the method described
+   in Section 2.3.  On receipt of a Quick-Start Request, the receiver
+   MUST send a Quick-Start Response (even if a receiver is constrained
+   by the ACK Ratio).
+
+3.1.3.  Using the Quick-Start Response with CCID 2
+
+   On receipt of a valid Quick-Start Response option, the sender MUST
+   send a Quick-Start Approved option [RFC4782] (see Section 2.3).
+
+   If the approved Quick-Start rate is less than current sending rate,
+   the sender does not enter the Quick-Start Mode, and continues using
+   the procedure defined in CCID 2.
+
+   If the approved Quick-Start rate at the sender exceeds the current
+   sending rate, the sender enters the Quick-Start Mode and continues in
+   the Quick-Start Mode for a maximum period of one RTT.
+
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 13]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+   The sender sets its Quick-Start cwnd (QS_cwnd) as follows:
+
+      QS_cwnd = (R * T) / (s + H)                          (1)
+
+   where R is the Rate Request in bytes per second, T is the measured
+   round-trip path delay (RTT), s is the packet size, and H is the
+   estimated DCCP/IP header size in bytes (e.g., 32 bytes for DCCP
+   layered directly over IPv4, but larger when using IPsec or IPv6).
+
+   A CCID 2 sender MAY then increase its cwnd to the QS_cwnd.  The cwnd
+   should not be reduced (i.e., a QS_cwnd lower than cwnd should be
+   ignored, since the CCID 2 congestion control method already permits
+   this rate).  CCID 2 is not a rate-paced protocol.  Therefore, if the
+   QS_cwnd is used, the sending host MUST implement a suitable method to
+   pace the rate at which the Quick-Start Packets are sent until it
+   receives a DCCP-ACK for a packet sent during the Quick-Start Mode
+   [RFC4782].  The sending host SHOULD also record the previous cwnd and
+   note that the new cwnd has been determined by Quick-Start, rather by
+   other means (e.g., by setting a flag to indicate that it is in Quick-
+   Start Mode).
+
+   When the sender receives the first DCCP-ACK to a packet sent in the
+   Quick-Start Mode, it leaves the Quick-Start Mode and enters the
+   Validation Phase.
+
+3.1.4.  Quick-Start Validation Phase for CCID 2
+
+   A CCID 2 sender MAY continue to send at the paced Quick-Start Rate
+   while in the Validation Phase.  It leaves the Validation Phase on
+   receipt of an ACK that acknowledges the last Quick-Start Packet, or
+   if the validation phase persists for a period that exceeds the
+   Quick-Start Validation Time of 1 RTT.  It MUST then reduce the cwnd
+   to the actual flight size (the current amount of unacknowledged data
+   sent) [RFC4782] and uses the congestion control methods specified for
+   CCID 2.
+
+3.1.5.  Reported Loss or Congestion While Using Quick-Start
+
+   A sender in the Quick-Start Mode (or Validation Phase) that detects
+   congestion (e.g., receives a feedback packet that reports new packet
+   loss or a packet with a congestion marking), MUST immediately leave
+   the Quick-Start Mode (or Validation Phase).  It then resets the cwnd
+   to half the recorded previous cwnd and enters the congestion
+   avoidance phase described in [RFC4341].
+
+   In the absence of any feedback at the end of the Validation period,
+   the sender resets the cwnd to half the recorded previous cwnd and
+   enters the congestion avoidance phase.
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 14]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+3.1.6.  CCID 2 Feedback Traffic on the Reverse Path
+
+   A CCID 2 receiver sends feedback for groups of received packets
+   [RFC4341].  Approval of a higher transmission rate using Quick-Start
+   will increase control traffic on the reverse path.  A return path
+   that becomes congested could have a transient negative impact on
+   other traffic flows sharing the return link.  The lower rate of
+   feedback will then limit the achievable rate in the forward
+   direction.
+
+3.2.  Quick-Start for CCID 3
+
+   This section describes the Quick-Start mechanism to be used with DCCP
+   CCID 3 [RFC4342].  The rate-based congestion control mechanism used
+   by CCID 3 leads to specific issues that are addressed by Quick-Start
+   in this section.
+
+3.2.1.  The Quick-Start Request for CCID 3
+
+   A Quick-Start Request MAY be sent to allow the sender to determine if
+   it is safe to use a larger initial sending rate.  This permits a
+   faster start-up of a new CCID 3 flow.
+
+   A Quick-Start Request MAY also be sent to request a higher sending
+   rate after an idle period (in which the nofeedback timer expires
+   [RFC5348]) or an application-limited period (described in Section
+   2.1).  This allows a receiver to increase the sending rate faster
+   than allowed with standard operation (i.e., faster than twice the
+   rate reported by a CCID 3 receiver in the most recent feedback
+   message).
+
+   The requested rate specified in a Quick-Start Request MUST NOT exceed
+   the TFRC-controlled sending rate [RFC4342] when this is bounded by
+   the current loss event rate (if any), either from calculation at the
+   sender or from feedback received from the receiver.  CCID 3 considers
+   this rate is a safe response in the presence of expected congestion.
+
+3.2.2.  Sending a Quick-Start Response with CCID 3
+
+   When processing a received Quick-Start Request, the receiver uses the
+   method described in Section 2.3.  In addition, if a CCID 3 receiver
+   uses the window counter to send periodic feedback messages, then the
+   receiver sets its local variable last_counter to the value of the
+   window counter reported by the segment containing the Quick-Start
+   Request.  The next feedback message would then be sent when the
+   window_counter is greater or equal to last_counter + 4.  If the CCID
+   3 receiver uses a feedback timer to send period feedback messages,
+   then the receiver MUST reset the CCID 3 feedback timer, causing the
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 15]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+   feedback to be sent as soon as possible.  This helps to align the
+   timing of feedback to the start and end of the period in which
+   Quick-Start Packets are sent, and will normally result in feedback at
+   a time that is approximately the end of the period when Quick-Start
+   Packets are received.
+
+3.2.3.  Using the Quick-Start Response with CCID 3
+
+   On receipt of a valid Quick-Start Response option, the sender MUST
+   send a Quick-Start Approved option [RFC4782] (see Section 2.3).  The
+   sender then uses one of three procedures:
+
+   * If the approved Quick-Start rate is less than the current sending
+     rate, the sender does not enter the Quick-Start Mode and continues
+     using the procedure defined in CCID 3.
+
+   * If loss or congestion is reported after sending the Quick-Start
+     Request, the sender also does not enter the Quick-Start Mode and
+     continues using the procedure defined in CCID 3.
+
+   * If the approved Quick-Start rate exceeds the current sending rate,
+     the sender enters the Quick-Start Mode and continues in the Quick-
+     Start Mode for a maximum period of 1 RTT.  The sender sets its
+     Quick-Start sending rate (QS_sendrate) as follows:
+
+      QS_sendrate = R * s/(s + H);                                (2)
+
+     where R the Rate Request in bytes per second, s is the packet size
+     [RFC4342], and H the estimated DCCP/IP header size in bytes (e.g.,
+     32 bytes for IPv4).  A CCID 3 host MAY then increase its sending
+     rate to the QS_sendrate.  The rate should not be reduced.
+
+     CCID 3 is a rate-paced protocol.  Therefore, if the QS_sendrate is
+     used, the sending host MUST pace the rate at which the Quick-Start
+     Packets are sent over the next RTT.  The sending host SHOULD also
+     record the previous congestion-controlled rate and note that the
+     new rate has been determined by Quick-Start rather by other means
+     (e.g., by setting a flag to indicate that it is in the Quick-Start
+     Mode).
+
+   The sender exits the Quick-Start Mode after either:
+
+   * Receipt of a feedback packet acknowledging one or more Quick-Start
+     Packets,
+
+   * A period of 1 RTT after receipt of a Quick-Start Response, or
+
+   * Detection of a loss or congestion event (see Section 3.2.5).
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 16]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+3.2.4.  Quick-Start Validation Phase for CCID 3
+
+   After transmitting a set of Quick-Start Packets in the Quick Start
+   Mode (and providing that no loss or congestion marking is reported),
+   the sender enters the Quick-Start Validation Phase.  A sender that
+   receives feedback that reports a loss or congestion event MUST follow
+   the procedures described in Section 3.2.5.
+
+   The sender MUST exit the Quick-Start Validation Phase on receipt of
+   feedback that acknowledges all packets sent in the Quick-Start Mode
+   (i.e., all Quick-Start Packets) or if the Validation Phase persists
+   for a period that exceeds the Quick-Start Validation Time of two
+   RTTs.
+
+   A sender that completes the Quick-Start Validation Phase with no
+   reported packet loss or congestion stops using the QS_sendrate and
+   MUST recalculate a suitable sending rate using the standard
+   congestion control mechanisms [RFC4342].
+
+   If no feedback is received within the Quick-Start Validation Phase,
+   the sender MUST return to the minimum of the recorded original rate
+   (at the start of the Quick-Start Mode) and one half of the
+   QS_sendrate.  The nofeedback timer is also reset.
+
+3.2.5.  Reported Loss or Congestion during the Quick-Start Mode or
+        Validation Phase
+
+   A sender in the Quick-Start Mode or Validation Phase that detects
+   congestion (e.g., receives a feedback packet that reports new packet
+   loss or a packet with a congestion marking) MUST immediately leave
+   the Quick-Start Mode or Validation Phase and enter the congestion
+   avoidance phase [RFC4342].  This implies re-calculating the sending
+   rate, X, as required by RFC 4342:
+
+      X = max(min(X_calc, 2*X_recv), s/t_mbi);
+
+   where X_calc is the transmit rate calculated by the throughput
+   equation, X_recv is the reported receiver rate, s is the packet size
+   and t_mbi is the maximum back-off interval of 64 seconds.
+
+   The current specification of TFRC [RFC5348], which obsoletes RFC
+   3448, uses a set of X_recv values and uses the maximum of the set
+   during application-limited intervals.  This calculates the sending
+   rate, X as:
+
+      X = max(min(X_calc, recv_limit),s/t_mbi);
+
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 17]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+   where recv_limit could be max(X_recv_set) or 2*max(X_recv_set)
+   depending on whether there was a new loss event during a data-
+   limited interval, or no loss event during an application-limited
+   interval respectively.  When the sender is not application-limited,
+   the recv_limit is set to 2*max(X_recv_set).
+
+   A sender using RFC 4342 updated by [RFC5348], calculates the sending
+   rate, X, using the above formula normatively defined in [RFC5348].
+
+3.2.6.  CCID 3 Feedback Traffic on the Reverse Path
+
+   A CCID 3 receiver sends feedback at least once each RTT [RFC4342].
+   Use of Quick-Start is therefore not expected to significantly
+   increase control traffic on the reverse path.
+
+3.3.  Quick-Start for CCID 4
+
+   This section describes the Quick-Start mechanism to be used when DCCP
+   uses TFRC-SP [RFC4828] in place of TFRC [RFC5348], as specified in
+   CCID 4 [RFC5622].  CCID 4 is similar to CCID 3 except that a sender
+   using CCID 4 is limited to a maximum of 100 packets/second.
+
+   The Quick-Start procedure defined below therefore resembles that for
+   CCID 3.
+
+3.3.1.  The Quick-Start Request for CCID 4
+
+   The procedure for sending a Quick-Start Request using CCID 4 is the
+   same as for CCID 3, defined in Section 3.2.1.  In addition, the
+   requested rate MUST be less than or equal to the equivalent of a
+   sending rate of 100 packets per second [RFC4828].  CCID 4 [RFC4828]
+   specifies that the allowed sending rate derived from the TCP
+   throughput equation is reduced by a factor that accounts for packet
+   header size.
+
+3.3.2.  Sending a Quick-Start Response with CCID 4
+
+   This procedure is the same as for CCID 3, defined in Section 3.2.2.
+
+3.3.3.  Using the Quick-Start Response with CCID 4
+
+   This procedure is the same as for CCID 3, defined in Sections 3.2.3,
+   3.2.4, and 3.2.5, except that the congestion control procedures is
+   updated to use TFRC-SP [RFC4828].
+
+   A CCID 4 sender does not need to account for headers a second time
+   when translating the approved Quick-Start rate into an allowed
+   sending rate (as described in Section 5 of [RFC5622].
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 18]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+3.3.4.  Reported Loss or Congestion While Using Quick-Start
+
+   This procedure is the same as for CCID 3, defined in Section 3.2.5,
+   except that the congestion control procedures is updated to use
+   TFRC-SP [RFC4828].
+
+3.3.5.  CCID 4 Feedback Traffic on the Reverse Path
+
+   A CCID 4 receiver sends feedback at least once each RTT.  Use of
+   Quick-Start is therefore not expected to significantly increase
+   control traffic on the reverse path.
+
+4.  Discussion of Issues
+
+   The considerations for using Quick-Start with DCCP are not
+   significantly different to those for Quick-Start with TCP.  The
+   document does not modify the router behavior specified for Quick-
+   Start.
+
+4.1.  Overrun and the Quick-Start Validation Phase
+
+   The less frequent feedback of DCCP raises an issue in that a sender
+   using Quick-Start may continue to use the rate specified by a Quick-
+   Start Response for a period that exceeds one path round trip time
+   (i.e., that which TCP would have used).  This overrun is a result of
+   the less frequent feedback interval used by DCCP (i.e., CCID 2 may
+   delay feedback by at most one half cwnd and CCID 3 and CCID 4 provide
+   feedback at least once per RTT).  In the method specified by this
+   document, the Quick-Start Validation Phase bounds this overrun to be
+   not more than an additional two RTTs.
+
+   The selected method was chosen as a compromise that reflects the need
+   to terminate quickly following the loss of a feedback packet, and the
+   need to allow sufficient time for end host and router processing, as
+   well as the different perceptions of the path RTT held at the sender
+   and receiver.  Any reported loss or congestion results in immediate
+   action without waiting for completion of the Quick-Start Validation
+   period.
+
+4.2.  Experimental Status
+
+   There are many cases in which Quick-Start Requests would not be
+   approved [RFC4782].  These include communication over paths
+   containing routers, IP tunnels, MPLS paths, and the like, that do not
+   support Quick-Start.  These cases also include paths with routers or
+   middleboxes that drop packets containing IP options (or IPv6
+   extensions).  Quick-Start Requests could be difficult to approve over
+   paths that include multi-access Layer-2 networks.
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 19]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+   Transient effects could arise when the transport protocol packets
+   associated with a connection are multiplexed over multiple parallel
+   (sometimes known as alternative) links or network-layer paths, and
+   Quick-Start is used, since it will be effective on only one of the
+   paths, but could lead to increased traffic on all paths.
+
+   A CCID 2 sender using Quick-Start can increase the control traffic on
+   the reverse path, which could have a transient negative impact on
+   other traffic flows sharing the return link (Section 3.1.6).  The
+   lower rate of feedback will then limit the achievable rate in the
+   forward direction.
+
+   [RFC4782] also describes environments where the Quick-Start mechanism
+   could fail with false positives, with the sender incorrectly assuming
+   that the Quick-Start Request had been approved by all of the routers
+   along the path.  As a result of these concerns, and as a result of
+   the difficulties and the seeming absence of motivation for routers,
+   such as core routers, to deploy Quick-Start, Quick-Start has been
+   proposed as a mechanism that could be of use in controlled
+   environments, and not as a mechanism that would be intended or
+   appropriate for ubiquitous deployment in the global Internet.
+
+   Further experimentation would be required to confirm the deployment
+   of Quick-Start and to investigate performance issues that may arise,
+   prior to any recommendation for use over the general Internet.
+
+5.  IANA Considerations
+
+   IANA has assigned a DCCP Option Type (45) from the DCCP Option Types
+   Registry.  This Option is applicable to all CCIDs and is known as the
+   "Quick-Start Response" Option and is defined in Section 2.2.1.  It
+   specifies a length value in the format used for options numbered
+   32-128.
+
+6.  Acknowledgments
+
+   The author gratefully acknowledges the previous work by Sally Floyd
+   to identify issues that impact Quick-Start for DCCP, and her comments
+   to improve this document.  We also acknowledge comments and
+   corrections from Pasi Sarolahti, Vincent Roca, Mark Allman, Michael
+   Scharf, and others in the IETF DCCP Working Group (WG).
+
+7.  Security Considerations
+
+   Security issues are discussed in [RFC4782].  Middlebox deployment
+   issues are also highlighted in Section 2.8.  No new security issues
+   are raised within this document.
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 20]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
+              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
+
+   [RFC4341]  Floyd, S. and E. Kohler, "Profile for Datagram Congestion
+              Control Protocol (DCCP) Congestion Control ID 2: TCP-like
+              Congestion Control", RFC 4341, March 2006.
+
+   [RFC4342]  Floyd, S., Kohler, E., and J. Padhye, "Profile for
+              Datagram Congestion Control Protocol (DCCP) Congestion
+              Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
+              March 2006.
+
+   [RFC4782]  Floyd, S., Allman, M., Jain, A., and P. Sarolahti,
+              "Quick-Start for TCP and IP", RFC 4782, January 2007.
+
+   [RFC4828]  Floyd, S. and E. Kohler, "TCP Friendly Rate Control
+              (TFRC): The Small-Packet (SP) Variant", RFC 4828, April
+              2007.
+
+   [RFC5348]  Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
+              Friendly Rate Control (TFRC): Protocol Specification", RFC
+              5348, September 2008.
+
+   [RFC5622]  Floyd, S., and E. Kohler, "Profile for Datagram Congestion
+              Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate
+              Control for Small Packets (TFRC-SP)", RFC 5622, August
+              2009.
+
+8.2.  Informative References
+
+   [RFC3344]  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
+              3344, August 2002.
+
+   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
+              in IPv6", RFC 3775, June 2004.
+
+   [RFC3390]  Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
+              Initial Window", RFC 3390, October 2002.
+
+   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+              Discovery", RFC 4821, March 2007.
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 21]
+
+RFC 5634                  Quick-Start for DCCP               August 2009
+
+
+Authors' Addresses
+
+   Godred Fairhurst
+   School of Engineering
+   University of Aberdeen
+   Aberdeen, AB24 3UE
+   Scotland, UK
+
+   EMail: gorry@erg.abdn.ac.uk
+   URI: http://www.erg.abdn.ac.uk/users/gorry
+
+
+   Arjuna Sathiaseelan
+   School of Engineering
+   University of Aberdeen
+   Aberdeen, AB24 3UE
+   Scotland, UK
+
+   EMail: arjuna@erg.abdn.ac.uk
+   URI: http://www.erg.abdn.ac.uk/users/arjuna
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Sathiaseelan      Experimental                     [Page 22]
+