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

["Schwarz, Albrecht (Albrecht)" <[e-mail]>]

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


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Qin Wu
> Sent: Dienstag, 11. Oktober 2011 14:06
> To: Schwarz, Albrecht (Albrecht); Colin Perkins; [e-mail]
> Subject: Re: [AVTCORE] I-D 
> Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt
> 
> 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
> > =
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>