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

[Joerg Ott <[e-mail]>]

David,

thanks for your comments.  My responses inline.

> 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 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 the feedback as part of the scheduled packet.

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

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