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

[Qin Wu <[e-mail]>]

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)" <[e-mail]>
To: "Qin Wu" <[e-mail]>; "Colin Perkins" <[e-mail]>; <[e-mail]>
Sent: Tuesday, October 11, 2011 5:51 PM
Subject: RE: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt


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: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Qin Wu
> Sent: Dienstag, 11. Oktober 2011 10:11
> To: Colin Perkins; [e-mail]
> Subject: Re: [AVTCORE] I-D 
> Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt
> 
> Hi, Colin:
> Thank for your careful review, please see my replies belows.
> 
> Regards!
> -Qin
> ----- Original Message -----
> From: "Colin Perkins" <[e-mail]>
> To: <[e-mail]>
> Sent: Tuesday, October 11, 2011 5:46 AM
> Subject: Re: [AVTCORE] I-D 
> Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt
> 
> 
> > On 26 Sep 2011, at 09:17, [e-mail] 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-feedbac
> k-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"?
> 
> [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 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?
> 
> [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.
> 
> > 
> > 
> > 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"
> 
> [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 generate an additional TPLR?
> 
> [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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
> =