Subject: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03

From: Qin Wu <[email-masked]>
Date: Sat, 09 Oct 2010 12:49:11 +0800

Folks,

We have updated draft-wu-avt-retransmission-suppression-rtp which should now reflect the discussion we had since IETF78. 

The feedback suppression solution has also been greatly generalized comparing to the previous version.

Comments are solicited.

Regards!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Saturday, October 09, 2010 12:45 PM
Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : RTCP Report Extension for Feedback Suppression
> Author(s)       : W. Wu, et al.
> Filename        : draft-wu-avt-retransmission-supression-rtp-03.txt
> Pages           : 24
> Date            : 2010-10-08
> 
> This document specifies an extension to the RTCP feedback messages
> defined in the Audio-Visual Profile with Feedback (AVPF).  This
> extension allows an intermediate node in the network (such as an RTP
> translator) inform downstream receivers that sending a feedback
> message concerning a specified set of RTP messages may be
> unnecessary, or even harmful.  For example, in a source-specific
> multicast session with large fan-out, packet loss close to the media
> or distribution source of the session is detected as a loss by a
> large number of receivers.  The RTCP NACK messages used to request
> retransmission of the missing packets are all addressed to the media
> sender, or a designated feedback target.  This may result in a
> phenomenon known variously as a "NACK implosion" or "feedback storm".
> The Feedback Suppression message defined herein is used to notify
> receivers that packet loss was detected and that the sender of the
> report will either proactively recover, or no recovery is possible.
> Receivers respond to receipt of a feedback suppression message by not
> sending a feedback message (e.g. a NACK) that they otherwise would,
> This in turn reduces load on both the feedback target and on the
> network.  This document registers two new RTCP messages for Feedback
> Suppression.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

--------------------------------------------------------------------------------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 9 Oct 2010 09:38:06 -0700

Comments:
1) Abstract is too long, could you shorten it?

Typos in abstract:
a) .. that *are* sending ...
b) RTP messages -> RTP packets
c) "the sender of the report will either proactively recover": Well, it does not have to be the sender of the report who will attempt the recovery. I would rephrase this.

2) Throughout the document, avoiding "sender" might be a good idea. For the source, use media or distribution source. Sender may mean different things in different contexts.

3) Intro 1st paragraph: The retransmission payload format is 4588 not 4585.

4) Most of the discussion in the introduction section can be shortened in a concrete way by referring to other existing RFC in this area. I am actually quite surprised that RFC 5740 is not mentioned at all here. I would rather refer to RFC 5740 (rather than DVB-IPTV).

5) Do not use (upper-case) 2119 keywords in the introduction. IESG does not like it :)

6) Section 2: The definitions seem to evolve around SSM. Why would not they apply to ASM?

7) Section 3 and further on: There are several lower-case 2119 keywords in the text which you might wanna replace.

8) Section 6.1.1 says "If the loss reporter is part of group, the Distribution source MUST filter this packet out and not forward it back to this loss reporter." How does it filter that loss reporter out?

9) What about the cases where the receiver will actually not send a NACK despite the packet loss? Consider where there is also a FEC stream that can recover the lost packets. Should the loss reporter listen to the FEC channel as well and act accordingly?

10) You seem to assume that different loss reporters will always see the same losses. That is not necessarily true. What should be reported back to the receivers if the reports coming to the FT are conflicting? Do you report the union or intersection of the reports back to the receivers?

11) You also seem to be relating this NACK implosion to retransmission. I would actually prefer to keep the retransmission stuff out of the text here (just mention it in the introduction and then forget about it). Whether the distribution source actually retransmits the missing packets or not has nothing to do with the messages defined in this draft.

-acbegen 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
> Sent: Saturday, October 09, 2010 12:49 PM
> To: [email-masked]
> Subject: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03
> 
> Folks,
>

---

From: Qin Wu <[email-masked]>
Date: Mon, 11 Oct 2010 16:38:22 +0800

Hi, Ali
Thank for your comments, please see my reply inline.
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Sunday, October 10, 2010 12:38 AM
Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03

Comments:

[Qin] Okay.

Typos in abstract:

[Qin]: You may misunderstand, the subject is actually "sending a feedback message"

[Qin]: yes.

[Qin]: Okay.

[Qin]: Okay.

[Qin]: Good catch, thanks.

[Qin]; Okay.

[Qin]: Okay.

[Qin]: Right, they should apply to ASM.

[Qin]: Okay, thanks.

[Qin]: It is one optimized behavior.
One possible way to do this is that the Distribution Source knows the address of loss reporter or know in which port it can receive the RTCP message from the loss reporter.
Is that reasonable?

[Qin]: Good question. I think if the reciever know it will not send a NACK, then the distribution source should know as well. In such case, the distribution source may choose not to send feedback suppression message to the receiver.

[Qin]: If there are duplication reports, the Distribution source should filter the duplicated report out and only send one copy of report to the reciever. What the distribution source does is to create one summary report which only append different loss in this summary report.

[Qin] Okay.

-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Mon, 11 Oct 2010 12:03:13 +0100

This draft is generally along the right lines, and – as discussed in  
Maastricht – we should consider adopting it as a working group draft.  
That said, I have a number of comments, which generally echo Ali's  
comments:

- The abstract needs to be rewritten as an abstract, rather than an  
introduction.

- Should note, in the introduction, that the NACK storm respects the  
RTCP bandwidth constraint on average, but that naïve implementations  
that don’t choose to dither their response can cause short term  
overload. There is no risk of congestion collapse, if the receivers  
are correctly implemented. While there is a real problem to be solved,  
I believe the discussion in the introduction overplays the risks.

- The introduction includes RFC 2119 language specifying requirements  
– this should be moved into Section 3. Specifically, I suggest the  
last six paragraphs of the Introduction be moved into Section 3.

- Section 3 contains a lot of discussion of the loss reporter and the  
SSM use case. Much of this seems unnecessary in this part of the  
draft: discussion of SSM and the loss reporter concept should be in  
section 6.1, leaving section 3 to specify the general protocol  
behaviour, independent of particular use cases.

- Section 4 has unnecessary subheadings. Suggest removing the 4.1  
header then renaming section 4.1.1 to “4.1 Transport Layer Feedback:  
NACK Suppression Report”, and also removing the 4.2 header then  
renaming section 4.2.1 to “4.2 Payload Specific Feedback: FIR  
suppression report”.

- Section 7 should note that middleboxes that are not visible at the  
RTP layer that wish to send NACK/FIR suppression reports on behalf of  
the sender can only do so if they spoof the SSRC of the sender. This  
is difficult is SRTP is in use. If the middlebox is visible at the RTP  
layer, this is not an issue, provided the middlebox is part of the  
security context for the session.

- Section 7 should note that endpoints that receive a NACK/FIR  
suppression request would be well-advised to ignore it, unless it is  
authenticated via SRTCP or similar. Accepting un-authenticated NACK/ 
FIR suppression requests can lead to a denial of service attack, where  
the endpoint accepts poor quality media that could be repaired.

None of these are fundamental, and I don't think there's anything that  
should delay adoption as a working group draft.

Colin

On 9 Oct 2010, at 17:38, Ali C. Begen (abegen) wrote:
> c) "the sender of the report will either proactively recover": Well,  
> it does not have to be the sender of the report who will attempt the  
> recovery. I would rephrase this.
>
> 2) Throughout the document, avoiding "sender" might be a good idea.  
> For the source, use media or distribution source. Sender may mean  
> different things in different contexts.
>
> 4) Most of the discussion in the introduction section can be  
> shortened in a concrete way by referring to other existing RFC in  
> this area. I am actually quite surprised that RFC 5740 is not  
> mentioned at all here. I would rather refer to RFC 5740 (rather than  
> DVB-IPTV).
>
> 7) Section 3 and further on: There are several lower-case 2119  
> keywords in the text which you might wanna replace.
>
> 8) Section 6.1.1 says "If the loss reporter is part of group, the  
> Distribution source MUST filter this packet out and not forward it  
> back to this loss reporter." How does it filter that loss reporter  
> out?
>
> 9) What about the cases where the receiver will actually not send a  
> NACK despite the packet loss? Consider where there is also a FEC  
> stream that can recover the lost packets. Should the loss reporter  
> listen to the FEC channel as well and act accordingly?
>
> 10) You seem to assume that different loss reporters will always see  
> the same losses. That is not necessarily true. What should be  
> reported back to the receivers if the reports coming to the FT are  
> conflicting? Do you report the union or intersection of the reports  
> back to the receivers?
>
> 11) You also seem to be relating this NACK implosion to  
> retransmission. I would actually prefer to keep the retransmission  
> stuff out of the text here (just mention it in the introduction and  
> then forget about it). Whether the distribution source actually  
> retransmits the missing packets or not has nothing to do with the  
> messages defined in this draft.
>
> -acbegen
>
>
>
>> We have updated draft-wu-avt-retransmission-suppression-rtp which  
>> should now reflect the discussion we had since IETF78.
>>
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 11 Oct 2010 16:38:08 -0700

...
> [Qin]: You may misunderstand, the subject is actually "sending a feedback message"

Right. Shortening the sentence would definitely help here.
 
...
> 8) Section 6.1.1 says "If the loss reporter is part of group, the Distribution source MUST filter this packet out and not forward
> it back to this loss reporter." How does it filter that loss reporter out?
> 
> One possible way to do this is that the Distribution Source knows the address of loss reporter or know in which port it can
> receive the RTCP message from the loss reporter.
> Is that reasonable?

Are your reports unicast or multicast? In the latter, how do you deal with it?
 
> 9) What about the cases where the receiver will actually not send a NACK despite the packet loss? Consider where there is
> also a FEC stream that can recover the lost packets. Should the loss reporter listen to the FEC channel as well and act
> accordingly?
> 
> [Qin]: Good question. I think if the reciever know it will not send a NACK, then the distribution source should know as well. In

Not necessarily. If the FEC is on another distribution channel (which is usually the case), the DS does not know what the receivers are getting in terms of FEC.

> such case, the distribution source may choose not to send feedback suppression message to the receiver.

I think we need to think about this a bit further. If FEC recovers most of the errors for majority of the receivers, maybe doing this (feedback suppression) will not be needed as much.
 
> 10) You seem to assume that different loss reporters will always see the same losses. That is not necessarily true. What
> should be reported back to the receivers if the reports coming to the FT are conflicting? Do you report the union or
> intersection of the reports back to the receivers?
> 
> [Qin]: If there are duplication reports, the Distribution source should filter the duplicated report out and only send one copy
> of report to the reciever. What the distribution source does is to create one summary report which only append different loss
> in this summary report.

This does not answer my question. If the reports are identical, yes you can remove the duplicate. But if the reports are not identical. Now you have a decision to make? And whatever you do may actually change the performance.
 
-acbegen

---

From: Qin Wu <[email-masked]>
Date: Tue, 12 Oct 2010 15:05:13 +0800

Hi, 
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 12, 2010 7:38 AM
Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03

...

[Qin]: Okay.
...

[Qin]: In the current draft, we assume Report sent from loss reporter to the distribution source is unicast, the report sent from or created  at distribution source is multicast.
Suppose the loss report is separated from the distribution source and send multicast report to the distribution source, the distribution souce can identify this multicast report
based on the dedicated RTCP port used for loss report. Is it acceptable?

[Qin]: Right.

 
[Qin]: It seems we need media source or receiver to tell distribution source not suppress the specified stream sent from the media source. Right?
Or we assume FEC schemes will not used with suppression mechanism at the same time? Do you have any proposal?

> of report to the reciever. What the distribution source does is to create one summary report which only append different loss

This does not answer my question. If the reports are identical, yes you can remove the duplicate. But if the reports are not identical. Now you have a decision to make? 

[Qin]: Append the different report to the summary report.

And whatever you do may actually change the performance.
 
[Qin] In my opinion,  If the report is created at the distribution source and sent from the distribution source to all the reciever, the performance will not be influenced. If the loss report is not part of distribution source, i.e., separated from distribution source, we may ask the loss reporter to send unicast report to the distribution source and then the distribution source create the summary report  in multicast and send it to the recievers. that is to say, the unicast report will be terminated at the distribution source, so  the performance will be affected very little. If you really concern about this, we could only consider the case that the loss report is part of distribution source and distribution source create the multicast report.

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Tue, 12 Oct 2010 15:19:18 +0800

Hi,
Thank for your valuable comments, I will take them in the new version.

Regards!
-Qin
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Ali C. Begen (abegen)" <[email-masked]>
Cc: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Monday, October 11, 2010 7:03 PM
Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03

[Qin]: Okay.

[Qin]: Good point.

[Qin]: Okay.

[Qin]: Good input, thanks.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Roni Even <[email-masked]>
Date: Tue, 12 Oct 2010 09:33:40 +0200

Hi,
> Distribution source MUST filter this packet out and not forward
> > One possible way to do this is that the Distribution Source knows the
> address of loss reporter or know in which port it can

I think this has to do with your question about merging reports.

> NACK despite the packet loss? Consider where there is
> > also a FEC stream that can recover the lost packets. Should the loss
> reporter listen to the FEC channel as well and act
> > accordingly?
> >
> > [Qin]: Good question. I think if the reciever know it will not send a
> NACK, then the distribution source should know as well. In
> 
> Not necessarily. If the FEC is on another distribution channel (which
> is usually the case), the DS does not know what the receivers are
> getting in terms of FEC.

>From the DS perspective there are packet losses and letting the receiver
know even if it uses FEC may help the receiver giving him an earlier warning
allowing him to use FEC without waiting. 

> I think we need to think about this a bit further. If FEC recovers most
> of the errors for majority of the receivers, maybe doing this (feedback
> suppression) will not be needed as much.
> 
> the same losses. That is not necessarily true. What
> > should be reported back to the receivers if the reports coming to the
> FT are conflicting? Do you report the union or
> > [Qin]: If there are duplication reports, the Distribution source
> should filter the duplicated report out and only send one copy
> > of report to the reciever. What the distribution source does is to
> create one summary report which only append different loss
> > in this summary report.
> 
> This does not answer my question. If the reports are identical, yes you
> can remove the duplicate. But if the reports are not identical. Now you
> have a decision to make? And whatever you do may actually change the
> performance.

This is a good feedback. I think that this is application dependent, the
typical behavior can be union but if the DS knows the network topology it
may take another policy. Anyhow even if the receiver gets the union and on
his path the packet were not lost, it does not break since it will receive
the packets. The suppression just tell the receiver to not sent NACKs. The
draft does not address the behavior of the DS in the upstream direction and
leave it open to the implementation.

Roni Even

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 12 Oct 2010 16:35:23 +0200

Hi Qin,

these are my comments on the draft 3 version:

-you know of course that DVB IPTV has defined a solution to addres NACK storms. This solution was recently also adopted by OIPF. You propose to define a new dedicated message for NACK suppression, whereas in DVB/OIPF we defined that when an RTP receiver gets such a NACK message, this receiver should not send a NACK itself (provided the NACK was received before the receiver sends its own NACK). In a similar way, this could also be defined for FIR messages. I have no fundamental problem if AVT  decides to define a dedicated message, but can you provide arguments why a NACK sent by the distribution source/translator in a SSM to the client is not good enough for imposing NACK suppression to a receiver, by definition?

-a general comment: suppressing NACKs from receivers is a very tricky thing. Sometimes it may do more harm than do any good, and I feel this discussion and possible negative impact is not really addressed in this draft.

-in your figure 1, the SSM is sourced by the intermediate source which hosts the feedback target and a "loss reporter". This does not represent a realistic architecture as it would mean that for IPTV scenario the head-end receives all RTCP messages from all receivers. You should include architectures where FT are decoupled from the SSM source.

-the definition of the "loss reporter" is somewhat obscure to me. From various text fragments, it appears that a (NACK) FB message sent by the loss reporter, will result in the intermediate source/distribution source sending  a NACK storm suppression or FFS message to the clients in the group.  This means to me that any packet loss reported by the "loss reporter" is packet loss that will impact all receivers downstream of the intermediate/distribution source. If this is not the case, you will provide unneeded retransmissions. Is this a correct interpretation? If so, please make this clear in the definition of "loss reporter". If it is not, then mandating that getting a NACK from a loss reporter results in a FFS message, is not recommended IMO.  

-I do not understand why a "loss reporter" MUST not receive the FFS message -which is meant to be sent on the SSM-, and I also do not get how you can avoid that the "loss reporter" would receive this FFS message, as a "loss reporter" that is downstream of the intermediate source must be receiving the SSM in order to detect missing packets.

-you introduce the "immediate reporting RTP client" terminology from the DVB IPTV spec that is referenced, but its definition does not align with how it is defined in the DVB spec. So, please,  either stick to the DVB definition or use a different term. 

Regards
Tom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: zaterdag 9 oktober 2010 6:49
To: [email-masked]
Subject: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03

Folks,

Comments are solicited.

Regards!
-Qin

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 12 Oct 2010 07:34:59 -0700

> From: Roni Even [mailto:[email-masked]]
> Sent: Tuesday, October 12, 2010 3:34 AM
> To: Ali C. Begen (abegen); 'Qin Wu'; [email-masked]
> Subject: RE: [AVT] New Version Notification fordraft-wu-avt-retransmission-supression-rtp-03
> 
> 
> Hi,
> >
> > ...

Sure, but either I am missing something or could not explain my question clearly. But no hurry we can discuss it in the meeting.
 
> allowing him to use FEC without waiting.

Early warning is not bad, could be useful but FEC was just one example. We probably need to think about this more.
 
> leave it open to the implementation.

I think we need some guidelines presented in the draft since different reports will show up from time to time and some recommendations would be useful.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Tue, 12 Oct 2010 17:35:28 +0200

Hi Tom,
The semantics of sending NACK from the sender is not defined in RFC 4585. We
could add the sender semantics to NACK but the consensus so far was to use a
new message and not add new semantics to NACK. Note that the use of the
message is not only for NACK suppression.

See inline

Roni

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Van Caenegem, Tom (Tom)
> Sent: Tuesday, October 12, 2010 4:35 PM
> To: Qin Wu; [email-masked]
> -you know of course that DVB IPTV has defined a solution to addres NACK
> storms. This solution was recently also adopted by OIPF. You propose to
> define a new dedicated message for NACK suppression, whereas in
> DVB/OIPF we defined that when an RTP receiver gets such a NACK message,
> this receiver should not send a NACK itself (provided the NACK was
> received before the receiver sends its own NACK). In a similar way,
> this could also be defined for FIR messages. I have no fundamental
> problem if AVT  decides to define a dedicated message, but can you
> provide arguments why a NACK sent by the distribution source/translator
> in a SSM to the client is not good enough for imposing NACK suppression
> to a receiver, by definition?
> 
> -a general comment: suppressing NACKs from receivers is a very tricky
> thing. Sometimes it may do more harm than do any good, and I feel this
> discussion and possible negative impact is not really addressed in this
> draft.

I am not sure what you mean here. The receivers do not suppress NACKs, the
NACK suppression is sent by intermediary devices.

> 
> -in your figure 1, the SSM is sourced by the intermediate source which
> hosts the feedback target and a "loss reporter". This does not
> represent a realistic architecture as it would mean that for IPTV
> scenario the head-end receives all RTCP messages from all receivers.
> You should include architectures where FT are decoupled from the SSM
> source.

This is not IPTV specific feature so this is an example. There can be other
cases.

> 
> -the definition of the "loss reporter" is somewhat obscure to me. From
> various text fragments, it appears that a (NACK) FB message sent by the
> loss reporter, will result in the intermediate source/distribution
> source sending  a NACK storm suppression or FFS message to the clients
> in the group.  This means to me that any packet loss reported by the
> "loss reporter" is packet loss that will impact all receivers
> downstream of the intermediate/distribution source. If this is not the
> case, you will provide unneeded retransmissions. Is this a correct
> interpretation? If so, please make this clear in the definition of
> "loss reporter". If it is not, then mandating that getting a NACK from
> a loss reporter results in a FFS message, is not recommended IMO.

The draft only says the intermediate device will send NACK suppression and
leaves open the application behavior in the upstream side. The discussion so
far suggested that it should be out of scope for the draft.

> 
> -I do not understand why a "loss reporter" MUST not receive the FFS
> message -which is meant to be sent on the SSM-, and I also do not get
> how you can avoid that the "loss reporter" would receive this FFS
> message, as a "loss reporter" that is downstream of the intermediate
> source must be receiving the SSM in order to detect missing packets.
> 
> -you introduce the "immediate reporting RTP client" terminology from
> the DVB IPTV spec that is referenced, but its definition does not align
> with how it is defined in the DVB spec. So, please,  either stick to
> the DVB definition or use a different term.
> 
> Regards
> Tom
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 13 Oct 2010 16:12:46 +0800

Hi,:
Thank Tom for your valubable reviews. I agree with Roni's clarification in response to your comments.
I will soon issue new version to address all the comments recieved on the list.
Thank for all.

Regards!
-Qin
----- Original Message ----- 
From: "Roni Even" <[email-masked]>
To: "'Van Caenegem, Tom (Tom)'" <[email-masked]>; "'Qin Wu'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 12, 2010 11:35 PM
Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03

> NACK suppression is sent by intermediary devices.

[Qin]: It seems to me suppressing NACK from one dedicated reciever is not good choice as I talked with Ali on the list.
Therefore our draft will focus on how to use distribution source to suppress NACK or Feedback message
sent from downstream of distribution source. 

> far suggested that it should be out of scope for the draft.

[Qin]: Yes, the draft will focus on defining new NACK suppression message using RTCP and how to use such new message
to suppression feedback implosion.

>> source must be receiving the SSM in order to detect missing packets.

[Qin]: I think you raise the same issue as Ali. You are right, it does not make sense to avoid the loss reporter
to receive Feedback Suppression message if the loss reporter is part of group.
I will remove the following paragraph from the draft.
"
If the Loss Detector is part of group, the Distribution source MUST 
not send the summary report back to this Loss Detector.
"
 
>> the DVB definition or use a different term.

[Qin]: Okay, I will leave "immediate reporting RTP client" out of this draft.

>> Qin Wu

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Thu, 14 Oct 2010 13:06:38 +0200

Roni, thanks for your clarifying comments. See below. 

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: dinsdag 12 oktober 2010 17:35
To: Van Caenegem, Tom (Tom); 'Qin Wu'; [email-masked]
Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03

Hi Tom,
The semantics of sending NACK from the sender is not defined in RFC 4585. We could add the sender semantics to NACK but the consensus so far was to use a new message and not add new semantics to NACK. Note that the use of the message is not only for NACK suppression.

TOM: can you give me a pointer to where that concensus was reached, including the rationale? I must have missed it.

See inline

Roni

> -you know of course that DVB IPTV has defined a solution to addres 
> NACK storms. This solution was recently also adopted by OIPF. You 
> propose to define a new dedicated message for NACK suppression, 
> whereas in DVB/OIPF we defined that when an RTP receiver gets such a 
> NACK message, this receiver should not send a NACK itself (provided 
> the NACK was received before the receiver sends its own NACK). In a 
> similar way, this could also be defined for FIR messages. I have no 
> fundamental problem if AVT  decides to define a dedicated message, but 
> can you provide arguments why a NACK sent by the distribution 
> source/translator in a SSM to the client is not good enough for 
> imposing NACK suppression to a receiver, by definition?
> 
> discussion and possible negative impact is not really addressed in 
> this draft.

I am not sure what you mean here. The receivers do not suppress NACKs, the NACK suppression is sent by intermediary devices.

TOM: Sure. The draft basically specifies the Suppression message. But in terms of intermediate source/receiver behaviour, my read-out is as follows: 
1)a intermediate source can send at any time a NACK suppression
2)there is no normative language for the receiver what to do when this message is received

In the text, the intermediate source seems to rely on a NACK from a "loss reporter" for sending NACK suppression messages. Is this some kind of trusted device? Can it always be guaranteed that the packets this loss reporter receives or does not receive, are the same packets received/not received for all receivers that get the NACK suppression (and optional the retransmission afterwards)? Why would a receiver not systematically send the NACK anyhow -even if it does understand the suppression message, to maximise its chance of getting a retransmission.. This is the kind of discussion that should be included IMO.

> You should include architectures where FT are decoupled from the SSM 

This is not IPTV specific feature so this is an example. There can be other cases.

TOM: The (only) figure in the draft (entitled "system architecture") shows that the "intermediate source" is sourcing the SSM, hence is also the distribution source. The draft is also explicit about this as it says: "The intermediate source must be able to communicate with all group members in order for either mechanism to be effective at suppressing feedback" 

This means that scenarios/architectures as addressed with RAMS (where the BRS is co-located with the FT which is in general separate from the DS) are outside the scope of this work?

> various text fragments, it appears that a (NACK) FB message sent by 
> the loss reporter, will result in the intermediate source/distribution 

The draft only says the intermediate device will send NACK suppression and leaves open the application behavior in the upstream side. The discussion so far suggested that it should be out of scope for the draft.

TOM: My remark here was about the "loss reporter" concept, not about how -"plain normal"- receivers should respond on the NACK suppression message. As written above, the draft's architecture in which you position the NACK suppression seems restricted and not covering RAMS architecture.

> the DVB IPTV spec that is referenced, but its definition does not 
> align with how it is defined in the DVB spec. So, please,  either 
> stick to the DVB definition or use a different term.

TOM: I hope above two comments will be addressed and further discussed as well, and I have another question: the draft defines how one can signal in SDP, support for the NACK suppression.  Is that for SDP to be received by the RTP receivers? If so, why must that be declared in the SDP?

Thx
Tom

> > Receivers respond to receipt of a feedback suppression message by 
> > not sending a feedback message (e.g. a NACK) that they otherwise 
> > would, This in turn reduces load on both the feedback target and on 
> > the network.  This document registers two new RTCP messages for 
> > Feedback Suppression.
> >
> ----------------------------------------------------------------------
> -
> ---------
> 
> 
> > Internet-Draft directories: http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >

---

From: Qin Wu <[email-masked]>
Date: Fri, 15 Oct 2010 11:14:46 +0800

I would like to mention that the new version of draft-wu-avt-retransmission-supression-rtp has been issued.
http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt

[Qin]: No, the intermediate source follows the timing of RTCP feedback messages
  defined in the Audio-Visual Profile with Feedback (AVPF).  

[Qin]: You may look at the new version of draft-wu-avt-retransmission-supression-rtp:
http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt
According to normatve text of section 3 of draft-wu-avt-retransmission-supression-rtp-04:
the receiver will be silent when it receives feedback suppression message.
A receiver may still have sent a Feedback message before receiving a feedback suppression
 message, but further feedback messages for those sequence numbers
 will be suppressed by this technique.

[Qin]: No, according to discussion so far on the list, relying on dedicated reciever as loss reporter to report packet loss by sending existing NACK may have some impact the performance. 
the intermediate source may has its own loss detection functionality and should not rely on NACK from such dedicated receiver disjointed from intermediate source.
So I have remove the case relying on NACK from a loss report from this draft. Hope this clarfiies.
Also I have moved the text associated with use cases to the example use case section. So they are just one example.

[Qin]: Thank you for point out this. You may not realized we have removed this ambiguity in the new version of draft-wu-avt-retransmission-supression-rtp
http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt
The main changes is:
a. Move the last 6 paragraph to the protocol overview section.
b. Remove the ambiguity text from protocol overview section and add some text in the SSM use cases section.
This architecture will focus on specifying more generic mechanism and discuss how the mechanism works in the different use cases including the scenario as addressed with RAMS.

[Qin] See above.

> stick to the DVB definition or use a different term.

TOM: I hope above two comments will be addressed and further discussed as well, 

[Qin]: Based on the discussion with Ingemar, David, Ali and you, it seems the discussion suggest that relying on NACK from dedicated receiver is not a good idea and has some harm. So I have removed this use case from the draft. 
Do it make sense?

and I have another question: the draft defines how one can signal in SDP, support for the NACK suppression.  Is that for SDP to be received by the RTP receivers?

[Qin]: Yes, the reciever should understand feedback suppression message.

 If so, why must that be declared in the SDP?

[Qin]: Any other choice? what's your proposal?

Thx
Tom