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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 9 Nov 2010 08:31:48 -0800

As I expressed in the session as well, I think the message sent downstream should only mean "I have not seen this and that packet and you will likely not see it, either". It should not say anything at all like "oh, don’t worry retransmission is on its way, or don't send a NACK we know the packets are missing." An external parameter (e.g., in SDP) or something like that can be defined to tell the clients to suppress their NACKs upon receiving that message but the message itself should not say it. Without such a parameter, the client can do whatever it wants to do based on the regular 4585 rules. So, I would not call this message a "suppression" message, rather I would call it an "indication" message.

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Van Caenegem, Tom (Tom)
> Sent: Wednesday, November 10, 2010 12:22 AM
> To: Colin Perkins
> Cc: IETF AVT WG
> Subject: Re: [AVT] Offline//Re: I-D Action:draft-wu-avt-retransmission-supression-rtp-07.txt
> 
> 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,
> 
> 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
> 
> 
> 
> On 9 Nov 2010, at 18:04, Van Caenegem, Tom (Tom) wrote:
> > 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
> >
> > 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/
> >
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt