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

Qin,
See my comments below,
Tom

-----Original Message-----
From: Qin Wu [mailto:sunseawq@huawei.com] 
Sent: woensdag 22 juni 2011 4:40
To: Colin Perkins; Van Caenegem, Tom (Tom)
Cc: 'IETF AVTCore WG'; Roni Even
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04

I agree with Colin's observation. 

Tom: I suggest you to then include this new rationale in an updated version of the draft

Another basic rational I think is we should use NACK and new report appropriately. i.e., both new report and NACK can not be used in any cases.

NACK and new report defined in this document are both feedback message, however they should have different uses.
we don't expect to see that when NACK is sent from A to B, the new report can replace NACK as one  alternative and is also sent from A to B. But we allow that NACK and new report work together in the same sceanrio, e.g.,when NACK is sent from A to B, the new report is sent from B to C. 

The basic reason is NACK and new report has totally different semantics, i.e., when the middlebox or media source detect the packet loss by himself, the middlebox or media source SHOULD send NACK message, when the middlebox is told by another middlebox or RTP_Reciever about the packet loss, the middlebox SHOULD send new report defined in this draft.

In that case, we can clearly distinguish the semantics and use of both NACK and new report. 
Such rational is clearly described in the last paragraph of section 1 and the fifth paragraph of section 2

Tom: what you say above seems to be in conflict with the behaviour you specify in section 3:  "Alternatively, the media source may directly monitor the amount of
   feedback reports it receives from downstream.  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"

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

Tom: Again, if your provide an example of an RFC 5760 architecture, you can only talk about one DS!
Please clarify your architecture. If you have two DS, then you have two SSM RTP sessions.. What's the point of linking these? What is your use case?

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/