Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04

From: Colin Perkins <[email-masked]>
Date: Sat, 2 Jul 2011 13:25:08 +0100

On 30 Jun 2011, at 10:47, Van Caenegem, Tom (Tom) wrote:
> Qin,
> See below
> Tom
> -----Original Message-----
> From: Qin Wu [mailto:[email-masked]] 
> Sent: donderdag 30 juni 2011 11:36
> To: Van Caenegem, Tom (Tom); Colin Perkins
> Cc: 'IETF AVTCore WG'; Roni Even; Qin Wu
> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04
> 
> Hi,
> ----- Original Message -----
> From: "Van Caenegem, Tom (Tom)" <[email-masked]>
> To: "Qin Wu" <[email-masked]>; "Colin Perkins" <[email-masked]>
> Cc: "'IETF AVTCore WG'" <[email-masked]>; "Roni Even" <[email-masked]>
> Sent: Thursday, June 30, 2011 5:07 PM
> Subject: RE: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04
> 
> 
> Qin,
> See below,
> 
> 
> [Qin]: Okay, maybe there is some ambiguity on describing media source behavior. I will add some texts to get consistent with 
> Intermediary behavior of suppressing feedback described in the previous paragraph.
> The proposed text may look like:
> "
> Alternatively, the media source may directly monitor the amount of
>   feedback reports it receives from downstream.  If the media source notices the loss itself, then it
>   may send a NACK downstream towards the receivers to suppress feedback. If the media source
>   receives a NACK from another system, it should redistribute that NACK
>   to all other systems that would not otherwise receive it.  An example
>   of this is RTCP-SSM in simple feedback model [RFC5760], where the
>   distribution source reflects NACKs to other systems.  If the media source
>   receives a NACK from another system, but, for some
>   reason, cannot redistribute that NACK, then it may send a third-party
>   loss report to the systems that were unable to receive the NACK, and
>   won't receive the NACK via other means.  An example would be a
>   distribution source using RTCP-SSM in Distribution Source Feedback
>   Summary model [RFC5760].
> "
> 
> 
> Tom: the "for some reason" will have to be clarified. I also do not understand:  "may send a third-party loss report to the systems that were unable to receive the NACK"  Based on the rationale provided by Colin why one may not always simply forward/redistribute NACKs, this is not a matter of systems being "UNABLE" to receive the NACK. They are always able, it is just a decision from the intermediate to not FW the received NACKs.
> 
> [Qin]:  No, basic rationale is prevent the receivers know who send NACK. 
> In SSM case, the rationale is Distribution Source Feedback Summary model does not allow the NACK to be forwarded downstream.
> 
> Tom: In RFC 5760 for SSM in FB summary mode, the DS might also forward RTCP feedback messages and transmit them in the SSM session, when this is explicitly signaled. It is a service/deployment decision whether NACKs are hence FW-ed or not, and there may be good reasons to not do so, but saying that such systems(i..e RTP Rx) are unable to receive the NACK is not justified IMO.

It might be clearer to say that the receivers don't get the NACKs, since they're not forwarded by the distribution source.

Colin

> [Qin]: I agree we should follow RFC5760 architecture. But I am not sure the example I give in the section 6.1.1 conflict with  RFC5760 architecture.
> The architecture I bulild looks like this:
> Suppose there are 100 RTP receivers, in these receivers, 50 RTP receivers belong to DS A, 50 RTP receivers belong to DS B, DS A may be placed at the upstream
> of DS B or DS A is adjacent to DS B at the same level, Do this kind architecture conflict with RFC5760? If yes, please point out.
> 
> Tom: a DS represents the source/RTP sender of the SSM RTP session. Receivers send out NACKs related to packet loss in a particular SSM RTP session. If a receiver is not "belonging" to a DS X (I guess you mean ..is not receiving packets from that DS X), then why would you implement some kind of FB suppression for such receiver(s) within the SSM RTP session that is sourced by that DS X  ???
> 
> [Qin]: What I am saying here each DS has its own coverage for receivers. You can implement FB suppression for each DS. But you are not necessary to prevent interaction between DS.
> Anyway since you or other folks may think this multiple DS case introduce ambiguity and complexity, I will remove this case from the draft, Is that okay with you?
> 
> Tom: Fine! 
> 
> Regards!
> -Qin
> ----- Original Message -----
> From: "Colin Perkins" <[email-masked]>
> To: "Van Caenegem, Tom (Tom)" <[email-masked]>
> Cc: "Qin Wu" <[email-masked]>; "'IETF AVTCore WG'" <[email-masked]>; "Roni Even" <[email-masked]>
> Sent: Tuesday, June 21, 2011 10:07 PM
> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04
> 
> 
> On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote:
>> Hi,
>> 
>> as promised, these are comments I have on the draft " RTCP Extension for Third-party Loss Report"
>> 
>> -IMO the draft does not provide a good rationale on the use case for sending this new report. The section 3 (protocol overview) says:
>> 
>> "If an intermediary receives a NACK from another system, it should redistribute that NACK to all other systems that would not otherwise receive it.  An example of this is RTCP-SSM in simple feedback model [RFC5760], where the distribution source reflects NACKs to other systems.   
>> If an intermediary receives a NACK from another system, but, for some reason, cannot redistribute that NACK, then it may send a third-party loss report to the systems that were unable to receive the NACK, and won't receive the NACK via other means. An example would be a distribution source using RTCP-SSM in Distribution Source Feedback Summary model [RFC5760]."
>> 
>> My questions: 
>> 
>> -why would the intermediary not be able or capable to send the received NACK to the "systems" that were unable to receive the NACK, whereas it would be able or capable to send the 3rd party loss report to those same "systems"? 
> 
> Because the intermediary is trying to hide the identity or existence of those systems, and cannot forward the NACK from them without revealing that information
> 
>> -The DS in RTCP-SSM operating in FB summary mode is mentioned as an example for a case where a NACK cannnot be forwarded. Why is this?  RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and my quote from that RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00"
> 
> RFC 5760 allows the NACK to be forwarded, but this would cause the other receivers to become aware of, and keep state for, the participant that sent the NACK. If a third-party loss report is used, the other receivers don't become aware of the participant that signalled the loss, they just know that the loss occurred. 
> 
>> -This section 3 makes a distinction between an intermediate that does check the RTP stream for missing packets itself, and an intermediate that does not, but still the behaviour in terms of FW-ing the NACKs received from other "systems" is exactly the same. Why make this distinction then?
>> 
>> I still have an outstanding comment which has not been resolved yet. The section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but section 6.1.1. talks about two distribution sources, whereas RFC 5760 only defined ONE SINGLE DS. Please clarify this.
> 
> [Qin]: two distribution sources means we have two levels of SSM communication, one distribution souce is placed at the upstream of the other distribution source.
> two distribution sources case is just one exmaple to discuss how to use new report when there are multiple middleboxs or intermediaries between media source and the receivers. 
> The middlebox can be distribution source and can be other intermediary.
> 
>> 
>> Regards
>> Tom
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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

---

From: Roni Even <[email-masked]>
Date: Sun, 03 Jul 2011 19:51:54 +0300

Hi,
I think that we can look at the following use cases.

1. The single DS /FT in a Distribution Source Feedback Summary Model. The
case mentioned by Collin using 3rd party report to hide the topology.

2. A single DS with multiple FT. See RFC 5760 section 3 in the FT
definition. In this case I am not sure if there is a DS without any FT with
multiple FTs or one DS with a FT and multiple FTs sending unicast RTCP
feedback to the FT co-located with the DS. Maybe we need to look at both
cases.

3. RFC 5760 talks about single DS. Is there a use case for multiple DSs
where each DS is in a different SSRC space with one media source
transmitting to all. Is there such a case, maybe if there is some hierarchy
which may look like a DS which is also an RTP mixer or translator.

Does these use cases make sense?

Are there others

Regards
Roni

> Sent: Thursday, June 30, 2011 12:36 PM
> [Qin]: Okay, maybe there is some ambiguity on describing media source
> behavior. I will add some texts to get consistent with
> Tom: the "for some reason" will have to be clarified. I also do not
> understand:  "may send a third-party loss report to the systems that
> were unable to receive the NACK"  Based on the rationale provided by
> Colin why one may not always simply forward/redistribute NACKs, this is
> not a matter of systems being "UNABLE" to receive the NACK. They are
> always able, it is just a decision from the intermediate to not FW the
> received NACKs.
> 
> In SSM case, the rationale is Distribution Source Feedback Summary
> model does not allow the NACK to be forwarded downstream.
> 
> [Qin]: I agree we should follow RFC5760 architecture. But I am not sure
> the example I give in the section 6.1.1 conflict with  RFC5760
> architecture.
> Suppose there are 100 RTP receivers, in these receivers, 50 RTP
> receivers belong to DS A, 50 RTP receivers belong to DS B, DS A may be
> placed at the upstream
> of DS B or DS A is adjacent to DS B at the same level, Do this kind
> architecture conflict with RFC5760? If yes, please point out.
> 
> Tom: a DS represents the source/RTP sender of the SSM RTP session.
> Receivers send out NACKs related to packet loss in a particular SSM RTP
> session. If a receiver is not "belonging" to a DS X (I guess you mean
> ..is not receiving packets from that DS X), then why would you
> implement some kind of FB suppression for such receiver(s) within the
> SSM RTP session that is sourced by that DS X  ???
> 
> [Qin]: What I am saying here each DS has its own coverage for
> receivers. You can implement FB suppression for each DS. But you are
> not necessary to prevent interaction between DS.
> Anyway since you or other folks may think this multiple DS case
> introduce ambiguity and complexity, I will remove this case from the
> draft, Is that okay with you?
> 
> 
> Regards!
> -Qin
> > -IMO the draft does not provide a good rationale on the use case for
> sending this new report. The section 3 (protocol overview) says:
> >
> > "If an intermediary receives a NACK from another system, it should
> redistribute that NACK to all other systems that would not otherwise
> receive it.  An example of this is RTCP-SSM in simple feedback model
> [RFC5760], where the distribution source reflects NACKs to other
> systems.
> > If an intermediary receives a NACK from another system, but, for some
> Summary model [RFC5760]."
> >
> > My questions:
> >
> > -why would the intermediary not be able or capable to send the
> received NACK to the "systems" that were unable to receive the NACK,
> whereas it would be able or capable to send the 3rd party loss report
> to those same "systems"?
> 
> Because the intermediary is trying to hide the identity or existence of
> those systems, and cannot forward the NACK from them without revealing
> that information
> 
> > -The DS in RTCP-SSM operating in FB summary mode is mentioned as an
> example for a case where a NACK cannnot be forwarded. Why is this?
> RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and
> my quote from that RFC in "draft-vancaenegem-avtcore-retransmission-
> for-ssm-00"
> 
> RFC 5760 allows the NACK to be forwarded, but this would cause the
> other receivers to become aware of, and keep state for, the participant
> that sent the NACK. If a third-party loss report is used, the other
> receivers don't become aware of the participant that signalled the
> loss, they just know that the loss occurred.
> 
> > -This section 3 makes a distinction between an intermediate that does
> check the RTP stream for missing packets itself, and an intermediate
> that does not, but still the behaviour in terms of FW-ing the NACKs
> received from other "systems" is exactly the same. Why make this
> distinction then?
> >
> > I still have an outstanding comment which has not been resolved yet.
> The section 6.1. and 6.1.1. take RFC 5760 as use case architectures,
> but section 6.1.1. talks about two distribution sources, whereas RFC
> 5760 only defined ONE SINGLE DS. Please clarify this.
> 
> [Qin]: two distribution sources means we have two levels of SSM
> communication, one distribution souce is placed at the upstream of the
> other distribution source.
> two distribution sources case is just one exmaple to discuss how to use
> new report when there are multiple middleboxs or intermediaries between
> media source and the receivers.

---

From: Qin Wu <[email-masked]>
Date: Thu, 07 Jul 2011 14:08:52 +0800

Hi,
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Van Caenegem, Tom (Tom)" <[email-masked]>
Cc: "Qin Wu" <[email-masked]>; "'IETF AVTCore WG'" <[email-masked]>
Sent: Saturday, July 02, 2011 8:25 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04

[Qin]: Okay. I agree.

Colin

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

---

From: Qin Wu <[email-masked]>
Date: Thu, 07 Jul 2011 14:24:47 +0800

Hi,
----- Original Message ----- 
From: "Roni Even" <[email-masked]>
To: "'Qin Wu'" <[email-masked]>; "'Van Caenegem, Tom (Tom)'" <[email-masked]>; "'Colin Perkins'" <[email-masked]>
Cc: "'IETF AVTCore WG'" <[email-masked]>
Sent: Monday, July 04, 2011 12:51 AM
Subject: RE: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04

> Does these use cases make sense?

[Qin]: I think These three cases are all SSM use case. 
Current draft covers case 1 and case 3. 
But according to  Tom's comments,
case 3 may introduce too much confusion and complexity. 
I am going to leave this case out since the focus of this draft is 
on  usage of  new message in the SSM general use case.

As for case 2, draft-vancaenegem-avtcore-retransmission-for-ssm-00
 discusses a lot about how to extend protocol 
to provide better retransmission. some part is relevant to this draft. 
But I guess updating RFC5760 or  rule changing of RFC5760 is required.