Subject: [AVT] Comments on draft-ietf-avt-rtcpssm-11

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Mar 2006 13:46:00 +0100

Hi,

I have reviewed the draft and have some comments.

1. Section 6.2, second paragraph: Should this paragraph introduce 
explicit exceptions for what the distribution source deems to be 
malicous RTCP messages?

2. Section 6.2 and 6.4: The source address of the reflected RTCP 
packets. I think there is need for some special behavior here. If I 
understand SSM right, the source IP address will need to be that of the 
DS. However that will result in that any RTCP receiver stack that uses 
the the IP address to detect a SSRC collision with its own reflected 
RTCP packets. So I think there is needed a clarification on that this 
will happen and that the collision detection can only be done based on 
CNAME.

3. Section 6.4, first paragraph:
"Each receiver MUST calculate its share of the
    control bandwidth R/n, based on the standard rule that a fraction of
    the RTCP bandwidth, R, allocated to receivers is divided equally
    between the number of unique receiver SSRCs in the session, n."

Two things here. First of all I think "standard rule" should be replaced 
by the "in accordance with the profile in use".

Secondly the R/n is not part of Td calculation formula in RFC 3550. I 
think one need to explain the mapping as it in fact replaces several 
variables.

4. Section 7, third paragraph:
   "From an RTP perspective, the Distribution Source acts like an RTP
    receiver, generating its own Receiver Reports and sending them to
    the receiver group and to the Media Senders.  However, the
    Distribution Source is not counted in the receiver bandwidth
    allocation, as it summarizes information provided by the other
    receivers."

I think this definition is confusing. Who should not count the 
distribution source in the calculation? If it is the receivers I don't 
see the need. And if it is the DS itself, then I think we should clarify 
how it should calculate the rate so that it is easy to fulfill the next 
sentence:

    Nevertheless, the Distribution Source's transmission
    rate MUST adhere to RTCP bandwidth limitations for receivers.  In
    the Distribution Source Feedback Summary Model, an RSI report block
    MUST be appended to all RRs the Distribution Source generates.

As I see it the DS will have the allowance to use up to all the 
receivers it summarize bandwidth allocation. However it must take into 
account the media senders and their share. Thus it and the media sender 
would need to consider the R/(R+S) and S/(S+R) bit-rates for RTCP to 
determine things.

5. Section 7, the Note: I think the motivation why there is better to 
keep the SSRC of the media sending part separate from the one used for 
summary is weak. I think one should probably explain that it provides a 
more consistent behavior and also allow the distribution of bandwidth 
between sender and receiver to be used in a more optimized way. For 
example, small media sender SRs sent often for synch and larger summary 
packets from the receiver part.

6. Section 7.1.1: Figure contains CSRC which it can't be.

7. Section 7.1.1: Please remove "optional" from the "optional report 
blocks" as all block aren't optional and there will always be some block 
here I don't think the use of optional is correct.

8. Section 7.1.1: I think that the RSI format is missing a SSRC field. 
It lacks a field that indicate which SSRC the reports summarized is for. 
As RTCP RRs received are in relation to a specific media sender that 
semantic needs to be kept in the RSI format.

9. Section 7.1.1: The clock used in the RSI format should have a note 
that explains that it is not necessary NTP synchronized, and only need 
to provide a consistent behavior in the advancement of time. The same 
way that the NTP time values in SRs are.

10. Section 7.1.3:
   "Interpretation of the minimum, maximum, and distribution values in
    the sub-report block is profile-specific and is addressed
    individually in the sections below."

Isn't "profile-specific" in the above the wrong word? When profiles is 
mentioned I think of RTP profiles, which doesn't seem to be the profiles 
indicated here. Should it be "block-specific"?

11. Section 7.1.4: I think the Loss sub-report block is missing a 
clarifying limit on the NDB values. Buckets that are smaller than 1/256 
in width are useless as they would need to be empty if they not include 
a particular x/256 sampling (0<=x<=255) bin.

In general I think it might be worth explaining if the bucket ranges for 
discreet values only is used to determine if a particular discreet value 
bin falls within the bucket or not, rather than being equally 
distributed over the range the discreet sample value represent.

12. Section 7.1.5:
"Jitter values are measured in timestamp units and expressed as
    unsigned integers."

I think should be changed to:

"Jitter values are measured in timestamp units with the rate used by the 
media source reported on and expressed as unsigned integers."

13. Section 7.1.10: The generalized information include the median 
inter-arrival jitter. Isn't maybe the 5 or 10% percentile be of more 
equal interest?

14. Section 7.1.11: RTCP Bandwidth: Is the bit-rate definition the 
correct one? The smallest value that one can hand out will be 1/64 = 
0.01525 bits/second per receiver. That means that 3.2 million receivers 
generate 50kbits/second of feedback traffic. The largest value of 65535 
kbit/s seems sufficient. I think this okay, but can be worth lifting for 
further consideration?

15. Section 7.1.12: Is there any point in used both explicit bandwidth 
and session size in the same RSI packets. With the precedence rules I 
don't see a big problem. However what was the intention. Switch over and 
allow people to populate their stacks with correct values? If that is 
the case It might be worth indicating that intention better.

16. Section 7.2, page 23, second paragraph: I think this paragraph 
should be present in the RSI sub-report blocks definitions and possibly 
in the receiver behavior, rather than here.

17. Section 7.2.1, page 25:
"The timer T_summary MUST be initialized as T_summary = 1.5*Td,
         where Td is the reporting interval, and MUST be updated
         following timer reconsideration whenever the group size or the
         average RTCP size ("avg_rtcp_size") changes."

I think one should insert "deterministic" before reporting interval.

18. Section 7.3, third paragraph: Contains the normative word "MUT".

19. Section 7.4:
"The receiver SHOULD do so immediately after noticing and
    before sending any (further) RTCP feedback messages."

What are the exceptions when you can ignore the SHOULD? If there are no 
known exceptions, why not a SHALL or MUST?

20. Section 7.5:
"Media Senders listen on a unicast or multicast transport address for
    RTCP reports sent by the receivers (and forwarded by the
    Distribution Source) or other Media Senders (optionally forwarded by
    the Distribution Source)."

Why is it optional for the DS to forward the other media senders RTCP? 
If you don't they are not sharing the RTCP sender bw correctly.

21. Section 9.1:
"A receiver uses these values as input to the calculation of the
    deterministic calculated interval as per [1] and [10]."

I don't think this is clear as there is different naming etc on the values.

22. Section 9.2:
"Therefore, the Distribution Source SHOULD use
    the full RTCP bandwidth for its receiver reports and associated RTCP
    packets, as well as RTCP RSI packets."

What is the definition of "full RTCP bandwidth"?

23. Section 9.4: Please include SAVPF in the list of profiles to follow 
the defined operation procedures.

24. Section 10.1:
"rtcp-unicast:rsi [<processing>:<rtcp-type>]*"

What is the "*" in the above?

25. Section 10.1:
att-value  = "reflection"
               / "rsi" [rsi-rule]
rsi-rule   = processing ":" rtcp-type SP rsi-rule
               / processing ":" rtcp-type

The ABFN is not correct (missing "SP" before [rsi-rule] in att-value 
rule. In addition it doesn't provide references to SP, token and DIGIT. 
However I also wonder if using recursion in the definition is really the 
right choice. I would have written this as:

att-value  = "reflection" / ("rsi" *(SP rsi-rule))
rsi-rule   = processing ":" rtcp-type

Which I think is simpler.

26. Section 10.2, fourth paragraph. IS the a= rtcp address an 
alternative or an address that override the one specified with 
a=source-filter and RTP port derivation?

27. Section 11.3, b) bullet, second paragraph: Is not this paragraph in 
the wrong place. The symptom of a security problem arises here but are 
caused by something in the sender to receiver path?

28. Section 11.6.1: IPsec is wrongly capitalized.

29. Section 11.6.1: I am missing a lot of refernces in this section. As 
this provide recommendation on what to implement I find it important 
that one are certain what is being described by using references.

30. Section 14.2, there is an extra line between reference 15 and 16.

31. Section 15.2, first paragraph: I don't think the use of SSM to reach 
the distribution node is out of the picture. What I understand one could 
basically cascade SSM sessions with unicast feedback.

32. Section 16.1 and 16.2: I don't think this algorithm is particular 
clear. In fact I don't understand it. I think I know what the intention 
is but the description is not clear.

33. Section 16.4, page 52:
"The maximum value would therefore be 5 - 7.5 which is 5970."

I think this sentence is unclear. In addition loss values with ranges 
that are not integer values are meaning less. Thus I would propose to 
write the sentence as:

"The largest bucket value would in this case be the bucket for X values 
5 - 7, which sum is 5970."

34. Page 53, In the result table, the ranges in the third column ends 
with range 27.5-20 instead of the 30 it should be.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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