Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

[Magnus Westerlund <[e-mail]>]

Hi,

See inline. Removed the resolved bullets.

On 2011-09-10 12:29, Qin Wu wrote:
> Hi, Magnus, Thank for your comments, a quick reply below. -----
> Original Message ----- From: "Magnus Westerlund"
> <[e-mail]> To: <[e-mail]> Cc:
> <[e-mail]> Sent:
> Friday, September 09, 2011 7:25 PM Subject: Re: [AVTCORE] Comments on
> draft-ietf-avtcore-feedback-supression-rtp-06.txt
> 

> 3. Section 6.2:
> 
> First of all the figure 3 doesn't make it clear that there are N RTP 
> receivers to the right in the figure.
> 
> [Qin]:True, Does it make sense to remove it? If not, will redraw it.

I think the question is how much the text needs the support of the
figure to explain the context.

> 
> 4. Section 6.2: "If the BRS impacted by packet loss has been told the
> actual packet loss, the BRS MAY choose to create new Third Party Loss
> Report message and send it to the receivers in the downstream link.
> "
> 
> I don't understand how the BRS can inject any message into the SSM
> tree, as the source anchor of the SSM tree is up at the multicast
> source. Thus a BRS needs to tell the distribution source to send
> something down stream on its behalf.
> 
> 
> 
> 
> [Qin]: It is possbile for BRS to tell the distrbution source to send
> TPLR down on its BRS. My question is Is the BRS similar to
> Distribution source as an intermediary between multicast source and
> 
> downstream receivers? Why BRS can not inject in between while
> Distribution Source can?

My understanding what that the BRS is in fact not owner of their own SSM
session, only help nodes that are receiver of the SSM session but not DS
in it. And having the BRS send something to the DS which is only valid
for its little part of a large SSM session is strange.

But RAMS authors view would be appreciated.

> 
> 5. Section 6.3:
> 
> I think some assumptions are missing in this case. If the translator 
> receive a NACK for a missing packet, why can't that be forwarded? I 
> don't see why you need a TPLR in this case.
> 
> 
> 
> 
> 
> [Qin]: How about the following rephrasing: OLD text: " The translator
> can identify packet loss using co-located monitor
> [I-D.ietf-avtcore-monarch] by receiving a NACK from another system
> and then the monitor can use it's own SSRC as packet sender SSRC for
> transmitting the Third Party Loss Report message and send this
> message to the unicast receivers that is not aware of packet loss.
> 
> 
> " New Text: " The translator acting as quality monitoring may suffer
> a loss of important video packets. In this case, the translator may
> trigger repair by the media sender and tt the same time ,use it's own
> SSRC as packet sender SSRC to create a new Third Party Loss Report
> message and send it to the receivers that is not aware of packet
> loss. "

Much clearer.

> 
> 6. Section 6.4:
> 
> As this is a poorly supported model in RTP, why is a use case built
> on that? Shouldn't a RTP Mixer case be a better basis for building a
> FIR suppression usage?
> 
> 
> 
> [Qin]: I agree we can have a mixer use case for Feedback
> suppression.
> 
> but I am a little confused. do you think MCU is poorly supported
> model
> 
> or MCU use case for Feedback suppression is a poorly supported
> model?

I think MCU as described in RFC 5117 is a broken device and should not
taken into account when designing RTP/RTCP solutions.

> 
> My understanding of a video stream switching RTP mixer is that it in 
> fact sends a FIR to the media source it is going to switch to prior
> to actually switching. It doesn't switch until it actually has an
> I-frame or similar decoder refresh point to switch on. Thus the
> actually switching shouldn't be the cause for downstream FIR
> suppression. If the receiver has packet loss, it should in fact send
> PLI, rather than FIR.
> 
> 
> 
> [Qin]: It is true FIR SHALL NOT be sent as a reaction to picture
> losses However according to four paragraph, section 4.3.1.2 of
> RFC5104, FIR
> 
> can beSHOULD be used in situations where not sending a decoder
> refresh
> 
> point would render the video unusable for the users. Therefore large
> number of
> 
> participants may send FIR to ask for decoder reshresh point rather
> than packet
> 
> loss at the same time. Am I wrong?

No, you quote the RFC correctly. However, I think one needs to ask one
self if this issue occurs in an MIXER/MCU setup at all. As the Mixer are
sitting between each session participant it can suppress the the FIR
most naturally for most use cases.

I agree in cases where the video gets badly screwed up between media
source and mixer and the system doesn't use retransmission, suppression
of FIR and I would say PLI also could have its points.

So it occur in two cases. One where the mixer analyses the video enough
so that it can determine that the packet loss will result in PLI or FIR
transmissions from most of the group, and thus initiate it on it own accord.

The second case is when it starts to receive FIR or PLI from some
participants and like to suppress the rest by sending out a message.




> 
> So I do wonder do we have a use case for suppressing FIR?
> 
> 
> 
> [Qin]: Do you think we need a use case for suppressing PLI?

Yes, there exist a case for this, but I would consider it not supper
strong. Also I think it apply equally to PLI as to FIR.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------