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

[Qin Wu <[e-mail]>]

Hi, Tom:
Thank for your clarifications, which do answer my questions. please see my suggestions below.
----- 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 23, 2011 5:04 AM
Subject: RE: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt


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

[Qin]: I think this is not clear from reading RFC4585, however if you look at the section 3.5.2, Step 5b),  it said:
"
If R understands the received FB message's semantics and the
 message contents is not a superset of the feedback R wanted to
send, then R SHOULD transmit its own FB message as scheduled.
"
I think you need to expand Receiver behavior based on this paragraph regarding FB suppression.

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.

[Qin]: Agree. In RAMS session, if BRS cache the packet which the receiver is ask for,it is better not to suppress receiver sending unicast NACK to ask for its lost packet. if BRS does not cache that packet due to upstream packet loss, such packet loss affect all the receiver, therefore it is better to supress receiver sending unicast NACK.  

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.

[Qin]: True.

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? 

[Qin]: As I said above, if the receiver is allowed to send unicast NACK to RS to ask for lost packet if RS keep that packet for retransmission,  it think this is reasonable to have independent document to talk about such optimization. In this case, if RS has already cached that packet, NACK for that packet should not be sent from DS to all the receivers, rather than RS itself compensate this lost packet by sending retransmission packet in response to each retransmission request. However if RS does not have that packet, the RS can choose to forward NACK or send TPLR via DS to the remaining receiver.

My suggestion is to be clear about this in your draft.
Another suggestion is your draft should more focus on RAMS case.In the introduction it is better to clarify what the downside of using FB suppression rule defined in RFC4585 in the RAMS session.

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.

[Qin]:I think this is another optimization you can do. Since BRS know how many receivers it has and it can determine if sending NACK or TPLR via DS to the receivers to avoid uncessary NACK or TPLR.


Regards=