Subject: [AVT] Comments on http://www.ietf.org/id/draft-ietf-avt-rapid-acquisition-for-rtp-05.txt

From: Joshua Gahm <[email-masked]>
Date: Wed, 9 Dec 2009 09:35:55 -0500

I would like to make a few comments on http://www.ietf.org/id/draft-ietf-avt-rapid-acquisition-for-rtp-05.txt 
, which is currently in Last Call.

1. On page 18, with reference to the following sentence:

        The unicast burst duration MAY be calculated by RS, and its  
value
        MAY be updated by messages received from RTP_Rx.

Is the word "MAY" here at the discretion of the RS or the RTP_Rx?  In  
other words, does this mean that the RS MAY send updated durations and  
the RTP_Rx MAY pay attention to them, or does it mean that the RS MAY  
send updated durations and the RTP_Rx MUST may attention to them if it  
receives them?  I would suggest that the RS MAY send updated burst  
information to the RTP_Rx and if the RTP_Rx receives this information  
it SHOULD use the most recently received information.

2. I am not able to understand the meaning of the paragraph just below  
figure 3 which begins, which says:

    This document defines the expected behaviors of RS and RTP_Rx.  It  
is
    instructive to have independently operating implementations on RS  
and
    RTP_Rx that request the burst, describe the burst, start the burst,
    join the multicast session and stop the burst.  These  
implementations
    send messages to each other, but there MUST be provisions for the
    cases where the control messages get lost, or re-ordered, or are not
    being delivered to their destinations.

Can the intent of this paragraph be clarified, particularly as it  
contains a "MUST".  Specifically:

a. What do the words "independently operating implementations" mean?   
Are they referring to different sub-components of the RS and the  
RTP_Rx (e.g. the parts that "request the burst, describe the burst,  
start the burst", etc)? Or do they refer to the possibility that the  
RS and RTP_Rx were written independently with only this draft to guide  
them in order to achieve interoperability?

b. Are the provisions for lost or reordered messages which both RS and  
RTP_Rx MUST have up to the implementors of RS and RTP_Rx to decide on,  
or are they laid out more specifically in the draft elsewhere?  If the  
latter, can this general requirement be dropped?  If the former, is it  
possible to offer more specific guidance to implementors in order to  
ensure that what they decide to do will result in interoperable RS and  
RTP_Rx implementations?

3. In the introduction, and elsewhere in the document where "Reference  
Information" is described and discussed, I think it would be useful to  
explicitly mention that reference information may include an intra- 
coded video frame, such as an I-frame in MPEG-2, since this would be a  
leading example of Reference Information when RAMS is used for video  
applications.  I would suggest simply adding a sentence to the  
introduction saying, "When the multicast flow contains video data, the  
reference information will typically also include an intra-coded video  
frame, which is needed in order to process subsequent frames in the  
primary multicast stream."  The introduction as it now stands tends to  
suggest that intra-coded frames would not be part of the Reference  
Information, particularly in the sentence, "The Reference Information  
is conventionally sent periodically in the multicast session, and  
usually consists of items such as..."  By emphasizing the periodic  
sending (suggesting repetition) and failing to mention intra-coded  
frames in the list, the text tends to suggest that Reference  
Information does not include intra-coded frames.

4. Some minor editorial comments:

a. Page 5.  Missing word "and" before "size of the reference  
information".

b. Page 6.  Extra words "at a" after "Server may also burst the  
reference information".

c. Page 10. "self-" should probably be dropped from the sentence "In  
particular, the rapid acquisition operation must avoid self- 
interference with the multicast session that may be simultaneously  
being received by other hosts."

d. Page 11.  Missing "." after "excess-bandwidth coefficient".

e. Page 20.  First paragraph begins with the word "Alternatively" but  
actually seems to be saying the same thing as the previous paragraph.

f. Page 21.  Punctuation problem after "compound RTCP packet".

g. Page 21. Punctuation problem after "been delivered to RTP_Rx".

Thanks
Joshua Gahm

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 9 Dec 2009 07:54:12 -0800

Thanks for the comments.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Josh Gahm (jgahm)
> Sent: Wednesday, December 09, 2009 9:36 AM
> To: [email-masked]
> Subject: [AVT] Comments onhttp://www.ietf.org/id/draft-ietf-avt-rapid-acquisition-for-rtp-
> 05.txt
> 
> I would like to make a few comments on http://www.ietf.org/id/draft-ietf-avt-rapid-
> acquisition-for-rtp-05.txt, which is currently in Last Call.
> 
> 
> 
>        The unicast burst duration MAY be calculated by RS, and its value
> Is the word "MAY" here at the discretion of the RS or the RTP_Rx?  In other words, does
> this mean that the RS MAY send updated durations and the RTP_Rx MAY pay attention to them,
> or does it mean that the RS MAY send updated durations and the RTP_Rx MUST may attention
> to them if it receives them?  I would suggest that the RS MAY send updated burst

I just sent another email regarding this. I believe the wording should be that RS MAY send an update, and the receiver SHOULD adhere to it. See my other mail on the mailing list about the heuristics. 

> information to the RTP_Rx and if the RTP_Rx receives this information it SHOULD use the
> most recently received information.

Yes.
 
> 2. I am not able to understand the meaning of the paragraph just below figure 3 which
> begins, which says:
> 
>    This document defines the expected behaviors of RS and RTP_Rx.  It is
>    instructive to have independently operating implementations on RS and
>    join the multicast session and stop the burst.  These implementations
> Can the intent of this paragraph be clarified, particularly as it contains a "MUST".
> Specifically:
> 
> a. What do the words "independently operating implementations" mean?  Are they referring
> to different sub-components of the RS and the RTP_Rx (e.g. the parts that "request the
> burst, describe the burst, start the burst", etc)? Or do they refer to the possibility
> that the RS and RTP_Rx were written independently with only this draft to guide them in
> order to achieve interoperability?

The latter. Receivers and servers from different implementations should be able to communicate with each other w/o breaking things. A lot of stuff depends on the successful and timely receipt of some sort of messages. In case those messages get lost/re-ordered/etc., things should not break. That's why we used "MUST" in this sentence. But maybe we can make it "must".
 
> b. Are the provisions for lost or reordered messages which both RS and RTP_Rx MUST have up
> to the implementors of RS and RTP_Rx to decide on, or are they laid out more specifically
> in the draft elsewhere?  If the latter, can this general requirement be dropped?  If the
> former, is it possible to offer more specific guidance to implementors in order to ensure
> that what they decide to do will result in interoperable RS and RTP_Rx implementations?

We provided a section for this (6.4). Would they be satisfactory for your needs? It is informative as of now. Do you think it should be normative?
 
> 3. In the introduction, and elsewhere in the document where "Reference Information" is
> described and discussed, I think it would be useful to explicitly mention that reference
> information may include an intra-coded video frame, such as an I-frame in MPEG-2, since
> this would be a leading example of Reference Information when RAMS is used for video
> applications.  I would suggest simply adding a sentence to the introduction saying, "When
> the multicast flow contains video data, the reference information will typically also
> include an intra-coded video frame, which is needed in order to process subsequent frames
> in the primary multicast stream."  The introduction as it now stands tends to suggest that
> intra-coded frames would not be part of the Reference Information, particularly in the
> sentence, "The Reference Information is conventionally sent periodically in the multicast
> session, and usually consists of items such as..."  By emphasizing the periodic sending
> (suggesting repetition) and failing to mention intra-coded frames in the list, the text
> tends to suggest that Reference Information does not include intra-coded frames.

Good point. We need to make it clear that not all Reference Information will be repeated periodically (I frames do repeat but they are not the same I frames).

> a. Page 5.  Missing word "and" before "size of the reference information".
> 
> b. Page 6.  Extra words "at a" after "Server may also burst the reference information".
> 
> c. Page 10. "self-" should probably be dropped from the sentence "In particular, the rapid
> acquisition operation must avoid self-interference with the multicast session that may be
> simultaneously being received by other hosts."
> 
> 
> e. Page 20.  First paragraph begins with the word "Alternatively" but actually seems to be
> saying the same thing as the previous paragraph.
> 
> 

Thanks. Will fix these.

-acbegen