Subject: [AVT] RTCP Feedback Summary

From: Joerg Ott <[email-masked]>
Date: Tue, 11 Dec 2001 19:16:51 +0100

The AVP Profile for RTCP Feedback will be discussed in the
Wednesday morning slot of AVT. The current revision of the
document is: draft-ietf-avt-rtcp-feedback-01.txt

Changes from revision -00 include:

- More focused introduction (less video-specifics)
- Revised security considerations section (still needs some
  work)
- editorial changes
- numerous investigations on the randomization interval
  - even vs. exponential distribution
  - dependency on group size
  - robustness regarding group size estimates, packet loss
    distribution

We have also carried out a number of simulations some of
which are described in a companion document:
draft-burmeister-avt-rtcp-feedback-sim-00.txt

We have also done two independent implementations of the
feedback draft and carried out testing in point-to-point
as well as multicast scenarios using mixtures of both
implementations and tools that do not support AVPF.

There is one issue we would like to discuss:

In AVPF, RTCP feedback messages are suppressed if they
have the same contents.  This is trivial if we talk about
those packets defined in the AVPF draft since everyone
supporting AVPF is required to understand them.  However,
there may be application-specific messages to be conveyed
or future extensions made to AVPF with the result that not
everyone necessarily understands each message.

Now let's assume that a receiver R observes an event E0 to
report at time t0.  R calculates its delay interval for the
feedback for te.  Before te is reached, R receives a feedback
packet from another receiver S the contents of which it
does not understand.

In this case, should R suppress its own feedback, send its
own feedback, or use additional information to decide on
whether or not to send?

We consider that just suppressing the feedback is bad because
the feedback packet may -- due to the dithering -- be related
to an entirely different event E1 from time t1 (earlier or later
than t0).  So, no correlation can be established and hence
suppression should not be applied.

The draft currently proposes an additional RTCP packet to be
included along with application-specific feedback to indicate
the event to which this report refers.  This approach has the
merit that a receiver can at least tell whether or not the same
event is concerned (and, if so, R should suppress its feedback).

On the downside, if R does not understand what is stated, suppression
may still be the wrong approach.  And the Generic INFO method
introduced is unnecessarily verbose (16 bytes overhead) which reduces
the potentially scarce RTCP feedback bandwidth.  This latter issue
could be easily remedied by prepending the 4 bytes of event information
that make up the FCI part of the Generic INFO packet to each and
every PSFB packet.  Still, the issue of remains whether or not
a receiver can base meaningful suppression decision on this
information.

This gets us to the last alternative which has become more and
attractive: not doing any suppression at all if a packet is not
understood.  The rationale for this approach is that, in a given
application scenario, the number of new/unknown messages for a
certain media type is going to be limited.  If we have, say, three
new packets, we can classify the receivers into groups according
to which messages they support.  Suppression will, statistically,
work within each group since those members understand each others
feedback messages.  Across groups, suppression will not work so that
the number of duplicates received by the sender roughly increases
with the number of receiver groups that can be created in this fashion.
We would not consider this a major issue.

Hence, the current proposal is to remove the Generic INFO message from
the spec and follow the last alternative.  If deemed valuable by the
AVT group, we would consider include event information as fixed four
byte prefix into each PSFB packet.

Apart from this, we consider the specification to be done and would
like to finish it at this IETF.

Cheers,
Joerg

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