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

[Qin Wu <[e-mail]>]

Hi, Magnus:
----- Original Message ----- 
From: "Magnus Westerlund" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Monday, September 12, 2011 10:43 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt

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.

[Qin]: Yes, I propose to remove the last paragraph since Tom argues this is more related to Retransmission. Also I propose to rewrite the left texts in RAMS use case. So there will be not so much text to support the figure any more.



> 
> 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.

[Qin]: According to RAMS specification in RFC6285, the Retransmission server also joins the multicast session, that is why it can cache the most recent packets from the primary multicast.

But you are right, having the BRS send something to the DS which only affect little part of a large SSM session is weired. So I propose to revise the text in RAMS case as:

"

The typical RAMS architecture [RFC6285] may have several Burst/

   Retransmission Sources(BRS) behind the multicast source (MS) placed

   at the same level.  These BRSes will receive the primary multicast RTP stream from the media source after joining multicast session.  If packet loss happens at the upstream of all the BRSs. one of the BRSes or all the BRSes may identify packet loss and send a NACK to the distribution source. Similar to the Distribution Source Feedback Summary model, the distribution source doesn't want to redistribute the duplicated NACK for the same loss event from multiple BRSes. In this case, the distribution source may send a Third Party Loss Report to the systems that were unable to receive the NACK.

"

Does it make sense?



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.

[Qin]: Okay.

> 
> 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.

[Qin]: I guess you are saying content switching is not common deployed compared to content mixing. However we can not deny its existence.

 

According to RFC4587,section 5, it said:

"

Image refreshment may be needed due to packet loss or due

   to application requirements.  An example of application requirement

   may be the change of the speaker in a voice-activated multipoint

   video switching conference.  There are two methods that can be used

   for requesting image refreshment.  The first method is by using the

   Extended RTP Profile for RTCP-based Feedback and sending RTCP generic

   control packets, as described in RFC 4585 [RFC4585].  The second

   method is by using application protocol-specific commands, such as

   H.245 [ITU.H245] FastUpdateRequest.

"

In this case, they are talking about a use case using MCU, i.e., the change of the speaker in a voice-activated multipoint video switching conference.

 

So I proposed to revise MCU use case as follows:

"

When the speaker is changed in a voice-activated multipoint video switching conference [RFC4587], video switching MCU can be used to select the available input streams and forward one to each participant. However in some case, the receiver may lose synchronization with the video stream and send a FIR to ask for the new decoder refresh point. when the MCU starts to receive FIR from some participants and like to suppress the rest session participants sending FIR by sending out a Third party Loss report message. As suggested in RFC 5117, the MCU is better implemented as an Topo-Mixer, in which case the mixer's SSRC is used as packet sender SSRC for transmitting the Third Party Loss Report message.

"

What do you think of it?



> 
> 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.



[Qin]: Good inputs. How about rephrase it as a new mixer use case like this:

"

A Mixer, in accordance with [RFC5117], aggregates multiple RTP streams

from other session participants and generates a new RTP stream 

sent to the session participants. In some cases, the video may get badly

screwed up between media source and the mixer. In such case, the mixer need to check if the packet loss will result in PLI or FIR transmissions from most of the group by analyzing the received video. If so the mixer initiate it on behalf of all the session participants sending PLR or FIR and at the same time send the third part loss report to these session participants. Another possible way for mixer to deal with, is when the mixer starts to receive FIR or PLI from some

participants and like to suppress the rest session participants sending FIR or PLI by sending out a Third party Loss report 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.

[Qin]: See above.

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]
----------------------------------------------------------------------