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

From: [email-masked]
Date: Tue, 9 Jul 2002 14:24:57 -0500

Joerg,

Here are some other comments on your draft (some of them may be misuderstandings):

*Introduction of T_rr_interval seems a major change to the older timing rules. In the AV profile and previous versions of the feedback profiles, the RTCP bandwidth is constant during the session. In this new version of the profile, the RTCP bandwidth is variable, i.e. you can actually choose your parameters in such a way that very few RTCP packets may be sent during some time intervals and many packets are sent during some other time intervals. 
In particular, the text on page 9 "This is to ensure that the short term average bandwidth used for  RTCP with feedback does not exceed the bandwidth limit that would  be used without feedback" is not true anymore. 
The draft on the timing rules simulations looks outdated to me. Is it planned to update it with the new timing rules?
    
*The word 'message' and 'packet' are used interchangeably throughout the text. I think you should stick to 'feedback packet' throughout the text.

*As there are many variables, you could consider choosing some more 'systematic' names to help the reader, e.g. why is T_dither_max not abbreviated and T_fd abbreviated.  

*In page 13, if you end up in condition 2.a) it seems that you forget to check whether the feedback is still useful and if the same feedback packet has been sent by another receiver before sending the feedback as part of the scheduled packet.

*In page 14, where does the interval [t0-1s;te] come from?

*In Section 3.2 what does "the cost required to achieve mediam stream repair" actually mean?

Thanks for clarifying these points, David.
 
> 
> Hi Magnus,
> 
> thanks a lot for the input.
> 
> > 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.
> 
> 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 :-)
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> This is correct.
> 
> > 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.
> 
> 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).
> 
> > 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?
> 
> 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
> > T_min is set to 1.0 initially.
> 
> I'll be happy to put one in.
> 
> > 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.
> 
> Yes.  Good catch.
> 
> > 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.
> 
> 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.
> 
> > 
> > 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.
> 
> 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.
> 
> > 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.
> 
> Good point.  I will fix this.
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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.
> 
> > Section 6.2 Application Message (FCI). The message must be 32 bit
> > aligned no only octet aligned.
> 
> Fixed.
> 
> Thanks a lot for your comments!
> 
> Cheers,
> Joerg
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

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

---

From: Joerg Ott <[email-masked]>
Date: Tue, 16 Jul 2002 10:33:26 +0200

David,

thanks for your comments.  My responses inline.

> The draft on the timing rules simulations looks outdated to me. Is it planned to update it with the new timing rules?

The statement still holds.  The way in which the T_rr_interval is
defined and used will only lead to a reduction of regular RTCP
traffic frequency (and thus bandwidth).  It will not affect the
scheduling of Early FB packets at all.  Hence the simulations
in principle still hold.  But we have done further simulations
to make sure that the stuff still is ok.

> *The word 'message' and 'packet' are used interchangeably throughout the text. I think you should stick to 'feedback packet' throughout the text.

I have tried to make consistent use of those terms.  But I'll take up
the action item to go through the document again and make that they
are really used consistently in all places.  (I made a difference
between "message" and "packet" though.)

> *As there are many variables, you could consider choosing some more 'systematic' names to help the reader, e.g. why is T_dither_max not abbreviated and T_fd abbreviated.

This is more or less the attempt to find some meaningful names 
and not to confuse everybody.  Maybe I can do something here.

> *In page 13, if you end up in condition 2.a) it seems that you forget to check whether the feedback is still useful and if the same feedback packet has been sent by another receiver before sending…

This case is covered implicitly.  If you have a scheduled packet
already containing feedback, then you are obviously closer to
the point in time than you were last time.  Hence timing cannot
be an issue.

> *In page 14, where does the interval [t0-1s;te] come from?

From the fact that you may have received feedback packets from
others *before* you noticed the event -- different propagation
times may make this happen.  So you should just remember the last
packets you received.  I just noticed this during this revision.
The value of 1s is, admittedly, somewhat arbitrary but should
work in most cases.

> *In Section 3.2 what does "the cost required to achieve mediam stream repair" actually mean?

This refers to the extra amount of data to be sent, e.g. in video
depending on how old the last successfully received reference frame
is.  It is deliverately kept vague and generic here.

Thanks,
Joerg