Subject: [AVT] Comments on draft-ietf-avt-rtcp-feedback-02

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Mar 2002 21:10:05 +0100

Hi

I have the following comments on the RTCP feedback draft, starting with
the bigger issues:

1. Section 2. Says that the minimal reporting interval is completely
removed. Could it not be good to be able to specify your own minimal
interval. This requires a signaling attribute.

2. Section 3.1 top of page 6. The use of the encryption prefix. this
profile MUST use the encryption prefix. I guess it is required to use
MUST to be interoperable. However this is something that needs to be
clarified when specifying the secured AVPF, i.e. the combination of SRTP
and AVPF.

3. Section 3.5 Page 12,
  "Then, R MUST check whether its next regularly scheduled RTCP packet
   is within the time bounds for the RTCP FB (t0 + T_dither_max > tn).
   If so, an Early RTCP packet MUST NOT be scheduled; instead the FB
   message(s) MUST be stored to be appended to the regular RTCP packet
   scheduled for tn."

The draft must specify how you do reconsideration of the normal sending
time Tn. What happens if you at the time tn do reconsideration and
reschedule the tn to a time that is outside of t0 + T_dither_max?

4. Section 4.2 the SDP signaling. The use of the fmtp attribute seem to
be a bad choice. This attribute is intended for codec/payload format
specific stuff and overloading the attribute with two functionalities is
not good. It is also unnecessary verbose when feedback formats only
related to the whole RTP session and not individual payload formats.
Therefore I would recommend creating signaling that is capable of
expressing if the parameters is for a single payload type or for the
whole session.

5. Section 4.5 example 3. The use of multiple media lines with different
profiles needs to be clarified and how to express alternatives. The
current text is to little.

6. Section 6.1 figure 3. Why having a bit set to zero when it instead
can be used in the FMT field. This will double the available payload
specific types that can be registered in the future.

7. Section 6.2 FMT table, Why is there a "0: forbidden" in the table?
Could this point not be reserved for future use instead?

8. Section 6.2 and 6.3. The FCI defined here is of fixed size and it
would be possible to have multiple ones and use the length field in the
packet header to tell how many that are present. It would of course
require some text specifying what happens if they overlap.

Textual Clarifications / requests for rephrasing

C1. The introduction, some paragraphs are the same as the abstract.
Please rephrase them into something new that makes it less boring to
read.

C2. Section 3.6.1 second paragraph. The text is confusing when it one
sentence mentions 20 events per second which are sent in 2 packets for
64 kbit/s and in the next mentions 8 which are sent individual for a
bandwidth of 256 kbit/s. Please rephrase so the numbers are comparable.

C3. Section 4.2 the signaling BNF needs to be a clearer. As example, the
"app" takes parameters after it but that is not expressed in BNF.

C4. Section 6.1 Length definition. When referring to RTP [3], it
mentions RTCP sender and receiver reports when it is in fact all packet
types defined in RTP.

C5. Section 6.4 FCI for application messages. The application data needs
to be 32 bit aligned not byte aligned.

C6. Section 6.4 If would probably be a good idea to write a paragraph on
what a application message definition should think on. This could
include recommendation to use type field for extensions/multiple type of
messages.

C7. Section 9 The RTPFB and PSFB registries must have rules for what
type of document that is required to add a new code point.

Regards

Magnus Westerlund

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