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

["Van Caenegem, Tom (Tom)" <[e-mail]>]

Magnus,


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


Tom: I think you are mixing up two things : a NACK can be sent by the BRS to the DS with the aim to result in feedback suppression relying on the fact that the DS reflects this NACK down on the SSM. However, the DS may also host a RS, and then it could respond additionally with a retransmission to the BRS, which a BRS could send to receivers in existing retransmission sessions. However, this is not what this draft is about. You are right that both will result in FB suppression, but there is no mandate that a DS also hosts a RS.  


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.

Tom: well , again,  that's exactly why I want Qin to refer to "draft-vancaenegem-avtcore-retransmission-for-ssm-00". Can we defer the discussion on this item towards that draft? I will provide a second version in due time.