Subject: [AVT] Draft-ietf-avt-rtcp-feedback-00.txt - Format questions

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Jul 2001 13:52:39 +0200

Hi,

This letter will comment on RTCP timing rules and feedback formats.

3.5  (page 11)
        Otherwise, when te is reached, R MUST transmit the RTCP packet
         containing the FB message.  R then MUST set allow_early :=
FALSE
         and MUST recalculate tn := tp + 2*T_rr.  As soon as R sends its

         next regularly scheduled RTCP RR (at the new tn), it MUST set
         allow_early := TRUE again.

What does the resetting of tn mean? Is that you after sending a early
packet do a normal recalculation of when the next packet should be sent
and then increase it with 2 times the largest RTT in the session? This
is my guess on what is reasonable to do, but it is not the only
interpretation I could give. Anyway, this paragraph must be clearer on
what to do with the RTP variables.

3 paragraphs later:
      The E bit in the message header is used upon reception to detect
      whether this RTCP feedback message was sent as Early RTCP or not.
      Hence, a feedback message that is sent as an Immediate or Early
RTCP
      packet MUST set the E bit in the message header to "1".  Feedback
      messages piggy-backed on regularly scheduled RTCP packets MUST set

      the E bit to "0".  If a receiver R receives an Early RTCP packet
      (E=1), then it MAY set allow_early := TRUE.

I wonder over the last sentence. Is there something wrong in this
sentences, to me it seems like it could allow one to send rather many
early RTCP packets during a normal RTCP interval. As long as at least
two receivers a bounces early feedback messages back and forward they
can keep on doing it.

4.1 - FCI definition: Should it not clearly state that this part must
always be 32 bit aligned.

The use of the payload specific headers FMT field. The current solution
only has 11 code points left. What happens when we have used them up?
Maybe another mechanism for identifying payload format specific feedback
formats should be found.

4.3.3.2 RPSI format. Is it not very unwise to change the definition of
the RTCP packet header length field from "32 bit words -1" to "bits"?
This will make it impossible for receiver not knowing this format to
skip to the next header correctly. It will also result in that at least
my and perhaps many more RTP stacks RTCP packet verification will drop
this entire packet as non RTCP.

4.4 Last paragraph. Contradicts the first paragraph in the section.

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems 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]
http://www.ietf.org/mailman/listinfo/avt

---

From: Carsten Burmeister <[email-masked]>
Date: Fri, 20 Jul 2001 02:37:57 +0200

Hi Magnus and all,

thanks for your fast comments. I think about them at the moment, but can
give you a short answer to some points now.

> what to do with the RTP variables.

First, the interval T_rr is the time between two regularly scheduled
receiver reports, as the receiver calculated using the function
rtcp_interval from the RTP specification, but omitting the 5s minimum
interval.

If an early packet is sent at time te, where tp < te < tn, it increases its
RTCP bit rate share, because it sends feedback earlier than it should have
done according to the interval calculation. In order to stick to the RTCP
bit rate share on the long term, it has to delay the next RR. So instead of
scheduling the next RR at tn = te + T_rr, which would be straight forward,
but wrong, it schedules it to tn = tp + 2*T_rr. This would have been the
scheduled time for that RR anyway, if no early packet, but a regularly one
had been sent in between.

> two receivers a bounces early feedback messages back and forward they

This must have been an editorial mistake. The last part of the paragraph
should have been deleted. Jörg discovered the problem of two receivers
bouncing feedback messages back and forward quite long ago. We came to the
conclusion that it should simply be deleted.

BR,
  Carsten