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

[Jan Lindquist <[e-mail]>]

When i wrote mac address i meant uuid. I thought they are close in nature and it would be easier for the reader to identify oneself.
Regards,
JanL

Sent from Moxier Mail
(http://www.moxier.com)


----- Original Message -----
From: "Schwarz, Albrecht (Albrecht)" <[e-mail]>
To: Qin Wu <[e-mail]>, "[e-mail]" <[e-mail]>
Sent: 2011/10/11 14:17
Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt



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
>
_______________________________________________
Audio/Video Transport Core Maintenance
[e-mail]
https://www.ietf.org/mailman/listinfo/avt