Re: [AVT] WG last call: RTP Profile for RTCP-based Feedback (RTP/AVPF)

[Magnus Westerlund <[e-mail]>]

Hi,

Here is my comments on the latest version of the AVPF draft. I am glad 
that we are coming very near a finished specification for AVPF. However 
I still have some things that we might need to discuss a little bit, see 
point 14-17. I hope this will not delay the progressing to much. I would 
very much hope that we can see a updated version just weeks after meeting.

Best Regards

Magnus


1. Before Abstract: The short copyright is missing.

2. Section 1.1: Early RTCP packet definition. It might be good in this 
definition to explain what [1] is by including the word "RTP/RTCP" 
before the reference.

3. The documents page lengths seem to be highly variable. It is not 
pretty when the footer jumps up and down the different pages.

4. Section 2, RTCP Report interval: The second sentence in the 
explanation says: " In Regular RTCP mode, all rules from [1] apply." 
This is not true as the minimal 5 second rules is removed in this case. 
Also the following sentence makes it clear that the five second rules is 
only removed for immediate and early RTCP modes.

5. Isn't usually that the page header has the document title centered on 
the line?

6. Section 3.2 Third paragraph: A sentence beginning with "Hence" is 
missing space before it.

7. Section 3.2 Fourth paragraph: The first sentence is a bit unclear. 
The use of following lacks a clear context. I understand that one may 
send a earlier then what the normal rules would allow. However this 
sentence may also be interpreted that scheduling earlier is done by 
following the previous normal rule.

8. Section 3.2 Fourth paragraph. In the middle of the section there is a 
number of spaces missing and a double ".". See sentence: "The receiver 
waits for a (short)random dithering intervalto checkwhether it sees a 
corresponding FB message from any other receiver reporting the same event.."

9. Section 3.2 Fourth paragraph, last sentence: "The permission to send 
Early feedback is derived from the time Early feedback was sent." I 
think this is a bit unclear. I think that one must better clarify that 
it depend on if early feedback has been sent or not in the last 
interval. A proposal could be :" The permission to send Early feedback 
is dependent if an Early feedback has been sent since the last regular 
RTCP packet."

10. Section 3.4 bullet d: I think the word "deterministic" should be 
added to the first sentence to clarify the impact Tmin has.

11. Section 3.4 bullet g: I think one could include text to clarify what 
the value will be if in a multicast session.

12. Section 3.4 Bullet m: The following sentence should be reformulated 
to become more clear and precise: "If T_rr_interval!= 0 then Regular 
RTCP packets will not be scheduled T_rr after the last Regular RTCP 
transmission (at tp+T_rr) but at least T_rr_interval after the last 
Regular RTCP transmission, i.e. later than or at tp+T_rr_interval." 
Mostly I think that "but" is the wrong word here.

13. Section 3.4 Bullet o: Prior to this section there is a stray 
occurrence of "Regular".

14. Before section 3.5: I think that there should be a section 
describing Immediate Feedback mode also. This mode is a bit under 
explained. One get some general impression of the mode in section 3.3. I 
think that this section could clarify that in immediate more one can 
send FB messages anytime. Also how one connects immediate packets to 
regular reports.  However one MUST track the number of reports that are 
sent to determine when one passes the FB threshold.

15. Section 3.5.3 bullet 2C: I think this paragraph is not specified 
enough on what to do. In all other cases one always determines what to 
do next. Here one simple says that it will not be sent. I think there 
are two ways forward:
A) As currently specify that one does not send and then included which 
variables that needs to be updated so that a new scheduling calculation 
is performed. Otherwise the RTCP sending simple stops here.
B) Specify that one shall in this case schedule the next regular packet 
for t_rr_last+T_rr_current_interval. As this is a random value, it meats 
the criteria for a value possible to schedule.

16. Section 4: The SDP attribute: I have problems with the current 
definitions of the values. I don't understand why the payload specific 
FB messages must be signaled in either ack or nack. What if you do not 
want to use generic NACK or ACK and only a payload format specific type 
like RPSI. Wouldn't it be better to create this as a flat structure. 
Having a attribute definition like the following one:

rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
   
   rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
                      / fmt   ; as defined in SDP spec
   
   rtcp-fb-val        = "ack"
                      / "nack"
                      / "app" [SP byte-string]
                      / "rpsi"
                      / "sli"
                      / "pli"
                      / "trr-int" SP 1*DIGIT
                      / rtcp-fb-id [SP byte-string]
   
   rtcp-fb-id         = 1*(alpha-numeric | "-" | "_")
   


I can accept the choice to only have one parameter per attribute line. 
The gain is of course that extension types are easier to write and parse.

17. Section 5. bullet for AVPF receivers. Similar to the note in AVP 
enties that AVP receivers may timeout AVPF sources that run with 
T_rr_interval larger than 5 seconds, a problem for AVPF exist.  A AVPF 
receiver setting T_rr_interval smaller than 5 seconds may actually time 
out AVP entities. So unless only AVPF senders are present T_rr_interval 
SHOULD NOT be set smaller than 5 seconds.


18. Section 6.3.3.2 Native RPSI bit string: Shouldn't it be good to put 
some references here to codes that has RPSI and have RTP payload formats?

19. Section 8, Second paragraph: "Group members of the
   associated RTP session (possibly pretending to represent a large
   number of entities) may disturb the operation of RTCP by sending
   large numbers of RTCP packets thereby reducing the RTCP bandwidth
   available for Regular RTCP reporting as well as for Early FB
   messages."

This section covers one case. When a attacker sends with different SSRC 
every time to make the number of participants large. There is another 
case that effect RTCP reporting interval that might also be mentioned. 
May however not be as potent. This is to send very large RTCP packets. 
This increase the avg_rtcp_size variable and also results in lower 
reporting interval.

20. Section 9: The registration of Application Layer Feedback claims 
that it will use value "1" instead of "15" which the earlier tables 
indicate.


-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



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