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

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

> -----Original Message-----
> From: Qin Wu [mailto:bill.wu@huawei.com]
> Sent: Thursday, June 30, 2011 12:36 PM
> 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)" <tom.van_caenegem@alcatel-lucent.com>
> To: "Qin Wu" <bill.wu@huawei.com>; "Colin Perkins" <csp@csperkins.org>
> Cc: "'IETF AVTCore WG'" <avt@ietf.org>; "Roni Even"
> <Even.roni@huawei.com>
> 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.
> 
> [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?
> 
> 
> Regards!
> -Qin
> ----- Original Message -----
> From: "Colin Perkins" <csp@csperkins.org>
> To: "Van Caenegem, Tom (Tom)" <tom.van_caenegem@alcatel-lucent.com>
> Cc: "Qin Wu" <sunseawq@huawei.com>; "'IETF AVTCore WG'" <avt@ietf.org>;
> "Roni Even" <Even.roni@huawei.com>
> 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
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 