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

Hi,
----- Original Message ----- 
From: "Roni Even" <even.roni@huawei.com>
To: "'Qin Wu'" <bill.wu@huawei.com>; "'Van Caenegem, Tom (Tom)'" <tom.van_caenegem@alcatel-lucent.com>; "'Colin Perkins'" <csp@csperkins.org>
Cc: "'IETF AVTCore WG'" <avt@ietf.org>
Sent: Monday, July 04, 2011 12:51 AM
Subject: 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?

[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.

> 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/
>> 
> 
>