Subject: Re: [AVT] I-D Action:draft-wu-avt-retransmission-supression-rtp-06.txt

From: Jonathan Lennox <[email-masked]>
Date: Sun, 7 Nov 2010 14:30:10 -0500

I've read this draft, and I'm unclear on what the intended *semantics* are of the retransmission suppression message.

Are they "repair is in progress upstream, please wait"?  Or "repair will not be forthcoming, please conceal the loss"?  Or just "if you were in an ASM multicast group for your RTCP, by now you would have seen -- or probably would soon see -- a NACK for this packet from another session participant"?

For one practical consequence of this question, RFC 4588 discusses receivers' timers for when to retransmit a NACK, if after a certain amount of time it appears that a previous retransmission request has failed.  In this case, should the suppression be considered to just suppress the first of these messages?  I.e., if the receiver concludes that the suppressed request has failed, can it "re"-send its NACK?

Architecturally, consider the case where a packet is lost on the upstream between a media source and an loss-detecting intermediary.  In this case, the intermediary will send a NACK upstream and a retransmission suppression downstream, and the repaired packet should soon arrive and be distributed.

However, it is of course possible for that retransmitted packet to itself be lost on one of the downstream access links as well.  In this case, presumably it would be desirable for the receiver on that downstream link to eventually notice that the suppressed retransmission request has failed, and to re-send its NACK.

My initial suggestion is that the semantics of a suppression indication should be the first one I mentioned, i.e. "you would have seen someone else's NACK/FIR, so don't send one yourself, but start retransmission timers if you like."  This allows this double-loss case I described to be handled correctly.

RFC 4588 also discusses circumstances in which a sender/retransmission source can decide (for example, due to bandwidth/congestion constraints) that certain lower-importance packets in a stream will not be retransmitted.  In such a case, one might want to have a retransmission suppression message that indicates this fact.  However, under the semantics I described, this could presumably be handled by having the retransmission source resend the NSEI at some frequency (regular RTCP intervals?) for the duration of the source's rtx-time.

This wouldn't allow for suppression semantics that trigger early concealment, but that may be a less compelling use case.

Other comments on the draft:

I don't think the format of the NSEI packet is defined correctly; notice that RFC 4585 NACK feedback packets can contain multiple Generic NACK elements, for use when the range of lost sequence numbers is greater than 17.

The FIR suppression packet (FSEI) seems very underdefined; in particular, the semantics of its sequence number field are unclear, since it doesn't carry over in any natural way from FIR itself.

On Oct 25, 2010, at 9:55 AM, Qin Wu wrote:

> Hi, folks:
> 06 version of draft-wu-avt-retransmission-supression-rtp is posted which address the remaining comments:
> * shorten the abstract
> * simplify the introduction section
> * remove the appdendix
> * rephrase the section 6.1.1 to define only the behaviour of a single distribution source
> * keeps retransmission as packet loss repair mechanism out.
> * Add RAMS case to explain how feedback suppression works.
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-06.txt
> Thank for Ali, Colin and Tom's comments.
> 
> Regards!
> -Qin

--
Jonathan Lennox
[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Mon, 08 Nov 2010 08:50:17 +0800

Hi, 
Thank for your comments.
I think we have many packet loss repair mechanisms like Retransmission and loss concealment, FEC that can be used with Feedback Suppression mechanism together. However how packet loss can be 
recovered is not the focus of this draft based on the discussion on the list and comments in the last IETF meeting. That is why we keep packet loss repair stuff like retransmission out of normative text in the
current version. As for the purpose of Feedback Suppression, please see my reply below.

Regards!
-Qin
----- Original Message ----- 
From: "Jonathan Lennox" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 08, 2010 3:30 AM
Subject: Re: [AVT] I-D Action:draft-wu-avt-retransmission-supression-rtp-06.txt

[Qin]: As for the purpose of Feedback Suppression, we have two case:
case 1: packet loss can not be repaired
case 2: packet loss can be repaired by the middle box. In other words, The middlebox can help the all the receiver get the lost packet and send them to the reciever via multicast channel.
For case 1, the Feedback Suppression will be sent to inform the receiver that packet loss repair can not be repaired.
For case 2, the Feedback Suppression will be sent to inform the reciever that sending packet loss request like retransmission request is not necessary and the middlebox will help push 
the lost packet to the receiver. 

[Qin]: Good question, In my personal opionion, I think if the receiver receives Feedback suppression message, all the NACKs from this same receiver will be suppressed to reduce possibility of Feedback Implosion. But as for how the receiver deal with this Feedback Suppression message,  it is not the scope of this document. one way you can do is to start retransmission timer, it is specific implementaton issues for packet loss repair.

[Qin]: Okay, that is one way for packet loss repair.

[Qin]: if retransmission packet lost on one of the downstream access links, only receievers connecting to that downstream access links will be affected. In my understanding, it will cause large number of
reciever from all the downstream access links  addressed to the same media source and lead to Feedback  Implosion.

[Qin]: We are on the same page.

[Qin]: Feedback Suppression message can follow the timing of regualr RTCP Feedback or the timing of early feedback specified in RFC4585.

[Qin]: No, This new message uses the similar format of NACK Feedback packet and contain multiple NACK suppression elements if you want.

[Qin]: Also this new messages use the similar packet as FIR specified in RFC5104 and carry sequence number of the lost packet over the same layer/level as FIR.

--
Jonathan Lennox
[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Sun, 7 Nov 2010 20:38:10 -0500

On Nov 7, 2010, at 4:50 PM, Qin Wu wrote:

> current version.

The existing documents follow this separation -- RFC 4585 defines the NACK reporting mechanism, whereas RFC 4588 defines the retransmission/repair behavior.  I agree that keeping these separate is a good idea, and this document's core normative behavior should probably be defined in relation to RFC 4585 only.

That said, some guidance (possibly non-normative) describing the mechanism's relationship with RFC 4588 would probably be useful. 

> the lost packet to the receiver. 

Is there any way for a receiver to distinguish these two cases?  If not, are you certain that it will never be needed?

> [Qin]: Good question, In my personal opionion, I think if the receiver receives Feedback suppression message, all the NACKs from this same receiver will be suppressed to reduce possibility of Feedb…

Yes, clearly the particular behavior I describe here is specific to the repair mechanism.

However, this is where the issue of the semantics of NSEI is important.  If NSEI is a command that means "never send a NACK for this packet", the behavior I described would be invalid (a violation of this specification).  However, if it is an indication that means "someone else has sent a NACK for this packet, you don't need to send one right now", the behavior I describe would be a valid implementation.

> reciever from all the downstream access links  addressed to the same media source and lead to Feedback  Implosion.

I don't understand this comment.  If a retransmission packet is lost only on one of the downstream access links, then NACKs would only be sent by receivers on that one access link, which would not cause an implosion.  It should be the same behavior as would happen for a normal packet loss on a downstream access link.

> [Qin]: Feedback Suppression message can follow the timing of regualr RTCP Feedback or the timing of early feedback specified in RFC4585.

Should feedback suppression messages themselves be sent more than once?  Clearly it would be bad if the Feedback Suppression message itself is lost.

> [Qin]: No, This new message uses the similar format of NACK Feedback packet and contain multiple NACK suppression elements if you want.

Okay, I'm glad that's the intention -- I agree it's correct. I think the wording in the draft just needs some cleanup.

> [Qin]: Also this new messages use the similar packet as FIR specified in RFC5104 and carry sequence number of the lost packet over the same layer/level as FIR.

The sequence number in FIR is the command sequence number of the FIR itself, not an RTP sequence number from the original media stream.  Note that it is only 8 bits.

--
Jonathan Lennox
[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Mon, 08 Nov 2010 10:22:20 +0800

Hi,
----- Original Message ----- 
From: "Jonathan Lennox" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 08, 2010 9:38 AM
Subject: Re: [AVT] I-D Action:draft-wu-avt-retransmission-supression-rtp-06.txt

[Qin]:  Yes, we do have in the introduction section of this draft.
I have taken Ali's advice on the list to only mention such relationship in the introduction section 

[Qin]: Yes, I think it is easy to distinguish these two cases by adding a indication bit in the message.
but I am not sure if we need such feature. we can discuss this in this afternoon AVT session.

[Qin]: Okay.

[Qin]: Sorry for bad typo. We are on  the same page. 
What I really means is in that case, it will not cause large number of
reciever from all the downstream access links  addressed to the same media source and will not lead to Feedback  Implosion.
Also this draft focus on packet lost clost to media source or at the upstream of middle box. Hope it clarifies.

[Qin]: It allows if RTP/AVPF allows.

[Qin]: Okay. Thanks.

[Qin]: I get your point. Thanks.

--
Jonathan Lennox
[email-masked]

---

From: Roni Even <[email-masked]>
Date: Mon, 08 Nov 2010 12:41:54 +0200

Hi Jonathan,
Thanks, you are making a good point. The objective is to let the middle box
identify lost packet from the upstream and notify the downstream receivers
that he did not see these specific packets and therefore is not sending them
downstream now. (the emphasis is on the now)
The draft does not address the repair behavior and the middle box does not
define a specific behavior but provides as informative text some use cases. 

One use case that you mention is when the downstream receiver would have
sent  according to his application flow a NACK message but since it got the
suppression message he will not send it. Still the downstream receiver
behaves as if he did sent one and have started a timeout in which it
expected to get a retransmission packet. When this timeout expires  and
there is no retransmitted packet or a new suppression message he can take
his normal behavior as if there is no current retransmission suppression.
One example where this may happen is when the middle box sent a NACK
upstream got the retransmitted packet and sent it downstream and the
retransmit packet was lost on the downstream link. This is why the emphasis
is on the now in the suppression message semantics.

As for the case where the suppression message is lost, it will mean that the
some downstream receivers will send a NACK and the middle box can decide to
ignore it. I think that this make the retransmission suppression more of an
indication  and not a command.

Roni Even 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jonathan Lennox
> Sent: Sunday, November 07, 2010 9:30 PM
> To: Qin Wu
> Cc: [email-masked]
> I've read this draft, and I'm unclear on what the intended *semantics*
> are of the retransmission suppression message.
> 
> Are they "repair is in progress upstream, please wait"?  Or "repair
> will not be forthcoming, please conceal the loss"?  Or just "if you
> were in an ASM multicast group for your RTCP, by now you would have
> seen -- or probably would soon see -- a NACK for this packet from
> another session participant"?
> 
> For one practical consequence of this question, RFC 4588 discusses
> receivers' timers for when to retransmit a NACK, if after a certain
> amount of time it appears that a previous retransmission request has
> failed.  In this case, should the suppression be considered to just
> suppress the first of these messages?  I.e., if the receiver concludes
> that the suppressed request has failed, can it "re"-send its NACK?
> 
> Architecturally, consider the case where a packet is lost on the
> upstream between a media source and an loss-detecting intermediary.  In
> this case, the intermediary will send a NACK upstream and a
> retransmission suppression downstream, and the repaired packet should
> soon arrive and be distributed.
> 
> However, it is of course possible for that retransmitted packet to
> itself be lost on one of the downstream access links as well.  In this
> case, presumably it would be desirable for the receiver on that
> downstream link to eventually notice that the suppressed retransmission
> request has failed, and to re-send its NACK.
> 
> 
> My initial suggestion is that the semantics of a suppression indication
> should be the first one I mentioned, i.e. "you would have seen someone
> else's NACK/FIR, so don't send one yourself, but start retransmission
> timers if you like."  This allows this double-loss case I described to
> be handled correctly.
> 
> RFC 4588 also discusses circumstances in which a sender/retransmission
> source can decide (for example, due to bandwidth/congestion
> constraints) that certain lower-importance packets in a stream will not
> be retransmitted.  In such a case, one might want to have a
> retransmission suppression message that indicates this fact.  However,
> under the semantics I described, this could presumably be handled by
> having the retransmission source resend the NSEI at some frequency
> (regular RTCP intervals?) for the duration of the source's rtx-time.
> 
> This wouldn't allow for suppression semantics that trigger early
> concealment, but that may be a less compelling use case.
> 
> 
> I don't think the format of the NSEI packet is defined correctly;
> notice that RFC 4585 NACK feedback packets can contain multiple Generic
> NACK elements, for use when the range of lost sequence numbers is
> greater than 17.
> 
> The FIR suppression packet (FSEI) seems very underdefined; in
> particular, the semantics of its sequence number field are unclear,
> since it doesn't carry over in any natural way from FIR itself.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Qin Wu <[email-masked]>
Date: Mon, 08 Nov 2010 20:42:00 +0800

Hi, :
Based on the offline discussion with Jonathan after the meeting, we have issued the new version of draft to address Jonathan's concern about Double Loss Case.
http://www.ietf.org/id/draft-wu-avt-retransmission-supression-rtp-07.txt
We put one new paragaraph at the end of Introduction section to explain Feedback Suppression should not adversely impact the repair of lost source packets
and give some guidance (possibly non-normative) describing the mechanism's relationship with RFC 4588. 
Also we make editorial change to protocol overview section a little bit to get alignment with the change in the introduction.
If you have any concerns, please let us know.

Chairs:
I belive this draft is in good shape now after cooking for a while after the last IETF meeting and We have gotten lots of support in the last meeting and on the list. 
Therefore I would like to request WG to adopt this work. Thanks!

Regards!
-Qin

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Mon, 8 Nov 2010 16:52:52 +0100

Hi Qin,
 
Unfortunately, it was not practical for me to be in Bejing to discuss further the draft in the meeting. Based on your latest draft, these are my comments. You will see that some comments are not even new, but as they have not been addressed yet, I repeat them here.
 
1) The abstract is written as:

"In a large RTP session using the RTCP feedback mechanism defined in
   RFC 4585, a media source or middlebox may experience transient
   overload if some event causes a large number of receivers to send
   feedback at once.  This feedback implosion can be mitigated if the
   device suffering from overload can send a feedback suppression
   message to the receivers to inhibit further feedback. This memo
   defines RTCP extensions for feedback suppression, to suppress NACK
   and FIR feedback requests.  It also defines associated SDP
   signalling"

I think the abstract (which of course must be kept small) provides a wrong impression. Let me explain:

Basically IMO there are two ways by which suppression messages can bring relief:

Case 1: activate and have MULTIPLE "intermediate nodes" that can send suppression indication. If there is only one intermediate node, there is no real advantage of sending this message unless multicast is used (=> case 2). When multiple intermediate nodes are involved, this allows to distribute the message load/processing over these multiple intermediates, and thus shapes one potential big FB (/retransmission) storm that must otherwise be handled by a single entity, into multiple smaller -and hence addressable- storms, even if only unicast delivery mechanisms are used.

Case 2: having a media source/distribution source/ sender/intermediate entity send suppression message over multicast. In the best case (packet loss upstream of the entity) one single multicast suppression message will not result in any unicast FB message sent by the receivers. For packet loss downstream of the entity which may be detected quite late, a suppression message over multicast can still reduce the amount of unicast FB messages transmitted upstream by the receivers.

Of course case 1 and 2 can be mixed (and a RAMS topology is a good example that can do that)

So.. defining a "feedback suppression message" as such will not result in gain unless one or both of the two conditions above are present: it is equally bad to have a entity getting a massive amount of unicast FBs compared to having this same entity sending a massive amount of unicast FB suppression messages.  This should be reflected in the abstract and other sections of the document. For the abstract, you could bring it in as follows:

In a large RTP session using the RTCP feedback mechanism defined in
   RFC 4585, a media source or middlebox may experience transient
   overload if some event causes a large number of receivers to send
   feedback at once.  This feedback implosion can be mitigated by leveraging intermediate nodes that can send a feedback suppression message to the receivers to inhibit further feedback and/or if multicast distribution can be leveraged for sending this message. This memo defines RTCP extensions for feedback suppression, to suppress NACK and FIR feedback requests  and discusses example architectures where feedback implosion is mitigated or avoided.  It also defines associated SDP signalling.

2) Section "Example use cases": in the SSM use case (6.1) you refer to RFC 5760 and then you mention several times multiple Distribution Sources.   I do not see how this fits with RFC 5760 which defines a single DS. There can be multiple FT, is this what you mean? Or do you mean multiple "intermediate nodes"? The considered  architecture  is not clear to me (am I the only one?), and one or multiple  drawings could really help a lot!!

3)I had previously a question why you see need to declare with SDP the suppression indication. I did not see an answer (yet). But in your latest draft you now introduce timers that a RTP receiver could set, and if within a time-out after packet loss detection by the receiver, no suppression message has been received -and neither the original packet or retransmission, the receiver can still send the  RTCP FB message.  So, one reason why it could be benefical to declare support of feedback suppression at the sender side, is that it can trigger a dedicated client behaviour. But then you need to define or at least describe this recommended behaviour in my opinion. Note that this client behaviour is part of the DVB IPTV solution defining retransmission (& feedback suppression)! 

If there are other reasons why the retransmission suppression must be declared, please tell!  

4)I do not understand why you define the SSRC field in the suppression message as: The "SSRC value of the media source that is requested to send the lost packet". 
The suppression message is sent by a sending entity to RTP receivers, but the message may be sent without a request was issued to (re-)send the lost packet!  The "media sender SSRC" field in the RTCP FB message header does carry that information, by the way. I am still not convinced a dedicated message is required for feedback suppression.  I am still waiting for a example where you can show me that using the same message formats as RFC 4585, but re-purposed (and defined as such!) is causing confusion...

5)I think the subsections in the "example use cases" need some major revisions, but first let's clear out the above comments..

Regards
Tom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: maandag 8 november 2010 13:42
To: Jonathan Lennox; [email-masked]
Cc: Roni Even
Subject: [AVT] Offline//Re: I-D Action:draft-wu-avt-retransmission-supression-rtp-07.txt

Hi, :
We put one new paragaraph at the end of Introduction section to explain Feedback Suppression should not adversely impact the repair of lost source packets and give some guidance (possibly non-normative) describing the mechanism's relationship with RFC 4588. 

Chairs:

Regards!
-Qin

---

From: Qin Wu <[email-masked]>
Date: Tue, 09 Nov 2010 10:42:24 +0800

Hi, Tom:
Thank for your comments. please see my reply belows.
Regards!
-Qin
----- Original Message ----- 
From: "Van Caenegem, Tom (Tom)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Jonathan Lennox" <[email-masked]>; <[email-masked]>
Cc: "Roni Even" <[email-masked]>
Sent: Monday, November 08, 2010 11:52 PM
Subject: RE: [AVT] Offline//Re: I-D Action:draft-wu-avt-retransmission-supression-rtp-07.txt

Hi Qin,

[Qin]: Okay, seems to have a narrow scope, but it is reasonable to me.

[Qin]: In the SSM use case, we may allow multiple DS or multiple intermediate situated between media source and receiver.
In order to  conform to RFC5760, we can only allow one DS to support loss detection functionality by itself. This DS is responsible for creating new message of Feedback Suppression. As for other intermediate nodes,  they may be just responsible for forwarding Feedback Suppression. 

[Qin]: Actually I take this issue as one open issue in the Monday afternoon AVT session and solicit comments and suggestions from WG. Unfortuenately we run out of time to talk about this. 
But I agree with your opinion on the reason why we need such SDP announcement. Thanks.

[Qin]: Good catch. Sorry for this terminology issue. the correct definition for SSRC field in the suppression message is
"
SSRC vallue of the sender that is requested to send the lost packet.
"
Becos in some case, it is middlebox or DS rather than media source to create new message for Feedback Suppression, therefore the middlebox or DS should set SSRC field of suppression message as their own SSRC value. Thank you.

[Qin]: Okay.

Regards
Tom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: maandag 8 november 2010 13:42
To: Jonathan Lennox; [email-masked]
Cc: Roni Even
Subject: [AVT] Offline//Re: I-D Action:draft-wu-avt-retransmission-supression-rtp-07.txt

Hi, :

Chairs:

Regards!
-Qin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Nov 2010 12:29:23 +0800

Hi Roni,

We should be clear that this report is not necessarily sent from a middlebox. It can just as legitimately be sent from a source that's receiving excessive amounts of feedback directly.

Colin

On 8 Nov 2010, at 18:41, Roni Even wrote:
> Hi Jonathan,
> Thanks, you are making a good point. The objective is to let the middle box identify lost packet from the upstream and notify the downstream receivers that he did not see these specific packets and therefore is not sending them downstream now. (the emphasis is on the now) The draft does not address the repair behavior and the middle box does not define a specific behavior but provides as informative text some use cases. 
> 
> One use case that you mention is when the downstream receiver would have sent  according to his application flow a NACK message but since it got the suppression message he will not send it. Still the downstream receiver behaves as if he did sent one and have started a timeout in which it expected to get a retransmission packet. When this timeout expires  and there is no retransmitted packet or a new suppression message he can take his normal behavior as if there is no current retransmission suppression. One example where this may happen is when the middle box sent a NACK upstream got the retransmitted packet and sent it downstream and the retransmit packet was lost on the downstream link. This is why the emphasis is on the now in the suppression message semantics.
> 
> As for the case where the suppression message is lost, it will mean that the some downstream receivers will send a NACK and the middle box can decide to ignore it. I think that this make the retransmission suppression more of an indication  and not a command.
> 
> Roni Even 
> 
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Nov 2010 12:39:49 +0800

On 8 Nov 2010, at 23:52, Van Caenegem, Tom (Tom) wrote:
...
> I am still not convinced a dedicated message is required for feedback suppression.  I am still waiting for a example where you can show me that using the same message formats as RFC 4585, but re-purposed (and defined as such!) is causing confusion...

The semantics of the two messages are different: the generic NACK in RFC 4585 indicates "I did not receive these packets" whereas the new message indicates "I have been told that others did not receive these packets". 

It's legitimate for a middlebox to send a NACK (upstream and downstream) to indicate that the middlebox noticed that certain packets were missing, and such a report should cause downstream receivers to suppress their own NACKs. However, that's different to the case where multiple downstream receivers notice loss and all decide to report it upstream at once (e.g., by unicast to a feedback target) so that an upstream device needs to suppress the NACKs.

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

---

From: Roni Even <[email-masked]>
Date: Tue, 09 Nov 2010 07:56:54 +0200

Hi Colin,
Yes, you are right
Roni

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, November 09, 2010 6:29 AM
> To: Roni Even
> Cc: 'Jonathan Lennox'; [email-masked]
> We should be clear that this report is not necessarily sent from a
> middlebox. It can just as legitimately be sent from a source that's
> receiving excessive amounts of feedback directly.
> 
> Colin
> 
> 
> 
> > Thanks, you are making a good point. The objective is to let the
> middle box identify lost packet from the upstream and notify the
> downstream receivers that he did not see these specific packets and
> therefore is not sending them downstream now. (the emphasis is on the
> now) The draft does not address the repair behavior and the middle box
> does not define a specific behavior but provides as informative text
> some use cases.
> >
> > One use case that you mention is when the downstream receiver would
> have sent  according to his application flow a NACK message but since
> it got the suppression message he will not send it. Still the
> downstream receiver behaves as if he did sent one and have started a
> timeout in which it expected to get a retransmission packet. When this
> timeout expires  and there is no retransmitted packet or a new
> suppression message he can take his normal behavior as if there is no
> current retransmission suppression. One example where this may happen
> is when the middle box sent a NACK upstream got the retransmitted
> packet and sent it downstream and the retransmit packet was lost on the
> downstream link. This is why the emphasis is on the now in the
> suppression message semantics.
> >
> > As for the case where the suppression message is lost, it will mean
> that the some downstream receivers will send a NACK and the middle box
> can decide to ignore it. I think that this make the retransmission
> suppression more of an indication  and not a command.
> >
> > Roni Even
> >
> >
> >> Subject: Re: [AVT] I-D Action:draft-wu-avt-retransmission-
> supression-
> >> rtp-06.txt
> >>
> >>> * rephrase the section 6.1.1 to define only the behaviour of a
> single
> >> distribution source

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 9 Nov 2010 03:16:28 -0500

First of all, let me say that I think this is useful work, and I support the AVT group working on it.

> Becos in some case, it is middlebox or DS rather than media source to create new message for Feedback Suppression, therefore the middlebox or DS should set SSRC field of suppression message as thei…

I'm not sure this is the best definition.

First of all, this is one area where you need to be careful to keep the 4585/4588 separation cleanly.  If (as I suggested) the normative text of this document only references 4585, then nothing is being "requested to send the lost packet" -- the middlebox is simply observing that it is already known that a packet has been lost, and requesting that receivers not send additional NACKs to report this fact.

Secondly, RTPFB and PSFB packets generically have two SSRC fields, and I think that they both apply in a pretty straightforward manner for NSEI (and FSEI). The "SSRC of packet sender" field contains the SSRC of the middlebox that observed the packet loss and is requesting NACK suppression, and the "SSRC of media source" field contains the SSRC of the media stream whose packet was lost.

I don't see the need for a third SSRC in the NSEI-specific FCI, unless there's some third participant in the process that I'm overlooking.
--
Jonathan Lennox
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Nov 2010 17:15:25 +0800

> First of all, let me say that I think this is useful work, and I support the AVT group working on it.

Agreed - this is useful, and there seems to be enough interest for AVT to take this on.

> I don't see the need for a third SSRC in the NSEI-specific FCI, unless there's some third participant in the process that I'm overlooking.

This makes sense.

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

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 9 Nov 2010 11:04:31 +0100

Hi Colin,

You got me quite confused. When you state:

"It's legitimate for a middlebox to send a NACK (upstream and downstream) to indicate that the middlebox noticed that certain packets were missing, and such a report should cause downstream receivers to suppress their own NACKs."

I do not see how this is different when I say that sending a RTCP FB NACK to RTP receivers (receivers of the RTP stream identified by the SSRC value as expressed in the "media sender" field of the RTCP FB mesage) can be re-purposed to suppress those RTP receivers sending NACKs for the same missing packet(s). 

The middle box can be anything, including the DS in SSM. 

So, what additional information does the new message format bring (which differs only in PT and FMT) and/or how can it cause confusion or misinterpretation, in particular with respect to the receiver behaviour? This remains unclear to me.

Tom

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: dinsdag 9 november 2010 5:40
To: Van Caenegem, Tom (Tom)
Cc: IETF AVT WG
Subject: Re: [AVT] Offline//Re: I-D Action:draft-wu-avt-retransmission-supression-rtp-07.txt

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

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 9 Nov 2010 18:50:24 +0800

> the AVT group working on it.

I agree.

...

---

From: Qin Wu <[email-masked]>
Date: Tue, 09 Nov 2010 21:49:00 +0800

Hi,
----- Original Message ----- 
From: "Jonathan Lennox" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 09, 2010 4:16 PM
Subject: Re: I-D Action:draft-wu-avt-retransmission-supression-rtp-07.txt

[Qin]: Thanks.

[Qin]: Okay. I take it and will make it clear in the example use case of the new version.
--
Jonathan Lennox
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Nov 2010 22:08:14 +0800

> We put one new paragaraph at the end of Introduction section to explain Feedback Suppression should not adversely impact the repair of lost source packets and give some guidance (possibly non-norma…

That would be better in the normative part of the draft, rather than the introduction. It would also be desirable to explicitly cite the relevant section of RFC 4585 that discusses the timing rules for feedback.

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 09 Nov 2010 22:14:59 +0800

----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Jonathan Lennox" <[email-masked]>; <[email-masked]>; "Roni Even" <[email-masked]>
Sent: Tuesday, November 09, 2010 10:08 PM
Subject: Re: [AVT] Offline//Re: I-D Action:draft-wu-avt-retransmission-supression-rtp-07.txt

[Qin]: Okay, thank for this suggestion.

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Nov 2010 22:19:13 +0800

Tom,

As I said, the new message is an indication that the middlebox has been told that some receivers lost the packet. The middlebox sending a NACK is an indication that the middlebox saw the loss itself. Both cause other receivers to suppress their NACKs, but other devices may act differently in the two cases (e.g., local retransmission might work in one case, but not the other).

Colin

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

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 9 Nov 2010 17:22:00 +0100

Hi Colin,

Thanks, I do now understand the difference. So, sending a NACK to a receiver also results in suppression behaviour?  To be honnest, I had not deduced this from existing RFCs that when a RTP receiver receives a NACK, it should abstain from sending a NACK. Is that written somewhere in RFC 4585? Till now I believed we had to define this behaviour...

I also need to bring up again the association between (NACK) FB suppression and retransmission. The current draft does not bring the combined story, but then I think some fundamental aspect is ignored.
 
Suppose an RTP receiver X receives the NACK FB/ suppression indication, and it did not get the packet itself. The current draft now says a receiver that understands this message should not send a FB itself. This is problematic: how will the retransmission server then know that X would like a retransmission (too). If the policy at the retransmission server is that it will attempt retransmissions to all receivers that got the suppression message (either N x unicast or 1 x multicast), then that is fine from the RTP receiver X point of view. But the RTP receiver X does not know that this is the policy. So, it means there are good reasons for the RTP receiver X to still send the NACK FB message, despite having received a suppression indication/ NACK. 

So suppression indication will not reach its goal. I think it would hence be better to have language stating that a receiver MUST not send FB messages upon reception of suppression indication message/ NACK , making the suppression highly effective. It is then up to the retransmission server (or middlebox, whatever entity that sends the suppression message or NACK) to provide the retransmission (if any) to all receivers to which the suppression message/ NACK was sent. I may be mistaken, but I also do not really see a need to differentiate the RTP receiver behavior whether it gets a NACK or a suppression message.

Your and other people's comments are well appreciated,
Tom

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: dinsdag 9 november 2010 15:19
To: Van Caenegem, Tom (Tom)
Cc: IETF AVT WG
Subject: Re: [AVT] Offline//Re: I-D Action:draft-wu-avt-retransmission-supression-rtp-07.txt

Tom,

Colin

On 9 Nov 2010, at 18:04, Van Caenegem, Tom (Tom) wrote:
> Subject: Re: [AVT] Offline//Re: I-D 
> Action:draft-wu-avt-retransmission-supression-rtp-07.txt
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 11 Nov 2010 09:43:24 +0800

Tom,

> Thanks, I do now understand the difference. So, sending a NACK to a receiver also results in suppression behaviour?  To be honnest, I had not deduced this from existing RFCs that when a RTP receive…

Sure, it's in section 3 (in general terms in 3.2, and specifically the T_dither_max stuff later in 3.4 and 3.5 - especially page 17).

> So suppression indication will not reach its goal. I think it would hence be better to have language stating that a receiver MUST not send FB messages upon reception of suppression indication messa…

As we discussed in the RTCP guidelines draft, RTCP is not a reliable control channel. Stating "MUST NOT send feedback" doesn't make sense here, since you have to deal with lost suppression messages anyway. SHOULD NOT is fine here: don't try to over-optimise the system.

Colin

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

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 16 Nov 2010 11:51:59 +0100

Hi Colin,

Thx for the response. See below.

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: donderdag 11 november 2010 2:43
To: Van Caenegem, Tom (Tom)
Cc: IETF AVT WG
Subject: Re: [AVT] Offline//Re: I-D Action:draft-wu-avt-retransmission-supression-rtp-07.txt

Tom,

TOM: thx for this pointer! Based on RFC 4588, a receiver receiving a RTCP FB message (like NACK) in multi party session hence must not send immediately a corresponding RTCP FB message, and instead respect the normal RTCP packet transmission timing. I am now looking for architectures and cases where the dedicated suppression indication message is required to mitigate/prevent RTCP FB storm, and where a RTCP FB message (such as NACK) cannot be sent as currently defined in RFC 4588. 
IMO the RAMS case in particular as well as SSM with unicast feedback target(s) are not in need for such a specific message as a NACK will achieve the same goal. If a FB target is itself capable of detecting packet loss on its upstream link, it IS acting as a RTP receiver, and thus can send itself a (NACK) FB message to all other receivers.  Alternatively the FB target can relay RTCP FB message from RTP receivers reporting to this target, when it decides there is a FB storm threat. 

I call upon the authors of the suppression draft to come up with specific examples that justify the new message.

TOM: I do not see why you would define a less stringent behaviour for NACK/FB suppression compared to what is defined in RFC 4585 (which uses MUST (NOT) terminology). "should" does not really make sense. I agree that if the suppression indication message (or a NACK transmitted towards the receivers) gets dropped in the network, there MAY be a NACK storm anyhow (depends on network topology, use of multicast versus unicast and network location where message is dropped). The server/network may not be able to cope with that and so the result could be that receivers that send the NACK will not get a retransmission. Fine. Receivers sending a NACK, should indeed not rely on getting a retransmission anyhow. But what we ought to specify here is the receiver behaviour when a receiver does get the suppression indication. This is not about reliability nor about over-optimisation. If we just say a receiver 'SHOULD NOT" send a NACK, we defeat the purpose of suppression indication, and this purpose is ultimately to maximise the chance that as many receivers as possibly can, still get a retransmission. Furthermore, once you start using "SHOULD" terminology, we also need to explain where/when it is still "justified" a RTP receiver does send a NACK when getting a suppression indication. I remain convinced "MUST NOT" is justified here and the right choice, similar as per RFC 4585. 

But again, IMO there is no need to define anything new here, as FB suppression is already defined in RFC 4585. 

Tom

Colin

> Your and other people's comments are well appreciated, Tom
> 
> 
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 16 Nov 2010 11:19:41 +0000

Tom,

As we have discussed before: while both cause feedback suppression, the semantics of the two messages are different (they indicate that different hosts lost the packet). This difference is important, and is a reason for defining the new message.

Colin

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