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

[Magnus Westerlund <[e-mail]>]

On 2011-09-19 07:45, Qin Wu wrote:
>>>> 
>>>> 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?
> 

Not entirely. As I don't see how a BRS can determine on its own if a
loss upstream of itself will affect only the part of the tree it is
responsible to service with repair, or if it affects all. Thus, I don't
see how we currently can define a suppression that involves BRSs at all.

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

I think that is likely the right place. That draft will have to extend
the suppression behavior in those cases to include the "targeting" to
downstream of a certain repair node. Otherwise the suppression will have
whole SSM wide scope, which will be 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.

I see it as necessary to avoid receivers that has no loss at the BRS
level of the multicast tree from suppressing their repair requests
unnecessary.

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

I think this is better but still not clear. Two issues with the text.

1. " early before they
> are reached by the broken video packets"

Are you assuming that the mixer will not have sent the broken RTP packet
prior to sending the suppression message? or that the mixer will detect
the case and be able to send a suppression message that cancel the
transmission of a NACK or PLI requrest?

2. " and going to send PLR or FIR."

Maybe formulate it so that it is clear that the receivers may or are
expected to send a PLI or 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]
----------------------------------------------------------------------