Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt
"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Tue, 11 October 2011 09:52 UTC
Return-Path: <albrecht.schwarz@alcatel-lucent.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C8421F8C98 for <avt@ietfa.amsl.com>; Tue, 11 Oct 2011 02:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.349
X-Spam-Level:
X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_47=0.6, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDu3nzAB2ZBh for <avt@ietfa.amsl.com>; Tue, 11 Oct 2011 02:52:27 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3171E21F8C8D for <avt@ietf.org>; Tue, 11 Oct 2011 02:52:27 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9B9pO2K004144 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Oct 2011 11:51:30 +0200
Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 11 Oct 2011 11:51:14 +0200
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: Qin Wu <bill.wu@huawei.com>, Colin Perkins <csp@csperkins.org>, "avt@ietf.org" <avt@ietf.org>
Date: Tue, 11 Oct 2011 11:51:51 +0200
Thread-Topic: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt
Thread-Index: AcyH7YvYscVSzw7MTEmmz7cH/zNnvQADNu4A
Message-ID: <5F7BCCF5541B7444830A2288ABBEBC962160D2642D@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com>
References: <20110926081759.16674.85402.idtracker@ietfa.amsl.com> <AABD4735-2788-4CD7-B129-AF63B4EB2377@csperkins.org> <9F1217B1416045A987E6B48A4CC87037@china.huawei.com>
In-Reply-To: <9F1217B1416045A987E6B48A4CC87037@china.huawei.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Oct 2011 09:52:28 -0000
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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Qin Wu > Sent: Dienstag, 11. Oktober 2011 10:11 > To: Colin Perkins; avt@ietf.org > 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" <csp@csperkins.org> > To: <avt@ietf.org> > 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, Internet-Drafts@ietf.org 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 > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >
- [AVTCORE] I-D Action: draft-ietf-avtcore-feedback… internet-drafts
- Re: [AVTCORE] I-D Action: draft-ietf-avtcore-feed… Colin Perkins
- Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedb… Qin Wu
- Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedb… Schwarz, Albrecht (Albrecht)
- Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedb… Qin Wu
- Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedb… Schwarz, Albrecht (Albrecht)
- Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedb… Colin Perkins
- Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedb… Qin Wu