[dccp] **** NiTs on draft-ietf-dccp-tfrc-media-00.txt

[Gorry Fairhurst <gorry at erg.abdn.ac.uk>]

I started reading draft-ietf-dccp-tfrc-media-00.txt on the way home, and
finished it tonight.

Best wishes,
Gorry

I have two comments/queries...

-----
Intro end para 2
" experiencing considerable duress"
- Can you more precise about the nature of the ill-effects that you expect?
------
In point " o  Capacity Probing and Lost Packets:"
The text says " TFRC will continuously raise the allowed rate until
 a packet is lost:"
- Is this correct?
- I thought TFRC allowed (expected?) the sender to do so, but it is the
application that generates the data used as probes, so for the rate to
increase requires that the application is *able* to send at a higher rate
(i.e. There is data available)? - I think you make this point later?

===========================================================
The rest of my comments are editorial NiTs, on the text, which you may like
to fix in the next rev:
----
Into start para 2
The I-D says:
  "The IAB has expressed concerns over the stability of the Internet if
   these applications become too popular with regard to TCP-based
   applications [RFC 3714]."

- I think the concern wasn't that specific applications became "popular",
but that if the traffic generated by these non-congestion responsive
applications became an appreciable component of the traffic compared to that
of TCP. 
----
Section 2 para 1
"AIMD congestion control algorithms, such DCCP's CCID2 [CCID2] or"
                                         ^
Insert "as"
-----
Section 2 para 1
"transmitter" 
s/transmitter/transmitter sending rate/
------
Page 8:
" this is probably too slow initially,"
                   ^^^^^^^^
- I think this is slower than the required decoding rate/playback threshold?
----
Page 8:
" that the network has a bit "
- delete "a bit" ?;-)
----
Page 11:
" the transmit buffer will drain and we'll reach a steady"
- "we'll" -> is that the "receiver will"
- similarly "we" on the next line.
----
Page 14:
"   The reasoning for this is that bottlenecks can be the bits per second
   capacity of links, and also the packets per second capacity of
   routers."
- I didn't understand what this was meant to mean.
----