Subject: [AVT] Comments on draft-ietf-avt-rtcp-feedback-03.txt

From: Magnus Westerlund <[email-masked]>
Date: Thu, 04 Jul 2002 16:32:17 +0200

Hi,

I have a number of comments on the RTCP feedback draft:

Section 3.4, The explanation about T_dither_max is not clear on the fact 
that if working in unicast the variable should be set to 0. I especially 
reacted to the ".. MUST delay ..." that is written in the second 
paragraph on page 11.

Section 3.5.2: Bullet 2. What is meant by checking if a packet waiting 
for transmission? My interpretation of this section is that if you have 
a outgoing packet attach the feedback to that packet. However this 
sentence seems redundant and out of place. The other bullets all specify 
the cases when you should piggyback your feedback to other packets. 
Therefore I would recommend that the text about checking is removed or 
at least moved to before the algorithm specification.

Section 3.4 and 3.5: I think the definition and usage of T_rr_interval 
results in making the algorithm more complex. To my understanding of 
T_rr_interval will be exactly the same as T_min when no early packets 
are scheduled. The case when the old algorithm will be used but with 
T_min = 0 is when to calculate the point to set Allow_Early to true. I 
would therefore like the authors to consider if the definition of the 
algorithm would be easier if the T_min would be simply set to 0 or a 
given value.

Section 3.5.1: Is the motivation for setting T_min initial to 1 second 
that the receiver should have some time for receiving RTCP messages and 
sampling the group size? Anyway I am lacking an explanation for why 
T_min is set to 1.0 initially.

Section 3.5.3: In third paragraph on page 16:
       "If t_rr_last + T_rr_interval > tn and RTCP feedback messages
        have been stored and are awaiting transmission, an RTCP packet
        MUST be scheduled."
 The RTCP packet MUST be scheduled but to when? I would guess that it 
should be scheduled to tn but that is not explicit.

Section 3.5.4: Fourth paragraph on page 16:
       "Otherwise (if t_rr_last + T_rr_interval > tn but no stored
        RTCP feedback messages are awaiting transmission), no compound
        RTCP packet MUST be scheduled."
My question is what should be done. Should the parameters be updated as 
the packet has been sent or should tn be set to t_rr_last+T_rr_interval? 
This page is one of the reason I think setting T_min = T_rr_interval and 
instead give the exceptions when other values and methods in the 
calculation of "tn" would  be simpler  to used.

Section 4.2 The SDP attributes:
I think using "a=fmtp" for this is wrong. The fmtp attribute is intended 
for parameters that are connected to the format. For many payload format 
the a=fmtp attribute is used for controlling the payload format and 
codec. Having multiple usage of fmtp seems bad. RTCP feedback are also 
not all connected to a specific format, but rather attributes for the 
whole RTP session. Due to this I would argue that a new attribute for 
RTCP feedback parameters should be created. My proposal is:

rtcp-fb-syntax= "a=rtcp-fb:" format-spec SP rtcp-fb-val *(";" rtcp-fb-val)
foramt-spec = <format> | "all"

Both the transport and application specific feedback and also setting 
T_rr_interval is independent of the payload format. To be able to 
specify parameters for the whole session I like to have a "all" format 
attribute. I would also think that there is an advantage to be able to 
specify multiple feedback formats that may occur. For example a session 
with video may very well use both NACK and SLI.

Section 5. AVP entities second paragraph.
As you state there exist a possibility that to large T_rr_interval may 
result in timing out AVPF participants unnecessary. However I would not 
write should not use T_rr_interval at all. I would rather write a should 
that T_rr_interval in cases with mixed participants should not be bigger 
than 5 seconds. If it is 5 seconds no difference in timeout will exist.

Section 6.1 Header format.
Why is bit 3 of the first line set to 0? I can't see a reason for 
statically set a bit when it instead can be used in the FMT field and 
give that 5 bits and 32 code points. This will allow for more formats 
before exhaustion of the number field.

Section 6.1 FCI definition.
I can't understand why only a single FCI is allowed per packet header. 
As long as the FCI has a fixed length the number of FCIs can be resolved 
with the length field. I would strongly recommend that this is changed 
to allow multiple FCI as long as they has a fixed length. This will 
allow ACK and NACK feedback with much less overhead. For large groups or 
sessions with many packets during each report interval there will exist 
need for having multiple ACK or NACK specifiers. Allowing for several 
will save a 12 byte overhead for each extra specifier.

Section 6.2 Application Message (FCI). The message must be 32 bit 
aligned no only octet aligned.

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: Fri, 05 Jul 2002 17:25:16 +0200

Hi Magnus,

thanks a lot for the input.

> reacted to the ".. MUST delay ..." that is written in the second

I have added some clarifying text in both the definition and the para on
page 11.  You are right that it is probably safer to make things explicit
(However, I think an even random distribution out of an interval [0;0]
will always yield zero :-)

> at least moved to before the algorithm specification.

I am not entirely getting it.  2. specifies the "IF-clause" for the
following two alternatives; it serves as introduction for the indented
parts 2a and 2b.  I cannot just remove the text in 2. since 2. would
then become empty and the "If so" in 2a would have nothing to refer to.
Plus, this is part of the algorithm.

If have another minor issue to fix though.

> are scheduled.

This is correct.

> The case when the old algorithm will be used but with

T_min = 0 is already used for this purpose.  But we need two different
values here.  One to determine how ofter to send regular packets and one
to determine the maximum frequency of early feedback packets.  We tried
to use two different terms for the different meanings rather than
overloading one.

However, I am not entirely happy either with the amount of additional
spec text need to incorporate the WGLC comment idea on the minimum
interval.  We are open to any suggestions to simplify the text
(and will of course look into this before the hopefully final draft
submission of -04).

> sampling the group size?

Yes.  BTW: RTP uses 2.5 seconds initially, but we figured for feedback
purposes this might just be too long.  If there is strong disagreement
with this decision, please speak up.

> Anyway I am lacking an explanation for why

I'll be happy to put one in.

> should be scheduled to tn but that is not explicit.

Yes.  Good catch.

> calculation of "tn" would  be simpler  to used.

The paragraph following the four indented ones refers to an action for all
the ones above: i.e. ou proceed as if you had sent the RTCP packet, you
just don't do the actual transmission.  This is closest to the original
algorithm -- and I figure was a pretty good exception.  We actually wrote
down source code to do exactly this handling.

> with video may very well use both NACK and SLI.

In principle, I agree.  We have had this discussion once which
motivated exactly the opposite decision a while back.  I think it
pretty much depends on your view of the scope for fmtp.  I do not
care too much what is used, but payload-specific stuff (which may
need to be negotiated on a per payload basis using offer/answer)
should go into the fmtp attributes.  I am afraid that introducing
yet another structure is going to make negotiation worse.

It might be the cleanest way to distinguish between general and codec-
specific parameters and put the general ones in as you suggest above
(we actually used a similar format in the first revisions of the
draft).  But I feel a bit reluctant to allow for both.

> than 5 seconds. If it is 5 seconds no difference in timeout will exist.

Good point.  I will fix this.

> before exhaustion of the number field.

This bit was previously used as the 'E' bit to mark an packet that
has been sent as early feedback packet.  Since the algorithm changed,
this was no longer needed -- but never reclaimed (for future extensions).
I have updated the -04 version accordingly.

> will save a 12 byte overhead for each extra specifier.

We have had this comment multiple times.  It was introduced when moving
from -00 to the -01 spec because we encountered that the text was
ambigous before.  We can allow multiple FCIs of the same type (which I
will put in); of course, they cannot be mixed.

> aligned no only octet aligned.

Fixed.

Thanks a lot for your comments!

Cheers,
Joerg

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Jul 2002 16:49:55 +0200

Hi Joerg,

See comments inline.

>will always yield zero :-)

Good.

>If have another minor issue to fix though.

I don't understand how you reasonably can check if a packet is awaiting 
transmission. This seems implementation dependent. In my RTCP 
implementation the packet is not created until the scheduled time of 
transmission. It will of course take some small time to form and 
transmit it but this I regard as zero time and with that assumption I 
can't hold the packet to include a extra feedback packet. Seen from 
another point the next packet is always scheduled to be transmitted. Due 
to this the comparison in the first sentence does not make sense. I do 
believe it requires a time limit to make the comparison sane, i.e. "R 
first checks whether there is a compound RTCP packet scheduled or awaits 
transmission within time X from t0."

>(and will of course look into this before the hopefully final draft

Okay, removing the name may be a bad idea but it should be used in a 
more cleaver way. Perhaps defining a simple algorithm which defines 
which of the values should be used based on conditions in the 
calculation of T.
As example:

If a normal compound packet and is to be sent calculate T using on 
T_rr_interval instead of T_min. Of course it must be clarified that T_rr 
is calculated using T_min and as soon as any feedback RTCP packets is to 
be added to the compound packet T_min should also be used.

By rewriting the algorithm around this as one of the basic assumption I 
do believe a smaller and more clear definition of the algorithm can be 
achieved.

>with this decision, please speak up.

I don't see a big problem. It could result in overusing the bandwidth 
when many joins the group simultaneously which would be slightly more 
than with T_min = 2.5 seconds. I was actually thinking of an exception 
when it is known that it will only be two members in the session. The 
initial value of T_min should actually be set to 3 T calculated with 
T_min = 0 (2 T calculated for members =1 will be the same as 1 T for 
members=2 times the randomization max of 1.5 => 3T). In that case there 
is no possibility for unicast conditions that the bandwidth is over used.

>down source code to do exactly this handling.

I see. Doesn't that algorithm have the effect that the more 
possibilities to send a packet for each T_rr_interval the closer to 
every T_rr_interval will the packets be sent, i.e. the randomization of 
inter packet distances will be less. This may result in timer 
synchronization. Using T_rr_interval in the calculation of T will 
maintain the inter packet interval to normal RTCP values.

>draft).  But I feel a bit reluctant to allow for both.
I for a moment thought that there would be backwards compatibility 
problems here but as media line using the AVPF would not be interpreted 
by receivers not knowing about the fmtp attribute rtcp-fb it is no 
problem. I do believe using a special attribute is better. It will 
remove the need for any parser to check within the fmtp attribute to 
distinguish if a line should be sent to initialization of RTCP feedback 
or to the payload packetizier media codec. Using the same attribute for 
both general parameter and format specific has advantages by keeping it 
consistent and at the same time simple to combine format specific and 
general in media blocks.

I can't find any old AVT message discussing the use of  fmtp. I would be 
interested in pointers or a summary of the arguments.

I think my proposal above is a good one and can be exemplified below 
with multiple codecs having different potentials of using feedback. In 
the example it may not save any lines but there are examples which will. 
I also see an advantage of not having two fmtp lines for the same format 
which has different parts of the system as target.

m=video 51372 RTP/AVPF 34 99
c=IN IP4 224.2.1.184
a=rtpmap:99 MP4V-ES/90000
a=fmtp:99 profile-level-id=8; config=01010000012000884006682C2090A21F
a=rtcp-fb:all nack trr-int 1000
a=rtcp-fb:99 rpsi sli

>will put in); of course, they cannot be mixed.
That would be good.

Cheers

Magnus Westerlund