[dccp] Problem Statement for DCCP

[Sally Floyd <floyd at icir.org>]

I have done a round of minor editing to the Problem Statement draft,
at "http://www.ietf.org/internet-drafts/draft-ietf-dccp-problem-01.txt";, 
and I think it is now ready to move to Informational.  (The final
version will have updated addresses for Mark and Eddie...)  The
changes were for updating references, or minor editing changes.
The diffs are below (excluding the diffs for formatting, updated
boilerplate copy, updated references, etc.)

There is also a brief history of the Problem Statement draft below.

I think this is now ready to go to Informational.  (I guess after
another Working Group Last Call?)  If there is any feedback, let me
know.

- Sally

------------------------------------------------------------------

The history of the Problem Statement draft:

The Problem Statement was presented in the Yokohama IETF in 2002,
and working-group-last-called on September 12, 2002, with Spencer
Dawkins as an assigned reviewer.

The Working Group Last Call included the following:
"After last call we're going to freeze this document but not submit it
to the RFC Editor.  This gives us the flexibility to make changes
later on."

>From September 16 2002 email from Aaron:
"The intent here is to get a working group consensus on the 'problem
statement' but wait a while before sending it to become an RFC.
Should we learn more about the nature of the problem we may wish
to revise it later.  Note that this won't be done lightly as we
will have already reached a consensus that the document is good as
it stands.  Since RFCs last *forever* and may *never* be changed,
only obsoleted by new documents, this gives us just a little
flexibility to ensure a more consistent set of documents later on."

The revised document, draft-ietf-dccp-problem-00.txt, was submitted
in October 2002, and had been in deep-freeze since that time.

------------------------------------------------------------------

The diffs from draft-ietf-dccp-problem-00.txt:

Index: problem.nrf
===================================================================
RCS file: /usr/local/share/doc/apache/cvs/dcp/problem.nrf,v
retrieving revision 1.42
retrieving revision 1.48
diff -r1.42 -r1.48
171c176,180
< .br
---
> 
> Changes from draft-ietf-dccp-problem-00.txt:
> 
> * Updated references, minor editing changes.
> 
244c253
< This problem statement began as a formalization of the goals of DCCP, a
---
> This problem statement began in 2002 as a formalization of the goals of DCCP, which was at that time a
246c255
< DCCP to satisfy the problem statement laid out here. However, we believe the
---
> DCCP to satisfy the problem statement laid out here. However, we believed the
249c258
< Nevertheless, for convenience, we write "DCCP" to mean "any protocol that
---
> For convenience, in this document we write "DCCP" to mean "any protocol that
295c304
< applications that generate large, long-lived flows of unreliable datagrams,
---
> applications that generate large or long-lived flows of unreliable datagrams,
331c340
< Of these issues, applications that generate large, long-lived flows of
---
> Of these issues, applications that generate large or long-lived flows of
372,373c381,382
< control. (TCP-Friendly Rate Control, or TFRC, is
< being standardized in the IETF as a congestion control mechanism that
---
> control. (TCP-Friendly Rate Control, or TFRC, has 
> been standardized in the IETF as a congestion control mechanism that
388,394c397,401
< For example, a telephony application sending a 20Kb/s packet stream
< wanting moderately low delay may send a packet every 20ms, leaving only 50
< bytes for each packet.  Of this, 20 bytes is taken up by the
< IP header, leaving only 30 bytes for the transport header and payload.
< Of course this is a relatively extreme example, but it serves to
< illustrate the degree to which some of these applications care that
< the transport protocol is low overhead.
---
> For example, a telephony application sending a 5.6Kbps data stream
> but wanting moderately low delay may send a packet every 20ms, sending only 14 data bytes in each packet.  In addition, 20 bytes is taken up by the
> IP header, with additional bytes for transport and/or application
> headers.  Clearly, for such an application it is desirable to have
> a low overhead for the transport protocol header.
577c583,585
< the receiving UDP will pass that CE status to the receiving application
---
> the receiving IP layer will pass the CE status to the UDP layer,
> which will pass it
> to the receiving application
667c675
< approach suffers from most of the problems described in section
---
> approach suffers from most of the problems described in Section
695c703,704
< To use this mechanism most effectively, the semantics
---
> To use congestion feedback at a layer below UDP most effectively, 
> the semantics
780c789
< structure of the SCTP packet, into a common SCTP header followed
---
> structure of the SCTP packet, of a common SCTP header followed
810c819,822
< ``kitchen sink'' approach in this case.
---
> ``kitchen sink'' approach in this case; aside from the higher
> header overhead, a ``kitchen sink '' protocol seems more likely
> to have unforseen interactions and difficulties in making
> modifications down the road.
846c858
< RTP header that removes fields redundant with the new protocol's headers.
---
> RTP header that removes any fields redundant with the new protocol's headers.
872c884
< have been brought to the IETF for further feedback.
---
> were brought to the IETF for further feedback.
874,875c886,888
< decisions resulting from this problem statement will be addressed
< in a later document.
---
> decisions resulting from this problem statement have been 
> addressed in later documents
> .CITE DCCP ". "
885c898,899
< These include the use of Explicit Congestion Notification (ECN) and the
---
> These design requirements
> include the use of Explicit Congestion Notification (ECN) and the
1047,1048c1060,1062
< If there is a consensus about the need for a new unicast transport protocol
< for unreliable datagrams, then the next step can be the
---
> In 2002, there was judged to be
> a consensus about the need for a new unicast transport protocol
> for unreliable datagrams, and the next step was then the
1074,1075c1088,1089