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

[Qin Wu <[e-mail]>]

Hi, Magnus:
Please see my reply below.
----- Original Message ----- 
From: "Magnus Westerlund" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Friday, September 16, 2011 11:24 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt


> On 2011-09-16 12:24, Qin Wu wrote:
>> 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.
> 
> Ok, do what you think best here.


[Qin]: Okay.

>> 
>> 
>> 
>>> 
>>> 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?
>> 
> 
> Hmmm, this is strange. If the BRS can send the NACKs then I would expect
> the DS to retransmit the missing packet, rather than sending a TPLR as
> they will not arrive to the receivers any prior to the actual repair
> packet.
> 
> In the same way I don't see how a TPLR works well in this use case if is
> only targeted to a part of the multicast tree. This as there isn't
> really anyway of controlling who interpret the TPLR.
> 
> I don't know what I think of Tom's idea that the receiver should filter
> the TPLR based on the source SSRC of it and only react on the ones that
> matches its configured BRS. Then I think this needs to be well defined,
> rather than just discussed here for that particular use case.
> 

[Qin]: Just for clarification. The data cached from the primary multicast at the BRS is only for unicast retransmission.

Therefore I think we need look at RAMS use case in two cases supposing multiple BRSes placed in between at the same level.

Case 1: multicast packet loss happens at the upstream of all the BRSes

Case 2: multicast or unicast packet loss happens at the aggregating downstream of one BRS

For case 1, multicast packet loss is targeted to all the BRSes and their downstream receivers, in this case,

 one or all BRS may be aware of upstream multicast packet loss and tell the DS to send TPLR to suppress 

NACK from each BRS downstream receiver. Also in this case, BRS can send TPLR, DS forward this TPLR to 

the downstream. Is this case clear or well defined to you?

 

For case 2, packet loss is only targeted to one BRS and will not affect other BRSes and relevant downstream

 receiver in that branch. Also packet loss includes unicast packet loss and multicast packet loss. In unicast 

packet loss, the BRS will send unicast retransmitted packet from its cache to the affected receiver upon receiving 

NACK from downstream receiver. If downstream multicast packet loss happens at the downstream of this BRS, 

this BRS (in the multicast path between media source and receiver) needs to check if the multicast packet loss need 

to be told to DS. 

 

In draft-ietf-avtcore-feedback-suppression-rtp, we only talking about the first case(i.e., upstream loss case).  

For case 2, I guess Tom's draft is mostly used to deal with this case. Am I wrong?


Also In my understanding, Tom's idea on SSRC declaring is just to help receiver to know how to deal with unnecessary TPLR or 
NACK from network.



> 
>>> 
>>> 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.
>> 
> 
> No, that is not what I am saying. The fact is that stream switching can
> be implemented in the RTP mixer model just as well as actually
> composited video streams. It is still an RTP mixer, rather then the
> broken MCU topology that butchers the RTCP reporting for the RTP session.

[Qin]: I see and agree.

>> 
>> 
>> 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?
>> 
> 
> I would claim that the correct way of implementing the functionality
> they are talking about in RFC 4587 is to use an RTP mixer. Thus I would
> modify the text to say:
> 
> When the speaker is changed in a voice-activated multipoint video
> switching conference [RFC4587], an RTP mixer 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 RTP Mixer starts to receive FIR from
> some participants it can suppress the rest of the session participants
> from sending FIR by sending out a Third party Loss report message.
> 

[Qin]: I am okay with this rephrasing, thanks.

> 
>> 
>> 
>>> 
>>> 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
> I would change "need to" to "may"

[Qin] Okay.

>> transmissions from most of the group by analyzing the received video.
>> If so the mixer initiate it on behalf of all the session participants
> 
> Change it to what it is, I guess FIR or PLI towards the media source

[Qin] Okay and Yes.

>> sending PLR or FIR and at the same time send the third part loss
>> report to these session participants. 
> 
> I think the above is a bit confused. I don't see the receivers having
> sent a FIR or PLI yet. As they may not have been reached by the broken
> video packets. The goal is after all to try to get the receivers to
> suppress their sending before they actually send something.

[Qin]: My mistake for introducing such confustion. How about change the texts from

"

 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. 

"

to

"

If so, the mixer initiates FIR or PLI towards the media source

on behalf of all the session participants and send out a Third party Loss report message

to these session participants

early before they are reached by the broken video packets from the upstream of mixer 

and going to send PLR or FIR.

"


> 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.
> 
> I guess "rest" here should be remaining. And I think there is missing
> "from" before sending.

[Qin] Yes, thanks for catching.

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