Re: [AVTCORE] comments on "draft-ietf-avtcore-feedback-supression-rtp-06"

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

Qin,

see below
Regards
Tom


>>2)Intro, first paragraph:

>>"One common cause of such a feedback storm is receivers utilizing RTP retransmission [RFC4588] as a packet loss recovery technique based, sending feedback using RTCP NACK messages [RFC4585] without proper dithering of the retransmission requests."

>>Comment: what is meant with "without proper dithering"?  Is this about RTP Rx not behaving according to RFC 4585 when sending RTCP FB messages?  Please clarify.

>[Qin]: No, it is in accordance with RFC4585. Dithering means wait for random time to send NACK. However in some cases, multiple recievers may wait for almost the same time without seeing a >corresponding FB message from any other receiver reporting the same event  and then send its own NACK. After they sent out NACK, these receivers then recieved the late NACK from each other >reporting the same event.

>Tom: I think it is worthwhile to clarify this in the ID, i.e. what "without proper" means in this context. I think you should add that the probability this will happen is of course dependent from the size of the >group of receivers.

[Qin]:Okay. Any proposed text?

TOM: probably needs further discussion...see also Colin's remark

>Another rationale is multiple receivers May still send NACK to the same source to ask for the lost packet besides Sending NACK to the other recivers in the same group,
>Therefore sending NACK to the other recievers in the same group is not enough to prevent NACK is recieved by the same source that posses the lost packet. Hope this clarifies.

>Tom: I am sorry I (still) do not understand this..

[Qin]: what I am saying here is
In general case, NACK can be sent either in multicast or in unicast.
Multicast NACK can be used to inform other receiver in the group not sending NACK but is not used to request the lost packet .
Unicast NACK can be used by receivers to send retransmission requests to a specified media source for the specified lost packet.
When one receiver A detect packet loss wants to inform others not send NACK while all the other receivers want to request the same lost packet by sending retransmission request using NACK,
However Multicast NACK from the receiver A may arrive late after multiple other receivers send unicast NACK to the same source for the same lost packet. In this case, multicast NACK from the receiver can not prevent other receiver from sending unicast NACK.
Does it make sense to you?

Tom:  I do not see the added value that a receiver sends 2 NACKs (one in unicast to a dedicated retransmission server and another to a MC group which all receivers would get... you are actually worsening the situation in terms of FB storm potential.  Either just make the  retransmission server part of the MC group, or adopt the RFC 5760 arch.
...And this case provides not a rationale as such for defining a 3rd party loss message!
I really think the section explaining the rationale for defining the TPLR message should be re-phrased along the lines I provided below.

>>To elaborate further here: what I (still!) miss in this section is a clear description of  the rationale why this ID defines a new RTCP message. IMO the baseline should be as follows for this section:

>>-RFC 4585 does include feedback suppression

>>-For some RTP topologies and/or policies, RFC 4585-based suppression (based on a receiver receiving a FB message from another receiver) may not be adequate or not possible. Provide examples for >>such RTP topologies/policies.

>Tom: IMO the main reason why this new message is defined is because an intermediate has received a packet loss indication that impacts a large group of receivers, and hence issues the TPL message to >those receivers to avoid FB implosion.  But alternatively, the intermediate may also send a NACK to avoid FB implosion.

>Examples:

>When the intermediate detects the loss itself, it should send a NACK, not a TPL.

>When the packet loss indication to the intermediate is an RTCP NACK, it can either send a TPL message or  foward this NACK acting as a translator.

>I do not agree with your statement that sending a NACK is confusing to the receiver, and which seems to be a justification for defining the TPL message.

[Qin]:Just for clarification.
Firstly, in some cases, some receivers want to send unicast NACK to ask for the lost packet. Other receivers want to send multicast NACK or unicast NACK to inform other receivers in the same group not send NACK for the same loss event. In such cases, it does introduce confusion to the intermediary.
Secondly, NACK can be sent either to intermediary/media source for lost packet or sent from one receiver to other receivers to suppress them sending NACK, therefore in some case it is straightforward to the receiver, e.g., when there is very few downstream receivers, in some other cases when there is large number downstream receivers, they send a large number of NACK at the same time, simply forwarding NACK by intermediary from each downstream receiver introduce unnecessary NACK for the same packet loss multiple times. In this case, it seems the NACK forwarding only can be used to suppress each receiver sending a second new NACK out. The cost is if you have one hundred downstream receivers, they almost send NACK for the same loss at the same times, the intermediary is required to forward the NACK for the same loss one hundred times.
However if you use TPLR, there is no such issue since TPLR is defined as a message sent from the network to the receiver. When the intermediary is told about the packet loss, intermediary can filter duplicated NACK from each downstream receiver out for the same loss, then send only one TPLR in multicast channel to all the downstream receiver. Therefore the cost and complexity can be greatly reduced.
Does this make sense to you?


Tom: See my comment above on this assumed intentional behaviour of a RTP receiver sending twice a NACK.

>>Maybe another reason could be that there is a timing aspect that is different from RFC 4585 (I concur with Magnus that the timing aspect is indeed something that must be >addressed)

>[Qin]: The timing rule of sending new message could be same as the timing rule of sending NACK.

>I am afraid additional timing rule is not needed.



>Tom: it is true that we will complicate things here. But if the intermediate sending an RTCP TPLR needs to comply with the same rules as a normal RTP receiver, its feedback suppression will not be >(always) effective. A receiver that gets a TPL message should indeed simply comply with the same rules as getting a NACK when having detected the same packet loss (FB suppression from RFC 4585).

[Qin]:Okay,agree.

Tom: ..below you propose a different behaviour for the receiver (using a timer) ?



>>5)Protocol overview, 4th paragraph

>>I really do not understand this paragraph.. are you describing a situation where an intermediate should not send a TPL report?

>[Qin]: This paragraph explaines TPL report usage should not conflict with packet loss repair mechanism and gives a example explain this. The example mostly focuses on how receiver deals with second >loss (i.e., retransmission packet loss when TPLR is used) raised by Janathan.

>Tom: If you want an example on how FB suppression interferes with retransmission, I rather prefer you to refer to the ID  "draft-vancaenegem-avtcore-retransmission-for-ssm-00"

>.  I recall that the agreement on the exploder was that this WG draft will not discuss retransmission.

[Qin]:I disagree since this is not simply about how to deal with retransmission. When the receiver get the first TPLR, it set a timer to estimate when to receive the retransmitted packet or another TPLR, if it receive another TPLR, the timer should be restarted. If either retransmitted packet or another TPLR is not received, the receiver should fall back to normal receiver behavior as if there is no TPLR for suppression. I will do some rewording in this paragraph.

Tom: ..this is similar what has been defined in the DVB IPTV retransmission text, but the difference is that in DVB we defined a time-out value which- when signaled- is used by all receivers as the time interval between two successive retransmission requests. This same time-out value is also the time that a feedback suppression (imposed by receiving a nack) must be enforced @ the receiver. RFC 4588 does not define this parameter and each receiver assesses the time between successive retransmission requests. I think Magnus touched upon this as well. It is now much harder for a receiver to make a good assessment as there are other network segments involved (e..g between a media source and a intermediate/retr server).

This text is IMO not about protocol section , but about receiver behaviour.  And you will need a similar text that indicates an intermediate can send multiple TPL messages for the sake of prolonging the feedback supression.


 >>6)Protocol overview, general comment:

 >Tom: well.. I am a bit lost here.. you describe SSM (RFC 5760), but where all receivers send multicast NACKs and they also send a unicast NACK to the DS?  Acoording to RFC 5760, a receiver only >sends unicast NACK to the FT (which can co-incide with the DS). If the receivers send multicast NACKs, this is about AnySourceMulticast.

[Qin]:
 I agree this sentence does not apply to SSM case. According to RFC5760, in SSM, NACK from each downstream receiver is unicast to FT in the DS. The DS then sends NACK as multicast RTCP packet to all the downstream receivers.
Therefore I will remove it.
BTW: I suspect you can not define ASM as one receiver sending multicast NACK. For SSM session without Feedback Target, why does the receiver can not send multicast NACK?

Tom: OK.
Tom: with source specific multicast, only the media source can send RTP/RTCP  in this specific multicast group.



[Qin]: I agree NACK should be sent from receiver of RTP stream rather than sender of RTP stream. However I still think TPLR can be sent from media source to the receiver if the media source have ways to know the loss.

Tom: sure, this is what TPLR is about...


>>10) section 6.2.

>>The meat in this section is about the capability of a BRS to send a TPL message using its own SSRC to its receivers on the downstream link...

>[Qin]: More exact to say, the section 6.2 focuses on when one branch of SSM tree encounter packet loss, how TPL is used to suppress other receiver sending unnecessary message.

>Tom: what you do is describing an architecture where TPL messages are only sent to a subset of all SSM receivers.

>>But you do not specify how this happens.. Is this in >dedicated unicast sessions or in dedicated SSM? How are these sessions than associated with the original SSM for which a TPL message has been >>created?

>[Qin]:It does not matter it is in unicast session or SSM. But using TPL report in SSM session is more useful than in unicast session.

>Also I think it is not focus of this case to describe the association between different session.


>Tom:  FB suppression (via a NACK or a TPL) for such architecture is more detailed in  "draft-vancaenegem-avtcore-retransmission-for-ssm-00"   In order to avoid conflicts, I suggest to refer to this ID.

[Qin]: I think this case is just a general case to explain how to use TPLR in RAMS case, nothing else. I am not sure it really conflicts.

Tom: maybe it is not conflicting, maybe it does.. fact is that the other ID will probably still evolve..

>>The second paragraph is more about retransmission and implementation  choices and should be deleted IMO

>[Qin]: No, this second paragraph is about how the receiver deal with second loss raised by Janathan when TPL report has been applied. It is relevant.

>Tom: if a receiver receives a TPL, my understanding is that it will not send a NACK anymore. If your understanding is different, please explain.  The receiver is NOT aware of any (second) loss.. it has >received a TPL message and if you say that this imposes a FB supression rule as described in RFC 4585, what more needs to be explained?
>I also do not understand why this "event" description is linked to this specific use case?

[Qin]:Just clarification. The receiver is just temporarily hold NACK for a certain time. What receiver will do is to set a timer to wait for retransmitted packet or another TPLR, if either retransmission packet or another TPLR is received, the receiver will fall back to normal receiver behavior.

Tom: see my comments above.. It will need more elaboration if you want to go this way..