From magnus.westerlund@ericsson.com Thu Oct 6 02:34:11 2011 Return-Path: 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 8236521F8C84 for ; Thu, 6 Oct 2011 02:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 5P+WMzSgAR9i for ; Thu, 6 Oct 2011 02:34:10 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3A94121F8C77 for ; Thu, 6 Oct 2011 02:34:10 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4d-4e8d76cf9994 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.115.93]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 58.4E.20773.FC67D8E4; Thu, 6 Oct 2011 11:37:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 6 Oct 2011 11:37:10 +0200 Message-ID: <4E8D76C1.5080508@ericsson.com> Date: Thu, 6 Oct 2011 11:37:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: IETF AVTCore WG , "draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org" X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 09:34:11 -0000 Thanks for updating the draft, I have reviewed the updated draft and have the following comments on the updated version. Some issues are follow up on previous version or on the actual changes. 1. Section 3. "The Third Party Loss Report message is generated by a RTP system that has not seen the actual packet loss and sent following the same timing rule as sending NACK defined in [RFC4585]" I do object against the strict formulation that the TPLR sender hasn't seen the loss itself. In the case of tree based distribution, the sending node can have observed the loss first hand. Thus I think it should say "may not seen the actual packet loss". And I think the second part of the sentence needs to be split into its own sentence. Also fix the capitilization of "The" after the e.g. in this sentence. I would consider thurther splitting rather than have a 5 line sentence. 2. Section 3. "The timer value shall be based on the observed round-trip time. A receiver should compute an estimate of the round-trip time (RTT) to the sender of TPLR from RTCP report round-trip time if available, or its reception time of the reflected RTCP FB message (e.g.,NACK), or any other means." We hade the discussion before but now that you clarified which RTT to be used, I think it is worth having a discussion if that RTT is the right one. So you suggest that the RTT between the sender of the TPLR and the receiver of the message is the most appropriate to use when suppressing the message. I am not certain that is the case. Lets consider the use cases. In the case of an intermediary in a distribution tree sending the TPLR and at the same time sending a NACK upstream. Then the time until the retransmission reaches the suppressed receiver is the time from the sending of the NACK up to the retransmitting entity and all the way down past the TPLR sender to the suppressed receiver. The receiver may not have a true RTT to the original media sender as that source appears to live at the TPLR sender, not further upstream. Yes, the sender of the TPLR and the receiver might at least have mutual knowledge of each other, thus the TPLR sender is able to determine the lowest RTT in the set of receviers thus determining how often to repeat it to cover additional time requried for the upstream part of the request. But I do note that these times aren't matching what appear to be the delays in the systems. Can we find a better solution? 3. Section 3: "To increase the robustness to the loss of a TPLR or of a transmission packet, a receiver is allowed to receive additional TPLR for the same packet. In the case the first TPLR is lost and the additional TPLR arrives at the receiver, the receiver should immediately refresh the timer." In the second sentence I don't see how the receiver can know that it is a retransmission. It is simply a TPLR from its perspective if that is lost. Robustness reasons is only one reason for repeating them the other is clearly to renew the timer. Thus I think the formulation should be more generic to make it clear that all receivers should upon reception of a TPLR refresh the timer for the packets indicated. 4. Section 3. "The media source or intermediate nodes cannot assume that the use of a Third Party Loss Report message actually reduces the amount of feedback it receives." I would recommend that one changes "assume" to "be certain". The intention is that TPLRs should reduced the feedback, but it is not guaranteed. 5. Section 4.1: "and the "SSRC of media source" denotes the media sender." I would expand this, to say the "denotes the media sender of the flow for which the indicated losses are being suppressed." This to make it more clear that this field is used to identify the sequence number space for which the rest identifies which packets where loss is suppressed. 6. Section 4.2: "Each entry applies to a different media Source that is requested to send a decoder refresh point or that is indicated that it lost synchronization with the video stream, identified by its SSRC." and "SSRC (32 bits): The SSRC value of the media source that is requested to send a decoder refresh point or that is indicated that it lost synchronization with the video stream." I think this needs to be better defined to identify that these are the SSRCs of the flows for on which suppression of transmission of PLI or FIR is suppressed. 7. Section 4.2: Seq nr:8bits Command sequence number. It is used by the Command receiver to check if the Command is repeated. The sequence number space is unique for each pairing of the SSRC of command sender and the SSRC of the command receiver. The sequence number SHALL increase by 1 modulo 256 for each new Command. A repetition SHALL NOT increase the sequence number. The initial value is arbitrary. Based on that it is defined that upon receiving one of the PSLEI request, one shouldn't send a FIR or PLI message for a time interval equal to the RTT between the receiver and the sender of the PSLEI message does the sequence number field have any meaning? From my perspective it doesn't matter if it is a new request or not. You are suppressed from the reception of the message, nothing else. 8. Section 5. " using the Augmented Backus-Naur Form (ABNF) [RFC4585]." The reference is wrong. The form of the reference implies that the reference is for ABNF which is RFC 5234, rather than the specific semantics defined in RFC 4585. 9. Section 5: The comments in the ABNF is to long. Please break them over several lines so that they don't violate the max column count of the draft format. Also "token" needs to have a reference like for the "byte-string". 10. Section 6.2: " one or more BRSes. one" Strange punctuation. 11. Section 7. "Sending the spurious Third Party Loss Report (e.g., the Third Party Loss Report with the wrong sequence number of lost packet) that makes missing RTP packets can not be compensated." "that makes" seems to be strange grammer. Please reword. "... that causes missing RTP packets to not be repaired in a timely fashion."? 12. Section 8. New registration in this registry follows the "Specification required" policy as defined by [RFC2434]. In addition, they are required to indicate any additional RTCP feedback types, such as "nack" and "ack". The reference should be RFC 5226. In addition you should check the plural forms that is currently used, due to the copy and paste from RFC 5104 to singular form as only a single of each type is present in the FMT registration requests. You are also missing the the initial values in the "Third Party Loss Report Messages" registry you create. Both TLLEI and PSLEI should be part of that registry shouldn't they? 13. Section 10.1: The following references I think should be moved to the Informative section instead (10.2). The reason are that they are not strictly needed for implementation and understanding of the normative parts. RFC 5760 RFC 3711 RFC 5124 The following isn't used in the text at all: RFC 3550 Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From thomas.belling@nsn.com Fri Oct 7 11:29:36 2011 Return-Path: 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 1B2DD21F8BDB for ; Fri, 7 Oct 2011 11:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 61VT0RztCf3b for ; Fri, 7 Oct 2011 11:29:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5F46021F8BF7 for ; Fri, 7 Oct 2011 11:29:24 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p97IWXrh019372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Oct 2011 20:32:33 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p97IWUtL027597 for ; Fri, 7 Oct 2011 20:32:33 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 20:30:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC851F.38CAFA91" Date: Fri, 7 Oct 2011 20:30:41 +0200 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F922484@DEMUEXC014.nsn-intra.net> In-Reply-To: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 Thread-Index: Acx/bJMAZn1O9EdQQ6OkqDNm9OOyyQFsOF6A References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> From: "Belling, Thomas (NSN - DE/Munich)" To: X-OriginalArrivalTime: 07 Oct 2011 18:30:43.0215 (UTC) FILETIME=[38E899F0:01CC851F] Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 18:29:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC851F.38CAFA91 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 I checked the draft and believe it is ready for publication. =20 I only have a small proposal for improvement, that could be incorporated if a revision becomes necessary due to other comments: =20 I noticed that you changed "must" to "should" in the Implementation Considerations In Clause 9 when going from version 01 to 02: =20 To allow the use of ECN with RTP over UDP, the RTP implementation =20 *should* be able to set the ECT bits in outgoing UDP datagrams, and *should* be able to read the value of the ECT bits on received UDP datagrams. =20 =20 After some discussions with Magnus I understand that the exception motivating the "should" rather than a "must" is implementations only supporting sending or receiving of unidirectional media streams. But it would be clearer to state that explicitly, for instance by saying: =20 "To allow the use of ECN with RTP over UDP, an RTP implementation =20 desiring to support receiving ECN controlled media streams must support reading the value of the ECT bits on received UDP datagrams, and an RTP implementation desiring to support sending ECN controlled media streams must support setting the ECT bits in outgoing UDP datagrams." =20 =20 Thomas Belling =20 ---------------------------------- Dr. Thomas Belling=20 3GPP Standardisation Nokia Siemens Networks=20 =20 =20 =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of ext Roni Even Sent: Friday, September 30, 2011 2:29 PM To: avt@ietf.org Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 =20 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP over UDP. =20 The WGLC will end on October 21, 2011 =20 Please review the draft and send comments to the list. =20 =20 Roni Even =20 =20 =20 ------_=_NextPart_001_01CC851F.38CAFA91 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I checked = the draft and believe it is ready for = publication.

 

I only have = a small proposal for improvement, that could be incorporated if a = revision becomes necessary due to other = comments:

 

I noticed = that you changed "must" to "should" in the = Implementation Considerations In Clause 9 when going from version 01 to = 02:

 

    To allow the = use of ECN with RTP over UDP, the RTP implementation   =

    *should* be able to set the ECT = bits in outgoing UDP datagrams, and  

    *should* = be able to read the value of the ECT bits on received = UDP   

    datagrams.  =

 

After some = discussions with Magnus I understand that the exception motivating the = “should” rather than a “must” is implementations = only supporting sending or receiving of unidirectional media streams. = But it would be clearer to state that explicitly, for instance by = saying:

 

"To allow the use of ECN = with RTP over UDP, an RTP implementation   =

desiring to support receiving ECN controlled media streams = must support reading the value of the ECT bits on received UDP = datagrams, and an RTP implementation desiring to support sending ECN = controlled media streams must support setting the ECT bits in outgoing = UDP datagrams."

 

 

Thomas = Belling

 

----------------------------------
Dr. Thomas Belling
3GPP Standardisation
Nokia Siemens Networks 

 

 

 

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = ext Roni Even
Sent: Friday, September 30, 2011 2:29 = PM
To: avt@ietf.org
Subject: [AVTCORE] WGLC on = draft-ietf-avtcore-ecn-for-rtp-04

 

Hi,

I would =
like to start a WGLC on htt=
p://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , =
Explicit =
Congestion Notification (ECN) for RTP over =
UDP.
 =

The WGLC will = end on October 21, 2011

 

Please review the draft and send comments to the = list.

 

 

Roni Even

 

 =

 

------_=_NextPart_001_01CC851F.38CAFA91-- From magnus.westerlund@ericsson.com Mon Oct 10 02:47:10 2011 Return-Path: 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 DBEFF21F8B27 for ; Mon, 10 Oct 2011 02:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 qrJ1X3Mo94t7 for ; Mon, 10 Oct 2011 02:47:10 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2256821F8A97 for ; Mon, 10 Oct 2011 02:47:09 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-68-4e92bf1ce1cf Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.83.13753.C1FB29E4; Mon, 10 Oct 2011 11:47:09 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 10 Oct 2011 11:47:08 +0200 Message-ID: <4E92BF1A.3040300@ericsson.com> Date: Mon, 10 Oct 2011 11:47:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <1A8A7D59006A8240B27FF63C794CA57F922484@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F922484@DEMUEXC014.nsn-intra.net> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 09:47:11 -0000 On 2011-10-07 20:30, Belling, Thomas (NSN - DE/Munich) wrote: > Dear all, > > > > I checked the draft and believe it is ready for publication. > > > > I only have a small proposal for improvement, that could be incorporated > if a revision becomes necessary due to other comments: > > > > I noticed that you changed "must" to "should" in the Implementation > Considerations In Clause 9 when going from version 01 to 02: > > > > To allow the use of ECN with RTP over UDP, the RTP implementation > > *should* be able to set the ECT bits in outgoing UDP datagrams, and > > *should* be able to read the value of the ECT bits on received UDP > > datagrams. > > > > After some discussions with Magnus I understand that the exception > motivating the “should” rather than a “must” is implementations only > supporting sending or receiving of unidirectional media streams. But it > would be clearer to state that explicitly, for instance by saying: > > > > "To allow the use of ECN with RTP over UDP, an RTP implementation > desiring to support receiving ECN controlled media streams must support > reading the value of the ECT bits on received UDP datagrams, and an RTP > implementation desiring to support sending ECN controlled media streams > must support setting the ECT bits in outgoing UDP datagrams." > I think this a good clarification. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Mon Oct 10 11:17:40 2011 Return-Path: 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 498E421F8BBF; Mon, 10 Oct 2011 11:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 jpPUP29G9wbv; Mon, 10 Oct 2011 11:17:39 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7B54A21F8BB9; Mon, 10 Oct 2011 11:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=632; q=dns/txt; s=iport; t=1318270659; x=1319480259; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=rAa8Lcbj+6H4MAbinfiVMLPbrLnkpT0hm3mZqV97ai0=; b=QdtQI56t3WHRA4RGW1KCRV69SFs9aICGIFpV4s1k3GwINYE/fA3dAL8J j41iFxmuv09EYyuMGxo0FYklWIGX9cQOF2RjSW0XOIlaOltmcAaiOiHle f8yFok4jrxy/C8qIQizDEfi6CQzUuhcsfHaZMz6IkorROTlq3OFAIBcw9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL41k06rRDoG/2dsb2JhbABDqB6BBYFVAQEDEgEdSRIBKgYYB1cBBBsah2OaMAGeJwOGYmEEh00wjG+EPYxA X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="7004189" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 Oct 2011 18:17:39 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9AIHddQ001464; Mon, 10 Oct 2011 18:17:39 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 11:17:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2011 11:17:20 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5410097E4B@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Duplication semantics drafts Thread-Index: AcyHeEjl/8RP3G7tSZC9DV9gLHt2UQ== From: "Ali C. Begen (abegen)" To: "mmusic (E-mail)" X-OriginalArrivalTime: 10 Oct 2011 18:17:38.0970 (UTC) FILETIME=[E4B38FA0:01CC8778] Cc: avt@ietf.org Subject: [AVTCORE] Duplication semantics drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 18:17:40 -0000 I revised the two drafts per the feedback in Quebec. If there are further comments, we would like to hear about them. As of = now, there are no open issues from our standpoint except possibly = defining a new RTCP XR report, which can be done later. Thus, we would = like these two drafts to be considered and adopted by the MMUSIC wg. https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ https://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving= /=20 CC'ing AVT(core) since the topic is relevant but please post your = comments to mmusic where the drafts belong to. -acbegen From rjsparks@nostrum.com Mon Oct 10 14:17:13 2011 Return-Path: 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 01C2E21F8C5A for ; Mon, 10 Oct 2011 14:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Zm4JNjxqTS1B for ; Mon, 10 Oct 2011 14:17:12 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 83CB021F8CA4 for ; Mon, 10 Oct 2011 14:17:12 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9ALH9OX014751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Oct 2011 16:17:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2011 16:17:09 -0500 Message-Id: <210CC951-2C9A-4B75-82B7-9107186E8433@nostrum.com> To: IETF AVTCORE WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [AVTCORE] AD review: draft-ietf-avtcore-srtp-vbr-adio-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 21:17:13 -0000 Summary: Ready - IETF LC requested - watch for its announcement shortly. Please consider this a last call comment: The title of the draft should capture that the document also provides = guidelines for the use of VAD with SRTP. RjS= From iesg-secretary@ietf.org Mon Oct 10 14:25:41 2011 Return-Path: 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 3456521F86A5; Mon, 10 Oct 2011 14:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 i4B1l1BTS3cG; Mon, 10 Oct 2011 14:25:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B923921F85F7; Mon, 10 Oct 2011 14:25:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111010212540.15419.25054.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2011 14:25:40 -0700 Cc: avt@ietf.org Subject: [AVTCORE] Last Call: (Guidelines for the use of Variable Bit Rate Audio with Secure RTP) to BCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 21:25:41 -0000 The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Guidelines for the use of Variable Bit Rate Audio with Secure RTP' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo discusses potential security issues that arise when using variable bit rate audio with the secure RTP profile. Guidelines to mitigate these issues are suggested. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-vbr-audio/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-vbr-audio/ No IPR declarations have been submitted directly on this I-D. From csp@csperkins.org Mon Oct 10 14:46:32 2011 Return-Path: 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 C2C8721F8C75 for ; Mon, 10 Oct 2011 14:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 4A17UGfLOj36 for ; Mon, 10 Oct 2011 14:46:32 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9C821F8B66 for ; Mon, 10 Oct 2011 14:46:32 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RDNg6-0004mE-Z3 for avt@ietf.org; Mon, 10 Oct 2011 21:46:30 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Colin Perkins In-Reply-To: <20110926081759.16674.85402.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2011 22:46:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110926081759.16674.85402.idtracker@ietfa.amsl.com> To: "avt@ietf.org WG" X-Mailer: Apple Mail (2.1084) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 21:46:32 -0000 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. >=20 > 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 >=20 > 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. >=20 >=20 > 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?=20 - Section 4.1: "bitmask of proceeding lost packets" -> "bitmask of lost = packets" --=20 Colin Perkins http://csperkins.org/ From bill.wu@huawei.com Mon Oct 10 18:41:49 2011 Return-Path: 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 C14A721F8CA3 for ; Mon, 10 Oct 2011 18:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 E3PwW0gTz8qQ for ; Mon, 10 Oct 2011 18:41:48 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C244C21F8C22 for ; Mon, 10 Oct 2011 18:41:44 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSV00M4VOPJRX@szxga04-in.huawei.com> for avt@ietf.org; Tue, 11 Oct 2011 09:41:44 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSV003PKOPJGP@szxga04-in.huawei.com> for avt@ietf.org; Tue, 11 Oct 2011 09:41:43 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI83133; Tue, 11 Oct 2011 09:41:43 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 09:41:41 +0800 Received: from w53375q (10.138.41.130) by szxeml407-hub.china.huawei.com (10.82.67.94) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 09:41:05 +0800 Date: Tue, 11 Oct 2011 09:40:40 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Magnus Westerlund , IETF AVTCore WG , draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_GT0MYcDqjFnyAwAiXXnoXA)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4E8D76C1.5080508@ericsson.com> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 01:41:49 -0000 --Boundary_(ID_GT0MYcDqjFnyAwAiXXnoXA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGksIE1hZ251cywNClRoYW5rIGZvciB5b3VyIHZhbHVhYmxlIHJldmlldywgcGxlYXNlIHNlZSBt eSByZXBsaWVzIGJlbG93cy4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQpGcm9tOiAiTWFnbnVzIFdlc3Rlcmx1bmQiIDxtYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb20+DQpUbzogIklFVEYgQVZUQ29yZSBXRyIgPGF2dEBpZXRmLm9yZz47IDxkcmFm dC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHBAdG9vbHMuaWV0Zi5vcmc+DQpT ZW50OiBUaHVyc2RheSwgT2N0b2JlciAwNiwgMjAxMSA1OjM3IFBNDQpTdWJqZWN0OiBbQVZUQ09S RV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRw LTA3DQoNCg0KVGhhbmtzIGZvciB1cGRhdGluZyB0aGUgZHJhZnQsDQoNCkkgaGF2ZSByZXZpZXdl ZCB0aGUgdXBkYXRlZCBkcmFmdCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzIG9uIHRo ZQ0KdXBkYXRlZCB2ZXJzaW9uLiBTb21lIGlzc3VlcyBhcmUgZm9sbG93IHVwIG9uIHByZXZpb3Vz IHZlcnNpb24gb3Igb24gdGhlDQphY3R1YWwgY2hhbmdlcy4NCg0KMS4gU2VjdGlvbiAzLg0KIlRo ZSBUaGlyZCBQYXJ0eSBMb3NzIFJlcG9ydA0KICAgbWVzc2FnZSBpcyBnZW5lcmF0ZWQgYnkgYSBS VFAgc3lzdGVtIHRoYXQgaGFzIG5vdCBzZWVuIHRoZSBhY3R1YWwNCiAgIHBhY2tldCBsb3NzIGFu ZCBzZW50IGZvbGxvd2luZyB0aGUgc2FtZSB0aW1pbmcgcnVsZSBhcyBzZW5kaW5nIE5BQ0sNCiAg IGRlZmluZWQgaW4gW1JGQzQ1ODVdIg0KDQpJIGRvIG9iamVjdCBhZ2FpbnN0IHRoZSBzdHJpY3Qg Zm9ybXVsYXRpb24gdGhhdCB0aGUgVFBMUiBzZW5kZXIgaGFzbid0DQpzZWVuIHRoZSBsb3NzIGl0 c2VsZi4gSW4gdGhlIGNhc2Ugb2YgdHJlZSBiYXNlZCBkaXN0cmlidXRpb24sIHRoZQ0Kc2VuZGlu ZyBub2RlIGNhbiBoYXZlIG9ic2VydmVkIHRoZSBsb3NzIGZpcnN0IGhhbmQuIFRodXMgSSB0aGlu ayBpdA0Kc2hvdWxkIHNheSAibWF5IG5vdCBzZWVuIHRoZSBhY3R1YWwgcGFja2V0IGxvc3MiLiBB bmQgSSB0aGluayB0aGUgc2Vjb25kDQpwYXJ0IG9mIHRoZSBzZW50ZW5jZSBuZWVkcyB0byBiZSBz cGxpdCBpbnRvIGl0cyBvd24gc2VudGVuY2UuDQoNCkFsc28gZml4IHRoZSBjYXBpdGlsaXphdGlv biBvZiAiVGhlIiBhZnRlciB0aGUgZS5nLiBpbiB0aGlzIHNlbnRlbmNlLiBJDQp3b3VsZCBjb25z aWRlciB0aHVydGhlciBzcGxpdHRpbmcgcmF0aGVyIHRoYW4gaGF2ZSBhIDUgbGluZSBzZW50ZW5j ZS4NCg0KW1Fpbl06IE9rYXksIGZpeGVkLg0KDQoyLiBTZWN0aW9uIDMuDQogICJUaGUgdGltZXIg dmFsdWUgc2hhbGwgYmUNCiAgIGJhc2VkIG9uIHRoZSBvYnNlcnZlZCByb3VuZC10cmlwIHRpbWUu ICBBIHJlY2VpdmVyIHNob3VsZCBjb21wdXRlIGFuDQogICBlc3RpbWF0ZSBvZiB0aGUgcm91bmQt dHJpcCB0aW1lIChSVFQpIHRvIHRoZSBzZW5kZXIgb2YgVFBMUiBmcm9tIFJUQ1ANCiAgIHJlcG9y dCByb3VuZC10cmlwIHRpbWUgaWYgYXZhaWxhYmxlLCBvciBpdHMgcmVjZXB0aW9uIHRpbWUgb2Yg dGhlDQogICByZWZsZWN0ZWQgUlRDUCBGQiBtZXNzYWdlIChlLmcuLE5BQ0spLCBvciBhbnkgb3Ro ZXIgbWVhbnMuIg0KDQpXZSBoYWRlIHRoZSBkaXNjdXNzaW9uIGJlZm9yZSBidXQgbm93IHRoYXQg eW91IGNsYXJpZmllZCB3aGljaCBSVFQgdG8gYmUNCnVzZWQsIEkgdGhpbmsgaXQgaXMgd29ydGgg aGF2aW5nIGEgZGlzY3Vzc2lvbiBpZiB0aGF0IFJUVCBpcyB0aGUgcmlnaHQNCm9uZS4gU28geW91 IHN1Z2dlc3QgdGhhdCB0aGUgUlRUIGJldHdlZW4gdGhlIHNlbmRlciBvZiB0aGUgVFBMUiBhbmQg dGhlDQpyZWNlaXZlciBvZiB0aGUgbWVzc2FnZSBpcyB0aGUgbW9zdCBhcHByb3ByaWF0ZSB0byB1 c2Ugd2hlbiBzdXBwcmVzc2luZw0KdGhlIG1lc3NhZ2UuIEkgYW0gbm90IGNlcnRhaW4gdGhhdCBp cyB0aGUgY2FzZS4NCg0KTGV0cyBjb25zaWRlciB0aGUgdXNlIGNhc2VzLiBJbiB0aGUgY2FzZSBv ZiBhbiBpbnRlcm1lZGlhcnkgaW4gYQ0KZGlzdHJpYnV0aW9uIHRyZWUgc2VuZGluZyB0aGUgVFBM UiBhbmQgYXQgdGhlIHNhbWUgdGltZSBzZW5kaW5nIGEgTkFDSw0KdXBzdHJlYW0uIFRoZW4gdGhl IHRpbWUgdW50aWwgdGhlIHJldHJhbnNtaXNzaW9uIHJlYWNoZXMgdGhlIHN1cHByZXNzZWQNCnJl Y2VpdmVyIGlzIHRoZSB0aW1lIGZyb20gdGhlIHNlbmRpbmcgb2YgdGhlIE5BQ0sgdXAgdG8gdGhl DQpyZXRyYW5zbWl0dGluZyBlbnRpdHkgYW5kIGFsbCB0aGUgd2F5IGRvd24gcGFzdCB0aGUgVFBM UiBzZW5kZXIgdG8gdGhlDQpzdXBwcmVzc2VkIHJlY2VpdmVyLiBUaGUgcmVjZWl2ZXIgbWF5IG5v dCBoYXZlIGEgdHJ1ZSBSVFQgdG8gdGhlDQpvcmlnaW5hbCBtZWRpYSBzZW5kZXIgYXMgdGhhdCBz b3VyY2UgYXBwZWFycyB0byBsaXZlIGF0IHRoZSBUUExSIHNlbmRlciwNCm5vdCBmdXJ0aGVyIHVw c3RyZWFtLg0KDQpZZXMsIHRoZSBzZW5kZXIgb2YgdGhlIFRQTFIgYW5kIHRoZSByZWNlaXZlciBt aWdodCBhdCBsZWFzdCBoYXZlIG11dHVhbA0Ka25vd2xlZGdlIG9mIGVhY2ggb3RoZXIsIHRodXMg dGhlIFRQTFIgc2VuZGVyIGlzIGFibGUgdG8gZGV0ZXJtaW5lIHRoZQ0KbG93ZXN0IFJUVCBpbiB0 aGUgc2V0IG9mIHJlY2V2aWVycyB0aHVzIGRldGVybWluaW5nIGhvdyBvZnRlbiB0byByZXBlYXQN Cml0IHRvIGNvdmVyIGFkZGl0aW9uYWwgdGltZSByZXF1cmllZCBmb3IgdGhlIHVwc3RyZWFtIHBh cnQgb2YgdGhlDQpyZXF1ZXN0LiBCdXQgSSBkbyBub3RlIHRoYXQgdGhlc2UgdGltZXMgYXJlbid0 IG1hdGNoaW5nIHdoYXQgYXBwZWFyIHRvDQpiZSB0aGUgZGVsYXlzIGluIHRoZSBzeXN0ZW1zLg0K DQpDYW4gd2UgZmluZCBhIGJldHRlciBzb2x1dGlvbj8NCg0KW1Fpbl06IEl0IGxvb2tzIHRvIG1l IHRoZSByb3VuZCB0cmlwIHRpbWUgYmV0d2VlbiBtZWRpYSBzb3VyY2UgYW5kDQoNCiBpbnRlcm1l ZGlhcnkgaXMgdHJpdmlhbCBpZiB3ZSBhc3N1bWUgdGhlIGludGVybWVkaWFyeSBpcyBtdWNoIA0K DQpjbG9zZXIgdG8gdGhlIHNvdXJjZSwgdGhhdCBpcyB3aHkgSSBwdXQgdGhlIGxhc3QgcGFyYWdy YXBoIGluIHRoZSANCg0Kc2VjdGlvbiAzIGFzIGZvbGxvd3M6DQoNCiINCg0KSW4gb3JkZXIgbm90 IHRvIGluY3VyIGEgbG90IG9mIE5BQ0sgcmVxdWVzdHMgZHVlIHRvIGFkZGl0aW9uYWwgVFBMUiAN Cg0KZGVzY3JpYmVkIGFib3ZlLCBpdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBSVFAgc3lzdGVt IHNlbmRpbmcgDQoNClRQTFIgc2hvdWxkIGJlIGltcGxlbWVudGVkIG1vcmUgY2xvc2VyIHRvIHRo ZSBzb3VyY2UuIEFsc28gd2hlbg0KDQogdGhlIGxvc3Mgd2FzIGRldGVjdGVkIGFuZCByZXBhaXIg aW5pdGlhdGVkIG11Y2ggY2xvc2VyIHRvIHRoZSBzb3VyY2UsIA0KDQp0aGUgZGVsYXkgZm9yIHRo ZSByZWNlaXZlciB0byByZWNvdmVyIGZyb20gcGFja2V0IGxvc3MgY2FuIGJlIHJlZHVjZWQgDQoN CnRocm91Z2ggdGhlIGNvbWJpbmF0aW9uIG9mIGludGVybWVkaWFyeSBmZWVkYmFjayB0byB0aGUg c291cmNlIGFuZCANCg0KVGhpcmQgUGFydHkgTG9zcyBSZXBvcnQgZG93bnN0cmVhbS4NCg0KIg0K DQoNCg0KSWYgd2UgbG9vayBmb3IgYSBiZXR0ZXIgc29sdXRpb24sIEkgdGhpbmsgd2UgaGF2ZSB0 d28gcG9zc2libGUgd2F5czoNCg0KVGhlIGZpcnN0IHdheSBpcyB0byByZWx5IG9uIHNlbmRlciBy ZXBvcnQgZnJvbSBtZWRpYSBzZW5kZXIgdG8gDQoNCmNhbGN1bGF0ZSB0aGUgbW9yZSBhcHByb3hp bWF0ZSBSVFQgZnJvbSBtZWRpYSBzZW5kZXIgdG8gdGhlIHJlY2VpdmVyLiANCg0KUlRUIG1lYXN1 cmVtZW50IG1ldGhvZCBmb2xsb3dzIHRoZSBzYW1lIHdheSBkZXNjcmliZWQgaW4gdGhlIA0KDQpm aWd1cmUgMiBvZiBSRkMzNTUwLg0KDQoNCg0KVGhlIHNlY29uZCB3YXkgaXMgdG8gd2UgY2FuIGFs bG93IHRoZSBpbnRlcm1lZGlhcnkgdGVsbCB0aGUgcmVjZWl2ZXIgdGhlIA0KDQpSVFQgZnJvbSBt ZWRpYSBzb3VyY2UgdG8gaW50ZXJtZWRpYXJ5IGl0c2VsZiBieSBzZW5kaW5nIGEgbmV3IG1lc3Nh Z2UgDQoNCnNpbmNlIHRoZSBpbnRlcm1lZGlhcnkgY2FuIG1lYXN1cmUgc3VjaCBSVFQgYmFzZWQg b24gcGFzdCBvYnNlcnZhdGlvbiANCg0KYW5kIGVzdGltYXRpb24uIEhvd2V2ZXIgZm9yIHRoZSBz ZWNvbmQgd2F5IHdlIG5lZWQgdG8gZGVmaW5lIG5ldyANCg0KbWVzc2FnZSBvciBleHRlbmQgVFBM UiBtZXNzYWdlIHRvIGNhcnJ5IHN1Y2ggUlRULg0KDQoNCg0KV2hhdCBkbyB5b3UgdGhpbms/IA0K DQoNCg0KMy4gU2VjdGlvbiAzOg0KICAiVG8gaW5jcmVhc2UgdGhlIHJvYnVzdG5lc3MgdG8gdGhl IGxvc3Mgb2YgYSBUUExSIG9yIG9mIGEgdHJhbnNtaXNzaW9uDQogICBwYWNrZXQsIGEgcmVjZWl2 ZXIgaXMgYWxsb3dlZCB0byByZWNlaXZlIGFkZGl0aW9uYWwgVFBMUiBmb3IgdGhlIHNhbWUNCiAg IHBhY2tldC4gIEluIHRoZSBjYXNlIHRoZSBmaXJzdCBUUExSIGlzIGxvc3QgYW5kIHRoZSBhZGRp dGlvbmFsIFRQTFINCiAgIGFycml2ZXMgYXQgdGhlIHJlY2VpdmVyLCB0aGUgcmVjZWl2ZXIgc2hv dWxkIGltbWVkaWF0ZWx5IHJlZnJlc2ggdGhlDQogICB0aW1lci4iDQoNCkluIHRoZSBzZWNvbmQg c2VudGVuY2UgSSBkb24ndCBzZWUgaG93IHRoZSByZWNlaXZlciBjYW4ga25vdyB0aGF0IGl0IGlz DQphIHJldHJhbnNtaXNzaW9uLiBJdCBpcyBzaW1wbHkgYSBUUExSIGZyb20gaXRzIHBlcnNwZWN0 aXZlIGlmIHRoYXQgaXMgbG9zdC4NCg0KUm9idXN0bmVzcyByZWFzb25zIGlzIG9ubHkgb25lIHJl YXNvbiBmb3IgcmVwZWF0aW5nIHRoZW0gdGhlIG90aGVyIGlzDQpjbGVhcmx5IHRvIHJlbmV3IHRo ZSB0aW1lci4gVGh1cyBJIHRoaW5rIHRoZSBmb3JtdWxhdGlvbiBzaG91bGQgYmUgbW9yZQ0KZ2Vu ZXJpYyB0byBtYWtlIGl0IGNsZWFyIHRoYXQgYWxsIHJlY2VpdmVycyBzaG91bGQgdXBvbiByZWNl cHRpb24gb2YgYQ0KVFBMUiByZWZyZXNoIHRoZSB0aW1lciBmb3IgdGhlIHBhY2tldHMgaW5kaWNh dGVkLg0KDQoNCg0KW1Fpbl06IElmIHRoZSByZWNlaXZlciBkb2VzIG5vdCBrZWVwIHN0YXRlIGZv ciB0aGUgdGltZXMgdGhlIFRQTFIgaXMNCg0KIHJldHJhbnNtaXR0ZWQsIHdlIGNhbiBhZGQgcmVw ZXRpdGlvbiBjb3VudCBmaWVsZCBpbiBlYWNoIEZDSSBlbnRyeQ0KDQogb2YgVFBMUiBmZWVkYmFj ayBtZXNzYWdlIHRvIGluZGljYXRlIHRoZSB0aW1lcyBUUExSIGlzIHJldHJhbnNtaXR0ZWQuDQoN CiBQYXJ0aWN1bGFybHkgaW4gUFNMRUkgRmVlZGJhY2sgTWVzc2FnZSwgd2UgY2FuIHJldXNlIHNl cSBuci4gRmllbGQgdG8NCg0KIGluZGljYXRlIGlmIGFkZGl0aW9uYWwgVFBMUiBpcyByZXRyYW5z bWl0dGVkLCB3aGljaCBvbmUgeW91IHRoaW5rIGJldHRlcj8NCg0KDQoNCjQuIFNlY3Rpb24gMy4N CiJUaGUgbWVkaWEgc291cmNlIG9yIGludGVybWVkaWF0ZSBub2RlcyBjYW5ub3QgYXNzdW1lIHRo YXQgdGhlIHVzZSBvZg0KICAgYSBUaGlyZCBQYXJ0eSBMb3NzIFJlcG9ydCBtZXNzYWdlIGFjdHVh bGx5IHJlZHVjZXMgdGhlIGFtb3VudCBvZg0KICAgZmVlZGJhY2sgaXQgcmVjZWl2ZXMuIg0KDQpJ IHdvdWxkIHJlY29tbWVuZCB0aGF0IG9uZSBjaGFuZ2VzICJhc3N1bWUiIHRvICJiZSBjZXJ0YWlu Ii4gVGhlDQppbnRlbnRpb24gaXMgdGhhdCBUUExScyBzaG91bGQgcmVkdWNlZCB0aGUgZmVlZGJh Y2ssIGJ1dCBpdCBpcyBub3QNCmd1YXJhbnRlZWQuDQoNCg0KDQpbUWluXTogT2theS4NCg0KDQoN CjUuIFNlY3Rpb24gNC4xOg0KImFuZCB0aGUgIlNTUkMgb2YgbWVkaWEgc291cmNlIg0KICAgZGVu b3RlcyB0aGUgbWVkaWEgc2VuZGVyLiINCg0KSSB3b3VsZCBleHBhbmQgdGhpcywgdG8gc2F5IHRo ZSAiZGVub3RlcyB0aGUgbWVkaWEgc2VuZGVyIG9mIHRoZSBmbG93DQpmb3Igd2hpY2ggdGhlIGlu ZGljYXRlZCBsb3NzZXMgYXJlIGJlaW5nIHN1cHByZXNzZWQuIg0KDQpUaGlzIHRvIG1ha2UgaXQg bW9yZSBjbGVhciB0aGF0IHRoaXMgZmllbGQgaXMgdXNlZCB0byBpZGVudGlmeSB0aGUNCnNlcXVl bmNlIG51bWJlciBzcGFjZSBmb3Igd2hpY2ggdGhlIHJlc3QgaWRlbnRpZmllcyB3aGljaCBwYWNr ZXRzIHdoZXJlDQpsb3NzIGlzIHN1cHByZXNzZWQuDQoNCg0KDQpbUWluXTogT2theS4NCg0KNi4g U2VjdGlvbiA0LjI6DQoiRWFjaCBlbnRyeSBhcHBsaWVzIHRvIGEgZGlmZmVyZW50IG1lZGlhDQog ICBTb3VyY2UgdGhhdCBpcyByZXF1ZXN0ZWQgdG8gc2VuZCBhIGRlY29kZXIgcmVmcmVzaCBwb2lu dCBvciB0aGF0IGlzDQogICBpbmRpY2F0ZWQgdGhhdCBpdCBsb3N0IHN5bmNocm9uaXphdGlvbiB3 aXRoIHRoZSB2aWRlbyBzdHJlYW0sDQogICBpZGVudGlmaWVkIGJ5IGl0cyBTU1JDLiINCg0KYW5k DQoNCiJTU1JDICgzMiBiaXRzKToNCg0KICAgICAgVGhlIFNTUkMgdmFsdWUgb2YgdGhlIG1lZGlh IHNvdXJjZSB0aGF0IGlzIHJlcXVlc3RlZCB0byBzZW5kIGENCiAgICAgIGRlY29kZXIgcmVmcmVz aCBwb2ludCBvciB0aGF0IGlzIGluZGljYXRlZCB0aGF0IGl0IGxvc3QNCiAgICAgIHN5bmNocm9u aXphdGlvbiB3aXRoIHRoZSB2aWRlbyBzdHJlYW0uIg0KDQpJIHRoaW5rIHRoaXMgbmVlZHMgdG8g YmUgYmV0dGVyIGRlZmluZWQgdG8gaWRlbnRpZnkgdGhhdCB0aGVzZSBhcmUgdGhlDQpTU1JDcyBv ZiB0aGUgZmxvd3MgZm9yIG9uIHdoaWNoIHN1cHByZXNzaW9uIG9mIHRyYW5zbWlzc2lvbiBvZiBQ TEkgb3INCkZJUiBpcyBzdXBwcmVzc2VkLg0KDQoNCg0KW1Fpbl06T2theSwgd2lsbCBkbyBpdCBp biB0aGUgbmV3IHZlcnNpb24uDQoNCjcuIFNlY3Rpb24gNC4yOg0KICAgU2VxIG5yOjhiaXRzICBD b21tYW5kIHNlcXVlbmNlIG51bWJlci4gIEl0IGlzIHVzZWQgYnkgdGhlIENvbW1hbmQNCiAgICAg IHJlY2VpdmVyIHRvIGNoZWNrIGlmIHRoZSBDb21tYW5kIGlzIHJlcGVhdGVkLiAgVGhlIHNlcXVl bmNlIG51bWJlcg0KICAgICAgc3BhY2UgaXMgdW5pcXVlIGZvciBlYWNoIHBhaXJpbmcgb2YgdGhl IFNTUkMgb2YgY29tbWFuZCBzZW5kZXIgYW5kDQogICAgICB0aGUgU1NSQyBvZiB0aGUgY29tbWFu ZCByZWNlaXZlci4gIFRoZSBzZXF1ZW5jZSBudW1iZXIgU0hBTEwNCiAgICAgIGluY3JlYXNlIGJ5 IDEgbW9kdWxvIDI1NiBmb3IgZWFjaCBuZXcgQ29tbWFuZC4gIEEgcmVwZXRpdGlvbiBTSEFMTA0K ICAgICAgTk9UIGluY3JlYXNlIHRoZSBzZXF1ZW5jZSBudW1iZXIuICBUaGUgaW5pdGlhbCB2YWx1 ZSBpcyBhcmJpdHJhcnkuDQoNCkJhc2VkIG9uIHRoYXQgaXQgaXMgZGVmaW5lZCB0aGF0IHVwb24g cmVjZWl2aW5nIG9uZSBvZiB0aGUgUFNMRUkNCnJlcXVlc3QsIG9uZSBzaG91bGRuJ3Qgc2VuZCBh IEZJUiBvciBQTEkgbWVzc2FnZSBmb3IgYSB0aW1lIGludGVydmFsDQplcXVhbCB0byB0aGUgUlRU IGJldHdlZW4gdGhlIHJlY2VpdmVyIGFuZCB0aGUgc2VuZGVyIG9mIHRoZSBQU0xFSQ0KbWVzc2Fn ZSBkb2VzIHRoZSBzZXF1ZW5jZSBudW1iZXIgZmllbGQgaGF2ZSBhbnkgbWVhbmluZz8gRnJvbSBt eQ0KcGVyc3BlY3RpdmUgaXQgZG9lc24ndCBtYXR0ZXIgaWYgaXQgaXMgYSBuZXcgcmVxdWVzdCBv ciBub3QuIFlvdSBhcmUNCnN1cHByZXNzZWQgZnJvbSB0aGUgcmVjZXB0aW9uIG9mIHRoZSBtZXNz YWdlLCBub3RoaW5nIGVsc2UuDQoNCg0KDQpbUWluXTogSSB0aGluayB3ZSBjYW4gdXNlIHNlcSBu ciBmaWVsZCB0byBpbmRpY2F0ZSB0aGUgdGltZXMgdGhlIFRQTFIgaXMgcmV0cmFuc21pdHRlZCwg ZS5nLiwNCg0KSWYgdGhlIGFkZGl0aW9uYWwgVFBMUiB3aXRoIHRoZSBzYW1lIFNTUkMgYW5kIGRp ZmZlcmVudCBTZXEgTnVtYmVyIGlzIHJlY2VpdmVkLCB0aGUgDQoNCnJlY2VpdmVyIGtub3dzIHRo YXQgaXQgaXMgYSByZXRyYW5zbWlzc2lvbiBpZiB0aGUgcmVjZWl2ZXIga2VlcHMgc3RhdGUgZm9y IHRoZSBwcmV2aW91cyANCg0KVFBMUiB3aXRoIHRoZSBzYW1lIFNTUkMuDQoNCkFsc28gd2UgY2Fu IHJlcGxhY2Ugc2VxIG5yLiBGaWVsZCB3aXRoIFJlcGV0aXRpb24gY291bnQgZmllbGQgdG8gaW5k aWNhdGUgaG93IG1hbnkgdGltZSANCg0KdGhlIFRQTFIgaXMgcmV0cmFuc21pdHRlZC4gDQoNCg0K OC4gU2VjdGlvbiA1Lg0KIiB1c2luZyB0aGUgQXVnbWVudGVkIEJhY2t1cy1OYXVyIEZvcm0gKEFC TkYpDQogICBbUkZDNDU4NV0uIg0KDQpUaGUgcmVmZXJlbmNlIGlzIHdyb25nLiBUaGUgZm9ybSBv ZiB0aGUgcmVmZXJlbmNlIGltcGxpZXMgdGhhdCB0aGUNCnJlZmVyZW5jZSBpcyBmb3IgQUJORiB3 aGljaCBpcyBSRkMgNTIzNCwgcmF0aGVyIHRoYW4gdGhlIHNwZWNpZmljDQpzZW1hbnRpY3MgZGVm aW5lZCBpbiBSRkMgNDU4NS4NCg0KDQoNCltRaW5dOiBPa2F5LCBmaXhlZC4NCg0KOS4gU2VjdGlv biA1Og0KVGhlIGNvbW1lbnRzIGluIHRoZSBBQk5GIGlzIHRvIGxvbmcuIFBsZWFzZSBicmVhayB0 aGVtIG92ZXIgc2V2ZXJhbA0KbGluZXMgc28gdGhhdCB0aGV5IGRvbid0IHZpb2xhdGUgdGhlIG1h eCBjb2x1bW4gY291bnQgb2YgdGhlIGRyYWZ0IGZvcm1hdC4NCg0KQWxzbyAidG9rZW4iIG5lZWRz IHRvIGhhdmUgYSByZWZlcmVuY2UgbGlrZSBmb3IgdGhlICJieXRlLXN0cmluZyIuDQoNCg0KDQpb UWluXTogT2theSwgZml4ZWQuDQoNCjEwLiBTZWN0aW9uIDYuMjoNCiIgb25lIG9yIG1vcmUgQlJT ZXMuIG9uZSINCg0KU3RyYW5nZSBwdW5jdHVhdGlvbi4NCg0KMTEuIFNlY3Rpb24gNy4NCiJTZW5k aW5nIHRoZSBzcHVyaW91cyBUaGlyZCBQYXJ0eSBMb3NzIFJlcG9ydCAoZS5nLiwgdGhlIFRoaXJk IFBhcnR5DQogICBMb3NzIFJlcG9ydCB3aXRoIHRoZSB3cm9uZyBzZXF1ZW5jZSBudW1iZXIgb2Yg bG9zdCBwYWNrZXQpIHRoYXQgbWFrZXMNCiAgIG1pc3NpbmcgUlRQIHBhY2tldHMgY2FuIG5vdCBi ZSBjb21wZW5zYXRlZC4iDQoNCiJ0aGF0IG1ha2VzIiBzZWVtcyB0byBiZSBzdHJhbmdlIGdyYW1t ZXIuIFBsZWFzZSByZXdvcmQuDQoiLi4uIHRoYXQgY2F1c2VzIG1pc3NpbmcgUlRQIHBhY2tldHMg dG8gbm90IGJlIHJlcGFpcmVkIGluIGEgdGltZWx5DQpmYXNoaW9uLiI/DQoNCg0KDQpbUWluXTog T2theSwgZml4ZWQuDQoNCg0KMTIuIFNlY3Rpb24gOC4NCiAgIE5ldyByZWdpc3RyYXRpb24gaW4g dGhpcyByZWdpc3RyeSBmb2xsb3dzIHRoZSAiU3BlY2lmaWNhdGlvbg0KICAgcmVxdWlyZWQiIHBv bGljeSBhcyBkZWZpbmVkIGJ5IFtSRkMyNDM0XS4gIEluIGFkZGl0aW9uLCB0aGV5IGFyZQ0KICAg cmVxdWlyZWQgdG8gaW5kaWNhdGUgYW55IGFkZGl0aW9uYWwgUlRDUCBmZWVkYmFjayB0eXBlcywg c3VjaCBhcw0KICAgIm5hY2siIGFuZCAiYWNrIi4NCg0KVGhlIHJlZmVyZW5jZSBzaG91bGQgYmUg UkZDIDUyMjYuDQoNCkluIGFkZGl0aW9uIHlvdSBzaG91bGQgY2hlY2sgdGhlIHBsdXJhbCBmb3Jt cyB0aGF0IGlzIGN1cnJlbnRseSB1c2VkLA0KZHVlIHRvIHRoZSBjb3B5IGFuZCBwYXN0ZSBmcm9t IFJGQyA1MTA0IHRvIHNpbmd1bGFyIGZvcm0gYXMgb25seSBhDQpzaW5nbGUgb2YgZWFjaCB0eXBl IGlzIHByZXNlbnQgaW4gdGhlIEZNVCByZWdpc3RyYXRpb24gcmVxdWVzdHMuDQoNCllvdSBhcmUg YWxzbyBtaXNzaW5nIHRoZSB0aGUgaW5pdGlhbCB2YWx1ZXMgaW4gdGhlICJUaGlyZCBQYXJ0eSBM b3NzDQpSZXBvcnQgTWVzc2FnZXMiIHJlZ2lzdHJ5IHlvdSBjcmVhdGUuIEJvdGggVExMRUkgYW5k IFBTTEVJIHNob3VsZCBiZQ0KcGFydCBvZiB0aGF0IHJlZ2lzdHJ5IHNob3VsZG4ndCB0aGV5Pw0K DQoNCg0KW1Fpbl06IE9rYXksIGZpeGVkLg0KDQoxMy4gU2VjdGlvbiAxMC4xOg0KDQpUaGUgZm9s bG93aW5nIHJlZmVyZW5jZXMgSSB0aGluayBzaG91bGQgYmUgbW92ZWQgdG8gdGhlIEluZm9ybWF0 aXZlDQpzZWN0aW9uIGluc3RlYWQgKDEwLjIpLiBUaGUgcmVhc29uIGFyZSB0aGF0IHRoZXkgYXJl IG5vdCBzdHJpY3RseSBuZWVkZWQNCmZvciBpbXBsZW1lbnRhdGlvbiBhbmQgdW5kZXJzdGFuZGlu ZyBvZiB0aGUgbm9ybWF0aXZlIHBhcnRzLg0KDQpSRkMgNTc2MA0KUkZDIDM3MTENClJGQyA1MTI0 DQoNClRoZSBmb2xsb3dpbmcgaXNuJ3QgdXNlZCBpbiB0aGUgdGV4dCBhdCBhbGw6DQpSRkMgMzU1 MA0KDQoNCg0KW1Fpbl06IE9rYXksIGZpeGVkLg0KDQpDaGVlcnMNCg0KTWFnbnVzIFdlc3Rlcmx1 bmQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KTXVsdGltZWRpYSBUZWNobm9sb2dpZXMsIEVyaWNzc29uIFJl c2VhcmNoIEVBQi9UVk0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkVyaWNzc29uIEFCICAgICAgICAgICAgICAg IHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQpG5HL2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1v YmlsZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVufCBtYWlsdG86 IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJh bnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCmF2dEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hdnQNCg0K --Boundary_(ID_GT0MYcDqjFnyAwAiXXnoXA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTEyMCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZPg0KPERJVj5IaSwgTWFnbnVzLDwvRElWPg0KPERJVj5UaGFuayBmb3IgeW91ciB2 YWx1YWJsZSByZXZpZXcsIHBsZWFzZSBzZWUgbXkgcmVwbGllcyBiZWxvd3MuPC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5SZWdhcmRzITwvRElWPg0KPERJVj4tUWluPC9ESVY+DQo8RElW Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo8RElWPkZyb206ICJNYWdudXMgV2VzdGVy bHVuZCIgJmx0OzxBIA0KaHJlZj0ibWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bSI+bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPC9BPiZndDs8L0RJVj4NCjxESVY+VG86 ICJJRVRGIEFWVENvcmUgV0ciICZsdDs8QSANCmhyZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2 dEBpZXRmLm9yZzwvQT4mZ3Q7OyAmbHQ7PEEgDQpocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1hdnRj b3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLWF2 dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHBAdG9vbHMuaWV0Zi5vcmc8L0E+Jmd0OzwvRElW Pg0KPERJVj5TZW50OiBUaHVyc2RheSwgT2N0b2JlciAwNiwgMjAxMSA1OjM3IFBNPC9ESVY+DQo8 RElWPlN1YmplY3Q6IFtBVlRDT1JFXSBDb21tZW50cyBvbiANCmRyYWZ0LWlldGYtYXZ0Y29yZS1m ZWVkYmFjay1zdXByZXNzaW9uLXJ0cC0wNzwvRElWPjwvRElWPg0KPERJVj48QlI+PC9ESVY+DQo8 RElWPlRoYW5rcyBmb3IgdXBkYXRpbmcgdGhlIGRyYWZ0LDxCUj48QlI+SSBoYXZlIHJldmlld2Vk IHRoZSB1cGRhdGVkIGRyYWZ0IGFuZCANCmhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50cyBvbiB0 aGU8QlI+dXBkYXRlZCB2ZXJzaW9uLiBTb21lIGlzc3VlcyBhcmUgZm9sbG93IHVwIA0Kb24gcHJl dmlvdXMgdmVyc2lvbiBvciBvbiB0aGU8QlI+YWN0dWFsIGNoYW5nZXMuPEJSPjxCUj4xLiBTZWN0 aW9uIDMuPEJSPiJUaGUgDQpUaGlyZCBQYXJ0eSBMb3NzIFJlcG9ydDxCUj4mbmJzcDsmbmJzcDsg bWVzc2FnZSBpcyBnZW5lcmF0ZWQgYnkgYSBSVFAgc3lzdGVtIA0KdGhhdCBoYXMgbm90IHNlZW4g dGhlIGFjdHVhbDxCUj4mbmJzcDsmbmJzcDsgcGFja2V0IGxvc3MgYW5kIHNlbnQgZm9sbG93aW5n IHRoZSANCnNhbWUgdGltaW5nIHJ1bGUgYXMgc2VuZGluZyBOQUNLPEJSPiZuYnNwOyZuYnNwOyBk ZWZpbmVkIGluIFtSRkM0NTg1XSI8QlI+PEJSPkkgDQpkbyBvYmplY3QgYWdhaW5zdCB0aGUgc3Ry aWN0IGZvcm11bGF0aW9uIHRoYXQgdGhlIFRQTFIgc2VuZGVyIGhhc24ndDxCUj5zZWVuIHRoZSAN Cmxvc3MgaXRzZWxmLiBJbiB0aGUgY2FzZSBvZiB0cmVlIGJhc2VkIGRpc3RyaWJ1dGlvbiwgdGhl PEJSPnNlbmRpbmcgbm9kZSBjYW4gDQpoYXZlIG9ic2VydmVkIHRoZSBsb3NzIGZpcnN0IGhhbmQu IFRodXMgSSB0aGluayBpdDxCUj5zaG91bGQgc2F5ICJtYXkgbm90IHNlZW4gDQp0aGUgYWN0dWFs IHBhY2tldCBsb3NzIi4gQW5kIEkgdGhpbmsgdGhlIHNlY29uZDxCUj5wYXJ0IG9mIHRoZSBzZW50 ZW5jZSBuZWVkcyB0byANCmJlIHNwbGl0IGludG8gaXRzIG93biBzZW50ZW5jZS48QlI+PEJSPkFs c28gZml4IHRoZSBjYXBpdGlsaXphdGlvbiBvZiAiVGhlIiANCmFmdGVyIHRoZSBlLmcuIGluIHRo aXMgc2VudGVuY2UuIEk8QlI+d291bGQgY29uc2lkZXIgdGh1cnRoZXIgc3BsaXR0aW5nIHJhdGhl ciANCnRoYW4gaGF2ZSBhIDUgbGluZSBzZW50ZW5jZS48QlI+PEJSPjxTUEFOIA0Kc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwLjVwdDsgbXNv LWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRp bjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjMjM0MzU7JiMyMDMwNzs7IG1zby1mYXJlYXN0 LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1s YXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS10 aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJl YXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4t VVM+PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNUUk9ORz5bUWluXTogT2th eSwgDQpmaXhlZC48L1NUUk9ORz48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48QlI+Mi4gU2Vj dGlvbiAzLjxCUj4mbmJzcDsgIlRoZSB0aW1lciB2YWx1ZSBzaGFsbCBiZTxCUj4mbmJzcDsmbmJz cDsgYmFzZWQgDQpvbiB0aGUgb2JzZXJ2ZWQgcm91bmQtdHJpcCB0aW1lLiZuYnNwOyBBIHJlY2Vp dmVyIHNob3VsZCBjb21wdXRlIA0KYW48QlI+Jm5ic3A7Jm5ic3A7IGVzdGltYXRlIG9mIHRoZSBy b3VuZC10cmlwIHRpbWUgKFJUVCkgdG8gdGhlIHNlbmRlciBvZiBUUExSIA0KZnJvbSBSVENQPEJS PiZuYnNwOyZuYnNwOyByZXBvcnQgcm91bmQtdHJpcCB0aW1lIGlmIGF2YWlsYWJsZSwgb3IgaXRz IHJlY2VwdGlvbiANCnRpbWUgb2YgdGhlPEJSPiZuYnNwOyZuYnNwOyByZWZsZWN0ZWQgUlRDUCBG QiBtZXNzYWdlIChlLmcuLE5BQ0spLCBvciBhbnkgb3RoZXIgDQptZWFucy4iPEJSPjxCUj5XZSBo YWRlIHRoZSBkaXNjdXNzaW9uIGJlZm9yZSBidXQgbm93IHRoYXQgeW91IGNsYXJpZmllZCB3aGlj aCANClJUVCB0byBiZTxCUj51c2VkLCBJIHRoaW5rIGl0IGlzIHdvcnRoIGhhdmluZyBhIGRpc2N1 c3Npb24gaWYgdGhhdCBSVFQgaXMgdGhlIA0KcmlnaHQ8QlI+b25lLiBTbyB5b3Ugc3VnZ2VzdCB0 aGF0IHRoZSBSVFQgYmV0d2VlbiB0aGUgc2VuZGVyIG9mIHRoZSBUUExSIGFuZCANCnRoZTxCUj5y ZWNlaXZlciBvZiB0aGUgbWVzc2FnZSBpcyB0aGUgbW9zdCBhcHByb3ByaWF0ZSB0byB1c2Ugd2hl biANCnN1cHByZXNzaW5nPEJSPnRoZSBtZXNzYWdlLiBJIGFtIG5vdCBjZXJ0YWluIHRoYXQgaXMg dGhlIGNhc2UuPEJSPjxCUj5MZXRzIA0KY29uc2lkZXIgdGhlIHVzZSBjYXNlcy4gSW4gdGhlIGNh c2Ugb2YgYW4gaW50ZXJtZWRpYXJ5IGluIGE8QlI+ZGlzdHJpYnV0aW9uIHRyZWUgDQpzZW5kaW5n IHRoZSBUUExSIGFuZCBhdCB0aGUgc2FtZSB0aW1lIHNlbmRpbmcgYSBOQUNLPEJSPnVwc3RyZWFt LiBUaGVuIHRoZSB0aW1lIA0KdW50aWwgdGhlIHJldHJhbnNtaXNzaW9uIHJlYWNoZXMgdGhlIHN1 cHByZXNzZWQ8QlI+cmVjZWl2ZXIgaXMgdGhlIHRpbWUgZnJvbSB0aGUgDQpzZW5kaW5nIG9mIHRo ZSBOQUNLIHVwIHRvIHRoZTxCUj5yZXRyYW5zbWl0dGluZyBlbnRpdHkgYW5kIGFsbCB0aGUgd2F5 IGRvd24gcGFzdCANCnRoZSBUUExSIHNlbmRlciB0byB0aGU8QlI+c3VwcHJlc3NlZCByZWNlaXZl ci4gVGhlIHJlY2VpdmVyIG1heSBub3QgaGF2ZSBhIHRydWUgDQpSVFQgdG8gdGhlPEJSPm9yaWdp bmFsIG1lZGlhIHNlbmRlciBhcyB0aGF0IHNvdXJjZSBhcHBlYXJzIHRvIGxpdmUgYXQgdGhlIFRQ TFIgDQpzZW5kZXIsPEJSPm5vdCBmdXJ0aGVyIHVwc3RyZWFtLjxCUj48QlI+WWVzLCB0aGUgc2Vu ZGVyIG9mIHRoZSBUUExSIGFuZCB0aGUgDQpyZWNlaXZlciBtaWdodCBhdCBsZWFzdCBoYXZlIG11 dHVhbDxCUj5rbm93bGVkZ2Ugb2YgZWFjaCBvdGhlciwgdGh1cyB0aGUgVFBMUiANCnNlbmRlciBp cyBhYmxlIHRvIGRldGVybWluZSB0aGU8QlI+bG93ZXN0IFJUVCBpbiB0aGUgc2V0IG9mIHJlY2V2 aWVycyB0aHVzIA0KZGV0ZXJtaW5pbmcgaG93IG9mdGVuIHRvIHJlcGVhdDxCUj5pdCB0byBjb3Zl ciBhZGRpdGlvbmFsIHRpbWUgcmVxdXJpZWQgZm9yIHRoZSANCnVwc3RyZWFtIHBhcnQgb2YgdGhl PEJSPnJlcXVlc3QuIEJ1dCBJIGRvIG5vdGUgdGhhdCB0aGVzZSB0aW1lcyBhcmVuJ3QgbWF0Y2hp bmcgDQp3aGF0IGFwcGVhciB0bzxCUj5iZSB0aGUgZGVsYXlzIGluIHRoZSBzeXN0ZW1zLjxCUj48 QlI+Q2FuIHdlIGZpbmQgYSBiZXR0ZXIgDQpzb2x1dGlvbj88L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPg0KPFAg DQpzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2lu YXRpb246IHdpZG93LW9ycGhhbjsgdGFiLXN0b3BzOiA0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgz LjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMu OHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCIgDQpjbGFzcz1Nc29O b3JtYWwgYWxpZ249bGVmdD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGNvbG9yPSMwMDAwZmY+W1Fp bl06IEl0IGxvb2tzIA0KdG8gbWUgdGhlIHJvdW5kIHRyaXAgdGltZSBiZXR3ZWVuIG1lZGlhIHNv dXJjZSBhbmQ8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIA0Kc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IHRhYi1z dG9wczogNDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42 cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJw dCA2ODcuMHB0IDczMi44cHQiIA0KY2xhc3M9TXNvTm9ybWFsIGFsaWduPWxlZnQ+PFNQQU4gbGFu Zz1FTi1VUz48Rk9OVCANCmNvbG9yPSMwMDAwZmY+Jm5ic3A7aW50ZXJtZWRpYXJ5Jm5ic3A7aXMg dHJpdmlhbCBpZiB3ZSBhc3N1bWUgdGhlIGludGVybWVkaWFyeSANCmlzIG11Y2ggPC9GT05UPjwv U1BBTj48L1A+DQo8UCANCnN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBjbSAwY20g MHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuOyB0YWItc3RvcHM6IDQ1LjhwdCA5MS42 cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJw dCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0 IiANCmNsYXNzPU1zb05vcm1hbCBhbGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgY29s b3I9IzAwMDBmZj5jbG9zZXIgdG8gdGhlIA0Kc291cmNlLCB0aGF0IGlzIHdoeSBJIHB1dCB0aGUg bGFzdCBwYXJhZ3JhcGggaW4gdGhlIDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgDQpzdHlsZT0iVEVY VC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93 LW9ycGhhbjsgdGFiLXN0b3BzOiA0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0 IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQg NTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCIgDQpjbGFzcz1Nc29Ob3JtYWwgYWxpZ249 bGVmdD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGNvbG9yPSMwMDAwZmY+c2VjdGlvbiAzIGFzIA0K Zm9sbG93czo8P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbyBucyA9IA0KInVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgLz48bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9Q Pg0KPFAgDQpzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNv LXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsgdGFiLXN0b3BzOiA0NS44cHQgOTEuNnB0IDEzNy40 cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBw dCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCIgDQpjbGFz cz1Nc29Ob3JtYWwgYWxpZ249bGVmdD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIA0KY29sb3I9IzAw MDBmZj6TPG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIA0Kc3R5bGU9IlRFWFQtQUxJ R046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBo YW47IHRhYi1zdG9wczogNDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQu OHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40 cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiIA0KY2xhc3M9TXNvTm9ybWFsIGFsaWduPWxlZnQ+ PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBjb2xvcj0jMDAwMGZmPkluIG9yZGVyIG5vdCB0byANCmlu Y3VyIGEgbG90IG9mIE5BQ0sgcmVxdWVzdHMgZHVlIHRvIGFkZGl0aW9uYWwgVFBMUiA8L0ZPTlQ+ PC9TUEFOPjwvUD4NCjxQIA0Kc3R5bGU9IlRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IHRhYi1zdG9wczogNDUuOHB0IDkx LjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIu MnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44 cHQiIA0KY2xhc3M9TXNvTm9ybWFsIGFsaWduPWxlZnQ+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBj b2xvcj0jMDAwMGZmPmRlc2NyaWJlZCBhYm92ZSwgDQppdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRo ZSBSVFAgc3lzdGVtIHNlbmRpbmcgPC9GT05UPjwvU1BBTj48L1A+DQo8UCANCnN0eWxlPSJURVhU LUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ct b3JwaGFuOyB0YWItc3RvcHM6IDQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQg Mjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1 OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0IiANCmNsYXNzPU1zb05vcm1hbCBhbGlnbj1s ZWZ0PjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgY29sb3I9IzAwMDBmZj5UUExSIHNob3VsZCBiZSAN CmltcGxlbWVudGVkIG1vcmUgY2xvc2VyIHRvIHRoZSBzb3VyY2UuIEFsc28gd2hlbjwvRk9OVD48 L1NQQU4+PC9QPg0KPFAgDQpzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsgdGFiLXN0b3BzOiA0NS44cHQgOTEu NnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4y cHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhw dCIgDQpjbGFzcz1Nc29Ob3JtYWwgYWxpZ249bGVmdD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGNv bG9yPSMwMDAwZmY+Jm5ic3A7dGhlIGxvc3MgDQp3YXMgZGV0ZWN0ZWQgYW5kIHJlcGFpciBpbml0 aWF0ZWQgbXVjaCBjbG9zZXIgdG8gdGhlIHNvdXJjZSwgPC9GT05UPjwvU1BBTj48L1A+DQo8UCAN CnN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tcGFnaW5h dGlvbjogd2lkb3ctb3JwaGFuOyB0YWItc3RvcHM6IDQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMu MnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44 cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0IiANCmNsYXNzPU1zb05v cm1hbCBhbGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgY29sb3I9IzAwMDBmZj50aGUg ZGVsYXkgZm9yIA0KdGhlIHJlY2VpdmVyIHRvIHJlY292ZXIgZnJvbSBwYWNrZXQgbG9zcyBjYW4g YmUgcmVkdWNlZCA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIA0Kc3R5bGU9IlRFWFQtQUxJR046IGxl ZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IHRh Yi1zdG9wczogNDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMy MC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQx LjJwdCA2ODcuMHB0IDczMi44cHQiIA0KY2xhc3M9TXNvTm9ybWFsIGFsaWduPWxlZnQ+PFNQQU4g bGFuZz1FTi1VUz48Rk9OVCBjb2xvcj0jMDAwMGZmPnRocm91Z2ggdGhlIA0KY29tYmluYXRpb24g b2YgaW50ZXJtZWRpYXJ5IGZlZWRiYWNrIHRvIHRoZSBzb3VyY2UgYW5kIDwvRk9OVD48L1NQQU4+ PC9QPg0KPFAgDQpzdHlsZT0iVEVYVC1BTElHTjogbGVmdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg bXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsgdGFiLXN0b3BzOiA0NS44cHQgOTEuNnB0IDEz Ny40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4 LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCIgDQpj bGFzcz1Nc29Ob3JtYWwgYWxpZ249bGVmdD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGNvbG9yPSMw MDAwZmY+VGhpcmQgUGFydHkgTG9zcyANClJlcG9ydCBkb3duc3RyZWFtLjxvOnA+PC9vOnA+PC9G T05UPjwvU1BBTj48L1A+DQo8UCANCnN0eWxlPSJURVhULUFMSUdOOiBsZWZ0OyBNQVJHSU46IDBj bSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuOyB0YWItc3RvcHM6IDQ1Ljhw dCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQg NDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3 MzIuOHB0IiANCmNsYXNzPU1zb05vcm1hbCBhbGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVM+PEZP TlQgDQpjb2xvcj0jMDAwMGZmPpQ8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIA0Kc3R5bGU9IlRFWFQt QUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1v cnBoYW47IHRhYi1zdG9wczogNDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAy NzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5 NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiIA0KY2xhc3M9TXNvTm9ybWFsIGFsaWduPWxl ZnQ+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjxGT05UIA0KY29sb3I9IzAwMDBmZj48L0ZPTlQ+PC9v OnA+PC9TUEFOPiZuYnNwOzwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFz cz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmNvbG9yPSMwMDAwZmY+SWYgd2Ug bG9vayBmb3IgYSBiZXR0ZXIgc29sdXRpb24sIEkgdGhpbmsgd2UgaGF2ZSB0d28gcG9zc2libGUg DQp3YXlzOjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpjb2xv cj0jMDAwMGZmPlRoZSBmaXJzdCB3YXkgaXMgdG8gcmVseSBvbiBzZW5kZXIgcmVwb3J0IGZyb20g bWVkaWEgc2VuZGVyIHRvIA0KPC9GT05UPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpjb2xv cj0jMDAwMGZmPmNhbGN1bGF0ZSB0aGUgbW9yZSBhcHByb3hpbWF0ZSBSVFQgZnJvbSBtZWRpYSBz ZW5kZXIgdG8gdGhlIA0KcmVjZWl2ZXIuIDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPjxGT05U IA0KY29sb3I9IzAwMDBmZj5SVFQgbWVhc3VyZW1lbnQgbWV0aG9kIGZvbGxvd3MgdGhlIHNhbWUg d2F5IGRlc2NyaWJlZCBpbiB0aGUgDQo8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJH SU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCAN CmNvbG9yPSMwMDAwZmY+ZmlndXJlIDIgb2YgUkZDMzU1MC48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQ IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1F Ti1VUz48bzpwPjxGT05UIA0KY29sb3I9IzAwMDBmZj48L0ZPTlQ+PC9vOnA+PC9TUEFOPiZuYnNw OzwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQ QU4gbGFuZz1FTi1VUz48Rk9OVCANCmNvbG9yPSMwMDAwZmY+VGhlIHNlY29uZCB3YXkgaXMgdG8g d2UgY2FuIGFsbG93IHRoZSBpbnRlcm1lZGlhcnkgdGVsbCB0aGUgDQpyZWNlaXZlciB0aGUgPC9G T05UPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPlJUVCBmcm9tIG1l ZGlhIHNvdXJjZSB0byBpbnRlcm1lZGlhcnkgaXRzZWxmIGJ5IHNlbmRpbmcgYSBuZXcgDQptZXNz YWdlIDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNs YXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIA0KY29sb3I9IzAwMDBmZj5zaW5j ZSB0aGUgaW50ZXJtZWRpYXJ5IGNhbiBtZWFzdXJlIHN1Y2ggUlRUIGJhc2VkIG9uIHBhc3QgDQpv YnNlcnZhdGlvbiA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmNvbG9yPSMwMDAw ZmY+YW5kIGVzdGltYXRpb24uIEhvd2V2ZXIgZm9yIHRoZSBzZWNvbmQgd2F5IHdlIG5lZWQgdG8g ZGVmaW5lIG5ldyANCjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBj bSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIA0KY29sb3I9IzAw MDBmZj5tZXNzYWdlIG9yIGV4dGVuZCBUUExSIG1lc3NhZ2UgdG8gY2Fycnkgc3VjaCANClJUVC48 L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1N c29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjxGT05UIA0KY29sb3I9IzAwMDBmZj48L0ZP TlQ+PC9vOnA+PC9TUEFOPiZuYnNwOzwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0 IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmNvbG9yPSMwMDAwZmY+ V2hhdCBkbyB5b3UgdGhpbms/IDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCmxhbmc9RU4tVVM+PC9TUEFOPiZu YnNwOzwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gbGFuZz1FTi1VUz48L1NQQU4+My4gDQpTZWN0aW9uIDM6PEJSPiZuYnNwOyAiVG8gaW5j cmVhc2UgdGhlIHJvYnVzdG5lc3MgdG8gdGhlIGxvc3Mgb2YgYSBUUExSIG9yIG9mIGEgDQp0cmFu c21pc3Npb248QlI+Jm5ic3A7Jm5ic3A7IHBhY2tldCwgYSByZWNlaXZlciBpcyBhbGxvd2VkIHRv IHJlY2VpdmUgYWRkaXRpb25hbCANClRQTFIgZm9yIHRoZSBzYW1lPEJSPiZuYnNwOyZuYnNwOyBw YWNrZXQuJm5ic3A7IEluIHRoZSBjYXNlIHRoZSBmaXJzdCBUUExSIGlzIA0KbG9zdCBhbmQgdGhl IGFkZGl0aW9uYWwgVFBMUjxCUj4mbmJzcDsmbmJzcDsgYXJyaXZlcyBhdCB0aGUgcmVjZWl2ZXIs IHRoZSANCnJlY2VpdmVyIHNob3VsZCBpbW1lZGlhdGVseSByZWZyZXNoIHRoZTxCUj4mbmJzcDsm bmJzcDsgdGltZXIuIjxCUj48QlI+SW4gdGhlIA0Kc2Vjb25kIHNlbnRlbmNlIEkgZG9uJ3Qgc2Vl IGhvdyB0aGUgcmVjZWl2ZXIgY2FuIGtub3cgdGhhdCBpdCBpczxCUj5hIA0KcmV0cmFuc21pc3Np b24uIEl0IGlzIHNpbXBseSBhIFRQTFIgZnJvbSBpdHMgcGVyc3BlY3RpdmUgaWYgdGhhdCBpcyAN Cmxvc3QuPEJSPjxCUj5Sb2J1c3RuZXNzIHJlYXNvbnMgaXMgb25seSBvbmUgcmVhc29uIGZvciBy ZXBlYXRpbmcgdGhlbSB0aGUgb3RoZXIgDQppczxCUj5jbGVhcmx5IHRvIHJlbmV3IHRoZSB0aW1l ci4gVGh1cyBJIHRoaW5rIHRoZSBmb3JtdWxhdGlvbiBzaG91bGQgYmUgDQptb3JlPEJSPmdlbmVy aWMgdG8gbWFrZSBpdCBjbGVhciB0aGF0IGFsbCByZWNlaXZlcnMgc2hvdWxkIHVwb24gcmVjZXB0 aW9uIG9mIA0KYTxCUj5UUExSIHJlZnJlc2ggdGhlIHRpbWVyIGZvciB0aGUgcGFja2V0cyBpbmRp Y2F0ZWQuPC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1h bD4mbmJzcDs8L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9y bWFsPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPltRaW5dOiBJZiB0aGUg cmVjZWl2ZXIgZG9lcyBub3Qga2VlcCBzdGF0ZSBmb3IgdGhlIHRpbWVzIHRoZSBUUExSIA0KaXM8 L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1N c29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmNvbG9yPSMwMDAwZmY+Jm5ic3A7cmV0 cmFuc21pdHRlZCwgd2UgY2FuIGFkZCByZXBldGl0aW9uIGNvdW50IGZpZWxkIGluIGVhY2ggRkNJ IA0KZW50cnk8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0 IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmNvbG9yPSMwMDAwZmY+ Jm5ic3A7b2YgVFBMUiBmZWVkYmFjayBtZXNzYWdlIHRvIGluZGljYXRlIHRoZSB0aW1lcyBUUExS IGlzIA0KcmV0cmFuc21pdHRlZC48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCANCmNv bG9yPSMwMDAwZmY+Jm5ic3A7UGFydGljdWxhcmx5IGluIFBTTEVJIEZlZWRiYWNrIE1lc3NhZ2Us IHdlIGNhbiByZXVzZSBzZXEgbnIuIA0KRmllbGQgdG88L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0 eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1V Uz48Rk9OVCANCmNvbG9yPSMwMDAwZmY+Jm5ic3A7aW5kaWNhdGUgaWYgYWRkaXRpb25hbCBUUExS IGlzIHJldHJhbnNtaXR0ZWQsIHdoaWNoIG9uZSB5b3UgDQp0aGluayBiZXR0ZXI/PG86cD48L286 cD48L0ZPTlQ+PC9TUEFOPjwvUD48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7Pjwv Rk9OVD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PEJS PjxCUj40LiBTZWN0aW9uIDMuPEJSPiJUaGUgDQptZWRpYSBzb3VyY2Ugb3IgaW50ZXJtZWRpYXRl IG5vZGVzIGNhbm5vdCBhc3N1bWUgdGhhdCB0aGUgdXNlIG9mPEJSPiZuYnNwOyZuYnNwOyANCmEg VGhpcmQgUGFydHkgTG9zcyBSZXBvcnQgbWVzc2FnZSBhY3R1YWxseSByZWR1Y2VzIHRoZSBhbW91 bnQgb2Y8QlI+Jm5ic3A7Jm5ic3A7IA0KZmVlZGJhY2sgaXQgcmVjZWl2ZXMuIjxCUj48QlI+SSB3 b3VsZCByZWNvbW1lbmQgdGhhdCBvbmUgY2hhbmdlcyAiYXNzdW1lIiB0byAiYmUgDQpjZXJ0YWlu Ii4gVGhlPEJSPmludGVudGlvbiBpcyB0aGF0IFRQTFJzIHNob3VsZCByZWR1Y2VkIHRoZSBmZWVk YmFjaywgYnV0IGl0IGlzIA0Kbm90PEJSPmd1YXJhbnRlZWQuPC9QPg0KPFAgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8L1A+DQo8UCBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTVFJPTkc+W1Fpbl06IA0KT2theS48 L1NUUk9ORz48L1A+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzs+PC9GT05UPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNz PU1zb05vcm1hbD48QlI+PEJSPjUuIFNlY3Rpb24gNC4xOjxCUj4iYW5kIA0KdGhlICJTU1JDIG9m IG1lZGlhIHNvdXJjZSI8QlI+Jm5ic3A7Jm5ic3A7IGRlbm90ZXMgdGhlIG1lZGlhIHNlbmRlci4i PEJSPjxCUj5JIA0Kd291bGQgZXhwYW5kIHRoaXMsIHRvIHNheSB0aGUgImRlbm90ZXMgdGhlIG1l ZGlhIHNlbmRlciBvZiB0aGUgZmxvdzxCUj5mb3Igd2hpY2ggDQp0aGUgaW5kaWNhdGVkIGxvc3Nl cyBhcmUgYmVpbmcgc3VwcHJlc3NlZC4iPEJSPjxCUj5UaGlzIHRvIG1ha2UgaXQgbW9yZSBjbGVh ciANCnRoYXQgdGhpcyBmaWVsZCBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZTxCUj5zZXF1ZW5jZSBu dW1iZXIgc3BhY2UgZm9yIHdoaWNoIHRoZSANCnJlc3QgaWRlbnRpZmllcyB3aGljaCBwYWNrZXRz IHdoZXJlPEJSPmxvc3MgaXMgc3VwcHJlc3NlZC48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20g MGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBj bSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNUUk9ORz5bUWluXTogDQpPa2F5LjxCUj48L1NU Uk9ORz48QlI+Ni4gU2VjdGlvbiA0LjI6PEJSPiJFYWNoIGVudHJ5IGFwcGxpZXMgdG8gYSBkaWZm ZXJlbnQgDQptZWRpYTxCUj4mbmJzcDsmbmJzcDsgU291cmNlIHRoYXQgaXMgcmVxdWVzdGVkIHRv IHNlbmQgYSBkZWNvZGVyIHJlZnJlc2ggcG9pbnQgDQpvciB0aGF0IGlzPEJSPiZuYnNwOyZuYnNw OyBpbmRpY2F0ZWQgdGhhdCBpdCBsb3N0IHN5bmNocm9uaXphdGlvbiB3aXRoIHRoZSB2aWRlbyAN CnN0cmVhbSw8QlI+Jm5ic3A7Jm5ic3A7IGlkZW50aWZpZWQgYnkgaXRzIFNTUkMuIjxCUj48QlI+ YW5kPEJSPjxCUj4iU1NSQyAoMzIgDQpiaXRzKTo8QlI+PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGUgU1NSQyB2YWx1ZSBvZiB0aGUgbWVkaWEgc291cmNlIA0KdGhhdCBpcyBy ZXF1ZXN0ZWQgdG8gc2VuZCBhPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWNv ZGVyIHJlZnJlc2ggDQpwb2ludCBvciB0aGF0IGlzIGluZGljYXRlZCB0aGF0IGl0IGxvc3Q8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0Kc3luY2hyb25pemF0aW9uIHdpdGggdGhl IHZpZGVvIHN0cmVhbS4iPEJSPjxCUj5JIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgYmV0dGVyIA0K ZGVmaW5lZCB0byBpZGVudGlmeSB0aGF0IHRoZXNlIGFyZSB0aGU8QlI+U1NSQ3Mgb2YgdGhlIGZs b3dzIGZvciBvbiB3aGljaCANCnN1cHByZXNzaW9uIG9mIHRyYW5zbWlzc2lvbiBvZiBQTEkgb3I8 QlI+RklSIGlzIHN1cHByZXNzZWQuPC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQi IGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBw dCIgY2xhc3M9TXNvTm9ybWFsPjxTVFJPTkc+W1Fpbl06T2theSwgd2lsbCBkbyBpdCBpbiANCnRo ZSBuZXcgdmVyc2lvbi48L1NUUk9ORz48L0ZPTlQ+PEJSPjxCUj43LiBTZWN0aW9uIDQuMjo8QlI+ Jm5ic3A7Jm5ic3A7IFNlcSANCm5yOjhiaXRzJm5ic3A7IENvbW1hbmQgc2VxdWVuY2UgbnVtYmVy LiZuYnNwOyBJdCBpcyB1c2VkIGJ5IHRoZSANCkNvbW1hbmQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHJlY2VpdmVyIHRvIGNoZWNrIGlmIHRoZSBDb21tYW5kIGlzIA0KcmVwZWF0 ZWQuJm5ic3A7IFRoZSBzZXF1ZW5jZSBudW1iZXI8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNwYWNlIGlzIA0KdW5pcXVlIGZvciBlYWNoIHBhaXJpbmcgb2YgdGhlIFNTUkMgb2Yg Y29tbWFuZCBzZW5kZXIgDQphbmQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo ZSBTU1JDIG9mIHRoZSBjb21tYW5kIHJlY2VpdmVyLiZuYnNwOyANClRoZSBzZXF1ZW5jZSBudW1i ZXIgU0hBTEw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluY3JlYXNlIGJ5IDEg bW9kdWxvIA0KMjU2IGZvciBlYWNoIG5ldyBDb21tYW5kLiZuYnNwOyBBIHJlcGV0aXRpb24gDQpT SEFMTDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTk9UIGluY3JlYXNlIHRoZSBz ZXF1ZW5jZSBudW1iZXIuJm5ic3A7IA0KVGhlIGluaXRpYWwgdmFsdWUgaXMgYXJiaXRyYXJ5LjxC Uj48QlI+QmFzZWQgb24gdGhhdCBpdCBpcyBkZWZpbmVkIHRoYXQgdXBvbiANCnJlY2VpdmluZyBv bmUgb2YgdGhlIFBTTEVJPEJSPnJlcXVlc3QsIG9uZSBzaG91bGRuJ3Qgc2VuZCBhIEZJUiBvciBQ TEkgbWVzc2FnZSANCmZvciBhIHRpbWUgaW50ZXJ2YWw8QlI+ZXF1YWwgdG8gdGhlIFJUVCBiZXR3 ZWVuIHRoZSByZWNlaXZlciBhbmQgdGhlIHNlbmRlciBvZiANCnRoZSBQU0xFSTxCUj5tZXNzYWdl IGRvZXMgdGhlIHNlcXVlbmNlIG51bWJlciBmaWVsZCBoYXZlIGFueSBtZWFuaW5nPyBGcm9tIA0K bXk8QlI+cGVyc3BlY3RpdmUgaXQgZG9lc24ndCBtYXR0ZXIgaWYgaXQgaXMgYSBuZXcgcmVxdWVz dCBvciBub3QuIFlvdSANCmFyZTxCUj5zdXBwcmVzc2VkIGZyb20gdGhlIHJlY2VwdGlvbiBvZiB0 aGUgbWVzc2FnZSwgbm90aGluZyBlbHNlLjxCUj48QlI+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIA0KY29s b3I9IzAwMDBmZj5bUWluXTogSSB0aGluayB3ZSBjYW4gdXNlIHNlcSBuciBmaWVsZCB0byBpbmRp Y2F0ZSB0aGUgdGltZXMgdGhlIA0KVFBMUiBpcyByZXRyYW5zbWl0dGVkLCBlLmcuLDxvOnA+PC9v OnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xh c3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPklmIHRo ZSBhZGRpdGlvbmFsIFRQTFIgd2l0aCB0aGUgc2FtZSBTU1JDIGFuZCBkaWZmZXJlbnQgU2VxIE51 bWJlciANCmlzIHJlY2VpdmVkLCB0aGUgPC9GT05UPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQg DQpjb2xvcj0jMDAwMGZmPnJlY2VpdmVyIGtub3dzIHRoYXQgaXQgaXMgYSByZXRyYW5zbWlzc2lv biBpZiB0aGUgcmVjZWl2ZXIga2VlcHMgDQpzdGF0ZSBmb3IgdGhlIHByZXZpb3VzIDwvRk9OVD48 L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1h bD48U1BBTiBsYW5nPUVOLVVTPjxGT05UIA0KY29sb3I9IzAwMDBmZj5UUExSIHdpdGggdGhlIHNh bWUgU1NSQy48bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTog J0NhbGlicmknLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMC41cHQ7IG1zby1iaWRpLWZvbnQt c2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7OyBtc28tZmFyZWFzdC10aGVtZS1mb250 OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1i aWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktdGhlbWUtZm9udDog bWlub3ItYmlkaTsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFn ZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgDQpsYW5nPUVOLVVTPjxGT05UIGNv bG9yPSMwMDAwZmYgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+QWxzbyB3ZSBjYW4gcmVw bGFjZSANCnNlcSBuci4gRmllbGQgd2l0aCBSZXBldGl0aW9uIGNvdW50IGZpZWxkIHRvIGluZGlj YXRlIGhvdyBtYW55IHRpbWUgDQo8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgY29sb3I9IzAwMDBmZj48U1BBTiAN CnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAx MC41cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTEuMHB0OyBtc28tYXNjaWktdGhlbWUtZm9udDog bWlub3ItbGF0aW47IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmIzIzNDM1OyYjMjAzMDc7OyBt c28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktdGhlbWUtZm9u dDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsg bXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItYmlkaTsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVT OyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIg DQpsYW5nPUVOLVVTPjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPnRoZSBUUExS IGlzIDwvRk9OVD48L1NQQU4+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywn c2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTAuNXB0OyBtc28tYmlkaS1mb250LXNpemU6IDExLjBw dDsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC1mb250LWZh bWlseTogJiMyMzQzNTsmIzIwMzA3OzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFy ZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7 IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBt c28tYmlkaS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1VUz48Rk9OVCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj5yZXRyYW5zbWl0dGVkLiANCjwvRk9OVD48L1NQQU4+PC9GT05UPjwv UD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIHNpemU9Mz48Rk9OVCBzaXplPTIg DQpmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBj bSAwcHQiIGNsYXNzPU1zb05vcm1hbD48QlI+OC4gU2VjdGlvbiA1LjxCUj4iIHVzaW5nIHRoZSAN CkF1Z21lbnRlZCBCYWNrdXMtTmF1ciBGb3JtIChBQk5GKTxCUj4mbmJzcDsmbmJzcDsgW1JGQzQ1 ODVdLiI8QlI+PEJSPlRoZSANCnJlZmVyZW5jZSBpcyB3cm9uZy4gVGhlIGZvcm0gb2YgdGhlIHJl ZmVyZW5jZSBpbXBsaWVzIHRoYXQgdGhlPEJSPnJlZmVyZW5jZSBpcyANCmZvciBBQk5GIHdoaWNo IGlzIFJGQyA1MjM0LCByYXRoZXIgdGhhbiB0aGUgc3BlY2lmaWM8QlI+c2VtYW50aWNzIGRlZmlu ZWQgaW4gUkZDIA0KNDU4NS48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xh c3M9TXNvTm9ybWFsPiZuYnNwOzwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+ PEZPTlQgDQpzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD48U1RST05HPltRaW5d OiBPa2F5LCBmaXhlZC48QlI+PC9TVFJPTkc+PEJSPjkuIFNlY3Rpb24gDQo1OjxCUj5UaGUgY29t bWVudHMgaW4gdGhlIEFCTkYgaXMgdG8gbG9uZy4gUGxlYXNlIGJyZWFrIHRoZW0gb3ZlciANCnNl dmVyYWw8QlI+bGluZXMgc28gdGhhdCB0aGV5IGRvbid0IHZpb2xhdGUgdGhlIG1heCBjb2x1bW4g Y291bnQgb2YgdGhlIGRyYWZ0IA0KZm9ybWF0LjxCUj48QlI+QWxzbyAidG9rZW4iIG5lZWRzIHRv IGhhdmUgYSByZWZlcmVuY2UgbGlrZSBmb3IgdGhlIA0KImJ5dGUtc3RyaW5nIi48L1A+DQo8UCBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzwvUD4NCjxQ IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNUUk9ORz5bUWlu XTogT2theSwgDQpmaXhlZC48L1NUUk9ORz48QlI+PEJSPjEwLiBTZWN0aW9uIDYuMjo8QlI+IiBv bmUgb3IgbW9yZSBCUlNlcy4gDQpvbmUiPEJSPjxCUj5TdHJhbmdlIHB1bmN0dWF0aW9uLjxCUj48 QlI+MTEuIFNlY3Rpb24gNy48QlI+IlNlbmRpbmcgdGhlIHNwdXJpb3VzIA0KVGhpcmQgUGFydHkg TG9zcyBSZXBvcnQgKGUuZy4sIHRoZSBUaGlyZCBQYXJ0eTxCUj4mbmJzcDsmbmJzcDsgTG9zcyBS ZXBvcnQgd2l0aCANCnRoZSB3cm9uZyBzZXF1ZW5jZSBudW1iZXIgb2YgbG9zdCBwYWNrZXQpIHRo YXQgbWFrZXM8QlI+Jm5ic3A7Jm5ic3A7IG1pc3NpbmcgUlRQIA0KcGFja2V0cyBjYW4gbm90IGJl IGNvbXBlbnNhdGVkLiI8QlI+PEJSPiJ0aGF0IG1ha2VzIiBzZWVtcyB0byBiZSBzdHJhbmdlIA0K Z3JhbW1lci4gUGxlYXNlIHJld29yZC48QlI+Ii4uLiB0aGF0IGNhdXNlcyBtaXNzaW5nIFJUUCBw YWNrZXRzIHRvIG5vdCBiZSANCnJlcGFpcmVkIGluIGEgdGltZWx5PEJSPmZhc2hpb24uIj88L1A+ DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzwv UD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNUUk9O Rz5bUWluXTogT2theSwgDQpmaXhlZC48L1NUUk9ORz48QlI+PEJSPjxCUj4xMi4gU2VjdGlvbiA4 LjxCUj4mbmJzcDsmbmJzcDsgTmV3IHJlZ2lzdHJhdGlvbiBpbiANCnRoaXMgcmVnaXN0cnkgZm9s bG93cyB0aGUgIlNwZWNpZmljYXRpb248QlI+Jm5ic3A7Jm5ic3A7IHJlcXVpcmVkIiBwb2xpY3kg YXMgDQpkZWZpbmVkIGJ5IFtSRkMyNDM0XS4mbmJzcDsgSW4gYWRkaXRpb24sIHRoZXkgYXJlPEJS PiZuYnNwOyZuYnNwOyByZXF1aXJlZCB0byANCmluZGljYXRlIGFueSBhZGRpdGlvbmFsIFJUQ1Ag ZmVlZGJhY2sgdHlwZXMsIHN1Y2ggYXM8QlI+Jm5ic3A7Jm5ic3A7ICJuYWNrIiBhbmQgDQoiYWNr Ii48QlI+PEJSPlRoZSByZWZlcmVuY2Ugc2hvdWxkIGJlIFJGQyA1MjI2LjxCUj48QlI+SW4gYWRk aXRpb24geW91IHNob3VsZCANCmNoZWNrIHRoZSBwbHVyYWwgZm9ybXMgdGhhdCBpcyBjdXJyZW50 bHkgdXNlZCw8QlI+ZHVlIHRvIHRoZSBjb3B5IGFuZCBwYXN0ZSBmcm9tIA0KUkZDIDUxMDQgdG8g c2luZ3VsYXIgZm9ybSBhcyBvbmx5IGE8QlI+c2luZ2xlIG9mIGVhY2ggdHlwZSBpcyBwcmVzZW50 IGluIHRoZSBGTVQgDQpyZWdpc3RyYXRpb24gcmVxdWVzdHMuPEJSPjxCUj5Zb3UgYXJlIGFsc28g bWlzc2luZyB0aGUgdGhlIGluaXRpYWwgdmFsdWVzIGluIHRoZSANCiJUaGlyZCBQYXJ0eSBMb3Nz PEJSPlJlcG9ydCBNZXNzYWdlcyIgcmVnaXN0cnkgeW91IGNyZWF0ZS4gQm90aCBUTExFSSBhbmQg UFNMRUkgDQpzaG91bGQgYmU8QlI+cGFydCBvZiB0aGF0IHJlZ2lzdHJ5IHNob3VsZG4ndCB0aGV5 PzwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+Jm5i c3A7PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48 U1RST05HPltRaW5dOiBPa2F5LCANCmZpeGVkLjwvU1RST05HPjxCUj48QlI+MTMuIFNlY3Rpb24g MTAuMTo8QlI+PEJSPlRoZSBmb2xsb3dpbmcgcmVmZXJlbmNlcyBJIHRoaW5rIA0Kc2hvdWxkIGJl IG1vdmVkIHRvIHRoZSBJbmZvcm1hdGl2ZTxCUj5zZWN0aW9uIGluc3RlYWQgKDEwLjIpLiBUaGUg cmVhc29uIGFyZSANCnRoYXQgdGhleSBhcmUgbm90IHN0cmljdGx5IG5lZWRlZDxCUj5mb3IgaW1w bGVtZW50YXRpb24gYW5kIHVuZGVyc3RhbmRpbmcgb2YgdGhlIA0Kbm9ybWF0aXZlIHBhcnRzLjxC Uj48QlI+UkZDIDU3NjA8QlI+UkZDIDM3MTE8QlI+UkZDIDUxMjQ8QlI+PEJSPlRoZSBmb2xsb3dp bmcgDQppc24ndCB1c2VkIGluIHRoZSB0ZXh0IGF0IGFsbDo8QlI+UkZDIDM1NTA8L1A+DQo8UCBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzwvUD4NCjxQ IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNUUk9ORz5bUWlu XTogT2theSwgDQpmaXhlZC48L1NUUk9ORz48QlI+PEJSPkNoZWVyczxCUj48QlI+TWFnbnVzIA0K V2VzdGVybHVuZDxCUj48QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5NdWx0aW1lZGlhIA0KVGVjaG5vbG9n aWVzLCBFcmljc3NvbiBSZXNlYXJjaCANCkVBQi9UVk08QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5Fcmlj c3NvbiANCkFCJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCBQaG9uZSZuYnNw OyArNDYgMTAgNzE0ODI4NzxCUj5G5HL2Z2F0YW4gDQo2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzk8QlI+U0UtMTY0IDgwIFN0b2NraG9s bSwgU3dlZGVufCBtYWlsdG86IDwvRk9OVD48L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86bWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tIj5tYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208 L0E+PEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPEJSPkF1ZGlvL1ZpZGVvIA0KVHJhbnNwb3J0IENvcmUgTWFpbnRl bmFuY2U8QlI+PEEgDQpocmVmPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5vcmc8L0E+ PEJSPjxBIA0KaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0PC9BPjxCUj48L1A+PC9E SVY+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_GT0MYcDqjFnyAwAiXXnoXA)-- From bill.wu@huawei.com Mon Oct 10 19:49:58 2011 Return-Path: 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 D7DF921F8C6F for ; Mon, 10 Oct 2011 19:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_84=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 DEbPfKVYDrB8 for ; Mon, 10 Oct 2011 19:49:56 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id E513821F8C6E for ; Mon, 10 Oct 2011 19:49:55 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSV00294RPKZR@szxga04-in.huawei.com> for avt@ietf.org; Tue, 11 Oct 2011 10:46:32 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSV0074IRP3SX@szxga04-in.huawei.com> for avt@ietf.org; Tue, 11 Oct 2011 10:46:32 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AED86479; Tue, 11 Oct 2011 10:46:29 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 10:46:26 +0800 Received: from w53375q (10.138.41.130) by szxeml406-hub.china.huawei.com (10.82.67.93) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 10:46:20 +0800 Date: Tue, 11 Oct 2011 10:46:19 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Roni Even , avt@ietf.org Message-id: <76AADF1A61784B52A8516E16AAF78E71@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_ylaBF/OsDDeImGWJZ5qkeg)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> Cc: Magnus Westerlund Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 02:49:59 -0000 --Boundary_(ID_ylaBF/OsDDeImGWJZ5qkeg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi, I have reviewed this draft and support it moving towards publication. Here is my minor editional comments to this 04 version draft. 1. Section 1 [Qin]:Is it better to move the first paragraph next to the third paragraph. 2. Section 3, 1st paragraph " ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], and DCCP [RFC4340] transports. These are all unicast protocols which negotiate the use of ECN during the initial connection establishment handshake (supporting incremental deployment, and checking if ECN marked packets pass all middleboxes on the path). " [Qin]: I think "these" in the second sentence can't be "ECN" mentioned in the first sentence. Is it better to replace "these" the first word in this sentence with "these transport"? " ECN-CE marks are immediately echoed back to the sender by the receiving end-point using an additional bit in feedback messages, and the sender then interprets the mark as equivalent to a packet loss for congestion control purposes. " [Qin]: For this sentence, it is not clear to me what is the feedback message? Is feedback message a new RTCP Feedback message defined in this document or TCP message or SCTP message? If it is latter, I would like to change it as these transport protocols header 3. Section 3, 2nd paragraph " Counting vs Detecting Congestion: TCP and the protocols derived from it are mainly designed to respond the same whether they experience a burst of congestion indications within one RTT or just one. " [Qin]: What's the difference between "one RTT" and "just one"? 4. Section 3.1 [Qin]: Any requirements that should be met by the middlebox or intermediate node? 5. Section 3.2,3rd paragraph " Topo-Point-to-Point: This is a standard unicast flow. .... " [Qin]: Topo-point-to-point is not flow but a topology. Should this sentence be rephrased as "This is for a standard unicast flow". " Accordingly, we allow ECN to be used by an RTP sender using multicast UDP provided the sender has verified that the paths to all its known receivers support ECN, and irrespective of whether the paths from other senders to their receivers support ECN ("all its known receivers" are all the SSRCs that the RTP sender has received RTP or RTCP from the last five reporting intervals, i.e., they have not timed out). " [Qin]: Five is default value of the timeout multiplier, do you think other value is not allowed? " Since only a subset of the RTP packets generated by a sender are forwarded to the receivers, a video switching MCU can break ECN negotiation (the success of the ECN negotiation may depend on the voice activity of the participant at the instant the negotiation takes place - shout if you want ECN). " [Qin]: Is "shout if you want ECN" appropirate language here? 6. Section 3.2, 4th paragraph " This is a great benefit as the rate of an RTP session can be varied in a number of ways, " [Qin]: Should "rate" in this sentence be data rate or bitrate? 7. Section 3.2, 5th paragraph " The standard RTP/ AVP profile [RFC3551] does not allow any early or immediate transmission of RTCP feedback, and has a minimal RTCP interval whose default value (5 seconds) is many times the normal RTT between sender and receiver. " [Qin]: What's the purpose of last sentence of this paragraph? Are you saying RFC3551 following Regular RTCP timing rule? or something else? Another question is according to RFC3551, the negotiation of parameters or membership control may be not support. in other wonder, there may be no way to negotiate ECN with RTP using SDP signaling, I am wondering can we say ECN with RTP can be used with the standard RTP/ AVP profile [RFC3551]. 8. Section 3.3,3rd paragraph " For interoperability we mandate the implementation of the RTP/AVPF profile, with both RTCP extensions and the necessary signalling to support a common operations mode. This specification recommends the use of RTP/AVPF in all cases as negotiation of the common interoperability point requires RTP/AVPF, mixed negotiation of RTP/ AVP and RTP/AVPF depending on other SDP attributes in the same media block is difficult, " [Qin] How mixed negotiation is avoided when you don't put all the SDP attribute into the same media block? I don't really understand the rationale. Would you like to clarify a little bit? 9. Section 4, 1st paragraph " 2. Initiation and initial verification of ECN capable transport " [Qin]: It looks the bullet 2 has two steps, a. Initiation procedure b. inital verification procedure, If there is no STUN exchange in between, if the step (a) initiation procedure is required? 10. Section 4, 2nd paragraph " This document defines the information that needs to be negotiated, and provides a mapping to SDP for use in both declarative and offer/answer contexts. " [Qin]: Would it be better to add an anchor pointing to the section 6.1.1 and 6.1.2? 11. Section 4, 3rd paragraph " o The sender may generate a (small) subset of its RTP data packets with the ECN field set to ECT(0) or ECT(1). " [Qin] It is not clear to me where the ECN field is located. Is ECN field in the IP header or UDP header or RTP header? 12. Section 5, 1st paragraph " This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585] transport layer feedback format for urgent ECN information, " [Qin]: Should the "urgent ECN information" be "urgent ECN information reporting" 13.Section 5.1,1st paragraph " This RTP/AVPF transport layer feedback format is intended for use in RTP/AVPF early or immediate feedback modes when information needs to urgently reach the sender. Thus its main use is to report reception of an ECN-CE marked RTP packet so that the sender may perform congestion control, or to speed up the initiation procedures by rapidly reporting that the path can support ECN-marked traffic. " [Qin]: are you saying slow initiation procedure may result in network congestion? In my understanding, when ECN-CE marked packet is received, the only choice for sender is to do congestion control since you are not sure if initiation procedure lead to such congestion. If it is not intiation procedure that lead to congestion, you get risk to worse congestion condition? 14.Section 6.1, 1st paragraph " One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a media level attribute, and MUST NOT be used at the session level. It is not subject to the character set chosen. " [Qin] Would it better to put reference to the section 6 of RFC4566 for character set? 15. Sectioin 6.1, 2nd paragraph " ect: This parameter makes it possible to express the preferred ECT marking. This is either "random", "0", or "1", with "0" being implied if not specified. The "ect" parameter describes a receiver preference, and is useful in the case where the receiver knows it is behind a link using IP header compression, the efficiency of which would be seriously disrupted if it were to receive packets with randomly chosen ECT marks. It is RECOMMENDED that ECT(0) marking be used. " [Qin]: It looks ect is not well specified here. e.g.,what it means if ect is set to "random" or "1" from above paragraph. what does "randomly chosen" stand for? I think when ect is set 0, it means ECT(0) is chosen, when ect is set 1, it means ECT(1) is chosen, when ect is set random, it means either ECT(0) or ECT(1) is chosen. I think it should be clear in the text. Also I think the text like ""0" being implied if not specified" in this paragraph is not correct. 16. Section 6.1.3, 2nd paragraph " If timely feedback is not required it is still RECOMMENDED to used RTP/AVPF. " [Qin]: Should "used" in this sentence be "use"? 17.Section 7.1,2nd paragraph " The "rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used whenever the initialization method or a congestion control algorithm requiring timely sender side knowledge of received CE markings. " [Qin]: Should "requiring" in this sentence be "requires"? 18.Section 7.2, 2nd paragraph " At the start of the RTP session, when the first packets with ECT are sent, it is important to verify that IP packets with ECN field values of ECT or ECN-CE will reach their destination(s). " [Qin]: Should "first packets" be "first packet" and "IP packets" be "IP packet"? " If the path between the sender and the receivers exhibits either of these behaviours one " [Qin]: s/the receivers/receiver " If the path between the sender and the receivers exhibits either of these behaviours one needs to stop using ECN immediately to protect both the network and the application. " [Qin]: How does sender or receiver detects ECN is misused? Who is the "one" in this sentence? If it is middlebox, the middlebox should also tell the sender ECN is not used. 19.Section 7.2.1, 1st paragraph " Then any resulting lack of congestion response is likely to have little damaging affect on others. " [Qin] s/affect/effect " Note: The above optimization supports peer to peer unicast transport with several SSRCs multiplexed onto the same flow (e.g., a single participant with two video cameras, or SSRC multiplexed RTP retransmission [RFC4588]). It is desirable to " [Qin]: In SSRC multiplexed RTP Retransmission case, original stream and associated retransmission stream possible have different transport characteristics, however the original stream may be multicast stream, which contradict to what you said about "The above optimization supports peer to peer unicast transport", am I wrong? " be able to rapidly negotiate ECN support for such a session, but the optimisation above can fail if there are implementations that use the same CNAME for different parts of a distributed implementation that have different transport characteristics (e.g., if a single logical endpoint is split across multiple hosts). " [Qin]: I don't get this example clearly. are you saying when two streams with the same CNAME is sent from the same RTP sender, such above optimization applies.However when two streams with the same CNAME are sent from two differnt RTP entities,such above optimization can not apply. 20. Section 7.2.2,1st paragraph " This section describes an OPTIONAL method that can be used to avoid media impact and also ensure an ECN capable path prior to media " [Qin]: What's the media impact? It looks like a new term that needs to be explained somewhere. 21. Section 7.2.2,3rd paragraph " A STUN server thatdoesn't understand the extension, or is incapable of reading the ECN values on incoming STUN packets, should follow the rule in the STUN specification for unknown comprehension-optional attributes, and ignore the attribute, resulting in the sender receiving a STUN response without the ECN Check STUN attribute. " [Qin]: Is the sender in this sentence "the media sender" or new participant? 22. Section 7.2.2, last paragraph " If that is successfully completed the ECT properties of the session are maintained for the other senders in the session. " [Qin]: Who is the other senders? are the other senders "new participant" or other participants? It should be clear in the text. 23. Section 7.3, 1st paragraph " Once ECN has been successfully initiated for an RTP sender, that sender begins sending all RTP data packets as ECT-marked, and its receivers send ECN feedback information via RTCP packets. This section describes procedures for sending ECT-marked data, providing ECN feedback information via RTCP, responding to ECN feedback information, and detecting failures and misbehaving receivers. " [Qin]It looks failure detection is discussed in different section, i.e., section 7.4. Suggest to remove ", and detecting failures and misbehaving receivers" from this paragraph. 24. Section 7.3.1, 2nd paragraph " The sender SHALL NOT include ECT marks on outgoing RTCP packets, " [Qin]: Is it true, since RTP/AVPF Transport Layer ECN Feedback packet include the satistics of ECT marks? 25. Section 7.4.1,4th paragraph " load balancing devices may in worst case result in that some packets take a different network path then the others; " [Qin]: Should "then" in this sentence be "than" ? 26. Section 7.4.2, 4th paragraph " The rate of packet duplication is tracked, allowing one to take the duplication into account. The value of the ECN field for duplicates will also be counted and when comparing the figures one needs to take " [Qin]: What and where are the figures? 27.Section 8.2,8th paragraph " When rounding counter values in the translated RTCP packet, the translator should try to ensure that they sum to the number of RTP packets in the pre-translation sequence number space (numOrig). The translator should also try to ensure that no non-zero counter is rounded to a zero value, since that will lose information that a particular type of event has occurred. It is recognised that it may be impossible to satisfy both of these constraints; " [Qin]: What's the difficulty to satisfy both constraints, why non-zero counter can be rounded into zero? what kind of round method is used? can you explain a little bit? 28.Section 8.4, 2nd paragraph " An ECN-aware RTP mixer must generate RTCP ECN feedback packets and RTCP XR report blocks for ECN summary information relating to the RTP flows it terminates, in exactly the same way it would if it were an RTP receiver. These reports form part of the congestion control loop between the mixer and the media senders generating the streams it is mixing. A separate control loop runs between each sender and the mixer. " [Qin]: what's the difference between congestion control loop and a separate control loop between media sender and mixer? are you saying congestion control loop is unidirectional? 29. Section 12,1st paragraph " This section contain a few different examples of the signalling mechanism defined in this specification in an SDP context. If there are discrepancies between these examples and the specification text, the specification text is definitive. " [Qin]: Why discrepacies is allowed? Should these example be consistent with the sepcification text? 30. Section 12.1 " This SDP offer offers a single media stream with 3 media payload types. It proposes to use ECN with RTP, with the ICE based initialization as being preferred over the RTP/RTCP one. Leap of faith is not suggested to be used. The offerer is capable of both setting and reading the ECN bits. In addition the RTCP ECN feedback packet is configured and the RTCP XR ECN summary report. " [Qin]: Are you saying both ECN feedback and the XR ECN summary report are allowed and configured or something else? Regards! -Qin ----- Original Message ----- From: Roni Even To: avt@ietf.org Sent: Friday, September 30, 2011 8:29 PM Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP over UDP. The WGLC will end on October 21, 2011 Please review the draft and send comments to the list. Roni Even ------------------------------------------------------------------------------ _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_ylaBF/OsDDeImGWJZ5qkeg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi,
I have reviewed this draft and support it moving towards publication.
Here is my minor editional comments to this 04 version draft.
1. Section 1
[Qin]:Is it better to move the first paragraph next to the third paragraph.
 
2. Section 3, 1st paragraph
"
   ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960],
   and DCCP [RFC4340] transports. These are all unicast protocols which
   negotiate the use of ECN during the initial connection establishment
   handshake (supporting incremental deployment, and checking if ECN
   marked packets pass all middleboxes on the path).
"
[Qin]: I think "these"  in the second sentence can't be "ECN"
mentioned in the first sentence. Is it better to replace "these"
the first word in this sentence with "these transport"?
 
"
   ECN-CE marks are
   immediately echoed back to the sender by the receiving end-point
   using an additional bit in feedback messages, and the sender then
   interprets the mark as equivalent to a packet loss for congestion
   control purposes.
"
 
[Qin]: For this sentence, it is not clear to me what is the  feedback message?
Is feedback message a new RTCP Feedback message defined in this
document or TCP message or SCTP message? If it is latter, I would like
to change it as these transport protocols header
 
3. Section 3, 2nd paragraph
"
   Counting vs Detecting Congestion:  TCP and the protocols derived from
   it are mainly designed to respond the same whether they experience
   a burst of congestion indications within one RTT or just one.
"
[Qin]: What's the difference between "one RTT" and "just one"?
 
4. Section 3.1
 
[Qin]: Any requirements that should be met by the middlebox or intermediate node?
 
 
5. Section 3.2,3rd paragraph
"
   Topo-Point-to-Point:  This is a standard unicast flow.  
   ....
"
 
[Qin]: Topo-point-to-point is not flow but a topology. Should this sentence be
rephrased as "This is for a standard unicast flow".
 
"
Accordingly, we allow ECN to be used by an RTP sender using multicast UDP
provided the sender has verified that the paths to all its known receivers support ECN,
and irrespective of whether the paths from other senders to their receivers support ECN
("all its known receivers" are all the SSRCs that the RTP sender has received RTP or RTCP
from the last five reporting intervals, i.e., they have not timed out).
"   
[Qin]: Five is default value of the timeout multiplier, do you think other value is not allowed?
 
"
Since only a subset  of the RTP packets generated by a sender are forwarded to the
 receivers, a video switching MCU can break ECN negotiation (the success of the
ECN negotiation may depend on the voice activity of  the participant at the instant the
 negotiation takes place - shout  if you want ECN). 
"
  
[Qin]: Is "shout if you want ECN" appropirate language here?
 
 
6. Section 3.2, 4th paragraph
"
 This is a great benefit as the rate of an
 RTP session can be varied in a number of ways,
"
[Qin]: Should "rate" in this sentence be data rate or bitrate?
 
7. Section 3.2, 5th paragraph
"
The standard RTP/ AVP profile [RFC3551] does not allow any early or immediate
transmission of RTCP feedback, and has a minimal RTCP interval whose default value
 (5 seconds) is many times the normal RTT between sender and receiver.
"
[Qin]: What's the purpose of last sentence of this paragraph?
       Are you saying RFC3551 following Regular RTCP timing rule?
       or something else?
 
   Another question is according to RFC3551, the negotiation of
   parameters or membership control may be not support. in other wonder,
   there may be no way to negotiate ECN with RTP using SDP signaling,
   I am wondering can we say ECN with RTP can be used with the standard RTP/
   AVP profile [RFC3551].
 
8. Section 3.3,3rd paragraph
"
   For interoperability we mandate the implementation of the RTP/AVPF
   profile, with both RTCP extensions and the necessary signalling to
   support a common operations mode.  This specification recommends the
   use of RTP/AVPF in all cases as negotiation of the common
   interoperability point requires RTP/AVPF, mixed negotiation of RTP/
   AVP and RTP/AVPF depending on other SDP attributes in the same media
   block is difficult,
"
[Qin] How mixed negotiation is avoided when you don't put all the SDP attribute
 into the same media block? I don't really understand the rationale. Would you
like to clarify a little bit?
 
9. Section 4, 1st paragraph
"
2.  Initiation and initial verification of ECN capable transport
"
 [Qin]: It looks the bullet 2 has two steps,
 a. Initiation procedure
 b. inital verification procedure, If there is no STUN exchange in between, if the step (a) initiation procedure
 is required?
 
10. Section 4, 2nd paragraph
"
This document defines the information that needs to be negotiated, and provides a mapping to SDP
for use in both declarative and offer/answer contexts.
"
[Qin]: Would it be better to add an anchor pointing to the section 6.1.1 and 6.1.2?
 
11. Section 4, 3rd paragraph
"
   o  The sender may generate a (small) subset of its RTP data packets
      with the ECN field set to ECT(0) or ECT(1).
"
 
[Qin] It is not clear to me where the ECN field is located.
Is ECN field in the IP header or UDP header or RTP header?
 
12. Section 5, 1st paragraph
"
   This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585]
   transport layer feedback format for urgent ECN information,
"
 [Qin]: Should the "urgent ECN information" be "urgent ECN information reporting"
 
13.Section 5.1,1st paragraph
"
   This RTP/AVPF transport layer feedback format is intended for use in
   RTP/AVPF early or immediate feedback modes when information needs to
   urgently reach the sender.  Thus its main use is to report reception
   of an ECN-CE marked RTP packet so that the sender may perform
   congestion control, or to speed up the initiation procedures by
   rapidly reporting that the path can support ECN-marked traffic.
"
 
[Qin]: are you saying slow initiation procedure may result in network congestion?
In my understanding, when ECN-CE marked packet is received, the only choice for sender
is to do congestion control since you are not sure if initiation procedure lead to such
congestion. If it is not intiation procedure that lead to congestion, you get risk to worse
congestion condition?
 
14.Section 6.1, 1st paragraph
"
   One new SDP attribute, "a=ecn-capable-rtp", is defined.  This is a
   media level attribute, and MUST NOT be used at the session level.  It
   is not subject to the character set chosen.
"
 
[Qin] Would it better to put reference to the section 6 of RFC4566 for character set?
 
15. Sectioin 6.1, 2nd paragraph
"
   ect:  This parameter makes it possible to express the preferred ECT
      marking.  This is either "random", "0", or "1", with "0" being
      implied if not specified.  The "ect" parameter describes a
      receiver preference, and is useful in the case where the receiver
      knows it is behind a link using IP header compression, the
      efficiency of which would be seriously disrupted if it were to
      receive packets with randomly chosen ECT marks.  It is RECOMMENDED
      that ECT(0) marking be used.
"
 
[Qin]: It looks ect is not well specified here.
e.g.,what it means if ect is set to "random" or "1" from above paragraph. what does "randomly chosen" stand for?
I think when ect is set 0, it means ECT(0) is chosen, when ect is set 1,
it means ECT(1) is chosen, when ect is set random, it means either ECT(0) or
ECT(1) is chosen. I think it should be clear in the text.
 
Also I think the text like ""0" being implied if not specified" in this paragraph is not correct.
 
16. Section 6.1.3, 2nd paragraph
"
If timely feedback is not required it is still RECOMMENDED
to used RTP/AVPF.
"
 
[Qin]: Should "used" in this sentence be "use"?
 
17.Section 7.1,2nd paragraph
"
The "rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used
whenever the initialization method or a congestion control algorithm
requiring timely sender side knowledge of received CE markings.
"
 [Qin]: Should "requiring" in this sentence be "requires"?
 
18.Section 7.2, 2nd paragraph
"
   At the start of the RTP session, when the first packets with ECT are
   sent, it is important to verify that IP packets with ECN field values
   of ECT or ECN-CE will reach their destination(s). 
"
[Qin]: Should "first packets" be "first packet" and "IP packets" be "IP packet"?
 
"
If the path between the sender and the receivers exhibits either of these behaviours one
"
[Qin]: s/the receivers/receiver
 
"
If the path between the sender and the receivers exhibits either of these behaviours one
 needs to stop using ECN immediately to protect both the network and
 the application.
"
 [Qin]: How does sender or receiver detects ECN is misused? Who is the
  "one" in this sentence? If it is middlebox, the middlebox should also
 tell the sender ECN is not used.
 
19.Section 7.2.1, 1st paragraph
"
 Then any resulting lack of congestion response is likely to have little
 damaging affect on others. 
"
 
[Qin] s/affect/effect
 
"
Note: The above optimization supports peer to peer unicast
transport with several SSRCs multiplexed onto the same flow
(e.g., a single participant with two video cameras, or SSRC
multiplexed RTP retransmission [RFC4588]).  It is desirable to
"
[Qin]: In SSRC multiplexed RTP Retransmission case, original stream and associated retransmission
        stream possible have different
        transport characteristics, however the original stream may be multicast stream, which contradict to
        what you said about "The above optimization supports peer to peer unicast
         transport", am I wrong?
"
be able to rapidly negotiate ECN support for such a session,
but the optimisation above can fail if there are
implementations that use the same CNAME for different parts of
a distributed implementation that have different transport
characteristics (e.g., if a single logical endpoint is split
across multiple hosts).
"
[Qin]: I don't get this example clearly. are you saying when two streams with the same CNAME
is sent from the same RTP sender, such above optimization applies.However when two streams
with the same CNAME are sent from two differnt RTP entities,such above optimization can not apply.
 
20. Section 7.2.2,1st paragraph
"
This section describes an OPTIONAL method that can be used to avoid
media impact and also ensure an ECN capable path prior to media
"
[Qin]: What's the media impact? It looks like a new term that needs to be explained
somewhere.
 
21. Section 7.2.2,3rd paragraph
"
 A STUN server thatdoesn't understand the extension, or is incapable of
 reading the ECN values on incoming STUN packets, should follow the rule in the STUN
 specification for unknown comprehension-optional attributes, and ignore the attribute,
 resulting in the sender receiving a STUN response without the ECN Check STUN attribute.
 
"
[Qin]: Is the sender in this sentence "the media sender" or new participant?
 
22. Section 7.2.2, last paragraph
"
 If that is successfully completed the ECT properties of the session are
 maintained for the other senders in the session. 
"
 
[Qin]: Who is the other senders? are the other senders "new participant"
 or other participants? It should be clear in the text.
 
23. Section 7.3, 1st paragraph
"
   Once ECN has been successfully initiated for an RTP sender, that
   sender begins sending all RTP data packets as ECT-marked, and its
   receivers send ECN feedback information via RTCP packets.  This
   section describes procedures for sending ECT-marked data, providing
   ECN feedback information via RTCP, responding to ECN feedback
   information, and detecting failures and misbehaving receivers.
"
[Qin]It looks failure detection is discussed in different section, i.e., section 7.4.
 Suggest to remove ", and detecting failures and misbehaving receivers" from this paragraph.
 
24. Section 7.3.1, 2nd paragraph
"
 The sender SHALL NOT include ECT marks on outgoing RTCP packets,
"
[Qin]: Is it true, since RTP/AVPF Transport Layer ECN Feedback packet include
the satistics of ECT marks?
 
25. Section 7.4.1,4th paragraph
"
load balancing devices may in worst case result in that some packets take a
different network path then the others;
"
 
[Qin]: Should "then" in this sentence be "than" ?
 
26. Section 7.4.2, 4th paragraph
"
   The rate of packet duplication is tracked, allowing one to take the
   duplication into account.  The value of the ECN field for duplicates
   will also be counted and when comparing the figures one needs to take
"
[Qin]: What and where are the figures?
 
27.Section 8.2,8th paragraph
"
   When rounding counter values in the translated RTCP packet, the
   translator should try to ensure that they sum to the number of RTP
   packets in the pre-translation sequence number space (numOrig).  The
   translator should also try to ensure that no non-zero counter is
   rounded to a zero value, since that will lose information that a
   particular type of event has occurred.  It is recognised that it may
   be impossible to satisfy both of these constraints;
"
 
[Qin]: What's the difficulty to satisfy both constraints, why non-zero
counter can be rounded into zero? what kind of round method is used?
can you explain a little bit?
 
28.Section 8.4, 2nd paragraph
"
   An ECN-aware RTP mixer must generate RTCP ECN feedback packets and
   RTCP XR report blocks for ECN summary information relating to the RTP
   flows it terminates, in exactly the same way it would if it were an
   RTP receiver.  These reports form part of the congestion control loop
   between the mixer and the media senders generating the streams it is
   mixing.  A separate control loop runs between each sender and the
   mixer.
"
 
[Qin]: what's the difference between congestion control loop and a separate control loop
 between media sender and mixer? are you saying congestion control loop is unidirectional?
 
29. Section 12,1st paragraph
"
   This section contain a few different examples of the signalling
   mechanism defined in this specification in an SDP context.  If there
   are discrepancies between these examples and the specification text,
   the specification text is definitive.
"
[Qin]: Why discrepacies is allowed? Should these example be consistent with
the sepcification text?
 
30. Section 12.1
"

   This SDP offer offers a single media stream with 3 media payload
   types.  It proposes to use ECN with RTP, with the ICE based
   initialization as being preferred over the RTP/RTCP one.  Leap of
   faith is not suggested to be used.  The offerer is capable of both
   setting and reading the ECN bits.  In addition the RTCP ECN feedback
   packet is configured and the RTCP XR ECN summary report.
"
[Qin]: Are you saying both ECN feedback and the XR ECN summary
report are allowed and configured or something else?
 
Regards!
-Qin
 
----- Original Message -----
From: Roni Even
Sent: Friday, September 30, 2011 8:29 PM
Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

Hi,

I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP over UDP.
 

The WGLC will end on October 21, 2011

 

Please review the draft and send comments to the list.

 

 

Roni Even

 

 

 

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
--Boundary_(ID_ylaBF/OsDDeImGWJZ5qkeg)-- From bill.wu@huawei.com Tue Oct 11 00:21:29 2011 Return-Path: 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 683B321F8C8A for ; Tue, 11 Oct 2011 00:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[AWL=1.163, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 ehQcsC48lOEg for ; Tue, 11 Oct 2011 00:21:28 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1504421F8C83 for ; Tue, 11 Oct 2011 00:21:28 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSW0082T4EBB2@szxga05-in.huawei.com> for avt@ietf.org; Tue, 11 Oct 2011 15:20:36 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSW00K0O4EA65@szxga05-in.huawei.com> for avt@ietf.org; Tue, 11 Oct 2011 15:20:35 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ05364; Tue, 11 Oct 2011 15:19:54 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 15:19:51 +0800 Received: from w53375q (10.138.41.130) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 15:19:48 +0800 Date: Tue, 11 Oct 2011 15:19:48 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Magnus Westerlund , IETF AVTCore WG , draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org Message-id: <46B94027CF7149FD9238297DB6FA4320@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_b191HPidGGJFkjL00E6sNw)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4E8D76C1.5080508@ericsson.com> Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-07 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 07:21:29 -0000 --Boundary_(ID_b191HPidGGJFkjL00E6sNw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi,Magnus: As regarding if there is better solution, I have some corrections and additional thoughts. I think If the media source is the repair server, the receiver should set timer to T1=max(the RTT from media source to middlebox sending TPLR, 1/2 of RTT from middlebox to receiver) when the receiver receives first TPLR. When the receiver receive addtional TPLR within T1, the receiver should reset the timer to the RTT from media source to middlebox sending TPLR. If the middlebox is the repair server, the receiver should set the timer to T2=1/2 of RTT from middlebox to receiver when the receiver receives first TPLR. When the receiver receive addtional TPLR within T2, the receiver should reset the timer to the T2. Regards! -Qin ----- Original Message ----- From: Qin Wu To: Magnus Westerlund ; IETF AVTCore WG ; draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org Sent: Tuesday, October 11, 2011 9:40 AM Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-07 Hi, Magnus, Thank for your valuable review, please see my replies belows. Regards! -Qin ----- Original Message ----- From: "Magnus Westerlund" To: "IETF AVTCore WG" ; Sent: Thursday, October 06, 2011 5:37 PM Subject: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07 Thanks for updating the draft, I have reviewed the updated draft and have the following comments on the updated version. Some issues are follow up on previous version or on the actual changes. 2. Section 3. "The timer value shall be based on the observed round-trip time. A receiver should compute an estimate of the round-trip time (RTT) to the sender of TPLR from RTCP report round-trip time if available, or its reception time of the reflected RTCP FB message (e.g.,NACK), or any other means." We hade the discussion before but now that you clarified which RTT to be used, I think it is worth having a discussion if that RTT is the right one. So you suggest that the RTT between the sender of the TPLR and the receiver of the message is the most appropriate to use when suppressing the message. I am not certain that is the case. Lets consider the use cases. In the case of an intermediary in a distribution tree sending the TPLR and at the same time sending a NACK upstream. Then the time until the retransmission reaches the suppressed receiver is the time from the sending of the NACK up to the retransmitting entity and all the way down past the TPLR sender to the suppressed receiver. The receiver may not have a true RTT to the original media sender as that source appears to live at the TPLR sender, not further upstream. Yes, the sender of the TPLR and the receiver might at least have mutual knowledge of each other, thus the TPLR sender is able to determine the lowest RTT in the set of receviers thus determining how often to repeat it to cover additional time requried for the upstream part of the request. But I do note that these times aren't matching what appear to be the delays in the systems. Can we find a better solution? --Boundary_(ID_b191HPidGGJFkjL00E6sNw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi,Magnus:
As regarding if there is better solution, I have some corrections and additional thoughts.
I think
If the media source is the repair server,
the receiver should set timer to T1=max(the RTT from media source to middlebox sending TPLR, 1/2 of RTT from middlebox to receiver) when the receiver
receives first TPLR. When the receiver receive addtional TPLR within T1, the receiver should reset the timer to the RTT from media source to middlebox sending TPLR.
 
If the middlebox is the repair server, the receiver should set the timer to T2=1/2 of RTT from middlebox to receiver when the receiver
receives first TPLR. When the receiver receive addtional TPLR within T2, the receiver should reset the timer to the T2.
 
Regards!
-Qin
----- Original Message -----
From: Qin Wu
Sent: Tuesday, October 11, 2011 9:40 AM
Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-07

Hi, Magnus,
Thank for your valuable review, please see my replies belows.
 
Regards!
-Qin
----- Original Message -----
From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
Sent: Thursday, October 06, 2011 5:37 PM
Subject: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07

Thanks for updating the draft,

I have reviewed the updated draft and have the following comments on the
updated version. Some issues are follow up on previous version or on the
actual changes.

2. Section 3.
  "The timer value shall be
   based on the observed round-trip time.  A receiver should compute an
   estimate of the round-trip time (RTT) to the sender of TPLR from RTCP
   report round-trip time if available, or its reception time of the
   reflected RTCP FB message (e.g.,NACK), or any other means."

We hade the discussion before but now that you clarified which RTT to be
used, I think it is worth having a discussion if that RTT is the right
one. So you suggest that the RTT between the sender of the TPLR and the
receiver of the message is the most appropriate to use when suppressing
the message. I am not certain that is the case.

Lets consider the use cases. In the case of an intermediary in a
distribution tree sending the TPLR and at the same time sending a NACK
upstream. Then the time until the retransmission reaches the suppressed
receiver is the time from the sending of the NACK up to the
retransmitting entity and all the way down past the TPLR sender to the
suppressed receiver. The receiver may not have a true RTT to the
original media sender as that source appears to live at the TPLR sender,
not further upstream.

Yes, the sender of the TPLR and the receiver might at least have mutual
knowledge of each other, thus the TPLR sender is able to determine the
lowest RTT in the set of receviers thus determining how often to repeat
it to cover additional time requried for the upstream part of the
request. But I do note that these times aren't matching what appear to
be the delays in the systems.

Can we find a better solution?
 

 

--Boundary_(ID_b191HPidGGJFkjL00E6sNw)-- From bill.wu@huawei.com Tue Oct 11 01:12:21 2011 Return-Path: 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 F3B6C21F8D02 for ; Tue, 11 Oct 2011 01:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.931 X-Spam-Level: X-Spam-Status: No, score=-3.931 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, 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 9jZCcstJPHiQ for ; Tue, 11 Oct 2011 01:12:20 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id AB87C21F8CF9 for ; Tue, 11 Oct 2011 01:12:19 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSW00EX86QL4S@szxga04-in.huawei.com> for avt@ietf.org; Tue, 11 Oct 2011 16:11:09 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSW000FK6POVI@szxga04-in.huawei.com> for avt@ietf.org; Tue, 11 Oct 2011 16:11:09 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEE08326; Tue, 11 Oct 2011 16:11:09 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 16:11:06 +0800 Received: from w53375q (10.138.41.130) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 16:11:02 +0800 Date: Tue, 11 Oct 2011 16:11:01 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Colin Perkins , avt@ietf.org Message-id: <9F1217B1416045A987E6B48A4CC87037@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <20110926081759.16674.85402.idtracker@ietfa.amsl.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 08:12:21 -0000 Hi, Colin: Thank for your careful review, please see my replies belows. Regards! -Qin ----- Original Message ----- From: "Colin Perkins" To: 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-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"? [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 From magnus.westerlund@ericsson.com Tue Oct 11 02:41:42 2011 Return-Path: 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 2B97221F8C00; Tue, 11 Oct 2011 02:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ZUPwVKYFhbX6; Tue, 11 Oct 2011 02:41:41 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA7521F8BFE; Tue, 11 Oct 2011 02:41:40 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-8e-4e940f54b3f4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F9.83.13753.45F049E4; Tue, 11 Oct 2011 11:41:40 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 11 Oct 2011 11:41:39 +0200 Message-ID: <4E940F52.4030007@ericsson.com> Date: Tue, 11 Oct 2011 11:41:38 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D5410097E4B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5410097E4B@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic \(E-mail\)" , "avt@ietf.org" Subject: Re: [AVTCORE] Duplication semantics drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 09:41:42 -0000 On 2011-10-10 20:17, Ali C. Begen (abegen) wrote: > I revised the two drafts per the feedback in Quebec. > > If there are further comments, we would like to hear about them. As > of now, there are no open issues from our standpoint except possibly > defining a new RTCP XR report, which can be done later. Thus, we > would like these two drafts to be considered and adopted by the > MMUSIC wg. > > https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ > > https://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/ > > CC'ing AVT(core) since the topic is relevant but please post your > comments to mmusic where the drafts belong to. > Hi, (as individual) I have looked at the redundancy-grouping draft and still think it fails as RTP specifications for how duplication should be done in RTP, either using SSRC multiplexing with two different SSRCs in the same RTP session or for the alternative how having two different RTP sessions. This first appears to be sufficiently specified, where my only comment is the dependency on signalling to determine that this grouping is in place. I do propose that an RTP/RTCP based complement is derived. I would personally suggest that my own proposal for a new SDES item SRCNAME is used but that should clearly be discussed. For the case where multiple RTP sessions are used, it is still not clear how a receiver determine which SSRC in each RTP session that are related. And I would like to point out that CNAME is not sufficient. I still think we should consider splitting this into one AVTCORE document discussing the RTP aspects of duplication, and another MMUSIC document defining the grouping semantics. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From albrecht.schwarz@alcatel-lucent.com Tue Oct 11 02:52:28 2011 Return-Path: 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 ; 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 ; 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 ; 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)" To: Qin Wu , Colin Perkins , "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> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 di= scussion below, but a reference to such a device is not really provided. There seems to be two possible interpretations: "Middlebox"=20 a) =3D MIDCOM-compliant middlebox (and then a reference to definition =A7 2= .2/RFC 3303 could be added) b) =3D a network intermediate device that implements unknown services on to= p of IP packet forwarding (i.e., a block box with unknown behaviour). I suppose that interpretation (b) is supposed here, - and thus slightly con= cerned that such a definition may be used to justify "any kind of requireme= nt":-) Regards, Albrecht PS Similar is "repair server", but such a device is not mentioned in the draft= . =20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Qin Wu > Sent: Dienstag, 11. Oktober 2011 10:11 > To: Colin Perkins; avt@ietf.org > Subject: Re: [AVTCORE] I-D=20 > Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt >=20 > Hi, Colin: > Thank for your careful review, please see my replies belows. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Colin Perkins" > To: > Sent: Tuesday, October 11, 2011 5:46 AM > Subject: Re: [AVTCORE] I-D=20 > Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt >=20 >=20 > > On 26 Sep 2011, at 09:17, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. This draft is a work item of the=20 > Audio/Video Transport Core Maintenance Working Group of the IETF. > >>=20 > >> 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 > >>=20 > >> In a large RTP session using the RTCP feedback mechanism=20 > defined in > >> RFC 4585, a feedback target may experience transient=20 > overload if some > >> event causes a large number of receivers to send=20 > feedback at once. > >> This overload is usually avoided by ensuring that=20 > feedback reports > >> are forwarded to all receivers, allowing them to avoid sending > >> duplicate feedback reports. However, there are cases=20 > where it is not > >> recommended to forward feedback reports, and this may=20 > allow feedback > >> implosion. This memo discusses these cases and defines=20 > a new RTCP > >> third-party loss report that can be used to inform=20 > receivers that the > >> network is aware of some loss event, allowing them to suppress > >> feedback. Associated SDP signalling is also defined. > >>=20 > >>=20 > >> A URL for this Internet-Draft is: > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedbac > k-supression-rtp-07.txt > >=20 > >=20 > > I have read this draft, and have some comments: > >=20 > > - Section 1, 1st paragraph: "(e.g, implementing the RFC=20 > 4585" - should this be "(e.g., not implementing the RFC 4585"? >=20 > [Qin]:It is a typo and my mistake. Thank for catching it. >=20 >=20 > > - Section 3, 3rd paragraph, says the "timer value shall be=20 > based on the observed round-trip time", but it's not clear=20 > that this means. By based on, do you mean equal to the RTT,=20 > or some other function derived from it? Which RTT? The=20 > suppression, ideally, wants to be for long enough for the=20 > sender of the TPLR to somehow repair the loss at all of its=20 > downstream receivers, so none of them need to resend a NACK.=20 > This might imply the RTT from the receiver to the original=20 > media source and/or repair server be used, which is different=20 > from the RTT specified. I think some more thought is needed here. > >=20 >=20 > [Qin]: See my discussion with Magnus in the previous email on=20 > this thread. But that need some corrections. I think you are=20 > right, If the middlbox is repair server, more approximate RTT=20 > is the RTT from the receiver and repair server. If the=20 > original media is repair server, more approximate RTT should=20 > be 1/2 of RTT between the middlebox and receiver plus RTT=20 > from middlebox to media source. But if the middlebox sending=20 > TPLR is more close to media source, one RTT from middlebox to=20 > media source can be omitted. >=20 > > - Section 3, 4th paragraph: "In the case the first TPLR is=20 > lost and the additional TPLR arrives at the receiver, the=20 > receiver should immediately refresh the timer" - sure, but=20 > what else would it do? This makes it seem that something=20 > different is done in this case, but the behaviour looks to be=20 > the same whether or not a TPLR is lost. >=20 > [Qin]: Assume the middlebox sending NACK upstream and TPLR=20 > downstream at the same time,refresh timer means waiting for=20 > one RTT from media source to get the retransmitted RTP data=20 > packet after getting that additional TPLR, however if the=20 > middlebox itself is repair server, the timer should be same=20 > irrespectively a TPLR is lost, i.e., 1/2 RTT from middlebox=20 > to the receiver. >=20 >=20 > > - Section 6.3: if a monitor co-located with a translator=20 > detects a loss, why does that monitor not send a NACK? Not=20 > clear what's the reason for using a TPLR here. >=20 > [Qin]:That's becos translator has a monitor, which told=20 > translator to send TPLR, if translator has no monitor and=20 > receives NACK from a receiver, this receiver should forward=20 > NACK directly. Does this clarify? >=20 > > - Section 6.5: the behaviour described makes sense for an=20 > RTP-terminating mixer, but an RFC 3550 mixer could just=20 > forward the FIR or PLI messages without using the TPLR, no? >=20 > [Qin]: According to Section 7.3 of RFC 3550, a mixer must not=20 > forward RTCP unaltered between > the two domains, also according to section 3.4 of RFC5117,=20 > 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. =20 > So I think this is not a issue. >=20 > >=20 > >=20 > > I also have a number of more minor, mostly editorial, suggestions: > >=20 > > - Abstract: change "that the network is aware" to "that the=20 > feedback target is aware" >=20 > [Qin]: Okay, fixed. >=20 > > - Section 1, 1st paragraph: "as a packet loss recovery=20 > technique based, sending" -> "as a packet loss recovery=20 > technique, sending" >=20 > [Qin]: Okay, fixed. >=20 > >=20 > > - Section 1, 4th paragraph: "while the case the" -> "while=20 > the case where the" >=20 > [Qin]: Okay, fixed. > >=20 > > - Section 1, 4th paragraph: last sentence is repeated >=20 > [Qin]: Okay, fixed. > >=20 > > - Section 3, 2nd paragraph: "generated by a RTP system" ->=20 > "generated by an RTP system" >=20 > [Qin]: Okay, fixed. > >=20 > > - Section 3, 2nd paragraph: "as per AVPF" -> "as per the=20 > RTP/AVPF rules" >=20 > [Qin]: Okay, fixed. > >=20 > > - Section 3, 2nd paragraph: "SHOULD NOT initiate their own=20 > additional" -> "SHOULD NOT send their own additional" >=20 > [Qin]: Okay, fixed. > >=20 > > - Section 3, 4th paragraph: what is meant by "a=20 > transmission packet"? Do you mean an RTP data packet, or some=20 > other RTCP packet? >=20 > [Qin]: RTP data packet. I will fix this by adding some=20 > explanation text. >=20 > >=20 > > - Section 3, 4th paragraph: not sure what is meant by "a=20 > receiver is allowed to receive additional TPLR" - when would=20 > it not be allowed to receive? Would this be better saying=20 > that the sending an generate an additional TPLR? >=20 > [Qin]: Okay, fixed. > >=20 > > - Section 3, 5th paragraph: "may still have sent" -> "may have sent" >=20 > [Qin]: Okay, fixed. > >=20 > > - Section 3, 5th paragraph: "will be suppressed by this=20 > technique for a certain period of time" -> "SHOULD be=20 > suppressed for a period of time after receiving the TPLR"? >=20 > [Qin]: Okay, fixed. > >=20 > > - Section 3, 6th paragraph: what is meant by "closer to the=20 > source" in this paragraph?=20 >=20 > [Qin]: means the location of middlebox is more closer to the=20 > media source.=20 > I will fix this by adding some explanation text. >=20 > >=20 > > - Section 4.1: "bitmask of proceeding lost packets" ->=20 > "bitmask of lost packets" >=20 > [Qin]: Okay, fixed. > >=20 > >=20 > >=20 > > --=20 > > Colin Perkins > > http://csperkins.org/ > >=20 > >=20 > >=20 > > _______________________________________________ > > 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 > = From abegen@cisco.com Tue Oct 11 03:46:37 2011 Return-Path: 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 E724B21F8C0B; Tue, 11 Oct 2011 03:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 dv8r0vjgCB1T; Tue, 11 Oct 2011 03:46:37 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4C08621F8C09; Tue, 11 Oct 2011 03:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3147; q=dns/txt; s=iport; t=1318329997; x=1319539597; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zCz1hrINf8nwE6Eri1bPhRqOv88+01AfxvTgSIg28V0=; b=jBMSQ9JHc6v3BOSqWYedcRmuBfrRkPAgHEIm1Gtm+GZsUILlGt4feymt 6lRCWIJHnhM+9qIdufNJ3DbiFukXhozG9OravHLJdQT7VKKq8UwT9LDJq IzUDtkx50Fk9Ht5D6gwsafmJyGZMMXFGrbqIB+wjY3So+G0mqubYZpsXz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0AAKwdlE6rRDoH/2dsb2JhbABDmQSPI4EFgVMBAQEDAQwGAR1CBwUHAgICAQgRBAEBAQoGFwEGARorCQgBAQQTCBqHXAebMgGeUwMChmlhBId+kSeMQQ X-IronPort-AV: E=Sophos;i="4.68,522,1312156800"; d="scan'208";a="7144579" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 11 Oct 2011 10:46:36 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9BAkaV4012931; Tue, 11 Oct 2011 10:46:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 03:46:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Oct 2011 03:46:24 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54100980DB@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4E940F52.4030007@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Duplication semantics drafts Thread-Index: AcyH+fti2yzOq66+SYqeCQGHBALQzgACFZnw References: <04CAD96D4C5A3D48B1919248A8FE0D5410097E4B@xmb-sjc-215.amer.cisco.com> <4E940F52.4030007@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 11 Oct 2011 10:46:36.0553 (UTC) FILETIME=[0CA82F90:01CC8803] Cc: "mmusic \(E-mail\)" , avt@ietf.org Subject: Re: [AVTCORE] Duplication semantics drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 10:46:38 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, October 11, 2011 5:42 AM > To: Ali C. Begen (abegen) > Cc: mmusic (E-mail); avt@ietf.org > Subject: Re: [AVTCORE] Duplication semantics drafts >=20 > On 2011-10-10 20:17, Ali C. Begen (abegen) wrote: > > I revised the two drafts per the feedback in Quebec. > > > > If there are further comments, we would like to hear about them. As > > of now, there are no open issues from our standpoint except possibly > > defining a new RTCP XR report, which can be done later. Thus, we > > would like these two drafts to be considered and adopted by the > > MMUSIC wg. > > > > = https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ > > > > = https://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving= / > > > > CC'ing AVT(core) since the topic is relevant but please post your > > comments to mmusic where the drafts belong to. > > >=20 > Hi, >=20 > (as individual) >=20 > I have looked at the redundancy-grouping draft and still think it = fails > as RTP specifications for how duplication should be done in RTP, = either > using SSRC multiplexing with two different SSRCs in the same RTP = session > or for the alternative how having two different RTP sessions. This = first > appears to be sufficiently specified, where my only comment is the > dependency on signalling to determine that this grouping is in place. = I > do propose that an RTP/RTCP based complement is derived. I would > personally suggest that my own proposal for a new SDES item SRCNAME is > used but that should clearly be discussed. Right, the ssrc muxing case is straightforward and easy to implement. = Everything works fine without the need for defining new stuff except the = grouping semantics. I am not sure why you think there is a problem in = the signaling. If duplication will be done across sessions (your second case), then it = gets complicated. And as I understand your claim is regular CNAME falls = short to define this relation. Is that correct? And your proposal is = SRCNAME, right? =20 > For the case where multiple RTP sessions are used, it is still not = clear > how a receiver determine which SSRC in each RTP session that are > related. And I would like to point out that CNAME is not sufficient. >=20 > I still think we should consider splitting this into one AVTCORE > document discussing the RTP aspects of duplication, and another MMUSIC > document defining the grouping semantics. This sounds like a good plan to me. -acbegen =20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From bill.wu@huawei.com Tue Oct 11 05:06:38 2011 Return-Path: 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 0000221F8532 for ; Tue, 11 Oct 2011 05:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=-1.476, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, MANGLED_LIST=2.3, MIME_BASE64_TEXT=1.753, 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 q6VDAPQ4Z4GG for ; Tue, 11 Oct 2011 05:06:37 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C9E7721F8C04 for ; Tue, 11 Oct 2011 05:06:36 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSW00EDGHMRIP@szxga05-in.huawei.com> for avt@ietf.org; Tue, 11 Oct 2011 20:06:28 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSW008BSHMR41@szxga05-in.huawei.com> for avt@ietf.org; Tue, 11 Oct 2011 20:06:27 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEE23736; Tue, 11 Oct 2011 20:06:27 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 20:06:24 +0800 Received: from w53375q (10.138.41.130) by szxeml410-hub.china.huawei.com (10.82.67.137) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 20:06:20 +0800 Date: Tue, 11 Oct 2011 20:06:19 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: "Schwarz, Albrecht (Albrecht)" , Colin Perkins , avt@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <20110926081759.16674.85402.idtracker@ietfa.amsl.com> <9F1217B1416045A987E6B48A4CC87037@china.huawei.com> <5F7BCCF5541B7444830A2288ABBEBC962160D2642D@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 12:06:38 -0000 SGksIEFsYnJlY2h0Og0KVGhhbmsgZm9yIHlvdXIgY29tbWVudCwgSSBhZ3JlZSB3aXRoIHlvdXIg Y2xhcmlmaWNhdGlvbiBhbmQgd2lsbCBiZSBjYXJlZnVsIHdpdGggdGVybXMgdXNpbmcNCmluIHRo ZSBkcmFmdC4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQpGcm9tOiAiU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KSIgPGFsYnJlY2h0LnNjaHdhcnpA YWxjYXRlbC1sdWNlbnQuY29tPg0KVG86ICJRaW4gV3UiIDxiaWxsLnd1QGh1YXdlaS5jb20+OyAi Q29saW4gUGVya2lucyIgPGNzcEBjc3BlcmtpbnMub3JnPjsgPGF2dEBpZXRmLm9yZz4NClNlbnQ6 IFR1ZXNkYXksIE9jdG9iZXIgMTEsIDIwMTEgNTo1MSBQTQ0KU3ViamVjdDogUkU6IFtBVlRDT1JF XSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXByZXNzaW9uLXJ0cC0w Ny50eHQNCg0KDQpIaSwNCnRoZSBub3Rpb24gb2YgYSAibWlkZGxlYm94IiBpcyBmcmVxdWVudGx5 IHVzZWQgZm9yIGp1c3RpZnlpbmcgc3RoIGluIHRoZSBkaXNjdXNzaW9uIGJlbG93LCBidXQgYSBy ZWZlcmVuY2UgdG8gc3VjaCBhIGRldmljZSBpcyBub3QgcmVhbGx5IHByb3ZpZGVkLg0KVGhlcmUg c2VlbXMgdG8gYmUgdHdvIHBvc3NpYmxlIGludGVycHJldGF0aW9uczoNCiJNaWRkbGVib3giIA0K YSkgPSBNSURDT00tY29tcGxpYW50IG1pZGRsZWJveCAoYW5kIHRoZW4gYSByZWZlcmVuY2UgdG8g ZGVmaW5pdGlvbiCnIDIuMi9SRkMgMzMwMyBjb3VsZCBiZSBhZGRlZCkNCmIpID0gYSBuZXR3b3Jr IGludGVybWVkaWF0ZSBkZXZpY2UgdGhhdCBpbXBsZW1lbnRzIHVua25vd24gc2VydmljZXMgb24g dG9wIG9mIElQIHBhY2tldCBmb3J3YXJkaW5nIChpLmUuLCBhIGJsb2NrIGJveCB3aXRoIHVua25v d24gYmVoYXZpb3VyKS4NCg0KSSBzdXBwb3NlIHRoYXQgaW50ZXJwcmV0YXRpb24gKGIpIGlzIHN1 cHBvc2VkIGhlcmUsIC0gYW5kIHRodXMgc2xpZ2h0bHkgY29uY2VybmVkIHRoYXQgc3VjaCBhIGRl ZmluaXRpb24gbWF5IGJlIHVzZWQgdG8ganVzdGlmeSAiYW55IGtpbmQgb2YgcmVxdWlyZW1lbnQi Oi0pDQoNClJlZ2FyZHMsDQpBbGJyZWNodA0KDQpQUw0KU2ltaWxhciBpcyAicmVwYWlyIHNlcnZl ciIsIGJ1dCBzdWNoIGEgZGV2aWNlIGlzIG5vdCBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0Lg0KIA0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGF2dC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86YXZ0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPiBCZWhhbGYgT2YgUWluIFd1 DQo+IFNlbnQ6IERpZW5zdGFnLCAxMS4gT2t0b2JlciAyMDExIDEwOjExDQo+IFRvOiBDb2xpbiBQ ZXJraW5zOyBhdnRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtBVlRDT1JFXSBJLUQgDQo+IEFj dGlvbjpkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDcudHh0DQo+ IA0KPiBIaSwgQ29saW46DQo+IFRoYW5rIGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3LCBwbGVhc2Ug c2VlIG15IHJlcGxpZXMgYmVsb3dzLg0KPiANCj4gUmVnYXJkcyENCj4gLVFpbg0KPiAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJDb2xpbiBQZXJraW5zIiA8Y3NwQGNzcGVy a2lucy5vcmc+DQo+IFRvOiA8YXZ0QGlldGYub3JnPg0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVy IDExLCAyMDExIDU6NDYgQU0NCj4gU3ViamVjdDogUmU6IFtBVlRDT1JFXSBJLUQgDQo+IEFjdGlv bjpkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDcudHh0DQo+IA0K PiANCj4gPiBPbiAyNiBTZXAgMjAxMSwgYXQgMDk6MTcsIEludGVybmV0LURyYWZ0c0BpZXRmLm9y ZyB3cm90ZToNCj4gPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgDQo+IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgDQo+IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5h bmNlIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+ID4+IA0KPiA+PiBUaXRsZSAgICAgICAg ICAgOiBSVENQIEV4dGVuc2lvbiBmb3IgVGhpcmQtcGFydHkgTG9zcyBSZXBvcnQNCj4gPj4gQXV0 aG9yKHMpICAgICAgIDogUWluIFd1DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICBGcmFu ayBYaWENCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgIFJvbmkgRXZlbg0KPiA+PiBGaWxl bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAt MDcudHh0DQo+ID4+IFBhZ2VzICAgICAgICAgICA6IDE2DQo+ID4+IERhdGUgICAgICAgICAgICA6 IDIwMTEtMDktMjYNCj4gPj4gDQo+ID4+ICAgSW4gYSBsYXJnZSBSVFAgc2Vzc2lvbiB1c2luZyB0 aGUgUlRDUCBmZWVkYmFjayBtZWNoYW5pc20gDQo+IGRlZmluZWQgaW4NCj4gPj4gICBSRkMgNDU4 NSwgYSBmZWVkYmFjayB0YXJnZXQgbWF5IGV4cGVyaWVuY2UgdHJhbnNpZW50IA0KPiBvdmVybG9h ZCBpZiBzb21lDQo+ID4+ICAgZXZlbnQgY2F1c2VzIGEgbGFyZ2UgbnVtYmVyIG9mIHJlY2VpdmVy cyB0byBzZW5kIA0KPiBmZWVkYmFjayBhdCBvbmNlLg0KPiA+PiAgIFRoaXMgb3ZlcmxvYWQgaXMg dXN1YWxseSBhdm9pZGVkIGJ5IGVuc3VyaW5nIHRoYXQgDQo+IGZlZWRiYWNrIHJlcG9ydHMNCj4g Pj4gICBhcmUgZm9yd2FyZGVkIHRvIGFsbCByZWNlaXZlcnMsIGFsbG93aW5nIHRoZW0gdG8gYXZv aWQgc2VuZGluZw0KPiA+PiAgIGR1cGxpY2F0ZSBmZWVkYmFjayByZXBvcnRzLiAgSG93ZXZlciwg dGhlcmUgYXJlIGNhc2VzIA0KPiB3aGVyZSBpdCBpcyBub3QNCj4gPj4gICByZWNvbW1lbmRlZCB0 byBmb3J3YXJkIGZlZWRiYWNrIHJlcG9ydHMsIGFuZCB0aGlzIG1heSANCj4gYWxsb3cgZmVlZGJh Y2sNCj4gPj4gICBpbXBsb3Npb24uICBUaGlzIG1lbW8gZGlzY3Vzc2VzIHRoZXNlIGNhc2VzIGFu ZCBkZWZpbmVzIA0KPiBhIG5ldyBSVENQDQo+ID4+ICAgdGhpcmQtcGFydHkgbG9zcyByZXBvcnQg dGhhdCBjYW4gYmUgdXNlZCB0byBpbmZvcm0gDQo+IHJlY2VpdmVycyB0aGF0IHRoZQ0KPiA+PiAg IG5ldHdvcmsgaXMgYXdhcmUgb2Ygc29tZSBsb3NzIGV2ZW50LCBhbGxvd2luZyB0aGVtIHRvIHN1 cHByZXNzDQo+ID4+ICAgZmVlZGJhY2suICBBc3NvY2lhdGVkIFNEUCBzaWduYWxsaW5nIGlzIGFs c28gZGVmaW5lZC4NCj4gPj4gDQo+ID4+IA0KPiA+PiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1E cmFmdCBpczoNCj4gPj4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjDQo+IGstc3VwcmVzc2lvbi1ydHAtMDcudHh0DQo+ID4g DQo+ID4gDQo+ID4gSSBoYXZlIHJlYWQgdGhpcyBkcmFmdCwgYW5kIGhhdmUgc29tZSBjb21tZW50 czoNCj4gPiANCj4gPiAtIFNlY3Rpb24gMSwgMXN0IHBhcmFncmFwaDogIihlLmcsIGltcGxlbWVu dGluZyB0aGUgUkZDIA0KPiA0NTg1IiAtIHNob3VsZCB0aGlzIGJlICIoZS5nLiwgbm90IGltcGxl bWVudGluZyB0aGUgUkZDIDQ1ODUiPw0KPiANCj4gW1Fpbl06SXQgaXMgYSB0eXBvIGFuZCBteSBt aXN0YWtlLiBUaGFuayBmb3IgY2F0Y2hpbmcgaXQuDQo+IA0KPiANCj4gPiAtIFNlY3Rpb24gMywg M3JkIHBhcmFncmFwaCwgc2F5cyB0aGUgInRpbWVyIHZhbHVlIHNoYWxsIGJlIA0KPiBiYXNlZCBv biB0aGUgb2JzZXJ2ZWQgcm91bmQtdHJpcCB0aW1lIiwgYnV0IGl0J3Mgbm90IGNsZWFyIA0KPiB0 aGF0IHRoaXMgbWVhbnMuIEJ5IGJhc2VkIG9uLCBkbyB5b3UgbWVhbiBlcXVhbCB0byB0aGUgUlRU LCANCj4gb3Igc29tZSBvdGhlciBmdW5jdGlvbiBkZXJpdmVkIGZyb20gaXQ/IFdoaWNoIFJUVD8g VGhlIA0KPiBzdXBwcmVzc2lvbiwgaWRlYWxseSwgd2FudHMgdG8gYmUgZm9yIGxvbmcgZW5vdWdo IGZvciB0aGUgDQo+IHNlbmRlciBvZiB0aGUgVFBMUiB0byBzb21laG93IHJlcGFpciB0aGUgbG9z cyBhdCBhbGwgb2YgaXRzIA0KPiBkb3duc3RyZWFtIHJlY2VpdmVycywgc28gbm9uZSBvZiB0aGVt IG5lZWQgdG8gcmVzZW5kIGEgTkFDSy4gDQo+IFRoaXMgbWlnaHQgaW1wbHkgdGhlIFJUVCBmcm9t IHRoZSByZWNlaXZlciB0byB0aGUgb3JpZ2luYWwgDQo+IG1lZGlhIHNvdXJjZSBhbmQvb3IgcmVw YWlyIHNlcnZlciBiZSB1c2VkLCB3aGljaCBpcyBkaWZmZXJlbnQgDQo+IGZyb20gdGhlIFJUVCBz cGVjaWZpZWQuIEkgdGhpbmsgc29tZSBtb3JlIHRob3VnaHQgaXMgbmVlZGVkIGhlcmUuDQo+ID4g DQo+IA0KPiBbUWluXTogU2VlIG15IGRpc2N1c3Npb24gd2l0aCBNYWdudXMgaW4gdGhlIHByZXZp b3VzIGVtYWlsIG9uIA0KPiB0aGlzIHRocmVhZC4gQnV0IHRoYXQgbmVlZCBzb21lIGNvcnJlY3Rp b25zLiBJIHRoaW5rIHlvdSBhcmUgDQo+IHJpZ2h0LCBJZiB0aGUgbWlkZGxib3ggaXMgcmVwYWly IHNlcnZlciwgbW9yZSBhcHByb3hpbWF0ZSBSVFQgDQo+IGlzIHRoZSBSVFQgZnJvbSB0aGUgcmVj ZWl2ZXIgYW5kIHJlcGFpciBzZXJ2ZXIuIElmIHRoZSANCj4gb3JpZ2luYWwgbWVkaWEgaXMgcmVw YWlyIHNlcnZlciwgbW9yZSBhcHByb3hpbWF0ZSBSVFQgc2hvdWxkIA0KPiBiZSAxLzIgb2YgUlRU IGJldHdlZW4gdGhlIG1pZGRsZWJveCBhbmQgcmVjZWl2ZXIgcGx1cyBSVFQgDQo+IGZyb20gbWlk ZGxlYm94IHRvIG1lZGlhIHNvdXJjZS4gQnV0IGlmIHRoZSBtaWRkbGVib3ggc2VuZGluZyANCj4g VFBMUiBpcyBtb3JlIGNsb3NlIHRvIG1lZGlhIHNvdXJjZSwgb25lIFJUVCBmcm9tIG1pZGRsZWJv eCB0byANCj4gbWVkaWEgc291cmNlIGNhbiBiZSBvbWl0dGVkLg0KPiANCj4gPiAtIFNlY3Rpb24g MywgNHRoIHBhcmFncmFwaDogIkluIHRoZSBjYXNlIHRoZSBmaXJzdCBUUExSIGlzIA0KPiBsb3N0 IGFuZCB0aGUgYWRkaXRpb25hbCBUUExSIGFycml2ZXMgYXQgdGhlIHJlY2VpdmVyLCB0aGUgDQo+ IHJlY2VpdmVyIHNob3VsZCBpbW1lZGlhdGVseSByZWZyZXNoIHRoZSB0aW1lciIgLSBzdXJlLCBi dXQgDQo+IHdoYXQgZWxzZSB3b3VsZCBpdCBkbz8gVGhpcyBtYWtlcyBpdCBzZWVtIHRoYXQgc29t ZXRoaW5nIA0KPiBkaWZmZXJlbnQgaXMgZG9uZSBpbiB0aGlzIGNhc2UsIGJ1dCB0aGUgYmVoYXZp b3VyIGxvb2tzIHRvIGJlIA0KPiB0aGUgc2FtZSB3aGV0aGVyIG9yIG5vdCBhIFRQTFIgaXMgbG9z dC4NCj4gDQo+IFtRaW5dOiBBc3N1bWUgdGhlIG1pZGRsZWJveCBzZW5kaW5nIE5BQ0sgdXBzdHJl YW0gYW5kIFRQTFIgDQo+IGRvd25zdHJlYW0gYXQgdGhlIHNhbWUgdGltZSxyZWZyZXNoIHRpbWVy IG1lYW5zIHdhaXRpbmcgZm9yIA0KPiBvbmUgUlRUIGZyb20gbWVkaWEgc291cmNlIHRvIGdldCB0 aGUgcmV0cmFuc21pdHRlZCBSVFAgZGF0YSANCj4gcGFja2V0IGFmdGVyIGdldHRpbmcgdGhhdCBh ZGRpdGlvbmFsIFRQTFIsIGhvd2V2ZXIgaWYgdGhlIA0KPiBtaWRkbGVib3ggaXRzZWxmIGlzIHJl cGFpciBzZXJ2ZXIsIHRoZSB0aW1lciBzaG91bGQgYmUgc2FtZSANCj4gaXJyZXNwZWN0aXZlbHkg YSBUUExSIGlzIGxvc3QsIGkuZS4sIDEvMiBSVFQgZnJvbSBtaWRkbGVib3ggDQo+IHRvIHRoZSBy ZWNlaXZlci4NCj4gDQo+IA0KPiA+IC0gU2VjdGlvbiA2LjM6IGlmIGEgbW9uaXRvciBjby1sb2Nh dGVkIHdpdGggYSB0cmFuc2xhdG9yIA0KPiBkZXRlY3RzIGEgbG9zcywgd2h5IGRvZXMgdGhhdCBt b25pdG9yIG5vdCBzZW5kIGEgTkFDSz8gTm90IA0KPiBjbGVhciB3aGF0J3MgdGhlIHJlYXNvbiBm b3IgdXNpbmcgYSBUUExSIGhlcmUuDQo+IA0KPiBbUWluXTpUaGF0J3MgYmVjb3MgdHJhbnNsYXRv ciBoYXMgYSBtb25pdG9yLCB3aGljaCB0b2xkIA0KPiB0cmFuc2xhdG9yIHRvIHNlbmQgVFBMUiwg aWYgdHJhbnNsYXRvciBoYXMgbm8gbW9uaXRvciBhbmQgDQo+IHJlY2VpdmVzIE5BQ0sgZnJvbSBh IHJlY2VpdmVyLCB0aGlzIHJlY2VpdmVyIHNob3VsZCBmb3J3YXJkIA0KPiBOQUNLIGRpcmVjdGx5 LiBEb2VzIHRoaXMgY2xhcmlmeT8NCj4gDQo+ID4gLSBTZWN0aW9uIDYuNTogdGhlIGJlaGF2aW91 ciBkZXNjcmliZWQgbWFrZXMgc2Vuc2UgZm9yIGFuIA0KPiBSVFAtdGVybWluYXRpbmcgbWl4ZXIs IGJ1dCBhbiBSRkMgMzU1MCBtaXhlciBjb3VsZCBqdXN0IA0KPiBmb3J3YXJkIHRoZSBGSVIgb3Ig UExJIG1lc3NhZ2VzIHdpdGhvdXQgdXNpbmcgdGhlIFRQTFIsIG5vPw0KPiANCj4gW1Fpbl06IEFj Y29yZGluZyB0byBTZWN0aW9uIDcuMyBvZiBSRkMgMzU1MCwgYSBtaXhlciBtdXN0IG5vdCANCj4g Zm9yd2FyZCBSVENQIHVuYWx0ZXJlZCBiZXR3ZWVuDQo+ICAgIHRoZSB0d28gZG9tYWlucywgYWxz byBhY2NvcmRpbmcgdG8gc2VjdGlvbiAzLjQgb2YgUkZDNTExNywgDQo+IEluIHNvbWUgY2FzZXMs IHRoZSByZWNlcHRpb24NCj4gICAgb2YgYSBjb2RlYy1jb250cm9sIG1lc3NhZ2UgbWF5IHJlc3Vs dCBpbiB0aGUgZ2VuZXJhdGlvbiBhbmQNCj4gICAgdHJhbnNtaXNzaW9uIG9mIFJUQ1AgZmVlZGJh Y2sgbWVzc2FnZXMgYnkgdGhlIE1peGVyIHRvIHRoZQ0KPiAgICBwYXJ0aWNpcGFudHMgaW4gdGhl IG90aGVyIGRvbWFpbi4gIA0KPiAgIFNvIEkgdGhpbmsgdGhpcyBpcyBub3QgYSBpc3N1ZS4NCj4g DQo+ID4gDQo+ID4gDQo+ID4gSSBhbHNvIGhhdmUgYSBudW1iZXIgb2YgbW9yZSBtaW5vciwgbW9z dGx5IGVkaXRvcmlhbCwgc3VnZ2VzdGlvbnM6DQo+ID4gDQo+ID4gLSBBYnN0cmFjdDogY2hhbmdl ICJ0aGF0IHRoZSBuZXR3b3JrIGlzIGF3YXJlIiB0byAidGhhdCB0aGUgDQo+IGZlZWRiYWNrIHRh cmdldCBpcyBhd2FyZSINCj4gDQo+IFtRaW5dOiBPa2F5LCBmaXhlZC4NCj4gDQo+ID4gLSBTZWN0 aW9uIDEsIDFzdCBwYXJhZ3JhcGg6ICJhcyBhIHBhY2tldCBsb3NzIHJlY292ZXJ5IA0KPiB0ZWNo bmlxdWUgYmFzZWQsIHNlbmRpbmciIC0+ICJhcyBhIHBhY2tldCBsb3NzIHJlY292ZXJ5IA0KPiB0 ZWNobmlxdWUsIHNlbmRpbmciDQo+IA0KPiBbUWluXTogT2theSwgZml4ZWQuDQo+IA0KPiA+IA0K PiA+IC0gU2VjdGlvbiAxLCA0dGggcGFyYWdyYXBoOiAid2hpbGUgdGhlIGNhc2UgdGhlIiAtPiAi d2hpbGUgDQo+IHRoZSBjYXNlIHdoZXJlIHRoZSINCj4gDQo+IFtRaW5dOiBPa2F5LCBmaXhlZC4N Cj4gPiANCj4gPiAtIFNlY3Rpb24gMSwgNHRoIHBhcmFncmFwaDogbGFzdCBzZW50ZW5jZSBpcyBy ZXBlYXRlZA0KPiANCj4gW1Fpbl06IE9rYXksIGZpeGVkLg0KPiA+IA0KPiA+IC0gU2VjdGlvbiAz LCAybmQgcGFyYWdyYXBoOiAiZ2VuZXJhdGVkIGJ5IGEgUlRQIHN5c3RlbSIgLT4gDQo+ICJnZW5l cmF0ZWQgYnkgYW4gUlRQIHN5c3RlbSINCj4gDQo+IFtRaW5dOiBPa2F5LCBmaXhlZC4NCj4gPiAN Cj4gPiAtIFNlY3Rpb24gMywgMm5kIHBhcmFncmFwaDogImFzIHBlciBBVlBGIiAtPiAiYXMgcGVy IHRoZSANCj4gUlRQL0FWUEYgcnVsZXMiDQo+IA0KPiBbUWluXTogT2theSwgZml4ZWQuDQo+ID4g DQo+ID4gLSBTZWN0aW9uIDMsIDJuZCBwYXJhZ3JhcGg6ICJTSE9VTEQgTk9UIGluaXRpYXRlIHRo ZWlyIG93biANCj4gYWRkaXRpb25hbCIgLT4gIlNIT1VMRCBOT1Qgc2VuZCB0aGVpciBvd24gYWRk aXRpb25hbCINCj4gDQo+IFtRaW5dOiBPa2F5LCBmaXhlZC4NCj4gPiANCj4gPiAtIFNlY3Rpb24g MywgNHRoIHBhcmFncmFwaDogd2hhdCBpcyBtZWFudCBieSAiYSANCj4gdHJhbnNtaXNzaW9uIHBh Y2tldCI/IERvIHlvdSBtZWFuIGFuIFJUUCBkYXRhIHBhY2tldCwgb3Igc29tZSANCj4gb3RoZXIg UlRDUCBwYWNrZXQ/DQo+IA0KPiBbUWluXTogUlRQIGRhdGEgcGFja2V0LiBJIHdpbGwgZml4IHRo aXMgYnkgYWRkaW5nIHNvbWUgDQo+IGV4cGxhbmF0aW9uIHRleHQuDQo+IA0KPiA+IA0KPiA+IC0g U2VjdGlvbiAzLCA0dGggcGFyYWdyYXBoOiBub3Qgc3VyZSB3aGF0IGlzIG1lYW50IGJ5ICJhIA0K PiByZWNlaXZlciBpcyBhbGxvd2VkIHRvIHJlY2VpdmUgYWRkaXRpb25hbCBUUExSIiAtIHdoZW4g d291bGQgDQo+IGl0IG5vdCBiZSBhbGxvd2VkIHRvIHJlY2VpdmU/IFdvdWxkIHRoaXMgYmUgYmV0 dGVyIHNheWluZyANCj4gdGhhdCB0aGUgc2VuZGluZyBhbiBnZW5lcmF0ZSBhbiBhZGRpdGlvbmFs IFRQTFI/DQo+IA0KPiBbUWluXTogT2theSwgZml4ZWQuDQo+ID4gDQo+ID4gLSBTZWN0aW9uIDMs IDV0aCBwYXJhZ3JhcGg6ICJtYXkgc3RpbGwgaGF2ZSBzZW50IiAtPiAibWF5IGhhdmUgc2VudCIN Cj4gDQo+IFtRaW5dOiBPa2F5LCBmaXhlZC4NCj4gPiANCj4gPiAtIFNlY3Rpb24gMywgNXRoIHBh cmFncmFwaDogIndpbGwgYmUgc3VwcHJlc3NlZCBieSB0aGlzIA0KPiB0ZWNobmlxdWUgZm9yIGEg Y2VydGFpbiBwZXJpb2Qgb2YgdGltZSIgLT4gIlNIT1VMRCBiZSANCj4gc3VwcHJlc3NlZCBmb3Ig YSBwZXJpb2Qgb2YgdGltZSBhZnRlciByZWNlaXZpbmcgdGhlIFRQTFIiPw0KPiANCj4gW1Fpbl06 IE9rYXksIGZpeGVkLg0KPiA+IA0KPiA+IC0gU2VjdGlvbiAzLCA2dGggcGFyYWdyYXBoOiB3aGF0 IGlzIG1lYW50IGJ5ICJjbG9zZXIgdG8gdGhlIA0KPiBzb3VyY2UiIGluIHRoaXMgcGFyYWdyYXBo PyANCj4gDQo+IFtRaW5dOiBtZWFucyB0aGUgbG9jYXRpb24gb2YgbWlkZGxlYm94IGlzIG1vcmUg Y2xvc2VyIHRvIHRoZSANCj4gbWVkaWEgc291cmNlLiANCj4gSSB3aWxsIGZpeCB0aGlzIGJ5IGFk ZGluZyBzb21lIGV4cGxhbmF0aW9uIHRleHQuDQo+IA0KPiA+IA0KPiA+IC0gU2VjdGlvbiA0LjE6 ICJiaXRtYXNrIG9mIHByb2NlZWRpbmcgbG9zdCBwYWNrZXRzIiAtPiANCj4gImJpdG1hc2sgb2Yg bG9zdCBwYWNrZXRzIg0KPiANCj4gW1Fpbl06IE9rYXksIGZpeGVkLg0KPiA+IA0KPiA+IA0KPiA+ IA0KPiA+IC0tIA0KPiA+IENvbGluIFBlcmtpbnMNCj4gPiBodHRwOi8vY3NwZXJraW5zLm9yZy8N Cj4gPiANCj4gPiANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNl DQo+ID4gYXZ0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hdnQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCj4gYXZ0QGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+ID0= From albrecht.schwarz@alcatel-lucent.com Tue Oct 11 05:17:43 2011 Return-Path: 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 D437921F8D8D for ; Tue, 11 Oct 2011 05:17:43 -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 wcRWT2Nc8ndS for ; Tue, 11 Oct 2011 05:17:42 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9A04B21F8D8C for ; Tue, 11 Oct 2011 05:17:42 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9BCFq3K006326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Oct 2011 14:17:16 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 11 Oct 2011 14:16:28 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Qin Wu , "avt@ietf.org" Date: Tue, 11 Oct 2011 14:17:05 +0200 Thread-Topic: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt Thread-Index: AcyIDj/Z56crtq+JRdWkhWTYf6ciqgAAVC5Q Message-ID: <5F7BCCF5541B7444830A2288ABBEBC962160D264A8@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <20110926081759.16674.85402.idtracker@ietfa.amsl.com> <9F1217B1416045A987E6B48A4CC87037@china.huawei.com> <5F7BCCF5541B7444830A2288ABBEBC962160D2642D@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: 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.80 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 12:17:43 -0000 Please note that there's also a definition of middlebox in draft-ietf-avtco= re-ecn-for-rtp, which might be also applicable. -Albrecht=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Qin Wu > Sent: Dienstag, 11. Oktober 2011 14:06 > To: Schwarz, Albrecht (Albrecht); Colin Perkins; avt@ietf.org > Subject: Re: [AVTCORE] I-D=20 > Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt >=20 > Hi, Albrecht: > Thank for your comment, I agree with your clarification and=20 > will be careful with terms using in the draft. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Schwarz, Albrecht (Albrecht)"=20 > > To: "Qin Wu" ; "Colin Perkins"=20 > ; > Sent: Tuesday, October 11, 2011 5:51 PM > Subject: RE: [AVTCORE] I-D=20 > Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt >=20 >=20 > Hi, > the notion of a "middlebox" is frequently used for justifying=20 > sth in the discussion below, but a reference to such a device=20 > is not really provided. > There seems to be two possible interpretations: > "Middlebox"=20 > a) =3D MIDCOM-compliant middlebox (and then a reference to=20 > definition =A7 2.2/RFC 3303 could be added) > b) =3D a network intermediate device that implements unknown=20 > services on top of IP packet forwarding (i.e., a block box=20 > with unknown behaviour). >=20 > I suppose that interpretation (b) is supposed here, - and=20 > thus slightly concerned that such a definition may be used to=20 > justify "any kind of requirement":-) >=20 > Regards, > Albrecht >=20 > PS > Similar is "repair server", but such a device is not=20 > mentioned in the draft. > =20 >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > > Behalf Of Qin Wu > > Sent: Dienstag, 11. Oktober 2011 10:11 > > To: Colin Perkins; avt@ietf.org > > Subject: Re: [AVTCORE] I-D=20 > > Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt > >=20 > > Hi, Colin: > > Thank for your careful review, please see my replies belows. > >=20 > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Colin Perkins" > > To: > > Sent: Tuesday, October 11, 2011 5:46 AM > > Subject: Re: [AVTCORE] I-D=20 > > Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt > >=20 > >=20 > > > On 26 Sep 2011, at 09:17, Internet-Drafts@ietf.org wrote: > > >> A New Internet-Draft is available from the on-line=20 > > Internet-Drafts directories. This draft is a work item of the=20 > > Audio/Video Transport Core Maintenance Working Group of the IETF. > > >>=20 > > >> Title : RTCP Extension for Third-party Loss Report > > >> Author(s) : Qin Wu > > >> Frank Xia > > >> Roni Even > > >> Filename :=20 > draft-ietf-avtcore-feedback-supression-rtp-07.txt > > >> Pages : 16 > > >> Date : 2011-09-26 > > >>=20 > > >> In a large RTP session using the RTCP feedback mechanism=20 > > defined in > > >> RFC 4585, a feedback target may experience transient=20 > > overload if some > > >> event causes a large number of receivers to send=20 > > feedback at once. > > >> This overload is usually avoided by ensuring that=20 > > feedback reports > > >> are forwarded to all receivers, allowing them to avoid sending > > >> duplicate feedback reports. However, there are cases=20 > > where it is not > > >> recommended to forward feedback reports, and this may=20 > > allow feedback > > >> implosion. This memo discusses these cases and defines=20 > > a new RTCP > > >> third-party loss report that can be used to inform=20 > > receivers that the > > >> network is aware of some loss event, allowing them to suppress > > >> feedback. Associated SDP signalling is also defined. > > >>=20 > > >>=20 > > >> A URL for this Internet-Draft is: > > >>=20 > > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedbac > > k-supression-rtp-07.txt > > >=20 > > >=20 > > > I have read this draft, and have some comments: > > >=20 > > > - Section 1, 1st paragraph: "(e.g, implementing the RFC=20 > > 4585" - should this be "(e.g., not implementing the RFC 4585"? > >=20 > > [Qin]:It is a typo and my mistake. Thank for catching it. > >=20 > >=20 > > > - Section 3, 3rd paragraph, says the "timer value shall be=20 > > based on the observed round-trip time", but it's not clear=20 > > that this means. By based on, do you mean equal to the RTT,=20 > > or some other function derived from it? Which RTT? The=20 > > suppression, ideally, wants to be for long enough for the=20 > > sender of the TPLR to somehow repair the loss at all of its=20 > > downstream receivers, so none of them need to resend a NACK.=20 > > This might imply the RTT from the receiver to the original=20 > > media source and/or repair server be used, which is different=20 > > from the RTT specified. I think some more thought is needed here. > > >=20 > >=20 > > [Qin]: See my discussion with Magnus in the previous email on=20 > > this thread. But that need some corrections. I think you are=20 > > right, If the middlbox is repair server, more approximate RTT=20 > > is the RTT from the receiver and repair server. If the=20 > > original media is repair server, more approximate RTT should=20 > > be 1/2 of RTT between the middlebox and receiver plus RTT=20 > > from middlebox to media source. But if the middlebox sending=20 > > TPLR is more close to media source, one RTT from middlebox to=20 > > media source can be omitted. > >=20 > > > - Section 3, 4th paragraph: "In the case the first TPLR is=20 > > lost and the additional TPLR arrives at the receiver, the=20 > > receiver should immediately refresh the timer" - sure, but=20 > > what else would it do? This makes it seem that something=20 > > different is done in this case, but the behaviour looks to be=20 > > the same whether or not a TPLR is lost. > >=20 > > [Qin]: Assume the middlebox sending NACK upstream and TPLR=20 > > downstream at the same time,refresh timer means waiting for=20 > > one RTT from media source to get the retransmitted RTP data=20 > > packet after getting that additional TPLR, however if the=20 > > middlebox itself is repair server, the timer should be same=20 > > irrespectively a TPLR is lost, i.e., 1/2 RTT from middlebox=20 > > to the receiver. > >=20 > >=20 > > > - Section 6.3: if a monitor co-located with a translator=20 > > detects a loss, why does that monitor not send a NACK? Not=20 > > clear what's the reason for using a TPLR here. > >=20 > > [Qin]:That's becos translator has a monitor, which told=20 > > translator to send TPLR, if translator has no monitor and=20 > > receives NACK from a receiver, this receiver should forward=20 > > NACK directly. Does this clarify? > >=20 > > > - Section 6.5: the behaviour described makes sense for an=20 > > RTP-terminating mixer, but an RFC 3550 mixer could just=20 > > forward the FIR or PLI messages without using the TPLR, no? > >=20 > > [Qin]: According to Section 7.3 of RFC 3550, a mixer must not=20 > > forward RTCP unaltered between > > the two domains, also according to section 3.4 of RFC5117,=20 > > 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. =20 > > So I think this is not a issue. > >=20 > > >=20 > > >=20 > > > I also have a number of more minor, mostly editorial, suggestions: > > >=20 > > > - Abstract: change "that the network is aware" to "that the=20 > > feedback target is aware" > >=20 > > [Qin]: Okay, fixed. > >=20 > > > - Section 1, 1st paragraph: "as a packet loss recovery=20 > > technique based, sending" -> "as a packet loss recovery=20 > > technique, sending" > >=20 > > [Qin]: Okay, fixed. > >=20 > > >=20 > > > - Section 1, 4th paragraph: "while the case the" -> "while=20 > > the case where the" > >=20 > > [Qin]: Okay, fixed. > > >=20 > > > - Section 1, 4th paragraph: last sentence is repeated > >=20 > > [Qin]: Okay, fixed. > > >=20 > > > - Section 3, 2nd paragraph: "generated by a RTP system" ->=20 > > "generated by an RTP system" > >=20 > > [Qin]: Okay, fixed. > > >=20 > > > - Section 3, 2nd paragraph: "as per AVPF" -> "as per the=20 > > RTP/AVPF rules" > >=20 > > [Qin]: Okay, fixed. > > >=20 > > > - Section 3, 2nd paragraph: "SHOULD NOT initiate their own=20 > > additional" -> "SHOULD NOT send their own additional" > >=20 > > [Qin]: Okay, fixed. > > >=20 > > > - Section 3, 4th paragraph: what is meant by "a=20 > > transmission packet"? Do you mean an RTP data packet, or some=20 > > other RTCP packet? > >=20 > > [Qin]: RTP data packet. I will fix this by adding some=20 > > explanation text. > >=20 > > >=20 > > > - Section 3, 4th paragraph: not sure what is meant by "a=20 > > receiver is allowed to receive additional TPLR" - when would=20 > > it not be allowed to receive? Would this be better saying=20 > > that the sending an generate an additional TPLR? > >=20 > > [Qin]: Okay, fixed. > > >=20 > > > - Section 3, 5th paragraph: "may still have sent" -> "may=20 > have sent" > >=20 > > [Qin]: Okay, fixed. > > >=20 > > > - Section 3, 5th paragraph: "will be suppressed by this=20 > > technique for a certain period of time" -> "SHOULD be=20 > > suppressed for a period of time after receiving the TPLR"? > >=20 > > [Qin]: Okay, fixed. > > >=20 > > > - Section 3, 6th paragraph: what is meant by "closer to the=20 > > source" in this paragraph?=20 > >=20 > > [Qin]: means the location of middlebox is more closer to the=20 > > media source.=20 > > I will fix this by adding some explanation text. > >=20 > > >=20 > > > - Section 4.1: "bitmask of proceeding lost packets" ->=20 > > "bitmask of lost packets" > >=20 > > [Qin]: Okay, fixed. > > >=20 > > >=20 > > >=20 > > > --=20 > > > Colin Perkins > > > http://csperkins.org/ > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > 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 > > =3D > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > = From magnus.westerlund@ericsson.com Tue Oct 11 05:31:04 2011 Return-Path: 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 6B2D621F8C0B; Tue, 11 Oct 2011 05:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 cDJScPvZwhIm; Tue, 11 Oct 2011 05:31:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 677BD21F8BB9; Tue, 11 Oct 2011 05:31:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-0d-4e943706bac2 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 57.93.13753.607349E4; Tue, 11 Oct 2011 14:31:02 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 11 Oct 2011 14:31:01 +0200 Message-ID: <4E943705.8080409@ericsson.com> Date: Tue, 11 Oct 2011 14:31:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D5410097E4B@xmb-sjc-215.amer.cisco.com> <4E940F52.4030007@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D54100980DB@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54100980DB@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic \(E-mail\)" , "avt@ietf.org" Subject: Re: [AVTCORE] Duplication semantics drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 12:31:04 -0000 On 2011-10-11 12:46, Ali C. Begen (abegen) wrote: >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> (as Individual) >> I have looked at the redundancy-grouping draft and still think it fails >> as RTP specifications for how duplication should be done in RTP, either >> using SSRC multiplexing with two different SSRCs in the same RTP session >> or for the alternative how having two different RTP sessions. This first >> appears to be sufficiently specified, where my only comment is the >> dependency on signalling to determine that this grouping is in place. I >> do propose that an RTP/RTCP based complement is derived. I would >> personally suggest that my own proposal for a new SDES item SRCNAME is >> used but that should clearly be discussed. > > Right, the ssrc muxing case is straightforward and easy to implement. > Everything works fine without the need for defining new stuff except > the grouping semantics. I am not sure why you think there is a problem > in the signaling. Yes, it works as long as the application can accept to rely on the signalling protocol. However, if one would like to to this in session where one has a dynamic set of participants and it is large enough that it isn't feasible to updated the signalling for each new participant that joins the session and is a potential sender. Then it would be good to have something that works on the RTP/RTCP level. > > If duplication will be done across sessions (your second case), then it gets complicated. And as I understand your claim is regular CNAME falls short to define this relation. Is that correct? And your proposal is SRCNAME, right? Yes, the show case when CNAME falls short is for any case where an end-point will have multiple media flows in the same session. So in this case you have 2 SSRC in one session carrying the source (original) stream and 2 SSRCs in the second carrying the duplicated data. As the two source SSRC come from the same synchronization context they do carry the same CNAME. Thus a receiver will have two sets of SSRCs that both carry the same CNAME. Thus that can't be used to bind the correct set of SSRCs together. Using the sequence numbers are prone to errors and can easily fail. I don't like overriding the SSRC randomization and require the duplicated streams to have the same SSRC as the original. It also creates separate solutions for the two cases. I therefore prefer to see a solution that can handle both cases and targeted at this particular problem. There will be a dedicated version of the SRCNAME draft submitted before the deadline. > >> For the case where multiple RTP sessions are used, it is still not clear >> how a receiver determine which SSRC in each RTP session that are >> related. And I would like to point out that CNAME is not sufficient. >> >> I still think we should consider splitting this into one AVTCORE >> document discussing the RTP aspects of duplication, and another MMUSIC >> document defining the grouping semantics. > > This sounds like a good plan to me. Good Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From csp@csperkins.org Tue Oct 11 07:13:25 2011 Return-Path: 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 0288821F8DB4 for ; Tue, 11 Oct 2011 07:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 W-206Q7o+utc for ; Tue, 11 Oct 2011 07:13:24 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7E421F8B9D for ; Tue, 11 Oct 2011 07:13:24 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RDd59-0007WU-Xk; Tue, 11 Oct 2011 14:13:23 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins X-Priority: 3 In-Reply-To: <9F1217B1416045A987E6B48A4CC87037@china.huawei.com> Date: Tue, 11 Oct 2011 15:13:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <34C8727C-BD15-460B-9107-05C683B2B39C@csperkins.org> References: <20110926081759.16674.85402.idtracker@ietfa.amsl.com> <9F1217B1416045A987E6B48A4CC87037@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1084) Cc: avt@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 14:13:25 -0000 Qin, On 11 Oct 2011, at 09:11, Qin Wu wrote: > Hi, Colin: > Thank for your careful review, please see my replies belows. >=20 > Regards! > -Qin > ----- Original Message -----=20 > From: "Colin Perkins" > To: > Sent: Tuesday, October 11, 2011 5:46 AM > Subject: Re: [AVTCORE] I-D = Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt >=20 >=20 >> 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. >>>=20 >>> 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 >>>=20 >>> 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. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression= -rtp-07.txt >>=20 >>=20 >> I have read this draft, and have some comments: >>=20 >> - Section 1, 1st paragraph: "(e.g, implementing the RFC 4585" - = should this be "(e.g., not implementing the RFC 4585"? >=20 > [Qin]:It is a typo and my mistake. Thank for catching it. >=20 >=20 >> - 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. >>=20 >=20 > [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. 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. >> - 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. >=20 > [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. 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. >> - 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. >=20 > [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? 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. >> - 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? >=20 > [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. =20 > 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. --=20 Colin Perkins http://csperkins.org/ From fboronat@dcom.upv.es Tue Oct 11 02:54:34 2011 Return-Path: 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 9691621F8D23; Tue, 11 Oct 2011 02:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 fcB8Rpv4qqqI; Tue, 11 Oct 2011 02:54:31 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6934D21F8C98; Tue, 11 Oct 2011 02:54:27 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p9B9sOax011485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2011 11:54:24 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p9B9sOwW016751; Tue, 11 Oct 2011 11:54:24 +0200 Received: from [127.0.0.1] (fboronat2114.pc.upv.es [158.42.145.157]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id p9B9sNY3022508; Tue, 11 Oct 2011 11:54:23 +0200 Message-ID: <4E941250.2080500@dcom.upv.es> Date: Tue, 11 Oct 2011 11:54:24 +0200 From: =?ISO-8859-1?Q?Fernando_Boronat_Segu=ED?= Organization: UNIVERSIDAD =?ISO-8859-1?Q?POLIT=C9CNICA_DE_VALENCIA?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: avt@ietf.org, xrblock-request@ietf.org Content-Type: multipart/alternative; boundary="------------020902020101000503040600" X-Mailman-Approved-At: Tue, 11 Oct 2011 07:49:55 -0700 Subject: [AVTCORE] Possible Additional functionalities for draft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fboronat@dcom.upv.es List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 09:54:34 -0000 This is a multi-part message in MIME format. --------------020902020101000503040600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Group members, As this is our first mail to the list, we introduce ourselves. We are Fernando Boronat and Mario Montagud, co-authors of the Internet Draft (I-D) "RTCP for inter-destination media synchronization" (draft-ietf-avtcore-idms-01.txt). As the I-D was accepted as a WG document, any changes will have to be approved by the AVTCORE group. So, we would like to know if you consider appropriate to introduce some additional functionalities to the proposed IDMS approach in the I-D. In many distributed applications it is required that all the receivers start the playout of the media stream almost simultaneously (we refer this as Coarse Sync) and, after that, all of them play-out the media in a synchronous way (we refer this as Fine Sync). Those processes are essential for acquiring IDMS. A Global Initial Playout Instant for all the geographically distributed receivers (SCs) in a media session could prevent from an initial playout time discrepancy (asynchrony) at the beginning of the playout of the media stream/s (if a fixed global initial buffering delay is set) mainly due to the variable network delays from the media server to each one of the SCs. Thus, we are thinking about including a new section in the I-D about possible packets for Coarse Sync for both the initial playout instant (at the begining of a media session) and the initial instant at each stage in which the session can be divided (we consider that a stage ends when no streams are transmitted during a fixed interval (it could be defined depending on the applications), and that the next stage starts when data is transmitted again). This technique has been considered in some previous IDMS works (see reference [Boronat09] in the I-D), but using proprietary protocols. The methods we propose here are based on the use of already defined and standard RTCP packets, which would avoid the introduction of proprietary closed solutions. Regarding the Initial Playout Instant, we have primarily thought about the use of already proposed RTCP XR packets (RFC 3611): 1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC 3611) for measuring the delay between MSAS and SCs, allowing MSAS to estimate the RTT for all the SCs, then calculate a common initial playout instant and then communicate it to all SCs by sending them an RTCP IDMS Packet (defined in the I-D). The RTCP IDMS packet must include the RTP Timestamp of the first MU to be sent by the source and its proper playout instant, which will be common for all of them. MSAS may estimate its round trip time (RTT) to the SCs by sending them an RTCP XR with the Receiver Reference Time Report Block and forcing (according to RFC 3611) them to reply by sending an RTCP XR with a DLRR Report Block. Notice that both XR blocks are defined in RFC 3611 to be used in the opposite way we propose. If this solution is not considered appropriate we could think about another solution based on the packets already defined in the I-D, but maybe we would need to change the format adding new field/s. 2. Once joined the session, if it is not started yet, all the SCs could start sending RTCP XR with IDMS block (until they receive the Initial Playout Instant indication, sent using the RTCP IDMS Packet) as it is defined in the I-D, but including only the essential timing information (e.g. the wallclock time at which the packet is sent by the SC) to let the MSAS estimate the one-way network delays (not round-trip as in the previous case) for each SC (assuming symmetric delays as in TCP) and calculate the Initial Playout Instant. For that purpose, some field of the RTCP XR IDMS block should be used to indicate the XR IDMS block is carrying out temporal information for Coarse Sync, and not for reporting about arrival/playout timing of a specific RTP packet. From the Initial Instant they will continue playing the streams and sending the RTCP XR with IDMS complete block (as currently defined in the I-D). It could be a possible solution. The process of the calculation of the optimum Initial Playout Instant must take into consideration some factors such as the maximum and minimum estimated delays, jitter values, expected duration of the session, or probable clock deviations, in order to allow enough buffered MUs to start the playout and to maintain it continuously, thus avoiding underflow/overflow situations (playout discontinuities), during the session. This process is out of the scope of the ID. With the introduction of the Coarse Sync functionality, the IDMS proposal can counteract the effect of the delay variability at the beginning of the playout of the media stream/s in each one of the stages in which a media session can be divided. We prefer the first method because there is no need to define new IDMS control messages (or to include some fields to already defined packets), but the use of already defined RTCP reports (RFC 3611) can be adapted for that purpose. Moreover, with the use of the first method, SCs do not have to send control messages once they join the session, which may possibly result on inefficient control traffic overhead. They will only have to send RTCP XR DLRR messages in response to a new incoming RTRR message from the source, which is who really knows the initial transmission time for the RTP media stream. Moreover, the Initial Playout Instant can be sent to the receivers by using the RTCP IDMS packet, already introduced in the I-D. Feedback will be much appreciated. Regards ======================================================================== Dr. Fernando Boronat Seguí IEEE Senior Member Profesor Titular / Lecturer Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN ======================================================================== --------------020902020101000503040600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Group members,

As this is our first mail to the list, we introduce ourselves. We are Fernando Boronat and Mario Montagud, co-authors of the Internet Draft (I-D) “RTCP for inter-destination media synchronization” (draft-ietf-avtcore-idms-01.txt).
As the I-D was accepted as a WG document, any changes will have to be approved by the AVTCORE group. So, we would like to know if you consider appropriate to introduce some additional functionalities to the proposed IDMS approach in the I-D.

In many distributed applications it is required that all the receivers start the playout of the media stream almost simultaneously (we refer this as Coarse Sync) and, after that, all of them play-out the media in a synchronous way (we refer this as Fine Sync). Those processes are essential for acquiring IDMS. A Global Initial Playout Instant for all the geographically distributed receivers (SCs) in a media session could prevent from an initial playout time discrepancy (asynchrony) at the beginning of the playout of the media stream/s (if a fixed global initial buffering delay is set) mainly due to the variable network delays from the media server to each one of the SCs.

Thus, we are thinking about including a new section in the I-D about possible packets for Coarse Sync for both the initial playout instant (at the begining of a media session) and the initial instant at each stage in which the session can be divided (we consider that a stage ends when no streams are transmitted during a fixed interval (it could be defined depending on the applications), and that the next stage starts when data is transmitted again).

This technique has been considered in some previous IDMS works (see reference [Boronat09] in the I-D), but using proprietary protocols. The methods we propose here are based on the use of already defined and standard RTCP packets, which would avoid the introduction of proprietary closed solutions.

Regarding the Initial Playout Instant, we have primarily thought about the use of already proposed RTCP XR packets (RFC 3611):

1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC 3611) for measuring the delay between MSAS and SCs, allowing MSAS to estimate the RTT for all the SCs, then calculate a common initial playout instant and then communicate it to all SCs by sending them an RTCP IDMS Packet (defined in the I-D). The RTCP IDMS packet must include the RTP Timestamp of the first MU to be sent by the source and its proper playout instant, which will be common for all of them.
MSAS may estimate its round trip time (RTT) to the SCs by sending them an RTCP XR with the Receiver Reference Time Report Block and forcing (according to RFC 3611) them to reply by sending an RTCP XR with a DLRR Report Block. Notice that both XR blocks are defined in RFC 3611 to be used in the opposite way we propose.

If this solution is not considered appropriate we could think about another solution based on the packets already defined in the I-D, but maybe we would need to change the format adding new field/s.

2. Once joined the session, if it is not started yet, all the SCs could start sending RTCP XR with IDMS block (until they receive the Initial Playout Instant indication, sent using the RTCP IDMS Packet) as it is defined in the I-D, but including only the essential timing information (e.g. the wallclock time at which the packet is sent by the SC) to let the MSAS estimate the one-way network delays (not round-trip as in the previous case) for each SC (assuming symmetric delays as in TCP) and calculate the Initial Playout Instant. For that purpose, some field of the RTCP XR IDMS block should be used to indicate the XR IDMS block is carrying out temporal information for Coarse Sync, and not for reporting about arrival/playout timing of a specific RTP packet.
From the Initial Instant they will continue playing the streams and sending the RTCP XR with IDMS complete block (as currently defined in the I-D). It could be a possible solution.

The process of the calculation of the optimum Initial Playout Instant must take into consideration some factors such as the maximum and minimum estimated delays, jitter values, expected duration of the session, or probable clock deviations, in order to allow enough buffered MUs to start the playout and to maintain it continuously, thus avoiding underflow/overflow situations (playout discontinuities), during the session. This process is out of the scope of the ID.

With the introduction of the Coarse Sync functionality, the IDMS proposal can counteract the effect of the delay variability at the beginning of the playout of the media stream/s in each one of the stages in which a media session can be divided.

We prefer the first method because there is no need to define new IDMS control messages (or to include some fields to already defined packets), but the use of already defined RTCP reports (RFC 3611) can be adapted for that purpose.

Moreover, with the use of the first method, SCs do not have to send control messages once they join the session, which may possibly result on inefficient control traffic overhead. They will only have to send RTCP XR DLRR messages in response to a new incoming RTRR message from the source, which is who really knows the initial transmission time for the RTP media stream. Moreover, the Initial Playout Instant can be sent to the receivers by using the RTCP IDMS packet, already introduced in the I-D.

Feedback will be much appreciated.
Regards
========================================================================
Dr. Fernando Boronat Seguí
IEEE Senior Member
Profesor Titular / Lecturer	
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================
--------------020902020101000503040600-- From fboronat@dcom.upv.es Tue Oct 11 06:37:12 2011 Return-Path: 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 4D19F21F8C4D; Tue, 11 Oct 2011 06:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3] 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 wbDuU-bhhrwY; Tue, 11 Oct 2011 06:37:11 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 52AC221F8BF8; Tue, 11 Oct 2011 06:37:10 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p9BDb8D4003002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2011 15:37:09 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p9BDb8uF017694; Tue, 11 Oct 2011 15:37:09 +0200 Received: from [127.0.0.1] (fboronat2114.pc.upv.es [158.42.145.157]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id p9BDb7OU020328; Tue, 11 Oct 2011 15:37:07 +0200 Message-ID: <4E94467D.7040601@dcom.upv.es> Date: Tue, 11 Oct 2011 15:37:01 +0200 From: =?windows-1252?Q?Fernando_Boronat_Segu=ED?= Organization: UNIVERSIDAD =?windows-1252?Q?POLIT=C9CNICA_DE_VALENCIA?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: avt@ietf.org, xrblock-request@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 11 Oct 2011 07:49:55 -0700 Subject: [AVTCORE] Possible Additional functionalities for draft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fboronat@dcom.upv.es List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 13:37:12 -0000 Dear Group members, As this is our first mail to the list, we introduce ourselves. We are Fernando Boronat and Mario Montagud, co-authors of the Internet Draft (I-D) “RTCP for inter-destination media synchronization” (draft-ietf-avtcore-idms-01.txt). As the I-D was accepted as a WG document, any changes will have to be approved by the AVTCORE group. So, we would like to know if you consider appropriate to introduce some additional functionalities to the proposed IDMS approach in the I-D. In many distributed applications it is required that all the receivers start the playout of the media stream almost simultaneously (we refer this as Coarse Sync) and, after that, all of them play-out the media in a synchronous way (we refer this as Fine Sync). Those processes are essential for acquiring IDMS. A Global Initial Playout Instant for all the geographically distributed receivers (SCs) in a media session could prevent from an initial playout time discrepancy (asynchrony) at the beginning of the playout of the media stream/s (if a fixed global initial buffering delay is set) mainly due to the variable network delays from the media server to each one of the SCs. Thus, we are thinking about including a new section in the I-D about possible packets for Coarse Sync for both the initial playout instant (at the begining of a media session) and the initial instant at each stage in which the session can be divided (we consider that a stage ends when no streams are transmitted during a fixed interval (it could be defined depending on the applications), and that the next stage starts when data is transmitted again). This technique has been considered in some previous IDMS works (see reference [Boronat09] in the I-D), but using proprietary protocols. The methods we propose here are based on the use of already defined and standard RTCP packets, which would avoid the introduction of proprietary closed solutions. Regarding the Initial Playout Instant, we have primarily thought about the use of already proposed RTCP XR packets (RFC 3611): 1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC 3611) for measuring the delay between MSAS and SCs, allowing MSAS to estimate the RTT for all the SCs, then calculate a common initial playout instant and then communicate it to all SCs by sending them an RTCP IDMS Packet (defined in the I-D). The RTCP IDMS packet must include the RTP Timestamp of the first MU to be sent by the source and its proper playout instant, which will be common for all of them. MSAS may estimate its round trip time (RTT) to the SCs by sending them an RTCP XR with the Receiver Reference Time Report Block and forcing (according to RFC 3611) them to reply by sending an RTCP XR with a DLRR Report Block. Notice that both XR blocks are defined in RFC 3611 to be used in the opposite way we propose. If this solution is not considered appropriate we could think about another solution based on the packets already defined in the I-D, but maybe we would need to change the format adding new field/s. 2. Once joined the session, if it is not started yet, all the SCs could start sending RTCP XR with IDMS block (until they receive the Initial Playout Instant indication, sent using the RTCP IDMS Packet) as it is defined in the I-D, but including only the essential timing information (e.g. the wallclock time at which the packet is sent by the SC) to let the MSAS estimate the one-way network delays (not round-trip as in the previous case) for each SC (assuming symmetric delays as in TCP) and calculate the Initial Playout Instant. For that purpose, some field of the RTCP XR IDMS block should be used to indicate the XR IDMS block is carrying out temporal information for Coarse Sync, and not for reporting about arrival/playout timing of a specific RTP packet. From the Initial Instant they will continue playing the streams and sending the RTCP XR with IDMS complete block (as currently defined in the I-D). It could be a possible solution. The process of the calculation of the optimum Initial Playout Instant must take into consideration some factors such as the maximum and minimum estimated delays, jitter values, expected duration of the session, or probable clock deviations, in order to allow enough buffered MUs to start the playout and to maintain it continuously, thus avoiding underflow/overflow situations (playout discontinuities), during the session. This process is out of the scope of the ID. With the introduction of the Coarse Sync functionality, the IDMS proposal can counteract the effect of the delay variability at the beginning of the playout of the media stream/s in each one of the stages in which a media session can be divided. We prefer the first method because there is no need to define new IDMS control messages (or to include some fields to already defined packets), but the use of already defined RTCP reports (RFC 3611) can be adapted for that purpose. Moreover, with the use of the first method, SCs do not have to send control messages once they join the session, which may possibly result on inefficient control traffic overhead. They will only have to send RTCP XR DLRR messages in response to a new incoming RTRR message from the source, which is who really knows the initial transmission time for the RTP media stream. Moreover, the Initial Playout Instant can be sent to the receivers by using the RTCP IDMS packet, already introduced in the I-D. Feedback will be much appreciated. Regards ======================================================================== Dr. Fernando Boronat Seguí IEEE Senior Member Profesor Titular / Lecturer Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN ======================================================================== From thomas.belling@nsn.com Tue Oct 11 08:14:26 2011 Return-Path: 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 EA17A21F8E28 for ; Tue, 11 Oct 2011 08:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 D41vNbpsv4HQ for ; Tue, 11 Oct 2011 08:14:24 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF3221F8E23 for ; Tue, 11 Oct 2011 08:14:23 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9BFED76007317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Oct 2011 17:14:13 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9BFECAV031881; Tue, 11 Oct 2011 17:14:12 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 17:14:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8828.6EA9F332" Date: Tue, 11 Oct 2011 17:14:12 +0200 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F98549C@DEMUEXC014.nsn-intra.net> In-Reply-To: <76AADF1A61784B52A8516E16AAF78E71@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 Thread-Index: AcyHwHxs/U3+y8TaT2ammrvk+OA0TwAM8xqg References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <76AADF1A61784B52A8516E16AAF78E71@china.huawei.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Qin Wu" , "Roni Even" , X-OriginalArrivalTime: 11 Oct 2011 15:14:12.0752 (UTC) FILETIME=[6EE5B900:01CC8828] Cc: Magnus Westerlund Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:14:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8828.6EA9F332 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Dear Qin, Magnus, =20 Some replies to some of the earlier comments (I only briefly checked the rest). =20 Thomas =20 =20 3. Section 3, 2nd paragraph " Counting vs Detecting Congestion: TCP and the protocols derived from it are mainly designed to respond the same whether they experience a burst of congestion indications within one RTT or just one. " [Qin]: What's the difference between "one RTT" and "just one"? =20 [Thomas] Intention seems rather to be "just one congestion indication". =20 =20 7. Section 3.2, 5th paragraph " The standard RTP/ AVP profile [RFC3551] does not allow any early or immediate transmission of RTCP feedback, and has a minimal RTCP interval whose default value (5 seconds) is many times the normal RTT between sender and receiver. " [Qin]: What's the purpose of last sentence of this paragraph? Are you saying RFC3551 following Regular RTCP timing rule? or something else? =20 Another question is according to RFC3551, the negotiation of parameters or membership control may be not support. in other wonder, there may be no way to negotiate ECN with RTP using SDP signaling, I am wondering can we say ECN with RTP can be used with the standard RTP/ AVP profile [RFC3551].=20 =20 [Thomas] Negotiation is done with the 'ecn-capable-rtp' SDP attribute defined is this draft. Implantations not supporting ECN would ignore this, But this is independent of AVP or AVPF.=20 =20 =20 8. Section 3.3,3rd paragraph " For interoperability we mandate the implementation of the RTP/AVPF profile, with both RTCP extensions and the necessary signalling to support a common operations mode. This specification recommends the use of RTP/AVPF in all cases as negotiation of the common interoperability point requires RTP/AVPF, mixed negotiation of RTP/ AVP and RTP/AVPF depending on other SDP attributes in the same media block is difficult, " [Qin] How mixed negotiation is avoided when you don't put all the SDP attribute into the same media block? I don't really understand the rationale. Would you like to clarify a little bit? =20 [Thomas] SDP capneg allows offering AVPF and AVP in the same media block, and also to relate SDP attributes to one of the transports only. Trouble is that this is not yet supported everywhere and has its problems with traversing intermediates not supporting it. =20 =20 11. Section 4, 3rd paragraph " o The sender may generate a (small) subset of its RTP data packets with the ECN field set to ECT(0) or ECT(1).=20 " =20 [Qin] It is not clear to me where the ECN field is located. Is ECN field in the IP header or UDP header or RTP header? =20 [Thomas] It is the IP header. Text could be modified accordingly, e.g.:=20 o The sender may generate a (small) subset of its RTP data packets with the ECN IP header field set to ECT(0) or ECT(1).=20 =20 =20 13.Section 5.1,1st paragraph " This RTP/AVPF transport layer feedback format is intended for use in RTP/AVPF early or immediate feedback modes when information needs to urgently reach the sender. Thus its main use is to report reception of an ECN-CE marked RTP packet so that the sender may perform congestion control, or to speed up the initiation procedures by rapidly reporting that the path can support ECN-marked traffic. " =20 [Qin]: are you saying slow initiation procedure may result in network congestion? In my understanding, when ECN-CE marked packet is received, the only choice for sender is to do congestion control since you are not sure if initiation procedure lead to such congestion. If it is not intiation procedure that lead to congestion, you get risk to worse congestion condition?=20 =20 [Thomas] I believe this does not only refer to initiation, but mainly to feedback if congestion is encountered after the ECN media flow has been established. =20 =20 =20 =20 Regards! -Qin =20 ----- Original Message -----=20 From: Roni Even =20 To: avt@ietf.org=20 Sent: Friday, September 30, 2011 8:29 PM Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 =20 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP over UDP. =20 The WGLC will end on October 21, 2011 =20 Please review the draft and send comments to the list. =20 =20 Roni Even =20 =20 =20 =09 ________________________________ _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01CC8828.6EA9F332 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Dear Qin, = Magnus,

 

Some = replies to some of the earlier comments (I only briefly checked the = rest).

 

Thomas

 

 

3. = Section 3, 2nd paragraph

"

   Counting vs Detecting Congestion:  TCP = and the protocols derived from
   it are mainly = designed to respond the same whether they = experience
   a burst of congestion indications within = one RTT or just one.

"

[Qin]: = What's the difference between "one RTT" and "just = one"?

 

[Thomas] = Intention seems rather to be “just one congestion = indication”.

 

 

7. = Section 3.2, 5th paragraph

"

The = standard RTP/ AVP profile [RFC3551] does not allow any early or = immediate
transmission of RTCP feedback, and has a minimal RTCP = interval whose default value

 (5 seconds) is many times the normal RTT between = sender and receiver.

"

[Qin]: = What's the purpose of last sentence of this = paragraph?
       Are you saying = RFC3551 following Regular RTCP timing = rule?
       or something = else?

 

   Another question is according to RFC3551, = the negotiation of
   parameters or membership control may = be not support. in other wonder,
   there may be no way to = negotiate ECN with RTP using SDP signaling,
   I am = wondering can we say ECN with RTP can be used with the standard = RTP/
   AVP profile [RFC3551].

 

[Thomas] = Negotiation is done with the ‘ecn-capable-rtp’ SDP attribute = defined is this draft. Implantations not supporting ECN would ignore = this, But this is independent of AVP or AVPF. =

 

 

8. = Section 3.3,3rd paragraph

"

   For interoperability we mandate the = implementation of the RTP/AVPF
   profile, with both RTCP = extensions and the necessary signalling to
   support a = common operations mode.  This specification recommends = the
   use of RTP/AVPF in all cases as negotiation of the = common
   interoperability point requires RTP/AVPF, mixed = negotiation of RTP/
   AVP and RTP/AVPF depending on other = SDP attributes in the same media
   block is = difficult,

"

[Qin] = How mixed negotiation is avoided when you don't put all the SDP = attribute
 into the same media block? I don't really understand = the rationale. Would you
like to clarify a little = bit?

 

[Thomas] = SDP capneg allows offering AVPF and AVP in the same media block, and = also to relate SDP attributes to one of the transports only. Trouble is = that this is not yet supported everywhere and has its problems with = traversing intermediates not supporting = it.

 

 

11. = Section 4, 3rd paragraph

"

   o  The sender may generate a (small) = subset of its RTP data packets
      with = the ECN field set to ECT(0) or ECT(1). =

"

 

[Qin] = It is not clear to me where the ECN field is located.
Is ECN field in = the IP header or UDP header or RTP header?

 

[Thomas] It = is the IP header. Text could be modified accordingly, e.g.: =

    o  The sender may generate a = (small) subset of its RTP data packets
      = with the ECN IP header field set to = ECT(0) or ECT(1).

 

 

13.Section 5.1,1st = paragraph

"

   This RTP/AVPF transport layer feedback = format is intended for use in
   RTP/AVPF early or = immediate feedback modes when information needs to
   = urgently reach the sender.  Thus its main use is to report = reception
   of an ECN-CE marked RTP packet so that the = sender may perform
   congestion control, or to speed up = the initiation procedures by
   rapidly reporting that the = path can support ECN-marked traffic.

"

 

[Qin]: = are you saying slow initiation procedure may result in network = congestion?
In my understanding, when ECN-CE marked packet is = received, the only choice for sender
is to do congestion control = since you are not sure if initiation procedure lead to = such
congestion. If it is not intiation procedure that lead to = congestion, you get risk to worse
congestion condition? =

 

[Thomas] I = believe this does not only refer to initiation, but mainly to feedback = if congestion is encountered after the ECN media flow has been = established.

 

 

 

 

Regards!

-Qin

 

----- Original Message = -----

Sent: Friday, = September 30, 2011 8:29 PM

Subject: [AVTCORE] = WGLC on = draft-ietf-avtcore-ecn-for-rtp-04

 

Hi,

I would =
like to start a WGLC on htt=
p://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , =
Explicit =
Congestion Notification (ECN) for RTP over =
UDP.
 =

The WGLC will = end on October 21, 2011

 

Please review the draft and send comments to the = list.

 

 

Roni Even

 

 =

 

_______________________________________________
Audio/= Video Transport Core = Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt<= o:p>

------_=_NextPart_001_01CC8828.6EA9F332-- From jan.lindquist@ericsson.com Tue Oct 11 11:11:56 2011 Return-Path: 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 6541421F8E3A for ; Tue, 11 Oct 2011 11:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 dl3UdUvx2e5e for ; Tue, 11 Oct 2011 11:11:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 957A621F8E26 for ; Tue, 11 Oct 2011 11:11:54 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-3a-4e9486e9f41c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 90.B6.20773.9E6849E4; Tue, 11 Oct 2011 20:11:53 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([153.88.115.182]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 11 Oct 2011 20:11:53 +0200 From: Jan Lindquist To: "Schwarz, Albrecht (Albrecht)" Date: Tue, 11 Oct 2011 20:11:53 +0200 Thread-Topic: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt Thread-Index: AcyIDj/Z56crtq+JRdWkhWTYf6ciqgAAVC5QAAxsKdM= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:11:56 -0000 When i wrote mac address i meant uuid. I thought they are close in nature a= nd 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)" To: Qin Wu , "avt@ietf.org" Sent: 2011/10/11 14:17 Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rt= p-07.txt Please note that there's also a definition of middlebox in draft-ietf-avtco= re-ecn-for-rtp, which might be also applicable. -Albrecht > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Qin Wu > Sent: Dienstag, 11. Oktober 2011 14:06 > To: Schwarz, Albrecht (Albrecht); Colin Perkins; avt@ietf.org > 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)" > > To: "Qin Wu" ; "Colin Perkins" > ; > 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) =3D MIDCOM-compliant middlebox (and then a reference to > definition =A7 2.2/RFC 3303 could be added) > b) =3D 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" > > To: > > 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 > > =3D > _______________________________________________ > 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 From kevin.gross@avanw.com Tue Oct 11 14:36:09 2011 Return-Path: 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 AD6FE21F8DD3 for ; Tue, 11 Oct 2011 14:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 7nc+kjgL5Vcc for ; Tue, 11 Oct 2011 14:36:08 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 4501821F8C9E for ; Tue, 11 Oct 2011 14:36:08 -0700 (PDT) Received: (qmail 18044 invoked by uid 0); 11 Oct 2011 21:36:06 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy8.bluehost.com with SMTP; 11 Oct 2011 21:36:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=cu5ty/p6qW4VYROVcp7GOLR4tGXcwGPiCWzzr3gIbA8=; b=U37QUZ43ALJVxUJEsxfvuHzSEl1ZFqCkCjcWPKT9+ZgTz0lS9s8L8Q03RsS9wBqRMD0b5xegmTgbKaA1mNxDFXWXI2YRiwkyXWnVk8UMBtBi5RCBXEy5qEvwys01s2sx; Received: from mail-dy0-f44.google.com ([209.85.220.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RDjza-0003Ql-88 for avt@ietf.org; Tue, 11 Oct 2011 15:36:06 -0600 Received: by dye36 with SMTP id 36so5230dye.31 for ; Tue, 11 Oct 2011 14:36:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.15.10 with SMTP id i10mr41893296faa.17.1318368964584; Tue, 11 Oct 2011 14:36:04 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Tue, 11 Oct 2011 14:36:04 -0700 (PDT) In-Reply-To: <4E941250.2080500@dcom.upv.es> References: <4E941250.2080500@dcom.upv.es> Date: Tue, 11 Oct 2011 15:36:04 -0600 Message-ID: From: Kevin Gross To: fboronat@dcom.upv.es Content-Type: multipart/alternative; boundary=001517448214d123c004af0cb1f2 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.220.44 authed with kevin.gross@avanw.com} Cc: avt@ietf.org Subject: Re: [AVTCORE] Possible Additional functionalities for draft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 21:36:09 -0000 --001517448214d123c004af0cb1f2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Welcome to the group. I've removed the cross-post to xrblock. We've been discussing IDMS in this group (AVTCORE a.k.a. AVT). Here are some initial comments: 1. The sender and the MSAS are not necessarily co-located. You want to measure propagation time from sender to SCs not from MSAS to SCs. 2. Propagation time is often a function of packet size. Measuring with small RTCP packets won't give you the same results as with larger packet= s containing media. 3. Since the sender and all receivers have an NTP time reference, it is possible to measure propagaion time directly. It is not necessary to mea= sure RTT and divide by two. 4. One way of achieving coarse sync without modification to the IDMS proposal is to just start streaming with null media data. Once the MSAS receives IDMS XR reports from all receivers and distributes sync informa= tion to receivers and the receivers have done whatever they need to do to get= in sync, the sender can be queued to start sending real data. --=20 Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org 2011/10/11 Fernando Boronat Segu=ED > Dear Group members, > > As this is our first mail to the list, we introduce ourselves. We are > Fernando Boronat and Mario Montagud, co-authors of the Internet Draft (I-= D) > =93RTCP for inter-destination media synchronization=94 > (draft-ietf-avtcore-idms-01.txt). > As the I-D was accepted as a WG document, any changes will have to be > approved by the AVTCORE group. So, we would like to know if you consider > appropriate to introduce some additional functionalities to the proposed > IDMS approach in the I-D. > > In many distributed applications it is required that all the receivers > start the playout of the media stream almost simultaneously (we refer thi= s > as Coarse Sync) and, after that, all of them play-out the media in a > synchronous way (we refer this as Fine Sync). Those processes are essenti= al > for acquiring IDMS. A Global Initial Playout Instant for all the > geographically distributed receivers (SCs) in a media session could preve= nt > from an initial playout time discrepancy (asynchrony) at the beginning of > the playout of the media stream/s (if a fixed global initial buffering de= lay > is set) mainly due to the variable network delays from the media server t= o > each one of the SCs. > > Thus, we are thinking about including a new section in the I-D about > possible packets for Coarse Sync for both the initial playout instant (at > the begining of a media session) and the initial instant at each stage in > which the session can be divided (we consider that a stage ends when no > streams are transmitted during a fixed interval (it could be defined > depending on the applications), and that the next stage starts when data = is > transmitted again). > > This technique has been considered in some previous IDMS works (see > reference [Boronat09] in the I-D), but using proprietary protocols. The > methods we propose here are based on the use of already defined and stand= ard > RTCP packets, which would avoid the introduction of proprietary closed > solutions. > > Regarding the Initial Playout Instant, we have primarily thought about th= e > use of already proposed RTCP XR packets (RFC 3611): > > 1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC 3611) for > measuring the delay between MSAS and SCs, allowing MSAS to estimate the R= TT > for all the SCs, then calculate a common initial playout instant and then > communicate it to all SCs by sending them an RTCP IDMS Packet (defined in > the I-D). The RTCP IDMS packet must include the RTP Timestamp of the firs= t > MU to be sent by the source and its proper playout instant, which will be > common for all of them. > MSAS may estimate its round trip time (RTT) to the SCs by sending them an > RTCP XR with the Receiver Reference Time Report Block and forcing (accord= ing > to RFC 3611) them to reply by sending an RTCP XR with a DLRR Report Block= . > Notice that both XR blocks are defined in RFC 3611 to be used in the > opposite way we propose. > > If this solution is not considered appropriate we could think about anoth= er > solution based on the packets already defined in the I-D, but maybe we wo= uld > need to change the format adding new field/s. > > 2. Once joined the session, if it is not started yet, all the SCs could > start sending RTCP XR with IDMS block (until they receive the Initial > Playout Instant indication, sent using the RTCP IDMS Packet) as it is > defined in the I-D, but including only the essential timing information > (e.g. the wallclock time at which the packet is sent by the SC) to let th= e > MSAS estimate the one-way network delays (not round-trip as in the previo= us > case) for each SC (assuming symmetric delays as in TCP) and calculate the > Initial Playout Instant. For that purpose, some field of the RTCP XR IDMS > block should be used to indicate the XR IDMS block is carrying out tempor= al > information for Coarse Sync, and not for reporting about arrival/playout > timing of a specific RTP packet. > From the Initial Instant they will continue playing the streams and sendi= ng > the RTCP XR with IDMS complete block (as currently defined in the I-D). I= t > could be a possible solution. > > The process of the calculation of the optimum Initial Playout Instant mus= t > take into consideration some factors such as the maximum and minimum > estimated delays, jitter values, expected duration of the session, or > probable clock deviations, in order to allow enough buffered MUs to start > the playout and to maintain it continuously, thus avoiding > underflow/overflow situations (playout discontinuities), during the sessi= on. > This process is out of the scope of the ID. > > With the introduction of the Coarse Sync functionality, the IDMS proposal > can counteract the effect of the delay variability at the beginning of th= e > playout of the media stream/s in each one of the stages in which a media > session can be divided. > > We prefer the first method because there is no need to define new IDMS > control messages (or to include some fields to already defined packets), = but > the use of already defined RTCP reports (RFC 3611) can be adapted for tha= t > purpose. > > Moreover, with the use of the first method, SCs do not have to send contr= ol > messages once they join the session, which may possibly result on > inefficient control traffic overhead. They will only have to send RTCP XR > DLRR messages in response to a new incoming RTRR message from the source, > which is who really knows the initial transmission time for the RTP media > stream. Moreover, the Initial Playout Instant can be sent to the receiver= s > by using the RTCP IDMS packet, already introduced in the I-D. > > Feedback will be much appreciated. > > Regards > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dr. Fernando Boronat Segu=ED > IEEE Senior Member > Profesor Titular / Lecturer=09 > Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 > Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) > UNIVERSIDAD POLIT=C9CNICA DE VALENCIA-CAMPUS DE GANDIA > Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > --001517448214d123c004af0cb1f2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Welcome to the group. I've removed the=A0cross-post to=A0xrblock. We= 9;ve been discussing IDMS in this group (AVTCORE a.k.a. AVT). Here are some= initial comments:
  1. The sender and the MSAS are not necessarily = co-located. You want to measure propagation time from sender to SCs not fro= m MSAS to SCs.
  2. Propagation time is often a function of packet size. Measuring with sma= ll RTCP packets won't give you the same results as with larger packets = containing media.
  3. Since the sender and all receivers have an NTP ti= me reference, it is possible to measure propagaion time directly. It is not= necessary to measure RTT and divide by two.
  4. One way of=A0achieving=A0coarse sync without modification to the IDMS p= roposal is to just start streaming with null media data. Once the MSAS rece= ives IDMS XR=A0reports=A0from all receivers and distributes sync informatio= n to receivers and the receivers have done whatever they need to do to get = in sync, the sender can be queued to start sending real data.
--=A0
Kevin Gross
+1-303-447-0517
Med= ia Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


2011/10/11 F= ernando Boronat Segu=ED <fboronat@dcom.upv.es>
=20 =20 =20
Dear Group members,

As this is our first mail to the list, we introduce ourselves. We are Fernando Boronat and Mario Montagud, co-authors of the Internet Draft (I-D) =93RTCP for inter-destination media synchronization=94 (draft-ietf-avtcore-idms-01.txt).
As the I-D was accepted as a WG document, any changes will have to be approved by the AVTCORE group. So, we would like to know if you consider appropriate to introduce some additional functionalities to the proposed IDMS approach in the I-D.

In many distributed applications it is required that all the receivers start the playout of the media stream almost simultaneously (we refer this as Coarse Sync) and, after that, all of them play-out the media in a synchronous way (we refer this as Fine Sync). Those processes are essential for acquiring IDMS. A Global Initial Playout Instant for all the geographically distributed receivers (SCs) in a media session could prevent from an initial playout time discrepancy (asynchrony) at the beginning of the playout of the media stream/s (if a fixed global initial buffering delay is set) mainly due to the variable network delays from the media server to each one of the SCs.

Thus, we are thinking about including a new section in the I-D about possible packets for Coarse Sync for both the initial playout instant (at the begining of a media session) and the initial instant at each stage in which the session can be divided (we consider that a stage ends when no streams are transmitted during a fixed interval (it could be defined depending on the applications), and that the next stage starts when data is transmitted again).

This technique has been considered in some previous IDMS works (see reference [Boronat09] in the I-D), but using proprietary protocols. The methods we propose here are based on the use of already defined and standard RTCP packets, which would avoid the introduction of proprietary closed solutions.

Regarding the Initial Playout Instant, we have primarily thought about the use of already proposed RTCP XR packets (RFC 3611):

1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC 3611) for measuring the delay between MSAS and SCs, allowing MSAS to estimate the RTT for all the SCs, then calculate a common initial playout instant and then communicate it to all SCs by sending them an RTCP IDMS Packet (defined in the I-D). The RTCP IDMS packet must include the RTP Timestamp of the first MU to be sent by the source and its proper playout instant, which will be common for all of them.
MSAS may estimate its round trip time (RTT) to the SCs by sending them an RTCP XR with the Receiver Reference Time Report Block and forcing (according to RFC 3611) them to reply by sending an RTCP XR with a DLRR Report Block. Notice that both XR blocks are defined in RFC 3611 to be used in the opposite way we propose.

If this solution is not considered appropriate we could think about another solution based on the packets already defined in the I-D, but maybe we would need to change the format adding new field/s.

2. Once joined the session, if it is not started yet, all the SCs could start sending RTCP XR with IDMS block (until they receive the Initial Playout Instant indication, sent using the RTCP IDMS Packet) as it is defined in the I-D, but including only the essential timing information (e.g. the wallclock time at which the packet is sent by the SC) to let the MSAS estimate the one-way network delays (not round-trip as in the previous case) for each SC (assuming symmetric delays as in TCP) and calculate the Initial Playout Instant. For that purpose, some field of the RTCP XR IDMS block should be used to indicate the XR IDMS block is carrying out temporal information for Coarse Sync, and not for reporting about arrival/playout timing of a specific RTP packet.
From the Initial Instant they will continue playing the streams and sending the RTCP XR with IDMS complete block (as currently defined in the I-D). It could be a possible solution.

The process of the calculation of the optimum Initial Playout Instant must take into consideration some factors such as the maximum and minimum estimated delays, jitter values, expected duration of the session, or probable clock deviations, in order to allow enough buffered MUs to start the playout and to maintain it continuously, thus avoiding underflow/overflow situations (playout discontinuities), during the session. This process is out of the scope of the ID.

With the introduction of the Coarse Sync functionality, the IDMS proposal can counteract the effect of the delay variability at the beginning of the playout of the media stream/s in each one of the stages in which a media session can be divided.

We prefer the first method because there is no need to define new IDMS control messages (or to include some fields to already defined packets), but the use of already defined RTCP reports (RFC 3611) can be adapted for that purpose.

Moreover, with the use of the first method, SCs do not have to send control messages once they join the session, which may possibly result on inefficient control traffic overhead. They will only have to send RTCP XR DLRR messages in response to a new incoming RTRR message from the source, which is who really knows the initial transmission time for the RTP media stream. Moreover, the Initial Playout Instant can be sent to the receivers by using the RTCP IDMS packet, already introduced in the I-D.

Feedback will be much appreciated.
Regards
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr. Fernando Boronat Segu=ED
IEEE Senior Member
Profesor Titular / Lecturer=09
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLIT=C9CNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt


--001517448214d123c004af0cb1f2-- From bill.wu@huawei.com Tue Oct 11 22:54:14 2011 Return-Path: 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 1554921F8C28; Tue, 11 Oct 2011 22:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.057 X-Spam-Level: X-Spam-Status: No, score=-4.057 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, MIME_BASE64_TEXT=1.753, 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 tWIoyUEK4k3R; Tue, 11 Oct 2011 22:54:12 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2B23721F8C37; Tue, 11 Oct 2011 22:54:12 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSX001ERV2BSL@szxga03-in.huawei.com>; Wed, 12 Oct 2011 13:54:11 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSX00LQAV2B5C@szxga03-in.huawei.com>; Wed, 12 Oct 2011 13:54:11 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEE53359; Wed, 12 Oct 2011 13:54:10 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 13:54:05 +0800 Received: from w53375q (10.138.41.130) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 13:54:02 +0800 Date: Wed, 12 Oct 2011 13:54:02 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: fboronat@dcom.upv.es, avt@ietf.org, xrblock@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_gj17M8co2AeakgQq+vx4zg)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4E941250.2080500@dcom.upv.es> Subject: Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 05:54:14 -0000 --Boundary_(ID_gj17M8co2AeakgQq+vx4zg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGksDQpJZiB5b3Ugd2FudCBYUkJsb2NrIGZvbGtzIHRvIHByb3ZpZGUgZmVlZGJhY2ssIEkgdGhp bmsgeW91IHNob3VsZCBwb3N0ICB0byB4cmJsb2NrQGlldGYub3JnLiBJIGhhdmUgaGVscCB5b3Ug Zm9yd2FyZCB0byBYUkJsb2NrIGxpc3QgaW4gdGhpcyB0aHJlYWQuIA0KQWxzbyBJIGhhdmUgc29t ZSBxdWljayBjb21tZW50cyBiZWxvdy4NCg0KUmVnYXJkcyENCi1RaW4NCiAgLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogRmVybmFuZG8gQm9yb25hdCBTZWd17SANCiAgVG86 IGF2dEBpZXRmLm9yZyA7IHhyYmxvY2stcmVxdWVzdEBpZXRmLm9yZyANCiAgU2VudDogVHVlc2Rh eSwgT2N0b2JlciAxMSwgMjAxMSA1OjU0IFBNDQogIFN1YmplY3Q6IFtBVlRDT1JFXSBQb3NzaWJs ZSBBZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdGllcyBmb3JkcmFmdC1icmFuZGVuYnVyZy1hdnQtcnRj cC1mb3ItaWRtcw0KDQoNCiAgRGVhciBHcm91cCBtZW1iZXJzLA0KDQogIEFzIHRoaXMgaXMgb3Vy IGZpcnN0IG1haWwgdG8gdGhlIGxpc3QsIHdlIGludHJvZHVjZSBvdXJzZWx2ZXMuIFdlIGFyZSBG ZXJuYW5kbyBCb3JvbmF0IGFuZCBNYXJpbyBNb250YWd1ZCwgY28tYXV0aG9ycyBvZiB0aGUgSW50 ZXJuZXQgRHJhZnQgKEktRCkgIlJUQ1AgZm9yIGludGVyLWRlc3RpbmF0aW9uIG1lZGlhIHN5bmNo cm9uaXphdGlvbiIgKGRyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTAxLnR4dCkuDQogIEFzIHRoZSBJ LUQgd2FzIGFjY2VwdGVkIGFzIGEgV0cgZG9jdW1lbnQsIGFueSBjaGFuZ2VzIHdpbGwgaGF2ZSB0 byBiZSBhcHByb3ZlZCBieSB0aGUgQVZUQ09SRSBncm91cC4gU28sIHdlIHdvdWxkIGxpa2UgdG8g a25vdyBpZiB5b3UgY29uc2lkZXIgYXBwcm9wcmlhdGUgdG8gaW50cm9kdWNlIHNvbWUgYWRkaXRp b25hbCBmdW5jdGlvbmFsaXRpZXMgdG8gdGhlIHByb3Bvc2VkIElETVMgYXBwcm9hY2ggaW4gdGhl IEktRC4gDQoNCiAgSW4gbWFueSBkaXN0cmlidXRlZCBhcHBsaWNhdGlvbnMgaXQgaXMgcmVxdWly ZWQgdGhhdCBhbGwgdGhlIHJlY2VpdmVycyBzdGFydCB0aGUgcGxheW91dCBvZiB0aGUgbWVkaWEg c3RyZWFtIGFsbW9zdCBzaW11bHRhbmVvdXNseSAod2UgcmVmZXIgdGhpcyBhcyBDb2Fyc2UgU3lu YykgYW5kLCBhZnRlciB0aGF0LCBhbGwgb2YgdGhlbSBwbGF5LW91dCB0aGUgbWVkaWEgaW4gYSBz eW5jaHJvbm91cyB3YXkgKHdlIHJlZmVyIHRoaXMgYXMgRmluZSBTeW5jKS4gVGhvc2UgcHJvY2Vz c2VzIGFyZSBlc3NlbnRpYWwgZm9yIGFjcXVpcmluZyBJRE1TLiBBIEdsb2JhbCBJbml0aWFsIFBs YXlvdXQgSW5zdGFudCBmb3IgYWxsIHRoZSBnZW9ncmFwaGljYWxseSBkaXN0cmlidXRlZCByZWNl aXZlcnMgKFNDcykgaW4gYSBtZWRpYSBzZXNzaW9uIGNvdWxkIHByZXZlbnQgZnJvbSBhbiBpbml0 aWFsIHBsYXlvdXQgdGltZSBkaXNjcmVwYW5jeSAoYXN5bmNocm9ueSkgYXQgdGhlIGJlZ2lubmlu ZyBvZiB0aGUgcGxheW91dCBvZiB0aGUgbWVkaWEgc3RyZWFtL3MgKGlmIGEgZml4ZWQgZ2xvYmFs IGluaXRpYWwgYnVmZmVyaW5nIGRlbGF5IGlzIHNldCkgbWFpbmx5IGR1ZSB0byB0aGUgdmFyaWFi bGUgbmV0d29yayBkZWxheXMgZnJvbSB0aGUgbWVkaWEgc2VydmVyIHRvIGVhY2ggb25lIG9mIHRo ZSBTQ3MuDQoNCg0KICBUaHVzLCB3ZSBhcmUgdGhpbmtpbmcgYWJvdXQgaW5jbHVkaW5nIGEgbmV3 IHNlY3Rpb24gaW4gdGhlIEktRCBhYm91dCBwb3NzaWJsZSBwYWNrZXRzIGZvciBDb2Fyc2UgU3lu YyBmb3IgYm90aCB0aGUgaW5pdGlhbCBwbGF5b3V0IGluc3RhbnQgKGF0IHRoZSBiZWdpbmluZyBv ZiBhIG1lZGlhIHNlc3Npb24pIGFuZCB0aGUgaW5pdGlhbCBpbnN0YW50IGF0IGVhY2ggc3RhZ2Ug aW4gd2hpY2ggdGhlIHNlc3Npb24gY2FuIGJlIGRpdmlkZWQgKHdlIGNvbnNpZGVyIHRoYXQgYSBz dGFnZSBlbmRzIHdoZW4gbm8gc3RyZWFtcyBhcmUgdHJhbnNtaXR0ZWQgZHVyaW5nIGEgZml4ZWQg aW50ZXJ2YWwgKGl0IGNvdWxkIGJlIGRlZmluZWQgZGVwZW5kaW5nIG9uIHRoZSBhcHBsaWNhdGlv bnMpLCBhbmQgdGhhdCB0aGUgbmV4dCBzdGFnZSBzdGFydHMgd2hlbiBkYXRhIGlzIHRyYW5zbWl0 dGVkIGFnYWluKS4NCg0KICBbUWluXTpZb3VyIHByb3Bvc2FsIGxvb2tzIGxpa2UgdG8gbWUgaXMg dG8gYWRkIEZpbmUgU3luYyBmdW5jdGlvbmFsaXR5IHRvIElETVMgZHJhZnQgaW4gdGhlIG1pZGRs ZSBvZiBzZXNzaW9uLCBob3dldmVyIGl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGUgZXhhY3QgdXNl IGNhc2UgKGlzIGl0IHBlcmlvZGljYWwgcGxheW91dClhbmQgd2hhdCdzIHRoZSByZWFsIGRpZmZl cmVuY2UgYmV0d2VlbiBDb2Fyc2UgU3luYyBhbmQgRmluZSBTeW5jIGluIHRlcm1zIG9mIFJUQ1Ag c2lnbmFsaW5nPyBhcmUgeW91IHNheWluZyB0aGUgaW5pdGlhbCBhdCBlYWNoIHN0YWdlIGlzIGNh bGN1bGF0ZWQgbW9yZSBhY2N1cmF0ZSB0aGFuIGluaXRpYWwgcGxheW91dCBpbnN0YW50Pw0KDQog IFRoaXMgdGVjaG5pcXVlIGhhcyBiZWVuIGNvbnNpZGVyZWQgaW4gc29tZSBwcmV2aW91cyBJRE1T IHdvcmtzIChzZWUgcmVmZXJlbmNlIFtCb3JvbmF0MDldIGluIHRoZSBJLUQpLCBidXQgdXNpbmcg cHJvcHJpZXRhcnkgcHJvdG9jb2xzLiBUaGUgbWV0aG9kcyB3ZSBwcm9wb3NlIGhlcmUgYXJlIGJh c2VkIG9uIHRoZSB1c2Ugb2YgYWxyZWFkeSBkZWZpbmVkIGFuZCBzdGFuZGFyZCBSVENQIHBhY2tl dHMsIHdoaWNoIHdvdWxkIGF2b2lkIHRoZSBpbnRyb2R1Y3Rpb24gb2YgcHJvcHJpZXRhcnkgY2xv c2VkIHNvbHV0aW9ucy4NCg0KICBSZWdhcmRpbmcgdGhlIEluaXRpYWwgUGxheW91dCBJbnN0YW50 LCB3ZSBoYXZlIHByaW1hcmlseSB0aG91Z2h0IGFib3V0IHRoZSB1c2Ugb2YgYWxyZWFkeSBwcm9w b3NlZCBSVENQIFhSIHBhY2tldHMgKFJGQyAzNjExKToNCg0KICAxLiBVc2Ugb2YgUlRDUCBYUiB3 aXRoIFJSVFIgYW5kIERMUlIgcmVwb3J0IGJsb2NrcyAoZGVmaW5lZCBSRkMgMzYxMSkgZm9yIG1l YXN1cmluZyB0aGUgZGVsYXkgYmV0d2VlbiBNU0FTIGFuZCBTQ3MsIGFsbG93aW5nIE1TQVMgdG8g ZXN0aW1hdGUgdGhlIFJUVCBmb3IgYWxsIHRoZSBTQ3MsIHRoZW4gY2FsY3VsYXRlIGEgY29tbW9u IGluaXRpYWwgcGxheW91dCBpbnN0YW50IGFuZCB0aGVuIGNvbW11bmljYXRlIGl0IHRvIGFsbCBT Q3MgYnkgc2VuZGluZyB0aGVtIGFuIFJUQ1AgSURNUyBQYWNrZXQgKGRlZmluZWQgaW4gdGhlIEkt RCkuIFRoZSBSVENQIElETVMgcGFja2V0IG11c3QgaW5jbHVkZSB0aGUgUlRQIFRpbWVzdGFtcCBv ZiB0aGUgZmlyc3QgTVUgdG8gYmUgc2VudCBieSB0aGUgc291cmNlIGFuZCBpdHMgcHJvcGVyIHBs YXlvdXQgaW5zdGFudCwgd2hpY2ggd2lsbCBiZSBjb21tb24gZm9yIGFsbCBvZiB0aGVtLg0KICBN U0FTIG1heSBlc3RpbWF0ZSBpdHMgcm91bmQgdHJpcCB0aW1lIChSVFQpIHRvIHRoZSBTQ3MgYnkg c2VuZGluZyB0aGVtIGFuIFJUQ1AgWFIgd2l0aCB0aGUgUmVjZWl2ZXIgUmVmZXJlbmNlIFRpbWUg UmVwb3J0IEJsb2NrIGFuZCBmb3JjaW5nIChhY2NvcmRpbmcgdG8gUkZDIDM2MTEpIHRoZW0gdG8g cmVwbHkgYnkgc2VuZGluZyBhbiBSVENQIFhSIHdpdGggYSBETFJSIFJlcG9ydCBCbG9jay4gTm90 aWNlIHRoYXQgYm90aCBYUiBibG9ja3MgYXJlIGRlZmluZWQgaW4gUkZDIDM2MTEgdG8gYmUgdXNl ZCBpbiB0aGUgb3Bwb3NpdGUgd2F5IHdlIHByb3Bvc2UuDQoNCiAgW1Fpbl06IFdoeSBub3QgdXNl IHJvdW5kIHRyaXAgdGltZSBjb21wdXRhdGlvbiBtZXRob2QgZGVmaW5lZCBpbiB0aGUgZmlndXJl IDIgb2YgUkZDMzU1MCwgYXJlIHlvdSBzYXlpbmcgaXQgaXMgbm90IGFsbG93ZWQgdG8gdXNlIFNS L1JSIHJlcG9ydHMgaW4gSURNUyBjYXNlLg0KDQogIElmIHRoaXMgc29sdXRpb24gaXMgbm90IGNv bnNpZGVyZWQgYXBwcm9wcmlhdGUgd2UgY291bGQgdGhpbmsgYWJvdXQgYW5vdGhlciBzb2x1dGlv biBiYXNlZCBvbiB0aGUgcGFja2V0cyBhbHJlYWR5IGRlZmluZWQgaW4gdGhlIEktRCwgYnV0IG1h eWJlIHdlIHdvdWxkIG5lZWQgdG8gY2hhbmdlIHRoZSBmb3JtYXQgYWRkaW5nIG5ldyBmaWVsZC9z Lg0KDQogIDIuIE9uY2Ugam9pbmVkIHRoZSBzZXNzaW9uLCBpZiBpdCBpcyBub3Qgc3RhcnRlZCB5 ZXQsIGFsbCB0aGUgU0NzIGNvdWxkIHN0YXJ0IHNlbmRpbmcgUlRDUCBYUiB3aXRoIElETVMgYmxv Y2sgKHVudGlsIHRoZXkgcmVjZWl2ZSB0aGUgSW5pdGlhbCBQbGF5b3V0IEluc3RhbnQgaW5kaWNh dGlvbiwgc2VudCB1c2luZyB0aGUgUlRDUCBJRE1TIFBhY2tldCkgYXMgaXQgaXMgZGVmaW5lZCBp biB0aGUgSS1ELCBidXQgaW5jbHVkaW5nIG9ubHkgdGhlIGVzc2VudGlhbCB0aW1pbmcgaW5mb3Jt YXRpb24gKGUuZy4gdGhlIHdhbGxjbG9jayB0aW1lIGF0IHdoaWNoIHRoZSBwYWNrZXQgaXMgc2Vu dCBieSB0aGUgU0MpIHRvIGxldCB0aGUgTVNBUyBlc3RpbWF0ZSB0aGUgb25lLXdheSBuZXR3b3Jr IGRlbGF5cyAobm90IHJvdW5kLXRyaXAgYXMgaW4gdGhlIHByZXZpb3VzIGNhc2UpIGZvciBlYWNo IFNDIChhc3N1bWluZyBzeW1tZXRyaWMgZGVsYXlzIGFzIGluIFRDUCkgYW5kIGNhbGN1bGF0ZSB0 aGUgSW5pdGlhbCBQbGF5b3V0IEluc3RhbnQuIEZvciB0aGF0IHB1cnBvc2UsIHNvbWUgZmllbGQg b2YgdGhlIFJUQ1AgWFIgSURNUyBibG9jayBzaG91bGQgYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGUg WFIgSURNUyBibG9jayBpcyBjYXJyeWluZyBvdXQgdGVtcG9yYWwgaW5mb3JtYXRpb24gZm9yIENv YXJzZSBTeW5jLCBhbmQgbm90IGZvciByZXBvcnRpbmcgYWJvdXQgYXJyaXZhbC9wbGF5b3V0IHRp bWluZyBvZiBhIHNwZWNpZmljIFJUUCBwYWNrZXQuDQogIEZyb20gdGhlIEluaXRpYWwgSW5zdGFu dCB0aGV5IHdpbGwgY29udGludWUgcGxheWluZyB0aGUgc3RyZWFtcyBhbmQgc2VuZGluZyB0aGUg UlRDUCBYUiB3aXRoIElETVMgY29tcGxldGUgYmxvY2sgKGFzIGN1cnJlbnRseSBkZWZpbmVkIGlu IHRoZSBJLUQpLiBJdCBjb3VsZCBiZSBhIHBvc3NpYmxlIHNvbHV0aW9uLg0KDQogIFtRaW5dOiBZ b3UgY2FuIHVzZSBEZWxheSBtZXRyaWMgcmVwb3J0IGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1hdnQt cnRjcC14ci1kZWxheS0wMiB0byBkaXJlY3RseSBnZXQgb25lLXdheSBuZXR3b3JrIGRlbGF5cy4g QWxzbyBtYXhpbXVtIGFuZCBtaW5pbXVtIG5ldHdvcmsgZGVsYXlzIGNhbiBiZSBvYnRhaW5lZCBm cm9tIHRoaXMgWFIgcmVwb3J0Lg0KDQogIFRoZSBwcm9jZXNzIG9mIHRoZSBjYWxjdWxhdGlvbiBv ZiB0aGUgb3B0aW11bSBJbml0aWFsIFBsYXlvdXQgSW5zdGFudCBtdXN0IHRha2UgaW50byBjb25z aWRlcmF0aW9uIHNvbWUgZmFjdG9ycyBzdWNoIGFzIHRoZSBtYXhpbXVtIGFuZCBtaW5pbXVtIGVz dGltYXRlZCBkZWxheXMsIGppdHRlciB2YWx1ZXMsIGV4cGVjdGVkIGR1cmF0aW9uIG9mIHRoZSBz ZXNzaW9uLCBvciBwcm9iYWJsZSBjbG9jayBkZXZpYXRpb25zLCBpbiBvcmRlciB0byBhbGxvdyBl bm91Z2ggYnVmZmVyZWQgTVVzIHRvIHN0YXJ0IHRoZSBwbGF5b3V0IGFuZCB0byBtYWludGFpbiBp dCBjb250aW51b3VzbHksIHRodXMgYXZvaWRpbmcgdW5kZXJmbG93L292ZXJmbG93IHNpdHVhdGlv bnMgKHBsYXlvdXQgZGlzY29udGludWl0aWVzKSwgZHVyaW5nIHRoZSBzZXNzaW9uLiBUaGlzIHBy b2Nlc3MgaXMgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGUgSUQuDQoNCiAgW1Fpbl0gSSB0aGluayB5 b3UgY2FuIHJlbHkgb24gZHJhZnQtaWV0Zi1hdnQtcnRjcC14ci1tZWFzLWlkZW50aXR5IHRvIGtu b3cgZXhwZWN0ZWQgZHVyYXRpb24gb2YgdGhlIHNlc3Npb24uDQogIHlvdSBtYXkgcmVseSBvbiBk cmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1wZHYtMDAgdG8gZ2V0IGppdHRlciB2YWx1ZXMuDQog IEJ1dCBYUkJMb2NrIGlzIG5vdCB0aGUgcmlnaHQgcGxhY2UgdG8gc2VlayBmb3IgdGhlIG1lYXN1 cmVtZW50IG1ldGhvZCwgd2hpY2ggaXMgZGVmaW5lZCBzb21ld2hlcmUgZWxzZSwgZS5nLiwgaW4g b3RoZXIgUkZDIGxpa2UgUkZDMzU1MCwgb3RoZXIgV0dzLCBvciBvdGhlciBTRE9zLg0KDQogIFdp dGggdGhlIGludHJvZHVjdGlvbiBvZiB0aGUgQ29hcnNlIFN5bmMgZnVuY3Rpb25hbGl0eSwgdGhl IElETVMgcHJvcG9zYWwgY2FuIGNvdW50ZXJhY3QgdGhlIGVmZmVjdCBvZiB0aGUgZGVsYXkgdmFy aWFiaWxpdHkgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgcGxheW91dCBvZiB0aGUgbWVkaWEgc3Ry ZWFtL3MgaW4gZWFjaCBvbmUgb2YgdGhlIHN0YWdlcyBpbiB3aGljaCBhIG1lZGlhIHNlc3Npb24g Y2FuIGJlIGRpdmlkZWQuDQoNCiAgV2UgcHJlZmVyIHRoZSBmaXJzdCBtZXRob2QgYmVjYXVzZSB0 aGVyZSBpcyBubyBuZWVkIHRvIGRlZmluZSBuZXcgSURNUyBjb250cm9sIG1lc3NhZ2VzIChvciB0 byBpbmNsdWRlIHNvbWUgZmllbGRzIHRvIGFscmVhZHkgZGVmaW5lZCBwYWNrZXRzKSwgYnV0IHRo ZSB1c2Ugb2YgYWxyZWFkeSBkZWZpbmVkIFJUQ1AgcmVwb3J0cyAoUkZDIDM2MTEpIGNhbiBiZSBh ZGFwdGVkIGZvciB0aGF0IHB1cnBvc2UuIA0KDQogIE1vcmVvdmVyLCB3aXRoIHRoZSB1c2Ugb2Yg dGhlIGZpcnN0IG1ldGhvZCwgU0NzIGRvIG5vdCBoYXZlIHRvIHNlbmQgY29udHJvbCBtZXNzYWdl cyBvbmNlIHRoZXkgam9pbiB0aGUgc2Vzc2lvbiwgd2hpY2ggbWF5IHBvc3NpYmx5IHJlc3VsdCBv biBpbmVmZmljaWVudCBjb250cm9sIHRyYWZmaWMgb3ZlcmhlYWQuIFRoZXkgd2lsbCBvbmx5IGhh dmUgdG8gc2VuZCBSVENQIFhSIERMUlIgbWVzc2FnZXMgaW4gcmVzcG9uc2UgdG8gYSBuZXcgaW5j b21pbmcgUlRSUiBtZXNzYWdlIGZyb20gdGhlIHNvdXJjZSwgd2hpY2ggaXMgd2hvIHJlYWxseSBr bm93cyB0aGUgaW5pdGlhbCB0cmFuc21pc3Npb24gdGltZSBmb3IgdGhlIFJUUCBtZWRpYSBzdHJl YW0uIE1vcmVvdmVyLCB0aGUgSW5pdGlhbCBQbGF5b3V0IEluc3RhbnQgY2FuIGJlIHNlbnQgdG8g dGhlIHJlY2VpdmVycyBieSB1c2luZyB0aGUgUlRDUCBJRE1TIHBhY2tldCwgYWxyZWFkeSBpbnRy b2R1Y2VkIGluIHRoZSBJLUQuDQoNCiAgRmVlZGJhY2sgd2lsbCBiZSBtdWNoIGFwcHJlY2lhdGVk Lg0KDQpSZWdhcmRzDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkRyLiBGZXJuYW5kbyBCb3JvbmF0IFNlZ3Xt DQpJRUVFIFNlbmlvciBNZW1iZXINClByb2Zlc29yIFRpdHVsYXIgLyBMZWN0dXJlcgkNCkRlcHQu IENvbXVuaWNhY2lvbmVzICAgICAgICAgICBUbGYuLSszNCs5NjIgODQ5IDMwMCBFeHQuLTQ5MzQx DQpUbGYuIGRpcmVjdG8gLSszNCs5NjIgODQ5IDM0MSAgRmF4Li0rMzQrOTYyIDg0OSAzMDkgKENv bXBhcnRpZG8pDQpVTklWRVJTSURBRCBQT0xJVMlDTklDQSBERSBWQUxFTkNJQS1DQU1QVVMgREUg R0FORElBDQpDYWxsZSBQYXJhcmFuaW5mbywgMSwgQ1AuIDQ2NzMwLCBHcmFvIGRlIEdhbmRpYSAo VmFsZW5jaWEpLCBTUEFJTg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCiAgYXZ0QGlldGYub3Jn DQogIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo= --Boundary_(ID_gj17M8co2AeakgQq+vx4zg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTEyMCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZiB0ZXh0PSMwMDAwMDA+DQo8RElWPkhpLDwvRElWPg0K PERJVj5JZiB5b3Ugd2FudCBYUkJsb2NrIGZvbGtzIHRvIHByb3ZpZGUgZmVlZGJhY2ssIEkgdGhp bmsgeW91IHNob3VsZCANCnBvc3QmbmJzcDsgdG8gPEEgaHJlZj0ibWFpbHRvOnhyYmxvY2tAaWV0 Zi5vcmciPnhyYmxvY2tAaWV0Zi5vcmc8L0E+LiBJIGhhdmUgDQpoZWxwIHlvdSBmb3J3YXJkJm5i c3A7dG8gWFJCbG9jayBsaXN0Jm5ic3A7aW4gdGhpcyB0aHJlYWQuJm5ic3A7PC9ESVY+DQo8RElW PkFsc28gSSBoYXZlIHNvbWUgcXVpY2sgY29tbWVudHMgYmVsb3cuPC9ESVY+DQo8RElWPjxGT05U IHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj5S ZWdhcmRzITwvRElWPg0KPERJVj4tUWluPC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJCT1JE RVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4OyBQQURESU5HLVJJ R0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBz dHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBC QUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8 QSB0aXRsZT1mYm9yb25hdEBkY29tLnVwdi5lcyBocmVmPSJtYWlsdG86ZmJvcm9uYXRAZGNvbS51 cHYuZXMiPkZlcm5hbmRvIA0KICBCb3JvbmF0IFNlZ3XtPC9BPiA8L0RJVj4NCiAgPERJViBzdHls ZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9YXZ0QGll dGYub3JnIA0KICBocmVmPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5vcmc8L0E+IDsg PEEgDQogIHRpdGxlPXhyYmxvY2stcmVxdWVzdEBpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOnhy YmxvY2stcmVxdWVzdEBpZXRmLm9yZyI+eHJibG9jay1yZXF1ZXN0QGlldGYub3JnPC9BPiA8L0RJ Vj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9C PiBUdWVzZGF5LCBPY3RvYmVyIDExLCAyMDExIDU6NTQgUE08L0RJVj4NCiAgPERJViBzdHlsZT0i Rk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBbQVZUQ09SRV0gUG9z c2libGUgQWRkaXRpb25hbCANCiAgZnVuY3Rpb25hbGl0aWVzIGZvcmRyYWZ0LWJyYW5kZW5idXJn LWF2dC1ydGNwLWZvci1pZG1zPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPkRlYXIg R3JvdXAgbWVtYmVycyw8QlI+PEJSPkFzIHRoaXMgaXMgb3VyIGZpcnN0IG1haWwgdG8gdGhlIGxp c3QsIHdlIA0KICBpbnRyb2R1Y2Ugb3Vyc2VsdmVzLiBXZSBhcmUgRmVybmFuZG8gQm9yb25hdCBh bmQgTWFyaW8gTW9udGFndWQsIGNvLWF1dGhvcnMgb2YgDQogIHRoZSBJbnRlcm5ldCBEcmFmdCAo SS1EKSCTUlRDUCBmb3IgaW50ZXItZGVzdGluYXRpb24gbWVkaWEgc3luY2hyb25pemF0aW9ulCAN CiAgKGRyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTAxLnR4dCkuPEJSPkFzIHRoZSBJLUQgd2FzIGFj Y2VwdGVkIGFzIGEgV0cgZG9jdW1lbnQsIA0KICBhbnkgY2hhbmdlcyB3aWxsIGhhdmUgdG8gYmUg YXBwcm92ZWQgYnkgdGhlIEFWVENPUkUgZ3JvdXAuIFNvLCB3ZSB3b3VsZCBsaWtlIA0KICB0byBr bm93IGlmIHlvdSBjb25zaWRlciBhcHByb3ByaWF0ZSB0byBpbnRyb2R1Y2Ugc29tZSBhZGRpdGlv bmFsIA0KICBmdW5jdGlvbmFsaXRpZXMgdG8gdGhlIHByb3Bvc2VkIElETVMgYXBwcm9hY2ggaW4g dGhlIEktRC4gPEJSPjxCUj5JbiBtYW55IA0KICBkaXN0cmlidXRlZCBhcHBsaWNhdGlvbnMgaXQg aXMgcmVxdWlyZWQgdGhhdCBhbGwgdGhlIHJlY2VpdmVycyBzdGFydCB0aGUgDQogIHBsYXlvdXQg b2YgdGhlIG1lZGlhIHN0cmVhbSBhbG1vc3Qgc2ltdWx0YW5lb3VzbHkgKHdlIHJlZmVyIHRoaXMg YXMgQ29hcnNlIA0KICBTeW5jKSBhbmQsIGFmdGVyIHRoYXQsIGFsbCBvZiB0aGVtIHBsYXktb3V0 IHRoZSBtZWRpYSBpbiBhIHN5bmNocm9ub3VzIHdheSAod2UgDQogIHJlZmVyIHRoaXMgYXMgRmlu ZSBTeW5jKS4gVGhvc2UgcHJvY2Vzc2VzIGFyZSBlc3NlbnRpYWwgZm9yIGFjcXVpcmluZyBJRE1T LiBBIA0KICBHbG9iYWwgSW5pdGlhbCBQbGF5b3V0IEluc3RhbnQgZm9yIGFsbCB0aGUgZ2VvZ3Jh cGhpY2FsbHkgZGlzdHJpYnV0ZWQgDQogIHJlY2VpdmVycyAoU0NzKSBpbiBhIG1lZGlhIHNlc3Np b24gY291bGQgcHJldmVudCBmcm9tIGFuIGluaXRpYWwgcGxheW91dCB0aW1lIA0KICBkaXNjcmVw YW5jeSAoYXN5bmNocm9ueSkgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgcGxheW91dCBvZiB0aGUg bWVkaWEgc3RyZWFtL3MgDQogIChpZiBhIGZpeGVkIGdsb2JhbCBpbml0aWFsIGJ1ZmZlcmluZyBk ZWxheSBpcyBzZXQpIG1haW5seSBkdWUgdG8gdGhlIHZhcmlhYmxlIA0KICBuZXR3b3JrIGRlbGF5 cyBmcm9tIHRoZSBtZWRpYSBzZXJ2ZXIgdG8gZWFjaCBvbmUgb2YgdGhlIFNDcy48L0RJVj48L0JM T0NLUVVPVEU+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHgg c29saWQ7IFBBRERJTkctTEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZU OiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4Ij48Rk9OVCANCiAgc2l6ZT0yIGZhY2U9JiMyMzQzNTsm IzIwMzA3Oz48L0ZPTlQ+DQogIDxESVY+PEJSPjxCUj5UaHVzLCB3ZSBhcmUgdGhpbmtpbmcgYWJv dXQgaW5jbHVkaW5nIGEgbmV3IHNlY3Rpb24gaW4gdGhlIEktRCANCiAgYWJvdXQgcG9zc2libGUg cGFja2V0cyBmb3IgQ29hcnNlIFN5bmMgZm9yIGJvdGggdGhlIGluaXRpYWwgcGxheW91dCBpbnN0 YW50IA0KICAoYXQgdGhlIGJlZ2luaW5nIG9mIGEgbWVkaWEgc2Vzc2lvbikgYW5kIHRoZSBpbml0 aWFsIGluc3RhbnQgYXQgZWFjaCBzdGFnZSBpbiANCiAgd2hpY2ggdGhlIHNlc3Npb24gY2FuIGJl IGRpdmlkZWQgKHdlIGNvbnNpZGVyIHRoYXQgYSBzdGFnZSBlbmRzIHdoZW4gbm8gDQogIHN0cmVh bXMgYXJlIHRyYW5zbWl0dGVkIGR1cmluZyBhIGZpeGVkIGludGVydmFsIChpdCBjb3VsZCBiZSBk ZWZpbmVkIGRlcGVuZGluZyANCiAgb24gdGhlIGFwcGxpY2F0aW9ucyksIGFuZCB0aGF0IHRoZSBu ZXh0IHN0YWdlIHN0YXJ0cyB3aGVuIGRhdGEgaXMgdHJhbnNtaXR0ZWQgDQogIGFnYWluKS48L0RJ Vj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj4NCiAgPERJVj5bUWluXTpZb3VyIHByb3Bv c2FsIGxvb2tzIGxpa2UgdG8gbWUgaXMgdG8gYWRkIEZpbmUgU3luYyBmdW5jdGlvbmFsaXR5IHRv IA0KICBJRE1TIGRyYWZ0IGluIHRoZSBtaWRkbGUgb2Ygc2Vzc2lvbiwgaG93ZXZlciBpdCBpcyBu b3QgY2xlYXIgdG8gbWUgdGhlIGV4YWN0IA0KICB1c2UgY2FzZSAoaXMgaXQgcGVyaW9kaWNhbCBw bGF5b3V0KWFuZCB3aGF0J3MgdGhlIHJlYWwgZGlmZmVyZW5jZSBiZXR3ZWVuIA0KICBDb2Fyc2Ug U3luYyBhbmQgRmluZSBTeW5jIGluIHRlcm1zIG9mIFJUQ1Agc2lnbmFsaW5nPyBhcmUgeW91IHNh eWluZyB0aGUgDQogIGluaXRpYWwgYXQgZWFjaCBzdGFnZSZuYnNwO2lzIGNhbGN1bGF0ZWQgbW9y ZSBhY2N1cmF0ZSB0aGFuIGluaXRpYWwgcGxheW91dCANCiAgaW5zdGFudD88QlI+PEJSPlRoaXMg dGVjaG5pcXVlIGhhcyBiZWVuIGNvbnNpZGVyZWQgaW4gc29tZSBwcmV2aW91cyBJRE1TIHdvcmtz IA0KICAoc2VlIHJlZmVyZW5jZSBbQm9yb25hdDA5XSBpbiB0aGUgSS1EKSwgYnV0IHVzaW5nIHBy b3ByaWV0YXJ5IHByb3RvY29scy4gVGhlIA0KICBtZXRob2RzIHdlIHByb3Bvc2UgaGVyZSBhcmUg YmFzZWQgb24gdGhlIHVzZSBvZiBhbHJlYWR5IGRlZmluZWQgYW5kIHN0YW5kYXJkIA0KICBSVENQ IHBhY2tldHMsIHdoaWNoIHdvdWxkIGF2b2lkIHRoZSBpbnRyb2R1Y3Rpb24gb2YgcHJvcHJpZXRh cnkgY2xvc2VkIA0KICBzb2x1dGlvbnMuPEJSPjxCUj5SZWdhcmRpbmcgdGhlIEluaXRpYWwgUGxh eW91dCBJbnN0YW50LCB3ZSBoYXZlIHByaW1hcmlseSANCiAgdGhvdWdodCBhYm91dCB0aGUgdXNl IG9mIGFscmVhZHkgcHJvcG9zZWQgUlRDUCBYUiBwYWNrZXRzIChSRkMgDQogIDM2MTEpOjxCUj48 QlI+MS4gVXNlIG9mIFJUQ1AgWFIgd2l0aCBSUlRSIGFuZCBETFJSIHJlcG9ydCBibG9ja3MgKGRl ZmluZWQgUkZDIA0KICAzNjExKSBmb3IgbWVhc3VyaW5nIHRoZSBkZWxheSBiZXR3ZWVuIE1TQVMg YW5kIFNDcywgYWxsb3dpbmcgTVNBUyB0byBlc3RpbWF0ZSANCiAgdGhlIFJUVCBmb3IgYWxsIHRo ZSBTQ3MsIHRoZW4gY2FsY3VsYXRlIGEgY29tbW9uIGluaXRpYWwgcGxheW91dCBpbnN0YW50IGFu ZCANCiAgdGhlbiBjb21tdW5pY2F0ZSBpdCB0byBhbGwgU0NzIGJ5IHNlbmRpbmcgdGhlbSBhbiBS VENQIElETVMgUGFja2V0IChkZWZpbmVkIGluIA0KICB0aGUgSS1EKS4gVGhlIFJUQ1AgSURNUyBw YWNrZXQgbXVzdCBpbmNsdWRlIHRoZSBSVFAgVGltZXN0YW1wIG9mIHRoZSBmaXJzdCBNVSANCiAg dG8gYmUgc2VudCBieSB0aGUgc291cmNlIGFuZCBpdHMgcHJvcGVyIHBsYXlvdXQgaW5zdGFudCwg d2hpY2ggd2lsbCBiZSBjb21tb24gDQogIGZvciBhbGwgb2YgdGhlbS48QlI+TVNBUyBtYXkgZXN0 aW1hdGUgaXRzIHJvdW5kIHRyaXAgdGltZSAoUlRUKSB0byB0aGUgU0NzIGJ5IA0KICBzZW5kaW5n IHRoZW0gYW4gUlRDUCBYUiB3aXRoIHRoZSBSZWNlaXZlciBSZWZlcmVuY2UgVGltZSBSZXBvcnQg QmxvY2sgYW5kIA0KICBmb3JjaW5nIChhY2NvcmRpbmcgdG8gUkZDIDM2MTEpIHRoZW0gdG8gcmVw bHkgYnkgc2VuZGluZyBhbiBSVENQIFhSIHdpdGggYSANCiAgRExSUiBSZXBvcnQgQmxvY2suIE5v dGljZSB0aGF0IGJvdGggWFIgYmxvY2tzIGFyZSBkZWZpbmVkIGluIFJGQyAzNjExIHRvIGJlIA0K ICB1c2VkIGluIHRoZSBvcHBvc2l0ZSB3YXkgd2UgcHJvcG9zZS48L0RJVj4NCiAgPERJVj4mbmJz cDs8L0RJVj4NCiAgPERJVj5bUWluXTogV2h5IG5vdCB1c2Ugcm91bmQgdHJpcCB0aW1lIGNvbXB1 dGF0aW9uIG1ldGhvZCBkZWZpbmVkIGluIHRoZSANCiAgZmlndXJlIDIgb2YgUkZDMzU1MCwgYXJl IHlvdSBzYXlpbmcgaXQgaXMgbm90IGFsbG93ZWQgdG8gdXNlIFNSL1JSIHJlcG9ydHMgaW4gDQog IElETVMgY2FzZS48QlI+PEJSPklmIHRoaXMgc29sdXRpb24gaXMgbm90IGNvbnNpZGVyZWQgYXBw cm9wcmlhdGUgd2UgY291bGQgDQogIHRoaW5rIGFib3V0IGFub3RoZXIgc29sdXRpb24gYmFzZWQg b24gdGhlIHBhY2tldHMgYWxyZWFkeSBkZWZpbmVkIGluIHRoZSBJLUQsIA0KICBidXQgbWF5YmUg d2Ugd291bGQgbmVlZCB0byBjaGFuZ2UgdGhlIGZvcm1hdCBhZGRpbmcgbmV3IGZpZWxkL3MuPEJS PjxCUj4yLiANCiAgT25jZSBqb2luZWQgdGhlIHNlc3Npb24sIGlmIGl0IGlzIG5vdCBzdGFydGVk IHlldCwgYWxsIHRoZSBTQ3MgY291bGQgc3RhcnQgDQogIHNlbmRpbmcgUlRDUCBYUiB3aXRoIElE TVMgYmxvY2sgKHVudGlsIHRoZXkgcmVjZWl2ZSB0aGUgSW5pdGlhbCBQbGF5b3V0IA0KICBJbnN0 YW50IGluZGljYXRpb24sIHNlbnQgdXNpbmcgdGhlIFJUQ1AgSURNUyBQYWNrZXQpIGFzIGl0IGlz IGRlZmluZWQgaW4gdGhlIA0KICBJLUQsIGJ1dCBpbmNsdWRpbmcgb25seSB0aGUgZXNzZW50aWFs IHRpbWluZyBpbmZvcm1hdGlvbiAoZS5nLiB0aGUgd2FsbGNsb2NrIA0KICB0aW1lIGF0IHdoaWNo IHRoZSBwYWNrZXQgaXMgc2VudCBieSB0aGUgU0MpIHRvIGxldCB0aGUgTVNBUyBlc3RpbWF0ZSB0 aGUgDQogIG9uZS13YXkgbmV0d29yayBkZWxheXMgKG5vdCByb3VuZC10cmlwIGFzIGluIHRoZSBw cmV2aW91cyBjYXNlKSBmb3IgZWFjaCBTQyANCiAgKGFzc3VtaW5nIHN5bW1ldHJpYyBkZWxheXMg YXMgaW4gVENQKSBhbmQgY2FsY3VsYXRlIHRoZSBJbml0aWFsIFBsYXlvdXQgDQogIEluc3RhbnQu IEZvciB0aGF0IHB1cnBvc2UsIHNvbWUgZmllbGQgb2YgdGhlIFJUQ1AgWFIgSURNUyBibG9jayBz aG91bGQgYmUgdXNlZCANCiAgdG8gaW5kaWNhdGUgdGhlIFhSIElETVMgYmxvY2sgaXMgY2Fycnlp bmcgb3V0IHRlbXBvcmFsIGluZm9ybWF0aW9uIGZvciBDb2Fyc2UgDQogIFN5bmMsIGFuZCBub3Qg Zm9yIHJlcG9ydGluZyBhYm91dCBhcnJpdmFsL3BsYXlvdXQgdGltaW5nIG9mIGEgc3BlY2lmaWMg UlRQIA0KICBwYWNrZXQuPEJSPkZyb20gdGhlIEluaXRpYWwgSW5zdGFudCB0aGV5IHdpbGwgY29u dGludWUgcGxheWluZyB0aGUgc3RyZWFtcyBhbmQgDQogIHNlbmRpbmcgdGhlIFJUQ1AgWFIgd2l0 aCBJRE1TIGNvbXBsZXRlIGJsb2NrIChhcyBjdXJyZW50bHkgZGVmaW5lZCBpbiB0aGUgDQogIEkt RCkuIEl0IGNvdWxkIGJlIGEgcG9zc2libGUgc29sdXRpb24uPC9ESVY+DQogIDxESVY+Jm5ic3A7 PC9ESVY+DQogIDxESVY+W1Fpbl06IFlvdSBjYW4gdXNlIERlbGF5IG1ldHJpYyByZXBvcnQgZGVm aW5lZCBpbiANCiAgZHJhZnQtaWV0Zi1hdnQtcnRjcC14ci1kZWxheS0wMiB0byBkaXJlY3RseSZu YnNwO2dldCBvbmUtd2F5IG5ldHdvcmsgZGVsYXlzLiANCiAgQWxzbyBtYXhpbXVtIGFuZCBtaW5p bXVtIG5ldHdvcmsgZGVsYXlzIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoaXMgWFIgDQogIHJlcG9y dC48QlI+PEJSPlRoZSBwcm9jZXNzIG9mIHRoZSBjYWxjdWxhdGlvbiBvZiB0aGUgb3B0aW11bSBJ bml0aWFsIFBsYXlvdXQgDQogIEluc3RhbnQgbXVzdCB0YWtlIGludG8gY29uc2lkZXJhdGlvbiBz b21lIGZhY3RvcnMgc3VjaCBhcyB0aGUgbWF4aW11bSBhbmQgDQogIG1pbmltdW0gZXN0aW1hdGVk IGRlbGF5cywgaml0dGVyIHZhbHVlcywgZXhwZWN0ZWQgZHVyYXRpb24gb2YgdGhlIHNlc3Npb24s IG9yIA0KICBwcm9iYWJsZSBjbG9jayBkZXZpYXRpb25zLCBpbiBvcmRlciB0byBhbGxvdyBlbm91 Z2ggYnVmZmVyZWQgTVVzIHRvIHN0YXJ0IHRoZSANCiAgcGxheW91dCBhbmQgdG8gbWFpbnRhaW4g aXQgY29udGludW91c2x5LCB0aHVzIGF2b2lkaW5nIHVuZGVyZmxvdy9vdmVyZmxvdyANCiAgc2l0 dWF0aW9ucyAocGxheW91dCBkaXNjb250aW51aXRpZXMpLCBkdXJpbmcgdGhlIHNlc3Npb24uIFRo aXMgcHJvY2VzcyBpcyBvdXQgDQogIG9mIHRoZSBzY29wZSBvZiB0aGUgSUQuPC9ESVY+DQogIDxE SVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQogIDxESVY+W1Fpbl0gSSB0aGluayB5b3UgY2FuIHJlbHkgb24gZHJhZnQtaWV0Zi1hdnQtcnRj cC14ci1tZWFzLWlkZW50aXR5IHRvIA0KICBrbm93IGV4cGVjdGVkIGR1cmF0aW9uIG9mIHRoZSBz ZXNzaW9uLjwvRElWPg0KICA8RElWPnlvdSBtYXkgcmVseSBvbiBkcmFmdC1pZXRmLXhyYmxvY2st cnRjcC14ci1wZHYtMDAgdG8gZ2V0IGppdHRlciANCiAgdmFsdWVzLjwvRElWPg0KICA8RElWPkJ1 dCBYUkJMb2NrIGlzIG5vdCB0aGUgcmlnaHQgcGxhY2UgdG8mbmJzcDtzZWVrIGZvciZuYnNwO3Ro ZSBtZWFzdXJlbWVudCANCiAgbWV0aG9kLCB3aGljaCBpcyBkZWZpbmVkIHNvbWV3aGVyZSBlbHNl LCBlLmcuLCBpbiBvdGhlciBSRkMgbGlrZSBSRkMzNTUwLCANCiAgb3RoZXIgV0dzLCBvciBvdGhl ciBTRE9zLjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+ PC9GT05UPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPjxGT05UIHNp emU9MiANCiAgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD48QlI+V2l0aCB0aGUgaW50cm9k dWN0aW9uIG9mIHRoZSBDb2Fyc2UgU3luYyBmdW5jdGlvbmFsaXR5LCB0aGUgDQogIElETVMgcHJv cG9zYWwgY2FuIGNvdW50ZXJhY3QgdGhlIGVmZmVjdCBvZiB0aGUgZGVsYXkgdmFyaWFiaWxpdHkg YXQgdGhlIA0KICBiZWdpbm5pbmcgb2YgdGhlIHBsYXlvdXQgb2YgdGhlIG1lZGlhIHN0cmVhbS9z IGluIGVhY2ggb25lIG9mIHRoZSBzdGFnZXMgaW4gDQogIHdoaWNoIGEgbWVkaWEgc2Vzc2lvbiBj YW4gYmUgZGl2aWRlZC48QlI+PEJSPldlIHByZWZlciB0aGUgZmlyc3QgbWV0aG9kIA0KICBiZWNh dXNlIHRoZXJlIGlzIG5vIG5lZWQgdG8gZGVmaW5lIG5ldyBJRE1TIGNvbnRyb2wgbWVzc2FnZXMg KG9yIHRvIGluY2x1ZGUgDQogIHNvbWUgZmllbGRzIHRvIGFscmVhZHkgZGVmaW5lZCBwYWNrZXRz KSwgYnV0IHRoZSB1c2Ugb2YgYWxyZWFkeSBkZWZpbmVkIFJUQ1AgDQogIHJlcG9ydHMgKFJGQyAz NjExKSBjYW4gYmUgYWRhcHRlZCBmb3IgdGhhdCBwdXJwb3NlLiA8QlI+PEJSPk1vcmVvdmVyLCB3 aXRoIHRoZSANCiAgdXNlIG9mIHRoZSBmaXJzdCBtZXRob2QsIFNDcyBkbyBub3QgaGF2ZSB0byBz ZW5kIGNvbnRyb2wgbWVzc2FnZXMgb25jZSB0aGV5IA0KICBqb2luIHRoZSBzZXNzaW9uLCB3aGlj aCBtYXkgcG9zc2libHkgcmVzdWx0IG9uIGluZWZmaWNpZW50IGNvbnRyb2wgdHJhZmZpYyANCiAg b3ZlcmhlYWQuIFRoZXkgd2lsbCBvbmx5IGhhdmUgdG8gc2VuZCBSVENQIFhSIERMUlIgbWVzc2Fn ZXMgaW4gcmVzcG9uc2UgdG8gYSANCiAgbmV3IGluY29taW5nIFJUUlIgbWVzc2FnZSBmcm9tIHRo ZSBzb3VyY2UsIHdoaWNoIGlzIHdobyByZWFsbHkga25vd3MgdGhlIA0KICBpbml0aWFsIHRyYW5z bWlzc2lvbiB0aW1lIGZvciB0aGUgUlRQIG1lZGlhIHN0cmVhbS4gTW9yZW92ZXIsIHRoZSBJbml0 aWFsIA0KICBQbGF5b3V0IEluc3RhbnQgY2FuIGJlIHNlbnQgdG8gdGhlIHJlY2VpdmVycyBieSB1 c2luZyB0aGUgUlRDUCBJRE1TIHBhY2tldCwgDQogIGFscmVhZHkgaW50cm9kdWNlZCBpbiB0aGUg SS1ELjxCUj48QlI+RmVlZGJhY2sgd2lsbCBiZSBtdWNoIA0KICBhcHByZWNpYXRlZC48QlI+PC9E SVY+PC9ESVY+PFBSRSBjbGFzcz1tb3otc2lnbmF0dXJlIGNvbHM9IjcyIj5SZWdhcmRzDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCkRyLiBGZXJuYW5kbyBCb3JvbmF0IFNlZ3XtDQpJRUVFIFNlbmlvciBNZW1i ZXINClByb2Zlc29yIFRpdHVsYXIgLyBMZWN0dXJlcgkNCkRlcHQuIENvbXVuaWNhY2lvbmVzICAg ICAgICAgICBUbGYuLSszNCs5NjIgODQ5IDMwMCBFeHQuLTQ5MzQxDQpUbGYuIGRpcmVjdG8gLSsz NCs5NjIgODQ5IDM0MSAgRmF4Li0rMzQrOTYyIDg0OSAzMDkgKENvbXBhcnRpZG8pDQpVTklWRVJT SURBRCBQT0xJVMlDTklDQSBERSBWQUxFTkNJQS1DQU1QVVMgREUgR0FORElBDQpDYWxsZSBQYXJh cmFuaW5mbywgMSwgQ1AuIDQ2NzMwLCBHcmFvIGRlIEdhbmRpYSAoVmFsZW5jaWEpLCBTUEFJTg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PC9QUkU+DQogIDxQPg0KICA8SFI+DQoNCiAgPFA+PC9QPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPkF1ZGlvL1ZpZGVvIA0K ICBUcmFuc3BvcnQgQ29yZSANCiAgTWFpbnRlbmFuY2U8QlI+YXZ0QGlldGYub3JnPEJSPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0PEJSPjwvQkxPQ0tRVU9URT48L0JP RFk+PC9IVE1MPg0K --Boundary_(ID_gj17M8co2AeakgQq+vx4zg)-- From bill.wu@huawei.com Wed Oct 12 01:32:07 2011 Return-Path: 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 1BA7E21F8BB7 for ; Wed, 12 Oct 2011 01:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, MIME_BASE64_TEXT=1.753, 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 2GWm0dYlCatU for ; Wed, 12 Oct 2011 01:32:06 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7E05D21F8B92 for ; Wed, 12 Oct 2011 01:32:05 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY00KRZ2DFT1@szxga04-in.huawei.com> for avt@ietf.org; Wed, 12 Oct 2011 16:32:04 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY007WM2D47Z@szxga04-in.huawei.com> for avt@ietf.org; Wed, 12 Oct 2011 16:32:03 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ69324; Wed, 12 Oct 2011 16:32:02 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 16:31:58 +0800 Received: from w53375q (10.138.41.130) by szxeml411-hub.china.huawei.com (10.82.67.138) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 16:31:54 +0800 Date: Wed, 12 Oct 2011 16:31:53 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: "Belling, Thomas (NSN - DE/Munich)" , Roni Even , avt@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_+7YYUi7SZ0nu0Z3NL3YRKA)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <76AADF1A61784B52A8516E16AAF78E71@china.huawei.com> <1A8A7D59006A8240B27FF63C794CA57F98549C@DEMUEXC014.nsn-intra.net> Cc: Magnus Westerlund Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 08:32:07 -0000 --Boundary_(ID_+7YYUi7SZ0nu0Z3NL3YRKA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi,Thomas: Your clarification make sense to me. Thanks. Regards! -Qin ----- Original Message ----- From: Belling, Thomas (NSN - DE/Munich) To: ext Qin Wu ; Roni Even ; avt@ietf.org Cc: Magnus Westerlund Sent: Tuesday, October 11, 2011 11:14 PM Subject: RE: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 Dear Qin, Magnus, Some replies to some of the earlier comments (I only briefly checked the rest). Thomas 3. Section 3, 2nd paragraph " Counting vs Detecting Congestion: TCP and the protocols derived from it are mainly designed to respond the same whether they experience a burst of congestion indications within one RTT or just one. " [Qin]: What's the difference between "one RTT" and "just one"? [Thomas] Intention seems rather to be "just one congestion indication". 7. Section 3.2, 5th paragraph " The standard RTP/ AVP profile [RFC3551] does not allow any early or immediate transmission of RTCP feedback, and has a minimal RTCP interval whose default value (5 seconds) is many times the normal RTT between sender and receiver. " [Qin]: What's the purpose of last sentence of this paragraph? Are you saying RFC3551 following Regular RTCP timing rule? or something else? Another question is according to RFC3551, the negotiation of parameters or membership control may be not support. in other wonder, there may be no way to negotiate ECN with RTP using SDP signaling, I am wondering can we say ECN with RTP can be used with the standard RTP/ AVP profile [RFC3551]. [Thomas] Negotiation is done with the 'ecn-capable-rtp' SDP attribute defined is this draft. Implantations not supporting ECN would ignore this, But this is independent of AVP or AVPF. 8. Section 3.3,3rd paragraph " For interoperability we mandate the implementation of the RTP/AVPF profile, with both RTCP extensions and the necessary signalling to support a common operations mode. This specification recommends the use of RTP/AVPF in all cases as negotiation of the common interoperability point requires RTP/AVPF, mixed negotiation of RTP/ AVP and RTP/AVPF depending on other SDP attributes in the same media block is difficult, " [Qin] How mixed negotiation is avoided when you don't put all the SDP attribute into the same media block? I don't really understand the rationale. Would you like to clarify a little bit? [Thomas] SDP capneg allows offering AVPF and AVP in the same media block, and also to relate SDP attributes to one of the transports only. Trouble is that this is not yet supported everywhere and has its problems with traversing intermediates not supporting it. [Qin]: It worth adding some text in the draft to make this clear. 11. Section 4, 3rd paragraph " o The sender may generate a (small) subset of its RTP data packets with the ECN field set to ECT(0) or ECT(1). " [Qin] It is not clear to me where the ECN field is located. Is ECN field in the IP header or UDP header or RTP header? [Thomas] It is the IP header. Text could be modified accordingly, e.g.: o The sender may generate a (small) subset of its RTP data packets with the ECN IP header field set to ECT(0) or ECT(1). 13.Section 5.1,1st paragraph " This RTP/AVPF transport layer feedback format is intended for use in RTP/AVPF early or immediate feedback modes when information needs to urgently reach the sender. Thus its main use is to report reception of an ECN-CE marked RTP packet so that the sender may perform congestion control, or to speed up the initiation procedures by rapidly reporting that the path can support ECN-marked traffic. " [Qin]: are you saying slow initiation procedure may result in network congestion? In my understanding, when ECN-CE marked packet is received, the only choice for sender is to do congestion control since you are not sure if initiation procedure lead to such congestion. If it is not intiation procedure that lead to congestion, you get risk to worse congestion condition? [Thomas] I believe this does not only refer to initiation, but mainly to feedback if congestion is encountered after the ECN media flow has been established. [Qin]: I think your interpretation is correct. But I am not sure this is a issue, no?. The prolem is do we have way to identify which factor lead to the final congestion. slow initiation, timely feedback or intermediary cheating in between. Regards! -Qin ----- Original Message ----- From: Roni Even To: avt@ietf.org Sent: Friday, September 30, 2011 8:29 PM Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP over UDP. The WGLC will end on October 21, 2011 Please review the draft and send comments to the list. Roni Even ---------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_+7YYUi7SZ0nu0Z3NL3YRKA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4ID0gDQoidXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnAgPSANCiJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpwb3dlcnBvaW50IiB4bWxuczphID0gDQoidXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6YWNjZXNzIiB4bWxuczpkdCA9IA0KInV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzID0gDQoidXVpZDpCREM2RTNGMC02REEz LTExZDEtQTJBMy0wMEFBMDBDMTQ4ODIiIHhtbG5zOnJzID0gDQoidXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpyb3dzZXQiIHhtbG5zOnogPSAiI1Jvd3NldFNjaGVtYSIgeG1sbnM6YiA9IA0KInVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnB1Ymxpc2hlciIgeG1sbnM6c3MgPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6YyA9IA0K InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmNvbXBvbmVudDpzcHJlYWRzaGVldCIg eG1sbnM6b2RjID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2RjIiB4bWxu czpvYSA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2YXRpb24iIHht bG5zOmh0bWwgPSANCiJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxuczpxID0g DQoiaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOnJ0YyA9 IA0KImh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIFhNTE5TOkQg PSAiREFWOiIgWE1MTlM6UmVwbCA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVw bC8iIHhtbG5zOm10ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50 L3NvYXAvbWVldGluZ3MvIiB4bWxuczp4MiA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlL2V4Y2VsLzIwMDMveG1sIiB4bWxuczpwcGRhID0gDQoiaHR0cDovL3d3dy5wYXNz cG9ydC5jb20vTmFtZVNwYWNlLnhzZCIgeG1sbnM6b2lzID0gDQoiaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvZGlyZWN0b3J5LyIgeG1sbnM6ZHMg PSANCiJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3AgPSANCiJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvZHNwIiB4bWxuczp1ZGMgPSAN CiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjIiB4bWxuczp4c2QgPSANCiJo dHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViID0gDQoiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvMjAwMi8xL2FsZXJ0cy8iIHhtbG5z OmVjID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjIiB4bWxuczpzcCA9IA0K Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcyA9IA0K Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIgeG1sbnM6eHNp ID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnVk Y3MgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5z OnVkY3hmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy94bWxmaWxl IiB4bWxuczp1ZGNwMnAgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRj L3BhcnR0b3BhcnQiIHhtbG5zOndmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9z aGFyZXBvaW50L3NvYXAvd29ya2Zsb3cvIiB4bWxuczpkc3NzID0gDQoiaHR0cDovL3NjaGVtYXMu bWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9kaWdzaWctc2V0dXAiIHhtbG5zOmRzc2kgPSANCiJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2RpZ3NpZyIgeG1sbnM6bWRz c2kgPSANCiJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2L2Rp Z2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyID0gDQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZv cm1hdHMub3JnL21hcmt1cC1jb21wYXRpYmlsaXR5LzIwMDYiIHhtbG5zOm0gPSANCiJodHRwOi8v c2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxzID0g DQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9yZWxhdGlv bnNoaXBzIiB4bWxuczpzcHdwID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vc2hhcmVwb2ludC93 ZWJwYXJ0cGFnZXMiIHhtbG5zOmV4MTJ0ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9leGNoYW5nZS9zZXJ2aWNlcy8yMDA2L3R5cGVzIiB4bWxuczpleDEybSA9IA0KImh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1s bnM6cHB0c2wgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9TbGlkZUxpYnJhcnkvIiB4bWxuczpzcHNsID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vd2Vi c2VydmljZXMvU2hhcmVQb2ludFBvcnRhbFNlcnZlci9QdWJsaXNoZWRMaW5rc1NlcnZpY2UiIA0K WE1MTlM6WiA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3QgPSAiASI+PEhF QUQ+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1l cXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250ZW50PSJNU0hUTUwg OC4wMC42MDAxLjE5MTIwIj48IS0tW2lmICFtc29dPg0KPFNUWUxFPnZcOiogew0KCUJFSEFWSU9S OiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0Kb1w6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNW TUwpDQp9DQp3XDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0NCi5zaGFwZSB7 DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQo8L1NUWUxFPg0KPCFbZW5kaWZdLS0+ DQo8U1RZTEU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAx O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxWb3Jmb3JtYXRpZXJ0WmNobg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRpZXJ0IjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0 dGVkLCBkaXYuSFRNTFByZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmgxMQ0KCXttc28tc3R5bGUtbmFtZTpo MTE7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglmb250LXdlaWdodDpib2xkO30NCnNw YW4uRS1NYWlsRm9ybWF0dm9ybGFnZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9TVFlMRT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9IRUFEPg0KPEJPRFkgbGFuZz1ERSBsaW5rPWJs dWUgYmdDb2xvcj13aGl0ZSB2TGluaz1wdXJwbGU+DQo8RElWPkhpLFRob21hczo8L0RJVj4NCjxE SVY+WW91ciBjbGFyaWZpY2F0aW9uIG1ha2Ugc2Vuc2UgdG8gbWUuIFRoYW5rcy48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPlJlZ2FyZHMhPC9ESVY+DQo8RElWPi1RaW48L0RJVj4NCjxC TE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElO Ry1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lO LVJJR0hUOiAwcHgiIA0KZGlyPWx0cj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7 JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250 LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT10aG9tYXMuYmVsbGluZ0Bu c24uY29tIGhyZWY9Im1haWx0bzp0aG9tYXMuYmVsbGluZ0Buc24uY29tIj5CZWxsaW5nLCANCiAg VGhvbWFzIChOU04gLSBERS9NdW5pY2gpPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDog OXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9YmlsbC53dUBodWF3ZWku Y29tIA0KICBocmVmPSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIj5leHQgUWluIFd1PC9BPiA7 IDxBIA0KICB0aXRsZT1FdmVuLnJvbmlAaHVhd2VpLmNvbSBocmVmPSJtYWlsdG86RXZlbi5yb25p QGh1YXdlaS5jb20iPlJvbmkgRXZlbjwvQT4gOyANCiAgPEEgdGl0bGU9YXZ0QGlldGYub3JnIGhy ZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5DYzo8L0I+IDxBIHRpdGxlPW1h Z251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbSANCiAgaHJlZj0ibWFpbHRvOm1hZ251cy53ZXN0 ZXJsdW5kQGVyaWNzc29uLmNvbSI+TWFnbnVzIFdlc3Rlcmx1bmQ8L0E+IDwvRElWPg0KICA8RElW IHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IFR1ZXNkYXks IE9jdG9iZXIgMTEsIDIwMTEgMTE6MTQgDQpQTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5 cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFJFOiBbQVZUQ09SRV0gV0dMQyBv biANCiAgZHJhZnQtaWV0Zi1hdnRjb3JlLWVjbi1mb3ItcnRwLTA0PC9ESVY+DQogIDxESVY+PEJS PjwvRElWPg0KICA8RElWIGNsYXNzPVdvcmRTZWN0aW9uMT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIHN0eWxlPSJDT0xPUjogIzFmNDk3ZCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gc3R5bGU9IkNPTE9SOiAjMWY0OTdkIj5EZWFy IFFpbiwgDQogIE1hZ251cyw8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48U1BBTiBzdHlsZT0iQ09MT1I6ICMxZjQ5N2QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFO PjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJDT0xPUjogIzFmNDk3ZCIg bGFuZz1FTi1HQj5Tb21lIHJlcGxpZXMgdG8gDQogIHNvbWUgb2YgdGhlIGVhcmxpZXIgY29tbWVu dHMgKEkgb25seSBicmllZmx5IGNoZWNrZWQgdGhlIA0KICByZXN0KS48bzpwPjwvbzpwPjwvU1BB Tj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBzdHlsZT0iQ09MT1I6ICMxZjQ5N2Qi IA0KICBsYW5nPUVOLUdCPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJDT0xPUjogIzFmNDk3ZCIgDQogIGxhbmc9RU4tR0I+VGhv bWFzPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gc3R5bGU9IkNPTE9SOiAjMWY0OTdkIiANCiAgbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwv bzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BB TiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBGT05U LVNJWkU6IDEycHQiIA0KICBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48 L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0laRTogMTJwdCIgbGFu Zz1FTi1VUz4zLiANCiAgU2VjdGlvbiAzLCAybmQgcGFyYWdyYXBoPG86cD48L286cD48L1NQQU4+ PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxl PSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgRk9OVC1TSVpFOiAxMnB0 IiANCiAgbGFuZz1FTi1VUz4iPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVz IE5ldyBSb21hbicsJ3NlcmlmJzsgRk9OVC1TSVpFOiAxMnB0IiANCiAgbGFuZz1FTi1VUz4mbmJz cDsmbmJzcDsgQ291bnRpbmcgdnMgRGV0ZWN0aW5nIENvbmdlc3Rpb246Jm5ic3A7IFRDUCBhbmQg dGhlIA0KICBwcm90b2NvbHMgZGVyaXZlZCBmcm9tPEJSPiZuYnNwOyZuYnNwOyZuYnNwO2l0IGFy ZSBtYWlubHkgZGVzaWduZWQgdG8gcmVzcG9uZCANCiAgdGhlIHNhbWUgd2hldGhlciB0aGV5IGV4 cGVyaWVuY2U8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YSBidXJzdCBvZiBjb25nZXN0aW9uIA0KICBp bmRpY2F0aW9ucyB3aXRoaW4gb25lIFJUVCBvciBqdXN0IG9uZS48bzpwPjwvbzpwPjwvU1BBTj48 L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9 IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBGT05ULVNJWkU6IDEycHQi IA0KICBsYW5nPUVOLVVTPiI8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJywnc2VyaWYnOyBGT05ULVNJWkU6IDEycHQiIA0KICBsYW5nPUVOLVVTPltRaW5d OiBXaGF0J3MgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiAib25lIFJUVCIgYW5kICJqdXN0IA0KICBv bmUiPzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0 eWxlPSJDT0xPUjogIzFmNDk3ZCIgDQogIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQ QU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gc3R5bGU9IkNPTE9SOiAjMWY0OTdk IiBsYW5nPUVOLVVTPltUaG9tYXNdIEludGVudGlvbiANCiAgc2VlbXMgcmF0aGVyIHRvIGJlIJNq dXN0IG9uZSBjb25nZXN0aW9uIA0KICBpbmRpY2F0aW9ulC48bzpwPjwvbzpwPjwvU1BBTj48L1A+ PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZP TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBGT05ULVNJWkU6IDEycHQiIA0K ICBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1l cyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0laRTogMTJwdCIgDQogIGxhbmc9RU4tVVM+Jm5i c3A7PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3Nl cmlmJzsgRk9OVC1TSVpFOiAxMnB0IiBsYW5nPUVOLVVTPjcuIA0KICBTZWN0aW9uIDMuMiwgNXRo IHBhcmFncmFwaDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t YW4nLCdzZXJpZic7IEZPTlQtU0laRTogMTJwdCIgDQogIGxhbmc9RU4tVVM+IjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0la RTogMTJwdCIgbGFuZz1FTi1VUz5UaGUgDQogIHN0YW5kYXJkIFJUUC8mbmJzcDtBVlAgcHJvZmls ZSBbUkZDMzU1MV0gZG9lcyBub3QgYWxsb3cgYW55IGVhcmx5IG9yIA0KICBpbW1lZGlhdGU8QlI+ dHJhbnNtaXNzaW9uIG9mIFJUQ1AgZmVlZGJhY2ssIGFuZCBoYXMgYSBtaW5pbWFsIFJUQ1AgaW50 ZXJ2YWwgDQogIHdob3NlJm5ic3A7ZGVmYXVsdCB2YWx1ZTxvOnA+PC9vOnA+PC9TUEFOPjwvUD48 L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0laRTogMTJwdCIgDQog IGxhbmc9RU4tVVM+Jm5ic3A7KDUgc2Vjb25kcykgaXMgbWFueSB0aW1lcyB0aGUgbm9ybWFsIFJU VCBiZXR3ZWVuIA0KICBzZW5kZXImbmJzcDthbmQgcmVjZWl2ZXIuPG86cD48L286cD48L1NQQU4+ PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxl PSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgRk9OVC1TSVpFOiAxMnB0 IiANCiAgbGFuZz1FTi1VUz4iPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVz IE5ldyBSb21hbicsJ3NlcmlmJzsgRk9OVC1TSVpFOiAxMnB0IiANCiAgbGFuZz1FTi1VUz5bUWlu XTogV2hhdCdzIHRoZSBwdXJwb3NlIG9mIGxhc3Qgc2VudGVuY2Ugb2YgdGhpcyANCiAgcGFyYWdy YXBoPzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXJlIHlvdSBzYXlp bmcgUkZDMzU1MSANCiAgZm9sbG93aW5nIFJlZ3VsYXIgUlRDUCB0aW1pbmcgcnVsZT88QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yIA0KICBzb21ldGhpbmcgZWxzZT88 bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1h bD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYn OyBGT05ULVNJWkU6IDEycHQiIA0KICBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFO PjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0laRTogMTJw dCIgDQogIGxhbmc9RU4tVVM+Jm5ic3A7Jm5ic3A7IEFub3RoZXIgcXVlc3Rpb24gaXMgYWNjb3Jk aW5nIHRvIFJGQzM1NTEsIHRoZSANCiAgbmVnb3RpYXRpb24gb2Y8QlI+Jm5ic3A7Jm5ic3A7IHBh cmFtZXRlcnMgb3IgbWVtYmVyc2hpcCBjb250cm9sIG1heSBiZSBub3QgDQogIHN1cHBvcnQuIGlu IG90aGVyIHdvbmRlciw8QlI+Jm5ic3A7Jm5ic3A7IHRoZXJlIG1heSBiZSBubyB3YXkgdG8gbmVn b3RpYXRlIEVDTiANCiAgd2l0aCBSVFAgdXNpbmcgU0RQIHNpZ25hbGluZyw8QlI+Jm5ic3A7Jm5i c3A7IEkgYW0gd29uZGVyaW5nIGNhbiB3ZSBzYXkgRUNOIA0KICB3aXRoIFJUUCBjYW4gYmUgdXNl ZCB3aXRoIHRoZSBzdGFuZGFyZCBSVFAvPEJSPiZuYnNwOyZuYnNwOyBBVlAgcHJvZmlsZSANCiAg W1JGQzM1NTFdLiA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 U1BBTiBzdHlsZT0iQ09MT1I6ICMxZjQ5N2QiIA0KICBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9v OnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJDT0xPUjog IzFmNDk3ZCIgbGFuZz1FTi1VUz5bVGhvbWFzXSANCiAgTmVnb3RpYXRpb24gaXMgZG9uZSB3aXRo IHRoZSCRZWNuLWNhcGFibGUtcnRwkiBTRFAgYXR0cmlidXRlIGRlZmluZWQgaXMgdGhpcyANCiAg ZHJhZnQuIEltcGxhbnRhdGlvbnMgbm90IHN1cHBvcnRpbmcgRUNOIHdvdWxkIGlnbm9yZSB0aGlz LCBCdXQgdGhpcyBpcyANCiAgaW5kZXBlbmRlbnQgb2YgQVZQIG9yIEFWUEYuIDxvOnA+PC9vOnA+ PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0la RTogMTJwdCIgDQogIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gc3R5bGU9IkNPTE9SOiAjMWY0OTdkIiANCiAgbGFuZz1F Ti1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNs YXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJywnc2VyaWYnOyBGT05ULVNJWkU6IDEycHQiIGxhbmc9RU4tVVM+OC4gDQogIFNlY3Rpb24g My4zLDNyZCBwYXJhZ3JhcGg8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJywnc2VyaWYnOyBGT05ULVNJWkU6IDEycHQiIA0KICBsYW5nPUVOLVVTPiI8bzpw PjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBG T05ULVNJWkU6IDEycHQiIA0KICBsYW5nPUVOLVVTPiZuYnNwOyZuYnNwOyBGb3IgaW50ZXJvcGVy YWJpbGl0eSB3ZSBtYW5kYXRlIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiANCiAgdGhlIFJUUC9BVlBG PEJSPiZuYnNwOyZuYnNwOyBwcm9maWxlLCB3aXRoIGJvdGggUlRDUCBleHRlbnNpb25zIGFuZCB0 aGUgDQogIG5lY2Vzc2FyeSBzaWduYWxsaW5nIHRvPEJSPiZuYnNwOyZuYnNwOyBzdXBwb3J0IGEg Y29tbW9uIG9wZXJhdGlvbnMgDQogIG1vZGUuJm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiByZWNv bW1lbmRzIHRoZTxCUj4mbmJzcDsmbmJzcDsgdXNlIG9mIFJUUC9BVlBGIA0KICBpbiBhbGwgY2Fz ZXMgYXMgbmVnb3RpYXRpb24gb2YgdGhlIGNvbW1vbjxCUj4mbmJzcDsmbmJzcDsgaW50ZXJvcGVy YWJpbGl0eSANCiAgcG9pbnQgcmVxdWlyZXMgUlRQL0FWUEYsIG1peGVkIG5lZ290aWF0aW9uIG9m IFJUUC88QlI+Jm5ic3A7Jm5ic3A7IEFWUCBhbmQgDQogIFJUUC9BVlBGIGRlcGVuZGluZyBvbiBv dGhlciBTRFAgYXR0cmlidXRlcyBpbiB0aGUgc2FtZSBtZWRpYTxCUj4mbmJzcDsmbmJzcDsgDQog IGJsb2NrIGlzIGRpZmZpY3VsdCw8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGlt ZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBGT05ULVNJWkU6IDEycHQiIA0KICBsYW5nPUVOLVVTPiI8 bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1h bD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYn OyBGT05ULVNJWkU6IDEycHQiIA0KICBsYW5nPUVOLVVTPltRaW5dIEhvdyBtaXhlZCBuZWdvdGlh dGlvbiBpcyBhdm9pZGVkIHdoZW4geW91IGRvbid0IHB1dCBhbGwgdGhlIA0KICBTRFAgYXR0cmli dXRlPEJSPiZuYnNwO2ludG8gdGhlIHNhbWUgbWVkaWEgYmxvY2s/IEkgZG9uJ3QgcmVhbGx5IHVu ZGVyc3RhbmQgDQogIHRoZSByYXRpb25hbGUuIFdvdWxkIHlvdTxCUj5saWtlIHRvIGNsYXJpZnkg YSBsaXR0bGUgDQpiaXQ/PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PFNQQU4gc3R5bGU9IkNPTE9SOiAjMWY0OTdkIiANCiAgbGFuZz1FTi1VUz48bzpwPiZuYnNw OzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBzdHlsZT0iQ09M T1I6ICMxZjQ5N2QiIGxhbmc9RU4tVVM+W1Rob21hc10gU0RQIGNhcG5lZyANCiAgYWxsb3dzIG9m ZmVyaW5nIEFWUEYgYW5kIEFWUCBpbiB0aGUgc2FtZSBtZWRpYSBibG9jaywgYW5kIGFsc28gdG8g cmVsYXRlIFNEUCANCiAgYXR0cmlidXRlcyB0byBvbmUgb2YgdGhlIHRyYW5zcG9ydHMgb25seS4g VHJvdWJsZSBpcyB0aGF0IHRoaXMgaXMgbm90IHlldCANCiAgc3VwcG9ydGVkIGV2ZXJ5d2hlcmUg YW5kIGhhcyBpdHMgcHJvYmxlbXMgd2l0aCB0cmF2ZXJzaW5nIGludGVybWVkaWF0ZXMgbm90IA0K ICBzdXBwb3J0aW5nIGl0LjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBz dHlsZT0iQ09MT1I6ICMxZjQ5N2QiIGxhbmc9RU4tVVM+PC9TUEFOPiZuYnNwOzwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJDT0xPUjogIzFmNDk3ZCIgbGFuZz1FTi1VUz5b UWluXTogSXQgd29ydGggDQogIGFkZGluZyBzb21lIHRleHQgaW4gdGhlIGRyYWZ0IHRvIG1ha2Ug dGhpcyBjbGVhci48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3Nlcmlm JzsgRk9OVC1TSVpFOiAxMnB0IiANCiAgbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvU1BB Tj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBzdHlsZT0iQ09MT1I6ICMxZjQ5N2Qi IA0KICBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJ Vj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0laRTogMTJwdCIgbGFuZz1FTi1VUz4xMS4g DQogIFNlY3Rpb24gNCwgM3JkIHBhcmFncmFwaDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4N CiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0laRTogMTJwdCIgDQogIGxhbmc9 RU4tVVM+IjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4n LCdzZXJpZic7IEZPTlQtU0laRTogMTJwdCIgDQogIGxhbmc9RU4tVVM+Jm5ic3A7Jm5ic3A7IG8m bmJzcDsgVGhlIHNlbmRlciBtYXkgZ2VuZXJhdGUgYSAoc21hbGwpIHN1YnNldCBvZiANCiAgaXRz IFJUUCBkYXRhIHBhY2tldHM8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGgg dGhlIEVDTiBmaWVsZCBzZXQgDQogIHRvIEVDVCgwKSBvciBFQ1QoMSkuIDxvOnA+PC9vOnA+PC9T UEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0laRTog MTJwdCIgDQogIGxhbmc9RU4tVVM+IjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJ Vj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0laRTogMTJwdCIgDQogIGxhbmc9RU4tVVM+ Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbics J3NlcmlmJzsgRk9OVC1TSVpFOiAxMnB0IiANCiAgbGFuZz1FTi1VUz5bUWluXSBJdCBpcyBub3Qg Y2xlYXIgdG8gbWUgd2hlcmUgdGhlIEVDTiBmaWVsZCBpcyBsb2NhdGVkLjxCUj5JcyANCiAgRUNO IGZpZWxkIGluIHRoZSBJUCBoZWFkZXIgb3IgVURQIGhlYWRlciBvciBSVFAgaGVhZGVyPzxvOnA+ PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJDT0xP UjogIzFmNDk3ZCIgDQogIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gc3R5bGU9IkNPTE9SOiAjMWY0OTdkIiBsYW5nPUVO LVVTPltUaG9tYXNdIEl0IGlzIHRoZSANCiAgSVAgaGVhZGVyLiBUZXh0IGNvdWxkIGJlIG1vZGlm aWVkIGFjY29yZGluZ2x5LCBlLmcuOiANCiAgPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0K ICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlM WTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgRk9OVC1TSVpFOiAxMnB0IiANCiAgbGFuZz1F Ti1VUz4mbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBUaGUgc2VuZGVyIG1heSBnZW5lcmF0ZSBh IChzbWFsbCkgc3Vic2V0IA0KICBvZiBpdHMgUlRQIGRhdGEgcGFja2V0czxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgd2l0aCB0aGUgRUNOIDxTUEFOIA0KICBzdHlsZT0iQ09MT1I6 ICM0ZjgxYmQiPklQIGhlYWRlcjwvU1BBTj4gZmllbGQgc2V0IHRvIEVDVCgwKSBvciBFQ1QoMSku IA0KICA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiAN CiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBGT05ULVNJ WkU6IDEycHQiIA0KICBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD48L0RJ Vj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1G QU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0laRTogMTJwdCIgDQogIGxh bmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5l dyBSb21hbicsJ3NlcmlmJzsgRk9OVC1TSVpFOiAxMnB0IiANCiAgbGFuZz1FTi1VUz4xMy5TZWN0 aW9uIDUuMSwxc3QgcGFyYWdyYXBoPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElW Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Rp bWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgRk9OVC1TSVpFOiAxMnB0IiANCiAgbGFuZz1FTi1VUz4i PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3Nlcmlm JzsgRk9OVC1TSVpFOiAxMnB0IiANCiAgbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsgVGhpcyBSVFAv QVZQRiB0cmFuc3BvcnQgbGF5ZXIgZmVlZGJhY2sgZm9ybWF0IGlzIA0KICBpbnRlbmRlZCBmb3Ig dXNlIGluPEJSPiZuYnNwOyZuYnNwOyBSVFAvQVZQRiBlYXJseSBvciBpbW1lZGlhdGUgZmVlZGJh Y2sgbW9kZXMgDQogIHdoZW4gaW5mb3JtYXRpb24gbmVlZHMgdG88QlI+Jm5ic3A7Jm5ic3A7IHVy Z2VudGx5IHJlYWNoIHRoZSBzZW5kZXIuJm5ic3A7IA0KICBUaHVzIGl0cyBtYWluIHVzZSBpcyB0 byByZXBvcnQgcmVjZXB0aW9uPEJSPiZuYnNwOyZuYnNwOyBvZiBhbiBFQ04tQ0UgbWFya2VkIA0K ICBSVFAgcGFja2V0IHNvIHRoYXQgdGhlIHNlbmRlciBtYXkgcGVyZm9ybTxCUj4mbmJzcDsmbmJz cDsgY29uZ2VzdGlvbiBjb250cm9sLCANCiAgb3IgdG8gc3BlZWQgdXAgdGhlIGluaXRpYXRpb24g cHJvY2VkdXJlcyBieTxCUj4mbmJzcDsmbmJzcDsgcmFwaWRseSByZXBvcnRpbmcgDQogIHRoYXQg dGhlIHBhdGggY2FuIHN1cHBvcnQgRUNOLW1hcmtlZCB0cmFmZmljLjxvOnA+PC9vOnA+PC9TUEFO PjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0laRTogMTJw dCIgDQogIGxhbmc9RU4tVVM+IjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1l cyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQtU0laRTogMTJwdCIgDQogIGxhbmc9RU4tVVM+Jm5i c3A7PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3Nl cmlmJzsgRk9OVC1TSVpFOiAxMnB0IiANCiAgbGFuZz1FTi1VUz5bUWluXTogYXJlIHlvdSBzYXlp bmcgc2xvdyBpbml0aWF0aW9uIHByb2NlZHVyZSBtYXkgcmVzdWx0IGluIA0KICBuZXR3b3JrIGNv bmdlc3Rpb24/PEJSPkluIG15IHVuZGVyc3RhbmRpbmcsIHdoZW4gRUNOLUNFIG1hcmtlZCBwYWNr ZXQgaXMgDQogIHJlY2VpdmVkLCB0aGUgb25seSBjaG9pY2UgZm9yIHNlbmRlcjxCUj5pcyB0byBk byBjb25nZXN0aW9uIGNvbnRyb2wgc2luY2UgeW91IA0KICBhcmUgbm90IHN1cmUgaWYgaW5pdGlh dGlvbiBwcm9jZWR1cmUgbGVhZCB0byBzdWNoPEJSPmNvbmdlc3Rpb24uIElmIGl0IGlzIG5vdCAN CiAgaW50aWF0aW9uIHByb2NlZHVyZSB0aGF0IGxlYWQgdG8gY29uZ2VzdGlvbiwgeW91IGdldCBy aXNrIHRvIA0KICB3b3JzZTxCUj5jb25nZXN0aW9uIGNvbmRpdGlvbj8gPG86cD48L286cD48L1NQ QU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gc3R5bGU9IkNPTE9SOiAjMWY0OTdk IiANCiAgbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiBzdHlsZT0iQ09MT1I6ICMxZjQ5N2QiIGxhbmc9RU4tVVM+W1Rob21h c10gSSBiZWxpZXZlIA0KICB0aGlzIGRvZXMgbm90IG9ubHkgcmVmZXIgdG8gaW5pdGlhdGlvbiwg YnV0IG1haW5seSB0byBmZWVkYmFjayBpZiBjb25nZXN0aW9uIA0KICBpcyBlbmNvdW50ZXJlZCBh ZnRlciB0aGUgRUNOIG1lZGlhIGZsb3cgaGFzIGJlZW4gDQogIGVzdGFibGlzaGVkLjxvOnA+PC9v OnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZPTlQt U0laRTogMTJwdCIgDQogIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9QPjwv RElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05U LUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgRk9OVC1TSVpFOiAxMnB0IiANCiAg bGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJywnc2VyaWYnOyBGT05ULVNJWkU6IDEycHQiIA0KICBsYW5nPUVOLVVTPiZuYnNw O1tRaW5dOiBJIHRoaW5rIHlvdXIgaW50ZXJwcmV0YXRpb24gaXMgY29ycmVjdC4gQnV0IEkgYW0g bm90IA0KICBzdXJlIHRoaXMgaXMgYSBpc3N1ZSwgbm8/LiBUaGUgcHJvbGVtIGlzIGRvIHdlIGhh dmUgd2F5IHRvIGlkZW50aWZ5IHdoaWNoIA0KICBmYWN0b3ImbmJzcDtsZWFkIHRvIHRoZSBmaW5h bCBjb25nZXN0aW9uLjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAg c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBGT05ULVNJWkU6 IDEycHQiIA0KICBsYW5nPUVOLVVTPnNsb3cgaW5pdGlhdGlvbiwgdGltZWx5IGZlZWRiYWNrIG9y IGludGVybWVkaWFyeSBjaGVhdGluZyBpbiANCiAgYmV0d2Vlbi48L1NQQU4+PC9QPjwvRElWPg0K ICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlM WTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgRk9OVC1TSVpFOiAxMnB0IiANCiAgbGFuZz1F Ti1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNs YXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJywnc2VyaWYnOyBGT05ULVNJWkU6IDEycHQiIA0KICBsYW5nPUVOLVVTPlJlZ2FyZHMhPG86 cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsg Rk9OVC1TSVpFOiAxMnB0IiANCiAgbGFuZz1FTi1VUz4tUWluPG86cD48L286cD48L1NQQU4+PC9Q PjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJG T05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgRk9OVC1TSVpFOiAxMnB0IiAN CiAgbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxCTE9D S1FVT1RFIA0KICBzdHlsZT0iQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBibGFjayAxLjVwdCBzb2xpZDsgUEFERElORy1CT1RUT006IDBjbTsgTUFSR0lOOiA1cHQgMGNt IDVwdCAzLjc1cHQ7IFBBRERJTkctTEVGVDogNHB0OyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRF Ui1UT1A6IG1lZGl1bSBub25lOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRP UDogMGNtIj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBzdHlsZT0i Rk9OVC1GQU1JTFk6IFNpbVN1bjsgRk9OVC1TSVpFOiA5cHQiIA0KICAgIGxhbmc9RU4tVVM+LS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQog ICAgPERJVj4NCiAgICA8UCBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNCIgY2xhc3M9TXNvTm9y bWFsPjxCPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULUZBTUlMWTogU2ltU3VuOyBGT05ULVNJWkU6 IDlwdCIgbGFuZz1FTi1VUz5Gcm9tOjwvU1BBTj48L0I+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQt RkFNSUxZOiBTaW1TdW47IEZPTlQtU0laRTogOXB0IiBsYW5nPUVOLVVTPiA8QSANCiAgICB0aXRs ZT1FdmVuLnJvbmlAaHVhd2VpLmNvbSBocmVmPSJtYWlsdG86RXZlbi5yb25pQGh1YXdlaS5jb20i PlJvbmkgRXZlbjwvQT4gDQogICAgPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICAgIDxE SVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTog U2ltU3VuOyBGT05ULVNJWkU6IDlwdCIgDQogICAgbGFuZz1FTi1VUz5Ubzo8L1NQQU4+PC9CPjxT UEFOIHN0eWxlPSJGT05ULUZBTUlMWTogU2ltU3VuOyBGT05ULVNJWkU6IDlwdCIgDQogICAgbGFu Zz1FTi1VUz4gPEEgdGl0bGU9YXZ0QGlldGYub3JnIA0KICAgIGhyZWY9Im1haWx0bzphdnRAaWV0 Zi5vcmciPmF2dEBpZXRmLm9yZzwvQT4gPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICAg IDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM WTogU2ltU3VuOyBGT05ULVNJWkU6IDlwdCIgDQogICAgbGFuZz1FTi1VUz5TZW50OjwvU1BBTj48 L0I+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBTaW1TdW47IEZPTlQtU0laRTogOXB0IiANCiAg ICBsYW5nPUVOLVVTPiBGcmlkYXksIFNlcHRlbWJlciAzMCwgMjAxMSA4OjI5IFBNPG86cD48L286 cD48L1NQQU4+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxC PjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogU2ltU3VuOyBGT05ULVNJWkU6IDlwdCIgDQogICAg bGFuZz1FTi1VUz5TdWJqZWN0OjwvU1BBTj48L0I+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtRkFN SUxZOiBTaW1TdW47IEZPTlQtU0laRTogOXB0IiBsYW5nPUVOLVVTPiBbQVZUQ09SRV0gV0dMQyBv biANCiAgICBkcmFmdC1pZXRmLWF2dGNvcmUtZWNuLWZvci1ydHAtMDQ8bzpwPjwvbzpwPjwvU1BB Tj48L1A+PC9ESVY+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQog ICAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBGT05ULVNJ WkU6IDEycHQiIA0KICAgIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPjwv RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPkhpLDxvOnA+PC9v OnA+PC9TUEFOPjwvUD48UFJFPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdz YW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMXB0IiBsYW5nPUVOLVVTPkkgd291bGQgbGlrZSB0byBz dGFydCBhIFdHTEMgb24gPEEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1hdnRjb3JlLWVjbi1mb3ItcnRwLTA0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWF2dGNvcmUtZWNuLWZvci1ydHAtMDQ8L0E+ICwgPC9TUEFOPjxTUEFOIHN0eWxl PSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMXB0IiBs YW5nPUVOPkV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIGZvciBSVFAgb3Zl ciBVRFAuPG86cD48L286cD48L1NQQU4+PC9QUkU+PFBSRT48U1BBTiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTFwdCIgbGFuZz1FTj48bzpw PiZuYnNwOzwvbzpwPjwvU1BBTj48L1BSRT4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g bGFuZz1FTj5UaGUgV0dMQyB3aWxsIGVuZCBvbiBPY3RvYmVyIDIxLCANCiAgICAyMDExPG86cD48 L286cD48L1NQQU4+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVT PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQ QU4gbGFuZz1FTi1VUz5QbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQgc2VuZCANCiAgICBjb21t ZW50cyB0byB0aGUgbGlzdC48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICAg IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9T UEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz5Sb25pIEV2 ZW48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxh bmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPjxQUkU+PFNQQU4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDExcHQiIGxhbmc9 RU4+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QUkU+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIGxhbmc9RU4+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICAgIDxESVYgc3R5 bGU9IlRFWFQtQUxJR046IGNlbnRlciIgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlcj48U1BB TiANCiAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IEZP TlQtU0laRTogMTJwdCIgbGFuZz1FTi1VUz4NCiAgICA8SFIgYWxpZ249Y2VudGVyIFNJWkU9MiB3 aWR0aD0iMTAwJSI+DQogICAgPC9TUEFOPjwvRElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 U1BBTiANCiAgICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7 IEZPTlQtU0laRTogMTJwdCIgDQogICAgbGFuZz1FTi1VUz5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5BdWRpby9WaWRlbyANCiAgICBUcmFuc3BvcnQg Q29yZSANCiAgICBNYWludGVuYW5jZTxCUj5hdnRAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9CTE9DS1FV T1RFPjwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_+7YYUi7SZ0nu0Z3NL3YRKA)-- From versteb@cisco.com Wed Oct 12 05:57:24 2011 Return-Path: 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 99B3421F8C18 for ; Wed, 12 Oct 2011 05:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 0m5l5MUwV9EH for ; Wed, 12 Oct 2011 05:57:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1381821F84A9 for ; Wed, 12 Oct 2011 05:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=versteb@cisco.com; l=27752; q=dns/txt; s=iport; t=1318424239; x=1319633839; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=gb+7kVQpfjIU+aqEQ75OPQHHUR0ccDnWV99w3myFefU=; b=itK6UB92nwPtlEVuXCecI6qW42a3Sy7w3gw/AaSxxihcm3fm7/ARtST0 7zl2XblRyctaHKvcOg0sJ8syEbu/tJI/2w/8GcljMlHbVKG311pZkeoj9 v0SrWUjV6HzjcJyHrtEPRFVqftpnpA/MVRpwlUhgqSbC6OchygyhQk23z c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8AAIONlU6tJV2d/2dsb2JhbABDgk2WQ4dtAYcxgQWBUwEBAQQSAQkRA1kCAQgRBAEBCwYQBwEGAUUJCAEBBAESCBqHZJsUAZ5ohndhBIdPMJEnjEE X-IronPort-AV: E=Sophos;i="4.69,334,1315180800"; d="scan'208,217";a="27831037" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 12 Oct 2011 12:57:18 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9CCvH20030136; Wed, 12 Oct 2011 12:57:17 GMT Received: from xmb-rcd-312.cisco.com ([72.163.63.27]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Oct 2011 07:57:17 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC88DE.78CF251A" Date: Wed, 12 Oct 2011 07:57:16 -0500 Message-ID: <117602CF2B17DB4F9001427FA6D9053996F6FF@XMB-RCD-312.cisco.com> In-Reply-To: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 Thread-Index: Acx/bJMAZn1O9EdQQ6OkqDNm9OOyyQIsm8UQ References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> From: "Bill Ver Steeg (versteb)" To: "Roni Even" , , "Magnus Westerlund" X-OriginalArrivalTime: 12 Oct 2011 12:57:17.0919 (UTC) FILETIME=[78E36EF0:01CC88DE] Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 12:57:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC88DE.78CF251A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Magnus, Roni -=20 =20 Congestion control is an important area, and I support this document = moving forward after we take care of some issues.=20 =20 In this note, I list a few important points, followed by some less = important comments. =20 Important points - =20 =20 For the multicast case, we need to make it clear that feedback goes to = the feedback target, which may be a different device than the source. = This document consistently says "feedback goes to the source", which is = misleading. See the detailed comments below for the places in which I = found it to be most concerning. When viewed in the context of feedback = going to a discrete feedback target at the network egress edge (like = typical IPTV deployments), it makes sense for the feedback target to use = these reports as diagnostic in nature. Perhaps the network has changed = topology and caused a bottleneck link to appear, and the feedback is = triggering action in the network to fix the congestion in a systematic = manner. It is highly unlikely that RTCP feedback will be able to change = the rate of a flow in such a system. It is more likely that the system = would take other actions, but that is probably beyond the scope of this = document. =20 If a host is unable to read the ECN bits, it can't join an ECN-enabled = flow? This seems to be quite onerous, and will likely slow down the = adoption of ECN for RTP - particularly in the IPTV multicast case. If an = operator needs to dual carry hundreds of video channels (one ECN marked = and one not ECN marked), he will simply not implement ECN. I need to = think about this a bit more and see if there is a way to make this work. = My first instinct was to add a field/bit pattern to the RTCP feedback = that says " I joined the ECN enabled flow, but can't actually read the = ECT/ECN markings". However, let's think about na=EFve receivers that do = not understand the ECN SDP. They will ignore that SDP line, and join the = flow. They will provide their normal feedback, without the ECT/ECN = portions. How is this different from a receiver that knows about ECN, = but is unable to actually read the ECN bits? Maybe we just treat it like = a legacy receiver that does not know about the ECN SDP....... So, we = need to think about three receiver populations - fully ECN capable (as = currently described in this document), ECN aware in the application but = unable to read ECN bits (either acts like a legacy receiver or sends a = special RTCP feedback message), ECN unaware (ignores the SDP). I have = thought about this in the context of the declarative SDP case using leap = of faith, but need to think more about the offer/answer case and the = STUN case. We need a way to have each type of receiver unambiguously = join the same multicast flow. This would allow an operator to = incrementally deploy ECN on multicast flows. If we do not fix this, the = operator will be gated on the very last device in his deployment. =20 =20 It would be nice to have the RTCWEB folks take a courtesy look, as they = are envisioning some very interesting use cases. I do not think that = this presents any specific challenges, but it would be good to have = those eyeballs. I see that at least a few of them have provided = comments......... =20 =20 =20 A few minor points and a bit more specificity on the major = points------------ =20 There is a delicate balancing act between providing timely congestion = notifications to the sender and sending feedback packets into a = congested network. It is not clear that the this balancing act is = discussed in enough detail in the document. An inexperienced implementer = may "do the wrong thing" and send packets to freely, thus making the = congestion worse. Perhaps a short paragraph in the introduction would = make this clear? Perhaps a paragraph at the end of Page 11? Also in = section 7.3.2, as congestion is not highly featured in RFC4585 or = RFC3550. Congestion is mentioned in 7.3.2, as is feedback implosion, but = there is no warning about how they can interact. =20 =20 1---- Page 7 ECN support is more important for RTP sessions than, for instance, is the case for TCP. =20 This is a quite bold statement. I suspect that the following sentence is = closer to the truth, but it is truly a minor point. ECN support is as important for RTP sessions as it is for TCP. 2--- Page 13 ---- begin rant ---- I am always troubled by language discussing = signaling protocols and discovery in RTP documents. We all know that = declarative SDP is often used to configure endpoints. There is probably = nothing that needs to be changed in this section, but I am noting that = "declarative SDP" is not equal to a signaling protocol used for = discovery. --- end rant --- I need to think about the typical Service Provider use case- delivery of = IPTV to a very large population of receivers. The system is setup with = declarative SDP. Is the sender REALLY going to probe all of the = receivers and stop marking packets with ECN if a few receivers don't = respond? If you have a population of several million receivers at the = end of DSL lines, what are the odds of none of them being offline for a = few minutes? I would venture a guess that it is pretty small. In this = case, the "leap of faith" is probably what the network operator will = do....... So, I do not think I have a problem with this section, other = than the rant. 3--- Page 13 Considering again the case of the large Service Provider. The feedback = target for the flow is usually a repair device rather than the sender. = It is not clear from the text if the RTCP is going to the repair device = or the sender.=20 4--- Page 14 Is feedback send to the sender, or to the feedback target? Hopefully it = goes to the feedback target, or else you are going to have one hell of a = feedback storm in certain deployments. 5--- Page 15 I need to think about the case in which a large IPTV deployment is using = these methods, then one of the subscribers deploys a wireless gateway = that mangles ECT/ECN packets. It is not clear that the sender SHOULD = stop sending ECT/ECN marked packets. In a perfect world, the subscriber = would have a way to know that the problem is in the gateway..... I am = not sure we can fix this problem in the scope of this document, though. 6--- Page 15, and then sprinkled throughout the document Is feedback send to the sender, or to the feedback target? 7--- My SDP skills are suspect. It looked OK on a quick read, but = hopefully somebody is looking at this in detail. I am not sure I like = the setread/setonly/readonly semantics, but I do not have a = counter-proposal. 8--- Page 23 and 24 If a host is unable to read the ECN bits, it can't join an ECN-enabled = flow? This seems to be quite onerous, and will likely slow down the = adoption of ECN for RTP. This is particularly true of the "large IPTV = deployment" that wants to send multicast flows to STB, PC, Xbox, tablet, = etc. If there are millions of receivers, that means that there are = dozens/hundreds/thousands of device types. If the operator is gated on = having ECN support on all of the devices, this will never get deployed. = Perhaps we can change the feedback report to say " I joined the stream, = but can't actually read the ECN bits, so do not count me in your ECN = algorithm". 9--- section 7.2.1 If the feedback goes to a discrete feedback target, the system will have = to correlate the responses and send a summary to the original sender. 10 --- page 28 change For video formats, packets containing P- or B-frames, rather than = I-frames, would be an appropriate choice to For video formats, packets containing NULLS, P-frames or B-frames = (rather than I-frames), would be an appropriate choice 11--- page 29 For streams with millions of receivers (think IPTV and the World Cup = Final), the group will never be stable for three RTCP reporting = intervals. Perhaps a group associated with a given feedback target would = be stable for this long, but even that is marginal. =20 =20 BVS =20 =20 =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Roni Even Sent: Friday, September 30, 2011 8:29 AM To: avt@ietf.org Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 =20 Hi, I would like to start a WGLC on = http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit = Congestion Notification (ECN) for RTP over UDP. =20 The WGLC will end on October 21, 2011 =20 Please review the draft and send comments to the list. =20 =20 Roni Even =20 =20 =20 ------_=_NextPart_001_01CC88DE.78CF251A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Magnus, Roni –

 

Congestion control is an = important area, and I support this document moving forward=A0 after we = take care of some issues.

 

In this note, I list a = few important points, followed by some less important = comments.

 

Important points = -

 

 

For the multicast case, = we need to make it clear that feedback goes to the feedback target, = which may be a different device than the source. This document = consistently says “feedback goes to the source”, which is = misleading. See the detailed comments below for the places in which I = found it to be most concerning. When viewed in the context of feedback = going to a discrete feedback target at the network egress edge (like = typical IPTV deployments), it makes sense for the feedback target to use = these reports as diagnostic in nature. Perhaps the network has changed = topology and caused a bottleneck link to appear, and the feedback is = triggering action in the network to fix the congestion in a systematic = manner. It is highly unlikely that RTCP feedback will be able to change = the rate of a flow in such a system. It is more likely that the system = would take other actions, but that is probably beyond the scope of this = document.

 

If a host is unable to = read the ECN bits, it can’t join an ECN-enabled flow? This seems = to be quite onerous, and will likely slow down the adoption of ECN for = RTP – particularly in the IPTV multicast case. If an operator = needs to dual carry hundreds of video channels (one ECN marked and one = not ECN marked), he will simply not implement ECN. I need to think about = this a bit more and see if there is a way to make this work. My first = instinct was to add a field/bit pattern to the RTCP feedback that says = “ I joined the ECN enabled flow, but can’t actually read the = ECT/ECN markings”. However, let’s think about na=EFve = receivers that do not understand the ECN SDP. They will ignore that SDP = line, and join the flow. They will provide their normal feedback, = without the ECT/ECN portions. How is this different from a receiver that = knows about ECN, but is unable to actually read the ECN bits? Maybe we = just treat it like a legacy receiver that does not know about the ECN = SDP....... So, we need to think about three receiver populations – = fully ECN capable (as currently described in this document), ECN aware = in the application but unable to read ECN bits (either acts like a = legacy receiver or sends a special RTCP feedback message), ECN unaware = (ignores the SDP). I have thought about this in the context of the = declarative SDP case using leap of faith, but need to think more about = the offer/answer case and the STUN case. We need a way to have each type = of receiver unambiguously join the same multicast flow. This would allow = an operator to incrementally deploy ECN on multicast flows. If we do not = fix this, the operator will be gated on the very last device in his = deployment.

 

 

It would be nice to have = the RTCWEB folks take a courtesy look, as they are envisioning some very = interesting use cases. I do not think that this presents any specific = challenges, but it would be good to have those eyeballs. I see that at = least a few of them have provided = comments………

 

 

 

A few minor points and a = bit more specificity on the major = points------------

 

There is a delicate = balancing act between providing timely congestion notifications to the = sender and sending feedback packets into a congested network. It is not = clear that the this balancing act is discussed in enough detail in the = document. An inexperienced implementer may “do the wrong = thing” and send packets to freely, thus making the congestion = worse. Perhaps a short paragraph in the introduction would make this = clear? Perhaps a paragraph at the end of Page 11? Also in section 7.3.2, = as congestion is not highly featured in RFC4585 or RFC3550. Congestion = is mentioned in 7.3.2, as is feedback implosion, but there is no warning = about how they can interact.

 

 

1---- Page = 7

=A0=A0 ECN support = is more important for RTP sessions than, for instance, = is

=A0=A0 = the case for TCP.

 

This is a quite bold statement. I suspect that = the following sentence is closer to the truth, but it is truly a minor = point.

ECN support is as = important for RTP sessions as it is =A0for = TCP.

2--- Page 13

---- begin rant ---- I = am always troubled by language discussing=A0 signaling protocols and = discovery in RTP documents. We all know that declarative SDP is often = used to configure endpoints. There is probably nothing that needs to be = changed in this section, but I am noting that “declarative = SDP” is not equal to a signaling protocol used for discovery. --- = end rant ---

I need to think about the typical Service = Provider use case- delivery of IPTV to a very large population of = receivers. The system is setup with declarative SDP. Is the sender = REALLY going to probe all of the receivers and stop marking packets with = ECN if a few receivers don’t respond? If you have a population of = several million receivers at the end of DSL lines, what are the odds of = none of them being offline for a few minutes? I would venture a guess = that it is pretty small. In this case, the “leap of faith” = is probably what the network operator will do……. So, I do = not think I have a problem with this section, other than the = rant.

3--- Page 13

Considering again the = case of the large Service Provider. The feedback target for the flow is = usually a repair device rather than the sender. It is not clear from the = text if the RTCP is going to the repair device or the sender. =

4--- Page 14

Is feedback send to the = sender, or to the feedback target? Hopefully it goes to the feedback = target, or else you are going to have one hell of a feedback storm in = certain deployments.

5--- Page 15

I need to think about = the case in which a large IPTV deployment is using these methods, then = one of the subscribers deploys a wireless gateway that mangles ECT/ECN = packets. It is not clear that the sender SHOULD stop sending ECT/ECN = marked packets. In a perfect world, the subscriber would have a way to = know that the problem is in the gateway….. I am not sure we can = fix this problem in the scope of this document, = though.

6--- Page 15, and then sprinkled throughout the = document

Is feedback send to the sender, or to the = feedback target?

7--- My SDP skills are suspect. It looked OK on = a quick read, but hopefully somebody is looking at this in detail. I am = not sure I like the setread/setonly/readonly semantics, but I do not = have a counter-proposal.

8--- Page 23 and 24

If a host is unable to = read the ECN bits, it can’t join an ECN-enabled flow? This seems = to be quite onerous, and will likely slow down the adoption of ECN for = RTP. This is particularly true of the “large IPTV = deployment” that wants to send multicast flows to STB, PC, Xbox, = tablet, etc. If there are millions of receivers, that means that there = are dozens/hundreds/thousands of device types. If the operator is gated = on having ECN support on all of the devices, this will never get = deployed. Perhaps we can change the feedback report to say “ I = joined the stream, but can’t actually read the ECN bits, so do not = count me in your ECN algorithm”.

9--- section = 7.2.1

If the feedback goes to a discrete feedback = target, the system will have to correlate the responses and send a = summary to the original sender.

10 --- page = 28

change

For video formats, = packets containing P- or B-frames, rather than = I-frames,

=A0=A0=A0=A0=A0 would be an appropriate = choice

to

For video formats, = packets containing NULLS, P-frames or B-frames (rather than = I-frames),

=A0=A0=A0=A0=A0 would be an appropriate = choice

11--- page = 29

For streams with millions of receivers (think = IPTV and the World Cup Final), the group will never be stable for three = RTCP reporting intervals. Perhaps a group associated with a given = feedback target would be stable for this long, but even that is = marginal.

 

 

BVS

 

 

 

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.or= g] On Behalf Of Roni Even
Sent: Friday, September = 30, 2011 8:29 AM
To: avt@ietf.org
Subject: = [AVTCORE] WGLC on = draft-ietf-avtcore-ecn-for-rtp-04

 

Hi,

I would =
like to start a WGLC on htt=
p://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , =
Explicit =
Congestion Notification (ECN) for RTP over =
UDP.
 =

The WGLC will = end on October 21, 2011

 

Please = review the draft and send comments to the list.

 

 

Roni = Even

 

 =

 

------_=_NextPart_001_01CC88DE.78CF251A-- From dwing@cisco.com Thu Oct 13 10:35:08 2011 Return-Path: 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 05A8F21F88B7 for ; Thu, 13 Oct 2011 10:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.221 X-Spam-Level: X-Spam-Status: No, score=-102.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 anQ7xuKQ+0NM for ; Thu, 13 Oct 2011 10:35:07 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6231421F8678 for ; Thu, 13 Oct 2011 10:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2432; q=dns/txt; s=iport; t=1318527307; x=1319736907; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=xmkgnfw0xlVhthCskDjzXf9cYJOpN047w4ZJ9V9xhIE=; b=PEWi9fUuYVGKc03ut+f000t3artv1bu24w5galmEk7zqe+/DcndmlCS6 N8vbNi8xOrQruNhVqbItGFoUFk0dPF5TLrVDQNSjcayqRp2xxnHPpV9gD KH+chWlKv2UIWMiLavq3/U06KbMtRJFIdX7m9UIaG2XHzjFk5Jz3HGpKZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEAAIYgl06rRDoG/2dsb2JhbABDmTSBbI05gQWBUwEBAQQICgEVAhBLAQMCCQ8CBAEBKAcZIwoJCAEBBAESCxeHZJlFAZ4wh20EiAGdbA X-IronPort-AV: E=Sophos;i="4.69,341,1315180800"; d="scan'208";a="7706926" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 13 Oct 2011 17:35:06 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9DHZ5VC003960; Thu, 13 Oct 2011 17:35:06 GMT From: "Dan Wing" To: , References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> In-Reply-To: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> Date: Thu, 13 Oct 2011 10:35:05 -0700 Message-ID: <008b01cc89ce$724dee80$56e9cb80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx/bJMAZn1O9EdQQ6OkqDNm9OOyyQKYIHzQ Content-Language: en-us Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 17:35:08 -0000 Two comments: 1. The section http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04#section-7.2.2 does not seem to discuss what happens if the ECN-marked ICE messages are discarded (e.g., by an aggressive firewall). This seems to be an oversight. For this to work better, I suggest sending two STUN messages, back to back: one with ECN set and the other with ECN clear. If the response to the ECN-set message isn't received within, say, 20% of the time for the ECN-cleared message, assume ECN-marked messages are being dropped/filtered. Note one of the non-ECN'd messages can be the normal ICE exchange, so if you're already doing ICE I am not proposing any additional messages on the wire. I expect the other packet probes (RTP/RTCP probes) may need similar consideration / adjustment. 2. The section http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04#section-7.2.2 can be summarized as: a. do normal ICE b. use ICE messages to do an ECN validation c. if (b) showed ECN worked, start sending RTP with ECN. d. if (b) showed ECN failed, start sending RTP without ECN. Step (b-d) adds additional call setup time, which is undesirable. Instead, I would prefer changing two aspects: (1) not relying or caring about an initial ICE transaction (which means we can have both endpoints merely do ICE-Lite, if they wish -- we only need to know they will respond to ICE, really -- we don't need all of the other ICE overhead to use ICE to test the path is ECN capable), and (2) sending non-ECN'd RTP without waiting. That can be summarized as: a. immediately start sending RTP without ECN b. use ICE messages to do ECN validation c. if (b) showed ECN worked, start sending RTP with ECN. d. if (b) showed ECN failed, start sending RTP without ECN. -d > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Roni Even > Sent: Friday, September 30, 2011 5:29 AM > To: avt@ietf.org > Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 > > Hi, > > I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf- > avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP > over UDP. > > > The WGLC will end on October 21, 2011 > > > > Please review the draft and send comments to the list. > > > > > > Roni Even > > > > > > From magnus.westerlund@ericsson.com Fri Oct 14 06:14:50 2011 Return-Path: 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 6219721F8C5E for ; Fri, 14 Oct 2011 06:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 lZjR7qT2mJzH for ; Fri, 14 Oct 2011 06:14:49 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 515C221F8C52 for ; Fri, 14 Oct 2011 06:14:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-c0-4e9835c87c7c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 53.A6.13753.8C5389E4; Fri, 14 Oct 2011 15:14:48 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Fri, 14 Oct 2011 15:14:48 +0200 Message-ID: <4E9835C6.6040408@ericsson.com> Date: Fri, 14 Oct 2011 15:14:46 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: IETF AVTCore WG References: <20111014123417.23644.32150.idtracker@ietfa.amsl.com> In-Reply-To: <20111014123417.23644.32150.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.2 X-Forwarded-Message-Id: <20111014123417.23644.32150.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------040004000400010303050902" X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-transport-multiplexing-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 13:14:50 -0000 --------------040004000400010303050902 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit WG, I have submitted a draft that looks at the case of multiplexing multiple RTP sessions over the same lower layer transport. Feedback is appreciated. Cheers Magnus --------------040004000400010303050902 Content-Type: message/rfc822; name="I-D Action: draft-westerlund-avtcore-transport-multiplexing-00_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="I-D Action: draft-westerlund-avtcore-transport-multiplexing-"; filename*1="00_txt.eml" Received: from mailgw2.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.95) with Microsoft SMTP Server id 8.3.137.0; Fri, 14 Oct 2011 14:34:28 +0200 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AD.E1.09133.35C289E4; Fri, 14 Oct 2011 14:34:28 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE25921F8B98; Fri, 14 Oct 2011 05:34:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7045621F8BA2 for ; Fri, 14 Oct 2011 05:34:17 -0700 (PDT) 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 kSHIgwqcOEk5 for ; Fri, 14 Oct 2011 05:34:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071C921F8B2A for ; Fri, 14 Oct 2011 05:34:17 -0700 (PDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Sender: "i-d-announce-bounces@ietf.org" Date: Fri, 14 Oct 2011 14:34:17 +0200 Subject: I-D Action: draft-westerlund-avtcore-transport-multiplexing-00.txt Thread-Topic: I-D Action: draft-westerlund-avtcore-transport-multiplexing-00.txt Thread-Index: AcyKbZ1gCn9nnCY/QgS6MPD0rUb8vg== Message-ID: <20111014123417.23644.32150.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "internet-drafts@ietf.org" Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0247.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb25-b7cb3ae0000023ad-bc-4e982c53a8fd x-brightmail-tracker: AAAAAA== dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1318595660; bh=qPRsXQoVXKWliHVO2sAWGnTzXfG604RqNO7yyfRz11g=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ydhiHMWvYIPxd4/koO1BEIIKfT8t09FagJ/75qGZTjGVEs6fALdsvm3nMVYGV0+U0 tIvBZTzysUxfdfYMJGE1F60YVenbQfSRvDTzzOxLStrb1E9n29nGLY4CMDx9uK7st3 IXpmuFw4XdGP4ywCPp28+faVhq5HS1orbx7bklro= errors-to: i-d-announce-bounces@ietf.org x-virus-scanned: amavisd-new at amsl.com x-mailman-version: 2.1.12 list-post: list-archive: list-id: Internet Draft Announcements only x-beenthere: i-d-announce@ietf.org x-spam-level: x-spam-status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] x-spam-score: -102.574 x-spam-flag: NO delivered-to: i-d-announce@ietfa.amsl.com x-original-to: i-d-announce@ietfa.amsl.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Multiple RTP Session on a Single Lower-Layer Transport Author(s) : Magnus Westerlund Filename : draft-westerlund-avtcore-transport-multiplexing-00.txt Pages : 23 Date : 2011-10-14 This document specifies how multiple RTP sessions are to be multiplexed on the same lower-layer transport, e.g. a UDP flow. It discusses various requirements that have been raised and their feasibility, which results in a solution with a certain applicability. A solution is recommended and that solution is provided in more detail, including signalling and examples. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westerlund-avtcore-transport-mult= iplexing-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-westerlund-avtcore-transport-multi= plexing-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------040004000400010303050902-- From p.ohanlon@gmail.com Fri Oct 14 07:55:09 2011 Return-Path: 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 1713921F8C80 for ; Fri, 14 Oct 2011 07:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_84=0.6, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-1] 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 5B-cbCNDmfB3 for ; Fri, 14 Oct 2011 07:55:07 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65E2321F8C7F for ; Fri, 14 Oct 2011 07:55:07 -0700 (PDT) Received: by ggnk3 with SMTP id k3so1405357ggn.31 for ; Fri, 14 Oct 2011 07:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=MqTpKM743TLaZSYwdYr/0vT1yvdzx5XYF+P1H86efH8=; b=EPQMoWogVOTWA7OTui2Bj0OF8JKTaQbGiGOEycNdPS5R54Mv66ttKllHeeE0SfMjHv fgaM3CBBqyR6+Oa35XfsREbglgJ7TDIinzntECEYPzj5hd3KP2hheuo1N7Pq7xj5hc9I NHM89hPi//wAW0WR/dzfufIlSgsPZD+T1oSa4= Received: by 10.42.154.194 with SMTP id r2mr16757624icw.50.1318604104077; Fri, 14 Oct 2011 07:55:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.169.66 with HTTP; Fri, 14 Oct 2011 07:54:44 -0700 (PDT) In-Reply-To: <76AADF1A61784B52A8516E16AAF78E71@china.huawei.com> References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <76AADF1A61784B52A8516E16AAF78E71@china.huawei.com> From: "Piers O'Hanlon" Date: Fri, 14 Oct 2011 15:54:44 +0100 Message-ID: To: Qin Wu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Magnus Westerlund , avt@ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 14:55:09 -0000 Dear Qin, Thanks for your feedback. Comments inline [omitting Thomas's clarifications= ] On 11 October 2011 03:46, Qin Wu wrote: > Hi, > I have reviewed this draft and=A0support it moving towards publication. > Here is my minor editional comments to this 04 version draft. > 1. Section 1 > [Qin]:Is it better to move the first paragraph next to the third paragrap= h. > > 2. Section 3, 1st paragraph > " > =A0=A0 ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], > =A0=A0 and DCCP [RFC4340] transports.=A0These are all unicast protocols w= hich > =A0=A0 negotiate the use of ECN during the initial connection establishme= nt > =A0=A0 handshake (supporting incremental deployment, and checking if ECN > =A0=A0 marked packets pass all middleboxes on the path). > " > [Qin]: I think "these"=A0 in the second sentence can't be "ECN" > mentioned in the first sentence. Is it better to replace "these" > the first word in this sentence=A0with "these transport"? > The 'these' in the second sentance refers to the transport protocols (not ECN). I think the existing wording is probably ok. > " > =A0=A0 ECN-CE marks are > =A0=A0 immediately echoed back to the sender by the receiving end-point > =A0=A0 using an additional bit in feedback messages, and the sender then > =A0=A0 interprets the mark as equivalent to a packet loss for congestion > =A0=A0 control purposes. > " > > [Qin]: For this sentence, it is not clear to me what is the=A0 feedback > message? > Is feedback message a new RTCP Feedback message=A0defined in this > document or TCP message or SCTP message? If it is=A0latter, I would like > to change it as these transport protocols header > This paragraph is aiming to describe the existing ECN enabled transport protocols so it does not refer to RTCP/AVPF messages. We have attempted to describe the feedback process in a generic way as they all have their own way of fee= ding back the ECN state information - so there is inevitably some lack of specificity. > 4. Section 3.1 > > [Qin]: Any requirements that should be met by the middlebox or intermedia= te > node? > These are just a list of requirements on the protocol - and correspondingly on any equipment that implements this protocol (which could include a middlebox, intermediate node, MCU, router etc). So such support is implied for any of these boxes. > > 5. Section 3.2,3rd paragraph > " > =A0=A0 Topo-Point-to-Point:=A0 This is a standard unicast flow. > =A0=A0 .... > " > > [Qin]: Topo-point-to-point is not flow but a topology. Should this senten= ce > be > rephrased as "This is for a standard unicast flow". > This may benefit from some rewording. > " > Accordingly, we allow ECN to be used=A0by an RTP sender using multicast U= DP > provided the sender has=A0verified that the paths to all its known receiv= ers > support ECN, > and irrespective of whether the paths from other senders to their=A0recei= vers > support ECN > ("all its known receivers" are all the SSRCs=A0that the RTP sender has > received RTP or RTCP > from the last five=A0reporting intervals, i.e., they have not timed out). > " > [Qin]: Five is default value of the timeout multiplier, do you think othe= r > value=A0is not allowed? > That issue is down to compliance with the RTP spec: http://tools.ietf.org/html/rfc3550#section-6.3.5 Where 5 is specified as the default value, so in principle it's possible to choose something else but that could lead to problems. > " > Since only a subset=A0 of the RTP packets generated by a sender are forwa= rded > to the > =A0receivers, a video switching MCU can break ECN negotiation (the=A0succ= ess of > the > ECN negotiation may depend on the voice activity of=A0 the participant at= the > instant the > =A0negotiation takes place - shout=A0 if you want ECN). > " > > [Qin]: Is "shout if you want ECN" appropirate language here? > Well it serves the purpose - given that this not a recommended topology and is shall not be used with ECN. > > 6. Section 3.2, 4th paragraph > " > =A0This is a great benefit as the rate of an > =A0RTP session can be varied in a number of ways, > " > [Qin]: Should "rate" in this sentence be data rate or bitrate? > It is intentionally left open as one could alter the bit/byte rate or the packet rate. > 7. Section 3.2, 5th paragraph > " > The standard RTP/=A0AVP profile [RFC3551] does not allow any early or > immediate > transmission of RTCP feedback, and has a minimal RTCP interval whose=A0de= fault > value > =A0(5 seconds) is many times the normal RTT between sender=A0and receiver= . > " > [Qin]: What's the purpose of last sentence of this paragraph? > =A0=A0=A0=A0=A0=A0 Are you saying RFC3551 following Regular RTCP timing r= ule? > =A0=A0=A0=A0=A0=A0 or something else? > Yes - That sentence is just reiterating the RFC3551 timing rules so that the read may understand the limitations of using that approach (as opposed to employing AVPF). > =A0=A0 Another question is according to RFC3551, the negotiation of > =A0=A0 parameters or membership control may be not support. in other wond= er, > =A0=A0 there may be no way to negotiate ECN with RTP using SDP signaling, > =A0=A0 I am wondering can we say ECN with RTP can be used with the standa= rd RTP/ > =A0=A0 AVP profile [RFC3551]. > We have explicitly mentioned that it is possible to use RFC3551 but performance may be limited. RFC3551 doesn't have any impact upon the SDP negotiations. > 8. Section 3.3,3rd paragraph > " > =A0=A0 For interoperability we mandate the implementation of the RTP/AVPF > =A0=A0 profile, with both RTCP extensions and the necessary signalling to > =A0=A0 support a common operations mode.=A0 This specification recommends= the > =A0=A0 use of RTP/AVPF in all cases as negotiation of the common > =A0=A0 interoperability point requires RTP/AVPF, mixed negotiation of RTP= / > =A0=A0 AVP and RTP/AVPF depending on other SDP attributes in the same med= ia > =A0=A0 block is difficult, > " > [Qin] How mixed negotiation is avoided when you don't put all the SDP > attribute > =A0into the same media block? I don't really understand the rationale. Wo= uld > you like to clarify a little bit? > > 9. Section 4, 1st paragraph > " > 2.=A0 Initiation and initial verification of ECN capable transport > " > =A0[Qin]: It looks the bullet 2 has two steps, > =A0a. Initiation procedure > =A0b. inital verification procedure, If there is no STUN exchange in betw= een, > if the step (a) initiation procedure > =A0is required? > This list is meant to describe the overall pieces of the solution - not necessarily every single step. > 10. Section 4, 2nd paragraph > " > This document defines the information that=A0needs to be negotiated, and > provides a mapping to SDP > for use in both=A0declarative and offer/answer contexts. > " > [Qin]: Would it be better to add an anchor pointing to the section 6.1.1 = and > 6.1.2? > I'm not sure if that is necessary. > 11. Section 4, 3rd paragraph > " > =A0=A0 o=A0 The sender may generate a (small) subset of its RTP data pack= ets > =A0=A0=A0=A0=A0 with the ECN field set to ECT(0) or ECT(1). > " > > [Qin] It is not clear to me where the ECN field is located. > Is ECN field in the IP header or UDP header or RTP header? > > 12. Section 5, 1st paragraph > " > =A0=A0 This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585] > =A0=A0 transport layer feedback format for urgent ECN information, > " > =A0[Qin]: Should the "urgent ECN information" be "urgent ECN information > reporting" > > 13.Section 5.1,1st paragraph > " > =A0=A0 This RTP/AVPF transport layer feedback format is intended for use = in > =A0=A0 RTP/AVPF early or immediate feedback modes when information needs = to > =A0=A0 urgently reach the sender.=A0 Thus its main use is to report recep= tion > =A0=A0 of an ECN-CE marked RTP packet so that the sender may perform > =A0=A0 congestion control, or to speed up the initiation procedures by > =A0=A0 rapidly reporting that the path can support ECN-marked traffic. > " > > [Qin]: are you saying slow initiation procedure may result in network > congestion? > In my understanding, when ECN-CE marked packet is received, the only choi= ce > for sender > is to do congestion control since you are not sure if initiation procedur= e > lead to such > congestion. If it is not intiation procedure that lead to congestion, you > get risk to worse > congestion condition? > > 14.Section 6.1, 1st paragraph > " > =A0=A0 One new SDP attribute, "a=3Decn-capable-rtp", is defined.=A0 This = is a > =A0=A0 media level attribute, and MUST NOT be used at the session level.= =A0 It > =A0=A0 is not subject to the character set chosen. > " > > [Qin] Would it better to put reference to the section 6 of RFC4566 for > character set? > Since it is independent of the character set it is probably necessary to add the reference. > 15. Sectioin 6.1, 2nd paragraph > " > =A0=A0 ect:=A0 This parameter makes it possible to express the preferred = ECT > =A0=A0=A0=A0=A0 marking.=A0 This is either "random", "0", or "1", with "0= " being > =A0=A0=A0=A0=A0 implied if not specified.=A0 The "ect" parameter describe= s a > =A0=A0=A0=A0=A0 receiver preference, and is useful in the case where the = receiver > =A0=A0=A0=A0=A0 knows it is behind a link using IP header compression, th= e > =A0=A0=A0=A0=A0 efficiency of which would be seriously disrupted if it we= re to > =A0=A0=A0=A0=A0 receive packets with randomly chosen ECT marks.=A0 It is = RECOMMENDED > =A0=A0=A0=A0=A0 that ECT(0) marking be used. > " > > [Qin]: It looks ect is not well specified here. > e.g.,what it means if ect is set to "random" or "1"=A0from above paragrap= h. > what does "randomly chosen" stand for? > I think when ect is set 0, it means ECT(0) is chosen, when ect is set 1, > it means ECT(1) is chosen, when ect is set random, it means either ECT(0)= or > ECT(1) is chosen. I think it should be clear in the text. > As you explain that is what is meant in the paragraph. It seems fairly clear as we have put it - Though the mapping between "0" and ECT(0) is not explicitly mentioned till the end so we may need to address this. > Also I think the text like ""0" being=A0implied if not specified" in this > paragraph is not correct. > This is correct - it just another way of saying this the default value but the current wording makes sense > 16. Section 6.1.3, 2nd paragraph > " > If timely feedback is not required it is still RECOMMENDED > to used RTP/AVPF. > " > > [Qin]: Should "used" in this sentence be "use"? > Yes that needs changing. > 17.Section 7.1,2nd paragraph > " > The "rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used > whenever the initialization method or a congestion control algorithm > requiring timely sender side knowledge of received CE markings. > " > =A0[Qin]: Should "requiring" in this sentence be "requires"? > Yes that sentence may need some modification. > 18.Section 7.2, 2nd paragraph > " > =A0=A0 At the start of the RTP session, when the first packets with ECT a= re > =A0=A0 sent, it is important to verify that IP packets with ECN field val= ues > =A0=A0 of ECT or ECN-CE will reach their destination(s). > " > [Qin]: Should "first packets" be "first packet" and "IP packets" be "IP > packet"? > No - as there are more than of these packets. > " > If the path between=A0the sender and the receivers exhibits either of the= se > behaviours one > " > [Qin]: s/the receivers/receiver > I'm not sure that is necessary. > " > If the path between=A0the sender and the receivers exhibits either of the= se > behaviours one > =A0needs to stop using ECN immediately to protect both the network and > =A0the application. > " > =A0[Qin]: How does sender or receiver detects ECN is misused? Who is the > =A0 "one" in this sentence? If it is middlebox, the middlebox should also > =A0tell the sender ECN is not used. > As mentioned earlier in the section the "behaviours" will be detected by th= e end-systems. The 'one' is the parties involved in the connection setup - wh= ich could in certain cases be a 'middlebox' - but that doesn't need to be expli= citly covered here. > 19.Section 7.2.1, 1st paragraph > " > =A0Then any=A0resulting lack of congestion response is likely to have lit= tle > =A0damaging affect on others. > " > > [Qin] s/affect/effect > I think you're correct there. > " > Note: The above optimization supports peer to peer unicast > transport with several SSRCs multiplexed onto the same flow > (e.g., a single participant with two video cameras, or SSRC > multiplexed RTP retransmission [RFC4588]).=A0 It is desirable to > " > [Qin]: In SSRC multiplexed RTP Retransmission case, original stream and > associated retransmission > =A0=A0=A0=A0=A0=A0=A0 stream possible have different > =A0=A0=A0=A0=A0=A0=A0 transport characteristics, however the original str= eam may be > multicast stream, which contradict to > =A0=A0=A0=A0=A0=A0=A0 what you said about "The above optimization support= s peer to peer > unicast > =A0=A0=A0=A0=A0=A0=A0=A0 transport", am I wrong? > " In the case of multicast the optimisation wouldn't apply. > be able to rapidly negotiate ECN support for such a session, > but the optimisation above can fail if there are > implementations that use the same CNAME for different parts of > a distributed implementation that have different transport > characteristics (e.g., if a single logical endpoint is split > across multiple hosts). > " > [Qin]: I don't get this example clearly. are you saying when two streams > with=A0the same CNAME > is sent from the same RTP sender, such above optimization applies.However > when two streams > with the same CNAME are sent from two differnt RTP entities,such above > optimization can not apply. > For the first part you are correct, but the the two stream case only talks about a 'logical endpoint' i.e. a single RTP endpoint which is split over multiple hosts, not separate RTP endpoints. > 20. Section 7.2.2,1st paragraph > " > This section describes an OPTIONAL method that can be used to avoid > media impact and also ensure an ECN capable path prior to media > " > [Qin]: What's the media impact? It looks like a new term that needs to be > explained somewhere. > It refers to the effect of the ECN path discovery mechanisms that need to b= e normally employed at session initiation. We could explain this a little bet= ter. > 21. Section 7.2.2,3rd paragraph > " > =A0A STUN server thatdoesn't understand the extension, or is incapable of > =A0reading the ECN=A0values on incoming STUN packets, should follow the r= ule in > the STUN > =A0specification for unknown comprehension-optional attributes, and ignor= e the > attribute, > =A0resulting in the sender receiving a STUN response without the ECN Chec= k > STUN attribute. > > " > [Qin]: Is the sender in this sentence "the media sender" or new participa= nt? > The sender would be the entity that sent the STUN message in the first plac= e. > 22. Section 7.2.2, last paragraph > " > =A0If that is successfully completed the ECT properties of the session ar= e > =A0maintained for the other senders in the session. > " > [Qin]: Who is the other senders? are the other senders "new participant" > =A0or other participants? It should be clear in the text. > The other senders are the other existing participants (i.e. Not the new participant). > 23. Section 7.3, 1st paragraph > " > =A0=A0 Once ECN has been successfully initiated for an RTP sender, that > =A0=A0 sender begins sending all RTP data packets as ECT-marked, and its > =A0=A0 receivers send ECN feedback information via RTCP packets.=A0 This > =A0=A0 section describes procedures for sending ECT-marked data, providin= g > =A0=A0 ECN feedback information via RTCP, responding to ECN feedback > =A0=A0 information, and detecting failures and misbehaving receivers. > " > [Qin]It looks failure detection is discussed in different section, i.e., > section 7.4. > =A0Suggest to remove ", and detecting failures and misbehaving receivers"= from > this paragraph. > Agreed. > 24. Section 7.3.1, 2nd paragraph > " > =A0The sender SHALL NOT include ECT marks on outgoing RTCP packets, > " > [Qin]: Is it true, since RTP/AVPF Transport Layer ECN Feedback packet > include the satistics of ECT marks? > Yes - whilst the RTCP packet may contain information regarding the ECN mark= ings, they are not themselves ECT marked. > 25. Section 7.4.1,4th paragraph > " > load balancing=A0devices may in worst case result in that some packets ta= ke a > different network path then the others; > " > [Qin]: Should "then" in this sentence be "than" ? > No. > 26. Section 7.4.2, 4th paragraph > " > =A0=A0 The rate of packet duplication is tracked, allowing one to take th= e > =A0=A0 duplication into account.=A0 The value of the ECN field for duplic= ates > =A0=A0 will also be counted and when comparing the figures one needs to t= ake > " > [Qin]: What and where are the figures? > The 'figures' refers to the values of the various counters of ECN markings,= as explained earlier in the paragraph. > 27.Section 8.2,8th paragraph > " > =A0=A0 When rounding counter values in the translated RTCP packet, the > =A0=A0 translator should try to ensure that they sum to the number of RTP > =A0=A0 packets in the pre-translation sequence number space (numOrig).=A0= The > =A0=A0 translator should also try to ensure that no non-zero counter is > =A0=A0 rounded to a zero value, since that will lose information that a > =A0=A0 particular type of event has occurred.=A0 It is recognised that it= may > =A0=A0 be impossible to satisfy both of these constraints; > " > > [Qin]: What's the difficulty to satisfy both constraints, why non-zero > counter can be rounded into zero? what kind of round method is used? > can you explain a little bit? > Because the translator actually alters the packet stream there is not alway= s a clear mapping between the values taken from the original packets vs the translated packets. But if a particular event has been reported it is best = to report that event (e.g. ECN-CE marking) has occurred in the translated packets - but they may not always add up correctly if one wants to indicate that a marking is now 'spread' over more than one packet in the translated stream. The rounding used means that it shouldn't round down to zero unless the pre-translated values are zero. > 28.Section 8.4, 2nd paragraph > " > =A0=A0 An ECN-aware RTP mixer must generate RTCP ECN feedback packets and > =A0=A0 RTCP XR report blocks for ECN summary information relating to the = RTP > =A0=A0 flows it terminates, in exactly the same way it would if it were a= n > =A0=A0 RTP receiver.=A0 These reports form part of the congestion control= loop > =A0=A0 between the mixer and the media senders generating the streams it = is > =A0=A0 mixing.=A0 A separate control loop runs between each sender and th= e > =A0=A0 mixer. > " > > [Qin]: what's the difference between congestion control loop and a separa= te > control loop > =A0between media sender and mixer? are you saying congestion control loop= is > unidirectional? > This may needs clarifying a little, though basically the 'control loop' refers to the overall exchange of messages - which are then used to drive 'congestion con= trol loop'. The congestion control loop is not unidirectional. > 29. Section 12,1st paragraph > " > =A0=A0 This section contain a few different examples of the signalling > =A0=A0 mechanism defined in this specification in an SDP context.=A0 If t= here > =A0=A0 are discrepancies between these examples and the specification tex= t, > =A0=A0 the specification text is definitive. > " > [Qin]: Why discrepacies is allowed? Should these example be consistent wi= th > the sepcification text? > This a good point - we will take a look at them. > 30. Section=A012.1 > " > =A0=A0 This SDP offer offers a single media stream with 3 media payload > =A0=A0 types.=A0 It proposes to use ECN with RTP, with the ICE based > =A0=A0 initialization as being preferred over the RTP/RTCP one.=A0 Leap o= f > =A0=A0 faith is not suggested to be used.=A0 The offerer is capable of bo= th > =A0=A0 setting and reading the ECN bits.=A0 In addition the RTCP ECN feed= back > =A0=A0 packet is configured and the RTCP XR ECN summary report. > " > [Qin]: Are you saying both ECN feedback and the XR ECN summary > report are allowed and configured or something else? > Yes that probably needs a small clarification. We're basically saying that they're both supported - though not necessarily configured as yet, Thanks, Piers. > Regards! > -Qin > > > ----- Original Message ----- > From: Roni Even > To: avt@ietf.org > Sent: Friday, September 30, 2011 8:29 PM > Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 > > Hi, > > I would like to start a WGLC on > http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit > Congestion Notification (ECN) for RTP over UDP. > > > > The WGLC will end on October 21, 2011 > > > > Please review the draft and send comments to the list. > > > > > > Roni Even > > > > > > > > ________________________________ > > _______________________________________________ > 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 > > From bill.wu@huawei.com Mon Oct 17 19:48:58 2011 Return-Path: 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 1C4B621F8AA8 for ; Mon, 17 Oct 2011 19:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.363 X-Spam-Level: X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, 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 WVIJlvUXgRZ7 for ; Mon, 17 Oct 2011 19:48:57 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 731A221F8A7E for ; Mon, 17 Oct 2011 19:48:56 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT800K8AQHJR5@szxga04-in.huawei.com> for avt@ietf.org; Tue, 18 Oct 2011 10:48:55 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT800971QHABX@szxga04-in.huawei.com> for avt@ietf.org; Tue, 18 Oct 2011 10:48:55 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEM72103; Tue, 18 Oct 2011 10:48:55 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 10:48:52 +0800 Received: from w53375q (10.138.41.130) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 10:48:46 +0800 Date: Tue, 18 Oct 2011 10:48:46 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Colin Perkins Message-id: <43C968D510D24719AD6A1A6D37449559@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <20110926081759.16674.85402.idtracker@ietfa.amsl.com> <9F1217B1416045A987E6B48A4CC87037@china.huawei.com> <34C8727C-BD15-460B-9107-05C683B2B39C@csperkins.org> Cc: avt@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 02:48:58 -0000 Sorry for late reply. please see inline. ----- Original Message ----- From: "Colin Perkins" To: "Qin Wu" Cc: Sent: Tuesday, October 11, 2011 10:13 PM Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt Qin, On 11 Oct 2011, at 09:11, Qin Wu wrote: > Hi, Colin: > Thank for your careful review, please see my replies belows. > > Regards! > -Qin > ----- Original Message ----- > From: "Colin Perkins" > To: > 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-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"? > > [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. 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]: 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. >> - 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. 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]: 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? >> - 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? 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. [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. >> - 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 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. [Qin] Okay, I agree both approaches are possible. I will make this clear in the relevant text. -- Colin Perkins http://csperkins.org/ From bill.wu@huawei.com Mon Oct 17 23:14:41 2011 Return-Path: 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 DAFAD11E80C8 for ; Mon, 17 Oct 2011 23:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.478 X-Spam-Level: X-Spam-Status: No, score=-5.478 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, 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 GMs8PaLndqur for ; Mon, 17 Oct 2011 23:14:41 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD9111E8091 for ; Mon, 17 Oct 2011 23:14:40 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT90056J003P2@szxga04-in.huawei.com> for avt@ietf.org; Tue, 18 Oct 2011 14:14:27 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT8002AXZZZSV@szxga04-in.huawei.com> for avt@ietf.org; Tue, 18 Oct 2011 14:14:27 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEH09264; Tue, 18 Oct 2011 14:14:26 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 14:14:22 +0800 Received: from w53375q (10.138.41.130) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 14:14:19 +0800 Date: Tue, 18 Oct 2011 14:14:18 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Piers O'Hanlon Message-id: <4C7553D5AE4E4B7CB13038F3256FF536@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <76AADF1A61784B52A8516E16AAF78E71@china.huawei.com> Cc: Magnus Westerlund , avt@ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 06:14:42 -0000 Hi,Piers: You address most of my comments which are removed from this followup. Please see a few my remaining comments below. Regards! -Qin ----- Original Message ----- From: "Piers O'Hanlon" To: "Qin Wu" Cc: "Roni Even" ; ; "Magnus Westerlund" Sent: Friday, October 14, 2011 10:54 PM Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 Dear Qin, Thanks for your feedback. Comments inline [omitting Thomas's clarifications] On 11 October 2011 03:46, Qin Wu wrote: > Hi, > I have reviewed this draft and support it moving towards publication. > Here is my minor editional comments to this 04 version draft. > 1. Section 1 > [Qin]:Is it better to move the first paragraph next to the third paragraph. > > 2. Section 3, 1st paragraph > " > ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], > and DCCP [RFC4340] transports. These are all unicast protocols which > negotiate the use of ECN during the initial connection establishment > handshake (supporting incremental deployment, and checking if ECN > marked packets pass all middleboxes on the path). > " > [Qin]: I think "these" in the second sentence can't be "ECN" > mentioned in the first sentence. Is it better to replace "these" > the first word in this sentence with "these transport"? > The 'these' in the second sentance refers to the transport protocols (not ECN). I think the existing wording is probably ok. [Qin]: I know. But the problem is you change the subject in two consecutive sentences which looks ambiguity to me. that's why I suggest you to do some rewording. > " > ECN-CE marks are > immediately echoed back to the sender by the receiving end-point > using an additional bit in feedback messages, and the sender then > interprets the mark as equivalent to a packet loss for congestion > control purposes. > " > > [Qin]: For this sentence, it is not clear to me what is the feedback > message? > Is feedback message a new RTCP Feedback message defined in this > document or TCP message or SCTP message? If it is latter, I would like > to change it as these transport protocols header > This paragraph is aiming to describe the existing ECN enabled transport protocols so it does not refer to RTCP/AVPF messages. We have attempted to describe the feedback process in a generic way as they all have their own way of feeding back the ECN state information - so there is inevitably some lack of specificity. [Qin]: It looks not clear to me at the first glance since I misunderstood "the Feedback" as "RTCP Feedback message". But I am okay with your clarification. > " > If the path between the sender and the receivers exhibits either of these > behaviours one > needs to stop using ECN immediately to protect both the network and > the application. > " > [Qin]: How does sender or receiver detects ECN is misused? Who is the > "one" in this sentence? If it is middlebox, the middlebox should also > tell the sender ECN is not used. > As mentioned earlier in the section the "behaviours" will be detected by the end-systems. The 'one' is the parties involved in the connection setup - which could in certain cases be a 'middlebox' - but that doesn't need to be explicitly covered here. [Qin]: It is still not clear to me.If end system detects those behavior and one is the middlebox, how end systems that detects those behavior tellsthe middlebox that those behaviro occur, through dedicated ECN feedback message or any other means? or you assume the middlebox can be a receiver? > be able to rapidly negotiate ECN support for such a session, > but the optimisation above can fail if there are > implementations that use the same CNAME for different parts of > a distributed implementation that have different transport > characteristics (e.g., if a single logical endpoint is split > across multiple hosts). > " > [Qin]: I don't get this example clearly. are you saying when two streams > with the same CNAME > is sent from the same RTP sender, such above optimization applies.However > when two streams > with the same CNAME are sent from two differnt RTP entities,such above > optimization can not apply. > For the first part you are correct, but the the two stream case only talks about a 'logical endpoint' i.e. a single RTP endpoint which is split over multiple hosts, not separate RTP endpoints. [Qin]: In this case, CNAME is not enough to identify each of RTPendpoints. >From this perspective, I agree. Is that what you are saying? > 25. Section 7.4.1,4th paragraph > " > load balancing devices may in worst case result in that some packets take a > different network path then the others; > " > [Qin]: Should "then" in this sentence be "than" ? > No. [Qin]: Why? Using "different from" instead? > 26. Section 7.4.2, 4th paragraph > " > The rate of packet duplication is tracked, allowing one to take the > duplication into account. The value of the ECN field for duplicates > will also be counted and when comparing the figures one needs to take > " > [Qin]: What and where are the figures? > The 'figures' refers to the values of the various counters of ECN markings, as explained earlier in the paragraph. [Qin]: I misunderstood "figures" as "charts" or "drawings", Isn't worth better wording? > 27.Section 8.2,8th paragraph > " > When rounding counter values in the translated RTCP packet, the > translator should try to ensure that they sum to the number of RTP > packets in the pre-translation sequence number space (numOrig). The > translator should also try to ensure that no non-zero counter is > rounded to a zero value, since that will lose information that a > particular type of event has occurred. It is recognised that it may > be impossible to satisfy both of these constraints; > " > > [Qin]: What's the difficulty to satisfy both constraints, why non-zero > counter can be rounded into zero? what kind of round method is used? > can you explain a little bit? > Because the translator actually alters the packet stream there is not always a clear mapping between the values taken from the original packets vs the translated packets. But if a particular event has been reported it is best to report that event (e.g. ECN-CE marking) has occurred in the translated packets - but they may not always add up correctly if one wants to indicate that a marking is now 'spread' over more than one packet in the translated stream. The rounding used means that it shouldn't round down to zero unless the pre-translated values are zero. [Qin]: Thank for your clarfication, I am clear, it is better to replace " The translator should also try to ensure that no non-zero counter is rounded to a zero value " with your proposed text " The translator should also try to ensure that no non-zero counter is rounded to a zero value unless the pre-translated values are zero. " That will be more clear to me. Thanks, Piers. > Regards! > -Qin > > > ----- Original Message ----- > From: Roni Even > To: avt@ietf.org > Sent: Friday, September 30, 2011 8:29 PM > Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 > > Hi, > > I would like to start a WGLC on > http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit > Congestion Notification (ECN) for RTP over UDP. > > > > The WGLC will end on October 21, 2011 > > > > Please review the draft and send comments to the list. > > > > > > Roni Even > > > > > > > > ________________________________ > > _______________________________________________ > 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 > > From Even.roni@huawei.com Tue Oct 18 01:12:38 2011 Return-Path: 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 E025321F8B26 for ; Tue, 18 Oct 2011 01:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.213 X-Spam-Level: X-Spam-Status: No, score=-106.213 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 swEhaAJ5W5iH for ; Tue, 18 Oct 2011 01:12:38 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 53FEE21F8B1F for ; Tue, 18 Oct 2011 01:12:38 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT900M175EV6H@szxga04-in.huawei.com> for avt@ietf.org; Tue, 18 Oct 2011 16:11:20 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT9004F85EVNF@szxga04-in.huawei.com> for avt@ietf.org; Tue, 18 Oct 2011 16:11:19 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LT9007YX5ER4L@szxml12-in.huawei.com>; Tue, 18 Oct 2011 16:11:19 +0800 (CST) Date: Tue, 18 Oct 2011 10:08:52 +0200 From: Roni Even To: avt@ietf.org Message-id: <021f01cc8d6d$30090170$901b0450$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcyJ0tBv7Vrm/HztRrmpwVkSa79xxgDmWW0Q Cc: 'Magnus Westerlund' Subject: [AVTCORE] avtcore - session for IETF 82 - requests for agenda time. X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 08:12:39 -0000 Hi, This is the schedule for AVTcore. Note that the agenda is not final and can change. Final agenda will be published on October 21. Monday November 14th , Afternoon Session I 1300-1500 Room Name: 101C If you wish to have agenda time at the upcoming meeting in Taipei regarding AVTcore work, please send an agenda request to the AVTcore chairs. We are trying to prepare the agenda early and not wait for the last minute. Roni Even AVTcore co-chair From magnus.westerlund@ericsson.com Wed Oct 19 02:09:01 2011 Return-Path: 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 7754321F8BAD for ; Wed, 19 Oct 2011 02:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 fXtuI47PSfa5 for ; Wed, 19 Oct 2011 02:09:00 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3F121F8A55 for ; Wed, 19 Oct 2011 02:08:59 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-5f-4e9e93aa8fe9 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8C.6E.20773.AA39E9E4; Wed, 19 Oct 2011 11:08:59 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 19 Oct 2011 11:08:58 +0200 Message-ID: <4E9E93A0.10701@ericsson.com> Date: Wed, 19 Oct 2011 11:08:48 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Qin Wu References: <4E8D76C1.5080508@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVTCore WG , "draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org" Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 09:09:01 -0000 Hi, Sorry for the delay in following up. I have removed the issues which don't need further discussion. On 2011-10-11 03:40, Qin Wu wrote: > Hi, Magnus, > Thank for your valuable review, please see my replies belows. > ----- Original Message ----- > From: "Magnus Westerlund" 2. Section 3. > "The timer value shall be > based on the observed round-trip time. A receiver should compute an > estimate of the round-trip time (RTT) to the sender of TPLR from RTCP > report round-trip time if available, or its reception time of the > reflected RTCP FB message (e.g.,NACK), or any other means." > > We hade the discussion before but now that you clarified which RTT to be > used, I think it is worth having a discussion if that RTT is the right > one. So you suggest that the RTT between the sender of the TPLR and the > receiver of the message is the most appropriate to use when suppressing > the message. I am not certain that is the case. > > Lets consider the use cases. In the case of an intermediary in a > distribution tree sending the TPLR and at the same time sending a NACK > upstream. Then the time until the retransmission reaches the suppressed > receiver is the time from the sending of the NACK up to the > retransmitting entity and all the way down past the TPLR sender to the > suppressed receiver. The receiver may not have a true RTT to the > original media sender as that source appears to live at the TPLR sender, > not further upstream. > > Yes, the sender of the TPLR and the receiver might at least have mutual > knowledge of each other, thus the TPLR sender is able to determine the > lowest RTT in the set of receviers thus determining how often to repeat > it to cover additional time requried for the upstream part of the > request. But I do note that these times aren't matching what appear to > be the delays in the systems. > > Can we find a better solution? > > > [Qin]: It looks to me the round trip time between media source and > > intermediary is trivial if we assume the intermediary is much > > closer to the source, that is why I put the last paragraph in the > > section 3 as follows: > > “ > > In order not to incur a lot of NACK requests due to additional TPLR > > described above, it is recommended that the RTP system sending > > TPLR should be implemented more closer to the source. Also when > > the loss was detected and repair initiated much closer to the source, > > the delay for the receiver to recover from packet loss can be reduced > > through the combination of intermediary feedback to the source and > > Third Party Loss Report downstream. > > ” > > > > If we look for a better solution, I think we have two possible ways: > > The first way is to rely on sender report from media sender to > > calculate the more approximate RTT from media sender to the receiver. > > RTT measurement method follows the same way described in the > > figure 2 of RFC3550. > > > > The second way is to we can allow the intermediary tell the receiver the > > RTT from media source to intermediary itself by sending a new message > > since the intermediary can measure such RTT based on past observation > > and estimation. However for the second way we need to define new > > message or extend TPLR message to carry such RTT. > > > > What do you think? > >From follow up email: > Hi,Magnus: As regarding if there is better solution, I have some > corrections and additional thoughts. > I think If the media source is the repair server, the receiver should > set timer to T1=max(the RTT from media source to middlebox sending > TPLR, 1/2 of RTT from middlebox to receiver) when the receiver > receives first TPLR. When the receiver receive addtional TPLR within > T1, the receiver should reset the timer to the RTT from media source > to middlebox sending TPLR. > > If the middlebox is the repair server, the receiver should set the > timer to T2=1/2 of RTT from middlebox to receiver when the receiver > receives first TPLR. When the receiver receive addtional TPLR within > T2, the receiver should reset the timer to the T2. > Can you express these rules for the receiver as something that is based on what is observable from the RTP and RTCP traffic? Is when media server being repair server equal to TPLR sender SSRC = Media SSRC the TPLR applies on? And if they are not the same it is the second case? > > > 3. Section 3: > "To increase the robustness to the loss of a TPLR or of a transmission > packet, a receiver is allowed to receive additional TPLR for the same > packet. In the case the first TPLR is lost and the additional TPLR > arrives at the receiver, the receiver should immediately refresh the > timer." > > In the second sentence I don't see how the receiver can know that it is > a retransmission. It is simply a TPLR from its perspective if that is lost. > > Robustness reasons is only one reason for repeating them the other is > clearly to renew the timer. Thus I think the formulation should be more > generic to make it clear that all receivers should upon reception of a > TPLR refresh the timer for the packets indicated. > > > > [Qin]: If the receiver does not keep state for the times the TPLR is > > retransmitted, we can add repetition count field in each FCI entry > > of TPLR feedback message to indicate the times TPLR is retransmitted. > > Particularly in PSLEI Feedback Message, we can reuse seq nr. Field to > > indicate if additional TPLR is retransmitted, which one you think better? > > How, can the receiver keep state for something it has not seen due to the initial packet not having been received? I don't think we need new packet extensions, just clarified rules that correctly describe what the RTP end-point should do when it sees the TPLR message. > > 7. Section 4.2: > Seq nr:8bits Command sequence number. It is used by the Command > receiver to check if the Command is repeated. The sequence number > space is unique for each pairing of the SSRC of command sender and > the SSRC of the command receiver. The sequence number SHALL > increase by 1 modulo 256 for each new Command. A repetition SHALL > NOT increase the sequence number. The initial value is arbitrary. > > Based on that it is defined that upon receiving one of the PSLEI > request, one shouldn't send a FIR or PLI message for a time interval > equal to the RTT between the receiver and the sender of the PSLEI > message does the sequence number field have any meaning? From my > perspective it doesn't matter if it is a new request or not. You are > suppressed from the reception of the message, nothing else. > > [Qin]: I think we can use seq nr field to indicate the times the TPLR is > retransmitted, e.g., > > If the additional TPLR with the same SSRC and different Seq Number is > received, the > > receiver knows that it is a retransmission if the receiver keeps state > for the previous > > TPLR with the same SSRC. > > Also we can replace seq nr. Field with Repetition count field to > indicate how many time > > the TPLR is retransmitted. > > That is possible, but is the repetition count really providing anything? What is the simplest most straight forward that can work? I think that is that one simple suppress the source for X time after having receives a TPLR message indicate that source. So, as long as you get repeat messages more often than X you continue to be suppressed. Will the receiver work better to know that it is now suppressed for Y times in a go because of the same event? cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Oct 19 02:16:08 2011 Return-Path: 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 C881E21F84DC for ; Wed, 19 Oct 2011 02:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 n1shvt-dYvwb for ; Wed, 19 Oct 2011 02:16:08 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8474521F84D6 for ; Wed, 19 Oct 2011 02:16:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-c1-4e9e9540bfdc Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 89.E8.13753.0459E9E4; Wed, 19 Oct 2011 11:15:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 19 Oct 2011 11:15:44 +0200 Message-ID: <4E9E953C.507@ericsson.com> Date: Wed, 19 Oct 2011 11:15:40 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <4E94467D.7040601@dcom.upv.es> In-Reply-To: <4E94467D.7040601@dcom.upv.es> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] Possible Additional functionalities for draft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 09:16:08 -0000 Hi, If I understand the main issue you have is to determine the set of transmission delays from a given media source to its population of receivers so that an appropriate playout time can be selected by the media source prior to actually having sent any media? Cheers Magnus On 2011-10-11 15:37, Fernando Boronat Seguí wrote: > Dear Group members, > > As this is our first mail to the list, we introduce ourselves. We are > Fernando Boronat and Mario Montagud, co-authors of the Internet Draft > (I-D) “RTCP for inter-destination media synchronization” > (draft-ietf-avtcore-idms-01.txt). > As the I-D was accepted as a WG document, any changes will have to be > approved by the AVTCORE group. So, we would like to know if you consider > appropriate to introduce some additional functionalities to the proposed > IDMS approach in the I-D. > > In many distributed applications it is required that all the receivers > start the playout of the media stream almost simultaneously (we refer > this as Coarse Sync) and, after that, all of them play-out the media in > a synchronous way (we refer this as Fine Sync). Those processes are > essential for acquiring IDMS. A Global Initial Playout Instant for all > the geographically distributed receivers (SCs) in a media session could > prevent from an initial playout time discrepancy (asynchrony) at the > beginning of the playout of the media stream/s (if a fixed global > initial buffering delay is set) mainly due to the variable network > delays from the media server to each one of the SCs. > > Thus, we are thinking about including a new section in the I-D about > possible packets for Coarse Sync for both the initial playout instant > (at the begining of a media session) and the initial instant at each > stage in which the session can be divided (we consider that a stage ends > when no streams are transmitted during a fixed interval (it could be > defined depending on the applications), and that the next stage starts > when data is transmitted again). > > This technique has been considered in some previous IDMS works (see > reference [Boronat09] in the I-D), but using proprietary protocols. The > methods we propose here are based on the use of already defined and > standard RTCP packets, which would avoid the introduction of proprietary > closed solutions. > > Regarding the Initial Playout Instant, we have primarily thought about > the use of already proposed RTCP XR packets (RFC 3611): > > 1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC 3611) > for measuring the delay between MSAS and SCs, allowing MSAS to estimate > the RTT for all the SCs, then calculate a common initial playout instant > and then communicate it to all SCs by sending them an RTCP IDMS Packet > (defined in the I-D). The RTCP IDMS packet must include the RTP > Timestamp of the first MU to be sent by the source and its proper > playout instant, which will be common for all of them. > MSAS may estimate its round trip time (RTT) to the SCs by sending them > an RTCP XR with the Receiver Reference Time Report Block and forcing > (according to RFC 3611) them to reply by sending an RTCP XR with a DLRR > Report Block. Notice that both XR blocks are defined in RFC 3611 to be > used in the opposite way we propose. > > If this solution is not considered appropriate we could think about > another solution based on the packets already defined in the I-D, but > maybe we would need to change the format adding new field/s. > > 2. Once joined the session, if it is not started yet, all the SCs could > start sending RTCP XR with IDMS block (until they receive the Initial > Playout Instant indication, sent using the RTCP IDMS Packet) as it is > defined in the I-D, but including only the essential timing information > (e.g. the wallclock time at which the packet is sent by the SC) to let > the MSAS estimate the one-way network delays (not round-trip as in the > previous case) for each SC (assuming symmetric delays as in TCP) and > calculate the Initial Playout Instant. For that purpose, some field of > the RTCP XR IDMS block should be used to indicate the XR IDMS block is > carrying out temporal information for Coarse Sync, and not for reporting > about arrival/playout timing of a specific RTP packet. > From the Initial Instant they will continue playing the streams and > sending the RTCP XR with IDMS complete block (as currently defined in > the I-D). It could be a possible solution. > > The process of the calculation of the optimum Initial Playout Instant > must take into consideration some factors such as the maximum and > minimum estimated delays, jitter values, expected duration of the > session, or probable clock deviations, in order to allow enough buffered > MUs to start the playout and to maintain it continuously, thus avoiding > underflow/overflow situations (playout discontinuities), during the > session. This process is out of the scope of the ID. > > With the introduction of the Coarse Sync functionality, the IDMS > proposal can counteract the effect of the delay variability at the > beginning of the playout of the media stream/s in each one of the stages > in which a media session can be divided. > > We prefer the first method because there is no need to define new IDMS > control messages (or to include some fields to already defined packets), > but the use of already defined RTCP reports (RFC 3611) can be adapted > for that purpose. > > Moreover, with the use of the first method, SCs do not have to send > control messages once they join the session, which may possibly result > on inefficient control traffic overhead. They will only have to send > RTCP XR DLRR messages in response to a new incoming RTRR message from > the source, which is who really knows the initial transmission time for > the RTP media stream. Moreover, the Initial Playout Instant can be sent > to the receivers by using the RTCP IDMS packet, already introduced in > the I-D. > > Feedback will be much appreciated. > > Regards > ======================================================================== > Dr. Fernando Boronat Seguí > IEEE Senior Member > Profesor Titular / Lecturer > Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 > Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) > UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA > Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN > ======================================================================== > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Oct 19 07:19:14 2011 Return-Path: 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 190F921F8BBB for ; Wed, 19 Oct 2011 07:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.274 X-Spam-Level: X-Spam-Status: No, score=-106.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 tDL5nUik5bPp for ; Wed, 19 Oct 2011 07:19:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E4A6721F8BB7 for ; Wed, 19 Oct 2011 07:19:12 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-fc-4e9edc1c46be Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.83.20773.C1CDE9E4; Wed, 19 Oct 2011 16:18:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 19 Oct 2011 16:18:04 +0200 Message-ID: <4E9EDC19.2000707@ericsson.com> Date: Wed, 19 Oct 2011 16:18:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dan Wing References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <008b01cc89ce$724dee80$56e9cb80$@com> In-Reply-To: <008b01cc89ce$724dee80$56e9cb80$@com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avtcore-ecn-for-rtp@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 14:19:14 -0000 Hi, Thanks for the comments. On 2011-10-13 19:35, Dan Wing wrote: > Two comments: > > 1. The section > http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04#section-7.2.2 > does not seem to discuss what happens if the ECN-marked ICE messages are > discarded (e.g., by an aggressive firewall). This seems to be an oversight. > For this to work better, I suggest sending two STUN messages, back to back: > one with ECN set and the other with ECN clear. If the response to the > ECN-set message isn't received within, say, 20% of the time for the > ECN-cleared message, assume ECN-marked messages are being dropped/filtered. > Note one of the non-ECN'd messages can be the normal ICE exchange, so if > you're already doing ICE I am not proposing any additional messages on the > wire. > > I expect the other packet probes (RTP/RTCP probes) may need similar > consideration / adjustment. Yes, you are correct that we don't have a specification for when the ICE client should consider the ECN check as being failed. I think we should allow the ICE agent to send multiple transmissions of the ECN STUN check packets. The second aspect is that I think 20% extra delay is to little. The STUN packet may easily suffer that amount of network jitter. My proposal would be to add the following paragraph to Section 7.2.2: The ECN STUN checks may be lost on the path, either due to the ECT marking in the ECN field or for some other reason. The first will result in a failure to verify the path as ECT. The second should not result in a failure to verify the path. Therefore a number of retransmissions should be attempted. But, the sender of ECN STUN checks will also have to set a criteria for when it gives up testing for ECN capability on the path. As the ICE agent have successfully verified the path a RTT measurement for this path can be performed. To have high probability of succesfully verifying the path it is RECOMMENDED that the client retransmitt the ECN STUN check 5 times. The interval between the retransmissions will be based on the Ta timer as defined in Section 16.1 for RTP Media Streams in ICE [RFC5245]. The number of ECN STUN checks needing to be sent will depend on the number of ECN capable flows (N) that is to be established. Thus the interval between each transmission of an ECN check packet MUST be Ta. In other words for a given flow being verified for ECT the RTO is set to Ta*N. The transmission for that flow is stopped when an ECN Check STUN response has been received which don't indicate to retransmit the request due to temporary error. The ICE agent is recommended to give up on the ECN verification MAX(1.5*RTT, 20 ms) after the last ECN STUN check was sent. When it comes to RTP I think we have a clear criteria for failure in 7.2.1: ECN initiation is considered to have failed at the instant when any RTP session participant sends an RTCP packet that doesn't contain an RTCP ECN feedback report or ECN summary report, but has an RTCP RR with an extended RTP sequence number field that indicates that it should have received multiple (>3) ECT marked RTP packets. This can be due to failure to support the ECN feedback format by the receiver or some middlebox, or the loss of all ECT marked packets. Both indicate a lack of ECN support. > > > 2. The section > http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04#section-7.2.2 > can be summarized as: > > a. do normal ICE > b. use ICE messages to do an ECN validation > c. if (b) showed ECN worked, start sending RTP with ECN. > d. if (b) showed ECN failed, start sending RTP without ECN. > > Step (b-d) adds additional call setup time, which is undesirable. > > Instead, I would prefer changing two aspects: (1) not relying or caring > about an initial ICE transaction (which means we can have both endpoints > merely do ICE-Lite, if they wish -- we only need to know they will respond > to ICE, really -- we don't need all of the other ICE overhead to use ICE to > test the path is ECN capable), and (2) sending non-ECN'd RTP without > waiting. That can be summarized as: > > a. immediately start sending RTP without ECN > b. use ICE messages to do ECN validation > c. if (b) showed ECN worked, start sending RTP with ECN. > d. if (b) showed ECN failed, start sending RTP without ECN. I disagree with the disconnection from ICE processing. First of all the side that want to determine if the path from it to the other side must be an ICE node. The other side could be an ICE-Lite supporting the ECN check attribute. But if the goal is to establish if the path is ECT bi-directionally then both sides need to be ICE capable. Secondly, I think the optimization you propose is good and I think we can accept it with the note that I would like much more conservative ECN STUN check transmission schedule if we are going to do media in parallel. However, this is an substantiative change so I would like to see if there is WG support for it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Oct 19 07:41:40 2011 Return-Path: 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 9D3BB21F8AB8 for ; Wed, 19 Oct 2011 07:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 dTJ6rtH1wZgP for ; Wed, 19 Oct 2011 07:41:39 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 30C2521F8A71 for ; Wed, 19 Oct 2011 07:41:38 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f6-4e9ee1874705 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 09.87.20773.781EE9E4; Wed, 19 Oct 2011 16:41:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 19 Oct 2011 16:41:10 +0200 Message-ID: <4E9EE184.4090606@ericsson.com> Date: Wed, 19 Oct 2011 16:41:08 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Bill Ver Steeg (versteb)" References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <117602CF2B17DB4F9001427FA6D9053996F6FF@XMB-RCD-312.cisco.com> In-Reply-To: <117602CF2B17DB4F9001427FA6D9053996F6FF@XMB-RCD-312.cisco.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 14:41:40 -0000 Bill, Thanks for the review. I here respond to the major issues. If needed I will follow up on the minor issues, otherwise I will simply implement them in the next update. On 2011-10-12 14:57, Bill Ver Steeg (versteb) wrote: > > For the multicast case, we need to make it clear that feedback goes to > the feedback target, which may be a different device than the source. > This document consistently says “feedback goes to the source”, which is > misleading. See the detailed comments below for the places in which I > found it to be most concerning. When viewed in the context of feedback > going to a discrete feedback target at the network egress edge (like > typical IPTV deployments), it makes sense for the feedback target to use > these reports as diagnostic in nature. Perhaps the network has changed > topology and caused a bottleneck link to appear, and the feedback is > triggering action in the network to fix the congestion in a systematic > manner. It is highly unlikely that RTCP feedback will be able to change > the rate of a flow in such a system. It is more likely that the system > would take other actions, but that is probably beyond the scope of this > document. I think we might not have been sufficient clear on the SSM case. But in fact for this to work, the Feedback Targets will need to relay the feedback, at least in aggregated form to the source (or at least the entity marking the packets as ECN which might be the Distributuion Source). > > > > If a host is unable to read the ECN bits, it can’t join an ECN-enabled > flow? This seems to be quite onerous, and will likely slow down the > adoption of ECN for RTP – particularly in the IPTV multicast case. If an > operator needs to dual carry hundreds of video channels (one ECN marked > and one not ECN marked), he will simply not implement ECN. I need to > think about this a bit more and see if there is a way to make this work. > My first instinct was to add a field/bit pattern to the RTCP feedback > that says “ I joined the ECN enabled flow, but can’t actually read the > ECT/ECN markings”. However, let’s think about naïve receivers that do > not understand the ECN SDP. They will ignore that SDP line, and join the > flow. They will provide their normal feedback, without the ECT/ECN > portions. How is this different from a receiver that knows about ECN, > but is unable to actually read the ECN bits? Maybe we just treat it like > a legacy receiver that does not know about the ECN SDP....... So, we > need to think about three receiver populations – fully ECN capable (as > currently described in this document), ECN aware in the application but > unable to read ECN bits (either acts like a legacy receiver or sends a > special RTCP feedback message), ECN unaware (ignores the SDP). I have > thought about this in the context of the declarative SDP case using leap > of faith, but need to think more about the offer/answer case and the > STUN case. We need a way to have each type of receiver unambiguously > join the same multicast flow. This would allow an operator to > incrementally deploy ECN on multicast flows. If we do not fix this, the > operator will be gated on the very last device in his deployment. > Lets start with commenting on the naive receivers, if they join an ECN enabled RTP session they will cause the session to stop using ECN. That is why we say the same to a receiver that knows about ECN but can't read the session. If they join they will force the session into not-ECT operations. Yes, this is onerous. But we can't frankly figure out how we can allow any other behavior in any best-effort network. Having receivers get preferential treatment of their traffic compared to not-ECT marked in a best effort seems problematic if they aren't reporting back on it and telling the sender to adjust the bit-rate. We know from that start that ECN and large scale multicast would be problematic and that is not our main target. This as it will be difficult to combine source rate modifications with large groups. I think we authors are still of the opinion that we develop what is safe but possibly overly conservative and get that published. If people want to improve the ECN in multicast usage later they are free to do so. But tackling the issues that arise from letting non ECN capable receivers into a group that uses ECN is problematic. So my opinion is that we shouldn't change anything in this behavior. > > It would be nice to have the RTCWEB folks take a courtesy look, as they > are envisioning some very interesting use cases. I do not think that > this presents any specific challenges, but it would be good to have > those eyeballs. I see that at least a few of them have provided comments……… > Which RTCWEB folks do you want to have a look at this? My personal view that I would love to have overturned is that ECN in open Internet is so dysfunctional that it is barely worth trying. Thus adding ECN support to RTCWEB nodes in the initial phase is lots of work for the implementor with very little bang back. > > A few minor points and a bit more specificity on the major > points------------ > > > > There is a delicate balancing act between providing timely congestion > notifications to the sender and sending feedback packets into a > congested network. It is not clear that the this balancing act is > discussed in enough detail in the document. An inexperienced implementer > may “do the wrong thing” and send packets to freely, thus making the > congestion worse. Perhaps a short paragraph in the introduction would > make this clear? Perhaps a paragraph at the end of Page 11? Also in > section 7.3.2, as congestion is not highly featured in RFC4585 or > RFC3550. Congestion is mentioned in 7.3.2, as is feedback implosion, but > there is no warning about how they can interact. I think we can add more warnings and check that we are clear on that one must follow the transmission rules for the session the end-point is operating. I would note that congestion is in fact likely asymmetric. Thus just because you receive CE marked packets doesn't mean that the RTCP FB packets will go over path that is loaded into congestion and of course the reverse. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Oct 19 08:48:12 2011 Return-Path: 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 3670821F84FD for ; Wed, 19 Oct 2011 08:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] 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 JDF7MQ5TUbZ7 for ; Wed, 19 Oct 2011 08:48:11 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DEA8621F84DF for ; Wed, 19 Oct 2011 08:48:10 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-45-4e9ef1399a04 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DD.F1.20773.931FE9E4; Wed, 19 Oct 2011 17:48:10 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 19 Oct 2011 17:48:10 +0200 Message-ID: <4E9EF136.3000804@ericsson.com> Date: Wed, 19 Oct 2011 17:48:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Bill Ver Steeg (versteb)" References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <117602CF2B17DB4F9001427FA6D9053996F6FF@XMB-RCD-312.cisco.com> In-Reply-To: <117602CF2B17DB4F9001427FA6D9053996F6FF@XMB-RCD-312.cisco.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:48:12 -0000 Hi, some more in detail comments. I propose that the SSM usage is clarified in section 3.3 by adding the following text. SSM groups that uses unicast RTCP feedback [RFC5760] do need a few extra considerations. This topology can have multiple media senders that provides traffic to the distribution source (DS) and are separated from the DS. There can also be multiple feedback targets. The requirement for using ECN for RTP in this topology is that the media sender must be provided the feedback from the receivers, it may be in aggregated form from the feedback targets. We will not mention this SSM use case in the below text specifically, but when actions are required by the media source, they do apply also to case of SSM where the RTCP feedback goes to the Feedback Target. But, I guess that you might find this insufficient. But, I don't see how we can take care of all implications of large scale multicast usage. Maybe what we should add is: "This specification do support multicast, but has primarily considered smaller multicast groups and is not optimized for larger groups and their needs." On 2011-10-12 14:57, Bill Ver Steeg (versteb) wrote: > > 1---- Page 7 > > ECN support is more important for RTP sessions than, for instance, is > > the case for TCP. > > > > This is a quite bold statement. I suspect that the following sentence is > closer to the truth, but it is truly a minor point. > > ECN support is as important for RTP sessions as it is for TCP. I still believe based on the motivation provided below this sentence that the original one is true. Yes, I can see if "delay" is your main performance factor, then TCP might be similarly benefited by ECN. > > 2--- Page 13 > > ---- begin rant ---- I am always troubled by language discussing > signaling protocols and discovery in RTP documents. We all know that > declarative SDP is often used to configure endpoints. There is probably > nothing that needs to be changed in this section, but I am noting that > “declarative SDP” is not equal to a signaling protocol used for > discovery. --- end rant --- > > I need to think about the typical Service Provider use case- delivery of > IPTV to a very large population of receivers. The system is setup with > declarative SDP. Is the sender REALLY going to probe all of the > receivers and stop marking packets with ECN if a few receivers don’t > respond? If you have a population of several million receivers at the > end of DSL lines, what are the odds of none of them being offline for a > few minutes? I would venture a guess that it is pretty small. In this > case, the “leap of faith” is probably what the network operator will > do……. So, I do not think I have a problem with this section, other than > the rant. I assume the rant is over this following sentence: Before an RTP session can be created, a signalling protocol is used to discover the other participants and negotiate or configure session parameters (see Section 7.1). Is this better? Before an RTP session can be created, a signalling protocol is used to negotiate or at least configure session parameters (see Section 7.1). In some topologies the signalling protocol can also be used to discover the other participants. > > 3--- Page 13 > > Considering again the case of the large Service Provider. The feedback > target for the flow is usually a repair device rather than the sender. > It is not clear from the text if the RTCP is going to the repair device > or the sender. I assume this is sentence that triggers your comment: Upon reception of this feedback from each receiver it knows of, the sender can consider ECN functional for its traffic. Is that more acceptable in the light of the section 3.3 addition making clear the requirement that in case of SSM the media sender will get a aggregated information. > > 4--- Page 14 > > Is feedback send to the sender, or to the feedback target? Hopefully it > goes to the feedback target, or else you are going to have one hell of a > feedback storm in certain deployments. Well, if you have an SSM with feedback targets then it goes to the feedback targets. As stated in 3.3 addition I see an feedback target aggregating the information to the media sender. > > 5--- Page 15 > > I need to think about the case in which a large IPTV deployment is using > these methods, then one of the subscribers deploys a wireless gateway > that mangles ECT/ECN packets. It is not clear that the sender SHOULD > stop sending ECT/ECN marked packets. In a perfect world, the subscriber > would have a way to know that the problem is in the gateway….. I am not > sure we can fix this problem in the scope of this document, though. No, I don't see how we really can deal with it. As I said before I think we likley need that disclaimer for larger multicast groups. > > 6--- Page 15, and then sprinkled throughout the document > > Is feedback send to the sender, or to the feedback target? It is sent to where ever you send your RTCP packets, but the feedback is addressed to the SSRC that you report on. > > 7--- My SDP skills are suspect. It looked OK on a quick read, but > hopefully somebody is looking at this in detail. I am not sure I like > the setread/setonly/readonly semantics, but I do not have a > counter-proposal. Noted, input by SDP gurus desired. > > 8--- Page 23 and 24 > > If a host is unable to read the ECN bits, it can’t join an ECN-enabled > flow? This seems to be quite onerous, and will likely slow down the > adoption of ECN for RTP. This is particularly true of the “large IPTV > deployment” that wants to send multicast flows to STB, PC, Xbox, tablet, > etc. If there are millions of receivers, that means that there are > dozens/hundreds/thousands of device types. If the operator is gated on > having ECN support on all of the devices, this will never get deployed. > Perhaps we can change the feedback report to say “ I joined the stream, > but can’t actually read the ECN bits, so do not count me in your ECN > algorithm”. Yes, but as stated in previous email I don't see how we can allow someone who don't react, nor report to the congestion signals to join the group. > > 9--- section 7.2.1 > > If the feedback goes to a discrete feedback target, the system will have > to correlate the responses and send a summary to the original sender. Yes, I think this would be fixed by 3.3 addition. > > 10 --- page 28 > > change > > For video formats, packets containing P- or B-frames, rather than I-frames, > > would be an appropriate choice > > to > > For video formats, packets containing NULLS, P-frames or B-frames > (rather than I-frames), > > would be an appropriate choice I have done the change, but isn't this a US vs UK english thing? > > 11--- page 29 > > For streams with millions of receivers (think IPTV and the World Cup > Final), the group will never be stable for three RTCP reporting > intervals. Perhaps a group associated with a given feedback target would > be stable for this long, but even that is marginal. I agree this is an issue. But I would group this with the large multicast group issues that we have identified as being problematic. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dwing@cisco.com Wed Oct 19 09:25:19 2011 Return-Path: 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 AD49921F8CE8 for ; Wed, 19 Oct 2011 09:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.228 X-Spam-Level: X-Spam-Status: No, score=-105.228 tagged_above=-999 required=5 tests=[AWL=1.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 wjjYxR2B8lm9 for ; Wed, 19 Oct 2011 09:25:19 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 51B0321F8CDD for ; Wed, 19 Oct 2011 09:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=592; q=dns/txt; s=iport; t=1319041519; x=1320251119; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=5T7BBtfwqJs55msMl2t2Td+heq9QiDsiVwDFgOuVpXE=; b=MtHkZKIL4TY8KPOYmjfIvgMZpW3o0vEtDvSFab4qh4lTWoA4CTJxOpkv gPbFEEGr4tgQi/P7bKpny7pgs0T/5VOcS3I4wb2dlyrOlUnF/2w0Sb4aK VkGieulnF5eN9dfPm3rq5LDgvVkl2+zCRL+d0iiwM3vJoaPBRow8AOQ3W A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADn5nk6rRDoG/2dsb2JhbABEmzCNRIEFgW4BAQEECAoBFxA/DQMCCQ83GSMbAQEEHhefCQGeTIgbBIgCnXM X-IronPort-AV: E=Sophos;i="4.69,373,1315180800"; d="scan'208";a="8909934" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 19 Oct 2011 16:25:19 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9JGPG2T017429; Wed, 19 Oct 2011 16:25:18 GMT From: "Dan Wing" To: "'Magnus Westerlund'" References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <008b01cc89ce$724dee80$56e9cb80$@com> <4E9EDC19.2000707@ericsson.com> In-Reply-To: <4E9EDC19.2000707@ericsson.com> Date: Wed, 19 Oct 2011 09:25:18 -0700 Message-ID: <0b5d01cc8e7b$b106b470$13141d50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyOaeynmZ0L0S2HTwq5+GYqJGxduwAEQ8gg Content-Language: en-us Cc: draft-ietf-avtcore-ecn-for-rtp@tools.ietf.org, avt@ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:25:19 -0000 ... > Secondly, I think the optimization you propose is good and I think we > can accept it with the note that I would like much more conservative > ECN > STUN check transmission schedule if we are going to do media in > parallel. > > However, this is an substantiative change so I would like to see if > there is WG support for it. With the years-long bru-hah-hah of ICE being misunderstood for "delaying call set up", it seems important for the success of ECN RTP to ensure it does not suffer that same fate. That would delay/prevent ECN RTP's widespread deployment. -d From mcgrew@cisco.com Wed Oct 19 15:14:50 2011 Return-Path: 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 1056911E80B0 for ; Wed, 19 Oct 2011 15:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ba-2jP4rfBFI for ; Wed, 19 Oct 2011 15:14:49 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 42CC711E8098 for ; Wed, 19 Oct 2011 15:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=8896; q=dns/txt; s=iport; t=1319062489; x=1320272089; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=CvACvu58SHQuA1OFG4kNod/03c8oHEe2fc3R8aQQkbk=; b=L2m8sLC/UyZDaiw4xek30LE35P5se0MtGE15hRV4odVBLKz0VUKg6KS7 7d903AfKipa+JPXtRFc9rRINQ/cMk7BTWlb1WJfA7UnSA9S0XQTRC5RSw h2tBXwgBLYzNBDQGgJsgCNOSFmqV9VFz+kiW5LKDQ0xxJKsJQJUQIGNIf g=; X-Files: smime.p7s : 3497 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL1Ln06rRDoG/2dsb2JhbABEqQKBBYFuAQEBAQIBEgFmBQsFBg44AlUGJBGHXpdgAZ5PhzphBIgCi3yRdw X-IronPort-AV: E=Sophos;i="4.69,374,1315180800"; d="p7s'?scan'208";a="8976120" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 19 Oct 2011 22:14:49 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9JMEmFq022419; Wed, 19 Oct 2011 22:14:48 GMT Message-Id: From: David McGrew To: Qin Wu In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-278--694612237; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 3 Date: Wed, 19 Oct 2011 15:14:47 -0700 References: <4FD125153A070D45BC87645D3B88028802BB7BC639@IMCMBX3.MITRE.ORG> X-Mailer: Apple Mail (2.936) Cc: avt@ietf.org Subject: Re: [AVTCORE] Comments on draft-ietf-avt-srtp-aes-gcm-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:14:50 -0000 --Apple-Mail-278--694612237 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Qin, thanks for your comments, On Sep 22, 2011, at 5:11 AM, Qin Wu wrote: > Hi, > This draft is well written. I would like to see this work moving > forward. > Here are my minor comments to this document: > > 1. Section 1, Second Paragraph > > [Qin]: It looks SRTP (together with SRTCP) utilizes AES as the > default cipher. > However in some case(e.g., in ITU-T H.235.8), Public key > cryptography be used with SRTP to provide end to end confidential and > authentication. So is it fair to assume in SRTP, both sender and > receiver only use symmetric cryptography? what if asymmetric > cryptography? > only symmetric crypto is in scope for SRTP. To establish SRTP sessions using public keys, the best standard to use is DTLS-SRTP (RFC 5764). ZRTP is similar (but not a standard). Alternatively, one can use public key cryptography to protect signaling (which should be done anyway ;-) and then pass the SRTP keys through it. > 2. Section 1.1 Second Bullet > > [Qin]: It is not clear why four instantiations is required for each > participant in the session, > I think it is better at least to have a reference to put here. > > 3. Section 1.2.1, First Paragraph > > [Qin]: Is the AEAD authentication tag is authentication tag > defined in SRTP/SRTCP packet? If not, how they are different? If > yes, > it is better to be clear about this in the draft. In the text " Rationale. Some applications use the Authentication Tag " I will add "SRTP Authentication Tag" to make that clear. > > 4. Section 1.2.1, Second Pragraph > > [Qin]: Should it say the optional SRTP Authentication Tag is NOT > Recommended to be present > to be consistent with the figure in section 1.2.5. These terms are defined to be equivalent in RFC 2119. But if you think it is clearer, we could change "SHOULD NOT be present" to "is NOT RECOMMENDED and SHOULD NOT be present". That is fine with me. > > 5. Section 1.2.5 > > [Qin]: Should it also say authentication tag is not reccommended in > the note to the figure? > Sure. > 6.Section 2.1 Four Paragraph > > [Qin]: How the number of invocations is calcualted for SRTP/SRTCP > respectively? Here an invocation means of the AEAD encrypt or decrypt function. It is equivalent to the number of packets that are being protected. > > 7. Section 2.2, Table 1 > > [Qin]: You also need to support the algorithm specified in > [RFC5282],Should it say > A detailed description of the AES-GCM family can be found in > [RFC5116][RFC5282]? Good point. > > 8. Section 2.2 Last Paragraph > > [Qin]: You didn't mentioned IV is formed from invocation counter in > the section > 1.2.2, rather than you point out "The packet counter is closely > related to the invocation field", > what is missing? > > [Qin]:It is not clear to me how the invocation counter is related to > each instantiation of AES-GCM? > Good point. > 9.Section 3 > > [Qin]: I can not understand this formulation and table. how do you > get this formulation and table? > what's the rationale behind? > The table entries are computed using the formula in the paragraph above. To limit the success probability to 2^-30 when using an 8- octet tag, for instance, one must limit the number of tries that an attacker has to 2^32. Here a "try" is when the attacker gets the SRT[C]P receiver to accept a maliciously chosen packet, e.g. as part of a forgery attempt. > 10.Section 4 > > [Qin]:It looks not complete since you didn't specify the SRTP > transform parameters fro each profile. > Yes, good point. thanks again, David > Regards! > -Qin --Apple-Mail-278--694612237 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPDCCA5ow ggKCoAMCAQICAWQwCwYJKoZIhvcNAQEFMG0xFTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UE CAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMxETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcN AQkBFhBtY2dyZXdAY2lzY28uY29tMB4XDTA4MTIwOTIyMDMzMFoXDTA5MTIwOTIyMDMzMFowbTEV MBMGA1UEAwwMRGF2aWQgTWNHcmV3MRMwEQYDVQQIDApDYWxpZm9ybmlhMQswCQYDVQQGEwJVUzER MA8GA1UEBwwIU2FuIEpvc2UxHzAdBgkqhkiG9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDh5WR1gATRK4ubbWwmG2T/XTUeVc2FAxnmtoYy00fM 5jp3DYFXHkWj4Cl8RVVfAJxP/2PhKsTl0qx2b7N9pIZZa6BaODEyJ8yVMRHloHrpzHeU8DIrst/H SFVkcJvl3p9LFD42BCvznzQ48VxnWX68OCk7GAwg6XoKMY8Z1F70PVvcZ0JcbnDuKx0efQ+P74uY UdpjRYSXb2xJUziGs5k6b1kTr5754B3tnYCGkum49YAbONpsOL4R+e4HNNrkVTx254ggrcDb1GDr IpZYCSPh6lZWwOp0XBoJiLYEKXuBf/jSNEv15/Kt/Uu5Oh8jUBxkBHGAVZuaVu25s3Zk9waLAgMB AAGjRzBFMA4GA1UdDwEB/wQEAwIEsDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAbBgNVHREEFDAS gRBtY2dyZXdAY2lzY28uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCbD+Y6Yu0d5FZHSGd7WTP7vlo+ SE2rF0YzqvcMYrEuu6VBbkOFGfq3leu2WVJinXYQwAgaZ7vJpH43/bjDIK4YuOqAUv57ZQjtCJ6W 6b0rdG8/A2cWcGoDjqmjAGJ4TC8oMIc0h33QPEjsGdon0nsV0QCxrgWcWEjFSzlE6kbR4pT3yA2V zo7byNoDoYpH5otGH0/cRQM9i6ENTytxzczPeNTt2uaMp/3s8MZ5W/0Yz8U/yy5bcS5TGrqgTvN7 mI+nngoJ4TNKapSpdSqCyEK86z51VWtRRFyBosLQsNhMYb7HWzW/mIQCG0SygOVjUcRPKxhYUokR gCmxsHqcL1uMMIIFmjCCA4ICCQD8XsAekzPPFDANBgkqhkiG9w0BAQUFADCBjjELMAkGA1UEBhMC VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMRwwGgYDVQQKExNDaXNj byBTeXN0ZW1zLCBJbmMuMRgwFgYDVQQDEw9EYXZpZCBBLiBNY0dyZXcxHzAdBgkqhkiG9w0BCQEW EG1jZ3Jld0BjaXNjby5jb20wHhcNMTEwMzE0MTgwOTAyWhcNMTMwMzEzMTgwOTAyWjCBjjELMAkG A1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMRwwGgYDVQQK ExNDaXNjbyBTeXN0ZW1zLCBJbmMuMRgwFgYDVQQDEw9EYXZpZCBBLiBNY0dyZXcxHzAdBgkqhkiG 9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDL KlHKr3WA3U7qp3aPD6XqP+nSwKGxXYA2Sn/rgpxo34tTS9CpCqhQUU7oNxGJ1/534P8GhpwP8Ufg HVqNa6wDAWUsHJBRdqLT2qqjnFFmEa4G7V2Hmis6nbAnQ+vu9TdZVMDJDEakTiAh6XCgzGRWYTiJ XgIn6UT+aIWQ63VRVTnOQVN+fhzhoKzmd3opwHiavo/gfavu/2t4S/hSLTZikroi0h68df4w3nRo b/1ksC+NVbG8LHnHQ3fjyhdrxZwl9aH2k1hNS8LosET9rIQbzOvwkueC/9xYBjfr4yZcTlpDtixZ fh26rg/AFLkzXrtBBt4Sqi3niI+zWTXUOx1JMwFKEQBTn2z+RYPi9Q1VWCIg93Rh5RT6nkH/ZOyp HbmElrYoThYH+duDASssKyX3yXRu4F6UMoC897ynR7g9aV3RLF9PevN4k8UeIQQR6e0+aFvoo/zm xKYCCZIGnqWmMa6cnlzKWoMD5sTu+ILDk7Ty67+7LijhJxCO14erj4/XYmY1uvSuN/axd587emXu BmdWI3sDQoC1l/H7QxRROoONTWK5wAEGpNUUMllJmYDW//LxIiDhEsKC6wc1rOIhHy3FuykMA1BI xkIVaqOwYvokVdH/jXwpZNHoMEhS6hXCvWKt4mwIEJQRQsYGSC/TAB25D5cTkVmo/RCE/sTzXQID AQABMA0GCSqGSIb3DQEBBQUAA4ICAQCUtnHAg+JXVgQPFwz2hiIdD+MB14I3vThsphpEkD4PgdJz /KbIegcEe60ZaOvvDYVcLnY0dE3Z6kSXSS8Y5GCoXh9gKTL1mmzT+Rux0gFgbQHHd9xtnIeEUjuq E2MvznfgipTCvEIAqTZaonvilTeJJie4oEAPHX8Jjy7De3HM11bjbq4qZJhWv/9RE8CG08YUFmC3 /LQcGEdo4qSH16juGst5NuacAqg3Hugt9LCwLiSwoTpLXfhykd58kvTmPawrTszstDOvQAR1Q3TY zMw3/cbaKN2b/WMkxYZFwxmzwy7pYYgnkGPf3ehxfrwEmVzlzXUnMZVTqyk7KlF5sUE1ahS8mu1k jKOyGtOOPuFmGydDTFHHAHLGO5I8zoR3qfzeeOLEqr0tdG8ye7ZprVZyYVEa2EMUBl0vyH0+aAOy oPP5mba7eDyZLs357Xy8277x/2t2Zmcu6IkYdkQ3/yIfAb/99Ws7020X+zyaiiImsHangUmw9DKy LirSIeI03ZFcyEy8pMFFoIZFhg3/DM9md8YcUDubJjneWQaU5PpskcjfmOTzzhGag23ow9vw+upX mLVErB5jB2O0WCOMZZbAC837+Od3nAJhaIAXtk7OU67KbOgM/tfph71ZS/OhfQnu3+o9FQJwCTKM U+3z3+45mPYuaPT5+MPyGep06MXlczGCBC8wggQrAgEBMIGcMIGOMQswCQYDVQQGEwJVUzETMBEG A1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxHDAaBgNVBAoTE0Npc2NvIFN5c3Rl bXMsIEluYy4xGDAWBgNVBAMTD0RhdmlkIEEuIE1jR3JldzEfMB0GCSqGSIb3DQEJARYQbWNncmV3 QGNpc2NvLmNvbQIJAPxewB6TM88UMAkGBSsOAwIaBQCgggFnMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAxOTIyMTQ0N1owIwYJKoZIhvcNAQkEMRYEFN+dN7+A gv4uU/fpxZgvB7KlzP9RMIGBBgkrBgEEAYI3EAQxdDByMG0xFTATBgNVBAMMDERhdmlkIE1jR3Jl dzETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMxETAPBgNVBAcMCFNhbiBKb3NlMR8w HQYJKoZIhvcNAQkBFhBtY2dyZXdAY2lzY28uY29tAgFkMIGDBgsqhkiG9w0BCRACCzF0oHIwbTEV MBMGA1UEAwwMRGF2aWQgTWNHcmV3MRMwEQYDVQQIDApDYWxpZm9ybmlhMQswCQYDVQQGEwJVUzER MA8GA1UEBwwIU2FuIEpvc2UxHzAdBgkqhkiG9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20CAWQwDQYJ KoZIhvcNAQEBBQAEggIAj+d7fFSpa1LRAYehHkuJl4ljE7rQs72caFuuIXw78EovDeStwSMUkkcX 7LzqY6owaWRCoqGJGWNw+WVb13F+gKKP/KXi9H/usViaW1S5NmhmfJ63EG7EWbnFb6COu7m6Lhqn WJL9K25rBlKFa+r7xYL+WNga+OPE4YaASVONrsiXEx0wL0UzT9unp1MJOlC3OZJfNEILwKO7u3cx X1isXMUpBbIAPwBouQ4sh2boTKGhfrS43T++kyJ4979Ha/pZNLNOkyUkHppwS4/EfaYZMsxNWJc3 xJarc98tsmShkE/BNkqh6LRQxLZZP0Kq91hVKWWS+KNdfuB7/zvK7pbvRZZTLqJRCfj64Hic7EnA pASyuo9Tvdaa0avbZm/PvDSNarVhtm1PwRmnov+sqvOKid5HU43dbdtba4K5VmQkkDCGjN8rJEw2 EW9OekSx9tqTGEXZSfvjdnqj8TPuArZkJSAIZXeMaP2o0b5Yl4tHE01HP3Cr2fjPSa5e1sCNUrPk NgPqXw5+MxfXzNaoTdvoWNmGFpucJcVAQlvUbKG1yD445LtjYxmYRizrRIWJGdmc41oC0sGJm0fS YuDtRdl9w/PNVIcZP57tpy59qePznvT+zzdRN14opAGZ4DP1IFKjxDofevX+Sqm7XhOn/Sny6bvM 4WuG2ghp3JjwoWsmgtUAAAAAAAA= --Apple-Mail-278--694612237-- From kevin.gross@avanw.com Wed Oct 19 19:35:33 2011 Return-Path: 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 D018F11E80CD for ; Wed, 19 Oct 2011 19:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 2qVQ5xSY2Zls for ; Wed, 19 Oct 2011 19:35:33 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 1A49711E80BF for ; Wed, 19 Oct 2011 19:35:33 -0700 (PDT) Received: (qmail 31438 invoked by uid 0); 20 Oct 2011 02:35:32 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy1.bluehost.com with SMTP; 20 Oct 2011 02:35:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Transfer-Encoding:Content-Type:To:From:Subject:Message-ID:Date:MIME-Version; bh=9jnL+7cbUsIIUApvvrqxXW2l7SewDWdghZ2JQiWaQpY=; b=nRyHWMo4eCRMs6zGvqjrA6NWt/cIhl0FDppsal4eyBherHq9FMLwSMqnT2gOUG0WZ/cqp8vDe0IEdBr8WuS7V4ggc29FmZE3p0XduyqsRxubvMcEnubQi+ALZ6DmKCkt; Received: from mail-ey0-f172.google.com ([209.85.215.172]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RGiTj-0003sW-PG for avt@ietf.org; Wed, 19 Oct 2011 20:35:32 -0600 Received: by eyg24 with SMTP id 24so2486692eyg.31 for ; Wed, 19 Oct 2011 19:35:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.61.211 with SMTP id u19mr15011145fah.29.1319078130405; Wed, 19 Oct 2011 19:35:30 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Wed, 19 Oct 2011 19:35:30 -0700 (PDT) Date: Wed, 19 Oct 2011 20:35:30 -0600 Message-ID: From: Kevin Gross To: avt@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.215.172 authed with kevin.gross@avanw.com} Subject: [AVTCORE] draft-ietf-avtcore-idms-01 leap seconds X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 02:35:33 -0000 I've prepared the following paragraphs which discuss the issue and describe measures required to avoid leap second problems. I propose this be inserted into section 8 of=A0draft-ietf-avtcore-idms-01. A subset of these recommendations are applicable to RFC 3550 applications that make use of the NTP timestamp in sender reports. I=92d be happy to propose corresponding revisions to RFC 3550 once we=92ve ironed out IDMS. "IDMS implementation is simplified by using a clock reference with timescale which does not include leap seconds. IEEE 1588, GPS and other TAI (Inernational Atomic Time) references do not include leap seconds. NTP time, operating system clocks and other UTC (Coordinated Universal Time) references include leap seconds (though the ITU is studying a proposal which could eventually eliminate leap seconds from UTC). If a timescale with leap seconds is used for IDMS, receivers must take care not to generate any IDMS XR reports in the immediate vicinity of the leap second. Synchronization servers must ignore any such reports that may inadvertently generated. Senders using a leap-second-bearing reference must not generate sender reports containing an origination NTP timestamp in the vicinity or a leap second. Receivers should ignore timestamps in any such reports inadvertently generated. Receivers working to a leap-second-bearing reference must also be careful to take leap seconds into account if a leap second occurs between the time a RTP packet is originated and when it is to be presented. "Leap seconds are potentially scheduled at the end of the last day of December and June each year. NTP inserts a leap second at the beginning of the last second of the day. This results in the clock freezing for one second immediately prior to the last second of the affected day. Most system clocks insert the leap second at the end of the last second. This results in repetition of the last second of the day. Generating or using timestamps during the entire last second of a day on which a leap second has been scheduled should therefore be avoided. Note that the period to be avoided has a real-time duration of two seconds. It is also important that all participants correctly implement leap seconds and have a working communications channel to receive notification of leap second scheduling. Without prior knowledge of leap second schedule, NTP servers and clients may be offset by exactly one second with respect to their UTC reference. This potential discrepancy begins when a leap second occurs and ends when all participants receive a time update from a server or peer. Such a long-lived discrepancy can be particularly disruptive to RTP and IDMS operation." On Fri, Sep 23, 2011 at 9:48 AM, Kevin Gross wrote: > > Qin, > Thank you for this reminder. I have revisited the IDMS draft and am remin= ded that it does define a means to specify wallclock source. I think it cou= ld use a little work but it is an excellent start. > The IDMS draft doesn't mention leap seconds but since it is a draft, that= can easily be changed! > I will contact Ray Brandenburg and see if I can offer to help with this. > I think it would still be useful to add some leap second discussion to 35= 50 but I would propose to work it out under IDMS first since IDMS receivers= is where these NTP timestamps will be most relied upon. > Kevin Gross > > On Thu, Sep 22, 2011 at 3:52 AM, Qin Wu wrote: >> >> Hi, Kevin: >> Regarding how to know where the leap seconds are, I think, you may follo= w two potential ways: >> 1. you may take take David's suggestion, compare the NTP/RTP pairs in th= e two consecutive SRs to know if exception happen. >> 2.=A0you may look at IDMS draft, the parameter clock source=A0is =A0defi= ned in SDP to signal the source for clock >> =A0=A0 synchronization. Using this parameter, the receiver may know wher= e the leap seconds are. >> Does this make sense? >> >> Regards! >> -Qin From bill.wu@huawei.com Thu Oct 20 02:27:57 2011 Return-Path: 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 DF84421F8A71 for ; Thu, 20 Oct 2011 02:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.123 X-Spam-Level: X-Spam-Status: No, score=-4.123 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, MIME_BASE64_TEXT=1.753, 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 nRu9nnEfdPhc for ; Thu, 20 Oct 2011 02:27:55 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id E323F21F8A6F for ; Thu, 20 Oct 2011 02:27:54 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTC00D1QY9BW6@szxga04-in.huawei.com> for avt@ietf.org; Thu, 20 Oct 2011 17:27:11 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTC007LGY9AJV@szxga04-in.huawei.com> for avt@ietf.org; Thu, 20 Oct 2011 17:27:11 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEO92187; Thu, 20 Oct 2011 17:26:37 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 20 Oct 2011 17:26:32 +0800 Received: from w53375q (10.138.41.130) by szxeml406-hub.china.huawei.com (10.82.67.93) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 20 Oct 2011 17:26:28 +0800 Date: Thu, 20 Oct 2011 17:26:28 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: fboronat@dcom.upv.es, avt@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_TrBr9HUYBaN6AqU0NpPrqA)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4E941250.2080500@dcom.upv.es> <4E9F1C00.7090007@dcom.upv.es> Subject: Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 09:27:58 -0000 --Boundary_(ID_TrBr9HUYBaN6AqU0NpPrqA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 SGksIEZlcm5hbmRvOg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBG ZXJuYW5kbyBCb3JvbmF0IFNlZ3XtIA0KICBUbzogYXZ0QGlldGYub3JnIA0KICBDYzogYmlsbC53 dUBodWF3ZWkuY29tIA0KICBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMCwgMjAxMSAyOjUwIEFN DQogIFN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gUG9zc2libGUgQWRkaXRpb25hbCBmdW5jdGlvbmFs aXRpZXMgZm9yZHJhZnQtYnJhbmRlbmJ1cmctYXZ0LXJ0Y3AtZm9yLWlkbXMNCg0KDQogIERlYXIg UWluLA0KDQogIFRoYW5rIFlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29tbWVudHMuIEkgdHJ5IHRv IGFuc3dlciB0aGVtIGJlbG93Lg0KDQogICAgICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KICAgICAgRnJvbTogRmVybmFuZG8gQm9yb25hdCBTZWd17SANCiAgICAgIFRvOiBhdnRAaWV0 Zi5vcmcgOyB4cmJsb2NrLXJlcXVlc3RAaWV0Zi5vcmcgDQogICAgICBTZW50OiBUdWVzZGF5LCBP Y3RvYmVyIDExLCAyMDExIDU6NTQgUE0NCiAgICAgIFN1YmplY3Q6IFtBVlRDT1JFXSBQb3NzaWJs ZSBBZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdGllcyBmb3JkcmFmdC1icmFuZGVuYnVyZy1hdnQtcnRj cC1mb3ItaWRtcw0KDQoNCiAgICAgIERlYXIgR3JvdXAgbWVtYmVycywNCg0KICAgICAgQXMgdGhp cyBpcyBvdXIgZmlyc3QgbWFpbCB0byB0aGUgbGlzdCwgd2UgaW50cm9kdWNlIG91cnNlbHZlcy4g V2UgYXJlIEZlcm5hbmRvIEJvcm9uYXQgYW5kIE1hcmlvIE1vbnRhZ3VkLCBjby1hdXRob3JzIG9m IHRoZSBJbnRlcm5ldCBEcmFmdCAoSS1EKSAiUlRDUCBmb3IgaW50ZXItZGVzdGluYXRpb24gbWVk aWEgc3luY2hyb25pemF0aW9uIiAoZHJhZnQtaWV0Zi1hdnRjb3JlLWlkbXMtMDEudHh0KS4NCiAg ICAgIEFzIHRoZSBJLUQgd2FzIGFjY2VwdGVkIGFzIGEgV0cgZG9jdW1lbnQsIGFueSBjaGFuZ2Vz IHdpbGwgaGF2ZSB0byBiZSBhcHByb3ZlZCBieSB0aGUgQVZUQ09SRSBncm91cC4gU28sIHdlIHdv dWxkIGxpa2UgdG8ga25vdyBpZiB5b3UgY29uc2lkZXIgYXBwcm9wcmlhdGUgdG8gaW50cm9kdWNl IHNvbWUgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXRpZXMgdG8gdGhlIHByb3Bvc2VkIElETVMgYXBw cm9hY2ggaW4gdGhlIEktRC4gDQoNCiAgICAgIEluIG1hbnkgZGlzdHJpYnV0ZWQgYXBwbGljYXRp b25zIGl0IGlzIHJlcXVpcmVkIHRoYXQgYWxsIHRoZSByZWNlaXZlcnMgc3RhcnQgdGhlIHBsYXlv dXQgb2YgdGhlIG1lZGlhIHN0cmVhbSBhbG1vc3Qgc2ltdWx0YW5lb3VzbHkgKHdlIHJlZmVyIHRo aXMgYXMgQ29hcnNlIFN5bmMpIGFuZCwgYWZ0ZXIgdGhhdCwgYWxsIG9mIHRoZW0gcGxheS1vdXQg dGhlIG1lZGlhIGluIGEgc3luY2hyb25vdXMgd2F5ICh3ZSByZWZlciB0aGlzIGFzIEZpbmUgU3lu YykuIFRob3NlIHByb2Nlc3NlcyBhcmUgZXNzZW50aWFsIGZvciBhY3F1aXJpbmcgSURNUy4gQSBH bG9iYWwgSW5pdGlhbCBQbGF5b3V0IEluc3RhbnQgZm9yIGFsbCB0aGUgZ2VvZ3JhcGhpY2FsbHkg ZGlzdHJpYnV0ZWQgcmVjZWl2ZXJzIChTQ3MpIGluIGEgbWVkaWEgc2Vzc2lvbiBjb3VsZCBwcmV2 ZW50IGZyb20gYW4gaW5pdGlhbCBwbGF5b3V0IHRpbWUgZGlzY3JlcGFuY3kgKGFzeW5jaHJvbnkp IGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHBsYXlvdXQgb2YgdGhlIG1lZGlhIHN0cmVhbS9zIChp ZiBhIGZpeGVkIGdsb2JhbCBpbml0aWFsIGJ1ZmZlcmluZyBkZWxheSBpcyBzZXQpIG1haW5seSBk dWUgdG8gdGhlIHZhcmlhYmxlIG5ldHdvcmsgZGVsYXlzIGZyb20gdGhlIG1lZGlhIHNlcnZlciB0 byBlYWNoIG9uZSBvZiB0aGUgU0NzLg0KDQoNCiAgICAgIFRodXMsIHdlIGFyZSB0aGlua2luZyBh Ym91dCBpbmNsdWRpbmcgYSBuZXcgc2VjdGlvbiBpbiB0aGUgSS1EIGFib3V0IHBvc3NpYmxlIHBh Y2tldHMgZm9yIENvYXJzZSBTeW5jIGZvciBib3RoIHRoZSBpbml0aWFsIHBsYXlvdXQgaW5zdGFu dCAoYXQgdGhlIGJlZ2luaW5nIG9mIGEgbWVkaWEgc2Vzc2lvbikgYW5kIHRoZSBpbml0aWFsIGlu c3RhbnQgYXQgZWFjaCBzdGFnZSBpbiB3aGljaCB0aGUgc2Vzc2lvbiBjYW4gYmUgZGl2aWRlZCAo d2UgY29uc2lkZXIgdGhhdCBhIHN0YWdlIGVuZHMgd2hlbiBubyBzdHJlYW1zIGFyZSB0cmFuc21p dHRlZCBkdXJpbmcgYSBmaXhlZCBpbnRlcnZhbCAoaXQgY291bGQgYmUgZGVmaW5lZCBkZXBlbmRp bmcgb24gdGhlIGFwcGxpY2F0aW9ucyksIGFuZCB0aGF0IHRoZSBuZXh0IHN0YWdlIHN0YXJ0cyB3 aGVuIGRhdGEgaXMgdHJhbnNtaXR0ZWQgYWdhaW4pLg0KDQogICAgICBbUWluXTpZb3VyIHByb3Bv c2FsIGxvb2tzIGxpa2UgdG8gbWUgaXMgdG8gYWRkIEZpbmUgU3luYyBmdW5jdGlvbmFsaXR5IHRv IElETVMgZHJhZnQgaW4gdGhlIG1pZGRsZSBvZiBzZXNzaW9uLCBob3dldmVyIGl0IGlzIG5vdCBj bGVhciB0byBtZSB0aGUgZXhhY3QgdXNlIGNhc2UgKGlzIGl0IHBlcmlvZGljYWwgcGxheW91dClh bmQgd2hhdCdzIHRoZSByZWFsIGRpZmZlcmVuY2UgYmV0d2VlbiBDb2Fyc2UgU3luYyBhbmQgRmlu ZSBTeW5jIGluIHRlcm1zIG9mIFJUQ1Agc2lnbmFsaW5nPyBhcmUgeW91IHNheWluZyB0aGUgaW5p dGlhbCBhdCBlYWNoIHN0YWdlIGlzIGNhbGN1bGF0ZWQgbW9yZSBhY2N1cmF0ZSB0aGFuIGluaXRp YWwgcGxheW91dCBpbnN0YW50Pw0KDQogIFtBbnN3ZXJdIFRoZSBnb2FsIG9mIG91ciBwcm9wb3Nh bCBpbiBvdXIgbGFzdCBtYWlsIHdhcyBub3QgcmVsYXRlZCB3aXRoIGZpbmUgc3luY2hyb25pemF0 aW9uLiBGaW5lIFN5bmMgdGVjaG5pcXVlIGlzIHVzZWQgdG8gbWFpbnRhaW4gdGhlIHBsYXlvdXQg cHJvY2Vzc2VzIGJldHdlZW4gZGlzdHJpYnV0ZWQgU0NzIGluIGEgc3luY2hyb25pemVkIG1hbm5l ciBkdXJpbmcgdGhlIGV2b2x1dGlvbiBvZiB0aGUgc2Vzc2lvbiAob3IgZHVyaW5nIGVhY2ggc3Rh Z2VzIG9mIHRoZSBzZXNzaW9uLCBpZiBpdCBpcyBkaXZpZGVkIGludG8gZGlmZmVyZW50IHBoYXNl cykuICBEdXJpbmcgdGhlIHNlc3Npb24gKG9yIGl0cyBwaGFzZXMpLCBTQ3MgcmVwb3J0IG9uIHRo ZWlyIGFycml2YWwvcGxheW91dCB0aW1pbmcsIGFuZCB0aGUgTVNBUyBjYW4gc2VuZCB0byB0aGVt IHBsYXlvdXQgc2V0dGluZyBpbnN0cnVjdGlvbnMgaW4gb3JkZXIgdG8gbWFpbnRhaW4gZmluZSBz eW5jLCB1c2luZyBSVENQIElETVMgcGFja2V0cyAoZGVmaW5lZCBpbiB0aGUgSS1EKSwgaWYgYW4g b3V0IG9mIHN5bmMgc2l0dWF0aW9uIGlzIGRldGVjdGVkLg0KDQogIFRoZSBjb2Fyc2Ugc3luYyB0 ZWNobmlxdWUgd2UgaGVyZSBwcm9wb3NlIHRvIGJlIGluY2x1ZGVkIGluIG91ciBJLUQgd291bGQg bWFpbmx5IGFpbSB0byBwcmV2ZW50IGZyb20gaW5pdGlhbCBwbGF5b3V0IHRpbWUgZGlzY3JlcGFu Y2llcyBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBwbGF5b3V0IG9mIHRoZSBtZWRpYSBzdHJlYW0v cyBpbiBhIG11bHRpbWVkaWEgc2Vzc2lvbiAob3IgYXQgdGhlIGJlZ2lubmluZyBvZiBlYWNoIG9u ZSBvZiB0aGUgc3RhZ2VzIGluIHdoaWNoIGEgc2Vzc2lvbiBjYW4gYmUgZGl2aWRlZCksIGR1ZSB0 byB0aGUgZGVsYXkgdmFyaWFiaWxpdHkgZHVyaW5nIHRoZSBzZXNzaW9uIGZyb20gdGhlIHNlbmRl ciB0byBlYWNoIGdyb3VwIG9mIHNlcGFyYXRlZCBTQ3MgKFN5bmMgQ2xpZW50cykuIA0KDQogIEl0 IGNhbiBiZSBhY2hpZXZlZCBieSBkaXN0cmlidXRpbmcgdG8gdGhlIFNDcyBhIEdsb2JhbCBJbml0 aWFsIFBsYXlvdXQgSW5zdGFudCwgY2FycmllZCBvdXQgaW4gYSBSVENQIElETVMgcGFja2V0IHR5 cGUgZm9yIElETVMgKGFscmVhZHkgZGVmaW5lZCBpbiBvdXIgSS1EKSwgcHJpb3IgdGhlIHRyYW5z bWlzc2lvbiBvZiB0aGUgaW5pdGlhbCBSVFAgZGF0YSBwYWNrZXRzIG9mIGVhY2ggc3RhZ2UuIFRo aXMgd2F5LCB3ZSBjYW4gZW5zdXJlIGNvbmN1cnJlbnRseSBzaW5jcm9uaXplZCBwbGF5b3V0IHBv aW50cyBhdCB0aGUgc3RhcnRpbmcgcG9pbnQgb2YgZWFjaCBzdGFnZSwgZGVzcGl0ZSB0aGUgdmFy aWFibGUgbmV0d29yayBkZWxheXMgZnJvbSB0aGUgc2VuZGVyIHRvIHRoZSBTQ3MNCg0KICBbUWlu XTogU28geW91IHByb3Bvc2FsIGlzIHRvICBmaXggdGhlIGFzeW5jaHJvbml6YXRpb24gZnJvbSB0 aGUgYmVnaW5uaW5nIG9mIHNlc3Npb24gYmVmb3JlIG1lZGlhIHN0cmVhbSBpcyBzZW50IGZyb20g dGhlIG1lZGlhIHNvdXJjZS4gSXNuJ3QgaXQgYSBzaW1wbGUgd2F5IHRvIG1lYXN1cmUgZWFjaCBw cm9wYWdhdGlvbiB0aW1lIGZyb20gTVNBIHRvIGVhY2ggU0MgYW5kIGNob29zZSB0aGUgbGFyZ2Vz dCBwcm9wcmF0YXRpb24gdGltZSB0byBjYWxjdWFsdGUgdGhlIEluaXRpYWwgUGxheW91dCBJbnN0 YW50PyBJcyB0aGlzIHdoYXQgeW91IHdhbnQgdG8gc2F5PyANCg0KDQogICAgICBUaGlzIHRlY2hu aXF1ZSBoYXMgYmVlbiBjb25zaWRlcmVkIGluIHNvbWUgcHJldmlvdXMgSURNUyB3b3JrcyAoc2Vl IHJlZmVyZW5jZSBbQm9yb25hdDA5XSBpbiB0aGUgSS1EKSwgYnV0IHVzaW5nIHByb3ByaWV0YXJ5 IHByb3RvY29scy4gVGhlIG1ldGhvZHMgd2UgcHJvcG9zZSBoZXJlIGFyZSBiYXNlZCBvbiB0aGUg dXNlIG9mIGFscmVhZHkgZGVmaW5lZCBhbmQgc3RhbmRhcmQgUlRDUCBwYWNrZXRzLCB3aGljaCB3 b3VsZCBhdm9pZCB0aGUgaW50cm9kdWN0aW9uIG9mIHByb3ByaWV0YXJ5IGNsb3NlZCBzb2x1dGlv bnMuDQoNCiAgICAgIFJlZ2FyZGluZyB0aGUgSW5pdGlhbCBQbGF5b3V0IEluc3RhbnQsIHdlIGhh dmUgcHJpbWFyaWx5IHRob3VnaHQgYWJvdXQgdGhlIHVzZSBvZiBhbHJlYWR5IHByb3Bvc2VkIFJU Q1AgWFIgcGFja2V0cyAoUkZDIDM2MTEpOg0KDQogICAgICAxLiBVc2Ugb2YgUlRDUCBYUiB3aXRo IFJSVFIgYW5kIERMUlIgcmVwb3J0IGJsb2NrcyAoZGVmaW5lZCBSRkMgMzYxMSkgZm9yIG1lYXN1 cmluZyB0aGUgZGVsYXkgYmV0d2VlbiBNU0FTIGFuZCBTQ3MsIGFsbG93aW5nIE1TQVMgdG8gZXN0 aW1hdGUgdGhlIFJUVCBmb3IgYWxsIHRoZSBTQ3MsIHRoZW4gY2FsY3VsYXRlIGEgY29tbW9uIGlu aXRpYWwgcGxheW91dCBpbnN0YW50IGFuZCB0aGVuIGNvbW11bmljYXRlIGl0IHRvIGFsbCBTQ3Mg Ynkgc2VuZGluZyB0aGVtIGFuIFJUQ1AgSURNUyBQYWNrZXQgKGRlZmluZWQgaW4gdGhlIEktRCku IFRoZSBSVENQIElETVMgcGFja2V0IG11c3QgaW5jbHVkZSB0aGUgUlRQIFRpbWVzdGFtcCBvZiB0 aGUgZmlyc3QgTVUgdG8gYmUgc2VudCBieSB0aGUgc291cmNlIGFuZCBpdHMgcHJvcGVyIHBsYXlv dXQgaW5zdGFudCwgd2hpY2ggd2lsbCBiZSBjb21tb24gZm9yIGFsbCBvZiB0aGVtLg0KICAgICAg TVNBUyBtYXkgZXN0aW1hdGUgaXRzIHJvdW5kIHRyaXAgdGltZSAoUlRUKSB0byB0aGUgU0NzIGJ5 IHNlbmRpbmcgdGhlbSBhbiBSVENQIFhSIHdpdGggdGhlIFJlY2VpdmVyIFJlZmVyZW5jZSBUaW1l IFJlcG9ydCBCbG9jayBhbmQgZm9yY2luZyAoYWNjb3JkaW5nIHRvIFJGQyAzNjExKSB0aGVtIHRv IHJlcGx5IGJ5IHNlbmRpbmcgYW4gUlRDUCBYUiB3aXRoIGEgRExSUiBSZXBvcnQgQmxvY2suIE5v dGljZSB0aGF0IGJvdGggWFIgYmxvY2tzIGFyZSBkZWZpbmVkIGluIFJGQyAzNjExIHRvIGJlIHVz ZWQgaW4gdGhlIG9wcG9zaXRlIHdheSB3ZSBwcm9wb3NlLg0KDQogICAgICBbUWluXTogV2h5IG5v dCB1c2Ugcm91bmQgdHJpcCB0aW1lIGNvbXB1dGF0aW9uIG1ldGhvZCBkZWZpbmVkIGluIHRoZSBm aWd1cmUgMiBvZiBSRkMzNTUwLCBhcmUgeW91IHNheWluZyBpdCBpcyBub3QgYWxsb3dlZCB0byB1 c2UgU1IvUlIgcmVwb3J0cyBpbiBJRE1TIGNhc2UuDQoNCiAgW0Fuc3dlcl0gVG8gdGhlIGJlc3Qg b2Ygb3VyIGtub3dsZWRnZSwgcHJpb3IgdGhlIHRyYW5zbWlzc2lvbiBvZiBSVFAgZGF0YSBwYWNr ZXRzLCBuZWl0aGVyIFJUQ1AgU1Igbm9yIFJSIGFyZSBzZW50LCBhcmVuJ3QgdGhleT8uIFNvLCB0 aGUgZGVsYXkgZnJvbSB0aGUgc2VuZGVyIHRvIHRoZSBTQ3MgY291bGQgbm90IGJlIGNhbGN1bGF0 ZWQgdXNpbmcgdGhvc2UgcGFja2V0cyBhdCBsZWFzdCBhdCB0aGUgc3RhcnRpbmcgcG9pbnQgb2Yg dGhlIHNlc3Npb24gKG1heWJlIGF0IHRoZSBpbml0aWFsIHBvaW50cyBvZiBlYWNoIHN0YWdlLCBi dXQgd2UgYXJlIG5vdCBzdXJlKS4gSWYsIGF0IHRoZSBiZWdpbm5pbmcgb2YgZWFjaCBzdGFnZSwg dGhlIHNlc3Npb24gaGFzIGJlZW4gc3RvcHBlZCBkdXJpbmcgYSBsb25nIHBlcmlvZCBhbmQsIHRo ZXJlZm9yZSwgdGhlIG5ldHdvcmsgY29uZGl0aW9ucyAoZS5nLiwgZGVsYXlzIHRvIGVhY2ggU0Nz KSBoYXZlIHNpZ25pZmljYW50bHkgdmFyaWVkIHdlIHdpbGwgbmVlZCB0byBtb25pdG9yIHRoZW0u DQoNCiAgW1Fpbl06IEkgYWdyZWUgdXN1YWxseSBTUi9SUiBhcmUgc2VudCBhZnRlciB0aGUgdHJh bnNtaXNzaW9ub2YgUlRQIGRhdGEgcGFja2V0cy4gQnV0IGluIG15IHVuZGVyc3RhbmRpbmcsIGl0 IGlzIG5vdCBwcm9ibGVtIHRvIHNlbmQgU1IvUlIgcHJpb3IgdGhlIHRyYW5zbWlzc2lvbiBvZiBS VFAgZGF0YSBwYWNrZXRzIHNpbmNlIHRoZSBpcnJlbGF2YW50IGZpZWxkcyBpbiB0aGUgU1IvUlIg Y2FuIGJlIHNldCB0byB6ZXJvIHdoZW4gdGhlcmUgaXMgbm8gbWVkaWEgc3RyZWFtIGV4Y2hhbmdl ZC4NCg0KDQogICAgICBJZiB0aGlzIHNvbHV0aW9uIGlzIG5vdCBjb25zaWRlcmVkIGFwcHJvcHJp YXRlIHdlIGNvdWxkIHRoaW5rIGFib3V0IGFub3RoZXIgc29sdXRpb24gYmFzZWQgb24gdGhlIHBh Y2tldHMgYWxyZWFkeSBkZWZpbmVkIGluIHRoZSBJLUQsIGJ1dCBtYXliZSB3ZSB3b3VsZCBuZWVk IHRvIGNoYW5nZSB0aGUgZm9ybWF0IGFkZGluZyBuZXcgZmllbGQvcy4NCg0KICAgICAgMi4gT25j ZSBqb2luZWQgdGhlIHNlc3Npb24sIGlmIGl0IGlzIG5vdCBzdGFydGVkIHlldCwgYWxsIHRoZSBT Q3MgY291bGQgc3RhcnQgc2VuZGluZyBSVENQIFhSIHdpdGggSURNUyBibG9jayAodW50aWwgdGhl eSByZWNlaXZlIHRoZSBJbml0aWFsIFBsYXlvdXQgSW5zdGFudCBpbmRpY2F0aW9uLCBzZW50IHVz aW5nIHRoZSBSVENQIElETVMgUGFja2V0KSBhcyBpdCBpcyBkZWZpbmVkIGluIHRoZSBJLUQsIGJ1 dCBpbmNsdWRpbmcgb25seSB0aGUgZXNzZW50aWFsIHRpbWluZyBpbmZvcm1hdGlvbiAoZS5nLiB0 aGUgd2FsbGNsb2NrIHRpbWUgYXQgd2hpY2ggdGhlIHBhY2tldCBpcyBzZW50IGJ5IHRoZSBTQykg dG8gbGV0IHRoZSBNU0FTIGVzdGltYXRlIHRoZSBvbmUtd2F5IG5ldHdvcmsgZGVsYXlzIChub3Qg cm91bmQtdHJpcCBhcyBpbiB0aGUgcHJldmlvdXMgY2FzZSkgZm9yIGVhY2ggU0MgKGFzc3VtaW5n IHN5bW1ldHJpYyBkZWxheXMgYXMgaW4gVENQKSBhbmQgY2FsY3VsYXRlIHRoZSBJbml0aWFsIFBs YXlvdXQgSW5zdGFudC4gRm9yIHRoYXQgcHVycG9zZSwgc29tZSBmaWVsZCBvZiB0aGUgUlRDUCBY UiBJRE1TIGJsb2NrIHNob3VsZCBiZSB1c2VkIHRvIGluZGljYXRlIHRoZSBYUiBJRE1TIGJsb2Nr IGlzIGNhcnJ5aW5nIG91dCB0ZW1wb3JhbCBpbmZvcm1hdGlvbiBmb3IgQ29hcnNlIFN5bmMsIGFu ZCBub3QgZm9yIHJlcG9ydGluZyBhYm91dCBhcnJpdmFsL3BsYXlvdXQgdGltaW5nIG9mIGEgc3Bl Y2lmaWMgUlRQIHBhY2tldC4NCiAgICAgIEZyb20gdGhlIEluaXRpYWwgSW5zdGFudCB0aGV5IHdp bGwgY29udGludWUgcGxheWluZyB0aGUgc3RyZWFtcyBhbmQgc2VuZGluZyB0aGUgUlRDUCBYUiB3 aXRoIElETVMgY29tcGxldGUgYmxvY2sgKGFzIGN1cnJlbnRseSBkZWZpbmVkIGluIHRoZSBJLUQp LiBJdCBjb3VsZCBiZSBhIHBvc3NpYmxlIHNvbHV0aW9uLg0KDQogICAgICBbUWluXTogWW91IGNh biB1c2UgRGVsYXkgbWV0cmljIHJlcG9ydCBkZWZpbmVkIGluIGRyYWZ0LWlldGYtYXZ0LXJ0Y3At eHItZGVsYXktMDIgdG8gZGlyZWN0bHkgZ2V0IG9uZS13YXkgbmV0d29yayBkZWxheXMuIEFsc28g bWF4aW11bSBhbmQgbWluaW11bSBuZXR3b3JrIGRlbGF5cyBjYW4gYmUgb2J0YWluZWQgZnJvbSB0 aGlzIFhSIHJlcG9ydC4NCg0KICBUaGFuayB5b3UgZm9yIHRoZSBzdWdnZXN0aW9uLiANCg0KICBJ biBvdXIgcmVzcG9uc2UgdG8gS2V2aW4gR3Jvc3Mgd2UgcHJvcG9zZSBhbiBhbHRlcm5hdGl2ZSB0 byBjYWxjdWxhdGUgb25lLXdheSBkZWxheXMgZnJvbSBzb3VyY2UgdG8gU0NzIHVzaW5nIG9ubHkg dGhlIHBhY2tldHMgZGVmaW5lZCBpbiB0aGUgSS1ELiBQbGVhc2UsIHRlbGwgdXMgeW91ciBvcGlu aW9uIGFib3V0IGl0Lg0KDQogIFtRaW5dOiBNeSBwb2ludCBpcyBvbmUgd2F5IGRlbGF5cyBmcm9t IHNvdXJjZSB0byBTQyBtYXkgYmUgbm90IDEvMiBvZiBuZXR3b3JrIHJvdW5kIHRyaXAgZGVsYXkg c2luY2U6DQogIE5ldHdvcmsgcm91bmQgdHJpcCBkZWxheSA9IG9uZSB3YXkgZGVsYXkgZnJvbSBz b3VyY2UgdG8gU0MgKyBvbmUgd2F5IGRlbGF5IGZyb20gU0MgdG8gdGhlIFNvdXJjZSwgDQogIE9u ZSB3YXkgZGVsYXkgZnJvbSBzb3VyY2UgdG8gU0MgbWF5IG5vdCBlcXVhbCB0byBvbmUgd2F5IGRl bGF5IGZyb20gU0MgdG8gdGhlIFNvdXJjZS4NCg0KICBUaGVyZWZvcmUsIGV2ZW4geW91IHJlbHkg b24gUlRDUCBYUiB3aXRoIFJSVFIgYW5kIERMUlIsIHlvdSBzdGlsbCBnZXQgcm91bmQgdHJpcCB0 aW1lIGJldHdlZW4gc291cmNlIGFuZCBTQyByYXRoZXIgdGhhbiBvbmUgd2F5IGRlbGF5Lg0KDQog IFdlIHRob3VnaHQgYWJvdXQgdGhlIHVzZSBvZiBSVENQIFhSIFJSVFIgYW5kIERMUlIgKGFscmVh ZHkgZGVmaW5lZCBpbiBhbiBSRkMgMzYxMSBhbmQgbm90IGFib3V0IHBhY2tldHMgZGVmaW5lZCBp biBhIL9vbGQvZXhwaXJlZD8gZHJhZnQgLTIwMDktKSBiZWNhdXNlIHRoZXNlIFhSIGJsb2NrcyBh cmUgYWxyZWFkeSBzdGFuZGFyZGl6ZWQgYW5kIGNvdWxkIGJlIHVzZWZ1bCBmb3Igb3VyIENvYXJz ZSBTeW5jIHB1cnBvc2VzLiBNb3Jlb3ZlciwgaW4gc3VjaCBhIHdheSwgU0NzIG11c3Qgb25seSBz ZW5kIFJUQ1AgWFIgd2l0aCBETFJSIGJsb2NrcyBhcyBhIHJlc3BvbnNlIHRvIGFuIGluY29taW5n IFJUQ1AgWFIgd2l0aCBSUlRSIGJsb2NrLCBzZW50IGJ5IHRoZSBzb3VyY2UsIHdoaWNoIGlzIHdo byByZWFsbHkga25vd3MgdGhlIGluaXRpYWwgdHJhbnNtaXNzaW9uIGluc3RhbnQgKHRodXMsIHVu bmVjZXNzYXJ5IFJUQ1AgcGFja2V0IHdvdWxkIG5vdCBiZSBzZW50KS4NCiAgVGhlbiwgdGhlIElu aXRpYWwgUGxheW91dCBJbnN0YW50IHdvdWxkIGJlIGNhbGN1bGF0ZWQgYnkgdGFraW5nIGludG8g Y29uc2lkZXJhdGlvbiB0aGUgZXN0aW1hdGVkIG5ldHdvcmsgZGVsYXlzLCBpbiBvcmRlciB0byBh bGxvdyBhbGwgdGhlIFNDcyB0byBoYXZlIGJ1ZmZlcmVkIHN1ZmZpY2llbnQgUlRQIGRhdGEgcGFj a2V0cyB0byBzbW9vdGggb3V0IHRoZSBlZmZlY3Qgb2YgbmV0d29yayBqaXR0ZXIsIHBvc3NpYmxl IHBsYXlvdXQgcmF0ZSBkZXZpYXRpb25zIG9yIHNwb3JhZGljIGNvbmdlc3Rpb24gY2FzZXMsIHRo dXMgbWFpbnRhaW5pbmcgYSBjb250aW51b3VzIHBsYXlvdXQgcHJvY2VzcyBkdXJpbmcgdGhlIHNl c3Npb24uDQoNCiAgRG8geW91IHRoaW5rIHRoYXQgdGhlIHVzZSBvZiB0aGUgcGFja2V0cyBkZWZp bmVkIGluIHRoZSC/b2xkL2V4cGlyZWQ/IGRyYWZ0IHNob3VsZCBiZSB1c2VkIHRvIHRoaXMgcHVy cG9zZT8gSW4gdGhhdCBjYXNlIHdlIHdvdWxkIG5lZWQgdG8gbW9kaWZ5IHRoZWlyIGZvcm1hdCB0 byBtYWtlIHRoZW0gbW9yZSBhcHByb3ByaWF0ZSBmb3Igb3VyIG5lZWRzLg0KDQogIFtRaW5dOiBB cyBJIHNhaWQgYWJvdmUsIG9uZSB3YXkgZGVsYXkgZnJvbSBzb3VyY2UgdG8gU0MgbWF5IGJlIG5v dCAxLzIgcm91bmQgdHJpcCB0aW1lIGJldHdlZW4gc291cmNlIGFuZCBTQy4gSWYgeW91IHdhbnQg dG8gbWVhc3VyZSBvbmUgd2F5IGRlbGF5IGZyb20gc291cmNlIHRvIFNDIG1vcmUgcHJlY2lzZWx5 LCB5b3UgbmVlZCBhIG5ldyBtZWFzdXJlbWVudCBtZXRob2QgZm9yIG9uZSB3YXkgZGVsYXkgZnJv bSBzb3VyY2UgdG8gdGhlIFNDLg0KICBZZXMsIGRyYWZ0LWlldGYtYXZ0LXJ0Y3AteHItZGVsYXkt MDIgaGFzIGJlZW4gcmV2aXZlZCBpbnRvIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWRlbGF5 LTAwLiBJdCBpcyBub3QgYSBwcm9ibGVtIHlvdSB1c2UgZGVsYXkgbWV0cmljIGluIHRoZSBkcmFm dC1pZXRmLXhyYmxvY2stcnRjcC14ci1kZWxheS0wMCBieSBleHRlbmRpbmcgaXQgZm9yIHlvdXIg cHVycG9zZS4gQWxzbyB5b3UgY2FuIHdyaXRlIGEgbmV3IGRyYWZ0IHRvIGRlZmluZSBhIG5ldyBt ZXRyaWMgZm9yIHlvdXIgcHVycG9zZS4gU3VjaCBkcmFmdCBzaG91bGQgYmUgc3VtaXR0ZWQgdG8g WFJCbG9jayBXRy4NCg0KDQogICAgICBbUWluXSBJIHRoaW5rIHlvdSBjYW4gcmVseSBvbiBkcmFm dC1pZXRmLWF2dC1ydGNwLXhyLW1lYXMtaWRlbnRpdHkgdG8ga25vdyBleHBlY3RlZCBkdXJhdGlv biBvZiB0aGUgc2Vzc2lvbi4NCiAgICAgIHlvdSBtYXkgcmVseSBvbiBkcmFmdC1pZXRmLXhyYmxv Y2stcnRjcC14ci1wZHYtMDAgdG8gZ2V0IGppdHRlciB2YWx1ZXMuDQogICAgICBCdXQgWFJCTG9j ayBpcyBub3QgdGhlIHJpZ2h0IHBsYWNlIHRvIHNlZWsgZm9yIHRoZSBtZWFzdXJlbWVudCBtZXRo b2QsIHdoaWNoIGlzIGRlZmluZWQgc29tZXdoZXJlIGVsc2UsIGUuZy4sIGluIG90aGVyIFJGQyBs aWtlIFJGQzM1NTAsIG90aGVyIFdHcywgb3Igb3RoZXIgU0RPcy4NCiAgW0Fuc3dlcl0gVGhhbmsg eW91IGZvciB5b3VyIGhlbHBmdWwgc3VnZ2VzdGlvbi4gSW4gdGhlIEktRCB3ZSBvbmx5IHdhbnQg dG8gcHJvcG9zZSB0aGUgcGFja2V0cyB0byBiZSB1c2VkIGZvciBvdXIgcHVycG9zZS4gVGhlIGNh bGN1bGF0aW9uIG1ldGhvZHMsIGFzIHdlIG1lbnRpb25lZCBhYm92ZSwgYXJlIG91dCBvZiB0aGUg c2NvcGUgb2YgdGhlIElELiANCg0KICBUaGFuayBZb3UgYWdhaW4gZm9yIHlvdXIgY29tbWVudHMN Cg0KICBNb3JlIGZlZWRiYWNrIGFib3V0IGl0IGZyb20gdGhlIEFWVENvcmUgZ3JvdXAgbWVtYmVy cyB3aWxsIGJlIG11Y2ggYXBwcmVjaWF0ZWQuDQoNCg0KDQogICAgICBXaXRoIHRoZSBpbnRyb2R1 Y3Rpb24gb2YgdGhlIENvYXJzZSBTeW5jIGZ1bmN0aW9uYWxpdHksIHRoZSBJRE1TIHByb3Bvc2Fs IGNhbiBjb3VudGVyYWN0IHRoZSBlZmZlY3Qgb2YgdGhlIGRlbGF5IHZhcmlhYmlsaXR5IGF0IHRo ZSBiZWdpbm5pbmcgb2YgdGhlIHBsYXlvdXQgb2YgdGhlIG1lZGlhIHN0cmVhbS9zIGluIGVhY2gg b25lIG9mIHRoZSBzdGFnZXMgaW4gd2hpY2ggYSBtZWRpYSBzZXNzaW9uIGNhbiBiZSBkaXZpZGVk Lg0KDQogICAgICBXZSBwcmVmZXIgdGhlIGZpcnN0IG1ldGhvZCBiZWNhdXNlIHRoZXJlIGlzIG5v IG5lZWQgdG8gZGVmaW5lIG5ldyBJRE1TIGNvbnRyb2wgbWVzc2FnZXMgKG9yIHRvIGluY2x1ZGUg c29tZSBmaWVsZHMgdG8gYWxyZWFkeSBkZWZpbmVkIHBhY2tldHMpLCBidXQgdGhlIHVzZSBvZiBh bHJlYWR5IGRlZmluZWQgUlRDUCByZXBvcnRzIChSRkMgMzYxMSkgY2FuIGJlIGFkYXB0ZWQgZm9y IHRoYXQgcHVycG9zZS4gDQoNCiAgICAgIE1vcmVvdmVyLCB3aXRoIHRoZSB1c2Ugb2YgdGhlIGZp cnN0IG1ldGhvZCwgU0NzIGRvIG5vdCBoYXZlIHRvIHNlbmQgY29udHJvbCBtZXNzYWdlcyBvbmNl IHRoZXkgam9pbiB0aGUgc2Vzc2lvbiwgd2hpY2ggbWF5IHBvc3NpYmx5IHJlc3VsdCBvbiBpbmVm ZmljaWVudCBjb250cm9sIHRyYWZmaWMgb3ZlcmhlYWQuIFRoZXkgd2lsbCBvbmx5IGhhdmUgdG8g c2VuZCBSVENQIFhSIERMUlIgbWVzc2FnZXMgaW4gcmVzcG9uc2UgdG8gYSBuZXcgaW5jb21pbmcg UlRSUiBtZXNzYWdlIGZyb20gdGhlIHNvdXJjZSwgd2hpY2ggaXMgd2hvIHJlYWxseSBrbm93cyB0 aGUgaW5pdGlhbCB0cmFuc21pc3Npb24gdGltZSBmb3IgdGhlIFJUUCBtZWRpYSBzdHJlYW0uIE1v cmVvdmVyLCB0aGUgSW5pdGlhbCBQbGF5b3V0IEluc3RhbnQgY2FuIGJlIHNlbnQgdG8gdGhlIHJl Y2VpdmVycyBieSB1c2luZyB0aGUgUlRDUCBJRE1TIHBhY2tldCwgYWxyZWFkeSBpbnRyb2R1Y2Vk IGluIHRoZSBJLUQuDQoNCiAgICAgIEZlZWRiYWNrIHdpbGwgYmUgbXVjaCBhcHByZWNpYXRlZC4N Cg0KUmVnYXJkcw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEci4gRmVybmFuZG8gQm9yb25hdCBTZWd17Q0K SUVFRSBTZW5pb3IgTWVtYmVyDQpQcm9mZXNvciBUaXR1bGFyIC8gTGVjdHVyZXIJDQpEZXB0LiBD b211bmljYWNpb25lcyAgICAgICAgICAgVGxmLi0rMzQrOTYyIDg0OSAzMDAgRXh0Li00OTM0MQ0K VGxmLiBkaXJlY3RvIC0rMzQrOTYyIDg0OSAzNDEgIEZheC4tKzM0Kzk2MiA4NDkgMzA5IChDb21w YXJ0aWRvKQ0KVU5JVkVSU0lEQUQgUE9MSVTJQ05JQ0EgREUgVkFMRU5DSUEtQ0FNUFVTIERFIEdB TkRJQQ0KQ2FsbGUgUGFyYXJhbmluZm8sIDEsIENQLiA0NjczMCwgR3JhbyBkZSBHYW5kaWEgKFZh bGVuY2lhKSwgU1BBSU4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAg IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQogICAgICBhdnRAaWV0Zi5v cmcNCiAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQoNCg0K DQotLSANClNhbHVkb3MvUmVnYXJkcw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEci4gRmVybmFuZG8gQm9y b25hdCBTZWd17Q0KUHJvZmVzb3IgVGl0dWxhciAvIExlY3R1cmVyCQ0KRGVwdC4gQ29tdW5pY2Fj aW9uZXMgICAgICAgICAgIFRsZi4tKzM0Kzk2MiA4NDkgMzAwIEV4dC4tNDkzNDENClRsZi4gZGly ZWN0byAtKzM0Kzk2MiA4NDkgMzQxICBGYXguLSszNCs5NjIgODQ5IDMwOSAoQ29tcGFydGlkbykN ClVOSVZFUlNJREFEIFBPTElUyUNOSUNBIERFIFZBTEVOQ0lBLUNBTVBVUyBERSBHQU5ESUENCkNh bGxlIFBhcmFyYW5pbmZvLCAxLCBDUC4gNDY3MzAsIEdyYW8gZGUgR2FuZGlhIChWYWxlbmNpYSks IFNQQUlODQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0= --Boundary_(ID_TrBr9HUYBaN6AqU0NpPrqA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTEyMCI+PC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0j ZmZmZmZmIHRleHQ9IzAwMDAwMD4NCjxESVY+SGksIEZlcm5hbmRvOjwvRElWPg0KPEJMT0NLUVVP VEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6 IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6 IDBweCIgDQpkaXI9bHRyPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3 OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9O VDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IEJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6 IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPWZib3JvbmF0QGRjb20udXB2LmVzIGhy ZWY9Im1haWx0bzpmYm9yb25hdEBkY29tLnVwdi5lcyI+RmVybmFuZG8gDQogIEJvcm9uYXQgU2Vn de08L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+ PEI+VG86PC9CPiA8QSB0aXRsZT1hdnRAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzphdnRAaWV0 Zi5vcmciPmF2dEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAm IzIzNDM1OyYjMjAzMDc7Ij48Qj5DYzo8L0I+IDxBIHRpdGxlPWJpbGwud3VAaHVhd2VpLmNvbSAN CiAgaHJlZj0ibWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbSI+YmlsbC53dUBodWF3ZWkuY29tPC9B PiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNl bnQ6PC9CPiBUaHVyc2RheSwgT2N0b2JlciAyMCwgMjAxMSAyOjUwIA0KQU08L0RJVj4NCiAgPERJ ViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBSZTog W0FWVENPUkVdIFBvc3NpYmxlIEFkZGl0aW9uYWwgDQogIGZ1bmN0aW9uYWxpdGllcyBmb3JkcmFm dC1icmFuZGVuYnVyZy1hdnQtcnRjcC1mb3ItaWRtczwvRElWPg0KICA8RElWPjxCUj48L0RJVj5E ZWFyIFFpbiw8QlI+PEJSPlRoYW5rIFlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29tbWVudHMuIEkg dHJ5IA0KICB0byBhbnN3ZXIgdGhlbSBiZWxvdy48QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlk OkNERUJENUExRTY2NDQ3QzY5OTczMkRGQjMyM0QzQjQ0QGNoaW5hLmh1YXdlaS5jb20gDQogIHR5 cGU9ImNpdGUiPg0KICAgIDxCTE9DS1FVT1RFIA0KICAgIHN0eWxlPSJCT1JERVItTEVGVDogIzAw MDAwMCAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1B UkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICAgIDxESVYgc3R5bGU9IkZP TlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwv RElWPg0KICAgICAgPERJViANCiAgICAgIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3 OzsgQkFDS0dST1VORDogI2U0ZTRlNDsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiAN CiAgICAgIDxBIHRpdGxlPWZib3JvbmF0QGRjb20udXB2LmVzIGhyZWY9Im1haWx0bzpmYm9yb25h dEBkY29tLnVwdi5lcyIgDQogICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPkZlcm5hbmRvIEJv cm9uYXQgU2Vnde08L0E+IDwvRElWPg0KICAgICAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9YXZ0QGlldGYub3JnIA0KICAgICAgaHJl Zj0ibWFpbHRvOmF2dEBpZXRmLm9yZyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5hdnRAaWV0Zi5v cmc8L0E+IDsgPEEgDQogICAgICB0aXRsZT14cmJsb2NrLXJlcXVlc3RAaWV0Zi5vcmcgaHJlZj0i bWFpbHRvOnhyYmxvY2stcmVxdWVzdEBpZXRmLm9yZyIgDQogICAgICBtb3otZG8tbm90LXNlbmQ9 InRydWUiPnhyYmxvY2stcmVxdWVzdEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogICAgICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IFR1ZXNkYXksIE9j dG9iZXIgMTEsIDIwMTEgNTo1NCANCiAgICAgIFBNPC9ESVY+DQogICAgICA8RElWIHN0eWxlPSJG T05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFtBVlRDT1JFXSBQb3Nz aWJsZSBBZGRpdGlvbmFsIA0KICAgICAgZnVuY3Rpb25hbGl0aWVzIGZvcmRyYWZ0LWJyYW5kZW5i dXJnLWF2dC1ydGNwLWZvci1pZG1zPC9ESVY+DQogICAgICA8RElWPjxCUj48L0RJVj4NCiAgICAg IDxESVY+RGVhciBHcm91cCBtZW1iZXJzLDxCUj48QlI+QXMgdGhpcyBpcyBvdXIgZmlyc3QgbWFp bCB0byB0aGUgbGlzdCwgd2UgDQogICAgICBpbnRyb2R1Y2Ugb3Vyc2VsdmVzLiBXZSBhcmUgRmVy bmFuZG8gQm9yb25hdCBhbmQgTWFyaW8gTW9udGFndWQsIA0KICAgICAgY28tYXV0aG9ycyBvZiB0 aGUgSW50ZXJuZXQgRHJhZnQgKEktRCkgk1JUQ1AgZm9yIGludGVyLWRlc3RpbmF0aW9uIG1lZGlh IA0KICAgICAgc3luY2hyb25pemF0aW9ulCAoZHJhZnQtaWV0Zi1hdnRjb3JlLWlkbXMtMDEudHh0 KS48QlI+QXMgdGhlIEktRCB3YXMgDQogICAgICBhY2NlcHRlZCBhcyBhIFdHIGRvY3VtZW50LCBh bnkgY2hhbmdlcyB3aWxsIGhhdmUgdG8gYmUgYXBwcm92ZWQgYnkgdGhlIA0KICAgICAgQVZUQ09S RSBncm91cC4gU28sIHdlIHdvdWxkIGxpa2UgdG8ga25vdyBpZiB5b3UgY29uc2lkZXIgYXBwcm9w cmlhdGUgdG8gDQogICAgICBpbnRyb2R1Y2Ugc29tZSBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdGll cyB0byB0aGUgcHJvcG9zZWQgSURNUyBhcHByb2FjaCBpbiANCiAgICAgIHRoZSBJLUQuIDxCUj48 QlI+SW4gbWFueSBkaXN0cmlidXRlZCBhcHBsaWNhdGlvbnMgaXQgaXMgcmVxdWlyZWQgdGhhdCBh bGwgDQogICAgICB0aGUgcmVjZWl2ZXJzIHN0YXJ0IHRoZSBwbGF5b3V0IG9mIHRoZSBtZWRpYSBz dHJlYW0gYWxtb3N0IHNpbXVsdGFuZW91c2x5IA0KICAgICAgKHdlIHJlZmVyIHRoaXMgYXMgQ29h cnNlIFN5bmMpIGFuZCwgYWZ0ZXIgdGhhdCwgYWxsIG9mIHRoZW0gcGxheS1vdXQgdGhlIA0KICAg ICAgbWVkaWEgaW4gYSBzeW5jaHJvbm91cyB3YXkgKHdlIHJlZmVyIHRoaXMgYXMgRmluZSBTeW5j KS4gVGhvc2UgcHJvY2Vzc2VzIA0KICAgICAgYXJlIGVzc2VudGlhbCBmb3IgYWNxdWlyaW5nIElE TVMuIEEgR2xvYmFsIEluaXRpYWwgUGxheW91dCBJbnN0YW50IGZvciBhbGwgDQogICAgICB0aGUg Z2VvZ3JhcGhpY2FsbHkgZGlzdHJpYnV0ZWQgcmVjZWl2ZXJzIChTQ3MpIGluIGEgbWVkaWEgc2Vz c2lvbiBjb3VsZCANCiAgICAgIHByZXZlbnQgZnJvbSBhbiBpbml0aWFsIHBsYXlvdXQgdGltZSBk aXNjcmVwYW5jeSAoYXN5bmNocm9ueSkgYXQgdGhlIA0KICAgICAgYmVnaW5uaW5nIG9mIHRoZSBw bGF5b3V0IG9mIHRoZSBtZWRpYSBzdHJlYW0vcyAoaWYgYSBmaXhlZCBnbG9iYWwgaW5pdGlhbCAN CiAgICAgIGJ1ZmZlcmluZyBkZWxheSBpcyBzZXQpIG1haW5seSBkdWUgdG8gdGhlIHZhcmlhYmxl IG5ldHdvcmsgZGVsYXlzIGZyb20gdGhlIA0KICAgICAgbWVkaWEgc2VydmVyIHRvIGVhY2ggb25l IG9mIHRoZSBTQ3MuPC9ESVY+PC9CTE9DS1FVT1RFPg0KICAgIDxCTE9DS1FVT1RFIA0KICAgIHN0 eWxlPSJCT1JERVItTEVGVDogcmdiKDAsMCwwKSAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4 OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4 Ij4NCiAgICAgIDxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+ PEJSPjxCUj5UaHVzLCB3ZSBhcmUgdGhpbmtpbmcgYWJvdXQgDQogICAgICBpbmNsdWRpbmcgYSBu ZXcgc2VjdGlvbiBpbiB0aGUgSS1EIGFib3V0IHBvc3NpYmxlIHBhY2tldHMgZm9yIENvYXJzZSBT eW5jIA0KICAgICAgZm9yIGJvdGggdGhlIGluaXRpYWwgcGxheW91dCBpbnN0YW50IChhdCB0aGUg YmVnaW5pbmcgb2YgYSBtZWRpYSBzZXNzaW9uKSANCiAgICAgIGFuZCB0aGUgaW5pdGlhbCBpbnN0 YW50IGF0IGVhY2ggc3RhZ2UgaW4gd2hpY2ggdGhlIHNlc3Npb24gY2FuIGJlIGRpdmlkZWQgDQog ICAgICAod2UgY29uc2lkZXIgdGhhdCBhIHN0YWdlIGVuZHMgd2hlbiBubyBzdHJlYW1zIGFyZSB0 cmFuc21pdHRlZCBkdXJpbmcgYSANCiAgICAgIGZpeGVkIGludGVydmFsIChpdCBjb3VsZCBiZSBk ZWZpbmVkIGRlcGVuZGluZyBvbiB0aGUgYXBwbGljYXRpb25zKSwgYW5kIA0KICAgICAgdGhhdCB0 aGUgbmV4dCBzdGFnZSBzdGFydHMgd2hlbiBkYXRhIGlzIHRyYW5zbWl0dGVkIGFnYWluKS48L0RJ Vj4NCiAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPg0KICAgICAgPERJVj5bUWlu XTpZb3VyIHByb3Bvc2FsIGxvb2tzIGxpa2UgdG8gbWUgaXMgdG8gYWRkIEZpbmUgU3luYyANCiAg ICAgIGZ1bmN0aW9uYWxpdHkgdG8gSURNUyBkcmFmdCBpbiB0aGUgbWlkZGxlIG9mIHNlc3Npb24s IGhvd2V2ZXIgaXQgaXMgbm90IA0KICAgICAgY2xlYXIgdG8gbWUgdGhlIGV4YWN0IHVzZSBjYXNl IChpcyBpdCBwZXJpb2RpY2FsIHBsYXlvdXQpYW5kIHdoYXQncyB0aGUgDQogICAgICByZWFsIGRp ZmZlcmVuY2UgYmV0d2VlbiBDb2Fyc2UgU3luYyBhbmQgRmluZSBTeW5jIGluIHRlcm1zIG9mIFJU Q1AgDQogICAgICBzaWduYWxpbmc/IGFyZSB5b3Ugc2F5aW5nIHRoZSBpbml0aWFsIGF0IGVhY2gg c3RhZ2UmbmJzcDtpcyBjYWxjdWxhdGVkIA0KICAgICAgbW9yZSBhY2N1cmF0ZSB0aGFuIGluaXRp YWwgcGxheW91dCANCiAgaW5zdGFudD88QlI+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxP Q0tRVU9URT4NCiAgPERJVj4NCiAgPE1FVEEgbmFtZT1Qcm9nSWQgY29udGVudD1Xb3JkLkRvY3Vt ZW50Pg0KICA8TUVUQSBuYW1lPUdlbmVyYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCI+ DQogIDxNRVRBIG5hbWU9T3JpZ2luYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCI+PExJ TksgcmVsPUZpbGUtTGlzdCANCiAgaHJlZj0iZmlsZTovLy9DOiU1Q1VzZXJzJTVDZmJvcm9uYXQl NUNBcHBEYXRhJTVDTG9jYWwlNUNUZW1wJTVDbXNvaHRtbGNsaXAxJTVDMDElNUNjbGlwX2ZpbGVs aXN0LnhtbCI+PExJTksgDQogIHJlbD10aGVtZURhdGEgDQogIGhyZWY9ImZpbGU6Ly8vQzolNUNV c2VycyU1Q2Zib3JvbmF0JTVDQXBwRGF0YSU1Q0xvY2FsJTVDVGVtcCU1Q21zb2h0bWxjbGlwMSU1 QzAxJTVDY2xpcF90aGVtZWRhdGEudGhteCI+PExJTksgDQogIHJlbD1jb2xvclNjaGVtZU1hcHBp bmcgDQogIGhyZWY9ImZpbGU6Ly8vQzolNUNVc2VycyU1Q2Zib3JvbmF0JTVDQXBwRGF0YSU1Q0xv Y2FsJTVDVGVtcCU1Q21zb2h0bWxjbGlwMSU1QzAxJTVDY2xpcF9jb2xvcnNjaGVtZW1hcHBpbmcu eG1sIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3OlZp ZXc+Tm9ybWFsPC93OlZpZXc+DQogIDx3Olpvb20+MDwvdzpab29tPg0KICA8dzpUcmFja01vdmVz Lz4NCiAgPHc6VHJhY2tGb3JtYXR0aW5nLz4NCiAgPHc6SHlwaGVuYXRpb25ab25lPjIxPC93Okh5 cGhlbmF0aW9uWm9uZT4NCiAgPHc6UHVuY3R1YXRpb25LZXJuaW5nLz4NCiAgPHc6VmFsaWRhdGVB Z2FpbnN0U2NoZW1hcy8+DQogIDx3OlNhdmVJZlhNTEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1M SW52YWxpZD4NCiAgPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29u dGVudD4NCiAgPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93 UGxhY2Vob2xkZXJUZXh0Pg0KICA8dzpEb05vdFByb21vdGVRRi8+DQogIDx3OkxpZFRoZW1lT3Ro ZXI+Tkw8L3c6TGlkVGhlbWVPdGhlcj4NCiAgPHc6TGlkVGhlbWVBc2lhbj5aSC1UVzwvdzpMaWRU aGVtZUFzaWFuPg0KICA8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+WC1OT05FPC93OkxpZFRoZW1l Q29tcGxleFNjcmlwdD4NCiAgPHc6Q29tcGF0aWJpbGl0eT4NCiAgIDx3OkJyZWFrV3JhcHBlZFRh Ymxlcy8+DQogICA8dzpTbmFwVG9HcmlkSW5DZWxsLz4NCiAgIDx3OldyYXBUZXh0V2l0aFB1bmN0 Lz4NCiAgIDx3OlVzZUFzaWFuQnJlYWtSdWxlcy8+DQogICA8dzpEb250R3Jvd0F1dG9maXQvPg0K ICAgPHc6U3BsaXRQZ0JyZWFrQW5kUGFyYU1hcmsvPg0KICAgPHc6RW5hYmxlT3BlblR5cGVLZXJu aW5nLz4NCiAgIDx3OkRvbnRGbGlwTWlycm9ySW5kZW50cy8+DQogICA8dzpPdmVycmlkZVRhYmxl U3R5bGVIcHMvPg0KICAgPHc6VXNlRkVMYXlvdXQvPg0KICA8L3c6Q29tcGF0aWJpbGl0eT4NCiAg PG06bWF0aFByPg0KICAgPG06bWF0aEZvbnQgbTp2YWw9IkNhbWJyaWEgTWF0aCIvPg0KICAgPG06 YnJrQmluIG06dmFsPSJiZWZvcmUiLz4NCiAgIDxtOmJya0JpblN1YiBtOnZhbD0iJiM0NTstIi8+ DQogICA8bTpzbWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0KICAgPG06ZGlzcERlZi8+DQogICA8bTps TWFyZ2luIG06dmFsPSIwIi8+DQogICA8bTpyTWFyZ2luIG06dmFsPSIwIi8+DQogICA8bTpkZWZK YyBtOnZhbD0iY2VudGVyR3JvdXAiLz4NCiAgIDxtOndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4N CiAgIDxtOmludExpbSBtOnZhbD0ic3ViU3VwIi8+DQogICA8bTpuYXJ5TGltIG06dmFsPSJ1bmRP dnIiLz4NCiAgPC9tOm1hdGhQcj48L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRl PSJmYWxzZSIgRGVmVW5oaWRlV2hlblVzZWQ9InRydWUiDQogIERlZlNlbWlIaWRkZW49InRydWUi IERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiDQogIExhdGVudFN0eWxlQ291bnQ9 IjI2NyI+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMCIgU2Vt aUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9Ik5vcm1hbCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDIiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5 IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDci Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDkiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDEiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9j IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFt ZT0idG9jIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIz OSIgTmFtZT0idG9jIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzOSIgTmFtZT0idG9jIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDgiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDkiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iY2FwdGlvbiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjEwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIxIiBOYW1lPSJEZWZhdWx0IFBhcmFncmFwaCBGb250Ii8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTEiIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIyIiBTZW1pSGlk ZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iU3Ryb25nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjU5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJQbGFjZWhvbGRlciBUZXh0Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vIFNw YWNpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0 IFNoYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ikxp Z2h0IExpc3QiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ikxp Z2h0IEdyaWQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQg MSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlz dCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgR3JpZCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2Nl bnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJSZXZpc2lvbiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjM0IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyOSIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzAiIFNlbWlIaWRkZW49 ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJ bnRlbnNlIFF1b3RlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2Vu dCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExp c3QgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNj ZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0 IExpc3QgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEg QWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBB Y2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQg MyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlz dCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2Nl bnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBT ZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IExpc3QgMiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2Vu dCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBTaGFkaW5nIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFj Y2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIi IFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdo dCBHcmlkIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlz dCAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNo YWRpbmcgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50 IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2Vt aUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdy aWQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIg QWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGlu ZyBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i Q29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlk ZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBB Y2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYz IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2Nl bnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBT ZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IEdyaWQgMSBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFj Y2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIi IFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xv cmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMSIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Iklu dGVuc2UgRW1waGFzaXMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzMSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFG b3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNl Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzMiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJCb29rIFRpdGxlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzciIE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIv Pg0KIDwvdzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtlbmRpZl0tLT4NCiAgPFNUWUxFPkBmb250 LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBQTWluZ0xpVTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiBQTWluZ0xpVTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBDYWxpYnJp Ow0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEBQTWluZ0xpVTsNCn0NCkBwYWdlIFdv cmRTZWN0aW9uMSB7c2l6ZTogNjEyLjBwdCA3OTIuMHB0OyBtYXJnaW46IDcwLjg1cHQgMy4wY20g NzAuODVwdCAzLjBjbTsgbXNvLWhlYWRlci1tYXJnaW46IDM2LjBwdDsgbXNvLWZvb3Rlci1tYXJn aW46IDM2LjBwdDsgbXNvLXBhcGVyLXNvdXJjZTogMDsgfQ0KUC5Nc29Ob3JtYWwgew0KCUxJTkUt SEVJR0hUOiAxMTUlOyBNQVJHSU46IDBjbSAwY20gMTBwdDsgRk9OVC1GQU1JTFk6ICJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7IEZPTlQtU0laRTogMTFwdDsgbXNvLXN0eWxlLXVuaGlkZTogbm87IG1z by1zdHlsZS1xZm9ybWF0OiB5ZXM7IG1zby1zdHlsZS1wYXJlbnQ6ICIiOyBtc28tcGFnaW5hdGlv bjogd2lkb3ctb3JwaGFuOyBtc28tYXNjaWktZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1hc2Np aS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFBNaW5n TGlVOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktZm9u dC1mYW1pbHk6IENhbGlicmk7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNv LWJpZGktZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tYmlkaS10aGVtZS1mb250 OiBtaW5vci1iaWRpOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtVFcNCn0NCkxJLk1zb05vcm1h bCB7DQoJTElORS1IRUlHSFQ6IDExNSU7IE1BUkdJTjogMGNtIDBjbSAxMHB0OyBGT05ULUZBTUlM WTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgRk9OVC1TSVpFOiAxMXB0OyBtc28tc3R5bGUtdW5o aWRlOiBubzsgbXNvLXN0eWxlLXFmb3JtYXQ6IHllczsgbXNvLXN0eWxlLXBhcmVudDogIiI7IG1z by1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IG1zby1hc2NpaS1mb250LWZhbWlseTogQ2FsaWJy aTsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC1mb250LWZh bWlseTogUE1pbmdMaVU7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1z by1oYW5zaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9y LWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogIlRpbWVzIE5ldyBSb21hbiI7IG1zby1iaWRp LXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1UVw0KfQ0K RElWLk1zb05vcm1hbCB7DQoJTElORS1IRUlHSFQ6IDExNSU7IE1BUkdJTjogMGNtIDBjbSAxMHB0 OyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgRk9OVC1TSVpFOiAxMXB0OyBt c28tc3R5bGUtdW5oaWRlOiBubzsgbXNvLXN0eWxlLXFmb3JtYXQ6IHllczsgbXNvLXN0eWxlLXBh cmVudDogIiI7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47IG1zby1hc2NpaS1mb250LWZh bWlseTogQ2FsaWJyaTsgbXNvLWFzY2lpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogUE1pbmdMaVU7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9y LWZhcmVhc3Q7IG1zby1oYW5zaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWhhbnNpLXRoZW1l LWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogIlRpbWVzIE5ldyBSb21h biI7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby1mYXJlYXN0LWxhbmd1YWdl OiBaSC1UVw0KfQ0KLk1zb0NocERlZmF1bHQgew0KCUZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOyBtc28tYXNjaWktZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1hc2NpaS10aGVt ZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFBNaW5nTGlVOyBt c28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28taGFuc2ktZm9udC1mYW1p bHk6IENhbGlicmk7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGkt Zm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5v ci1iaWRpOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtVFc7IG1zby1zdHlsZS10eXBlOiBleHBv cnQtb25seTsgbXNvLWRlZmF1bHQtcHJvcHM6IHllcw0KfQ0KLk1zb1BhcERlZmF1bHQgew0KCUxJ TkUtSEVJR0hUOiAxMTUlOyBNQVJHSU4tQk9UVE9NOiAxMHB0OyBtc28tc3R5bGUtdHlwZTogZXhw b3J0LW9ubHkNCn0NCkRJVi5Xb3JkU2VjdGlvbjEgew0KCXBhZ2U6IFdvcmRTZWN0aW9uMQ0KfQ0K PC9TVFlMRT4NCjwhLS1baWYgZ3RlIG1zbyAxMF0+DQo8c3R5bGU+DQogLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCiB0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGEg bm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFu ZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20g NS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luLXRvcDowY207DQoJbXNvLXBhcmEtbWFyZ2luLXJpZ2h0 OjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOjEwLjBwdDsNCgltc28tcGFyYS1tYXJnaW4t bGVmdDowY207DQoJbGluZS1oZWlnaHQ6MTE1JTsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBo YW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hc2NpaS10aGVtZS1m b250Om1pbm9yLWxhdGluOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1o YW5zaS10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLXRoZW1lLWZvbnQ6bWlub3ItYmlkaTsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1UVzt9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+W0Fuc3dlcjxCSUc+ XSA8L0JJRz5UaGUgZ29hbCBvZiBvdXIgcHJvcG9zYWwgaW4gb3VyIGxhc3QgbWFpbCB3YXMgDQog IG5vdCByZWxhdGVkIHdpdGggZmluZSBzeW5jaHJvbml6YXRpb24uIEZpbmUgU3luYyB0ZWNobmlx dWUgaXMgdXNlZCB0byBtYWludGFpbiANCiAgdGhlIHBsYXlvdXQgcHJvY2Vzc2VzIGJldHdlZW4g ZGlzdHJpYnV0ZWQgU0NzIGluIGEgc3luY2hyb25pemVkIG1hbm5lciBkdXJpbmcgDQogIHRoZSBl dm9sdXRpb24gb2YgdGhlIHNlc3Npb24gKG9yIGR1cmluZyBlYWNoIHN0YWdlcyBvZiB0aGUgc2Vz c2lvbiwgaWYgaXQgaXMgDQogIGRpdmlkZWQgaW50byBkaWZmZXJlbnQgcGhhc2VzKS4mbmJzcDsg RHVyaW5nIHRoZSBzZXNzaW9uIChvciBpdHMgcGhhc2VzKSwgU0NzIA0KICByZXBvcnQgb24gdGhl aXIgYXJyaXZhbC9wbGF5b3V0IHRpbWluZywgYW5kIHRoZSBNU0FTIGNhbiBzZW5kIHRvIHRoZW0g cGxheW91dCANCiAgc2V0dGluZyBpbnN0cnVjdGlvbnMgaW4gb3JkZXIgdG8gbWFpbnRhaW4gZmlu ZSBzeW5jLCB1c2luZyBSVENQIElETVMgcGFja2V0cyANCiAgKGRlZmluZWQgaW4gdGhlIEktRCks IGlmIGFuIG91dCBvZiBzeW5jIHNpdHVhdGlvbiBpcyBkZXRlY3RlZC48QlI+PEJSPlRoZSANCiAg Y29hcnNlIHN5bmMgdGVjaG5pcXVlIHdlIGhlcmUgcHJvcG9zZSB0byBiZSBpbmNsdWRlZCBpbiBv dXIgSS1EIHdvdWxkIG1haW5seSANCiAgYWltIHRvIHByZXZlbnQgZnJvbSBpbml0aWFsIHBsYXlv dXQgdGltZSBkaXNjcmVwYW5jaWVzIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIA0KICBwbGF5b3V0 IG9mIHRoZSBtZWRpYSBzdHJlYW0vcyBpbiBhIG11bHRpbWVkaWEgc2Vzc2lvbiAob3IgYXQgdGhl IGJlZ2lubmluZyBvZiANCiAgZWFjaCBvbmUgb2YgdGhlIHN0YWdlcyBpbiB3aGljaCBhIHNlc3Np b24gY2FuIGJlIGRpdmlkZWQpLCBkdWUgdG8gdGhlIGRlbGF5IA0KICB2YXJpYWJpbGl0eSBkdXJp bmcgdGhlIHNlc3Npb24gZnJvbSB0aGUgc2VuZGVyIHRvIGVhY2ggZ3JvdXAgb2Ygc2VwYXJhdGVk IFNDcyANCiAgKFN5bmMgQ2xpZW50cykuIDxCUj48QlI+SXQgY2FuIGJlIGFjaGlldmVkIGJ5IGRp c3RyaWJ1dGluZyB0byB0aGUgU0NzIGEgR2xvYmFsIA0KICBJbml0aWFsIFBsYXlvdXQgSW5zdGFu dCwgY2FycmllZCBvdXQgaW4gYSBSVENQIElETVMgcGFja2V0IHR5cGUgZm9yIElETVMgDQogIChh bHJlYWR5IGRlZmluZWQgaW4gb3VyIEktRCksIHByaW9yIHRoZSB0cmFuc21pc3Npb24gb2YgdGhl IGluaXRpYWwgUlRQIGRhdGEgDQogIHBhY2tldHMgb2YgZWFjaCBzdGFnZS4gVGhpcyB3YXksIHdl IGNhbiBlbnN1cmUgY29uY3VycmVudGx5IHNpbmNyb25pemVkIA0KICBwbGF5b3V0IHBvaW50cyBh dCB0aGUgc3RhcnRpbmcgcG9pbnQgb2YgZWFjaCBzdGFnZSwgZGVzcGl0ZSB0aGUgdmFyaWFibGUg DQogIG5ldHdvcmsgZGVsYXlzIGZyb20gdGhlIHNlbmRlciB0byB0aGUgU0NzPC9ESVY+DQogIDxE SVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+W1Fpbl06Jm5ic3A7U28geW91IHByb3Bvc2FsIGlzIHRv ICZuYnNwO2ZpeCB0aGUgYXN5bmNocm9uaXphdGlvbiBmcm9tIHRoZSANCiAgYmVnaW5uaW5nIG9m Jm5ic3A7c2Vzc2lvbiBiZWZvcmUgbWVkaWEgc3RyZWFtIGlzIHNlbnQgZnJvbSB0aGUgbWVkaWEg c291cmNlLiANCiAgSXNuJ3QmbmJzcDtpdCBhJm5ic3A7c2ltcGxlIHdheSB0byBtZWFzdXJlJm5i c3A7ZWFjaCBwcm9wYWdhdGlvbiB0aW1lIGZyb20gTVNBIA0KICB0byBlYWNoIFNDIGFuZCBjaG9v c2UgdGhlIGxhcmdlc3QgcHJvcHJhdGF0aW9uIHRpbWUgdG8gY2FsY3VhbHRlIHRoZSBJbml0aWFs IA0KICBQbGF5b3V0IEluc3RhbnQ/IElzIHRoaXMgd2hhdCB5b3Ugd2FudCB0byBzYXk/Jm5ic3A7 PEJSPjxCUj48L0RJVj4NCiAgPEJMT0NLUVVPVEUgY2l0ZT1taWQ6Q0RFQkQ1QTFFNjY0NDdDNjk5 NzMyREZCMzIzRDNCNDRAY2hpbmEuaHVhd2VpLmNvbSANCiAgdHlwZT0iY2l0ZSI+DQogICAgPEJM T0NLUVVPVEUgDQogICAgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMCwwLDApIDJweCBzb2xpZDsg UEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsg TUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgICAgPERJVj4NCiAgICAgIDxESVY+VGhpcyB0ZWNobmlx dWUgaGFzIGJlZW4gY29uc2lkZXJlZCBpbiBzb21lIHByZXZpb3VzIElETVMgd29ya3MgKHNlZSAN CiAgICAgIHJlZmVyZW5jZSBbQm9yb25hdDA5XSBpbiB0aGUgSS1EKSwgYnV0IHVzaW5nIHByb3By aWV0YXJ5IHByb3RvY29scy4gVGhlIA0KICAgICAgbWV0aG9kcyB3ZSBwcm9wb3NlIGhlcmUgYXJl IGJhc2VkIG9uIHRoZSB1c2Ugb2YgYWxyZWFkeSBkZWZpbmVkIGFuZCANCiAgICAgIHN0YW5kYXJk IFJUQ1AgcGFja2V0cywgd2hpY2ggd291bGQgYXZvaWQgdGhlIGludHJvZHVjdGlvbiBvZiBwcm9w cmlldGFyeSANCiAgICAgIGNsb3NlZCBzb2x1dGlvbnMuPEJSPjxCUj5SZWdhcmRpbmcgdGhlIElu aXRpYWwgUGxheW91dCBJbnN0YW50LCB3ZSBoYXZlIA0KICAgICAgcHJpbWFyaWx5IHRob3VnaHQg YWJvdXQgdGhlIHVzZSBvZiBhbHJlYWR5IHByb3Bvc2VkIFJUQ1AgWFIgcGFja2V0cyAoUkZDIA0K ICAgICAgMzYxMSk6PEJSPjxCUj4xLiBVc2Ugb2YgUlRDUCBYUiB3aXRoIFJSVFIgYW5kIERMUlIg cmVwb3J0IGJsb2NrcyAoZGVmaW5lZCANCiAgICAgIFJGQyAzNjExKSBmb3IgbWVhc3VyaW5nIHRo ZSBkZWxheSBiZXR3ZWVuIE1TQVMgYW5kIFNDcywgYWxsb3dpbmcgTVNBUyB0byANCiAgICAgIGVz dGltYXRlIHRoZSBSVFQgZm9yIGFsbCB0aGUgU0NzLCB0aGVuIGNhbGN1bGF0ZSBhIGNvbW1vbiBp bml0aWFsIHBsYXlvdXQgDQogICAgICBpbnN0YW50IGFuZCB0aGVuIGNvbW11bmljYXRlIGl0IHRv IGFsbCBTQ3MgYnkgc2VuZGluZyB0aGVtIGFuIFJUQ1AgSURNUyANCiAgICAgIFBhY2tldCAoZGVm aW5lZCBpbiB0aGUgSS1EKS4gVGhlIFJUQ1AgSURNUyBwYWNrZXQgbXVzdCBpbmNsdWRlIHRoZSBS VFAgDQogICAgICBUaW1lc3RhbXAgb2YgdGhlIGZpcnN0IE1VIHRvIGJlIHNlbnQgYnkgdGhlIHNv dXJjZSBhbmQgaXRzIHByb3BlciBwbGF5b3V0IA0KICAgICAgaW5zdGFudCwgd2hpY2ggd2lsbCBi ZSBjb21tb24gZm9yIGFsbCBvZiB0aGVtLjxCUj5NU0FTIG1heSBlc3RpbWF0ZSBpdHMgDQogICAg ICByb3VuZCB0cmlwIHRpbWUgKFJUVCkgdG8gdGhlIFNDcyBieSBzZW5kaW5nIHRoZW0gYW4gUlRD UCBYUiB3aXRoIHRoZSANCiAgICAgIFJlY2VpdmVyIFJlZmVyZW5jZSBUaW1lIFJlcG9ydCBCbG9j ayBhbmQgZm9yY2luZyAoYWNjb3JkaW5nIHRvIFJGQyAzNjExKSANCiAgICAgIHRoZW0gdG8gcmVw bHkgYnkgc2VuZGluZyBhbiBSVENQIFhSIHdpdGggYSBETFJSIFJlcG9ydCBCbG9jay4gTm90aWNl IHRoYXQgDQogICAgICBib3RoIFhSIGJsb2NrcyBhcmUgZGVmaW5lZCBpbiBSRkMgMzYxMSB0byBi ZSB1c2VkIGluIHRoZSBvcHBvc2l0ZSB3YXkgd2UgDQogICAgICBwcm9wb3NlLjwvRElWPg0KICAg ICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+W1Fpbl06IFdoeSBub3QgdXNlIHJvdW5k IHRyaXAgdGltZSBjb21wdXRhdGlvbiBtZXRob2QgZGVmaW5lZCBpbiB0aGUgDQogICAgICBmaWd1 cmUgMiBvZiBSRkMzNTUwLCBhcmUgeW91IHNheWluZyBpdCBpcyBub3QgYWxsb3dlZCB0byB1c2Ug U1IvUlIgcmVwb3J0cyANCiAgICAgIGluIElETVMgY2FzZS48QlI+PC9ESVY+PC9ESVY+PC9CTE9D S1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgPERJVj5bQW5zd2VyPEJJRz5dIDwvQklHPlRvIHRoZSBi ZXN0IG9mIG91ciBrbm93bGVkZ2UsIHByaW9yIHRoZSB0cmFuc21pc3Npb24gDQogIG9mIFJUUCBk YXRhIHBhY2tldHMsIG5laXRoZXIgUlRDUCBTUiBub3IgUlIgYXJlIHNlbnQsIGFyZW4ndCB0aGV5 Py4gU28sIHRoZSANCiAgZGVsYXkgZnJvbSB0aGUgc2VuZGVyIHRvIHRoZSBTQ3MgY291bGQgbm90 IGJlIGNhbGN1bGF0ZWQgdXNpbmcgdGhvc2UgcGFja2V0cyANCiAgYXQgbGVhc3QgYXQgdGhlIHN0 YXJ0aW5nIHBvaW50IG9mIHRoZSBzZXNzaW9uIChtYXliZSBhdCB0aGUgaW5pdGlhbCBwb2ludHMg b2YgDQogIGVhY2ggc3RhZ2UsIGJ1dCB3ZSBhcmUgbm90IHN1cmUpLiBJZiwgYXQgdGhlIGJlZ2lu bmluZyBvZiBlYWNoIHN0YWdlLCB0aGUgDQogIHNlc3Npb24gaGFzIGJlZW4gc3RvcHBlZCBkdXJp bmcgYSBsb25nIHBlcmlvZCBhbmQsIHRoZXJlZm9yZSwgdGhlIG5ldHdvcmsgDQogIGNvbmRpdGlv bnMgKGUuZy4sIGRlbGF5cyB0byBlYWNoIFNDcykgaGF2ZSBzaWduaWZpY2FudGx5IHZhcmllZCB3 ZSB3aWxsIG5lZWQgDQogIHRvIG1vbml0b3IgdGhlbS48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJ Vj4NCiAgPERJVj5bUWluXTogSSBhZ3JlZSB1c3VhbGx5IFNSL1JSIGFyZSBzZW50IGFmdGVyIHRo ZSB0cmFuc21pc3Npb25vZiBSVFAgZGF0YSANCiAgcGFja2V0cy4gQnV0IGluIG15IHVuZGVyc3Rh bmRpbmcsIGl0IGlzIG5vdCBwcm9ibGVtIHRvIHNlbmQgU1IvUlIgcHJpb3IgdGhlIA0KICB0cmFu c21pc3Npb24gb2YgUlRQIGRhdGEgcGFja2V0cyBzaW5jZSB0aGUgaXJyZWxhdmFudCBmaWVsZHMg aW4gdGhlIFNSL1JSIGNhbiANCiAgYmUgc2V0IHRvIHplcm8gd2hlbiB0aGVyZSBpcyBubyBtZWRp YSBzdHJlYW0gZXhjaGFuZ2VkLjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0 MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8QkxPQ0tRVU9URSBjaXRlPW1pZDpD REVCRDVBMUU2NjQ0N0M2OTk3MzJERkIzMjNEM0I0NEBjaGluYS5odWF3ZWkuY29tIA0KICB0eXBl PSJjaXRlIj4NCiAgICA8QkxPQ0tRVU9URSANCiAgICBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigw LDAsMCkgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBN QVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICA8RElWPg0KICAgICAg PERJVj48QlI+SWYgdGhpcyBzb2x1dGlvbiBpcyBub3QgY29uc2lkZXJlZCBhcHByb3ByaWF0ZSB3 ZSBjb3VsZCB0aGluayANCiAgICAgIGFib3V0IGFub3RoZXIgc29sdXRpb24gYmFzZWQgb24gdGhl IHBhY2tldHMgYWxyZWFkeSBkZWZpbmVkIGluIHRoZSBJLUQsIA0KICAgICAgYnV0IG1heWJlIHdl IHdvdWxkIG5lZWQgdG8gY2hhbmdlIHRoZSBmb3JtYXQgYWRkaW5nIG5ldyBmaWVsZC9zLjxCUj48 QlI+Mi4gDQogICAgICBPbmNlIGpvaW5lZCB0aGUgc2Vzc2lvbiwgaWYgaXQgaXMgbm90IHN0YXJ0 ZWQgeWV0LCBhbGwgdGhlIFNDcyBjb3VsZCBzdGFydCANCiAgICAgIHNlbmRpbmcgUlRDUCBYUiB3 aXRoIElETVMgYmxvY2sgKHVudGlsIHRoZXkgcmVjZWl2ZSB0aGUgSW5pdGlhbCBQbGF5b3V0IA0K ICAgICAgSW5zdGFudCBpbmRpY2F0aW9uLCBzZW50IHVzaW5nIHRoZSBSVENQIElETVMgUGFja2V0 KSBhcyBpdCBpcyBkZWZpbmVkIGluIA0KICAgICAgdGhlIEktRCwgYnV0IGluY2x1ZGluZyBvbmx5 IHRoZSBlc3NlbnRpYWwgdGltaW5nIGluZm9ybWF0aW9uIChlLmcuIHRoZSANCiAgICAgIHdhbGxj bG9jayB0aW1lIGF0IHdoaWNoIHRoZSBwYWNrZXQgaXMgc2VudCBieSB0aGUgU0MpIHRvIGxldCB0 aGUgTVNBUyANCiAgICAgIGVzdGltYXRlIHRoZSBvbmUtd2F5IG5ldHdvcmsgZGVsYXlzIChub3Qg cm91bmQtdHJpcCBhcyBpbiB0aGUgcHJldmlvdXMgDQogICAgICBjYXNlKSBmb3IgZWFjaCBTQyAo YXNzdW1pbmcgc3ltbWV0cmljIGRlbGF5cyBhcyBpbiBUQ1ApIGFuZCBjYWxjdWxhdGUgdGhlIA0K ICAgICAgSW5pdGlhbCBQbGF5b3V0IEluc3RhbnQuIEZvciB0aGF0IHB1cnBvc2UsIHNvbWUgZmll bGQgb2YgdGhlIFJUQ1AgWFIgSURNUyANCiAgICAgIGJsb2NrIHNob3VsZCBiZSB1c2VkIHRvIGlu ZGljYXRlIHRoZSBYUiBJRE1TIGJsb2NrIGlzIGNhcnJ5aW5nIG91dCANCiAgICAgIHRlbXBvcmFs IGluZm9ybWF0aW9uIGZvciBDb2Fyc2UgU3luYywgYW5kIG5vdCBmb3IgcmVwb3J0aW5nIGFib3V0 IA0KICAgICAgYXJyaXZhbC9wbGF5b3V0IHRpbWluZyBvZiBhIHNwZWNpZmljIFJUUCBwYWNrZXQu PEJSPkZyb20gdGhlIEluaXRpYWwgDQogICAgICBJbnN0YW50IHRoZXkgd2lsbCBjb250aW51ZSBw bGF5aW5nIHRoZSBzdHJlYW1zIGFuZCBzZW5kaW5nIHRoZSBSVENQIFhSIA0KICAgICAgd2l0aCBJ RE1TIGNvbXBsZXRlIGJsb2NrIChhcyBjdXJyZW50bHkgZGVmaW5lZCBpbiB0aGUgSS1EKS4gSXQg Y291bGQgYmUgYSANCiAgICAgIHBvc3NpYmxlIHNvbHV0aW9uLjwvRElWPg0KICAgICAgPERJVj4m bmJzcDs8L0RJVj4NCiAgICAgIDxESVY+W1Fpbl06IFlvdSBjYW4gdXNlIERlbGF5IG1ldHJpYyBy ZXBvcnQgZGVmaW5lZCBpbiANCiAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0Y3AteHItZGVsYXktMDIg dG8gZGlyZWN0bHkmbmJzcDtnZXQgb25lLXdheSBuZXR3b3JrIA0KICAgICAgZGVsYXlzLiBBbHNv IG1heGltdW0gYW5kIG1pbmltdW0gbmV0d29yayBkZWxheXMgY2FuIGJlIG9idGFpbmVkIGZyb20g dGhpcyANCiAgICAgIFhSIHJlcG9ydC48QlI+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxP Q0tRVU9URT4NCiAgPERJVj5UaGFuayB5b3UgZm9yIHRoZSBzdWdnZXN0aW9uLiA8QlI+PEJSPklu IG91ciByZXNwb25zZSB0byBLZXZpbiBHcm9zcyB3ZSANCiAgcHJvcG9zZSBhbiBhbHRlcm5hdGl2 ZSB0byBjYWxjdWxhdGUgb25lLXdheSBkZWxheXMgZnJvbSBzb3VyY2UgdG8gU0NzIHVzaW5nIA0K ICBvbmx5IHRoZSBwYWNrZXRzIGRlZmluZWQgaW4gdGhlIEktRC4gUGxlYXNlLCB0ZWxsIHVzIHlv dXIgb3BpbmlvbiBhYm91dCANCiAgaXQuPC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQogIDxE SVY+W1Fpbl06IE15Jm5ic3A7cG9pbnQgaXMgb25lIHdheSBkZWxheXMgZnJvbSBzb3VyY2UgdG8g U0MgbWF5IGJlIG5vdCAxLzIgDQogIG9mIG5ldHdvcmsgcm91bmQgdHJpcCBkZWxheSBzaW5jZTo8 L0RJVj4NCiAgPERJVj5OZXR3b3JrIHJvdW5kIHRyaXAgZGVsYXkgPSBvbmUgd2F5IGRlbGF5IGZy b20gc291cmNlIHRvIFNDICsgb25lIHdheSANCiAgZGVsYXkgZnJvbSBTQyB0byB0aGUgU291cmNl LCA8L0RJVj4NCiAgPERJVj5PbmUgd2F5IGRlbGF5IGZyb20gc291cmNlIHRvIFNDIG1heSBub3Qg ZXF1YWwgdG8gb25lIHdheSBkZWxheSBmcm9tIFNDIHRvIA0KICB0aGUgU291cmNlLjwvRElWPg0K ICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPlRoZXJlZm9yZSwgZXZlbiB5b3UgcmVseSBvbiBS VENQIFhSIHdpdGggUlJUUiBhbmQgRExSUiwgeW91IHN0aWxsIGdldCANCiAgcm91bmQgdHJpcCB0 aW1lIGJldHdlZW4gc291cmNlIGFuZCBTQyByYXRoZXIgdGhhbiBvbmUgd2F5IGRlbGF5LjwvRElW Pg0KICA8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPjxCUj5X ZSB0aG91Z2h0IGFib3V0IHRoZSB1c2Ugb2YgUlRDUCBYUiBSUlRSIA0KICBhbmQgRExSUiAoYWxy ZWFkeSBkZWZpbmVkIGluIGFuIFJGQyAzNjExIGFuZCBub3QgYWJvdXQgcGFja2V0cyBkZWZpbmVk IGluIGEgDQogIL9vbGQvZXhwaXJlZD8gZHJhZnQgLTIwMDktKSBiZWNhdXNlIHRoZXNlIFhSIGJs b2NrcyBhcmUgYWxyZWFkeSBzdGFuZGFyZGl6ZWQgDQogIGFuZCBjb3VsZCBiZSB1c2VmdWwgZm9y IG91ciBDb2Fyc2UgU3luYyBwdXJwb3Nlcy4gTW9yZW92ZXIsIGluIHN1Y2ggYSB3YXksIFNDcyAN CiAgbXVzdCBvbmx5IHNlbmQgUlRDUCBYUiB3aXRoIERMUlIgYmxvY2tzIGFzIGEgcmVzcG9uc2Ug dG8gYW4gaW5jb21pbmcgUlRDUCBYUiANCiAgd2l0aCBSUlRSIGJsb2NrLCBzZW50IGJ5IHRoZSBz b3VyY2UsIHdoaWNoIGlzIHdobyByZWFsbHkga25vd3MgdGhlIGluaXRpYWwgDQogIHRyYW5zbWlz c2lvbiBpbnN0YW50ICh0aHVzLCB1bm5lY2Vzc2FyeSBSVENQIHBhY2tldCB3b3VsZCBub3QgYmUg DQogIHNlbnQpLjxCUj5UaGVuLCB0aGUgSW5pdGlhbCBQbGF5b3V0IEluc3RhbnQgd291bGQgYmUg Y2FsY3VsYXRlZCBieSB0YWtpbmcgaW50byANCiAgY29uc2lkZXJhdGlvbiB0aGUgZXN0aW1hdGVk IG5ldHdvcmsgZGVsYXlzLCBpbiBvcmRlciB0byBhbGxvdyBhbGwgdGhlIFNDcyB0byANCiAgaGF2 ZSBidWZmZXJlZCBzdWZmaWNpZW50IFJUUCBkYXRhIHBhY2tldHMgdG8gc21vb3RoIG91dCB0aGUg ZWZmZWN0IG9mIG5ldHdvcmsgDQogIGppdHRlciwgcG9zc2libGUgcGxheW91dCByYXRlIGRldmlh dGlvbnMgb3Igc3BvcmFkaWMgY29uZ2VzdGlvbiBjYXNlcywgdGh1cyANCiAgbWFpbnRhaW5pbmcg YSBjb250aW51b3VzIHBsYXlvdXQgcHJvY2VzcyBkdXJpbmcgdGhlIHNlc3Npb24uPEJSPjxCUj5E byB5b3UgDQogIHRoaW5rIHRoYXQgdGhlIHVzZSBvZiB0aGUgcGFja2V0cyBkZWZpbmVkIGluIHRo ZSC/b2xkL2V4cGlyZWQ/IGRyYWZ0IHNob3VsZCBiZSANCiAgdXNlZCB0byB0aGlzIHB1cnBvc2U/ IEluIHRoYXQgY2FzZSB3ZSB3b3VsZCBuZWVkIHRvIG1vZGlmeSB0aGVpciBmb3JtYXQgdG8gDQog IG1ha2UgdGhlbSBtb3JlIGFwcHJvcHJpYXRlIGZvciBvdXIgbmVlZHMuPC9ESVY+PEZPTlQgc2l6 ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+DQogIDxESVY+PEJSPltRaW5dOiBBcyBJ IHNhaWQgYWJvdmUsIG9uZSB3YXkgZGVsYXkgZnJvbSBzb3VyY2UgdG8gU0MgbWF5IGJlIG5vdCAN CiAgMS8yIHJvdW5kIHRyaXAgdGltZSBiZXR3ZWVuIHNvdXJjZSBhbmQgU0MuIElmIHlvdSB3YW50 IHRvIG1lYXN1cmUgb25lIHdheSANCiAgZGVsYXkgZnJvbSBzb3VyY2UgdG8gU0MgbW9yZSBwcmVj aXNlbHksIHlvdSBuZWVkJm5ic3A7YSBuZXcgbWVhc3VyZW1lbnQgbWV0aG9kIA0KICBmb3Igb25l IHdheSBkZWxheSBmcm9tIHNvdXJjZSB0byB0aGUgU0MuPC9ESVY+DQogIDxESVY+WWVzLCBkcmFm dC1pZXRmLWF2dC1ydGNwLXhyLWRlbGF5LTAyIGhhcyBiZWVuIHJldml2ZWQgaW50byANCiAgZHJh ZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItZGVsYXktMDAuIEl0IGlzIG5vdCBhIHByb2JsZW0geW91 IHVzZSBkZWxheSBtZXRyaWMgDQogIGluIHRoZSBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1k ZWxheS0wMCBieSBleHRlbmRpbmcgaXQgZm9yIHlvdXIgcHVycG9zZS4gDQogIEFsc28geW91IGNh biB3cml0ZSBhIG5ldyBkcmFmdCB0byBkZWZpbmUgYSBuZXcgbWV0cmljIGZvciB5b3VyIA0KICBw dXJwb3NlLiZuYnNwO1N1Y2ggZHJhZnQgc2hvdWxkIGJlIHN1bWl0dGVkIHRvIFhSQmxvY2sgV0cu PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkOkNERUJENUExRTY2NDQ3QzY5OTcz MkRGQjMyM0QzQjQ0QGNoaW5hLmh1YXdlaS5jb20gDQogIHR5cGU9ImNpdGUiPg0KICAgIDxCTE9D S1FVT1RFIA0KICAgIHN0eWxlPSJCT1JERVItTEVGVDogcmdiKDAsMCwwKSAycHggc29saWQ7IFBB RERJTkctTEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1B UkdJTi1SSUdIVDogMHB4Ij4NCiAgICAgIDxESVY+DQogICAgICA8RElWPjxGT05UIHNpemU9MiBm YWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj5bUWlu XSBJIHRoaW5rIHlvdSBjYW4gcmVseSBvbiBkcmFmdC1pZXRmLWF2dC1ydGNwLXhyLW1lYXMtaWRl bnRpdHkgdG8gDQogICAgICBrbm93IGV4cGVjdGVkIGR1cmF0aW9uIG9mIHRoZSBzZXNzaW9uLjwv RElWPg0KICAgICAgPERJVj55b3UgbWF5IHJlbHkgb24gZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3At eHItcGR2LTAwIHRvIGdldCBqaXR0ZXIgDQogICAgICB2YWx1ZXMuPC9ESVY+DQogICAgICA8RElW PkJ1dCBYUkJMb2NrIGlzIG5vdCB0aGUgcmlnaHQgcGxhY2UgdG8mbmJzcDtzZWVrIGZvciZuYnNw O3RoZSANCiAgICAgIG1lYXN1cmVtZW50IG1ldGhvZCwgd2hpY2ggaXMgZGVmaW5lZCBzb21ld2hl cmUgZWxzZSwgZS5nLiwgaW4gb3RoZXIgUkZDIA0KICAgICAgbGlrZSBSRkMzNTUwLCBvdGhlciBX R3MsIG9yIG90aGVyIA0KICBTRE9zLjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVP VEU+W0Fuc3dlcl0gVGhhbmsgeW91IGZvciB5b3VyIGhlbHBmdWwgDQogIHN1Z2dlc3Rpb24uIElu IHRoZSBJLUQgd2Ugb25seSB3YW50IHRvIHByb3Bvc2UgdGhlIHBhY2tldHMgdG8gYmUgdXNlZCBm b3Igb3VyIA0KICBwdXJwb3NlLiBUaGUgY2FsY3VsYXRpb24gbWV0aG9kcywgYXMgd2UgbWVudGlv bmVkIGFib3ZlLCBhcmUgb3V0IG9mIHRoZSBzY29wZSANCiAgb2YgdGhlIElELiA8QlI+PEJSPlRo YW5rIFlvdSBhZ2FpbiBmb3IgeW91ciBjb21tZW50czxCUj48QlI+TW9yZSBmZWVkYmFjayANCiAg YWJvdXQgaXQgZnJvbSB0aGUgQVZUQ29yZSBncm91cCBtZW1iZXJzIHdpbGwgYmUgbXVjaCBhcHBy ZWNpYXRlZC48QlI+DQogIDxNRVRBIG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVudD4N CiAgPE1FVEEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQiPg0KICA8 TUVUQSBuYW1lPU9yaWdpbmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQiPjxMSU5LIHJl bD1GaWxlLUxpc3QgDQogIGhyZWY9ImZpbGU6Ly8vQzolNUNVc2VycyU1Q2Zib3JvbmF0JTVDQXBw RGF0YSU1Q0xvY2FsJTVDVGVtcCU1Q21zb2h0bWxjbGlwMSU1QzAxJTVDY2xpcF9maWxlbGlzdC54 bWwiPjxMSU5LIA0KICByZWw9dGhlbWVEYXRhIA0KICBocmVmPSJmaWxlOi8vL0M6JTVDVXNlcnMl NUNmYm9yb25hdCU1Q0FwcERhdGElNUNMb2NhbCU1Q1RlbXAlNUNtc29odG1sY2xpcDElNUMwMSU1 Q2NsaXBfdGhlbWVkYXRhLnRobXgiPjxMSU5LIA0KICByZWw9Y29sb3JTY2hlbWVNYXBwaW5nIA0K ICBocmVmPSJmaWxlOi8vL0M6JTVDVXNlcnMlNUNmYm9yb25hdCU1Q0FwcERhdGElNUNMb2NhbCU1 Q1RlbXAlNUNtc29odG1sY2xpcDElNUMwMSU1Q2NsaXBfY29sb3JzY2hlbWVtYXBwaW5nLnhtbCI+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpWaWV3Pk5v cm1hbDwvdzpWaWV3Pg0KICA8dzpab29tPjA8L3c6Wm9vbT4NCiAgPHc6VHJhY2tNb3Zlcy8+DQog IDx3OlRyYWNrRm9ybWF0dGluZy8+DQogIDx3Okh5cGhlbmF0aW9uWm9uZT4yMTwvdzpIeXBoZW5h dGlvblpvbmU+DQogIDx3OlB1bmN0dWF0aW9uS2VybmluZy8+DQogIDx3OlZhbGlkYXRlQWdhaW5z dFNjaGVtYXMvPg0KICA8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93OlNhdmVJZlhNTEludmFs aWQ+DQogIDx3Oklnbm9yZU1peGVkQ29udGVudD5mYWxzZTwvdzpJZ25vcmVNaXhlZENvbnRlbnQ+ DQogIDx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNl aG9sZGVyVGV4dD4NCiAgPHc6RG9Ob3RQcm9tb3RlUUYvPg0KICA8dzpMaWRUaGVtZU90aGVyPk5M PC93OkxpZFRoZW1lT3RoZXI+DQogIDx3OkxpZFRoZW1lQXNpYW4+WkgtVFc8L3c6TGlkVGhlbWVB c2lhbj4NCiAgPHc6TGlkVGhlbWVDb21wbGV4U2NyaXB0PlgtTk9ORTwvdzpMaWRUaGVtZUNvbXBs ZXhTY3JpcHQ+DQogIDx3OkNvbXBhdGliaWxpdHk+DQogICA8dzpCcmVha1dyYXBwZWRUYWJsZXMv Pg0KICAgPHc6U25hcFRvR3JpZEluQ2VsbC8+DQogICA8dzpXcmFwVGV4dFdpdGhQdW5jdC8+DQog ICA8dzpVc2VBc2lhbkJyZWFrUnVsZXMvPg0KICAgPHc6RG9udEdyb3dBdXRvZml0Lz4NCiAgIDx3 OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCiAgIDx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+ DQogICA8dzpEb250RmxpcE1pcnJvckluZGVudHMvPg0KICAgPHc6T3ZlcnJpZGVUYWJsZVN0eWxl SHBzLz4NCiAgIDx3OlVzZUZFTGF5b3V0Lz4NCiAgPC93OkNvbXBhdGliaWxpdHk+DQogIDxtOm1h dGhQcj4NCiAgIDxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCiAgIDxtOmJya0Jp biBtOnZhbD0iYmVmb3JlIi8+DQogICA8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KICAg PG06c21hbGxGcmFjIG06dmFsPSJvZmYiLz4NCiAgIDxtOmRpc3BEZWYvPg0KICAgPG06bE1hcmdp biBtOnZhbD0iMCIvPg0KICAgPG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KICAgPG06ZGVmSmMgbTp2 YWw9ImNlbnRlckdyb3VwIi8+DQogICA8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQogICA8 bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0KICAgPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+ DQogIDwvbTptYXRoUHI+PC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KIDx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFs c2UiIERlZlVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICBEZWZTZW1pSGlkZGVuPSJ0cnVlIiBEZWZR Rm9ybWF0PSJmYWxzZSIgRGVmUHJpb3JpdHk9Ijk5Ig0KICBMYXRlbnRTdHlsZUNvdW50PSIyNjci Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJOb3JtYWwiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5 IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iaGVhZGluZyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iaGVhZGluZyA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAxIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAyIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRv YyAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5h bWU9InRvYyA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIE5hbWU9InRvYyA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzkiIE5hbWU9InRvYyA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA5Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImNh cHRpb24iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IlRpdGxlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjExIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0 cm9uZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBT ZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iRW1waGFzaXMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IlRhYmxlIEdyaWQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5n Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFk aW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBM aXN0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBH cmlkIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g U2hhZGluZyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjQiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gTGlzdCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNj ZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0 IEdyaWQgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iUmV2aXNpb24iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IFFGb3JtYXQ9InRydWUiIE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJRdW90ZSIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5z ZSBRdW90ZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2 IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIExpc3QgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlk ZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFj Y2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEi IFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xv cmZ1bCBTaGFkaW5nIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAy Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0 IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJM aWdodCBHcmlkIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAyIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2Vu dCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAyIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAyIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49 ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50 IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2Vt aUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVs IFNoYWRpbmcgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDMiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNj ZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0 IEdyaWQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0 IDIgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDMiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMyIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlk ZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hh ZGluZyBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNCIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQg NCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3Jp ZCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNCIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBB Y2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3 IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMSBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49 ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5n IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA1Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFj Y2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMi IFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gU2hhZGluZyAxIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA1Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2Vu dCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g R3JpZCAxIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNj ZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9y ZnVsIExpc3QgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50 IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2Vt aUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDEgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDYiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlk IDEgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNiIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQg NiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwg TGlzdCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjE5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lzIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNl IEVtcGhhc2lzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i Qm9vayBUaXRsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM3IiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCiA8 L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+DQogIDxTVFlMRT4NCjwhLS0NCiAv KiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpQTWluZ0xp VTsNCglwYW5vc2UtMToyIDIgNSAwIDAgMCAwIDAgMCAwOw0KCW1zby1mb250LWFsdDomIzI2MDMy OyYjMzIwNDg7JiMyNjEyNjsmIzM5NjM2OzsNCgltc28tZm9udC1jaGFyc2V0OjEzNjsNCgltc28t Z2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCglt c28tZm9udC1zaWduYXR1cmU6LTE2MTA2MTE5NjkgNjg0NzE5MzU0IDIyIDAgMTA0ODU3NyAwO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6UE1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDUgMCAw IDAgMCAwIDAgMDsNCgltc28tZm9udC1hbHQ6JiMyNjAzMjsmIzMyMDQ4OyYjMjYxMjY7JiMzOTYz Njs7DQoJbXNvLWZvbnQtY2hhcnNldDoxMzY7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9t YW47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0xNjEw NjExOTY5IDY4NDcxOTM1NCAyMiAwIDEwNDg1NzcgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQt Y2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBp dGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTIwMDkyOTI5IDEwNzM3ODYxMTEg OSAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAUE1pbmdMaVUiOw0KCXBh bm9zZS0xOjIgMiA1IDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtY2hhcnNldDoxMzY7DQoJbXNv LWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJ bXNvLWZvbnQtc2lnbmF0dXJlOi0xNjEwNjExOTY5IDY4NDcxOTM1NCAyMiAwIDEwNDg1NzcgMDt9 DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6 eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjEwLjBwdDsNCgltYXJnaW4tbGVmdDowY207DQoJbGlu ZS1oZWlnaHQ6MTE1JTsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2Np aS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hc2NpaS10aGVtZS1mb250Om1pbm9yLWxhdGlu Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OlBNaW5nTGlVOw0KCW1zby1mYXJlYXN0LXRoZW1l LWZvbnQ6bWlub3ItZmFyZWFzdDsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglt c28taGFuc2ktdGhlbWUtZm9udDptaW5vci1sYXRpbjsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS10aGVtZS1mb250Om1pbm9yLWJpZGk7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtVFc7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ bXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6UE1pbmdMaVU7DQoJbXNvLWZhcmVhc3QtdGhlbWUtZm9udDptaW5vci1mYXJlYXN0Ow0KCW1z by1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS10aGVtZS1mb250Om1pbm9y LWxhdGluOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1i aWRpLXRoZW1lLWZvbnQ6bWlub3ItYmlkaTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1UVzt9 DQouTXNvUGFwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4t Ym90dG9tOjEwLjBwdDsNCglsaW5lLWhlaWdodDoxMTUlO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAzLjBjbSA3MC44NXB0IDMu MGNtOw0KCW1zby1oZWFkZXItbWFyZ2luOjM2LjBwdDsNCgltc28tZm9vdGVyLW1hcmdpbjozNi4w cHQ7DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KPCEtLVtpZiBndGUgbXNvIDEwXT4NCjxzdHlsZT4N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1z dHlsZS1uYW1lOiJUYWJsYSBub3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJ bXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1h bHQ6MGNtIDUuNHB0IDBjbSA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW4tdG9wOjBjbTsNCgltc28t cGFyYS1tYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206MTAuMHB0Ow0K CW1zby1wYXJhLW1hcmdpbi1sZWZ0OjBjbTsNCglsaW5lLWhlaWdodDoxMTUlOw0KCW1zby1wYWdp bmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ bXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWhhbnNpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktdGhlbWUtZm9udDptaW5v ci1iaWRpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILVRXO30NCjwvc3R5bGU+DQo8IVtlbmRp Zl0tLT48QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkOkNERUJENUExRTY2NDQ3QzY5OTczMkRG QjMyM0QzQjQ0QGNoaW5hLmh1YXdlaS5jb20gDQogIHR5cGU9ImNpdGUiPg0KICAgIDxCTE9DS1FV T1RFIA0KICAgIHN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJTkct TEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1S SUdIVDogMHB4Ij4NCiAgICAgIDxESVY+DQogICAgICA8RElWPjxCUj5XaXRoIHRoZSBpbnRyb2R1 Y3Rpb24gb2YgdGhlIENvYXJzZSBTeW5jIGZ1bmN0aW9uYWxpdHksIHRoZSBJRE1TIA0KICAgICAg cHJvcG9zYWwgY2FuIGNvdW50ZXJhY3QgdGhlIGVmZmVjdCBvZiB0aGUgZGVsYXkgdmFyaWFiaWxp dHkgYXQgdGhlIA0KICAgICAgYmVnaW5uaW5nIG9mIHRoZSBwbGF5b3V0IG9mIHRoZSBtZWRpYSBz dHJlYW0vcyBpbiBlYWNoIG9uZSBvZiB0aGUgc3RhZ2VzIA0KICAgICAgaW4gd2hpY2ggYSBtZWRp YSBzZXNzaW9uIGNhbiBiZSBkaXZpZGVkLjxCUj48QlI+V2UgcHJlZmVyIHRoZSBmaXJzdCBtZXRo b2QgDQogICAgICBiZWNhdXNlIHRoZXJlIGlzIG5vIG5lZWQgdG8gZGVmaW5lIG5ldyBJRE1TIGNv bnRyb2wgbWVzc2FnZXMgKG9yIHRvIA0KICAgICAgaW5jbHVkZSBzb21lIGZpZWxkcyB0byBhbHJl YWR5IGRlZmluZWQgcGFja2V0cyksIGJ1dCB0aGUgdXNlIG9mIGFscmVhZHkgDQogICAgICBkZWZp bmVkIFJUQ1AgcmVwb3J0cyAoUkZDIDM2MTEpIGNhbiBiZSBhZGFwdGVkIGZvciB0aGF0IHB1cnBv c2UuIA0KICAgICAgPEJSPjxCUj5Nb3Jlb3Zlciwgd2l0aCB0aGUgdXNlIG9mIHRoZSBmaXJzdCBt ZXRob2QsIFNDcyBkbyBub3QgaGF2ZSB0byANCiAgICAgIHNlbmQgY29udHJvbCBtZXNzYWdlcyBv bmNlIHRoZXkgam9pbiB0aGUgc2Vzc2lvbiwgd2hpY2ggbWF5IHBvc3NpYmx5IA0KICAgICAgcmVz dWx0IG9uIGluZWZmaWNpZW50IGNvbnRyb2wgdHJhZmZpYyBvdmVyaGVhZC4gVGhleSB3aWxsIG9u bHkgaGF2ZSB0byANCiAgICAgIHNlbmQgUlRDUCBYUiBETFJSIG1lc3NhZ2VzIGluIHJlc3BvbnNl IHRvIGEgbmV3IGluY29taW5nIFJUUlIgbWVzc2FnZSBmcm9tIA0KICAgICAgdGhlIHNvdXJjZSwg d2hpY2ggaXMgd2hvIHJlYWxseSBrbm93cyB0aGUgaW5pdGlhbCB0cmFuc21pc3Npb24gdGltZSBm b3IgDQogICAgICB0aGUgUlRQIG1lZGlhIHN0cmVhbS4gTW9yZW92ZXIsIHRoZSBJbml0aWFsIFBs YXlvdXQgSW5zdGFudCBjYW4gYmUgc2VudCB0byANCiAgICAgIHRoZSByZWNlaXZlcnMgYnkgdXNp bmcgdGhlIFJUQ1AgSURNUyBwYWNrZXQsIGFscmVhZHkgaW50cm9kdWNlZCBpbiB0aGUgDQogICAg ICBJLUQuPEJSPjxCUj5GZWVkYmFjayB3aWxsIGJlIG11Y2ggYXBwcmVjaWF0ZWQuPEJSPjwvRElW PjwvRElWPjxQUkUgY2xhc3M9bW96LXNpZ25hdHVyZSBjb2xzPSI3MiI+UmVnYXJkcw0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQpEci4gRmVybmFuZG8gQm9yb25hdCBTZWd17Q0KSUVFRSBTZW5pb3IgTWVtYmVy DQpQcm9mZXNvciBUaXR1bGFyIC8gTGVjdHVyZXIJDQpEZXB0LiBDb211bmljYWNpb25lcyAgICAg ICAgICAgVGxmLi0rMzQrOTYyIDg0OSAzMDAgRXh0Li00OTM0MQ0KVGxmLiBkaXJlY3RvIC0rMzQr OTYyIDg0OSAzNDEgIEZheC4tKzM0Kzk2MiA4NDkgMzA5IChDb21wYXJ0aWRvKQ0KVU5JVkVSU0lE QUQgUE9MSVTJQ05JQ0EgREUgVkFMRU5DSUEtQ0FNUFVTIERFIEdBTkRJQQ0KQ2FsbGUgUGFyYXJh bmluZm8sIDEsIENQLiA0NjczMCwgR3JhbyBkZSBHYW5kaWEgKFZhbGVuY2lhKSwgU1BBSU4NCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PTwvUFJFPg0KICAgICAgPFA+PC9QPg0KICAgICAgPEhSPg0KICAgICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+QXVkaW8vVmlk ZW8gVHJhbnNwb3J0IA0KICAgICAgQ29yZSBNYWludGVuYW5jZTxCUj48QSBjbGFzcz1tb3otdHh0 LWxpbmstYWJicmV2aWF0ZWQgDQogICAgICBocmVmPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRA aWV0Zi5vcmc8L0E+PEJSPjxBIA0KICAgICAgY2xhc3M9bW96LXR4dC1saW5rLWZyZWV0ZXh0IA0K ICAgICAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0PC9BPjxCUj48L0JMT0NLUVVP VEU+PC9CTE9DS1FVT1RFPjxCUj48UFJFIGNsYXNzPW1vei1zaWduYXR1cmUgY29scz0iNzIiPi0t IA0KU2FsdWRvcy9SZWdhcmRzDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkRyLiBGZXJuYW5kbyBCb3JvbmF0 IFNlZ3XtDQpQcm9mZXNvciBUaXR1bGFyIC8gTGVjdHVyZXIJDQpEZXB0LiBDb211bmljYWNpb25l cyAgICAgICAgICAgVGxmLi0rMzQrOTYyIDg0OSAzMDAgRXh0Li00OTM0MQ0KVGxmLiBkaXJlY3Rv IC0rMzQrOTYyIDg0OSAzNDEgIEZheC4tKzM0Kzk2MiA4NDkgMzA5IChDb21wYXJ0aWRvKQ0KVU5J VkVSU0lEQUQgUE9MSVTJQ05JQ0EgREUgVkFMRU5DSUEtQ0FNUFVTIERFIEdBTkRJQQ0KQ2FsbGUg UGFyYXJhbmluZm8sIDEsIENQLiA0NjczMCwgR3JhbyBkZSBHYW5kaWEgKFZhbGVuY2lhKSwgU1BB SU4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PTwvUFJFPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_TrBr9HUYBaN6AqU0NpPrqA)-- From bill.wu@huawei.com Thu Oct 20 02:29:09 2011 Return-Path: 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 A397421F8A6F for ; Thu, 20 Oct 2011 02:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.833 X-Spam-Level: X-Spam-Status: No, score=-4.833 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 Mv6OSq98qUZv for ; Thu, 20 Oct 2011 02:29:08 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 43A1821F8A97 for ; Thu, 20 Oct 2011 02:29:08 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTC006IAYA9BR@szxga05-in.huawei.com> for avt@ietf.org; Thu, 20 Oct 2011 17:27:46 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTC00MQ4YA6W6@szxga05-in.huawei.com> for avt@ietf.org; Thu, 20 Oct 2011 17:27:45 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI39623; Thu, 20 Oct 2011 17:27:20 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 20 Oct 2011 17:27:08 +0800 Received: from w53375q (10.138.41.130) by szxeml410-hub.china.huawei.com (10.82.67.137) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 20 Oct 2011 17:27:01 +0800 Date: Thu, 20 Oct 2011 17:27:01 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Magnus Westerlund Message-id: <06E9C1CF3B7D47B5A8FC8540EABA2FAF@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4E8D76C1.5080508@ericsson.com> <4E9E93A0.10701@ericsson.com> Cc: IETF AVTCore WG , draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 09:29:09 -0000 SGksIE1hZ251czoNClRoYW5rIGZvciB5b3VyIHJlcGxpZXMuIHBsZWFzZSBzZWUgaW5saW5lLg0K LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJNYWdudXMgV2VzdGVybHVuZCIg PG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NClRvOiAiUWluIFd1IiA8YmlsbC53dUBo dWF3ZWkuY29tPg0KQ2M6ICJJRVRGIEFWVENvcmUgV0ciIDxhdnRAaWV0Zi5vcmc+OyA8ZHJhZnQt aWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwQHRvb2xzLmlldGYub3JnPg0KU2Vu dDogV2VkbmVzZGF5LCBPY3RvYmVyIDE5LCAyMDExIDU6MDggUE0NClN1YmplY3Q6IFJlOiBbQVZU Q09SRV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb24t cnRwLTA3DQoNCg0KPiBIaSwNCj4gDQo+IFNvcnJ5IGZvciB0aGUgZGVsYXkgaW4gZm9sbG93aW5n IHVwLg0KPiANCj4gSSBoYXZlIHJlbW92ZWQgdGhlIGlzc3VlcyB3aGljaCBkb24ndCBuZWVkIGZ1 cnRoZXIgZGlzY3Vzc2lvbi4NCj4gDQo+IA0KPiBPbiAyMDExLTEwLTExIDAzOjQwLCBRaW4gV3Ug d3JvdGU6DQo+PiBIaSwgTWFnbnVzLA0KPj4gVGhhbmsgZm9yIHlvdXIgdmFsdWFibGUgcmV2aWV3 LCBwbGVhc2Ugc2VlIG15IHJlcGxpZXMgYmVsb3dzLg0KPj4gLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KPj4gRnJvbTogIk1hZ251cyBXZXN0ZXJsdW5kIiA8bWFnbnVzLndlc3Rlcmx1bmRA ZXJpY3Nzb24uY29tDQo+IA0KPj4gMi4gU2VjdGlvbiAzLg0KPj4gICAiVGhlIHRpbWVyIHZhbHVl IHNoYWxsIGJlDQo+PiAgICBiYXNlZCBvbiB0aGUgb2JzZXJ2ZWQgcm91bmQtdHJpcCB0aW1lLiAg QSByZWNlaXZlciBzaG91bGQgY29tcHV0ZSBhbg0KPj4gICAgZXN0aW1hdGUgb2YgdGhlIHJvdW5k LXRyaXAgdGltZSAoUlRUKSB0byB0aGUgc2VuZGVyIG9mIFRQTFIgZnJvbSBSVENQDQo+PiAgICBy ZXBvcnQgcm91bmQtdHJpcCB0aW1lIGlmIGF2YWlsYWJsZSwgb3IgaXRzIHJlY2VwdGlvbiB0aW1l IG9mIHRoZQ0KPj4gICAgcmVmbGVjdGVkIFJUQ1AgRkIgbWVzc2FnZSAoZS5nLixOQUNLKSwgb3Ig YW55IG90aGVyIG1lYW5zLiINCj4+IA0KPj4gV2UgaGFkZSB0aGUgZGlzY3Vzc2lvbiBiZWZvcmUg YnV0IG5vdyB0aGF0IHlvdSBjbGFyaWZpZWQgd2hpY2ggUlRUIHRvIGJlDQo+PiB1c2VkLCBJIHRo aW5rIGl0IGlzIHdvcnRoIGhhdmluZyBhIGRpc2N1c3Npb24gaWYgdGhhdCBSVFQgaXMgdGhlIHJp Z2h0DQo+PiBvbmUuIFNvIHlvdSBzdWdnZXN0IHRoYXQgdGhlIFJUVCBiZXR3ZWVuIHRoZSBzZW5k ZXIgb2YgdGhlIFRQTFIgYW5kIHRoZQ0KPj4gcmVjZWl2ZXIgb2YgdGhlIG1lc3NhZ2UgaXMgdGhl IG1vc3QgYXBwcm9wcmlhdGUgdG8gdXNlIHdoZW4gc3VwcHJlc3NpbmcNCj4+IHRoZSBtZXNzYWdl LiBJIGFtIG5vdCBjZXJ0YWluIHRoYXQgaXMgdGhlIGNhc2UuDQo+PiANCj4+IExldHMgY29uc2lk ZXIgdGhlIHVzZSBjYXNlcy4gSW4gdGhlIGNhc2Ugb2YgYW4gaW50ZXJtZWRpYXJ5IGluIGENCj4+ IGRpc3RyaWJ1dGlvbiB0cmVlIHNlbmRpbmcgdGhlIFRQTFIgYW5kIGF0IHRoZSBzYW1lIHRpbWUg c2VuZGluZyBhIE5BQ0sNCj4+IHVwc3RyZWFtLiBUaGVuIHRoZSB0aW1lIHVudGlsIHRoZSByZXRy YW5zbWlzc2lvbiByZWFjaGVzIHRoZSBzdXBwcmVzc2VkDQo+PiByZWNlaXZlciBpcyB0aGUgdGlt ZSBmcm9tIHRoZSBzZW5kaW5nIG9mIHRoZSBOQUNLIHVwIHRvIHRoZQ0KPj4gcmV0cmFuc21pdHRp bmcgZW50aXR5IGFuZCBhbGwgdGhlIHdheSBkb3duIHBhc3QgdGhlIFRQTFIgc2VuZGVyIHRvIHRo ZQ0KPj4gc3VwcHJlc3NlZCByZWNlaXZlci4gVGhlIHJlY2VpdmVyIG1heSBub3QgaGF2ZSBhIHRy dWUgUlRUIHRvIHRoZQ0KPj4gb3JpZ2luYWwgbWVkaWEgc2VuZGVyIGFzIHRoYXQgc291cmNlIGFw cGVhcnMgdG8gbGl2ZSBhdCB0aGUgVFBMUiBzZW5kZXIsDQo+PiBub3QgZnVydGhlciB1cHN0cmVh bS4NCj4+IA0KPj4gWWVzLCB0aGUgc2VuZGVyIG9mIHRoZSBUUExSIGFuZCB0aGUgcmVjZWl2ZXIg bWlnaHQgYXQgbGVhc3QgaGF2ZSBtdXR1YWwNCj4+IGtub3dsZWRnZSBvZiBlYWNoIG90aGVyLCB0 aHVzIHRoZSBUUExSIHNlbmRlciBpcyBhYmxlIHRvIGRldGVybWluZSB0aGUNCj4+IGxvd2VzdCBS VFQgaW4gdGhlIHNldCBvZiByZWNldmllcnMgdGh1cyBkZXRlcm1pbmluZyBob3cgb2Z0ZW4gdG8g cmVwZWF0DQo+PiBpdCB0byBjb3ZlciBhZGRpdGlvbmFsIHRpbWUgcmVxdXJpZWQgZm9yIHRoZSB1 cHN0cmVhbSBwYXJ0IG9mIHRoZQ0KPj4gcmVxdWVzdC4gQnV0IEkgZG8gbm90ZSB0aGF0IHRoZXNl IHRpbWVzIGFyZW4ndCBtYXRjaGluZyB3aGF0IGFwcGVhciB0bw0KPj4gYmUgdGhlIGRlbGF5cyBp biB0aGUgc3lzdGVtcy4NCj4+IA0KPj4gQ2FuIHdlIGZpbmQgYSBiZXR0ZXIgc29sdXRpb24/DQo+ PiAgDQo+PiANCj4+IFtRaW5dOiBJdCBsb29rcyB0byBtZSB0aGUgcm91bmQgdHJpcCB0aW1lIGJl dHdlZW4gbWVkaWEgc291cmNlIGFuZA0KPj4gDQo+PiAgaW50ZXJtZWRpYXJ5IGlzIHRyaXZpYWwg aWYgd2UgYXNzdW1lIHRoZSBpbnRlcm1lZGlhcnkgaXMgbXVjaA0KPj4gDQo+PiBjbG9zZXIgdG8g dGhlIHNvdXJjZSwgdGhhdCBpcyB3aHkgSSBwdXQgdGhlIGxhc3QgcGFyYWdyYXBoIGluIHRoZQ0K Pj4gDQo+PiBzZWN0aW9uIDMgYXMgZm9sbG93czoNCj4+IA0KPj4gkw0KPj4gDQo+PiBJbiBvcmRl ciBub3QgdG8gaW5jdXIgYSBsb3Qgb2YgTkFDSyByZXF1ZXN0cyBkdWUgdG8gYWRkaXRpb25hbCBU UExSDQo+PiANCj4+IGRlc2NyaWJlZCBhYm92ZSwgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUg UlRQIHN5c3RlbSBzZW5kaW5nDQo+PiANCj4+IFRQTFIgc2hvdWxkIGJlIGltcGxlbWVudGVkIG1v cmUgY2xvc2VyIHRvIHRoZSBzb3VyY2UuIEFsc28gd2hlbg0KPj4gDQo+PiAgdGhlIGxvc3Mgd2Fz IGRldGVjdGVkIGFuZCByZXBhaXIgaW5pdGlhdGVkIG11Y2ggY2xvc2VyIHRvIHRoZSBzb3VyY2Us DQo+PiANCj4+IHRoZSBkZWxheSBmb3IgdGhlIHJlY2VpdmVyIHRvIHJlY292ZXIgZnJvbSBwYWNr ZXQgbG9zcyBjYW4gYmUgcmVkdWNlZA0KPj4gDQo+PiB0aHJvdWdoIHRoZSBjb21iaW5hdGlvbiBv ZiBpbnRlcm1lZGlhcnkgZmVlZGJhY2sgdG8gdGhlIHNvdXJjZSBhbmQNCj4+IA0KPj4gVGhpcmQg UGFydHkgTG9zcyBSZXBvcnQgZG93bnN0cmVhbS4NCj4+IA0KPj4glA0KPj4gDQo+PiAgDQo+PiAN Cj4+IElmIHdlIGxvb2sgZm9yIGEgYmV0dGVyIHNvbHV0aW9uLCBJIHRoaW5rIHdlIGhhdmUgdHdv IHBvc3NpYmxlIHdheXM6DQo+PiANCj4+IFRoZSBmaXJzdCB3YXkgaXMgdG8gcmVseSBvbiBzZW5k ZXIgcmVwb3J0IGZyb20gbWVkaWEgc2VuZGVyIHRvDQo+PiANCj4+IGNhbGN1bGF0ZSB0aGUgbW9y ZSBhcHByb3hpbWF0ZSBSVFQgZnJvbSBtZWRpYSBzZW5kZXIgdG8gdGhlIHJlY2VpdmVyLg0KPj4g DQo+PiBSVFQgbWVhc3VyZW1lbnQgbWV0aG9kIGZvbGxvd3MgdGhlIHNhbWUgd2F5IGRlc2NyaWJl ZCBpbiB0aGUNCj4+IA0KPj4gZmlndXJlIDIgb2YgUkZDMzU1MC4NCj4+IA0KPj4gIA0KPj4gDQo+ PiBUaGUgc2Vjb25kIHdheSBpcyB0byB3ZSBjYW4gYWxsb3cgdGhlIGludGVybWVkaWFyeSB0ZWxs IHRoZSByZWNlaXZlciB0aGUNCj4+IA0KPj4gUlRUIGZyb20gbWVkaWEgc291cmNlIHRvIGludGVy bWVkaWFyeSBpdHNlbGYgYnkgc2VuZGluZyBhIG5ldyBtZXNzYWdlDQo+PiANCj4+IHNpbmNlIHRo ZSBpbnRlcm1lZGlhcnkgY2FuIG1lYXN1cmUgc3VjaCBSVFQgYmFzZWQgb24gcGFzdCBvYnNlcnZh dGlvbg0KPj4gDQo+PiBhbmQgZXN0aW1hdGlvbi4gSG93ZXZlciBmb3IgdGhlIHNlY29uZCB3YXkg d2UgbmVlZCB0byBkZWZpbmUgbmV3DQo+PiANCj4+IG1lc3NhZ2Ugb3IgZXh0ZW5kIFRQTFIgbWVz c2FnZSB0byBjYXJyeSBzdWNoIFJUVC4NCj4+IA0KPj4gIA0KPj4gDQo+PiBXaGF0IGRvIHlvdSB0 aGluaz8NCj4+IA0KPiANCj4gRnJvbSBmb2xsb3cgdXAgZW1haWw6DQo+PiBIaSxNYWdudXM6IEFz IHJlZ2FyZGluZyBpZiB0aGVyZSBpcyBiZXR0ZXIgc29sdXRpb24sIEkgaGF2ZSBzb21lDQo+PiBj b3JyZWN0aW9ucyBhbmQgYWRkaXRpb25hbCB0aG91Z2h0cy4NCj4+IEkgdGhpbmsgSWYgdGhlIG1l ZGlhIHNvdXJjZSBpcyB0aGUgcmVwYWlyIHNlcnZlciwgdGhlIHJlY2VpdmVyIHNob3VsZA0KPj4g c2V0IHRpbWVyIHRvIFQxPW1heCh0aGUgUlRUIGZyb20gbWVkaWEgc291cmNlIHRvIG1pZGRsZWJv eCBzZW5kaW5nDQo+PiBUUExSLCAxLzIgb2YgUlRUIGZyb20gbWlkZGxlYm94IHRvIHJlY2VpdmVy KSB3aGVuIHRoZSByZWNlaXZlcg0KPj4gcmVjZWl2ZXMgZmlyc3QgVFBMUi4gV2hlbiB0aGUgcmVj ZWl2ZXIgcmVjZWl2ZSBhZGR0aW9uYWwgVFBMUiB3aXRoaW4NCj4+IFQxLCB0aGUgcmVjZWl2ZXIg c2hvdWxkIHJlc2V0IHRoZSB0aW1lciB0byB0aGUgUlRUIGZyb20gbWVkaWEgc291cmNlDQo+PiB0 byBtaWRkbGVib3ggc2VuZGluZyBUUExSLg0KPj4gDQo+PiBJZiB0aGUgbWlkZGxlYm94IGlzIHRo ZSByZXBhaXIgc2VydmVyLCB0aGUgcmVjZWl2ZXIgc2hvdWxkIHNldCB0aGUNCj4+IHRpbWVyIHRv IFQyPTEvMiBvZiBSVFQgZnJvbSBtaWRkbGVib3ggdG8gcmVjZWl2ZXIgd2hlbiB0aGUgcmVjZWl2 ZXINCj4+IHJlY2VpdmVzIGZpcnN0IFRQTFIuIFdoZW4gdGhlIHJlY2VpdmVyIHJlY2VpdmUgYWRk dGlvbmFsIFRQTFIgd2l0aGluDQo+PiBUMiwgdGhlIHJlY2VpdmVyIHNob3VsZCByZXNldCB0aGUg dGltZXIgdG8gdGhlIFQyLg0KPj4gDQo+IA0KPiBDYW4geW91IGV4cHJlc3MgdGhlc2UgcnVsZXMg Zm9yIHRoZSByZWNlaXZlciBhcyBzb21ldGhpbmcgdGhhdCBpcyBiYXNlZA0KPiBvbiB3aGF0IGlz IG9ic2VydmFibGUgZnJvbSB0aGUgUlRQIGFuZCBSVENQIHRyYWZmaWM/IElzIHdoZW4gbWVkaWEN Cj4gc2VydmVyIGJlaW5nIHJlcGFpciBzZXJ2ZXIgZXF1YWwgdG8gVFBMUiBzZW5kZXIgU1NSQyA9 IE1lZGlhIFNTUkMgdGhlDQo+IFRQTFIgYXBwbGllcyBvbj8gQW5kIGlmIHRoZXkgYXJlIG5vdCB0 aGUgc2FtZSBpdCBpcyB0aGUgc2Vjb25kIGNhc2U/DQo+IA0KDQoNCltRaW5dOiBPa2F5LCBJIHRo aW5rIHRoZSBtZWRpYSBzb3VyY2Ugd2lsbCBub3QgYmUgdGhlIFRQTFIgc2VuZGVyLiANCg0KIA0K DQpUaGUgcmVjZWl2ZXIgc2hvdWxkIHNldCB0aGUgdGltZXIgZm9yIHRoZSByZXRyYW5zbWl0dGVk IGRhdGEgcGFja2V0IHdoZW4gaXQgcmVjZWl2ZSB0aGUgZmlyc3QgVFBMUi4NCg0KDQoNCg0KSWYg dGhlIHNlbmRlciBvZiBSZXRyYW5zbWl0dGVkIGRhdGEgcGFja2V0IGlzIHRoZSBtZWRpYSBzb3Vy Y2UsIHRoZSB0aW1lciB2YWx1ZSBzaGFsbCBiZQ0KDQpiYXNlZCBvbiB0aGUgb2JzZXJ2ZWQgdGlt ZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHJvdW5kLXRyaXAgdGltZSBmcm9tIHRoZSByZWNlaXZl ciB0byANCg0KdGhlIG9yaWdpbmFsIG1lZGlhIHNvdXJjZSBhbmQgdGhlIHJvdW5kLXRyaXAgdGlt ZSBmcm9tIHRoZSByZWNlaXZlciB0byB0aGUgc2VuZGVyIG9mIHRoZSBUUExSLiAgDQoNCg0KDQpB IHJlY2VpdmVyIHNob3VsZCBjb21wdXRlIGFuIGVzdGltYXRlIG9mIHRoZSByb3VuZC10cmlwIHRp bWUgKFJUVCkgdG8gdGhlIG9yaWdpbmFsIG1lZGlhIHNvdXJjZSANCg0KZnJvbSBTZW5kZXIgUmVw b3J0IChTUikgcGFja2V0cyBmb3IgdGhlIG9yaWdpbmFsIHN0cmVhbSwgb3IgYW55IG90aGVyIG1l YW5zLiBUaGUgcm91bmQtdHJpcCB0aW1lIA0KDQpmcm9tIHRoZSByZWNlaXZlciB0byB0aGUgc2Vu ZGVyIG9mIHRoZSBUUExSIGNhbiBiZSBjYWxjdWxhdGVkIGZyb20gUlRDUCByZXBvcnQgcm91bmQt dHJpcCB0aW1lIA0KDQppZiBhdmFpbGFibGUsIG9yIGFueSBvdGhlciBtZWFucy4NCg0KDQoNCj4+ ICANCj4+IA0KPj4gMy4gU2VjdGlvbiAzOg0KPj4gICAiVG8gaW5jcmVhc2UgdGhlIHJvYnVzdG5l c3MgdG8gdGhlIGxvc3Mgb2YgYSBUUExSIG9yIG9mIGEgdHJhbnNtaXNzaW9uDQo+PiAgICBwYWNr ZXQsIGEgcmVjZWl2ZXIgaXMgYWxsb3dlZCB0byByZWNlaXZlIGFkZGl0aW9uYWwgVFBMUiBmb3Ig dGhlIHNhbWUNCj4+ICAgIHBhY2tldC4gIEluIHRoZSBjYXNlIHRoZSBmaXJzdCBUUExSIGlzIGxv c3QgYW5kIHRoZSBhZGRpdGlvbmFsIFRQTFINCj4+ICAgIGFycml2ZXMgYXQgdGhlIHJlY2VpdmVy LCB0aGUgcmVjZWl2ZXIgc2hvdWxkIGltbWVkaWF0ZWx5IHJlZnJlc2ggdGhlDQo+PiAgICB0aW1l ci4iDQo+PiANCj4+IEluIHRoZSBzZWNvbmQgc2VudGVuY2UgSSBkb24ndCBzZWUgaG93IHRoZSBy ZWNlaXZlciBjYW4ga25vdyB0aGF0IGl0IGlzDQo+PiBhIHJldHJhbnNtaXNzaW9uLiBJdCBpcyBz aW1wbHkgYSBUUExSIGZyb20gaXRzIHBlcnNwZWN0aXZlIGlmIHRoYXQgaXMgbG9zdC4NCj4+IA0K Pj4gUm9idXN0bmVzcyByZWFzb25zIGlzIG9ubHkgb25lIHJlYXNvbiBmb3IgcmVwZWF0aW5nIHRo ZW0gdGhlIG90aGVyIGlzDQo+PiBjbGVhcmx5IHRvIHJlbmV3IHRoZSB0aW1lci4gVGh1cyBJIHRo aW5rIHRoZSBmb3JtdWxhdGlvbiBzaG91bGQgYmUgbW9yZQ0KPj4gZ2VuZXJpYyB0byBtYWtlIGl0 IGNsZWFyIHRoYXQgYWxsIHJlY2VpdmVycyBzaG91bGQgdXBvbiByZWNlcHRpb24gb2YgYQ0KPj4g VFBMUiByZWZyZXNoIHRoZSB0aW1lciBmb3IgdGhlIHBhY2tldHMgaW5kaWNhdGVkLg0KPj4gDQo+ PiAgDQo+PiANCj4+IFtRaW5dOiBJZiB0aGUgcmVjZWl2ZXIgZG9lcyBub3Qga2VlcCBzdGF0ZSBm b3IgdGhlIHRpbWVzIHRoZSBUUExSIGlzDQo+PiANCj4+ICByZXRyYW5zbWl0dGVkLCB3ZSBjYW4g YWRkIHJlcGV0aXRpb24gY291bnQgZmllbGQgaW4gZWFjaCBGQ0kgZW50cnkNCj4+IA0KPj4gIG9m IFRQTFIgZmVlZGJhY2sgbWVzc2FnZSB0byBpbmRpY2F0ZSB0aGUgdGltZXMgVFBMUiBpcyByZXRy YW5zbWl0dGVkLg0KPj4gDQo+PiAgUGFydGljdWxhcmx5IGluIFBTTEVJIEZlZWRiYWNrIE1lc3Nh Z2UsIHdlIGNhbiByZXVzZSBzZXEgbnIuIEZpZWxkIHRvDQo+PiANCj4+ICBpbmRpY2F0ZSBpZiBh ZGRpdGlvbmFsIFRQTFIgaXMgcmV0cmFuc21pdHRlZCwgd2hpY2ggb25lIHlvdSB0aGluayBiZXR0 ZXI/DQo+PiANCj4+IA0KPiANCj4gSG93LCBjYW4gdGhlIHJlY2VpdmVyIGtlZXAgc3RhdGUgZm9y IHNvbWV0aGluZyBpdCBoYXMgbm90IHNlZW4gZHVlIHRvDQo+IHRoZSBpbml0aWFsIHBhY2tldCBu b3QgaGF2aW5nIGJlZW4gcmVjZWl2ZWQ/DQo+IA0KPiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgbmV3 IHBhY2tldCBleHRlbnNpb25zLCBqdXN0IGNsYXJpZmllZCBydWxlcyB0aGF0DQo+IGNvcnJlY3Rs eSBkZXNjcmliZSB3aGF0IHRoZSBSVFAgZW5kLXBvaW50IHNob3VsZCBkbyB3aGVuIGl0IHNlZXMg dGhlDQo+IFRQTFIgbWVzc2FnZS4NCg0KW1Fpbl07IE9rYXksIEkgQWdyZWUgd2l0aCB0aGF0LCBz ZWUgYmVsb3cuDQoNCj4gDQo+PiANCj4+IDcuIFNlY3Rpb24gNC4yOg0KPj4gICAgU2VxIG5yOjhi aXRzICBDb21tYW5kIHNlcXVlbmNlIG51bWJlci4gIEl0IGlzIHVzZWQgYnkgdGhlIENvbW1hbmQN Cj4+ICAgICAgIHJlY2VpdmVyIHRvIGNoZWNrIGlmIHRoZSBDb21tYW5kIGlzIHJlcGVhdGVkLiAg VGhlIHNlcXVlbmNlIG51bWJlcg0KPj4gICAgICAgc3BhY2UgaXMgdW5pcXVlIGZvciBlYWNoIHBh aXJpbmcgb2YgdGhlIFNTUkMgb2YgY29tbWFuZCBzZW5kZXIgYW5kDQo+PiAgICAgICB0aGUgU1NS QyBvZiB0aGUgY29tbWFuZCByZWNlaXZlci4gIFRoZSBzZXF1ZW5jZSBudW1iZXIgU0hBTEwNCj4+ ICAgICAgIGluY3JlYXNlIGJ5IDEgbW9kdWxvIDI1NiBmb3IgZWFjaCBuZXcgQ29tbWFuZC4gIEEg cmVwZXRpdGlvbiBTSEFMTA0KPj4gICAgICAgTk9UIGluY3JlYXNlIHRoZSBzZXF1ZW5jZSBudW1i ZXIuICBUaGUgaW5pdGlhbCB2YWx1ZSBpcyBhcmJpdHJhcnkuDQo+PiANCj4+IEJhc2VkIG9uIHRo YXQgaXQgaXMgZGVmaW5lZCB0aGF0IHVwb24gcmVjZWl2aW5nIG9uZSBvZiB0aGUgUFNMRUkNCj4+ IHJlcXVlc3QsIG9uZSBzaG91bGRuJ3Qgc2VuZCBhIEZJUiBvciBQTEkgbWVzc2FnZSBmb3IgYSB0 aW1lIGludGVydmFsDQo+PiBlcXVhbCB0byB0aGUgUlRUIGJldHdlZW4gdGhlIHJlY2VpdmVyIGFu ZCB0aGUgc2VuZGVyIG9mIHRoZSBQU0xFSQ0KPj4gbWVzc2FnZSBkb2VzIHRoZSBzZXF1ZW5jZSBu dW1iZXIgZmllbGQgaGF2ZSBhbnkgbWVhbmluZz8gRnJvbSBteQ0KPj4gcGVyc3BlY3RpdmUgaXQg ZG9lc24ndCBtYXR0ZXIgaWYgaXQgaXMgYSBuZXcgcmVxdWVzdCBvciBub3QuIFlvdSBhcmUNCj4+ IHN1cHByZXNzZWQgZnJvbSB0aGUgcmVjZXB0aW9uIG9mIHRoZSBtZXNzYWdlLCBub3RoaW5nIGVs c2UuDQo+PiANCj4+IFtRaW5dOiBJIHRoaW5rIHdlIGNhbiB1c2Ugc2VxIG5yIGZpZWxkIHRvIGlu ZGljYXRlIHRoZSB0aW1lcyB0aGUgVFBMUiBpcw0KPj4gcmV0cmFuc21pdHRlZCwgZS5nLiwNCj4+ IA0KPj4gSWYgdGhlIGFkZGl0aW9uYWwgVFBMUiB3aXRoIHRoZSBzYW1lIFNTUkMgYW5kIGRpZmZl cmVudCBTZXEgTnVtYmVyIGlzDQo+PiByZWNlaXZlZCwgdGhlDQo+PiANCj4+IHJlY2VpdmVyIGtu b3dzIHRoYXQgaXQgaXMgYSByZXRyYW5zbWlzc2lvbiBpZiB0aGUgcmVjZWl2ZXIga2VlcHMgc3Rh dGUNCj4+IGZvciB0aGUgcHJldmlvdXMNCj4+IA0KPj4gVFBMUiB3aXRoIHRoZSBzYW1lIFNTUkMu DQo+PiANCj4+IEFsc28gd2UgY2FuIHJlcGxhY2Ugc2VxIG5yLiBGaWVsZCB3aXRoIFJlcGV0aXRp b24gY291bnQgZmllbGQgdG8NCj4+IGluZGljYXRlIGhvdyBtYW55IHRpbWUNCj4+IA0KPj4gdGhl IFRQTFIgaXMgcmV0cmFuc21pdHRlZC4NCj4+IA0KPj4gDQo+IA0KPiBUaGF0IGlzIHBvc3NpYmxl LCBidXQgaXMgdGhlIHJlcGV0aXRpb24gY291bnQgcmVhbGx5IHByb3ZpZGluZyBhbnl0aGluZz8N Cj4gV2hhdCBpcyB0aGUgc2ltcGxlc3QgbW9zdCBzdHJhaWdodCBmb3J3YXJkIHRoYXQgY2FuIHdv cms/IEkgdGhpbmsgdGhhdA0KPiBpcyB0aGF0IG9uZSBzaW1wbGUgc3VwcHJlc3MgdGhlIHNvdXJj ZSBmb3IgWCB0aW1lIGFmdGVyIGhhdmluZyByZWNlaXZlcw0KPiBhIFRQTFIgbWVzc2FnZSBpbmRp Y2F0ZSB0aGF0IHNvdXJjZS4gU28sIGFzIGxvbmcgYXMgeW91IGdldCByZXBlYXQNCj4gbWVzc2Fn ZXMgbW9yZSBvZnRlbiB0aGFuIFggeW91IGNvbnRpbnVlIHRvIGJlIHN1cHByZXNzZWQuIFdpbGwg dGhlDQo+IHJlY2VpdmVyIHdvcmsgYmV0dGVyIHRvIGtub3cgdGhhdCBpdCBpcyBub3cgc3VwcHJl c3NlZCBmb3IgWSB0aW1lcyBpbiBhDQo+IGdvIGJlY2F1c2Ugb2YgdGhlIHNhbWUgZXZlbnQ/DQoN CltRaW5dOiBJIGFncmVlIHRoYXQgYWRkaW5nIG5ldyBmaWVsZCBpcyBhIGxpdHRsZSBvdmVyZGVz aWduIGFuZCBkb2VzIG5vdCB0b28gbXVjaCB2YWx1ZS4NCg0KIFlvdXIgcHJvcG9zYWwgaXMgbW9y ZSBzdHJhaWdodGZvcndhcmQgYW5kIGxvb2tzIGdvb2QgdG8gbWUuIEkgd2lsbCBtYWtlIGl0IGNs ZWFyIGluIHRoZSB0ZXh0Lg0KDQoNCj4gY2hlZXJzDQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0K PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24g UmVzZWFyY2ggRUFCL1RWTQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAg ICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbkcvZnYXRhbiA2ICAgICAgICAgICAg ICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRl bnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPg== From p.ohanlon@gmail.com Thu Oct 20 05:34:15 2011 Return-Path: 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 8A73721F8A91 for ; Thu, 20 Oct 2011 05:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] 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 9dWU5M68LQ92 for ; Thu, 20 Oct 2011 05:34:14 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F46321F8A58 for ; Thu, 20 Oct 2011 05:34:14 -0700 (PDT) Received: by gyh20 with SMTP id 20so3317052gyh.31 for ; Thu, 20 Oct 2011 05:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=t5KjO47e2E12wONuiK0dS6evOa8N9afndcxjS6wcFCU=; b=UTW9Y8tmHgO0oCFVwRWRxldLS/SCZuWvzWCW5TdmMjWa7vm7//Je2l+7UZAp2AIE5v b+fRHU3TfWuq/YAZlO6ssJhLvseLE8JPPAjWisHTsxP/tSs9V1RuHSleTqLsV2SMs6aR uk1miDvHal/2Jh7tYTAqOzPID8CO7NNMuQnI8= Received: by 10.43.50.201 with SMTP id vf9mr13274759icb.10.1319114052190; Thu, 20 Oct 2011 05:34:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.169.66 with HTTP; Thu, 20 Oct 2011 05:33:52 -0700 (PDT) In-Reply-To: <4C7553D5AE4E4B7CB13038F3256FF536@china.huawei.com> References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <76AADF1A61784B52A8516E16AAF78E71@china.huawei.com> <4C7553D5AE4E4B7CB13038F3256FF536@china.huawei.com> From: "Piers O'Hanlon" Date: Thu, 20 Oct 2011 13:33:52 +0100 Message-ID: To: Qin Wu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Magnus Westerlund , avt@ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 12:34:15 -0000 Hi Qin Comments inline. On 18 October 2011 07:14, Qin Wu wrote: > Hi,Piers: > You address most of my comments which are removed from this followup. > Please see a few my remaining comments below. > > Regards! > -Qin > ----- Original Message ----- > From: "Piers O'Hanlon" > To: "Qin Wu" > Cc: "Roni Even" ; ; "Magnus Westerlun= d" > Sent: Friday, October 14, 2011 10:54 PM > Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 > > > Dear Qin, > > Thanks for your feedback. Comments inline [omitting Thomas's clarificatio= ns] > > On 11 October 2011 03:46, Qin Wu wrote: >> Hi, >> I have reviewed this draft and support it moving towards publication. >> Here is my minor editional comments to this 04 version draft. >> 1. Section 1 >> [Qin]:Is it better to move the first paragraph next to the third paragra= ph. >> >> 2. Section 3, 1st paragraph >> " >> ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], >> and DCCP [RFC4340] transports. These are all unicast protocols which >> negotiate the use of ECN during the initial connection establishment >> handshake (supporting incremental deployment, and checking if ECN >> marked packets pass all middleboxes on the path). >> " >> [Qin]: I think "these" in the second sentence can't be "ECN" >> mentioned in the first sentence. Is it better to replace "these" >> the first word in this sentence with "these transport"? >> > The 'these' in the second sentance refers to the transport protocols > (not ECN). I think the existing wording is probably ok. > > [Qin]: I know. But the problem is you change the subject in two consecuti= ve sentences which looks ambiguity to me. > that's why I suggest you to do some rewording. > I can understand your concern but I think it is clear enough as is. >> " >> If the path between the sender and the receivers exhibits either of thes= e >> behaviours one >> needs to stop using ECN immediately to protect both the network and >> the application. >> " >> [Qin]: How does sender or receiver detects ECN is misused? Who is the >> "one" in this sentence? If it is middlebox, the middlebox should also >> tell the sender ECN is not used. >> > As mentioned earlier in the section the "behaviours" will be detected by = the > end-systems. The 'one' is the parties involved in the connection setup - = which > could in certain cases be a 'middlebox' - but that doesn't need to be exp= licitly > covered here. > > [Qin]: It is still not clear to me.If end system detects those behavior a= nd one is the middlebox, > how end systems that detects those behavior tellsthe middlebox that those= behaviro occur, > through dedicated ECN feedback message or any other means? or you assume = the middlebox > can be a receiver? > The term "middlebox" is rather generic and can apply to wide range of entities including ones that implement ECN for RTP (e.g. RTP mixer/translators). These entities would be able to detect bad behaviours and react to them according to this document's specification. However other middleboxes that don't actually take part in the session may also be able detect what they see as bad behaviour but their operation is out of scope of this document. > >> be able to rapidly negotiate ECN support for such a session, >> but the optimisation above can fail if there are >> implementations that use the same CNAME for different parts of >> a distributed implementation that have different transport >> characteristics (e.g., if a single logical endpoint is split >> across multiple hosts). >> " >> [Qin]: I don't get this example clearly. are you saying when two streams >> with the same CNAME >> is sent from the same RTP sender, such above optimization applies.Howeve= r >> when two streams >> with the same CNAME are sent from two differnt RTP entities,such above >> optimization can not apply. >> > For the first part you are correct, but the the two stream case only > talks about a > 'logical endpoint' i.e. a single RTP endpoint which is split over > multiple hosts, not separate RTP endpoints. > > [Qin]: In this case, CNAME is not enough to identify each of RTPendpoints= . > From this perspective, I agree. > Is that what you are saying? > Yes. > >> 25. Section 7.4.1,4th paragraph >> " >> load balancing devices may in worst case result in that some packets tak= e a >> different network path then the others; >> " >> [Qin]: Should "then" in this sentence be "than" ? >> > No. > > [Qin]: Why? Using "different from" instead? > I'm sorry you're correct here (I initially looked at the wrong 'then'). >> 26. Section 7.4.2, 4th paragraph >> " >> The rate of packet duplication is tracked, allowing one to take the >> duplication into account. The value of the ECN field for duplicates >> will also be counted and when comparing the figures one needs to take >> " >> [Qin]: What and where are the figures? >> > The 'figures' refers to the values of the various counters of ECN marking= s, as > explained earlier in the paragraph. > > [Qin]: I misunderstood "figures" as "charts" or "drawings", Isn't worth b= etter wording? > I can understand that one may confuse the meaning but I think it ok as is. >> 27.Section 8.2,8th paragraph >> " >> When rounding counter values in the translated RTCP packet, the >> translator should try to ensure that they sum to the number of RTP >> packets in the pre-translation sequence number space (numOrig). The >> translator should also try to ensure that no non-zero counter is >> rounded to a zero value, since that will lose information that a >> particular type of event has occurred. It is recognised that it may >> be impossible to satisfy both of these constraints; >> " >> >> [Qin]: What's the difficulty to satisfy both constraints, why non-zero >> counter can be rounded into zero? what kind of round method is used? >> can you explain a little bit? >> > Because the translator actually alters the packet stream there is not alw= ays > a clear mapping between the values taken from the original packets vs the > translated packets. But if a particular event has been reported it is bes= t to > report that event (e.g. ECN-CE marking) has occurred in the translated > packets - but they may not always add up correctly if one wants to indica= te > that a marking is now 'spread' over more than one packet in the translate= d > stream. The rounding used means that it shouldn't round down to zero unle= ss > the pre-translated values are zero. > > [Qin]: Thank for your clarfication, I am clear, it is better to replace > " > The translator should also try to ensure that no non-zero counter is > =A0rounded to a zero value > " > with your proposed text > " > The translator should also try to ensure that no non-zero counter is > =A0rounded to a zero value =A0unless the pre-translated values are zero. > " > That will be more clear to me. > We could add that clarification. Thanks again, Piers. > Thanks, > > Piers. > >> Regards! >> -Qin >> >> >> ----- Original Message ----- >> From: Roni Even >> To: avt@ietf.org >> Sent: Friday, September 30, 2011 8:29 PM >> Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 >> >> Hi, >> >> I would like to start a WGLC on >> http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit >> Congestion Notification (ECN) for RTP over UDP. >> >> >> >> The WGLC will end on October 21, 2011 >> >> >> >> Please review the draft and send comments to the list. >> >> >> >> >> >> Roni Even >> >> >> >> >> >> >> >> ________________________________ >> >> _______________________________________________ >> 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 >> >> > From bill.wu@huawei.com Thu Oct 20 06:24:38 2011 Return-Path: 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 D9FCA21F8B8C for ; Thu, 20 Oct 2011 06:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.936 X-Spam-Level: X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[AWL=-3.985, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 M5w-hU-iB9gc for ; Thu, 20 Oct 2011 06:24:37 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 267E221F8B86 for ; Thu, 20 Oct 2011 06:24:37 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTD00DLM93O11@szxga04-in.huawei.com> for avt@ietf.org; Thu, 20 Oct 2011 21:21:24 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTD002HJ93M3S@szxga04-in.huawei.com> for avt@ietf.org; Thu, 20 Oct 2011 21:21:24 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI50963; Thu, 20 Oct 2011 21:21:23 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 20 Oct 2011 21:21:18 +0800 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.73]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Thu, 20 Oct 2011 21:21:13 +0800 Date: Thu, 20 Oct 2011 13:21:12 +0000 From: Qin Wu In-reply-to: X-Originating-IP: [172.24.2.41] To: Piers O'Hanlon Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 Thread-index: Acx/bJMAZn1O9EdQQ6OkqDNm9OOyyQIWZj4CAJ3+2QAAyFZpaABgfcMAABJmBoY= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <76AADF1A61784B52A8516E16AAF78E71@china.huawei.com> <4C7553D5AE4E4B7CB13038F3256FF536@china.huawei.com> Cc: Magnus Westerlund , "avt@ietf.org" Subject: [AVTCORE] =?gb2312?b?tPC4tDogIFdHTEMgb24gZHJhZnQtaWV0Zi1hdnRjb3Jl?= =?gb2312?b?LWVjbi1mb3ItcnRwLTA0?= X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:24:39 -0000 SGksUGllcnM6DQpZb3UgYWRkcmVzcyBteSBjb21tZW50cywgdGhhbmtzIQ0KDQpSZWdhcmRzIQ0K LVFpbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGF2dC1i b3VuY2VzQGlldGYub3JnIFthdnQtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBQaWVycyBPJ0hhbmxv biBbcC5vaGFubG9uQGdtYWlsLmNvbV0NCreiy83KsbzkOiAyMDExxOoxMNTCMjDI1SAyMDozMw0K tb06IFFpbiBXdQ0KQ2M6IE1hZ251cyBXZXN0ZXJsdW5kOyBhdnRAaWV0Zi5vcmcNCtb3zOI6IFJl OiBbQVZUQ09SRV0gV0dMQyBvbiBkcmFmdC1pZXRmLWF2dGNvcmUtZWNuLWZvci1ydHAtMDQNCg0K SGkgUWluDQoNCkNvbW1lbnRzIGlubGluZS4NCg0KT24gMTggT2N0b2JlciAyMDExIDA3OjE0LCBR aW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IEhpLFBpZXJzOg0KPiBZb3UgYWRk cmVzcyBtb3N0IG9mIG15IGNvbW1lbnRzIHdoaWNoIGFyZSByZW1vdmVkIGZyb20gdGhpcyBmb2xs b3d1cC4NCj4gUGxlYXNlIHNlZSBhIGZldyBteSByZW1haW5pbmcgY29tbWVudHMgYmVsb3cuDQo+ DQo+IFJlZ2FyZHMhDQo+IC1RaW4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBG cm9tOiAiUGllcnMgTydIYW5sb24iIDxwLm9oYW5sb25AZ21haWwuY29tPg0KPiBUbzogIlFpbiBX dSIgPGJpbGwud3VAaHVhd2VpLmNvbT4NCj4gQ2M6ICJSb25pIEV2ZW4iIDxFdmVuLnJvbmlAaHVh d2VpLmNvbT47IDxhdnRAaWV0Zi5vcmc+OyAiTWFnbnVzIFdlc3Rlcmx1bmQiIDxtYWdudXMud2Vz dGVybHVuZEBlcmljc3Nvbi5jb20+DQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNCwgMjAxMSAx MDo1NCBQTQ0KPiBTdWJqZWN0OiBSZTogW0FWVENPUkVdIFdHTEMgb24gZHJhZnQtaWV0Zi1hdnRj b3JlLWVjbi1mb3ItcnRwLTA0DQo+DQo+DQo+IERlYXIgUWluLA0KPg0KPiBUaGFua3MgZm9yIHlv dXIgZmVlZGJhY2suIENvbW1lbnRzIGlubGluZSBbb21pdHRpbmcgVGhvbWFzJ3MgY2xhcmlmaWNh dGlvbnNdDQo+DQo+IE9uIDExIE9jdG9iZXIgMjAxMSAwMzo0NiwgUWluIFd1IDxiaWxsLnd1QGh1 YXdlaS5jb20+IHdyb3RlOg0KPj4gSGksDQo+PiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBh bmQgc3VwcG9ydCBpdCBtb3ZpbmcgdG93YXJkcyBwdWJsaWNhdGlvbi4NCj4+IEhlcmUgaXMgbXkg bWlub3IgZWRpdGlvbmFsIGNvbW1lbnRzIHRvIHRoaXMgMDQgdmVyc2lvbiBkcmFmdC4NCj4+IDEu IFNlY3Rpb24gMQ0KPj4gW1Fpbl06SXMgaXQgYmV0dGVyIHRvIG1vdmUgdGhlIGZpcnN0IHBhcmFn cmFwaCBuZXh0IHRvIHRoZSB0aGlyZCBwYXJhZ3JhcGguDQo+Pg0KPj4gMi4gU2VjdGlvbiAzLCAx c3QgcGFyYWdyYXBoDQo+PiAiDQo+PiBFQ04gaGFzIGJlZW4gc3BlY2lmaWVkIGZvciB1c2Ugd2l0 aCBUQ1AgW1JGQzMxNjhdLCBTQ1RQIFtSRkM0OTYwXSwNCj4+IGFuZCBEQ0NQIFtSRkM0MzQwXSB0 cmFuc3BvcnRzLiBUaGVzZSBhcmUgYWxsIHVuaWNhc3QgcHJvdG9jb2xzIHdoaWNoDQo+PiBuZWdv dGlhdGUgdGhlIHVzZSBvZiBFQ04gZHVyaW5nIHRoZSBpbml0aWFsIGNvbm5lY3Rpb24gZXN0YWJs aXNobWVudA0KPj4gaGFuZHNoYWtlIChzdXBwb3J0aW5nIGluY3JlbWVudGFsIGRlcGxveW1lbnQs IGFuZCBjaGVja2luZyBpZiBFQ04NCj4+IG1hcmtlZCBwYWNrZXRzIHBhc3MgYWxsIG1pZGRsZWJv eGVzIG9uIHRoZSBwYXRoKS4NCj4+ICINCj4+IFtRaW5dOiBJIHRoaW5rICJ0aGVzZSIgaW4gdGhl IHNlY29uZCBzZW50ZW5jZSBjYW4ndCBiZSAiRUNOIg0KPj4gbWVudGlvbmVkIGluIHRoZSBmaXJz dCBzZW50ZW5jZS4gSXMgaXQgYmV0dGVyIHRvIHJlcGxhY2UgInRoZXNlIg0KPj4gdGhlIGZpcnN0 IHdvcmQgaW4gdGhpcyBzZW50ZW5jZSB3aXRoICJ0aGVzZSB0cmFuc3BvcnQiPw0KPj4NCj4gVGhl ICd0aGVzZScgaW4gdGhlIHNlY29uZCBzZW50YW5jZSByZWZlcnMgdG8gdGhlIHRyYW5zcG9ydCBw cm90b2NvbHMNCj4gKG5vdCBFQ04pLiBJIHRoaW5rIHRoZSBleGlzdGluZyB3b3JkaW5nIGlzIHBy b2JhYmx5IG9rLg0KPg0KPiBbUWluXTogSSBrbm93LiBCdXQgdGhlIHByb2JsZW0gaXMgeW91IGNo YW5nZSB0aGUgc3ViamVjdCBpbiB0d28gY29uc2VjdXRpdmUgc2VudGVuY2VzIHdoaWNoIGxvb2tz IGFtYmlndWl0eSB0byBtZS4NCj4gdGhhdCdzIHdoeSBJIHN1Z2dlc3QgeW91IHRvIGRvIHNvbWUg cmV3b3JkaW5nLg0KPg0KSSBjYW4gdW5kZXJzdGFuZCB5b3VyIGNvbmNlcm4gYnV0IEkgdGhpbmsg aXQgaXMgY2xlYXIgZW5vdWdoIGFzIGlzLg0KDQo+PiAiDQo+PiBJZiB0aGUgcGF0aCBiZXR3ZWVu IHRoZSBzZW5kZXIgYW5kIHRoZSByZWNlaXZlcnMgZXhoaWJpdHMgZWl0aGVyIG9mIHRoZXNlDQo+ PiBiZWhhdmlvdXJzIG9uZQ0KPj4gbmVlZHMgdG8gc3RvcCB1c2luZyBFQ04gaW1tZWRpYXRlbHkg dG8gcHJvdGVjdCBib3RoIHRoZSBuZXR3b3JrIGFuZA0KPj4gdGhlIGFwcGxpY2F0aW9uLg0KPj4g Ig0KPj4gW1Fpbl06IEhvdyBkb2VzIHNlbmRlciBvciByZWNlaXZlciBkZXRlY3RzIEVDTiBpcyBt aXN1c2VkPyBXaG8gaXMgdGhlDQo+PiAib25lIiBpbiB0aGlzIHNlbnRlbmNlPyBJZiBpdCBpcyBt aWRkbGVib3gsIHRoZSBtaWRkbGVib3ggc2hvdWxkIGFsc28NCj4+IHRlbGwgdGhlIHNlbmRlciBF Q04gaXMgbm90IHVzZWQuDQo+Pg0KPiBBcyBtZW50aW9uZWQgZWFybGllciBpbiB0aGUgc2VjdGlv biB0aGUgImJlaGF2aW91cnMiIHdpbGwgYmUgZGV0ZWN0ZWQgYnkgdGhlDQo+IGVuZC1zeXN0ZW1z LiBUaGUgJ29uZScgaXMgdGhlIHBhcnRpZXMgaW52b2x2ZWQgaW4gdGhlIGNvbm5lY3Rpb24gc2V0 dXAgLSB3aGljaA0KPiBjb3VsZCBpbiBjZXJ0YWluIGNhc2VzIGJlIGEgJ21pZGRsZWJveCcgLSBi dXQgdGhhdCBkb2Vzbid0IG5lZWQgdG8gYmUgZXhwbGljaXRseQ0KPiBjb3ZlcmVkIGhlcmUuDQo+ DQo+IFtRaW5dOiBJdCBpcyBzdGlsbCBub3QgY2xlYXIgdG8gbWUuSWYgZW5kIHN5c3RlbSBkZXRl Y3RzIHRob3NlIGJlaGF2aW9yIGFuZCBvbmUgaXMgdGhlIG1pZGRsZWJveCwNCj4gaG93IGVuZCBz eXN0ZW1zIHRoYXQgZGV0ZWN0cyB0aG9zZSBiZWhhdmlvciB0ZWxsc3RoZSBtaWRkbGVib3ggdGhh dCB0aG9zZSBiZWhhdmlybyBvY2N1ciwNCj4gdGhyb3VnaCBkZWRpY2F0ZWQgRUNOIGZlZWRiYWNr IG1lc3NhZ2Ugb3IgYW55IG90aGVyIG1lYW5zPyBvciB5b3UgYXNzdW1lIHRoZSBtaWRkbGVib3gN Cj4gY2FuIGJlIGEgcmVjZWl2ZXI/DQo+DQpUaGUgdGVybSAibWlkZGxlYm94IiBpcyByYXRoZXIg Z2VuZXJpYyBhbmQgY2FuIGFwcGx5IHRvIHdpZGUgcmFuZ2Ugb2YNCmVudGl0aWVzIGluY2x1ZGlu Zw0Kb25lcyB0aGF0IGltcGxlbWVudCBFQ04gZm9yIFJUUCAoZS5nLiBSVFAgbWl4ZXIvdHJhbnNs YXRvcnMpLiBUaGVzZQ0KZW50aXRpZXMgd291bGQgYmUNCmFibGUgdG8gZGV0ZWN0IGJhZCBiZWhh dmlvdXJzIGFuZCByZWFjdCB0byB0aGVtIGFjY29yZGluZyB0byB0aGlzDQpkb2N1bWVudCdzIHNw ZWNpZmljYXRpb24uDQpIb3dldmVyIG90aGVyIG1pZGRsZWJveGVzIHRoYXQgZG9uJ3QgYWN0dWFs bHkgdGFrZSBwYXJ0IGluIHRoZSBzZXNzaW9uDQptYXkgYWxzbyBiZSBhYmxlIGRldGVjdA0Kd2hh dCB0aGV5IHNlZSBhcyBiYWQgYmVoYXZpb3VyIGJ1dCB0aGVpciBvcGVyYXRpb24gaXMgb3V0IG9m IHNjb3BlIG9mDQp0aGlzIGRvY3VtZW50Lg0KDQo+DQo+PiBiZSBhYmxlIHRvIHJhcGlkbHkgbmVn b3RpYXRlIEVDTiBzdXBwb3J0IGZvciBzdWNoIGEgc2Vzc2lvbiwNCj4+IGJ1dCB0aGUgb3B0aW1p c2F0aW9uIGFib3ZlIGNhbiBmYWlsIGlmIHRoZXJlIGFyZQ0KPj4gaW1wbGVtZW50YXRpb25zIHRo YXQgdXNlIHRoZSBzYW1lIENOQU1FIGZvciBkaWZmZXJlbnQgcGFydHMgb2YNCj4+IGEgZGlzdHJp YnV0ZWQgaW1wbGVtZW50YXRpb24gdGhhdCBoYXZlIGRpZmZlcmVudCB0cmFuc3BvcnQNCj4+IGNo YXJhY3RlcmlzdGljcyAoZS5nLiwgaWYgYSBzaW5nbGUgbG9naWNhbCBlbmRwb2ludCBpcyBzcGxp dA0KPj4gYWNyb3NzIG11bHRpcGxlIGhvc3RzKS4NCj4+ICINCj4+IFtRaW5dOiBJIGRvbid0IGdl dCB0aGlzIGV4YW1wbGUgY2xlYXJseS4gYXJlIHlvdSBzYXlpbmcgd2hlbiB0d28gc3RyZWFtcw0K Pj4gd2l0aCB0aGUgc2FtZSBDTkFNRQ0KPj4gaXMgc2VudCBmcm9tIHRoZSBzYW1lIFJUUCBzZW5k ZXIsIHN1Y2ggYWJvdmUgb3B0aW1pemF0aW9uIGFwcGxpZXMuSG93ZXZlcg0KPj4gd2hlbiB0d28g c3RyZWFtcw0KPj4gd2l0aCB0aGUgc2FtZSBDTkFNRSBhcmUgc2VudCBmcm9tIHR3byBkaWZmZXJu dCBSVFAgZW50aXRpZXMsc3VjaCBhYm92ZQ0KPj4gb3B0aW1pemF0aW9uIGNhbiBub3QgYXBwbHku DQo+Pg0KPiBGb3IgdGhlIGZpcnN0IHBhcnQgeW91IGFyZSBjb3JyZWN0LCBidXQgdGhlIHRoZSB0 d28gc3RyZWFtIGNhc2Ugb25seQ0KPiB0YWxrcyBhYm91dCBhDQo+ICdsb2dpY2FsIGVuZHBvaW50 JyBpLmUuIGEgc2luZ2xlIFJUUCBlbmRwb2ludCB3aGljaCBpcyBzcGxpdCBvdmVyDQo+IG11bHRp cGxlIGhvc3RzLCBub3Qgc2VwYXJhdGUgUlRQIGVuZHBvaW50cy4NCj4NCj4gW1Fpbl06IEluIHRo aXMgY2FzZSwgQ05BTUUgaXMgbm90IGVub3VnaCB0byBpZGVudGlmeSBlYWNoIG9mIFJUUGVuZHBv aW50cy4NCj4gRnJvbSB0aGlzIHBlcnNwZWN0aXZlLCBJIGFncmVlLg0KPiBJcyB0aGF0IHdoYXQg eW91IGFyZSBzYXlpbmc/DQo+DQpZZXMuDQoNCj4NCj4+IDI1LiBTZWN0aW9uIDcuNC4xLDR0aCBw YXJhZ3JhcGgNCj4+ICINCj4+IGxvYWQgYmFsYW5jaW5nIGRldmljZXMgbWF5IGluIHdvcnN0IGNh c2UgcmVzdWx0IGluIHRoYXQgc29tZSBwYWNrZXRzIHRha2UgYQ0KPj4gZGlmZmVyZW50IG5ldHdv cmsgcGF0aCB0aGVuIHRoZSBvdGhlcnM7DQo+PiAiDQo+PiBbUWluXTogU2hvdWxkICJ0aGVuIiBp biB0aGlzIHNlbnRlbmNlIGJlICJ0aGFuIiA/DQo+Pg0KPiBOby4NCj4NCj4gW1Fpbl06IFdoeT8g VXNpbmcgImRpZmZlcmVudCBmcm9tIiBpbnN0ZWFkPw0KPg0KSSdtIHNvcnJ5IHlvdSdyZSBjb3Jy ZWN0IGhlcmUgKEkgaW5pdGlhbGx5IGxvb2tlZCBhdCB0aGUgd3JvbmcgJ3RoZW4nKS4NCg0KPj4g MjYuIFNlY3Rpb24gNy40LjIsIDR0aCBwYXJhZ3JhcGgNCj4+ICINCj4+IFRoZSByYXRlIG9mIHBh Y2tldCBkdXBsaWNhdGlvbiBpcyB0cmFja2VkLCBhbGxvd2luZyBvbmUgdG8gdGFrZSB0aGUNCj4+ IGR1cGxpY2F0aW9uIGludG8gYWNjb3VudC4gVGhlIHZhbHVlIG9mIHRoZSBFQ04gZmllbGQgZm9y IGR1cGxpY2F0ZXMNCj4+IHdpbGwgYWxzbyBiZSBjb3VudGVkIGFuZCB3aGVuIGNvbXBhcmluZyB0 aGUgZmlndXJlcyBvbmUgbmVlZHMgdG8gdGFrZQ0KPj4gIg0KPj4gW1Fpbl06IFdoYXQgYW5kIHdo ZXJlIGFyZSB0aGUgZmlndXJlcz8NCj4+DQo+IFRoZSAnZmlndXJlcycgcmVmZXJzIHRvIHRoZSB2 YWx1ZXMgb2YgdGhlIHZhcmlvdXMgY291bnRlcnMgb2YgRUNOIG1hcmtpbmdzLCBhcw0KPiBleHBs YWluZWQgZWFybGllciBpbiB0aGUgcGFyYWdyYXBoLg0KPg0KPiBbUWluXTogSSBtaXN1bmRlcnN0 b29kICJmaWd1cmVzIiBhcyAiY2hhcnRzIiBvciAiZHJhd2luZ3MiLCBJc24ndCB3b3J0aCBiZXR0 ZXIgd29yZGluZz8NCj4NCkkgY2FuIHVuZGVyc3RhbmQgdGhhdCBvbmUgbWF5IGNvbmZ1c2UgdGhl IG1lYW5pbmcgYnV0IEkgdGhpbmsgaXQgb2sgYXMgaXMuDQoNCj4+IDI3LlNlY3Rpb24gOC4yLDh0 aCBwYXJhZ3JhcGgNCj4+ICINCj4+IFdoZW4gcm91bmRpbmcgY291bnRlciB2YWx1ZXMgaW4gdGhl IHRyYW5zbGF0ZWQgUlRDUCBwYWNrZXQsIHRoZQ0KPj4gdHJhbnNsYXRvciBzaG91bGQgdHJ5IHRv IGVuc3VyZSB0aGF0IHRoZXkgc3VtIHRvIHRoZSBudW1iZXIgb2YgUlRQDQo+PiBwYWNrZXRzIGlu IHRoZSBwcmUtdHJhbnNsYXRpb24gc2VxdWVuY2UgbnVtYmVyIHNwYWNlIChudW1PcmlnKS4gVGhl DQo+PiB0cmFuc2xhdG9yIHNob3VsZCBhbHNvIHRyeSB0byBlbnN1cmUgdGhhdCBubyBub24temVy byBjb3VudGVyIGlzDQo+PiByb3VuZGVkIHRvIGEgemVybyB2YWx1ZSwgc2luY2UgdGhhdCB3aWxs IGxvc2UgaW5mb3JtYXRpb24gdGhhdCBhDQo+PiBwYXJ0aWN1bGFyIHR5cGUgb2YgZXZlbnQgaGFz IG9jY3VycmVkLiBJdCBpcyByZWNvZ25pc2VkIHRoYXQgaXQgbWF5DQo+PiBiZSBpbXBvc3NpYmxl IHRvIHNhdGlzZnkgYm90aCBvZiB0aGVzZSBjb25zdHJhaW50czsNCj4+ICINCj4+DQo+PiBbUWlu XTogV2hhdCdzIHRoZSBkaWZmaWN1bHR5IHRvIHNhdGlzZnkgYm90aCBjb25zdHJhaW50cywgd2h5 IG5vbi16ZXJvDQo+PiBjb3VudGVyIGNhbiBiZSByb3VuZGVkIGludG8gemVybz8gd2hhdCBraW5k IG9mIHJvdW5kIG1ldGhvZCBpcyB1c2VkPw0KPj4gY2FuIHlvdSBleHBsYWluIGEgbGl0dGxlIGJp dD8NCj4+DQo+IEJlY2F1c2UgdGhlIHRyYW5zbGF0b3IgYWN0dWFsbHkgYWx0ZXJzIHRoZSBwYWNr ZXQgc3RyZWFtIHRoZXJlIGlzIG5vdCBhbHdheXMNCj4gYSBjbGVhciBtYXBwaW5nIGJldHdlZW4g dGhlIHZhbHVlcyB0YWtlbiBmcm9tIHRoZSBvcmlnaW5hbCBwYWNrZXRzIHZzIHRoZQ0KPiB0cmFu c2xhdGVkIHBhY2tldHMuIEJ1dCBpZiBhIHBhcnRpY3VsYXIgZXZlbnQgaGFzIGJlZW4gcmVwb3J0 ZWQgaXQgaXMgYmVzdCB0bw0KPiByZXBvcnQgdGhhdCBldmVudCAoZS5nLiBFQ04tQ0UgbWFya2lu ZykgaGFzIG9jY3VycmVkIGluIHRoZSB0cmFuc2xhdGVkDQo+IHBhY2tldHMgLSBidXQgdGhleSBt YXkgbm90IGFsd2F5cyBhZGQgdXAgY29ycmVjdGx5IGlmIG9uZSB3YW50cyB0byBpbmRpY2F0ZQ0K PiB0aGF0IGEgbWFya2luZyBpcyBub3cgJ3NwcmVhZCcgb3ZlciBtb3JlIHRoYW4gb25lIHBhY2tl dCBpbiB0aGUgdHJhbnNsYXRlZA0KPiBzdHJlYW0uIFRoZSByb3VuZGluZyB1c2VkIG1lYW5zIHRo YXQgaXQgc2hvdWxkbid0IHJvdW5kIGRvd24gdG8gemVybyB1bmxlc3MNCj4gdGhlIHByZS10cmFu c2xhdGVkIHZhbHVlcyBhcmUgemVyby4NCj4NCj4gW1Fpbl06IFRoYW5rIGZvciB5b3VyIGNsYXJm aWNhdGlvbiwgSSBhbSBjbGVhciwgaXQgaXMgYmV0dGVyIHRvIHJlcGxhY2UNCj4gIg0KPiBUaGUg dHJhbnNsYXRvciBzaG91bGQgYWxzbyB0cnkgdG8gZW5zdXJlIHRoYXQgbm8gbm9uLXplcm8gY291 bnRlciBpcw0KPiAgcm91bmRlZCB0byBhIHplcm8gdmFsdWUNCj4gIg0KPiB3aXRoIHlvdXIgcHJv cG9zZWQgdGV4dA0KPiAiDQo+IFRoZSB0cmFuc2xhdG9yIHNob3VsZCBhbHNvIHRyeSB0byBlbnN1 cmUgdGhhdCBubyBub24temVybyBjb3VudGVyIGlzDQo+ICByb3VuZGVkIHRvIGEgemVybyB2YWx1 ZSAgdW5sZXNzIHRoZSBwcmUtdHJhbnNsYXRlZCB2YWx1ZXMgYXJlIHplcm8uDQo+ICINCj4gVGhh dCB3aWxsIGJlIG1vcmUgY2xlYXIgdG8gbWUuDQo+DQpXZSBjb3VsZCBhZGQgdGhhdCBjbGFyaWZp Y2F0aW9uLg0KDQpUaGFua3MgYWdhaW4sDQoNClBpZXJzLg0KDQo+IFRoYW5rcywNCj4NCj4gUGll cnMuDQo+DQo+PiBSZWdhcmRzIQ0KPj4gLVFpbg0KPj4NCj4+DQo+PiAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tDQo+PiBGcm9tOiBSb25pIEV2ZW4NCj4+IFRvOiBhdnRAaWV0Zi5vcmcNCj4+ IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDMwLCAyMDExIDg6MjkgUE0NCj4+IFN1YmplY3Q6IFtB VlRDT1JFXSBXR0xDIG9uIGRyYWZ0LWlldGYtYXZ0Y29yZS1lY24tZm9yLXJ0cC0wNA0KPj4NCj4+ IEhpLA0KPj4NCj4+IEkgd291bGQgbGlrZSB0byBzdGFydCBhIFdHTEMgb24NCj4+IGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0Y29yZS1lY24tZm9yLXJ0cC0wNCAsIEV4 cGxpY2l0DQo+PiBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBmb3IgUlRQIG92ZXIgVURQ Lg0KPj4NCj4+DQo+Pg0KPj4gVGhlIFdHTEMgd2lsbCBlbmQgb24gT2N0b2JlciAyMSwgMjAxMQ0K Pj4NCj4+DQo+Pg0KPj4gUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHNlbmQgY29tbWVudHMg dG8gdGhlIGxpc3QuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IFJvbmkgRXZlbg0KPj4NCj4+DQo+ Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+PiBhdnRAaWV0Zi5vcmcN Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+Pg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEF1ZGlvL1Zp ZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+PiBhdnRAaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+Pg0KPj4NCj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBdWRpby9WaWRlbyBUcmFu c3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0K From kevin.gross@avanw.com Thu Oct 20 06:49:01 2011 Return-Path: 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 33BD721F8BE8 for ; Thu, 20 Oct 2011 06:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 ZI1cCBU4EycF for ; Thu, 20 Oct 2011 06:49:00 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 3264921F8BB6 for ; Thu, 20 Oct 2011 06:49:00 -0700 (PDT) Received: (qmail 7391 invoked by uid 0); 20 Oct 2011 13:48:59 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy8.bluehost.com with SMTP; 20 Oct 2011 13:48:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=11/asARgg6Q+oudiu6xANZHtclbvqQFyZN4adYWiQGU=; b=YKT4KvPs7GfANajykrwWpSksA5KAyhRT94seu4l47D+nLVAXGBYxR3GmUS1mS17fuGFQWGfGq5JfB5WT1Qe5qeMsWT8VBYMvPwfluLcIOxK+ZF4gb8lZPydceD7rVIBc; Received: from mail-gx0-f172.google.com ([209.85.161.172]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RGszT-0003Re-69 for avt@ietf.org; Thu, 20 Oct 2011 07:48:59 -0600 Received: by ggnv1 with SMTP id v1so3367589ggn.31 for ; Thu, 20 Oct 2011 06:48:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.63.75 with SMTP id a11mr18464623fai.9.1319118537808; Thu, 20 Oct 2011 06:48:57 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Thu, 20 Oct 2011 06:48:57 -0700 (PDT) In-Reply-To: <4E9F1AD4.4020102@dcom.upv.es> References: <4E941250.2080500@dcom.upv.es> <4E9F1AD4.4020102@dcom.upv.es> Date: Thu, 20 Oct 2011 07:48:57 -0600 Message-ID: From: Kevin Gross To: fboronat@dcom.upv.es Content-Type: multipart/alternative; boundary=00151743f83cdcdb9e04afbb379d X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.161.172 authed with kevin.gross@avanw.com} Cc: avt@ietf.org Subject: Re: [AVTCORE] Possible Additional functionalities for draft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:49:01 -0000 --00151743f83cdcdb9e04afbb379d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My comments below marked with [kg]. 2011/10/19 Fernando Boronat Segu=ED > > 1. Since the sender and all receivers have an NTP time reference, it i= s > possible to measure propagation time directly. It is not necessary to > measure RTT and divide by two. > > RTT calculation was one of the alternatives we considered by using XR > with RRTR and DLRR blocks because with the use of XR with RRTR and DLRR > blocks we got the advantage that the SCs only have to send XR with DLRR > blocks as a response to an incoming XR with RRTR block and the packets we= re > already defined. > > Of course that we are interested in on-way delays, not in RTT but we woul= d > need to define new packets (or adapt the ones already defined in the I-D)= in > order to calculate one-way delays. Should we do it? or do you consider it= is > enough with calculating RTT and divide it by 2? > > One option using the packets already defined in the I-D to calculate > Source-to-SC delays could be the following: Before the beginning of the > media transmission, the source could start sending one (or several > consecutive) RTCP IDMS reports (defined in section 7 of the I-D) with all > the bits of the packet received RTP timestamp field set to 0 (no packet i= s > referenced) and the 64-bit NTP timestamp of its sending time in the 64 > 'Packet received NTP Timestamp' field (NTP sending time). SCs should > response to this packet with an XR with an IDMS Report Block (also define= d > in the section 6 of the I-D) including the 64-bit NTP timestamp of the > instant in which that packet was received (NTP reception time), also > including the packet received RTP timestamp field set to 0 (no packet is > referenced) and copying the middle 32-bits of the 64-bit NTP timestamp of > the original packet received from the source (in order to allow the sourc= e > identify the response with the original query). Once received an XR with = the > IDMS report block from an SC, the source could calculate the one-way > source-to-SC delay by subtracting both 64-bit NTP timestamps (NTP recepti= on > time- NTPsending time). > > [kg] I'm afraid I'm not fully familiar with all the existing XR functionality you reference. For now I will clarify and expand my previous comment: Under IDMS senders and receivers are required to have a common accurate real-time clock (NTP, IEEE 1588, GPS, etc.). The standard RTCP sender report contains a 64-bit real-time timestamp which indicates exactly when an RTP packet was sent. A receiver can determine one-way delivery dela= y of this packet by comparing that timestamp to the time that RTP packet was received according to his own version of the shared real-time clock. This same technique can be used to measure the one-way delay for any transmissio= n in either direction. > > 1. One way of achieving coarse sync without modification to the IDMS > proposal is to just start streaming with null media data. Once the MSA= S > receives IDMS XR reports from all receivers and distributes sync infor= mation > to receivers and the receivers have done whatever they need to do to g= et in > sync, the sender can be queued to start sending real data. > > We are not sure about how to implement streaming with null media data. D= o > you mean empty RTP packets? If so, those RTP packets would be very short > packets, so the propagation time would also be smaller than for RTP real > data packets. Also it would introduce higher traffic overhead than when > using our proposal, wouldn't it? > > [kg] By null data I mean a data stream of RTP packets that resembles the expected media stream in terms of bandwidth, packet size etc. but decodes t= o silence (audio) or black (video). Clearly it is easier to construct such a stream for some formats than it is for others. Do you really think this option would be more suitable than the use of RTCP > control messages? > [kg] I hope you appreciate that this option is simpler than your proposal. = I would also argue that this option is more reliable and accurate because it more directly measures the quantities of concern using the same IDMS mechanisms that will be used once the stream is up and running. Your proposal potentially has an advantage in quicker start-up time but I think similar startup speed is possible if we specify accelerated RTCP reporting at the onset of a new stream. --00151743f83cdcdb9e04afbb379d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My comments below marked with [kg].

2011/= 10/19 Fernando Boronat Segu=ED <fboronat@dcom.upv.es>
=20 =20 =20
=
  1. Since the sender and all receivers have an NTP time reference, it is possible to measure propagation time directly. It is not necessary to measure RTT and divide by two.
RTT calculation was one of the alternatives we considered by using XR with RRTR and DLRR blocks because with the use of XR with RRTR and DLRR blocks we got the advantage that the SCs only have to send XR with DLRR blocks as a response to an incoming XR with RRTR block and the packets were already defined.

Of course that we are interested in on-way delays, not in RTT but we would need to define new packets (or adapt the ones already defined in the I-D) in order to calculate one-way delays. Should we do it? or do you consider it is enough with calculating RTT and divide it by 2?

One option using the packets already defined in the I-D to calculate Source-to-SC delays could be the following: Before the beginning of the media transmission, the source could start sending one (or several consecutive) RTCP IDMS reports (defined in section 7 of the I-D) with all the bits of the packet received RTP timestamp field set to 0 (no packet is referenced) and the 64-bit NTP timestamp of its sending time in the 64 'Packet received NTP Timestamp' fiel= d (NTP sending time). SCs should response to this packet with an XR with an IDMS Report Block (also defined in the section 6 of the I-D) including the 64-bit NTP timestamp of the instant in which that packet was received (NTP reception time), also including the packet received RTP timestamp field set to 0 (no packet is referenced) and copying the middle 32-bits of the 64-bit NTP timestamp of the original packet received from the source (in order to allow the source identify the response with the original query). Once received an XR with the IDMS report block from an SC, the source could calculate the one-way source-to-SC delay by subtracting both 64-bit NTP timestamps (NTP reception time- NTPsending time).
=

[kg] I'm afraid I'= m not fully=A0familiar=A0with all the existing XR functionality you referen= ce. For now I will clarify and expand my previous comment: Under IDMS sende= rs and receivers are required to have a common accurate real-time clock (NT= P, IEEE 1588, GPS, etc.). The standard RTCP sender report contains a 64-bit= real-time timestamp which indicates exactly when an RTP packet was sent. A= receiver can determine one-way delivery delay of this packet by comparing = that timestamp to the time that RTP packet was received according to his ow= n version of the shared real-time clock. This same technique can be used to= measure the one-way delay for any transmission in either direction.
=A0
  1. One w= ay of=A0achieving=A0coarse sync without modification to the IDMS proposal is to just start streaming with null media data. Once the MSAS receives IDMS XR=A0reports=A0from all receivers and distributes sync information to receivers and the receivers have done whatever they need to do to get in sync, the sender can be queued to start sending real data.
=20 =20 =20 =20 =20 =20 =20 =20
We are not sure about how to implement streaming with null media data. Do you mean empty RTP packets? If so, those RTP packets would be very short packets, so the propagation time would also be smaller than for RTP real data packets. Also it would introduce higher traffic overhead than when using our proposal, wouldn't it?<= br>
[kg] By null data I mean a data stream of RT= P packets that resembles the expected media stream in terms of bandwidth, p= acket size etc. but decodes to silence (audio) or black (video). Clearly it= is easier to construct such a stream for some formats than it is for other= s.

Do you really think this option would be more suitable than t= he use of RTCP control messages?

[kg= ] I hope you appreciate that this option is simpler than your proposal. I w= ould also argue that this option is more reliable and=A0accurate=A0because = it more directly measures the quantities of concern using the same IDMS mec= hanisms that will be used once the stream is up and running. Your proposal = potentially has an advantage in quicker start-up time but I think similar s= tartup speed is possible if we specify accelerated RTCP reporting at the on= set of a new stream.
--00151743f83cdcdb9e04afbb379d-- From fboronat@dcom.upv.es Wed Oct 19 11:45:56 2011 Return-Path: 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 83B4621F88B7 for ; Wed, 19 Oct 2011 11:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 YTVOgG6oU9vv for ; Wed, 19 Oct 2011 11:45:50 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 23FBF21F8AEA for ; Wed, 19 Oct 2011 11:45:47 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p9JIjdW7005283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2011 20:45:39 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p9JIjdPl002870; Wed, 19 Oct 2011 20:45:39 +0200 Received: from [127.0.0.1] (fboronat2114.pc.upv.es [158.42.145.157]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id p9JIjcmu032311; Wed, 19 Oct 2011 20:45:38 +0200 Message-ID: <4E9F1AD4.4020102@dcom.upv.es> Date: Wed, 19 Oct 2011 20:45:40 +0200 From: =?ISO-8859-1?Q?Fernando_Boronat_Segu=ED?= Organization: UNIVERSIDAD =?ISO-8859-1?Q?POLIT=C9CNICA_DE_VALENCIA?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kevin Gross References: <4E941250.2080500@dcom.upv.es> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050702080407040601020609" X-Mailman-Approved-At: Thu, 20 Oct 2011 12:39:32 -0700 Cc: avt@ietf.org Subject: Re: [AVTCORE] Possible Additional functionalities for draft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fboronat@dcom.upv.es List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:45:56 -0000 This is a multi-part message in MIME format. --------------050702080407040601020609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Kevin, We try to answer to your comments below: > Welcome to the group. Thank you. It is a pleasure for us to be able to contribute with our comments to the AVTCORE list. > Here are some initial comments: > > 1. The sender and the MSAS are not necessarily co-located. You want > to measure propagation time from sender to SCs not from MSAS to SCs. > Yes, you're right. We want to measure network delays from the sender to the SCs. It was a miss-understanding. > > 1. Propagation time is often a function of packet size. Measuring > with small RTCP packets won't give you the same results as with > larger packets containing media. > We agree. The purpose of collecting network delays for RTCP packets is to ensure that the common initial playout (end-to-end) delay for all the SCs is larger than the maximum estimated network delay and large enough in order to guarantee that SCs have buffered a minimum amount of media units before beginning the playout process (to avoid buffer underflow situations). The method to calculate the Initial Playout Instant is out of the scope of the I-D and should take into consideration such issue. Suggestion about how to measure it taking into account that issue will be much appreciate. > 1. Since the sender and all receivers have an NTP time reference, it > is possible to measure propagation time directly. It is not > necessary to measure RTT and divide by two. > RTT calculation was one of the alternatives we considered by using XR with RRTR and DLRR blocks because with the use of XR with RRTR and DLRR blocks we got the advantage that the SCs only have to send XR with DLRR blocks as a response to an incoming XR with RRTR block and the packets were already defined. Of course that we are interested in on-way delays, not in RTT but we would need to define new packets (or adapt the ones already defined in the I-D) in order to calculate one-way delays. Should we do it? or do you consider it is enough with calculating RTT and divide it by 2? One option using the packets already defined in the I-D to calculate Source-to-SC delays could be the following: Before the beginning of the media transmission, the source could start sending one (or several consecutive) RTCP IDMS reports (defined in section 7 of the I-D) with all the bits of the packet received RTP timestamp field set to 0 (no packet is referenced) and the 64-bit NTP timestamp of its sending time in the 64 'Packet received NTP Timestamp' field (NTP sending time). SCs should response to this packet with an XR with an IDMS Report Block (also defined in the section 6 of the I-D) including the 64-bit NTP timestamp of the instant in which that packet was received (NTP reception time), also including the packet received RTP timestamp field set to 0 (no packet is referenced) and copying the middle 32-bits of the 64-bit NTP timestamp of the original packet received from the source (in order to allow the source identify the response with the original query). Once received an XR with the IDMS report block from an SC, the source could calculate the one-way source-to-SC delay by subtracting both 64-bit NTP timestamps (NTP reception time- NTPsending time). > 1. One way of achieving coarse sync without modification to the IDMS > proposal is to just start streaming with null media data. Once the > MSAS receives IDMS XR reports from all receivers and distributes > sync information to receivers and the receivers have done whatever > they need to do to get in sync, the sender can be queued to start > sending real data. > We are not sure about how to implement streaming with null media data. Do you mean empty RTP packets? If so, those RTP packets would be very short packets, so the propagation time would also be smaller than for RTP real data packets. Also it would introduce higher traffic overhead than when using our proposal, wouldn't it? Do you really think this option would be more suitable than the use of RTCP control messages? Thank You very much for your helpful comments. > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com , www.X192.org > > > > 2011/10/11 Fernando Boronat Seguí > > > Dear Group members, > > As this is our first mail to the list, we introduce ourselves. We > are Fernando Boronat and Mario Montagud, co-authors of the > Internet Draft (I-D) "RTCP for inter-destination media > synchronization" (draft-ietf-avtcore-idms-01.txt). > As the I-D was accepted as a WG document, any changes will have to > be approved by the AVTCORE group. So, we would like to know if you > consider appropriate to introduce some additional functionalities > to the proposed IDMS approach in the I-D. > > In many distributed applications it is required that all the > receivers start the playout of the media stream almost > simultaneously (we refer this as Coarse Sync) and, after that, all > of them play-out the media in a synchronous way (we refer this as > Fine Sync). Those processes are essential for acquiring IDMS. A > Global Initial Playout Instant for all the geographically > distributed receivers (SCs) in a media session could prevent from > an initial playout time discrepancy (asynchrony) at the beginning > of the playout of the media stream/s (if a fixed global initial > buffering delay is set) mainly due to the variable network delays > from the media server to each one of the SCs. > > Thus, we are thinking about including a new section in the I-D > about possible packets for Coarse Sync for both the initial > playout instant (at the begining of a media session) and the > initial instant at each stage in which the session can be divided > (we consider that a stage ends when no streams are transmitted > during a fixed interval (it could be defined depending on the > applications), and that the next stage starts when data is > transmitted again). > > This technique has been considered in some previous IDMS works > (see reference [Boronat09] in the I-D), but using proprietary > protocols. The methods we propose here are based on the use of > already defined and standard RTCP packets, which would avoid the > introduction of proprietary closed solutions. > > Regarding the Initial Playout Instant, we have primarily thought > about the use of already proposed RTCP XR packets (RFC 3611): > > 1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC > 3611) for measuring the delay between MSAS and SCs, allowing MSAS > to estimate the RTT for all the SCs, then calculate a common > initial playout instant and then communicate it to all SCs by > sending them an RTCP IDMS Packet (defined in the I-D). The RTCP > IDMS packet must include the RTP Timestamp of the first MU to be > sent by the source and its proper playout instant, which will be > common for all of them. > MSAS may estimate its round trip time (RTT) to the SCs by sending > them an RTCP XR with the Receiver Reference Time Report Block and > forcing (according to RFC 3611) them to reply by sending an RTCP > XR with a DLRR Report Block. Notice that both XR blocks are > defined in RFC 3611 to be used in the opposite way we propose. > > If this solution is not considered appropriate we could think > about another solution based on the packets already defined in the > I-D, but maybe we would need to change the format adding new field/s. > > 2. Once joined the session, if it is not started yet, all the SCs > could start sending RTCP XR with IDMS block (until they receive > the Initial Playout Instant indication, sent using the RTCP IDMS > Packet) as it is defined in the I-D, but including only the > essential timing information (e.g. the wallclock time at which the > packet is sent by the SC) to let the MSAS estimate the one-way > network delays (not round-trip as in the previous case) for each > SC (assuming symmetric delays as in TCP) and calculate the Initial > Playout Instant. For that purpose, some field of the RTCP XR IDMS > block should be used to indicate the XR IDMS block is carrying out > temporal information for Coarse Sync, and not for reporting about > arrival/playout timing of a specific RTP packet. > From the Initial Instant they will continue playing the streams > and sending the RTCP XR with IDMS complete block (as currently > defined in the I-D). It could be a possible solution. > > The process of the calculation of the optimum Initial Playout > Instant must take into consideration some factors such as the > maximum and minimum estimated delays, jitter values, expected > duration of the session, or probable clock deviations, in order to > allow enough buffered MUs to start the playout and to maintain it > continuously, thus avoiding underflow/overflow situations (playout > discontinuities), during the session. This process is out of the > scope of the ID. > > With the introduction of the Coarse Sync functionality, the IDMS > proposal can counteract the effect of the delay variability at the > beginning of the playout of the media stream/s in each one of the > stages in which a media session can be divided. > > We prefer the first method because there is no need to define new > IDMS control messages (or to include some fields to already > defined packets), but the use of already defined RTCP reports (RFC > 3611) can be adapted for that purpose. > > Moreover, with the use of the first method, SCs do not have to > send control messages once they join the session, which may > possibly result on inefficient control traffic overhead. They will > only have to send RTCP XR DLRR messages in response to a new > incoming RTRR message from the source, which is who really knows > the initial transmission time for the RTP media stream. Moreover, > the Initial Playout Instant can be sent to the receivers by using > the RTCP IDMS packet, already introduced in the I-D. > > Feedback will be much appreciated. > > Regards > ======================================================================== > Dr. Fernando Boronat Seguí > IEEE Senior Member > Profesor Titular / Lecturer > Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 > Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) > UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA > Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN > ======================================================================== > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Saludos/Regards ======================================================================== Dr. Fernando Boronat Seguí Profesor Titular / Lecturer Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN ======================================================================== --------------050702080407040601020609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Kevin,

We try to answer to your comments below:

 Welcome to the group.
Thank you. It is a pleasure for us to be able to contribute with our comments to the AVTCORE list.

Here are some initial comments:
  1. The sender and the MSAS are not necessarily co-located. You want to measure propagation time from sender to SCs not from MSAS to SCs.
Yes, you’re right. We want to measure network delays from the sender to the SCs. It was a miss-understanding.
  1. Propagation time is often a function of packet size. Measuring with small RTCP packets won't give you the same results as with larger packets containing media.
We agree. The purpose of collecting network delays for RTCP packets is to ensure that the common initial playout (end-to-end) delay for all the SCs is larger than the maximum estimated network delay and large enough in order to guarantee that SCs have buffered a minimum amount of media units before beginning the playout process (to avoid buffer underflow situations). The method to calculate the Initial Playout Instant is out of the scope of the I-D and should take into consideration such issue.

Suggestion about how to measure it taking into account that issue will be much appreciate.

  1. Since the sender and all receivers have an NTP time reference, it is possible to measure propagation time directly. It is not necessary to measure RTT and divide by two.
RTT calculation was one of the alternatives we considered by using XR with RRTR and DLRR blocks because with the use of XR with RRTR and DLRR blocks we got the advantage that the SCs only have to send XR with DLRR blocks as a response to an incoming XR with RRTR block and the packets were already defined.

Of course that we are interested in on-way delays, not in RTT but we would need to define new packets (or adapt the ones already defined in the I-D) in order to calculate one-way delays. Should we do it? or do you consider it is enough with calculating RTT and divide it by 2?

One option using the packets already defined in the I-D to calculate Source-to-SC delays could be the following: Before the beginning of the media transmission, the source could start sending one (or several consecutive) RTCP IDMS reports (defined in section 7 of the I-D) with all the bits of the packet received RTP timestamp field set to 0 (no packet is referenced) and the 64-bit NTP timestamp of its sending time in the 64 'Packet received NTP Timestamp' field (NTP sending time). SCs should response to this packet with an XR with an IDMS Report Block (also defined in the section 6 of the I-D) including the 64-bit NTP timestamp of the instant in which that packet was received (NTP reception time), also including the packet received RTP timestamp field set to 0 (no packet is referenced) and copying the middle 32-bits of the 64-bit NTP timestamp of the original packet received from the source (in order to allow the source identify the response with the original query). Once received an XR with the IDMS report block from an SC, the source could calculate the one-way source-to-SC delay by subtracting both 64-bit NTP timestamps (NTP reception time- NTPsending time).


  1. One way of achieving coarse sync without modification to the IDMS proposal is to just start streaming with null media data. Once the MSAS receives IDMS XR reports from all receivers and distributes sync information to receivers and the receivers have done whatever they need to do to get in sync, the sender can be queued to start sending real data.
We are not sure about how to implement streaming with null media data. Do you mean empty RTP packets? If so, those RTP packets would be very short packets, so the propagation time would also be smaller than for RTP real data packets. Also it would introduce higher traffic overhead than when using our proposal, wouldn't it?

Do you really think this option would be more suitable than the use of RTCP control messages?

Thank You very much for your helpful comments.
 
Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com, www.X192.org


2011/10/11 Fernando Boronat Seguí <fboronat@dcom.upv.es>
Dear Group members,

As this is our first mail to the list, we introduce ourselves. We are Fernando Boronat and Mario Montagud, co-authors of the Internet Draft (I-D) “RTCP for inter-destination media synchronization” (draft-ietf-avtcore-idms-01.txt).
As the I-D was accepted as a WG document, any changes will have to be approved by the AVTCORE group. So, we would like to know if you consider appropriate to introduce some additional functionalities to the proposed IDMS approach in the I-D.

In many distributed applications it is required that all the receivers start the playout of the media stream almost simultaneously (we refer this as Coarse Sync) and, after that, all of them play-out the media in a synchronous way (we refer this as Fine Sync). Those processes are essential for acquiring IDMS. A Global Initial Playout Instant for all the geographically distributed receivers (SCs) in a media session could prevent from an initial playout time discrepancy (asynchrony) at the beginning of the playout of the media stream/s (if a fixed global initial buffering delay is set) mainly due to the variable network delays from the media server to each one of the SCs.

Thus, we are thinking about including a new section in the I-D about possible packets for Coarse Sync for both the initial playout instant (at the begining of a media session) and the initial instant at each stage in which the session can be divided (we consider that a stage ends when no streams are transmitted during a fixed interval (it could be defined depending on the applications), and that the next stage starts when data is transmitted again).

This technique has been considered in some previous IDMS works (see reference [Boronat09] in the I-D), but using proprietary protocols. The methods we propose here are based on the use of already defined and standard RTCP packets, which would avoid the introduction of proprietary closed solutions.

Regarding the Initial Playout Instant, we have primarily thought about the use of already proposed RTCP XR packets (RFC 3611):

1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC 3611) for measuring the delay between MSAS and SCs, allowing MSAS to estimate the RTT for all the SCs, then calculate a common initial playout instant and then communicate it to all SCs by sending them an RTCP IDMS Packet (defined in the I-D). The RTCP IDMS packet must include the RTP Timestamp of the first MU to be sent by the source and its proper playout instant, which will be common for all of them.
MSAS may estimate its round trip time (RTT) to the SCs by sending them an RTCP XR with the Receiver Reference Time Report Block and forcing (according to RFC 3611) them to reply by sending an RTCP XR with a DLRR Report Block. Notice that both XR blocks are defined in RFC 3611 to be used in the opposite way we propose.

If this solution is not considered appropriate we could think about another solution based on the packets already defined in the I-D, but maybe we would need to change the format adding new field/s.

2. Once joined the session, if it is not started yet, all the SCs could start sending RTCP XR with IDMS block (until they receive the Initial Playout Instant indication, sent using the RTCP IDMS Packet) as it is defined in the I-D, but including only the essential timing information (e.g. the wallclock time at which the packet is sent by the SC) to let the MSAS estimate the one-way network delays (not round-trip as in the previous case) for each SC (assuming symmetric delays as in TCP) and calculate the Initial Playout Instant. For that purpose, some field of the RTCP XR IDMS block should be used to indicate the XR IDMS block is carrying out temporal information for Coarse Sync, and not for reporting about arrival/playout timing of a specific RTP packet.
From the Initial Instant they will continue playing the streams and sending the RTCP XR with IDMS complete block (as currently defined in the I-D). It could be a possible solution.

The process of the calculation of the optimum Initial Playout Instant must take into consideration some factors such as the maximum and minimum estimated delays, jitter values, expected duration of the session, or probable clock deviations, in order to allow enough buffered MUs to start the playout and to maintain it continuously, thus avoiding underflow/overflow situations (playout discontinuities), during the session. This process is out of the scope of the ID.

With the introduction of the Coarse Sync functionality, the IDMS proposal can counteract the effect of the delay variability at the beginning of the playout of the media stream/s in each one of the stages in which a media session can be divided.

We prefer the first method because there is no need to define new IDMS control messages (or to include some fields to already defined packets), but the use of already defined RTCP reports (RFC 3611) can be adapted for that purpose.

Moreover, with the use of the first method, SCs do not have to send control messages once they join the session, which may possibly result on inefficient control traffic overhead. They will only have to send RTCP XR DLRR messages in response to a new incoming RTRR message from the source, which is who really knows the initial transmission time for the RTP media stream. Moreover, the Initial Playout Instant can be sent to the receivers by using the RTCP IDMS packet, already introduced in the I-D.

Feedback will be much appreciated.
Regards
========================================================================
Dr. Fernando Boronat Seguí
IEEE Senior Member
Profesor Titular / Lecturer	
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt



-- 
Saludos/Regards
========================================================================
Dr. Fernando Boronat Seguí
Profesor Titular / Lecturer	
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================
--------------050702080407040601020609-- From fboronat@dcom.upv.es Wed Oct 19 11:51:05 2011 Return-Path: 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 8572A21F8B3E for ; Wed, 19 Oct 2011 11:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, MIME_8BIT_HEADER=0.3] 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 fI1AZ0o5SYBt for ; Wed, 19 Oct 2011 11:50:58 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2067921F8A69 for ; Wed, 19 Oct 2011 11:50:51 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p9JIoexd006117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2011 20:50:40 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p9JIodg5004640; Wed, 19 Oct 2011 20:50:40 +0200 Received: from [127.0.0.1] (fboronat2114.pc.upv.es [158.42.145.157]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id p9JIochT001567; Wed, 19 Oct 2011 20:50:38 +0200 Message-ID: <4E9F1C00.7090007@dcom.upv.es> Date: Wed, 19 Oct 2011 20:50:40 +0200 From: =?ISO-8859-1?Q?Fernando_Boronat_Segu=ED?= Organization: UNIVERSIDAD =?ISO-8859-1?Q?POLIT=C9CNICA_DE_VALENCIA?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <4E941250.2080500@dcom.upv.es> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000001050903070800020805" X-Mailman-Approved-At: Thu, 20 Oct 2011 12:39:32 -0700 Subject: Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fboronat@dcom.upv.es List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:51:05 -0000 This is a multi-part message in MIME format. --------------000001050903070800020805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Qin, Thank You very much for your comments. I try to answer them below. > > ----- Original Message ----- > *From:* Fernando Boronat Seguí > *To:* avt@ietf.org ; > xrblock-request@ietf.org > *Sent:* Tuesday, October 11, 2011 5:54 PM > *Subject:* [AVTCORE] Possible Additional functionalities > fordraft-brandenburg-avt-rtcp-for-idms > > Dear Group members, > > As this is our first mail to the list, we introduce ourselves. We > are Fernando Boronat and Mario Montagud, co-authors of the > Internet Draft (I-D) "RTCP for inter-destination media > synchronization" (draft-ietf-avtcore-idms-01.txt). > As the I-D was accepted as a WG document, any changes will have to > be approved by the AVTCORE group. So, we would like to know if you > consider appropriate to introduce some additional functionalities > to the proposed IDMS approach in the I-D. > > In many distributed applications it is required that all the > receivers start the playout of the media stream almost > simultaneously (we refer this as Coarse Sync) and, after that, all > of them play-out the media in a synchronous way (we refer this as > Fine Sync). Those processes are essential for acquiring IDMS. A > Global Initial Playout Instant for all the geographically > distributed receivers (SCs) in a media session could prevent from > an initial playout time discrepancy (asynchrony) at the beginning > of the playout of the media stream/s (if a fixed global initial > buffering delay is set) mainly due to the variable network delays > from the media server to each one of the SCs. > > > > Thus, we are thinking about including a new section in the I-D > about possible packets for Coarse Sync for both the initial > playout instant (at the begining of a media session) and the > initial instant at each stage in which the session can be divided > (we consider that a stage ends when no streams are transmitted > during a fixed interval (it could be defined depending on the > applications), and that the next stage starts when data is > transmitted again). > [Qin]:Your proposal looks like to me is to add Fine Sync > functionality to IDMS draft in the middle of session, however it > is not clear to me the exact use case (is it periodical > playout)and what's the real difference between Coarse Sync and > Fine Sync in terms of RTCP signaling? are you saying the initial > at each stage is calculated more accurate than initial playout > instant? > [Answer] The goal of our proposal in our last mail was not related with fine synchronization. Fine Sync technique is used to maintain the playout processes between distributed SCs in a synchronized manner during the evolution of the session (or during each stages of the session, if it is divided into different phases). During the session (or its phases), SCs report on their arrival/playout timing, and the MSAS can send to them playout setting instructions in order to maintain fine sync, using RTCP IDMS packets (defined in the I-D), if an out of sync situation is detected. The coarse sync technique we here propose to be included in our I-D would mainly aim to prevent from initial playout time discrepancies at the beginning of the playout of the media stream/s in a multimedia session (or at the beginning of each one of the stages in which a session can be divided), due to the delay variability during the session from the sender to each group of separated SCs (Sync Clients). It can be achieved by distributing to the SCs a Global Initial Playout Instant, carried out in a RTCP IDMS packet type for IDMS (already defined in our I-D), prior the transmission of the initial RTP data packets of each stage. This way, we can ensure concurrently sincronized playout points at the starting point of each stage, despite the variable network delays from the sender to the SCs > This technique has been considered in some previous IDMS works > (see reference [Boronat09] in the I-D), but using proprietary > protocols. The methods we propose here are based on the use of > already defined and standard RTCP packets, which would avoid the > introduction of proprietary closed solutions. > > Regarding the Initial Playout Instant, we have primarily thought > about the use of already proposed RTCP XR packets (RFC 3611): > > 1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC > 3611) for measuring the delay between MSAS and SCs, allowing MSAS > to estimate the RTT for all the SCs, then calculate a common > initial playout instant and then communicate it to all SCs by > sending them an RTCP IDMS Packet (defined in the I-D). The RTCP > IDMS packet must include the RTP Timestamp of the first MU to be > sent by the source and its proper playout instant, which will be > common for all of them. > MSAS may estimate its round trip time (RTT) to the SCs by sending > them an RTCP XR with the Receiver Reference Time Report Block and > forcing (according to RFC 3611) them to reply by sending an RTCP > XR with a DLRR Report Block. Notice that both XR blocks are > defined in RFC 3611 to be used in the opposite way we propose. > [Qin]: Why not use round trip time computation method defined in > the figure 2 of RFC3550, are you saying it is not allowed to use > SR/RR reports in IDMS case. > [Answer] To the best of our knowledge, prior the transmission of RTP data packets, neither RTCP SR nor RR are sent, aren't they?. So, the delay from the sender to the SCs could not be calculated using those packets at least at the starting point of the session (maybe at the initial points of each stage, but we are not sure). If, at the beginning of each stage, the session has been stopped during a long period and, therefore, the network conditions (e.g., delays to each SCs) have significantly varied we will need to monitor them. > > If this solution is not considered appropriate we could think > about another solution based on the packets already defined in the > I-D, but maybe we would need to change the format adding new field/s. > > 2. Once joined the session, if it is not started yet, all the SCs > could start sending RTCP XR with IDMS block (until they receive > the Initial Playout Instant indication, sent using the RTCP IDMS > Packet) as it is defined in the I-D, but including only the > essential timing information (e.g. the wallclock time at which the > packet is sent by the SC) to let the MSAS estimate the one-way > network delays (not round-trip as in the previous case) for each > SC (assuming symmetric delays as in TCP) and calculate the Initial > Playout Instant. For that purpose, some field of the RTCP XR IDMS > block should be used to indicate the XR IDMS block is carrying out > temporal information for Coarse Sync, and not for reporting about > arrival/playout timing of a specific RTP packet. > From the Initial Instant they will continue playing the streams > and sending the RTCP XR with IDMS complete block (as currently > defined in the I-D). It could be a possible solution. > [Qin]: You can use Delay metric report defined in > draft-ietf-avt-rtcp-xr-delay-02 to directly get one-way network > delays. Also maximum and minimum network delays can be obtained > from this XR report. > Thank you for the suggestion. In our response to Kevin Gross we propose an alternative to calculate one-way delays from source to SCs using only the packets defined in the I-D. Please, tell us your opinion about it. We thought about the use of RTCP XR RRTR and DLRR (already defined in an RFC 3611 and not about packets defined in a ¿old/expired? draft -2009-) because these XR blocks are already standardized and could be useful for our Coarse Sync purposes. Moreover, in such a way, SCs must only send RTCP XR with DLRR blocks as a response to an incoming RTCP XR with RRTR block, sent by the source, which is who really knows the initial transmission instant (thus, unnecessary RTCP packet would not be sent). Then, the Initial Playout Instant would be calculated by taking into consideration the estimated network delays, in order to allow all the SCs to have buffered sufficient RTP data packets to smooth out the effect of network jitter, possible playout rate deviations or sporadic congestion cases, thus maintaining a continuous playout process during the session. Do you think that the use of the packets defined in the ¿old/expired? draft should be used to this purpose? In that case we would need to modify their format to make them more appropriate for our needs. > The process of the calculation of the optimum Initial Playout > Instant must take into consideration some factors such as the > maximum and minimum estimated delays, jitter values, expected > duration of the session, or probable clock deviations, in order to > allow enough buffered MUs to start the playout and to maintain it > continuously, thus avoiding underflow/overflow situations (playout > discontinuities), during the session. This process is out of the > scope of the ID. > [Qin] I think you can rely on draft-ietf-avt-rtcp-xr-meas-identity > to know expected duration of the session. > you may rely on draft-ietf-xrblock-rtcp-xr-pdv-00 to get jitter > values. > But XRBLock is not the right place to seek for the measurement > method, which is defined somewhere else, e.g., in other RFC like > RFC3550, other WGs, or other SDOs. > [Answer] Thank you for your helpful suggestion. In the I-D we only want to propose the packets to be used for our purpose. The calculation methods, as we mentioned above, are out of the scope of the ID. Thank You again for your comments More feedback about it from the AVTCore group members will be much appreciated. > > With the introduction of the Coarse Sync functionality, the IDMS > proposal can counteract the effect of the delay variability at the > beginning of the playout of the media stream/s in each one of the > stages in which a media session can be divided. > > We prefer the first method because there is no need to define new > IDMS control messages (or to include some fields to already > defined packets), but the use of already defined RTCP reports (RFC > 3611) can be adapted for that purpose. > > Moreover, with the use of the first method, SCs do not have to > send control messages once they join the session, which may > possibly result on inefficient control traffic overhead. They will > only have to send RTCP XR DLRR messages in response to a new > incoming RTRR message from the source, which is who really knows > the initial transmission time for the RTP media stream. Moreover, > the Initial Playout Instant can be sent to the receivers by using > the RTCP IDMS packet, already introduced in the I-D. > > Feedback will be much appreciated. > > Regards > ======================================================================== > Dr. Fernando Boronat Seguí > IEEE Senior Member > Profesor Titular / Lecturer > Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 > Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) > UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA > Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN > ======================================================================== > > ------------------------------------------------------------------------ > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Saludos/Regards ======================================================================== Dr. Fernando Boronat Seguí Profesor Titular / Lecturer Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN ======================================================================== --------------000001050903070800020805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Qin,

Thank You very much for your comments. I try to answer them below.
----- Original Message -----
Sent: Tuesday, October 11, 2011 5:54 PM
Subject: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms

Dear Group members,

As this is our first mail to the list, we introduce ourselves. We are Fernando Boronat and Mario Montagud, co-authors of the Internet Draft (I-D) “RTCP for inter-destination media synchronization” (draft-ietf-avtcore-idms-01.txt).
As the I-D was accepted as a WG document, any changes will have to be approved by the AVTCORE group. So, we would like to know if you consider appropriate to introduce some additional functionalities to the proposed IDMS approach in the I-D.

In many distributed applications it is required that all the receivers start the playout of the media stream almost simultaneously (we refer this as Coarse Sync) and, after that, all of them play-out the media in a synchronous way (we refer this as Fine Sync). Those processes are essential for acquiring IDMS. A Global Initial Playout Instant for all the geographically distributed receivers (SCs) in a media session could prevent from an initial playout time discrepancy (asynchrony) at the beginning of the playout of the media stream/s (if a fixed global initial buffering delay is set) mainly due to the variable network delays from the media server to each one of the SCs.


Thus, we are thinking about including a new section in the I-D about possible packets for Coarse Sync for both the initial playout instant (at the begining of a media session) and the initial instant at each stage in which the session can be divided (we consider that a stage ends when no streams are transmitted during a fixed interval (it could be defined depending on the applications), and that the next stage starts when data is transmitted again).
 
[Qin]:Your proposal looks like to me is to add Fine Sync functionality to IDMS draft in the middle of session, however it is not clear to me the exact use case (is it periodical playout)and what's the real difference between Coarse Sync and Fine Sync in terms of RTCP signaling? are you saying the initial at each stage is calculated more accurate than initial playout instant?
[Answer] The goal of our proposal in our last mail was not related with fine synchronization. Fine Sync technique is used to maintain the playout processes between distributed SCs in a synchronized manner during the evolution of the session (or during each stages of the session, if it is divided into different phases).  During the session (or its phases), SCs report on their arrival/playout timing, and the MSAS can send to them playout setting instructions in order to maintain fine sync, using RTCP IDMS packets (defined in the I-D), if an out of sync situation is detected.

The coarse sync technique we here propose to be included in our I-D would mainly aim to prevent from initial playout time discrepancies at the beginning of the playout of the media stream/s in a multimedia session (or at the beginning of each one of the stages in which a session can be divided), due to the delay variability during the session from the sender to each group of separated SCs (Sync Clients).

It can be achieved by distributing to the SCs a Global Initial Playout Instant, carried out in a RTCP IDMS packet type for IDMS (already defined in our I-D), prior the transmission of the initial RTP data packets of each stage. This way, we can ensure concurrently sincronized playout points at the starting point of each stage, despite the variable network delays from the sender to the SCs

This technique has been considered in some previous IDMS works (see reference [Boronat09] in the I-D), but using proprietary protocols. The methods we propose here are based on the use of already defined and standard RTCP packets, which would avoid the introduction of proprietary closed solutions.

Regarding the Initial Playout Instant, we have primarily thought about the use of already proposed RTCP XR packets (RFC 3611):

1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC 3611) for measuring the delay between MSAS and SCs, allowing MSAS to estimate the RTT for all the SCs, then calculate a common initial playout instant and then communicate it to all SCs by sending them an RTCP IDMS Packet (defined in the I-D). The RTCP IDMS packet must include the RTP Timestamp of the first MU to be sent by the source and its proper playout instant, which will be common for all of them.
MSAS may estimate its round trip time (RTT) to the SCs by sending them an RTCP XR with the Receiver Reference Time Report Block and forcing (according to RFC 3611) them to reply by sending an RTCP XR with a DLRR Report Block. Notice that both XR blocks are defined in RFC 3611 to be used in the opposite way we propose.
 
[Qin]: Why not use round trip time computation method defined in the figure 2 of RFC3550, are you saying it is not allowed to use SR/RR reports in IDMS case.
[Answer] To the best of our knowledge, prior the transmission of RTP data packets, neither RTCP SR nor RR are sent, aren't they?. So, the delay from the sender to the SCs could not be calculated using those packets at least at the starting point of the session (maybe at the initial points of each stage, but we are not sure). If, at the beginning of each stage, the session has been stopped during a long period and, therefore, the network conditions (e.g., delays to each SCs) have significantly varied we will need to monitor them.


If this solution is not considered appropriate we could think about another solution based on the packets already defined in the I-D, but maybe we would need to change the format adding new field/s.

2. Once joined the session, if it is not started yet, all the SCs could start sending RTCP XR with IDMS block (until they receive the Initial Playout Instant indication, sent using the RTCP IDMS Packet) as it is defined in the I-D, but including only the essential timing information (e.g. the wallclock time at which the packet is sent by the SC) to let the MSAS estimate the one-way network delays (not round-trip as in the previous case) for each SC (assuming symmetric delays as in TCP) and calculate the Initial Playout Instant. For that purpose, some field of the RTCP XR IDMS block should be used to indicate the XR IDMS block is carrying out temporal information for Coarse Sync, and not for reporting about arrival/playout timing of a specific RTP packet.
From the Initial Instant they will continue playing the streams and sending the RTCP XR with IDMS complete block (as currently defined in the I-D). It could be a possible solution.
 
[Qin]: You can use Delay metric report defined in draft-ietf-avt-rtcp-xr-delay-02 to directly get one-way network delays. Also maximum and minimum network delays can be obtained from this XR report.
Thank you for the suggestion.

In our response to Kevin Gross we propose an alternative to calculate one-way delays from source to SCs using only the packets defined in the I-D. Please, tell us your opinion about it.

We thought about the use of RTCP XR RRTR and DLRR (already defined in an RFC 3611 and not about packets defined in a ¿old/expired? draft -2009-) because these XR blocks are already standardized and could be useful for our Coarse Sync purposes. Moreover, in such a way, SCs must only send RTCP XR with DLRR blocks as a response to an incoming RTCP XR with RRTR block, sent by the source, which is who really knows the initial transmission instant (thus, unnecessary RTCP packet would not be sent).
Then, the Initial Playout Instant would be calculated by taking into consideration the estimated network delays, in order to allow all the SCs to have buffered sufficient RTP data packets to smooth out the effect of network jitter, possible playout rate deviations or sporadic congestion cases, thus maintaining a continuous playout process during the session.

Do you think that the use of the packets defined in the ¿old/expired? draft should be used to this purpose? In that case we would need to modify their format to make them more appropriate for our needs.

The process of the calculation of the optimum Initial Playout Instant must take into consideration some factors such as the maximum and minimum estimated delays, jitter values, expected duration of the session, or probable clock deviations, in order to allow enough buffered MUs to start the playout and to maintain it continuously, thus avoiding underflow/overflow situations (playout discontinuities), during the session. This process is out of the scope of the ID.
 
[Qin] I think you can rely on draft-ietf-avt-rtcp-xr-meas-identity to know expected duration of the session.
you may rely on draft-ietf-xrblock-rtcp-xr-pdv-00 to get jitter values.
But XRBLock is not the right place to seek for the measurement method, which is defined somewhere else, e.g., in other RFC like RFC3550, other WGs, or other SDOs.
[Answer] Thank you for your helpful suggestion. In the I-D we only want to propose the packets to be used for our purpose. The calculation methods, as we mentioned above, are out of the scope of the ID.

Thank You again for your comments

More feedback about it from the AVTCore group members will be much appreciated.


With the introduction of the Coarse Sync functionality, the IDMS proposal can counteract the effect of the delay variability at the beginning of the playout of the media stream/s in each one of the stages in which a media session can be divided.

We prefer the first method because there is no need to define new IDMS control messages (or to include some fields to already defined packets), but the use of already defined RTCP reports (RFC 3611) can be adapted for that purpose.

Moreover, with the use of the first method, SCs do not have to send control messages once they join the session, which may possibly result on inefficient control traffic overhead. They will only have to send RTCP XR DLRR messages in response to a new incoming RTRR message from the source, which is who really knows the initial transmission time for the RTP media stream. Moreover, the Initial Playout Instant can be sent to the receivers by using the RTCP IDMS packet, already introduced in the I-D.

Feedback will be much appreciated.
Regards
========================================================================
Dr. Fernando Boronat Seguí
IEEE Senior Member
Profesor Titular / Lecturer	
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

-- 
Saludos/Regards
========================================================================
Dr. Fernando Boronat Seguí
Profesor Titular / Lecturer	
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================
--------------000001050903070800020805-- From fboronat@dcom.upv.es Wed Oct 19 11:56:45 2011 Return-Path: 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 8A3BA21F8BA9 for ; Wed, 19 Oct 2011 11:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3] 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 yQ1KSu48IohC for ; Wed, 19 Oct 2011 11:56:44 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id E07DC21F8BA0 for ; Wed, 19 Oct 2011 11:56:43 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p9JIud63007118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Oct 2011 20:56:39 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p9JIudY8007022 for ; Wed, 19 Oct 2011 20:56:39 +0200 Received: from [127.0.0.1] (fboronat2114.pc.upv.es [158.42.145.157]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id p9JIud0V003485 for ; Wed, 19 Oct 2011 20:56:39 +0200 Message-ID: <4E9F1D69.2060703@dcom.upv.es> Date: Wed, 19 Oct 2011 20:56:41 +0200 From: =?ISO-8859-1?Q?Fernando_Boronat_Segu=ED?= Organization: UNIVERSIDAD =?ISO-8859-1?Q?POLIT=C9CNICA_DE_VALENCIA?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: avt@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020001070206040305010304" X-Mailman-Approved-At: Thu, 20 Oct 2011 12:39:32 -0700 Subject: Re: [AVTCORE] Possible Additional functionalities for draft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fboronat@dcom.upv.es List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:56:45 -0000 This is a multi-part message in MIME format. --------------020001070206040305010304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Magnus, Yes, you are right. That is our purpose. What do you think about our proposal? Any suggestion will be much appreciated. Thank you for your response. El 19/10/2011 16:41, avt-request@ietf.org escribió: > Date: Wed, 19 Oct 2011 11:15:40 +0200 > From: Magnus Westerlund > To: avt@ietf.org > Subject: Re: [AVTCORE] Possible Additional functionalities for > draft-brandenburg-avt-rtcp-for-idms > Message-ID:<4E9E953C.507@ericsson.com> > Content-Type: text/plain; charset="windows-1252" > > Hi, > > If I understand the main issue you have is to determine the set of > transmission delays from a given media source to its population of > receivers so that an appropriate playout time can be selected by the > media source prior to actually having sent any media? > > Cheers > > Magnus > > On 2011-10-11 15:37, Fernando Boronat Segu? wrote: >> Dear Group members, >> >> As this is our first mail to the list, we introduce ourselves. We are >> Fernando Boronat and Mario Montagud, co-authors of the Internet Draft >> (I-D) ?RTCP for inter-destination media synchronization? >> (draft-ietf-avtcore-idms-01.txt). >> As the I-D was accepted as a WG document, any changes will have to be >> approved by the AVTCORE group. So, we would like to know if you consider >> appropriate to introduce some additional functionalities to the proposed >> IDMS approach in the I-D. >> >> In many distributed applications it is required that all the receivers >> start the playout of the media stream almost simultaneously (we refer >> this as Coarse Sync) and, after that, all of them play-out the media in >> a synchronous way (we refer this as Fine Sync). Those processes are >> essential for acquiring IDMS. A Global Initial Playout Instant for all >> the geographically distributed receivers (SCs) in a media session could >> prevent from an initial playout time discrepancy (asynchrony) at the >> beginning of the playout of the media stream/s (if a fixed global >> initial buffering delay is set) mainly due to the variable network >> delays from the media server to each one of the SCs. >> >> Thus, we are thinking about including a new section in the I-D about >> possible packets for Coarse Sync for both the initial playout instant >> (at the begining of a media session) and the initial instant at each >> stage in which the session can be divided (we consider that a stage ends >> when no streams are transmitted during a fixed interval (it could be >> defined depending on the applications), and that the next stage starts >> when data is transmitted again). >> >> This technique has been considered in some previous IDMS works (see >> reference [Boronat09] in the I-D), but using proprietary protocols. The >> methods we propose here are based on the use of already defined and >> standard RTCP packets, which would avoid the introduction of proprietary >> closed solutions. >> >> Regarding the Initial Playout Instant, we have primarily thought about >> the use of already proposed RTCP XR packets (RFC 3611): >> >> 1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC 3611) >> for measuring the delay between MSAS and SCs, allowing MSAS to estimate >> the RTT for all the SCs, then calculate a common initial playout instant >> and then communicate it to all SCs by sending them an RTCP IDMS Packet >> (defined in the I-D). The RTCP IDMS packet must include the RTP >> Timestamp of the first MU to be sent by the source and its proper >> playout instant, which will be common for all of them. >> MSAS may estimate its round trip time (RTT) to the SCs by sending them >> an RTCP XR with the Receiver Reference Time Report Block and forcing >> (according to RFC 3611) them to reply by sending an RTCP XR with a DLRR >> Report Block. Notice that both XR blocks are defined in RFC 3611 to be >> used in the opposite way we propose. >> >> If this solution is not considered appropriate we could think about >> another solution based on the packets already defined in the I-D, but >> maybe we would need to change the format adding new field/s. >> >> 2. Once joined the session, if it is not started yet, all the SCs could >> start sending RTCP XR with IDMS block (until they receive the Initial >> Playout Instant indication, sent using the RTCP IDMS Packet) as it is >> defined in the I-D, but including only the essential timing information >> (e.g. the wallclock time at which the packet is sent by the SC) to let >> the MSAS estimate the one-way network delays (not round-trip as in the >> previous case) for each SC (assuming symmetric delays as in TCP) and >> calculate the Initial Playout Instant. For that purpose, some field of >> the RTCP XR IDMS block should be used to indicate the XR IDMS block is >> carrying out temporal information for Coarse Sync, and not for reporting >> about arrival/playout timing of a specific RTP packet. >> From the Initial Instant they will continue playing the streams and >> sending the RTCP XR with IDMS complete block (as currently defined in >> the I-D). It could be a possible solution. >> >> The process of the calculation of the optimum Initial Playout Instant >> must take into consideration some factors such as the maximum and >> minimum estimated delays, jitter values, expected duration of the >> session, or probable clock deviations, in order to allow enough buffered >> MUs to start the playout and to maintain it continuously, thus avoiding >> underflow/overflow situations (playout discontinuities), during the >> session. This process is out of the scope of the ID. >> >> With the introduction of the Coarse Sync functionality, the IDMS >> proposal can counteract the effect of the delay variability at the >> beginning of the playout of the media stream/s in each one of the stages >> in which a media session can be divided. >> >> We prefer the first method because there is no need to define new IDMS >> control messages (or to include some fields to already defined packets), >> but the use of already defined RTCP reports (RFC 3611) can be adapted >> for that purpose. >> >> Moreover, with the use of the first method, SCs do not have to send >> control messages once they join the session, which may possibly result >> on inefficient control traffic overhead. They will only have to send >> RTCP XR DLRR messages in response to a new incoming RTRR message from >> the source, which is who really knows the initial transmission time for >> the RTP media stream. Moreover, the Initial Playout Instant can be sent >> to the receivers by using the RTCP IDMS packet, already introduced in >> the I-D. >> >> Feedback will be much appreciated. >> >> Regards >> ======================================================================== >> Dr. Fernando Boronat Segu? >> IEEE Senior Member >> Profesor Titular / Lecturer >> Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 >> Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) >> UNIVERSIDAD POLIT?CNICA DE VALENCIA-CAMPUS DE GANDIA >> Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN >> ======================================================================== >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > -- Saludos/Regards ======================================================================== Dr. Fernando Boronat Seguí Profesor Titular / Lecturer Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN ======================================================================== --------------020001070206040305010304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Magnus,

Yes, you are right. That is our purpose.

What do you think about our proposal? Any suggestion will be much appreciated.

Thank you for your response.


El 19/10/2011 16:41, avt-request@ietf.org escribió: 
Date: Wed, 19 Oct 2011 11:15:40 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: avt@ietf.org
Subject: Re: [AVTCORE] Possible Additional functionalities for
	draft-brandenburg-avt-rtcp-for-idms
Message-ID: <4E9E953C.507@ericsson.com>
Content-Type: text/plain; charset="windows-1252"

Hi,

If I understand the main issue you have is to determine the set of
transmission delays from a given media source to its population of
receivers so that an appropriate playout time can be selected by the
media source prior to actually having sent any media?

Cheers

Magnus

On 2011-10-11 15:37, Fernando Boronat Segu? wrote:

Dear Group members,

As this is our first mail to the list, we introduce ourselves. We are 
Fernando Boronat and Mario Montagud, co-authors of the Internet Draft 
(I-D) ?RTCP for inter-destination media synchronization? 
(draft-ietf-avtcore-idms-01.txt).
As the I-D was accepted as a WG document, any changes will have to be 
approved by the AVTCORE group. So, we would like to know if you consider 
appropriate to introduce some additional functionalities to the proposed 
IDMS approach in the I-D.

In many distributed applications it is required that all the receivers 
start the playout of the media stream almost simultaneously (we refer 
this as Coarse Sync) and, after that, all of them play-out the media in 
a synchronous way (we refer this as Fine Sync). Those processes are 
essential for acquiring IDMS. A Global Initial Playout Instant for all 
the geographically distributed receivers (SCs) in a media session could 
prevent from an initial playout time discrepancy (asynchrony) at the 
beginning of the playout of the media stream/s (if a fixed global 
initial buffering delay is set) mainly due to the variable network 
delays from the media server to each one of the SCs.

Thus, we are thinking about including a new section in the I-D about 
possible packets for Coarse Sync for both the initial playout instant 
(at the begining of a media session) and the initial instant at each 
stage in which the session can be divided (we consider that a stage ends 
when no streams are transmitted during a fixed interval (it could be 
defined depending on the applications), and that the next stage starts 
when data is transmitted again).

This technique has been considered in some previous IDMS works (see 
reference [Boronat09] in the I-D), but using proprietary protocols. The 
methods we propose here are based on the use of already defined and 
standard RTCP packets, which would avoid the introduction of proprietary 
closed solutions.

Regarding the Initial Playout Instant, we have primarily thought about 
the use of already proposed RTCP XR packets (RFC 3611):

1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC 3611) 
for measuring the delay between MSAS and SCs, allowing MSAS to estimate 
the RTT for all the SCs, then calculate a common initial playout instant 
and then communicate it to all SCs by sending them an RTCP IDMS Packet 
(defined in the I-D). The RTCP IDMS packet must include the RTP 
Timestamp of the first MU to be sent by the source and its proper 
playout instant, which will be common for all of them.
MSAS may estimate its round trip time (RTT) to the SCs by sending them 
an RTCP XR with the Receiver Reference Time Report Block and forcing 
(according to RFC 3611) them to reply by sending an RTCP XR with a DLRR 
Report Block. Notice that both XR blocks are defined in RFC 3611 to be 
used in the opposite way we propose.

If this solution is not considered appropriate we could think about 
another solution based on the packets already defined in the I-D, but 
maybe we would need to change the format adding new field/s.

2. Once joined the session, if it is not started yet, all the SCs could 
start sending RTCP XR with IDMS block (until they receive the Initial 
Playout Instant indication, sent using the RTCP IDMS Packet) as it is 
defined in the I-D, but including only the essential timing information 
(e.g. the wallclock time at which the packet is sent by the SC) to let 
the MSAS estimate the one-way network delays (not round-trip as in the 
previous case) for each SC (assuming symmetric delays as in TCP) and 
calculate the Initial Playout Instant. For that purpose, some field of 
the RTCP XR IDMS block should be used to indicate the XR IDMS block is 
carrying out temporal information for Coarse Sync, and not for reporting 
about arrival/playout timing of a specific RTP packet.
 From the Initial Instant they will continue playing the streams and 
sending the RTCP XR with IDMS complete block (as currently defined in 
the I-D). It could be a possible solution.

The process of the calculation of the optimum Initial Playout Instant 
must take into consideration some factors such as the maximum and 
minimum estimated delays, jitter values, expected duration of the 
session, or probable clock deviations, in order to allow enough buffered 
MUs to start the playout and to maintain it continuously, thus avoiding 
underflow/overflow situations (playout discontinuities), during the 
session. This process is out of the scope of the ID.

With the introduction of the Coarse Sync functionality, the IDMS 
proposal can counteract the effect of the delay variability at the 
beginning of the playout of the media stream/s in each one of the stages 
in which a media session can be divided.

We prefer the first method because there is no need to define new IDMS 
control messages (or to include some fields to already defined packets), 
but the use of already defined RTCP reports (RFC 3611) can be adapted 
for that purpose.

Moreover, with the use of the first method, SCs do not have to send 
control messages once they join the session, which may possibly result 
on inefficient control traffic overhead. They will only have to send 
RTCP XR DLRR messages in response to a new incoming RTRR message from 
the source, which is who really knows the initial transmission time for 
the RTP media stream. Moreover, the Initial Playout Instant can be sent 
to the receivers by using the RTCP IDMS packet, already introduced in 
the I-D.

Feedback will be much appreciated.

Regards
========================================================================
Dr. Fernando Boronat Segu?
IEEE Senior Member
Profesor Titular / Lecturer
Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLIT?CNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt





-- 
Saludos/Regards
========================================================================
Dr. Fernando Boronat Seguí
Profesor Titular / Lecturer	
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================
--------------020001070206040305010304-- From kevin.gross@comcast.net Wed Oct 19 20:00:03 2011 Return-Path: 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 80D1011E80D1 for ; Wed, 19 Oct 2011 20:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 ag1+Tk-lzXgk for ; Wed, 19 Oct 2011 20:00:02 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id F1E5B11E80C2 for ; Wed, 19 Oct 2011 20:00:01 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta06.westchester.pa.mail.comcast.net with comcast id mqyN1h0011YDfWL56r02da; Thu, 20 Oct 2011 03:00:02 +0000 Received: from mail-ey0-f172.google.com ([209.85.215.172]) by omta20.westchester.pa.mail.comcast.net with comcast id mr011h00l3jky9M3gr02KW; Thu, 20 Oct 2011 03:00:02 +0000 Received: by eyg24 with SMTP id 24so2501884eyg.31 for ; Wed, 19 Oct 2011 19:59:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.57.139 with SMTP id c11mr15171760fah.24.1319079599282; Wed, 19 Oct 2011 19:59:59 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Wed, 19 Oct 2011 19:59:59 -0700 (PDT) Date: Wed, 19 Oct 2011 20:59:59 -0600 Message-ID: From: Kevin Gross To: IETF AVTCore WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 20 Oct 2011 12:39:32 -0700 Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 03:14:23 -0000 Part of my reason for bringing these use cases to the attention of the group relates to a yet unresolved comment I made against the IDMS draft. The draft proposes 64-bit timestamps for arrival times but only 32-bit timestamps for presentation times. A 32-bit NTP timestamp has a 15 microsecond precision. Presentation time synchronization with these timestamps would seem not to clearly meet the requirements of a couple of these use cases. Improving the protocol to support 64-bit timestamps throughout seems to be the straightforward solution. With this change, all timestamps would have the same precision and would have a precision comparable to their reference clocks. The problem with this is that our IDMS work is based on ETSI TISPAN standard TS 183 063. Efforts have been made in the draft to maintain compatibility with this standard. Changing the packet format to accommodate 64-bit timestamps will unravel those efforts. If ETSI compatibility is important, we will have to live with 15 microsecond precision and possibly suggest clever tricks to make the most of it. Which way do we want to go here? On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross wro= te: > The requirement for the stereo case is specified differently than the > others. The 10 microsecond figure there applies to _changes in latency_, = not > static difference in latency described in all the other cases. Tolerance = for > static differences for the stereo case are probably on the order of 1 > millisecond. The first-order effect of static latency differences is to m= ove > one of the speakers =96 just depends on how fussy you are about real vs. > effective speaker placement. > > > > The 10 microsecond figure is conservative (I=92ve heard anecdotal claims = of 1 > microseconds sensitivity) and derives from our ability to accurately loca= te > sounds based (in part) on comparison of arrival times at each ear. The 10 > microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is. > Here=92s a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/HAP.= html > (see Localisation of Sound Sources section) > > > > Throughout, I=92ve tried to use what I consider reasonable and verifiable > requirements figures. Some will always seem to argue that they need bette= r > performance. > > > > Kevin > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Tuesday, August 16, 2011 9:07 AM > To: IETF AVTCore WG > Subject: Re: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > Mr. Gross, > > The timing assertion for Networked stereo loudspeakers is much tighter th= at > I would have expected. Placement of stereo speakers within a foot is a > normal rule of thumb for the casual listener =96 and that =A0is about 1.1= ms > delta at room temperature. The =91 golden ears=92 do have ability to dete= ct > small differences especially with high attack waveforms, but I would like= to > see the study that showed this small time difference. Can you please prov= ide > a cite? > > And I wonder if the system requirement should be based on the smallest kn= own > delta, unless there is no implementation complexity added to convey the > suggested resolution. > > > > > > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone=A0 202 429 5418 > Fax=A0 202 775 4981 > www.nab.org > Advocacy =A0Education=A0 Innovation > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kev= in > Gross > Sent: Monday, August 15, 2011 11:48 PM > To: 'IETF AVTCore WG' > Subject: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > In reviewing the IDMS draft I had volunteered to contribute additional us= e > cases. Ray Brandenberg suggested that I post them here. > > > > Kevin Gross > > AVA Networks > > Networked stereo loudspeakers > > Because of our ability to localize sound based on inter-aural time > differences, in a stereo listening situation, we are very sensitive to > changes in latency between the two speakers. These changes are perceived = as > a shift in or instability of the =93sound stage=94 during critical listen= ing. > These effects are readily noticeable with shifts of 10 microseconds or > smaller. If the individual speakers in a stereo listening setup operate f= rom > independent network interfaces any changing difference in latency between > the two speakers greater than 10 microseconds will be detrimental to the > listening experience. > > Conferencing sound reinforcement system > > A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms, > boardrooms, classrooms (especially those supporting distance learning) an= d > other such venues. Each participant using such a system has a microphone = and > a speaker. There may also be other speakers to provide reinforcement for > non-speaking participants such as in an audience area or jury box. Each > microphone/speaker pair is individually connected to a network and transm= its > digital audio to the other devices through the network and receives digit= al > audio to be reproduced through the speaker over the network. There may be= a > central appliance which receives, prioritizes and mixes the microphone > signals. In some systems an individual mix is created for each speaker su= ch > that a speaker=92s own voice does not come out from his speaker or from t= hose > immediately surrounding him. > > The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels amplifie= d. > Meeting this objective helps insure that natural person-to-person > communication is retained. To this end, it is desirable that the sound > through the system and from the speakers arrive 5 to 30 milliseconds afte= r > the the sound arriving through the air from the person speaking. Delays i= n > this range invoke the Haas effect which allows listeners to locate the > person speaking based on the sound arriving through the air while the sou= nd > reinforcement system provides the additional gain required to achieve > desired intelligibility. It is also desirable for the sound to come out o= f > nearby speakers at within 5 milliseconds as longer differential delays wi= ll > be perceived as reverberation or echo. > > Video wall > > A video wall consists of multiple computer monitors, video projectors, or > television sets tiled together contiguously or overlapped in order to for= m > one large screen.# Each of the screens reproduces a portion of the larger > picture. In some implementations, each screen may be individually connect= ed > to the network and receive its portion of the overall image from a > network-connected video server or video scaler. Screens are refreshed at = 60 > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh i= s > not synchronized, the effect of multiple screens acting as one is broken. > > Phased array transducers > > Phased array and wave field synthesis techniques are increasingly used in > audio applications. These techniques work by sending or receiving slightl= y > different versions of a signal in a spacial sampling arrangement to produ= ce > or record spacial and directional sound fields. The individual transducer= s > in these applications can be extremely sensitive to differential latency. > Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise rati= o. > These microphones are also able to report the location of the speaker for > purposes of automatically aiming a video camera at them. > > Concert sound systems called line arrays allow technicians control over t= he > amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventing > sound from reaching the roof and back wall of the performance space, the > amount of reflected sound heard by the audience is reduced and the listen= ing > experience is improved. > > In these systems, accuracy in locating or emitting sound is related to > differential latency through basic trigonometry. In these applications, > microseconds of differential latency can translate to degrees of > uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired. > > From bill.wu@huawei.com Thu Oct 20 18:31:14 2011 Return-Path: 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 E5E2A11E807F for ; Thu, 20 Oct 2011 18:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 Xe46h85F3Qe5 for ; Thu, 20 Oct 2011 18:31:14 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id AD45F21F8672 for ; Thu, 20 Oct 2011 18:31:13 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE009JH6VXUK@szxga05-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 09:31:09 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00CV66VWRW@szxga05-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 09:31:09 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEP14751; Fri, 21 Oct 2011 09:31:07 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 09:31:00 +0800 Received: from w53375q (10.138.41.130) by szxeml402-hub.china.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 09:30:42 +0800 Date: Fri, 21 Oct 2011 09:30:41 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Kevin Gross , fboronat@dcom.upv.es Message-id: <6097318C062643BD853DF04B85BE7C65@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_Fg0+DUcjBp+eCvpLrIh6hA)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4E941250.2080500@dcom.upv.es> <4E9F1AD4.4020102@dcom.upv.es> Cc: avt@ietf.org Subject: Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 01:31:15 -0000 --Boundary_(ID_Fg0+DUcjBp+eCvpLrIh6hA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGksDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEtldmluIEdyb3Nz IA0KICBUbzogZmJvcm9uYXRAZGNvbS51cHYuZXMgDQogIENjOiBhdnRAaWV0Zi5vcmcgDQogIFNl bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIwLCAyMDExIDk6NDggUE0NCiAgU3ViamVjdDogUmU6IFtB VlRDT1JFXSBQb3NzaWJsZSBBZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdGllcyBmb3JkcmFmdC1icmFu ZGVuYnVyZy1hdnQtcnRjcC1mb3ItaWRtcw0KDQoNCiAgTXkgY29tbWVudHMgYmVsb3cgbWFya2Vk IHdpdGggW2tnXS4NCg0KDQogIDIwMTEvMTAvMTkgRmVybmFuZG8gQm9yb25hdCBTZWd17SA8ZmJv cm9uYXRAZGNvbS51cHYuZXM+DQoNCiAgICAgICAgMS4uIFNpbmNlIHRoZSBzZW5kZXIgYW5kIGFs bCByZWNlaXZlcnMgaGF2ZSBhbiBOVFAgdGltZSByZWZlcmVuY2UsIGl0IGlzIHBvc3NpYmxlIHRv IG1lYXN1cmUgcHJvcGFnYXRpb24gdGltZSBkaXJlY3RseS4gSXQgaXMgbm90IG5lY2Vzc2FyeSB0 byBtZWFzdXJlIFJUVCBhbmQgZGl2aWRlIGJ5IHR3by4gDQogICAgUlRUIGNhbGN1bGF0aW9uIHdh cyBvbmUgb2YgdGhlIGFsdGVybmF0aXZlcyB3ZSBjb25zaWRlcmVkIGJ5IHVzaW5nIFhSIHdpdGgg UlJUUiBhbmQgRExSUiBibG9ja3MgYmVjYXVzZSB3aXRoIHRoZSB1c2Ugb2YgWFIgd2l0aCBSUlRS IGFuZCBETFJSIGJsb2NrcyB3ZSBnb3QgdGhlIGFkdmFudGFnZSB0aGF0IHRoZSBTQ3Mgb25seSBo YXZlIHRvIHNlbmQgWFIgd2l0aCBETFJSIGJsb2NrcyBhcyBhIHJlc3BvbnNlIHRvIGFuIGluY29t aW5nIFhSIHdpdGggUlJUUiBibG9jayBhbmQgdGhlIHBhY2tldHMgd2VyZSBhbHJlYWR5IGRlZmlu ZWQuDQoNCiAgICBPZiBjb3Vyc2UgdGhhdCB3ZSBhcmUgaW50ZXJlc3RlZCBpbiBvbi13YXkgZGVs YXlzLCBub3QgaW4gUlRUIGJ1dCB3ZSB3b3VsZCBuZWVkIHRvIGRlZmluZSBuZXcgcGFja2V0cyAo b3IgYWRhcHQgdGhlIG9uZXMgYWxyZWFkeSBkZWZpbmVkIGluIHRoZSBJLUQpIGluIG9yZGVyIHRv IGNhbGN1bGF0ZSBvbmUtd2F5IGRlbGF5cy4gU2hvdWxkIHdlIGRvIGl0PyBvciBkbyB5b3UgY29u c2lkZXIgaXQgaXMgZW5vdWdoIHdpdGggY2FsY3VsYXRpbmcgUlRUIGFuZCBkaXZpZGUgaXQgYnkg Mj8gDQoNCiAgICBPbmUgb3B0aW9uIHVzaW5nIHRoZSBwYWNrZXRzIGFscmVhZHkgZGVmaW5lZCBp biB0aGUgSS1EIHRvIGNhbGN1bGF0ZSBTb3VyY2UtdG8tU0MgZGVsYXlzIGNvdWxkIGJlIHRoZSBm b2xsb3dpbmc6IEJlZm9yZSB0aGUgYmVnaW5uaW5nIG9mIHRoZSBtZWRpYSB0cmFuc21pc3Npb24s IHRoZSBzb3VyY2UgY291bGQgc3RhcnQgc2VuZGluZyBvbmUgKG9yIHNldmVyYWwgY29uc2VjdXRp dmUpIFJUQ1AgSURNUyByZXBvcnRzIChkZWZpbmVkIGluIHNlY3Rpb24gNyBvZiB0aGUgSS1EKSB3 aXRoIGFsbCB0aGUgYml0cyBvZiB0aGUgcGFja2V0IHJlY2VpdmVkIFJUUCB0aW1lc3RhbXAgZmll bGQgc2V0IHRvIDAgKG5vIHBhY2tldCBpcyByZWZlcmVuY2VkKSBhbmQgdGhlIDY0LWJpdCBOVFAg dGltZXN0YW1wIG9mIGl0cyBzZW5kaW5nIHRpbWUgaW4gdGhlIDY0ICdQYWNrZXQgcmVjZWl2ZWQg TlRQIFRpbWVzdGFtcCcgZmllbGQgKE5UUCBzZW5kaW5nIHRpbWUpLiBTQ3Mgc2hvdWxkIHJlc3Bv bnNlIHRvIHRoaXMgcGFja2V0IHdpdGggYW4gWFIgd2l0aCBhbiBJRE1TIFJlcG9ydCBCbG9jayAo YWxzbyBkZWZpbmVkIGluIHRoZSBzZWN0aW9uIDYgb2YgdGhlIEktRCkgaW5jbHVkaW5nIHRoZSA2 NC1iaXQgTlRQIHRpbWVzdGFtcCBvZiB0aGUgaW5zdGFudCBpbiB3aGljaCB0aGF0IHBhY2tldCB3 YXMgcmVjZWl2ZWQgKE5UUCByZWNlcHRpb24gdGltZSksIGFsc28gaW5jbHVkaW5nIHRoZSBwYWNr ZXQgcmVjZWl2ZWQgUlRQIHRpbWVzdGFtcCBmaWVsZCBzZXQgdG8gMCAobm8gcGFja2V0IGlzIHJl ZmVyZW5jZWQpIGFuZCBjb3B5aW5nIHRoZSBtaWRkbGUgMzItYml0cyBvZiB0aGUgNjQtYml0IE5U UCB0aW1lc3RhbXAgb2YgdGhlIG9yaWdpbmFsIHBhY2tldCByZWNlaXZlZCBmcm9tIHRoZSBzb3Vy Y2UgKGluIG9yZGVyIHRvIGFsbG93IHRoZSBzb3VyY2UgaWRlbnRpZnkgdGhlIHJlc3BvbnNlIHdp dGggdGhlIG9yaWdpbmFsIHF1ZXJ5KS4gT25jZSByZWNlaXZlZCBhbiBYUiB3aXRoIHRoZSBJRE1T IHJlcG9ydCBibG9jayBmcm9tIGFuIFNDLCB0aGUgc291cmNlIGNvdWxkIGNhbGN1bGF0ZSB0aGUg b25lLXdheSBzb3VyY2UtdG8tU0MgZGVsYXkgYnkgc3VidHJhY3RpbmcgYm90aCA2NC1iaXQgTlRQ IHRpbWVzdGFtcHMgKE5UUCByZWNlcHRpb24gdGltZS0gTlRQc2VuZGluZyB0aW1lKS4NCg0KDQoN Cg0KICBba2ddIEknbSBhZnJhaWQgSSdtIG5vdCBmdWxseSBmYW1pbGlhciB3aXRoIGFsbCB0aGUg ZXhpc3RpbmcgWFIgZnVuY3Rpb25hbGl0eSB5b3UgcmVmZXJlbmNlLiBGb3Igbm93IEkgd2lsbCBj bGFyaWZ5IGFuZCBleHBhbmQgbXkgcHJldmlvdXMgY29tbWVudDogVW5kZXIgSURNUyBzZW5kZXJz IGFuZCByZWNlaXZlcnMgYXJlIHJlcXVpcmVkIHRvIGhhdmUgYSBjb21tb24gYWNjdXJhdGUgcmVh bC10aW1lIGNsb2NrIChOVFAsIElFRUUgMTU4OCwgR1BTLCBldGMuKS4gVGhlIHN0YW5kYXJkIFJU Q1Agc2VuZGVyIHJlcG9ydCBjb250YWlucyBhIDY0LWJpdCByZWFsLXRpbWUgdGltZXN0YW1wIHdo aWNoIGluZGljYXRlcyBleGFjdGx5IHdoZW4gYW4gUlRQIHBhY2tldCB3YXMgc2VudC4gQSByZWNl aXZlciBjYW4gZGV0ZXJtaW5lIG9uZS13YXkgZGVsaXZlcnkgZGVsYXkgb2YgdGhpcyBwYWNrZXQg YnkgY29tcGFyaW5nIHRoYXQgdGltZXN0YW1wIHRvIHRoZSB0aW1lIHRoYXQgUlRQIHBhY2tldCB3 YXMgcmVjZWl2ZWQgYWNjb3JkaW5nIHRvIGhpcyBvd24gdmVyc2lvbiBvZiB0aGUgc2hhcmVkIHJl YWwtdGltZSBjbG9jay4gVGhpcyBzYW1lIHRlY2huaXF1ZSBjYW4gYmUgdXNlZCB0byBtZWFzdXJl IHRoZSBvbmUtd2F5IGRlbGF5IGZvciBhbnkgdHJhbnNtaXNzaW9uIGluIGVpdGhlciBkaXJlY3Rp b24uDQoNCiAgW1Fpbl06IEkgdGVuZCB0byBhZ3JlZSB3aXRoIEtldmluJ3MgcHJvcHNhbC4gQnV0 IEkgYW0gbm90IGdvaW5nIHRvIGp1ZGUgaWYgS2V2aW4ncyBpcyBiZXR0ZXIgdGhhbiBGZXJuYW5k bydzLiBBY3R1YWxseSBiZXNpZGVzIHRoZSBvcHRpb24gcHJvcG9zZWQgYnkgRmVybmFuZG8sIFJG QzM2MTEgcHJvdmlkZSBhbm90aGVyIHNpbWlsYXIgd2F5IGFzIGJvdGggeW91ciBwcm9wb3NhbHMg dG8gY2FsY3VhbHRlIG9uZSB3YXkgZGVsYXkuIFRoYXQncyBQYWNrZXQgUmVjZWlwdCBUaW1lcyBS ZXBvcnQgQmxvY2sgZGVmaW5lZCBpbiB0aGUgc2VjdGlvbiA0LjMgb2YgUkZDMzYxMS4gWW91IG1h eSBsb29rIGF0IHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNC4zLCBpdCBzYWlkOg0K ICAiDQogICAgIFBhY2tldCByZWNlaXB0IHRpbWVzIGFyZSBleHByZXNzZWQgaW4gdGhlIHNhbWUg dW5pdHMgYXMgaW4gdGhlIFJUUA0KICAgICB0aW1lc3RhbXBzIG9mIGRhdGEgcGFja2V0cy4gIFRo aXMgaXMgc28gdGhhdCwgZm9yIGVhY2ggcGFja2V0LCBvbmUNCiAgICAgY2FuIGVzdGFibGlzaCBi b3RoIHRoZSBzZW5kIHRpbWUgYW5kIHRoZSByZWNlaXB0IHRpbWUgaW4gY29tcGFyYWJsZQ0KICAg ICB0ZXJtcy4gIE5vdGUsIGhvd2V2ZXIsIHRoYXQgYXMgYW4gUlRQIHNlbmRlciBvcmRpbmFyaWx5 IGluaXRpYWxpemVzDQogICAgIGl0cyB0aW1lIHRvIGEgdmFsdWUgY2hvc2VuIGF0IHJhbmRvbSwg dGhlcmUgY2FuIGJlIG5vIGV4cGVjdGF0aW9uDQogICAgIHRoYXQgcmVwb3J0ZWQgc2VuZCBhbmQg cmVjZWlwdCB0aW1lcyB3aWxsIGRpZmZlciBieSBhbiBhbW91bnQgZXF1YWwNCiAgICAgdG8gdGhl IG9uZS13YXkgZGVsYXkgYmV0d2VlbiBzZW5kZXIgYW5kIHJlY2VpdmVyLiAgVGhlIHJlcG9ydGVk IHRpbWVzDQogICAgIGNhbiBub25ldGhlbGVzcyBiZSB1c2VmdWwgZm9yIHRoZSBwdXJwb3NlcyBt ZW50aW9uZWQgYWJvdmUuDQoNCiAgIg0KICBUaGF0J3MgdG8gc2F5IHRoaXMgWFIgQmxvY2sgY2Fu IGJlIHVzZWQgdG8gY2FsY3VsYXRlIG9uZSB3YXkgZGVsYXkuIA0K --Boundary_(ID_Fg0+DUcjBp+eCvpLrIh6hA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTEyMCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+SGksPC9ESVY+DQo8QkxPQ0tRVU9URSAN CnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4 OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4 Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1 OyYjMjAzMDc7OyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJv bTo8L0I+IA0KICA8QSB0aXRsZT1rZXZpbi5ncm9zc0BhdmFudy5jb20gaHJlZj0ibWFpbHRvOmtl dmluLmdyb3NzQGF2YW53LmNvbSI+S2V2aW4gDQogIEdyb3NzPC9BPiA8L0RJVj4NCiAgPERJViBz dHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9ZmJv cm9uYXRAZGNvbS51cHYuZXMgDQogIGhyZWY9Im1haWx0bzpmYm9yb25hdEBkY29tLnVwdi5lcyI+ ZmJvcm9uYXRAZGNvbS51cHYuZXM8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg JiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1hdnRAaWV0Zi5vcmcgDQogIGhy ZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4gVGh1cnNkYXks IE9jdG9iZXIgMjAsIDIwMTEgOTo0OCANClBNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlw dCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUmU6IFtBVlRDT1JFXSBQb3NzaWJs ZSBBZGRpdGlvbmFsIA0KICBmdW5jdGlvbmFsaXRpZXMgZm9yZHJhZnQtYnJhbmRlbmJ1cmctYXZ0 LXJ0Y3AtZm9yLWlkbXM8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+TXkgY29tbWVudHMgYmVsb3cg bWFya2VkIHdpdGggW2tnXS48QlI+PEJSPg0KICA8RElWIGNsYXNzPWdtYWlsX3F1b3RlPjIwMTEv MTAvMTkgRmVybmFuZG8gQm9yb25hdCBTZWd17SA8U1BBTiBkaXI9bHRyPiZsdDs8QSANCiAgaHJl Zj0ibWFpbHRvOmZib3JvbmF0QGRjb20udXB2LmVzIj5mYm9yb25hdEBkY29tLnVwdi5lczwvQT4m Z3Q7PC9TUEFOPjxCUj4NCiAgPEJMT0NLUVVPVEUgDQogIHN0eWxlPSJCT1JERVItTEVGVDogI2Nj YyAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4 IiANCiAgY2xhc3M9Z21haWxfcXVvdGU+DQogICAgPERJViB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9y PSIjRkZGRkZGIj4NCiAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4NCiAgICAgIDxESVY+DQog ICAgICA8T0w+DQogICAgICAgIDxMST5TaW5jZSB0aGUgc2VuZGVyIGFuZCBhbGwgcmVjZWl2ZXJz IGhhdmUgYW4gTlRQIHRpbWUgcmVmZXJlbmNlLCBpdCBpcyANCiAgICAgICAgcG9zc2libGUgdG8g bWVhc3VyZSBwcm9wYWdhdGlvbiB0aW1lIGRpcmVjdGx5LiBJdCBpcyBub3QgbmVjZXNzYXJ5IHRv IA0KICAgICAgICBtZWFzdXJlIFJUVCBhbmQgZGl2aWRlIGJ5IHR3by4gPC9MST48L09MPjwvRElW PjwvQkxPQ0tRVU9URT5SVFQgY2FsY3VsYXRpb24gDQogICAgd2FzIG9uZSBvZiB0aGUgYWx0ZXJu YXRpdmVzIHdlIGNvbnNpZGVyZWQgYnkgdXNpbmcgWFIgd2l0aCBSUlRSIGFuZCBETFJSIA0KICAg IGJsb2NrcyBiZWNhdXNlIHdpdGggdGhlIHVzZSBvZiBYUiB3aXRoIFJSVFIgYW5kIERMUlIgYmxv Y2tzIHdlIGdvdCB0aGUgDQogICAgYWR2YW50YWdlIHRoYXQgdGhlIFNDcyBvbmx5IGhhdmUgdG8g c2VuZCBYUiB3aXRoIERMUlIgYmxvY2tzIGFzIGEgcmVzcG9uc2UgDQogICAgdG8gYW4gaW5jb21p bmcgWFIgd2l0aCBSUlRSIGJsb2NrIGFuZCB0aGUgcGFja2V0cyB3ZXJlIGFscmVhZHkgDQogICAg ZGVmaW5lZC48QlI+PEJSPk9mIGNvdXJzZSB0aGF0IHdlIGFyZSBpbnRlcmVzdGVkIGluIG9uLXdh eSBkZWxheXMsIG5vdCBpbiANCiAgICBSVFQgYnV0IHdlIHdvdWxkIG5lZWQgdG8gZGVmaW5lIG5l dyBwYWNrZXRzIChvciBhZGFwdCB0aGUgb25lcyBhbHJlYWR5IA0KICAgIGRlZmluZWQgaW4gdGhl IEktRCkgaW4gb3JkZXIgdG8gY2FsY3VsYXRlIG9uZS13YXkgZGVsYXlzLiBTaG91bGQgd2UgZG8g aXQ/IA0KICAgIG9yIGRvIHlvdSBjb25zaWRlciBpdCBpcyBlbm91Z2ggd2l0aCBjYWxjdWxhdGlu ZyBSVFQgYW5kIGRpdmlkZSBpdCBieSAyPyANCiAgICA8QlI+PEJSPk9uZSBvcHRpb24gdXNpbmcg dGhlIHBhY2tldHMgYWxyZWFkeSBkZWZpbmVkIGluIHRoZSBJLUQgdG8gY2FsY3VsYXRlIA0KICAg IFNvdXJjZS10by1TQyBkZWxheXMgY291bGQgYmUgdGhlIGZvbGxvd2luZzogQmVmb3JlIHRoZSBi ZWdpbm5pbmcgb2YgdGhlIA0KICAgIG1lZGlhIHRyYW5zbWlzc2lvbiwgdGhlIHNvdXJjZSBjb3Vs ZCBzdGFydCBzZW5kaW5nIG9uZSAob3Igc2V2ZXJhbCANCiAgICBjb25zZWN1dGl2ZSkgUlRDUCBJ RE1TIHJlcG9ydHMgKGRlZmluZWQgaW4gc2VjdGlvbiA3IG9mIHRoZSBJLUQpIHdpdGggYWxsIA0K ICAgIHRoZSBiaXRzIG9mIHRoZSBwYWNrZXQgcmVjZWl2ZWQgUlRQIHRpbWVzdGFtcCBmaWVsZCBz ZXQgdG8gMCAobm8gcGFja2V0IGlzIA0KICAgIHJlZmVyZW5jZWQpIGFuZCB0aGUgNjQtYml0IE5U UCB0aW1lc3RhbXAgb2YgaXRzIHNlbmRpbmcgdGltZSBpbiB0aGUgNjQgDQogICAgJ1BhY2tldCBy ZWNlaXZlZCBOVFAgVGltZXN0YW1wJyBmaWVsZCAoTlRQIHNlbmRpbmcgdGltZSkuIFNDcyBzaG91 bGQgDQogICAgcmVzcG9uc2UgdG8gdGhpcyBwYWNrZXQgd2l0aCBhbiBYUiB3aXRoIGFuIElETVMg UmVwb3J0IEJsb2NrIChhbHNvIGRlZmluZWQgDQogICAgaW4gdGhlIHNlY3Rpb24gNiBvZiB0aGUg SS1EKSBpbmNsdWRpbmcgdGhlIDY0LWJpdCBOVFAgdGltZXN0YW1wIG9mIHRoZSANCiAgICBpbnN0 YW50IGluIHdoaWNoIHRoYXQgcGFja2V0IHdhcyByZWNlaXZlZCAoTlRQIHJlY2VwdGlvbiB0aW1l KSwgYWxzbyANCiAgICBpbmNsdWRpbmcgdGhlIHBhY2tldCByZWNlaXZlZCBSVFAgdGltZXN0YW1w IGZpZWxkIHNldCB0byAwIChubyBwYWNrZXQgaXMgDQogICAgcmVmZXJlbmNlZCkgYW5kIGNvcHlp bmcgdGhlIG1pZGRsZSAzMi1iaXRzIG9mIHRoZSA2NC1iaXQgTlRQIHRpbWVzdGFtcCBvZiANCiAg ICB0aGUgb3JpZ2luYWwgcGFja2V0IHJlY2VpdmVkIGZyb20gdGhlIHNvdXJjZSAoaW4gb3JkZXIg dG8gYWxsb3cgdGhlIHNvdXJjZSANCiAgICBpZGVudGlmeSB0aGUgcmVzcG9uc2Ugd2l0aCB0aGUg b3JpZ2luYWwgcXVlcnkpLiBPbmNlIHJlY2VpdmVkIGFuIFhSIHdpdGggdGhlIA0KICAgIElETVMg cmVwb3J0IGJsb2NrIGZyb20gYW4gU0MsIHRoZSBzb3VyY2UgY291bGQgY2FsY3VsYXRlIHRoZSBv bmUtd2F5IA0KICAgIHNvdXJjZS10by1TQyBkZWxheSBieSBzdWJ0cmFjdGluZyBib3RoIDY0LWJp dCBOVFAgdGltZXN0YW1wcyAoTlRQIHJlY2VwdGlvbiANCiAgICB0aW1lLSBOVFBzZW5kaW5nIHRp bWUpLg0KICAgIDxESVYgY2xhc3M9aW0+PEJSPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4NCiAg PERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD48QlI+PC9ESVY+ DQogIDxESVY+W2tnXSBJJ20gYWZyYWlkIEknbSBub3QgZnVsbHkmbmJzcDtmYW1pbGlhciZuYnNw O3dpdGggYWxsIHRoZSBleGlzdGluZyBYUiANCiAgZnVuY3Rpb25hbGl0eSB5b3UgcmVmZXJlbmNl LiBGb3Igbm93IEkgd2lsbCBjbGFyaWZ5IGFuZCBleHBhbmQgbXkgcHJldmlvdXMgDQogIGNvbW1l bnQ6IFVuZGVyIElETVMgc2VuZGVycyBhbmQgcmVjZWl2ZXJzIGFyZSByZXF1aXJlZCB0byBoYXZl IGEgY29tbW9uIA0KICBhY2N1cmF0ZSByZWFsLXRpbWUgY2xvY2sgKE5UUCwgSUVFRSAxNTg4LCBH UFMsIGV0Yy4pLiBUaGUgc3RhbmRhcmQgUlRDUCBzZW5kZXIgDQogIHJlcG9ydCBjb250YWlucyBh IDY0LWJpdCByZWFsLXRpbWUgdGltZXN0YW1wIHdoaWNoIGluZGljYXRlcyBleGFjdGx5IHdoZW4g YW4gDQogIFJUUCBwYWNrZXQgd2FzIHNlbnQuIEEgcmVjZWl2ZXIgY2FuIGRldGVybWluZSBvbmUt d2F5IGRlbGl2ZXJ5IGRlbGF5IG9mIHRoaXMgDQogIHBhY2tldCBieSBjb21wYXJpbmcgdGhhdCB0 aW1lc3RhbXAgdG8gdGhlIHRpbWUgdGhhdCBSVFAgcGFja2V0IHdhcyByZWNlaXZlZCANCiAgYWNj b3JkaW5nIHRvIGhpcyBvd24gdmVyc2lvbiBvZiB0aGUgc2hhcmVkIHJlYWwtdGltZSBjbG9jay4g VGhpcyBzYW1lIA0KICB0ZWNobmlxdWUgY2FuIGJlIHVzZWQgdG8gbWVhc3VyZSB0aGUgb25lLXdh eSBkZWxheSBmb3IgYW55IHRyYW5zbWlzc2lvbiBpbiANCiAgZWl0aGVyIGRpcmVjdGlvbi48L0RJ Vj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj5bUWluXTogSSB0ZW5kIHRvIGFncmVlIHdp dGggS2V2aW4ncyBwcm9wc2FsLiBCdXQgSSBhbSBub3QgZ29pbmcgdG8ganVkZSANCiAgaWYgS2V2 aW4ncyBpcyBiZXR0ZXIgdGhhbiBGZXJuYW5kbydzLiBBY3R1YWxseSBiZXNpZGVzIHRoZSBvcHRp b24gcHJvcG9zZWQgYnkgDQogIEZlcm5hbmRvLCBSRkMzNjExIHByb3ZpZGUgYW5vdGhlciBzaW1p bGFyIHdheSBhcyZuYnNwO2JvdGggeW91ciANCiAgcHJvcG9zYWxzJm5ic3A7dG8gY2FsY3VhbHRl IG9uZSB3YXkgZGVsYXkuIFRoYXQncyBQYWNrZXQgUmVjZWlwdCBUaW1lcyBSZXBvcnQgDQogIEJs b2NrIGRlZmluZWQgaW4gdGhlIHNlY3Rpb24gNC4zIG9mIFJGQzM2MTEuIFlvdSBtYXkgbG9vayBh dCB0aGUgc2Vjb25kIA0KICBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA0LjMsIGl0IHNhaWQ6PC9ESVY+ DQogIDxESVY+IjwvRElWPg0KICA8RElWPiZuYnNwOyZuYnNwOyBQYWNrZXQgcmVjZWlwdCB0aW1l cyBhcmUgZXhwcmVzc2VkIGluIHRoZSBzYW1lIHVuaXRzIGFzIGluIA0KICB0aGUgUlRQPEJSPiZu YnNwOyZuYnNwOyB0aW1lc3RhbXBzIG9mIGRhdGEgcGFja2V0cy4mbmJzcDsgPEZPTlQgDQogIGNv bG9yPSNmZjAwMDA+VGhpcyBpcyBzbyB0aGF0LCBmb3IgZWFjaCBwYWNrZXQsIG9uZTxCUj4mbmJz cDsmbmJzcDsgY2FuIA0KICBlc3RhYmxpc2ggYm90aCB0aGUgc2VuZCB0aW1lIGFuZCB0aGUgcmVj ZWlwdCB0aW1lIGluIA0KICBjb21wYXJhYmxlPEJSPiZuYnNwOyZuYnNwOyB0ZXJtcy4mbmJzcDsg Tm90ZSwgaG93ZXZlciwgdGhhdCBhcyBhbiBSVFAgc2VuZGVyIA0KICBvcmRpbmFyaWx5IGluaXRp YWxpemVzPEJSPiZuYnNwOyZuYnNwOyBpdHMgdGltZSB0byBhIHZhbHVlIGNob3NlbiBhdCByYW5k b20sIA0KICB0aGVyZSBjYW4gYmUgbm8gZXhwZWN0YXRpb248QlI+Jm5ic3A7Jm5ic3A7IHRoYXQg cmVwb3J0ZWQgc2VuZCBhbmQgcmVjZWlwdCANCiAgdGltZXMgd2lsbCBkaWZmZXIgYnkgYW4gYW1v dW50IGVxdWFsPEJSPiZuYnNwOyZuYnNwOyB0byB0aGUgb25lLXdheSBkZWxheSANCiAgYmV0d2Vl biBzZW5kZXIgYW5kIHJlY2VpdmVyLiZuYnNwOyBUaGUgcmVwb3J0ZWQgdGltZXM8QlI+Jm5ic3A7 Jm5ic3A7IGNhbiANCiAgbm9uZXRoZWxlc3MgYmUgdXNlZnVsIGZvciB0aGUgcHVycG9zZXMgbWVu dGlvbmVkIGFib3ZlLjxCUj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+IjwvRElWPg0KICA8RElWPlRo YXQncyB0byBzYXkgdGhpcyBYUiBCbG9jayBjYW4gYmUgdXNlZCB0byBjYWxjdWxhdGUgb25lIHdh eSBkZWxheS4gDQo8L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+ PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_Fg0+DUcjBp+eCvpLrIh6hA)-- From bill.wu@huawei.com Thu Oct 20 19:50:20 2011 Return-Path: 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 6AB571F0C41 for ; Thu, 20 Oct 2011 19:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.729 X-Spam-Level: X-Spam-Status: No, score=-4.729 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 iS6W08AXrG5D for ; Thu, 20 Oct 2011 19:50:19 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E4B121F0C3B for ; Thu, 20 Oct 2011 19:50:18 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE007PSAH1Q2@szxga05-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 10:48:38 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00DD1AH105@szxga05-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 10:48:37 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI66652; Fri, 21 Oct 2011 10:48:37 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 10:48:30 +0800 Received: from w53375q (10.138.41.130) by szxeml408-hub.china.huawei.com (10.82.67.95) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 10:48:30 +0800 Date: Fri, 21 Oct 2011 10:48:27 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Kevin Gross , IETF AVTCore WG Message-id: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 02:50:20 -0000 SXNuJ3QgNjQgYml0cyBOVFAgdGltZXN0YW1wIGFuZCAzMmJpdHMgUlRQIHRpbWVzdGFtcCBjb21w bGlhbnQgd2l0aCANCm9uZXMgZGVmaW5lZCBpbiBSRkMzNTUwPw0KDQpSZWdhcmRzIQ0KLVFpbg0K LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJLZXZpbiBHcm9zcyIgPGtldmlu Lmdyb3NzQGNvbWNhc3QubmV0Pg0KVG86ICJJRVRGIEFWVENvcmUgV0ciIDxhdnRAaWV0Zi5vcmc+ DQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMCwgMjAxMSAxMDo1OSBBTQ0KU3ViamVjdDogW0FW VENPUkVdIGRyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTAxIHRpbWVzdGFtcCBwcmVjaXNpb24NCg0K DQpQYXJ0IG9mIG15IHJlYXNvbiBmb3IgYnJpbmdpbmcgdGhlc2UgdXNlIGNhc2VzIHRvIHRoZSBh dHRlbnRpb24gb2YgdGhlDQpncm91cCByZWxhdGVzIHRvIGEgeWV0IHVucmVzb2x2ZWQgY29tbWVu dCBJIG1hZGUgYWdhaW5zdCB0aGUgSURNUw0KZHJhZnQuDQoNClRoZSBkcmFmdCBwcm9wb3NlcyA2 NC1iaXQgdGltZXN0YW1wcyBmb3IgYXJyaXZhbCB0aW1lcyBidXQgb25seSAzMi1iaXQNCnRpbWVz dGFtcHMgZm9yIHByZXNlbnRhdGlvbiB0aW1lcy4gQSAzMi1iaXQgTlRQIHRpbWVzdGFtcCBoYXMg YSAxNQ0KbWljcm9zZWNvbmQgcHJlY2lzaW9uLiBQcmVzZW50YXRpb24gdGltZSBzeW5jaHJvbml6 YXRpb24gd2l0aCB0aGVzZQ0KdGltZXN0YW1wcyB3b3VsZCBzZWVtIG5vdCB0byBjbGVhcmx5IG1l ZXQgdGhlIHJlcXVpcmVtZW50cyBvZiBhIGNvdXBsZQ0Kb2YgdGhlc2UgdXNlIGNhc2VzLg0KDQpJ bXByb3ZpbmcgdGhlIHByb3RvY29sIHRvIHN1cHBvcnQgNjQtYml0IHRpbWVzdGFtcHMgdGhyb3Vn aG91dCBzZWVtcw0KdG8gYmUgdGhlIHN0cmFpZ2h0Zm9yd2FyZCBzb2x1dGlvbi4gV2l0aCB0aGlz IGNoYW5nZSwgYWxsIHRpbWVzdGFtcHMNCndvdWxkIGhhdmUgdGhlIHNhbWUgcHJlY2lzaW9uIGFu ZCB3b3VsZCBoYXZlIGEgcHJlY2lzaW9uIGNvbXBhcmFibGUgdG8NCnRoZWlyIHJlZmVyZW5jZSBj bG9ja3MuIFRoZSBwcm9ibGVtIHdpdGggdGhpcyBpcyB0aGF0IG91ciBJRE1TIHdvcmsgaXMNCmJh c2VkIG9uIEVUU0kgVElTUEFOIHN0YW5kYXJkIFRTIDE4MyAwNjMuIEVmZm9ydHMgaGF2ZSBiZWVu IG1hZGUgaW4NCnRoZSBkcmFmdCB0byBtYWludGFpbiBjb21wYXRpYmlsaXR5IHdpdGggdGhpcyBz dGFuZGFyZC4gQ2hhbmdpbmcgdGhlDQpwYWNrZXQgZm9ybWF0IHRvIGFjY29tbW9kYXRlIDY0LWJp dCB0aW1lc3RhbXBzIHdpbGwgdW5yYXZlbCB0aG9zZQ0KZWZmb3J0cy4NCg0KSWYgRVRTSSBjb21w YXRpYmlsaXR5IGlzIGltcG9ydGFudCwgd2Ugd2lsbCBoYXZlIHRvIGxpdmUgd2l0aCAxNQ0KbWlj cm9zZWNvbmQgcHJlY2lzaW9uIGFuZCBwb3NzaWJseSBzdWdnZXN0IGNsZXZlciB0cmlja3MgdG8g bWFrZSB0aGUNCm1vc3Qgb2YgaXQuDQoNCldoaWNoIHdheSBkbyB3ZSB3YW50IHRvIGdvIGhlcmU/ DQoNCk9uIFR1ZSwgQXVnIDE2LCAyMDExIGF0IDExOjEyIEFNLCBLZXZpbiBHcm9zcyA8a2V2aW4u Z3Jvc3NAY29tY2FzdC5uZXQ+IHdyb3RlOg0KPiBUaGUgcmVxdWlyZW1lbnQgZm9yIHRoZSBzdGVy ZW8gY2FzZSBpcyBzcGVjaWZpZWQgZGlmZmVyZW50bHkgdGhhbiB0aGUNCj4gb3RoZXJzLiBUaGUg MTAgbWljcm9zZWNvbmQgZmlndXJlIHRoZXJlIGFwcGxpZXMgdG8gX2NoYW5nZXMgaW4gbGF0ZW5j eV8sIG5vdA0KPiBzdGF0aWMgZGlmZmVyZW5jZSBpbiBsYXRlbmN5IGRlc2NyaWJlZCBpbiBhbGwg dGhlIG90aGVyIGNhc2VzLiBUb2xlcmFuY2UgZm9yDQo+IHN0YXRpYyBkaWZmZXJlbmNlcyBmb3Ig dGhlIHN0ZXJlbyBjYXNlIGFyZSBwcm9iYWJseSBvbiB0aGUgb3JkZXIgb2YgMQ0KPiBtaWxsaXNl Y29uZC4gVGhlIGZpcnN0LW9yZGVyIGVmZmVjdCBvZiBzdGF0aWMgbGF0ZW5jeSBkaWZmZXJlbmNl cyBpcyB0byBtb3ZlDQo+IG9uZSBvZiB0aGUgc3BlYWtlcnMgliBqdXN0IGRlcGVuZHMgb24gaG93 IGZ1c3N5IHlvdSBhcmUgYWJvdXQgcmVhbCB2cy4NCj4gZWZmZWN0aXZlIHNwZWFrZXIgcGxhY2Vt ZW50Lg0KPg0KPg0KPg0KPiBUaGUgMTAgbWljcm9zZWNvbmQgZmlndXJlIGlzIGNvbnNlcnZhdGl2 ZSAoSZJ2ZSBoZWFyZCBhbmVjZG90YWwgY2xhaW1zIG9mIDENCj4gbWljcm9zZWNvbmRzIHNlbnNp dGl2aXR5KSBhbmQgZGVyaXZlcyBmcm9tIG91ciBhYmlsaXR5IHRvIGFjY3VyYXRlbHkgbG9jYXRl DQo+IHNvdW5kcyBiYXNlZCAoaW4gcGFydCkgb24gY29tcGFyaXNvbiBvZiBhcnJpdmFsIHRpbWVz IGF0IGVhY2ggZWFyLiBUaGUgMTANCj4gbWljcm9zZWNvbmQgZmlndXJlIGlzIG5vdCBkaWZmaWN1 bHQgdG8gZGVyaXZlL2NoZWNrLiBJdCBpcyBhbHNvIG5vdA0KPiBkaWZmaWN1bHQgdG8gc2V0IHVw IGEgbGlzdGVuaW5nIHRlc3QgdG8gc2VlIHdoYXQgeW91ciBvd24gdGhyZXNob2xkIGlzLg0KPiBI ZXJlknMgYSBxdWljayByZWZlcmVuY2Ugb24gaXQgLSBodHRwOi8vd3d3LmNzLnVjYy5pZS9+aWFu cC9DUzI1MTEvSEFQLmh0bWwNCj4gKHNlZSBMb2NhbGlzYXRpb24gb2YgU291bmQgU291cmNlcyBz ZWN0aW9uKQ0KPg0KPg0KPg0KPiBUaHJvdWdob3V0LCBJknZlIHRyaWVkIHRvIHVzZSB3aGF0IEkg Y29uc2lkZXIgcmVhc29uYWJsZSBhbmQgdmVyaWZpYWJsZQ0KPiByZXF1aXJlbWVudHMgZmlndXJl cy4gU29tZSB3aWxsIGFsd2F5cyBzZWVtIHRvIGFyZ3VlIHRoYXQgdGhleSBuZWVkIGJldHRlcg0K PiBwZXJmb3JtYW5jZS4NCj4NCj4NCj4NCj4gS2V2aW4NCj4NCj4NCj4NCj4gRnJvbTogYXZ0LWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m DQo+IEFsbGlzb24sIEFydA0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTYsIDIwMTEgOTowNyBB TQ0KPiBUbzogSUVURiBBVlRDb3JlIFdHDQo+IFN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gQWRkaXRp b25hbCB1c2UgY2FzZXMNCj4gZm9yZHJhZnQtYnJhbmRlbmJ1cmctYXZ0LXJ0Y3AtZm9yLWlkbXMN Cj4NCj4NCj4NCj4gTXIuIEdyb3NzLA0KPg0KPiBUaGUgdGltaW5nIGFzc2VydGlvbiBmb3IgTmV0 d29ya2VkIHN0ZXJlbyBsb3Vkc3BlYWtlcnMgaXMgbXVjaCB0aWdodGVyIHRoYXQNCj4gSSB3b3Vs ZCBoYXZlIGV4cGVjdGVkLiBQbGFjZW1lbnQgb2Ygc3RlcmVvIHNwZWFrZXJzIHdpdGhpbiBhIGZv b3QgaXMgYQ0KPiBub3JtYWwgcnVsZSBvZiB0aHVtYiBmb3IgdGhlIGNhc3VhbCBsaXN0ZW5lciCW IGFuZCB0aGF0IGlzIGFib3V0IDEuMW1zDQo+IGRlbHRhIGF0IHJvb20gdGVtcGVyYXR1cmUuIFRo ZSCRIGdvbGRlbiBlYXJzkiBkbyBoYXZlIGFiaWxpdHkgdG8gZGV0ZWN0DQo+IHNtYWxsIGRpZmZl cmVuY2VzIGVzcGVjaWFsbHkgd2l0aCBoaWdoIGF0dGFjayB3YXZlZm9ybXMsIGJ1dCBJIHdvdWxk IGxpa2UgdG8NCj4gc2VlIHRoZSBzdHVkeSB0aGF0IHNob3dlZCB0aGlzIHNtYWxsIHRpbWUgZGlm ZmVyZW5jZS4gQ2FuIHlvdSBwbGVhc2UgcHJvdmlkZQ0KPiBhIGNpdGU/DQo+DQo+IEFuZCBJIHdv bmRlciBpZiB0aGUgc3lzdGVtIHJlcXVpcmVtZW50IHNob3VsZCBiZSBiYXNlZCBvbiB0aGUgc21h bGxlc3Qga25vd24NCj4gZGVsdGEsIHVubGVzcyB0aGVyZSBpcyBubyBpbXBsZW1lbnRhdGlvbiBj b21wbGV4aXR5IGFkZGVkIHRvIGNvbnZleSB0aGUNCj4gc3VnZ2VzdGVkIHJlc29sdXRpb24uDQo+ DQo+DQo+DQo+DQo+DQo+IEFydCBBbGxpc29uDQo+IFNlbmlvciBEaXJlY3RvciBBZHZhbmNlZCBF bmdpbmVlcmluZywgU2NpZW5jZSBhbmQgVGVjaG5vbG9neQ0KPiBOYXRpb25hbCBBc3NvY2lhdGlv biBvZiBCcm9hZGNhc3RlcnMNCj4gMTc3MSBOIFN0cmVldCBOVw0KPiBXYXNoaW5ndG9uLCBEQyAy MDAzNg0KPiBQaG9uZSAyMDIgNDI5IDU0MTgNCj4gRmF4IDIwMiA3NzUgNDk4MQ0KPiB3d3cubmFi Lm9yZw0KPiBBZHZvY2FjeSBFZHVjYXRpb24gSW5ub3ZhdGlvbg0KPg0KPiBGcm9tOiBhdnQtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg S2V2aW4NCj4gR3Jvc3MNCj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMTUsIDIwMTEgMTE6NDggUE0N Cj4gVG86ICdJRVRGIEFWVENvcmUgV0cnDQo+IFN1YmplY3Q6IFtBVlRDT1JFXSBBZGRpdGlvbmFs IHVzZSBjYXNlcw0KPiBmb3JkcmFmdC1icmFuZGVuYnVyZy1hdnQtcnRjcC1mb3ItaWRtcw0KPg0K Pg0KPg0KPiBJbiByZXZpZXdpbmcgdGhlIElETVMgZHJhZnQgSSBoYWQgdm9sdW50ZWVyZWQgdG8g Y29udHJpYnV0ZSBhZGRpdGlvbmFsIHVzZQ0KPiBjYXNlcy4gUmF5IEJyYW5kZW5iZXJnIHN1Z2dl c3RlZCB0aGF0IEkgcG9zdCB0aGVtIGhlcmUuDQo+DQo+DQo+DQo+IEtldmluIEdyb3NzDQo+DQo+ IEFWQSBOZXR3b3Jrcw0KPg0KPiBOZXR3b3JrZWQgc3RlcmVvIGxvdWRzcGVha2Vycw0KPg0KPiBC ZWNhdXNlIG9mIG91ciBhYmlsaXR5IHRvIGxvY2FsaXplIHNvdW5kIGJhc2VkIG9uIGludGVyLWF1 cmFsIHRpbWUNCj4gZGlmZmVyZW5jZXMsIGluIGEgc3RlcmVvIGxpc3RlbmluZyBzaXR1YXRpb24s IHdlIGFyZSB2ZXJ5IHNlbnNpdGl2ZSB0bw0KPiBjaGFuZ2VzIGluIGxhdGVuY3kgYmV0d2VlbiB0 aGUgdHdvIHNwZWFrZXJzLiBUaGVzZSBjaGFuZ2VzIGFyZSBwZXJjZWl2ZWQgYXMNCj4gYSBzaGlm dCBpbiBvciBpbnN0YWJpbGl0eSBvZiB0aGUgk3NvdW5kIHN0YWdllCBkdXJpbmcgY3JpdGljYWwg bGlzdGVuaW5nLg0KPiBUaGVzZSBlZmZlY3RzIGFyZSByZWFkaWx5IG5vdGljZWFibGUgd2l0aCBz aGlmdHMgb2YgMTAgbWljcm9zZWNvbmRzIG9yDQo+IHNtYWxsZXIuIElmIHRoZSBpbmRpdmlkdWFs IHNwZWFrZXJzIGluIGEgc3RlcmVvIGxpc3RlbmluZyBzZXR1cCBvcGVyYXRlIGZyb20NCj4gaW5k ZXBlbmRlbnQgbmV0d29yayBpbnRlcmZhY2VzIGFueSBjaGFuZ2luZyBkaWZmZXJlbmNlIGluIGxh dGVuY3kgYmV0d2Vlbg0KPiB0aGUgdHdvIHNwZWFrZXJzIGdyZWF0ZXIgdGhhbiAxMCBtaWNyb3Nl Y29uZHMgd2lsbCBiZSBkZXRyaW1lbnRhbCB0byB0aGUNCj4gbGlzdGVuaW5nIGV4cGVyaWVuY2Uu DQo+DQo+IENvbmZlcmVuY2luZyBzb3VuZCByZWluZm9yY2VtZW50IHN5c3RlbQ0KPg0KPiBBIGNv bmZlcmVuY2luZyBzb3VuZCByZWluZm9yY2VtZW50IHN5c3RlbSBpcyB1c2VkIGluIGNvbW1lcmNp YWwgYW5kDQo+IGdvdmVybm1lbnQgaW5zdGFsbGF0aW9ucyBzdWNoIGFzIGxlZ2lzbGF0aXZlIGNo YW1iZXJzLCBjb3VydHJvb21zLA0KPiBib2FyZHJvb21zLCBjbGFzc3Jvb21zIChlc3BlY2lhbGx5 IHRob3NlIHN1cHBvcnRpbmcgZGlzdGFuY2UgbGVhcm5pbmcpIGFuZA0KPiBvdGhlciBzdWNoIHZl bnVlcy4gRWFjaCBwYXJ0aWNpcGFudCB1c2luZyBzdWNoIGEgc3lzdGVtIGhhcyBhIG1pY3JvcGhv bmUgYW5kDQo+IGEgc3BlYWtlci4gVGhlcmUgbWF5IGFsc28gYmUgb3RoZXIgc3BlYWtlcnMgdG8g cHJvdmlkZSByZWluZm9yY2VtZW50IGZvcg0KPiBub24tc3BlYWtpbmcgcGFydGljaXBhbnRzIHN1 Y2ggYXMgaW4gYW4gYXVkaWVuY2UgYXJlYSBvciBqdXJ5IGJveC4gRWFjaA0KPiBtaWNyb3Bob25l L3NwZWFrZXIgcGFpciBpcyBpbmRpdmlkdWFsbHkgY29ubmVjdGVkIHRvIGEgbmV0d29yayBhbmQg dHJhbnNtaXRzDQo+IGRpZ2l0YWwgYXVkaW8gdG8gdGhlIG90aGVyIGRldmljZXMgdGhyb3VnaCB0 aGUgbmV0d29yayBhbmQgcmVjZWl2ZXMgZGlnaXRhbA0KPiBhdWRpbyB0byBiZSByZXByb2R1Y2Vk IHRocm91Z2ggdGhlIHNwZWFrZXIgb3ZlciB0aGUgbmV0d29yay4gVGhlcmUgbWF5IGJlIGENCj4g Y2VudHJhbCBhcHBsaWFuY2Ugd2hpY2ggcmVjZWl2ZXMsIHByaW9yaXRpemVzIGFuZCBtaXhlcyB0 aGUgbWljcm9waG9uZQ0KPiBzaWduYWxzLiBJbiBzb21lIHN5c3RlbXMgYW4gaW5kaXZpZHVhbCBt aXggaXMgY3JlYXRlZCBmb3IgZWFjaCBzcGVha2VyIHN1Y2gNCj4gdGhhdCBhIHNwZWFrZXKScyBv d24gdm9pY2UgZG9lcyBub3QgY29tZSBvdXQgZnJvbSBoaXMgc3BlYWtlciBvciBmcm9tIHRob3Nl DQo+IGltbWVkaWF0ZWx5IHN1cnJvdW5kaW5nIGhpbS4NCj4NCj4gVGhlIG9iamVjdGl2ZSBvZiB0 aGVzZSBzeXN0ZW1zIGlzIHRvIHByb3ZpZGUgZW5vdWdoIGdhaW4gdG8gZW5oYW5jZQ0KPiBpbnRl bGxpZ2liaWxpdHkgYnV0IG5vdCBzbyBtdWNoIHRoYXQgdGhlIHNwZWFrZXIgc291bmRzIG9yIGZl ZWxzIGFtcGxpZmllZC4NCj4gTWVldGluZyB0aGlzIG9iamVjdGl2ZSBoZWxwcyBpbnN1cmUgdGhh dCBuYXR1cmFsIHBlcnNvbi10by1wZXJzb24NCj4gY29tbXVuaWNhdGlvbiBpcyByZXRhaW5lZC4g VG8gdGhpcyBlbmQsIGl0IGlzIGRlc2lyYWJsZSB0aGF0IHRoZSBzb3VuZA0KPiB0aHJvdWdoIHRo ZSBzeXN0ZW0gYW5kIGZyb20gdGhlIHNwZWFrZXJzIGFycml2ZSA1IHRvIDMwIG1pbGxpc2Vjb25k cyBhZnRlcg0KPiB0aGUgdGhlIHNvdW5kIGFycml2aW5nIHRocm91Z2ggdGhlIGFpciBmcm9tIHRo ZSBwZXJzb24gc3BlYWtpbmcuIERlbGF5cyBpbg0KPiB0aGlzIHJhbmdlIGludm9rZSB0aGUgSGFh cyBlZmZlY3Qgd2hpY2ggYWxsb3dzIGxpc3RlbmVycyB0byBsb2NhdGUgdGhlDQo+IHBlcnNvbiBz cGVha2luZyBiYXNlZCBvbiB0aGUgc291bmQgYXJyaXZpbmcgdGhyb3VnaCB0aGUgYWlyIHdoaWxl IHRoZSBzb3VuZA0KPiByZWluZm9yY2VtZW50IHN5c3RlbSBwcm92aWRlcyB0aGUgYWRkaXRpb25h bCBnYWluIHJlcXVpcmVkIHRvIGFjaGlldmUNCj4gZGVzaXJlZCBpbnRlbGxpZ2liaWxpdHkuIEl0 IGlzIGFsc28gZGVzaXJhYmxlIGZvciB0aGUgc291bmQgdG8gY29tZSBvdXQgb2YNCj4gbmVhcmJ5 IHNwZWFrZXJzIGF0IHdpdGhpbiA1IG1pbGxpc2Vjb25kcyBhcyBsb25nZXIgZGlmZmVyZW50aWFs IGRlbGF5cyB3aWxsDQo+IGJlIHBlcmNlaXZlZCBhcyByZXZlcmJlcmF0aW9uIG9yIGVjaG8uDQo+ DQo+IFZpZGVvIHdhbGwNCj4NCj4gQSB2aWRlbyB3YWxsIGNvbnNpc3RzIG9mIG11bHRpcGxlIGNv bXB1dGVyIG1vbml0b3JzLCB2aWRlbyBwcm9qZWN0b3JzLCBvcg0KPiB0ZWxldmlzaW9uIHNldHMg dGlsZWQgdG9nZXRoZXIgY29udGlndW91c2x5IG9yIG92ZXJsYXBwZWQgaW4gb3JkZXIgdG8gZm9y bQ0KPiBvbmUgbGFyZ2Ugc2NyZWVuLiMgRWFjaCBvZiB0aGUgc2NyZWVucyByZXByb2R1Y2VzIGEg cG9ydGlvbiBvZiB0aGUgbGFyZ2VyDQo+IHBpY3R1cmUuIEluIHNvbWUgaW1wbGVtZW50YXRpb25z LCBlYWNoIHNjcmVlbiBtYXkgYmUgaW5kaXZpZHVhbGx5IGNvbm5lY3RlZA0KPiB0byB0aGUgbmV0 d29yayBhbmQgcmVjZWl2ZSBpdHMgcG9ydGlvbiBvZiB0aGUgb3ZlcmFsbCBpbWFnZSBmcm9tIGEN Cj4gbmV0d29yay1jb25uZWN0ZWQgdmlkZW8gc2VydmVyIG9yIHZpZGVvIHNjYWxlci4gU2NyZWVu cyBhcmUgcmVmcmVzaGVkIGF0IDYwDQo+IGhlcnR6IChldmVyeSAxNi0yLzMgbWlsbGlzZWNvbmRz KSBvciBwb3RlbnRpYWxseSBmYXN0ZXIuIElmIHRoZSByZWZyZXNoIGlzDQo+IG5vdCBzeW5jaHJv bml6ZWQsIHRoZSBlZmZlY3Qgb2YgbXVsdGlwbGUgc2NyZWVucyBhY3RpbmcgYXMgb25lIGlzIGJy b2tlbi4NCj4NCj4gUGhhc2VkIGFycmF5IHRyYW5zZHVjZXJzDQo+DQo+IFBoYXNlZCBhcnJheSBh bmQgd2F2ZSBmaWVsZCBzeW50aGVzaXMgdGVjaG5pcXVlcyBhcmUgaW5jcmVhc2luZ2x5IHVzZWQg aW4NCj4gYXVkaW8gYXBwbGljYXRpb25zLiBUaGVzZSB0ZWNobmlxdWVzIHdvcmsgYnkgc2VuZGlu ZyBvciByZWNlaXZpbmcgc2xpZ2h0bHkNCj4gZGlmZmVyZW50IHZlcnNpb25zIG9mIGEgc2lnbmFs IGluIGEgc3BhY2lhbCBzYW1wbGluZyBhcnJhbmdlbWVudCB0byBwcm9kdWNlDQo+IG9yIHJlY29y ZCBzcGFjaWFsIGFuZCBkaXJlY3Rpb25hbCBzb3VuZCBmaWVsZHMuIFRoZSBpbmRpdmlkdWFsIHRy YW5zZHVjZXJzDQo+IGluIHRoZXNlIGFwcGxpY2F0aW9ucyBjYW4gYmUgZXh0cmVtZWx5IHNlbnNp dGl2ZSB0byBkaWZmZXJlbnRpYWwgbGF0ZW5jeS4NCj4gRXhhbXBsZSBhcHBsaWNhdGlvbnMgaW5j bHVkZSBjb25mZXJlbmNpbmcgbWljcm9waG9uZSBzeXN0ZW1zIGFibGUgdG8NCj4gZWxlY3Ryb25p Y2FsbHkgYWltIGF0IHRoZSBwZXJzb24gc3BlYWtpbmcgdG8gaW1wcm92ZSBzaWduYWwgdG8gbm9p c2UgcmF0aW8uDQo+IFRoZXNlIG1pY3JvcGhvbmVzIGFyZSBhbHNvIGFibGUgdG8gcmVwb3J0IHRo ZSBsb2NhdGlvbiBvZiB0aGUgc3BlYWtlciBmb3INCj4gcHVycG9zZXMgb2YgYXV0b21hdGljYWxs eSBhaW1pbmcgYSB2aWRlbyBjYW1lcmEgYXQgdGhlbS4NCj4NCj4gQ29uY2VydCBzb3VuZCBzeXN0 ZW1zIGNhbGxlZCBsaW5lIGFycmF5cyBhbGxvdyB0ZWNobmljaWFucyBjb250cm9sIG92ZXIgdGhl DQo+IGFtb3VudCBvZiBzb3VuZCBzZW50IHRvIGRpZmZlcmVudCBwbGFjZXMuIFBlb3BsZSBpbiB0 aGUgZnJvbnQgb2YgdGhlDQo+IGF1ZGllbmNlIGNhbiBoYXZlIHRoZSBzYW1lIGxvdWRuZXNzIGFz IHRob3NlIGluIHRoZSBiYWNrLiBCeSBwcmV2ZW50aW5nDQo+IHNvdW5kIGZyb20gcmVhY2hpbmcg dGhlIHJvb2YgYW5kIGJhY2sgd2FsbCBvZiB0aGUgcGVyZm9ybWFuY2Ugc3BhY2UsIHRoZQ0KPiBh bW91bnQgb2YgcmVmbGVjdGVkIHNvdW5kIGhlYXJkIGJ5IHRoZSBhdWRpZW5jZSBpcyByZWR1Y2Vk IGFuZCB0aGUgbGlzdGVuaW5nDQo+IGV4cGVyaWVuY2UgaXMgaW1wcm92ZWQuDQo+DQo+IEluIHRo ZXNlIHN5c3RlbXMsIGFjY3VyYWN5IGluIGxvY2F0aW5nIG9yIGVtaXR0aW5nIHNvdW5kIGlzIHJl bGF0ZWQgdG8NCj4gZGlmZmVyZW50aWFsIGxhdGVuY3kgdGhyb3VnaCBiYXNpYyB0cmlnb25vbWV0 cnkuIEluIHRoZXNlIGFwcGxpY2F0aW9ucywNCj4gbWljcm9zZWNvbmRzIG9mIGRpZmZlcmVudGlh bCBsYXRlbmN5IGNhbiB0cmFuc2xhdGUgdG8gZGVncmVlcyBvZg0KPiB1bmNlcnRhaW50eS4gQWNj dXJhY3kgZ3JlYXRlciB0aGFuIHRoZSBhdWRpbyBzYW1wbGUgcGVyaW9kIChhYm91dCAyMA0KPiBt aWNyb3NlY29uZHMgZm9yIHByb2Zlc3Npb25hbCA0OCBrSHogc2FtcGxlIHJhdGUpIGlzIGdlbmVy YWxseSBkZXNpcmVkLg0KPg0KPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo= From caoning@sttri.com.cn Thu Oct 20 23:35:41 2011 Return-Path: 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 6616E1F0C68 for ; Thu, 20 Oct 2011 23:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.286 X-Spam-Level: **** X-Spam-Status: No, score=4.286 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_NJABL_PROXY=1.643] 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 M7R76GDOlqqV for ; Thu, 20 Oct 2011 23:35:40 -0700 (PDT) Received: from corp.21cn.com (corp.forptr.21cn.com [121.14.129.35]) by ietfa.amsl.com (Postfix) with ESMTP id 29CE921F8500 for ; Thu, 20 Oct 2011 23:35:39 -0700 (PDT) Received: from ip?218.2.129.2? (entas5.inner-hermes.com [10.27.101.5]) by corp.21cn.com (HERMES) with ESMTP id 491C13E4096 for ; Fri, 21 Oct 2011 14:35:37 +0800 (CST) HMM_ATTACHE_NUM: 0000 HMM_SOURCE_IP: wmail.10.27.101.5.2043138298 HMM_SOURCE_TYPE: WEBMAIL Received: from ip<218.2.129.2> ([218.2.129.2]) by 21CN-entas5(Yuwen filter gate 10.27.101.5) with ESMTP id 1319178937.17030 for avt@ietf.org ; Fri Oct 21 14:35:38 2011 0/X-Total-Score: 3: X-FILTER-SCORE: to=, score=<1319178938JmaTTxTTWTTnTTaTXzxWnanB88088E88Q88b8Gk0EQbJ> Date: Fri, 21 Oct 2011 14:35:37 +0800 (CST) From: =?UTF-8?B?5pu55a6B?= To: avt Message-ID: <29600986.23381319178937356.JavaMail.root@ent11> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2478_21687857.1319178937106" HMM_WEBCLN_IP: 218.2.129.2 X-HERMES-SENDMODE: normal Subject: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 06:41:56 -0000 ------=_Part_2478_21687857.1319178937106 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+CiA8aGVhZD48L2hlYWQ+CiA8Ym9keT4KICA8ZGl2PgogICA8c3BhbiBzdHlsZT0iQkFD S0dST1VORC1DT0xPUjogd2hpdGUiPkhpLCZuYnNwOzwvc3Bhbj4KICA8L2Rpdj4gCiAgPGRpdj4g CiAgIDxkaXY+CiAgICA8Zm9udCBzaXplPSIyIj5JIGhhdmUgcmVhZCA8L2ZvbnQ+CiAgICA8Zm9u dCBzaXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiIGxh bmc9ImVuLVVTIj5kcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0wNCBhbmQgYmVsaWV2ZSBpdCBp cyByZWFkeSBmb3IgcHVibGljYXRpb24uPC9zcGFuPjwvZm9udD4KICAgPC9kaXY+IAogICA8ZGl2 PgogICAgPGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0IiBsYW5nPSJlbi1VUyI+SSBoYXZlIG9ubHkgb25lIHN1Z2dlc3Rpb24gZm9yIGl0cyBj bGFyaXR5IG9mIGRyYWZ0Ljwvc3Bhbj48L2ZvbnQ+CiAgIDwvZGl2PiAKICAgPGRpdj4KICAgIDxm b250IHNpemU9IjMiIGZhY2U9IuWui+S9kyI+PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCIg bGFuZz0iZW4tVVMiPkluIHRoZSBzZWN0aW9uIDUuMiwgaXQgbWVudGlvbnMgdXNpbmcgJnF1b3Q7 Y2h1bmsmcXVvdDs8L3NwYW4+PC9mb250PgogICA8L2Rpdj4gCiAgIDxkaXY+CiAgICA8Zm9udCBz aXplPSIzIiBmYWNlPSLlrovkvZMiPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiIGxhbmc9 ImVuLVVTIj50byBjb252ZXkgY29ycmVsYXRpb24gaW5mb3JtYXRpb24sIHdvdWxkIGl0IGJldHRl ciB0byB1c2UgU0RFQyBpdGVtIHRvIHJlcGxhY2UgaXQ/PC9zcGFuPjwvZm9udD4KICAgPC9kaXY+ IAogICA8ZGl2PgogICAgPGZvbnQgc2l6ZT0iMyIgZmFjZT0i5a6L5L2TIj48c3BhbiBzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0IiBsYW5nPSJlbi1VUyI+QWxzbyB3b3VsZCBpdCBiZXR0ZXIgdG8mbmJz cDtlbXBoYXNpemUgdGhlIG5ldyBTREVTIGl0ZW0gaXMgcmVxdWlyZWQuPC9zcGFuPjwvZm9udD4K ICAgPC9kaXY+IAogICA8ZGl2PgogICAgJm5ic3A7CiAgIDwvZGl2PiAKICAgPGRpdj4gCiAgICA8 ZGl2PgogICAgIDxmb250IHNpemU9IjIiIGZhY2U9IuWui+S9kyI+PHNwYW4gbGFuZz0iZW4tVVMi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJGT05ULVNJWkU6IDEw LjVwdCI+UmVnYXJkcyE8L3NwYW4+PC9mb250PiA8L3NwYW4+PC9mb250PgogICAgPC9kaXY+IAog ICAgPGRpdj4KICAgICA8Zm9udCBzaXplPSIyIiBmYWNlPSLlrovkvZMiPjxzcGFuIGxhbmc9ImVu LVVTIj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQiPk5pbmcg Q2FvPC9zcGFuPjwvZm9udD4mbmJzcDs8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iRk9OVC1T SVpFOiAxMC41cHQiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+IAogICAgICAgPGRpdj4KICAgICAgICA8 Zm9udCBmYWNlPSJDYWxpYnJpIj48c3Ryb25nPlNoYW5nSGFpIFJlc2VhcmNoIEluc3RpdHV0ZSBv ZiBDaGluYSBUZWxlY29tIENvcnBvcmF0aW9uIExpbWl0ZWQ8L3N0cm9uZz48L2ZvbnQ+CiAgICAg ICA8L2Rpdj48L3NwYW4+PC9mb250PgogICAgPC9kaXY+CiAgIDwvZGl2PgogIDwvZGl2PgogPC9i b2R5Pgo8L2h0bWw+ ------=_Part_2478_21687857.1319178937106-- From bill.wu@huawei.com Thu Oct 20 23:57:50 2011 Return-Path: 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 BF13C21F84DB for ; Thu, 20 Oct 2011 23:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.609 X-Spam-Level: X-Spam-Status: No, score=-5.609 tagged_above=-999 required=5 tests=[AWL=0.989, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 D68TzDxeAgOl for ; Thu, 20 Oct 2011 23:57:50 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id DB4CA21F84D7 for ; Thu, 20 Oct 2011 23:57:49 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00F41LYSZS@szxga04-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 14:56:53 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00L0MLYSXS@szxga04-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 14:56:52 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEP34060; Fri, 21 Oct 2011 14:56:52 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 14:56:44 +0800 Received: from w53375q (10.138.41.130) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 14:56:46 +0800 Date: Fri, 21 Oct 2011 14:56:45 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: avt Message-id: <86C62FE750A74BE2A3A3BAA0C60D746A@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_NhHFhuCh8B9scjo9Zk9VMw)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <29600986.23381319178937356.JavaMail.root@ent11> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 06:57:50 -0000 --Boundary_(ID_NhHFhuCh8B9scjo9Zk9VMw) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 SGksTmluZzoNCnlvdXIgY2xhcmlmaWNhdGlvbiBsb29rcyBnb29kIHRvIG1lLCANCnRoZSBuZXcg dmVyc2lvbiB3aWxsIHJlZmxlY3QgdGhpcyBjaGFuZ2Ugc29vbi4NClRoYW5rcyBmb3IgdGhlIHN1 cHBvcnQsIA0KDQpSZWdhcmRzIQ0KLVFpbg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KICBGcm9tOiDmm7nlroEgDQogIFRvOiBhdnQgDQogIFNlbnQ6IEZyaWRheSwgT2N0b2JlciAy MSwgMjAxMSAyOjM1IFBNDQogIFN1YmplY3Q6IFtBVlRDT1JFXSBDb21tZW50cyBvbiBkcmFmdC1p ZXRmLWF2dGNvcmUtbW9uYXJjaC0wNA0KDQoNCiAgSGksICANCiAgSSBoYXZlIHJlYWQgZHJhZnQt aWV0Zi1hdnRjb3JlLW1vbmFyY2gtMDQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1Ymxp Y2F0aW9uLiANCiAgSSBoYXZlIG9ubHkgb25lIHN1Z2dlc3Rpb24gZm9yIGl0cyBjbGFyaXR5IG9m IGRyYWZ0LiANCiAgSW4gdGhlIHNlY3Rpb24gNS4yLCBpdCBtZW50aW9ucyB1c2luZyAiY2h1bmsi IA0KICB0byBjb252ZXkgY29ycmVsYXRpb24gaW5mb3JtYXRpb24sIHdvdWxkIGl0IGJldHRlciB0 byB1c2UgU0RFQyBpdGVtIHRvIHJlcGxhY2UgaXQ/IA0KICBBbHNvIHdvdWxkIGl0IGJldHRlciB0 byBlbXBoYXNpemUgdGhlIG5ldyBTREVTIGl0ZW0gaXMgcmVxdWlyZWQuIA0KICAgDQogIFJlZ2Fy ZHMhIA0KICBOaW5nIENhbyAgIA0KICBTaGFuZ0hhaSBSZXNlYXJjaCBJbnN0aXR1dGUgb2YgQ2hp bmEgVGVsZWNvbSBDb3Jwb3JhdGlvbiBMaW1pdGVkIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCiAgYXZ0QGlldGYub3Jn DQogIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo= --Boundary_(ID_NhHFhuCh8B9scjo9Zk9VMw) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTkxMjAiPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPkhpLE5pbmc6PC9ESVY+DQo8RElWPnlvdXIg Y2xhcmlmaWNhdGlvbiBsb29rcyBnb29kIHRvIG1lLCZuYnNwOzwvRElWPg0KPERJVj50aGUgbmV3 IHZlcnNpb24gd2lsbCByZWZsZWN0IHRoaXMgY2hhbmdlIHNvb24uPC9ESVY+DQo8RElWPlRoYW5r cyBmb3IgdGhlIHN1cHBvcnQsIDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UmVnYXJk cyE8L0RJVj4NCjxESVY+LVFpbjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxF RlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDog MHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9 IkZPTlQ6IDlwdCDlrovkvZMiPjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPi0t LS0tIE9yaWdpbmFsIA0KICBNZXNzYWdlIC0tLS0tIDwvRk9OVD48L0RJVj4NCiAgPERJViBzdHls ZT0iRk9OVDogOXB0IOWui+S9kzsgQkFDS0dST1VORDogI2U0ZTRlNDsgZm9udC1jb2xvcjogYmxh Y2siPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIHNpemU9Mz48Qj5Gcm9t OjwvQj4gPC9GT05UPjwvRk9OVD48QSANCiAgdGl0bGU9Y2FvbmluZ0BzdHRyaS5jb20uY24gaHJl Zj0ibWFpbHRvOmNhb25pbmdAc3R0cmkuY29tLmNuIj48Rk9OVCBzaXplPTMgDQogIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+5pu55a6BPC9GT05UPjwvQT48Rk9OVCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4gDQogIDwvRk9OVD48L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWu i+S9kyI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBzaXplPTM+PEI+VG86PC9C PiANCiAgPC9GT05UPjwvRk9OVD48QSB0aXRsZT1hdnRAaWV0Zi5vcmcgaHJlZj0ibWFpbHRvOmF2 dEBpZXRmLm9yZyI+PEZPTlQgc2l6ZT0zIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmF2dDwv Rk9OVD48L0E+PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IA0KICA8L0ZPTlQ+ PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PEZPTlQgDQogIHNpemU9Mz48Qj5TZW50OjwvQj4gRnJpZGF5LCBPY3RvYmVy IDIxLCAyMDExIDI6MzUgUE08L0ZPTlQ+PC9GT05UPjwvRElWPg0KICA8RElWIHN0eWxlPSJGT05U OiA5cHQg5a6L5L2TIj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIA0KICBzaXpl PTM+PEI+U3ViamVjdDo8L0I+IFtBVlRDT1JFXSBDb21tZW50cyBvbiANCiAgZHJhZnQtaWV0Zi1h dnRjb3JlLW1vbmFyY2gtMDQ8L0ZPTlQ+PC9GT05UPjwvRElWPg0KICA8RElWPjxCUj48L0RJVj4N CiAgPERJVj48U1BBTiBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPkhpLCZuYnNwOzwv U1BBTj4gPC9ESVY+DQogIDxESVY+DQogIDxESVY+SSBoYXZlIHJlYWQgPFNQQU4gc3R5bGU9IkZP TlQtU0laRTogMTJwdCIgDQogIGxhbmc9ZW4tVVM+ZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gt MDQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIA0KICBwdWJsaWNhdGlvbi48L1NQQU4+IDwv RElWPg0KICA8RElWPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiIGxhbmc9ZW4tVVM+SSBo YXZlIG9ubHkgb25lIHN1Z2dlc3Rpb24gZm9yIA0KICBpdHMgY2xhcml0eSBvZiBkcmFmdC48L1NQ QU4+IDwvRElWPg0KICA8RElWPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiIGxhbmc9ZW4t VVM+SW4gdGhlIHNlY3Rpb24gNS4yLCBpdCBtZW50aW9ucyANCiAgdXNpbmcgImNodW5rIjwvU1BB Tj4gPC9ESVY+DQogIDxESVY+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCIgbGFuZz1lbi1V Uz50byBjb252ZXkgY29ycmVsYXRpb24gDQogIGluZm9ybWF0aW9uLCB3b3VsZCBpdCBiZXR0ZXIg dG8gdXNlIFNERUMgaXRlbSB0byByZXBsYWNlIGl0PzwvU1BBTj4gPC9ESVY+DQogIDxESVY+PFNQ QU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCIgbGFuZz1lbi1VUz5BbHNvIHdvdWxkIGl0IGJldHRl ciANCiAgdG8mbmJzcDtlbXBoYXNpemUgdGhlIG5ldyBTREVTIGl0ZW0gaXMgcmVxdWlyZWQuPC9T UEFOPiA8L0RJVj4NCiAgPERJVj4gPC9ESVY+DQogIDxESVY+DQogIDxESVY+PFNQQU4gbGFuZz1l bi1VUz48Rk9OVCBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwLjVwdCI+UmVn YXJkcyE8L1NQQU4+IDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gbGFuZz1lbi1V Uz48Rk9OVCBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0Ij5OaW5nIA0KICBD YW88L1NQQU4+Jm5ic3A7PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0Ij4mbmJzcDs8L1NQ QU4+IDwvRk9OVD4NCiAgPERJVj5TaGFuZ0hhaSBSZXNlYXJjaCBJbnN0aXR1dGUgb2YgQ2hpbmEg VGVsZWNvbSBDb3Jwb3JhdGlvbiBMaW1pdGVkIA0KICA8L0RJVj48L1NQQU4+PC9ESVY+PC9ESVY+ PC9ESVY+DQogIDxQPg0KICA8SFI+DQoNCiAgPFA+PC9QPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPEJSPkF1ZGlvL1ZpZGVvIA0KICBUcmFuc3BvcnQgQ29y ZSANCiAgTWFpbnRlbmFuY2U8QlI+YXZ0QGlldGYub3JnPEJSPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYXZ0PEJSPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_NhHFhuCh8B9scjo9Zk9VMw)-- From ray.vanbrandenburg@tno.nl Fri Oct 21 00:13:46 2011 Return-Path: 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 64F3A21F858D for ; Fri, 21 Oct 2011 00:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 RsJ9vUK4ncfU for ; Fri, 21 Oct 2011 00:13:44 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id B059021F8562 for ; Fri, 21 Oct 2011 00:13:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,384,1315173600"; d="scan'208";a="59187266" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 21 Oct 2011 09:13:42 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.01.0323.003; Fri, 21 Oct 2011 09:13:41 +0200 From: "Brandenburg, R. (Ray) van" To: Qin Wu , Kevin Gross , IETF AVTCore WG Thread-Topic: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Thread-Index: AQHMj2AZ1xwxk8RC5UaH+/0nn1Dcj5WGGa8tgABHnZA= Date: Fri, 21 Oct 2011 07:13:41 +0000 Message-ID: References: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> In-Reply-To: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 07:13:47 -0000 Hi Qin, Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report o= n Packet Receipt Times and a 32bit NTP timestamp to report on Packet Presen= tation Times (plus a 32bit timestamp for the RTP timestamp). The reason we = initially went with only a 32bit NTP timestamp for Packet Presentation time= s was that we figured that the 16 most significant bits of the NTP time (e.= g. the date) would be the same for packet presentation and packet reception= times and that the least significant 16bits (for sub 15 microsecond accura= cy) would not be necessary. We therefore went with the middle 32 bits to li= mit the length of the IDMS packet.=20 What Kevin now suggests, is that in some use cases sub-15 microsecond accur= acy is necessary. He therefore proposes to increase the Packet Presentation= timestamp to 64bits. The only disadvantage with this approach (apart from = a slightly larger packet) is that this would break compatibility with the E= TSI TISPAN standard. Which way do you think we should go here? Best Regards, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin Wu Sent: vrijdag 21 oktober 2011 4:48 To: Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with ones de= fined in RFC3550? Regards! -Qin ----- Original Message ----- From: "Kevin Gross" To: "IETF AVTCore WG" Sent: Thursday, October 20, 2011 10:59 AM Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Part of my reason for bringing these use cases to the attention of the group relates to a yet unresolved comment I made against the IDMS draft. The draft proposes 64-bit timestamps for arrival times but only 32-bit timestamps for presentation times. A 32-bit NTP timestamp has a 15 microsecond precision. Presentation time synchronization with these timestamps would seem not to clearly meet the requirements of a couple of these use cases. Improving the protocol to support 64-bit timestamps throughout seems to be the straightforward solution. With this change, all timestamps would have the same precision and would have a precision comparable to their reference clocks. The problem with this is that our IDMS work is based on ETSI TISPAN standard TS 183 063. Efforts have been made in the draft to maintain compatibility with this standard. Changing the packet format to accommodate 64-bit timestamps will unravel those efforts. If ETSI compatibility is important, we will have to live with 15 microsecond precision and possibly suggest clever tricks to make the most of it. Which way do we want to go here? On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross wro= te: > The requirement for the stereo case is specified differently than the > others. The 10 microsecond figure there applies to _changes in latency_, = not > static difference in latency described in all the other cases. Tolerance = for > static differences for the stereo case are probably on the order of 1 > millisecond. The first-order effect of static latency differences is to m= ove > one of the speakers - just depends on how fussy you are about real vs. > effective speaker placement. > > > > The 10 microsecond figure is conservative (I've heard anecdotal claims of= 1 > microseconds sensitivity) and derives from our ability to accurately loca= te > sounds based (in part) on comparison of arrival times at each ear. The 10 > microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is. > Here's a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/HAP.ht= ml > (see Localisation of Sound Sources section) > > > > Throughout, I've tried to use what I consider reasonable and verifiable > requirements figures. Some will always seem to argue that they need better > performance. > > > > Kevin > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Tuesday, August 16, 2011 9:07 AM > To: IETF AVTCore WG > Subject: Re: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > Mr. Gross, > > The timing assertion for Networked stereo loudspeakers is much tighter th= at > I would have expected. Placement of stereo speakers within a foot is a > normal rule of thumb for the casual listener - and that is about 1.1ms > delta at room temperature. The ' golden ears' do have ability to detect > small differences especially with high attack waveforms, but I would like= to > see the study that showed this small time difference. Can you please prov= ide > a cite? > > And I wonder if the system requirement should be based on the smallest kn= own > delta, unless there is no implementation complexity added to convey the > suggested resolution. > > > > > > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone 202 429 5418 > Fax 202 775 4981 > www.nab.org > Advocacy Education Innovation > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kev= in > Gross > Sent: Monday, August 15, 2011 11:48 PM > To: 'IETF AVTCore WG' > Subject: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > In reviewing the IDMS draft I had volunteered to contribute additional use > cases. Ray Brandenberg suggested that I post them here. > > > > Kevin Gross > > AVA Networks > > Networked stereo loudspeakers > > Because of our ability to localize sound based on inter-aural time > differences, in a stereo listening situation, we are very sensitive to > changes in latency between the two speakers. These changes are perceived = as > a shift in or instability of the "sound stage" during critical listening. > These effects are readily noticeable with shifts of 10 microseconds or > smaller. If the individual speakers in a stereo listening setup operate f= rom > independent network interfaces any changing difference in latency between > the two speakers greater than 10 microseconds will be detrimental to the > listening experience. > > Conferencing sound reinforcement system > > A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms, > boardrooms, classrooms (especially those supporting distance learning) and > other such venues. Each participant using such a system has a microphone = and > a speaker. There may also be other speakers to provide reinforcement for > non-speaking participants such as in an audience area or jury box. Each > microphone/speaker pair is individually connected to a network and transm= its > digital audio to the other devices through the network and receives digit= al > audio to be reproduced through the speaker over the network. There may be= a > central appliance which receives, prioritizes and mixes the microphone > signals. In some systems an individual mix is created for each speaker su= ch > that a speaker's own voice does not come out from his speaker or from tho= se > immediately surrounding him. > > The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels amplifie= d. > Meeting this objective helps insure that natural person-to-person > communication is retained. To this end, it is desirable that the sound > through the system and from the speakers arrive 5 to 30 milliseconds after > the the sound arriving through the air from the person speaking. Delays in > this range invoke the Haas effect which allows listeners to locate the > person speaking based on the sound arriving through the air while the sou= nd > reinforcement system provides the additional gain required to achieve > desired intelligibility. It is also desirable for the sound to come out of > nearby speakers at within 5 milliseconds as longer differential delays wi= ll > be perceived as reverberation or echo. > > Video wall > > A video wall consists of multiple computer monitors, video projectors, or > television sets tiled together contiguously or overlapped in order to form > one large screen.# Each of the screens reproduces a portion of the larger > picture. In some implementations, each screen may be individually connect= ed > to the network and receive its portion of the overall image from a > network-connected video server or video scaler. Screens are refreshed at = 60 > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh is > not synchronized, the effect of multiple screens acting as one is broken. > > Phased array transducers > > Phased array and wave field synthesis techniques are increasingly used in > audio applications. These techniques work by sending or receiving slightly > different versions of a signal in a spacial sampling arrangement to produ= ce > or record spacial and directional sound fields. The individual transducers > in these applications can be extremely sensitive to differential latency. > Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise rati= o. > These microphones are also able to report the location of the speaker for > purposes of automatically aiming a video camera at them. > > Concert sound systems called line arrays allow technicians control over t= he > amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventing > sound from reaching the roof and back wall of the performance space, the > amount of reflected sound heard by the audience is reduced and the listen= ing > experience is improved. > > In these systems, accuracy in locating or emitting sound is related to > differential latency through basic trigonometry. In these applications, > microseconds of differential latency can translate to degrees of > uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired. > > _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From magnus.westerlund@ericsson.com Fri Oct 21 00:37:04 2011 Return-Path: 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 8B6E721F858C for ; Fri, 21 Oct 2011 00:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 P3E4vyZtUC5c for ; Fri, 21 Oct 2011 00:37:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 332A521F850B for ; Fri, 21 Oct 2011 00:37:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-d3-4ea1211ea066 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 00.B5.13753.E1121AE4; Fri, 21 Oct 2011 09:37:02 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Fri, 21 Oct 2011 09:37:01 +0200 Message-ID: <4EA12119.4090900@ericsson.com> Date: Fri, 21 Oct 2011 09:36:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: IETF AVTCore WG , draft-ietf-avtcore-monarch@tools.ietf.org X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 07:37:04 -0000 Hi I have reviewed the monitoring architecture draft and have the following comments. The review was to see if the document was ready for WG last call. My collected judgment is still some work to do. 1. Abstract: Instead of "... , as proposed in RFC5968." please write out the documents title. This should be done in more places where using references. 2. Section 1. " These rapidly emerging standards, such as RTCP XR [RFC3611]and other RTCP extension to Sender Reports(SR), Receiver Reports (RR) [RFC3550]are being developed" There is quite a lot of places in the draft where there is missing spaces. In the above example I am missing spaces at "[3611]and", "Reports(SR)" and "[RFC3550]are". 3. Section 1, third paragraph "QoS/QoE" please expand acronyms on first usage. 4. section 3. "Monitor is a functional component defined in RFC3550 that acts as a source of information gathered for monitoring purposes. It may also collect statistics from multiple source, stores such information reported by RTCP XR or other RTCP extension appropriately as base metric or calculates composite metric." Grammer in the above looks strange. First, isn't it "a" or "the" monitor? Secondly, "stores" looks wrong. 5. Section 3. "does not participate RTP session" Missing "in the" RTP session? 6. Section 3, figure 1: The "third party monitor" and the monitor in the management system box both seems strange. The management system monitor would more be a "report collector" or something like this than an actual monitor of the RTP sessions traffic. Similarly the third party monitor needs to on the media path as I understand it. What I can interpret from the definition in RFC 3550 the third party monitor sees the RTP and RTCP traffic but is not making itself visible to the RTP Session participants. Thus I think the figure needs to be changed to make the third party monitor to get the "1" arrow through itself. 7. Section 3.1: Isn't the first bullet "transport level statistics" actually part of the sentence prior to the bullet list? 8. Section 3.1: Missing spaces "Feedback [RFC4585]extends the standard A/V Profile[RFC3551]" "parameters.[RFC6332]" "and signalchanges in the desired" Section 4: "multicast inference of network characteristics(MINC)" 9. Section 4: "It is also fixed across multiple RTP sessions from the same source." I interpret "source" in the above as an end-point or RTP node. Which causes me to have the following comment. This is very commonly true, but not universally true. As CNAME identifies a synchronziation context, a given end-point could have media sources that belong to multiple synchronization contexts in the same session. For example have microphones and cameras from multiple rooms, where each room will be its own synchronization context. 10. Section 4, bullet 2: Title for RFC 6035 reference 11. Section 4, bullet 3: "However in some cases, Identity information may be not part of metric and include information more than the SSRC in the metric block, e.g., when we set a metric interval for the session and monitor RTP packets within one or several consecutive metric interval, extra identity information (e.g., sequence number of 1st packet) is expected, if we put such extra identity information into each metric block, there may be situations where an RTCP XR packet containing more than two metric blocks including the duplicated extra identity information, reports on the same streams from the same source. each block have the same extra identity information for measurement, if each metric block carry such duplicated data for the measurement, it leads to redundant information in this design since equivalent information is provided multiple times, once in *every* metric block." This is one of the longest sentences I have seen. It also has a stray "." in it. Please do something with this to make easier to grasp. 12. Section 4. bullet 3: This issues does not have a recommendation in the next section. I think we should document the WG consensus on this issue. Even if it was that this issue wasn't significant enough to do something about. Or am I remembering the WG consensus wrong? 13. Section 4: "Though this ensures immunity to packet loss, the design may bring more complexity and the overhead is not completely trivial in some cases." Can you please explain what "complexity" the above refers to? 14. Section 5.1 I think the section title should be changed to: "Using Single Metric Blocks" 15. Section 5.1. I would suggest that one replaces "small blocks" with single metric blocks. 16. Section 5.2: "(in gateway),e.g., one RTCP XR Packet" To many commas? 17. Section 5.2: "SSRC of source" missing "the"? 18. Section 5.2: A flow measurement tool that is not call-aware then forward the RTCP XR reports along with SSRC of the measured RTP stream which is included in the XR Block header to the network management system. Network management system can then correlate this report using SSRC with other diagnostic information such as call detail records. I guess the flow measurement tool is configured with the 5-tuple and that its reports to the management system using a binding to that 5-tuple when reporting. Should this be mentioned? 19. Section 6. The PDV reference is "work in progress" but you don't need to repeat it at all the places. And in fact, if you just do a normal informational reference to the internet draft the RFC-editor will add the "work in prgoress" in the reference list. 20. Section 6. "jit" field. To my knowledge the field you reference are named "interarrival jitter" in the RFC 3550 RTCP report block structures. 21. Section 7.1: Strictly the RTP end system can only conclude that its RTP has been lost in the network, though an RTP end system complying with the robustness principle of [RFC1122] should survive with essential functions unimpaired. What is the purpose with this sentence? And what is actually seen as "essential functions"? 22. Section 7.2: For bidirectional unicast, an RTP system may usually detect RTCP XR from a translator by noting that the sending SSRC is not present in any RTP media packet. So the assumption here is that the translator has its own SSRC to send these monitoring reports. But, how does an RTP node determine that an SSRC is associated with a translator rather than a receiver only end-point? From a session participant I don't think you can determine if a give SSRC is a receiver or just a monitor. They will not look different. One needs session configuration information, and in that case configuration information where the translator announces its node type to the management system. 23. Section 8. I agree that this draft shouldn't have a IANA Consideration other to say that it is has no actions. However, I think the document should consider if it has some guidance on IANA actions for the monitoring architecture. Some part of this is clearly about the consumption of XR block code points that isn't a major issue. And if we do run out a second RTCP packet type for XR block 2 could be assigned. 24. Section 9. I think this security consideration should be have some actual considerations. This is an architecture document for monitoring. Thus collecting the security issues with monitoring do sound like a good idea. For example privacy and leaking information. Need for having protection of the monitoring reports etc. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bill.wu@huawei.com Fri Oct 21 01:33:49 2011 Return-Path: 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 CAA2021F8B39 for ; Fri, 21 Oct 2011 01:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.642 X-Spam-Level: X-Spam-Status: No, score=-5.642 tagged_above=-999 required=5 tests=[AWL=0.957, BAYES_00=-2.599, 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 Ft8W0qQSqrUd for ; Fri, 21 Oct 2011 01:33:48 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF3421F8B35 for ; Fri, 21 Oct 2011 01:33:48 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00BKBQGBZD@szxga04-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 16:33:47 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00HYRQGBLX@szxga04-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 16:33:47 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEP41522; Fri, 21 Oct 2011 16:32:47 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 16:32:41 +0800 Received: from w53375q (10.138.41.130) by szxeml411-hub.china.huawei.com (10.82.67.138) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 16:32:38 +0800 Date: Fri, 21 Oct 2011 16:32:37 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: "Brandenburg, R. (Ray) van" , Kevin Gross , IETF AVTCore WG Message-id: <900CF177095B48F695F9DFC04E57907A@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 08:33:49 -0000 Is it important to save packet size in 32bits at the cost of the accuracy. It will be good to see the presentation times follow the format of 64bits NTP timestamp defined in RFC3550 for SR/RR report unless you have a more strong justification for it rather than say thi is not ETSI TISPAN standard compliant. But I am not judge, this is just my personal opinion. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ; "IETF AVTCore WG" Sent: Friday, October 21, 2011 3:13 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report on Packet Receipt Times and a 32bit NTP timestamp to report on Packet Presentation Times (plus a 32bit timestamp for the RTP timestamp). The reason we initially went with only a 32bit NTP timestamp for Packet Presentation times was that we figured that the 16 most significant bits of the NTP time (e.g. the date) would be the same for packet presentation and packet reception times and that the least significant 16bits (for sub 15 microsecond accuracy) would not be necessary. We therefore went with the middle 32 bits to limit the length of the IDMS packet. What Kevin now suggests, is that in some use cases sub-15 microsecond accuracy is necessary. He therefore proposes to increase the Packet Presentation timestamp to 64bits. The only disadvantage with this approach (apart from a slightly larger packet) is that this would break compatibility with the ETSI TISPAN standard. Which way do you think we should go here? Best Regards, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin Wu Sent: vrijdag 21 oktober 2011 4:48 To: Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with ones defined in RFC3550? Regards! -Qin ----- Original Message ----- From: "Kevin Gross" To: "IETF AVTCore WG" Sent: Thursday, October 20, 2011 10:59 AM Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Part of my reason for bringing these use cases to the attention of the group relates to a yet unresolved comment I made against the IDMS draft. The draft proposes 64-bit timestamps for arrival times but only 32-bit timestamps for presentation times. A 32-bit NTP timestamp has a 15 microsecond precision. Presentation time synchronization with these timestamps would seem not to clearly meet the requirements of a couple of these use cases. Improving the protocol to support 64-bit timestamps throughout seems to be the straightforward solution. With this change, all timestamps would have the same precision and would have a precision comparable to their reference clocks. The problem with this is that our IDMS work is based on ETSI TISPAN standard TS 183 063. Efforts have been made in the draft to maintain compatibility with this standard. Changing the packet format to accommodate 64-bit timestamps will unravel those efforts. If ETSI compatibility is important, we will have to live with 15 microsecond precision and possibly suggest clever tricks to make the most of it. Which way do we want to go here? On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross wrote: > The requirement for the stereo case is specified differently than the > others. The 10 microsecond figure there applies to _changes in latency_, not > static difference in latency described in all the other cases. Tolerance for > static differences for the stereo case are probably on the order of 1 > millisecond. The first-order effect of static latency differences is to move > one of the speakers - just depends on how fussy you are about real vs. > effective speaker placement. > > > > The 10 microsecond figure is conservative (I've heard anecdotal claims of 1 > microseconds sensitivity) and derives from our ability to accurately locate > sounds based (in part) on comparison of arrival times at each ear. The 10 > microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is. > Here's a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/HAP.html > (see Localisation of Sound Sources section) > > > > Throughout, I've tried to use what I consider reasonable and verifiable > requirements figures. Some will always seem to argue that they need better > performance. > > > > Kevin > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Tuesday, August 16, 2011 9:07 AM > To: IETF AVTCore WG > Subject: Re: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > Mr. Gross, > > The timing assertion for Networked stereo loudspeakers is much tighter that > I would have expected. Placement of stereo speakers within a foot is a > normal rule of thumb for the casual listener - and that is about 1.1ms > delta at room temperature. The ' golden ears' do have ability to detect > small differences especially with high attack waveforms, but I would like to > see the study that showed this small time difference. Can you please provide > a cite? > > And I wonder if the system requirement should be based on the smallest known > delta, unless there is no implementation complexity added to convey the > suggested resolution. > > > > > > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone 202 429 5418 > Fax 202 775 4981 > www.nab.org > Advocacy Education Innovation > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin > Gross > Sent: Monday, August 15, 2011 11:48 PM > To: 'IETF AVTCore WG' > Subject: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > In reviewing the IDMS draft I had volunteered to contribute additional use > cases. Ray Brandenberg suggested that I post them here. > > > > Kevin Gross > > AVA Networks > > Networked stereo loudspeakers > > Because of our ability to localize sound based on inter-aural time > differences, in a stereo listening situation, we are very sensitive to > changes in latency between the two speakers. These changes are perceived as > a shift in or instability of the "sound stage" during critical listening. > These effects are readily noticeable with shifts of 10 microseconds or > smaller. If the individual speakers in a stereo listening setup operate from > independent network interfaces any changing difference in latency between > the two speakers greater than 10 microseconds will be detrimental to the > listening experience. > > Conferencing sound reinforcement system > > A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms, > boardrooms, classrooms (especially those supporting distance learning) and > other such venues. Each participant using such a system has a microphone and > a speaker. There may also be other speakers to provide reinforcement for > non-speaking participants such as in an audience area or jury box. Each > microphone/speaker pair is individually connected to a network and transmits > digital audio to the other devices through the network and receives digital > audio to be reproduced through the speaker over the network. There may be a > central appliance which receives, prioritizes and mixes the microphone > signals. In some systems an individual mix is created for each speaker such > that a speaker's own voice does not come out from his speaker or from those > immediately surrounding him. > > The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels amplified. > Meeting this objective helps insure that natural person-to-person > communication is retained. To this end, it is desirable that the sound > through the system and from the speakers arrive 5 to 30 milliseconds after > the the sound arriving through the air from the person speaking. Delays in > this range invoke the Haas effect which allows listeners to locate the > person speaking based on the sound arriving through the air while the sound > reinforcement system provides the additional gain required to achieve > desired intelligibility. It is also desirable for the sound to come out of > nearby speakers at within 5 milliseconds as longer differential delays will > be perceived as reverberation or echo. > > Video wall > > A video wall consists of multiple computer monitors, video projectors, or > television sets tiled together contiguously or overlapped in order to form > one large screen.# Each of the screens reproduces a portion of the larger > picture. In some implementations, each screen may be individually connected > to the network and receive its portion of the overall image from a > network-connected video server or video scaler. Screens are refreshed at 60 > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh is > not synchronized, the effect of multiple screens acting as one is broken. > > Phased array transducers > > Phased array and wave field synthesis techniques are increasingly used in > audio applications. These techniques work by sending or receiving slightly > different versions of a signal in a spacial sampling arrangement to produce > or record spacial and directional sound fields. The individual transducers > in these applications can be extremely sensitive to differential latency. > Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise ratio. > These microphones are also able to report the location of the speaker for > purposes of automatically aiming a video camera at them. > > Concert sound systems called line arrays allow technicians control over the > amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventing > sound from reaching the roof and back wall of the performance space, the > amount of reflected sound heard by the audience is reduced and the listening > experience is improved. > > In these systems, accuracy in locating or emitting sound is related to > differential latency through basic trigonometry. In these applications, > microseconds of differential latency can translate to degrees of > uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired. > > _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer From bill.wu@huawei.com Fri Oct 21 02:05:26 2011 Return-Path: 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 9630D21F8B77 for ; Fri, 21 Oct 2011 02:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 4DbS1wKKrcHw for ; Fri, 21 Oct 2011 02:05:25 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BA2B121F8B75 for ; Fri, 21 Oct 2011 02:05:22 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00FKARTOZS@szxga04-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 17:03:24 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00BYYRTDZ8@szxga04-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 17:03:24 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEP44032; Fri, 21 Oct 2011 17:03:24 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 17:03:18 +0800 Received: from w53375q (10.138.41.130) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 17:03:14 +0800 Date: Fri, 21 Oct 2011 17:03:14 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Magnus Westerlund , IETF AVTCore WG , draft-ietf-avtcore-monarch@tools.ietf.org Message-id: <0C80BD8E8293426DB3C50CC7F1ECB0F1@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4EA12119.4090900@ericsson.com> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:05:26 -0000 SGksTWFnbnVzOg0KSSB3aWxsIHJlc3BvbmQgdG8geW91ciBjb21tZW50cyBhbmQgdXBkYXRlIHRo ZSBkcmFmdCBzb29uLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCkZyb206ICJNYWdudXMgV2VzdGVybHVuZCIgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNz c29uLmNvbT4NClRvOiAiSUVURiBBVlRDb3JlIFdHIiA8YXZ0QGlldGYub3JnPjsgPGRyYWZ0LWll dGYtYXZ0Y29yZS1tb25hcmNoQHRvb2xzLmlldGYub3JnPg0KU2VudDogRnJpZGF5LCBPY3RvYmVy IDIxLCAyMDExIDM6MzYgUE0NClN1YmplY3Q6IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtYXZ0Y29y ZS1tb25hcmNoLTA0DQoNCg0KSGkNCg0KSSBoYXZlIHJldmlld2VkIHRoZSBtb25pdG9yaW5nIGFy Y2hpdGVjdHVyZSBkcmFmdCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nDQpjb21tZW50cy4gVGhlIHJl dmlldyB3YXMgdG8gc2VlIGlmIHRoZSBkb2N1bWVudCB3YXMgcmVhZHkgZm9yIFdHIGxhc3QNCmNh bGwuIE15IGNvbGxlY3RlZCBqdWRnbWVudCBpcyBzdGlsbCBzb21lIHdvcmsgdG8gZG8uDQoNCjEu IEFic3RyYWN0OiBJbnN0ZWFkIG9mICIuLi4gLCBhcyBwcm9wb3NlZCBpbiBSRkM1OTY4LiIgcGxl YXNlIHdyaXRlIG91dA0KdGhlIGRvY3VtZW50cyB0aXRsZS4gVGhpcyBzaG91bGQgYmUgZG9uZSBp biBtb3JlIHBsYWNlcyB3aGVyZSB1c2luZw0KcmVmZXJlbmNlcy4NCg0KMi4gU2VjdGlvbiAxLg0K IiAgVGhlc2UgcmFwaWRseSBlbWVyZ2luZw0KICAgc3RhbmRhcmRzLCBzdWNoIGFzIFJUQ1AgWFIg W1JGQzM2MTFdYW5kIG90aGVyIFJUQ1AgZXh0ZW5zaW9uIHRvDQogICBTZW5kZXIgUmVwb3J0cyhT UiksIFJlY2VpdmVyIFJlcG9ydHMgKFJSKSBbUkZDMzU1MF1hcmUgYmVpbmcNCiAgIGRldmVsb3Bl ZCINCg0KVGhlcmUgaXMgcXVpdGUgYSBsb3Qgb2YgcGxhY2VzIGluIHRoZSBkcmFmdCB3aGVyZSB0 aGVyZSBpcyBtaXNzaW5nDQpzcGFjZXMuIEluIHRoZSBhYm92ZSBleGFtcGxlIEkgYW0gbWlzc2lu ZyBzcGFjZXMgYXQgIlszNjExXWFuZCIsDQoiUmVwb3J0cyhTUikiIGFuZCAiW1JGQzM1NTBdYXJl Ii4NCg0KMy4gU2VjdGlvbiAxLCB0aGlyZCBwYXJhZ3JhcGgNCiJRb1MvUW9FIiBwbGVhc2UgZXhw YW5kIGFjcm9ueW1zIG9uIGZpcnN0IHVzYWdlLg0KDQo0LiBzZWN0aW9uIDMuDQogICJNb25pdG9y IGlzIGEgZnVuY3Rpb25hbCBjb21wb25lbnQgZGVmaW5lZCBpbiBSRkMzNTUwIHRoYXQgYWN0cyBh cyBhDQogICBzb3VyY2Ugb2YgaW5mb3JtYXRpb24gZ2F0aGVyZWQgZm9yIG1vbml0b3JpbmcgcHVy cG9zZXMuIEl0IG1heSBhbHNvDQogICBjb2xsZWN0IHN0YXRpc3RpY3MgZnJvbSBtdWx0aXBsZSBz b3VyY2UsIHN0b3JlcyBzdWNoIGluZm9ybWF0aW9uDQogICByZXBvcnRlZCBieSBSVENQIFhSIG9y IG90aGVyIFJUQ1AgZXh0ZW5zaW9uIGFwcHJvcHJpYXRlbHkgYXMgYmFzZQ0KICAgbWV0cmljIG9y IGNhbGN1bGF0ZXMgY29tcG9zaXRlIG1ldHJpYy4iDQoNCkdyYW1tZXIgaW4gdGhlIGFib3ZlIGxv b2tzIHN0cmFuZ2UuIEZpcnN0LCBpc24ndCBpdCAiYSIgb3IgInRoZSINCm1vbml0b3I/IFNlY29u ZGx5LCAic3RvcmVzIiBsb29rcyB3cm9uZy4NCg0KNS4gU2VjdGlvbiAzLg0KImRvZXMgbm90IHBh cnRpY2lwYXRlIFJUUCBzZXNzaW9uIg0KDQpNaXNzaW5nICJpbiB0aGUiIFJUUCBzZXNzaW9uPw0K DQo2LiBTZWN0aW9uIDMsIGZpZ3VyZSAxOg0KVGhlICJ0aGlyZCBwYXJ0eSBtb25pdG9yIiBhbmQg dGhlIG1vbml0b3IgaW4gdGhlIG1hbmFnZW1lbnQgc3lzdGVtIGJveA0KYm90aCBzZWVtcyBzdHJh bmdlLiBUaGUgbWFuYWdlbWVudCBzeXN0ZW0gbW9uaXRvciB3b3VsZCBtb3JlIGJlIGENCiJyZXBv cnQgY29sbGVjdG9yIiBvciBzb21ldGhpbmcgbGlrZSB0aGlzIHRoYW4gYW4gYWN0dWFsIG1vbml0 b3Igb2YgdGhlDQpSVFAgc2Vzc2lvbnMgdHJhZmZpYy4gU2ltaWxhcmx5IHRoZSB0aGlyZCBwYXJ0 eSBtb25pdG9yIG5lZWRzIHRvIG9uIHRoZQ0KbWVkaWEgcGF0aCBhcyBJIHVuZGVyc3RhbmQgaXQu IFdoYXQgSSBjYW4gaW50ZXJwcmV0IGZyb20gdGhlIGRlZmluaXRpb24NCmluIFJGQyAzNTUwIHRo ZSB0aGlyZCBwYXJ0eSBtb25pdG9yIHNlZXMgdGhlIFJUUCBhbmQgUlRDUCB0cmFmZmljIGJ1dCBp cw0Kbm90IG1ha2luZyBpdHNlbGYgdmlzaWJsZSB0byB0aGUgUlRQIFNlc3Npb24gcGFydGljaXBh bnRzLiBUaHVzIEkgdGhpbmsNCnRoZSBmaWd1cmUgbmVlZHMgdG8gYmUgY2hhbmdlZCB0byBtYWtl IHRoZSB0aGlyZCBwYXJ0eSBtb25pdG9yIHRvIGdldA0KdGhlICIxIiBhcnJvdyB0aHJvdWdoIGl0 c2VsZi4NCg0KNy4gU2VjdGlvbiAzLjE6DQoNCklzbid0IHRoZSBmaXJzdCBidWxsZXQgInRyYW5z cG9ydCBsZXZlbCBzdGF0aXN0aWNzIiBhY3R1YWxseSBwYXJ0IG9mIHRoZQ0Kc2VudGVuY2UgcHJp b3IgdG8gdGhlIGJ1bGxldCBsaXN0Pw0KDQo4LiBTZWN0aW9uIDMuMToNCk1pc3Npbmcgc3BhY2Vz DQoNCiJGZWVkYmFjayBbUkZDNDU4NV1leHRlbmRzIHRoZSBzdGFuZGFyZCBBL1YgUHJvZmlsZVtS RkMzNTUxXSINCiJwYXJhbWV0ZXJzLltSRkM2MzMyXSINCiJhbmQgc2lnbmFsY2hhbmdlcyBpbiB0 aGUgZGVzaXJlZCINClNlY3Rpb24gNDogIm11bHRpY2FzdA0KICAgICAgaW5mZXJlbmNlIG9mIG5l dHdvcmsgY2hhcmFjdGVyaXN0aWNzKE1JTkMpIg0KDQo5LiBTZWN0aW9uIDQ6DQoiSXQgaXMgYWxz bw0KICAgICAgZml4ZWQgYWNyb3NzIG11bHRpcGxlIFJUUCBzZXNzaW9ucyBmcm9tIHRoZSBzYW1l IHNvdXJjZS4iDQoNCkkgaW50ZXJwcmV0ICJzb3VyY2UiIGluIHRoZSBhYm92ZSBhcyBhbiBlbmQt cG9pbnQgb3IgUlRQIG5vZGUuIFdoaWNoDQpjYXVzZXMgbWUgdG8gaGF2ZSB0aGUgZm9sbG93aW5n IGNvbW1lbnQuDQoNClRoaXMgaXMgdmVyeSBjb21tb25seSB0cnVlLCBidXQgbm90IHVuaXZlcnNh bGx5IHRydWUuIEFzIENOQU1FDQppZGVudGlmaWVzIGEgc3luY2hyb256aWF0aW9uIGNvbnRleHQs IGEgZ2l2ZW4gZW5kLXBvaW50IGNvdWxkIGhhdmUgbWVkaWENCnNvdXJjZXMgdGhhdCBiZWxvbmcg dG8gbXVsdGlwbGUgc3luY2hyb25pemF0aW9uIGNvbnRleHRzIGluIHRoZSBzYW1lDQpzZXNzaW9u LiBGb3IgZXhhbXBsZSBoYXZlIG1pY3JvcGhvbmVzIGFuZCBjYW1lcmFzIGZyb20gbXVsdGlwbGUg cm9vbXMsDQp3aGVyZSBlYWNoIHJvb20gd2lsbCBiZSBpdHMgb3duIHN5bmNocm9uaXphdGlvbiBj b250ZXh0Lg0KDQoxMC4gU2VjdGlvbiA0LCBidWxsZXQgMjogVGl0bGUgZm9yIFJGQyA2MDM1IHJl ZmVyZW5jZQ0KDQoxMS4gU2VjdGlvbiA0LCBidWxsZXQgMzoNCiAgICAgIkhvd2V2ZXIgaW4gc29t ZSBjYXNlcywgSWRlbnRpdHkgaW5mb3JtYXRpb24gbWF5IGJlDQogICAgICBub3QgcGFydCBvZiBt ZXRyaWMgYW5kIGluY2x1ZGUgaW5mb3JtYXRpb24gbW9yZSB0aGFuIHRoZSBTU1JDIGluDQogICAg ICB0aGUgbWV0cmljIGJsb2NrLCBlLmcuLCB3aGVuIHdlIHNldCBhIG1ldHJpYyBpbnRlcnZhbCBm b3IgdGhlDQogICAgICBzZXNzaW9uIGFuZCBtb25pdG9yIFJUUCBwYWNrZXRzIHdpdGhpbiBvbmUg b3Igc2V2ZXJhbCBjb25zZWN1dGl2ZQ0KICAgICAgbWV0cmljIGludGVydmFsLCBleHRyYSBpZGVu dGl0eSBpbmZvcm1hdGlvbiAoZS5nLiwgc2VxdWVuY2UgbnVtYmVyDQogICAgICBvZiAxc3QgcGFj a2V0KSBpcyBleHBlY3RlZCwgaWYgd2UgcHV0IHN1Y2ggZXh0cmEgaWRlbnRpdHkNCiAgICAgIGlu Zm9ybWF0aW9uIGludG8gZWFjaCBtZXRyaWMgYmxvY2ssIHRoZXJlIG1heSBiZSBzaXR1YXRpb25z IHdoZXJlDQogICAgICBhbiBSVENQIFhSIHBhY2tldCBjb250YWluaW5nIG1vcmUgdGhhbiB0d28g bWV0cmljIGJsb2NrcyBpbmNsdWRpbmcNCiAgICAgIHRoZSBkdXBsaWNhdGVkIGV4dHJhIGlkZW50 aXR5IGluZm9ybWF0aW9uLCByZXBvcnRzIG9uIHRoZSBzYW1lDQogICAgICBzdHJlYW1zIGZyb20g dGhlIHNhbWUgc291cmNlLiBlYWNoIGJsb2NrIGhhdmUgdGhlIHNhbWUgZXh0cmENCiAgICAgIGlk ZW50aXR5IGluZm9ybWF0aW9uIGZvciBtZWFzdXJlbWVudCwgaWYgZWFjaCBtZXRyaWMgYmxvY2sg Y2FycnkNCiAgICAgIHN1Y2ggZHVwbGljYXRlZCBkYXRhIGZvciB0aGUgbWVhc3VyZW1lbnQsIGl0 IGxlYWRzIHRvIHJlZHVuZGFudA0KICAgICAgaW5mb3JtYXRpb24gaW4gdGhpcyBkZXNpZ24gc2lu Y2UgZXF1aXZhbGVudCBpbmZvcm1hdGlvbiBpcw0KICAgICAgcHJvdmlkZWQgbXVsdGlwbGUgdGlt ZXMsIG9uY2UgaW4gKmV2ZXJ5KiBtZXRyaWMgYmxvY2suIg0KDQpUaGlzIGlzIG9uZSBvZiB0aGUg bG9uZ2VzdCBzZW50ZW5jZXMgSSBoYXZlIHNlZW4uIEl0IGFsc28gaGFzIGEgc3RyYXkNCiIuIiBp biBpdC4gUGxlYXNlIGRvIHNvbWV0aGluZyB3aXRoIHRoaXMgdG8gbWFrZSBlYXNpZXIgdG8gZ3Jh c3AuDQoNCjEyLiBTZWN0aW9uIDQuIGJ1bGxldCAzOg0KVGhpcyBpc3N1ZXMgZG9lcyBub3QgaGF2 ZSBhIHJlY29tbWVuZGF0aW9uIGluIHRoZSBuZXh0IHNlY3Rpb24uIEkgdGhpbmsNCndlIHNob3Vs ZCBkb2N1bWVudCB0aGUgV0cgY29uc2Vuc3VzIG9uIHRoaXMgaXNzdWUuIEV2ZW4gaWYgaXQgd2Fz IHRoYXQNCnRoaXMgaXNzdWUgd2Fzbid0IHNpZ25pZmljYW50IGVub3VnaCB0byBkbyBzb21ldGhp bmcgYWJvdXQuIE9yIGFtIEkNCnJlbWVtYmVyaW5nIHRoZSBXRyBjb25zZW5zdXMgd3Jvbmc/DQoN CjEzLiBTZWN0aW9uIDQ6DQoiVGhvdWdoDQogICAgICB0aGlzIGVuc3VyZXMgaW1tdW5pdHkgdG8g cGFja2V0IGxvc3MsIHRoZSBkZXNpZ24gbWF5IGJyaW5nIG1vcmUNCiAgICAgIGNvbXBsZXhpdHkg YW5kIHRoZSBvdmVyaGVhZCBpcyBub3QgY29tcGxldGVseSB0cml2aWFsIGluIHNvbWUNCiAgICAg IGNhc2VzLiINCg0KQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbiB3aGF0ICJjb21wbGV4aXR5IiB0aGUg YWJvdmUgcmVmZXJzIHRvPw0KDQoxNC4gU2VjdGlvbiA1LjENCg0KSSB0aGluayB0aGUgc2VjdGlv biB0aXRsZSBzaG91bGQgYmUgY2hhbmdlZCB0bzogIlVzaW5nIFNpbmdsZSBNZXRyaWMgQmxvY2tz Ig0KDQoxNS4gU2VjdGlvbiA1LjEuIEkgd291bGQgc3VnZ2VzdCB0aGF0IG9uZSByZXBsYWNlcyAi c21hbGwgYmxvY2tzIiB3aXRoDQpzaW5nbGUgbWV0cmljIGJsb2Nrcy4NCg0KMTYuIFNlY3Rpb24g NS4yOg0KIihpbiBnYXRld2F5KSxlLmcuLCBvbmUgUlRDUCBYUiBQYWNrZXQiDQoNClRvIG1hbnkg Y29tbWFzPw0KDQoxNy4gU2VjdGlvbiA1LjI6DQoiU1NSQyBvZiBzb3VyY2UiIG1pc3NpbmcgInRo ZSI/DQoNCjE4LiBTZWN0aW9uIDUuMjoNCiBBIGZsb3cgbWVhc3VyZW1lbnQgdG9vbCB0aGF0IGlz IG5vdCBjYWxsLWF3YXJlDQogICB0aGVuIGZvcndhcmQgdGhlIFJUQ1AgWFIgcmVwb3J0cyBhbG9u ZyB3aXRoIFNTUkMgb2YgdGhlIG1lYXN1cmVkIFJUUA0KICAgc3RyZWFtIHdoaWNoIGlzIGluY2x1 ZGVkIGluIHRoZSBYUiBCbG9jayBoZWFkZXIgdG8gdGhlIG5ldHdvcmsNCiAgIG1hbmFnZW1lbnQg c3lzdGVtLiAgTmV0d29yayBtYW5hZ2VtZW50IHN5c3RlbSBjYW4gdGhlbiBjb3JyZWxhdGUgdGhp cw0KICAgcmVwb3J0IHVzaW5nIFNTUkMgd2l0aCBvdGhlciBkaWFnbm9zdGljIGluZm9ybWF0aW9u IHN1Y2ggYXMgY2FsbA0KICAgZGV0YWlsIHJlY29yZHMuDQoNCkkgZ3Vlc3MgdGhlIGZsb3cgbWVh c3VyZW1lbnQgdG9vbCBpcyBjb25maWd1cmVkIHdpdGggdGhlIDUtdHVwbGUgYW5kDQp0aGF0IGl0 cyByZXBvcnRzIHRvIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSB1c2luZyBhIGJpbmRpbmcgdG8gdGhh dA0KNS10dXBsZSB3aGVuIHJlcG9ydGluZy4gU2hvdWxkIHRoaXMgYmUgbWVudGlvbmVkPw0KDQox OS4gU2VjdGlvbiA2Lg0KVGhlIFBEViByZWZlcmVuY2UgaXMgIndvcmsgaW4gcHJvZ3Jlc3MiIGJ1 dCB5b3UgZG9uJ3QgbmVlZCB0byByZXBlYXQgaXQNCmF0IGFsbCB0aGUgcGxhY2VzLiBBbmQgaW4g ZmFjdCwgaWYgeW91IGp1c3QgZG8gYSBub3JtYWwgaW5mb3JtYXRpb25hbA0KcmVmZXJlbmNlIHRv IHRoZSBpbnRlcm5ldCBkcmFmdCB0aGUgUkZDLWVkaXRvciB3aWxsIGFkZCB0aGUgIndvcmsgaW4N CnByZ29yZXNzIiBpbiB0aGUgcmVmZXJlbmNlIGxpc3QuDQoNCjIwLiBTZWN0aW9uIDYuDQoiaml0 IiBmaWVsZC4gVG8gbXkga25vd2xlZGdlIHRoZSBmaWVsZCB5b3UgcmVmZXJlbmNlIGFyZSBuYW1l ZA0KImludGVyYXJyaXZhbCBqaXR0ZXIiIGluIHRoZSBSRkMgMzU1MCBSVENQIHJlcG9ydCBibG9j ayBzdHJ1Y3R1cmVzLg0KDQoyMS4gU2VjdGlvbiA3LjE6DQoNClN0cmljdGx5IHRoZSBSVFAgZW5k DQogICBzeXN0ZW0gY2FuIG9ubHkgY29uY2x1ZGUgdGhhdCBpdHMgUlRQIGhhcyBiZWVuIGxvc3Qg aW4gdGhlIG5ldHdvcmssDQogICB0aG91Z2ggYW4gUlRQIGVuZCBzeXN0ZW0gY29tcGx5aW5nIHdp dGggdGhlIHJvYnVzdG5lc3MgcHJpbmNpcGxlIG9mDQogICBbUkZDMTEyMl0gc2hvdWxkIHN1cnZp dmUgd2l0aCBlc3NlbnRpYWwgZnVuY3Rpb25zIHVuaW1wYWlyZWQuDQoNCldoYXQgaXMgdGhlIHB1 cnBvc2Ugd2l0aCB0aGlzIHNlbnRlbmNlPyBBbmQgd2hhdCBpcyBhY3R1YWxseSBzZWVuIGFzDQoi ZXNzZW50aWFsIGZ1bmN0aW9ucyI/DQoNCjIyLiBTZWN0aW9uIDcuMjoNCkZvciBiaWRpcmVjdGlv bmFsIHVuaWNhc3QsIGFuIFJUUCBzeXN0ZW0gbWF5IHVzdWFsbHkgZGV0ZWN0IFJUQ1AgWFINCiAg IGZyb20gYSB0cmFuc2xhdG9yIGJ5IG5vdGluZyB0aGF0IHRoZSBzZW5kaW5nIFNTUkMgaXMgbm90 IHByZXNlbnQgaW4NCiAgIGFueSBSVFAgbWVkaWEgcGFja2V0Lg0KDQpTbyB0aGUgYXNzdW1wdGlv biBoZXJlIGlzIHRoYXQgdGhlIHRyYW5zbGF0b3IgaGFzIGl0cyBvd24gU1NSQyB0byBzZW5kDQp0 aGVzZSBtb25pdG9yaW5nIHJlcG9ydHMuIEJ1dCwgaG93IGRvZXMgYW4gUlRQIG5vZGUgZGV0ZXJt aW5lIHRoYXQgYW4NClNTUkMgaXMgYXNzb2NpYXRlZCB3aXRoIGEgdHJhbnNsYXRvciByYXRoZXIg dGhhbiBhIHJlY2VpdmVyIG9ubHkNCmVuZC1wb2ludD8gRnJvbSBhIHNlc3Npb24gcGFydGljaXBh bnQgSSBkb24ndCB0aGluayB5b3UgY2FuIGRldGVybWluZSBpZg0KYSBnaXZlIFNTUkMgaXMgYSBy ZWNlaXZlciBvciBqdXN0IGEgbW9uaXRvci4gVGhleSB3aWxsIG5vdCBsb29rDQpkaWZmZXJlbnQu IE9uZSBuZWVkcyBzZXNzaW9uIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24sIGFuZCBpbiB0aGF0 IGNhc2UNCmNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gd2hlcmUgdGhlIHRyYW5zbGF0b3IgYW5u b3VuY2VzIGl0cyBub2RlIHR5cGUNCnRvIHRoZSBtYW5hZ2VtZW50IHN5c3RlbS4NCg0KMjMuIFNl Y3Rpb24gOC4gSSBhZ3JlZSB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkbid0IGhhdmUgYSBJQU5BDQpD b25zaWRlcmF0aW9uIG90aGVyIHRvIHNheSB0aGF0IGl0IGlzIGhhcyBubyBhY3Rpb25zLiBIb3dl dmVyLCBJIHRoaW5rDQp0aGUgZG9jdW1lbnQgc2hvdWxkIGNvbnNpZGVyIGlmIGl0IGhhcyBzb21l IGd1aWRhbmNlIG9uIElBTkEgYWN0aW9ucyBmb3INCnRoZSBtb25pdG9yaW5nIGFyY2hpdGVjdHVy ZS4gU29tZSBwYXJ0IG9mIHRoaXMgaXMgY2xlYXJseSBhYm91dCB0aGUNCmNvbnN1bXB0aW9uIG9m IFhSIGJsb2NrIGNvZGUgcG9pbnRzIHRoYXQgaXNuJ3QgYSBtYWpvciBpc3N1ZS4gQW5kIGlmIHdl DQpkbyBydW4gb3V0IGEgc2Vjb25kIFJUQ1AgcGFja2V0IHR5cGUgZm9yIFhSIGJsb2NrIDIgY291 bGQgYmUgYXNzaWduZWQuDQoNCjI0LiBTZWN0aW9uIDkuDQpJIHRoaW5rIHRoaXMgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbiBzaG91bGQgYmUgaGF2ZSBzb21lIGFjdHVhbA0KY29uc2lkZXJhdGlvbnMu IFRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGZvciBtb25pdG9yaW5nLiBUaHVzDQpj b2xsZWN0aW5nIHRoZSBzZWN1cml0eSBpc3N1ZXMgd2l0aCBtb25pdG9yaW5nIGRvIHNvdW5kIGxp a2UgYSBnb29kDQppZGVhLiBGb3IgZXhhbXBsZSBwcml2YWN5IGFuZCBsZWFraW5nIGluZm9ybWF0 aW9uLiBOZWVkIGZvciBoYXZpbmcNCnByb3RlY3Rpb24gb2YgdGhlIG1vbml0b3JpbmcgcmVwb3J0 cyBldGMuDQoNCkNoZWVycw0KDQpNYWdudXMgV2VzdGVybHVuZA0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpN dWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgy ODcNCkbkcvZnYXRhbiA2ICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQpT RS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From ray.vanbrandenburg@tno.nl Fri Oct 21 02:20:03 2011 Return-Path: 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 65CD921F8B9B for ; Fri, 21 Oct 2011 02:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 oinKvQQhkZcL for ; Fri, 21 Oct 2011 02:20:01 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4A121F8B8D for ; Fri, 21 Oct 2011 02:20:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,384,1315173600"; d="scan'208";a="59195236" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 21 Oct 2011 11:19:36 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0323.003; Fri, 21 Oct 2011 11:19:36 +0200 From: "Brandenburg, R. (Ray) van" To: Qin Wu , Kevin Gross , IETF AVTCore WG Thread-Topic: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Thread-Index: AQHMj2AZ1xwxk8RC5UaH+/0nn1Dcj5WGGa8tgABHnZCAABhWuIAADDrA Date: Fri, 21 Oct 2011 09:19:35 +0000 Message-ID: References: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> <900CF177095B48F695F9DFC04E57907A@china.huawei.com> In-Reply-To: <900CF177095B48F695F9DFC04E57907A@china.huawei.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:20:03 -0000 Hi Qin, Thanks for comments.=20 > Is it important to save packet size in 32bits at the cost of the accuracy= . > It will be good to see the presentation times follow the format of 64bits= NTP timestamp defined in RFC3550 for SR/RR report unless you have a more s= trong justification for it rather than say thi is not ETSI TISPAN standard = compliant. These statements seem to be contradictory. Do you mean you want to see the = presentation field extended to 64bits, or do you want to keep it at 32bits = to save packet length? Ray -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: vrijdag 21 oktober 2011 10:33 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Is it important to save packet size in 32bits at the cost of the accuracy. It will be good to see the presentation times follow the format of 64bits N= TP timestamp defined in RFC3550 for SR/RR report unless you have a more str= ong justification for it rather than say thi is not ETSI TISPAN standard co= mpliant. But I am not judge, this is just my personal opinion. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Friday, October 21, 2011 3:13 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report o= n Packet Receipt Times and a 32bit NTP timestamp to report on Packet Presen= tation Times (plus a 32bit timestamp for the RTP timestamp). The reason we = initially went with only a 32bit NTP timestamp for Packet Presentation time= s was that we figured that the 16 most significant bits of the NTP time (e.= g. the date) would be the same for packet presentation and packet reception= times and that the least significant 16bits (for sub 15 microsecond accura= cy) would not be necessary. We therefore went with the middle 32 bits to li= mit the length of the IDMS packet.=20 What Kevin now suggests, is that in some use cases sub-15 microsecond accur= acy is necessary. He therefore proposes to increase the Packet Presentation= timestamp to 64bits. The only disadvantage with this approach (apart from = a slightly larger packet) is that this would break compatibility with the E= TSI TISPAN standard. Which way do you think we should go here? Best Regards, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin W= u Sent: vrijdag 21 oktober 2011 4:48 To: Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with ones de= fined in RFC3550? Regards! -Qin ----- Original Message ----- From: "Kevin Gross" To: "IETF AVTCore WG" Sent: Thursday, October 20, 2011 10:59 AM Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Part of my reason for bringing these use cases to the attention of the group relates to a yet unresolved comment I made against the IDMS draft. The draft proposes 64-bit timestamps for arrival times but only 32-bit timestamps for presentation times. A 32-bit NTP timestamp has a 15 microsecond precision. Presentation time synchronization with these timestamps would seem not to clearly meet the requirements of a couple of these use cases. Improving the protocol to support 64-bit timestamps throughout seems to be the straightforward solution. With this change, all timestamps would have the same precision and would have a precision comparable to their reference clocks. The problem with this is that our IDMS work is based on ETSI TISPAN standard TS 183 063. Efforts have been made in the draft to maintain compatibility with this standard. Changing the packet format to accommodate 64-bit timestamps will unravel those efforts. If ETSI compatibility is important, we will have to live with 15 microsecond precision and possibly suggest clever tricks to make the most of it. Which way do we want to go here? On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross wro= te: > The requirement for the stereo case is specified differently than the > others. The 10 microsecond figure there applies to _changes in latency_, = not > static difference in latency described in all the other cases. Tolerance = for > static differences for the stereo case are probably on the order of 1 > millisecond. The first-order effect of static latency differences is to m= ove > one of the speakers - just depends on how fussy you are about real vs. > effective speaker placement. > > > > The 10 microsecond figure is conservative (I've heard anecdotal claims of= 1 > microseconds sensitivity) and derives from our ability to accurately loca= te > sounds based (in part) on comparison of arrival times at each ear. The 10 > microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is. > Here's a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/HAP.ht= ml > (see Localisation of Sound Sources section) > > > > Throughout, I've tried to use what I consider reasonable and verifiable > requirements figures. Some will always seem to argue that they need bette= r > performance. > > > > Kevin > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Tuesday, August 16, 2011 9:07 AM > To: IETF AVTCore WG > Subject: Re: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > Mr. Gross, > > The timing assertion for Networked stereo loudspeakers is much tighter th= at > I would have expected. Placement of stereo speakers within a foot is a > normal rule of thumb for the casual listener - and that is about 1.1ms > delta at room temperature. The ' golden ears' do have ability to detect > small differences especially with high attack waveforms, but I would like= to > see the study that showed this small time difference. Can you please prov= ide > a cite? > > And I wonder if the system requirement should be based on the smallest kn= own > delta, unless there is no implementation complexity added to convey the > suggested resolution. > > > > > > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone 202 429 5418 > Fax 202 775 4981 > www.nab.org > Advocacy Education Innovation > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kev= in > Gross > Sent: Monday, August 15, 2011 11:48 PM > To: 'IETF AVTCore WG' > Subject: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > In reviewing the IDMS draft I had volunteered to contribute additional us= e > cases. Ray Brandenberg suggested that I post them here. > > > > Kevin Gross > > AVA Networks > > Networked stereo loudspeakers > > Because of our ability to localize sound based on inter-aural time > differences, in a stereo listening situation, we are very sensitive to > changes in latency between the two speakers. These changes are perceived = as > a shift in or instability of the "sound stage" during critical listening. > These effects are readily noticeable with shifts of 10 microseconds or > smaller. If the individual speakers in a stereo listening setup operate f= rom > independent network interfaces any changing difference in latency between > the two speakers greater than 10 microseconds will be detrimental to the > listening experience. > > Conferencing sound reinforcement system > > A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms, > boardrooms, classrooms (especially those supporting distance learning) an= d > other such venues. Each participant using such a system has a microphone = and > a speaker. There may also be other speakers to provide reinforcement for > non-speaking participants such as in an audience area or jury box. Each > microphone/speaker pair is individually connected to a network and transm= its > digital audio to the other devices through the network and receives digit= al > audio to be reproduced through the speaker over the network. There may be= a > central appliance which receives, prioritizes and mixes the microphone > signals. In some systems an individual mix is created for each speaker su= ch > that a speaker's own voice does not come out from his speaker or from tho= se > immediately surrounding him. > > The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels amplifie= d. > Meeting this objective helps insure that natural person-to-person > communication is retained. To this end, it is desirable that the sound > through the system and from the speakers arrive 5 to 30 milliseconds afte= r > the the sound arriving through the air from the person speaking. Delays i= n > this range invoke the Haas effect which allows listeners to locate the > person speaking based on the sound arriving through the air while the sou= nd > reinforcement system provides the additional gain required to achieve > desired intelligibility. It is also desirable for the sound to come out o= f > nearby speakers at within 5 milliseconds as longer differential delays wi= ll > be perceived as reverberation or echo. > > Video wall > > A video wall consists of multiple computer monitors, video projectors, or > television sets tiled together contiguously or overlapped in order to for= m > one large screen.# Each of the screens reproduces a portion of the larger > picture. In some implementations, each screen may be individually connect= ed > to the network and receive its portion of the overall image from a > network-connected video server or video scaler. Screens are refreshed at = 60 > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh i= s > not synchronized, the effect of multiple screens acting as one is broken. > > Phased array transducers > > Phased array and wave field synthesis techniques are increasingly used in > audio applications. These techniques work by sending or receiving slightl= y > different versions of a signal in a spacial sampling arrangement to produ= ce > or record spacial and directional sound fields. The individual transducer= s > in these applications can be extremely sensitive to differential latency. > Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise rati= o. > These microphones are also able to report the location of the speaker for > purposes of automatically aiming a video camera at them. > > Concert sound systems called line arrays allow technicians control over t= he > amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventing > sound from reaching the roof and back wall of the performance space, the > amount of reflected sound heard by the audience is reduced and the listen= ing > experience is improved. > > In these systems, accuracy in locating or emitting sound is related to > differential latency through basic trigonometry. In these applications, > microseconds of differential latency can translate to degrees of > uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired. > > _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From bill.wu@huawei.com Fri Oct 21 02:41:08 2011 Return-Path: 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 9CB7421F8ABB for ; Fri, 21 Oct 2011 02:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.673 X-Spam-Level: X-Spam-Status: No, score=-5.673 tagged_above=-999 required=5 tests=[AWL=0.926, BAYES_00=-2.599, 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 hptsVIt5EMF9 for ; Fri, 21 Oct 2011 02:41:07 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D725021F87D3 for ; Fri, 21 Oct 2011 02:40:48 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00EEWTDN0A@szxga04-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 17:36:59 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTE00HBHTD0A6@szxga04-in.huawei.com> for avt@ietf.org; Fri, 21 Oct 2011 17:36:59 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI93316; Fri, 21 Oct 2011 17:36:58 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 17:36:50 +0800 Received: from w53375q (10.138.41.130) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 17:36:50 +0800 Date: Fri, 21 Oct 2011 17:36:49 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: "Brandenburg, R. (Ray) van" , Kevin Gross , IETF AVTCore WG Message-id: <9C557C5D1922426EB3C570BFD4B9034D@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> <900CF177095B48F695F9DFC04E57907A@china.huawei.com> Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:41:08 -0000 Hi, ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ; "IETF AVTCore WG" Sent: Friday, October 21, 2011 5:19 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Thanks for comments. > Is it important to save packet size in 32bits at the cost of the accuracy. > It will be good to see the presentation times follow the format of 64bits NTP timestamp defined in RFC3550 for SR/RR report unless you have a more strong justification for it rather than say thi is not ETSI TISPAN standard compliant. These statements seem to be contradictory. Do you mean you want to see the presentation field extended to 64bits, or do you want to keep it at 32bits to save packet length? [Qin]: I prefer to the former. -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com] Sent: vrijdag 21 oktober 2011 10:33 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Is it important to save packet size in 32bits at the cost of the accuracy. It will be good to see the presentation times follow the format of 64bits NTP timestamp defined in RFC3550 for SR/RR report unless you have a more strong justification for it rather than say thi is not ETSI TISPAN standard compliant. But I am not judge, this is just my personal opinion. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ; "IETF AVTCore WG" Sent: Friday, October 21, 2011 3:13 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report on Packet Receipt Times and a 32bit NTP timestamp to report on Packet Presentation Times (plus a 32bit timestamp for the RTP timestamp). The reason we initially went with only a 32bit NTP timestamp for Packet Presentation times was that we figured that the 16 most significant bits of the NTP time (e.g. the date) would be the same for packet presentation and packet reception times and that the least significant 16bits (for sub 15 microsecond accuracy) would not be necessary. We therefore went with the middle 32 bits to limit the length of the IDMS packet. What Kevin now suggests, is that in some use cases sub-15 microsecond accuracy is necessary. He therefore proposes to increase the Packet Presentation timestamp to 64bits. The only disadvantage with this approach (apart from a slightly larger packet) is that this would break compatibility with the ETSI TISPAN standard. Which way do you think we should go here? Best Regards, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin Wu Sent: vrijdag 21 oktober 2011 4:48 To: Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with ones defined in RFC3550? Regards! -Qin ----- Original Message ----- From: "Kevin Gross" To: "IETF AVTCore WG" Sent: Thursday, October 20, 2011 10:59 AM Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Part of my reason for bringing these use cases to the attention of the group relates to a yet unresolved comment I made against the IDMS draft. The draft proposes 64-bit timestamps for arrival times but only 32-bit timestamps for presentation times. A 32-bit NTP timestamp has a 15 microsecond precision. Presentation time synchronization with these timestamps would seem not to clearly meet the requirements of a couple of these use cases. Improving the protocol to support 64-bit timestamps throughout seems to be the straightforward solution. With this change, all timestamps would have the same precision and would have a precision comparable to their reference clocks. The problem with this is that our IDMS work is based on ETSI TISPAN standard TS 183 063. Efforts have been made in the draft to maintain compatibility with this standard. Changing the packet format to accommodate 64-bit timestamps will unravel those efforts. If ETSI compatibility is important, we will have to live with 15 microsecond precision and possibly suggest clever tricks to make the most of it. Which way do we want to go here? On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross wrote: > The requirement for the stereo case is specified differently than the > others. The 10 microsecond figure there applies to _changes in latency_, not > static difference in latency described in all the other cases. Tolerance for > static differences for the stereo case are probably on the order of 1 > millisecond. The first-order effect of static latency differences is to move > one of the speakers - just depends on how fussy you are about real vs. > effective speaker placement. > > > > The 10 microsecond figure is conservative (I've heard anecdotal claims of 1 > microseconds sensitivity) and derives from our ability to accurately locate > sounds based (in part) on comparison of arrival times at each ear. The 10 > microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is. > Here's a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/HAP.html > (see Localisation of Sound Sources section) > > > > Throughout, I've tried to use what I consider reasonable and verifiable > requirements figures. Some will always seem to argue that they need better > performance. > > > > Kevin > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Tuesday, August 16, 2011 9:07 AM > To: IETF AVTCore WG > Subject: Re: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > Mr. Gross, > > The timing assertion for Networked stereo loudspeakers is much tighter that > I would have expected. Placement of stereo speakers within a foot is a > normal rule of thumb for the casual listener - and that is about 1.1ms > delta at room temperature. The ' golden ears' do have ability to detect > small differences especially with high attack waveforms, but I would like to > see the study that showed this small time difference. Can you please provide > a cite? > > And I wonder if the system requirement should be based on the smallest known > delta, unless there is no implementation complexity added to convey the > suggested resolution. > > > > > > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone 202 429 5418 > Fax 202 775 4981 > www.nab.org > Advocacy Education Innovation > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin > Gross > Sent: Monday, August 15, 2011 11:48 PM > To: 'IETF AVTCore WG' > Subject: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > In reviewing the IDMS draft I had volunteered to contribute additional use > cases. Ray Brandenberg suggested that I post them here. > > > > Kevin Gross > > AVA Networks > > Networked stereo loudspeakers > > Because of our ability to localize sound based on inter-aural time > differences, in a stereo listening situation, we are very sensitive to > changes in latency between the two speakers. These changes are perceived as > a shift in or instability of the "sound stage" during critical listening. > These effects are readily noticeable with shifts of 10 microseconds or > smaller. If the individual speakers in a stereo listening setup operate from > independent network interfaces any changing difference in latency between > the two speakers greater than 10 microseconds will be detrimental to the > listening experience. > > Conferencing sound reinforcement system > > A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms, > boardrooms, classrooms (especially those supporting distance learning) and > other such venues. Each participant using such a system has a microphone and > a speaker. There may also be other speakers to provide reinforcement for > non-speaking participants such as in an audience area or jury box. Each > microphone/speaker pair is individually connected to a network and transmits > digital audio to the other devices through the network and receives digital > audio to be reproduced through the speaker over the network. There may be a > central appliance which receives, prioritizes and mixes the microphone > signals. In some systems an individual mix is created for each speaker such > that a speaker's own voice does not come out from his speaker or from those > immediately surrounding him. > > The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels amplified. > Meeting this objective helps insure that natural person-to-person > communication is retained. To this end, it is desirable that the sound > through the system and from the speakers arrive 5 to 30 milliseconds after > the the sound arriving through the air from the person speaking. Delays in > this range invoke the Haas effect which allows listeners to locate the > person speaking based on the sound arriving through the air while the sound > reinforcement system provides the additional gain required to achieve > desired intelligibility. It is also desirable for the sound to come out of > nearby speakers at within 5 milliseconds as longer differential delays will > be perceived as reverberation or echo. > > Video wall > > A video wall consists of multiple computer monitors, video projectors, or > television sets tiled together contiguously or overlapped in order to form > one large screen.# Each of the screens reproduces a portion of the larger > picture. In some implementations, each screen may be individually connected > to the network and receive its portion of the overall image from a > network-connected video server or video scaler. Screens are refreshed at 60 > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh is > not synchronized, the effect of multiple screens acting as one is broken. > > Phased array transducers > > Phased array and wave field synthesis techniques are increasingly used in > audio applications. These techniques work by sending or receiving slightly > different versions of a signal in a spacial sampling arrangement to produce > or record spacial and directional sound fields. The individual transducers > in these applications can be extremely sensitive to differential latency. > Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise ratio. > These microphones are also able to report the location of the speaker for > purposes of automatically aiming a video camera at them. > > Concert sound systems called line arrays allow technicians control over the > amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventing > sound from reaching the roof and back wall of the performance space, the > amount of reflected sound heard by the audience is reduced and the listening > experience is improved. > > In these systems, accuracy in locating or emitting sound is related to > differential latency through basic trigonometry. In these applications, > microseconds of differential latency can translate to degrees of > uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired. > > _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer From ray.vanbrandenburg@tno.nl Fri Oct 21 02:44:58 2011 Return-Path: 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 A31D321F8C0D for ; Fri, 21 Oct 2011 02:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 X1vU33YGhMMz for ; Fri, 21 Oct 2011 02:44:57 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id D661A21F8C04 for ; Fri, 21 Oct 2011 02:44:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,384,1315173600"; d="scan'208";a="13532519" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 21 Oct 2011 11:44:53 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.01.0323.003; Fri, 21 Oct 2011 11:44:53 +0200 From: "Brandenburg, R. (Ray) van" To: Qin Wu , Kevin Gross , IETF AVTCore WG Thread-Topic: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Thread-Index: AQHMj2AZ1xwxk8RC5UaH+/0nn1Dcj5WGGa8tgABHnZCAABhWuIAADDrAgAAGcVSAAAAa4A== Date: Fri, 21 Oct 2011 09:44:52 +0000 Message-ID: References: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> <900CF177095B48F695F9DFC04E57907A@china.huawei.com> <9C557C5D1922426EB3C570BFD4B9034D@china.huawei.com> In-Reply-To: <9C557C5D1922426EB3C570BFD4B9034D@china.huawei.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:44:58 -0000 Ok. I will work together with Kevin to create a new version of the draft. In the meantime we have to try to come to consensus on the Initial Playout = Sync proposal of Fernando Boronat so that we can post a new ID before the n= ext meeting deadline.=20 If I understand correctly, the main question here is the matter in which th= e delay between Media Sender en SC is determined.=20 Ray -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: vrijdag 21 oktober 2011 11:37 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi, ----- Original Message -----=20 From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Friday, October 21, 2011 5:19 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Thanks for comments.=20 > Is it important to save packet size in 32bits at the cost of the accuracy= . > It will be good to see the presentation times follow the format of 64bits= NTP timestamp defined in RFC3550 for SR/RR report unless you have a more s= trong justification for it rather than say thi is not ETSI TISPAN standard = compliant. These statements seem to be contradictory. Do you mean you want to see the = presentation field extended to 64bits, or do you want to keep it at 32bits = to save packet length? [Qin]: I prefer to the former. -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: vrijdag 21 oktober 2011 10:33 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Is it important to save packet size in 32bits at the cost of the accuracy. It will be good to see the presentation times follow the format of 64bits N= TP timestamp defined in RFC3550 for SR/RR report unless you have a more str= ong justification for it rather than say thi is not ETSI TISPAN standard co= mpliant. But I am not judge, this is just my personal opinion. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Friday, October 21, 2011 3:13 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report o= n Packet Receipt Times and a 32bit NTP timestamp to report on Packet Presen= tation Times (plus a 32bit timestamp for the RTP timestamp). The reason we = initially went with only a 32bit NTP timestamp for Packet Presentation time= s was that we figured that the 16 most significant bits of the NTP time (e.= g. the date) would be the same for packet presentation and packet reception= times and that the least significant 16bits (for sub 15 microsecond accura= cy) would not be necessary. We therefore went with the middle 32 bits to li= mit the length of the IDMS packet.=20 What Kevin now suggests, is that in some use cases sub-15 microsecond accur= acy is necessary. He therefore proposes to increase the Packet Presentation= timestamp to 64bits. The only disadvantage with this approach (apart from = a slightly larger packet) is that this would break compatibility with the E= TSI TISPAN standard. Which way do you think we should go here? Best Regards, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin W= u Sent: vrijdag 21 oktober 2011 4:48 To: Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with ones de= fined in RFC3550? Regards! -Qin ----- Original Message ----- From: "Kevin Gross" To: "IETF AVTCore WG" Sent: Thursday, October 20, 2011 10:59 AM Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Part of my reason for bringing these use cases to the attention of the group relates to a yet unresolved comment I made against the IDMS draft. The draft proposes 64-bit timestamps for arrival times but only 32-bit timestamps for presentation times. A 32-bit NTP timestamp has a 15 microsecond precision. Presentation time synchronization with these timestamps would seem not to clearly meet the requirements of a couple of these use cases. Improving the protocol to support 64-bit timestamps throughout seems to be the straightforward solution. With this change, all timestamps would have the same precision and would have a precision comparable to their reference clocks. The problem with this is that our IDMS work is based on ETSI TISPAN standard TS 183 063. Efforts have been made in the draft to maintain compatibility with this standard. Changing the packet format to accommodate 64-bit timestamps will unravel those efforts. If ETSI compatibility is important, we will have to live with 15 microsecond precision and possibly suggest clever tricks to make the most of it. Which way do we want to go here? On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross wro= te: > The requirement for the stereo case is specified differently than the > others. The 10 microsecond figure there applies to _changes in latency_, = not > static difference in latency described in all the other cases. Tolerance = for > static differences for the stereo case are probably on the order of 1 > millisecond. The first-order effect of static latency differences is to m= ove > one of the speakers - just depends on how fussy you are about real vs. > effective speaker placement. > > > > The 10 microsecond figure is conservative (I've heard anecdotal claims of= 1 > microseconds sensitivity) and derives from our ability to accurately loca= te > sounds based (in part) on comparison of arrival times at each ear. The 10 > microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is. > Here's a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/HAP.ht= ml > (see Localisation of Sound Sources section) > > > > Throughout, I've tried to use what I consider reasonable and verifiable > requirements figures. Some will always seem to argue that they need bette= r > performance. > > > > Kevin > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Tuesday, August 16, 2011 9:07 AM > To: IETF AVTCore WG > Subject: Re: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > Mr. Gross, > > The timing assertion for Networked stereo loudspeakers is much tighter th= at > I would have expected. Placement of stereo speakers within a foot is a > normal rule of thumb for the casual listener - and that is about 1.1ms > delta at room temperature. The ' golden ears' do have ability to detect > small differences especially with high attack waveforms, but I would like= to > see the study that showed this small time difference. Can you please prov= ide > a cite? > > And I wonder if the system requirement should be based on the smallest kn= own > delta, unless there is no implementation complexity added to convey the > suggested resolution. > > > > > > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone 202 429 5418 > Fax 202 775 4981 > www.nab.org > Advocacy Education Innovation > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kev= in > Gross > Sent: Monday, August 15, 2011 11:48 PM > To: 'IETF AVTCore WG' > Subject: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > In reviewing the IDMS draft I had volunteered to contribute additional us= e > cases. Ray Brandenberg suggested that I post them here. > > > > Kevin Gross > > AVA Networks > > Networked stereo loudspeakers > > Because of our ability to localize sound based on inter-aural time > differences, in a stereo listening situation, we are very sensitive to > changes in latency between the two speakers. These changes are perceived = as > a shift in or instability of the "sound stage" during critical listening. > These effects are readily noticeable with shifts of 10 microseconds or > smaller. If the individual speakers in a stereo listening setup operate f= rom > independent network interfaces any changing difference in latency between > the two speakers greater than 10 microseconds will be detrimental to the > listening experience. > > Conferencing sound reinforcement system > > A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms, > boardrooms, classrooms (especially those supporting distance learning) an= d > other such venues. Each participant using such a system has a microphone = and > a speaker. There may also be other speakers to provide reinforcement for > non-speaking participants such as in an audience area or jury box. Each > microphone/speaker pair is individually connected to a network and transm= its > digital audio to the other devices through the network and receives digit= al > audio to be reproduced through the speaker over the network. There may be= a > central appliance which receives, prioritizes and mixes the microphone > signals. In some systems an individual mix is created for each speaker su= ch > that a speaker's own voice does not come out from his speaker or from tho= se > immediately surrounding him. > > The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels amplifie= d. > Meeting this objective helps insure that natural person-to-person > communication is retained. To this end, it is desirable that the sound > through the system and from the speakers arrive 5 to 30 milliseconds afte= r > the the sound arriving through the air from the person speaking. Delays i= n > this range invoke the Haas effect which allows listeners to locate the > person speaking based on the sound arriving through the air while the sou= nd > reinforcement system provides the additional gain required to achieve > desired intelligibility. It is also desirable for the sound to come out o= f > nearby speakers at within 5 milliseconds as longer differential delays wi= ll > be perceived as reverberation or echo. > > Video wall > > A video wall consists of multiple computer monitors, video projectors, or > television sets tiled together contiguously or overlapped in order to for= m > one large screen.# Each of the screens reproduces a portion of the larger > picture. In some implementations, each screen may be individually connect= ed > to the network and receive its portion of the overall image from a > network-connected video server or video scaler. Screens are refreshed at = 60 > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh i= s > not synchronized, the effect of multiple screens acting as one is broken. > > Phased array transducers > > Phased array and wave field synthesis techniques are increasingly used in > audio applications. These techniques work by sending or receiving slightl= y > different versions of a signal in a spacial sampling arrangement to produ= ce > or record spacial and directional sound fields. The individual transducer= s > in these applications can be extremely sensitive to differential latency. > Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise rati= o. > These microphones are also able to report the location of the speaker for > purposes of automatically aiming a video camera at them. > > Concert sound systems called line arrays allow technicians control over t= he > amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventing > sound from reaching the roof and back wall of the performance space, the > amount of reflected sound heard by the audience is reduced and the listen= ing > experience is improved. > > In these systems, accuracy in locating or emitting sound is related to > differential latency through basic trigonometry. In these applications, > microseconds of differential latency can translate to degrees of > uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired. > > _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From fboronat@dcom.upv.es Fri Oct 21 03:44:00 2011 Return-Path: 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 E177021F8B47 for ; Fri, 21 Oct 2011 03:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 k2WQN6QZ8vil for ; Fri, 21 Oct 2011 03:44:00 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6A82C21F8B42 for ; Fri, 21 Oct 2011 03:43:57 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p9LAhFtK004065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Oct 2011 12:43:15 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p9LAhEYC005245; Fri, 21 Oct 2011 12:43:14 +0200 Received: from [127.0.0.1] (fboronat2114.pc.upv.es [158.42.145.157]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id p9LAhCxl028193; Fri, 21 Oct 2011 12:43:12 +0200 Message-ID: <4EA14CB9.2080404@dcom.upv.es> Date: Fri, 21 Oct 2011 12:43:05 +0200 From: =?ISO-8859-1?Q?Fernando_Boronat_Segu=ED?= Organization: UNIVERSIDAD =?ISO-8859-1?Q?POLIT=C9CNICA_DE_VALENCIA?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Qin Wu References: <4E941250.2080500@dcom.upv.es> <4E9F1AD4.4020102@dcom.upv.es> <6097318C062643BD853DF04B85BE7C65@china.huawei.com> In-Reply-To: <6097318C062643BD853DF04B85BE7C65@china.huawei.com> Content-Type: multipart/alternative; boundary="------------060805080006030604030103" X-Mailman-Approved-At: Fri, 21 Oct 2011 08:47:12 -0700 Cc: avt@ietf.org Subject: Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fboronat@dcom.upv.es List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 10:44:01 -0000 This is a multi-part message in MIME format. --------------060805080006030604030103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Qin, I understand that the Packet Receipt Times Report Block defined in the section 4.3 of RFC3611 is to provide feedback of the reception time of data RTP packets. It could be used in the solution proposed by Kevin (sending null data packets). Our aim is to calculate the one-way delay with the lower overhead possible. If we adopt the Kevin's proposal we understand that sending RTP packets at the same data rate than during the session will suppose an unnecessary extra load prior the starting of the session that can be avoided with our solution. Notice that prior the session start is when all the users join the session with the corresponding control packets implosion. We only need a reference of the maximum one-way delay between source and SCs, not the exact value, as the initial playout instant will be larger than that value (allowing receivers to have received enough media units to guarantee a continuous playout avoiding underflow/overflow situations). The calculation of this is out of the scope of the I-D. If you consider appropriate our proposal using the packets already defined in the I-D, but with 64 bits NTP timestamps, we can try to define it more precisely and timely to include it in the next ID version. Regards El 21/10/2011 3:30, Qin Wu escribió: > Hi, > > ----- Original Message ----- > *From:* Kevin Gross > *To:* fboronat@dcom.upv.es > *Cc:* avt@ietf.org > *Sent:* Thursday, October 20, 2011 9:48 PM > *Subject:* Re: [AVTCORE] Possible Additional functionalities > fordraft-brandenburg-avt-rtcp-for-idms > > My comments below marked with [kg]. > > 2011/10/19 Fernando Boronat Seguí > > >> 1. Since the sender and all receivers have an NTP time >> reference, it is possible to measure propagation time >> directly. It is not necessary to measure RTT and divide >> by two. >> > RTT calculation was one of the alternatives we considered by > using XR with RRTR and DLRR blocks because with the use of XR > with RRTR and DLRR blocks we got the advantage that the SCs > only have to send XR with DLRR blocks as a response to an > incoming XR with RRTR block and the packets were already defined. > > Of course that we are interested in on-way delays, not in RTT > but we would need to define new packets (or adapt the ones > already defined in the I-D) in order to calculate one-way > delays. Should we do it? or do you consider it is enough with > calculating RTT and divide it by 2? > > One option using the packets already defined in the I-D to > calculate Source-to-SC delays could be the following: Before > the beginning of the media transmission, the source could > start sending one (or several consecutive) RTCP IDMS reports > (defined in section 7 of the I-D) with all the bits of the > packet received RTP timestamp field set to 0 (no packet is > referenced) and the 64-bit NTP timestamp of its sending time > in the 64 'Packet received NTP Timestamp' field (NTP sending > time). SCs should response to this packet with an XR with an > IDMS Report Block (also defined in the section 6 of the I-D) > including the 64-bit NTP timestamp of the instant in which > that packet was received (NTP reception time), also including > the packet received RTP timestamp field set to 0 (no packet is > referenced) and copying the middle 32-bits of the 64-bit NTP > timestamp of the original packet received from the source (in > order to allow the source identify the response with the > original query). Once received an XR with the IDMS report > block from an SC, the source could calculate the one-way > source-to-SC delay by subtracting both 64-bit NTP timestamps > (NTP reception time- NTPsending time). > > > [kg] I'm afraid I'm not fully familiar with all the existing XR > functionality you reference. For now I will clarify and expand my > previous comment: Under IDMS senders and receivers are required to > have a common accurate real-time clock (NTP, IEEE 1588, GPS, > etc.). The standard RTCP sender report contains a 64-bit real-time > timestamp which indicates exactly when an RTP packet was sent. A > receiver can determine one-way delivery delay of this packet by > comparing that timestamp to the time that RTP packet was received > according to his own version of the shared real-time clock. This > same technique can be used to measure the one-way delay for any > transmission in either direction. > [Qin]: I tend to agree with Kevin's propsal. But I am not going to > jude if Kevin's is better than Fernando's. Actually besides the > option proposed by Fernando, RFC3611 provide another similar way > as both your proposals to calcualte one way delay. That's Packet > Receipt Times Report Block defined in the section 4.3 of RFC3611. > You may look at the second paragraph of section 4.3, it said: > " > Packet receipt times are expressed in the same units as in the RTP > timestamps of data packets. This is so that, for each packet, one > can establish both the send time and the receipt time in comparable > terms. Note, however, that as an RTP sender ordinarily initializes > its time to a value chosen at random, there can be no expectation > that reported send and receipt times will differ by an amount equal > to the one-way delay between sender and receiver. The reported > times > can nonetheless be useful for the purposes mentioned above. > " > That's to say this XR Block can be used to calculate one way delay. > -- Saludos/Regards ======================================================================== Dr. Fernando Boronat Seguí Profesor Titular / Lecturer Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN ======================================================================== --------------060805080006030604030103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Qin,

I understand that the Packet Receipt Times Report Block defined in the section 4.3 of RFC3611 is to provide feedback of the reception time of data RTP packets. It could be used in the solution proposed by Kevin (sending null data packets).

Our aim is to calculate the one-way delay with the lower overhead possible. If we adopt the Kevin's proposal we understand that sending RTP packets at the same data rate than during the session will suppose an unnecessary extra load prior the starting of the session that can be avoided with our solution. Notice that prior the session start is when all the users join the session with the corresponding control packets implosion.

We only need a reference of the maximum one-way delay between source and SCs, not the exact value, as the initial playout instant will be larger than that value (allowing receivers to have received enough media units to guarantee a continuous playout avoiding underflow/overflow situations). The calculation of this is out of the scope of the I-D.

If you consider appropriate our proposal using the packets already defined in the I-D, but with 64 bits NTP timestamps, we can try to define it more precisely and timely  to include it in the next ID version.

Regards



El 21/10/2011 3:30, Qin Wu escribió:
Hi,
----- Original Message -----
Sent: Thursday, October 20, 2011 9:48 PM
Subject: Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms

My comments below marked with [kg].

2011/10/19 Fernando Boronat Seguí <fboronat@dcom.upv.es>
  1. Since the sender and all receivers have an NTP time reference, it is possible to measure propagation time directly. It is not necessary to measure RTT and divide by two.
RTT calculation was one of the alternatives we considered by using XR with RRTR and DLRR blocks because with the use of XR with RRTR and DLRR blocks we got the advantage that the SCs only have to send XR with DLRR blocks as a response to an incoming XR with RRTR block and the packets were already defined.

Of course that we are interested in on-way delays, not in RTT but we would need to define new packets (or adapt the ones already defined in the I-D) in order to calculate one-way delays. Should we do it? or do you consider it is enough with calculating RTT and divide it by 2?

One option using the packets already defined in the I-D to calculate Source-to-SC delays could be the following: Before the beginning of the media transmission, the source could start sending one (or several consecutive) RTCP IDMS reports (defined in section 7 of the I-D) with all the bits of the packet received RTP timestamp field set to 0 (no packet is referenced) and the 64-bit NTP timestamp of its sending time in the 64 'Packet received NTP Timestamp' field (NTP sending time). SCs should response to this packet with an XR with an IDMS Report Block (also defined in the section 6 of the I-D) including the 64-bit NTP timestamp of the instant in which that packet was received (NTP reception time), also including the packet received RTP timestamp field set to 0 (no packet is referenced) and copying the middle 32-bits of the 64-bit NTP timestamp of the original packet received from the source (in order to allow the source identify the response with the original query). Once received an XR with the IDMS report block from an SC, the source could calculate the one-way source-to-SC delay by subtracting both 64-bit NTP timestamps (NTP reception time- NTPsending time).


[kg] I'm afraid I'm not fully familiar with all the existing XR functionality you reference. For now I will clarify and expand my previous comment: Under IDMS senders and receivers are required to have a common accurate real-time clock (NTP, IEEE 1588, GPS, etc.). The standard RTCP sender report contains a 64-bit real-time timestamp which indicates exactly when an RTP packet was sent. A receiver can determine one-way delivery delay of this packet by comparing that timestamp to the time that RTP packet was received according to his own version of the shared real-time clock. This same technique can be used to measure the one-way delay for any transmission in either direction.
 
[Qin]: I tend to agree with Kevin's propsal. But I am not going to jude if Kevin's is better than Fernando's. Actually besides the option proposed by Fernando, RFC3611 provide another similar way as both your proposals to calcualte one way delay. That's Packet Receipt Times Report Block defined in the section 4.3 of RFC3611. You may look at the second paragraph of section 4.3, it said:
"
   Packet receipt times are expressed in the same units as in the RTP
   timestamps of data packets.  This is so that, for each packet, one
   can establish both the send time and the receipt time in comparable
   terms.  Note, however, that as an RTP sender ordinarily initializes
   its time to a value chosen at random, there can be no expectation
   that reported send and receipt times will differ by an amount equal
   to the one-way delay between sender and receiver.  The reported times
   can nonetheless be useful for the purposes mentioned above.
"
That's to say this XR Block can be used to calculate one way delay.
 

-- 
Saludos/Regards
========================================================================
Dr. Fernando Boronat Seguí
Profesor Titular / Lecturer	
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================
--------------060805080006030604030103-- From Even.roni@huawei.com Fri Oct 21 16:43:05 2011 Return-Path: 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 A9A7B11E808E for ; Fri, 21 Oct 2011 16:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.287 X-Spam-Level: X-Spam-Status: No, score=-105.287 tagged_above=-999 required=5 tests=[AWL=-0.989, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_FROM=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Ck5UtGeDGn+G for ; Fri, 21 Oct 2011 16:43:04 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 021F411E808B for ; Fri, 21 Oct 2011 16:43:04 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTF00KQSWJP5R@szxga05-in.huawei.com> for avt@ietf.org; Sat, 22 Oct 2011 07:43:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTF00DU5WJOD4@szxga05-in.huawei.com> for avt@ietf.org; Sat, 22 Oct 2011 07:43:01 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LTF00GIUWJB8S@szxml11-in.huawei.com> for avt@ietf.org; Sat, 22 Oct 2011 07:43:00 +0800 (CST) Date: Sat, 22 Oct 2011 01:40:14 +0200 From: Roni Even In-reply-to: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> To: avt@ietf.org Message-id: <067701cc904a$d03ead90$70bc08b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_uDZ2v8ezKogfdmePUh+x8g)" Content-language: en-us Thread-index: Acx/bJMAZn1O9EdQQ6OkqDNm9OOyyQQ3GhcA References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 23:43:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_uDZ2v8ezKogfdmePUh+x8g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I am slow on my review and looked only at part of the comments so far so I may repeat them. 1. In section 6.1.1 when talking about multicast and ecn it is not clear what should be the policy for the init value, can each receiver select different one or must the offer only include one init value similar to the declarative case 2. In section 6.1.3 "If timely feedback is not required it is still RECOMMENDED to used RTP/AVPF." If AVP is used how will you signal the ecn-ce since it is done with an AVPF rtcp message which is not supported in AVP or in this case only the XR message will be used? Nit: In section 5.2 " Report and is be based ." delete the "be" Roni Even As individual From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, September 30, 2011 3:29 PM To: avt@ietf.org Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP over UDP. The WGLC will end on October 21, 2011 Please review the draft and send comments to the list. Roni Even _____ --Boundary_(ID_uDZ2v8ezKogfdmePUh+x8g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I am slow on my review and looked only at part of the comments so far so I may repeat them.

 

1.       In section 6.1.1 when talking about multicast and ecn it is not clear what should be the policy for the init value, can each receiver select different one or must the offer only include one init value similar to the declarative case< lass=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'>2.       In section 6.1.3 "If timely feedback is not required it is still RECOMMENDED  to used RTP/AVPF." If AVP is used how will you signal the ecn-ce since it is done with an AVPF rtcp message which is not supported in AVP or in this case only the XR message will be used?

 

 

Nit: In section 5.2 " …"  delete the "be"

 

 

Roni Even

As individual

 

Fr om: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Friday, September 30, 2011 3:29 PM
To: avt@ietf.org
Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

 

Hi,

I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP over UDP.
 

The WGLC will end on October 21, 2011

Please review the draft and send comments to the list.

 

 

Roni Even

 

 

 

--Boundary_(ID_uDZ2v8ezKogfdmePUh+x8g)-- From Even.roni@huawei.com Sat Oct 22 05:08:20 2011 Return-Path: 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 1BD5821F84D5 for ; Sat, 22 Oct 2011 05:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.73 X-Spam-Level: X-Spam-Status: No, score=-105.73 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Wdm2WyGFnJgO for ; Sat, 22 Oct 2011 05:08:19 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 845F621F84CE for ; Sat, 22 Oct 2011 05:08:18 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTG00EVKV1RS3@szxga05-in.huawei.com> for avt@ietf.org; Sat, 22 Oct 2011 20:08:15 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTG00II7V1QBS@szxga05-in.huawei.com> for avt@ietf.org; Sat, 22 Oct 2011 20:08:15 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LTG00E09V1959@szxml12-in.huawei.com> for avt@ietf.org; Sat, 22 Oct 2011 20:08:14 +0800 (CST) Date: Sat, 22 Oct 2011 14:05:20 +0200 From: Roni Even In-reply-to: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> To: avt@ietf.org Message-id: <06ad01cc90b2$e6b4d190$b41e74b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8C5biREOc56ME8Wt5aHCXQ)" Content-language: en-us Thread-index: Acx/bJMAZn1O9EdQQ6OkqDNm9OOyyQRQ5naA iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 - more X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 12:08:20 -0000 This is a multi-part message in MIME format. --Boundary_(ID_8C5biREOc56ME8Wt5aHCXQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I finished the review. 1. In section 7.2 "All session participants connected over the same transport will need to use the same initiation method. " maybe say MUST use instead of will need to use. 2. In section 7.2 " If support for both in-band and out-of-band mechanisms is signalled, the sender SHOULD try ECN negotiation using STUN with ICE first, and if it fails, fallback to negotiation using RTP and RTCP ECN feedback" I think that it should say that the sender should offer ice initialization method before rtp. 3. In section 7.2.1 you reference the no-op draft. Why not reference the keep-alive RFC 4. In section 7.2.1 Generating RTCP ECN Feedback it says "Reception of subsequent ECN-CE marked packets MUST result in additional early or immediate ECN". Why use MUST and not SHOULD since there is an exception case following the sentence. 5. In section 7.2.1 "ECN initiation is considered to have failed at the instant when any RTP session participant sends an RTCP packet that doesn't contain an RTCP ECN feedback report or ECN summary report " The RTCP ECN feedback report may be missing for other reasons like no timely response or using AVP profile. 6. In section 7.3.3 receiver driven congestion control you mention layered codecs as an option I think that using ccm tmbbr is more useful when there are no layered codecs in use (more common today) and should be mentioned in this section. 7. In section 10.6 you use the wrong range definition "From RFC 5389: STUN Attribute types in the first half of the comprehension-required range (0x0000 - 0x3FFF) and in the first half of the comprehension- optional range (0x8000 - 0xBFFF) are assigned by IETF Review" Roni Even As individual From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, September 30, 2011 3:29 PM To: avt@ietf.org Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04 , Explicit Congestion Notification (ECN) for RTP over UDP. The WGLC will end on October 21, 2011 Please review the draft and send comments to the list. Roni Even _____ --Boundary_(ID_8C5biREOc56ME8Wt5aHCXQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I finished the review.

 

1.      In section 7.2  "All session participants connected over the same transport   will need to use the same initiation method. " maybe say MUST use instead of will need to use.

2.       In section 7.2 " If support for both in-band and out-of-band mechanisms is signalled, the sender SHOULD try ECN negotiation using  STUN with ICE first, and if it fails, fallback to negotiation using  RTP and RTCP ECN feedback" I think that it should say that the sender should offer ice initialization method before rtp.

3.       In section 7.2.1 y ou refer not reference the keep-alive RFC

4.       In section 7.2.1 Generating RTCP ECN Feedback it says "Reception of subsequent ECN-CE marked packets MUST  result in additional early or immediate ECN". Why use MUST and not SHOULD since there is an exception case following the sentence.

5.       In section 7.2.1 "ECN initiation is considered to have failed at the instant when a ny RTP s an RTCP packet that doesn't  contain an RTCP ECN feedback report or ECN summary report " The RTCP ECN feedback report may be missing for other reasons like no timely response or using AVP profile.

6.       In section 7.3.3 receiver driven congestion control you mention layered codecs as an option I think that using ccm tmbbr is more useful when there are no layered codecs in use (more common today) and should be mentioned in this section.

7.&nbs ;  In section 10.6 you use the wrong range definition "From RFC 5389: STUN Attribute types in the first half of the comprehension-required range (0x0000 - 0x3FFF) and in the first half of the comprehension- optional range (0x8000 - 0xBFFF) are assigned by IETF Review"

 

Roni Even

As individual

 

 

 

 

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Friday, September 30, 2011 3:29 PM
To: avt@ietf.org
Subject: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

 

Hi,

I would like to start a WGLC on Explicit Congestion Notification (ECN) for RTP over UDP.
 

The WGLC will end on October 21, 2011

 

Please review the draft and send comments to the list.

 

 

Roni Even

 

 

 

> Qin, > > I understand that the Packet Receipt Times Report Block defined in the > section 4.3 of RFC3611 is to provide feedback of the reception time of da= ta > RTP packets. It could be used in the solution proposed by Kevin (sending > null data packets). > > Our aim is to calculate the one-way delay with the lower overhead possibl= e. > If we adopt the Kevin's proposal we understand that sending RTP packets a= t > the same data rate than during the session will suppose an unnecessary ex= tra > load prior the starting of the session that can be avoided with our > solution. Notice that prior the session start is when all the users join = the > session with the corresponding control packets implosion. > > We only need a reference of the maximum one-way delay between source and > SCs, not the exact value, as the initial playout instant will be larger t= han > that value (allowing receivers to have received enough media units to > guarantee a continuous playout avoiding underflow/overflow situations). T= he > calculation of this is out of the scope of the I-D. > > --00151747948eab00d404aff858f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I do not consider t= he loading with null or dummy data "unnecessary". You will often = get different measurements on an unloaded network. Your proposal will poten= tially give us a quick=A0assessment=A0of=A0parameters=A0but since the measu= rement conditions are different (unloaded) from operating conditions (loade= d), the accuracy may not be as good as in the method I have proposed.

I do however appreciate that parameters may change a great d= eal over the duration of a session so the importance of accuracy of these m= easurements should be given due consideration in this=A0discussion. The rea= son for my proposal is primarily for simplicity - we use the same protocol = mechanisms for startup as we do for the running case.

Kevin

2011/10/21 Fernando Boronat Segu=ED <fboronat@dcom.upv.es>= ;
=20 =20 =20
Qin,

I understand that the Packet Receipt Times Report Block defined in the section 4.3 of RFC3611 is to provide feedback of the reception time of data RTP packets. It could be used in the solution proposed by Kevin (sending null data packets).

Our aim is to calculate the one-way delay with the lower overhead possible. If we adopt the Kevin's proposal we understand that sending RTP packets at the same data rate than during the session will suppose an unnecessary extra load prior the starting of the session that can be avoided with our solution. Notice that prior the session start is when all the users join the session with the corresponding control packets implosion.

We only need a reference of the maximum one-way delay between source and SCs, not the exact value, as the initial playout instant will be larger than that value (allowing receivers to have received enough media units to guarantee a continuous playout avoiding underflow/overflow situations). The calculation of this is out of the scope of the I-D.

--00151747948eab00d404aff858f0-- From kevin.gross@comcast.net Sun Oct 23 07:48:23 2011 Return-Path: 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 377C721F8569 for ; Sun, 23 Oct 2011 07:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.92 X-Spam-Level: X-Spam-Status: No, score=-101.92 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 cH4lcwNhEKvm for ; Sun, 23 Oct 2011 07:48:21 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB3B21F84DF for ; Sun, 23 Oct 2011 07:48:21 -0700 (PDT) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta12.emeryville.ca.mail.comcast.net with comcast id oEnl1h00B1HpZEsACEoDJU; Sun, 23 Oct 2011 14:48:13 +0000 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by omta14.emeryville.ca.mail.comcast.net with comcast id oEmw1h00d0y2cix8aEmx7s; Sun, 23 Oct 2011 14:46:58 +0000 Received: by bkas6 with SMTP id s6so8137318bka.31 for ; Sun, 23 Oct 2011 07:48:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.6.25 with SMTP id 25mr37440644fax.14.1319381297069; Sun, 23 Oct 2011 07:48:17 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Sun, 23 Oct 2011 07:48:16 -0700 (PDT) In-Reply-To: <900CF177095B48F695F9DFC04E57907A@china.huawei.com> References: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> <900CF177095B48F695F9DFC04E57907A@china.huawei.com> Date: Sun, 23 Oct 2011 08:48:16 -0600 Message-ID: From: Kevin Gross To: Qin Wu Content-Type: multipart/alternative; boundary=00151747844288ff2104aff865f0 Cc: IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 14:48:23 -0000 --00151747844288ff2104aff865f0 Content-Type: text/plain; charset=ISO-8859-1 I don't think packet size is a primary consideration in this decision. This issue applies to small and relatively infrequent RTCP packets and not the larger, more frequent RTP media packets. Kevin On Fri, Oct 21, 2011 at 2:32 AM, Qin Wu wrote: > Is it important to save packet size in 32bits at the cost of the accuracy. > It will be good to see the presentation times follow the format of 64bits > NTP timestamp defined in RFC3550 for SR/RR report > unless you have a more strong justification for it rather than say thi is > not ETSI TISPAN standard compliant. > But I am not judge, this is just my personal opinion. > > Regards! > -Qin > ----- Original Message ----- > From: "Brandenburg, R. (Ray) van" > To: "Qin Wu" ; "Kevin Gross" ; > "IETF AVTCore WG" > Sent: Friday, October 21, 2011 3:13 PM > Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision > > > Hi Qin, > > Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report > on Packet Receipt Times and a 32bit NTP timestamp to report on Packet > Presentation Times (plus a 32bit timestamp for the RTP timestamp). The > reason we initially went with only a 32bit NTP timestamp for Packet > Presentation times was that we figured that the 16 most significant bits of > the NTP time (e.g. the date) would be the same for packet presentation and > packet reception times and that the least significant 16bits (for sub 15 > microsecond accuracy) would not be necessary. We therefore went with the > middle 32 bits to limit the length of the IDMS packet. > > What Kevin now suggests, is that in some use cases sub-15 microsecond > accuracy is necessary. He therefore proposes to increase the Packet > Presentation timestamp to 64bits. The only disadvantage with this approach > (apart from a slightly larger packet) is that this would break compatibility > with the ETSI TISPAN standard. > > Which way do you think we should go here? > > Best Regards, > > Ray > > > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin > Wu > Sent: vrijdag 21 oktober 2011 4:48 > To: Kevin Gross; IETF AVTCore WG > Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision > > Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with ones > defined in RFC3550? > > Regards! > -Qin > ----- Original Message ----- > From: "Kevin Gross" > To: "IETF AVTCore WG" > Sent: Thursday, October 20, 2011 10:59 AM > Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision > > > Part of my reason for bringing these use cases to the attention of the > group relates to a yet unresolved comment I made against the IDMS > draft. > > The draft proposes 64-bit timestamps for arrival times but only 32-bit > timestamps for presentation times. A 32-bit NTP timestamp has a 15 > microsecond precision. Presentation time synchronization with these > timestamps would seem not to clearly meet the requirements of a couple > of these use cases. > > Improving the protocol to support 64-bit timestamps throughout seems > to be the straightforward solution. With this change, all timestamps > would have the same precision and would have a precision comparable to > their reference clocks. The problem with this is that our IDMS work is > based on ETSI TISPAN standard TS 183 063. Efforts have been made in > the draft to maintain compatibility with this standard. Changing the > packet format to accommodate 64-bit timestamps will unravel those > efforts. > > If ETSI compatibility is important, we will have to live with 15 > microsecond precision and possibly suggest clever tricks to make the > most of it. > > Which way do we want to go here? > > On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross > wrote: > > The requirement for the stereo case is specified differently than the > > others. The 10 microsecond figure there applies to _changes in latency_, > not > > static difference in latency described in all the other cases. Tolerance > for > > static differences for the stereo case are probably on the order of 1 > > millisecond. The first-order effect of static latency differences is to > move > > one of the speakers - just depends on how fussy you are about real vs. > > effective speaker placement. > > > > > > > > The 10 microsecond figure is conservative (I've heard anecdotal claims of > 1 > > microseconds sensitivity) and derives from our ability to accurately > locate > > sounds based (in part) on comparison of arrival times at each ear. The 10 > > microsecond figure is not difficult to derive/check. It is also not > > difficult to set up a listening test to see what your own threshold is. > > Here's a quick reference on it - > http://www.cs.ucc.ie/~ianp/CS2511/HAP.html > > (see Localisation of Sound Sources section) > > > > > > > > Throughout, I've tried to use what I consider reasonable and verifiable > > requirements figures. Some will always seem to argue that they need > better > > performance. > > > > > > > > Kevin > > > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > > Allison, Art > > Sent: Tuesday, August 16, 2011 9:07 AM > > To: IETF AVTCore WG > > Subject: Re: [AVTCORE] Additional use cases > > fordraft-brandenburg-avt-rtcp-for-idms > > > > > > > > Mr. Gross, > > > > The timing assertion for Networked stereo loudspeakers is much tighter > that > > I would have expected. Placement of stereo speakers within a foot is a > > normal rule of thumb for the casual listener - and that is about 1.1ms > > delta at room temperature. The ' golden ears' do have ability to detect > > small differences especially with high attack waveforms, but I would like > to > > see the study that showed this small time difference. Can you please > provide > > a cite? > > > > And I wonder if the system requirement should be based on the smallest > known > > delta, unless there is no implementation complexity added to convey the > > suggested resolution. > > > > > > > > > > > > Art Allison > > Senior Director Advanced Engineering, Science and Technology > > National Association of Broadcasters > > 1771 N Street NW > > Washington, DC 20036 > > Phone 202 429 5418 > > Fax 202 775 4981 > > www.nab.org > > Advocacy Education Innovation > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Kevin > > Gross > > Sent: Monday, August 15, 2011 11:48 PM > > To: 'IETF AVTCore WG' > > Subject: [AVTCORE] Additional use cases > > fordraft-brandenburg-avt-rtcp-for-idms > > > > > > > > In reviewing the IDMS draft I had volunteered to contribute additional > use > > cases. Ray Brandenberg suggested that I post them here. > > > > > > > > Kevin Gross > > > > AVA Networks > > > > Networked stereo loudspeakers > > > > Because of our ability to localize sound based on inter-aural time > > differences, in a stereo listening situation, we are very sensitive to > > changes in latency between the two speakers. These changes are perceived > as > > a shift in or instability of the "sound stage" during critical listening. > > These effects are readily noticeable with shifts of 10 microseconds or > > smaller. If the individual speakers in a stereo listening setup operate > from > > independent network interfaces any changing difference in latency between > > the two speakers greater than 10 microseconds will be detrimental to the > > listening experience. > > > > Conferencing sound reinforcement system > > > > A conferencing sound reinforcement system is used in commercial and > > government installations such as legislative chambers, courtrooms, > > boardrooms, classrooms (especially those supporting distance learning) > and > > other such venues. Each participant using such a system has a microphone > and > > a speaker. There may also be other speakers to provide reinforcement for > > non-speaking participants such as in an audience area or jury box. Each > > microphone/speaker pair is individually connected to a network and > transmits > > digital audio to the other devices through the network and receives > digital > > audio to be reproduced through the speaker over the network. There may be > a > > central appliance which receives, prioritizes and mixes the microphone > > signals. In some systems an individual mix is created for each speaker > such > > that a speaker's own voice does not come out from his speaker or from > those > > immediately surrounding him. > > > > The objective of these systems is to provide enough gain to enhance > > intelligibility but not so much that the speaker sounds or feels > amplified. > > Meeting this objective helps insure that natural person-to-person > > communication is retained. To this end, it is desirable that the sound > > through the system and from the speakers arrive 5 to 30 milliseconds > after > > the the sound arriving through the air from the person speaking. Delays > in > > this range invoke the Haas effect which allows listeners to locate the > > person speaking based on the sound arriving through the air while the > sound > > reinforcement system provides the additional gain required to achieve > > desired intelligibility. It is also desirable for the sound to come out > of > > nearby speakers at within 5 milliseconds as longer differential delays > will > > be perceived as reverberation or echo. > > > > Video wall > > > > A video wall consists of multiple computer monitors, video projectors, or > > television sets tiled together contiguously or overlapped in order to > form > > one large screen.# Each of the screens reproduces a portion of the larger > > picture. In some implementations, each screen may be individually > connected > > to the network and receive its portion of the overall image from a > > network-connected video server or video scaler. Screens are refreshed at > 60 > > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh > is > > not synchronized, the effect of multiple screens acting as one is broken. > > > > Phased array transducers > > > > Phased array and wave field synthesis techniques are increasingly used in > > audio applications. These techniques work by sending or receiving > slightly > > different versions of a signal in a spacial sampling arrangement to > produce > > or record spacial and directional sound fields. The individual > transducers > > in these applications can be extremely sensitive to differential latency. > > Example applications include conferencing microphone systems able to > > electronically aim at the person speaking to improve signal to noise > ratio. > > These microphones are also able to report the location of the speaker for > > purposes of automatically aiming a video camera at them. > > > > Concert sound systems called line arrays allow technicians control over > the > > amount of sound sent to different places. People in the front of the > > audience can have the same loudness as those in the back. By preventing > > sound from reaching the roof and back wall of the performance space, the > > amount of reflected sound heard by the audience is reduced and the > listening > > experience is improved. > > > > In these systems, accuracy in locating or emitting sound is related to > > differential latency through basic trigonometry. In these applications, > > microseconds of differential latency can translate to degrees of > > uncertainty. Accuracy greater than the audio sample period (about 20 > > microseconds for professional 48 kHz sample rate) is generally desired. > > > > > _______________________________________________ > 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 > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --00151747844288ff2104aff865f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think packet size is a primary consideration in this decision. = This issue applies to small and relatively infrequent RTCP packets and not = the larger, more frequent RTP media packets.

Kevin

On Fri, Oct 21, 2011 at 2:32 AM, Qin Wu <bill.wu@huawei.com<= /a>> wrote:
Is it important to save packet size in 32bits at the cost of the accuracy.<= br> It will be good to see the presentation times follow the format of 64bits N= TP timestamp defined in RFC3550 for SR/RR report
unless you have a more strong justification for it rather than say thi is n= ot ETSI TISPAN standard compliant.
But I am not judge, this is just my personal opinion.

Regards!
-Qin
----- Original Message -----
From: "Brandenburg, R. (Ray) v= an" <ray.vanbrandenbur= g@tno.nl>
To: "Qin Wu" <bill.wu@hu= awei.com>; "Kevin Gross" <kevin.gross@comcast.net>; "IETF AVTCore WG" = <avt@ietf.org>
Sent: Friday, October 21, 2011 3:13 PM
Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision


Hi Qin,

Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report o= n Packet Receipt Times and a 32bit NTP timestamp to report on Packet Presen= tation Times (plus a 32bit timestamp for the RTP timestamp). The reason we = initially went with only a 32bit NTP timestamp for Packet Presentation time= s was that we figured that the 16 most significant bits of the NTP time (e.= g. the date) would be the same for packet presentation and packet reception= times and that the least significant 16bits (for sub 15 microsecond accura= cy) would not be necessary. We therefore went with the middle 32 bits to li= mit the length of the IDMS packet.

What Kevin now suggests, is that in some use cases sub-15 microsecond accur= acy is necessary. He therefore proposes to increase the Packet Presentation= timestamp to 64bits. The only disadvantage with this approach (apart from = a slightly larger packet) is that this would break compatibility with the E= TSI TISPAN standard.

Which way do you think we should go here?

Best Regards,

Ray



-----Original Message-----
From: avt-bounces@ietf.org [mai= lto:avt-bounces@ietf.org] On Be= half Of Qin Wu
Sent: vrijdag 21 oktober 2011 4:48
To: Kevin Gross; IETF AVTCore WG
Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision

Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with one= s defined in RFC3550?

Regards!
-Qin
----- Original Message -----
From: "Kevin Gross" <kevin.gross@comcast.net>
To: "IETF AVTCore WG" <avt@iet= f.org>
Sent: Thursday, October 20, 2011 10:59 AM
Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision


Part of my reason for bringing these use cases to the attention of the
group relates to a yet unresolved comment I made against the IDMS
draft.

The draft proposes 64-bit timestamps for arrival times but only 32-bit
timestamps for presentation times. A 32-bit NTP timestamp has a 15
microsecond precision. Presentation time synchronization with these
timestamps would seem not to clearly meet the requirements of a couple
of these use cases.

Improving the protocol to support 64-bit timestamps throughout seems
to be the straightforward solution. With this change, all timestamps
would have the same precision and would have a precision comparable to
their reference clocks. The problem with this is that our IDMS work is
based on ETSI TISPAN standard TS 183 063. Efforts have been made in
the draft to maintain compatibility with this standard. Changing the
packet format to accommodate 64-bit timestamps will unravel those
efforts.

If ETSI compatibility is important, we will have to live with 15
microsecond precision and possibly suggest clever tricks to make the
most of it.

Which way do we want to go here?

On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross <kevin.gross@comcast.net> wrote:
> The requirement for the stereo case is specified differently than the<= br> > others. The 10 microsecond figure there applies to _changes in latency= _, not
> static difference in latency described in all the other cases. Toleran= ce for
> static differences for the stereo case are probably on the order of 1<= br> > millisecond. The first-order effect of static latency differences is t= o move
> one of the speakers - just depends on how fussy you are about real vs.=
> effective speaker placement.
>
>
>
> The 10 microsecond figure is conservative (I've heard anecdotal cl= aims of 1
> microseconds sensitivity) and derives from our ability to accurately l= ocate
> sounds based (in part) on comparison of arrival times at each ear. The= 10
> microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is= .
> Here's a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/H= AP.html
> (see Localisation of Sound Sources section)
>
>
>
> Throughout, I've tried to use what I consider reasonable and verif= iable
> requirements figures. Some will always seem to argue that they need be= tter
> performance.
>
>
>
> Kevin
>
>
>
> From: avt-bounces@ietf.org= [mailto:avt-bounces@ietf.org] = On Behalf Of
> Allison, Art
> Sent: Tuesday, August 16, 2011 9:07 AM
> To: IETF AVTCore WG
> Subject: Re: [AVTCORE] Additional use cases
> fordraft-brandenburg-avt-rtcp-for-idms
>
>
>
> Mr. Gross,
>
> The timing assertion for Networked stereo loudspeakers is much tighter= that
> I would have expected. Placement of stereo speakers within a foot is a=
> normal rule of thumb for the casual listener - and that is about 1.1ms=
> delta at room temperature. The ' golden ears' do have ability = to detect
> small differences especially with high attack waveforms, but I would l= ike to
> see the study that showed this small time difference. Can you please p= rovide
> a cite?
>
> And I wonder if the system requirement should be based on the smallest= known
> delta, unless there is no implementation complexity added to convey th= e
> suggested resolution.
>
>
>
>
>
> Art Allison
> Senior Director Advanced Engineering, Science and Technology
> National Association of Broadcasters
> 1771 N Street NW
> Washington, DC 20036
> Phone 202 429 = 5418
> Fax 202 775 49= 81
> www.nab.org
> Advocacy Education Innovation
>
> From: avt-bounces@ietf.org= [mailto:avt-bounces@ietf.org] = On Behalf Of Kevin
> Gross
> Sent: Monday, August 15, 2011 11:48 PM
> To: 'IETF AVTCore WG'
> Subject: [AVTCORE] Additional use cases
> fordraft-brandenburg-avt-rtcp-for-idms
>
>
>
> In reviewing the IDMS draft I had volunteered to contribute additional= use
> cases. Ray Brandenberg suggested that I post them here.
>
>
>
> Kevin Gross
>
> AVA Networks
>
> Networked stereo loudspeakers
>
> Because of our ability to localize sound based on inter-aural time
> differences, in a stereo listening situation, we are very sensitive to=
> changes in latency between the two speakers. These changes are perceiv= ed as
> a shift in or instability of the "sound stage" during critic= al listening.
> These effects are readily noticeable with shifts of 10 microseconds or=
> smaller. If the individual speakers in a stereo listening setup operat= e from
> independent network interfaces any changing difference in latency betw= een
> the two speakers greater than 10 microseconds will be detrimental to t= he
> listening experience.
>
> Conferencing sound reinforcement system
>
> A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms,
> boardrooms, classrooms (especially those supporting distance learning)= and
> other such venues. Each participant using such a system has a micropho= ne and
> a speaker. There may also be other speakers to provide reinforcement f= or
> non-speaking participants such as in an audience area or jury box. Eac= h
> microphone/speaker pair is individually connected to a network and tra= nsmits
> digital audio to the other devices through the network and receives di= gital
> audio to be reproduced through the speaker over the network. There may= be a
> central appliance which receives, prioritizes and mixes the microphone=
> signals. In some systems an individual mix is created for each speaker= such
> that a speaker's own voice does not come out from his speaker or f= rom those
> immediately surrounding him.
>
> The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels ampli= fied.
> Meeting this objective helps insure that natural person-to-person
> communication is retained. To this end, it is desirable that the sound=
> through the system and from the speakers arrive 5 to 30 milliseconds a= fter
> the the sound arriving through the air from the person speaking. Delay= s in
> this range invoke the Haas effect which allows listeners to locate the=
> person speaking based on the sound arriving through the air while the = sound
> reinforcement system provides the additional gain required to achieve<= br> > desired intelligibility. It is also desirable for the sound to come ou= t of
> nearby speakers at within 5 milliseconds as longer differential delays= will
> be perceived as reverberation or echo.
>
> Video wall
>
> A video wall consists of multiple computer monitors, video projectors,= or
> television sets tiled together contiguously or overlapped in order to = form
> one large screen.# Each of the screens reproduces a portion of the lar= ger
> picture. In some implementations, each screen may be individually conn= ected
> to the network and receive its portion of the overall image from a
> network-connected video server or video scaler. Screens are refreshed = at 60
> hertz (every 16-2/3 milliseconds) or potentially faster. If the refres= h is
> not synchronized, the effect of multiple screens acting as one is brok= en.
>
> Phased array transducers
>
> Phased array and wave field synthesis techniques are increasingly used= in
> audio applications. These techniques work by sending or receiving slig= htly
> different versions of a signal in a spacial sampling arrangement to pr= oduce
> or record spacial and directional sound fields. The individual transdu= cers
> in these applications can be extremely sensitive to differential laten= cy.
> Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise r= atio.
> These microphones are also able to report the location of the speaker = for
> purposes of automatically aiming a video camera at them.
>
> Concert sound systems called line arrays allow technicians control ove= r the
> amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventin= g
> sound from reaching the roof and back wall of the performance space, t= he
> amount of reflected sound heard by the audience is reduced and the lis= tening
> experience is improved.
>
> In these systems, accuracy in locating or emitting sound is related to=
> differential latency through basic trigonometry. In these applications= ,
> microseconds of differential latency can translate to degrees of
> uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired= .
>
>
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaild= isclaimer

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--00151747844288ff2104aff865f0-- From thomas.belling@nsn.com Mon Oct 24 03:21:49 2011 Return-Path: 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 3372B21F8508 for ; Mon, 24 Oct 2011 03:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_42=1, MANGLED_FROM=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 G-rfJUmiY04B for ; Mon, 24 Oct 2011 03:21:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 051AE21F8B8F for ; Mon, 24 Oct 2011 03:21:46 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9OALgAC026473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Oct 2011 12:21:42 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9OALe0r011600; Mon, 24 Oct 2011 12:21:42 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 12:21:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9236.B7E08F4C" Date: Mon, 24 Oct 2011 12:21:38 +0200 Message-ID: <1A8A7D59006A8240B27FF63C794CA57FAA9B1D@DEMUEXC014.nsn-intra.net> In-Reply-To: <067701cc904a$d03ead90$70bc08b0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 Thread-Index: Acx/bJMAZn1O9EdQQ6OkqDNm9OOyyQQ3GhcAAHtFLyA= References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <067701cc904a$d03ead90$70bc08b0$%roni@huawei.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Roni Even" , X-OriginalArrivalTime: 24 Oct 2011 10:21:40.0244 (UTC) FILETIME=[B8284D40:01CC9236] Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 10:21:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9236.B7E08F4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, =20 in my understanding with AVP only XR would indeed be used. (In addition, for the AMR and AMR/WB codec you have "mode requests" within the AMR RTP payload for a payload specific adjustment. This also works with AVP.) =20 Thomas =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of ext Roni Even Sent: Saturday, October 22, 2011 1:40 AM To: avt@ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 =20 Hi, I am slow on my review and looked only at part of the comments so far so I may repeat them. =20 1. In section 6.1.1 when talking about multicast and ecn it is not clear what should be the policy for the init value, can each receiver select different one or must the offer only include one init value similar to the declarative case< lass=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'>In section 6.1.3 = "If timely feedback is not required it is still RECOMMENDED to used RTP/AVPF." If AVP is used how will you signal the ecn-ce since it is done with an AVPF rtcp message which is not supported in AVP or in this case only the XR message will be used? =20 =20 Nit: In section 5.2 " ..." delete the "be" =20 =20 Roni Even As individual =20 =20 Fr om: ------_=_NextPart_001_01CC9236.B7E08F4C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ron,

 

in my = understanding with AVP only XR would indeed be = used.

(In addition, for the AMR and AMR/WB codec you = have “mode requests” within the AMR RTP payload for a = payload specific adjustment. This also works with = AVP.)

 

Thomas

 

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = ext Roni Even
Sent: Saturday, October 22, 2011 1:40 = AM
To: avt@ietf.org
Subject: Re: [AVTCORE] WGLC on = draft-ietf-avtcore-ecn-for-rtp-04

 

Hi,

I am slow = on my review and looked only at part of the comments so far so I may = repeat them.

 

1.       = In section 6.1.1 when talking about multicast = and ecn it is not clear what should be the policy for the init value, can each receiver select different one or must = the offer only include one init value similar to the declarative = case< lass=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 = level1 lfo1'>In section 6.1.3 "If timely feedback is not = required it is still RECOMMENDED  to used RTP/AVPF." If AVP is used how will you signal the ecn-ce since it is = done with an AVPF rtcp message which is not supported in AVP or in this = case only the XR message will be used?

 

 

Nit: In = section 5.2 " …"  delete the = "be"

 =

 =

Roni = Even

As = individual

 

 

Fr = om:

------_=_NextPart_001_01CC9236.B7E08F4C-- From Even.roni@huawei.com Mon Oct 24 07:45:58 2011 Return-Path: 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 034AA21F8C13 for ; Mon, 24 Oct 2011 07:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.281 X-Spam-Level: X-Spam-Status: No, score=-106.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 q7ZelSVdM8jc for ; Mon, 24 Oct 2011 07:45:57 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D1EDF21F8538 for ; Mon, 24 Oct 2011 07:45:50 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTK00DHLRMSIO@szxga04-in.huawei.com> for avt@ietf.org; Mon, 24 Oct 2011 22:44:52 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTK00KPFRMSOC@szxga04-in.huawei.com> for avt@ietf.org; Mon, 24 Oct 2011 22:44:52 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LTK004THRMD59@szxml12-in.huawei.com>; Mon, 24 Oct 2011 22:44:52 +0800 (CST) Date: Mon, 24 Oct 2011 16:42:25 +0200 From: Roni Even In-reply-to: <4E9E93A0.10701@ericsson.com> To: 'Magnus Westerlund' , 'Qin Wu' Message-id: <07aa01cc925b$2f351930$8d9f4b90$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcyOPtM8iISG1uePRnGxigZgoj2HewEG+o9Q References: <4E8D76C1.5080508@ericsson.com> <4E9E93A0.10701@ericsson.com> Cc: 'IETF AVTCore WG' , draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 14:45:58 -0000 Hi Magnus, Maybe we can add a recommendation for SSM to use the round trip sub = report block specified in section 7.1.6 of RFC 5760 (http://tools.ietf.org/html/rfc5760 ) to distribute the RTT from the distribution source to the receivers. Roni > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: Wednesday, October 19, 2011 11:09 AM > To: Qin Wu > Cc: IETF AVTCore WG; draft-ietf-avtcore-feedback-supression- > rtp@tools.ietf.org > Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback- > supression-rtp-07 >=20 > Hi, >=20 > Sorry for the delay in following up. >=20 > I have removed the issues which don't need further discussion. >=20 >=20 > On 2011-10-11 03:40, Qin Wu wrote: > > Hi, Magnus, > > Thank for your valuable review, please see my replies belows. > > ----- Original Message ----- > > From: "Magnus Westerlund" =20 > > 2. Section 3. > > "The timer value shall be > > based on the observed round-trip time. A receiver should compute > an > > estimate of the round-trip time (RTT) to the sender of TPLR from > RTCP > > report round-trip time if available, or its reception time of the > > reflected RTCP FB message (e.g.,NACK), or any other means." > > > > We hade the discussion before but now that you clarified which RTT = to > be > > used, I think it is worth having a discussion if that RTT is the > right > > one. So you suggest that the RTT between the sender of the TPLR and > the > > receiver of the message is the most appropriate to use when > suppressing > > the message. I am not certain that is the case. > > > > Lets consider the use cases. In the case of an intermediary in a > > distribution tree sending the TPLR and at the same time sending a > NACK > > upstream. Then the time until the retransmission reaches the > suppressed > > receiver is the time from the sending of the NACK up to the > > retransmitting entity and all the way down past the TPLR sender to > the > > suppressed receiver. The receiver may not have a true RTT to the > > original media sender as that source appears to live at the TPLR > sender, > > not further upstream. > > > > Yes, the sender of the TPLR and the receiver might at least have > mutual > > knowledge of each other, thus the TPLR sender is able to determine > the > > lowest RTT in the set of receviers thus determining how often to > repeat > > it to cover additional time requried for the upstream part of the > > request. But I do note that these times aren't matching what appear > to > > be the delays in the systems. > > > > Can we find a better solution? > > > > > > [Qin]: It looks to me the round trip time between media source and > > > > intermediary is trivial if we assume the intermediary is much > > > > closer to the source, that is why I put the last paragraph in the > > > > section 3 as follows: > > > > =93 > > > > In order not to incur a lot of NACK requests due to additional TPLR > > > > described above, it is recommended that the RTP system sending > > > > TPLR should be implemented more closer to the source. Also when > > > > the loss was detected and repair initiated much closer to the > source, > > > > the delay for the receiver to recover from packet loss can be = reduced > > > > through the combination of intermediary feedback to the source and > > > > Third Party Loss Report downstream. > > > > =94 > > > > > > > > If we look for a better solution, I think we have two possible ways: > > > > The first way is to rely on sender report from media sender to > > > > calculate the more approximate RTT from media sender to the = receiver. > > > > RTT measurement method follows the same way described in the > > > > figure 2 of RFC3550. > > > > > > > > The second way is to we can allow the intermediary tell the receiver > the > > > > RTT from media source to intermediary itself by sending a new = message > > > > since the intermediary can measure such RTT based on past = observation > > > > and estimation. However for the second way we need to define new > > > > message or extend TPLR message to carry such RTT. > > > > > > > > What do you think? > > >=20 > From follow up email: > > Hi,Magnus: As regarding if there is better solution, I have some > > corrections and additional thoughts. > > I think If the media source is the repair server, the receiver = should > > set timer to T1=3Dmax(the RTT from media source to middlebox sending > > TPLR, 1/2 of RTT from middlebox to receiver) when the receiver > > receives first TPLR. When the receiver receive addtional TPLR within > > T1, the receiver should reset the timer to the RTT from media source > > to middlebox sending TPLR. > > > > If the middlebox is the repair server, the receiver should set the > > timer to T2=3D1/2 of RTT from middlebox to receiver when the = receiver > > receives first TPLR. When the receiver receive addtional TPLR within > > T2, the receiver should reset the timer to the T2. > > >=20 > Can you express these rules for the receiver as something that is = based > on what is observable from the RTP and RTCP traffic? Is when media > server being repair server equal to TPLR sender SSRC =3D Media SSRC = the > TPLR applies on? And if they are not the same it is the second case? >=20 >=20 >=20 > > > > > > 3. Section 3: > > "To increase the robustness to the loss of a TPLR or of a > transmission > > packet, a receiver is allowed to receive additional TPLR for the > same > > packet. In the case the first TPLR is lost and the additional > TPLR > > arrives at the receiver, the receiver should immediately refresh > the > > timer." > > > > In the second sentence I don't see how the receiver can know that it > is > > a retransmission. It is simply a TPLR from its perspective if that = is > lost. > > > > Robustness reasons is only one reason for repeating them the other = is > > clearly to renew the timer. Thus I think the formulation should be > more > > generic to make it clear that all receivers should upon reception of > a > > TPLR refresh the timer for the packets indicated. > > > > > > > > [Qin]: If the receiver does not keep state for the times the TPLR is > > > > retransmitted, we can add repetition count field in each FCI entry > > > > of TPLR feedback message to indicate the times TPLR is > retransmitted. > > > > Particularly in PSLEI Feedback Message, we can reuse seq nr. Field > to > > > > indicate if additional TPLR is retransmitted, which one you think > better? > > > > >=20 > How, can the receiver keep state for something it has not seen due to > the initial packet not having been received? >=20 > I don't think we need new packet extensions, just clarified rules that > correctly describe what the RTP end-point should do when it sees the > TPLR message. >=20 >=20 > > > > 7. Section 4.2: > > Seq nr:8bits Command sequence number. It is used by the Command > > receiver to check if the Command is repeated. The sequence > number > > space is unique for each pairing of the SSRC of command sender > and > > the SSRC of the command receiver. The sequence number SHALL > > increase by 1 modulo 256 for each new Command. A repetition > SHALL > > NOT increase the sequence number. The initial value is > arbitrary. > > > > Based on that it is defined that upon receiving one of the PSLEI > > request, one shouldn't send a FIR or PLI message for a time interval > > equal to the RTT between the receiver and the sender of the PSLEI > > message does the sequence number field have any meaning? From my > > perspective it doesn't matter if it is a new request or not. You are > > suppressed from the reception of the message, nothing else. > > > > [Qin]: I think we can use seq nr field to indicate the times the = TPLR > is > > retransmitted, e.g., > > > > If the additional TPLR with the same SSRC and different Seq Number = is > > received, the > > > > receiver knows that it is a retransmission if the receiver keeps > state > > for the previous > > > > TPLR with the same SSRC. > > > > Also we can replace seq nr. Field with Repetition count field to > > indicate how many time > > > > the TPLR is retransmitted. > > > > >=20 > That is possible, but is the repetition count really providing > anything? > What is the simplest most straight forward that can work? I think that > is that one simple suppress the source for X time after having = receives > a TPLR message indicate that source. So, as long as you get repeat > messages more often than X you continue to be suppressed. Will the > receiver work better to know that it is now suppressed for Y times in = a > go because of the same event? >=20 > cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From ray.vanbrandenburg@tno.nl Mon Oct 24 08:28:13 2011 Return-Path: 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 94FD821F8D3E for ; Mon, 24 Oct 2011 08:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 WIaZD-ZT6gpj for ; Mon, 24 Oct 2011 08:28:12 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id 70BB121F8D13 for ; Mon, 24 Oct 2011 08:28:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,399,1315173600"; d="scan'208";a="13576395" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 24 Oct 2011 17:28:10 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.01.0323.003; Mon, 24 Oct 2011 17:28:09 +0200 From: "Brandenburg, R. (Ray) van" To: Qin Wu , Kevin Gross , IETF AVTCore WG Thread-Topic: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Thread-Index: AQHMj2AZ1xwxk8RC5UaH+/0nn1Dcj5WGGa8tgABHnZCAABhWuIAADDrAgAAGcVSAAAAa4IAFFSqg Date: Mon, 24 Oct 2011 15:28:08 +0000 Message-ID: References: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> <900CF177095B48F695F9DFC04E57907A@china.huawei.com> <9C557C5D1922426EB3C570BFD4B9034D@china.huawei.com> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 15:28:13 -0000 Hi, In order to solve both the ETSI compatibility issue as well as the need for= high precision 64bit timestamps, Kevin and I have come up with the followi= ng solution: The current draft describes both an IDMS XR block (for SC->MSAS communicati= on) as well as an RTCP IDMS Packet Type (for MSAS->SC communication). I wou= ld like to propose that we change the length of the Presentation Timestamp = in the IDMS Packet Type to 64bit, while keeping the length of the Presentat= ion Timestamp in the IDMS XR block to 32bits. This way the MSAS is able to = send very precise control commands to the synchronization clients while the= SC->MSAS measurements can remain compatible with ETSI. Since the MSAS will= add additional safety to the measured packet presentation times anyway (e.= g. to allow for jitter), it is not necessary to have 64bit precision measur= ements available on the MSAS.=20 Do you agree with this solution? Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Brand= enburg, R. (Ray) van Sent: vrijdag 21 oktober 2011 11:45 To: Qin Wu; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Ok. I will work together with Kevin to create a new version of the draft. In the meantime we have to try to come to consensus on the Initial Playout = Sync proposal of Fernando Boronat so that we can post a new ID before the n= ext meeting deadline.=20 If I understand correctly, the main question here is the matter in which th= e delay between Media Sender en SC is determined.=20 Ray -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: vrijdag 21 oktober 2011 11:37 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi, ----- Original Message -----=20 From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Friday, October 21, 2011 5:19 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Thanks for comments.=20 > Is it important to save packet size in 32bits at the cost of the accuracy= . > It will be good to see the presentation times follow the format of 64bits= NTP timestamp defined in RFC3550 for SR/RR report unless you have a more s= trong justification for it rather than say thi is not ETSI TISPAN standard = compliant. These statements seem to be contradictory. Do you mean you want to see the = presentation field extended to 64bits, or do you want to keep it at 32bits = to save packet length? [Qin]: I prefer to the former. -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: vrijdag 21 oktober 2011 10:33 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Is it important to save packet size in 32bits at the cost of the accuracy. It will be good to see the presentation times follow the format of 64bits N= TP timestamp defined in RFC3550 for SR/RR report unless you have a more str= ong justification for it rather than say thi is not ETSI TISPAN standard co= mpliant. But I am not judge, this is just my personal opinion. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Friday, October 21, 2011 3:13 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report o= n Packet Receipt Times and a 32bit NTP timestamp to report on Packet Presen= tation Times (plus a 32bit timestamp for the RTP timestamp). The reason we = initially went with only a 32bit NTP timestamp for Packet Presentation time= s was that we figured that the 16 most significant bits of the NTP time (e.= g. the date) would be the same for packet presentation and packet reception= times and that the least significant 16bits (for sub 15 microsecond accura= cy) would not be necessary. We therefore went with the middle 32 bits to li= mit the length of the IDMS packet.=20 What Kevin now suggests, is that in some use cases sub-15 microsecond accur= acy is necessary. He therefore proposes to increase the Packet Presentation= timestamp to 64bits. The only disadvantage with this approach (apart from = a slightly larger packet) is that this would break compatibility with the E= TSI TISPAN standard. Which way do you think we should go here? Best Regards, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin W= u Sent: vrijdag 21 oktober 2011 4:48 To: Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with ones de= fined in RFC3550? Regards! -Qin ----- Original Message ----- From: "Kevin Gross" To: "IETF AVTCore WG" Sent: Thursday, October 20, 2011 10:59 AM Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Part of my reason for bringing these use cases to the attention of the group relates to a yet unresolved comment I made against the IDMS draft. The draft proposes 64-bit timestamps for arrival times but only 32-bit timestamps for presentation times. A 32-bit NTP timestamp has a 15 microsecond precision. Presentation time synchronization with these timestamps would seem not to clearly meet the requirements of a couple of these use cases. Improving the protocol to support 64-bit timestamps throughout seems to be the straightforward solution. With this change, all timestamps would have the same precision and would have a precision comparable to their reference clocks. The problem with this is that our IDMS work is based on ETSI TISPAN standard TS 183 063. Efforts have been made in the draft to maintain compatibility with this standard. Changing the packet format to accommodate 64-bit timestamps will unravel those efforts. If ETSI compatibility is important, we will have to live with 15 microsecond precision and possibly suggest clever tricks to make the most of it. Which way do we want to go here? On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross wro= te: > The requirement for the stereo case is specified differently than the > others. The 10 microsecond figure there applies to _changes in latency_, = not > static difference in latency described in all the other cases. Tolerance = for > static differences for the stereo case are probably on the order of 1 > millisecond. The first-order effect of static latency differences is to m= ove > one of the speakers - just depends on how fussy you are about real vs. > effective speaker placement. > > > > The 10 microsecond figure is conservative (I've heard anecdotal claims of= 1 > microseconds sensitivity) and derives from our ability to accurately loca= te > sounds based (in part) on comparison of arrival times at each ear. The 10 > microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is. > Here's a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/HAP.ht= ml > (see Localisation of Sound Sources section) > > > > Throughout, I've tried to use what I consider reasonable and verifiable > requirements figures. Some will always seem to argue that they need bette= r > performance. > > > > Kevin > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Tuesday, August 16, 2011 9:07 AM > To: IETF AVTCore WG > Subject: Re: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > Mr. Gross, > > The timing assertion for Networked stereo loudspeakers is much tighter th= at > I would have expected. Placement of stereo speakers within a foot is a > normal rule of thumb for the casual listener - and that is about 1.1ms > delta at room temperature. The ' golden ears' do have ability to detect > small differences especially with high attack waveforms, but I would like= to > see the study that showed this small time difference. Can you please prov= ide > a cite? > > And I wonder if the system requirement should be based on the smallest kn= own > delta, unless there is no implementation complexity added to convey the > suggested resolution. > > > > > > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone 202 429 5418 > Fax 202 775 4981 > www.nab.org > Advocacy Education Innovation > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kev= in > Gross > Sent: Monday, August 15, 2011 11:48 PM > To: 'IETF AVTCore WG' > Subject: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > In reviewing the IDMS draft I had volunteered to contribute additional us= e > cases. Ray Brandenberg suggested that I post them here. > > > > Kevin Gross > > AVA Networks > > Networked stereo loudspeakers > > Because of our ability to localize sound based on inter-aural time > differences, in a stereo listening situation, we are very sensitive to > changes in latency between the two speakers. These changes are perceived = as > a shift in or instability of the "sound stage" during critical listening. > These effects are readily noticeable with shifts of 10 microseconds or > smaller. If the individual speakers in a stereo listening setup operate f= rom > independent network interfaces any changing difference in latency between > the two speakers greater than 10 microseconds will be detrimental to the > listening experience. > > Conferencing sound reinforcement system > > A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms, > boardrooms, classrooms (especially those supporting distance learning) an= d > other such venues. Each participant using such a system has a microphone = and > a speaker. There may also be other speakers to provide reinforcement for > non-speaking participants such as in an audience area or jury box. Each > microphone/speaker pair is individually connected to a network and transm= its > digital audio to the other devices through the network and receives digit= al > audio to be reproduced through the speaker over the network. There may be= a > central appliance which receives, prioritizes and mixes the microphone > signals. In some systems an individual mix is created for each speaker su= ch > that a speaker's own voice does not come out from his speaker or from tho= se > immediately surrounding him. > > The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels amplifie= d. > Meeting this objective helps insure that natural person-to-person > communication is retained. To this end, it is desirable that the sound > through the system and from the speakers arrive 5 to 30 milliseconds afte= r > the the sound arriving through the air from the person speaking. Delays i= n > this range invoke the Haas effect which allows listeners to locate the > person speaking based on the sound arriving through the air while the sou= nd > reinforcement system provides the additional gain required to achieve > desired intelligibility. It is also desirable for the sound to come out o= f > nearby speakers at within 5 milliseconds as longer differential delays wi= ll > be perceived as reverberation or echo. > > Video wall > > A video wall consists of multiple computer monitors, video projectors, or > television sets tiled together contiguously or overlapped in order to for= m > one large screen.# Each of the screens reproduces a portion of the larger > picture. In some implementations, each screen may be individually connect= ed > to the network and receive its portion of the overall image from a > network-connected video server or video scaler. Screens are refreshed at = 60 > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh i= s > not synchronized, the effect of multiple screens acting as one is broken. > > Phased array transducers > > Phased array and wave field synthesis techniques are increasingly used in > audio applications. These techniques work by sending or receiving slightl= y > different versions of a signal in a spacial sampling arrangement to produ= ce > or record spacial and directional sound fields. The individual transducer= s > in these applications can be extremely sensitive to differential latency. > Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise rati= o. > These microphones are also able to report the location of the speaker for > purposes of automatically aiming a video camera at them. > > Concert sound systems called line arrays allow technicians control over t= he > amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventing > sound from reaching the roof and back wall of the performance space, the > amount of reflected sound heard by the audience is reduced and the listen= ing > experience is improved. > > In these systems, accuracy in locating or emitting sound is related to > differential latency through basic trigonometry. In these applications, > microseconds of differential latency can translate to degrees of > uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired. > > _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From fboronat@dcom.upv.es Mon Oct 24 05:17:36 2011 Return-Path: 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 6608D21F8D26 for ; Mon, 24 Oct 2011 05:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.373 X-Spam-Level: X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 i-vJQjBQ9xpY for ; Mon, 24 Oct 2011 05:17:35 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id E600221F8D14 for ; Mon, 24 Oct 2011 05:17:34 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p9OCHTY5012266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2011 14:17:29 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p9OCHTRK018239; Mon, 24 Oct 2011 14:17:29 +0200 Received: from [127.0.0.1] (fboronat2114.pc.upv.es [158.42.145.157]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id p9OCHRfm005037; Mon, 24 Oct 2011 14:17:27 +0200 Message-ID: <4EA5574D.5020309@dcom.upv.es> Date: Mon, 24 Oct 2011 14:17:17 +0200 From: =?ISO-8859-1?Q?Fernando_Boronat_Segu=ED?= Organization: UNIVERSIDAD =?ISO-8859-1?Q?POLIT=C9CNICA_DE_VALENCIA?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kevin Gross References: <4E941250.2080500@dcom.upv.es> <4E9F1AD4.4020102@dcom.upv.es> <6097318C062643BD853DF04B85BE7C65@china.huawei.com> <4EA14CB9.2080404@dcom.upv.es> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010207010803030509050801" X-Mailman-Approved-At: Mon, 24 Oct 2011 10:28:14 -0700 Cc: avt@ietf.org Subject: Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: fboronat@dcom.upv.es List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 12:17:36 -0000 This is a multi-part message in MIME format. --------------010207010803030509050801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear members, In order to move the discussion further, below I try to summarize the different alternatives to obtain Intial Playout Instant Synchronization for each stage in which we can divide a media session, that we have been discussing about during the last week: 1. Our proposal: Use control packets already defined in the draft, or in other RFCs or drafts, in order to obtain the mean one-way delay between source and SCs. It would be an initial phase with exchange of control packets, before the starting of the media session, i.e., the transmission of RTP packets with valid media data. 2. Kevin Gross' proposal: As propagation time is often a function of packet size, measuring with small RTCP packets won't give us the same results as with larger packets containing media. One simpler way of achieving coarse sync, and without modification to the IDMS proposal, is to just start streaming with null media data. Once the MSAS receives IDMS XR reports from all receivers and distributes sync information to receivers and the receivers have done whatever they need to do to get in sync, the sender can be queued to start sending real data. Since the sender and all receivers have an NTP time reference, it is possible to measure propagation time directly and both proposals would work. As Kevin states, in his last mail to the list, our proposal will potentially give us a quick assessment of parameters but since the measurement conditions are different (unloaded) from operating conditions (loaded), the accuracy may not be as good as in the method he proposes. We only need a reference of the maximum one-way delay between source and SCs, not the exact value, as the initial playout instant will be larger than that value (allowing receivers to have received enough media units to guarantee a continuous playout, avoiding underflow/overflow situations). So we are not sure that the level of accuracy is so important here. So, I would like to ask to the list members for choosing one of the alternatives (or both) in order to go on working on and include the most supported one in the I-D, if you agree, as a way to obtain initial playout instant synchronization. Thank you in advance. Regards from Spain > You will often get different measurements on an unloaded network. Your > proposal will potentially give us a quick assessment of parameters but > since the measurement conditions are different (unloaded) from > operating conditions (loaded), the accuracy may not be as good as in > the method I have proposed. > I do however appreciate that parameters may change a great deal over > the duration of a session so the importance of accuracy of these > measurements should be given due consideration in this discussion. The > reason for my proposal is primarily for simplicity - we use the same > protocol mechanisms for startup as we do for the running case. > Kevin > > 2011/10/21 Fernando Boronat Seguí > > > Qin, > > I understand that the Packet Receipt Times Report Block defined in > the section 4.3 of RFC3611 is to provide feedback of the reception > time of data RTP packets. It could be used in the solution > proposed by Kevin (sending null data packets). > > Our aim is to calculate the one-way delay with the lower overhead > possible. If we adopt the Kevin's proposal we understand that > sending RTP packets at the same data rate than during the session > will suppose an unnecessary extra load prior the starting of the > session that can be avoided with our solution. Notice that prior > the session start is when all the users join the session with the > corresponding control packets implosion. > > We only need a reference of the maximum one-way delay between > source and SCs, not the exact value, as the initial playout > instant will be larger than that value (allowing receivers to have > received enough media units to guarantee a continuous playout > avoiding underflow/overflow situations). The calculation of this > is out of the scope of the I-D. > -- Saludos/Regards ======================================================================== Dr. Fernando Boronat Seguí Profesor Titular / Lecturer Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN ======================================================================== --------------010207010803030509050801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear members,

In order to move the discussion further, below I try to summarize the different alternatives to obtain Intial Playout Instant Synchronization for each stage in which we can divide a media session, that we have been discussing about during the last week:

1. Our proposal: Use control packets already defined in the draft, or in other RFCs or drafts, in order to obtain the mean one-way delay between source and SCs. It would be an initial phase with exchange of control packets, before the starting of the media session, i.e., the transmission of RTP packets with valid media data.

2. Kevin Gross' proposal: As propagation time is often a function of packet size, measuring with small RTCP packets won't give us the same results as with larger packets containing media. One simpler way of achieving coarse sync, and without modification to the IDMS proposal, is to just start streaming with null media data. Once the MSAS receives IDMS XR reports from all receivers and distributes sync information to receivers and the receivers have done whatever they need to do to get in sync, the sender can be queued to start sending real data.

Since the sender and all receivers have an NTP time reference, it is possible to measure propagation time directly and both proposals would work. As Kevin states, in his last mail to the list, our proposal will potentially give us a quick assessment of parameters but since the measurement conditions are different (unloaded) from operating conditions (loaded), the accuracy may not be as good as in the method he proposes.

We only need a reference of the maximum one-way delay between source and SCs, not the exact value, as the initial playout instant will be larger than that value (allowing receivers to have received enough media units to guarantee a continuous playout, avoiding underflow/overflow situations). So we are not sure that the level of accuracy is so important here.

So, I would like to ask to the list members for choosing one of the alternatives (or both) in order to go on working on and include the most supported one in the I-D, if you agree, as a way to obtain initial playout instant synchronization.

Thank you in advance.

Regards from Spain

You will often get different measurements on an unloaded network. Your proposal will potentially give us a quick assessment of parameters but since the measurement conditions are different (unloaded) from operating conditions (loaded), the accuracy may not be as good as in the method I have proposed.
I do however appreciate that parameters may change a great deal over the duration of a session so the importance of accuracy of these measurements should be given due consideration in this discussion. The reason for my proposal is primarily for simplicity - we use the same protocol mechanisms for startup as we do for the running case.
Kevin

2011/10/21 Fernando Boronat Seguí <fboronat@dcom.upv.es>
Qin,

I understand that the Packet Receipt Times Report Block defined in the section 4.3 of RFC3611 is to provide feedback of the reception time of data RTP packets. It could be used in the solution proposed by Kevin (sending null data packets).

Our aim is to calculate the one-way delay with the lower overhead possible. If we adopt the Kevin's proposal we understand that sending RTP packets at the same data rate than during the session will suppose an unnecessary extra load prior the starting of the session that can be avoided with our solution. Notice that prior the session start is when all the users join the session with the corresponding control packets implosion.

We only need a reference of the maximum one-way delay between source and SCs, not the exact value, as the initial playout instant will be larger than that value (allowing receivers to have received enough media units to guarantee a continuous playout avoiding underflow/overflow situations). The calculation of this is out of the scope of the I-D.


-- 
Saludos/Regards
========================================================================
Dr. Fernando Boronat Seguí
Profesor Titular / Lecturer	
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================
--------------010207010803030509050801-- From jonathan@vidyo.com Mon Oct 24 18:06:37 2011 Return-Path: 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 59D6B21F8CF5 for ; Mon, 24 Oct 2011 18:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599] 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 bU3CZvk4HeiR for ; Mon, 24 Oct 2011 18:06:36 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6724E11E8083 for ; Mon, 24 Oct 2011 18:06:36 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 19763416D96; Mon, 24 Oct 2011 21:06:36 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id AD059416EA9; Mon, 24 Oct 2011 21:06:35 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Mon, 24 Oct 2011 21:06:33 -0400 From: Jonathan Lennox To: IETF AVTCore WG Date: Mon, 24 Oct 2011 21:06:34 -0400 Thread-Topic: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt Thread-Index: AcySsk6emQ4oqYIlTZ+nKYZtkY9P8w== Message-ID: <5ED88EAD-41A3-443D-9244-4046830B1522@vidyo.com> References: <20111024232740.11885.97235.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jonathan Rosenberg Subject: [AVTCORE] Fwd: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 01:06:37 -0000 Hello all -- Jonathan Rosenberg and I have written a draft describing RTP-level procedur= es for multiplexing multiple media types into a single RTP session. It's p= rimarily targeted at RTCWeb, but could be of broader applicability. This draft's content probably has some overlap (or contradiction) with the = drafts that Magnus et al. have just published; I haven't yet had a chance t= o read them (since I was finishing up my own drafts). Comments are welcome. Begin forwarded message: > From: "internet-drafts@ietf.org" > Date: October 24, 2011 7:27:40 PM EDT > To: "i-d-announce@ietf.org" > Subject: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt > Reply-To: "internet-drafts@ietf.org" >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : Multiplexing Multiple Media Types In a Single Real-Tim= e Transport Protocol (RTP) Session > Author(s) : Jonathan Lennox > Jonathan Rosenberg > Filename : draft-lennox-rtcweb-rtp-media-type-mux-00.txt > Pages : 11 > Date : 2011-10-24 >=20 > This document describes mechanisms and recommended practice for > transmitting media streams of multiple media types (e.g., audio and > video) over a single Real-Time Transport Protocol (RTP) session, > primarily for the use of Real-Time Communication for the Web > (rtcweb). >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mu= x-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mux= -00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 -- Jonathan Lennox jonathan@vidyo.com From internet-drafts@ietf.org Mon Oct 24 21:51:56 2011 Return-Path: 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 EB7F311E80F6; Mon, 24 Oct 2011 21:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 6PqpPiOAlwhx; Mon, 24 Oct 2011 21:51:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2283C11E80F4; Mon, 24 Oct 2011 21:51:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025045156.32191.39709.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 21:51:56 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 04:51:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Monitoring Architectures for RTP Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-05.txt Pages : 24 Date : 2011-10-24 This memo proposes an architecture for extending RTCP with a new RTCP XR (RFC3611) block type to report new metrics regarding media transmission or reception quality, following RTCP guideline established in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers th= eir set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-05.txt From bill.wu@huawei.com Mon Oct 24 22:46:37 2011 Return-Path: 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 A1AF211E8091 for ; Mon, 24 Oct 2011 22:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.824 X-Spam-Level: X-Spam-Status: No, score=-4.824 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 5D9vT+NW+G8W for ; Mon, 24 Oct 2011 22:46:36 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF3411E80DB for ; Mon, 24 Oct 2011 22:46:36 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTL002IDXCCN9@szxga03-in.huawei.com> for avt@ietf.org; Tue, 25 Oct 2011 13:45:48 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTL00H6AXCCKJ@szxga03-in.huawei.com> for avt@ietf.org; Tue, 25 Oct 2011 13:45:48 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ67998; Tue, 25 Oct 2011 13:45:47 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 13:45:45 +0800 Received: from w53375q (10.138.41.130) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 13:45:40 +0800 Date: Tue, 25 Oct 2011 13:45:39 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Magnus Westerlund , IETF AVTCore WG , draft-ietf-avtcore-monarch@tools.ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4EA12119.4090900@ericsson.com> <0C80BD8E8293426DB3C50CC7F1ECB0F1@china.huawei.com> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 05:46:37 -0000 SGksIE1hZ251czoNClRoYW5rIGZvciB5b3VyIHZhbHVhYmxlIHJldmlldy4gcGxlYXNlIHNlZSBp bmxpbmUuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0K RnJvbTogIlFpbiBXdSIgPGJpbGwud3VAaHVhd2VpLmNvbT4NClRvOiAiTWFnbnVzIFdlc3Rlcmx1 bmQiIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+OyAiSUVURiBBVlRDb3JlIFdHIiA8 YXZ0QGlldGYub3JnPjsgPGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoQHRvb2xzLmlldGYub3Jn Pg0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDIxLCAyMDExIDU6MDMgUE0NClN1YmplY3Q6IFJlOiBb QVZUQ09SRV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMDQNCg0KDQpI aSxNYWdudXM6DQpJIHdpbGwgcmVzcG9uZCB0byB5b3VyIGNvbW1lbnRzIGFuZCB1cGRhdGUgdGhl IGRyYWZ0IHNvb24uDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIA0KRnJvbTogIk1hZ251cyBXZXN0ZXJsdW5kIiA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nz b24uY29tPg0KVG86ICJJRVRGIEFWVENvcmUgV0ciIDxhdnRAaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0 Zi1hdnRjb3JlLW1vbmFyY2hAdG9vbHMuaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIE9jdG9iZXIg MjEsIDIwMTEgMzozNiBQTQ0KU3ViamVjdDogQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1hdnRjb3Jl LW1vbmFyY2gtMDQNCg0KDQpIaQ0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhlIG1vbml0b3JpbmcgYXJj aGl0ZWN0dXJlIGRyYWZ0IGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcNCmNvbW1lbnRzLiBUaGUgcmV2 aWV3IHdhcyB0byBzZWUgaWYgdGhlIGRvY3VtZW50IHdhcyByZWFkeSBmb3IgV0cgbGFzdA0KY2Fs bC4gTXkgY29sbGVjdGVkIGp1ZGdtZW50IGlzIHN0aWxsIHNvbWUgd29yayB0byBkby4NCg0KMS4g QWJzdHJhY3Q6IEluc3RlYWQgb2YgIi4uLiAsIGFzIHByb3Bvc2VkIGluIFJGQzU5NjguIiBwbGVh c2Ugd3JpdGUgb3V0DQp0aGUgZG9jdW1lbnRzIHRpdGxlLiBUaGlzIHNob3VsZCBiZSBkb25lIGlu IG1vcmUgcGxhY2VzIHdoZXJlIHVzaW5nDQpyZWZlcmVuY2VzLg0KDQpbUWluXTogT2theSwgZml4 ZWQuDQoNCjIuIFNlY3Rpb24gMS4NCiIgIFRoZXNlIHJhcGlkbHkgZW1lcmdpbmcNCiAgIHN0YW5k YXJkcywgc3VjaCBhcyBSVENQIFhSIFtSRkMzNjExXWFuZCBvdGhlciBSVENQIGV4dGVuc2lvbiB0 bw0KICAgU2VuZGVyIFJlcG9ydHMoU1IpLCBSZWNlaXZlciBSZXBvcnRzIChSUikgW1JGQzM1NTBd YXJlIGJlaW5nDQogICBkZXZlbG9wZWQiDQoNClRoZXJlIGlzIHF1aXRlIGEgbG90IG9mIHBsYWNl cyBpbiB0aGUgZHJhZnQgd2hlcmUgdGhlcmUgaXMgbWlzc2luZw0Kc3BhY2VzLiBJbiB0aGUgYWJv dmUgZXhhbXBsZSBJIGFtIG1pc3Npbmcgc3BhY2VzIGF0ICJbMzYxMV1hbmQiLA0KIlJlcG9ydHMo U1IpIiBhbmQgIltSRkMzNTUwXWFyZSIuDQoNCltRaW5dOiBPa2F5LCBmaXhlZCBpbiB0aGUgd2hv bGUgZG9jdW1lbnQuDQoNCjMuIFNlY3Rpb24gMSwgdGhpcmQgcGFyYWdyYXBoDQoiUW9TL1FvRSIg cGxlYXNlIGV4cGFuZCBhY3JvbnltcyBvbiBmaXJzdCB1c2FnZS4NCg0KW1Fpbl06IEZpeGVkLg0K DQo0LiBzZWN0aW9uIDMuDQogICJNb25pdG9yIGlzIGEgZnVuY3Rpb25hbCBjb21wb25lbnQgZGVm aW5lZCBpbiBSRkMzNTUwIHRoYXQgYWN0cyBhcyBhDQogICBzb3VyY2Ugb2YgaW5mb3JtYXRpb24g Z2F0aGVyZWQgZm9yIG1vbml0b3JpbmcgcHVycG9zZXMuIEl0IG1heSBhbHNvDQogICBjb2xsZWN0 IHN0YXRpc3RpY3MgZnJvbSBtdWx0aXBsZSBzb3VyY2UsIHN0b3JlcyBzdWNoIGluZm9ybWF0aW9u DQogICByZXBvcnRlZCBieSBSVENQIFhSIG9yIG90aGVyIFJUQ1AgZXh0ZW5zaW9uIGFwcHJvcHJp YXRlbHkgYXMgYmFzZQ0KICAgbWV0cmljIG9yIGNhbGN1bGF0ZXMgY29tcG9zaXRlIG1ldHJpYy4i DQoNCkdyYW1tZXIgaW4gdGhlIGFib3ZlIGxvb2tzIHN0cmFuZ2UuIEZpcnN0LCBpc24ndCBpdCAi YSIgb3IgInRoZSINCm1vbml0b3I/IFNlY29uZGx5LCAic3RvcmVzIiBsb29rcyB3cm9uZy4NCg0K W1Fpbl06IEZpeGVkLg0KDQo1LiBTZWN0aW9uIDMuDQoiZG9lcyBub3QgcGFydGljaXBhdGUgUlRQ IHNlc3Npb24iDQoNCk1pc3NpbmcgImluIHRoZSIgUlRQIHNlc3Npb24/DQoNCg0KDQpbUWluXTog Rml4ZWQsIHRoYW5rcy4NCg0KNi4gU2VjdGlvbiAzLCBmaWd1cmUgMToNClRoZSAidGhpcmQgcGFy dHkgbW9uaXRvciIgYW5kIHRoZSBtb25pdG9yIGluIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSBib3gN CmJvdGggc2VlbXMgc3RyYW5nZS4gVGhlIG1hbmFnZW1lbnQgc3lzdGVtIG1vbml0b3Igd291bGQg bW9yZSBiZSBhDQoicmVwb3J0IGNvbGxlY3RvciIgb3Igc29tZXRoaW5nIGxpa2UgdGhpcyB0aGFu IGFuIGFjdHVhbCBtb25pdG9yIG9mIHRoZQ0KUlRQIHNlc3Npb25zIHRyYWZmaWMuIFNpbWlsYXJs eSB0aGUgdGhpcmQgcGFydHkgbW9uaXRvciBuZWVkcyB0byBvbiB0aGUNCm1lZGlhIHBhdGggYXMg SSB1bmRlcnN0YW5kIGl0LiBXaGF0IEkgY2FuIGludGVycHJldCBmcm9tIHRoZSBkZWZpbml0aW9u DQppbiBSRkMgMzU1MCB0aGUgdGhpcmQgcGFydHkgbW9uaXRvciBzZWVzIHRoZSBSVFAgYW5kIFJU Q1AgdHJhZmZpYyBidXQgaXMNCm5vdCBtYWtpbmcgaXRzZWxmIHZpc2libGUgdG8gdGhlIFJUUCBT ZXNzaW9uIHBhcnRpY2lwYW50cy4gVGh1cyBJIHRoaW5rDQp0aGUgZmlndXJlIG5lZWRzIHRvIGJl IGNoYW5nZWQgdG8gbWFrZSB0aGUgdGhpcmQgcGFydHkgbW9uaXRvciB0byBnZXQNCnRoZSAiMSIg YXJyb3cgdGhyb3VnaCBpdHNlbGYuDQoNCg0KDQpbUWluXTogRWFybHkgdGhlIGludGVudGlvbiBv ZiB0aGUgb3JpZ2luYWwgdGV4dCBpcyB0byBub3QgZGlmZmVyZW50aWF0ZSB0aGUgcm9sZSBvZiBy ZXBvcnQgY29sbGVjdG9yDQoNCkFuZCByZXBvcnQgZ2VuZXJhdG9yLiBCdXQgSSBhZ3JlZSB3aXRo IHlvdXIgY29tbWVudCBhbmQgd2lsbCBmaXggdGhpcyBpbiB0aGUgbmV3IHZlcnNpb24uDQoNCjcu IFNlY3Rpb24gMy4xOg0KDQpJc24ndCB0aGUgZmlyc3QgYnVsbGV0ICJ0cmFuc3BvcnQgbGV2ZWwg c3RhdGlzdGljcyIgYWN0dWFsbHkgcGFydCBvZiB0aGUNCnNlbnRlbmNlIHByaW9yIHRvIHRoZSBi dWxsZXQgbGlzdD8NCg0KDQoNCltRaW5dOiBBZ3JlZSwgZml4ZWQuDQoNCjguIFNlY3Rpb24gMy4x Og0KTWlzc2luZyBzcGFjZXMNCg0KIkZlZWRiYWNrIFtSRkM0NTg1XWV4dGVuZHMgdGhlIHN0YW5k YXJkIEEvViBQcm9maWxlW1JGQzM1NTFdIg0KInBhcmFtZXRlcnMuW1JGQzYzMzJdIg0KImFuZCBz aWduYWxjaGFuZ2VzIGluIHRoZSBkZXNpcmVkIg0KU2VjdGlvbiA0OiAibXVsdGljYXN0DQogICAg ICBpbmZlcmVuY2Ugb2YgbmV0d29yayBjaGFyYWN0ZXJpc3RpY3MoTUlOQykiDQoNCg0KDQpbUWlu XTogQWdyZWUsIGZpeGVkLg0KDQo5LiBTZWN0aW9uIDQ6DQoiSXQgaXMgYWxzbw0KICAgICAgZml4 ZWQgYWNyb3NzIG11bHRpcGxlIFJUUCBzZXNzaW9ucyBmcm9tIHRoZSBzYW1lIHNvdXJjZS4iDQoN CkkgaW50ZXJwcmV0ICJzb3VyY2UiIGluIHRoZSBhYm92ZSBhcyBhbiBlbmQtcG9pbnQgb3IgUlRQ IG5vZGUuIFdoaWNoDQpjYXVzZXMgbWUgdG8gaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnQuDQoN ClRoaXMgaXMgdmVyeSBjb21tb25seSB0cnVlLCBidXQgbm90IHVuaXZlcnNhbGx5IHRydWUuIEFz IENOQU1FDQppZGVudGlmaWVzIGEgc3luY2hyb256aWF0aW9uIGNvbnRleHQsIGEgZ2l2ZW4gZW5k LXBvaW50IGNvdWxkIGhhdmUgbWVkaWENCnNvdXJjZXMgdGhhdCBiZWxvbmcgdG8gbXVsdGlwbGUg c3luY2hyb25pemF0aW9uIGNvbnRleHRzIGluIHRoZSBzYW1lDQpzZXNzaW9uLiBGb3IgZXhhbXBs ZSBoYXZlIG1pY3JvcGhvbmVzIGFuZCBjYW1lcmFzIGZyb20gbXVsdGlwbGUgcm9vbXMsDQp3aGVy ZSBlYWNoIHJvb20gd2lsbCBiZSBpdHMgb3duIHN5bmNocm9uaXphdGlvbiBjb250ZXh0Lg0KDQoN Cg0KW1Fpbl06IEFncmVlIHdpdGggeW91ciB0aGlua2luZywgYnV0IGhlcmUgd2hhdCB3ZSBlbXBo YXNpemUgaXMgImFjcm9zcyBtdWx0aXBsZSBSVFAgc2Vzc2lvbiINCg0KRG9lcyB0aGlzIHJlYWxs eSBjb25mbGljdCB3aXRoIHdoYXQgeW91IHNhaWQ/DQoNCkFueXdheSBJIHdpbGwgcmV3b3JkIHRo aXMgaW4gdGhlIG5ldyB2ZXNpb24uDQoNCjEwLiBTZWN0aW9uIDQsIGJ1bGxldCAyOiBUaXRsZSBm b3IgUkZDIDYwMzUgcmVmZXJlbmNlDQoNCjExLiBTZWN0aW9uIDQsIGJ1bGxldCAzOg0KICAgICAi SG93ZXZlciBpbiBzb21lIGNhc2VzLCBJZGVudGl0eSBpbmZvcm1hdGlvbiBtYXkgYmUNCiAgICAg IG5vdCBwYXJ0IG9mIG1ldHJpYyBhbmQgaW5jbHVkZSBpbmZvcm1hdGlvbiBtb3JlIHRoYW4gdGhl IFNTUkMgaW4NCiAgICAgIHRoZSBtZXRyaWMgYmxvY2ssIGUuZy4sIHdoZW4gd2Ugc2V0IGEgbWV0 cmljIGludGVydmFsIGZvciB0aGUNCiAgICAgIHNlc3Npb24gYW5kIG1vbml0b3IgUlRQIHBhY2tl dHMgd2l0aGluIG9uZSBvciBzZXZlcmFsIGNvbnNlY3V0aXZlDQogICAgICBtZXRyaWMgaW50ZXJ2 YWwsIGV4dHJhIGlkZW50aXR5IGluZm9ybWF0aW9uIChlLmcuLCBzZXF1ZW5jZSBudW1iZXINCiAg ICAgIG9mIDFzdCBwYWNrZXQpIGlzIGV4cGVjdGVkLCBpZiB3ZSBwdXQgc3VjaCBleHRyYSBpZGVu dGl0eQ0KICAgICAgaW5mb3JtYXRpb24gaW50byBlYWNoIG1ldHJpYyBibG9jaywgdGhlcmUgbWF5 IGJlIHNpdHVhdGlvbnMgd2hlcmUNCiAgICAgIGFuIFJUQ1AgWFIgcGFja2V0IGNvbnRhaW5pbmcg bW9yZSB0aGFuIHR3byBtZXRyaWMgYmxvY2tzIGluY2x1ZGluZw0KICAgICAgdGhlIGR1cGxpY2F0 ZWQgZXh0cmEgaWRlbnRpdHkgaW5mb3JtYXRpb24sIHJlcG9ydHMgb24gdGhlIHNhbWUNCiAgICAg IHN0cmVhbXMgZnJvbSB0aGUgc2FtZSBzb3VyY2UuIGVhY2ggYmxvY2sgaGF2ZSB0aGUgc2FtZSBl eHRyYQ0KICAgICAgaWRlbnRpdHkgaW5mb3JtYXRpb24gZm9yIG1lYXN1cmVtZW50LCBpZiBlYWNo IG1ldHJpYyBibG9jayBjYXJyeQ0KICAgICAgc3VjaCBkdXBsaWNhdGVkIGRhdGEgZm9yIHRoZSBt ZWFzdXJlbWVudCwgaXQgbGVhZHMgdG8gcmVkdW5kYW50DQogICAgICBpbmZvcm1hdGlvbiBpbiB0 aGlzIGRlc2lnbiBzaW5jZSBlcXVpdmFsZW50IGluZm9ybWF0aW9uIGlzDQogICAgICBwcm92aWRl ZCBtdWx0aXBsZSB0aW1lcywgb25jZSBpbiAqZXZlcnkqIG1ldHJpYyBibG9jay4iDQoNClRoaXMg aXMgb25lIG9mIHRoZSBsb25nZXN0IHNlbnRlbmNlcyBJIGhhdmUgc2Vlbi4gSXQgYWxzbyBoYXMg YSBzdHJheQ0KIi4iIGluIGl0LiBQbGVhc2UgZG8gc29tZXRoaW5nIHdpdGggdGhpcyB0byBtYWtl IGVhc2llciB0byBncmFzcC4NCg0KDQoNCltRaW5dOiBBZ3JlZSwgZml4ZWQuDQoNCjEyLiBTZWN0 aW9uIDQuIGJ1bGxldCAzOg0KVGhpcyBpc3N1ZXMgZG9lcyBub3QgaGF2ZSBhIHJlY29tbWVuZGF0 aW9uIGluIHRoZSBuZXh0IHNlY3Rpb24uIEkgdGhpbmsNCndlIHNob3VsZCBkb2N1bWVudCB0aGUg V0cgY29uc2Vuc3VzIG9uIHRoaXMgaXNzdWUuIEV2ZW4gaWYgaXQgd2FzIHRoYXQNCnRoaXMgaXNz dWUgd2Fzbid0IHNpZ25pZmljYW50IGVub3VnaCB0byBkbyBzb21ldGhpbmcgYWJvdXQuIE9yIGFt IEkNCnJlbWVtYmVyaW5nIHRoZSBXRyBjb25zZW5zdXMgd3Jvbmc/DQoNCg0KDQpbUWluXTogWWVz LCB0aGUgaXNzdWUgd2Fzbid0IHNpZ25pZmljYW50IGFuZCBJIHJlbWVtYmVyZWQgdGhlIGNvbnNl bnN1cyBpcyANCg0KdG8gcmVwbGFjZSB0YWcgd2l0aCB0aGUgU1NSQyBhbmQgdXNlIFNTUkMgdG8g aWRlbnRpZnkgYW5kIGNvcnJlbGF0ZSBhbmQgZ3JvdXANCg0KIHBhcnRpY2lwYW50cyBiZXR3ZWVu IHJlcG9ydHMuIFRoZSBzZXF1ZW5jZSBudW1iZXJpbmcgaW5mb3JtYXRpb24gYW5kDQoNCiBtZWFz dXJlbWVudCBpbnRlcnZhbCBjYW4gYmUgZGVmaW5lZCBpbiBhIG5ldyBSVENQIFhSIGJsb2NrIGlm IG5lZWRlZCwgDQoNCmJ1dCBpcyBub3QgcmVsYXRlZCB0byBpZGVudGl0eS4gVGhlcmVmb3JlIEkg d2lsbCBhZGQgb25lIHNlY3Rpb24gdG8gdGFsayBhYm91dCBob3cgdG8gZGVhbCB3aXRoIHRoaXMg aXNzdWUuDQoNCg0KDQoxMy4gU2VjdGlvbiA0Og0KIlRob3VnaA0KICAgICAgdGhpcyBlbnN1cmVz IGltbXVuaXR5IHRvIHBhY2tldCBsb3NzLCB0aGUgZGVzaWduIG1heSBicmluZyBtb3JlDQogICAg ICBjb21wbGV4aXR5IGFuZCB0aGUgb3ZlcmhlYWQgaXMgbm90IGNvbXBsZXRlbHkgdHJpdmlhbCBp biBzb21lDQogICAgICBjYXNlcy4iDQoNCkNhbiB5b3UgcGxlYXNlIGV4cGxhaW4gd2hhdCAiY29t cGxleGl0eSIgdGhlIGFib3ZlIHJlZmVycyB0bz8NCg0KDQpbUWluXTogY29tcGxleGl0eSBpcyBy ZWZlcnJlZCB0byBwYWNrZXRpemF0aW9uIGNvbXBsZXhpdHkuDQoNCg0KMTQuIFNlY3Rpb24gNS4x DQoNCkkgdGhpbmsgdGhlIHNlY3Rpb24gdGl0bGUgc2hvdWxkIGJlIGNoYW5nZWQgdG86ICJVc2lu ZyBTaW5nbGUgTWV0cmljIEJsb2NrcyINCg0KDQoNCltRaW5dOiBPa2F5Lg0KDQoxNS4gU2VjdGlv biA1LjEuIEkgd291bGQgc3VnZ2VzdCB0aGF0IG9uZSByZXBsYWNlcyAic21hbGwgYmxvY2tzIiB3 aXRoDQpzaW5nbGUgbWV0cmljIGJsb2Nrcy4NCg0KDQoNCltRaW5dOiBPa2F5Lg0KDQoxNi4gU2Vj dGlvbiA1LjI6DQoiKGluIGdhdGV3YXkpLGUuZy4sIG9uZSBSVENQIFhSIFBhY2tldCINCg0KVG8g bWFueSBjb21tYXM/DQoNCg0KDQpbUWluXTogT2theSwgZml4ZWQuDQoNCjE3LiBTZWN0aW9uIDUu MjoNCiJTU1JDIG9mIHNvdXJjZSIgbWlzc2luZyAidGhlIj8NCg0KDQoNCltRaW5dOiBPa2F5LCBm aXhlZC4NCg0KMTguIFNlY3Rpb24gNS4yOg0KIEEgZmxvdyBtZWFzdXJlbWVudCB0b29sIHRoYXQg aXMgbm90IGNhbGwtYXdhcmUNCiAgIHRoZW4gZm9yd2FyZCB0aGUgUlRDUCBYUiByZXBvcnRzIGFs b25nIHdpdGggU1NSQyBvZiB0aGUgbWVhc3VyZWQgUlRQDQogICBzdHJlYW0gd2hpY2ggaXMgaW5j bHVkZWQgaW4gdGhlIFhSIEJsb2NrIGhlYWRlciB0byB0aGUgbmV0d29yaw0KICAgbWFuYWdlbWVu dCBzeXN0ZW0uICBOZXR3b3JrIG1hbmFnZW1lbnQgc3lzdGVtIGNhbiB0aGVuIGNvcnJlbGF0ZSB0 aGlzDQogICByZXBvcnQgdXNpbmcgU1NSQyB3aXRoIG90aGVyIGRpYWdub3N0aWMgaW5mb3JtYXRp b24gc3VjaCBhcyBjYWxsDQogICBkZXRhaWwgcmVjb3Jkcy4NCg0KSSBndWVzcyB0aGUgZmxvdyBt ZWFzdXJlbWVudCB0b29sIGlzIGNvbmZpZ3VyZWQgd2l0aCB0aGUgNS10dXBsZSBhbmQNCnRoYXQg aXRzIHJlcG9ydHMgdG8gdGhlIG1hbmFnZW1lbnQgc3lzdGVtIHVzaW5nIGEgYmluZGluZyB0byB0 aGF0DQo1LXR1cGxlIHdoZW4gcmVwb3J0aW5nLiBTaG91bGQgdGhpcyBiZSBtZW50aW9uZWQ/DQoN Cg0KDQpbUWluXTogTWFrZSBzZW5zZSwgd2lsbCBhZGQgaXQgdG8gdGhlIG5leHQgdmVyc2lvbi4N Cg0KMTkuIFNlY3Rpb24gNi4NClRoZSBQRFYgcmVmZXJlbmNlIGlzICJ3b3JrIGluIHByb2dyZXNz IiBidXQgeW91IGRvbid0IG5lZWQgdG8gcmVwZWF0IGl0DQphdCBhbGwgdGhlIHBsYWNlcy4gQW5k IGluIGZhY3QsIGlmIHlvdSBqdXN0IGRvIGEgbm9ybWFsIGluZm9ybWF0aW9uYWwNCnJlZmVyZW5j ZSB0byB0aGUgaW50ZXJuZXQgZHJhZnQgdGhlIFJGQy1lZGl0b3Igd2lsbCBhZGQgdGhlICJ3b3Jr IGluDQpwcmdvcmVzcyIgaW4gdGhlIHJlZmVyZW5jZSBsaXN0Lg0KDQoNCg0KW1Fpbl06IE9rYXku DQoNCjIwLiBTZWN0aW9uIDYuDQoiaml0IiBmaWVsZC4gVG8gbXkga25vd2xlZGdlIHRoZSBmaWVs ZCB5b3UgcmVmZXJlbmNlIGFyZSBuYW1lZA0KImludGVyYXJyaXZhbCBqaXR0ZXIiIGluIHRoZSBS RkMgMzU1MCBSVENQIHJlcG9ydCBibG9jayBzdHJ1Y3R1cmVzLg0KDQoNCg0KW1Fpbl06IFlvdSBh cmUgcmlnaHQsIGZpeGVkLg0KDQoyMS4gU2VjdGlvbiA3LjE6DQoNClN0cmljdGx5IHRoZSBSVFAg ZW5kDQogICBzeXN0ZW0gY2FuIG9ubHkgY29uY2x1ZGUgdGhhdCBpdHMgUlRQIGhhcyBiZWVuIGxv c3QgaW4gdGhlIG5ldHdvcmssDQogICB0aG91Z2ggYW4gUlRQIGVuZCBzeXN0ZW0gY29tcGx5aW5n IHdpdGggdGhlIHJvYnVzdG5lc3MgcHJpbmNpcGxlIG9mDQogICBbUkZDMTEyMl0gc2hvdWxkIHN1 cnZpdmUgd2l0aCBlc3NlbnRpYWwgZnVuY3Rpb25zIHVuaW1wYWlyZWQuDQoNCldoYXQgaXMgdGhl IHB1cnBvc2Ugd2l0aCB0aGlzIHNlbnRlbmNlPyBBbmQgd2hhdCBpcyBhY3R1YWxseSBzZWVuIGFz DQoiZXNzZW50aWFsIGZ1bmN0aW9ucyI/DQoNCg0KDQpbUWluXTogSSB0aGluayBlc3NlbnRpYWwg ZnVuY3Rpb25zIGFyZSByZWZlcnJlZCB0byBhcyAibWVkaWEgZGlzdHJpYnV0aW9uIg0KDQoyMi4g U2VjdGlvbiA3LjI6DQpGb3IgYmlkaXJlY3Rpb25hbCB1bmljYXN0LCBhbiBSVFAgc3lzdGVtIG1h eSB1c3VhbGx5IGRldGVjdCBSVENQIFhSDQogICBmcm9tIGEgdHJhbnNsYXRvciBieSBub3Rpbmcg dGhhdCB0aGUgc2VuZGluZyBTU1JDIGlzIG5vdCBwcmVzZW50IGluDQogICBhbnkgUlRQIG1lZGlh IHBhY2tldC4NCg0KU28gdGhlIGFzc3VtcHRpb24gaGVyZSBpcyB0aGF0IHRoZSB0cmFuc2xhdG9y IGhhcyBpdHMgb3duIFNTUkMgdG8gc2VuZA0KdGhlc2UgbW9uaXRvcmluZyByZXBvcnRzLiBCdXQs IGhvdyBkb2VzIGFuIFJUUCBub2RlIGRldGVybWluZSB0aGF0IGFuDQpTU1JDIGlzIGFzc29jaWF0 ZWQgd2l0aCBhIHRyYW5zbGF0b3IgcmF0aGVyIHRoYW4gYSByZWNlaXZlciBvbmx5DQplbmQtcG9p bnQ/IEZyb20gYSBzZXNzaW9uIHBhcnRpY2lwYW50IEkgZG9uJ3QgdGhpbmsgeW91IGNhbiBkZXRl cm1pbmUgaWYNCmEgZ2l2ZSBTU1JDIGlzIGEgcmVjZWl2ZXIgb3IganVzdCBhIG1vbml0b3IuIFRo ZXkgd2lsbCBub3QgbG9vaw0KZGlmZmVyZW50LiBPbmUgbmVlZHMgc2Vzc2lvbiBjb25maWd1cmF0 aW9uIGluZm9ybWF0aW9uLCBhbmQgaW4gdGhhdCBjYXNlDQpjb25maWd1cmF0aW9uIGluZm9ybWF0 aW9uIHdoZXJlIHRoZSB0cmFuc2xhdG9yIGFubm91bmNlcyBpdHMgbm9kZSB0eXBlDQp0byB0aGUg bWFuYWdlbWVudCBzeXN0ZW0uDQoNCg0KDQpbUWluXTogVGhhdCdzIHdoYXQgSSB3YW50IHRvIHNh aWQgaW4gcGFydC4gQW5kIEkgYWdyZWUgdGhhdCBub2RlIHR5cGUgc2hvdWxkIGFsc28gYmUgYW5u b3VuY2VkLg0KDQpJIHdpbGwgcmVmbGVjdCB0aGUgZHJhZnQgdG8gcmVmbGVjdCB0aGlzLg0KDQoy My4gU2VjdGlvbiA4LiBJIGFncmVlIHRoYXQgdGhpcyBkcmFmdCBzaG91bGRuJ3QgaGF2ZSBhIElB TkENCkNvbnNpZGVyYXRpb24gb3RoZXIgdG8gc2F5IHRoYXQgaXQgaXMgaGFzIG5vIGFjdGlvbnMu IEhvd2V2ZXIsIEkgdGhpbmsNCnRoZSBkb2N1bWVudCBzaG91bGQgY29uc2lkZXIgaWYgaXQgaGFz IHNvbWUgZ3VpZGFuY2Ugb24gSUFOQSBhY3Rpb25zIGZvcg0KdGhlIG1vbml0b3JpbmcgYXJjaGl0 ZWN0dXJlLiBTb21lIHBhcnQgb2YgdGhpcyBpcyBjbGVhcmx5IGFib3V0IHRoZQ0KY29uc3VtcHRp b24gb2YgWFIgYmxvY2sgY29kZSBwb2ludHMgdGhhdCBpc24ndCBhIG1ham9yIGlzc3VlLiBBbmQg aWYgd2UNCmRvIHJ1biBvdXQgYSBzZWNvbmQgUlRDUCBwYWNrZXQgdHlwZSBmb3IgWFIgYmxvY2sg MiBjb3VsZCBiZSBhc3NpZ25lZC4NCg0KDQoNCltRaW5dOiBUaGUgV0cgY29uc2Vuc3VzIGlzIHNw YWNlIGRlcGxldGlvbiBpcyBub3QgaXNzdWUNCg0KaWYgeW91IHJlYWxseSB3YW50IHNwYWNlIGV4 cGFuc2lvbiwgeW91IGNhbiBkZWZpbmUgb25lIFhSIGJsb2NrIHR5cGUNCg0KIGZvciB2ZW5kb3It c3BlY2lmaWMgZXh0ZW5zaW9ucywgd2l0aCBhbiBlbnRlcnByaXNlIG51bWJlciBpbmNsdWRlZCAN Cg0KdG8gaWRlbnRpZnkgdGhlIHZlbmRvciBtYWtpbmcgdGhlIGV4dGVuc2lvbi4gU28gSSBwcmVm ZXIgdG8gc2F5DQoNCiJUaGVyZSBpcyBubyBJQU5BIGFjdGlvbiBpbiB0aGlzIGRvY3VtZW50Ig0K DQoyNC4gU2VjdGlvbiA5Lg0KSSB0aGluayB0aGlzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2hv dWxkIGJlIGhhdmUgc29tZSBhY3R1YWwNCmNvbnNpZGVyYXRpb25zLiBUaGlzIGlzIGFuIGFyY2hp dGVjdHVyZSBkb2N1bWVudCBmb3IgbW9uaXRvcmluZy4gVGh1cw0KY29sbGVjdGluZyB0aGUgc2Vj dXJpdHkgaXNzdWVzIHdpdGggbW9uaXRvcmluZyBkbyBzb3VuZCBsaWtlIGEgZ29vZA0KaWRlYS4g Rm9yIGV4YW1wbGUgcHJpdmFjeSBhbmQgbGVha2luZyBpbmZvcm1hdGlvbi4gTmVlZCBmb3IgaGF2 aW5nDQpwcm90ZWN0aW9uIG9mIHRoZSBtb25pdG9yaW5nIHJlcG9ydHMgZXRjLg0KDQoNCg0KW1Fp bl06IEkgYWdyZWUgd2l0aCB5b3VyIHN1Z2dlc3Rpb24uIFdpbGwgYWRkIG5ldyB0ZXh0IHRvIGFk ZHJlc3MgdGhlIA0KDQpzZWN1cml0eSBpc3N1ZSB3aXRoIHRoZSBtb25pdG9yaW5nLg0KDQpDaGVl cnMNCg0KTWFnbnVzIFdlc3Rlcmx1bmQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTXVsdGltZWRpYSBUZWNo bm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UVk0NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkVyaWNz c29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQpG5HL2Z2F0YW4g NiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0IDgwIFN0b2Nr aG9sbSwgU3dlZGVufCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo= From internet-drafts@ietf.org Mon Oct 24 23:47:24 2011 Return-Path: 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 EFA6011E80D9; Mon, 24 Oct 2011 23:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 046mBo7WWORG; Mon, 24 Oct 2011 23:47:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874F421F8AD9; Mon, 24 Oct 2011 23:47:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025064723.28199.71289.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 23:47:23 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 06:47:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e 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-08.txt Pages : 17 Date : 2011-10-24 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 feedback target 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-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-r= tp-08.txt From bill.wu@huawei.com Tue Oct 25 02:54:32 2011 Return-Path: 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 13D7421F8C71 for ; Tue, 25 Oct 2011 02:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, 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 Ytvehl6Q3Npl for ; Tue, 25 Oct 2011 02:54:30 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 98A4C21F8C70 for ; Tue, 25 Oct 2011 02:54:29 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTM0093J8URE1@szxga03-in.huawei.com> for avt@ietf.org; Tue, 25 Oct 2011 17:54:27 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTM00E078UODL@szxga03-in.huawei.com> for avt@ietf.org; Tue, 25 Oct 2011 17:54:27 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEK34998; Tue, 25 Oct 2011 17:54:26 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 17:54:21 +0800 Received: from w53375q (10.138.41.130) by szxeml405-hub.china.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 17:54:18 +0800 Date: Tue, 25 Oct 2011 17:54:17 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: "Brandenburg, R. (Ray) van" , Kevin Gross , IETF AVTCore WG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> <900CF177095B48F695F9DFC04E57907A@china.huawei.com> <9C557C5D1922426EB3C570BFD4B9034D@china.huawei.com> Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 09:54:32 -0000 Yes, the format looks good to me. However is it better to define RTCP IDMS packet type in two direction (i.e., both MSAS->SC communication and SC->MSAS communication)? In this case, timely feedback can be guaranteed in two directions. and you still can use XRBLock in the upstream direction to maintain ETSI compatibility. That's my 2cents. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ; "IETF AVTCore WG" Sent: Monday, October 24, 2011 11:28 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi, In order to solve both the ETSI compatibility issue as well as the need for high precision 64bit timestamps, Kevin and I have come up with the following solution: The current draft describes both an IDMS XR block (for SC->MSAS communication) as well as an RTCP IDMS Packet Type (for MSAS->SC communication). I would like to propose that we change the length of the Presentation Timestamp in the IDMS Packet Type to 64bit, while keeping the length of the Presentation Timestamp in the IDMS XR block to 32bits. This way the MSAS is able to send very precise control commands to the synchronization clients while the SC->MSAS measurements can remain compatible with ETSI. Since the MSAS will add additional safety to the measured packet presentation times anyway (e.g. to allow for jitter), it is not necessary to have 64bit precision measurements available on the MSAS. Do you agree with this solution? Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: vrijdag 21 oktober 2011 11:45 To: Qin Wu; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Ok. I will work together with Kevin to create a new version of the draft. In the meantime we have to try to come to consensus on the Initial Playout Sync proposal of Fernando Boronat so that we can post a new ID before the next meeting deadline. If I understand correctly, the main question here is the matter in which the delay between Media Sender en SC is determined. Ray -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com] Sent: vrijdag 21 oktober 2011 11:37 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi, ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ; "IETF AVTCore WG" Sent: Friday, October 21, 2011 5:19 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Thanks for comments. > Is it important to save packet size in 32bits at the cost of the accuracy. > It will be good to see the presentation times follow the format of 64bits NTP timestamp defined in RFC3550 for SR/RR report unless you have a more strong justification for it rather than say thi is not ETSI TISPAN standard compliant. These statements seem to be contradictory. Do you mean you want to see the presentation field extended to 64bits, or do you want to keep it at 32bits to save packet length? [Qin]: I prefer to the former. -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com] Sent: vrijdag 21 oktober 2011 10:33 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Is it important to save packet size in 32bits at the cost of the accuracy. It will be good to see the presentation times follow the format of 64bits NTP timestamp defined in RFC3550 for SR/RR report unless you have a more strong justification for it rather than say thi is not ETSI TISPAN standard compliant. But I am not judge, this is just my personal opinion. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ; "IETF AVTCore WG" Sent: Friday, October 21, 2011 3:13 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report on Packet Receipt Times and a 32bit NTP timestamp to report on Packet Presentation Times (plus a 32bit timestamp for the RTP timestamp). The reason we initially went with only a 32bit NTP timestamp for Packet Presentation times was that we figured that the 16 most significant bits of the NTP time (e.g. the date) would be the same for packet presentation and packet reception times and that the least significant 16bits (for sub 15 microsecond accuracy) would not be necessary. We therefore went with the middle 32 bits to limit the length of the IDMS packet. What Kevin now suggests, is that in some use cases sub-15 microsecond accuracy is necessary. He therefore proposes to increase the Packet Presentation timestamp to 64bits. The only disadvantage with this approach (apart from a slightly larger packet) is that this would break compatibility with the ETSI TISPAN standard. Which way do you think we should go here? Best Regards, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin Wu Sent: vrijdag 21 oktober 2011 4:48 To: Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with ones defined in RFC3550? Regards! -Qin ----- Original Message ----- From: "Kevin Gross" To: "IETF AVTCore WG" Sent: Thursday, October 20, 2011 10:59 AM Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Part of my reason for bringing these use cases to the attention of the group relates to a yet unresolved comment I made against the IDMS draft. The draft proposes 64-bit timestamps for arrival times but only 32-bit timestamps for presentation times. A 32-bit NTP timestamp has a 15 microsecond precision. Presentation time synchronization with these timestamps would seem not to clearly meet the requirements of a couple of these use cases. Improving the protocol to support 64-bit timestamps throughout seems to be the straightforward solution. With this change, all timestamps would have the same precision and would have a precision comparable to their reference clocks. The problem with this is that our IDMS work is based on ETSI TISPAN standard TS 183 063. Efforts have been made in the draft to maintain compatibility with this standard. Changing the packet format to accommodate 64-bit timestamps will unravel those efforts. If ETSI compatibility is important, we will have to live with 15 microsecond precision and possibly suggest clever tricks to make the most of it. Which way do we want to go here? On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross wrote: > The requirement for the stereo case is specified differently than the > others. The 10 microsecond figure there applies to _changes in latency_, not > static difference in latency described in all the other cases. Tolerance for > static differences for the stereo case are probably on the order of 1 > millisecond. The first-order effect of static latency differences is to move > one of the speakers - just depends on how fussy you are about real vs. > effective speaker placement. > > > > The 10 microsecond figure is conservative (I've heard anecdotal claims of 1 > microseconds sensitivity) and derives from our ability to accurately locate > sounds based (in part) on comparison of arrival times at each ear. The 10 > microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is. > Here's a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/HAP.html > (see Localisation of Sound Sources section) > > > > Throughout, I've tried to use what I consider reasonable and verifiable > requirements figures. Some will always seem to argue that they need better > performance. > > > > Kevin > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Tuesday, August 16, 2011 9:07 AM > To: IETF AVTCore WG > Subject: Re: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > Mr. Gross, > > The timing assertion for Networked stereo loudspeakers is much tighter that > I would have expected. Placement of stereo speakers within a foot is a > normal rule of thumb for the casual listener - and that is about 1.1ms > delta at room temperature. The ' golden ears' do have ability to detect > small differences especially with high attack waveforms, but I would like to > see the study that showed this small time difference. Can you please provide > a cite? > > And I wonder if the system requirement should be based on the smallest known > delta, unless there is no implementation complexity added to convey the > suggested resolution. > > > > > > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone 202 429 5418 > Fax 202 775 4981 > www.nab.org > Advocacy Education Innovation > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin > Gross > Sent: Monday, August 15, 2011 11:48 PM > To: 'IETF AVTCore WG' > Subject: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > In reviewing the IDMS draft I had volunteered to contribute additional use > cases. Ray Brandenberg suggested that I post them here. > > > > Kevin Gross > > AVA Networks > > Networked stereo loudspeakers > > Because of our ability to localize sound based on inter-aural time > differences, in a stereo listening situation, we are very sensitive to > changes in latency between the two speakers. These changes are perceived as > a shift in or instability of the "sound stage" during critical listening. > These effects are readily noticeable with shifts of 10 microseconds or > smaller. If the individual speakers in a stereo listening setup operate from > independent network interfaces any changing difference in latency between > the two speakers greater than 10 microseconds will be detrimental to the > listening experience. > > Conferencing sound reinforcement system > > A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms, > boardrooms, classrooms (especially those supporting distance learning) and > other such venues. Each participant using such a system has a microphone and > a speaker. There may also be other speakers to provide reinforcement for > non-speaking participants such as in an audience area or jury box. Each > microphone/speaker pair is individually connected to a network and transmits > digital audio to the other devices through the network and receives digital > audio to be reproduced through the speaker over the network. There may be a > central appliance which receives, prioritizes and mixes the microphone > signals. In some systems an individual mix is created for each speaker such > that a speaker's own voice does not come out from his speaker or from those > immediately surrounding him. > > The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels amplified. > Meeting this objective helps insure that natural person-to-person > communication is retained. To this end, it is desirable that the sound > through the system and from the speakers arrive 5 to 30 milliseconds after > the the sound arriving through the air from the person speaking. Delays in > this range invoke the Haas effect which allows listeners to locate the > person speaking based on the sound arriving through the air while the sound > reinforcement system provides the additional gain required to achieve > desired intelligibility. It is also desirable for the sound to come out of > nearby speakers at within 5 milliseconds as longer differential delays will > be perceived as reverberation or echo. > > Video wall > > A video wall consists of multiple computer monitors, video projectors, or > television sets tiled together contiguously or overlapped in order to form > one large screen.# Each of the screens reproduces a portion of the larger > picture. In some implementations, each screen may be individually connected > to the network and receive its portion of the overall image from a > network-connected video server or video scaler. Screens are refreshed at 60 > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh is > not synchronized, the effect of multiple screens acting as one is broken. > > Phased array transducers > > Phased array and wave field synthesis techniques are increasingly used in > audio applications. These techniques work by sending or receiving slightly > different versions of a signal in a spacial sampling arrangement to produce > or record spacial and directional sound fields. The individual transducers > in these applications can be extremely sensitive to differential latency. > Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise ratio. > These microphones are also able to report the location of the speaker for > purposes of automatically aiming a video camera at them. > > Concert sound systems called line arrays allow technicians control over the > amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventing > sound from reaching the roof and back wall of the performance space, the > amount of reflected sound heard by the audience is reduced and the listening > experience is improved. > > In these systems, accuracy in locating or emitting sound is related to > differential latency through basic trigonometry. In these applications, > microseconds of differential latency can translate to degrees of > uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired. > > _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From ray.vanbrandenburg@tno.nl Tue Oct 25 03:45:55 2011 Return-Path: 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 F19E121F84A4 for ; Tue, 25 Oct 2011 03:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 SPppC5S9glYc for ; Tue, 25 Oct 2011 03:45:53 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id D63B621F8B4D for ; Tue, 25 Oct 2011 03:45:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,403,1315173600"; d="scan'208";a="13583169" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 25 Oct 2011 12:45:51 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.01.0323.003; Tue, 25 Oct 2011 12:45:50 +0200 From: "Brandenburg, R. (Ray) van" To: Qin Wu , Kevin Gross , IETF AVTCore WG Thread-Topic: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Thread-Index: AQHMj2AZ1xwxk8RC5UaH+/0nn1Dcj5WGGa8tgABHnZCAABhWuIAADDrAgAAGcVSAAAAa4IAFFSqggAE38SiAAAv6sA== Date: Tue, 25 Oct 2011 10:45:49 +0000 Message-ID: References: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> <900CF177095B48F695F9DFC04E57907A@china.huawei.com> <9C557C5D1922426EB3C570BFD4B9034D@china.huawei.com> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 10:45:55 -0000 Hi Qin, The reason for having an XR block for SC->MSAS communication and an RTCP Pa= cket Type for MSAS->SC is the result of a discussion on the list between Co= lin Perkins, Magnus Westerlund and myself on when to use XR blocks and when= to use RTCP packet types. If I remember correctly, XR blocks should be use= d for the transportation of metrics regarding media transmission and media = reception quality. Since the SC reports on the network delay between Media = Sender and client this should therefore be an XR block. Since the MSAS->SC = communication is more control information than measurement information, it = was deemed that an RTCP packet type would be more appropriate. If you want = to look up the exact arguments that were used in the discussion, you might = want to search the list for it. If I remember correctly, this discussion to= ok place somewhere around the March '11 meeting.=20 Best regards, Ray -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: dinsdag 25 oktober 2011 11:54 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Yes, the format looks good to me. However is it better to define RTCP IDMS = packet type in two direction (i.e., both MSAS->SC communication and SC->MS= AS communication)? In this case, timely feedback can be guaranteed in two directions. and you= still can use XRBLock in the upstream direction to maintain ETSI compatib= ility. That's my 2cents. Regards! -Qin ----- Original Message -----=20 From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Monday, October 24, 2011 11:28 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi, In order to solve both the ETSI compatibility issue as well as the need for= high precision 64bit timestamps, Kevin and I have come up with the followi= ng solution: The current draft describes both an IDMS XR block (for SC->MSAS communicati= on) as well as an RTCP IDMS Packet Type (for MSAS->SC communication). I wou= ld like to propose that we change the length of the Presentation Timestamp = in the IDMS Packet Type to 64bit, while keeping the length of the Presentat= ion Timestamp in the IDMS XR block to 32bits. This way the MSAS is able to = send very precise control commands to the synchronization clients while the= SC->MSAS measurements can remain compatible with ETSI. Since the MSAS will= add additional safety to the measured packet presentation times anyway (e.= g. to allow for jitter), it is not necessary to have 64bit precision measur= ements available on the MSAS.=20 Do you agree with this solution? Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Brand= enburg, R. (Ray) van Sent: vrijdag 21 oktober 2011 11:45 To: Qin Wu; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Ok. I will work together with Kevin to create a new version of the draft. In the meantime we have to try to come to consensus on the Initial Playout = Sync proposal of Fernando Boronat so that we can post a new ID before the n= ext meeting deadline.=20 If I understand correctly, the main question here is the matter in which th= e delay between Media Sender en SC is determined.=20 Ray -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: vrijdag 21 oktober 2011 11:37 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi, ----- Original Message -----=20 From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Friday, October 21, 2011 5:19 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Thanks for comments.=20 > Is it important to save packet size in 32bits at the cost of the accuracy= . > It will be good to see the presentation times follow the format of 64bits= NTP timestamp defined in RFC3550 for SR/RR report unless you have a more s= trong justification for it rather than say thi is not ETSI TISPAN standard = compliant. These statements seem to be contradictory. Do you mean you want to see the = presentation field extended to 64bits, or do you want to keep it at 32bits = to save packet length? [Qin]: I prefer to the former. -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: vrijdag 21 oktober 2011 10:33 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Is it important to save packet size in 32bits at the cost of the accuracy. It will be good to see the presentation times follow the format of 64bits N= TP timestamp defined in RFC3550 for SR/RR report unless you have a more str= ong justification for it rather than say thi is not ETSI TISPAN standard co= mpliant. But I am not judge, this is just my personal opinion. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Friday, October 21, 2011 3:13 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report o= n Packet Receipt Times and a 32bit NTP timestamp to report on Packet Presen= tation Times (plus a 32bit timestamp for the RTP timestamp). The reason we = initially went with only a 32bit NTP timestamp for Packet Presentation time= s was that we figured that the 16 most significant bits of the NTP time (e.= g. the date) would be the same for packet presentation and packet reception= times and that the least significant 16bits (for sub 15 microsecond accura= cy) would not be necessary. We therefore went with the middle 32 bits to li= mit the length of the IDMS packet.=20 What Kevin now suggests, is that in some use cases sub-15 microsecond accur= acy is necessary. He therefore proposes to increase the Packet Presentation= timestamp to 64bits. The only disadvantage with this approach (apart from = a slightly larger packet) is that this would break compatibility with the E= TSI TISPAN standard. Which way do you think we should go here? Best Regards, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin W= u Sent: vrijdag 21 oktober 2011 4:48 To: Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with ones de= fined in RFC3550? Regards! -Qin ----- Original Message ----- From: "Kevin Gross" To: "IETF AVTCore WG" Sent: Thursday, October 20, 2011 10:59 AM Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Part of my reason for bringing these use cases to the attention of the group relates to a yet unresolved comment I made against the IDMS draft. The draft proposes 64-bit timestamps for arrival times but only 32-bit timestamps for presentation times. A 32-bit NTP timestamp has a 15 microsecond precision. Presentation time synchronization with these timestamps would seem not to clearly meet the requirements of a couple of these use cases. Improving the protocol to support 64-bit timestamps throughout seems to be the straightforward solution. With this change, all timestamps would have the same precision and would have a precision comparable to their reference clocks. The problem with this is that our IDMS work is based on ETSI TISPAN standard TS 183 063. Efforts have been made in the draft to maintain compatibility with this standard. Changing the packet format to accommodate 64-bit timestamps will unravel those efforts. If ETSI compatibility is important, we will have to live with 15 microsecond precision and possibly suggest clever tricks to make the most of it. Which way do we want to go here? On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross wro= te: > The requirement for the stereo case is specified differently than the > others. The 10 microsecond figure there applies to _changes in latency_, = not > static difference in latency described in all the other cases. Tolerance = for > static differences for the stereo case are probably on the order of 1 > millisecond. The first-order effect of static latency differences is to m= ove > one of the speakers - just depends on how fussy you are about real vs. > effective speaker placement. > > > > The 10 microsecond figure is conservative (I've heard anecdotal claims of= 1 > microseconds sensitivity) and derives from our ability to accurately loca= te > sounds based (in part) on comparison of arrival times at each ear. The 10 > microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is. > Here's a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/HAP.ht= ml > (see Localisation of Sound Sources section) > > > > Throughout, I've tried to use what I consider reasonable and verifiable > requirements figures. Some will always seem to argue that they need bette= r > performance. > > > > Kevin > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Tuesday, August 16, 2011 9:07 AM > To: IETF AVTCore WG > Subject: Re: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > Mr. Gross, > > The timing assertion for Networked stereo loudspeakers is much tighter th= at > I would have expected. Placement of stereo speakers within a foot is a > normal rule of thumb for the casual listener - and that is about 1.1ms > delta at room temperature. The ' golden ears' do have ability to detect > small differences especially with high attack waveforms, but I would like= to > see the study that showed this small time difference. Can you please prov= ide > a cite? > > And I wonder if the system requirement should be based on the smallest kn= own > delta, unless there is no implementation complexity added to convey the > suggested resolution. > > > > > > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone 202 429 5418 > Fax 202 775 4981 > www.nab.org > Advocacy Education Innovation > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kev= in > Gross > Sent: Monday, August 15, 2011 11:48 PM > To: 'IETF AVTCore WG' > Subject: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > In reviewing the IDMS draft I had volunteered to contribute additional us= e > cases. Ray Brandenberg suggested that I post them here. > > > > Kevin Gross > > AVA Networks > > Networked stereo loudspeakers > > Because of our ability to localize sound based on inter-aural time > differences, in a stereo listening situation, we are very sensitive to > changes in latency between the two speakers. These changes are perceived = as > a shift in or instability of the "sound stage" during critical listening. > These effects are readily noticeable with shifts of 10 microseconds or > smaller. If the individual speakers in a stereo listening setup operate f= rom > independent network interfaces any changing difference in latency between > the two speakers greater than 10 microseconds will be detrimental to the > listening experience. > > Conferencing sound reinforcement system > > A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms, > boardrooms, classrooms (especially those supporting distance learning) an= d > other such venues. Each participant using such a system has a microphone = and > a speaker. There may also be other speakers to provide reinforcement for > non-speaking participants such as in an audience area or jury box. Each > microphone/speaker pair is individually connected to a network and transm= its > digital audio to the other devices through the network and receives digit= al > audio to be reproduced through the speaker over the network. There may be= a > central appliance which receives, prioritizes and mixes the microphone > signals. In some systems an individual mix is created for each speaker su= ch > that a speaker's own voice does not come out from his speaker or from tho= se > immediately surrounding him. > > The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels amplifie= d. > Meeting this objective helps insure that natural person-to-person > communication is retained. To this end, it is desirable that the sound > through the system and from the speakers arrive 5 to 30 milliseconds afte= r > the the sound arriving through the air from the person speaking. Delays i= n > this range invoke the Haas effect which allows listeners to locate the > person speaking based on the sound arriving through the air while the sou= nd > reinforcement system provides the additional gain required to achieve > desired intelligibility. It is also desirable for the sound to come out o= f > nearby speakers at within 5 milliseconds as longer differential delays wi= ll > be perceived as reverberation or echo. > > Video wall > > A video wall consists of multiple computer monitors, video projectors, or > television sets tiled together contiguously or overlapped in order to for= m > one large screen.# Each of the screens reproduces a portion of the larger > picture. In some implementations, each screen may be individually connect= ed > to the network and receive its portion of the overall image from a > network-connected video server or video scaler. Screens are refreshed at = 60 > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh i= s > not synchronized, the effect of multiple screens acting as one is broken. > > Phased array transducers > > Phased array and wave field synthesis techniques are increasingly used in > audio applications. These techniques work by sending or receiving slightl= y > different versions of a signal in a spacial sampling arrangement to produ= ce > or record spacial and directional sound fields. The individual transducer= s > in these applications can be extremely sensitive to differential latency. > Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise rati= o. > These microphones are also able to report the location of the speaker for > purposes of automatically aiming a video camera at them. > > Concert sound systems called line arrays allow technicians control over t= he > amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventing > sound from reaching the roof and back wall of the performance space, the > amount of reflected sound heard by the audience is reduced and the listen= ing > experience is improved. > > In these systems, accuracy in locating or emitting sound is related to > differential latency through basic trigonometry. In these applications, > microseconds of differential latency can translate to degrees of > uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired. > > _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From bill.wu@huawei.com Tue Oct 25 04:03:20 2011 Return-Path: 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 9937F21F8B30 for ; Tue, 25 Oct 2011 04:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.726 X-Spam-Level: X-Spam-Status: No, score=-5.726 tagged_above=-999 required=5 tests=[AWL=0.873, BAYES_00=-2.599, 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 L6P+3CDIrhRx for ; Tue, 25 Oct 2011 04:03:19 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 75BAE21F8B08 for ; Tue, 25 Oct 2011 04:03:18 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTM00K1OC1B92@szxga05-in.huawei.com> for avt@ietf.org; Tue, 25 Oct 2011 19:03:11 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTM00HQ2C19ZH@szxga05-in.huawei.com> for avt@ietf.org; Tue, 25 Oct 2011 19:03:11 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ94901; Tue, 25 Oct 2011 19:02:59 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 19:02:56 +0800 Received: from w53375q (10.138.41.130) by szxeml411-hub.china.huawei.com (10.82.67.138) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 19:02:49 +0800 Date: Tue, 25 Oct 2011 19:02:48 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: "Brandenburg, R. (Ray) van" , Kevin Gross , IETF AVTCore WG Message-id: <1D1EECCC6B67407C993BDD0DA9B47191@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> <900CF177095B48F695F9DFC04E57907A@china.huawei.com> <9C557C5D1922426EB3C570BFD4B9034D@china.huawei.com> Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 11:03:20 -0000 I see. One more suggestion is you'd better make it clear in the document how you calculate 64bits presentation timestamp from 32bits presentation timestamp in the XRBlock. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ; "IETF AVTCore WG" Sent: Tuesday, October 25, 2011 6:45 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, The reason for having an XR block for SC->MSAS communication and an RTCP Packet Type for MSAS->SC is the result of a discussion on the list between Colin Perkins, Magnus Westerlund and myself on when to use XR blocks and when to use RTCP packet types. If I remember correctly, XR blocks should be used for the transportation of metrics regarding media transmission and media reception quality. Since the SC reports on the network delay between Media Sender and client this should therefore be an XR block. Since the MSAS->SC communication is more control information than measurement information, it was deemed that an RTCP packet type would be more appropriate. If you want to look up the exact arguments that were used in the discussion, you might want to search the list for it. If I remember correctly, this discussion took place somewhere around the March '11 meeting. Best regards, Ray -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com] Sent: dinsdag 25 oktober 2011 11:54 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Yes, the format looks good to me. However is it better to define RTCP IDMS packet type in two direction (i.e., both MSAS->SC communication and SC->MSAS communication)? In this case, timely feedback can be guaranteed in two directions. and you still can use XRBLock in the upstream direction to maintain ETSI compatibility. That's my 2cents. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ; "IETF AVTCore WG" Sent: Monday, October 24, 2011 11:28 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi, In order to solve both the ETSI compatibility issue as well as the need for high precision 64bit timestamps, Kevin and I have come up with the following solution: The current draft describes both an IDMS XR block (for SC->MSAS communication) as well as an RTCP IDMS Packet Type (for MSAS->SC communication). I would like to propose that we change the length of the Presentation Timestamp in the IDMS Packet Type to 64bit, while keeping the length of the Presentation Timestamp in the IDMS XR block to 32bits. This way the MSAS is able to send very precise control commands to the synchronization clients while the SC->MSAS measurements can remain compatible with ETSI. Since the MSAS will add additional safety to the measured packet presentation times anyway (e.g. to allow for jitter), it is not necessary to have 64bit precision measurements available on the MSAS. Do you agree with this solution? Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van Sent: vrijdag 21 oktober 2011 11:45 To: Qin Wu; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Ok. I will work together with Kevin to create a new version of the draft. In the meantime we have to try to come to consensus on the Initial Playout Sync proposal of Fernando Boronat so that we can post a new ID before the next meeting deadline. If I understand correctly, the main question here is the matter in which the delay between Media Sender en SC is determined. Ray -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com] Sent: vrijdag 21 oktober 2011 11:37 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi, ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ; "IETF AVTCore WG" Sent: Friday, October 21, 2011 5:19 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Thanks for comments. > Is it important to save packet size in 32bits at the cost of the accuracy. > It will be good to see the presentation times follow the format of 64bits NTP timestamp defined in RFC3550 for SR/RR report unless you have a more strong justification for it rather than say thi is not ETSI TISPAN standard compliant. These statements seem to be contradictory. Do you mean you want to see the presentation field extended to 64bits, or do you want to keep it at 32bits to save packet length? [Qin]: I prefer to the former. -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com] Sent: vrijdag 21 oktober 2011 10:33 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Is it important to save packet size in 32bits at the cost of the accuracy. It will be good to see the presentation times follow the format of 64bits NTP timestamp defined in RFC3550 for SR/RR report unless you have a more strong justification for it rather than say thi is not ETSI TISPAN standard compliant. But I am not judge, this is just my personal opinion. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ; "IETF AVTCore WG" Sent: Friday, October 21, 2011 3:13 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report on Packet Receipt Times and a 32bit NTP timestamp to report on Packet Presentation Times (plus a 32bit timestamp for the RTP timestamp). The reason we initially went with only a 32bit NTP timestamp for Packet Presentation times was that we figured that the 16 most significant bits of the NTP time (e.g. the date) would be the same for packet presentation and packet reception times and that the least significant 16bits (for sub 15 microsecond accuracy) would not be necessary. We therefore went with the middle 32 bits to limit the length of the IDMS packet. What Kevin now suggests, is that in some use cases sub-15 microsecond accuracy is necessary. He therefore proposes to increase the Packet Presentation timestamp to 64bits. The only disadvantage with this approach (apart from a slightly larger packet) is that this would break compatibility with the ETSI TISPAN standard. Which way do you think we should go here? Best Regards, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin Wu Sent: vrijdag 21 oktober 2011 4:48 To: Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with ones defined in RFC3550? Regards! -Qin ----- Original Message ----- From: "Kevin Gross" To: "IETF AVTCore WG" Sent: Thursday, October 20, 2011 10:59 AM Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Part of my reason for bringing these use cases to the attention of the group relates to a yet unresolved comment I made against the IDMS draft. The draft proposes 64-bit timestamps for arrival times but only 32-bit timestamps for presentation times. A 32-bit NTP timestamp has a 15 microsecond precision. Presentation time synchronization with these timestamps would seem not to clearly meet the requirements of a couple of these use cases. Improving the protocol to support 64-bit timestamps throughout seems to be the straightforward solution. With this change, all timestamps would have the same precision and would have a precision comparable to their reference clocks. The problem with this is that our IDMS work is based on ETSI TISPAN standard TS 183 063. Efforts have been made in the draft to maintain compatibility with this standard. Changing the packet format to accommodate 64-bit timestamps will unravel those efforts. If ETSI compatibility is important, we will have to live with 15 microsecond precision and possibly suggest clever tricks to make the most of it. Which way do we want to go here? On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross wrote: > The requirement for the stereo case is specified differently than the > others. The 10 microsecond figure there applies to _changes in latency_, not > static difference in latency described in all the other cases. Tolerance for > static differences for the stereo case are probably on the order of 1 > millisecond. The first-order effect of static latency differences is to move > one of the speakers - just depends on how fussy you are about real vs. > effective speaker placement. > > > > The 10 microsecond figure is conservative (I've heard anecdotal claims of 1 > microseconds sensitivity) and derives from our ability to accurately locate > sounds based (in part) on comparison of arrival times at each ear. The 10 > microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is. > Here's a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/HAP.html > (see Localisation of Sound Sources section) > > > > Throughout, I've tried to use what I consider reasonable and verifiable > requirements figures. Some will always seem to argue that they need better > performance. > > > > Kevin > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Tuesday, August 16, 2011 9:07 AM > To: IETF AVTCore WG > Subject: Re: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > Mr. Gross, > > The timing assertion for Networked stereo loudspeakers is much tighter that > I would have expected. Placement of stereo speakers within a foot is a > normal rule of thumb for the casual listener - and that is about 1.1ms > delta at room temperature. The ' golden ears' do have ability to detect > small differences especially with high attack waveforms, but I would like to > see the study that showed this small time difference. Can you please provide > a cite? > > And I wonder if the system requirement should be based on the smallest known > delta, unless there is no implementation complexity added to convey the > suggested resolution. > > > > > > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone 202 429 5418 > Fax 202 775 4981 > www.nab.org > Advocacy Education Innovation > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin > Gross > Sent: Monday, August 15, 2011 11:48 PM > To: 'IETF AVTCore WG' > Subject: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > In reviewing the IDMS draft I had volunteered to contribute additional use > cases. Ray Brandenberg suggested that I post them here. > > > > Kevin Gross > > AVA Networks > > Networked stereo loudspeakers > > Because of our ability to localize sound based on inter-aural time > differences, in a stereo listening situation, we are very sensitive to > changes in latency between the two speakers. These changes are perceived as > a shift in or instability of the "sound stage" during critical listening. > These effects are readily noticeable with shifts of 10 microseconds or > smaller. If the individual speakers in a stereo listening setup operate from > independent network interfaces any changing difference in latency between > the two speakers greater than 10 microseconds will be detrimental to the > listening experience. > > Conferencing sound reinforcement system > > A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms, > boardrooms, classrooms (especially those supporting distance learning) and > other such venues. Each participant using such a system has a microphone and > a speaker. There may also be other speakers to provide reinforcement for > non-speaking participants such as in an audience area or jury box. Each > microphone/speaker pair is individually connected to a network and transmits > digital audio to the other devices through the network and receives digital > audio to be reproduced through the speaker over the network. There may be a > central appliance which receives, prioritizes and mixes the microphone > signals. In some systems an individual mix is created for each speaker such > that a speaker's own voice does not come out from his speaker or from those > immediately surrounding him. > > The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels amplified. > Meeting this objective helps insure that natural person-to-person > communication is retained. To this end, it is desirable that the sound > through the system and from the speakers arrive 5 to 30 milliseconds after > the the sound arriving through the air from the person speaking. Delays in > this range invoke the Haas effect which allows listeners to locate the > person speaking based on the sound arriving through the air while the sound > reinforcement system provides the additional gain required to achieve > desired intelligibility. It is also desirable for the sound to come out of > nearby speakers at within 5 milliseconds as longer differential delays will > be perceived as reverberation or echo. > > Video wall > > A video wall consists of multiple computer monitors, video projectors, or > television sets tiled together contiguously or overlapped in order to form > one large screen.# Each of the screens reproduces a portion of the larger > picture. In some implementations, each screen may be individually connected > to the network and receive its portion of the overall image from a > network-connected video server or video scaler. Screens are refreshed at 60 > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh is > not synchronized, the effect of multiple screens acting as one is broken. > > Phased array transducers > > Phased array and wave field synthesis techniques are increasingly used in > audio applications. These techniques work by sending or receiving slightly > different versions of a signal in a spacial sampling arrangement to produce > or record spacial and directional sound fields. The individual transducers > in these applications can be extremely sensitive to differential latency. > Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise ratio. > These microphones are also able to report the location of the speaker for > purposes of automatically aiming a video camera at them. > > Concert sound systems called line arrays allow technicians control over the > amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventing > sound from reaching the roof and back wall of the performance space, the > amount of reflected sound heard by the audience is reduced and the listening > experience is improved. > > In these systems, accuracy in locating or emitting sound is related to > differential latency through basic trigonometry. In these applications, > microseconds of differential latency can translate to degrees of > uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired. > > _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From kevin.gross@avanw.com Tue Oct 25 12:22:16 2011 Return-Path: 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 ADA161F0C44 for ; Tue, 25 Oct 2011 12:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.428 X-Spam-Level: * X-Spam-Status: No, score=1.428 tagged_above=-999 required=5 tests=[AWL=-1.301, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=2.601, RDNS_NONE=0.1] 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 eV7yyh+lZ1fi for ; Tue, 25 Oct 2011 12:22:07 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 71B291F0C3F for ; Tue, 25 Oct 2011 12:22:03 -0700 (PDT) Received: (qmail 29293 invoked by uid 0); 25 Oct 2011 19:22:02 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy1.bluehost.com with SMTP; 25 Oct 2011 19:22:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:MIME-Version; bh=OU+hxP5m5KoTuRtbwv1sOTcPot4Fm6CZXRTZINHNovk=; b=V6UKy0JZUGg0z8/1GEtTRjNoYrok2PJ7WBG6oA/20S25HalXHNfK+BeEsh39x9bh+h0APE7AzP+Pbkh/j9+ndN6ixoYnDLHE4cu1BVL4lXLBlSBQvZ4W2uV4X+CE5Zle; Received: from mail-fx0-f44.google.com ([209.85.161.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RImZV-0000Gs-TJ for avt@ietf.org; Tue, 25 Oct 2011 13:22:02 -0600 Received: by faas12 with SMTP id s12so1024240faa.31 for ; Tue, 25 Oct 2011 12:21:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.14.140 with SMTP id g12mr20399665faa.34.1319570519404; Tue, 25 Oct 2011 12:21:59 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Tue, 25 Oct 2011 12:21:59 -0700 (PDT) Date: Tue, 25 Oct 2011 15:21:59 -0400 Message-ID: From: Kevin Gross To: avt@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25de810b01604b024746f X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.161.44 authed with kevin.gross@avanw.com} Subject: [AVTCORE] draft-ietf-avtcore-idms-01 leap seconds X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 19:22:17 -0000 --000e0cd25de810b01604b024746f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Apologies if you've already received this. I first sent it out 19 October but it apparently didn't make it through for some reason. Ray Brandenburg i= s in the process of preparing a new IDMS draft and would appreciate any comments on my leap seconds proposal before including it. I've prepared the following paragraphs which discuss the issue and describe measures required to avoid leap second problems. I propose this be inserted into section 8 of draft-ietf-avtcore-idms-01. A subset of these recommendations are applicable to RFC 3550 applications that make use of the NTP timestamp in sender reports. I=92d be happy to propose corresponding revisions to RFC 3550 once we=92ve ironed out IDMS. "IDMS implementation is simplified by using a clock reference with timescale which does not include leap seconds. IEEE 1588, GPS and other TAI (Inernational Atomic Time) references do not include leap seconds. NTP time, operating system clocks and other UTC (Coordinated Universal Time) references include leap seconds (though the ITU is studying a proposal which could eventually eliminate leap seconds from UTC). If a timescale with leap seconds is used for IDMS, receivers must take care not to generate any IDMS XR reports in the immediate vicinity of the leap second. Synchronization servers must ignore any such reports that may inadvertently generated. Senders using a leap-second-bearing reference must not generate sender reports containing an origination NTP timestamp in the vicinity or a leap second. Receivers should ignore timestamps in any such reports inadvertently generated. Receivers working to a leap-second-bearing reference must also be careful to take leap seconds into account if a leap second occurs between the time a RTP packet is originated and when it is to be presented. "Leap seconds are potentially scheduled at the end of the last day of December and June each year. NTP inserts a leap second at the beginning of the last second of the day. This results in the clock freezing for one second immediately prior to the last second of the affected day. Most system clocks insert the leap second at the end of the last second. This results in repetition of the last second of the day. Generating or using timestamps during the entire last second of a day on which a leap second has been scheduled should therefore be avoided. Note that the period to be avoided has a real-time duration of two seconds. It is also important that all participants correctly implement leap seconds and have a working communications channel to receive notification of leap second scheduling. Without prior knowledge of leap second schedule, NTP servers and clients may be offset by exactly one second with respect to their UTC reference. This potential discrepancy begins when a leap second occurs and ends when all participants receive a time update from a server or peer. Such a long-lived discrepancy can be particularly disruptive to RTP and IDMS operation." --=20 Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org --000e0cd25de810b01604b024746f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Apologies=A0if you've already received this. I fir= st sent it out 19 October but it apparently didn't make it through for = some reason. Ray=A0Brandenburg=A0is in the process of preparing a new IDMS draft= and would appreciate any comments on my leap seconds proposal before inclu= ding it.

I've = prepared the following paragraphs which discuss the issue and
describe measures required to avoid=A0leap= =A0second problems. I propose
this be inserted into section 8 of=A0draft-ietf-avtcore-idms-01. A
subset of these recommendations are applicable to RFC 3550
applications = that make use of the NTP timestamp in sender reports. I=92d
be happy to = propose corresponding revisions to RFC 3550 once we=92ve
ironed out=A0IDMS.

"IDMS=A0implementation is = simplified by using a clock reference with
timescale which does not include=A0leap=A0seconds. IEEE 1588, GPS and<= br> other TAI (Inernational Atomic Time) references do not include=A0leap
seconds. NTP time, operating system= clocks and other UTC (Coordinated
Universal Time) references include=A0leap<= /span>=A0seconds=A0(though the ITU = is
studying a proposal which could eventually eliminate=A0leap=A0seconds= =A0from
UTC). If a timescale with=A0leap=A0= seconds=A0is used for=A0IDMS, receivers
must take care not to generate any=A0IDMS<= /span>=A0XR reports in the immediate
vicinity of the=A0leap=A0second. Sy= nchronization servers must ignore any
such reports that may inadvertently generated. Senders using a
leap-second-bearing reference must not gener= ate sender reports
containing an origination NTP timestamp in the vicinity or a=A0leap
second. Receivers should ignore timestamps in any such reports
inadverte= ntly generated. Receivers working to a=A0l= eap-second-bearing
reference must also be careful to take=A0l= eap=A0seconds=A0into account= if a
leap=A0second occurs between the ti= me a RTP packet is originated and
when it is to be presented.

"L= eap=A0seconds=A0are potentia= lly scheduled at the end of the last day of
December and June each year. NTP inserts a=A0leap=A0second at the
beginning of the last second of the day. This results in the clock
freez= ing for one second immediately prior to the last second of the
affected = day. Most system clocks insert the=A0leap<= /span>=A0second at the end of
the last second. This results in repetition of the last second of the
da= y. Generating or using timestamps during the entire last second of a
day= on which a=A0leap=A0second has bee= n scheduled should therefore be
avoided. Note that the period to be avoided has a real-time duration
of = two=A0seconds. It is also important= that all participants correctly
implement=A0leap=A0seconds=A0and have a working communications channel= to
receive notification of=A0leap=A0se= cond scheduling. Without prior
knowledge of=A0leap=A0second schedu= le, NTP servers and clients may be
offset by exactly one second with respect to their UTC reference. This
p= otential discrepancy begins when a=A0leap<= /span>=A0second occurs and ends when
all participants receive a time update from a server or peer. Such a
lon= g-lived discrepancy can be particularly disruptive to RTP and=A0IDMS
operation."

--
Kevin Gross<= br>
Media Network Consultant
AVA = Networks -=A0www.AVAnw.= com,=A0www.X192.org


--000e0cd25de810b01604b024746f-- From ray.vanbrandenburg@tno.nl Wed Oct 26 00:27:29 2011 Return-Path: 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 2251021F84D2 for ; Wed, 26 Oct 2011 00:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 NOfn3kz12NX6 for ; Wed, 26 Oct 2011 00:27:26 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id ED05521F84CC for ; Wed, 26 Oct 2011 00:27:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,408,1315173600"; d="scan'208,217";a="59439495" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 26 Oct 2011 09:27:13 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.01.0323.003; Wed, 26 Oct 2011 09:27:13 +0200 From: "Brandenburg, R. (Ray) van" To: "avt@ietf.org" Thread-Topic: Comments on draft-westerlund-avtcore-rtp-simulcast-00 Thread-Index: AcyTIZ2iVQibSCxwScyjBkbRqff1xw== Date: Wed, 26 Oct 2011 07:27:13 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA158155893E1EXCMBX03tsntnon_" MIME-Version: 1.0 Subject: [AVTCORE] Comments on draft-westerlund-avtcore-rtp-simulcast-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 07:27:29 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA158155893E1EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Magnus, I reviewed your draft draft-westerlund-avtcore-rtp-simulcast-00 and have so= me questions/comments: - Section 3: This section lacks a summary/conclusion. A number of = different scenarios are introduced, some of which are explicitly stated to = be out-of-scope (e.g. 3.5), and some are stated to be in-scope (e.g. 3.3). = Some scenarios however (e.g. 3.2) are not specified to be either in- or out= -of-scope. - Section 3: This section talks quite a bit about the relation bet= ween Simulcast and Scalable Coding and in which situations one of the two i= s more suitable. I'm not sure why this is relevant. Simulcast and Scalable = Coding might be two techniques that in some cases can be used to solve the = same problem, the layer on which they do this is completely different (code= c-level versus transport level). The fact that Scalable Coding might, in so= me situations, be a better solution than Simulcast does not mean that Simul= cast should not be standardized to handle those situations. I understand th= at you've written this mainly from a video conferencing perspective, in whi= ch Scalable Coding might be used more often, but in a lot of situations, su= ch as IPTV, Scalable Coding is just not an option due to its inherent compl= exity. In these situations Simulcast might be able to solve some real issue= s, despite the fact that Scalable Coding might be able to solve these issue= s more efficiently. - Section 3.1.1 See comment above. Why is this section relevant to= the rest of the document? - Section 3.2.1: This scenario is the only one of the scenarios in= section 3 to make a clear pro/con of SSRC versus Session based multiplexin= g. Furthermore, it does so before the actual discussion of SSRC vs. Session= -based multiplexing is introduced in section 4. - Section 3.3: For the tiled streaming use case described below, t= his scenario is especially relevant. Is there any technical reason why it h= as less emphasis than the RTP-Mixer scenario? - Section 5.5: Your conclusion here is that Session Based Multiple= xing is the best choice, since SSRC multiplexing seems to require a large a= mount of extensions in order to work. How does this conclusion relate to th= e draft-lennox-rtcweb-rtp-media-type-mux-00 which seems to suggest that SSR= C multiplexing is not that difficult? (I should note that I have no experie= nce with sending multiple streams inside a single RTP session, so it could = be that I don't understand the issues correctly) - Section 6.2: How do you suggest the sequence numbers and RTP tim= estamps are handled between multiple alternative streams? Would it make thi= ngs easier if these were aligned across multiple streams? And one more remark: - In the introduction session you describe three different ways in= which the encoding of a media content can differ: bit-rate, codec and samp= ling. Recent work in the area of immersive media has proposed a fourth meth= od: tiled video. With tiled video (or spatial segmentation), the video resu= lting from a single camera is split into a number of areas, each focusing o= n a particular spatial area of the video (e.g. a single video source could = be tiled into four separate video streams, one describing the topleft quart= er of the video and three more describing the topright, bottomleft and bott= omright quarters respectively). Are you willing to extend the scope of this document to include the tiled v= ideo scenario? Best Regards, Ray van Brandenburg This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA158155893E1EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Magnus,

 

I reviewed your draft draft-wes= terlund-avtcore-rtp-simulcast-00 and have some questions/comments:

 

-  = ;        Section 3: This section= lacks a summary/conclusion. A number of different scenarios are introduced= , some of which are explicitly stated to be out-of-scope (e.g. 3.5), and so= me are stated to be in-scope (e.g. 3.3). Some scenarios however (e.g. 3.2) are not specified to be either in-= or out-of-scope.

 =

-  = ;        Section 3: This section= talks quite a bit about the relation between Simulcast and Scalable Coding= and in which situations one of the two is more suitable. I’m not sur= e why this is relevant. Simulcast and Scalable Coding might be two techniques that in some cases can be used to solve the= same problem, the layer on which they do this is completely different (cod= ec-level versus transport level). The fact that Scalable Coding might, in s= ome situations, be a better solution than Simulcast does not mean that Simulcast should not be standardized to = handle those situations. I understand that you’ve written this mainly= from a video conferencing perspective, in which Scalable Coding might be u= sed more often, but in a lot of situations, such as IPTV, Scalable Coding is just not an option due to its inherent co= mplexity. In these situations Simulcast might be able to solve some real is= sues, despite the fact that Scalable Coding might be able to solve these is= sues more efficiently.

 =

-  = ;        Section 3.1.1 See comme= nt above. Why is this section relevant to the rest of the document?

 =

-  = ;        Section 3.2.1: This sce= nario is the only one of the scenarios in section 3 to make a clear pro/con= of SSRC versus Session based multiplexing. Furthermore, it does so before = the actual discussion of SSRC vs. Session-based multiplexing is introduced in section 4. <= /p>

 =

-  = ;        Section 3.3: For the ti= led streaming use case described below, this scenario is especially relevan= t. Is there any technical reason why it has less emphasis than the RTP-Mixe= r scenario?

 

-  = ;        Section 5.5: Your concl= usion here is that Session Based Multiplexing is the best choice, since SSR= C multiplexing seems to require a large amount of extensions in order to wo= rk. How does this conclusion relate to the draft-lennox-rtcweb-rtp-media-type-mux-00 which seems to suggest th= at SSRC multiplexing is not that difficult? (I should note that I have no e= xperience with sending multiple streams inside a single RTP session, so it = could be that I don’t understand the issues correctly)

 =

-  = ;        Section 6.2: How do you= suggest the sequence numbers and RTP timestamps are handled between multip= le alternative streams? Would it make things easier if these were aligned a= cross multiple streams?

 =

And one more remark:=

 

-  = ;        In the introduction ses= sion you describe three different ways in which the encoding of a media con= tent can differ: bit-rate, codec and sampling. Recent work in the area of i= mmersive media has proposed a fourth method: tiled video. With tiled video (or spatial segmentation), the video= resulting from a single camera is split into a number of areas, each focus= ing on a particular spatial area of the video (e.g. a single video source c= ould be tiled into four separate video streams, one describing the topleft quarter of the video and three m= ore describing the topright, bottomleft and bottomright quarters respective= ly).

 

Are you willing to extend the s= cope of this document to include the tiled video scenario?

 

Best Regards,=

 

Ray van Brandenburg<= /span>

 

This e-mail and its contents are subject to the DI= SCLAIMER at http://www.tno.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA158155893E1EXCMBX03tsntnon_-- From Even.roni@huawei.com Wed Oct 26 01:38:44 2011 Return-Path: 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 C891D21F8B07 for ; Wed, 26 Oct 2011 01:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.301 X-Spam-Level: X-Spam-Status: No, score=-106.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 YKVb34uc8bc3 for ; Wed, 26 Oct 2011 01:38:43 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B79CB21F84CC for ; Wed, 26 Oct 2011 01:38:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTN006HDZZ2GE@szxga03-in.huawei.com> for avt@ietf.org; Wed, 26 Oct 2011 16:37:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTN00HYFZZ2K3@szxga03-in.huawei.com> for avt@ietf.org; Wed, 26 Oct 2011 16:37:50 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LTN00CISZYXQO@szxml11-in.huawei.com>; Wed, 26 Oct 2011 16:37:50 +0800 (CST) Date: Wed, 26 Oct 2011 10:35:20 +0200 From: Roni Even To: avt@ietf.org Message-id: <090a01cc93ba$358b6630$a0a23290$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcyJ0tBv7Vrm/HztRrmpwVkSa79xxgDmWW0Q Cc: 'Magnus Westerlund' Subject: [AVTCORE] avtcore - session for IETF 82 - requests for agenda time - reminder X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 08:38:44 -0000 Hi, This is the schedule for AVTcore. Monday November 14th , Afternoon Session I 1300-1500 Room Name: 101C If you wish to have agenda time at the upcoming meeting in Taipei regarding AVTcore work, please send an agenda request to the AVTcore chairs. We are trying to prepare the agenda early and not wait for the last minute. So far I got requests from Ali, Ray, Qin and Varun. We need to publish the agenda next week so please send your requests. Thanks Roni Even AVTcore co-chair From harald@alvestrand.no Wed Oct 26 10:19:11 2011 Return-Path: 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 0783121F85C7 for ; Wed, 26 Oct 2011 10:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.349 X-Spam-Level: X-Spam-Status: No, score=-110.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 rp8U8pj2Q+Mv for ; Wed, 26 Oct 2011 10:19:10 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF2321F84A5 for ; Wed, 26 Oct 2011 10:19:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 52EC239E106 for ; Wed, 26 Oct 2011 19:19:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1s8NL5V9dl4 for ; Wed, 26 Oct 2011 19:19:08 +0200 (CEST) Received: from [172.19.28.23] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4974C39E082 for ; Wed, 26 Oct 2011 19:19:08 +0200 (CEST) Message-ID: <4EA8410A.7070801@alvestrand.no> Date: Wed, 26 Oct 2011 10:19:06 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "avt@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [AVTCORE] Max SSRC declaration: Objection to retrofitting rules X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:19:11 -0000 Hello, I have read through draft-westerlund-avtcore-max-ssrc, and generally I find it a fine specification, which allows us to be explicit about an aspect of RTP usage that was not previously explicit. However, I do have one strong objection to two specific paragraph: When max-send-ssrc or max-recv-ssrc are not included in the SDP, it MUST be interpreted as equivalent to a limit of one, unless sendonly or recvonly attributes are specified, in which case the limit is implicitly zero for the corresponding unused direction. ..... In case an answer fails to include any of the limitation attributes, the agent SHOULD be interpreted as capable of supporting only a single stream in the direction for which attributes are missing. If I read this correctly: - There is no way to tell from SDP whether or not the sender or recipient intends to conform to the max-ssrc draft: The extension itself is not signalled. - Therefore, it seems that the intent of the paragraph is to change the rules about how to interpret SDP messages that do NOT contain any hint that their sender is conforming to max-ssrc - Therefore, the draft, if taken literally as written, would retroactively declare all usage of multiple SSRCs in a single RTP session to be noncompliant with its SDP declaration. That seems to me to be an entirely unreasonable thing to do, given that implementations are using multiple SSRCs on single RTP sessions every minute of every day. I would not object to a section that instead said: When max-send-ssrc or max-recv-ssrc are not included in the SDP, no information about the supported number of SSRCs is available, unless sendonly or recvonly attributes are specified, in which case the limit is implicitly zero for the corresponding unused direction. If a specific deployment is protected by gateways that modify SDP, and have knowledge of a specific limit active within that deployment, those gateways MAY choose to add max-*-ssrc attributes to the SDP exchanged with the outside world, to indicate the limited capacity of those devices. ..... In case an answer fails to include any of the limitation attributes, local heuristics SHOULD be applied to produce a reasonable guess at the capacity of the responding agent. Declaring a class of deployments non-conformant by IETF fiat is not, in my opinion, a reasonable option. Encouraging the deployers of limited-function devices to be explicit about those limitations is a reasonable option. Harald From magnus.westerlund@ericsson.com Thu Oct 27 06:36:01 2011 Return-Path: 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 2CBDF21F8532 for ; Thu, 27 Oct 2011 06:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 cbJQpyZdbpES for ; Thu, 27 Oct 2011 06:36:00 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AE64C21F84CF for ; Thu, 27 Oct 2011 06:35:59 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-74-4ea95e3e60f2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 00.9B.20773.E3E59AE4; Thu, 27 Oct 2011 15:35:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 27 Oct 2011 15:35:58 +0200 Message-ID: <4EA95E3C.2020907@ericsson.com> Date: Thu, 27 Oct 2011 15:35:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Roni Even References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <06ad01cc90b2$e6b4d190$b41e74b0$%roni@huawei.com> In-Reply-To: <06ad01cc90b2$e6b4d190$b41e74b0$%roni@huawei.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 - more X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 13:36:01 -0000 Hi Roni, Thanks for the feedback. On 2011-10-22 14:05, Roni Even wrote: > > 1. In section 7.2 "All session participants connected over the > same transport will need to use the same initiation method." maybe say > MUST use instead of will need to use. sure. > > 2. In section 7.2 " If support for both in-band and out-of-band > mechanisms is signalled, the sender SHOULD try ECN negotiation using > STUN with ICE first, and if it fails, fallback to negotiation using RTP > and RTCP ECN feedback" I think that it should say that the sender should > offer ice initialization method before rtp. I would suggest to formulate this as: If support for both in-band and out-of-band mechanisms are signalled, the sender when negotiating SHOULD offer detection of ECT using STUN with ICE with higher priority than detection of ECT using RTP and RTCP. > > 3. In section 7.2.1 y ou refer not reference the keep-alive RFC Why do you think we should reference RFC 6263? Is is because we discuss which packets would have least impact on the media flow when used as ECT probes? IF that is the reasons I don't think RFC6263 has much to offer. The outcome of this document is that nothing short of real RTP or RTCP packets work well for keep-alive. And in this context of ECN we can't use the RTCP packets. > > 4. In section 7.2.1 Generating RTCP ECN Feedback it says > "Reception of subsequent ECN-CE marked packets MUST result in > additional early or immediate ECN". Why use MUST and not SHOULD since > there is an exception case following the sentence. Because if we use SHOULD then one might consider that additional exceptions than just that one exists. And that is not the case. If you use a method that requires timely feedback, then you better send that feedback. > > 5. In section 7.2.1 "ECN initiation is considered to have failed > at the instant when a ny RTP s an RTCP packet that doesn't contain an > RTCP ECN feedback report or ECN summary report " The RTCP ECN feedback > report may be missing for other reasons like no timely response or using > AVP profile. I think you are misunderstanding what was written, maybe because of the bad formulation in the sentence. I have rewritten this to: ECN initiation is considered to have failed at the instant the initiating RTP sender received an RTCP packet that doesn't contain an RTCP ECN feedback report or ECN summary report from any RTP session participant that has an RTCP RR with an extended RTP sequence number field that indicates that it should have received multiple (>3) ECT marked RTP packets. Is that clearer? > > 6. In section 7.3.3 receiver driven congestion control you mention > layered codecs as an option I think that using ccm tmbbr is more useful > when there are no layered codecs in use (more common today) and should > be mentioned in this section. I am very split about discussing this. I know there exist implementations that uses TMMBR as primary congestion control. However, RFC 5104 hasn't specified it in that way. I also see an issue with bringing it up in this context, namely that we bless this without any specification or requirements on the solution. For example how responsive to congestion is the usage of TMMBR. One parameter is the AVPF operations mode and due to this RTCP bandwidths. another is the algorithm determining the appropriate bit-rate. I know that the multicast scalable encoding share similar concerns but there we have even less alternatives. I think reformulating the introduction of the section to make clear that this is just an example of Receiver driven congestion control is most appropriate. In a receiver driven congestion control mechanism, the receivers can react to the ECN-CE marks themselves without providing ECN-CE feedback to the sender. This may allow faster response than sender-driven congestion control in some circumstances and also scale to large number of receivers and multicast usage. One example of receiver-driven congestion control is implemented by providing the content in a layered way, with each layer providing improved media quality but also increased bandwidth usage. > > 7.&nbs ; In section 10.6 you use the wrong range definition "From RFC > 5389: STUN Attribute types in the first half of the > comprehension-requiredrange (0x0000 - 0x3FFF) and in the first half of > the comprehension- optional range (0x8000 - 0xBFFF) are assigned by IETF > Review" > Good catch. Thanks Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Even.roni@huawei.com Thu Oct 27 06:59:45 2011 Return-Path: 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 7584621F8AF7 for ; Thu, 27 Oct 2011 06:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.319 X-Spam-Level: X-Spam-Status: No, score=-106.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 PmALwvQgsSjz for ; Thu, 27 Oct 2011 06:59:44 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 763F021F8ACE for ; Thu, 27 Oct 2011 06:59:44 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTQ007IL9D9OI@szxga03-in.huawei.com> for avt@ietf.org; Thu, 27 Oct 2011 21:55:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTQ00G559D9WL@szxga03-in.huawei.com> for avt@ietf.org; Thu, 27 Oct 2011 21:55:57 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LTQ00G4D9CYX0@szxml12-in.huawei.com>; Thu, 27 Oct 2011 21:55:57 +0800 (CST) Date: Thu, 27 Oct 2011 15:53:14 +0200 From: Roni Even In-reply-to: <4EA95E3C.2020907@ericsson.com> To: 'Magnus Westerlund' Message-id: <09a801cc94af$cdd3f6f0$697be4d0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcyUrWh6Z/76n20/TuKlu621VZYGEAAAlLPw References: <016101cc7f6c$9795e380$c6c1aa80$%roni@huawei.com> <06ad01cc90b2$e6b4d190$b41e74b0$%roni@huawei.com> <4EA95E3C.2020907@ericsson.com> Cc: avt@ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 - more X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 13:59:45 -0000 Magnus, I am OK with your answers Roni > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, October 27, 2011 3:36 PM > To: Roni Even > Cc: avt@ietf.org > Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04 - = more >=20 > Hi Roni, >=20 > Thanks for the feedback. >=20 >=20 > On 2011-10-22 14:05, Roni Even wrote: > > > > 1. In section 7.2 "All session participants connected over the > > same transport will need to use the same initiation method." maybe > say > > MUST use instead of will need to use. >=20 > sure. >=20 > > > > 2. In section 7.2 " If support for both in-band and = out-of-band > > mechanisms is signalled, the sender SHOULD try ECN negotiation using > > STUN with ICE first, and if it fails, fallback to negotiation using > RTP > > and RTCP ECN feedback" I think that it should say that the sender > should > > offer ice initialization method before rtp. >=20 > I would suggest to formulate this as: >=20 > If support for both in-band and out-of-band mechanisms are signalled, > the sender when negotiating SHOULD offer detection of ECT using STUN > with ICE with higher priority than detection of ECT using RTP and = RTCP. >=20 >=20 > > > > 3. In section 7.2.1 y ou refer not reference the keep-alive = RFC >=20 > Why do you think we should reference RFC 6263? Is is because we = discuss > which packets would have least impact on the media flow when used as > ECT > probes? IF that is the reasons I don't think RFC6263 has much to = offer. > The outcome of this document is that nothing short of real RTP or RTCP > packets work well for keep-alive. And in this context of ECN we can't > use the RTCP packets. >=20 > > > > 4. In section 7.2.1 Generating RTCP ECN Feedback it says > > "Reception of subsequent ECN-CE marked packets MUST result in > > additional early or immediate ECN". Why use MUST and not SHOULD = since > > there is an exception case following the sentence. >=20 > Because if we use SHOULD then one might consider that additional > exceptions than just that one exists. And that is not the case. If you > use a method that requires timely feedback, then you better send that > feedback. >=20 > > > > 5. In section 7.2.1 "ECN initiation is considered to have > failed > > at the instant when a ny RTP s an RTCP packet that doesn't contain > an > > RTCP ECN feedback report or ECN summary report " The RTCP ECN > feedback > > report may be missing for other reasons like no timely response or > using > > AVP profile. >=20 > I think you are misunderstanding what was written, maybe because of = the > bad formulation in the sentence. I have rewritten this to: >=20 > ECN initiation is considered to have failed at the instant the > initiating RTP sender received an RTCP packet that doesn't contain an > RTCP ECN feedback report or ECN summary report from any RTP session > participant that has an RTCP RR with an extended RTP sequence number > field that indicates that it should have received multiple (>3) ECT > marked RTP packets. >=20 > Is that clearer? >=20 >=20 > > > > 6. In section 7.3.3 receiver driven congestion control you > mention > > layered codecs as an option I think that using ccm tmbbr is more > useful > > when there are no layered codecs in use (more common today) and > should > > be mentioned in this section. >=20 > I am very split about discussing this. I know there exist > implementations that uses TMMBR as primary congestion control. = However, > RFC 5104 hasn't specified it in that way. >=20 > I also see an issue with bringing it up in this context, namely that = we > bless this without any specification or requirements on the solution. > For example how responsive to congestion is the usage of TMMBR. One > parameter is the AVPF operations mode and due to this RTCP = bandwidths. > another is the algorithm determining the appropriate bit-rate. >=20 > I know that the multicast scalable encoding share similar concerns but > there we have even less alternatives. >=20 > I think reformulating the introduction of the section to make clear > that > this is just an example of Receiver driven congestion control is most > appropriate. >=20 >=20 > In a receiver driven congestion control mechanism, the receivers can > react to the ECN-CE marks themselves without providing ECN-CE feedback > to the sender. This may allow faster response than sender-driven > congestion control in some circumstances and also scale to large = number > of receivers and multicast usage. One example of receiver-driven > congestion control is implemented by providing the content in a = layered > way, with each layer providing improved media quality but also > increased > bandwidth usage. >=20 > > > > 7.&nbs ; In section 10.6 you use the wrong range definition "From > RFC > > 5389: STUN Attribute types in the first half of the > > comprehension-requiredrange (0x0000 - 0x3FFF) and in the first half > of > > the comprehension- optional range (0x8000 - 0xBFFF) are assigned by > IETF > > Review" > > >=20 > Good catch. >=20 > Thanks >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From jonathan@vidyo.com Thu Oct 27 08:58:17 2011 Return-Path: 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 3800521F8C2F; Thu, 27 Oct 2011 08:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] 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 8UOscupigXxk; Thu, 27 Oct 2011 08:58:16 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id ACC4721F8C2B; Thu, 27 Oct 2011 08:58:16 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D3BF47A0B3B; Thu, 27 Oct 2011 11:58:15 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 915647A0C63; Thu, 27 Oct 2011 11:57:54 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Thu, 27 Oct 2011 11:57:51 -0400 From: Jonathan Lennox To: Colin Perkins Date: Thu, 27 Oct 2011 11:57:53 -0400 Thread-Topic: [rtcweb] Fwd: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt Thread-Index: AcyUwSaqbGDvgmXZTuGxetCa4yUwng== Message-ID: <0B68D2E0-3480-47FB-8427-4032FD7B18F6@vidyo.com> References: <20111024232740.11885.97235.idtracker@ietfa.amsl.com> <462F77C3-8CAD-4699-9238-71B5C9EF7F9B@csperkins.org> In-Reply-To: <462F77C3-8CAD-4699-9238-71B5C9EF7F9B@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , IETF AVTCore WG Subject: Re: [AVTCORE] [rtcweb] Fwd: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:58:17 -0000 Hi, Colin -- Thanks for taking a look my draft! I saw this recommendation in the multiplex-architecture draft, after I fini= shed my own (I didn't get a chance to read any other -00 drafts before fini= shing my own before the deadline). I think this is an AVTCore issue, so I'm following up there...further discu= ssion should probably just be on AVTCore, unless there are WebRTC-specific = issues. The multiplexing-architecture draft in general is a very good draft -- it's= extremely thorough and useful -- but I admit to not being very convinced b= y that section of it. At small numbers of sources, self-reporting and cross-reporting does indeed= use a fairly small amount of bandwidth, but the problem is that their band= width usage is quadratic in the number of sources, since every source must = report on every other. So as the number of sources grows, they begin to con= sume all RTCP bandwidth sending redundant or trivial information. And this for the sake of third-party monitors, which (personally) I've neve= r seen deployed outside a research environment, and seem architecturally du= bious to me, at least for offer-answer negotiated streams. (IPTV and other = declarative-SDP architectures are probably different.) On Oct 27, 2011, at 11:12 AM, Colin Perkins wrote: > Jonathan, >=20 > Thanks for submitting. This is a good draft. >=20 > One comment: Section 3.1 suggests that a source generating multiple RTP s= treams, with multiple SSRCs, should not send RTCP reports for its own media= , and should pick a single SSRC to use when sending reports on other media.= I agree that this would save a small amount of bandwidth, but I think the = savings are negligible, it complicates the monitoring model, and so is a mi= stake. We talk about this in draft-westerlund-avtcore-multiplex-architectur= e-00 (Section 9, in particular). >=20 > Cheers, > Colin -- Jonathan Lennox jonathan@vidyo.com From ray.vanbrandenburg@tno.nl Fri Oct 28 05:46:43 2011 Return-Path: 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 6C52721F8AF1 for ; Fri, 28 Oct 2011 05:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 AkGbwCUQya+U for ; Fri, 28 Oct 2011 05:46:31 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id A3AD821F8A7E for ; Fri, 28 Oct 2011 05:46:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,418,1315173600"; d="scan'208,217";a="13618685" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 28 Oct 2011 14:46:19 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0323.003; Fri, 28 Oct 2011 14:46:19 +0200 From: "Brandenburg, R. (Ray) van" To: Kevin Gross , "avt@ietf.org" Thread-Topic: [AVTCORE] draft-ietf-avtcore-idms-01 leap seconds Thread-Index: AQHMk0tvkrbrD78FpUKkwO21I60tOpWRt6Bw Date: Fri, 28 Oct 2011 12:46:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581558A955EXCMBX03tsntnon_" MIME-Version: 1.0 Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 leap seconds X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 12:46:43 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581558A955EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, So far I haven't seen any comments on Kevin's proposal (detailed below) on = the Leap Second issue . If you have any comments or opinions on the changes= /updates Kevin proposes, please send them by Sunday at the latest. In the absence of any further comments I will assume that no one objects an= d I will update the IDMS draft and publish the updated version before the d= eadline on Monday. Best regards, Ray van Brandenburg From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin= Gross Sent: dinsdag 25 oktober 2011 21:22 To: avt@ietf.org Subject: [AVTCORE] draft-ietf-avtcore-idms-01 leap seconds Apologies if you've already received this. I first sent it out 19 October b= ut it apparently didn't make it through for some reason. Ray Brandenburg is= in the process of preparing a new IDMS draft and would appreciate any comm= ents on my leap seconds proposal before including it. I've prepared the following paragraphs which discuss the issue and describe measures required to avoid leap second problems. I propose this be inserted into section 8 of draft-ietf-avtcore-idms-01. A subset of these recommendations are applicable to RFC 3550 applications that make use of the NTP timestamp in sender reports. I'd be happy to propose corresponding revisions to RFC 3550 once we've ironed out IDMS. "IDMS implementation is simplified by using a clock reference with timescale which does not include leap seconds. IEEE 1588, GPS and other TAI (Inernational Atomic Time) references do not include leap seconds. NTP time, operating system clocks and other UTC (Coordinated Universal Time) references include leap seconds (though the ITU is studying a proposal which could eventually eliminate leap seconds from UTC). If a timescale with leap seconds is used for IDMS, receivers must take care not to generate any IDMS XR reports in the immediate vicinity of the leap second. Synchronization servers must ignore any such reports that may inadvertently generated. Senders using a leap-second-bearing reference must not generate sender reports containing an origination NTP timestamp in the vicinity or a leap second. Receivers should ignore timestamps in any such reports inadvertently generated. Receivers working to a leap-second-bearing reference must also be careful to take leap seconds into account if a leap second occurs between the time a RTP packet is originated and when it is to be presented. "Leap seconds are potentially scheduled at the end of the last day of December and June each year. NTP inserts a leap second at the beginning of the last second of the day. This results in the clock freezing for one second immediately prior to the last second of the affected day. Most system clocks insert the leap second at the end of the last second. This results in repetition of the last second of the day. Generating or using timestamps during the entire last second of a day on which a leap second has been scheduled should therefore be avoided. Note that the period to be avoided has a real-time duration of two seconds. It is also important that all participants correctly implement leap seconds and have a working communications channel to receive notification of leap second scheduling. Without prior knowledge of leap second schedule, NTP servers and clients may be offset by exactly one second with respect to their UTC reference. This potential discrepancy begins when a leap second occurs and ends when all participants receive a time update from a server or peer. Such a long-lived discrepancy can be particularly disruptive to RTP and IDMS operation." -- Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com, www.X192.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581558A955EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 = ;

So far I h= aven’t seen any comments on Kevin’s proposal (detailed below) o= n the Leap Second issue . If you have any comments or opinions on the changes/updates Kevin proposes, please send them by Sunday at the latest. =

 = ;

In the abs= ence of any further comments I will assume that no one objects and I will u= pdate the IDMS draft and publish the updated version before the deadline on Monday.

 

Best regards,

 

Ray van Brandenburg

 = ;

 = ;

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin Gross
Sent: dinsdag 25 oktober 2011 21:22
To: avt@ietf.org
Subject: [AVTCORE] draft-ietf-avtcore-idms-01 leap seconds

 

Apologies if you'v= e already received this. I first sent it out 19 October but it apparently d= idn't make it through for some reason. Ray Brandenburg<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";background:white"> is in the process of preparing a new IDMS = draft and would appreciate any comments on my leap seconds proposal before including it.

 

I've prepared the follow= ing paragraphs which discuss the issue and
describe measures required to avoid leap second proble= ms. I propose
this be inserted into section 8 of draft-ietf-avtcore-idms-= 01. A
subset of these recommendations are applicable to RFC 3550
applications that make use of the NTP timestamp in sender reports. I’= d
be happy to propose corresponding revisions to RFC 3550 once we’ve
ironed out IDMS.

"IDMS implementation is simplified by using a clock re= ference with
timescale which does not include leap secondsleap
seconds. NTP time, operating system clocks and other UTC (Coordi= nated
Universal Time) references include leap seconds (though the ITU is
studying a proposal which could eventually eliminate leap&n= bsp;seconds from
UTC). If a timescale with leap seconds = ;is used for IDMS, receivers
must take care not to generate any IDMS XR reports in = the immediate
vicinity of the lea= p second. Synchronization servers m= ust ignore any
such reports that may inadvertently generated. Senders using a
leap-second-bearing reference must not generate sender reports=
containing an origination NTP timestamp in the vicinity or a leap
second. Receivers should ignore timestamps in any such reports
inadvertently generated. Receivers working to a leap-second= -bearing
reference must also be careful to take leap seconds into account if a
leap second occurs between the time a RTP packet is origi= nated and
when it is to be presented.

"Leap seconds are potentially scheduled at the end of the last day of
December and June each year. NTP inserts a leap second= at the
beginning of the last second of the day. This results in the clock
freezing for one second immediately prior to the last second of the
affected day. Most system clocks insert the leap secon= d at the end of
the last second. This results in repetition of the last second of the
day. Generating or using timestamps during the entire last second of a
day on which a leap=  second has been scheduled should t= herefore be
avoided. Note that the period to be avoided has a real-time duration
of two seconds. It is also important that all participants = correctly
implement leap seconds and have a working communications channel to
receive notification of leap second scheduling. Withou= t prior
knowledge of leap second schedule, NTP servers and cli= ents may be
offset by exactly one second with respect to their UTC reference. This
potential discrepancy begins when a leap second occurs= and ends when
all participants receive a time update from a server or peer. Such a
long-lived discrepancy can be particularly disruptive to RTP and IDMS
operation."

 

--
Kevin Gross

Media Network Consultant

AVA Networks - www.AVAnw.com, www.X192.org

 

 

This e-mail and its contents are subject to the DI= SCLAIMER at http://www.tno.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581558A955EXCMBX03tsntnon_-- From ray.vanbrandenburg@tno.nl Fri Oct 28 05:49:12 2011 Return-Path: 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 8919A21F8B62 for ; Fri, 28 Oct 2011 05:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.703 X-Spam-Level: X-Spam-Status: No, score=0.703 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 HlTlfwSXLD27 for ; Fri, 28 Oct 2011 05:49:10 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id 387DF21F8B48 for ; Fri, 28 Oct 2011 05:49:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,418,1315173600"; d="scan'208";a="59577413" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 28 Oct 2011 14:49:09 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.01.0323.003; Fri, 28 Oct 2011 14:49:08 +0200 From: "Brandenburg, R. (Ray) van" To: Kevin Gross , IETF AVTCore WG Thread-Topic: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Thread-Index: AQHMj2AZ1xwxk8RC5UaH+/0nn1Dcj5WGGa8tgABHnZCAABhWuIAADDrAgAAGcVSAAAAa4IAFFSqggAE38SiAAAv6sIAABzBsgATUDsA= Date: Fri, 28 Oct 2011 12:49:08 +0000 Message-ID: References: <67099C86A4654DE8ADBFFDB63284C9BB@china.huawei.com> <900CF177095B48F695F9DFC04E57907A@china.huawei.com> <9C557C5D1922426EB3C570BFD4B9034D@china.huawei.com> <1D1EECCC6B67407C993BDD0DA9B47191@china.huawei.com> In-Reply-To: <1D1EECCC6B67407C993BDD0DA9B47191@china.huawei.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 12:49:12 -0000 Hi all, Apart from Qin I haven't seen any comments on the proposal to extend the Pr= esentation Timestamp field in the IDMS Packet Type to 64bit to allow for hi= gh-precision use cases as outlined by Kevin . If you have any comments or o= pinions on this change/update, please send them by Sunday at the latest.=20 In the absence of any further comments I will assume that no one objects an= d I will update the IDMS draft and publish the updated version before the d= eadline on Monday.=20 Best regards, Ray van Brandenburg -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: dinsdag 25 oktober 2011 13:03 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision I see.=20 One more suggestion is you'd better make it clear in the document how you c= alculate 64bits presentation timestamp from 32bits presentation timestamp = in the XRBlock. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Tuesday, October 25, 2011 6:45 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, The reason for having an XR block for SC->MSAS communication and an RTCP Pa= cket Type for MSAS->SC is the result of a discussion on the list between Co= lin Perkins, Magnus Westerlund and myself on when to use XR blocks and when= to use RTCP packet types. If I remember correctly, XR blocks should be use= d for the transportation of metrics regarding media transmission and media = reception quality. Since the SC reports on the network delay between Media = Sender and client this should therefore be an XR block. Since the MSAS->SC = communication is more control information than measurement information, it = was deemed that an RTCP packet type would be more appropriate. If you want = to look up the exact arguments that were used in the discussion, you might = want to search the list for it. If I remember correctly, this discussion to= ok place somewhere around the March '11 meeting.=20 Best regards, Ray -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: dinsdag 25 oktober 2011 11:54 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Yes, the format looks good to me. However is it better to define RTCP IDMS = packet type in two direction (i.e., both MSAS->SC communication and SC->MS= AS communication)? In this case, timely feedback can be guaranteed in two directions. and you= still can use XRBLock in the upstream direction to maintain ETSI compatib= ility. That's my 2cents. Regards! -Qin ----- Original Message -----=20 From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Monday, October 24, 2011 11:28 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi, In order to solve both the ETSI compatibility issue as well as the need for= high precision 64bit timestamps, Kevin and I have come up with the followi= ng solution: The current draft describes both an IDMS XR block (for SC->MSAS communicati= on) as well as an RTCP IDMS Packet Type (for MSAS->SC communication). I wou= ld like to propose that we change the length of the Presentation Timestamp = in the IDMS Packet Type to 64bit, while keeping the length of the Presentat= ion Timestamp in the IDMS XR block to 32bits. This way the MSAS is able to = send very precise control commands to the synchronization clients while the= SC->MSAS measurements can remain compatible with ETSI. Since the MSAS will= add additional safety to the measured packet presentation times anyway (e.= g. to allow for jitter), it is not necessary to have 64bit precision measur= ements available on the MSAS.=20 Do you agree with this solution? Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Brand= enburg, R. (Ray) van Sent: vrijdag 21 oktober 2011 11:45 To: Qin Wu; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Ok. I will work together with Kevin to create a new version of the draft. In the meantime we have to try to come to consensus on the Initial Playout = Sync proposal of Fernando Boronat so that we can post a new ID before the n= ext meeting deadline.=20 If I understand correctly, the main question here is the matter in which th= e delay between Media Sender en SC is determined.=20 Ray -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: vrijdag 21 oktober 2011 11:37 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi, ----- Original Message -----=20 From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Friday, October 21, 2011 5:19 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Thanks for comments.=20 > Is it important to save packet size in 32bits at the cost of the accuracy= . > It will be good to see the presentation times follow the format of 64bits= NTP timestamp defined in RFC3550 for SR/RR report unless you have a more s= trong justification for it rather than say thi is not ETSI TISPAN standard = compliant. These statements seem to be contradictory. Do you mean you want to see the = presentation field extended to 64bits, or do you want to keep it at 32bits = to save packet length? [Qin]: I prefer to the former. -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: vrijdag 21 oktober 2011 10:33 To: Brandenburg, R. (Ray) van; Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Is it important to save packet size in 32bits at the cost of the accuracy. It will be good to see the presentation times follow the format of 64bits N= TP timestamp defined in RFC3550 for SR/RR report unless you have a more str= ong justification for it rather than say thi is not ETSI TISPAN standard co= mpliant. But I am not judge, this is just my personal opinion. Regards! -Qin ----- Original Message ----- From: "Brandenburg, R. (Ray) van" To: "Qin Wu" ; "Kevin Gross" ;= "IETF AVTCore WG" Sent: Friday, October 21, 2011 3:13 PM Subject: RE: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Hi Qin, Yes. However, the current IDMS draft uses a 64bit NTP timestamp to report o= n Packet Receipt Times and a 32bit NTP timestamp to report on Packet Presen= tation Times (plus a 32bit timestamp for the RTP timestamp). The reason we = initially went with only a 32bit NTP timestamp for Packet Presentation time= s was that we figured that the 16 most significant bits of the NTP time (e.= g. the date) would be the same for packet presentation and packet reception= times and that the least significant 16bits (for sub 15 microsecond accura= cy) would not be necessary. We therefore went with the middle 32 bits to li= mit the length of the IDMS packet.=20 What Kevin now suggests, is that in some use cases sub-15 microsecond accur= acy is necessary. He therefore proposes to increase the Packet Presentation= timestamp to 64bits. The only disadvantage with this approach (apart from = a slightly larger packet) is that this would break compatibility with the E= TSI TISPAN standard. Which way do you think we should go here? Best Regards, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin W= u Sent: vrijdag 21 oktober 2011 4:48 To: Kevin Gross; IETF AVTCore WG Subject: Re: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Isn't 64 bits NTP timestamp and 32bits RTP timestamp compliant with ones de= fined in RFC3550? Regards! -Qin ----- Original Message ----- From: "Kevin Gross" To: "IETF AVTCore WG" Sent: Thursday, October 20, 2011 10:59 AM Subject: [AVTCORE] draft-ietf-avtcore-idms-01 timestamp precision Part of my reason for bringing these use cases to the attention of the group relates to a yet unresolved comment I made against the IDMS draft. The draft proposes 64-bit timestamps for arrival times but only 32-bit timestamps for presentation times. A 32-bit NTP timestamp has a 15 microsecond precision. Presentation time synchronization with these timestamps would seem not to clearly meet the requirements of a couple of these use cases. Improving the protocol to support 64-bit timestamps throughout seems to be the straightforward solution. With this change, all timestamps would have the same precision and would have a precision comparable to their reference clocks. The problem with this is that our IDMS work is based on ETSI TISPAN standard TS 183 063. Efforts have been made in the draft to maintain compatibility with this standard. Changing the packet format to accommodate 64-bit timestamps will unravel those efforts. If ETSI compatibility is important, we will have to live with 15 microsecond precision and possibly suggest clever tricks to make the most of it. Which way do we want to go here? On Tue, Aug 16, 2011 at 11:12 AM, Kevin Gross wro= te: > The requirement for the stereo case is specified differently than the > others. The 10 microsecond figure there applies to _changes in latency_, = not > static difference in latency described in all the other cases. Tolerance = for > static differences for the stereo case are probably on the order of 1 > millisecond. The first-order effect of static latency differences is to m= ove > one of the speakers - just depends on how fussy you are about real vs. > effective speaker placement. > > > > The 10 microsecond figure is conservative (I've heard anecdotal claims of= 1 > microseconds sensitivity) and derives from our ability to accurately loca= te > sounds based (in part) on comparison of arrival times at each ear. The 10 > microsecond figure is not difficult to derive/check. It is also not > difficult to set up a listening test to see what your own threshold is. > Here's a quick reference on it - http://www.cs.ucc.ie/~ianp/CS2511/HAP.ht= ml > (see Localisation of Sound Sources section) > > > > Throughout, I've tried to use what I consider reasonable and verifiable > requirements figures. Some will always seem to argue that they need bette= r > performance. > > > > Kevin > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Tuesday, August 16, 2011 9:07 AM > To: IETF AVTCore WG > Subject: Re: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > Mr. Gross, > > The timing assertion for Networked stereo loudspeakers is much tighter th= at > I would have expected. Placement of stereo speakers within a foot is a > normal rule of thumb for the casual listener - and that is about 1.1ms > delta at room temperature. The ' golden ears' do have ability to detect > small differences especially with high attack waveforms, but I would like= to > see the study that showed this small time difference. Can you please prov= ide > a cite? > > And I wonder if the system requirement should be based on the smallest kn= own > delta, unless there is no implementation complexity added to convey the > suggested resolution. > > > > > > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone 202 429 5418 > Fax 202 775 4981 > www.nab.org > Advocacy Education Innovation > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kev= in > Gross > Sent: Monday, August 15, 2011 11:48 PM > To: 'IETF AVTCore WG' > Subject: [AVTCORE] Additional use cases > fordraft-brandenburg-avt-rtcp-for-idms > > > > In reviewing the IDMS draft I had volunteered to contribute additional us= e > cases. Ray Brandenberg suggested that I post them here. > > > > Kevin Gross > > AVA Networks > > Networked stereo loudspeakers > > Because of our ability to localize sound based on inter-aural time > differences, in a stereo listening situation, we are very sensitive to > changes in latency between the two speakers. These changes are perceived = as > a shift in or instability of the "sound stage" during critical listening. > These effects are readily noticeable with shifts of 10 microseconds or > smaller. If the individual speakers in a stereo listening setup operate f= rom > independent network interfaces any changing difference in latency between > the two speakers greater than 10 microseconds will be detrimental to the > listening experience. > > Conferencing sound reinforcement system > > A conferencing sound reinforcement system is used in commercial and > government installations such as legislative chambers, courtrooms, > boardrooms, classrooms (especially those supporting distance learning) an= d > other such venues. Each participant using such a system has a microphone = and > a speaker. There may also be other speakers to provide reinforcement for > non-speaking participants such as in an audience area or jury box. Each > microphone/speaker pair is individually connected to a network and transm= its > digital audio to the other devices through the network and receives digit= al > audio to be reproduced through the speaker over the network. There may be= a > central appliance which receives, prioritizes and mixes the microphone > signals. In some systems an individual mix is created for each speaker su= ch > that a speaker's own voice does not come out from his speaker or from tho= se > immediately surrounding him. > > The objective of these systems is to provide enough gain to enhance > intelligibility but not so much that the speaker sounds or feels amplifie= d. > Meeting this objective helps insure that natural person-to-person > communication is retained. To this end, it is desirable that the sound > through the system and from the speakers arrive 5 to 30 milliseconds afte= r > the the sound arriving through the air from the person speaking. Delays i= n > this range invoke the Haas effect which allows listeners to locate the > person speaking based on the sound arriving through the air while the sou= nd > reinforcement system provides the additional gain required to achieve > desired intelligibility. It is also desirable for the sound to come out o= f > nearby speakers at within 5 milliseconds as longer differential delays wi= ll > be perceived as reverberation or echo. > > Video wall > > A video wall consists of multiple computer monitors, video projectors, or > television sets tiled together contiguously or overlapped in order to for= m > one large screen.# Each of the screens reproduces a portion of the larger > picture. In some implementations, each screen may be individually connect= ed > to the network and receive its portion of the overall image from a > network-connected video server or video scaler. Screens are refreshed at = 60 > hertz (every 16-2/3 milliseconds) or potentially faster. If the refresh i= s > not synchronized, the effect of multiple screens acting as one is broken. > > Phased array transducers > > Phased array and wave field synthesis techniques are increasingly used in > audio applications. These techniques work by sending or receiving slightl= y > different versions of a signal in a spacial sampling arrangement to produ= ce > or record spacial and directional sound fields. The individual transducer= s > in these applications can be extremely sensitive to differential latency. > Example applications include conferencing microphone systems able to > electronically aim at the person speaking to improve signal to noise rati= o. > These microphones are also able to report the location of the speaker for > purposes of automatically aiming a video camera at them. > > Concert sound systems called line arrays allow technicians control over t= he > amount of sound sent to different places. People in the front of the > audience can have the same loudness as those in the back. By preventing > sound from reaching the roof and back wall of the performance space, the > amount of reflected sound heard by the audience is reduced and the listen= ing > experience is improved. > > In these systems, accuracy in locating or emitting sound is related to > differential latency through basic trigonometry. In these applications, > microseconds of differential latency can translate to degrees of > uncertainty. Accuracy greater than the audio sample period (about 20 > microseconds for professional 48 kHz sample rate) is generally desired. > > _______________________________________________ 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From bo.burman@ericsson.com Fri Oct 28 08:45:25 2011 Return-Path: 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 A1E7821F8531 for ; Fri, 28 Oct 2011 08:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 IPmwZHc4tf2C for ; Fri, 28 Oct 2011 08:45:25 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B35A721F8AC9 for ; Fri, 28 Oct 2011 08:45:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-6b-4eaace130dff Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E0.DB.13753.31ECAAE4; Fri, 28 Oct 2011 17:45:23 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.7]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 28 Oct 2011 17:45:23 +0200 From: Bo Burman To: Harald Alvestrand Date: Fri, 28 Oct 2011 17:45:22 +0200 Thread-Topic: [AVTCORE] Max SSRC declaration: Objection to retrofitting rules Thread-Index: AcyUA2KS3l58FFC5TCWE6iMV2qRMfABgi6lg Message-ID: <05F760EF51FA6A4F804F9759C239313A29ABC9B09E@ESESSCMS0361.eemea.ericsson.se> References: <4EA8410A.7070801@alvestrand.no> In-Reply-To: <4EA8410A.7070801@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Max SSRC declaration: Objection to retrofitting rules X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 15:45:25 -0000 Hello Harald, I think your objection as well as your proposed replacement text are both v= ery reasonable, and we will update the document accordingly. Do you think that the proposed "local heuristics" approach will be a genera= lly acceptable method to apply when the proposed attributes are not present= ? I am aware that it is most likely what will have to be done, but is it ac= ceptable to refer to it in an Internet Draft, or need it somehow be more el= aborate? Best Regards /Bo B -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Haral= d Alvestrand Sent: den 26 oktober 2011 19:19 To: avt@ietf.org Subject: [AVTCORE] Max SSRC declaration: Objection to retrofitting rules Hello, I have read through draft-westerlund-avtcore-max-ssrc, and generally I find= it a fine specification, which allows us to be explicit about an aspect of= RTP usage that was not previously explicit. However, I do have one strong objection to two specific paragraph: When max-send-ssrc or max-recv-ssrc are not included in the SDP, it MUST be interpreted as equivalent to a limit of one, unless sendonly or recvonly attributes are specified, in which case the limit is implicitly zero for the corresponding unused direction. ..... In case an answer fails to include any of the limitation attributes, the agent SHOULD be interpreted as capable of supporting only a single stream in the direction for which attributes are missing. If I read this correctly: - There is no way to tell from SDP whether or not the sender or recipient= intends to conform to the max-ssrc draft: The extension itself is not signalled. - Therefore, it seems that the intent of the paragraph is to change the r= ules about how to interpret SDP messages that do NOT contain any hint that their sender is conformi= ng to max-ssrc - Therefore, the draft, if taken literally as written, would retroactivel= y declare all usage of multiple SSRCs in a single RTP session to be noncompliant with its S= DP declaration. That seems to me to be an entirely unreasonable thing to do, given that imp= lementations are using multiple SSRCs on single RTP sessions every minute o= f every day. I would not object to a section that instead said: When max-send-ssrc or max-recv-ssrc are not included in the SDP, no information about the supported number of SSRCs is available, unless se= ndonly or recvonly attributes are specified, in which case the limit is implicitly zero for the corresponding unused direction. If a specific deployment is protected by gateways that modify SDP, and = have knowledge of a specific limit active within that deployment, those gatew= ays MAY choose to add max-*-ssrc attributes to the SDP exchanged with the outside world, to indicate the limited capacity of those devices. ..... In case an answer fails to include any of the limitation attributes, local heuristics SHOULD be applied to produce a reasonable guess at the capacity of the responding agent. Declaring a class of deployments non-conformant by IETF fiat is not, in my = opinion, a reasonable option. Encouraging the deployers of limited-function devices to be explicit about = those limitations is a reasonable option. Harald _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From harald@alvestrand.no Fri Oct 28 10:25:47 2011 Return-Path: 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 2411F21F854F for ; Fri, 28 Oct 2011 10:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.345 X-Spam-Level: X-Spam-Status: No, score=-110.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ufKyUxrdhI8c for ; Fri, 28 Oct 2011 10:25:46 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 874E421F8514 for ; Fri, 28 Oct 2011 10:25:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8EA3B39E165; Fri, 28 Oct 2011 19:25:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ewDO6xBRn0w; Fri, 28 Oct 2011 19:25:44 +0200 (CEST) Received: from [172.19.29.10] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id DEA2639E048; Fri, 28 Oct 2011 19:25:43 +0200 (CEST) Message-ID: <4EAAE596.5000805@alvestrand.no> Date: Fri, 28 Oct 2011 10:25:42 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Bo Burman References: <4EA8410A.7070801@alvestrand.no> <05F760EF51FA6A4F804F9759C239313A29ABC9B09E@ESESSCMS0361.eemea.ericsson.se> In-Reply-To: <05F760EF51FA6A4F804F9759C239313A29ABC9B09E@ESESSCMS0361.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Max SSRC declaration: Objection to retrofitting rules X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:25:47 -0000 On 10/28/2011 08:45 AM, Bo Burman wrote: > Hello Harald, > > I think your objection as well as your proposed replacement text are both very reasonable, and we will update the document accordingly. Thanks! > Do you think that the proposed "local heuristics" approach will be a generally acceptable method to apply when the proposed attributes are not present? I am aware that it is most likely what will have to be done, but is it acceptable to refer to it in an Internet Draft, or need it somehow be more elaborate? My personal opinion is that the more our internet-drafts reflect reality, the better off we are.... It is not an area in which I am expert, but I would think that people who do SBCs for a living are the best people to turn to for advice on how to describe what needs to be done here - and whether it is at all helpful to have these local heuristics described in an I-D. Harald From internet-drafts@ietf.org Fri Oct 28 16:41:50 2011 Return-Path: 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 1348911E808B; Fri, 28 Oct 2011 16:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 bVjrx-jKRZU9; Fri, 28 Oct 2011 16:41:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC6A1F0C3D; Fri, 28 Oct 2011 16:41:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111028234149.16551.50443.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2011 16:41:49 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-encrypted-header-ext-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 23:41:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Encryption of Header Extensions in the Secure Real-Time = Transport Protocol (SRTP) Author(s) : Jonathan Lennox Filename : draft-ietf-avtcore-srtp-encrypted-header-ext-01.txt Pages : 13 Date : 2011-10-28 The Secure Real-Time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-Time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-encrypted-heade= r-ext-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-encrypted-header= -ext-01.txt From jonathan@vidyo.com Fri Oct 28 16:48:40 2011 Return-Path: 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 87BD321F8488 for ; Fri, 28 Oct 2011 16:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] 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 dqoKKHvv0p9f for ; Fri, 28 Oct 2011 16:48:40 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 04A6E21F8486 for ; Fri, 28 Oct 2011 16:48:40 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2F4B255488B for ; Fri, 28 Oct 2011 19:48:39 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C61CF55484E for ; Fri, 28 Oct 2011 19:48:38 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Fri, 28 Oct 2011 19:48:22 -0400 From: Jonathan Lennox To: IETF AVTCore WG Date: Fri, 28 Oct 2011 19:48:37 -0400 Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-encrypted-header-ext-01.txt Thread-Index: AcyVzBJqDnwRY5PwRTyXMtQj66FwTg== Message-ID: References: <20111028234149.16551.50443.idtracker@ietfa.amsl.com> In-Reply-To: <20111028234149.16551.50443.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-encrypted-header-ext-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 23:48:40 -0000 I've just posted a new version of the header extension encryption draft. I= believe this version resolves all open issues and comments from the mailin= g list and from the last IETF, including a resolution of the AEAD issue tha= t David McGrew and I worked out in Montr=E9al. (For a full list of changes= , see the "Changes" appendix in the draft.) This version adds test vectors for the header extension encryption process;= it'd be great if someone could independently double-check these for me. Other than that, this is, as far as I know, ready for WGLC. Note also that= this is a dependency of the audio-levels drafts in AVTExt. On Oct 28, 2011, at 7:41 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Audio/Video Transport Core Maintena= nce Working Group of the IETF. >=20 > Title : Encryption of Header Extensions in the Secure Real-Tim= e Transport Protocol (SRTP) > Author(s) : Jonathan Lennox > Filename : draft-ietf-avtcore-srtp-encrypted-header-ext-01.txt > Pages : 13 > Date : 2011-10-28 >=20 > The Secure Real-Time Transport Protocol (SRTP) provides > authentication, but not encryption, of the headers of Real-Time > Transport Protocol (RTP) packets. However, RTP header extensions may > carry sensitive information for which participants in multimedia > sessions want confidentiality. This document provides a mechanism, > extending the mechanisms of SRTP, to selectively encrypt RTP header > extensions in SRTP. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-encrypted-hea= der-ext-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-encrypted-head= er-ext-01.txt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 -- Jonathan Lennox jonathan@vidyo.com From internet-drafts@ietf.org Mon Oct 31 03:37:52 2011 Return-Path: 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 EB4F121F8D87; Mon, 31 Oct 2011 03:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 F+BRCnRMDta1; Mon, 31 Oct 2011 03:37:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E1F21F8D6C; Mon, 31 Oct 2011 03:37:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031103752.17672.85845.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 03:37:52 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 10:37:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Why RTP Does Not Mandate a Single Security Mechanism Author(s) : Colin Perkins Magnus Westerlund Filename : draft-ietf-avt-srtp-not-mandatory-08.txt Pages : 11 Date : 2011-10-31 This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP), and the associated RTP control protocol (RTCP), do not mandate a single media security mechanism. It also discusses how applications using RTP can meet the goals of BCP 61 to have strong and mandatory to implement security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-not-mandatory-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-srtp-not-mandatory-08.txt From magnus.westerlund@ericsson.com Mon Oct 31 06:27:56 2011 Return-Path: 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 E81FE21F8C50 for ; Mon, 31 Oct 2011 06:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 I+zZku1XQuRx for ; Mon, 31 Oct 2011 06:27:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EF13021F8C68 for ; Mon, 31 Oct 2011 06:27:55 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-2b-4eaea25a0818 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 15.EF.20773.A52AEAE4; Mon, 31 Oct 2011 14:27:55 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 31 Oct 2011 14:27:54 +0100 Message-ID: <4EAEA257.8060007@ericsson.com> Date: Mon, 31 Oct 2011 14:27:51 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <20111031103752.17672.85845.idtracker@ietfa.amsl.com> In-Reply-To: <20111031103752.17672.85845.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:27:57 -0000 WG, I have with the help of Colin, finally gotten around to update this document. This is an attempt to resolve the IESG comments we have received on this document. We have not yet gotten thumbs up from the IESG on the proposed changes, we will request that feedback. I would recommend the WG participants to review the changes. The two major points are: 1) IETF should consider defining RTP security profiles more 2) Strong recommendations on any user of RTP to define a Mandatory to Implement security solution for their application. http://tools.ietf.org/rfcdiff?url2=draft-ietf-avt-srtp-not-mandatory-08 Cheers Magnus On 2011-10-31 11:37, 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 : Why RTP Does Not Mandate a Single Security Mechanism > Author(s) : Colin Perkins > Magnus Westerlund > Filename : draft-ietf-avt-srtp-not-mandatory-08.txt > Pages : 11 > Date : 2011-10-31 > > This memo discusses the problem of securing real-time multimedia > sessions, and explains why the Real-time Transport Protocol (RTP), > and the associated RTP control protocol (RTCP), do not mandate a > single media security mechanism. It also discusses how applications > using RTP can meet the goals of BCP 61 to have strong and mandatory > to implement security. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-not-mandatory-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-srtp-not-mandatory-08.txt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Mon Oct 31 09:13:55 2011 Return-Path: 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 557EF21F8D7B; Mon, 31 Oct 2011 09:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.581 X-Spam-Level: X-Spam-Status: No, score=-98.581 tagged_above=-999 required=5 tests=[AWL=-3.958, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, USER_IN_WHITELIST=-100] 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 oMKhe75MTLVe; Mon, 31 Oct 2011 09:13:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E310E21F8DAA; Mon, 31 Oct 2011 09:13:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031161354.23849.15132.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 09:13:54 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:13:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : RTCP for inter-destination media synchronization Author(s) : Ray van Brandenburg Hans M. Stokking M. Oskar van Deventer Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-02.txt Pages : 24 Date : 2011-10-31 This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for inter-destination media synchronization (IDMS). The RTCP XR Block Type, registered with IANA based on an ETSI specification, is used to collect media play- out information from participants in a group playing-out (watching, listening, etc.) a specific RTP media stream. The RTCP packet type specified by this document is used to distribute a summary of the collected information so that the participants can synchronize play- out. Typical applications for IDMS are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked speakers, etc. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-idms-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-idms-02.txt From Internet-Drafts@ietf.org Mon Oct 31 11:45:02 2011 Return-Path: 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 2103111E8153; Mon, 31 Oct 2011 11:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 hsNy1BHhPN0K; Mon, 31 Oct 2011 11:45:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE5C11E8090; Mon, 31 Oct 2011 11:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031184501.1294.957.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 11:45:01 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D ACTION:draft-ietf-avt-srtp-aes-gcm-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:45:02 -0000 --NextPart 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 : AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) Author(s) : D. McGrew, et al Filename : draft-ietf-avt-srtp-aes-gcm-02.txt Pages : 19 Date : 2011-10-31 This document defines how AES-GCM, AES-CCM, and other Authenticated Encryption with Associated Data (AEAD) algorithms, can be used to provide confidentiality and data authentication mechanisms in the SRTP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-aes-gcm-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-srtp-aes-gcm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-10-31113729.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Mon Oct 31 14:41:04 2011 Return-Path: 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 7D22811E82B9; Mon, 31 Oct 2011 14:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ftP-qildGzbs; Mon, 31 Oct 2011 14:41:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0994411E82B3; Mon, 31 Oct 2011 14:41:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031214102.6537.14692.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 14:41:02 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:41:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Explicit Congestion Notification (ECN) for RTP over UDP Author(s) : Magnus Westerlund Ingemar Johansson Colin Perkins Piers O'Hanlon Ken Carlberg Filename : draft-ietf-avtcore-ecn-for-rtp-05.txt Pages : 56 Date : 2011-10-31 This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialization methods are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-05.txt From internet-drafts@ietf.org Mon Oct 31 16:48:02 2011 Return-Path: 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 151B71F0D92; Mon, 31 Oct 2011 16:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 tVOI0733AxAt; Mon, 31 Oct 2011 16:48:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12501F0D70; Mon, 31 Oct 2011 16:48:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031234801.8045.67057.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 16:48:01 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avt-srtp-ekt-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:48:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Encrypted Key Transport for Secure RTP Author(s) : David A. McGrew Dan Wing Kai Fischer Filename : draft-ietf-avt-srtp-ekt-03.txt Pages : 53 Date : 2011-10-31 SRTP Encrypted Key Transport (EKT) is an extension to SRTP that provides for the secure transport of SRTP master keys, Rollover Counters, and other information, within SRTP or SRTCP. This facility enables SRTP to work for decentralized conferences with minimal control, and to handle situations caused by early media. This note defines EKT, and also describes how to use it with SDP Security Descriptions, DTLS-SRTP, and MIKEY. These other key management protocols provide an EKT key to everyone in a session, and EKT coordinates the keys within the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-ekt-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-srtp-ekt-03.txt