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

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 21 Jun 2011 11:29:53 +0200

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"? 

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

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

Regards
Tom

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Jun 2011 15:07:58 +0100

> -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 re…

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…

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. 

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 21 Jun 2011 17:04:23 +0200

Hi Colin,

Thx for sharing your view. See below. 

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: dinsdag 21 juni 2011 16:08
To: Van Caenegem, Tom (Tom)
Cc: Qin Wu; 'IETF AVTCore WG'; Roni Even
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04

Tom: well.. This is a  new element you bring in here.. I can only guess why this rationale has not been explicitly included before in a WG document? Did I miss this discussion? It is certainly not aligned with the text/reasoning in the draft because a DS operating in simple FB mode is an example where the forwarding of NACKs seems to be the right thing to do (and not sending the 3rd party loss report) whereas a DS in summary FB mode is an example that would send 3rd party loss message. Why is hiding the identity an issue for the latter case (SSM in summary mode) and not for the former case (simple FB mode)? 

Also, the draft is about FB storm suppression which is also realised with NACKs as you know... An incoming NACK can also be "anonimised" by having the DS or the FT acting as a translator for this NACK message. See draft-vancaenegem-avtcore-retransmission-for-ssm-00.

Tom: why is keeping state "required" here? Keeping state of what? 

> Audio/Video Transport Core Maintenance [email-masked] 

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Jun 2011 16:12:44 +0100

> Tom: well.. This is a  new element you bring in here.. I can only guess why this rationale has not been explicitly included before in a WG document? Did I miss this discussion? It is certainly not…

This is the purpose of summary feedback mode of RTCP-SSM: to limit the distribution of state for all participants, and instead give a summary. 

> Also, the draft is about FB storm suppression which is also realised with NACKs as you know... An incoming NACK can also be "anonimised" by having the DS or the FT acting as a translator for this N…

I know that NACKs suppress feedback. That doesn't invalidate the need for a third party loss report that also suppresses feedback, for the cases where it's not appropriate to use a NACK, such as the summary feedback mode of RTCP-SSM.

> Tom: why is keeping state "required" here? Keeping state of what? 

RTCP state, since they'll see a NACK from a participant of which they were previously unaware.

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 21 Jun 2011 08:39:14 -0700

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

But, they could be keeping that state anyway for other RTCP they saw from other peers.

-acbegen

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 21 Jun 2011 17:42:44 +0200

Colin,

What you say makes sense, but my feeling is that the rationale for defining the 3rd party loss report should be much better defined in the WG document, potentially along the lines you mentioned (but does it go beyond SSM in summary mode architectures?). The only rationale explicitly provided, is the one in the introduction which contains other reasoning which are partly incorrect. So I call upon the authors of the WG draft to revise the text. 
Tom

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: dinsdag 21 juni 2011 17:13
To: Van Caenegem, Tom (Tom)
Cc: Qin Wu; 'IETF AVTCore WG'; Roni Even
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04

On 21 Jun 2011, at 16:04, Van Caenegem, Tom (Tom) wrote:
>> Subject: Re: [AVTCORE] Comments on 
>> draft-ietf-avtcore-feedback-supression-rtp-04
>> 

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Jun 2011 16:42:05 +0100

> But, they could be keeping that state anyway for other RTCP they saw from other peers.

In summary feedback mode, they don't see the RTCP from the other peers, just the summary reports from the DS. 

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 21 Jun 2011 08:47:23 -0700

> Sent: Tuesday, June 21, 2011 5:42 PM
> To: Ali C. Begen (abegen)
> Cc: Van Caenegem, Tom (Tom); IETF AVTCore WG
> Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-04
> 
> >>>> 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.
> >>>>

Agreed. What I was trying to say is that in the simple feedback model, seeing the NACKs from others will not necessarily increase the amount of state information since sooner or later, peers will see each other's RTCP anyway. In the summary mode, using a new report is fine with me (and I agree with Tom that the draft needs a bit improvement on the motivation part).

-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Jun 2011 16:52:22 +0100

> Agreed. What I was trying to say is that in the simple feedback model, seeing the NACKs from others will not necessarily increase the amount of state information since sooner or later, peers will s…

Sure, make sense.

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

---

From: Qin Wu <[email-masked]>
Date: Wed, 22 Jun 2011 10:39:59 +0800

I agree with Colin's observation. 
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

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

> 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, wh…

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

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

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 28 Jun 2011 11:21:17 +0200

Qin,
See my comments below,
Tom

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
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

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"

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

> -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 re…

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

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

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Thu, 30 Jun 2011 11:07:59 +0200

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]: 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  ???

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

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

---

From: Qin Wu <[email-masked]>
Date: Thu, 30 Jun 2011 17:35:36 +0800

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,

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]: 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" <[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

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

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Thu, 30 Jun 2011 11:47:44 +0200

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,

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.

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

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