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

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

Qin,
Appreciate your swift responses! Second round..
Tom

________________________________

From: Qin Wu [mailto:[e-mail]] 
Sent: dinsdag 6 september 2011 11:03
To: Van Caenegem, Tom (Tom); 'IETF AVTCore WG'
Subject: Re: comments on "draft-ietf-avtcore-feedback-supression-rtp-06"


Hi,Tom
Thank for your early feedback to this new version and please see my replies below.

	----- Original Message ----- 
	From: Van Caenegem, Tom (Tom) <mailto:[e-mail]>  
	To: 'IETF AVTCore WG' <mailto:[e-mail]>  
	Cc: Qin Wu <mailto:[e-mail]>  
	Sent: Monday, September 05, 2011 11:30 PM
	Subject: comments on "draft-ietf-avtcore-feedback-supression-rtp-06"
	
	
	>Hi Qin
	>these are my comments on "draft-ietf-avtcore-feedback-supression-rtp-06" 
	>Regards
	 
	>1)Abstract:
	>'This memo discusses these cases and defines a new RTCP third-party loss report that can be used to inform receivers that a feedback target is aware of some loss event."

	>Comment:  "feedback target" is only defined in RFC 5760. Please use terminology that does not limit to RFC 5760 architectures (unless this is what this ID is after?)

	[Qin]: Okay, how about say "the network" instead of saying "Feedback target". 

	 

	Tom: yes, better. 

	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.

	 

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

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

	[Qin]: See above. 

	 

	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.

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

	 

	>IMO, the above rationale is the one reason to define a new message.Your text suggests that one reason for defining this TPL message is that receiving a NACK for an RTP receiver (and which enables >suppression, the feature this ID is about) is confusing towards that receiver. How can this be, if it is part of RFC 4585? 

	[Qin]: How the sender of TPLR message is told about packet loss is not focus of this document. Receiving NACK

	 from a receiver that detects pakcet loss is just one way or example. There may be other ways,e.g., receiving receive report that convey packet loss event. 

	Tom: I agree (see above), but my point is that an intermediate can in some cases also send/forward a NACK. In some cases not. 

	>3)Protocol overview, 2nd paragraph

	>"When a receiver gets a Third Party Loss Report message, it should refrain from sending a feedback request (e.g., NACK or FIR) for the missing packets reported in the message for a certain period of >time.'

	>Comment: why don't you mandate (...MUST refrain from sending..) the suppression (in the same way it is mandated by RFC 4585?)

	[Qin]: Okay, I think it makes sense.

	>4)Protocol overview, 3rd paragraph

	>'Systems that receive a Third Party Loss Report SHOULD NOT initiate their own additional Third Party Loss Report messages for the same packet sequence numbers. They may either simply forward >the Third Party Loss Report message, or they may generate their own Third Party Loss Report that reports a set of the losses they see, which are different from ones reported in the Third Party Loss >report they received." 

	>Comment: "systems" (these are entities, right?) that observe packet losses themselves , can only issue/source NACKs, not TPL reports

	[Qin]:Your are right, but this is irrevelant to this paragraph. This paragraph focuses on how to deal with recieved TPL report.
	Systems could be any RTP Systems or RTP node. It doesn't matter. 

	Tom: it does matter: this "system: can for instance not be a simple (end) RTP receiver, otherwise forwarding the TPL messages goes against its intention: FB suppression!

	 

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

	>6)Protocol overview, general comment:

	>What I miss in this section is some text/clarification in which RTP session, using which SSRC, this TPL message is transmitted. E.g. in case of a DS in summary feedback model which gets a nack from >one or more receivers, and this DS decides to send a TPL message. It will do so using its  own SSRC and I guess it will send it inside the SSM. . but what about other topologies like RAMS.. see my >note number 10.

	[Qin]: Section 3 is about the semantic of TPLR and how to deal with TPLR by sender, middlebox and receiver and is not specific to any case. As regarding how SSRC is chosen has been clarified in the section 6 (use case section) and section 4 (message format section).

	>7) section 6.1. first paragraph

	>"Note that each receiver sending multicast NACK to its group may still need to send unicast NACK addressed to the media source or distribution source for lost packets, this may lead to a NACK >storm if feedback suppression is not performed and if the RTCP bandwidth limit is misconfigured."

	>Comment: are you suggesting that TPL reports are a way to deal with the lack of FB suppression at Rx or with misconfigured limits? If not, please delete this sentence.

	[Qin]: Yes, TPL report is necessary when multiple receivers still send NACK to the source to ask for lost packet at the same time, in this case, FB suppression at Rx to suppress other receiver sending NACk is not adequate 

	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.  

	>8) section 6.1. general

	>The main message in this section is that SSM in summary feedback model may generate TPL reports and when operating in simple feedback model, the DS will simply forward received NACKs.  There >is IMO unneeded repititions in paragraph 2 and 3, and there is also text on intermediate nodes (different from DS/FTs and receivers) in the 3rd paragraph that are NOT specific to SSM architecture, i.e. >unneeded and confusing.  

	[Qin]: Okay and will fix it in the new version.

	>9) section 6.1. last paragraph

	>A "media source" in SSM architecture has no direct relationship with the SSM receivers. So, the media souurce will not send a RTCP NACK to all receivers... What it can do is sending a NACK to the >DS, which then distributes via the SSM to all receivers. However I am not sure that a source can send a NACK?..This is ..well.. indeed confusing!
	 
	[Qin]: The example for media source to send NACK is the case when DS/FT is collocated with media source. In this case, the loss was detected and repair initiated much closer to the source 
	 
	Tom: a media source is NOT supposed to send NACK message for packets it has sourced itself.  FB messages can only be sourced by receivers of that particular RTP stream 
	 
	>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.
	 
	>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?  
	 
	>11)section 6.3
	 
	>Please explain why forwarding the NACK in the transport translator use case -which is the supposed activity of a transport translator- is not a possibility here ( iso mapping it to a TPL message). 
	>(Note again that both result in FB suppression!)
	 
	[Qin]:Firstly I think either forwarding NACK or TPLR messaage work and we are not mandating using TPLR message. 
	 
	Tom: OK, worthwhile to mention this in the draft, and maybe you could consider to say why a translator would source a TPL message rather than FW-ing a NACK, or vice versa.
	 
	Seconly, receiving NACK is not only way for RTP translator to be told by packet loss. what the translator is a quality monitor it may receive the packet loss not as NACKs but as part of the receiver reports and send TPL message. Here this case just gives an example.
	 
	Tom: agree, but the example is.. that the monitor send a NACK to the translator, so see my comment above.