From rjsparks@nostrum.com Mon Jan 9 09:00:42 2012 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 A6E0821F86C6 for ; Mon, 9 Jan 2012 09:00:42 -0800 (PST) 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=[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 eUdPEIV+XeDd for ; Mon, 9 Jan 2012 09:00:38 -0800 (PST) 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 3D0E221F86A0 for ; Mon, 9 Jan 2012 09:00:36 -0800 (PST) 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 q09H0ZY2067439 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 9 Jan 2012 11:00:35 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F0B1D32.8070203@nostrum.com> Date: Mon, 09 Jan 2012 11:00:34 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: avt@ietf.org References: <20111230230924.32622.2169.idtracker@ietfa.amsl.com> <7A588527-C897-4491-8FB3-F3C6C122B40B@csperkins.org> In-Reply-To: <7A588527-C897-4491-8FB3-F3C6C122B40B@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-vbr-audio-04.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, 09 Jan 2012 17:00:42 -0000 AVTCORE participants: I'll be issuing a 2nd IETF LC for this soon calling out that the recommendations have been strengthened and that the intended status is changed to Proposed Standard. Please verify that you are ok with these changes as part of that LC. RjS On 12/30/11 5:16 PM, Colin Perkins wrote: > On 30 Dec 2011, at 23:09, 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 : Guidelines for the use of Variable Bit Rate Audio with Secure RTP >> Author(s) : Colin Perkins >> Jean-Marc Valin >> Filename : draft-ietf-avtcore-srtp-vbr-audio-04.txt >> Pages : 7 >> Date : 2011-12-30 >> >> 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. > > This version strengthens the recommendations in the light of review by the security area, and discussion in SAAG at IETF 82. This was heavily influenced by http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf > > In the light of the changes, a new WG last call is likely required. > > Colin > > From iesg-secretary@ietf.org Mon Jan 9 09:17:36 2012 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 E94D711E80C5; Mon, 9 Jan 2012 09:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.185 X-Spam-Level: X-Spam-Status: No, score=-102.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 y6kjrFhvow-N; Mon, 9 Jan 2012 09:17:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8111E809B; Mon, 9 Jan 2012 09:17:36 -0800 (PST) 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.64p1 Message-ID: <20120109171736.13851.20033.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2012 09:17:36 -0800 Cc: avt@ietf.org Subject: [AVTCORE] 2nd Last Call: (Guidelines for the use of Variable Bit Rate Audio with Secure RTP) to Proposed Standard 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, 09 Jan 2012 17:17:37 -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 Proposed Standard This is a second IETF Last Call to verify the strengthening of recommendations as a result of security area review during IESG evaluation, and a change of intended status from BCP to Proposed Standard. 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 2012-01-23. 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 jsaldana@unizar.es Tue Jan 10 03:34:19 2012 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 6382721F8622 for ; Tue, 10 Jan 2012 03:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.184 X-Spam-Level: X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 EAHfTlMBg5wx for ; Tue, 10 Jan 2012 03:34:15 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id B344821F861F for ; Tue, 10 Jan 2012 03:34:14 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q0ABY6oI019594 for ; Tue, 10 Jan 2012 12:34:10 +0100 From: To: Date: Tue, 10 Jan 2012 12:34:09 +0100 Organization: Universidad de Zaragoza Message-ID: <002c01cccf8b$c739f5d0$55ade170$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01CCCF94.28FE5DD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczPi3w8BVdEEVnbTE+4GDTYYqR88g== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: [AVTCORE] Proposal for updating TCRTP (RFC 4170) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 11:34:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002D_01CCCF94.28FE5DD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all. My name is Jose Saldana, from the University of Zaragoza, in Spain. I am = new here. I would like to share with AVTCORE Work Group a proposal, in case it = could be considered interesting. The main idea is to update TCRTP. This is a = "Best current practice" RFC (http://datatracker.ietf.org/doc/rfc4170/) which = was developed in Audio/Video Transport working group in 2005-11. It = "describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method = combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path." (from the introduction = of RFC4170). The scheme of TCRTP is: RTP/UDP/IP | | ECRTP (compressing layer). Compresses RTP/UDP/IP headers | | =20 PPPMux (multiplexing layer). Includes a number of compressed packets into a bigger one | | L2TP (tunneling layer). Permits its use end-to-end | | IP However, there exist many real-time flows that do not use RTP: - Online "First Person Shooter" (FPS) games use UDP datagrams, and they = are one of the most "real-time" applications nowadays. Some examples: = Counter Strike, Halo, Quake, etc.[1]. - Online "Massively Multiplayer Online Role Playing Games" (MMORPG): = They use TCP, but can be considered "real-time", since the actions of the = players have to be transmitted very quickly to the server. It should be taken = into account that player vs player fights are one of the possible activities = of the game. Some examples: World of Warcraft (more than 10 million subscribers) [2]. - TCP is also getting used for media delivery. For many reasons, such as avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is = substituted in many cases by IP/ TCP/ HTTP/ FLV [3]. - Another interesting scenario is satellite communication links. Multiplexing small packets into one packet for transmission would = improve the efficiency. Satellite links would also find it useful to multiplex = small TCP packets into one packet =96 this could be especially interesting for compressing TCP ACKs. In our recent research activities, we have adapted TCRTP scheme for its = use when the traffic is not RTP. The idea is to substitute ECRTP by other compression scheme which can be used for UDP or TCP headers. In 2006, = the IETF formed the Robust Header Compression (ROHC) working group which = created specifications for header compression over links for RTP, UDP and TCP. These specifications were extended to compress headers over other = networks. For most RTP flows, ROHC is more bandwidth efficient than ECRTP, at the = cost of implementation complexity. It has a special care of context synchronization, defining some states at the compressor and = decompressor. Once the effort for designing ROHC has been conducted, it is worth = including it in the compressing and multiplexing standard. In a recent paper in Nov. issue of IEEE Communications Magazine, it was shown that 30% of bandwidth saving can be achieved for 8 FPS different = games using IPv4. If IPv6 is used, savings can be up to 54% [4]. Another = recent study, which is still under review, has estimated 45% bandwidth saving = for World of Warcraft. After talking to other researchers, including some of the authors of RFC4170, the possible scheme of the proposal could be this one: G.711.0 payload compression TCP UDP UDP/RTP | | | | | \ | / | \ | / | nothing or ROHC or ECRTP | | \ / \ / multiplexing layer (other or PPPMUX) | | tunneling layer (other or GRE or L2TP) | | IP It should be more "open" than TCRTP. I mean, it could be "orthogonal" to different protocols: different header compression algorithms could be = used, depending on the application and the scenario; also different = multiplexing and tunneling protocols could be included. Finally, we have also = included the G.711.0 "branch": it could be interesting to convert G.711 to = G.711.0 (a lossless encoding of G.711) and back, using a similar tunneling = mechanism. In a similar way to TCRTP, the G.711 to G.711.0 and vice versa = conversion does not involve SIP/SDP/RTSP signaling with the endpoints, since G.711 = has a fixed RTP payload number. We have not written a draft. This is only the first idea, so we look = forward to hearing the opinion of the Working Group, Thank you very much, and sorry for writing such a long message, Jose Saldana University of Zaragoza ______________ [1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of First-Person Shooter Gaming Traffic on the Internet," Internet Computing, IEEE , = vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5445069&isnum= ber=3D556 2482 [2] P. Svoboda, W Karner and M. Rupp, =93Traffic Analysis and Modeling = for World of Warcraft,=94 ICC '07. IEEE International Conference on Communications, pp.1612-1617, 24-28, Jun. 2007. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D4288941&isnum= ber=3D428 8671 [3] G. Marfia and M. Roccetti, =93TCP At Last: Reconsidering TCP=92s = Role for Wireless Entertainment Centers at Home,=94 IEEE Transactions on Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5681095&isnum= ber=3D568 1060 [4] J. Saldana, J. Fern=E1ndez-Navajas, J. Ruiz-Mas, J. I. Aznar, E. = Viruete and L. Casadesus, =93First Person Shooters: Can a Smarter Network Save Bandwidth without Annoying the Players?,=94 IEEE Communications = Magazine, Consumer Communications and Networking Series, vol. 49, no. 11, pp. = 190-198, Nov. 2011. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D6069728&isnum= ber=3D606 9696 ------=_NextPart_000_002D_01CCCF94.28FE5DD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Proposal for updating TCRTP (RFC 4170)

Hello all.

My name is Jose = Saldana, from the University of Zaragoza, in Spain. I am new = here.

I would like to = share with AVTCORE Work Group a proposal, in case it could be considered = interesting. The main idea is to update TCRTP. This is a "Best = current practice" RFC (http://datatracker.ietf= .org/doc/rfc4170/) which was developed in Audio/Video Transport = working group in 2005-11. It "describes a method to improve the = bandwidth utilization of RTP streams over network paths that carry = multiple Real-time Transport Protocol (RTP) streams in parallel between = two endpoints, as in voice trunking. The method combines standard = protocols that provide compression, multiplexing, and tunneling over a = network path for the purpose of reducing the bandwidth used when = multiple RTP streams are carried over that path." (from the = introduction of RFC4170).


The scheme of = TCRTP is:

  = RTP/UDP/IP

     |

     |

   ECRTP (compressing layer). Compresses RTP/UDP/IP = headers

     |

     = |            =        

    PPPMux (multiplexing layer). Includes a number = of compressed packets into a bigger one

     |

     |

   L2TP     (tunneling layer). = Permits its use end-to-end

     |

     |

     IP

However, there = exist many real-time flows that do not use RTP:

- Online = "First Person Shooter" (FPS) games use UDP datagrams, and they = are one of the most "real-time" applications nowadays. Some = examples: Counter Strike, Halo, Quake, etc.[1].

- Online = "Massively Multiplayer Online Role Playing Games" (MMORPG): = They use TCP, but can be considered "real-time", since the = actions of the players have to be transmitted very quickly to the = server. It should be taken into account that player vs player fights are = one of the possible activities of the game. Some examples: World of = Warcraft (more than 10 million subscribers) [2].

- TCP is also = getting used for media delivery. For many reasons, such as avoiding = firewalls, the standard IP/ UDP/ RTP protocol stack is substituted in = many cases by IP/ TCP/ HTTP/ FLV [3].

- Another = interesting scenario is satellite communication links. Multiplexing = small packets into one packet for transmission would improve the = efficiency. Satellite links would also find it useful to multiplex small = TCP packets into one packet – this could be especially interesting = for compressing TCP ACKs.


In our recent = research activities, we have adapted TCRTP scheme for its use when the = traffic is not RTP. The idea is to substitute ECRTP by other compression = scheme which can be used for UDP or TCP headers. In 2006, the IETF = formed the Robust Header Compression (ROHC) working group which created = specifications for header compression over links for RTP, UDP and = TCP.  These specifications were extended to compress headers over = other networks. For most RTP flows, ROHC is more bandwidth efficient = than ECRTP, at the cost of implementation complexity. It has a special = care of context synchronization, defining some states at the compressor = and decompressor. Once the effort for designing ROHC has been conducted, = it is worth including it in the compressing and multiplexing = standard.


In a recent = paper in Nov. issue of IEEE Communications Magazine, it was shown that = 30% of bandwidth saving can be achieved for 8 FPS different games using = IPv4. If IPv6 is used, savings can be up to 54% [4]. Another recent = study, which is still under review, has estimated 45% bandwidth saving = for World of Warcraft.


After talking = to other researchers, including some of the authors of RFC4170, the = possible scheme of the proposal could be this one:


G.711.0 payload = compression        = TCP     UDP   UDP/RTP

           &n= bsp;     = |            =         = |      |      = |

           &n= bsp;     = |            =          = \     |     /

           &n= bsp;     = |            =            = \   |   /

           &n= bsp;     = |            =    nothing or ROHC or ECRTP

           &n= bsp;     = |            =             &= nbsp;  |

           &n= bsp;      = \            =              = /

           &n= bsp;        = \            =          /

           &n= bsp;    multiplexing layer (other or = PPPMUX)

           &n= bsp;           &nb= sp;   |

           &n= bsp;           &nb= sp;   |

           &n= bsp;   tunneling layer (other or GRE or = L2TP)

           &n= bsp;           &nb= sp;   |

           &n= bsp;           &nb= sp;   |

           &n= bsp;           &nb= sp;  IP

It should be = more "open" than TCRTP. I mean, it could be = "orthogonal" to different protocols: different header = compression algorithms could be used, depending on the application and = the scenario; also different multiplexing and tunneling protocols could = be included. Finally, we have also included the G.711.0 = "branch": it could be interesting to convert G.711 to G.711.0 = (a lossless encoding of G.711) and back, using a similar tunneling = mechanism. In a similar way to TCRTP, the G.711 to G.711.0 and vice = versa conversion does not involve SIP/SDP/RTSP signaling with the = endpoints, since G.711 has a fixed RTP payload number.

We have not = written a draft. This is only the first idea, so we look forward to = hearing the opinion of the Working Group,


Thank you very = much, and sorry for writing such a long message,

Jose = Saldana

University of = Zaragoza

______________

[1] Ratti, S.; = Hariri, B.; Shirmohammadi, S., "A Survey of First-Person Shooter = Gaming Traffic on the Internet," Internet Computing, IEEE , vol.14, = no.5, pp.60-69, Sept.-Oct. 2010. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&a= rnumber=3D5445069&isnumber=3D5562482

[2] P. Svoboda, = W Karner and M. Rupp, “Traffic Analysis and Modeling for World of = Warcraft,” ICC '07. IEEE International Conference on = Communications, pp.1612-1617, 24-28, Jun. 2007. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&a= rnumber=3D4288941&isnumber=3D4288671

[3] G. Marfia = and M. Roccetti, “TCP At Last: Reconsidering TCP’s Role for = Wireless Entertainment Centers at Home,” IEEE Transactions on = Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&a= rnumber=3D5681095&isnumber=3D5681060

[4] J. Saldana, = J. Fern=E1ndez-Navajas, J. Ruiz-Mas, J. I. Aznar, E. Viruete and  = L. Casadesus, “First Person Shooters: Can a Smarter Network Save = Bandwidth without Annoying the Players?,” IEEE Communications = Magazine, Consumer Communications and Networking Series, vol. 49, no. = 11, pp. 190-198, Nov. 2011. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&a= rnumber=3D6069728&isnumber=3D6069696

------=_NextPart_000_002D_01CCCF94.28FE5DD0-- From magnus.westerlund@ericsson.com Thu Jan 12 08:08:27 2012 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 DEF4621F85E9 for ; Thu, 12 Jan 2012 08:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.899 X-Spam-Level: X-Spam-Status: No, score=-104.899 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_82=0.6, MIME_BAD_LINEBREAK=0.5, 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 hN5WVQA48+gL for ; Thu, 12 Jan 2012 08:08:26 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BED7E21F85E6 for ; Thu, 12 Jan 2012 08:08:25 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-9e-4f0f0578668e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EA.16.23425.8750F0F4; Thu, 12 Jan 2012 17:08:24 +0100 (CET) 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; Thu, 12 Jan 2012 17:08:23 +0100 Message-ID: <4F0F0576.9090606@ericsson.com> Date: Thu, 12 Jan 2012 17:08:22 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: IETF AVTCore WG Content-Type: multipart/mixed; boundary="------------020502010106010704060502" X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Draft Minutes IETF 82 AVTCORE session 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, 12 Jan 2012 16:08:28 -0000 --------------020502010106010704060502 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Hi, Attached are draft minutes for the AVTCORE WG session. Sorry for them being very late, this is due to me being ill. In the end Roni made most of the work to prepare these minutes. Please review them. We will see if we can get them added to the proceedings after the WG have had some time to look at them. 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 ---------------------------------------------------------------------- --------------020502010106010704060502 Content-Type: text/plain; name="notes ietf82-avtcore-v2.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="notes ietf82-avtcore-v2.txt" QXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UgKEFWVENvcmUpIFdvcmtp bmcgR3JvdXAgTWludXRlcyBJRVRGIDgyDQogDQpDaGFpcnM6IE1hZ251cyBXZXN0ZXJsdW5k IA0KIFJvbmkgRXZlbg0KIA0KTm90ZSBUYWtlcnM6ICAgIEFsIE1vcnRvbg0KICAgICAgICAg ICAgICAgICAgICAgICAgDQogDQpBVlRDb3JlIFN0YXR1cyBVcGRhdGUNCiANClRoZXNlIGFy ZSB0aGUgbWludXRlcyBmb3IgdGhlIEFWVENvcmUgV0cuIFRoZSBXRyBoYXMgcHVibGlzaGVk IDIgUkZDcywgDQpDdXJyZW50bHksIHR3byBkb2N1bWVudCBhcmUgaW4gSUVTRyBwcm9jZXNz aW5nIChkcmFmdC1pZXRmLWF2dC1zcnRwLW5vbi0NCm1hbmRhdG9yeSwgZHJhZnQtaWV0Zi1h dnRjb3JlLXNydHAtdmItYXVkaW8pIENvbGluOiBUaGVyZSB3ZXJlIGEgYnVuY2ggb2YgDQpj b21tZW50cywgdGhpcyBpcyBnb2luZyB0byBiZSBkaXNjdXNzZWQgaW4gdGhlIHNlY3VyaXR5 IGFyZWEgbWVldGluZy4NClJvbmkgcHJlc2VudHMgdGhlIG1pbGVzdG9uZSByZXZpZXcgKG1p bGVzdG9uZXMgbmVlZCB0byBiZSB1cGRhdGVkKQ0KDQoNCg0KDQpFQ04gZm9yIFJUUCBvdmVy IFVEUCBwcmVzZW50ZWQgYnkgQ29sbGluIFBlcmtpbnMgDQooZHJhZnQtaWV0Zi1hdnRjb3Jl LWVjbi1mb3ItcnRwLTA1KQ0KDQpUaGVyZSB3YXMgYSBXR0xDIG9uIDA0IHZlcnNpb24uIE5l dyB2ZXJzaW9uIDA1IGhhcyBiZWVuIHN1Ym1pdHRlZCB0byBhZGRyZXNzIHRoZSANCmlzc3Vl cyBicm91Z2h0IHVwLiANCg0KVHdvIG9wZW4gaXNzdWVzIHJlbWFpbjoNCjEuIEVDTiBpbnRl cmFjdGlvbiB3aXRoIElDRQ0KQ29saW4gcHJlc2VudHMgdGhlIHByb2Nlc3MgdG8gY2hlY2sg Zm9yIEVDVCBjYXBhYmxlIHBhdGggdXNpbmcgSUNFLiBJbiBzb21lIA0KY2FzZXMgdGhlc2Ug c3RlcHMgY2FuIGFkZCBhZGRpdGlvbmFsIHNldHVwIHRpbWUsIHdoaWNoIGlzIHVuZGVzaXJh YmxlLiBIZSANCnByb3Bvc2VzIGEgbWV0aG9kIGluIHdoaWNoLCBvbmNlIHRoZSBjYWxsIGhh cyBiZWVuIGFuc3dlcmVkLCBtZWRpYSBzaG91bGQgYmUgDQpzZW50IHdpdGhvdXQgRUNOIG9u Y2UgdGhlIG5vcm1hbCBJQ0UgZXhjaGFuZ2UgaGFzIGJlZW4gY29tcGxldGVlZC4gDQpBbHRl cm5hdGl2ZWx5LCBvbmNlIFNUVU4gaGFzIHZlcmlmaWVkIHRoZW4gRUNOIGlzIGVuYWJsZWQu IEpvbmF0aGFuIExlbm5veDogSSANCmxpa2UgdGhpcyBhcHByb2FjaC4NCg0KMi4gU3VwcG9y dCBmb3IgTXVsdGljYXN0IC0gRUNOIHJlcXVpcmVkIGZvciBBTEwgcmVjZWl2ZXJzIG9yIG5v bmUgZmFsbGluZyBiYWNrIHRvIG5vbi1FQ04gZG9lcyBub3Qgc2NhbGUgZm9yIGxhcmdlIGdy b3VwcywgDQpCaWxsIFZlciBTdGVlZyByYXNpZWQgdGhlIGNvbmNlcm4gdGhhdCB0aGlzIGlz IGNvbnNlcnZhdGl2ZS4gV2l0aCBhIGxhcmdlIGdyb3VwLCANCnRoZSBjaGFuY2Ugb2Ygb25l IHJjZWl2ZXIgbm90IHN1cHBvcnRpbmcgRUNOIGlzIHF1aXRlIGxhcmdlLiBDb2xpbiBpcyBh d2FyZSBvZiANCnRoZSBwcm9ibGVtLCBzYXlzIHRoYXQgaXQgaXMgYSBmYXJpbmVzcyBpc3N1 ZS4gSGUgcHJvcG9zZXMgdG8gYWRkIGEgbm90ZSB0byB0aGUgDQpkcmFmdCBpZGVudGlmeWlu ZyB0aGlzIHByb2JsZW0gYW5kIHRoZSBmYWlybmVzcyBpc3N1ZS4gSGUgaW52aXRlcyBvdGhl cnMgdG8gDQpleHBlcmltZW50IHdpdGggRUNOIGZvciBsYXJnZSBncm91cHMuIEhlIGRvZXMg bm90IHdhbnQgdG8gaG9sZCB1cCB0aGUgZHJhZnQgZm9yIA0KanVzdCB0aGlzIGlzc3VlLiAN Cg0KTmV4dCBzdGVwczogV0dMQyBvZiBuZXcgdmVyc2lvbiAtMDYgb25jZSBvcGVuIGlzc3Vl cyBoYXZlIGJlZW4gc29sdmVkIGFuZCBuZXcgDQp2ZXJzaW9uIHN1Ym1pdHRlZC4gDQoNCkpv bmF0aGFuOiBUaGVyZSB3ZXJlIHNvbWUgb3RoZXIgbWlub3IgaXNzdWVzLCBJIHRoaW5rIHdl IHNob3VsZCBkaXNjdXNzIG9mZmxpbmUNCiAgICANCg0KUlRDUCBFeHRlbnNpb24gZm9yIEZl ZWRiYWNrIFN1cHByZXNzaW9uIEluZGljYXRpb24gcHJlc2VudGVkIGJ5IFFpbiBXdSANCihk cmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDgpDQoNCkFsbCBj aGFuZ2VzIHNpbmNlIDA1IHZlcnNpb24gd2VyZSBlZGl0b2lyaWFsLiBPbmUgb3BlbiBpc3N1 ZSBkaXNjdXNzZWQgb24gdGhlIA0KbGlzdCBpcyB0aGUgU2Vjb25kIExvc3MgaXNzdWU6ICBX aGVuIGEgcmVjZWl2ZXIgZ2V0cyBhIFRQTFIgbWVzc2FnZSwgZXhwZWN0aW5nIGEgDQpyZXRy YW5zbWlzc2lvbiBwYWNrZXQgd2hpY2ggZ2V0cyBsb3N0IGZyb20gRFMvTWVkaWEgU3JvdWNl LiBJcyBpdCB0aGVuIHJlbGV2YW50IA0KdG8gYXNrIGZvciByZXRyYW5zbWlzc2lvbj8gQW5k IGlmIHNvLCB3aGljaCBSVFQgc2hvdWxkIGJlIHVzZWQgZm9yIHRpbWVvdXQ/IFFpbiANCnBy ZXNlbnRzIHR3byBvcHRpb25zIHRvIHNvbHZlIHRoaXMgaXNzdWUuIEVpdGhlciB0byBjcmVh dGUgYSBuZXcgcmVwb3J0IGJsb2NrIHRvIA0KY2FycnkgUlRUMywgb3IgdG8gdXNlIHRoZSBz b2x1dGlvbiBjdXJyZW50bHkgZGVzcmliZWQgaW4gZHJhZnQuIA0KDQpDb2xpbjogZG9pbmcg dGhpcyB3aXRoIHRpbWVycyBhbmQgUlRUIHNvdW5kcyB3cm9uZy4gV2h5IG5vdCBqdXN0IHRy ZWF0IFRQTFIganVzdCANCmFzIHlvdSB0cmVhdCBhbnkgb3RoZXIgcGFja2V0PyANIA0KCg0K Sm9yZyBPdHQ6IFlvdSBhcmUgY3JlYXRpbmcgYW4gb3ZlcmxheSBiZXR3ZWVuIGRpZmZlcmVu dCBSVFAgZW50aXRpZXMsIHdoaWNoIGlzIA0Kc29sdmVkIGluIGFub3RoZXIgZHJhZnQuIA0K DQpNYWdudXM6IChhcyBpbmRpdmlkdWFsKTogSSBhZ3JlZSwgZm9yIHRoaXMgZHJhZnQgaXQg aXMgb2sgdG8ganVzdCBzdXJwcmVzcyB0aGlzIA0Kb25lLiBXZSBjYW4gc29sdmUgdGhpcyBp c3N1ZSBpbiB0aGUgZnV0dXJlLiANCg0KUm9uaTogU28gd2UgYXJlIGdvaW5nIHRoZSB3YXkg cHJvcG9zZWQgYnkgTWFnbnVzLiBEZWFsIHdpdGggVFBMUiB0aGUgc2FtZSB3YXkgYXMgDQpO QUNLIGFuZCBsb29rIGF0IHRpbWVyIHNvbHV0aW9uIGluIGxvbmcgdGVybSBObyBjb21tZW50 cyBmcm9tIHJvb20NCg0KDQoNCk1vbml0b3JpbmcgQXJjaGl0ZWN0dXJlIGZvciBSVFAgcHJl c2VudGVkIGJ5IFFpbiBXdSANCihkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0wNikNCg0K UWluIFd1IHByZXNlbnRpbmcgb3ZlcnZpZXcgYW5kIGNoYW5nZSBoaXN0b3J5IG9mIGRvY3Vt ZW50LCB0aGVyZSB3ZXJlIHRocmVlIA0KdXBkYXRlcyBzaW5jZSBJRVRGODEuDQoNCklzc3Vl cyBmcm9tIHRoZSBsaXN0Og0KDQoxLiBJcyB0aGVyZSBhIHNlY3R1cml0eSBpc3N1ZSB3aXRo IG1vbml0b3Jpbmc/DQpUaGUgc2VjdXJpdHkgc2VjdGlvbiBzYXlzIHRoYXQgaXQgaW50cm9k dWNlcyBubyBzZWN1dGlyeSB2dWxuZXJhYmlsaXRpZXMgYmV5b25kIA0KdGhvc2UgZGVzY2li cmVkIGluIDM2MTEuIFRoZXJlIGFyZSBpc3N1ZXMgd2l0aCBtb25pdG9yaW5nOiBGb3J3YXJp bmcgbW9uaXRvciANCnJlcG9ydHMgdG8gdHJhbnNsYXRlcnMgcHJlc2VudHMgcmlzay4gVGhp cmQgcGFydHkgbW9uaXRvcnMgcHJlc2VudCByaXNrDQoNCkNvbGluOiBJIGFncmVlIHRoYXQg Zm9yd2FyaW5nIG1vbml0b3IgcmVwb3JzIGlzIGEgbGVhaywgbWlnaHQgbm90IGJlIHJpc2su IFdoeSANCmp1c3QgdHJhbnNsYXRvcnM/IFFpbjogQWdyZWUsIG5vdCBsaW1pdGVkIHRvIHRy YW5zbGF0b3JzLCB3aWxsIHJldmlzZSB0ZXh0Lg0KDQoyLiBUaGVyZSBoYXMgYmVlbiBhIHN1 Z2dlc3Rpb24gdG8gYWRkIGRlZmluaXRpb25zIGZvciBhZGRpdGlvbmFsIHRlcm1zLiBRaW4g DQpmaW5kcyB0aGlzIHJlcXVlc3QgdG8gYmUgcmVhc29uYWJsZSBhbmQgcHJvcG9zZXMgYSBu dW1iZXIgb2YgZGVmaW5pdGlvbiAobG9va2luZyANCmZvciBmZWVkYmFjaykgTWFnbnVzOiBJ IHRoaW5rIHRoZSB0ZXJtIFNhbXBsZSBNZXRyaWNzIGlzIGEgYmFkIG5hbWUuIFRvbyBlYXN5 IHRvIA0KY29uZnVzZSB3aXRoIHNvbWV0aGluZyB0aGF0IGlzIGFuIGV4YW1wbGUgDQoNClFp biBwcm9wb3NlcyB0byBzdGFydCBXR0xDDQpNYWdudXM6IGZyb20gbXkgcGVyc3BlY3RpdmUs IGl0IHNlZW1zIHJlYWR5LiBBbnkgY29tbWVudHM/IA0KUm9uaTogdGhlIG5ldyB2ZXJzaW9u IGlzIHF1aXRlIHJlY2VudCwgcGxlYXNlIHJldmlldyBpdC4gDQoNCg0KUlRDUCBmb3IgaW50 ZXItZGVzdGluYXRpb24gbWVkaWEgc3luY2hyb25pemF0aW9uIHByZXNlbnRlZCBieSBSYXkg dmFuIEJyYW5kZW5idXJnIA0KKGRyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTAyKQ0KDQpSZWNl bnQgd29yayBvbiB0aGUgZHJhZnQgd2FzIHRvIGJyb2FkZW5lZCBzY29wZSB0byBpbmNsdWRl IFZpZGVvIHdhbGxzLCANCk5ldHdvcmtlZCBzcGVha2VycyBhbmQgUGhhc2VkIGFycmF5IHRy YW5zZHVjZXJzLg0KDQpJbmNyZWFzZWQgcHJlc2VudGF0aW9uIHRpbWVzdGFtcCB0byA2NCBi aXRzLg0KQ3VsbGVuOiBXaGF0IGxldmVsIG9mIHByZWNpc2lvbiBpcyBuZWVkZWQ/DQpBaWRl biBXaWxsaWFtczogIHBoYXNlZCBhcnJheXMgbmVlZCBzdWItbWlsbGlzZWNvbmQgYWNjdXJh Y3kgdG8gZG8gYmVhbSANCnN0ZWVyaW5nLCBuZWVkIDY0IGJpdHMgZm9yIHN1ZmZpY2llbnQg YWNjdXJhY3kgaW4gdGltZXN0YW1wLCBwcmV2aW91cyByZWZlcmVuY2VzIA0Kb24gdGhlIGxp c3QuDQoNCk5lZWQgb25lLXdheSBkZWxheSBmb3Igc3luYywgaG93IHRvIGdldCBpdD8gIFJU VC8yIHdpbGwgbm90IHdvcmsuDQoNClRocmVlIG9wdGlvbnMgaGF2ZSBiZWVuIHByb3Bvc2Vk DQqWVXNlIGV4aXN0aW5nIElETVMgcmVwb3J0cyBiZWZvcmUgc3RyZWFtaW5nIHN0YXJ0cw0K llN0YXJ0IHN0cmVhbWluZyB3aXRoIG51bGwgZGF0YSBhbmQgdXNlIGV4aXN0aW5nIElETVMg cmVwb3J0cw0KlkNyZWF0ZSBuZXcgWFIgYmxvY2sgdG8gcmVwb3J0IG9uIG9uZS13YXkgKHNl bmRlci0+cmVjZWl2ZXIpIGRlbGF5DQoNClByb3Bvc2FsIDEgLSBDb2xsaW4gc2F5cyBJRE1T IHJlcG9ydCBiZWZvcmUgc3RyZWFtaW5nIHdpbGwgbm90IHdvcmsNCiAgICAgICAgICAgICBk aWZmZXJlbnQgdGltaW5nIGZvciBkYXRhIHBhY2tldHMgdGhhbiBmb3IgbWVkaWEgcGFja2V0 cy4NCiAgICAgICAgICAgICBSVENQIHRpbWluZyBydWxlcyBkb24ndCBhbGxvdyBpdC4gIFBy aW9yaXRpemF0aW9uIG9mIHBhY2tldHMgd2lsbCANCiAgICAgICAgICAgICBkaXN0b3J0IHRp bWluZyBtZWFzdXJlbWVudC4NCiAgICAgICAgICAgICANClByb3Bvc2FsIDIgLSBzdGFydCBz dHJlYW1pbmcgUlRQIHBhY2tldHMgd2l0aCBOdWxsIG1lZGlhLg0KICAgIENvbGxpbiAtIGlz IGl0IG5lY2Vzc2FyeSB0byBzZW5kIG51bGwgbWVkaWE/IGp1c3Qgc2VuZCBtZWRpYSBhbmQg aXRzIG91dCBvZiBzeW5jLg0KICAgIEFpZGVuIFdpbGxpYW1zIHNheXMgbmVlZCBzeW5jaHJv bml6YXRpb24gZm9yIHF1aWNrIHN3aXRjaGluZyAoZWcgMTAgbXMpIGFwcGxpY2F0aW9ucy4N Cg0KUHJvcG9zYWwgMyAtIGRvZXNuJ3Qgc29sdmUgdGhlIGNsb2NrIHN5bmMgcHJvYmxlbSwg YnV0IG5ldyBYUiBibG9jayBmb3Igb25lLXdheSBkZWxheQ0KICAgIENvbGxpbiAtIHRoZSBz eW5jIHByb2JsZW0gaXMgbW9yZSBnZW5lcmFsLCANCiAgIENsb2NrIHN5bmNocm9uaXphdGlv biBtaWdodCBiZSB3b3J0aCBhIHNlcGFyYXRlIGRyYWZ0IHNpbmNlIGl0J3MgYSBnZW5lcmFs IHByb2JsZW0uDQogICBBaWRlbiBXaWxsaWFtczogIFRha2UgdGltaW5nIG91dCBvZiB0aGlz IGRyYWZ0IGFuZCBtYWtlIGEgc2VwYXJhdGUgb25lLg0KICAgICAgICAgICANCg0KDQoNClJU UCBNdWx0aXBsZXhpbmcgQXJjaGl0ZWN0dXJlIHByZXNlbnRlZCBieSBDb2xsaW4gUGVya2lu cyANCihkcmFmdC13ZXN0ZXJsdW5kLWF2dGNvcmUtbXVsdGlwbGV4LWFyY2hpdGVjdHVyZS0w MCkNCg0KQ29saW4gcHJlc2VudHMgdGhlIHJhdGlvbmFsZSBmb3IgdGhpcyBkcmFmdC4gRWFy bHkgaW1wbGVtZW50YXRpb25zIG9mIFJUUCBtYWRlIA0KZXh0ZW5zaXZlIHVzZSBvZiB0aGUg Z3JvdXAtYmFzZWQgZmVhdHVyZXMgb2YgUlRQLiBNb3JlIHJlY2VudCBWT0lQIGFuZCANCmNv bmZlcmVuY2luZyBzeXN0ZW1zIGRpZCBub3QgZG8gbXVjaCBpbiB0aGUgYXJlYSBvZiBncm91 cC1jb21tdW5pY2F0aW9uLiBFdmVuIA0KbW9yZSByZWNlbnRseSwgd29yayBvbiBlLmcuIFJU Q1dFQi9DbHVlLCBoYXMgcmVraW5kbGVkIGludGVyZXN0IGluIHRoZXNlIA0KZmVhdHVyZXMu IFRoaXMgZHJhZnQgcHJvdmlkZXMgZ3VpZGFuY2Ugb24gaG93IHRvIGRvIHRoaXMuDQoNCkNv bGluIHByZXNlbnRzIG51bWJlciBvZiBpc3N1ZXM6DQogICAgUlRQIE11bHRpcGxleGluZyBw b2ludHMgZm9yIG11bHRpcGxlIHN0cmVhbXMNCiAgICBSVFAgdG9wb2xvZ2llcyBhbmQgcmVz dWx0aW5nIGlzc3Vlcw0KICAgIFdoZW4gdG8gdXNlIG11bHRpcGxlIFNTUkMgaW4gYSBzaW5n bGUgc2Vzc2lvbiB2ZXJzdXMgd2hlbiB0byB1c2UgbXVsdGlwbGUgc2Vzc2lvbnMNCg0KVGhl IGRyYWZ0IHByb3Bvc2VzIGEgbnVtYmVyIG9mIGdlbmVyYWwgZ3VpZGVsaW5lcw0KDQpSVENX RUIgYW5kIENMVUUgYXJlIGxvb2tpbmcgYXQgdGhpcywgYnV0IG5vdCBleGFjdGx5IHRoaXMg bW9kZWwsIG1heSBiZSANCmNvbnRyb3ZlcnNpYWwgKE1hcnkgQmFybmVzIGdvdCB0aGlzIGNs YXJpZmljYXRpb24pDQoNCkN1bGxlbjogV2UgYWxyZWFkeSB0YWxrZWQgYWJvdXQgdGhpcyBp biB0aGUgbGFzdCBtZWV0aW5nLiBUaGVyZSBzZWVtZWQgdG8gYmUgDQpjb25zZXN1cy4gWW91 IG1pZ2h0IG5vdCBsaWtlIHRoaXMgY29uc2Vuc3VzLiBUbyBtZSB0aGUgcHVycG9zZSBvZiB0 aGlzIGlzIG5vdCBjbGVhci4gDQpDb2xpbjogVGhpcyBpcyBhIHZlcnkgYnJvYWQgdG9waWMs IHRoZXJlIGlzIG5vdCBhIHNpbmdsZSB1c2UgY2FzZQ0KQ3VsbGVuOiBXZSBhbHJlYWR5IGRp c2N1c3NlZCB0aGlzLiBQZW9wbGUgYXJlIG5vdCBidXlpbmcgaXQuIFdoYXQgYXJlIHdlIGdv aW5nIHRvIGRvIHdpdGggdGhhdCBkaXNjdXNzaW9uPw0KQ29saW46IFdlIGNhbiBhcmd1ZSBh Ym91dCB0aGUgZGV0YWlscyBvZiB0aGUgcmVjb21tZW5kYXRpb25zLiANCldoYXQgd2UgYXJl IGRpc2N1c3Npbmcgbm93LCBpcyB3aGV0aGVyIHRoZXJlIGlzIGEgcHVycG9zZSB0byBoYXZp bmcgc3VjaCBhIGRvY3VtZW50DQpIYXJhbGQ6IEkgaGF2ZSB0d28gcHJvYmxlbXMgd2l0aCBk cmFmdC4gDQoxKSBhIGxvdCBvZiB0ZXh0IHNwZW50IG9uIGtpY2tpbmcgaW4gb3BlbiBkb29y cy4gDQoyKSBUaGUgZHJhZnQgd2Fsa3MgYSB2ZXJ5IHRpZ2h0IGxpbmUgYmV0d2VlbiBnaXZp bmcgcmVjb21tZW5kYXRpb25zIGFuZCANCnNwZWNpZnlpbmcgdGhlbS4gVGhlIGF1dGhvcnMg b2YgdGhpcyBkcmFmdCBzZWVtIHRvIGRpY3RhdGUgdGhlbS4gQSBsb3Qgb2YgdGhpcyANCnN0 dWZmIHNob3VsZCBiZSBsZWZ0IHRvIHRoZSBpbXBsZW1lbnRhdGlvbi4NCg0KQ29saW46IFdl IHNob3VsZG4ndCBiZSBkaXNjdXNzaW5nIHNwZWNpZmljIG9mIHRoZXNlIHJlY29tbWVuZGF0 aW9uLiANCldlIHNob3VsZCBiZSBkaXNjdXNzaW5nIHdoZXRoZXIgd2Ugc2hvdWxkIGJlIG1h a2luZyByZWNvbW1lbmRhdGlvbnMNCg0KVGVkOiBUaGUgd2F5IHRoaXMgaXMgY29uc3RydWN0 ZWQgaXMgbm90IGhlbHBpbmcgdXMuIA0KTGFzdCB0aW1lIHdlIHRhbGtlZCBhYm91dCBhIHF1 aWNrIHNob3J0LXRlcm0gc29sdXRpb24gYW5kIHRoZW4gYSB3ZWxsIHRob3VnaHQtDQpvdXQg bG9uZy10ZXJtIHNvbHV0aW9uLiBUaGlzIGRyYWZ0IGRvZXMgbm90IHNlZW0gbGlrZSB0aGlz IGxvbmctdGVybSBzb2x1dGlvbi4gDQoNCkN1bGxlbjogQ3VycmVudCBkcmFmdCBpcyBub3Qg dXNhYmxlIGFkdmljZQ0KTWFnbnVzOiBUaGFua3MgZm9yIGZlZWRiYWNrLiBQbGVhc2UgcG9p bnQgdG8gc3BlY2lmaWMgc2VjdGlvbiB3aXRoIHdoaWNoIHlvdSANCmRpc2FncmVlLiBJdCBp cyBhIGxhcmdlIGRvY3VtZW50LCBwbGVhc2UgYmUgY2xlYXJlci4gDQoNCihub3Qgc3VyZSB3 aG8pOiBJIGFncmVlIHdpdGggQ3VsbGVuLiBQbGVhc2Ugc3RhdGUgcHJvL2NvbnMgZm9yIGVh Y2ggYXBwcm9hY2gsIA0KaW5zdGVhZCBvZiAoZGljdGF0aW5nKSBhIGNlcnRhaW4gYXBwcm9h Y2guIA0KSGFyYWxkOiBJIGRvbid0IGxpa2UgYSBkcmFmdCB0aGF0IHNheXMgJ3Rob3Ugc2hh bGx0IG5vdC4uJw0KSm9uOiBJIGRvbid0IHRoaW5rIGEgdG9waWMgbGlrZSB0aGlzIHdhcnJh bnRzIGEgbWlsZXN0b25lLiBJdCBqdXN0IGFkZHMgdG8gDQpjb25mdXNpb24uIE1heWJlIHdl IHNob3VsZG4ndCBkbyB0aGlzLiANCkNvbGxpbiAtIG1heWJlIHdlIG5lZWQgYW4gaXNzdWVz IGRyYWZ0LCBtYXliZSB0aGUgZWRpdG9yIHNob3VsZCBiZSBmcm9tIEVJVEhFUiBjYW1wLg0K Um9uaTogQ29udGludWUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdA0KDQoNCg0KTXVsdGlwbGUg UlRQIFNlc3Npb25zIG9uIGEgU2luZ2xlIExvd2VyLUxheWVyIFRyYW5zcG9ydCBwcmVzZW50 ZWQgYnkgTWFnbnVzIFdlc3Rlcmx1bmQgDQooZHJhZnQtd2VzdGVybHVuZC1hdnRjb3JlLXRy YW5zcG9ydC1tdWx0aXBsZXhpbmctMDEpDQoNClJlYXNvbiBmb3IgbXVsdGlwbGV4aW5nIGZs b3dzIGluIHNpbmdsZSBzZXNzaW9ucyBpcyBOQVRzLiBBZGRpdGlvbmFsIGRlbGF5IGZvciAN CmVhY2ggTkFUIHRyYXZlcnNhbCwgcmlzayBvZiBmYWlsdXJlLCBldGMuIFRoZSBwcm9ibGVt IHRoaXMgZHJhZnQgaXMgdHJ5aW5nIHRvIA0Kc29sdmUgaXMgZW5hYmxpbmcgYXBwbGljYXRp b25zIHRvIHNlbGVjdCBiZXR3ZWVuIHVzaW5nIG11bHRpcGxlIHNlc3Npb25zIGFuZCBub3Qg DQpoYXZpbmcgdG8gcGF5IGV4dHJhIGNvc3Qgb2YgdHJhbnNwb3J0IGRpZmZlcmVudGF0aW9u LiBEb2VzIHRoZSBXRyBiZWxpZXZlIHRoZSANCnByb2JsZW0gb2Ygc29sdmluZyBtdWx0aXBs ZSBSVFAgc2Vzc2lvbnMgb3ZlciBhIHNpbmdsZSB0cmFuc3BvcnQgZmxvdyBzaG91bGQgYmUg DQpzb2x2ZWQ/DQoNCkN1bGxlbjogU2FtZSBhcyBsYXN0IG1lZXRpbmcuIFdoeSBhcmUgd2Ug cG9zaW5nIHRoZSBzYW1lIHF1ZXN0aW9ucyBhZ2Fpbj8NCkNvbGluOiBJZiBJIHVuZGVzdGFu ZCBjb25zZW5zdXMgZnJvbSBsYXN0IHRpbWUsIGl0IHdhcyB0aGF0IHdlIHNob3VsZCBnbyBh aGVhZCANCmFuZCBwcm9wb3NlIHNvbWV0aGluZw0KDQpUaGUgZHJhZnQgZ2l2ZXMgcmVxdWly ZW1lbnRzLCBldmFsdWF0ZSBzb2x1dGlvbnMgYW5kIHByb3ZpZGVzIHJlY29tbWVuZGF0aW9u cy4NCg0KTWFnbnVzIHByZXNlbnRzIGxpc3Qgb2YgcmVxdWlyZW1lbnRzDQpNYXR0aGV3IEth dWZtYW46IE1vc3Qgb2YgdGhlc2UgcHJvYmxlbXMgd2l0aCBSVFAgYXJlIHRoZSByZXN1bHQg b2YgaXRzIG11bHRpY2FzdCANCm9yaWdpbnMuIFdoeSBub3QgcmVtb3ZlIE11bHRpY2FzdCBy ZXF1aXJlbWVudD8NCkNvbGluOiBNYXR0aGV3LCB3aGF0IHdvdWxkIHlvdSByZW1vdmUgdGhl bj8gDQpNYXR0aGV3OiBUaGVyZSBhcmUgcHJvYmxlbXMgdW5pcXVlIHRvIHNwZWNpZmljIG11 bHRpY2FzdCB0b3BvbG9naWVzDQpKb25hdGhhbjogU29tZSBuZXR3b3JrcyB0cmVhdCBSVFAg ZGlmZmVyZW50IHRoYW4gb3RoZXIgcHJvdG9jb2xzLiBUaGF0IGltcGxpZXMgDQpEUEkoRGVl cCBQYWNrZXQgSW5zcGVjdGlvbikuIFdoeSBub3QgYWRkIGEgcmVxdWlyZW1lbnQgdG8gbm90 IGJyZWFrIERQST8NCg0KU3RlcGhhbjogTWFnbnVzLCBjYW4geW91IHJlcGVhdCB3aGF0IHlv dSBtZWFuIGJ5IGluY3JlbWVudGFsIGRlcGxveW1lbnQNCk1hZ251czogWW91IHdhbnQgdG8g YmUgYWJsZSB0byB1c2UgYm90aCB0eXBlcyBjb25jdXJyZW50bHksIHNvIG11bHRpcGxlIHNl c3Npb25zIA0KYXMgd2VsbCBhcyBzaW5nbGUgc2Vzc2lvbi4gDQpDdWxsZW46IEkgZG9uJ3Qg bWluZCByZXVzaW5nIGJpdHMgYXMgbG9uZyBhcyB3ZSBkb24ndCBicmVhayBkZXBsb3ltZW50 cy4gIA0KV2h5IGRvIHdlIG5lZWQgYSByZXF1aXJlbWVudCBzYXlpbmcgJ0VuYWJsZSBzYW1l IFNTUkMgaW4gbXVsdGlwbGUgUlRQIHNlc3Npb25zPycNCk1hZ251czogeW91IG1pZ2h0IG5v dCB1c2UgdGhlbSwgYnV0IHNvbWUgcGVvcGxlIGRvDQpDdWxsZW46IFdlIHNob3VsZCBnbyB0 aHJvdWdoIGVhY2ggZXh0ZW5zaW9uIHRvIHNlZSB3aGV0aGVyIGl0IGlzIHVzZWQuDQpDdWxs ZW46IEFkZCByZXF1aXJlbWVudDogZG9uJ3QgdXNlIG1vcmUgYmFuZHdpZHRoIHRoYW4gcmVx dWlyZWQNCkhhcmFsZDsgSSB3b3VsZCBsaWtlIHRvIHJlZm9ybXVsYXRlIHJlcSAzOiAiZG9u J3QgY3JlYXRlIG5ldyBzZWN1cml0eSByaXNrcyINCkhhZHJpZWw6IE5vdCBldmVyeSBleHRl bnNpb24gd2lsbCBtYWtlIHVzZSBvZiB0aGlzLiBTbyBpbmNvbXBhdGliaWxpdHkgbWlnaHQg bm90IA0KYmUgYSBwcm9ibGVtLiANCkZhbGxiYWNrIHNvbHV0aW9ucyBhcmUgYWx3YXlzIHBv c3NpYmxlLiANCk1hdGhldzogQmVjYXVzZSB0aGlzIGlzIGp1c3QgYW4gb3B0aW1pemF0aW9u IGZvciBhIGNlcnRhaW4gc2NlbmFyaW8sZG8gbm90IGNhcmUgDQpmb3IgcmVxdWlyZW1lbnRz IDIsIDMsIDYsIDcsIGJyZWFraW5nIHNvbWUgc3R1ZmYgaXMgbm90IGltcG9ydGFudC4gWW91 IGNhbiANCnNpbXBseSBjaG9vc2Ugbm90IHRvIHVzZSB0aGVzZSBvcHRpbWl6YXRpb25zDQoN Cihub3Qgc3VyZSk6IEhvdyBkbyB3ZSBtYWtlIHN1cmUgdGhhdCB0aGlzIHJlbWFpbnMgYW4g b3B0aW1pemF0aW9uLiBBbmQgbm90IA0KZGVmYXVsdCBiZWhhdmlvdXIgaW4gYSBmZXcgeWVh cnMgdGltZT8NCkNvbGluOiBJZiB5b3Ugd2FudCB0byBkZWZpbmUgYSBuZXcgUlRQLCBvayBn byBhaGVhZC4gQnV0IGlmIHdlIHdhbnQgdG8gb3B0aW1pemUgDQpSVFAsIHRoZW4gd2Ugc2hv dWxkIGF0IGxlYXN0IHRyeSB0byBiZSBjb21wYXRpYmxlLiBNYWdudXM6IEkgcmVwZWF0LCB0 aGlzIGlzIA0KanVzdCBvbmUgd2F5LiBOb3QgVEhFIHdheS4NCg0KTWFnbnVzIHByZXNlbnRz IGEgc29sdXRpb24vcmVxdWlyZW1lbnQgbWF0cml4LiANCkN1bGxlbjogSSBkb24ndCBhZ3Jl ZSB3aXRoIGEgbG90IG9mIHRoaXMuIGxldHMgZXhhbWluZSBtdXggc2hpbSwgZ3JlZW4gaW4g YmxvY2sgDQo4LCBpdCBjYW4ndCBiZSByaWdodA0KDQpNYWdudXM6IHRoZSBjb25zZW5zdXMg aW4gUXVlYmVjIHdhcyB0byBkbyBib3RoOiBzaW5nbGUgc2Vzc2lvbnMgYW5kIG11bHRpcGxl IA0Kc2Vzc2lvbnMgb24gc2luZ2xlIHRyYW5zcG9ydCBmbG93LiBJcyB0aGlzIHN0aWxsIHRy dWU/IERvIHdlIHJlYWxseSBuZWVkIGJvdGg/DQpUZWQ6IFRoaXMgcXVlc3Rpb24gaXMgYmV0 dGVyIGFuc3dlcmVkIGFmdGVyIEpvbmF0aGFuJ3MgcHJlc2VudGF0aW9uDQoNCkF1dGhvcnMg cmVjb21tZW5kIGEgc29sdXRpb24gYmFzZWQgb24gTXVsdGlwbGV4aW5nIFNoaW0sDQogIEFO RCBzaW5nbGUgc2Vzc2lvbiBwcm9wb3NhbCBpbiBKb25hdGhhbiBMZW5ub3ggcHJlc2VudGF0 aW9uLiANCg0KSGFyYWxkOiBUaGUgZ29vZCB0aGluZyBhYm91dCBtdWx0aXBsZSBzb2x1dGlv bnMsIGlzIHRoYXQgSSBjYW4gY2hvb3NlIHRoZSBvbmUgSSANCmxpa2UuIA0KDQoNCg0KDQoN Cg0KTXVsdGlwbGUgUlRQIFNlc3Npb24gb24gYSBTaW5nbGUgTG93ZXItTGF5ZXIgVHJhbnNw b3J0LCANCnBhcnQgMiBKb25hdGhhbiBMZW5ub3ggcHJlc2VudGluZyAoZHJhZnQtbGVubm94 LXJ0Y3dlYi1ydHAtbWVkaWEtdHlwZS1tdXgtMDApLiANCg0KV2Ugd2FudCB0byBiZSBhYmxl IHRvIHNlbmQgUlRQIHNvdXJjZXMgb2YgbXVsdGlwbGUgbWVkaWEgdHlwZXMgb3ZlciBhIHNp bmdsZSANCnRyYW5zcG9ydCBmbG93IGZvciB0aGUgcmVhc29ucyBNYWdudXMgaGFzIG1lbnRp b25lZCBTYXlpbmcgd2Ugd2FudCB0byBzZW5kIA0KbXVsdGlwbGUgUlRQIHNlc3Npb25zIGlz IGFzc3VtaW5nIHRoZSBzb2x1dGlvbi4NCg0KSnVzdCBzZW5kIHNvdXJjZXMgb2YgbXVsdGlw bGUgbWVkaWEgdHlwZXMgaW4gb25lIG1lZGlhIHNlc3Npb24uIE5vIG5ldyBSVFAtbGV2ZWwg DQpzdGFuZGFyZGl6YXRpb24gd29yayBuZWVkZWQgKGp1c3QgaWdub3JlIG9uZSBTSE9VTEQg aW4gUkZDIDM1NTApLiBUaGUgU0RQLWxldmVsIA0Kc3RhbmRhcmRpemF0aW9uIHdvcmsgaXMg cm91Z2hseSBlcXVpdmFsZW50IGZvciBldmVyeSB0cmFuc3BvcnQgbWVjaGFuaXNtLiBUaGUg DQpCVU5ETEUgZ3JvdXAgc2VtYW50aWNzIGlzIHByb2JhYmx5IHRoZSByaWdodCBhcHByb2Fj aCwgdW5sZXNzIHdlIHdhbnQgdG8gDQpqZXR0aXNvbiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5 LiBQcm9wb3NlIHRvIG5vdCBzdXBwb3J0IHB1cmUtdHJhbnNwb3J0IA0KdHJhbnNsYXRpb24g YmV0d2VlbiBtdWx0aXBsZXhlZCBhbmQgbm9uIG11bHRpcGxleGVkIHN0cmVhbXMuDQoNCkpv bmF0aGFuOiBBYm92ZSBhc3N1bWVzIG11bHRpLXBvaW50LiANCg0KQ29saW46IFlvdSBzZWVt IHRvIGJlIHJlcXVpcmluZyBhIHZlcnkgY29tcGxpY2F0ZWQgbWlkZGxlLWJveC4gDQpZb3Ug bWF5IHdhbnQgdG8gc3VwcG9ydCB2ZXJ5IHNpbXBsZSBtaWRkbGUtYm94ZXMgYW5kIHRoZW4g Zml4IHRoZSBzaWduYWxsaW5nLiANCg0KSm9uYXRoYW46IHNlbGYtcmVwb3J0aW5nIGFuZCBj cm9zcy1yZXBvcnRpbmcgYXJlIG9ubHkgdXNlZnVsIGZvciBwdXJlLXRyYW5zcG9ydCANCnRy YW5zbGF0aW9ucy4gVGhpcyBpcyBub3Qgc3BlY2lmaWMgdG8gbWVkaWEgdHlwZSBtdXhpbmcs IHNvIHByb2JhYmx5IHNob3VsZCBiZSANCmluIHNlcGVyYXRlIGRyYWZ0DQpNYWdudXM6IExl dCdzIHRha2UgdGhpcyBkaXNjdXNzaW9uIG9mZmxpbmUNCg0KUm9uaTogTGV0J3MgZ28gYmFj ayB0byBNYWdudXMnIHF1ZXN0aW9uIG9uIHdoZXRoZXIgdG8gZG8gYm90aCBhcHByb2FjaGVz IG9yIGp1c3Qgb25lLiANCkhhZHJpZWw6IEkgbmVlZCBtb3JlIGlucHV0DQpIYXJhbGQ6IFdo ZW4gd2UgaGF2ZSB0d28gdmlkZW8gc3RyZWFtcyBhcnJpdmluZyBhdCBvbmUgZGVzdGluYXRp b24sIG5vIG1hdHRlciANCmhvdyB0aGV5IGFyZSBwYWNrYWdlZCwgd2UgbmVlZCB0byBrbm93 IHdoaWNoIGlzIHdoaWNoLiBUaGF0IGlzIGluZGVwZW5kZW50IG9mIA0Kd2hldGhlciB0aGV5 IGFyZSBpbiBhIHNpbmdsZSBzZXNzaW9uIG9yIG5vdC4gDQpSb25pOiBXZSdsbCB0YWtlIE1h Z251cycgcXVlc3Rpb24gdG8gdGhlIGxpc3QuIA0KDQpDdWxsZW46IEhvdyBtYW55IHBlb3Bs ZSBhcmUgaW50ZXJlc3RlZCBpbiB0aGlzPw0KKGFib3V0IDIwIHBlb3BsZSByYWlzZSBoYW5k cykNCkN1bGxlbjogSSB3YW50IHRvIHNlZSBhdCBsZWFzdCAyMCBwZW9wbGUgY29tbWVudCBv biB0aGlzIG9uIHRoZSBsaXN0IGJlZm9yZSB3ZSANCmNhbGwgY29uc2Vuc3VzLiANClJvbmk6 IE5vdGVkLiANCg0KDQpEdXBsaWNhdGluZyBSVFAgU3RyZWFtcywgQ29sbGluIFBlcmtpbnMg cHJlc2VudGVkIGZvciBBbGkgQmVnZW4gDQooZHJhZnQtYmVnZW4tYXZ0Y29yZS1ydHAtZHVw bGljYXRpb24tMDApDQoNClBhY2tldCBsb3NzIGlzIHVuYXZvaWRhYmxlIChlLmcuIGNvbmdl c3Rpb24sIG91dGFnZXMpLiBBIHJlZHVuZGFudCBzdHJlYW0gY2FuIA0KY2FycmF5IEZFQy1s aWtlIGRhdGEgb3IgcGFja2V0IGR1cGxpY2F0ZXMuIFRoaXMgZG9jdW1lbnQgZXhwbGFpbnMg aG93IFJUUCANCnN0cmVhbXMgYXJlIHRvIGJlIGR1cGxpY2F0ZWQgd2l0aG91dCBicmVha2lu ZyBSVFAvUlRDUCBydWxlcyBDb2xpbiBwcmVzZW50cyBhIA0KbnVtYmVyIG9mIGRpZmZlcmVu dCBzY2VuYXJpb3MgKHRlbXBvcmFsIHZzLiBzcGF0aWFsLCBtZXJnaW5nIGF0IHJlY2VpdmVy IHZzLiANCm1lcmdpbmcgaW4gbmV0d29yaykgYW5kIHNvbWUgcmVjb21tZW5kYXRpb25zIG9u IGhvdyB0byBkZWFsIHdpdGggdGhlbS4gDQoNCkNvbGluOiBGb3IgdGltZS1zaGlmdGVkIHJl ZHVuZGFuY3kgY2FzZSwgb3BlbiBpc3N1ZSBpcyBob3cgd2Ugc2hvdWxkIGNvcnJlbGF0ZSAN CmR1cGxpY2F0ZSBzdHJlYW1zDQpKb25hdGhhbjogVGhlcmUgc2VlbSB0byBiZSBhIGZldyBj YXNlcyB3aGVyZSB5b3UgbmVlZCB0byBzZWUgZGlmZmVyZW5jZSBiZXR3ZWVuIA0Kb3Jpbmdp YWwgcGFja2V0IGFuZCBkdXBsaWNhdGUuIEJ1dCBub3QgaW4gYWxsIGNhc2VzLiBNYWdudXMn IHByb3Bvc2FsIGZvciBzaW5nbGUgDQpzZXNzaW9ucyBjYW4ndCBtYWtlIHRoYXQgZGlzdGlu Y3Rpb24uIElzIHRoYXQgaW1wb3J0YW50Pw0KDQpDb2xpbiBwcmVzZW50cyBvcGVuIGlzc3Vl czogSG93IHRvIGNvcnJlbGF0ZSBzdHJlYW1zPyBDYW4gd2UgdXNlIHN0YW5kYXJkIFJUUCAN CnN5bmNocm9uaXphdGlvbj8gT3IgdGltZXN0YW1wIGFsaWdubWVudD8gSG93IGRvIFJUQ1Ag cmVwb3J0cyB3b3JrIGluIGNhc2Ugb2YgDQpuZXR3b3JrIG1lcmdpbmc/IA0KDQpOZXR3b3Jr IHN0cmVhbSBtZXJnaW5nIC0gDQpIYXJhbGQgLSBhc2tzIGNsYXJpZmljYXRpb24gLSBpZiBs b3NzLCB0aGVuIFJUUCB0cmFuc2xhdG9yIGhhcyB0byBiZSBhYmxlIHRvIGNyZWF0ZQ0KICAg ICAgICAgIHBhY2tldHMsIHNvIG5lZWRzIHNlY3VyaXR5IGtleS4NCkhhZHJpZWwtIHJlLW9y ZGVyaW5nIHByb2JsZW0gd2l0aCBvcmlnaW5hbCBzdHJlYW0gbG9zcyAtIA0KICAgICAgICAg IENvbGluIC0gbmVlZCB0byByZWNvbnN0cnVjdCB0aW1pbmcgdG8gYXZvaWQgdGhpcw0KDQpD b2xpbjogSXMgdGhlcmUgaW50ZXJlc3QgaW4gcHVyc3VpbmcgdGhpcyB3b3JrIGluIEFWVENP UkU/DQoNCkpvbmF0aGFuOiBXaHkgaXMgdGhpcyBpbiBBVlRjb3JlIGFuZCBub3QgaW4gQVZU ZXh0Pw0KSGFkcmllbDogTW9zdCBvZiB0aGUgdGltZSBwYWNrZXQgbG9zcyBpcyBkdWUgdG8g Y29uZ2VzdGlvbi4gU28geW91J3JlIG9ubHkgDQptYWtpbmcgdGhlIHByb2JsZW0gd29yc2Ug YnkgZHVwbGljYXRpbmcgcGFja2V0cw0KRGF2ZTogSW4gdGhlIHRlbXBvcmFsIGNhc2UsIHlv dSBoYXZlIGRpZmZlcmVudCByb3V0aW5nIHlvdSBjYW4gaGF2ZSBsb3NzbGVzcyBpZiANCnRo ZSB0aW1lIG9mZnNldCBpcyBncmVhdGVyIHRoYW4gdGhlIHJvdXRlIGNvbnZlcmdlbmNlIHRp bWUgYXQgdGhlIGNvc3Qgb2YgdHdpY2UgDQp0aGUgYmFuZHdpZHRoLiBJbiB0aGUgY2FzZSBv ZiBzcGF0aWFsIHJlZHVuZG5hY3ksIHlvdSBtaWdodCBoYXZlIGRpZmZlcmVudCANCm5ldHdv cmsgcGxhbmVzLiANCkhhZHJpZWw6IGlzIHRoYXQgYSByZWFsaXN0aWMgc2NlbmFyaW8/IFRo YXQgY2xpZW50cyBoYXZlIGNvbnRyb2wgb3ZlciB0aGUgDQpuZXR3b3JrIHJvdXRlPyBEYXZl IE9yYW4gLSBjYW4gc2VuZCBvdmVyIHBhcmFsbGVsIG5ldHdvcmsgcGxhbmVzIC0gQ2lzY28g aXMgDQpzaGlwcGluZyB0aGlzLkNhbid0IGRpc2N1c3MgZnVydGhlci4NCg0KDQpNdWx0aXBh dGggUlRQIChkcmFmdC1zaW5naC1hdnQtbXBydHAtMDMpIHdhcyBub3QgcHJlc2VudGVkIHNp bmNlIHdlIHJhbiBvdXQgb2YgdGltZS4NCg== --------------020502010106010704060502-- From internet-drafts@ietf.org Thu Jan 12 16:39:18 2012 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 D763E21F8642; Thu, 12 Jan 2012 16:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 ePl+KXN-wzVU; Thu, 12 Jan 2012 16:39:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A12D21F8552; Thu, 12 Jan 2012 16:38:51 -0800 (PST) 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.64p1 Message-ID: <20120113003851.32604.83453.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 16:38:51 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-09.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, 13 Jan 2012 00:39:18 -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-09.txt Pages : 26 Date : 2012-01-12 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 their 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-09.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-09.txt From bill.wu@huawei.com Thu Jan 12 16:53:02 2012 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 03A0A21F85FC for ; Thu, 12 Jan 2012 16:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.473, 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 jXR8iG-GrwKl for ; Thu, 12 Jan 2012 16:53:01 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 91FF321F8606 for ; Thu, 12 Jan 2012 16:52:57 -0800 (PST) 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 <0LXP00FNHP426M@szxga05-in.huawei.com> for avt@ietf.org; Fri, 13 Jan 2012 08:52:50 +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 <0LXP00HEAP42HT@szxga05-in.huawei.com> for avt@ietf.org; Fri, 13 Jan 2012 08:52:50 +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 AGH03894; Fri, 13 Jan 2012 08:52:50 +0800 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jan 2012 08:52:38 +0800 Received: from w53375q (10.138.41.130) by szxeml418-hub.china.huawei.com (10.82.67.157) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jan 2012 08:52:41 +0800 Date: Fri, 13 Jan 2012 08:52:38 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: 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=utf-8 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected Subject: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-monarch-09.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, 13 Jan 2012 00:53:02 -0000 Hi, This version addresses a few comments on the list from Colin, Albrecht and Charles. Regards! -Qin On 13 January 2012, at 8:39 AM, Internet-Drafts@ietf.org wrote: >A new version of I-D, draft-ietf-avtcore-monarch-09.txt has been successfully submitted by Qin Wu and posted to the IETF repository. >Title : Monitoring Architectures for RTP >Author(s) : Qin Wu > Geoff Hunt > Philip Arden >Filename : draft-ietf-avtcore-monarch-09.txt >Pages : 26 >Date : 2012-01-12 >Abstract: > 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 their 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. From magnus.westerlund@ericsson.com Tue Jan 17 01:55:06 2012 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 D67AB21F8615 for ; Tue, 17 Jan 2012 01:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 1nvuSZuYuhHy for ; Tue, 17 Jan 2012 01:55:06 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 191FC21F860D for ; Tue, 17 Jan 2012 01:55:05 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-72-4f15457882f7 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 54.A1.23425.875451F4; Tue, 17 Jan 2012 10:55:05 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Tue, 17 Jan 2012 10:55:04 +0100 Message-ID: <4F154577.9060109@ericsson.com> Date: Tue, 17 Jan 2012 10:55:03 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: avt@ietf.org References: <4F0F0576.9090606@ericsson.com> In-Reply-To: <4F0F0576.9090606@ericsson.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] Draft Minutes IETF 82 AVTCORE session 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, 17 Jan 2012 09:55:07 -0000 WG, Unless we still have outstanding issues on Friday, I will submit these minutes then. Best regards Magnus On 2012-01-12 17:08, Magnus Westerlund wrote: > Hi, > > Attached are draft minutes for the AVTCORE WG session. Sorry for them > being very late, this is due to me being ill. In the end Roni made most > of the work to prepare these minutes. > > Please review them. > > We will see if we can get them added to the proceedings after the WG > have had some time to look at them. > > 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 > ---------------------------------------------------------------------- -- 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 Tue Jan 17 06:00:52 2012 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 6522721F86CE for ; Tue, 17 Jan 2012 06:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.312 X-Spam-Level: X-Spam-Status: No, score=-106.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 yzvJxE1S-59v for ; Tue, 17 Jan 2012 06:00:51 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E94E321F86CB for ; Tue, 17 Jan 2012 06:00:48 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-90-4f157f0febda Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DA.EA.09514.F0F751F4; Tue, 17 Jan 2012 15:00:48 +0100 (CET) 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; Tue, 17 Jan 2012 15:00:47 +0100 Message-ID: <4F157F0D.1060204@ericsson.com> Date: Tue, 17 Jan 2012 15:00:45 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "jsaldana@unizar.es" References: <002c01cccf8b$c739f5d0$55ade170$@unizar.es> In-Reply-To: <002c01cccf8b$c739f5d0$55ade170$@unizar.es> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Proposal for updating TCRTP (RFC 4170) 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, 17 Jan 2012 14:00:52 -0000 Hi, As you are proposing to go towards a more generic scheme I don't think this proposal really belongs in the WG, most likely not this area even. I think this is a topic that primarily are related to Intarea and Transport. Intarea as the owner of the tunneling work in IETF and Transport as the actual aggregation and header compression is primarily transport topics. A question I would have is where this type of mechanism would make sense. Where do you have scarce bandwidth capacity and are willing to pay the downsides of the ingress egress complexities and the impact on the traffic in regards to additional delay. Cheers Magnus On 2012-01-10 12:34, jsaldana@unizar.es wrote: > Hello all. > > My name is Jose Saldana, from the University of Zaragoza, in Spain. I am > new here. > > I would like to share with AVTCORE Work Group a proposal, in case it > could be considered interesting. The main idea is to update TCRTP. This > is a "Best current practice" RFC > (http://datatracker.ietf.org/doc/rfc4170/) which was developed in > Audio/Video Transport working group in 2005-11. It "describes a method > to improve the bandwidth utilization of RTP streams over network paths > that carry multiple Real-time Transport Protocol (RTP) streams in > parallel between two endpoints, as in voice trunking. The method > combines standard protocols that provide compression, multiplexing, and > tunneling over a network path for the purpose of reducing the bandwidth > used when multiple RTP streams are carried over that path." (from the > introduction of RFC4170). > > > The scheme of TCRTP is: > > RTP/UDP/IP > > | > > | > > ECRTP (compressing layer). Compresses RTP/UDP/IP headers > > | > > | > > PPPMux (multiplexing layer). Includes a number of compressed packets > into a bigger one > > | > > | > > L2TP (tunneling layer). Permits its use end-to-end > > | > > | > > IP > > However, there exist many real-time flows that do not use RTP: > > - Online "First Person Shooter" (FPS) games use UDP datagrams, and they > are one of the most "real-time" applications nowadays. Some examples: > Counter Strike, Halo, Quake, etc.[1]. > > - Online "Massively Multiplayer Online Role Playing Games" (MMORPG): > They use TCP, but can be considered "real-time", since the actions of > the players have to be transmitted very quickly to the server. It should > be taken into account that player vs player fights are one of the > possible activities of the game. Some examples: World of Warcraft (more > than 10 million subscribers) [2]. > > - TCP is also getting used for media delivery. For many reasons, such as > avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is > substituted in many cases by IP/ TCP/ HTTP/ FLV [3]. > > - Another interesting scenario is satellite communication links. > Multiplexing small packets into one packet for transmission would > improve the efficiency. Satellite links would also find it useful to > multiplex small TCP packets into one packet – this could be especially > interesting for compressing TCP ACKs. > > > In our recent research activities, we have adapted TCRTP scheme for its > use when the traffic is not RTP. The idea is to substitute ECRTP by > other compression scheme which can be used for UDP or TCP headers. In > 2006, the IETF formed the Robust Header Compression (ROHC) working group > which created specifications for header compression over links for RTP, > UDP and TCP. These specifications were extended to compress headers > over other networks. For most RTP flows, ROHC is more bandwidth > efficient than ECRTP, at the cost of implementation complexity. It has a > special care of context synchronization, defining some states at the > compressor and decompressor. Once the effort for designing ROHC has been > conducted, it is worth including it in the compressing and multiplexing > standard. > > > In a recent paper in Nov. issue of IEEE Communications Magazine, it was > shown that 30% of bandwidth saving can be achieved for 8 FPS different > games using IPv4. If IPv6 is used, savings can be up to 54% [4]. Another > recent study, which is still under review, has estimated 45% bandwidth > saving for World of Warcraft. > > > After talking to other researchers, including some of the authors of > RFC4170, the possible scheme of the proposal could be this one: > > > G.711.0 payload compression TCP UDP UDP/RTP > > | | | | > > | \ | / > > | \ | / > > | nothing or ROHC or ECRTP > > | | > > \ / > > \ / > > multiplexing layer (other or PPPMUX) > > | > > | > > tunneling layer (other or GRE or L2TP) > > | > > | > > IP > > It should be more "open" than TCRTP. I mean, it could be "orthogonal" to > different protocols: different header compression algorithms could be > used, depending on the application and the scenario; also different > multiplexing and tunneling protocols could be included. Finally, we have > also included the G.711.0 "branch": it could be interesting to convert > G.711 to G.711.0 (a lossless encoding of G.711) and back, using a > similar tunneling mechanism. In a similar way to TCRTP, the G.711 to > G.711.0 and vice versa conversion does not involve SIP/SDP/RTSP > signaling with the endpoints, since G.711 has a fixed RTP payload number. > > We have not written a draft. This is only the first idea, so we look > forward to hearing the opinion of the Working Group, > > > Thank you very much, and sorry for writing such a long message, > > Jose Saldana > > University of Zaragoza > > ______________ > > [1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of First-Person > Shooter Gaming Traffic on the Internet," Internet Computing, IEEE , > vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5445069&isnumber=5562482 > > > [2] P. Svoboda, W Karner and M. Rupp, “Traffic Analysis and Modeling for > World of Warcraft,” ICC '07. IEEE International Conference on > Communications, pp.1612-1617, 24-28, Jun. 2007. URL: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4288941&isnumber=4288671 > > > [3] G. Marfia and M. Roccetti, “TCP At Last: Reconsidering TCP’s Role > for Wireless Entertainment Centers at Home,” IEEE Transactions on > Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5681095&isnumber=5681060 > > > [4] J. Saldana, J. Fernández-Navajas, J. Ruiz-Mas, J. I. Aznar, E. > Viruete and L. Casadesus, “First Person Shooters: Can a Smarter Network > Save Bandwidth without Annoying the Players?,” IEEE Communications > Magazine, Consumer Communications and Networking Series, vol. 49, no. > 11, pp. 190-198, Nov. 2011. URL: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6069728&isnumber=6069696 > > -- 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 jsaldana@unizar.es Tue Jan 17 10:01:32 2012 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 13A2A21F858A for ; Tue, 17 Jan 2012 10:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 HsCFTtvdmedE for ; Tue, 17 Jan 2012 10:01:30 -0800 (PST) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4D53A21F8557 for ; Tue, 17 Jan 2012 10:01:29 -0800 (PST) Received: from unizar.es (mesa.unizar.es [155.210.1.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q0HI1KYU025260 for ; Tue, 17 Jan 2012 19:01:20 +0100 Received: from wsip-70-165-225-204.lv.lv.cox.net (wsip-70-165-225-204.lv.lv.cox.net [70.165.225.204]) by webmail.unizar.es (Horde MIME library) with HTTP; Tue, 17 Jan 2012 19:01:20 +0100 Message-ID: <20120117190120.w1d4m0pv1cgk888k@webmail.unizar.es> Date: Tue, 17 Jan 2012 19:01:20 +0100 From: jsaldana@unizar.es To: avt@ietf.org References: <002c01cccf8b$c739f5d0$55ade170$@unizar.es> <4F157F0D.1060204@ericsson.com> In-Reply-To: <4F157F0D.1060204@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [AVTCORE] Proposal for updating TCRTP (RFC 4170) 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, 17 Jan 2012 18:01:32 -0000 Magnus, Thank you very much for your message. I'm going to send the proposal =20 to Internet Area and to Transport Area too. We are merging different =20 ideas and I think one problem of this proposal is in which area and =20 group can it fit. Regarding the scenarios, we have considered some of them: - A provider of a real-time service (e.g. game or voip) can have an =20 infrastructure with a number of proxies that can group traffic from =20 different users and send it to the server. - An Internet caf=E9, where a number (sometimes big) of players share =20 the same access link. Bandwidth is scarce in that scenario. - A satellite link, where the bandwidth and the pps have to be saved. Some of the publications I cited in my first message have studied the =20 impact of multiplexing on network parameters, and even in subjective =20 quality. In fact, two days ago I presented in CCNC (Las Vegas) a paper =20 about that: http://diec.unizar.es/~jsaldana/personal/ccnc_2012_july.pdf Other related papers are: http://diec.unizar.es/~jsaldana/personal/gamma_CCNC_2011_in_proc.pdf http://diec.unizar.es/~jsaldana/personal/ciber_SPECTS_2011_in_proc.pdf We sent the proposal to avt group because the first version was =20 developed for real-time services, but perhaps the current proposal has =20 become too generic. Nevertheless, the main idea is to use it for =20 real-time services. Thank you very much, Jose > Hi, > > As you are proposing to go towards a more generic scheme I don't think > this proposal really belongs in the WG, most likely not this area even. > > I think this is a topic that primarily are related to Intarea and > Transport. Intarea as the owner of the tunneling work in IETF and > Transport as the actual aggregation and header compression is primarily > transport topics. > > A question I would have is where this type of mechanism would make > sense. Where do you have scarce bandwidth capacity and are willing to > pay the downsides of the ingress egress complexities and the impact on > the traffic in regards to additional delay. > > Cheers > > Magnus > > > On 2012-01-10 12:34, jsaldana@unizar.es wrote: >> Hello all. >> >> My name is Jose Saldana, from the University of Zaragoza, in Spain. I am >> new here. >> >> I would like to share with AVTCORE Work Group a proposal, in case it >> could be considered interesting. The main idea is to update TCRTP. This >> is a "Best current practice" RFC >> (http://datatracker.ietf.org/doc/rfc4170/) which was developed in >> Audio/Video Transport working group in 2005-11. It "describes a method >> to improve the bandwidth utilization of RTP streams over network paths >> that carry multiple Real-time Transport Protocol (RTP) streams in >> parallel between two endpoints, as in voice trunking. The method >> combines standard protocols that provide compression, multiplexing, and >> tunneling over a network path for the purpose of reducing the bandwidth >> used when multiple RTP streams are carried over that path." (from the >> introduction of RFC4170). >> >> >> The scheme of TCRTP is: >> >> RTP/UDP/IP >> >> | >> >> | >> >> ECRTP (compressing layer). Compresses RTP/UDP/IP headers >> >> | >> >> | >> >> PPPMux (multiplexing layer). Includes a number of compressed packets >> into a bigger one >> >> | >> >> | >> >> L2TP (tunneling layer). Permits its use end-to-end >> >> | >> >> | >> >> IP >> >> However, there exist many real-time flows that do not use RTP: >> >> - Online "First Person Shooter" (FPS) games use UDP datagrams, and they >> are one of the most "real-time" applications nowadays. Some examples: >> Counter Strike, Halo, Quake, etc.[1]. >> >> - Online "Massively Multiplayer Online Role Playing Games" (MMORPG): >> They use TCP, but can be considered "real-time", since the actions of >> the players have to be transmitted very quickly to the server. It should >> be taken into account that player vs player fights are one of the >> possible activities of the game. Some examples: World of Warcraft (more >> than 10 million subscribers) [2]. >> >> - TCP is also getting used for media delivery. For many reasons, such as >> avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is >> substituted in many cases by IP/ TCP/ HTTP/ FLV [3]. >> >> - Another interesting scenario is satellite communication links. >> Multiplexing small packets into one packet for transmission would >> improve the efficiency. Satellite links would also find it useful to >> multiplex small TCP packets into one packet - this could be especially >> interesting for compressing TCP ACKs. >> >> >> In our recent research activities, we have adapted TCRTP scheme for its >> use when the traffic is not RTP. The idea is to substitute ECRTP by >> other compression scheme which can be used for UDP or TCP headers. In >> 2006, the IETF formed the Robust Header Compression (ROHC) working group >> which created specifications for header compression over links for RTP, >> UDP and TCP. These specifications were extended to compress headers >> over other networks. For most RTP flows, ROHC is more bandwidth >> efficient than ECRTP, at the cost of implementation complexity. It has a >> special care of context synchronization, defining some states at the >> compressor and decompressor. Once the effort for designing ROHC has been >> conducted, it is worth including it in the compressing and multiplexing >> standard. >> >> >> In a recent paper in Nov. issue of IEEE Communications Magazine, it was >> shown that 30% of bandwidth saving can be achieved for 8 FPS different >> games using IPv4. If IPv6 is used, savings can be up to 54% [4]. Another >> recent study, which is still under review, has estimated 45% bandwidth >> saving for World of Warcraft. >> >> >> After talking to other researchers, including some of the authors of >> RFC4170, the possible scheme of the proposal could be this one: >> >> >> G.711.0 payload compression TCP UDP UDP/RTP >> >> | | | | >> >> | \ | / >> >> | \ | / >> >> | nothing or ROHC or ECRTP >> >> | | >> >> \ / >> >> \ / >> >> multiplexing layer (other or PPPMUX) >> >> | >> >> | >> >> tunneling layer (other or GRE or L2TP) >> >> | >> >> | >> >> IP >> >> It should be more "open" than TCRTP. I mean, it could be "orthogonal" to >> different protocols: different header compression algorithms could be >> used, depending on the application and the scenario; also different >> multiplexing and tunneling protocols could be included. Finally, we have >> also included the G.711.0 "branch": it could be interesting to convert >> G.711 to G.711.0 (a lossless encoding of G.711) and back, using a >> similar tunneling mechanism. In a similar way to TCRTP, the G.711 to >> G.711.0 and vice versa conversion does not involve SIP/SDP/RTSP >> signaling with the endpoints, since G.711 has a fixed RTP payload number. >> >> We have not written a draft. This is only the first idea, so we look >> forward to hearing the opinion of the Working Group, >> >> >> Thank you very much, and sorry for writing such a long message, >> >> Jose Saldana >> >> University of Zaragoza >> >> ______________ >> >> [1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of First-Person >> Shooter Gaming Traffic on the Internet," Internet Computing, IEEE , >> vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL: >> http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5445069&isnum= ber=3D5562482 >> >> >> [2] P. Svoboda, W Karner and M. Rupp, "Traffic Analysis and Modeling for >> World of Warcraft," ICC '07. IEEE International Conference on >> Communications, pp.1612-1617, 24-28, Jun. 2007. URL: >> http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D4288941&isnum= ber=3D4288671 >> >> >> [3] G. Marfia and M. Roccetti, "TCP At Last: Reconsidering TCP's Role >> for Wireless Entertainment Centers at Home," IEEE Transactions on >> Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL: >> http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5681095&isnum= ber=3D5681060 >> >> >> [4] J. Saldana, J. Fern=E1ndez-Navajas, J. Ruiz-Mas, J. I. Aznar, E. >> Viruete and L. Casadesus, "First Person Shooters: Can a Smarter Network >> Save Bandwidth without Annoying the Players?," IEEE Communications >> Magazine, Consumer Communications and Networking Series, vol. 49, no. >> 11, pp. 190-198, Nov. 2011. URL: >> http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D6069728&isnum= ber=3D6069696 >> >> > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > 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 magnus.westerlund@ericsson.com Thu Jan 19 06:44:51 2012 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 234B621F85EA for ; Thu, 19 Jan 2012 06:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.72 X-Spam-Level: X-Spam-Status: No, score=-108.72 tagged_above=-999 required=5 tests=[AWL=1.879, 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 tSeJ48XG-XGC for ; Thu, 19 Jan 2012 06:44:50 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4F37C21F85C2 for ; Thu, 19 Jan 2012 06:44:50 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-98-4f182c5dd4bb Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CC.1A.23425.E5C281F4; Thu, 19 Jan 2012 15:44:46 +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; Thu, 19 Jan 2012 15:44:45 +0100 Message-ID: <4F182C52.5010706@ericsson.com> Date: Thu, 19 Jan 2012 15:44:34 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] WG last call for RTCP Extension for Third-party Loss Report (draft-ietf-avtcore-feedback-supression-rtp-09) 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, 19 Jan 2012 14:44:51 -0000 WG, This is to announce the start of a 2 week WG last call for the "RTCP Extension for Third-party Loss Report" with intended status of standards track. The WG last call ends on the 3rf of February. There is no known IPR disclosure against this draft. https://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp/?include_text=1 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 Thu Jan 19 06:48:42 2012 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 E082621F853F for ; Thu, 19 Jan 2012 06:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.355 X-Spam-Level: X-Spam-Status: No, score=-109.355 tagged_above=-999 required=5 tests=[AWL=2.044, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_75=0.6, J_CHICKENPOX_82=0.6, 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 gRo7S9cnIlnk for ; Thu, 19 Jan 2012 06:48:42 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F15EC21F854E for ; Thu, 19 Jan 2012 06:48:41 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-c0-4f182d484e44 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AD.A6.09514.84D281F4; Thu, 19 Jan 2012 15:48:41 +0100 (CET) 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; Thu, 19 Jan 2012 15:48:40 +0100 Message-ID: <4F182D48.4040804@ericsson.com> Date: Thu, 19 Jan 2012 15:48:40 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: avt@ietf.org, draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org References: <4F182C52.5010706@ericsson.com> In-Reply-To: <4F182C52.5010706@ericsson.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] WG last call for RTCP Extension for Third-party Loss Report (draft-ietf-avtcore-feedback-supression-rtp-09) 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, 19 Jan 2012 14:48:43 -0000 Hi, I have a few comments that I propose have addressed after the WG last call. I only consider two of those as having any real substance. I believe the document to ready for publication request when these issues has been addressed. And when I say addressed, I mean discussed and a way forward agreed on and that implemented if need. It may very well be to say that my opinion is rough in regards to the WG's. 1. Section 4.2: Synchronization source (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 definition is wrong. Shouldn't it be the SSRC for who's media stream the media sender is already aware of an expressed need for taking action that a PLI or FIR reqiests of this SSRC? I don't think the above is the right text for the spec, but I just trying to express what the right type of definition would be. 2. Section 5. "A new feedback value "tplr" needs to be defined for the Third Party Loss Report message to be used with Session Description Protocol (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC4585]." I do wonder, do we really need to define a new feedback value? If this already is associated either with generic NACK, with uses just "nack" or PLI which is "nack pli" or FIR which is "ccm fir" on the a=rtcp-fb line. Wouldn't it be more natural to use "nack tllei" and either "nack pslei" or "ccm pslei"? NITS N1. Section 3: When a receiver gets a Third Party Loss Report message, it should follow the rules for NACK suppression in RFC 4585 and refrain from sending a feedback request (e.g., NACK or FIR) for the missing packets reported in the message,which is dealt with in the same way as receiving NACK. and When the retransmitted packet is received by the receiver,it should take its normal behavior as if there is no current feedback suppression. Missing space after comma. N2. Section 3. 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 media source. Strange sentence. "more closer" is probably best reduced to just "closer". However, closer would benefit from a "closer to the media source than ..." N3. Section 4.1, Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" denotes the media sender of the flow for which the indicated losses are being suppressed . additional space at the end of the sentence. N4. Section 4.1. "The BLP's definition is identical to that given in [RFC4585]." I think a section reference into RFC4585 is recommended. N5. Section 4.2: FIR [RFC5104]or PLI [RFC4585]. Missing space between first ref and "or". And should shouldn't that "or" be an "and"? The message can suppress both FIR and PLI messages. N6. When using references, like in section 6.1: "In SSM RTP sessions as described in [RFC5760], ..." It would be much clearer if one included the title of the RFC before the reference, like this: In SSM RTP sessions as described in "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback" [RFC5760], ... N7. Section 6.1: "since the summary feedback does not mandate the forwarding of NACK downstream." Missing initial capital letter on Since. N8. Section 6.3: If the translator acting as quality monitor [Monarch]is aware of packet loss, it may use the SSRC of monitor as packet sender SSRC to create NACK message and send it to the receivers that is not aware of packet loss. it should be the "the monitor" and missing space after [Monarch] 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 Thu Jan 19 07:00:54 2012 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 2D13F21F8648 for ; Thu, 19 Jan 2012 07:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.182 X-Spam-Level: X-Spam-Status: No, score=-109.182 tagged_above=-999 required=5 tests=[AWL=1.417, 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 HyyGmxfWLiPF for ; Thu, 19 Jan 2012 07:00:53 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3950C21F8647 for ; Thu, 19 Jan 2012 07:00:53 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-95-4f183024b4ad Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E7.A8.09514.420381F4; Thu, 19 Jan 2012 16:00:52 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 19 Jan 2012 16:00:51 +0100 Message-ID: <4F183023.1000504@ericsson.com> Date: Thu, 19 Jan 2012 16:00:51 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: IETF AVTCore WG References: <20120109171736.13851.20033.idtracker@ietfa.amsl.com> In-Reply-To: <20120109171736.13851.20033.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.4 X-Forwarded-Message-Id: <20120109171736.13851.20033.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------070709050400050200000409" X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Fwd: 2nd Last Call: (Guidelines for the use of Variable Bit Rate Audio with Secure RTP) to Proposed Standard 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, 19 Jan 2012 15:00:54 -0000 --------------070709050400050200000409 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit WG, I just want to remind people about the ongoing second IETF last call. It ends the 23rd. So please do review the changes. A side by side diff between the version in the previous IETF last call and this one. https://tools.ietf.org/rfcdiff?url1=draft-ietf-avtcore-srtp-vbr-audio-03&difftype=--html&submit=Go!&url2=draft-ietf-avtcore-srtp-vbr-audio-04 Cheers Magnus --------------070709050400050200000409 Content-Type: message/rfc822; name="2nd Last Call: (Guidelines for the use of Variable Bit Rate Audio with Secure RTP) to Proposed Standard.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="2nd Last Call: (G"; filename*1="uidelines for the use of Variable Bit Rate Audio with Secure"; filename*2=" RTP) to Proposed Standard.eml" Received: from mailgw7.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.89) with Microsoft SMTP Server id 8.3.137.0; Mon, 9 Jan 2012 18:18:30 +0100 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F0.0E.28963.5612B0F4; Mon, 9 Jan 2012 18:18:30 +0100 (CET) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F8711E80BB; Mon, 9 Jan 2012 09:17:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94D711E80C5; Mon, 9 Jan 2012 09:17:36 -0800 (PST) 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 y6kjrFhvow-N; Mon, 9 Jan 2012 09:17:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8111E809B; Mon, 9 Jan 2012 09:17:36 -0800 (PST) From: The IESG To: IETF-Announce CC: "avt@ietf.org" Sender: "ietf-announce-bounces@ietf.org" Date: Mon, 9 Jan 2012 18:17:36 +0100 Subject: 2nd Last Call: (Guidelines for the use of Variable Bit Rate Audio with Secure RTP) to Proposed Standard Thread-Topic: 2nd Last Call: (Guidelines for the use of Variable Bit Rate Audio with Secure RTP) to Proposed Standard Thread-Index: AczO8rVGPOytlaN/QIe+yo/EjpObPA== Message-ID: <20120109171736.13851.20033.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "ietf@ietf.org" Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0197.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb30-b7c3eae000007123-f1-4f0b216518e6 x-brightmail-tracker: AAAAAA== dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326129459; bh=2ZIo2g9TOT8X0KRyngLXbpMn+FmL7KtAZYHyMWgCoe0=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=SQg5veol6qNb5oEYw7YJ2P/yk1YKc8GJs5FxENpeKnzMksPVs38IiM7M3VXaHVFKH 1eWttKhvab5KnGIHU/0zxyWiFfyUHv6eU+kap8rOC2xtU1y93B/PyGQafnqtPY5+8L ZdIA2iYlLYZp2i8Lzds12LnBfUAduRqDKqlhF1ng= errors-to: ietf-announce-bounces@ietf.org x-virus-scanned: amavisd-new at amsl.com x-mailman-version: 2.1.12 list-post: list-archive: list-id: "IETF announcement list. No discussions." x-beenthere: ietf-announce@ietf.org x-spam-level: x-spam-status: No, score=-102.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, USER_IN_WHITELIST=-100] x-spam-score: -102.185 x-spam-flag: NO delivered-to: ietf-announce@ietfa.amsl.com x-original-to: ietf-announce@ietfa.amsl.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 Proposed Standard This is a second IETF Last Call to verify the strengthening of recommendati= ons as a result of security area review during IESG evaluation, and a change of intended statu= s from BCP to Proposed Standard. 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 2012-01-23. 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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------070709050400050200000409-- From jsaldana@unizar.es Fri Jan 20 01:48:20 2012 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 A7D3E21F8576 for ; Fri, 20 Jan 2012 01:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.184 X-Spam-Level: X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 t2ThitiGc81J for ; Fri, 20 Jan 2012 01:48:16 -0800 (PST) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2B45521F85AC for ; Fri, 20 Jan 2012 01:48:14 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q0K9m51H030329 for ; Fri, 20 Jan 2012 10:48:09 +0100 From: "Jose Saldana" To: References: <002c01cccf8b$c739f5d0$55ade170$@unizar.es> <4F157F0D.1060204@ericsson.com> In-Reply-To: <4F157F0D.1060204@ericsson.com> Date: Fri, 20 Jan 2012 10:48:09 +0100 Organization: Universidad de Zaragoza Message-ID: <001f01ccd758$a061f550$e125dff0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CCD761.02265D50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKj1iJ4eaFrPsNTW53yGlPW9dhD+ALU01fmlFBWOvA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [AVTCORE] Proposal for updating TCRTP (RFC 4170) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 09:48:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0020_01CCD761.02265D50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Magnus, Although I have also sent the proposal to Internet and Transport areas, = I have been thinking about your response, and there is some reason for = considering this proposal in a real-time workgroup: multiplexing is only = interesting when the size of native packets is small, and this mainly = happens in real-time services. Let us make some calculations. We have to take into account the 1500 = bytes packet size limit. We will define bandwidth relationship as: BWR =3D Multiplexed_BW / Original_BW =3D Multiplexed_size / = Original_size (as the time of native and multiplexed packets is the = same) 1) If we consider a header of 28 bytes (IPv4/UDP) and a payload of 60 = bytes, then we can multiplex up to =E2=94=941500 / 60=E2=94=98 =E2=89=88 = 23 packets. The common header at the beginning of a multiplexed packet will be of 25 = bytes (IPv4 / L2TP / PPPMux). The compressed header for each packet would be 4 bytes. Then Multiplexed_size =3D 25 + 23*(4+60) =3D 1497 bytes And Original_size =3D 23 * (28+60) =3D 2024 bytes So BWR =3D 0.73 . We are saving 27% of bandwidth. If IPv6 is used, the = saving grows up to 39%. 2) If header size is 40 bytes (IPv4 /UDP/RTP or IPv4/TCP), we obtain an = original size of 23 * (40 + 60) =3D 2300 bytes, so BWR =3D 0.65 (35% = saving). With IPv6 it grows to 45%. 3) But on the other hand, if we consider bigger payloads of e.g. 250 = bytes, multiplexing is not interesting: We can multiplex 5 packets, so: Multiplexed_size =3D 25 + 5*(4+250) =3D1295 Original_size =3D 5*(40+250)=3D1450 So BWR =3D 0.89. We are saving 11% of bandwidth. With IPv6 it is 15%. _______________ As a conclusion, we see that multiplexing is only interesting for (very) = small packets. I think the typical applications that use these packets = are VoIP, FPS games, MMORPG games. I do not know if there are some = others using tiny packets while not being real-time. Please consider this argument and tell me your opinion. I have not yet = received any response from Internet and Transport areas. Thank you for your attention, Jose Saldana -----Mensaje original----- De: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Enviado el: martes, 17 de enero de 2012 15:01 Para: jsaldana@unizar.es CC: avt@ietf.org Asunto: Re: [AVTCORE] Proposal for updating TCRTP (RFC 4170) Hi, As you are proposing to go towards a more generic scheme I don't think = this proposal really belongs in the WG, most likely not this area even. I think this is a topic that primarily are related to Intarea and = Transport. Intarea as the owner of the tunneling work in IETF and = Transport as the actual aggregation and header compression is primarily = transport topics. A question I would have is where this type of mechanism would make = sense. Where do you have scarce bandwidth capacity and are willing to = pay the downsides of the ingress egress complexities and the impact on = the traffic in regards to additional delay. Cheers Magnus On 2012-01-10 12:34, jsaldana@unizar.es wrote: > Hello all. >=20 > My name is Jose Saldana, from the University of Zaragoza, in Spain. I=20 > am new here. >=20 > I would like to share with AVTCORE Work Group a proposal, in case it=20 > could be considered interesting. The main idea is to update TCRTP.=20 > This is a "Best current practice" RFC > (http://datatracker.ietf.org/doc/rfc4170/) which was developed in=20 > Audio/Video Transport working group in 2005-11. It "describes a method = > to improve the bandwidth utilization of RTP streams over network paths = > that carry multiple Real-time Transport Protocol (RTP) streams in=20 > parallel between two endpoints, as in voice trunking. The method=20 > combines standard protocols that provide compression, multiplexing,=20 > and tunneling over a network path for the purpose of reducing the=20 > bandwidth used when multiple RTP streams are carried over that path."=20 > (from the introduction of RFC4170). >=20 >=20 > The scheme of TCRTP is: >=20 > RTP/UDP/IP >=20 > | >=20 > | >=20 > ECRTP (compressing layer). Compresses RTP/UDP/IP headers >=20 > | >=20 > | =20 >=20 > PPPMux (multiplexing layer). Includes a number of compressed=20 > packets into a bigger one >=20 > | >=20 > | >=20 > L2TP (tunneling layer). Permits its use end-to-end >=20 > | >=20 > | >=20 > IP >=20 > However, there exist many real-time flows that do not use RTP: >=20 > - Online "First Person Shooter" (FPS) games use UDP datagrams, and=20 > they are one of the most "real-time" applications nowadays. Some = examples: > Counter Strike, Halo, Quake, etc.[1]. >=20 > - Online "Massively Multiplayer Online Role Playing Games" (MMORPG): > They use TCP, but can be considered "real-time", since the actions of=20 > the players have to be transmitted very quickly to the server. It=20 > should be taken into account that player vs player fights are one of=20 > the possible activities of the game. Some examples: World of Warcraft=20 > (more than 10 million subscribers) [2]. >=20 > - TCP is also getting used for media delivery. For many reasons, such=20 > as avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is=20 > substituted in many cases by IP/ TCP/ HTTP/ FLV [3]. >=20 > - Another interesting scenario is satellite communication links. > Multiplexing small packets into one packet for transmission would=20 > improve the efficiency. Satellite links would also find it useful to=20 > multiplex small TCP packets into one packet =E2=80=93 this could be = especially=20 > interesting for compressing TCP ACKs. >=20 >=20 > In our recent research activities, we have adapted TCRTP scheme for=20 > its use when the traffic is not RTP. The idea is to substitute ECRTP=20 > by other compression scheme which can be used for UDP or TCP headers.=20 > In 2006, the IETF formed the Robust Header Compression (ROHC) working=20 > group which created specifications for header compression over links=20 > for RTP, UDP and TCP. These specifications were extended to compress=20 > headers over other networks. For most RTP flows, ROHC is more=20 > bandwidth efficient than ECRTP, at the cost of implementation=20 > complexity. It has a special care of context synchronization, defining = > some states at the compressor and decompressor. Once the effort for=20 > designing ROHC has been conducted, it is worth including it in the=20 > compressing and multiplexing standard. >=20 >=20 > In a recent paper in Nov. issue of IEEE Communications Magazine, it=20 > was shown that 30% of bandwidth saving can be achieved for 8 FPS=20 > different games using IPv4. If IPv6 is used, savings can be up to 54%=20 > [4]. Another recent study, which is still under review, has estimated=20 > 45% bandwidth saving for World of Warcraft. >=20 >=20 > After talking to other researchers, including some of the authors of=20 > RFC4170, the possible scheme of the proposal could be this one: >=20 >=20 > G.711.0 payload compression TCP UDP UDP/RTP >=20 > | | | | >=20 > | \ | / >=20 > | \ | / >=20 > | nothing or ROHC or ECRTP >=20 > | | >=20 > \ / >=20 > \ / >=20 > multiplexing layer (other or PPPMUX) >=20 > | >=20 > | >=20 > tunneling layer (other or GRE or L2TP) >=20 > | >=20 > | >=20 > IP >=20 > It should be more "open" than TCRTP. I mean, it could be "orthogonal"=20 > to different protocols: different header compression algorithms could=20 > be used, depending on the application and the scenario; also different = > multiplexing and tunneling protocols could be included. Finally, we=20 > have also included the G.711.0 "branch": it could be interesting to=20 > convert > G.711 to G.711.0 (a lossless encoding of G.711) and back, using a=20 > similar tunneling mechanism. In a similar way to TCRTP, the G.711 to > G.711.0 and vice versa conversion does not involve SIP/SDP/RTSP=20 > signaling with the endpoints, since G.711 has a fixed RTP payload = number. >=20 > We have not written a draft. This is only the first idea, so we look=20 > forward to hearing the opinion of the Working Group, >=20 >=20 > Thank you very much, and sorry for writing such a long message, >=20 > Jose Saldana >=20 > University of Zaragoza >=20 > ______________ >=20 > [1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of=20 > First-Person Shooter Gaming Traffic on the Internet," Internet=20 > Computing, IEEE , vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL: > = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5445069&isnum= b > er=3D5562482=20 > = ber=3D5562482> >=20 > [2] P. Svoboda, W Karner and M. Rupp, =E2=80=9CTraffic Analysis and = Modeling=20 > for World of Warcraft,=E2=80=9D ICC '07. IEEE International Conference = on=20 > Communications, pp.1612-1617, 24-28, Jun. 2007. URL: > = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D4288941&isnum= b > er=3D4288671=20 > = ber=3D4288671> >=20 > [3] G. Marfia and M. Roccetti, =E2=80=9CTCP At Last: Reconsidering = TCP=E2=80=99s Role=20 > for Wireless Entertainment Centers at Home,=E2=80=9D IEEE Transactions = on=20 > Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL: > = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5681095&isnum= b > er=3D5681060=20 > = ber=3D5681060> >=20 > [4] J. Saldana, J. Fern=C3=A1ndez-Navajas, J. Ruiz-Mas, J. I. Aznar, = E. > Viruete and L. Casadesus, =E2=80=9CFirst Person Shooters: Can a = Smarter=20 > Network Save Bandwidth without Annoying the Players?,=E2=80=9D IEEE=20 > Communications Magazine, Consumer Communications and Networking = Series, vol. 49, no. > 11, pp. 190-198, Nov. 2011. URL: > = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D6069728&isnum= b > er=3D6069696=20 > = ber=3D6069696> >=20 --=20 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- ------=_NextPart_000_0020_01CCD761.02265D50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: [AVTCORE] Proposal for updating TCRTP (RFC 4170)

Magnus,

Although I have also sent the proposal to Internet and = Transport areas, I have been thinking = about your response, and = there is some reason for considering this = proposal in a real-time workgroup: multiplexing = is only interesting when the size of native packets is small, and this = mainly happens in real-time services.

Let us make = some calculations. We have to take into account = the 1500 bytes packet size limit. We will define bandwidth = relationship as:

BWR =3D Multiplexed_BW = / Original_BW =3D Multiplexed_size / = Original_size (as the time of native and = multiplexed packets is the same)

1) If we consider a header of 28 = bytes (IPv4/UDP) and a payload of 60 bytes, then we can = multiplex up to =E2=94=941500 = / 60=E2=94=98 =E2=89=88 23 = packets.

The common = header at the beginning of a multiplexed packet will be of 25 bytes = (IPv4 / L2TP / PPPMux).

The compressed = header for each packet would be 4 bytes.

Then Multiplexed_size = =3D  25 = + 23*(4+60) =3D 1497 = bytes

And = Original_size =3D 23 * (28+60) = =3D 2024 bytes

So BWR =3D = 0.73 . We are saving = 27% of bandwidth. If IPv6 = is used, the saving grows up to 39%.

2) If header size is 40 bytes = (IPv4 /UDP/RTP or IPv4/TCP), we obtain an original size of 23 * (40 + 60) = =3D 2300 bytes, so BWR =3D 0.65 (35% = saving). With IPv6 it grows to 45%.


3) But on the other hand, if we = consider bigger payloads of e.g. 250 = bytes, multiplexing is not interesting:

We can = multiplex 5 packets, so:

Multiplexed_size =3D 25 + 5*(4+250) = =3D1295

Original_size = =3D 5*(40+250)=3D1450

So BWR =3D = 0.89. We are saving 11% of bandwidth. With = IPv6 it is 15%.

_______________

As a = conclusion, we see that multiplexing is only = interesting for (very) small = packets. I think the typical applications that use these = packets are VoIP, FPS games, MMORPG games. I do not know if there are = some others using tiny packets while not being = real-time.

Please consider = this argument and tell me your opinion. I have = not yet received any response from = Internet and Transport areas.

Thank you for = your attention,

Jose = Saldana

-----Mensaje original-----
De: Magnus Westerlund [mailto:magnus.westerlund@e= ricsson.com]
Enviado el: martes, 17 de enero de 2012 = 15:01
Para: jsaldana@unizar.es
CC: avt@ietf.org
Asunto: Re: [AVTCORE] Proposal for updating TCRTP (RFC = 4170)

Hi,

As you are = proposing to go towards a more generic scheme I don't think this = proposal really belongs in the WG, most likely not this area = even.

I think this is a = topic that primarily are related to Intarea and Transport. Intarea as = the owner of the tunneling work in IETF and Transport as the actual = aggregation and header compression is primarily transport = topics.

A question I would = have is where this type of mechanism would make sense. Where do you have = scarce bandwidth capacity and are willing to pay the downsides of the = ingress egress complexities and the impact on the traffic in regards to = additional delay.

Cheers

Magnus


On 2012-01-10 = 12:34, jsaldana@unizar.es = wrote:

> Hello = all.

> =

> My name is = Jose Saldana, from the University of Zaragoza, in Spain. I =

> am new = here.

> =

> I would like = to share with AVTCORE Work Group a proposal, in case it =

> could be = considered interesting. The main idea is to update TCRTP. =

> This is a = "Best current practice" RFC

> = (http://datatracker.ietf.org/doc/rfc4170/) = which was developed in

> Audio/Video = Transport working group in 2005-11. It "describes a method =

> to improve = the bandwidth utilization of RTP streams over network paths =

> that carry = multiple Real-time Transport Protocol (RTP) streams in =

> parallel = between two endpoints, as in voice trunking. The method =

> combines = standard protocols that provide compression, multiplexing, =

> and tunneling = over a network path for the purpose of reducing the

> bandwidth = used when multiple RTP streams are carried over that path." =

> (from the = introduction of RFC4170).

> =

> =

> The scheme of = TCRTP is:

> =

>   = RTP/UDP/IP

> =

>      |

> =

>      |

> =

>    ECRTP (compressing layer). = Compresses RTP/UDP/IP headers

> =

>      |

> =

>      = |            =       

> =

>     PPPMux (multiplexing = layer). Includes a number of compressed

> packets into = a bigger one

> =

>      |

> =

>      |

> =

>    L2TP     = (tunneling layer). Permits its use end-to-end

> =

>      |

> =

>      |

> =

>      IP

> =

> However, = there exist many real-time flows that do not use RTP:

> =

> - Online = "First Person Shooter" (FPS) games use UDP datagrams, and =

> they are one = of the most "real-time" applications nowadays. Some = examples:

> Counter = Strike, Halo, Quake, etc.[1].

> =

> - Online = "Massively Multiplayer Online Role Playing Games" = (MMORPG):

> They use TCP, = but can be considered "real-time", since the actions of =

> the players = have to be transmitted very quickly to the server. It

> should be = taken into account that player vs player fights are one of =

> the possible = activities of the game. Some examples: World of Warcraft =

> (more than 10 = million subscribers) [2].

> =

> - TCP is also = getting used for media delivery. For many reasons, such =

> as avoiding = firewalls, the standard IP/ UDP/ RTP protocol stack is =

> substituted = in many cases by IP/ TCP/ HTTP/ FLV [3].

> =

> - Another = interesting scenario is satellite communication links.

> Multiplexing = small packets into one packet for transmission would

> improve the = efficiency. Satellite links would also find it useful to =

> multiplex = small TCP packets into one packet =E2=80=93 this could be especially =

> interesting = for compressing TCP ACKs.

> =

> =

> In our recent = research activities, we have adapted TCRTP scheme for

> its use when = the traffic is not RTP. The idea is to substitute ECRTP =

> by other = compression scheme which can be used for UDP or TCP headers. =

> In 2006, the = IETF formed the Robust Header Compression (ROHC) working =

> group which = created specifications for header compression over links =

> for RTP, UDP = and TCP.  These specifications were extended to compress =

> headers over = other networks. For most RTP flows, ROHC is more

> bandwidth = efficient than ECRTP, at the cost of implementation

> complexity. = It has a special care of context synchronization, defining =

> some states = at the compressor and decompressor. Once the effort for =

> designing = ROHC has been conducted, it is worth including it in the =

> compressing = and multiplexing standard.

> =

> =

> In a recent = paper in Nov. issue of IEEE Communications Magazine, it =

> was shown = that 30% of bandwidth saving can be achieved for 8 FPS =

> different = games using IPv4. If IPv6 is used, savings can be up to 54% =

> [4]. Another = recent study, which is still under review, has estimated =

> 45% bandwidth = saving for World of Warcraft.

> =

> =

> After talking = to other researchers, including some of the authors of =

> RFC4170, the = possible scheme of the proposal could be this one:

> =

> =

> G.711.0 = payload compression        = TCP     UDP   UDP/RTP

> =

>        &nbs= p;         = |            =         = |      |      = |

> =

>        &nbs= p;         = |            =          = \     |     /

> =

>        &nbs= p;         = |            =            = \   |   /

> =

>        &nbs= p;         = |            =    nothing or ROHC or ECRTP

> =

>        &nbs= p;         = |            =             &= nbsp;  |

> =

>        &nbs= p;          = \            =              = /

> =

>        &nbs= p;            = \            =          /

> =

>        &nbs= p;        multiplexing layer (other = or PPPMUX)

> =

>        &nbs= p;            = ;       |

> =

>        &nbs= p;            = ;       |

> =

>        &nbs= p;       tunneling layer (other or GRE or = L2TP)

> =

>        &nbs= p;            = ;       |

> =

>        &nbs= p;            = ;       |

> =

>        &nbs= p;            = ;      IP

> =

> It should be = more "open" than TCRTP. I mean, it could be = "orthogonal"

> to different = protocols: different header compression algorithms could =

> be used, = depending on the application and the scenario; also different =

> multiplexing = and tunneling protocols could be included. Finally, we =

> have also = included the G.711.0 "branch": it could be interesting to =

> = convert

> G.711 to = G.711.0 (a lossless encoding of G.711) and back, using a =

> similar = tunneling mechanism. In a similar way to TCRTP, the G.711 = to

> G.711.0 and = vice versa conversion does not involve SIP/SDP/RTSP

> signaling = with the endpoints, since G.711 has a fixed RTP payload = number.

> =

> We have not = written a draft. This is only the first idea, so we look =

> forward to = hearing the opinion of the Working Group,

> =

> =

> Thank you = very much, and sorry for writing such a long message,

> =

> Jose = Saldana

> =

> University of = Zaragoza

> =

> = ______________

> =

> [1] Ratti, = S.; Hariri, B.; Shirmohammadi, S., "A Survey of

> First-Person = Shooter Gaming Traffic on the Internet," Internet =

> Computing, = IEEE , vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL:

> http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arn= umber=3D5445069&isnumb

> er=3D5562482 =

> = <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D54450= 69&isnum

> = ber=3D5562482>

> =

> [2] P. = Svoboda, W Karner and M. Rupp, =E2=80=9CTraffic Analysis and Modeling =

> for World of = Warcraft,=E2=80=9D ICC '07. IEEE International Conference on =

> = Communications, pp.1612-1617, 24-28, Jun. 2007. URL:

> http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arn= umber=3D4288941&isnumb

> er=3D4288671 =

> = <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D42889= 41&isnum

> = ber=3D4288671>

> =

> [3] G. Marfia = and M. Roccetti, =E2=80=9CTCP At Last: Reconsidering TCP=E2=80=99s Role =

> for Wireless = Entertainment Centers at Home,=E2=80=9D IEEE Transactions on =

> Consumer = Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. = URL:

> http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arn= umber=3D5681095&isnumb

> er=3D5681060 =

> = <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D56810= 95&isnum

> = ber=3D5681060>

> =

> [4] J. = Saldana, J. Fern=C3=A1ndez-Navajas, J. Ruiz-Mas, J. I. Aznar, = E.

> Viruete = and  L. Casadesus, =E2=80=9CFirst Person Shooters: Can a Smarter =

> Network Save = Bandwidth without Annoying the Players?,=E2=80=9D IEEE =

> = Communications Magazine, Consumer Communications and Networking Series, = vol. 49, no.

> 11, pp. = 190-198, Nov. 2011. URL:

> http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arn= umber=3D6069728&isnumb

> er=3D6069696 =

> = <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D60697= 28&isnum

> = ber=3D6069696>

> =


-- =

Magnus = Westerlund

--------------------------------------------------------= --------------

Multimedia = Technologies, Ericsson Research EAB/TVM

--------------------------------------------------------= --------------

Ericsson = AB            = ;    | Phone  +46 10 7148287

F=C3=A4r=C3=B6gatan = 6            =     | Mobile +46 73 0949079

SE-164 80 = Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com

--------------------------------------------------------= --------------

------=_NextPart_000_0020_01CCD761.02265D50-- From magnus.westerlund@ericsson.com Fri Jan 20 02:15:55 2012 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 34DCD21F864E for ; Fri, 20 Jan 2012 02:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.024 X-Spam-Level: X-Spam-Status: No, score=-109.024 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, 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 9RcDebOxkpvH for ; Fri, 20 Jan 2012 02:15:54 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1B73321F8648 for ; Fri, 20 Jan 2012 02:15:53 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-d9-4f193ed81948 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 94.1F.09514.8DE391F4; Fri, 20 Jan 2012 11:15:53 +0100 (CET) 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; Fri, 20 Jan 2012 11:15:52 +0100 Message-ID: <4F193ED6.8090301@ericsson.com> Date: Fri, 20 Jan 2012 11:15:50 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "jsaldana@unizar.es" References: <002c01cccf8b$c739f5d0$55ade170$@unizar.es> <4F157F0D.1060204@ericsson.com> <001f01ccd758$a061f550$e125dff0$@unizar.es> In-Reply-To: <001f01ccd758$a061f550$e125dff0$@unizar.es> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Proposal for updating TCRTP (RFC 4170) 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, 20 Jan 2012 10:15:55 -0000 Jose, Yes, I fully agree with your conclusions that to get substantial benefit from an mechanism that aggregates and compresses headers you need to operate on small packets. The reason I am pushing back on this WG being the right place for discussion is the fact that you focus on packet streams that aren't RTP. This WG is chartered for the core extensions and maintenance of RTP. Based on that we are clearly the right place for RTP related discussion. However, my understanding of the goal is to generalize the mechanism to handle flows that uses other protocols that RTP in addition to RTP. Thus I think the generalized goal is the most important aspect of the work. When you want input on RTP related aspects then is when this WG really should be involved. Sending this WG an occasional pointer to where discussion happens is fine, but I think you do need to find another place to discuss details on this. Cheers Magnus On 2012-01-20 10:48, Jose Saldana wrote: > Magnus, > > Although I havealsosent the proposal to Internet and Transport areas,I > have been thinking aboutyour response, and there is some reason for > consideringthis proposalinareal-time workgroup: multiplexing is only > interesting when the size of native packets is small, and this mainly > happens in real-time services. > > Let us make some calculations.We have to take into account the1500 > bytespacket sizelimit.We willdefinebandwidth relationshipas: > > BWR =Multiplexed_BW /Original_BW= Multiplexed_size / Original_size(as > the time of native and multiplexed packets is the same) > > 1)If we consider a header of 28 bytes (IPv4/UDP) and a payload of60 > bytes, thenwe can multiplex up to└1500 /60┘≈23packets. > > The common header at the beginning of a multiplexed packet will be of 25 > bytes (IPv4 / L2TP / PPPMux). > > The compressed header for each packet would be 4 bytes. > > ThenMultiplexed_size = 25 +23*(4+60)=1497bytes > > And Original_size =23* (28+60) =2024bytes > > So BWR = 0.73. We are saving 27% of bandwidth. If IPv6 is used, the > saving grows up to 39%. > > 2)If header size is 40 bytes (IPv4/UDP/RTP orIPv4/TCP), we obtain an > original size of 23 * (40 + 60) =2300 bytes, so BWR = 0.65 (35% saving). > With IPv6 it grows to45%. > > > 3)But on the other hand, if we consider bigger payloads of e.g.250 > bytes, multiplexing is not interesting: > > We can multiplex 5 packets, so: > > Multiplexed_size = 25 + 5*(4+250) =1295 > > Original_size = 5*(40+250)=1450 > > So BWR = 0.89. We are saving 11% of bandwidth.With IPv6 it is 15%. > > _______________ > > As a conclusion, we see thatmultiplexingis only interesting > for(very)small packets. I think the typical applications that use these > packets are VoIP, FPS games, MMORPG games. I do not know if there are > some others using tiny packetswhilenot being real-time. > > Please consider this argument and tell me your opinion.I have > notyetreceived any response from Internet and Transport areas. > -- 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 tom.van_caenegem@alcatel-lucent.com Fri Jan 20 07:48:16 2012 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 B4CE121F8631 for ; Fri, 20 Jan 2012 07:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.809 X-Spam-Level: X-Spam-Status: No, score=-7.809 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_75=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 HBb1B1cIZ1C7 for ; Fri, 20 Jan 2012 07:48:15 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCD221F8619 for ; Fri, 20 Jan 2012 07:48:15 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q0KFlvoZ010334 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 20 Jan 2012 16:48:11 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 20 Jan 2012 16:48:06 +0100 From: "Van Caenegem, Tom (Tom)" To: Magnus Westerlund , IETF AVTCore WG Date: Fri, 20 Jan 2012 16:48:03 +0100 Thread-Topic: [AVTCORE] WG last call for RTCP Extension for Third-party Loss Report (draft-ietf-avtcore-feedback-supression-rtp-09) Thread-Index: AczWuPS0iFmv5kFmSpmsocmVJwvLZgA0UR9w Message-ID: References: <4F182C52.5010706@ericsson.com> In-Reply-To: <4F182C52.5010706@ericsson.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, 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.83 Subject: Re: [AVTCORE] WG last call for RTCP Extension for Third-party Loss Report (draft-ietf-avtcore-feedback-supression-rtp-09) 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, 20 Jan 2012 15:48:16 -0000 Hi Qin, Magnus, I have reviewed once more the draft, and these are my comments/questions... Thx Tom 1)section 1 There are cases where multiple receivers may initiate the same, or an equivalent message towards the same media source. Suggest to have : There are cases where multiple receivers may initiate the same, or an equivalent message towards the same media source or same= feedback target. 2)section 1 One common cause of such a feedback storm is receivers utilizing RTP retransmission [RFC4588] as a packet loss recovery technique, sending feedback using RTCP NACK messages [RFC4585] without proper dithering of the retransmission requests (e.g., not implementing the RFC 4585 dithering rules or sending NACKs to a middlebox that doesn't redistribute them to other receivers). Suggest to reposition the ")" and use "feedback target" iso "middlebox" (= aligned with the vocabulary in the abstract) and add additional clarificat= ion: One common cause of such a feedback storm is receivers utilizing RTP retransmission [RFC4588] as a packet loss recovery technique, sending feedback using RTCP NACK messages [RFC4585] without proper dithering of the retransmission requests (e.g., not implementing the RFC 4585 dithering rules) or sending NACKs to a feedback target that doesn't redistribute them to oth= er receivers and where as a consequence the required feedback suppression b= ehaviour of RTP receivers conforming to RFC 4588 is not activated. 3)section 1=20 RTCP feedback storms may cause short term overload, and in extreme cases to pose a possible risk of increasing network congestion on the control channel (e.g. RTCP feedback), the data channel, or both. It is therefore desirable to provide a way of suppressing unneeded feedback. I think this paragraph has some issues:-can you give an example on where la= ck of RTCP FB suppression message increases data channel congestion-"it is = therefore desirable to (..) suppressing unneeded feedbackWhat is meant with= "unneeded" feedback?.. from a receiver point of view, the feedback mechani= sm is desiredas it wants to inform it is missing a packet (and requesting a= retransmission). From the retransmission server point of view, this feedba= ck is also desired as it wants to know who is missing a packet so it can fo= llow-up with a retransmission.So, instead, just state: "It is therefore des= irable to provide a way of suppressing feedback". I think it would be bette= r to highlight that feedback suppression has the obvious effect that the re= ceiver may not receive -in time- a retransmission, (but further disusison i= s outside the scope of this document), so it would be good to add:"Such ded= icated feedback suppression has as consequence that the receiver can be (te= mporarily) deprived from its repair service"=20 4) I still feel uncomfortbale with the paragraph: "One approach to this, suggested in [DVB-IPTV], involves sending a NACK message to the other clients (or receiver) in the same group as the sender of NACK. However NACK is defined as a receiver report sent from a receiver observing a packet loss, therefore it only inform others that sender of NACK detected loss while the case where the sender of the feedback has received reports that the indicated packets were lost is not covered. This document specifies a new third-party loss report for this function. It supplements the existing the use of RTCP NACK packet and further is more precise in the uses where the network is active to suppress feedback." I suggest to delete this as it is more elaborated upon in the retransmissio= n-for-ssm draft (which reflects the same topology as addressed by DVB) 5) section 3 The Third Party Loss Report (TPLR) message is generated by a RTP system that may not seen the actual packet loss. It is sent following the same timing rule as sending NACK defined in [RFC4585].=20 Q: what is RTP system? Can it be an RTP receiver? Q: would be good to add a section reference to RFC 4588 wrt the timing rule 6) section 3 "RTP Systems in the network that receive a Third Party Loss Report SHOULD NOT send their own additional Third Party Loss Report messages for the same packet sequence numbers. They should simply forward the Third Party Loss Report message received from upstream direction, additionally, they may generate their own Third Party Loss Report that.." Q: forward to whom? 7) section 3, editorial (I think!); When a receiver gets a Third Party Loss Report message, it should follow the rules for NACK suppression in RFC 4585 and refrain from sending a feedback request (e.g., NACK or FIR) for the missing packets reported in the message,which is dealt with in the same way as receiving NACK. Suggest to delete ",which is dealt with in the same way as receiving NACK.", as being redundant... 8) section 3 "To increase the robustness to the loss of a TPLR or of a transmission RTP data packet, TPLR or the RTP packet for the same missing Packet may be retransmitted when RTP systems are aware that the same packet loss occurs again. If the additional TPLR arrives at receiver, the receiver should deal with the additional TPLR in the same way as receiving the first TPLR for the same packet and no additional behavior for receiver is required. When the retransmitted packet is received by the receiver,it should take its normal behavior as if there is no current feedback suppression." A couple of items here: -do you mean "..of a REtransmission RTP data packet"? Not sure why you lin= k multiple transmissions of TPLR with multiple transmissions of a retransmi= ssion packet? -" when RTP systems are aware that the same packet loss occurs again"=20 Do you mean the loss of the TPLR message?-the sentence is anyhow strange be= cause when you start the sentence as you did (to increase the robustness..)= , isn't there a silent assumption that the RTP "system" is NO aware that th= e packet loss occurs again?=20 -"When the retransmitted packet is received by the receiver,it should take its normal behavior as if there is no current feedback suppression." Feedback suppression is based/defined on a per packet basis or group of pac= kets' basis (as announced in the TPLR).. so if a (retransmission) packet is= received by RTP receiver, there is no longer a need to send feedback ( a N= ACK) by the receiver... So what is the normal behaviour here? 9) section 3: "Since Third Party Loss Report interacts strongly with repair timing, it has to work together with feedback to not adversely impact the repair of lost source packets. 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 media source. When the loss was detected and repair initiated much closer to the media 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." This paragraph is quite problematic for me.. you cannot really make stateme= nts on proximity of systems without topology considerations.. -what do you mean with TPL reports must work together with feedback? It sup= resses feedback!=20 -what does "incur a lot of NACK requests" mean ? -I do not understand how an RTP system sending TPLR operating in proximity = to the media source can help here.. as the RTP system sending the TPL needs= to wait for a NACK ..from a receiver, before sending a TPLR, this will not= really help. =20 -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnu= s Westerlund Sent: donderdag 19 januari 2012 15:45 To: IETF AVTCore WG Subject: [AVTCORE] WG last call for RTCP Extension for Third-party Loss Rep= ort (draft-ietf-avtcore-feedback-supression-rtp-09) WG, This is to announce the start of a 2 week WG last call for the "RTCP Extens= ion for Third-party Loss Report" with intended status of standards track. The WG last call ends on the 3rf o= f February. There is no known IPR disclosure against this draft. https://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp= /?include_text=3D1 Cheers Magnus Westerlund ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From ron.even.tlv@gmail.com Tue Jan 24 01:47:23 2012 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 C668C21F8537 for ; Tue, 24 Jan 2012 01:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=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 queW9PG1EV5e for ; Tue, 24 Jan 2012 01:47:23 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C392F21F8597 for ; Tue, 24 Jan 2012 01:47:22 -0800 (PST) Received: by eaai13 with SMTP id i13so1677846eaa.31 for ; Tue, 24 Jan 2012 01:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=pAC9riGuNynK0ChHGLuHYb9DamBTQFKaMxG4EcLp15o=; b=PppOjQuYPesSgtJ+P6UGwI3/O2DlwRPw9GBPzMBJE1DDz9eJVyKyudV+Uru4hSRSPu FuV6DGDJAwkiNBhyyarecyZLkXy2/jf60tAQOYJi0uYvAmyYhQTSg0LVul+ksfWhQ/i+ FOSe0bKi86Ks4jNG5A66iejltrZoxtUHa03FA= Received: by 10.213.34.73 with SMTP id k9mr268240ebd.83.1327398440981; Tue, 24 Jan 2012 01:47:20 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id n17sm65550238eei.3.2012.01.24.01.47.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jan 2012 01:47:20 -0800 (PST) From: "Roni Even" To: Date: Tue, 24 Jan 2012 11:43:34 +0200 Message-ID: <4f1e7e28.11840e0a.5332.5178@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczZ5rhYJCBqmo1vRaCfF/ps/EzATQAlalHQ Content-Language: en-us Subject: [AVTCORE] FW: [dispatch] Media Stream related signaling 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, 24 Jan 2012 09:47:23 -0000 Hi, I would like to draw your attention to this email that was sent to = DISPATCH mailing list. Please send any comments to dispatch in order to minimize duplication Thanks Roni Even AVTcor co-chair -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Bo Burman Sent: Monday, January 23, 2012 5:50 PM To: dispatch@ietf.org Subject: [dispatch] Media Stream related signaling Dispatch, We have requested agenda time for the upcoming meeting to discuss the subject of Media Stream related signaling. From the feedback we got in AVTEXT WG on the discussion for a certain problem, the one related to pausing and resuming sender to middlebox media traffic, it is clear that = a more high level discussion needs to happen. We have two Internet drafts related to the issues we would like to = discuss. Media Stream Selection (MESS) - draft-westerlund-dispatch-stream-selection-00 RTP Media Stream Pause and Resume - draft-westerlund-avtext-rtp-stream-pause-00 The first one (MESS) proposes that for the general selection of media streams, an end-point within a centralized conferencing scenario desires = to receive a media plane oriented rather than RTP/RTCP based signaling, = which appears to have benefits as discussed in the draft. As mentioned, the pause resume draft is targeted for a different use = case where a media plane solution has potential for other benefits. This was discussed and the main outcome of that discussion was three quite = different opinions; a) We already do this signaling using TMMBR (RFC 5104) by setting the bit-rate value to 0, which the current specs doesn't allow. b) This should be done in signalling plane, RTP/RTCP shouldn't be = bloated. (But I did interpret this as not necessarily needing to be SIP). c) When it comes to pause/resume, unless it is done using SIP/SDP it = will not work through any Session Border Gateway as the session will be torn = down after n seconds. Thus I think it important that we take a discussion around the use = cases, existing solutions, limitations in those or the proposal to try to = determine what is the most reasonable way of solving the problems and how to = enable; 1) Receiver based selection of media streams from a larger set of = streams, including different quality levels like video resolutions, in a = centralized conferencing application. 2) Optimize the transport so that media streams currently not used can = be turned off temporarily and then quickly resumed when someone determines = a need for the media stream. For example using mechanism (1) but also for voice activity based, centrally controlled or other mechanisms to select which media streams are delivered to other session participants. We are working to revise our Internet drafts. We seek as much input as possible into this prior to the meeting so that we can ensure that any discussion are as on topic and focused as possible. Regards Bo Burman & Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden| mailto: bo.burman at ericsson.com ---------------------------------------------------------------------- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From iesg-secretary@ietf.org Tue Jan 24 13:05:37 2012 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 C067B1F0C3D; Tue, 24 Jan 2012 13:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 UCSHhWnnUx7b; Tue, 24 Jan 2012 13:05:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A5221F8603; Tue, 24 Jan 2012 13:05:36 -0800 (PST) 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.64p1 Message-ID: <20120124210536.17982.26823.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2012 13:05:36 -0800 Cc: avtcore chair , avtcore mailing list , RFC Editor Subject: [AVTCORE] Protocol Action: 'Guidelines for the use of Variable Bit Rate Audio with Secure RTP' to Proposed Standard (draft-ietf-avtcore-srtp-vbr-audio-04.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, 24 Jan 2012 21:05:38 -0000 The IESG has approved the following document: - 'Guidelines for the use of Variable Bit Rate Audio with Secure RTP' (draft-ietf-avtcore-srtp-vbr-audio-04.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-vbr-audio/ Technical Summary This memo discusses potential security issues that arise when using variable bit rate audio with the secure RTP profile. When using SRTP with voice streams compressed using variable bit rate (VBR) codecs, the length of the compressed packets will depend on the characteristics of the speech signal. This variation in packet size will leak a small amount of information about the contents of the speech signal. Guidelines to mitigate these issues are suggested. Working Group Summary There was early on significant debate on how big a security issue this problem really was. But it was agreed on the need to document the issue and how the issue can be mitigated. Since then there has been good consensus on the document. Document Quality This document has gotten reasonable review from people with both RTP and Security focus. The quality of the document is good. Additional input from the security area during IESG review strengthened some of the recommendations which were re-reviewed with a second IETF LC. Personnel Robert Sparks is the responsible AD. Magnus Westerlund is the document shepherd. RFC Editor Note (valid for version -04) Please change the Intended Status in the header to Proposed Standard From bill.wu@huawei.com Mon Jan 30 01:04:56 2012 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 125F521F861D for ; Mon, 30 Jan 2012 01:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_75=0.6, J_CHICKENPOX_82=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 BfsAzDOWzc2E for ; Mon, 30 Jan 2012 01:04:55 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id F333F21F861B for ; Mon, 30 Jan 2012 01:04:54 -0800 (PST) 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 <0LYL00G5YT6EO8@szxga04-in.huawei.com> for avt@ietf.org; Mon, 30 Jan 2012 17:03:50 +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 <0LYL00M2KT693E@szxga04-in.huawei.com> for avt@ietf.org; Mon, 30 Jan 2012 17:03:50 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGP74618; Mon, 30 Jan 2012 17:03:48 +0800 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jan 2012 17:03:28 +0800 Received: from w53375q (10.138.41.130) by szxeml420-hub.china.huawei.com (10.82.67.159) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jan 2012 17:03:44 +0800 Date: Mon, 30 Jan 2012 17:03:43 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Magnus Westerlund , avt@ietf.org, draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org Message-id: <3374650BFFC7477E8B48193E1976DA4D@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: <4F182C52.5010706@ericsson.com> <4F182D48.4040804@ericsson.com> Subject: Re: [AVTCORE] WG last call for RTCP Extension for Third-party Loss Report (draft-ietf-avtcore-feedback-supression-rtp-09) 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, 30 Jan 2012 09:04:56 -0000 SGksIE1hZ251czoNClRoYW5rIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLCBwbGVhc2Ugc2Vl IG15IHJlcGxpZXMgaW5saW5lIGJlbG93Lg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJNYWdudXMgV2VzdGVybHVuZCIgPG1hZ251cy53ZXN0 ZXJsdW5kQGVyaWNzc29uLmNvbT4NClRvOiA8YXZ0QGlldGYub3JnPjsgPGRyYWZ0LWlldGYtYXZ0 Y29yZS1mZWVkYmFjay1zdXByZXNzaW9uLXJ0cEB0b29scy5pZXRmLm9yZz4NClNlbnQ6IFRodXJz ZGF5LCBKYW51YXJ5IDE5LCAyMDEyIDEwOjQ4IFBNDQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFdH IGxhc3QgY2FsbCBmb3IgUlRDUCBFeHRlbnNpb24gZm9yIFRoaXJkLXBhcnR5IExvc3MgUmVwb3J0 IChkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDkpDQoNCg0KSGks DQoNCkkgaGF2ZSBhIGZldyBjb21tZW50cyB0aGF0IEkgcHJvcG9zZSBoYXZlIGFkZHJlc3NlZCBh ZnRlciB0aGUgV0cgbGFzdA0KY2FsbC4gSSBvbmx5IGNvbnNpZGVyIHR3byBvZiB0aG9zZSBhcyBo YXZpbmcgYW55IHJlYWwgc3Vic3RhbmNlLiBJDQpiZWxpZXZlIHRoZSBkb2N1bWVudCB0byByZWFk eSBmb3IgcHVibGljYXRpb24gcmVxdWVzdCB3aGVuIHRoZXNlIGlzc3Vlcw0KaGFzIGJlZW4gYWRk cmVzc2VkLiBBbmQgd2hlbiBJIHNheSBhZGRyZXNzZWQsIEkgbWVhbiBkaXNjdXNzZWQgYW5kIGEg d2F5DQpmb3J3YXJkIGFncmVlZCBvbiBhbmQgdGhhdCBpbXBsZW1lbnRlZCBpZiBuZWVkLiBJdCBt YXkgdmVyeSB3ZWxsIGJlIHRvDQpzYXkgdGhhdCBteSBvcGluaW9uIGlzIHJvdWdoIGluIHJlZ2Fy ZHMgdG8gdGhlIFdHJ3MuDQoNCg0KMS4gU2VjdGlvbiA0LjI6DQoNClN5bmNocm9uaXphdGlvbiBz b3VyY2UgKFNTUkMpOjMyIGJpdHMNCg0KICAgICAgVGhlIFNTUkMgdmFsdWUgb2YgdGhlIG1lZGlh IHNvdXJjZSB0aGF0IGlzIHJlcXVlc3RlZCB0byBzZW5kIGENCiAgICAgIGRlY29kZXIgcmVmcmVz aCBwb2ludCBvciB0aGF0IGlzIGluZGljYXRlZCB0aGF0IGl0IGxvc3QNCiAgICAgIHN5bmNocm9u aXphdGlvbiB3aXRoIHRoZSB2aWRlbyBzdHJlYW0uDQoNCkkgdGhpbmsgdGhpcyBkZWZpbml0aW9u IGlzIHdyb25nLiBTaG91bGRuJ3QgaXQgYmUgdGhlIFNTUkMgZm9yIHdobydzDQptZWRpYSBzdHJl YW0gdGhlIG1lZGlhIHNlbmRlciBpcyBhbHJlYWR5IGF3YXJlIG9mIGFuIGV4cHJlc3NlZCBuZWVk IGZvcg0KdGFraW5nIGFjdGlvbiB0aGF0IGEgUExJIG9yIEZJUiByZXFpZXN0cyBvZiB0aGlzIFNT UkM/DQoNCkkgZG9uJ3QgdGhpbmsgdGhlIGFib3ZlIGlzIHRoZSByaWdodCB0ZXh0IGZvciB0aGUg c3BlYywgYnV0IEkganVzdA0KdHJ5aW5nIHRvIGV4cHJlc3Mgd2hhdCB0aGUgcmlnaHQgdHlwZSBv ZiBkZWZpbml0aW9uIHdvdWxkIGJlLg0KDQpbUWluXTogQWdyZWUuIEhvdyBhYm91dCBjaGFuZ2lu ZyB0aGUgdGV4dCBhczoNCiINClNlY3Rpb24gNC4yOg0KDQogICBTeW5jaHJvbml6YXRpb24gc291 cmNlIChTU1JDKTozMiBiaXRzDQoNCiAgICAgIFRoZSBTU1JDIHZhbHVlIG9mIHRoZSBtZWRpYSBz b3VyY2UgdGhhdCBoYXMgYWxyZWFkeSBiZWVuIGF3YXJlIHRoZQ0KICAgICAgcmVjZWl2ZXIgbG9z dCBzeW5jaHJvbml6YXRpb24gd2l0aCB0aGUgdmlkZW8gc3RyZWFtIGFuZCBzaWduYWwgdG8NCiAg ICAgIHRoZSByZWNlaXZlciBub3Qgc2VuZGluZyBhIGRlY29kZXIgcmVmcmVzaCBwb2ludA0KIg0K DQoyLiBTZWN0aW9uIDUuDQoNCiJBIG5ldyBmZWVkYmFjayB2YWx1ZSAidHBsciIgbmVlZHMgdG8g YmUgZGVmaW5lZCBmb3IgdGhlIFRoaXJkIFBhcnR5DQogICBMb3NzIFJlcG9ydCBtZXNzYWdlIHRv IGJlIHVzZWQgd2l0aCBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sDQogICAoU0RQKSBbUkZD NDU2Nl0gdXNpbmcgdGhlIEF1Z21lbnRlZCBCYWNrdXMtTmF1ciBGb3JtIChBQk5GKQ0KICAgW1JG QzQ1ODVdLiINCg0KSSBkbyB3b25kZXIsIGRvIHdlIHJlYWxseSBuZWVkIHRvIGRlZmluZSBhIG5l dyBmZWVkYmFjayB2YWx1ZT8gSWYgdGhpcw0KYWxyZWFkeSBpcyBhc3NvY2lhdGVkIGVpdGhlciB3 aXRoIGdlbmVyaWMgTkFDSywgd2l0aCB1c2VzIGp1c3QgIm5hY2siIG9yDQpQTEkgd2hpY2ggaXMg Im5hY2sgcGxpIiBvciBGSVIgd2hpY2ggaXMgImNjbSBmaXIiIG9uIHRoZSBhPXJ0Y3AtZmIgbGlu ZS4NCiBXb3VsZG4ndCBpdCBiZSBtb3JlIG5hdHVyYWwgdG8gdXNlICJuYWNrIHRsbGVpIiBhbmQg ZWl0aGVyICJuYWNrIHBzbGVpIg0Kb3IgImNjbSBwc2xlaSI/DQoNCltRaW5dOiBNYWtlIHNlbnNl LCBJIHdpbGwgdXNlICJuYWNrIHRsbGVpIiBhbmQgIm5hY2sgcHNsZWkiIGluc3RlYWQgb2YgZGVm aW5pbmcgbmV3IGZlZWRiYWNrIHZhbHVlICJ0cGxyIi4NCg0KTklUUw0KDQoNCk4xLiBTZWN0aW9u IDM6DQpXaGVuIGEgcmVjZWl2ZXIgZ2V0cyBhIFRoaXJkIFBhcnR5IExvc3MgUmVwb3J0IG1lc3Nh Z2UsIGl0IHNob3VsZA0KICAgZm9sbG93IHRoZSBydWxlcyBmb3IgTkFDSyBzdXBwcmVzc2lvbiBp biBSRkMgNDU4NSBhbmQgcmVmcmFpbiBmcm9tDQogICBzZW5kaW5nIGEgZmVlZGJhY2sgcmVxdWVz dCAoZS5nLiwgTkFDSyBvciBGSVIpIGZvciB0aGUgbWlzc2luZw0KICAgcGFja2V0cyByZXBvcnRl ZCBpbiB0aGUgbWVzc2FnZSx3aGljaCBpcyBkZWFsdCB3aXRoIGluIHRoZSBzYW1lIHdheQ0KICAg YXMgcmVjZWl2aW5nIE5BQ0suDQoNCmFuZA0KDQogV2hlbiB0aGUgcmV0cmFuc21pdHRlZCBwYWNr ZXQgaXMNCiAgIHJlY2VpdmVkIGJ5IHRoZSByZWNlaXZlcixpdCBzaG91bGQgdGFrZSBpdHMgbm9y bWFsIGJlaGF2aW9yIGFzIGlmDQogICB0aGVyZSBpcyBubyBjdXJyZW50IGZlZWRiYWNrIHN1cHBy ZXNzaW9uLg0KDQpNaXNzaW5nIHNwYWNlIGFmdGVyIGNvbW1hLg0KDQpbUWluXTogRml4ZWQuDQoN Ck4yLiBTZWN0aW9uIDMuDQoNCkluIG9yZGVyIG5vdCB0byBpbmN1ciBhIGxvdCBvZiBOQUNLDQog ICByZXF1ZXN0cyBkdWUgdG8gYWRkaXRpb25hbCBUUExSIGRlc2NyaWJlZCBhYm92ZSwgaXQgaXMg cmVjb21tZW5kZWQNCiAgIHRoYXQgdGhlIFJUUCBzeXN0ZW0gc2VuZGluZyBUUExSIHNob3VsZCBi ZSBpbXBsZW1lbnRlZCBtb3JlIGNsb3NlciB0bw0KICAgdGhlIG1lZGlhIHNvdXJjZS4NCg0KU3Ry YW5nZSBzZW50ZW5jZS4gIm1vcmUgY2xvc2VyIiBpcyBwcm9iYWJseSBiZXN0IHJlZHVjZWQgdG8g anVzdA0KImNsb3NlciIuIEhvd2V2ZXIsIGNsb3NlciB3b3VsZCBiZW5lZml0IGZyb20gYSAiY2xv c2VyIHRvIHRoZSBtZWRpYQ0Kc291cmNlIHRoYW4gLi4uIg0KDQpbUWluXTogRml4ZWQuDQoNCk4z LiBTZWN0aW9uIDQuMSwNCg0KV2l0aGluIHRoZSBjb21tb24gcGFja2V0IGhlYWRlciBmb3IgZmVl ZGJhY2sgbWVzc2FnZXMgKGFzIGRlZmluZWQgaW4NCiAgIHNlY3Rpb24gNi4xIG9mIFtSRkM0NTg1 XSksIHRoZSAiU1NSQyBvZiBwYWNrZXQgc2VuZGVyIiBmaWVsZA0KICAgaW5kaWNhdGVzIHRoZSBz b3VyY2Ugb2YgdGhlIHJlcXVlc3QsIGFuZCB0aGUgIlNTUkMgb2YgbWVkaWEgc291cmNlIg0KICAg ZGVub3RlcyB0aGUgbWVkaWEgc2VuZGVyIG9mIHRoZSBmbG93IGZvciB3aGljaCB0aGUgaW5kaWNh dGVkIGxvc3Nlcw0KICAgYXJlIGJlaW5nIHN1cHByZXNzZWQgLg0KDQphZGRpdGlvbmFsIHNwYWNl IGF0IHRoZSBlbmQgb2YgdGhlIHNlbnRlbmNlLg0KDQpbUWluXTogRml4ZWQuDQoNCk40LiBTZWN0 aW9uIDQuMS4NCiAgIlRoZSBCTFAncyBkZWZpbml0aW9uIGlzIGlkZW50aWNhbCB0byB0aGF0IGdp dmVuIGluIFtSRkM0NTg1XS4iDQoNCkkgdGhpbmsgYSBzZWN0aW9uIHJlZmVyZW5jZSBpbnRvIFJG QzQ1ODUgaXMgcmVjb21tZW5kZWQuDQoNCltRaW5dOiBGaXhlZC4NCg0KTjUuIFNlY3Rpb24gNC4y Og0KDQpGSVIgW1JGQzUxMDRdb3IgUExJIFtSRkM0NTg1XS4NCg0KTWlzc2luZyBzcGFjZSBiZXR3 ZWVuIGZpcnN0IHJlZiBhbmQgIm9yIi4NCg0KQW5kIHNob3VsZCBzaG91bGRuJ3QgdGhhdCAib3Ii IGJlIGFuICJhbmQiPyBUaGUgbWVzc2FnZSBjYW4gc3VwcHJlc3MNCmJvdGggRklSIGFuZCBQTEkg bWVzc2FnZXMuDQoNCltRaW5dOiBGaXhlZC4NCg0KTjYuIFdoZW4gdXNpbmcgcmVmZXJlbmNlcywg bGlrZSBpbiBzZWN0aW9uIDYuMToNCiJJbiBTU00gUlRQIHNlc3Npb25zIGFzIGRlc2NyaWJlZCBp biBbUkZDNTc2MF0sIC4uLiINCg0KSXQgd291bGQgYmUgbXVjaCBjbGVhcmVyIGlmIG9uZSBpbmNs dWRlZCB0aGUgdGl0bGUgb2YgdGhlIFJGQyBiZWZvcmUgdGhlDQpyZWZlcmVuY2UsIGxpa2UgdGhp czoNCg0KSW4gU1NNIFJUUCBzZXNzaW9ucyBhcyBkZXNjcmliZWQgaW4gIlJUUCBDb250cm9sIFBy b3RvY29sIChSVENQKQ0KRXh0ZW5zaW9ucyBmb3IgU2luZ2xlLVNvdXJjZSBNdWx0aWNhc3QgU2Vz c2lvbnMgd2l0aCBVbmljYXN0IEZlZWRiYWNrIg0KW1JGQzU3NjBdLCAuLi4NCg0KW1Fpbl06IEZp eGVkLg0KDQpONy4gU2VjdGlvbiA2LjE6DQoic2luY2UgdGhlIHN1bW1hcnkgZmVlZGJhY2sgZG9l cyBub3QNCiAgIG1hbmRhdGUgdGhlIGZvcndhcmRpbmcgb2YgTkFDSyBkb3duc3RyZWFtLiINCg0K TWlzc2luZyBpbml0aWFsIGNhcGl0YWwgbGV0dGVyIG9uIFNpbmNlLg0KDQpbUWluXTogRml4ZWQu DQoNCk44LiBTZWN0aW9uIDYuMzoNCklmIHRoZSB0cmFuc2xhdG9yIGFjdGluZyBhcyBxdWFsaXR5 IG1vbml0b3IgW01vbmFyY2hdaXMNCiAgIGF3YXJlIG9mIHBhY2tldCBsb3NzLCBpdCBtYXkgdXNl IHRoZSBTU1JDIG9mIG1vbml0b3IgYXMgcGFja2V0IHNlbmRlcg0KICAgU1NSQyB0byBjcmVhdGUg TkFDSyBtZXNzYWdlIGFuZCBzZW5kIGl0IHRvIHRoZSByZWNlaXZlcnMgdGhhdCBpcyBub3QNCiAg IGF3YXJlIG9mIHBhY2tldCBsb3NzLg0KDQppdCBzaG91bGQgYmUgdGhlICJ0aGUgbW9uaXRvciIg YW5kIG1pc3Npbmcgc3BhY2UgYWZ0ZXIgW01vbmFyY2hdDQoNCltRaW5dOiBGaXhlZC4NCg0KQ2hl ZXJzDQoNCk1hZ251cyBXZXN0ZXJsdW5kDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk11bHRpbWVkaWEgVGVj aG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFcmlj c3NvbiBBQiAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KRuRy9mdhdGFu IDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNClNFLTE2NCA4MCBTdG9j a2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0 From bill.wu@huawei.com Mon Jan 30 18:38:51 2012 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 D89D221F861D for ; Mon, 30 Jan 2012 18:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.078 X-Spam-Level: X-Spam-Status: No, score=-5.078 tagged_above=-999 required=5 tests=[AWL=-0.919, BAYES_00=-2.599, J_CHICKENPOX_75=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 fQvdqGV7Wqci for ; Mon, 30 Jan 2012 18:38:50 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 67DC321F85F9 for ; Mon, 30 Jan 2012 18:38:50 -0800 (PST) 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 <0LYN006BS60NGD@szxga03-in.huawei.com> for avt@ietf.org; Tue, 31 Jan 2012 10:38:47 +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 <0LYN001GB60L2N@szxga03-in.huawei.com> for avt@ietf.org; Tue, 31 Jan 2012 10:38:47 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGQ29683; Tue, 31 Jan 2012 10:38:46 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jan 2012 10:36:56 +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.323.3; Tue, 31 Jan 2012 10:37:22 +0800 Date: Tue, 31 Jan 2012 10:37:21 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: "Van Caenegem, Tom (Tom)" , Magnus Westerlund , 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: <4F182C52.5010706@ericsson.com> Subject: Re: [AVTCORE] WG last call for RTCP Extension for Third-partyLoss Report (draft-ietf-avtcore-feedback-supression-rtp-09) 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, 31 Jan 2012 02:38:52 -0000 Hi, Tom: ----- Original Message ----- From: "Van Caenegem, Tom (Tom)" To: "Magnus Westerlund" ; "IETF AVTCore WG" Sent: Friday, January 20, 2012 11:48 PM Subject: Re: [AVTCORE] WG last call for RTCP Extension for Third-partyLoss Report (draft-ietf-avtcore-feedback-supression-rtp-09) >Hi Qin, Magnus, >I have reviewed once more the draft, and these are my comments/questions... >Thx >Tom >1)section 1 >There are cases where multiple receivers may initiate > the same, or an equivalent message towards the same media source. >Suggest to have : There are cases where multiple receivers may initiate > the same, or an equivalent message towards the same media source or same feedback target. [Qin]: Okay. >2)section 1 >One common cause of such a > feedback storm is receivers utilizing RTP retransmission [RFC4588] as > a packet loss recovery technique, sending feedback using RTCP NACK > messages [RFC4585] without proper dithering of the retransmission > requests (e.g., not implementing the RFC 4585 dithering rules or > sending NACKs to a middlebox that doesn't redistribute them to other > receivers). >Suggest to reposition the ")" and use "feedback target" iso "middlebox" (aligned with the vocabulary in the abstract) and add additional clarification: >One common cause of such a > feedback storm is receivers utilizing RTP retransmission [RFC4588] as > a packet loss recovery technique, sending feedback using RTCP NACK > messages [RFC4585] without proper dithering of the retransmission > requests (e.g., not implementing the RFC 4585 dithering rules) or > sending NACKs to a feedback target that doesn't redistribute them to other > receivers and where as a consequence the required feedback suppression behaviour of RTP receivers conforming to RFC 4588 is not activated. [Qin]: Okay. >3)section 1 >RTCP feedback storms may cause short term overload, and in extreme > cases to pose a possible risk of increasing network congestion on the > control channel (e.g. RTCP feedback), the data channel, or both. It > is therefore desirable to provide a way of suppressing unneeded > feedback. >I think this paragraph has some issues:-can you give an example on where lack of RTCP FB suppression message increases data channel congestion-"it is therefore desirable to (..) suppressing unneeded >feedbackWhat is meant with "unneeded" feedback?.. [Qin]: Regarding examples, I like to point you to look at the 1st paragraph and 2nd paragraph of Introduction section and two examples are clearly given over there. >from a receiver point of view, the feedback mechanism is desiredas it wants to inform it is missing a packet (and requesting a retransmission). From the >retransmission server point of view, this feedback is >also desired as it wants to know who is missing a packet so it can follow-up with a retransmission.So, instead, just state: "It is therefore desirable to >provide a way of suppressing feedback". I think it >would be better to highlight that feedback suppression has the obvious effect that the receiver may not receive -in time- a retransmission, (but further >disusison is outside the scope of this document), so it >would be good to add:"Such dedicated feedback suppression has as consequence that the receiver can be (temporarily) deprived from its repair service" >4) I still feel uncomfortbale with the paragraph: >"One approach to this, suggested in [DVB-IPTV], involves sending a > NACK message to the other clients (or receiver) in the same group as > the sender of NACK. However NACK is defined as a receiver report > sent from a receiver observing a packet loss, therefore it only > inform others that sender of NACK detected loss while the case where > the sender of the feedback has received reports that the indicated > packets were lost is not covered. >I suggest to delete this as it is more elaborated upon in the retransmission-for-ssm draft (which reflects the same topology as addressed by DVB) [Qin]: Okay. >5) section 3 >The Third Party Loss Report > (TPLR) message is generated by a RTP system that may not seen the > actual packet loss. It is sent following the same timing rule as > sending NACK defined in [RFC4585]. >Q: what is RTP system? Can it be an RTP receiver? [Qin]: No, I propose to change RTP system into intermediary for consistency. >Q: would be good to add a section reference to RFC 4588 wrt the timing rule [Qin]: Okay. >6) section 3 >"RTP Systems in the network that > receive a Third Party Loss Report SHOULD NOT send their own > additional Third Party Loss Report messages for the same packet > sequence numbers. They should simply forward the Third Party Loss > Report message received from upstream direction, additionally, they > may generate their own Third Party Loss Report that.." >Q: forward to whom? [Qin]: to the reciever(s), will add this into the update. >7) section 3, editorial (I think!); >When a receiver gets a Third Party Loss Report message, it should > follow the rules for NACK suppression in RFC 4585 and refrain from > sending a feedback request (e.g., NACK or FIR) for the missing > packets reported in the message,which is dealt with in the same way > as receiving NACK. >Suggest to delete ",which is dealt with in the same way > as receiving NACK.", as being redundant... [Qin]: Okay. >8) section 3 >"To increase the robustness to the loss of a TPLR or of a transmission > RTP data packet, TPLR or the RTP packet for the same missing Packet > may be retransmitted when RTP systems are aware that the same packet > loss occurs again. If the additional TPLR arrives at receiver, the > receiver should deal with the additional TPLR in the same way as > receiving the first TPLR for the same packet and no additional > behavior for receiver is required. When the retransmitted packet is > received by the receiver,it should take its normal behavior as if > there is no current feedback suppression." >A couple of items here: >-do you mean "..of a REtransmission RTP data packet"? Not sure why you link multiple transmissions of TPLR with multiple transmissions of a retransmission packet? >-" when RTP systems are aware that the same packet loss occurs again" >Do you mean the loss of the TPLR message?-the sentence is anyhow strange because when you start the sentence as you did (to increase the robustness..), isn't there a silent assumption that the RTP >"system" is NO aware that the packet loss occurs again? [Qin]:You are right, will remove this. >-"When the retransmitted packet is > received by the receiver,it should take its normal behavior as if > there is no current feedback suppression." >Feedback suppression is based/defined on a per packet basis or group of packets' basis (as announced in the TPLR).. so if a (retransmission) packet is received by RTP receiver, there is no longer a need >to send feedback ( a NACK) by the receiver... So what is the normal behaviour here? [Qin]: You are right, since packet loss recovery mechanism is not focus of this document, I propose to remove the part about multiple transmissions of a retransmission packet from the above paragraph. >9) section 3: >"Since Third Party Loss Report interacts strongly with repair timing, > it has to work together with feedback to not adversely impact the > repair of lost source packets. 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 media source. When the loss was detected and repair initiated > much closer to the media 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." >-what do you mean with TPL reports must work together with feedback? It supresses feedback! [Qin]: A TPLR is sent to inform some participants in a session about feedback they would not otherwise see, and so the sender of the TPLR has to work together with the sends of NACKs to ensure that appropriate reports are sent to all receivers. >This paragraph is quite problematic for me.. you cannot really make statements on proximity of systems without topology considerations.. >-what does "incur a lot of NACK requests" mean ? >-I do not understand how an RTP system sending TPLR operating in proximity to the media source can help here.. as the RTP system sending the TPL needs to wait for a NACK ..from a receiver, before >sending a TPLR, this will not really help. [Qin]: I agree with you that this draft shouldn't talk about topology. To avoid further confusion, I propose to remove this paragraph.