Internet Engineering Task Force Gorry Fairhurst
Internet Draft Arjuna Sathiaseelan
Document: draft-fairhurst-tsvwg-dccp-qs-00.txt University of Aberdeen
Expires: August 2007
Category: Draft intended for EXPERIMENTAL February 2007
Quick-Start for DCCP
Status of this Draft
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. 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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 31, 2007.
Abstract
The Datagram Congestion Control Protocol (DCCP) is a transport
protocol that allows the transmission of congestion-controlled,
unreliable datagrams. It is intended for applications such as
streaming media, Internet telephony, and on-line games. In DCCP, an
application has a choice of congestion control mechanisms, each
specified by a Congestion Control Identifier (CCID). This document
specifies a framework for the use of the Experimental Quick-Start
Mechanism by DCCP, and specific procedures for the use of Quick-
Start with DCCP CCID-2 and CCID-3.
Expires August 2007 [page 1]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
Table of Contents
1. Introduction
2. Quick-Start for DCCP
2.1 Sending a Quick-Start Request for a DCCP flow
2.2 Receiving a Quick-Start Request for a DCCP flow
2.2.1 The Quick-Start Response Option
2.3 Receiving a Quick-Start Response
2.4 Procedure when no response to a Quick-Start Request
2.5 Procedure when a Quick-Start packet is dropped
2.6 Interactions with Path MTU Discovery
2.7 Interactions with Middle boxes
3. Mechanisms for Specific CCIDs
3.1 Quick-Start for CCID-2
3.2 Quick-Start for CCID-3
3.2.1 The Quick-Start Request for CCID-3
3.2.2 Sending a Quick-Start Response
3.2.3 Using the Quick-Start Response with CCID-3
3.2.4 The Quick-Start Validation Phase
3.2.5 Reported Loss during Quick-Start Mode or Validation Phase
3.2.6 An Example Quick-Start Scenario with CCID-3
3.2.7 Controlling Acknowledgement Traffic on the Reverse Path
4. Discussion of Issues
4.1 Over-run and Quick-Start Validation
5. Summary
6. IANA Considerations
7. Acknowledgments
8. Security Considerations
9. References
9.1 Normative References
9.2 Informative References
10. Authors' Addresses
11. IPR Notices
11.1 Intellectual Property Statement
11.2 Disclaimer of Validity
12. Copyright Statement
Expires August 2007 [page 2]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
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 on-line 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. In cooperation with routers, it allows 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 period).
This document assumes that the reader is familiar with RFC4782
[RFC4782]. RFC4782 specifies the use of Quick-Start with IP and with
TCP. Section 7 of RFC4782 also provides guidelines for the use of
Quick-Start with other transport protocols, including DCCP. This
document answers some of the issues that were raised by RFC4782 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 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 one round-trip time. Subsequent transmissions
will be governed by the default CCID congestion control mechanisms
for that connection. If the Quick-Start Requestis not approved, then
the sender must use the default congestion control mechanisms.
Expires August 2007 [page 3]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
2. Quick-Start for DCCP
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].
Unless otherwise specified, the DCCP end host follows 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 [RFC3390].
A Quick-Start Request MAY be also used once a DCCP flow is connected
(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
data-limited period (where the sender transmits at less than the
allowed sending rate) can send a Quick-Start Request using the
procedures defined in Section 3.
Excessive use of the Quick-Start mechanism is not recommended, end
hosts therefore MUST NOT therefore make a subsequent Quick-Start
Request within a period of four RTTs.
When sending a Quick-Start Request, the DCCP sender SHOULD send the
Request on a packet that requires an acknowledgement, such as a
DCCP-Request, DCCP-Response, or DCCP-Data.
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 summarised 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 TTL field, to the receiving DCCP layer. If the receiving host is
willing to permit the Quick-Start Request, then a Quick-Start
Response option is included in the DCCP header of the corresponding
feedback packet. The Rate Request 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. The TTL Diff in the Quick-
Start Response is set to the difference between the IP TTL value and
the QS TTL value. The QS Nonce in the Response is set to the
received value of the QS Nonce in the Quick-Start option.
Expires August 2007 [page 4]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
On receipt of a Quick-Start Request, the receiver SHOULD respond
immediately by sending a packet that carries the Quick-Start
Response option using either DCCP-Ack packet or in a DCCP-DataAck
packet.
If an end host receives an IP packet with a Quick-Start Request with
a rate request of zero, then that host SHOULD NOT send a Quick-Start
Response [RFC4782].
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.
2.2.1 The Quick-Start Response Option
This section defines a DCCP Header Option to carry the Quick-Start
response, in a format that resembles that defined for TCP in
[RFC4782]. This header option is REQUIRED for end hosts to utilise
the Quick-Start mechanism for DCCP flows.
### IANA ACTION, PLEASE REPLACE xQSOx with the assigned value ###
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=xQSOx | Length=8 | Resv. | Rate | TTL Diff |
| | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QS Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The Quick-Start Response option.
### IANA ACTION, PLEASE REPLACE xQSOx with the assigned value ###
The first byte of the Quick-Start Response option contains the
option kind, identifying the DCCP option (xQSOx).
The second byte of the Quick-Start Response option contains the
option length in bytes. The length field MUST be set to 8 bytes.
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 Quick-Start Rate Request option.
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 QS TTL fields in the received Quick-Start Request packet, as
calculated in [RFC4782].
Expires August 2007 [page 5]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
Bytes 5-8 of the DCCP option contain the 30-bit QS Nonce and a two-
bit Reserved field.
2.3 Receiving a Quick-Start Response
The procedure for processing a Quick-Start Response packet is CCID-
specific and described in Section 3.
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.
2.5 Procedure when a Quick-Start packet is dropped
While the sender is in the QS Mode, all sent packets are known as
Quick-Start Packets [RFC4782]. Loss of a Quick-Start Packet is an
indication of potential network congestion. The behaviour of a DCCP
sender following the loss of a Quick-Start Packet is specific to a
particular CCID (see section 3).
2.6 Interactions with Path MTU Discovery
While DCCP implementations are encouraged to support PMTUD, the
protocol is datagram-based and therefore the size of the segments
that are sent is a function of application behaviour as well as
being constrained by the largest supported Path MTU.
2.7 Interactions with Middle boxes
XXX Note: To be completed in a later revision of the document XXX
Expires August 2007 [page 6]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
3. Mechanisms for Specific CCIDs
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.
XXX Note: This Section to be completed later XXX
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 need to be addressed
by Quick-Start.
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 sate. This permits a
faster start-up of a new DCCP flow.
A Quick-Start Request MAY be also sent to request a higher sending
rate after an idle period or data-limited period (as described in
section 2.1). This allows a receiver to increase the sending rate
faster than allowed with standard operation, where CCID-3 does not
allow the sender to send more than twice as fast as reported by the
receiver in the most recent feedback message.
An idle period is defined in this context as one in which the
nofeedback timer expires [ID.DCCP-FR].
XXX Note: Future drafts may use common terminology to DCCP FR draft
XXX
When resuming a flow that has been idle, the requested rate must
consider the current loss event rate (if any), either from
calculation at the sender or from feedback received from the
receiver. A sender MUST not request more than this upper bound
dictated by the loss event rate.
XXX Author comment: Is it appropriate to also ask using QS after
receiving a loss-event, as a way of getting more capacity than
allowed by the throughput equation ??? XXX
XXX Author comment: One view is that under the current
circumstances, the sender does not have a proper knowledge of the
Expires August 2007 [page 7]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
network. So on that basis, the sender based on the current loss
event rate (current here means the loss event rate that was during
the start of the idle period), requests the rate. This MUST be an
upper bound. This is similar to asking for the last achieved rate
during slow start. This places an upper bound on the sending rate,
dictated by the loss event rate is an upper bound on the requested
Quick-Start rate. Later, mobility events can also be taken into
account. XXX
3.2.2 Sending a Quick-Start Response
When processing a received Quick-Start Request, the receiver uses
the method described in Section 2.2. In addition, the DCCP receiver
MUST reset the CCID-3 feedback timer. 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
The sender SHOULD NOT ignore a feedback packet containing a Quick-
Start Response option.
On receipt of a valid Quick-Start Response option, the sender enters
the Quick-Start Mode. The sender continues in the Quick-Start Mode
for a maximum period of 1 RTT, during which it sends Quick-Start
Packets.
On receipt of a Quick-Start response, the sending host sets its
Quick-Start sending rate (QS-sendrate) as follows:
QS-sendrate = R * s/(s + H) (1)
where R the Rate Request in bytes per second, s is the packet size,
and H the estimated DCCP/IP header size in bytes (e.g., 32 bytes).
A CCID 3 host MAY then increase its sending rate (sendrate) to the
QS-sendrate, if the QS-sendrate is greater than sendrate. The rate
SHOULD NOT be reduced (i.e., a QS-sendrate lower than sendrate
should be ignored). 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 Quick-Start Mode).
The sender MUST send a Quick-Start Approved option [RFC4782] on the
first Quick-Start packet or using a control packet if there are no
Quick-Start packets to be sent.
The sender exits the Quick-Start Mode after either:
Expires August 2007 [page 8]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
* A feedback packet acknowledging one or more Quick-Start Packets,
* A period of 1 RTT after receipt of a QS-Response,
or
* Detection of a loss event (see Section 3.2.5).
If no loss (or ECN marking) is reported, the sender then enters the
Quick-Start Validation Phase.
3.2.4 The Quick-Start Validation Phase
After transmitting a set of Quick-Start Packets (and providing that
no loss or ECN marking is reported), the sender enters the Quick-
Start Validation Phase. This phase comprises 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 (and CCID-2), CCID-3 does not receive frequent
feedback that indicates the congestion state of the forward path).
While in the Quick-Start Validation Phase, the sender is tentatively
permitted to continue sending at the QS-sendrate. On conclusion of
the Validation Phase, the sender expects to find assurance that it
may safely use the current rate.
The sender MUST exit the Quick-Start Validation Phase on receipt of
feedback that reports a loss event (see Section 3.2.5).
The sender SHOULD 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). It MUST also exit this phase on
expiry of the Quick-Start validation time. The Quick-Start
Validation Phase is limited to a maximum of 1.5 RTTs, the Quick-
Start Validation Time.
After completion of the Quick-Start Validation phase (with no
reported packet loss), the sender stops using the QS-sendrate and
MUST recalculate a suitable sending rate using the standard
congestion control mechanisms [RFC4342]. For example, if the DCCP
sender was in slow-start prior to the Quick-Start request, and no
packets were lost or marked since that time, then the sender
continues in slow-start after exiting Quick-Start Mode until the
sender sees a packet loss.
If no feedback is received within the Quick-Start Validation Phase,
the sender MUST return to the minimum of the original rate (at the
start of the Quick-Start Mode) and one half of the QS-sendrate.
3.2.5 Reported Loss during Quick-Start Mode or Validation Phase
If a feedback packet arrives that reports a packet loss, the sender
MUST immediately leave the Quick-Start Mode or Validation Phase and
Expires August 2007 [page 9]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
enter the congestion avoidance phase [RFC4342]. This implies re-
calculating the send rate X as follows:
X = max(min(X_calc, min(2*X_recv, 2* QS_recv-rate)), s/t_mbi);
where X_recv is the previously cached receiver rate and QS recv-rate
is the receiver rate reported by the feedback due to the arrival of
Quick-Start packets.
3.2.6 An Example Quick-Start Scenario with CCID-3
DCCP Sender DCCP Receiver
Quick-Start +----------------------------------------------+
Request/Response | Quick-Start Request --> |
| <-- Quick-Start Response |
| Quick-Start Approve --> |
+----------------------------------------------+
+----------------------------------------------+
Quick-Start | Quick-Start Packets --> |
Mode | |
| <-- Feedback from Receiver|
+----------------------------------------------+
+----------------------------------------------
Quick-Start | Packets --> |
Validation Phase | |
| <-- Feedback from Receiver|
+----------------------------------------------+
CCID-3 Packets -->
Congestion
Control <-- Feedback from Receiver
Figure 2. The Quick-Start Mode and Validation Phase.
Figure 2 shows an example of the use of Quick-Start with CCID-3.
3.2.7 Controlling Feedback Traffic on the Reverse Path
A CCID-3 receiver sends feedback at least once each RTT. Using
Quick-Start would not significantly increase traffic on the reverse
path.
4. Discussion of Issues
XXX Note: This Section to be completed later, please send issues to
the authors XXX
Quick-Start [RFC4782] describes many paths where Quick-Start
Requests would not be approved. These paths include all paths
containing routers, IP tunnels, MPLS paths, and the like that do not
support Quick-Start. These paths also include paths with routers or
Expires August 2007 [page 10]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
middleboxes that drop packets containing IP options. Quick-Start
requests could be difficult to approve over paths that include
multi-access layer-two networks. [RFC4782] also describes
environments where the Quick-Start process 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
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.
XXX Note: Need to consider implications of alternate paths, etc and
examine if there are specific issues. XXX
4.1 Over-run and Quick-Start Validation
CCID-3 raises an issue in that the sender may continue to use the
capacity allocated by Quick-Start for a period that exceeds that
which TCP would have used. This over-run is a result of the less
frequent feedback interval (once per RTT rather than once for a few
packets) used by TFRC (i.e. CCID-3), and is bounded by the Quick-
Start Validation Time.
The currently selected value is chosen as a compromise that reflects
the need to terminate quickly following 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 results in immediate
action without waiting for completion of the validation period.
5. Summary
Quick-Start with TCP has been normatively defined in RFC 4782
[RFC4782]. The appendix in RFC 4782 also discusses some issues when
Quick-Start is used with other protocols including DCCP, but does
specify the mechanisms to be used.
This document specifies the operation of DCCP with Quick-Start and
defines how Quick-Start operates when using CCID-2 and CCID-3.
Expires August 2007 [page 11]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
6. IANA Considerations
This document requires IANA involvement for the assignment of a DCCP
Option Type from the DCCP Option Types Registry. The Option 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.
XXX This option is DCCP-Specific, not CCID-Specific. XXX
7. 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.
8. Security Considerations
Security issues are discussed in [RFC4782]. No new security issues
are raised within this document.
9. References
9.1 Normative References
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 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.
9.2 Informative References
[RFC3390] Allman, M., Floyd, S., Partridge, C., "Increasing TCP's
Initial Window", RFRC 3390, October 2002.
Expires August 2007 [page 12]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
[ID.DCCP-FR] Kohler, E., Floyd, F., "Faster Restart for TCP
Friendly Rate Control (TFRC) ", IETF Work In Progress, 2007.
10. Authors' Addresses
Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/Gorry
Arjuna Sathiaseelan
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
UK
Email: arjuna@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/arjuna
11. IPR Notices
11.1 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
11.2 Disclaimer of Validity
Expires August 2007 [page 13]
INTERNET DRAFT Quick-Start for DCCP Feb 2007
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
12. Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
-------------------------------------------------------------------
[RFC EDITOR NOTE:
This section must be deleted prior to publication]
DOCUMENT HISTORY
Individual Draft 00
This is the first presentation of this document.
[END of RFC EDITOR NOTE]
Expires August 2007 [page 14]