Subject: [AVT] Remaining comments from AD review: draft-ietf-avt-rapid-acquisition-for-rtp-11

From: Robert Sparks <[email-masked]>
Date: Thu, 19 Aug 2010 16:36:29 -0500

Summary: There are some remaining points to discuss before taking this 
         into IETF LC

I've raised concerns on the interoperability of the 0 response code,
the level of specification of the rest of the response codes,
and the ABNF extension to rtcp-fb-val in separate threads.

* This document covers a lot of intricate technical ground in a small number 
  of words. I appreciate the effort that's gone into making it clear, 
  but I'm still finding parts very difficult to read. 
  One editorial suggestion that would relieve much of that difficulty would be 
  to consistently use articles before names like RS, RTP_Rx, and FT_Ap. 
  Say "associated with the FT_Ap" instead of "associated with FT_AP". I also
  encourage a careful pass looking for ambigious pronouns, particularly "it". 

* The document is internally inconsistent on whether this concept applies to more
  than SSM sessions. If the intent is to only specify this for SSM, that should 
  be explicit. If the intent is to be more general, there are sections that will
  need additional text.

* Why is the ", except perhaps in pathological circumstances," escape clause 
  added to the first constraint in section 5? If there are certain pathological
  circumstances to be aware of, call them out. I suggest deleting the clause.

* The argument for allowing immediate RTCP feedback messages in section 6.2 
  may need a more support. Is it clear that for special events (sporting events,
  political announcements, and other disasters), you won't have a large number 
  of clients beginning the acquisition process at the same time? Why don't the 
  concerns about flash crowds apply in this situation?

* In 6.2, It wasn't clear what the sentence "It is instructive to have
  independently ... stop the burst" was trying to accomplish during my first
  several reads. It looked like you were asking for actual independent 
  implementations like you would need for an interoperability report. 
  If I change it to say "It is instructive to consider independently ...", 
  the intent is clear to me.  Is that the meaning you had in mind?

* 6.2 step 3 (page 18): Suggest s/associate itself/be associated/

* 6.2 step 3 (page 19): Suggest replacing "RTP_Rx MUST NOT make
  protocol dependencies on quickly receiving the initial RAMS-I 
  message" with "An RTP-RX implementation MUST NOT assume it will
  quickly receive the initial RAMS-I message".

* 6.2 step 5 - last paragraph: Would it mean the same thing to say
  "It is an implementation-dependent  decision for an RTP_RX whether 
   and when to send an updated request."? 

* 6.2 step 9, last paragraph on page 21 : Is it possible that the
  BRS would already be past the point of sending the burst packet
  with an OSN matching the sequence number in the RAMS-T message
  when the RAMS-T message arrives and is processed?

* 6.2 step 9 (top of page 22) : Can you clarify "MUST be addressed to"
  in "The RAMS-T message(s) MUST be addressed to (the) BRS and sent in
  the unicast burst RTP session"?

* 6.5 fifth paragraph. The BRS _will_ (not _can_) continue sending
  burst packets in the case of a lost RAMS_T. There's no way for the
  RTP_Rx to know these messages were lost, so how would the RTP_Rx
  know it was "In such cases". Are you wanting the RTP_RX to _always_
  repeat the RAMS_T message or are you intending the
  recommended retransmission behavior to apply only if the RTP_Rx
  is still receiving burst packets after sinding a RAMS_T?
       
* 7.2 : Why doesn't Figure 7 show the mandatory TLV element?. Does
  this mandatory element have to occur first in the list? Is it allowed
  to have multiple TLV elements with the same type (for any type), and in
  particular, what happens if there is more than one TLV with element
  of Type 1?

* 7.2, 7.3, and 7.4: The last sentence of each of these sections would
  be more effective near the beginning of each section. It would also help
  to be precise on what "payload type" you are referring to. 

* 7.3 definition of type 32: Would it be correct to say "the respective unicast 
   RTP stream" ? In the second to last
   sentence, I suggest s/this element exists/this element MUST be included/.

* 7.3 definition of type 33: 
    I see in the history that the document had a mostly global substitution
    of "can" for "may". Avoiding ambiguities between lower and upper-case
    2119 words is a good thing, but I think this particular definition
    suffered from the edit, and normative requirements on the behavior
    of the element receiving this TLV were actually intended. (Otherwise,
    what's the point of having the TLV at all).

    Suggest s/when RTP_Rx sends an SFGMP Join/when an RTP_Rx MAY send an 
      SFGMP Join/
      (With the caveat that earlier versions of the draft said SHOULD send)
    and  s/RTP_Rx can send the SFGMP Join/RTP_RX MAY send the SFGMP Join/

    And there is a lowercase "should" in the third paragraph - should that
    have been SHOULD?

* 7.4 definition of type 34:
   What is a "delta difference" of two packets? Is this meant to be the
   difference in the time that the first and last burst packets are expected
   to be sent?

Nits:

* Last paragraph of 6.1: s/document proposes/document defines/

* Can you tighten Figure 3 to fit on one page?

* In 6.2, step 1 on page 17: Would it make more sense to say "choose its
  RTP and RTCP receive ports for the unicast" rather than "in the unicast"

* 6.2 , step 3 on page 18 : It had been long enough since the definition
  of FT_Ap back on page 8 that I wasn't able to easily find that defintion.
  Please call out what the FT_Ap is again here.

* 6.3 Suggest replacing the first sentence with "When an RTP_RX acquires
  multiple primary multicast streams, it might need to synchronize them for
  playout."

* 6.3, suggest deleting the word "traditionally" from "This synchronization
  is traditionally achieved"

* 6.5 (and 7.3) I'm not sure deterministic is quite the right word where
  you say "MUST be provisioned to deterministically terminate" and "MUST 
  terminate the flow in a deterministic timeframe". Are you trying to avoid
  non-deterministic (perhaps probabilistic) termination, or the possibility 
  of never terminating? I think it's the latter. I suggest deleting the word
  "deterministically" in 6.5 (is it adding anything?) and changing the 7.3
  to say something like "The BRS MUST terminate the flow in the timeframe
  indicated by this burst duration or the duration established by those 
  subsequent events, even if it does not get a RAMS-T or a BYE from the RTP_Rx".
  ("Those" points to the events discussed in the immediately preceeding sentence).

* 7.3 third paragraph, first sentence: 
    s/one RAMS Information/one RAMS Information message/

* 7.3 2nd bullet in the fields description: Please add a forward pointer to
    the IANA considerations section at "defines several inital response codes".

* 7.4 2nd paragraph: "a plain RAMS-T" message implies that there are special
    (or at least not plain) RAMS-T messages. I don't think the document defines
    any of those. I suggest deleting the word "plain" from the sentence.

* 8.3 Please review the sentence containing the phrase "prediction chain". 
    That's the only occurance of the phrase in the document. I suspect
    the sentence could be recast to fit this document a little more cleanly.

* 11.6 : You've reserved a value (65536) that can't be encoded in the 16 bit
         field you want to store it in. Did you mean 65535?

* 14.1 : The reference for [DLNA] is oddly formatted.

* (tiny nit) Section 4 last sentence: 
  The clause ", sometimes a significant amount," doesn't mean (or motivate) 
  much without characterizing significant. Can you say something more
  concrete like "sometimes thousands of octets"?

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 19 Aug 2010 15:55:49 -0700

Hi Robert, 

Thanks for the detailed review. My comments are inline:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Sparks
> Sent: Friday, August 20, 2010 12:36 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] Remaining comments from AD review:draft-ietf-avt-rapid-acquisition-for-rtp-11
> 

I am not a native speaker but I have been told several times that it is (more) correct to use acronyms without the "the" article. But, I am fine with adding "the"s.

>   encourage a careful pass looking for ambigious pronouns, particularly "it".

Will do another pass.
 
>   be explicit. If the intent is to be more general, there are sections that will

The protocol uses/requires 5760 so it is for SSM. In the introduction, we used "multicast" rather than specifically saying "SSM" because the same problem applies to any multicast application. But, we do not solve the problem for ASM apps. Maybe, saying this will be sufficient? 
 
>   circumstances to be aware of, call them out. I suggest deleting the clause.

Calling them out may open a new can of worms. This section is informative anyway, so I will rather delete it.
 
>   concerns about flash crowds apply in this situation?

We discussed this on the list in detail. The bottomline is it does not matter if you delay your first feedback message or randomize it or whatever. At the end, the individual instances the first feedback message will be sent by different clients are random anyway. So applying no delay is the same as applying a delay for everybody, i.e., will not make the flash crowds worse or better.
 
>   the intent is clear to me.  Is that the meaning you had in mind?

Yes, this is better.

> * 6.2 step 3 (page 18): Suggest s/associate itself/be associated/

OK.
 
>   quickly receive the initial RAMS-I message".

OK.
 
>    and when to send an updated request."?

Yes. Can replace it with your suggestion.
 
>   when the RAMS-T message arrives and is processed?

Could be. This is implementation specific. The BRS may prefer to overlap or fill a gap (and fill the gap later via retransmissions).
 
>   the unicast burst RTP session"?

Meaning they must be sent to BRS and the port associated with the unicast session (not the SSM session).

> * 6.5 fifth paragraph. The BRS _will_ (not _can_) continue sending

If the BRS is configured to stop the burst at a point (as a precaution), it may stop the burst.

>   is still receiving burst packets after sinding a RAMS_T?

RAMS-T can be repeated following the RTCP FB rules. If the burst is still going on, that is a clear indication that RAMS-T did not make it. I don't think we need to mandate repeated RAMS-T's.
 
> * 7.2 : Why doesn't Figure 7 show the mandatory TLV element?. Does

The list can be empty, which means this TLV is not mandatory. We need to fix it.

>   this mandatory element have to occur first in the list? Is it allowed

Mandatory elements occur before the optional ones.

>   particular, what happens if there is more than one TLV with element

No, multiple elements with the same type cannot exist. Let me add it if we don’t have this explicitly mentioned.
 
>   to be precise on what "payload type" you are referring to.

OK, here the payload type is the type of the media rapidly acquired (ie, the type carried in the SSM).
 
>    RTP stream" ? In the second to last

Yes.

>    sentence, I suggest s/this element exists/this element MUST be included/.

I believe we deleted the MUST here because the same requirement was mentioned in section 6. And if I am not mistaken, Keith has asked not to repeat the same 2119 requirements in different places.
 
>     and  s/RTP_Rx can send the SFGMP Join/RTP_RX MAY send the SFGMP Join/

OK.
 
>     And there is a lowercase "should" in the third paragraph - should that

Well, we could not agree on the case(s) when this SHOULD would not be respected. To me, we can even say MUST, because if those times are not close enough, that means the server is doing a bad job anyway.
 
>    difference in the time that the first and last burst packets are expected

Right, let me clarify it.
 
> * Last paragraph of 6.1: s/document proposes/document defines/

OK.
 
> * Can you tighten Figure 3 to fit on one page?

Will try.
 
>   RTP and RTCP receive ports for the unicast" rather than "in the unicast"

OK.
 
>   Please call out what the FT_Ap is again here.

OK.
 
>   multiple primary multicast streams, it might need to synchronize them for

OK.
 
>   is traditionally achieved"

OK.
 
>   of never terminating? I think it's the latter. I suggest deleting the word

Correct.

>   ("Those" points to the events discussed in the immediately preceeding sentence).

OK.
 
>     s/one RAMS Information/one RAMS Information message/

Good catch.
 
>     the IANA considerations section at "defines several inital response codes".

OK.
 
>     any of those. I suggest deleting the word "plain" from the sentence.

Right, it meant to be a message w/o the tlv.
 
>     the sentence could be recast to fit this document a little more cleanly.

Will try :)
 
>          field you want to store it in. Did you mean 65535?

Will fix.
 
> * 14.1 : The reference for [DLNA] is oddly formatted.

Will fix.
 
>   concrete like "sometimes thousands of octets"?

Can say "a few seconds". But this would not be true for all kinds of codecs/transports out there. Maybe, we should say "up to a few seconds".

We will wait for a few days for people to comment on these changes. Then we will revise the document along with other changes you requested earlier.

Cheers, acbegen