[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dccp] WG Last Call for Problem Statement

Hi John.

On Jul 26, 2005, at 10:43 PM, john.loughney at nokia.com wrote:

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.


Sounds good.

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." 

Sounds good.

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. 

Will add a reference to RFC 3714.

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. 

This has been changed to

This document began in 2002 as a formalization of the goals of DCCP,
the Datagram Congestion Control Protocol
.CITE DCCP ". "
We intended DCCP to satisfy this problem statement, and
thus the original reasoning behind many of DCCP's design choices can be
found here.
However, we believed, and continue to believe, that the problem should be
solved whether or not DCCP is the chosen solution.

in the most recent draft.

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. 

Don't plan to do anything here.

6) Section 2.1:

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

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

I think that's what was intended.  Expanded the acronym.

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.

Don't plan to change anything here. The document is qualified enough as it is.

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. 

Added reference to RFC3758.

Can you be more specific please? What exactly is inaccurate? There's no need to write text. Just say what the problem is.

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

Already updated.

Thanks for the comments.
Eddie



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