Subject: [AVT] comments on draft-ietf-avt-rtcp-feedback-01.txt

From: "Even, Roni" <[email-masked]>
Date: Sun, 10 Mar 2002 09:15:37 +0200

Hi,
I had some comments on the draft and I do not feel that they are resolved.
The major one is about the usability of the draft as defined now.

I guess I have a problem with understanding the purpose of the feedback
draft. Introduction states the problem that it want to address as 
"RTP makes no provision for timely feedback that would allow a sender to
repair the media stream immediately: through retransmissions, retro-active
FEC, or media-specific mechanisms such as reference picture selection.". 
I think that the receiver when encountering a problem needs to know what
will happen in the case when he sends such a report otherwise he will prefer
to use a signalling mechanism like H.245 and we will need to define a
similar signalling for SIP. This would mean that there is no need for this
draft proposal. The requirement in video is for all feedback indication or
commands is to cause a specific behavior since they are part of a defined
process. for example video MB not decodes are there to inform the encoder
not to use those MB for prediction, Lost picture indication is used to
inform the encoder to use correction according to annex U or annex W.6.3.12
if supported. I am not arguing the concept but I argue that as an
implementer I will not understand as an encoder what is the right way or as
a decoder what will happen when I send the message and will want to use more
specific feedback messages. 
Regards
Roni  Even

**********************************************
Roni Even
VP Product Planning
Polycom Network Systems
Tel: +972-3-9251200
Mobile: +972-55-481099
Fax: +972-3-9211571
Email: [email-masked]

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

---

From: Joerg Ott <[email-masked]>
Date: Mon, 11 Mar 2002 20:52:43 +0100

Hi Roni,

> I had some comments on the draft and I do not feel that they are resolved.

this observation is correct; I think we included some of the comments
as good as possible within the given scope but could not resolve some
others.  Apparently, the changes were not as good as I had hoped.
Let's see that we work this out.

> draft proposal.

RTCP feedback addresses the issue of timely feedback within the bounds
of RTCP bandwidth constraints.  The mechanisms are intertwined with
RTCP because they fit well into the model of reception statistics
reporting, but are just a bit more urgent.  Defining a similar
mechanisms over TCP is not ncessarily an alternative solution because
you get head-of-line blocking in case of packet loss -- which
unnecessarily delays all of the feedback.  So, in the general case,
H.245 is not exactly a perfect alternative.  But maybe let's not get
into this.

> The requirement in video is for all feedback indication or

Agreed.  But this is to be stated by the respective video coding
standard in use.  Tomorrow's H.26L++ may exhibit a different behavior
if the sender receives a report for a missing macroblock.  What is
important is that the receiver conveys the information what is wrong;
the receiver can expect the sender to perform some repair function,
but the sender may have different alternatives at its discretion.
This is particularly true if we are in a multicast environment and
the sender needs to repair several streams at once.  The receiver
may indicate a lost macroblock but may get an I-frame.

So, at the service level, I completely agree.  Feedback should lead
to media stream repair.  The question is how much detail we need to
specify at the protocol level.

This document defines a general feedback mechanism that allows for
more timely feedback reporting.  A number of video packet formats
happen to be defined since video was the primary motivation.
But it is up to the video coding standard to suggest ways to repair
a broken media stream, and it is up to the application to make use
of this suggestion or not -- taking into account the total feedback
received as well as on the perceived congestion within the network.

> specific feedback messages.

If you think that further guidance is needed for the specific video
feedback messages we have included I'll be happy to take further
suggestions on the text to make the intention clear.  All I would
like to avoid is replicating information from a video coding
standard.  And please note that the mandatory congestion
considerations do not allow us to state something like "if you
receive X you MUST send an I-frame or a macroblock in intra-mode".

Thanks for the comments, we'll sort this out.

Joerg