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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 04 Jun 2003 18:32:48 +0200

Hi,

I have a few comments that I think should be addressed before 
publication. I am also sorry for being late with these comments.

1. Page 7: "o OPTIONAL encryption prefix that MUST be present if the 
RTCP    packet(s) is to be encrypted." It believe this sentence to be in 
error, the prefix is only necessary when employing certain encryption 
methods. A corrected sentence could be: "o OPTIONAL encryption prefix 
that MUST be present if the RTCP packet(s) is to be encrypted according 
to section 9.1 of [1]."

2. Page 11: Section 3.4, first paragraph. This section claims that the 
variable in item (g), is not calculated locally. However I don't think 
this is correct. The T_dither_max is calculated locally, based on T_rr.

3. Page 18: Section 3.5.3, Bullet 2c: What should one do at this point 
if no packet is to be scheduled. Clearly sending at this time is shall 
not happened, but what should be done to get a scheduling at a 
reasonable time where tn > t_rr_last + T_rr_current_interval. To my 
understanding if one does nothing at this time the algorithm may 
actually collapse. If T_rr is smaller than 2/3 of the 
T_rr_current_interval one can end up in a state when the rescheduler 
will constantly reschedule the packet and still not produce a T_rr that 
is larger. My immediately reaction to when one ends up in 2c is to set 
"tn" to "t_rr_last + T_rr_current_interval". That way one will send 
according to the minimal interval. Actually suppressing the message and 
treating it as sent does not either work because that may result in that 
no message is sent. Please clarify how one should behave with the 
scheduling algorithm to get it to work correctly.

4. Page 19, Section 3.6.1, first paragraph. A question. The ACK mode is 
it only possible to use in cases where one is in a point to point 
communications scenario. However is it really necessary to require that 
only two participants in this scenario? I the case of SSRC multiplexing 
for RTP retransmission it will not be a different situation even if one 
uses 3 or 4 SSRC in the session.

5. Page 41, Section 6.4, first paragraph. I think there is a unnecessary 
strict MUST here. What I can see the sentence "There MUST be exactly one 
Application Layer FB message contained in the FCI field." could just as 
well be replace with this sentence: "There MUST be only one type of 
Application Layer FB message(s) contained in the FCI field.". If one has 
a application feedback message that is fixed size then one can use 
multiple of these within a single header without any problems.

I hope for quick response on my comments

Best Regards

Magnus Westerlund

Multimedia Technologies, Ericsson Research ERA/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

---

From: Joerg Ott <[email-masked]>
Date: Thu, 05 Jun 2003 14:19:07 +0200

Hi Magnus,

> that MUST be present if the RTCP packet(s) is to be encrypted according 

With additional encryption schemes coming up, this is a valid point.
I have updated the sentence following your proposal.

> this is correct. The T_dither_max is calculated locally, based on T_rr.

Oops, good catch.  Of course, T_dither_max is calculated locally.
The introductory sentence did not get updated properly when the numbering
for the items changed.  Some digging in past versions confirmed that this
was meant to refer to item h) T_max_fb_delay (which is application
specific).

> scheduling algorithm to get it to work correctly.

The basic assumption is that the regular scheduling algorithm will produce
a "new tn" roughly every T_rr (subject to dithering and timer reconsideration).
The algorithm in 3.5.2, item 2) sets in as soon as such a tn is reached
and is just used to determine whether or not to send it.  If the packet
is not scheduled following the rules of 2c), the rules below 2c) 
ensure that tn will be advanced to the next tn (roughly T_rr later).
That is, the T_rr add up until they are larger than T_rr_interval
(note that T_rr_current_interval is calculated newly each time from
the fixed T_rr_interval and thus cannot grow beyond a constant
1.5*T_rr_interval).

Therefore, I don't see any reason for a potential collapse here.
But I will double check. Further input is of course welcome.

> uses 3 or 4 SSRC in the session.

This is an interesting point.  Let me ask a quick counter-question: how
different is this, at the RTP level, from a multicast-unicast translator
scenario? If we want to make this distinction we can probably only use
CNAME bindings to determine the actual number of entities in a session.

Given my past experience, I am a bit hesitant to rely on CNAMEs for
establishing session size (which, to my knowledge, cannot draw on
definitions already present in RTP-new).

> multiple of these within a single header without any problems.

Well, one could argue that the application layer scheme could define
its own substructure and multiplexing format -- along with one major type.

Do you have something specific in mind?  I would like to avoid any further
statement about the nature of the application layer messages.

> I hope for quick response on my comments

I hope that this was quick enough :-)

Joerg

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 05 Jun 2003 15:23:24 +0200

Hi Joerg,

Here is some response to your comments.

Joerg Ott wrote:

>> will constantly reschedule the packet and still not produce a T_rr 
>> that is larger. My immediately reaction to when one ends up in 2c is 
>> to set "tn" to "t_rr_last + T_rr_current_interval". That way one will 
>> send according to the minimal interval. Actually suppressing the 
>> message and treating it as sent does not either work because that may 
>> result in that no message is sent. Please clarify how one should 
>> behave with the scheduling algorithm to get it to work correctly.
> 
> 
> is not scheduled following the rules of 2c), the rules below 2c) ensure 
> that tn will be advanced to the next tn (roughly T_rr later).

Yes, I think what I missed is the second paragraph of 3.5.3 and its 
relation to 2c in the algorithm list. My suggestion would be to clarify 
the actions one has to do when on come to 2c.

First I think one should use the word suppress, as this is what has been 
used on all other places. Then the text should also mention that tn and 
tp, Allow_early shall be updated as if the packet has been sent. It 
should also be made clear that t_rr_last SHALL NOT be updated.

My remaining objection is that the usage of T_rr_interval does not match 
the behaviour that setting T_min for the old algorithm achieved. Setting 
T_rr_interval to 5.0 seconds will not mean that a receiver will send 
messages every 5 seconds on average, given enough bandwidth and no 
feedback messages. This algorithm will instead send messages every N*Td 
 > T_rr_interval, where N is the smallest integer that result in that 
the equality is true, and Td is the deterministic RTCP reporting 
interval produced by the algorithm in the RTP spec. Taking the 
randomization into account one will have the possibility to send a 
regular RTCP packet in the interval 0.5*T_rr_interval to 
1.5*T_rr_interval+1.5*Td. Also I can't  determine what the distribution 
within this interval will become, at least it is not equal probability 
over the whole interval. If this has any ill effects compared to using a 
equal distribution between 0.5*T_rr_interval and 1.5*T_rr_interval I 
don't know.

Have you seen any problems with this in your simulations?

> 
>> 4. Page 19, Section 3.6.1, first paragraph. A question. The ACK mode 
>> is it only possible to use in cases where one is in a point to point 
>> communications scenario. However is it really necessary to require 
>> that only two participants in this scenario? I the case of SSRC 
>> multiplexing for RTP retransmission it will not be a different 
>> situation even if one uses 3 or 4 SSRC in the session.
> 
> 

Yes, you are correct, a client can't determine this reliable. I don't 
have any problem with leaving the restriction in.

>> 5. Page 41, Section 6.4, first paragraph. I think there is a 
>> unnecessary strict MUST here. What I can see the sentence "There MUST 
>> be exactly one Application Layer FB message contained in the FCI 
>> field." could just as well be replace with this sentence: "There MUST 
>> be only one type of Application Layer FB message(s) contained in the 
>> FCI field.". If one has a application feedback message that is fixed 
>> size then one can use multiple of these within a single header without 
>> any problems.
> 
> 

My only issue is that if one would like to create a application layer 
feedback message that can be used in multiples of the same size, for 
example report the same thing for multiple SSRCs, the present sentence 
forbids this. I think this is to restricted, and can be changed to my 
sentence proposal.

Best Regards

Magnus Westerlund

---

From: Joerg Ott <[email-masked]>
Date: Fri, 06 Jun 2003 10:35:01 +0200

Hi Magnus,

some further comments for you inline:

>>> 3. Page 18: Section 3.5.3, Bullet 2c: What should one do at this 
>>> point if no packet is to be scheduled. Clearly sending at this time 
>>> is shall not happened, but what should be done to get a scheduling at 
>>> a reasonable time where tn > t_rr_last + T_rr_current_interval. To my 

I believe the actions are clear.  The paragraph after 2c even explicitly
mentions 2c (and all others).  I do not see any need for additional
wording.

> should also be made clear that t_rr_last SHALL NOT be updated.

I have added the use of "supressed".  I think stating that "t_rr_last MUST
remain unchanged" is pretty unambiguous.  tn and tp as well as allow_early
are dealt with collectively for all four alternatives which I believe is
a feature, is clear, and which I do not want to change (it would just
increase wording).

> interval produced by the algorithm in the RTP spec.

It has never been stated anywhere -- and was explicitly not the intention
-- to enforce T_rr_interval as an "exact" value.  It should just be a lower
bound to limit the amount of RTCP traffic as you requested.  We have had
many  discussions among the authors regarding this issue (about a year
ago or so)  and came to the conclusion that trying to create another fixed
timer will just complicate things (as this timer's clock needs to run
independently of the regular RTCP intervals in order not to reduce the
amount of early feedback that can be sent).

> Taking the 

If you choose to use the T_rr_interval, you are likely to do so because
Td is too short for you, probably much too short (e.g. an order of
magnitude).  This means that 1.5*T_rr_interval will clearly dominate the
above equation.  Even if T_rr_interval == Td, you get 0.5*Td to 3*Td
(wondering whether the latter is really possible).

As I have argued before: if you start introducing T_rr_interval then you
do so to _reduce_ RTCP traffic.  This means in particular that you care
less about frequent feedback which makes RTCP less useful for any kind of
closed loop algorithm.  With RTCP and its dithering interval of
0.5 - 1.5 you won't get equidistant regular feedback anyway, and its
frequency further varies with the number of session members and the RTCP
packet size.

Why is this irregularity bad?  From experimenting, I think we have learned
that the members do not synchronize their RTCP transmissions.  They all
will also transmit them at some point and they will stay below the
calculated RTCP bandwidth.  I don't think we want to ask for more.

> have any problem with leaving the restriction in.

They key question probably is the impact on the retransmission draft.

>>> size then one can use multiple of these within a single header 
>>> without any problems.
>>

> sentence proposal.

How about this:

There MUST be exactly one Application Layer FB message contained in the FCI 
field, unless the Application Layer FB message structure itself allows for
stacking (e.g. by means of a fixed size or explicit length indicator).

Cheers,
Joerg

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Jun 2003 10:37:18 +0200

Hi Joerg,

Responses below:

> mentions 2c (and all others).  I do not see any need for additional

Okay.

> 
>> First I think one should use the word suppress, as this is what has 
>> been used on all other places. Then the text should also mention that 
>> tn and tp, Allow_early shall be updated as if the packet has been 
>> sent. It should also be made clear that t_rr_last SHALL NOT be updated.
> 
> 
> 

Okay.

> 
> 
>> My remaining objection is that the usage of T_rr_interval does not 
>> match the behaviour that setting T_min for the old algorithm achieved. 
>> Setting T_rr_interval to 5.0 seconds will not mean that a receiver 
>> will send messages every 5 seconds on average, given enough bandwidth 
>> and no feedback messages. This algorithm will instead send messages 
>> every N*Td  > T_rr_interval, where N is the smallest integer that 
>> result in that the equality is true, and Td is the deterministic RTCP 
>> reporting interval produced by the algorithm in the RTP spec.
> 
> 
> 
>> Taking the randomization into account one will have the possibility to 
>> send a regular RTCP packet in the interval 0.5*T_rr_interval to 
>> 1.5*T_rr_interval+1.5*Td. Also I can't  determine what the 
>> distribution within this interval will become, at least it is not 
>> equal probability over the whole interval. If this has any ill effects 
>> compared to using a equal distribution between 0.5*T_rr_interval and 
>> 1.5*T_rr_interval I don't know.
> 
> 
> 

Okay, as long as you have considered this I am fine. It is not how I 
would how made it, however it works this way, so lets end the discussion.

> They key question probably is the impact on the retransmission draft.

Yes, when using SSRC multiplexing it is not possible to use the ACK 
mode. I don't know if anyone has a problem with this. I don't think I 
have any problem with this restriction. The RTP retransmission format 
does recommend that one uses NACK.

> 
> 
> 
> How about this:
> 
> There MUST be exactly one Application Layer FB message contained in the 
> FCI field, unless the Application Layer FB message structure itself 
> allows for

sounds good.

Best Regards

Magnus Westerlund

---

From: Joerg Ott <[email-masked]>
Date: Tue, 10 Jun 2003 23:01:44 +0200

Hi Magnus,

thanks for your reply -- looks like we can close it then.  And, again,
thanks a lot for your review in general.

> does recommend that one uses NACK.

Ok, I'll prepare an updated draft (-07) tomorrow and submit it --
unless someone still has issues here.  Please speak up now.

Joerg