RE: [dccp] WG Last Call for Problem Statement

[john.loughney at nokia.com]

Lars,

> the document is in last call right now, and if I count days  
> correctly, that's just ending.
> 
> So far, we've counted three mostly positive responses (Eddie, Colin,  
> you) and have not seen any negative response. I think that's  
> consensus to publish, if not an overly enthusiastic one.
> 
> Would you send your proposed editorial tweaks to the authors and the  
> list? We'll formally end the LC after.
> 
> Thanks for your offer to review the doc - we'll include the offfer in  
> the writeup to the IESG.

My apologies for sending these comments late.  The run-up to IETF is always
hectic.  I think that most of these are fairly editorial in nature, and
I'm happy to submit text if that would help.  I think a quick revision of
this statement would vastly improve the document, so I hope you consider
my comments:

My comments:

1) Abstract says:

     ...  DCCP implements a congestion-
     controlled, unreliable flow of datagrams suitable for use by
     applications such as streaming media or on-line games.

There's been ongoing discussions on the suitability of the protocol
and the CCIDs about the applicability for streaming, etc.  It might
be more accurate to drop the 'suitable and say something like:

     ...  DCCP implements a congestion-
     controlled, unreliable flow of datagrams for use by
     applications such as streaming media or on-line games.

2) Intro:

    Recent years have seen the growth of applications that use UDP in a
    different way. These applications, including RealAudio, Internet

I think 'RealAudio' is a trademarked term, perhaps 'Internet Radio' might
be a better term.  I also wonder if we really need to include the name
of games "and on-line games such as Half Life, Quake, and Starcraft," 
in the RFC, and rather just say "multiplayer & massive multiplayer on-line
games."

3) The statement:

    This growth of long-lived non-congestion-controlled traffic,
    relative to congestion-controlled traffic, poses a real threat to
    the overall health of the Internet.

would be more powerful if there was reference backing up this.  These days,
I'm not sure that UDP traffic is really a problem, P2P traffic (BitTorrent, etc.)
seems to actually a major bandwidth hog these days.

4) The last paragraph in the intro:

    This problem statement began in 2002 as a formalization of the goals
    of DCCP, which was at that time a proposed protocol already
    described in several Internet-Drafts. We intended DCCP to satisfy
    the problem statement laid out here. However, we believed the
    problem should be solved whether or not the chosen solution is DCCP,
    and the DCCP drafts should be judged based on this document or its
    successors.  For convenience, in this document we write "DCCP" to
    mean "any protocol that satisfies this problem statement".

could probably be dropped, as DCCP will be published as an RFC.

5) 1st paragraph in the section 2:

    We perceive a number of problems related to the use of unreliable
    data flows in the Internet.  The major issues are:

    o The potential for non-congestion-controlled datagram flows to
      cause congestion collapse of the network.

What is the likely-hood of this?  Pointers to studies, papers, would be appreciated.
What would be a more likely issue is that some links / subnets / etc. could become
overloaded with UDP traffic and cause a lot of problems for service providers and
network operators.  Think of an ISP deploying a VoIP and having their access network
become unmanageable due to too much UDP traffic.

6) Section 2.1:

	... In an interactive game or VR session, position information is

What's VR?  I'm guessing virtual reality ...

7) 3.1.3.  The Evasion of Congestion Control

I'm not entirely convinced by this argument, the growth of p2p protocols and software
seems to indicate that there's enough coders out there who will go and implement
what they want, especially if they want performance.  Also, a quick google of "reliable"
and "udp" shows that many folks want the reliability of tcp without its cost (aka
congestion control).  I guess this section could be left in the document, but
it doesn't really seem to add much to the problem statement, imo.

8) Section 3.3.2 should be updated to talk about PR-SCTP: http://www.ietf.org/rfc/rfc3758.txt
Also, unreliable SCTP references should be updated to "Partially Reliable SCTP." And on
further thought, it might be good to re-write this section, as its fairly inaccurate.  i'd
be happy to try to re-write this section, in a fairly neutral, non-biased way, if it would
help.

9) Nit:  Lots of uses of `` - should be updated to either " or ''

So, in summary, I think that this document has a lot of good information, however I'm concerned
about some of the "death of the Internet, news at 9" statements - if they are accurate,
referencing papers, simulation results or other information would be needed.   I also
think that the text refering to unreliable SCTP should be corrected and updated.

thanks,
John