Internet DRAFT - draft-lanphear-dccp-user-guide
draft-lanphear-dccp-user-guide
Internet Engineering Task Force
INTERNET-DRAFT Damon Lanphear
draft-lanphear-dccp-user-guide-00.txt RealNetworks
25 October 2002
Expires: April 2003
Datagram Congestion Control Protocol (DCCP) User Guide
Status of this Document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC 2026]. 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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document is an informative reference for the
implementation of the Datagram Congestion Control Protocol
(DCCP) and its interface with the application layer.
Lanphear [Page 1]
INTERNET-DRAFT Expires: April 2003 October 2002
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
2. Considerations for Target Applications. . . . . . . . . 4
2.1. Real Time Media Applications . . . . . . . . . . . . 5
2.1.1. The Post Network Buffer and Rate Control. . . . . 5
2.1.2. Decode Costs and Media Adaptation . . . . . . . . 6
2.1.3. Selective Transmission and Retransmission . . . . 6
2.1.4. Latency Requirements. . . . . . . . . . . . . . . 7
2.1.5. RTP/RTCP. . . . . . . . . . . . . . . . . . . . . 8
2.1.6. IP Telephony. . . . . . . . . . . . . . . . . . . 8
2.1.7. Video Teleconferencing. . . . . . . . . . . . . . 8
2.1.8. Multi-Player Game Applications. . . . . . . . . . 8
2.2. Cross Application Issues . . . . . . . . . . . . . . 8
2.2.1. Loss Signaling. . . . . . . . . . . . . . . . . . 8
2.2.2. Drop Preference . . . . . . . . . . . . . . . . . 9
2.2.3. Mobility. . . . . . . . . . . . . . . . . . . . . 9
2.2.4. Send Option on Option Change With or With-
out Data . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.5. Protocol Information Shared with Overlying
Layers . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. API and Configuration Considerations. . . . . . . . . . 10
3.1. Configuration. . . . . . . . . . . . . . . . . . . . 10
3.1.1. Configurable Variables Specific to DCCP . . . . . 11
3.1.2. Configurable Variables Specific to an API
Implementation . . . . . . . . . . . . . . . . . . . . . 11
3.1.2.1. Feature Negotiation Limit. . . . . . . . . . . 11
3.1.2.2. Preferred Feature Priorities, Exclusions
and Inclusions. . . . . . . . . . . . . . . . . . . . . 11
3.1.2.3. Loss Window Ratio. . . . . . . . . . . . . . . 12
3.1.2.4. Slow Receiver Notification . . . . . . . . . . 12
3.1.2.5. Slow Receiver Option . . . . . . . . . . . . . 12
3.1.2.6. Buffer Close Drop Notification . . . . . . . . 12
3.1.2.7. Drop Preference. . . . . . . . . . . . . . . . 13
3.1.2.8. Mobile Receiver Drop Behavior
Preference. . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2.9. Use Service Name . . . . . . . . . . . . . . . 13
3.1.2.10. Minimal Buffering Option. . . . . . . . . . . 13
3.1.2.11. PMTU Change Behavior. . . . . . . . . . . . . 13
3.2. Connection Establishment and Termination . . . . . . 13
3.2.1. Connection Establishment. . . . . . . . . . . . . 13
3.2.2. Data Piggybacking . . . . . . . . . . . . . . . . 14
3.2.3. Connection Termination. . . . . . . . . . . . . . 14
3.3. Feature Negotiation. . . . . . . . . . . . . . . . . 14
3.3.1. Negotiable Features . . . . . . . . . . . . . . . 14
3.3.2. Impact on Configuration Interfaces. . . . . . . . 15
3.3.3. Feature options with data . . . . . . . . . . . . 15
Lanphear [Page 2]
INTERNET-DRAFT Expires: April 2003 October 2002
3.3.4. Impact of feature negotiation on I/O seman-
tics . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. Error Codes. . . . . . . . . . . . . . . . . . . . . 16
3.5. Statistics . . . . . . . . . . . . . . . . . . . . . 16
4. Implementation Considerations . . . . . . . . . . . . . 17
4.1. Connection State . . . . . . . . . . . . . . . . . . 17
4.2. Provision of sequence number, and loss data to
application . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Probabilistic Verification of Loss Rate using
ECN for TFRC. . . . . . . . . . . . . . . . . . . . . . . 18
4.4. Supporting Application Feature Preference. . . . . . 18
4.5. Slow Receiver Interpretation and
Notification. . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . 19
7. References. . . . . . . . . . . . . . . . . . . . . . . 19
8. Author's Address. . . . . . . . . . . . . . . . . . . . 19
Lanphear [Page 3]
INTERNET-DRAFT Expires: April 2003 October 2002
1. Introduction
This document presents issues that pertain to the semantics and
logistics of interaction between the Datagram Congestion Control
Protocol (DCCP) and an application that uses DCCP. The choices that
are to be made in implementing such semantics are also discussed.
This discussion may serve as a reference for the use and
implementation of the Datagram Congestion Control Protocol (DCCP).
The text of this document should be regarded as informative, rather
than normative.
A discussion of the interaction between an application and a lower
level service begs the question of an API specification. This text
does not assume a specific API paradigm. Rather, API issues are
discussed in the abstract. The purpose of which is to allow the
reader to focus on fundamental implementation issues without
limiting the discussion to a particular problem domain. An example
implementation using a specific API is presented, however, as a
means by which API design choices can be demonstrated in more
certain terms.
DCCP presents a set of unique challenges to the provision of an
application interface. These challenges are compounded by the fact
that many DCCP implementations will be done in kernel space. API
paradigms which are presented by existing kernels may not be
sufficient for the most complete exposure of DCCP's services.
Mitigating the trade off between DCCP functionality muted by an API
and providing a sufficiently flexible API considered throughout this
document.
The reader's knowledge of DCCP and its design rationale are assumed.
Reviewing the DCCP specification [DCCP] and the DCCP problem
statement [DCCP-PROBLEM] before reading this document is therefore
suggested.
2. Considerations for Target Applications
DCCP specifically targets a subset of network applications. These
applications have elected to use UDP over TCP for data transfer.
The reason for this choice is typically that the characteristics of
TCP data transfers are not congruent with the specific needs of the
application. Examples of such needs are:
(1) Startup Delay: Applications may wish to avoid the delay of a
three-way handshake.
(2) Statelessness: Applications may wish to avoid holding connection
state, and the potential state-holding attacks that come with
Lanphear Section 2. [Page 4]
INTERNET-DRAFT Expires: April 2003 October 2002
this.
(3) Trading of Reliability against Timing: For some applications,
data being sent is timely in the sense that if it is not
delivered by some deadline (typically a small number of RTTs)
then the data will not be useful at the receiver. [DCCP-
PROBLEM]
(4) Smoothness of Delivery: Applications such as media delivery and
IP Telephony are susceptible to the oscillations of delivery
rate induced by TCP. Periodic fluctuations of throughput can
cause media codecs to run dry, inducing a perceptible gap in the
presentation, if a continuous stream of data is not received at
the decode rate.
DCCP has been designed to resolve these issues in a way that will be
acceptable to applications that would otherwise use UDP. The extent
to which the design of a protocol can address these issues is
limited by the extent to which an implementation is sensitive to
these issues. It is therefore relevant that a DCCP implementation
takes into account the needs of the overlying application through
the way in which it exposes the features and semantics of DCCP.
This section discusses the needs of applications targeted by DCCP.
Emphasis is placed on the impact of these needs on an implementation
of DCCP.
2.1. Real Time Media Applications
2.1.1. The Post Network Buffer and Rate Control
Real time media applications typically employ a post network buffer,
or a play out buffer, in which media packets are queued prior to
decoding. Fluctuations in the rate and jitter of the media
transmission are absorbed by the play out buffer. A client in a
media application will attempt to maintain a certain degree of
occupation of the post network buffer throughout the session in
order to insulate the codec from such fluctuations. In the event
that this buffer is drained by the codec prior to the termination of
the session, the media application will typically pause the
presentation to refill the buffer. This is an undesirable state
since it implies a gap in the continuity of the media experienced by
the user.
The dynamics of the post network buffer introduce a set of
requirements to rate control that exist in parallel with those of
congestion control. Real time media applications may attempt to
manage the occupation of the post network buffer by asking the
Lanphear Section 2.1.1. [Page 5]
INTERNET-DRAFT Expires: April 2003 October 2002
server to either send more or less than the transmission rate
required by the codec to decode the media in real time. Although
this dynamic aspect of real time media applications' rate control
falls outside of the purview of DCCP, it does have implications on
DCCPs congestion control processing.
In DCCP congestion control processing is particular to the CCID
selected by the user of a given DCCP. In any case an implementation
may have to consider how an application's rate control may interact
with the specified congestion control algorithms. In certain cases
it may be appropriate for the congestion control scheme to regard
application cues in the same way as it would congestion cues from
the network. This may be achieved through the use of DCCP's slow
receiver notification.
[DCCP] articulates a specific interpretation of Slow Receiver
options, that DCCP will not increase the sending rate for one RTT.
An application, however, may need to alter its behavior to respond
to Slow Receiver reports in a way that is independent from DCCP's
response. As such, it may be useful for an API to specify to the
application that a Slow Receiver signal has been received. In this
way the application can more tightly integrate its flow control
requirements with the congestion control processing of DCCP,
avoiding redundant work and unintended side effects of interactions
between application and transport layer flow control.
2.1.2. Decode Costs and Media Adaptation
TBD
2.1.3. Selective Transmission and Retransmission
Real time media applications have specific delivery latency
requirements. A media packet must arrive at the the receiver within
a certain period of time in order for the the packet to have
relevance in the decoded media stream. This requirement has an
impact both on transmission policy and on retransmission policy.
DCCP's unreliable data flows, which defer implementation of ARQ to
the application, provide a clear advantage over TCP's requirement
that all data be presented to the application in order and without
loss. By deferring retransmission to the application, the
application can enforce retransmission policies that suit its
presentation requirements. A media application may not want to
pause the time line while awaiting the fulfillment of a
retransmission request. Likewise, the utility of retransmitting a
given packet as a function of the coding scheme may not be equal to
that of retransmitting any other packet in the stream. This problem
Lanphear Section 2.1.3. [Page 6]
INTERNET-DRAFT Expires: April 2003 October 2002
is compounded by the fact that the frequency of retransmitted
packets may impact the available throughput for more current or
relevant data.
DCCP has information about the loss and transmission latency that
may affect an application's ability to make a decision about
selective retransmission requests. Providing this information to an
application in an elegant and sufficiently flexible way is a
challenge for the API design. For certain API paradigms it may not
be efficient to represent to the application layer the identity of
packets that are lost. In such cases informing an application of why
packets are lost and the opportunity for successful retransmission
over a given window of time may be a helpful alternative to per
packet loss data.
Some media applications may wish to set transmission policies based
on the likelihood that a packet will be received on time. Although
an application may be aware that the current transmission rate is
sufficient for the codec to decode the media stream continuously, it
may not be aware that the dynamics of the send and receive buffers
in the DCCP are inducing a latency that prevents the timely delivery
of data. This issue becomes a particular problem during the
synchronization of two distinct streams at the client. It will
therefore be useful for an application to have information about the
delay induced by send and receive buffers.
Presentation of delay information from DCCP to the application
should be achieved through a representation of a compound of two
metrics, the estimated RTT and the estimated buffer depth. Although
the estimated RTT is not necessarily representative of the forward
propagation delay, it does provide an indication of the extent of
delay induced by the network. The number of buffers in the send
queue may also be used by the application to determine the amount of
delay the sending DCCP may add to the propagation of the
transmission of a given datagram. Providing such metrics to the
application is a matter of maintaining these metrics, and providing
them upon application request.
2.1.4. Latency Requirements
Within the domain of real time media applications exists a subset of
broadcast applications which have a varying latency requirements.
In instances, it may be permissible to have arbitrary latency
between the real time encoding source and the recipients of that
source. Such cases instances include broadcast media scenarios in
which there is no reference point against which to ascertain the
extent to which the received media is synchronized with wall clock
time. Likewise, there are instances in which such synchronization
Lanphear Section 2.1.4. [Page 7]
INTERNET-DRAFT Expires: April 2003 October 2002
is absolutely essential to the success of the application. For
example, broadcast sessions that are used for security purposes
where timely human response to events communicated in the broadcast
is essential.
DCCP congestion control processing and protocol processing should be
done in such as way as to always minimize propagation delay. The
application should be provided with a mechanism to inform any trade
offs between propagation delay and DCCP functionality. DCCP feature
negotiation, for example, may cost a delay in the stream while a
given feature is agreed upon. An implementation of DCCP may want to
allow the application to configure default responses that can
foreshorten feature negotiation requests. This will allow
mitigation of events that may otherwise stall the session until
feature negotiation completes.
An API to DCCP may, for example, allow the application to specify
preferences for negotiable features prior to the initiation of the
session. This will allow DCCP to perform feature negotiation as per
application preferences without explicit interaction with the
application. The same API may also accommodate the case where the
application needs a more dynamic presence in the DCCP feature
negotiation process.
2.1.5. RTP/RTCP
TBD
2.1.6. IP Telephony
TBD
2.1.7. Video Teleconferencing
TBD
2.1.8. Multi-Player Game Applications
TBD
2.2. Cross Application Issues
2.2.1. Loss Signaling
Although DCCP does provide unreliable delivery of data, it does have
a notion of which datagrams where dropped, and a limited notion of
why they were dropped. Such information is useful to applications
to perform ARQ, or take other adaptive measures. The provision of
Lanphear Section 2.2.1. [Page 8]
INTERNET-DRAFT Expires: April 2003 October 2002
such information to the application may blur the separation of
functionality maintained by the respective communication layers. As
such, an implementation that provides explicit loss information to
the application for each datagram may be both inefficient and
incongruent with certain API paradigms.
2.2.2. Drop Preference
One of DCCP's strong advantages over TCP is its unreliable delivery
of packets. Unreliable delivery allows an application to enforce
retransmission policies, for example, since not all packets need to
be regarded with equal relevance as they in are TCP. This paradigm
can be extended to scenarios where DCCP must drop packets when
resources become scarce.
In the event that DCCP must drop a packet due to buffer overflow, a
decision must be made as to which packet to drop. Some
applications, such as real time media applications, may place
preference on new data versus old data within a given queue. As
such, a DCCP implementation may want to provide the application with
the ability to specify a drop semantic to follow.
2.2.3. Mobility
Mobile capability in DCCP presents a set of problems to applications
that transmit a continuous stream of data. Such applications
include a certain subset of real time media applications and gaming
applications. In the event that a mobile enabled DCCP initiates a
move, the transmission of data must stop until the move completes
successfully. The API semantics of handling this event may be as
simple as responding to write requests with a failure code
indicating that a move event is occurring. It is critical, however,
that the application be afforded an opportunity to make an adaptive
decision in the presence of gaps in service induced by a move event.
DCCP specifies that a receiving DCCP HC may drop all data from a the
old IP address/port pair in response to a successful move event, or
follow an alternate route of accepting a loss window's worth of
data. The semantics chosen for this event should be configurable by
the application.
Since session attributes may have changed as a result of a Move
event, it may be useful to inform the application of the successful
completion of a move event so it can reset state contingent upon
such attributes. Path MTU is an example of such an attribute that
affects application behavior, and is susceptible to change as a
result of a Move event.
Lanphear Section 2.2.3. [Page 9]
INTERNET-DRAFT Expires: April 2003 October 2002
2.2.4. Send Option on Option Change With or Without Data
[DCCP] indicates that options may be sent either with or without
data. Sending options with data may require that the DCCP wait to
send the option until the application has more data to send. This
may not be a desired behavior for an application. Likewise and
application may want to piggyback options onto data for purposes of
efficiency. DCCP applications may be afforded the opportunity to
inform DCCP that an option change request should be sent immediately
rather than after some amount of data has been written to the DCCP.
This can be achieved through a flag sent with the options change
request.
2.2.5. Protocol Information Shared with Overlying Layers
Application layer framing protocols, such a RTP, may represent
session information that is redundant with that used by DCCP.
Examples of such data include sequence numbering and latency
calculations. A DCCP implementation may provide a way to share
information with the overlying protocol in an effort to minimize
redundancy.
Such a model, however, may neither be feasible nor appropriate for
certain existing kernel API paradigms such as BSD sockets. In a
clean design, DCCP need not have knowledge of the header information
added by the overlying protocol. A trade off must be made between
inducing an impact on existing APIs, or creating a new API with
added complexity, and coping with the overhead of redundant data.
3. API and Configuration Considerations
DCCP semantics and functionality must be rendered meaningfully to
the application layer through an API. This section collects the
semantical issues of DCCP that have an impact on an API to DCCP.
3.1. Configuration
DCCP's flexibility has a profound influence on the variability of
DCCP's semantics. Those areas in which DCCP's semantics may vary as
per the needs of the application are represented here as a
collection of configuration variables which an API designer may take
into account when exposing DCCP's functionality.
Configurable variables for DCCP fall into one of two categories.
Either configurable variable may be for an option provided in [DCCP]
, or an option may be exposed provided by the semantics of a
Lanphear Section 3.1. [Page 10]
INTERNET-DRAFT Expires: April 2003 October 2002
particular implementation.
3.1.1. Configurable Variables Specific to DCCP
The specific context and precise meaning of the configurable options
is found in [DCCP]. In some cases [DCCP] provides for a default
configuration, in others no default is specified. Those options
with a specified default are indicated with a *. Otherwise the
default value indicated is a suggested value.
Feature Default Value
------- -------------
CCID 2 *
Connection Nonce 1 *
ECN Capable 1 *
Mobility Capable 0 *
PMTU 0
Data Discard 0
Init Cookie 0
Loss Window 1000 *
Ack Ratio 2 *
Use Ack Vectors 0 *
Service Name n/a
3.1.2. Configurable Variables Specific to an API Implementation
The configurable options collected here represent levels of
flexibility that are provided for in [DCCP] but are not explicitly
articulated. An API to DCCP may expose these options in cases where
an implementation wants to allow default semantics to be modified to
fit the needs of an application.
3.1.2.1. Feature Negotiation Limit
Section 5.3 of [DCCP] discusses Feature Negotiation. It is possible
for DCCP's Feature Negotiation to enter an ambiguous state if a
given end point continues to negotiate for a specific option which
the remote end point does not prefer. In this case, it may be
useful for the application to specify the number of failed change
requests before the connection is aborted. The default value should
be 3.
3.1.2.2. Preferred Feature Priorities, Exclusions and Inclusions
An application may want to specify a set of preferred options with
which to negotiate against a remote end point. The utility of doing
Lanphear Section 3.1.2.2. [Page 11]
INTERNET-DRAFT Expires: April 2003 October 2002
so is to allow a DCCP to try a number of application specified
options before failing a connection, or feature change attempt.
This semantics mitigates the cost of forcing DCCP to negotiate
through the application layer for each failed option change.
An implementation of DCCP may also provide the application with the
ability to indicate certain features that it prefers to use or nor
to use. The inclusion or exclusion of negotiable features for a
DCCP allow that DCCP to indicate application preferences during
feature negotiation
3.1.2.3. Loss Window Ratio
The Loss Window feature, described in section 5.9 of [DCCP] ,
determines the window over which a DCCP endpoint regards received
datagrams as valid. Since the receiver may position the loss window
around the most recent sequence number seen, this variable allows
the application to set the ratio of the loss window space before the
current sequence number to the loss window space after the last
sequence number. The utility of this to an application may be based
on the needs of the application for timely data. That is
application that is too far beyond the current sequence number may
not be of any use to the application and can safely be dropped. The
default is 0, which implies that DCCP should select the ratio and/or
adjust it dynamically.
3.1.2.4. Slow Receiver Notification
Slow Receiver is described in section 7.6 of [DCCP] A sending
application may want to know if a DCCP HC is blocked because of
congestion or because the receiver is slow. This is because the
sending application may wish to take adaptive measures that are more
appropriate to a slow receiver than decreasing the sending rate. The
default value for this option is 0.
3.1.2.5. Slow Receiver Option
By setting the slow receiver option, the application allows the
underlying DCCP to send Slow Receiver options to the sending DCCP.
The default value for this option is 0.
3.1.2.6. Buffer Close Drop Notification
This option indicates that a sending application wants to be
notified in the event that packets are being dropped at the remote
end point, and therefore stop sending data to the underlying DCCP
for transmission. The default value for this option 1.
Lanphear Section 3.1.2.6. [Page 12]
INTERNET-DRAFT Expires: April 2003 October 2002
3.1.2.7. Drop Preference
An application may wish to specify the way in which packets are
dropped from a queue. For example, certain real time applications
have a preference for the most recent data over the oldest data in
the queue. This option may be articulated as a boolean which
indicates that the DCCP should drop-head (1) or drop-tail (0). The
default should be 1.
3.1.2.8. Mobile Receiver Drop Behavior Preference
Section 9.4 of [DCCP] discusses indicates that a DCCP receiver may
drop all data received from the old endpoint once a DCCP-Move has
completed successfully, or it may accept one Loss Window's worth of
data. This option lets the application determine the behavior in
this case. A value of 0 indicates that the receiver should drop all
data from the old endpoint after a move, and a value of 1 indicates
that the receiver should accept one loss window's worth of data from
the remote endpoint after the move.
3.1.2.9. Use Service Name
The Service Name is discussed in section 4.5 of [DCCP]. If this
option is set to 1 then DCCP must force every socket to specify a
Service Name. The default value should be 1.
3.1.2.10. Minimal Buffering Option
An implementation may wish to allow applications to specify the
amount of buffering that the DCCP will do on the sender side. So,
for example, a sending DCCP may support a semantic such that the
DCCP does not make itself available for write requests unless the
current CCID indicates that a write request would result in an
immediate transmission.
3.1.2.11. PMTU Change Behavior
Section 10 of [DCCP] suggests that if the MTU has changed to exceed
the sizes of the pending datagrams, then those datagrams may either
be dropped or transmitted with the DF bit cleared. This behavior
should be configurable by the application.
3.2. Connection Establishment and Termination
3.2.1. Connection Establishment
Due to Feature Negotiation, it is typical that a DCCP connection
attempt will not be completed immediately. An API to DCCP that
Lanphear Section 3.2.1. [Page 13]
INTERNET-DRAFT Expires: April 2003 October 2002
supports non-blocking method invocations should provide a mechanism
for polling the connection state so an application can determine if
a connection attempt is in progress, has failed, or has completed.
3.2.2. Data Piggybacking
[DCCP] permits data piggybacking onto connection requests. An API
need not support this. An API implementation may, however, provide
queuing of transmitted data in the DCCP prior to connection
establishment to mitigate application latency between connection
realization and the initiation of data flow. Implementation of data
piggybacking on a connection request may have an impact on the non-
blocking interface semantics of a DCCP when it a connection is in
progress. Write requests on a connecting DCCP socket may not, for
example, block until the sending DCCPs buffer has filled.
3.2.3. Connection Termination
A DCCP must close both of its half connections as a pair. In lieu
of closing a single DCCP half connection, an application may inform
the DCCP that it no longer wishes to receive data. At which point
the application should be allowed to retrieve all data in the DCCP's
receive buffer. The DCCP should then drop all incoming data for
that half connection, informing the sending end point of the buffer
closed drop.
If a sending end point receives notification of a receive buffer
drop, it should notify the application via some asynchronous
notification or upon a subsequent write request. This way the
sending application can be made aware that the receiving half
connection can no longer accept data.
A closed receive buffer should be regarded as a terminal state for
that half connection prior to closing the full DCCP connection.
That is, the half connection may not return from a buffer closed
state to a state in which it can receive more data without opening a
new DCCP session.
3.3. Feature Negotiation
3.3.1. Negotiable Features
The following features require negotiation with the remote DCCP:
o Congestion Control (CC)
Lanphear Section 3.3.1. [Page 14]
INTERNET-DRAFT Expires: April 2003 October 2002
o ECN Capable
o Use Ack Vector
o Mobility Capable
o Certain CCID-Specific Features
3.3.2. Impact on Configuration Interfaces
A non-blocking API may need to implement a mechanism to determine
the state of an options change request on a DCCP in the case that
the options change request can not be handled immediately. The
cases in which an options change request may be handled immediately
are:
(1) The DCCP is not in connected, and therefore will not negotiate a
feature change until a connection is initiated.
(2) The requested feature is non negotiable.
An implementation may chose to provide non-blocking semantics that
parallel the semantics for a connect attempt. A request to perform
an operation on a DCCP that is in an unknown state due to a pending
feature negotiation may result in the return of an error code that
indicates a feature change is in progress. The API may then provide
a mechanism for asynchronous notification or polling of the status
of the pending or completed feature change.
3.3.3. Feature options with data
DCCP does allow option change requests to contain application data
that is scheduled to be transmitted. An implementation of DCCP may
present a feature change mode where the feature change does not
begin until there is user data to transmit along with the feature
change request. The caveat for such a feature is that feature
changes may suffer from undue latency if the time between
application write requests is long.
3.3.4. Impact of feature negotiation on I/O semantics
The report of the success of a feature negotiation may depend on
more than just the acceptable completion of the negotiation
exchange. Outstanding data in the DCCP may need to be processed
under the previous feature parameters before new data may be
accepted from the application. This semantic is particularly
relevant for CCID changes, in which the application may reasonably
assume that all data sent prior to a CCID change will be sent
Lanphear Section 3.3.4. [Page 15]
INTERNET-DRAFT Expires: April 2003 October 2002
according to the prior CCID. This issue will ultimately the
determine the timing of reporting the completion of a feature
negotiation to the application.
3.4. Error Codes
An API to DCCP may wish to expose error codes that represent the
following conditions:
Connection In Progress
o Feature Change In Progress
o Feature Change Timed Out
o Feature Change failed due to lack of agreement
o Remote Buffer Closed
o Receive Buffer Empty
o Mobile Location Change Failed
o Connection Proof Failed
o Datagram Too Large for MTU
o Slow Receiver
3.5. Statistics
A DCCP implementation may maintain the following statistics for
exposure for use by the application:
o PMTU
o Estimated RTT
o Estimated Buffer Depth
o Estimated inter arrival time of datagrams
o Estimated inter retrieval time of datagrams
o Estimated loss metric
Lanphear Section 3.5. [Page 16]
INTERNET-DRAFT Expires: April 2003 October 2002
o Estimated congestion controlled data rate
o Outstanding un-Acked data
4. Implementation Considerations
DCCP implementations will confront a number of common design
choices. This section identifies and outlines those choices along
with possible solution paths.
4.1. Connection State
DCCP provides a mechanism to support common connection semantics,
while relieving the server of the need to keep state. This is
achieved through an Init Cookie, which the server uses to
encapsulate the original connection request, along with its
response. The echo of this data upon completion of the three way
hand shake allows the server to establish the connection with the
correct parameters without holding state throughout the processing
of the connection.
If the server wishes to avoid holding state during connection
processing, then it also must be able to reject data payloads
piggybacked with a DCCP-Request packet. Otherwise the server would
have to allocate the requisite structures to manage the pending user
data until the connection is established. These semantics leave open
the issues of the way in which the Init Cookie ought to be
implemented, and the way in which a client copes with a data discard
event.
DCCPs which allow the application to piggyback data on to connection
requests may have to handle cases where the server discards the
piggybacked data because it does not want to hold state. This
scenario may be quite common, since the stateless connection feature
of DCCP may be widely implemented and used by applications. DCCPs
may support the retransmission of data piggybacked on a DCCP-Request
packet in a subsequent DCCP-Data packet once the connection is
established. The concept of such retransmission, however, is
contrary to DCCPs design as an unreliable protocol. A more
appropriate implementation may provide a way to notify the
application that a retransmit is required.
4.2. Provision of sequence number, and loss data to application
DCCP's maintenance of a sequence number space and awareness of lost
data may leave room for optimizations with protocols that operate at
layers above DCCP. Certain application layer protocols, for
example, may require an awareness of lost data that is congruent
Lanphear Section 4.2. [Page 17]
INTERNET-DRAFT Expires: April 2003 October 2002
with that maintained by DCCP and may desire to share DCCP's
representation of this information.
There are, however, concerns with this approach. Failure to observe
the layering of protocols may introduce semantical complexities to
the API that could otherwise be avoided. Given that most DCCP
implementations will be in kernel space, the frequency with which
loss data or sequence number representation must be communicated
across the kernel/user boundary becomes a reasonable consideration
for scalability. The trade off for the elimination of redundant
maintenance of sequence numbers is therefore not necessarily useful.
Application layer implementations of DCCP may, however, find an
approach to the sharing of sequence information to be viable.
4.3. Probabilistic Verification of Loss Rate using ECN for TFRC
TBD
4.4. Supporting Application Feature Preference
A full featured DCCP implementation may provide a set of negotiable
features to the remote DCCP that the application may not wish to
present. In such cases it will be useful for an DCCP implementation
to maintain a table of features permitted by the application as per
the application's configuration input. This table should then be
consulted in response to DCCP feature change requests when a feature
preference must be indicated.
4.5. Slow Receiver Interpretation and Notification
A DCCP receiver may notify its sender that the overlying application
keeping up with the inbound data rate. In order to relieve the
application of having to explicitly specify Slow Receiver to DCCP,
an implementation may provide a heuristic to determine when to send
Slow Receiver itself.
A simple heuristic would involve sending Slow Receiver once the
DCCP's receive buffer is within some specified number of bytes of
being full. The problem with this approach is that such a condition
could represent a steady state behavior for the receive queue that
is acceptable to the application.
How a sender reacts to a slow receiver notification will depend
largely on behavior required by the application. For this reason,
an implementation should employ a mechanism to inform the
application that the sender is slow and for the application to
indicate a course of action for the sending DCCP to follow. There
should be no default behavior for the sender's response to a Slow
Lanphear Section 4.5. [Page 18]
INTERNET-DRAFT Expires: April 2003 October 2002
Receiver notification, since an appropriate response is not
dependent on information that is maintained by the transport layer.
5. Security Considerations
TBD
6. IANA Considerations
This document does not introduce any numbers for consideration by
IANA.
7. References
[DCCP] Eddie Kohler, Mark Handley, Sally Floyd, and Jitendra Padhye.
Datagram Congestion Control Protocol (DCCP). Work in progress.
[DCCP-PROBLEM] Sally Floyd, Mark Handley, Eddie Kohler. Problem
Statment for DCCP. Work in progress.
[RFC 2026] S. Bradner. The Internet Standards Process---Revision 3.
RFC 2026.
8. Author's Address
Damon Lanphear <damonlan@real.com>
Media Systems Development
RealNetworks, Inc.
PO Box 91123
Seattle, WA 98111-91123
USA
Lanphear Section 8. [Page 19]
