Subject: [AVT] Comments on draft-ietf-avt-tfrc-profile-08.txt

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 02 Jul 2007 17:25:36 +0200

Ladan

I enclose some comments after reading your latest rev of
draft-ietf-avt-tfrc-profile.  These comments concern questions on RFC
keywords, and some other queries. I will send editorial comments separately.
 
Please do keep me in the loop on further revisions, I'd be happy to read.
 
 Best wishes,
 
 Gorry Fairhurst

----

Questions: 
Section 7., paragraph 3:
OLD:
    Based on initial assumptions on round trip time if more than the
    recommended 5% is needed for RTCP bandwidth, the applications should
    use the SDP bandwidth modifiers RS and RR [3556] to signal the amount
    of RTCP bandwidth needed. Should this assumptions change once the RTP
    flows are running, the application can recalculate the amount of RTCP
    bandwidth needed and resignal this new value using its signaling
    protocol of choice.
= The phrase "should take into account" needs some clarification
(a) Is this a RFC2119 "SHOULD"?
(b) Please clarify "take into account", what does this imply, is it just a
matter of increasing the advertised bandwidth value?
 
- The phrase "should use the SDP bandwidth modifiers RS and RR"
Is this a RFC2119 "SHOULD"?

Section 7.

- The phrase "the application can recalculate the amount of RTCP bandwidth"
- Is this a RFC2119 "MAY" or "SHOULD"

Section 8., paragraph 0:
- The phrase: "the AVPF T_rr_interval variable must not be set"
- Is this a RFC2119 "MUST NOT"?

Section 8., paragraph 2:
- The phrase: "must signal their use of the AVPF profile"
- Is this a RFC2119 "MUST"?
 
- The phrase: "and optionally an initial"
-  Consider changing to "and optionally MAY sends an initial"

Please add (informative) References:

 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement for the
Datagram Congestion Control Protocol (DCCP)", RFC 4336, March 2006.
 
 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
 
 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control
Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC
4341, March 2006.
 
 [RFC4342]  Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram
Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly
Rate Control (TFRC)", RFC 4342, March 2006.
 
 [RFCxRTP] C. Perkins, "RTP and the Datagram Congestion Control
          Protocol (DCCP)", IETF Work in Progress, draft-ietf-dccp-
          rtp-xx.txt.
 
 [ID.DTLS] T.Phelan, "Datagram Transport Layer Security (DTLS)
          over the Datagram Congestion Control Protocol (DCCP)", IETF
          Work in Progress, draft-phelan-dccp-dtls-xx.txt.

---

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Ladan Gharai <[email-masked]>
Date: Thu, 5 Jul 2007 18:45:23 -0400

> keywords, and some other queries. I will send editorial comments  

    Thank you for raising the point of the RFC keyword usage in the  
draft,  as it was somewhat lax, particularly in Section 7.  I have  
addressed them below and welcome more feedback.
> Please do keep me in the loop on further revisions, I'd be happy to  

    Thank you, I will be submitting a revised draft before the monday  
deadline.
> matter of increasing the advertised bandwidth value?

     This paragraph seems to be a mine field of RFC keywords! below  
is a slightly rewritten one, which I hope is less ambiguous.

     Based on initial assumptions on round trip time if more than the
     recommended 5% is needed for RTCP bandwidth, the applications  
SHOULD
     use the SDP bandwidth modifiers RS and RR [3556] to signal the  
amount
     of RTCP bandwidth needed. If the round trip time assumptions  
change after the RTP
     flows start running, the application MAY recalculate the amount  
of RTCP
     bandwidth needed and resignal this new value using its signaling
     protocol of choice.

> - Is this a RFC2119 "MUST NOT"?

      This should be a MUST NOT - as setting T_rr_interval to a value  
higher than the current RTT will disrupt the TFRC timing requirements
> - Is this a RFC2119 "MUST"?

       Yes.
> -  Consider changing to "and optionally MAY sends an initial"

      This should probably be consistent with para 3 of section 7 -  
which says SHOULD