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

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

Qin,

Hope this answers your questions.
Tom 

-----Original Message-----
From: Qin Wu [mailto:[e-mail]] 
Sent: maandag 19 september 2011 10:34
To: Van Caenegem, Tom (Tom); Magnus Westerlund
Cc: [e-mail]; [e-mail]
Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt

Hi,
----- Original Message -----
From: "Van Caenegem, Tom (Tom)" <[e-mail]>
To: "Qin Wu" <[e-mail]>; "Magnus Westerlund" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Friday, September 16, 2011 7:00 PM
Subject: RE: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt



Qin,


The BRS sends a NACK or TPLR message to the DS, where the SSRC in this NACK or TPLR message is the one of the BRS. The DS forwards/reflects this message down on the primary SSM. This procedure will allow isolated feedback suppression, when RTP receivers only trigger FB suppression when recognising the SSRC as belonging to the BRS to which they report.

[Qin]: What do you mean about isolated feedback suppression, do you mean DS control which BRS it will redistribute Feedback suppression message from BRS or just flood the message to all the BRSes.

Tom: no. As explained above a BRS that wants FB suppression will send NACK or TPLM to the DS, which then re-distributes to ALL RTP receivers via the SSM. Only receivers that report to the BRS that sent the TPL or NACK message to the DS, will suppress feedback. Other receivers will ignore this NACK/TPL message. Whether the feedback suppression is activated or not, is hence determined by the SSRC identifier value (the one of the BRS) in the TPLM or NACK that is received by the RTP receiver. See the draft document.

[Qin]: It is not clear to me how this is different from FB suppression rule defined in RFC4585.
it looks to me the receiver behavior for FB suppression in your draft document is not compliant with what it described in RFC4585,
Fist of all,  ome receivers doesn't follow FB suppression rule defined in RFC4585 when they receive NACK or TPL with unkonw SSRC value.

Tom: well, my STARTING assumption is that receivers receiving a NACK, do implement FB suppression, independent from the SSRC inside. Is RFC 4585 saying that if SSRC is not known, the NACK  is ignored by receiver (and FB suppression is cancelled)?

However according to RFC4585, if NACK or TPLM is allowed to send to all the receivers, all the receivers should react to the receiving NACK or TPLM following rule defined in RFC4585
rather than ignore  or discard it when SSRC in NACK or TPLM is unknow.

Tom: indeed. And that's where FB suppression has an unfortunate side-effect for a RAMS like topology with multiple BRS-es. And that's one of the reasons why I submitted the draft.

Secondly If one receiver didn't report the loss to the BRS, however the DS may still send NACK or TPLM to this receiver. In your undersanding, this receiver should not activate feedback suppression.
However according to RFC4585, the receiver receiving NACK or TPLM should suppress FB message if it see the same loss.

So in my understanding, additional rule you proposed is like conditional FB suppression for receivers, in other words, the receiver selectively does FB suppression based on the SSRC delcared. 

Tom: indeed, selective -or conditional- feedback suppression is the (desired) result.

My question is does it conflict with RFC4585? 

Tom: it does "conflict" with the RFC 4585 rules with respect to a receiver's behaviour, but this new receiver behaviour for SSM with RAMS architecture is to make the overal system (retransmission service) work better without increasing risk on FB storm. The driver for creating new IDs and RFCs is making things better, no? 

Is it optional choice or 
mandatory choice for FB suppression? e.g., only the number of receivers exceeds the threshold, then conditional FB suppression applies.

Tom: RFC 4585  disallows the receiver to send a NACK when receiving a NACK. What the retransmission for ssm -ID says is that receiver MAY send a NACK, when the NACK or TPLM has an SSRC identifier that is not the one of its BRS (nor of the DS). This is independent from the number of receivers reporting to this BRS or the total number of receivers in the SSM group.


Regards=