Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-07.txt

From: Colin Perkins <[email-masked]>
Date: Mon, 10 Oct 2011 22:46:30 +0100

On 26 Sep 2011, at 09:17, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.
> 
> 	Title           : RTCP Extension for Third-party Loss Report
> 	Author(s)       : Qin Wu
>                          Frank Xia
>                          Roni Even
> 	Filename        : draft-ietf-avtcore-feedback-supression-rtp-07.txt
> 	Pages           : 16
> 	Date            : 2011-09-26
> 
>   In a large RTP session using the RTCP feedback mechanism defined in
>   RFC 4585, a feedback target may experience transient overload if some
>   event causes a large number of receivers to send feedback at once.
>   This overload is usually avoided by ensuring that feedback reports
>   are forwarded to all receivers, allowing them to avoid sending
>   duplicate feedback reports.  However, there are cases where it is not
>   recommended to forward feedback reports, and this may allow feedback
>   implosion.  This memo discusses these cases and defines a new RTCP
>   third-party loss report that can be used to inform receivers that the
>   network is aware of some loss event, allowing them to suppress
>   feedback.  Associated SDP signalling is also defined.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-07.txt

I have read this draft, and have some comments:

- Section 1, 1st paragraph: "(e.g, implementing the RFC 4585" - should this be "(e.g., not implementing the RFC 4585"?

- Section 3, 3rd paragraph, says the "timer value shall be based on the observed round-trip time", but it's not clear that this means. By based on, do you mean equal to the RTT, or some other function derived from it? Which RTT? The suppression, ideally, wants to be for long enough for the sender of the TPLR to somehow repair the loss at all of its downstream receivers, so none of them need to resend a NACK. This might imply the RTT from the receiver to the original media source and/or repair server be used, which is different from the RTT specified. I think some more thought is needed here.

- Section 3, 4th paragraph: "In the case the first TPLR is lost and the additional TPLR arrives at the receiver, the receiver should immediately refresh the timer" - sure, but what else would it do? This makes it seem that something different is done in this case, but the behaviour looks to be the same whether or not a TPLR is lost.

- Section 6.3: if a monitor co-located with a translator detects a loss, why does that monitor not send a NACK? Not clear what's the reason for using a TPLR here.

- Section 6.5: the behaviour described makes sense for an RTP-terminating mixer, but an RFC 3550 mixer could just forward the FIR or PLI messages without using the TPLR, no?

I also have a number of more minor, mostly editorial, suggestions:

- Abstract: change "that the network is aware" to "that the feedback target is aware"

- Section 1, 1st paragraph: "as a packet loss recovery technique based, sending" -> "as a packet loss recovery technique, sending"

- Section 1, 4th paragraph: "while the case the" -> "while the case where the"

- Section 1, 4th paragraph: last sentence is repeated

- Section 3, 2nd paragraph: "generated by a RTP system" -> "generated by an RTP system"

- Section 3, 2nd paragraph: "as per AVPF" -> "as per the RTP/AVPF rules"

- Section 3, 2nd paragraph: "SHOULD NOT initiate their own additional" -> "SHOULD NOT send their own additional"

- Section 3, 4th paragraph: what is meant by "a transmission packet"? Do you mean an RTP data packet, or some other RTCP packet?

- Section 3, 4th paragraph: not sure what is meant by "a receiver is allowed to receive additional TPLR" - when would it not be allowed to receive? Would this be better saying that the sending an generate an additional TPLR?

- Section 3, 5th paragraph: "may still have sent" -> "may have sent"

- Section 3, 5th paragraph: "will be suppressed by this technique for a certain period of time" -> "SHOULD be suppressed for a period of time after receiving the TPLR"?

- Section 3, 6th paragraph: what is meant by "closer to the source" in this paragraph? 

- Section 4.1: "bitmask of proceeding lost packets" -> "bitmask of lost packets"

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 11 Oct 2011 16:11:01 +0800

Hi, Colin:
Thank for your careful review, please see my replies belows.

Regards!
-Qin
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 11, 2011 5:46 AM
Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt

> - Section 1, 1st paragraph: "(e.g, implementing the RFC 4585" - should this be "(e.g., not implementing the RFC 4585"?

[Qin]:It is a typo and my mistake. Thank for catching it.

> - Section 3, 3rd paragraph, says the "timer value shall be based on the observed round-trip time", but it's not clear that this means. By based on, do you mean equal to the RTT, or some other funct…

[Qin]: See my discussion with Magnus in the previous email on this thread. But that need some corrections. I think you are right, If the middlbox is repair server, more approximate RTT is the RTT from the receiver and repair server. If the original media is repair server, more approximate RTT should be 1/2 of RTT between the middlebox and receiver plus RTT from middlebox to media source. But if the middlebox sending TPLR is more close to media source, one RTT from middlebox to media source can be omitted.

> - Section 3, 4th paragraph: "In the case the first TPLR is lost and the additional TPLR arrives at the receiver, the receiver should immediately refresh the timer" - sure, but what else would it do…

[Qin]: Assume the middlebox sending NACK upstream and TPLR downstream at the same time,refresh timer means waiting for one RTT from media source to get the retransmitted RTP data packet after getting that additional TPLR, however if the middlebox itself is repair server, the timer should be same irrespectively a TPLR is lost, i.e., 1/2 RTT from middlebox to the receiver.

> - Section 6.3: if a monitor co-located with a translator detects a loss, why does that monitor not send a NACK? Not clear what's the reason for using a TPLR here.

[Qin]:That's becos translator has a monitor, which told translator to send TPLR, if translator has no monitor and receives NACK from a receiver, this receiver should forward NACK directly. Does this clarify?

> - Section 6.5: the behaviour described makes sense for an RTP-terminating mixer, but an RFC 3550 mixer could just forward the FIR or PLI messages without using the TPLR, no?

[Qin]: According to Section 7.3 of RFC 3550, a mixer must not forward RTCP unaltered between
   the two domains, also according to section 3.4 of RFC5117, In some cases, the reception
   of a codec-control message may result in the generation and
   transmission of RTCP feedback messages by the Mixer to the
   participants in the other domain.  
  So I think this is not a issue.

> - Abstract: change "that the network is aware" to "that the feedback target is aware"

[Qin]: Okay, fixed.

> - Section 1, 1st paragraph: "as a packet loss recovery technique based, sending" -> "as a packet loss recovery technique, sending"

[Qin]: Okay, fixed.

> - Section 1, 4th paragraph: "while the case the" -> "while the case where the"

[Qin]: Okay, fixed.
> - Section 1, 4th paragraph: last sentence is repeated

[Qin]: Okay, fixed.
> - Section 3, 2nd paragraph: "generated by a RTP system" -> "generated by an RTP system"

[Qin]: Okay, fixed.
> - Section 3, 2nd paragraph: "as per AVPF" -> "as per the RTP/AVPF rules"

[Qin]: Okay, fixed.
> - Section 3, 2nd paragraph: "SHOULD NOT initiate their own additional" -> "SHOULD NOT send their own additional"

[Qin]: Okay, fixed.
> - Section 3, 4th paragraph: what is meant by "a transmission packet"? Do you mean an RTP data packet, or some other RTCP packet?

[Qin]: RTP data packet. I will fix this by adding some explanation text.

> - Section 3, 4th paragraph: not sure what is meant by "a receiver is allowed to receive additional TPLR" - when would it not be allowed to receive? Would this be better saying that the sending an g…

[Qin]: Okay, fixed.
> - Section 3, 5th paragraph: "may still have sent" -> "may have sent"

[Qin]: Okay, fixed.
> - Section 3, 5th paragraph: "will be suppressed by this technique for a certain period of time" -> "SHOULD be suppressed for a period of time after receiving the TPLR"?

[Qin]: Okay, fixed.
> - Section 3, 6th paragraph: what is meant by "closer to the source" in this paragraph? 

[Qin]: means the location of middlebox is more closer to the media source. 
I will fix this by adding some explanation text.

> - Section 4.1: "bitmask of proceeding lost packets" -> "bitmask of lost packets"

[Qin]: Okay, fixed.
> 
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 11 Oct 2011 11:51:51 +0200

Hi,
the notion of a "middlebox" is frequently used for justifying sth in the discussion below, but a reference to such a device is not really provided.
There seems to be two possible interpretations:
"Middlebox" 
a) = MIDCOM-compliant middlebox (and then a reference to definition § 2.2/RFC 3303 could be added)
b) = a network intermediate device that implements unknown services on top of IP packet forwarding (i.e., a block box with unknown behaviour).

I suppose that interpretation (b) is supposed here, - and thus slightly concerned that such a definition may be used to justify "any kind of requirement":-)

Regards,
Albrecht

PS
Similar is "repair server", but such a device is not mentioned in the draft.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Qin Wu
> Sent: Dienstag, 11. Oktober 2011 10:11
> To: Colin Perkins; [email-masked]
> Subject: Re: [AVTCORE] I-D 
> Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt
> 
> Hi, Colin:
> Subject: Re: [AVTCORE] I-D 
> Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt
> 
> 
> >> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories. This draft is a work item of the 
> Audio/Video Transport Core Maintenance Working Group of the IETF.
> >> 
> > - Section 1, 1st paragraph: "(e.g, implementing the RFC 
> 4585" - should this be "(e.g., not implementing the RFC 4585"?
> 
> > - Section 3, 3rd paragraph, says the "timer value shall be 
> based on the observed round-trip time", but it's not clear 
> that this means. By based on, do you mean equal to the RTT, 
> or some other function derived from it? Which RTT? The 
> suppression, ideally, wants to be for long enough for the 
> sender of the TPLR to somehow repair the loss at all of its 
> downstream receivers, so none of them need to resend a NACK. 
> This might imply the RTT from the receiver to the original 
> media source and/or repair server be used, which is different 
> from the RTT specified. I think some more thought is needed here.
> > 
> 
> [Qin]: See my discussion with Magnus in the previous email on 
> this thread. But that need some corrections. I think you are 
> right, If the middlbox is repair server, more approximate RTT 
> is the RTT from the receiver and repair server. If the 
> original media is repair server, more approximate RTT should 
> be 1/2 of RTT between the middlebox and receiver plus RTT 
> from middlebox to media source. But if the middlebox sending 
> TPLR is more close to media source, one RTT from middlebox to 
> media source can be omitted.
> 
> > - Section 3, 4th paragraph: "In the case the first TPLR is 
> lost and the additional TPLR arrives at the receiver, the 
> receiver should immediately refresh the timer" - sure, but 
> what else would it do? This makes it seem that something 
> different is done in this case, but the behaviour looks to be 
> the same whether or not a TPLR is lost.
> 
> [Qin]: Assume the middlebox sending NACK upstream and TPLR 
> downstream at the same time,refresh timer means waiting for 
> one RTT from media source to get the retransmitted RTP data 
> packet after getting that additional TPLR, however if the 
> middlebox itself is repair server, the timer should be same 
> irrespectively a TPLR is lost, i.e., 1/2 RTT from middlebox 
> to the receiver.
> 
> 
> > - Section 6.3: if a monitor co-located with a translator 
> detects a loss, why does that monitor not send a NACK? Not 
> clear what's the reason for using a TPLR here.
> 
> [Qin]:That's becos translator has a monitor, which told 
> translator to send TPLR, if translator has no monitor and 
> receives NACK from a receiver, this receiver should forward 
> NACK directly. Does this clarify?
> 
> > - Section 6.5: the behaviour described makes sense for an 
> RTP-terminating mixer, but an RFC 3550 mixer could just 
> forward the FIR or PLI messages without using the TPLR, no?
> 
> > - Section 1, 1st paragraph: "as a packet loss recovery 
> technique based, sending" -> "as a packet loss recovery 
> technique, sending"
> 
> [Qin]: Okay, fixed.
> 
> > 
> > - Section 3, 2nd paragraph: "SHOULD NOT initiate their own 
> additional" -> "SHOULD NOT send their own additional"
> 
> [Qin]: Okay, fixed.
> > 
> > - Section 3, 4th paragraph: what is meant by "a 
> transmission packet"? Do you mean an RTP data packet, or some 
> other RTCP packet?
> 
> > - Section 3, 4th paragraph: not sure what is meant by "a 
> receiver is allowed to receive additional TPLR" - when would 
> it not be allowed to receive? Would this be better saying 
> that the sending an generate an additional TPLR?
> 
> [Qin]: Okay, fixed.
> > 
> > - Section 3, 5th paragraph: "will be suppressed by this 
> technique for a certain period of time" -> "SHOULD be 
> suppressed for a period of time after receiving the TPLR"?
> 
> [Qin]: Okay, fixed.
> >

---

From: Qin Wu <[email-masked]>
Date: Tue, 11 Oct 2011 20:06:19 +0800

Hi, Albrecht:
Thank for your comment, I agree with your clarification and will be careful with terms using
in the draft.

Regards!
-Qin
----- Original Message ----- 
From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Colin Perkins" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 11, 2011 5:51 PM
Subject: RE: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt

Hi,

Regards,
Albrecht

PS

> =

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 11 Oct 2011 14:17:05 +0200

Please note that there's also a definition of middlebox in draft-ietf-avtcore-ecn-for-rtp, which might be also applicable.
-Albrecht 

> Sent: Dienstag, 11. Oktober 2011 14:06
> To: Schwarz, Albrecht (Albrecht); Colin Perkins; [email-masked]
> Thank for your comment, I agree with your clarification and 
> will be careful with terms using in the draft.
> 
> Regards!
> -Qin
> Subject: RE: [AVTCORE] I-D 
> the notion of a "middlebox" is frequently used for justifying 
> sth in the discussion below, but a reference to such a device 
> is not really provided.
> a) = MIDCOM-compliant middlebox (and then a reference to 
> definition § 2.2/RFC 3303 could be added)
> b) = a network intermediate device that implements unknown 
> services on top of IP packet forwarding (i.e., a block box 
> with unknown behaviour).
> 
> I suppose that interpretation (b) is supposed here, - and 
> thus slightly concerned that such a definition may be used to 
> justify "any kind of requirement":-)
> 
> Regards,
> Albrecht
> 
> PS
> > >> Filename        : 
> draft-ietf-avtcore-feedback-supression-rtp-07.txt
> > >> Pages           : 16
> > >> Date            : 2011-09-26
> > >>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 11 Oct 2011 15:13:22 +0100

Qin,

> [Qin]: See my discussion with Magnus in the previous email on this thread. But that need some corrections. I think you are right, If the middlbox is repair server, more approximate RTT is the RTT f…

How does the receiver of the TPLR know the RTT value to use? It doesn't seem to have the information it needs to calculate this.

> [Qin]: Assume the middlebox sending NACK upstream and TPLR downstream at the same time,refresh timer means waiting for one RTT from media source to get the retransmitted RTP data packet after getti…

I don't understand. The receiver of a TPLR cannot know if a previous TPLR has been lost, therefore it will behave the same in both cases.

> [Qin]:That's becos translator has a monitor, which told translator to send TPLR, if translator has no monitor and receives NACK from a receiver, this receiver should forward NACK directly. Does thi…

No, since an RTCP translator can't send a TPLR as it doesn't have an SSRC. The monitor has its own SSRC, and so can send RTCP reports, and should send a NACK packet since it is the monitor that detects the loss.

>  So I think this is not a issue.

I disagree. There are two valid ways to process RTCP FIR or PLI messages in a mixer: either do as you describe and send a TPLR message, or forward the FIR/PLI to all participants. Both are valid behaviours, yet your draft only mentions one of them. It should mention both.

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Oct 2011 10:48:46 +0800

Sorry for late reply. please see inline.
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 11, 2011 10:13 PM
Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt

Qin,

[Qin]: yes, the receiver doesn't have enough information to calculate more precise RTT unless unless the middlebox tell the receiver the RTT from original source to the middlebox.

 But the receiver can calculate one coarse RTT from receiver to the original media source or repair server and use this RTT as one approximate RTT since we assume the middlebox is near to the original media source.

[Qin]: your understanding, but if we want the receiver of TPLR know if a previous TPLR is lost, we can add repetition count field. This field can be used to specify the number

 of times the TPLR with the same SSRC has been retransmitted.

Do we allow such extension?

[Qin]: I believe you are right. How about say "RTCP translator acting as monitoring send NACK while translator without monitoring functionality just forward TPLR from its upstream to the downstream session participant
in the same way as forwarding other RTCP traffic.

[Qin] Okay, I agree both approaches are possible. I will make this clear in the relevant text.

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