From root@core3.amsl.com Fri Oct 1 01:45:17 2010 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1CD633A6C25; Fri, 1 Oct 2010 01:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101001084511.1CD633A6C25@core3.amsl.com> Date: Fri, 1 Oct 2010 01:45:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rfc3016bis-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 08:45:18 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for MPEG-4 Audio/Visual Streams Author(s) : M. Schmidt, et al. Filename : draft-ietf-avt-rfc3016bis-01.txt Pages : 32 Date : 2010-10-01 This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of Session Description Protocol (SDP). Comments are solicited and should be addressed to the working group's mailing list at avt@ietf.org and/or the author(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3016bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rfc3016bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-01013237.I-D@ietf.org> --NextPart-- From frans.de.bont@philips.com Fri Oct 1 01:54:42 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606543A6BE6 for ; Fri, 1 Oct 2010 01:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvVp-GN8YChO for ; Fri, 1 Oct 2010 01:54:41 -0700 (PDT) Received: from VA3EHSOBE001.bigfish.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by core3.amsl.com (Postfix) with ESMTP id 486A13A6B41 for ; Fri, 1 Oct 2010 01:54:41 -0700 (PDT) Received: from mail101-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 8.1.340.0; Fri, 1 Oct 2010 08:55:28 +0000 Received: from mail101-va3 (localhost.localdomain [127.0.0.1]) by mail101-va3-R.bigfish.com (Postfix) with ESMTP id 8EE551B00DC for ; Fri, 1 Oct 2010 08:55:28 +0000 (UTC) X-SpamScore: -67 X-BigFish: VPS-67(zz15d6O9251J936eK542N1432N14ffO217bP9371Pzz1202hzz8275dh1033ILz2dh2a8h61h) X-Spam-TCS-SCL: 0:0 Received: from mail101-va3 (localhost.localdomain [127.0.0.1]) by mail101-va3 (MessageSwitch) id 128592332829067_15689; Fri, 1 Oct 2010 08:55:28 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.253]) by mail101-va3.bigfish.com (Postfix) with ESMTP id 0400B12F8046 for ; Fri, 1 Oct 2010 08:55:28 +0000 (UTC) Received: from NLHILEXE04.connect1.local (168.87.56.20) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.0.482.44; Fri, 1 Oct 2010 08:55:27 +0000 Received: from NLHILEXH02.connect1.local (172.16.153.92) by connect1.philips.com (172.16.156.160) with Microsoft SMTP Server (TLS) id 8.2.234.1; Fri, 1 Oct 2010 10:55:19 +0200 Received: from NLCLUEXM01.connect1.local ([172.16.153.50]) by NLHILEXH02.connect1.local ([172.16.153.92]) with mapi; Fri, 1 Oct 2010 10:55:26 +0200 From: "Bont, Frans de" To: "avt@ietf.org" Date: Fri, 1 Oct 2010 10:55:23 +0200 Thread-Topic: [AVT] I-D Action:draft-ietf-avt-rfc3016bis-01.txt Thread-Index: ActhRSEGzfA2DDnKSIupnZcA/31aaAAANtuQ Message-ID: <19FE62CE8D62CF4B96C845DC556B8813774E0879EE@NLCLUEXM01.connect1.local> References: <20101001084511.1CD633A6C25@core3.amsl.com> In-Reply-To: <20101001084511.1CD633A6C25@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Reverse-DNS: smtpx.philips.com Subject: Re: [AVT] I-D Action:draft-ietf-avt-rfc3016bis-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 08:54:42 -0000 Hi all, We have submitted a slightly updated version of the draft as it would expir= e soon. Below a summary of the changes. http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3016bis-01.txt 1. The media subtype registration was not in line in accordance with RFC4855 and was not using the template of RFC4288. This has been corrected. 2. The registration section had examples, they have been moved to the mappi= ng to SDP section. 3. The IANA consideration was updating the registering of the media subtype definition from RFC 3016, but since it is the intention to obsolete 3016, RFC 3016 has been replaced by RFC XXXX in the related sections. 4. The draft listed the differences with respect to RFC 3016, but an interoperability consideration with systems that support RFC 3016 was missi= ng. Therefore, a section has been added to describe that no interoperability is= sues are foreseen because existing systems that support RFC 3016 already comply = with the specification of the 3GPP PSS service and the draft is compatible with = it. 5. In section 3.3 (f) an example of fragmentation was mentioned but the las= t sentence of that example was confusing. This last sentence has been removed= . 6. The change controller in the registration is changed to: "IETF Audio/Video Transport working group delegated from the IESG." Your comments are welcome! Best regards, Frans > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: 2010 Oct 01 10:45 AM > To: i-d-announce@ietf.org > Cc: avt@ietf.org > Subject: [AVT] I-D Action:draft-ietf-avt-rfc3016bis-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Working Group of t= he > IETF. > > > Title : RTP Payload Format for MPEG-4 Audio/Visual Stream= s > Author(s) : M. Schmidt, et al. > Filename : draft-ietf-avt-rfc3016bis-01.txt > Pages : 32 > Date : 2010-10-01 > > This document describes Real-Time Transport Protocol (RTP) payload format= s for > carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using = MPEG- > 4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitst= reams > onto RTP packets, it provides specifications for the use of RTP header fi= elds > and also specifies fragmentation rules. It also provides specifications = for > Media Type registration and the use of Session Description Protocol (SDP)= . > > Comments are solicited and should be addressed to the working group's mai= ling > list at avt@ietf.org and/or the author(s). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3016bis-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From Even.roni@huawei.com Fri Oct 1 13:51:03 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624FF3A6E2A for ; Fri, 1 Oct 2010 13:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.046 X-Spam-Level: X-Spam-Status: No, score=-99.046 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_BELOW2=2.154, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HITKHSly9p5s for ; Fri, 1 Oct 2010 13:51:02 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 4F3AA3A6D01 for ; Fri, 1 Oct 2010 13:51:02 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9M00I79PY4TS@szxga01-in.huawei.com> for avt@ietf.org; Sat, 02 Oct 2010 04:51:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9M00AU5PY4GY@szxga01-in.huawei.com> for avt@ietf.org; Sat, 02 Oct 2010 04:51:40 +0800 (CST) Received: from windows8d787f9 (bzq-109-64-32-104.red.bezeqint.net [109.64.32.104]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9M0025DPXSDP@szxml02-in.huawei.com>; Sat, 02 Oct 2010 04:51:40 +0800 (CST) Date: Fri, 01 Oct 2010 22:49:25 +0200 From: Roni Even In-reply-to: <4CA5DCCC.3020105@tandberg.com> To: 'IETF AVT WG' Message-id: <015f01cb61aa$29ef8a10$7dce9e30$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=windows-1255 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: ActhaXmd2eNVMAcqToWvhL7+ejvpbgAPaDZA References: <4CA5DCCC.3020105@tandberg.com> Cc: 'Randell Jesup' , 'Tom Kristensen' , keith.drage@alcatel-lucent.com Subject: Re: [AVT] rfc3984bis - max-smbps limit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 20:51:03 -0000 Hi, We got the following comment as a private email (bellow) . The draft has = not be published yet and we can do this change before publication. Please review and send comments to the list since it changes the current semantics. If there are no objections we will do this change. Since this parameter has been added in the bis draft and was not part of = RFC 3984 we do not see any interoperability issues. Thanks Roni Even As a co-author of the draft Email from Tom Kristensen I discovered missing alignment between H.241 MaxStaticMBPS and max-smbps = as defined in draft-ietf-avt-rtp-rfc3984bis. From Table 8-9, H.241: --- The encoder should recompute this value for each picture. The value of (MaxStaticMBPS =AA 500) shall not be less than the value = MaxMBPS for the Level given in Table A-1/H.264, and if CustomMaxMBPS is = signalled, shall not be less than the value (CustomMaxMBPS =AA 500). --- On the other hand in the SIP world, rfc3984bis says: --- The value of max-smbps MUST be greater than the value of MaxMBPS given = in Table A-1 of [1] for the highest level. --- http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-11#page-44 H.241 says max-smbps >=3D max-mbps. rfc3984bis says max-smbps > max-mbps. We are missing "or equal". Of course it doesn't really make much meaning to include a max-smbps=20 equal to max-mbps, but we have a mismatch between H.241 and the SDP=20 counterpart. Is it possible and feasible to alter the text given the current state of = soon-to-be-RFC draft-ietf-avt-rtp-rfc3984bis? From stephen.botzko@gmail.com Fri Oct 1 14:02:45 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A71B3A6E45 for ; Fri, 1 Oct 2010 14:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8WCrPb5VaRB for ; Fri, 1 Oct 2010 14:02:44 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 2594B3A6E2F for ; Fri, 1 Oct 2010 14:02:44 -0700 (PDT) Received: by qyk2 with SMTP id 2so4402356qyk.10 for ; Fri, 01 Oct 2010 14:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Ac62oLuvCxQ0no9cnhYiivd6QG7cdTLOmmeT3V3VM28=; b=PRZhMd1gkHF7nbfKxuXmQiQ6MsvuAEqBQfRUXgEk/iyWo9N4A1j+VEunmDW4SfCMh+ U3ElxXMxy60K8KPL11CMjHyw40LNFubo2lJMSDPj4s4w3VfndBuPKG04RcV7qN/8iEHv Aa52x/5PtVv1UwOyMaUSvowE+RwGVCV6twWWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ph35kZ0dU9VyFZZMSfPGhAudIvzT5R7ldGM1t0rQ748SaBmCkyR9KKu0V/ti+CICuD 6xouFtr6oKjBQ4qQQFXnqK7kWjYJ6Dx4K45gd5X/FNhRY3igORiX2z6a2xIlcgVY2aHh HrFJNj6MV9uxwL8t6V3BfncelUTWLfKLupa/w= MIME-Version: 1.0 Received: by 10.229.95.19 with SMTP id b19mr4361758qcn.64.1285967012701; Fri, 01 Oct 2010 14:03:32 -0700 (PDT) Received: by 10.229.63.14 with HTTP; Fri, 1 Oct 2010 14:03:32 -0700 (PDT) In-Reply-To: <015f01cb61aa$29ef8a10$7dce9e30$%roni@huawei.com> References: <4CA5DCCC.3020105@tandberg.com> <015f01cb61aa$29ef8a10$7dce9e30$%roni@huawei.com> Date: Fri, 1 Oct 2010 17:03:32 -0400 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/alternative; boundary=0016364ee23cfc25ef049194868c Cc: Randell Jesup , keith.drage@alcatel-lucent.com, Tom Kristensen , IETF AVT WG Subject: Re: [AVT] rfc3984bis - max-smbps limit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:02:45 -0000 --0016364ee23cfc25ef049194868c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think reconciling the text with H.241 is a good idea, as it removes a corner-case from fully compliant non-transcoding gateways. I also agree with Tom's observation that it doesn't make sense to signal max-smbps unless it is greater than max_mpbs. Stephen Botzko 2010/10/1 Roni Even > Hi, > > We got the following comment as a private email (bellow) . The draft has > not > be published yet and we can do this change before publication. > Please review and send comments to the list since it changes the current > semantics. If there are no objections we will do this change. > Since this parameter has been added in the bis draft and was not part of > RFC > 3984 we do not see any interoperability issues. > > Thanks > Roni Even > As a co-author of the draft > > > Email from Tom Kristensen > > I discovered missing alignment between H.241 MaxStaticMBPS and max-smbps = as > defined in draft-ietf-avt-rtp-rfc3984bis. > > From Table 8-9, H.241: > --- > The encoder should recompute this value for each picture. > The value of (MaxStaticMBPS =D7 500) shall not be less than the value Max= MBPS > for the Level given in Table A-1/H.264, and if CustomMaxMBPS is signalled= , > shall not be less than the value (CustomMaxMBPS =D7 500). > --- > > On the other hand in the SIP world, rfc3984bis says: > --- > The value of max-smbps MUST be greater than the value of MaxMBPS given in > Table A-1 of [1] for the highest level. > --- > http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-11#page-44 > > > H.241 says max-smbps >=3D max-mbps. > rfc3984bis says max-smbps > max-mbps. > We are missing "or equal". > > Of course it doesn't really make much meaning to include a max-smbps > equal to max-mbps, but we have a mismatch between H.241 and the SDP > counterpart. > > Is it possible and feasible to alter the text given the current state of > soon-to-be-RFC draft-ietf-avt-rtp-rfc3984bis? > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --0016364ee23cfc25ef049194868c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think reconciling the text with H.241 is a good idea, as it removes a cor= ner-case from fully compliant non-transcoding gateways.

I also agree= with Tom's observation that it doesn't make sense to signal max-sm= bps unless it is greater than max_mpbs.

Stephen Botzko

2010/10/1 Roni Even <Even.roni@huawe= i.com>
Hi,

We got the following comment as a private email (bellow) . The draft has no= t
be published yet and we can do this change before publication.
Please review and send comments to the list since it changes the current semantics. If there are no objections we will do this change.
Since this parameter has been added in the bis draft and was not part of RF= C
3984 we do not see any interoperability issues.

Thanks
Roni Even
As a co-author of the draft


Email from Tom Kristensen

I discovered missing alignment between H.241 MaxStaticMBPS and max-smbps as=
defined in draft-ietf-avt-rtp-rfc3984bis.

=A0From Table 8-9, H.241:
---
The encoder should recompute this value for each picture.
The value of (MaxStaticMBPS =D7 500) shall not be less than the value MaxMB= PS
for the Level given in Table A-1/H.264, and if CustomMaxMBPS is signalled,<= br> shall not be less than the value (CustomMaxMBPS =D7 500).
---

On the other hand in the SIP world, rfc3984bis says:
---
The value of max-smbps MUST be greater than the value of MaxMBPS given in Table A-1 of [1] for the highest level.
---
http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc398= 4bis-11#page-44


H.241 says =A0 =A0 =A0max-smbps >=3D max-mbps.
rfc3984bis says max-smbps > =A0max-mbps.
We are missing "or equal".

Of course it doesn't really make much meaning to include a max-smbps equal to max-mbps, but we have a mismatch between H.241 and the SDP
counterpart.

Is it possible and feasible to alter the text given the current state of soon-to-be-RFC draft-ietf-avt-rtp-rfc3984bis?


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

--0016364ee23cfc25ef049194868c-- From yekuiwang@huawei.com Fri Oct 1 14:05:49 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98F93A6D5D for ; Fri, 1 Oct 2010 14:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ5+B87YZdQS for ; Fri, 1 Oct 2010 14:05:48 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id B8D7A3A6CEF for ; Fri, 1 Oct 2010 14:05:48 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9M00NOLQN004@usaga04-in.huawei.com> for avt@ietf.org; Fri, 01 Oct 2010 16:06:37 -0500 (CDT) Received: from W90946 ([10.193.125.222]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9M0096LQMP95@usaga04-in.huawei.com> for avt@ietf.org; Fri, 01 Oct 2010 16:06:36 -0500 (CDT) Date: Fri, 01 Oct 2010 17:06:25 -0400 From: Ye-Kui Wang In-reply-to: To: 'Stephen Botzko' , 'Roni Even' Message-id: <0E1BEE7BB93D42C9AD14BD04A8D6A9D6@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_vgtMEuum0ZLN/8gT6+9SHQ)" Thread-index: ActhrCTO4z459UkEQPqgWUf3WbKQBQAAFBgQ References: <4CA5DCCC.3020105@tandberg.com> <015f01cb61aa$29ef8a10$7dce9e30$%roni@huawei.com> Cc: 'Randell Jesup' , keith.drage@alcatel-lucent.com, 'Tom Kristensen' , 'IETF AVT WG' Subject: Re: [AVT] rfc3984bis - max-smbps limit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:05:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_vgtMEuum0ZLN/8gT6+9SHQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable +1 _____ =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: Friday, October 01, 2010 5:04 PM To: Roni Even Cc: Randell Jesup; keith.drage@alcatel-lucent.com; Tom Kristensen; IETF = AVT WG Subject: Re: [AVT] rfc3984bis - max-smbps limit I think reconciling the text with H.241 is a good idea, as it removes a corner-case from fully compliant non-transcoding gateways. I also agree with Tom's observation that it doesn't make sense to signal max-smbps unless it is greater than max_mpbs. Stephen Botzko 2010/10/1 Roni Even Hi, We got the following comment as a private email (bellow) . The draft has = not be published yet and we can do this change before publication. Please review and send comments to the list since it changes the current semantics. If there are no objections we will do this change. Since this parameter has been added in the bis draft and was not part of = RFC 3984 we do not see any interoperability issues. Thanks Roni Even As a co-author of the draft Email from Tom Kristensen I discovered missing alignment between H.241 MaxStaticMBPS and max-smbps = as defined in draft-ietf-avt-rtp-rfc3984bis. From Table 8-9, H.241: --- The encoder should recompute this value for each picture. The value of (MaxStaticMBPS =D7 500) shall not be less than the value = MaxMBPS for the Level given in Table A-1/H.264, and if CustomMaxMBPS is = signalled, shall not be less than the value (CustomMaxMBPS =D7 500). --- On the other hand in the SIP world, rfc3984bis says: --- The value of max-smbps MUST be greater than the value of MaxMBPS given = in Table A-1 of [1] for the highest level. --- http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-11#page-44 H.241 says max-smbps >=3D max-mbps. rfc3984bis says max-smbps > max-mbps. We are missing "or equal". Of course it doesn't really make much meaning to include a max-smbps equal to max-mbps, but we have a mismatch between H.241 and the SDP counterpart. Is it possible and feasible to alter the text given the current state of soon-to-be-RFC draft-ietf-avt-rtp-rfc3984bis? _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_vgtMEuum0ZLN/8gT6+9SHQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable
+1

From: avt-bounces@ietf.org=20 [mailto:avt-bounces@ietf.org] On Behalf Of Stephen=20 Botzko
Sent: Friday, October 01, 2010 5:04 PM
To: = Roni=20 Even
Cc: Randell Jesup; keith.drage@alcatel-lucent.com; Tom=20 Kristensen; IETF AVT WG
Subject: Re: [AVT] rfc3984bis - = max-smbps=20 limit

I think reconciling the text with H.241 is a good idea, as = it=20 removes a corner-case from fully compliant non-transcoding = gateways.

I=20 also agree with Tom's observation that it doesn't make sense to signal = max-smbps unless it is greater than max_mpbs.

Stephen = Botzko

2010/10/1 Roni Even <Even.roni@huawei.com><= BR>
Hi,

We=20 got the following comment as a private email (bellow) . The draft = has=20 not
be published yet and we can do this change before=20 publication.
Please review and send comments to the list since it = changes=20 the current
semantics. If there are no objections we will do this = change.
Since this parameter has been added in the bis draft and = was not=20 part of RFC
3984 we do not see any interoperability=20 issues.

Thanks
Roni Even
As a co-author of the=20 draft


Email from Tom Kristensen

I discovered = missing=20 alignment between H.241 MaxStaticMBPS and max-smbps as
defined in = draft-ietf-avt-rtp-rfc3984bis.

 From Table 8-9,=20 H.241:
---
The encoder should recompute this value for each=20 picture.
The value of (MaxStaticMBPS =D7 500) shall not be less = than the=20 value MaxMBPS
for the Level given in Table A-1/H.264, and if=20 CustomMaxMBPS is signalled,
shall not be less than the value=20 (CustomMaxMBPS =D7 500).
---

On the other hand in the SIP = world,=20 rfc3984bis says:
---
The value of max-smbps MUST be greater = than the=20 value of MaxMBPS given in
Table A-1 of [1] for the highest=20 level.
---
http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-= 11#page-44


H.241=20 says      max-smbps >=3D max-mbps.
rfc3984bis = says=20 max-smbps >  max-mbps.
We are missing "or = equal".

Of=20 course it doesn't really make much meaning to include a = max-smbps
equal=20 to max-mbps, but we have a mismatch between H.241 and the=20 SDP
counterpart.

Is it possible and feasible to alter the = text=20 given the current state of
soon-to-be-RFC=20 = draft-ietf-avt-rtp-rfc3984bis?


_______________________________= ________________
Audio/Video=20 Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

--Boundary_(ID_vgtMEuum0ZLN/8gT6+9SHQ)-- From eckelcu@cisco.com Fri Oct 1 14:26:31 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9136B3A6D91 for ; Fri, 1 Oct 2010 14:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.522 X-Spam-Level: X-Spam-Status: No, score=-9.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAFHMVwNWKk8 for ; Fri, 1 Oct 2010 14:26:30 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 49A123A6BB0 for ; Fri, 1 Oct 2010 14:26:30 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIrupUyrRN+J/2dsb2JhbACiP3GsGpw5hUQEhFGIcw X-IronPort-AV: E=Sophos;i="4.57,268,1283731200"; d="scan'208";a="263532579" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 01 Oct 2010 21:27:19 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o91LRJjn019676; Fri, 1 Oct 2010 21:27:19 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Oct 2010 14:27:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Oct 2010 14:27:17 -0700 Message-ID: In-Reply-To: <0E1BEE7BB93D42C9AD14BD04A8D6A9D6@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] rfc3984bis - max-smbps limit Thread-Index: ActhrCTO4z459UkEQPqgWUf3WbKQBQAAFBgQAAC3G6A= References: <4CA5DCCC.3020105@tandberg.com><015f01cb61aa$29ef8a10$7dce9e30$%roni@huawei.com> <0E1BEE7BB93D42C9AD14BD04A8D6A9D6@china.huawei.com> From: "Charles Eckel (eckelcu)" To: "Ye-Kui Wang" , "Stephen Botzko" , "Roni Even" X-OriginalArrivalTime: 01 Oct 2010 21:27:19.0361 (UTC) FILETIME=[6D72EB10:01CB61AF] Cc: Randell Jesup , keith.drage@alcatel-lucent.com, Tom Kristensen , IETF AVT WG Subject: Re: [AVT] rfc3984bis - max-smbps limit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:26:31 -0000 I agree, and have seen this come up with H.323/SIP interworking = gateways. I think the change is worthwhile. Charles > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ye-Kui Wang > Sent: Friday, October 01, 2010 2:06 PM > To: 'Stephen Botzko'; 'Roni Even' > Cc: 'Randell Jesup'; keith.drage@alcatel-lucent.com; 'Tom Kristensen'; = 'IETF AVT WG' > Subject: Re: [AVT] rfc3984bis - max-smbps limit >=20 > +1 >=20 >=20 > ________________________________ >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Stephen Botzko > Sent: Friday, October 01, 2010 5:04 PM > To: Roni Even > Cc: Randell Jesup; keith.drage@alcatel-lucent.com; Tom Kristensen; = IETF AVT WG > Subject: Re: [AVT] rfc3984bis - max-smbps limit >=20 >=20 > I think reconciling the text with H.241 is a good idea, as it removes = a corner-case from fully > compliant non-transcoding gateways. >=20 > I also agree with Tom's observation that it doesn't make sense to = signal max-smbps unless it is > greater than max_mpbs. >=20 > Stephen Botzko >=20 >=20 > 2010/10/1 Roni Even >=20 >=20 > Hi, >=20 > We got the following comment as a private email (bellow) . The draft = has not > be published yet and we can do this change before publication. > Please review and send comments to the list since it changes the = current > semantics. If there are no objections we will do this change. > Since this parameter has been added in the bis draft and was not = part of RFC > 3984 we do not see any interoperability issues. >=20 > Thanks > Roni Even > As a co-author of the draft >=20 >=20 > Email from Tom Kristensen >=20 > I discovered missing alignment between H.241 MaxStaticMBPS and = max-smbps as > defined in draft-ietf-avt-rtp-rfc3984bis. >=20 > From Table 8-9, H.241: > --- > The encoder should recompute this value for each picture. > The value of (MaxStaticMBPS =D7 500) shall not be less than the = value MaxMBPS > for the Level given in Table A-1/H.264, and if CustomMaxMBPS is = signalled, > shall not be less than the value (CustomMaxMBPS =D7 500). > --- >=20 > On the other hand in the SIP world, rfc3984bis says: > --- > The value of max-smbps MUST be greater than the value of MaxMBPS = given in > Table A-1 of [1] for the highest level. > --- > http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-11#page-44 >=20 >=20 > H.241 says max-smbps >=3D max-mbps. > rfc3984bis says max-smbps > max-mbps. > We are missing "or equal". >=20 > Of course it doesn't really make much meaning to include a max-smbps > equal to max-mbps, but we have a mismatch between H.241 and the SDP > counterpart. >=20 > Is it possible and feasible to alter the text given the current = state of > soon-to-be-RFC draft-ietf-avt-rtp-rfc3984bis? >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 From mzanaty@cisco.com Sat Oct 2 06:08:46 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32DD43A6E7A for ; Sat, 2 Oct 2010 06:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.372 X-Spam-Level: X-Spam-Status: No, score=-9.372 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbcHMMTZtGVa for ; Sat, 2 Oct 2010 06:08:39 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B09483A6C02 for ; Sat, 2 Oct 2010 06:08:36 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAELMpkytJV2a/2dsb2JhbACiPnGlR5t0gwQIgjgEhFGIcw X-IronPort-AV: E=Sophos;i="4.57,271,1283731200"; d="scan'208";a="166208270" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2010 13:09:23 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o92D9NI6023722; Sat, 2 Oct 2010 13:09:23 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Oct 2010 08:09:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 2 Oct 2010 08:08:13 -0500 Message-ID: In-Reply-To: <015f01cb61aa$29ef8a10$7dce9e30$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] rfc3984bis - max-smbps limit Thread-Index: ActhaXmd2eNVMAcqToWvhL7+ejvpbgAPaDZAACFimyA= From: "Mo Zanaty (mzanaty)" To: "Roni Even" , "IETF AVT WG" X-OriginalArrivalTime: 02 Oct 2010 13:09:23.0280 (UTC) FILETIME=[08547D00:01CB6233] Cc: Randell Jesup , Tom Kristensen , keith.drage@alcatel-lucent.com Subject: Re: [AVT] rfc3984bis - max-smbps limit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 13:08:46 -0000 The draft is missing more than just "or equal to". > The value of max-smbps MUST be greater than the value of MaxMBPS given = in > Table A-1 of [1] for the highest level. It should also take max-mbps into account. And the reference to "highest = level" has no antecedent in this section; it is in the prior section on = max-mbps. I suggest this [new] text: "The value of max-smbps MUST be greater than [or equal to] the value of = MaxMBPS given [explicitly in max-mbps or implicitly] in Table A-1 of [1] = for the highest level [given in profile-level-id or max-recv-level]." Regards, Mo -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Roni Even Sent: Friday, October 01, 2010 4:49 PM To: 'IETF AVT WG' Cc: 'Randell Jesup'; 'Tom Kristensen'; keith.drage@alcatel-lucent.com Subject: Re: [AVT] rfc3984bis - max-smbps limit Hi, We got the following comment as a private email (bellow) . The draft has = not be published yet and we can do this change before publication. Please review and send comments to the list since it changes the current semantics. If there are no objections we will do this change. Since this parameter has been added in the bis draft and was not part of = RFC 3984 we do not see any interoperability issues. Thanks Roni Even As a co-author of the draft Email from Tom Kristensen I discovered missing alignment between H.241 MaxStaticMBPS and max-smbps = as defined in draft-ietf-avt-rtp-rfc3984bis. From Table 8-9, H.241: --- The encoder should recompute this value for each picture. The value of (MaxStaticMBPS =D7 500) shall not be less than the value = MaxMBPS for the Level given in Table A-1/H.264, and if CustomMaxMBPS is = signalled, shall not be less than the value (CustomMaxMBPS =D7 500). --- On the other hand in the SIP world, rfc3984bis says: --- The value of max-smbps MUST be greater than the value of MaxMBPS given = in Table A-1 of [1] for the highest level. --- http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-11#page-44 H.241 says max-smbps >=3D max-mbps. rfc3984bis says max-smbps > max-mbps. We are missing "or equal". Of course it doesn't really make much meaning to include a max-smbps=20 equal to max-mbps, but we have a mismatch between H.241 and the SDP=20 counterpart. Is it possible and feasible to alter the text given the current state of = soon-to-be-RFC draft-ietf-avt-rtp-rfc3984bis? _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From dworley@avaya.com Fri Oct 1 08:53:21 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C423A6C32 for ; Fri, 1 Oct 2010 08:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2nx7AA3dsFj for ; Fri, 1 Oct 2010 08:53:20 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 1C3063A6C5B for ; Fri, 1 Oct 2010 08:53:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,267,1283745600"; d="scan'208";a="210096418" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Oct 2010 11:54:06 -0400 X-IronPort-AV: E=Sophos;i="4.57,267,1283745600"; d="scan'208";a="518108049" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Oct 2010 11:54:05 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 1 Oct 2010 11:54:05 -0400 From: "Worley, Dale R (Dale)" To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "avt@ietf.org" , Robert Sparks Date: Fri, 1 Oct 2010 11:54:05 -0400 Thread-Topic: [AVT] Report on Errata ID: 1793, RFC4103, "RTP Payload for Text Conversation" Thread-Index: ActhM6VCNKu99JSiQKacY4QOabjOBwAS9Eao Message-ID: References: , <4CA58287.2020104@omnitor.se> In-Reply-To: <4CA58287.2020104@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 02 Oct 2010 12:38:09 -0700 Subject: Re: [AVT] Report on Errata ID: 1793, RFC4103, "RTP Payload for Text Conversation" X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 15:53:21 -0000 ________________________________________ From: Gunnar Hellstr=F6m [gunnar.hellstrom@omnitor.se] You say " if one is carefully examining the example, one can see that it is incorrect based on RFC 2198." Can you please explain what inconsistency you have found? ________________________________________ In the scenario discussed in RFC 4103 section 7.1, the example message on p= age 12 contains two T140blocks, one "primary" (P), that is, the most recent= , containing zero bytes, and one "redundant" (R), which is a copy of the im= mediately preceding T140block to be sent, containing some bytes. The examp= le message on page 13 (which is the subject of the erratum) is the next RTP= packet sent, and is to contain a primary T140block "P", the next-previous = T140block "R1", and the one before that, "R2". Thus, the various contained T140blocks are duplicates in the following way: (must be seen in fixed-width) RTP packet, p. 13 RTP packet, p. 12 P R1 ----------------- P R2 ----------------- R The p. 13 P is the newest T140block and is stated to be non-empty. The p. = 13 R1 is the same as the p. 12 P and is stated on p. 12 to be empty. The p= . 13 R2 is the same as the p. 12 R and is stated on p. 12 to be non-empty. = But the RFC's diagram on p. 13 says that R2 is empty and R1 is not. Corre= cting that statement is the substance of the erratum. Dale Worley, Dale R (Dale) skrev 2010-09-30 20:54: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Errata ID: 1793 > RFC4103, "RTP Payload for Text Conversation" > Source of RFC: avt (rai) > > Status: Reported > Type: Technical > > Reported By: Gunnar Hellstrom > Date Reported: 2009-06-16 > > Section 7.1 says: > > The value of the "R2 block length" would be set to zero in order to > represent the empty T140block. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V=3D2|P|X| CC=3D0 |M| "RED" PT | sequence number of primary | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | timestamp of primary encoding "P" | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | synchronization source (SSRC) identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| T140 PT | timestamp offset of "R2" | "R2" block length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| T140 PT | timestamp offset of "R1" | "R1" block length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| T140 PT | "R1" T.140 encoded redundant data | > +-+-+-+-+-+-+-+-+ +---------------+ > | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+ > | "P" T.140 encoded primary data | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > It should say: > > The value of the "R1 block length" would be set to zero in order to > represent the empty T140block. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V=3D2|P|X| CC=3D0 |M| "RED" PT | sequence number of primary | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | timestamp of primary encoding "P" | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | synchronization source (SSRC) identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| T140 PT | timestamp offset of "R2" | "R2" block length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| T140 PT | timestamp offset of "R1" | "R1" block length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| T140 PT | "R2" T.140 encoded redundant data | > +-+-+-+-+-+-+-+-+ +---------------+ > | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+ > | "P" T.140 encoded primary data | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ---------------------------------------------------------------------- > Recommended status: Verified, hold for document update > > The erratum is correct. In the example in question (on page 13), the > three T140blocks (in time order) are R2, R1, and P, the first two of > which correspond to R and P of the previous example (on page 12). The > latter P has zero length. So in the example in question, R2 is > non-empty, R1 is empty, and P is non-empty. > > However, if one is carefully examining the example, one can see that > it is incorrect based on RFC 2198. So I recommend that this erratum > be held for document update. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Dale > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From tom.kristensen@tandberg.com Sun Oct 3 02:48:28 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A28E3A6C1F for ; Sun, 3 Oct 2010 02:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.779 X-Spam-Level: X-Spam-Status: No, score=-4.779 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMVxbm8btm-o for ; Sun, 3 Oct 2010 02:48:27 -0700 (PDT) Received: from mail188.messagelabs.com (mail188.messagelabs.com [85.158.139.163]) by core3.amsl.com (Postfix) with SMTP id BF05B3A69F2 for ; Sun, 3 Oct 2010 02:48:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tom.kristensen@tandberg.com X-Msg-Ref: server-11.tower-188.messagelabs.com!1286099358!59887468!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 24436 invoked from network); 3 Oct 2010 09:49:19 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-11.tower-188.messagelabs.com with SMTP; 3 Oct 2010 09:49:19 -0000 Received: from ultra.eu.tandberg.int ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 Oct 2010 11:49:18 +0200 Received: from [10.47.13.9] ([10.47.13.9]) by ultra.eu.tandberg.int (8.13.1/8.13.1) with ESMTP id o939nF84027155; Sun, 3 Oct 2010 11:49:16 +0200 Message-ID: <4CA8519B.6020707@tandberg.com> Date: Sun, 03 Oct 2010 11:49:15 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.7 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Oct 2010 09:49:18.0068 (UTC) FILETIME=[3F144340:01CB62E0] Cc: Randell Jesup , keith.drage@alcatel-lucent.com, IETF AVT WG , Roni Even Subject: Re: [AVT] rfc3984bis - max-smbps limit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 09:48:28 -0000 Indeed, Mo, we have to take a potential max-mbps into account in the description and the clarification of "highest level" also in the max-smbps text part is just fine. Even though "highest level" is described under a common heading for these parameters, it is repeated for the other parameters. Cf.: max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: These parameters MAY be used to signal the capabilities of a receiver implementation. These parameters MUST NOT be used for any other purpose. The highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter MUST be such that the receiver is fully capable of supporting. -- Tom On 10/02/2010 03:08 PM, Mo Zanaty (mzanaty) wrote: > The draft is missing more than just "or equal to". > >> The value of max-smbps MUST be greater than the value of MaxMBPS given in >> Table A-1 of [1] for the highest level. > > It should also take max-mbps into account. And the reference to "highest level" has no antecedent in this section; it is in the prior section on max-mbps. > > I suggest this [new] text: > > "The value of max-smbps MUST be greater than [or equal to] the value of MaxMBPS given [explicitly in max-mbps or implicitly] in Table A-1 of [1] for the highest level [given in profile-level-id or max-recv-level]." > > Regards, > Mo > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even > Sent: Friday, October 01, 2010 4:49 PM > To: 'IETF AVT WG' > Cc: 'Randell Jesup'; 'Tom Kristensen'; keith.drage@alcatel-lucent.com > Subject: Re: [AVT] rfc3984bis - max-smbps limit > > Hi, > > We got the following comment as a private email (bellow) . The draft has not > be published yet and we can do this change before publication. > Please review and send comments to the list since it changes the current > semantics. If there are no objections we will do this change. > Since this parameter has been added in the bis draft and was not part of RFC > 3984 we do not see any interoperability issues. > > Thanks > Roni Even > As a co-author of the draft > > > Email from Tom Kristensen > > I discovered missing alignment between H.241 MaxStaticMBPS and max-smbps as > defined in draft-ietf-avt-rtp-rfc3984bis. > > From Table 8-9, H.241: > --- > The encoder should recompute this value for each picture. > The value of (MaxStaticMBPS × 500) shall not be less than the value MaxMBPS > for the Level given in Table A-1/H.264, and if CustomMaxMBPS is signalled, > shall not be less than the value (CustomMaxMBPS × 500). > --- > > On the other hand in the SIP world, rfc3984bis says: > --- > The value of max-smbps MUST be greater than the value of MaxMBPS given in > Table A-1 of [1] for the highest level. > --- > http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-11#page-44 > > > H.241 says max-smbps>= max-mbps. > rfc3984bis says max-smbps> max-mbps. > We are missing "or equal". > > Of course it doesn't really make much meaning to include a max-smbps > equal to max-mbps, but we have a mismatch between H.241 and the SDP > counterpart. > > Is it possible and feasible to alter the text given the current state of > soon-to-be-RFC draft-ietf-avt-rtp-rfc3984bis? > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Sun Oct 3 05:48:10 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3123A6C4F for ; Sun, 3 Oct 2010 05:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.495 X-Spam-Level: X-Spam-Status: No, score=-99.495 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_BELOW2=2.154, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SiaP9nBFtz0 for ; Sun, 3 Oct 2010 05:48:09 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CB4E33A6C4C for ; Sun, 3 Oct 2010 05:48:08 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9P009PQSXE00@szxga04-in.huawei.com> for avt@ietf.org; Sun, 03 Oct 2010 20:48:51 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9P00K3KSXEQ1@szxga04-in.huawei.com> for avt@ietf.org; Sun, 03 Oct 2010 20:48:50 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-32-184.red.bezeqint.net [79.181.32.184]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9P00FMASX5E7@szxml02-in.huawei.com>; Sun, 03 Oct 2010 20:48:50 +0800 (CST) Date: Sun, 03 Oct 2010 14:46:32 +0200 From: Roni Even In-reply-to: <4CA8519B.6020707@tandberg.com> To: 'Tom Kristensen' , "'Mo Zanaty (mzanaty)'" Message-id: <01fd01cb62f9$07d74bc0$1785e340$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=windows-1255 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acti4EiT1GxpbyLPQBGRNB6I9P/QwQAGKpdA References: <4CA8519B.6020707@tandberg.com> Cc: 'Randell Jesup' , keith.drage@alcatel-lucent.com, 'IETF AVT WG' Subject: Re: [AVT] rfc3984bis - max-smbps limit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 12:48:10 -0000 Tom, Can you suggest a final text so that we can ask the AD what to do Roni > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Tom Kristensen > Sent: Sunday, October 03, 2010 11:49 AM > To: Mo Zanaty (mzanaty) > Cc: Randell Jesup; keith.drage@alcatel-lucent.com; IETF AVT WG; Roni > Even > Subject: Re: [AVT] rfc3984bis - max-smbps limit >=20 > Indeed, Mo, we have to take a potential max-mbps into account in the > description and the clarification of "highest level" also in the > max-smbps text part is just fine. >=20 > Even though "highest level" is described under a common heading for > these parameters, it is repeated for the other parameters. > Cf.: > max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: > These parameters MAY be used to signal the capabilities of = a > receiver implementation. These parameters MUST NOT be used > for any other purpose. The highest level conveyed in the > value of the profile-level-id parameter or the max-recv- > level > parameter MUST be such that the receiver is fully capable = of > supporting. >=20 > -- Tom >=20 > On 10/02/2010 03:08 PM, Mo Zanaty (mzanaty) wrote: > > The draft is missing more than just "or equal to". > > > >> The value of max-smbps MUST be greater than the value of MaxMBPS > given in > >> Table A-1 of [1] for the highest level. > > > > It should also take max-mbps into account. And the reference to > "highest level" has no antecedent in this section; it is in the prior > section on max-mbps. > > > > I suggest this [new] text: > > > > "The value of max-smbps MUST be greater than [or equal to] the value > of MaxMBPS given [explicitly in max-mbps or implicitly] in Table A-1 = of > [1] for the highest level [given in profile-level-id or max-recv- > level]." > > > > Regards, > > Mo > > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of > Roni Even > > Sent: Friday, October 01, 2010 4:49 PM > > To: 'IETF AVT WG' > > Cc: 'Randell Jesup'; 'Tom Kristensen'; = keith.drage@alcatel-lucent.com > > Subject: Re: [AVT] rfc3984bis - max-smbps limit > > > > Hi, > > > > We got the following comment as a private email (bellow) . The draft > has not > > be published yet and we can do this change before publication. > > Please review and send comments to the list since it changes the > current > > semantics. If there are no objections we will do this change. > > Since this parameter has been added in the bis draft and was not = part > of RFC > > 3984 we do not see any interoperability issues. > > > > Thanks > > Roni Even > > As a co-author of the draft > > > > > > Email from Tom Kristensen > > > > I discovered missing alignment between H.241 MaxStaticMBPS and max- > smbps as > > defined in draft-ietf-avt-rtp-rfc3984bis. > > > > From Table 8-9, H.241: > > --- > > The encoder should recompute this value for each picture. > > The value of (MaxStaticMBPS =AA 500) shall not be less than the = value > MaxMBPS > > for the Level given in Table A-1/H.264, and if CustomMaxMBPS is > signalled, > > shall not be less than the value (CustomMaxMBPS =AA 500). > > --- > > > > On the other hand in the SIP world, rfc3984bis says: > > --- > > The value of max-smbps MUST be greater than the value of MaxMBPS > given in > > Table A-1 of [1] for the highest level. > > --- > > http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-11#page-44 > > > > > > H.241 says max-smbps>=3D max-mbps. > > rfc3984bis says max-smbps> max-mbps. > > We are missing "or equal". > > > > Of course it doesn't really make much meaning to include a max-smbps > > equal to max-mbps, but we have a mismatch between H.241 and the SDP > > counterpart. > > > > Is it possible and feasible to alter the text given the current = state > of > > soon-to-be-RFC draft-ietf-avt-rtp-rfc3984bis? > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From gonzalo.camarillo@ericsson.com Mon Oct 4 03:18:17 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEA43A6F7B for ; Mon, 4 Oct 2010 03:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.403 X-Spam-Level: X-Spam-Status: No, score=-106.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kjEB1FiVJzD for ; Mon, 4 Oct 2010 03:18:16 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id EAD6D3A6F75 for ; Mon, 4 Oct 2010 03:18:15 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbfae00000264e-e4-4ca9aa1e3552 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F5.D0.09806.E1AA9AC4; Mon, 4 Oct 2010 12:19:10 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Oct 2010 12:19:10 +0200 Received: from [131.160.126.165] ([131.160.126.165]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Oct 2010 12:19:10 +0200 Message-ID: <4CA9AA1D.6030508@ericsson.com> Date: Mon, 04 Oct 2010 13:19:09 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: avt@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2010 10:19:10.0554 (UTC) FILETIME=[95E5ABA0:01CB63AD] X-Brightmail-Tracker: AAAAAA== Subject: [AVT] AD review: draft-ietf-avt-rtp-h264-rcdo-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 10:18:17 -0000 Hi, as part of a load balancing exercise between Robert and I, I will be acting as the responsible AD for this draft. https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-h264-rcdo/ Below you can find my AD review. As soon as the authors address these comments (it should be trivial to address them), I will IETF Last Call this draft. Thanks, Gonzalo The acronyms RTP and RCDO need to be expanded in the title of the draft. In general, all acronyms need to be expanded on their first use. The document refers to [3] as RFC3984bis. Given that [3] is a normative reference, this document will not be published until [3] is published as well. So, referring to it as, say, RFCYYYY and then get the RFC Editor to update the text seems like a better option than calling it RFC3984bis. Page 19: section X should be section 9. Section 9: "although if suitable the usage of SRTP [11] is recommended". Should that be a normative RECOMMENDED instead? The draft should have a reference to the SDP spec: RFC 4566. From magnus.westerlund@ericsson.com Mon Oct 4 04:58:42 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2543A6F86; Mon, 4 Oct 2010 04:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.453 X-Spam-Level: X-Spam-Status: No, score=-106.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CIqODIASNaF; Mon, 4 Oct 2010 04:58:41 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 523313A6F6F; Mon, 4 Oct 2010 04:58:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbfae00000264e-16-4ca9c1a62170 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 51.42.09806.6A1C9AC4; Mon, 4 Oct 2010 13:59:34 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Oct 2010 13:59:33 +0200 Received: from [147.214.183.82] ([147.214.183.82]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Oct 2010 13:59:33 +0200 Message-ID: <4CA9C1A5.9080508@ericsson.com> Date: Mon, 04 Oct 2010 13:59:33 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <20100914165611.21618.35586.idtracker@localhost> <4CA33861.5070603@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Oct 2010 11:59:33.0801 (UTC) FILETIME=[9C083990:01CB63BB] X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org" , ietf , "avt@ietf.org" Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 11:58:42 -0000 Hi, Responses inline. Ali C. Begen (abegen) skrev 2010-09-29 17:32: > Hi Magnus, > > We are all glad to have you back. Comments are inline. We will get these into the revision. See inline. > >> I have the following comments on this document, I think version 7 or 8 >> was the last version I read before my parental leave. >> >> >> 1. Applicability statement: I think this document should have an >> applicability statement making clear that this is only for engineered >> environments due to the traffic bursts. > > We already put a lot of effort to explain the precautions for using this in BE networks. I don't think there is a strong argument here that this will only work in engineered networks. So, personally I don't think we should put such a statement. I can agree that it works in certain type of best-effort networks. However, I don't think at all it is suitable for any best-effort network. However, as this is mostly bound by the requirement to also support SSM in the same network the deployment cases are usually meeting the assumptions about network capacity. However, if one runs an multicast overlay and a client starts up with not congestion or network capacity information and does a RAMS-R it can severely congest a network for a few seconds. There are a number of assumptions in where this will work most of the time and with very few exceptions have any large scale impact on the network. I think these should be documented in an applicability statement. > >> 2. Section 6.2, bullet 5: I don't think the document is clear on that >> the BRS is expected to determine if a RAMS-R is a retransmission or an >> update based on if any content of the message has been changed. > > The statement over there implies this. And naturally it is the server's job to figure that out. Based on this discussion, we even wrote the new CNAME guidelines document so that the server's job would get easier. Exactly the document implies rather than being explicit. I am not certain that I have understood all the mechanism you expect me to use to determine if a RAMS-R is a retransmission or a new request. Based on that it is uncertain for a client to know what effect an RAMS-R message will have. I also think it makes sense to mandate that servers do have retransmission detection, otherwise you end up in a situation where a client don't dare retransmit a request for the fear of getting two bursts. > >> 3. I worried that what is intended to be an RAMS-R update from the >> client will be interpreted as new RAMS-R request. The reason is the only >> that separates these two cases are timing, does it arrive before the >> burst ends or not. Relying on this heuristics is quite weak and error >> prone. I still wished that an sequence number had been added to RAMS-R. > > I gave enough arguments why we should not use a seqnum for the RAMS-R messages earlier. It is not justified IMO. Based on the SSRC of the primary and the requesting client's CNAME, things are pretty straightforward. Yes, I know I am in the rough here. From my perspective, it makes the use of update RAMS-R uncertain to use. Maybe not a big issue if most doesn't implement updates. But if one finds need for it then there will be issues. Consider the AD and IESG notified about the potential issue. > >> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a globally >> unique CNAME identifier." >> >> I don't think this is a statement that can either be fulfilled nor >> tested. You can mandate a method for selecting CNAMEs that has low risk >> of producing CNAME collisions, but nothing can guarantee it unless a >> entity is coordinating the CNAME space for all clients. Can you mandate >> the method instead? > > The new CNAME draft has ways to ensure they are unique. If the client uses one of them, we are all set. Yes, but in that case mandate the implementation and usage of one of these instead of statement that can't be ensured. > >> If I understand the impact of a CNAME collision is that the collision >> clients request will be mixed up, for example terminating each others >> request, or update the values in the RAMS-R. > > When they are unique, this won't happen. Just checking, but if that is the case then I am missing a discussion of hijacking attacks in the security consideration section by guessing your targets CNAME. > >> 5. Section 6.4 and others: The draft has a tendency of formulating >> itself as everything is guaranteed to work as long as one keep within >> given limits for bandwidth etc. An example from Section 7.2 Max Receive >> Bitrate TLV: > > We don't assume things will sure work or guarantee that they will work if everything is satisfied. These are simple rules that both sides must comply with. No, but a certain view point is clear in the text. Lets call it optimistic that it will work, while I would write from a more pessimistic view. > >> If specified, the total bitrate of the unicast burst(s) plus any >> payload-specific information MUST NOT be larger than this value. >> Otherwise, congestion and packet loss may occur. >> >> The last sentence I would formulate as: >> "Otherwise, congestion and packet loss are much likelier to occur" > > How about "more likely to occur"? Sure. > >> Even if one stays within this value congestion and packet loss may >> occur. This is not the only case, but when I actually decided this seems >> to be an issue, I hadn't taken note of all examples I seen. >> >> 6. Section 7: >> >> Each feedback message has a fixed-length field for version, padding, >> feedback message type (FMT), payload type (PT), length, SSRC of >> packet sender, SSRC of media sender as well as a variable-length >> field for feedback control information (FCI). >> >> >> What is called "Payload type" is actually "Packet Type" in RTCP packet >> headers. > > We followed the definition from 4585 but "packet type" makes more sense to me as well. Well, section 6.1 of RFC 4585 is wrong. > >> 7. Section 7.3: >> "The MSN value SHALL >> be set to zero only when a new RAMS request is received." >> >> How is that actually known? And why reset it at all? Why not increase if >> for each new RAMS-I message with new content, independently if it is an >> update or a new request. > > If this is relating to a new burst request, then it is reset. Ow, what is the point of having a seqnum? If something has changed compared to the previous RAMS-I, then MSN is incremented. If it is just a re-xmit, MSN stays the same. I fully agree with the need for separating retransmissions from updates. However, I wonder over the reset of the field for each new RAMS-R. It appears to me to be more robust to simply increment it rather than reset. Otherwise you can send RAMS-R(1) resulting in RAMS-I MSN = 0. Then a RAMS-R(2) that is intended to be an update but becomes an new request results in an RAMS-I with MSN = 0. The client will not know if this is an retransmission of RAMS-R(1) info. The updated should result in MSN=1. So without comparing the RAMS-I you can't determine if there is new information. Going my way (no reset) does not allow a client to determine if an RAMS-R was treated as update or new request, but it will correctly know that it is new RAMS-I information. > >> 8. Section 7.3: >> "When the RTP_Rx receives a RAMS-I message with a response code >> that it does not understand, the RTP_Rx MUST send a RAMS-T message >> immediately to the BRS." >> >> Which media sender SSRC should the client direct this request to if it >> hasn't been signalled in SDP nor any RTP/RTCP packets received? > > The rules in the RAMS-T section applies. You received a RAMS-I so you know the SSRC. Yes, you are correct. My mistake. > >> 9. Section 7.3, Media Sender SSRC TLV: >> " While this >> information is already available in the message header, it can be >> useful to repeat it in an explicit field." >> >> This sentence seems out of place compared to the rest of the text. > > If I recall correctly, this was something you asked for. I am not sure whether there is a better place to put it. Maybe in parentheses? I think we can remove that sentence. I think you now have text making clear when it needs to be included and when it shouldn't. > >> 10. Section 7.3, RTP Seqnum of the First Packet TLV: >> >> How is this TLV bound to the SSRC number if is for? This is not >> explicitly explained. > > What do you mean? The SSRC comes from the RAMS-I's SSRC. There is one (not multiple) stream per RAMS-I. Yes, something that I apparently have forgotten. > >> 11. Section 7.4: >> Each of these RAMS-T messages has >> the appropriate media sender SSRC populated in its message header. >> >> Instead of writing "appropriate" cant you simply write " Each of these >> RAMS-T message's media sender SSRC SHALL BE populated with the SSRC of >> the Media Stream to be terminated." > > Good suggestion. > >> 12. Section 8.3: >> "This section provides a declarative SDP [RFC4566] example for >> enabling rapid acquisition of multicast RTP sessions." >> >> Can you make clear that this an example of an SDP to be provided to a >> client? > > OK. > >> 13. Section 9, bullet b: >> Be configured to forward certain ports (e.g., using HTML >> configuration and UPnP IGD [UPnP-IGD]). >> >> Shouldn't the "and" be an "or"? > > Yes, good catch. > >> 14. Section 10: >> >> Shouldn't the security consideration make it clear that RAMS-R are >> especially suspectible to Replay attacks as there is no information in >> the packet that one can use to detect that it is out of sequence. > > There is a wording about this in that section (which simply refers the reader to 5760). Are you considering a RAMS-specific replay attack here? Yes, I am considering that it is easy to target RAMS-R specifically for an replay attack. Especially when sent in a reduced size RTCP packet only containing RAMS-R and SDES CNAME. That has no time specific information and all replay detection must happen in the security protocol. 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 gonzalo.camarillo@ericsson.com Mon Oct 4 05:55:22 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8311C3A6F8C for ; Mon, 4 Oct 2010 05:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.407 X-Spam-Level: X-Spam-Status: No, score=-106.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIJrF2-SfrGx for ; Mon, 4 Oct 2010 05:55:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 745403A6F96 for ; Mon, 4 Oct 2010 05:55:21 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-72-4ca9ceef00c5 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D8.D7.27351.FEEC9AC4; Mon, 4 Oct 2010 14:56:15 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Oct 2010 14:53:13 +0200 Received: from [131.160.126.165] ([131.160.126.165]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Oct 2010 14:53:12 +0200 Message-ID: <4CA9CE38.1040802@ericsson.com> Date: Mon, 04 Oct 2010 15:53:12 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: avt@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2010 12:53:12.0585 (UTC) FILETIME=[1A93AF90:01CB63C3] X-Brightmail-Tracker: AAAAAA== Subject: [AVT] AD review: draft-ietf-avt-rtp-svc-22 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 12:55:22 -0000 Hi, as part of a load balancing exercise between Robert and I, I will be acting as the responsible AD for this draft. https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-svc/ Below you can find my AD review. As soon as the authors address these comments (it should be trivial to address them), I will IETF Last Call this draft. Thanks, Gonzalo The acronyms RTP and SVC need to be expanded in the title. All acronyms in the draft need to be expanded on their first use. Section 1.2.2 has a few non-normative statements such as "SST should be used...". This normatively specified at a later point in the document (Section 4.4). If Section 1 is meant to be a non-normative overview of the specification, the draft should say so somewhere. Page 80. When specifying behavior beyond RFC 3264, the draft should use normative language. However, when specifying behavior that is already specified in RFC 3264, the draft should not use normative language. For example: "the offer SHOULD also be used in the answer, as specified in [RFC3264]". This issue also appears in other sections in the document (e.g., in page 85). Simply s/SHOULD/should/ would resolve the issue, for instance. From abegen@cisco.com Mon Oct 4 05:57:32 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DBA33A6F97; Mon, 4 Oct 2010 05:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUjiUr49cXxf; Mon, 4 Oct 2010 05:57:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 11B1F3A6F8C; Mon, 4 Oct 2010 05:57:31 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADdsqUyrRN+K/2dsb2JhbACiQXGlEptihUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,278,1283731200"; d="scan'208";a="367747521" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2010 12:58:26 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o94CwQA4008021; Mon, 4 Oct 2010 12:58:26 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Oct 2010 05:58:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Oct 2010 05:57:58 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4CA9C1A5.9080508@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard Thread-Index: Actju6YiZZFZPMoaQY60RcFDl4zK3wABAGJg References: <20100914165611.21618.35586.idtracker@localhost> <4CA33861.5070603@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com> <4CA9C1A5.9080508@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 04 Oct 2010 12:58:26.0306 (UTC) FILETIME=[D591B620:01CB63C3] Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org, ietf , avt@ietf.org Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 12:57:32 -0000 Hi Magnus, > >> 1. Applicability statement: I think this document should have an > >> applicability statement making clear that this is only for = engineered > >> environments due to the traffic bursts. > > > > We already put a lot of effort to explain the precautions for using = this in BE networks. I don't think there is a strong > argument here that this will only work in engineered networks. So, = personally I don't think we should put such a statement. >=20 > I can agree that it works in certain type of best-effort networks. > However, I don't think at all it is suitable for any best-effort > network. However, as this is mostly bound by the requirement to also > support SSM in the same network the deployment cases are usually = meeting > the assumptions about network capacity. However, if one runs an > multicast overlay and a client starts up with not congestion or = network That is a bit stretch :) > capacity information and does a RAMS-R it can severely congest a = network > for a few seconds. Well we have rules how the server is supposed to send the burst (rate, = timing, etc.) documented in the text. It explains what the server does. =20 > There are a number of assumptions in where this will work most of the > time and with very few exceptions have any large scale impact on the > network. I think these should be documented in an applicability = statement. At the end of intro, I think we can put a few sentences about this. =20 > >> 2. Section 6.2, bullet 5: I don't think the document is clear on = that > >> the BRS is expected to determine if a RAMS-R is a retransmission or = an > >> update based on if any content of the message has been changed. > > > > The statement over there implies this. And naturally it is the = server's job to figure that out. Based on this discussion, we > even wrote the new CNAME guidelines document so that the server's job = would get easier. >=20 > Exactly the document implies rather than being explicit. I am not Actually, I re-read it and it is pretty explicit. The text says it = checks client's CNAME (which must be unique). If the server is already = processing a request from the same client for the same SSRC, then it is = a update. Ow, it is a new request. I can repeat the above in the text if you think it is necessary. > certain that I have understood all the mechanism you expect me to use = to > determine if a RAMS-R is a retransmission or a new request. Based on > that it is uncertain for a client to know what effect an RAMS-R = message > will have. I also think it makes sense to mandate that servers do have > retransmission detection, otherwise you end up in a situation where a > client don't dare retransmit a request for the fear of getting two = bursts. OK what if the text said: =20 Updated Request: The RTP_Rx MAY send an updated RAMS-R message (as unicast feedback in the primary multicast RTP session) with a different value for one or more fields of an earlier RAMS-R message. The RS MUST be able to detect whether a burst is = already planned for or being transmitted to this particular RTP_Rx for = this particular media source SSRC. If there is an existing burst planned = for or being transmitted, the newly arriving RAMS-R is an updated = request; otherwise it is a new request... =20 > >> 3. I worried that what is intended to be an RAMS-R update from the > >> client will be interpreted as new RAMS-R request. The reason is the = only > >> that separates these two cases are timing, does it arrive before = the > >> burst ends or not. Relying on this heuristics is quite weak and = error > >> prone. I still wished that an sequence number had been added to = RAMS-R. > > > > I gave enough arguments why we should not use a seqnum for the = RAMS-R messages earlier. It is not justified IMO. Based > on the SSRC of the primary and the requesting client's CNAME, things = are pretty straightforward. >=20 > Yes, I know I am in the rough here. From my perspective, it makes the > use of update RAMS-R uncertain to use. Maybe not a big issue if most > doesn't implement updates. But if one finds need for it then there = will > be issues. Consider the AD and IESG notified about the potential = issue. Is the updated text above good for you? =20 > > > >> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a globally > >> unique CNAME identifier." > >> > >> I don't think this is a statement that can either be fulfilled nor > >> tested. You can mandate a method for selecting CNAMEs that has low = risk > >> of producing CNAME collisions, but nothing can guarantee it unless = a > >> entity is coordinating the CNAME space for all clients. Can you = mandate > >> the method instead? > > > > The new CNAME draft has ways to ensure they are unique. If the = client uses one of them, we are all set. >=20 > Yes, but in that case mandate the implementation and usage of one of > these instead of statement that can't be ensured. Personally, this is one what I did initially but then we agreed that one = could come up with an alternative method that would produce unique = CNAMEs. In other words, methods for producing unique CNAMEs are not = unique. So, we rather put the "MUST" in the sentence above not for the = specific implementation. > >> If I understand the impact of a CNAME collision is that the = collision > >> clients request will be mixed up, for example terminating each = others > >> request, or update the values in the RAMS-R. > > > > When they are unique, this won't happen. >=20 > Just checking, but if that is the case then I am missing a discussion = of > hijacking attacks in the security consideration section by guessing = your > targets CNAME. We should probably mention this but I am not sure how the server can = deal with this. Hijacking is not easy since the attack must take place = at the same instant (more or less) with the request from the authentic = client. One of your family members can probably do this :) =20 > >> 5. Section 6.4 and others: The draft has a tendency of formulating > >> itself as everything is guaranteed to work as long as one keep = within > >> given limits for bandwidth etc. An example from Section 7.2 Max = Receive > >> Bitrate TLV: > > > > We don't assume things will sure work or guarantee that they will = work if everything is satisfied. These are simple rules > that both sides must comply with. >=20 > No, but a certain view point is clear in the text. Lets call it > optimistic that it will work, while I would write from a more > pessimistic view. Things may go wrong anytime, and we do ack that in the paper and have = solutions. But if one does not comply with the rules, more things will = likely go wrong. =20 > >> 6. Section 7: > >> > >> Each feedback message has a fixed-length field for version, = padding, > >> feedback message type (FMT), payload type (PT), length, SSRC of > >> packet sender, SSRC of media sender as well as a variable-length > >> field for feedback control information (FCI). > >> > >> > >> What is called "Payload type" is actually "Packet Type" in RTCP = packet > >> headers. > > > > We followed the definition from 4585 but "packet type" makes more = sense to me as well. >=20 > Well, section 6.1 of RFC 4585 is wrong. OK, "packet type" it is then. =20 > > > >> 7. Section 7.3: > >> "The MSN value SHALL > >> be set to zero only when a new RAMS request is received." > >> > >> How is that actually known? And why reset it at all? Why not = increase if > >> for each new RAMS-I message with new content, independently if it = is an > >> update or a new request. > > > > If this is relating to a new burst request, then it is reset. Ow, = what is the point of having a seqnum? If something has > changed compared to the previous RAMS-I, then MSN is incremented. If = it is just a re-xmit, MSN stays the same. >=20 > I fully agree with the need for separating retransmissions from = updates. > However, I wonder over the reset of the field for each new RAMS-R. It > appears to me to be more robust to simply increment it rather than > reset. Otherwise you can send RAMS-R(1) resulting in RAMS-I MSN =3D 0. I think we discussed this before. The RAMS-R numbers are no way = correlated with the RAMS-I numbers. You are still trying to correlate = them. > Then a RAMS-R(2) that is intended to be an update but becomes an new > request results in an RAMS-I with MSN =3D 0. The client will not know = if > this is an retransmission of RAMS-R(1) info. The updated should result > in MSN=3D1. So without comparing the RAMS-I you can't determine if = there The client checks the RAMS-I seqnum to see whether it is a repeat or new = info. If RAMS-I MSN is zero, that is the first RAMS-I anyway so it must = be fully parsed. Does not matter which RAMS-R actually generated it = since that is the info from the server until an updated RAMS-I is = received. This is how the protocol works. > is new information. Going my way (no reset) does not allow a client to > determine if an RAMS-R was treated as update or new request, but it = will > correctly know that it is new RAMS-I information. The server cannot keep state information (i.e. tracking RAMS-R numbers) = across different sessions. Furthermore, requests for different streams = can go to different servers. =20 > >> 9. Section 7.3, Media Sender SSRC TLV: > >> " While this > >> information is already available in the message header, it = can be > >> useful to repeat it in an explicit field." > >> > >> This sentence seems out of place compared to the rest of the text. > > > > If I recall correctly, this was something you asked for. I am not = sure whether there is a better place to put it. Maybe in > parentheses? >=20 > I think we can remove that sentence. I think you now have text making > clear when it needs to be included and when it shouldn't. Ok. =20 > >> 14. Section 10: > >> > >> Shouldn't the security consideration make it clear that RAMS-R are > >> especially suspectible to Replay attacks as there is no information = in > >> the packet that one can use to detect that it is out of sequence. > > > > There is a wording about this in that section (which simply refers = the reader to 5760). Are you considering a RAMS-specific > replay attack here? >=20 >=20 > Yes, I am considering that it is easy to target RAMS-R specifically = for > an replay attack. Especially when sent in a reduced size RTCP packet > only containing RAMS-R and SDES CNAME. That has no time specific > information and all replay detection must happen in the security = protocol. The Token stuff (or the cookie stuff) will avoid request messages from = being sent by others (it will do at least a reverse path check). Beyond = that is not SRTCP a good solution to avoid this? -acbegen From csp@csperkins.org Mon Oct 4 06:03:46 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E623A6F8C for ; Mon, 4 Oct 2010 06:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKNSqjpv6wOW for ; Mon, 4 Oct 2010 06:03:45 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 871C63A6F87 for ; Mon, 4 Oct 2010 06:03:45 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.17]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P2kie-0006PN-aL; Mon, 04 Oct 2010 13:04:40 +0000 Message-Id: <4EF79274-8451-4BEA-8689-C7D62CCC3ED0@csperkins.org> From: Colin Perkins To: Gonzalo Camarillo In-Reply-To: <4CA9CE38.1040802@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 4 Oct 2010 14:04:38 +0100 References: <4CA9CE38.1040802@ericsson.com> X-Mailer: Apple Mail (2.936) Cc: "avt@ietf.org WG" Subject: Re: [AVT] AD review: draft-ietf-avt-rtp-svc-22 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 13:03:46 -0000 On 4 Oct 2010, at 13:53, Gonzalo Camarillo wrote: > as part of a load balancing exercise between Robert and I, I will be > acting as the responsible AD for this draft. > > https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-svc/ > > Below you can find my AD review. As soon as the authors address these > comments (it should be trivial to address them), I will IETF Last Call > this draft. > > Thanks, > > Gonzalo > > > The acronyms RTP and SVC need to be expanded in the title. All > acronyms > in the draft need to be expanded on their first use. Unless their policy has changed recently, RTP is one of the few well- known acronyms the RFC editor allows to be used without expansion in document titles. > Section 1.2.2 has a few non-normative statements such as "SST should > be used...". This normatively specified at a later point in the > document (Section 4.4). If Section 1 is meant to be a non-normative > overview of the specification, the draft should say so somewhere. > > Page 80. When specifying behavior beyond RFC 3264, the draft should > use normative language. However, when specifying behavior that is > already specified in RFC 3264, the draft should not use normative > language. For example: "the offer SHOULD also be used in the answer, > as specified in [RFC3264]". This issue also appears in other sections > in the document (e.g., in page 85). Simply s/SHOULD/should/ would > resolve the issue, for instance. -- Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Mon Oct 4 08:37:23 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0683A6FCB; Mon, 4 Oct 2010 08:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.138 X-Spam-Level: X-Spam-Status: No, score=-106.138 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ctKYSzkesEY; Mon, 4 Oct 2010 08:37:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E1DCD3A6FD9; Mon, 4 Oct 2010 08:37:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbfae00000264e-08-4ca9f4e6092c Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 71.D1.09806.6E4F9AC4; Mon, 4 Oct 2010 17:38:14 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Oct 2010 17:38:14 +0200 Received: from [147.214.183.82] ([147.214.183.82]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Oct 2010 17:38:13 +0200 Message-ID: <4CA9F4E5.2020402@ericsson.com> Date: Mon, 04 Oct 2010 17:38:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <20100914165611.21618.35586.idtracker@localhost> <4CA33861.5070603@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com> <4CA9C1A5.9080508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Oct 2010 15:38:13.0350 (UTC) FILETIME=[27E48860:01CB63DA] X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org" , ietf , "avt@ietf.org" Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 15:37:23 -0000 Ali C. Begen (abegen) skrev 2010-10-04 14:57: > Hi Magnus, > >>>> 1. Applicability statement: I think this document should have an >>>> applicability statement making clear that this is only for engineered >>>> environments due to the traffic bursts. >>> >>> We already put a lot of effort to explain the precautions for using this in BE networks. I don't think there is a strong >> argument here that this will only work in engineered networks. So, personally I don't think we should put such a statement. >> >> I can agree that it works in certain type of best-effort networks. >> However, I don't think at all it is suitable for any best-effort >> network. However, as this is mostly bound by the requirement to also >> support SSM in the same network the deployment cases are usually meeting >> the assumptions about network capacity. However, if one runs an >> multicast overlay and a client starts up with not congestion or network > > That is a bit stretch :) > >> capacity information and does a RAMS-R it can severely congest a network >> for a few seconds. > > Well we have rules how the server is supposed to send the burst (rate, timing, etc.) documented in the text. It explains what the server does. > >> There are a number of assumptions in where this will work most of the >> time and with very few exceptions have any large scale impact on the >> network. I think these should be documented in an applicability statement. > > At the end of intro, I think we can put a few sentences about this. Ok, I guess I have to live with that. > >>>> 2. Section 6.2, bullet 5: I don't think the document is clear on that >>>> the BRS is expected to determine if a RAMS-R is a retransmission or an >>>> update based on if any content of the message has been changed. >>> >>> The statement over there implies this. And naturally it is the server's job to figure that out. Based on this discussion, we >> even wrote the new CNAME guidelines document so that the server's job would get easier. >> >> Exactly the document implies rather than being explicit. I am not > > Actually, I re-read it and it is pretty explicit. The text says it checks client's CNAME (which must be unique). If the server is already processing a request from the same client for the same SSRC, then it is a update. Ow, it is a new request. > > I can repeat the above in the text if you think it is necessary. > >> certain that I have understood all the mechanism you expect me to use to >> determine if a RAMS-R is a retransmission or a new request. Based on >> that it is uncertain for a client to know what effect an RAMS-R message >> will have. I also think it makes sense to mandate that servers do have >> retransmission detection, otherwise you end up in a situation where a >> client don't dare retransmit a request for the fear of getting two bursts. > > OK what if the text said: > > Updated Request: The RTP_Rx MAY send an updated RAMS-R message > (as unicast feedback in the primary multicast RTP session) with > a different value for one or more fields of an earlier RAMS-R > message. The RS MUST be able to detect whether a burst is already planned for or being transmitted to this particular RTP_Rx for this particular media source SSRC. If there is an existing burst planned for or being transmitted, the newly arriving RAMS-R is an updated request; otherwise it is a new request... > Better. >>>> 3. I worried that what is intended to be an RAMS-R update from the >>>> client will be interpreted as new RAMS-R request. The reason is the only >>>> that separates these two cases are timing, does it arrive before the >>>> burst ends or not. Relying on this heuristics is quite weak and error >>>> prone. I still wished that an sequence number had been added to RAMS-R. >>> >>> I gave enough arguments why we should not use a seqnum for the RAMS-R messages earlier. It is not justified IMO. Based >> on the SSRC of the primary and the requesting client's CNAME, things are pretty straightforward. >> >> Yes, I know I am in the rough here. From my perspective, it makes the >> use of update RAMS-R uncertain to use. Maybe not a big issue if most >> doesn't implement updates. But if one finds need for it then there will >> be issues. Consider the AD and IESG notified about the potential issue. > > Is the updated text above good for you? Not, really, because it has only clarified the issue. The issue is really the uncertainty for the client how its request will be interpreted, either as updated request or a new request, all depending on timing. The biggest issue is the updated request which might be interpreted as new request, when the client is likely satisfied and might even have gone one to join the multicast group when the RAMS-R(update) is processed as a new RAMS-R. Then causing congestion and unwanted traffic. The client that detects this can surely terminate the burst, but that will be after some delay, and traffic has arrived. > >>> >>>> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a globally >>>> unique CNAME identifier." >>>> >>>> I don't think this is a statement that can either be fulfilled nor >>>> tested. You can mandate a method for selecting CNAMEs that has low risk >>>> of producing CNAME collisions, but nothing can guarantee it unless a >>>> entity is coordinating the CNAME space for all clients. Can you mandate >>>> the method instead? >>> >>> The new CNAME draft has ways to ensure they are unique. If the client uses one of them, we are all set. >> >> Yes, but in that case mandate the implementation and usage of one of >> these instead of statement that can't be ensured. > > Personally, this is one what I did initially but then we agreed that one could come up with an alternative method that would produce unique CNAMEs. In other words, methods for producing unique CNAMEs are not unique. So, we rather put the "MUST" in the sentence above not for the specific implementation. Okay, I might be nit picking then to request that the text is changed to "Thus, the RTP_Rx MUST use a method that ensure it uses an unique CNAME identifier." I don't think globally is the correct scope, it is unnecessary big, when only needs to be unique within this particular instance of a system. > >>>> If I understand the impact of a CNAME collision is that the collision >>>> clients request will be mixed up, for example terminating each others >>>> request, or update the values in the RAMS-R. >>> >>> When they are unique, this won't happen. >> >> Just checking, but if that is the case then I am missing a discussion of >> hijacking attacks in the security consideration section by guessing your >> targets CNAME. > > We should probably mention this but I am not sure how the server can deal with this. Hijacking is not easy since the attack must take place at the same instant (more or less) with the request from the authentic client. One of your family members can probably do this :) The real solution is where you have an more permanent id system in place that you can connect through source authentication of the requests. In an SSM session that uses simple feedback model the RTP_Rx cname may leak as they are redistributed. Based on that you could bombard a BRS with RAMS-T for example for all known CNAMES and do that in a round-robin fashion across channels and time. Depending on source address spoofing you will more or less easy to find. But I do agree that it becomes a little bit more a brute force attack, but an attacker could gain knowledge about an important piece of information to mount the attack at all. > >>>> 5. Section 6.4 and others: The draft has a tendency of formulating >>>> itself as everything is guaranteed to work as long as one keep within >>>> given limits for bandwidth etc. An example from Section 7.2 Max Receive >>>> Bitrate TLV: >>> >>> We don't assume things will sure work or guarantee that they will work if everything is satisfied. These are simple rules >> that both sides must comply with. >> >> No, but a certain view point is clear in the text. Lets call it >> optimistic that it will work, while I would write from a more >> pessimistic view. > > Things may go wrong anytime, and we do ack that in the paper and have solutions. But if one does not comply with the rules, more things will likely go wrong. > It is a writing style thing and I think we can stop the discussion. >>>> 6. Section 7: >>>> >>>> Each feedback message has a fixed-length field for version, padding, >>>> feedback message type (FMT), payload type (PT), length, SSRC of >>>> packet sender, SSRC of media sender as well as a variable-length >>>> field for feedback control information (FCI). >>>> >>>> >>>> What is called "Payload type" is actually "Packet Type" in RTCP packet >>>> headers. >>> >>> We followed the definition from 4585 but "packet type" makes more sense to me as well. >> >> Well, section 6.1 of RFC 4585 is wrong. > > OK, "packet type" it is then. > Great. >>> >>>> 7. Section 7.3: >>>> "The MSN value SHALL >>>> be set to zero only when a new RAMS request is received." >>>> >>>> How is that actually known? And why reset it at all? Why not increase if >>>> for each new RAMS-I message with new content, independently if it is an >>>> update or a new request. >>> >>> If this is relating to a new burst request, then it is reset. Ow, what is the point of having a seqnum? If something has >> changed compared to the previous RAMS-I, then MSN is incremented. If it is just a re-xmit, MSN stays the same. >> >> I fully agree with the need for separating retransmissions from updates. >> However, I wonder over the reset of the field for each new RAMS-R. It >> appears to me to be more robust to simply increment it rather than >> reset. Otherwise you can send RAMS-R(1) resulting in RAMS-I MSN = 0. > > I think we discussed this before. The RAMS-R numbers are no way correlated with the RAMS-I numbers. You are still trying to correlate them. Nope, the number here are still only to indicate that they are different to get the sequence right. My point is that the client can determine based on MSN if it is an repeat or a new RAMS-I based on a new request. > >> Then a RAMS-R(2) that is intended to be an update but becomes an new >> request results in an RAMS-I with MSN = 0. The client will not know if >> this is an retransmission of RAMS-R(1) info. The updated should result >> in MSN=1. So without comparing the RAMS-I you can't determine if there > > The client checks the RAMS-I seqnum to see whether it is a repeat or new info. If RAMS-I MSN is zero, that is the first RAMS-I anyway so it must be fully parsed. Does not matter which RAMS-R actually generated it since that is the info from the server until an updated RAMS-I is received. This is how the protocol works. As I try to explain there is a case where you can get two RAMS-I with MSN=0 in a row with different information. Thus not providing any relieve for the client in the need to compare the whole request with the previous one. > >> is new information. Going my way (no reset) does not allow a client to >> determine if an RAMS-R was treated as update or new request, but it will >> correctly know that it is new RAMS-I information. > > The server cannot keep state information (i.e. tracking RAMS-R numbers) across different sessions. Furthermore, requests for different streams can go to different servers. > No, I am not talking about RAMS-R number here. I am talking about RAMS-I MSN numbers, that they shouldn't be kept. But I see your point in that you don't want to keep CNAME,SSRC => MSN counter mappings. But in that case, I think we should make it clear that a client that has sent a RAMS-R (update) must check if the RAMS-I information is same or different to determine if the server interpreted the update as a new request. >>>> 14. Section 10: >>>> >>>> Shouldn't the security consideration make it clear that RAMS-R are >>>> especially suspectible to Replay attacks as there is no information in >>>> the packet that one can use to detect that it is out of sequence. >>> >>> There is a wording about this in that section (which simply refers the reader to 5760). Are you considering a RAMS-specific >> replay attack here? >> >> >> Yes, I am considering that it is easy to target RAMS-R specifically for >> an replay attack. Especially when sent in a reduced size RTCP packet >> only containing RAMS-R and SDES CNAME. That has no time specific >> information and all replay detection must happen in the security protocol. > > The Token stuff (or the cookie stuff) will avoid request messages from being sent by others (it will do at least a reverse path check). Beyond that is not SRTCP a good solution to avoid this? SRTCP is if keyed correctly a good solution yes. My point is that one normally document the vulnerability and then ensure that one has a remedy for it. When it comes to the token stuff I am not certain that it helps against a replay attack. Unless the token has expired on the server you still will get traffic to the target. That is why I think a reverse path check when you start delivering should happen. Because first in that case if there is no listener at the indicated address and port will you find out that you are attempting a delivery not intended. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Mon Oct 4 09:06:05 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C483A6FF5; Mon, 4 Oct 2010 09:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.253 X-Spam-Level: X-Spam-Status: No, score=-10.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id turqcvZvrUa5; Mon, 4 Oct 2010 09:06:03 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 015F63A6FD6; Mon, 4 Oct 2010 09:06:02 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMuYqUyrR7Hu/2dsb2JhbACiQ3GoSZwMhUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,279,1283731200"; d="scan'208";a="367815398" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2010 16:05:42 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o94G51kP023935; Mon, 4 Oct 2010 16:05:01 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Oct 2010 09:05:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Oct 2010 09:04:52 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D4FA9A8@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4CA9F4E5.2020402@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard Thread-Index: Actj2i8xyd0LXzBpSSiOcJRdCBxJqQAAKxBw References: <20100914165611.21618.35586.idtracker@localhost> <4CA33861.5070603@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com> <4CA9C1A5.9080508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com> <4CA9F4E5.2020402@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 04 Oct 2010 16:05:01.0029 (UTC) FILETIME=[E624E150:01CB63DD] Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org, ietf , avt@ietf.org Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:06:05 -0000 I am glad that we are converging on something. > >>>> 3. I worried that what is intended to be an RAMS-R update from = the > >>>> client will be interpreted as new RAMS-R request. The reason is = the only > >>>> that separates these two cases are timing, does it arrive before = the > >>>> burst ends or not. Relying on this heuristics is quite weak and = error > >>>> prone. I still wished that an sequence number had been added to = RAMS-R. > >>> > >>> I gave enough arguments why we should not use a seqnum for the = RAMS-R messages earlier. It is not justified IMO. > Based > >> on the SSRC of the primary and the requesting client's CNAME, = things are pretty straightforward. > >> > >> Yes, I know I am in the rough here. From my perspective, it makes = the > >> use of update RAMS-R uncertain to use. Maybe not a big issue if = most > >> doesn't implement updates. But if one finds need for it then there = will > >> be issues. Consider the AD and IESG notified about the potential = issue. > > > > Is the updated text above good for you? >=20 > Not, really, because it has only clarified the issue. The issue is > really the uncertainty for the client how its request will be > interpreted, either as updated request or a new request, all depending > on timing. The biggest issue is the updated request which might be > interpreted as new request, when the client is likely satisfied and Why is this a problem? For this to happen, the initial request must have = been lost. And if it is lost and the second makes it, the client still = gets what it wants. I don't see a problem here. > might even have gone one to join the multicast group when the > RAMS-R(update) is processed as a new RAMS-R. Then causing congestion = and Are you saying this: 1- The client makes a request but it gets lost. In the mean time, the = client sends an update and the server thinks it is a new request and = starts sending the burst 2- In the mean time, client gives up and joins the multicast anyway. 3- Burst + mcast creates a congestion. > unwanted traffic. The client that detects this can surely terminate = the > burst, but that will be after some delay, and traffic has arrived. OK, so you are saying what I wrote above. Well, the client has to send a = RAMS-T and upon receiving it, the server stops the burst. So that is not = a big deal. If you are concerned about RAMS-T being lost (which is = repeated if the bust is not stopped), then I will just remind you that = this is a protocol where control messages are not fully reliable (they = are just repeated for redundancy as frequently as 4585 allows). If you = are really this unlucky, you will have a problem but it will be only = temporary.=20 I don't think there is anything here that requires for us to burn our = energy. FWIW, your proposal would not solve this problem entirely, = either. =20 > > > >>> > >>>> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a = globally > >>>> unique CNAME identifier." > >>>> > >>>> I don't think this is a statement that can either be fulfilled = nor > >>>> tested. You can mandate a method for selecting CNAMEs that has = low risk > >>>> of producing CNAME collisions, but nothing can guarantee it = unless a > >>>> entity is coordinating the CNAME space for all clients. Can you = mandate > >>>> the method instead? > >>> > >>> The new CNAME draft has ways to ensure they are unique. If the = client uses one of them, we are all set. > >> > >> Yes, but in that case mandate the implementation and usage of one = of > >> these instead of statement that can't be ensured. > > > > Personally, this is one what I did initially but then we agreed that = one could come up with an alternative method that would > produce unique CNAMEs. In other words, methods for producing unique = CNAMEs are not unique. So, we rather put the > "MUST" in the sentence above not for the specific implementation. >=20 > Okay, I might be nit picking then to request that the text is changed = to > "Thus, the RTP_Rx MUST use a method that ensure it uses an unique = CNAME > identifier." I don't think globally is the correct scope, it is > unnecessary big, when only needs to be unique within this particular > instance of a system. Fine with me. =20 > > > >>>> If I understand the impact of a CNAME collision is that the = collision > >>>> clients request will be mixed up, for example terminating each = others > >>>> request, or update the values in the RAMS-R. > >>> > >>> When they are unique, this won't happen. > >> > >> Just checking, but if that is the case then I am missing a = discussion of > >> hijacking attacks in the security consideration section by guessing = your > >> targets CNAME. > > > > We should probably mention this but I am not sure how the server can = deal with this. Hijacking is not easy since the attack > must take place at the same instant (more or less) with the request = from the authentic client. One of your family members > can probably do this :) >=20 > The real solution is where you have an more permanent id system in = place > that you can connect through source authentication of the requests. >=20 > In an SSM session that uses simple feedback model the RTP_Rx cname may > leak as they are redistributed. >=20 > Based on that you could bombard a BRS with RAMS-T for example for all > known CNAMES and do that in a round-robin fashion across channels and > time. Depending on source address spoofing you will more or less easy = to > find. But I do agree that it becomes a little bit more a brute force > attack, but an attacker could gain knowledge about an important piece = of > information to mount the attack at all. SRTCP? =20 > >>> > >>>> 7. Section 7.3: > >>>> "The MSN value SHALL > >>>> be set to zero only when a new RAMS request is received." > >>>> > >>>> How is that actually known? And why reset it at all? Why not = increase if > >>>> for each new RAMS-I message with new content, independently if it = is an > >>>> update or a new request. > >>> > >>> If this is relating to a new burst request, then it is reset. Ow, = what is the point of having a seqnum? If something has > >> changed compared to the previous RAMS-I, then MSN is incremented. = If it is just a re-xmit, MSN stays the same. > >> > >> I fully agree with the need for separating retransmissions from = updates. > >> However, I wonder over the reset of the field for each new RAMS-R. = It > >> appears to me to be more robust to simply increment it rather than > >> reset. Otherwise you can send RAMS-R(1) resulting in RAMS-I MSN =3D = 0. > > > > I think we discussed this before. The RAMS-R numbers are no way = correlated with the RAMS-I numbers. You are still trying > to correlate them. >=20 > Nope, the number here are still only to indicate that they are = different > to get the sequence right. My point is that the client can determine > based on MSN if it is an repeat or a new RAMS-I based on a new = request. When the client receives a RAMS-I with MSN=3D0, it knows that RAMS-I was = sent for a RAMS-R message that was received the first time by the server = or an identical repeat of the initial RAMS-I message.=20 But even if the client sends an updated request, the server may ignore = it, may ignore the changes and subsequently repeat the earlier RAMS-I = with no changes in it, which will have the previous MSN. The server may = not send anything at all or the message may get lost. The client cannot = assume the changes it requested were honored by the server UNLESS there = was an updated RAMS-I from the server. Even in that case, the RAMS-I = changes may be due to other things the server has observed - not the = changes the client asked. So, the client should not really read too much in to the MSN values = received. That is what I have been trying to explain in this discussion. =20 > > > >> Then a RAMS-R(2) that is intended to be an update but becomes an = new > >> request results in an RAMS-I with MSN =3D 0. The client will not = know if > >> this is an retransmission of RAMS-R(1) info. The updated should = result > >> in MSN=3D1. So without comparing the RAMS-I you can't determine if = there > > > > The client checks the RAMS-I seqnum to see whether it is a repeat or = new info. If RAMS-I MSN is zero, that is the first > RAMS-I anyway so it must be fully parsed. Does not matter which RAMS-R = actually generated it since that is the info from the > server until an updated RAMS-I is received. This is how the protocol = works. >=20 > As I try to explain there is a case where you can get two RAMS-I with > MSN=3D0 in a row with different information. Thus not providing any > relieve for the client in the need to compare the whole request with = the > previous one. So what? If you made a single request and received two RAMS-I messages = with MSN=3D0, that means they are identical. No need to compare them. If = you made two requests and received two RAMS-I messages with MSN=3D0, = they are different messages and you need to fully read them anyway. =20 > > > >> is new information. Going my way (no reset) does not allow a client = to > >> determine if an RAMS-R was treated as update or new request, but it = will > >> correctly know that it is new RAMS-I information. > > > > The server cannot keep state information (i.e. tracking RAMS-R = numbers) across different sessions. Furthermore, requests > for different streams can go to different servers. > > >=20 > No, I am not talking about RAMS-R number here. I am talking about = RAMS-I > MSN numbers, that they shouldn't be kept. But I see your point in that > you don't want to keep CNAME,SSRC =3D> MSN counter mappings. >=20 > But in that case, I think we should make it clear that a client that = has > sent a RAMS-R (update) must check if the RAMS-I information is same or > different to determine if the server interpreted the update as a new > request. >=20 > >>>> 14. Section 10: > >>>> > >>>> Shouldn't the security consideration make it clear that RAMS-R = are > >>>> especially suspectible to Replay attacks as there is no = information in > >>>> the packet that one can use to detect that it is out of sequence. > >>> > >>> There is a wording about this in that section (which simply refers = the reader to 5760). Are you considering a RAMS- > specific > >> replay attack here? > >> > >> > >> Yes, I am considering that it is easy to target RAMS-R specifically = for > >> an replay attack. Especially when sent in a reduced size RTCP = packet > >> only containing RAMS-R and SDES CNAME. That has no time specific > >> information and all replay detection must happen in the security = protocol. > > > > The Token stuff (or the cookie stuff) will avoid request messages = from being sent by others (it will do at least a reverse path > check). Beyond that is not SRTCP a good solution to avoid this? >=20 > SRTCP is if keyed correctly a good solution yes. >=20 > My point is that one normally document the vulnerability and then > ensure that one has a remedy for it. When it comes to the token stuff = I > am not certain that it helps against a replay attack. Unless the token > has expired on the server you still will get traffic to the target. = That > is why I think a reverse path check when you start delivering should > happen. Because first in that case if there is no listener at the > indicated address and port will you find out that you are attempting a > delivery not intended. Token provides RPF check. But, let's work on this Sec. section together. = I could use some help. Thanks. -acbegen From tom.kristensen@tandberg.com Mon Oct 4 14:16:02 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A153A70C8 for ; Mon, 4 Oct 2010 14:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.737 X-Spam-Level: X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6JwLkfGysj6 for ; Mon, 4 Oct 2010 14:16:00 -0700 (PDT) Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by core3.amsl.com (Postfix) with SMTP id 01A9D3A70DB for ; Mon, 4 Oct 2010 14:15:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tom.kristensen@tandberg.com X-Msg-Ref: server-13.tower-194.messagelabs.com!1286227014!16923871!2 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 21282 invoked from network); 4 Oct 2010 21:16:55 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-13.tower-194.messagelabs.com with SMTP; 4 Oct 2010 21:16:55 -0000 Received: from ultra.eu.tandberg.int ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Oct 2010 23:16:53 +0200 Received: from [10.47.13.45] ([10.47.13.45]) by ultra.eu.tandberg.int (8.13.1/8.13.1) with ESMTP id o94LGprD014111; Mon, 4 Oct 2010 23:16:52 +0200 Message-ID: <4CAA4443.9060503@tandberg.com> Date: Mon, 04 Oct 2010 23:16:51 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.7 MIME-Version: 1.0 To: Roni Even References: <4CA8519B.6020707@tandberg.com> <01fd01cb62f9$07d74bc0$1785e340$%roni@huawei.com> In-Reply-To: <01fd01cb62f9$07d74bc0$1785e340$%roni@huawei.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Oct 2010 21:16:53.0937 (UTC) FILETIME=[77E80A10:01CB6409] Cc: 'Randell Jesup' , keith.drage@alcatel-lucent.com, 'IETF AVT WG' Subject: Re: [AVT] rfc3984bis - max-smbps limit X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 21:16:02 -0000 Roni, I propose clarifying "highest level" first time the term is used for max-smbps, that is in the first bullet point at page 44. New text in []: ---- o If the parameter max-mbps is signalled, set a variable MaxMacroblocksPerSecond to the value of max-mbps. Otherwise, set MaxMacroblocksPerSecond equal to the value of MaxMBPS in Table A-1 [1] for the [signaled] highest level [conveyed in the value of the profile-level-id parameter or the max-recv-level parameter]. ---- Then the paragraph on top of page 45, after the bullet points should be: ---- The encoder should recompute this value for each picture. The value of max-smbps MUST be greater than [or equal to] the value of MaxMBPS given [explicitly as the value of the max-mbps parameter or implicitly] in Table A-1 of [1] for the [signaled] highest level. Senders MAY use this knowledge to send pictures of a given size at a higher picture rate than is indicated in the signaled highest level. ---- This way the "highest level" is explained initially in the scope of the parameter and referenced as "signaled highest level" later on as done for the other parameters. -- Tom On 10/03/2010 02:46 PM, Roni Even wrote: > Tom, > Can you suggest a final text so that we can ask the AD what to do > Roni > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >> Tom Kristensen >> Sent: Sunday, October 03, 2010 11:49 AM >> To: Mo Zanaty (mzanaty) >> Cc: Randell Jesup; keith.drage@alcatel-lucent.com; IETF AVT WG; Roni >> Even >> Subject: Re: [AVT] rfc3984bis - max-smbps limit >> >> Indeed, Mo, we have to take a potential max-mbps into account in the >> description and the clarification of "highest level" also in the >> max-smbps text part is just fine. >> >> Even though "highest level" is described under a common heading for >> these parameters, it is repeated for the other parameters. >> Cf.: >> max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: >> These parameters MAY be used to signal the capabilities of a >> receiver implementation. These parameters MUST NOT be used >> for any other purpose. The highest level conveyed in the >> value of the profile-level-id parameter or the max-recv- >> level >> parameter MUST be such that the receiver is fully capable of >> supporting. >> >> -- Tom >> >> On 10/02/2010 03:08 PM, Mo Zanaty (mzanaty) wrote: >>> The draft is missing more than just "or equal to". >>> >>>> The value of max-smbps MUST be greater than the value of MaxMBPS >> given in >>>> Table A-1 of [1] for the highest level. >>> >>> It should also take max-mbps into account. And the reference to >> "highest level" has no antecedent in this section; it is in the prior >> section on max-mbps. >>> >>> I suggest this [new] text: >>> >>> "The value of max-smbps MUST be greater than [or equal to] the value >> of MaxMBPS given [explicitly in max-mbps or implicitly] in Table A-1 of >> [1] for the highest level [given in profile-level-id or max-recv- >> level]." >>> >>> Regards, >>> Mo >>> >>> -----Original Message----- >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >> Roni Even >>> Sent: Friday, October 01, 2010 4:49 PM >>> To: 'IETF AVT WG' >>> Cc: 'Randell Jesup'; 'Tom Kristensen'; keith.drage@alcatel-lucent.com >>> Subject: Re: [AVT] rfc3984bis - max-smbps limit >>> >>> Hi, >>> >>> We got the following comment as a private email (bellow) . The draft >> has not >>> be published yet and we can do this change before publication. >>> Please review and send comments to the list since it changes the >> current >>> semantics. If there are no objections we will do this change. >>> Since this parameter has been added in the bis draft and was not part >> of RFC >>> 3984 we do not see any interoperability issues. >>> >>> Thanks >>> Roni Even >>> As a co-author of the draft >>> >>> >>> Email from Tom Kristensen >>> >>> I discovered missing alignment between H.241 MaxStaticMBPS and max- >> smbps as >>> defined in draft-ietf-avt-rtp-rfc3984bis. >>> >>> From Table 8-9, H.241: >>> --- >>> The encoder should recompute this value for each picture. >>> The value of (MaxStaticMBPS ª 500) shall not be less than the value >> MaxMBPS >>> for the Level given in Table A-1/H.264, and if CustomMaxMBPS is >> signalled, >>> shall not be less than the value (CustomMaxMBPS ª 500). >>> --- >>> >>> On the other hand in the SIP world, rfc3984bis says: >>> --- >>> The value of max-smbps MUST be greater than the value of MaxMBPS >> given in >>> Table A-1 of [1] for the highest level. >>> --- >>> http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-11#page-44 >>> >>> >>> H.241 says max-smbps>= max-mbps. >>> rfc3984bis says max-smbps> max-mbps. >>> We are missing "or equal". >>> >>> Of course it doesn't really make much meaning to include a max-smbps >>> equal to max-mbps, but we have a mismatch between H.241 and the SDP >>> counterpart. >>> >>> Is it possible and feasible to alter the text given the current state >> of >>> soon-to-be-RFC draft-ietf-avt-rtp-rfc3984bis? >>> >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > From magnus.westerlund@ericsson.com Tue Oct 5 01:27:51 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F3B63A6E2C; Tue, 5 Oct 2010 01:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.439 X-Spam-Level: X-Spam-Status: No, score=-106.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPYtr5eTmdjG; Tue, 5 Oct 2010 01:27:49 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 012573A6EF9; Tue, 5 Oct 2010 01:27:48 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-38-4caae1be2e70 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 24.49.27351.EB1EAAC4; Tue, 5 Oct 2010 10:28:46 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Oct 2010 10:28:45 +0200 Received: from [147.214.183.82] ([147.214.183.82]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Oct 2010 10:28:45 +0200 Message-ID: <4CAAE1BC.3080703@ericsson.com> Date: Tue, 05 Oct 2010 10:28:44 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <20100914165611.21618.35586.idtracker@localhost> <4CA33861.5070603@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com> <4CA9C1A5.9080508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com> <4CA9F4E5.2020402@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA9A8@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D4FA9A8@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Oct 2010 08:28:45.0771 (UTC) FILETIME=[53A1C1B0:01CB6467] X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org" , ietf , "avt@ietf.org" Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 08:27:51 -0000 Ali C. Begen (abegen) skrev 2010-10-04 18:04: > I am glad that we are converging on something. > >>>>>> 3. I worried that what is intended to be an RAMS-R update from the >>>>>> client will be interpreted as new RAMS-R request. The reason is the only >>>>>> that separates these two cases are timing, does it arrive before the >>>>>> burst ends or not. Relying on this heuristics is quite weak and error >>>>>> prone. I still wished that an sequence number had been added to RAMS-R. >>>>> >>>>> I gave enough arguments why we should not use a seqnum for the RAMS-R messages earlier. It is not justified IMO. >> Based >>>> on the SSRC of the primary and the requesting client's CNAME, things are pretty straightforward. >>>> >>>> Yes, I know I am in the rough here. From my perspective, it makes the >>>> use of update RAMS-R uncertain to use. Maybe not a big issue if most >>>> doesn't implement updates. But if one finds need for it then there will >>>> be issues. Consider the AD and IESG notified about the potential issue. >>> >>> Is the updated text above good for you? >> >> Not, really, because it has only clarified the issue. The issue is >> really the uncertainty for the client how its request will be >> interpreted, either as updated request or a new request, all depending >> on timing. The biggest issue is the updated request which might be >> interpreted as new request, when the client is likely satisfied and > > Why is this a problem? For this to happen, the initial request must have been lost. And if it is lost and the second makes it, the client still gets what it wants. I don't see a problem here. No, if you intended to send an update and that gets handled as new request, then you get the unintended consequence of getting a second burst. > >> might even have gone one to join the multicast group when the >> RAMS-R(update) is processed as a new RAMS-R. Then causing congestion and > > Are you saying this: > 1- The client makes a request but it gets lost. In the mean time, the client sends an update and the server thinks it is a new request and starts sending the burst No, 1. the client sends a request intended to update an ongoing burst. 2. The RAMS-R (update) arrive to late. Thus triggering a second burst. 3. In the mean time, client gets an RAMS-I and joins the multicast group 4. Burst + mcast creates a congestion. > >> unwanted traffic. The client that detects this can surely terminate the >> burst, but that will be after some delay, and traffic has arrived. > > OK, so you are saying what I wrote above. Well, the client has to send a RAMS-T and upon receiving it, the server stops the burst. So that is not a big deal. If you are concerned about RAMS-T being lost (which is repeated if the bust is not stopped), then I will just remind you that this is a protocol where control messages are not fully reliable (they are just repeated for redundancy as frequently as 4585 allows). If you are really this unlucky, you will have a problem but it will be only temporary. > I will agree that you can stop the burst, but you have biased your protocol by design against sending any RAMS-R with the purpose of updating the parameter because other things happens than what you intended to. Thus it will in most cases be better to not send an RAMS-R update message and avoid the risk of tripping a second burst. > I don't think there is anything here that requires for us to burn our energy. FWIW, your proposal would not solve this problem entirely, either. I agree that a RAMS-R sequence number would not resolve the issue you described. However, it resolves the issue I have tried to describe, I hope the above makes it clear. > >>> >>>>> >>>>>> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a globally >>>>>> unique CNAME identifier." [snip] >>> >>>>>> If I understand the impact of a CNAME collision is that the collision >>>>>> clients request will be mixed up, for example terminating each others >>>>>> request, or update the values in the RAMS-R. >>>>> >>>>> When they are unique, this won't happen. >>>> >>>> Just checking, but if that is the case then I am missing a discussion of >>>> hijacking attacks in the security consideration section by guessing your >>>> targets CNAME. >>> >>> We should probably mention this but I am not sure how the server can deal with this. Hijacking is not easy since the attack >> must take place at the same instant (more or less) with the request from the authentic client. One of your family members >> can probably do this :) >> >> The real solution is where you have an more permanent id system in place >> that you can connect through source authentication of the requests. >> >> In an SSM session that uses simple feedback model the RTP_Rx cname may >> leak as they are redistributed. >> >> Based on that you could bombard a BRS with RAMS-T for example for all >> known CNAMES and do that in a round-robin fashion across channels and >> time. Depending on source address spoofing you will more or less easy to >> find. But I do agree that it becomes a little bit more a brute force >> attack, but an attacker could gain knowledge about an important piece of >> information to mount the attack at all. > > SRTCP? SRTCP keyed with unique keys for each client will prevent anyone else to send RAMS-T to terminate a burst you have initiated. > >>>>> >>>>>> 7. Section 7.3: >>>>>> "The MSN value SHALL >>>>>> be set to zero only when a new RAMS request is received." >>>>>> >>>>>> How is that actually known? And why reset it at all? Why not increase if >>>>>> for each new RAMS-I message with new content, independently if it is an >>>>>> update or a new request. >>>>> >>>>> If this is relating to a new burst request, then it is reset. Ow, what is the point of having a seqnum? If something has >>>> changed compared to the previous RAMS-I, then MSN is incremented. If it is just a re-xmit, MSN stays the same. >>>> >>>> I fully agree with the need for separating retransmissions from updates. >>>> However, I wonder over the reset of the field for each new RAMS-R. It >>>> appears to me to be more robust to simply increment it rather than >>>> reset. Otherwise you can send RAMS-R(1) resulting in RAMS-I MSN = 0. >>> >>> I think we discussed this before. The RAMS-R numbers are no way correlated with the RAMS-I numbers. You are still trying >> to correlate them. >> >> Nope, the number here are still only to indicate that they are different >> to get the sequence right. My point is that the client can determine >> based on MSN if it is an repeat or a new RAMS-I based on a new request. > > When the client receives a RAMS-I with MSN=0, it knows that RAMS-I was sent for a RAMS-R message that was received the first time by the server or an identical repeat of the initial RAMS-I message. > > But even if the client sends an updated request, the server may ignore it, may ignore the changes and subsequently repeat the earlier RAMS-I with no changes in it, which will have the previous MSN. The server may not send anything at all or the message may get lost. The client cannot assume the changes it requested were honored by the server UNLESS there was an updated RAMS-I from the server. Even in that case, the RAMS-I changes may be due to other things the server has observed - not the changes the client asked. > > So, the client should not really read too much in to the MSN values received. That is what I have been trying to explain in this discussion. Also in this case I don't think we have been considering the same case. My case was the following. 1. C->S RAMS-R 2a. S->C RAMS-I (MSN=0) 2b. S->C Burst starts 3. C->S RAMS-R(Intended to update first RAMS-R) 4. S: Burst ends 5. S: RAMS-R from step 3 arrives in server and trigger new burst 6. S->C RAMS-I (MSN=0) 7. S->C Second burst transmitted When the RAMS-I message from step 6 arrives the client may think this is the same as the one in 2a. Are you assuming that there is a 4b RAMS-I message which indicates that the first burst will be terminated that has MSN=1? What if that is lost or not sent? > >>> >>>> Then a RAMS-R(2) that is intended to be an update but becomes an new >>>> request results in an RAMS-I with MSN = 0. The client will not know if >>>> this is an retransmission of RAMS-R(1) info. The updated should result >>>> in MSN=1. So without comparing the RAMS-I you can't determine if there >>> >>> The client checks the RAMS-I seqnum to see whether it is a repeat or new info. If RAMS-I MSN is zero, that is the first >> RAMS-I anyway so it must be fully parsed. Does not matter which RAMS-R actually generated it since that is the info from the >> server until an updated RAMS-I is received. This is how the protocol works. >> >> As I try to explain there is a case where you can get two RAMS-I with >> MSN=0 in a row with different information. Thus not providing any >> relieve for the client in the need to compare the whole request with the >> previous one. > > So what? If you made a single request and received two RAMS-I messages with MSN=0, that means they are identical. No need to compare them. If you made two requests and received two RAMS-I messages with MSN=0, they are different messages and you need to fully read them anyway. Okay, so your point is that as soon you have sent more than one RAMS-R message to a BRS you will need to look at all RAMS-I and the MSN becomes completely useless. But, then I think the document needs to point out that MSN is only reliable to detect repeat transmissions as long as you have sent no additional RAMS-R messages during a minute or so. >>>>>> 14. Section 10: >>>>>> >>>>>> Shouldn't the security consideration make it clear that RAMS-R are >>>>>> especially suspectible to Replay attacks as there is no information in >>>>>> the packet that one can use to detect that it is out of sequence. >>>>> >>>>> There is a wording about this in that section (which simply refers the reader to 5760). Are you considering a RAMS- >> specific >>>> replay attack here? >>>> >>>> >>>> Yes, I am considering that it is easy to target RAMS-R specifically for >>>> an replay attack. Especially when sent in a reduced size RTCP packet >>>> only containing RAMS-R and SDES CNAME. That has no time specific >>>> information and all replay detection must happen in the security protocol. >>> >>> The Token stuff (or the cookie stuff) will avoid request messages from being sent by others (it will do at least a reverse path >> check). Beyond that is not SRTCP a good solution to avoid this? >> >> SRTCP is if keyed correctly a good solution yes. >> >> My point is that one normally document the vulnerability and then >> ensure that one has a remedy for it. When it comes to the token stuff I >> am not certain that it helps against a replay attack. Unless the token >> has expired on the server you still will get traffic to the target. That >> is why I think a reverse path check when you start delivering should >> happen. Because first in that case if there is no listener at the >> indicated address and port will you find out that you are attempting a >> delivery not intended. > > Token provides RPF check. But, let's work on this Sec. section together. I could use some help. > Ok -- 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 gonzalo.camarillo@ericsson.com Tue Oct 5 02:00:29 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB443A6EDB for ; Tue, 5 Oct 2010 02:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.414 X-Spam-Level: X-Spam-Status: No, score=-106.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VWWIQcsRisX for ; Tue, 5 Oct 2010 02:00:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CCE903A6C55 for ; Tue, 5 Oct 2010 02:00:25 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-ab-4caae961a9c0 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 16.60.27351.169EAAC4; Tue, 5 Oct 2010 11:01:21 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Oct 2010 11:01:21 +0200 Received: from [131.160.126.165] ([131.160.126.165]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Oct 2010 11:01:20 +0200 Message-ID: <4CAAE960.1020309@ericsson.com> Date: Tue, 05 Oct 2010 12:01:20 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Colin Perkins References: <4CA9CE38.1040802@ericsson.com> <4EF79274-8451-4BEA-8689-C7D62CCC3ED0@csperkins.org> In-Reply-To: <4EF79274-8451-4BEA-8689-C7D62CCC3ED0@csperkins.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2010 09:01:20.0536 (UTC) FILETIME=[E0C33980:01CB646B] X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org WG" Subject: Re: [AVT] AD review: draft-ietf-avt-rtp-svc-22 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 09:00:29 -0000 Hi Colin, > Unless their policy has changed recently, RTP is one of the few well- > known acronyms the RFC editor allows to be used without expansion in > document titles. yes, it is: https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt Anyway, for all other acronyms in the draft, the following rule (also taken from the link above) applies: "Editorial guidelines for the RFC series generally require expansion of these abbreviations on first occurrence in a title, in an abstract, or in the body of the document." Thanks, Gonzalo From abegen@cisco.com Wed Oct 6 01:08:14 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49FC73A6F00 for ; Wed, 6 Oct 2010 01:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.55 X-Spam-Level: X-Spam-Status: No, score=-10.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkVDwsc4gjB1 for ; Wed, 6 Oct 2010 01:08:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BB39F3A70F9 for ; Wed, 6 Oct 2010 01:08:04 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALbLq0yrR7H+/2dsb2JhbACiP3GkRJwfgnOCVASEUYh3 X-IronPort-AV: E=Sophos;i="4.57,289,1283731200"; d="scan'208";a="599856154" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 06 Oct 2010 08:09:03 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o96893Wb001041; Wed, 6 Oct 2010 08:09:03 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 01:09:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 01:09:02 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D4FB165@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4CAAE1BC.3080703@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard Thread-Index: ActkZ2C2bZSF83dpSNG4NzGorR8JBAANydtA References: <20100914165611.21618.35586.idtracker@localhost> <4CA33861.5070603@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com> <4CA9C1A5.9080508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com> <4CA9F4E5.2020402@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA9A8@xmb-sjc-215.amer.cisco.com> <4CAAE1BC.3080703@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 06 Oct 2010 08:09:03.0482 (UTC) FILETIME=[BD5885A0:01CB652D] Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org, avt@ietf.org Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 08:08:14 -0000 Dropping the ietf list off. > > Are you saying this: > > 1- The client makes a request but it gets lost. In the mean time, = the client sends an update and the server thinks it is a new > request and starts sending the burst >=20 > No, > 1. the client sends a request intended to update an ongoing burst. >=20 > 2. The RAMS-R (update) arrive to late. Thus triggering a second burst. Oh, Ok. Now I see your scenario (update arriving late and causing a new = burst to start). Well, this is an ill scenario with mid-session updates. = While the chances are pretty slim for this happen, it can happen. For = this to happen, the client must really send an update close to the join = time and then the RAMS-R gets delayed for some reason. The only solution for this is that the client will send a RAMS-T for the = second burst as soon as it detects it. Furthermore, if the primary = stream packets have a higher priority than the burst packets (and they = should if the network supports this), mcast stream won't be hurt. FWIW, mid-sessions updates are not problem-free. So if someone wants to = implement it, they will have to live with the complications. =20 > 3. In the mean time, client gets an RAMS-I and joins the multicast = group >=20 > 4. Burst + mcast creates a congestion. >=20 > > > >> unwanted traffic. The client that detects this can surely terminate = the > >> burst, but that will be after some delay, and traffic has arrived. > > > > OK, so you are saying what I wrote above. Well, the client has to = send a RAMS-T and upon receiving it, the server stops the > burst. So that is not a big deal. If you are concerned about RAMS-T = being lost (which is repeated if the bust is not stopped), > then I will just remind you that this is a protocol where control = messages are not fully reliable (they are just repeated for > redundancy as frequently as 4585 allows). If you are really this = unlucky, you will have a problem but it will be only > temporary. > > >=20 > I will agree that you can stop the burst, but you have biased your > protocol by design against sending any RAMS-R with the purpose of > updating the parameter because other things happens than what you > intended to. Thus it will in most cases be better to not send an = RAMS-R > update message and avoid the risk of tripping a second burst. Personally, I don't see the much benefit in using the RAMS-R updates. = That's why they are optional for those who want to implement them. =20 >=20 > > I don't think there is anything here that requires for us to burn = our energy. FWIW, your proposal would not solve this > problem entirely, either. >=20 > I agree that a RAMS-R sequence number would not resolve the issue you > described. However, it resolves the issue I have tried to describe, I > hope the above makes it clear. >=20 > > > >>> > >>>>> > >>>>>> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a = globally > >>>>>> unique CNAME identifier." > [snip] >=20 > >>> > >>>>>> If I understand the impact of a CNAME collision is that the = collision > >>>>>> clients request will be mixed up, for example terminating each = others > >>>>>> request, or update the values in the RAMS-R. > >>>>> > >>>>> When they are unique, this won't happen. > >>>> > >>>> Just checking, but if that is the case then I am missing a = discussion of > >>>> hijacking attacks in the security consideration section by = guessing your > >>>> targets CNAME. > >>> > >>> We should probably mention this but I am not sure how the server = can deal with this. Hijacking is not easy since the > attack > >> must take place at the same instant (more or less) with the request = from the authentic client. One of your family > members > >> can probably do this :) > >> > >> The real solution is where you have an more permanent id system in = place > >> that you can connect through source authentication of the requests. > >> > >> In an SSM session that uses simple feedback model the RTP_Rx cname = may > >> leak as they are redistributed. > >> > >> Based on that you could bombard a BRS with RAMS-T for example for = all > >> known CNAMES and do that in a round-robin fashion across channels = and > >> time. Depending on source address spoofing you will more or less = easy to > >> find. But I do agree that it becomes a little bit more a brute = force > >> attack, but an attacker could gain knowledge about an important = piece of > >> information to mount the attack at all. > > > > SRTCP? >=20 > SRTCP keyed with unique keys for each client will prevent anyone else = to > send RAMS-T to terminate a burst you have initiated. OK. =20 > > > >>>>> > >>>>>> 7. Section 7.3: > >>>>>> "The MSN value SHALL > >>>>>> be set to zero only when a new RAMS request is received." > >>>>>> > >>>>>> How is that actually known? And why reset it at all? Why not = increase if > >>>>>> for each new RAMS-I message with new content, independently if = it is an > >>>>>> update or a new request. > >>>>> > >>>>> If this is relating to a new burst request, then it is reset. = Ow, what is the point of having a seqnum? If something has > >>>> changed compared to the previous RAMS-I, then MSN is incremented. = If it is just a re-xmit, MSN stays the same. > >>>> > >>>> I fully agree with the need for separating retransmissions from = updates. > >>>> However, I wonder over the reset of the field for each new = RAMS-R. It > >>>> appears to me to be more robust to simply increment it rather = than > >>>> reset. Otherwise you can send RAMS-R(1) resulting in RAMS-I MSN = =3D 0. > >>> > >>> I think we discussed this before. The RAMS-R numbers are no way = correlated with the RAMS-I numbers. You are still > trying > >> to correlate them. > >> > >> Nope, the number here are still only to indicate that they are = different > >> to get the sequence right. My point is that the client can = determine > >> based on MSN if it is an repeat or a new RAMS-I based on a new = request. > > > > When the client receives a RAMS-I with MSN=3D0, it knows that RAMS-I = was sent for a RAMS-R message that was received > the first time by the server or an identical repeat of the initial = RAMS-I message. > > > > But even if the client sends an updated request, the server may = ignore it, may ignore the changes and subsequently repeat > the earlier RAMS-I with no changes in it, which will have the previous = MSN. The server may not send anything at all or the > message may get lost. The client cannot assume the changes it = requested were honored by the server UNLESS there was an > updated RAMS-I from the server. Even in that case, the RAMS-I changes = may be due to other things the server has observed - > not the changes the client asked. > > > > So, the client should not really read too much in to the MSN values = received. That is what I have been trying to explain in > this discussion. >=20 > Also in this case I don't think we have been considering the same = case. > My case was the following. >=20 > 1. C->S RAMS-R > 2a. S->C RAMS-I (MSN=3D0) > 2b. S->C Burst starts > 3. C->S RAMS-R(Intended to update first RAMS-R) > 4. S: Burst ends > 5. S: RAMS-R from step 3 arrives in server and trigger new burst > 6. S->C RAMS-I (MSN=3D0) > 7. S->C Second burst transmitted >=20 > When the RAMS-I message from step 6 arrives the client may think this = is > the same as the one in 2a. >=20 > Are you assuming that there is a 4b RAMS-I message which indicates = that > the first burst will be terminated that has MSN=3D1? What if that is = lost > or not sent? Well that RAMS-I is not necessarily sent. And if sent, it may get lost. = Again, this is an ill scenario with RAMS-R updates. But here the problem = is the second burst not failing to identify the second RAMS-I. When the = 2nd burst starts, the client will figure out, things were screwed up. =20 > > > >>> > >>>> Then a RAMS-R(2) that is intended to be an update but becomes an = new > >>>> request results in an RAMS-I with MSN =3D 0. The client will not = know if > >>>> this is an retransmission of RAMS-R(1) info. The updated should = result > >>>> in MSN=3D1. So without comparing the RAMS-I you can't determine = if there > >>> > >>> The client checks the RAMS-I seqnum to see whether it is a repeat = or new info. If RAMS-I MSN is zero, that is the first > >> RAMS-I anyway so it must be fully parsed. Does not matter which = RAMS-R actually generated it since that is the info from > the > >> server until an updated RAMS-I is received. This is how the = protocol works. > >> > >> As I try to explain there is a case where you can get two RAMS-I = with > >> MSN=3D0 in a row with different information. Thus not providing any > >> relieve for the client in the need to compare the whole request = with the > >> previous one. > > > > So what? If you made a single request and received two RAMS-I = messages with MSN=3D0, that means they are identical. No > need to compare them. If you made two requests and received two RAMS-I = messages with MSN=3D0, they are different > messages and you need to fully read them anyway. >=20 > Okay, so your point is that as soon you have sent more than one RAMS-R > message to a BRS you will need to look at all RAMS-I and the MSN = becomes > completely useless. But, then I think the document needs to point out > that MSN is only reliable to detect repeat transmissions as long as = you > have sent no additional RAMS-R messages during a minute or so. We should put some text about this. IF the client sent RAMS-R update(s), = it should probably check every RAMS-I regardless of MSN values. -acbegen From magnus.westerlund@ericsson.com Wed Oct 6 07:21:03 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21F13A6F52 for ; Wed, 6 Oct 2010 07:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMzTlMFKaj6e for ; Wed, 6 Oct 2010 07:21:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 606443A6F77 for ; Wed, 6 Oct 2010 07:20:52 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbfae00000264e-da-4cac85eae2e5 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CC.53.09806.AE58CAC4; Wed, 6 Oct 2010 16:21:30 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Oct 2010 16:21:30 +0200 Received: from [147.214.183.82] ([147.214.183.82]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Oct 2010 16:21:29 +0200 Message-ID: <4CAC85E9.2010508@ericsson.com> Date: Wed, 06 Oct 2010 16:21:29 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <20100914165611.21618.35586.idtracker@localhost> <4CA33861.5070603@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com> <4CA9C1A5.9080508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com> <4CA9F4E5.2020402@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA9A8@xmb-sjc-215.amer.cisco.com> <4CAAE1BC.3080703@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FB165@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D4FB165@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Oct 2010 14:21:29.0212 (UTC) FILETIME=[C47053C0:01CB6561] X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 14:21:03 -0000 Hi, I would say that it is a failure of the design, to not make RAMS-R updates work well. I see one fix that would seem easy to avoid these problems. Create a new message type RAMS-U that is identical to RAMS-R except the message type and restrict it to work on a ongoing burst. The other way is to rip out update for now to avoid having this obviously broken mechanism stay in there. And if someone needs it in the future then define it properly. I do want this finished up and published, but not with serious issue part of the spec. Magnus Ali C. Begen (abegen) skrev 2010-10-06 10:09: > Dropping the ietf list off. > >>> Are you saying this: >>> 1- The client makes a request but it gets lost. In the mean time, the client sends an update and the server thinks it is a new >> request and starts sending the burst >> >> No, >> 1. the client sends a request intended to update an ongoing burst. >> >> 2. The RAMS-R (update) arrive to late. Thus triggering a second burst. > > Oh, Ok. Now I see your scenario (update arriving late and causing a new burst to start). Well, this is an ill scenario with mid-session updates. While the chances are pretty slim for this happen, it can happen. For this to happen, the client must really send an update close to the join time and then the RAMS-R gets delayed for some reason. > > The only solution for this is that the client will send a RAMS-T for the second burst as soon as it detects it. Furthermore, if the primary stream packets have a higher priority than the burst packets (and they should if the network supports this), mcast stream won't be hurt. > > FWIW, mid-sessions updates are not problem-free. So if someone wants to implement it, they will have to live with the complications. > >> 3. In the mean time, client gets an RAMS-I and joins the multicast group >> >> 4. Burst + mcast creates a congestion. >> >>> >>>> unwanted traffic. The client that detects this can surely terminate the >>>> burst, but that will be after some delay, and traffic has arrived. >>> >>> OK, so you are saying what I wrote above. Well, the client has to send a RAMS-T and upon receiving it, the server stops the >> burst. So that is not a big deal. If you are concerned about RAMS-T being lost (which is repeated if the bust is not stopped), >> then I will just remind you that this is a protocol where control messages are not fully reliable (they are just repeated for >> redundancy as frequently as 4585 allows). If you are really this unlucky, you will have a problem but it will be only >> temporary. >>> >> >> I will agree that you can stop the burst, but you have biased your >> protocol by design against sending any RAMS-R with the purpose of >> updating the parameter because other things happens than what you >> intended to. Thus it will in most cases be better to not send an RAMS-R >> update message and avoid the risk of tripping a second burst. > > Personally, I don't see the much benefit in using the RAMS-R updates. That's why they are optional for those who want to implement them. > >> >>> I don't think there is anything here that requires for us to burn our energy. FWIW, your proposal would not solve this >> problem entirely, either. >> >> I agree that a RAMS-R sequence number would not resolve the issue you >> described. However, it resolves the issue I have tried to describe, I >> hope the above makes it clear. >> >>> >>>>> >>>>>>> >>>>>>>> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a globally >>>>>>>> unique CNAME identifier." >> [snip] >> >>>>> >>>>>>>> If I understand the impact of a CNAME collision is that the collision >>>>>>>> clients request will be mixed up, for example terminating each others >>>>>>>> request, or update the values in the RAMS-R. >>>>>>> >>>>>>> When they are unique, this won't happen. >>>>>> >>>>>> Just checking, but if that is the case then I am missing a discussion of >>>>>> hijacking attacks in the security consideration section by guessing your >>>>>> targets CNAME. >>>>> >>>>> We should probably mention this but I am not sure how the server can deal with this. Hijacking is not easy since the >> attack >>>> must take place at the same instant (more or less) with the request from the authentic client. One of your family >> members >>>> can probably do this :) >>>> >>>> The real solution is where you have an more permanent id system in place >>>> that you can connect through source authentication of the requests. >>>> >>>> In an SSM session that uses simple feedback model the RTP_Rx cname may >>>> leak as they are redistributed. >>>> >>>> Based on that you could bombard a BRS with RAMS-T for example for all >>>> known CNAMES and do that in a round-robin fashion across channels and >>>> time. Depending on source address spoofing you will more or less easy to >>>> find. But I do agree that it becomes a little bit more a brute force >>>> attack, but an attacker could gain knowledge about an important piece of >>>> information to mount the attack at all. >>> >>> SRTCP? >> >> SRTCP keyed with unique keys for each client will prevent anyone else to >> send RAMS-T to terminate a burst you have initiated. > > OK. > >>> >>>>>>> >>>>>>>> 7. Section 7.3: >>>>>>>> "The MSN value SHALL >>>>>>>> be set to zero only when a new RAMS request is received." >>>>>>>> >>>>>>>> How is that actually known? And why reset it at all? Why not increase if >>>>>>>> for each new RAMS-I message with new content, independently if it is an >>>>>>>> update or a new request. >>>>>>> >>>>>>> If this is relating to a new burst request, then it is reset. Ow, what is the point of having a seqnum? If something has >>>>>> changed compared to the previous RAMS-I, then MSN is incremented. If it is just a re-xmit, MSN stays the same. >>>>>> >>>>>> I fully agree with the need for separating retransmissions from updates. >>>>>> However, I wonder over the reset of the field for each new RAMS-R. It >>>>>> appears to me to be more robust to simply increment it rather than >>>>>> reset. Otherwise you can send RAMS-R(1) resulting in RAMS-I MSN = 0. >>>>> >>>>> I think we discussed this before. The RAMS-R numbers are no way correlated with the RAMS-I numbers. You are still >> trying >>>> to correlate them. >>>> >>>> Nope, the number here are still only to indicate that they are different >>>> to get the sequence right. My point is that the client can determine >>>> based on MSN if it is an repeat or a new RAMS-I based on a new request. >>> >>> When the client receives a RAMS-I with MSN=0, it knows that RAMS-I was sent for a RAMS-R message that was received >> the first time by the server or an identical repeat of the initial RAMS-I message. >>> >>> But even if the client sends an updated request, the server may ignore it, may ignore the changes and subsequently repeat >> the earlier RAMS-I with no changes in it, which will have the previous MSN. The server may not send anything at all or the >> message may get lost. The client cannot assume the changes it requested were honored by the server UNLESS there was an >> updated RAMS-I from the server. Even in that case, the RAMS-I changes may be due to other things the server has observed - >> not the changes the client asked. >>> >>> So, the client should not really read too much in to the MSN values received. That is what I have been trying to explain in >> this discussion. >> >> Also in this case I don't think we have been considering the same case. >> My case was the following. >> >> 1. C->S RAMS-R >> 2a. S->C RAMS-I (MSN=0) >> 2b. S->C Burst starts >> 3. C->S RAMS-R(Intended to update first RAMS-R) >> 4. S: Burst ends >> 5. S: RAMS-R from step 3 arrives in server and trigger new burst >> 6. S->C RAMS-I (MSN=0) >> 7. S->C Second burst transmitted >> >> When the RAMS-I message from step 6 arrives the client may think this is >> the same as the one in 2a. >> >> Are you assuming that there is a 4b RAMS-I message which indicates that >> the first burst will be terminated that has MSN=1? What if that is lost >> or not sent? > > Well that RAMS-I is not necessarily sent. And if sent, it may get lost. Again, this is an ill scenario with RAMS-R updates. But here the problem is the second burst not failing to identify the second RAMS-I. When the 2nd burst starts, the client will figure out, things were screwed up. > >>> >>>>> >>>>>> Then a RAMS-R(2) that is intended to be an update but becomes an new >>>>>> request results in an RAMS-I with MSN = 0. The client will not know if >>>>>> this is an retransmission of RAMS-R(1) info. The updated should result >>>>>> in MSN=1. So without comparing the RAMS-I you can't determine if there >>>>> >>>>> The client checks the RAMS-I seqnum to see whether it is a repeat or new info. If RAMS-I MSN is zero, that is the first >>>> RAMS-I anyway so it must be fully parsed. Does not matter which RAMS-R actually generated it since that is the info from >> the >>>> server until an updated RAMS-I is received. This is how the protocol works. >>>> >>>> As I try to explain there is a case where you can get two RAMS-I with >>>> MSN=0 in a row with different information. Thus not providing any >>>> relieve for the client in the need to compare the whole request with the >>>> previous one. >>> >>> So what? If you made a single request and received two RAMS-I messages with MSN=0, that means they are identical. No >> need to compare them. If you made two requests and received two RAMS-I messages with MSN=0, they are different >> messages and you need to fully read them anyway. >> >> Okay, so your point is that as soon you have sent more than one RAMS-R >> message to a BRS you will need to look at all RAMS-I and the MSN becomes >> completely useless. But, then I think the document needs to point out >> that MSN is only reliable to detect repeat transmissions as long as you >> have sent no additional RAMS-R messages during a minute or so. > > We should put some text about this. IF the client sent RAMS-R update(s), it should probably check every RAMS-I regardless of MSN values. > > -acbegen > > -- 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 root@core3.amsl.com Wed Oct 6 07:45:03 2010 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DE70F3A70CA; Wed, 6 Oct 2010 07:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101006144502.DE70F3A70CA@core3.amsl.com> Date: Wed, 6 Oct 2010 07:45:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-h264-rcdo-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 14:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video Author(s) : T. Kristensen, P. Luthi Filename : draft-ietf-avt-rtp-h264-rcdo-07.txt Pages : 23 Date : 2010-10-06 This document describes an RTP payload format for the Reduced- Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RCDO RTP payload format is based on the H.264 RTP payload format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-rcdo-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-h264-rcdo-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-06074155.I-D@ietf.org> --NextPart-- From 2mkristensen@gmail.com Wed Oct 6 07:49:17 2010 Return-Path: <2mkristensen@gmail.com> X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3523A70E8 for ; Wed, 6 Oct 2010 07:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zO1fbie0Q-S for ; Wed, 6 Oct 2010 07:49:15 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8E7043A70E0 for ; Wed, 6 Oct 2010 07:49:15 -0700 (PDT) Received: by qwc9 with SMTP id 9so5045161qwc.31 for ; Wed, 06 Oct 2010 07:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YBQ5sNLfdCCDUJgJkEqiLeDH41MDYPEjW0rj2LAaNcc=; b=vZUWgo9eKYrzcsJlFZFZ7j0w7YBE60zGXe4dDjCvTcIBGkr0rCLy4rKjfvRJ7UzTwl 7+1t4nZ8H+1x1FX4Gid/NJkORN4ocdeBPH8SItzwEBDSoDrkgrtbL/To+TDB4x0GTX67 agbK3HdOCkStlKghj6WXZqAMZbvgILkBk4zyo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Fm8FR5Av80enEp4QEcpypWa5gbegi0sTciAH6P4GOhIzSEYu9RcZbfmoZYhO2CH+Gz IVgKGiQ5KPD1rtJ+UZ9z4qG6PgkPOPyFFHC/vwN5u/K/aKxh9FStv2Wws1FTsyFznZAH HxStpoEGJXUXcW1G5Gpcj7OFixKKM3sqlxXK8= MIME-Version: 1.0 Received: by 10.224.36.132 with SMTP id t4mr1617724qad.72.1286376615267; Wed, 06 Oct 2010 07:50:15 -0700 (PDT) Received: by 10.229.30.212 with HTTP; Wed, 6 Oct 2010 07:50:15 -0700 (PDT) In-Reply-To: <4CA9AA1D.6030508@ericsson.com> References: <4CA9AA1D.6030508@ericsson.com> Date: Wed, 6 Oct 2010 16:50:15 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: avt@ietf.org, Tom Kristensen Subject: Re: [AVT] AD review: draft-ietf-avt-rtp-h264-rcdo-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 14:49:17 -0000 On 4 October 2010 12:19, Gonzalo Camarillo wrote: > Hi, > > as part of a load balancing exercise between Robert and I, I will be > acting as the responsible AD for this draft. > > https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-h264-rcdo/ > > Below you can find my AD review. As soon as the authors address these > comments (it should be trivial to address them), I will IETF Last Call > this draft. Great, thanks! I just submitted a new version addressing these comments as detailed below. [...] > The acronyms RTP and RCDO need to be expanded in the title of the > draft. In general, all acronyms need to be expanded on their first > use. RTP kept as is, cf. answer to SVC draft on this list. Other "not well-known" acronyms are now expanded. > The document refers to [3] as RFC3984bis. Given that [3] is a > normative reference, this document will not be published until [3] is > published as well. So, referring to it as, say, RFCYYYY and then get > the RFC Editor to update the text seems like a better option than > calling it RFC3984bis. Done. We also have to remember syncing the identical parts of the media subtype definition with draft-ietf-avt-rtp-rfc3984bis-11 when it's 100% sure this will not change. > Page 19: section X should be section 9. Fixed. > Section 9: "although if suitable the usage of SRTP [11] is > recommended". Should that be a normative RECOMMENDED instead? Not so sure, so in spirit of draft-ietf-avt-srtp-not-mandatory the following sentence is used instead: "Usage of data origin authentication and data integrity protection of at least the RTP packet is RECOMMENDED, for example by use of the Secure Real-time Transport Protocol (SRTP) ." > The draft should have a reference to the SDP spec: RFC 4566. Yes, now referenced in the Introduction section. -- Tom --=20 # Cisco ## tomkrist@cisco.com =A0| =A0http://www.tandberg.com ### http://folk.uio.no/tomkri/ From abegen@cisco.com Wed Oct 6 08:52:28 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D557B3A70E8 for ; Wed, 6 Oct 2010 08:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.551 X-Spam-Level: X-Spam-Status: No, score=-10.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByhqY8ucWLxJ for ; Wed, 6 Oct 2010 08:52:27 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F40823A7140 for ; Wed, 6 Oct 2010 08:52:26 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALM4rEyrR7Hu/2dsb2JhbACiSXGobJwxAoJxglQEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,290,1283731200"; d="scan'208";a="600044028" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 06 Oct 2010 15:53:27 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o96FrRoR016234; Wed, 6 Oct 2010 15:53:27 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 08:53:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 08:53:08 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D4FB20C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4CAC85E9.2010508@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard Thread-Index: ActlYcksLi1lQkpmQf2ZWFicKaMCdAAC80iA References: <20100914165611.21618.35586.idtracker@localhost> <4CA33861.5070603@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com> <4CA9C1A5.9080508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com> <4CA9F4E5.2020402@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA9A8@xmb-sjc-215.amer.cisco.com> <4CAAE1BC.3080703@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FB165@xmb-sjc-215.amer.cisco.com> <4CAC85E9.2010508@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 06 Oct 2010 15:53:27.0214 (UTC) FILETIME=[9D6C9CE0:01CB656E] Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org, avt@ietf.org Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 15:52:28 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, October 06, 2010 10:21 AM > To: Ali C. Begen (abegen) > Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org; = avt@ietf.org > Subject: Re: Last Call: = (Unicast-Based Rapid = Acquisition of Multicast RTP > Sessions) to Proposed Standard >=20 > Hi, >=20 > I would say that it is a failure of the design, to not make RAMS-R > updates work well. I see one fix that would seem easy to avoid these > problems. Create a new message type RAMS-U that is identical to RAMS-R > except the message type and restrict it to work on a ongoing burst. = The I don't think this is a good design choice. When the updates feature was = desired by some folks, we only agreed to have it if it the messages = still stayed "self-defining". Now, when a server receives a RAMS-U = message but it does not have an ongoing burst since the first message = (RAMS-R) was lost, it won't process it based on your definition. > other way is to rip out update for now to avoid having this obviously > broken mechanism stay in there. And if someone needs it in the future > then define it properly. I think we can still keep the current text (about the update process) = for those who are still planning to use it by putting a caution against = such problems. Would that work for you? -acbegen =20 > I do want this finished up and published, but not with serious issue > part of the spec. >=20 > Magnus >=20 >=20 >=20 >=20 > Ali C. Begen (abegen) skrev 2010-10-06 10:09: > > Dropping the ietf list off. > > > >>> Are you saying this: > >>> 1- The client makes a request but it gets lost. In the mean time, = the client sends an update and the server thinks it is a > new > >> request and starts sending the burst > >> > >> No, > >> 1. the client sends a request intended to update an ongoing burst. > >> > >> 2. The RAMS-R (update) arrive to late. Thus triggering a second = burst. > > > > Oh, Ok. Now I see your scenario (update arriving late and causing a = new burst to start). Well, this is an ill scenario with > mid-session updates. While the chances are pretty slim for this = happen, it can happen. For this to happen, the client must > really send an update close to the join time and then the RAMS-R gets = delayed for some reason. > > > > The only solution for this is that the client will send a RAMS-T for = the second burst as soon as it detects it. Furthermore, if > the primary stream packets have a higher priority than the burst = packets (and they should if the network supports this), > mcast stream won't be hurt. > > > > FWIW, mid-sessions updates are not problem-free. So if someone wants = to implement it, they will have to live with the > complications. > > > >> 3. In the mean time, client gets an RAMS-I and joins the multicast = group > >> > >> 4. Burst + mcast creates a congestion. > >> > >>> > >>>> unwanted traffic. The client that detects this can surely = terminate the > >>>> burst, but that will be after some delay, and traffic has = arrived. > >>> > >>> OK, so you are saying what I wrote above. Well, the client has to = send a RAMS-T and upon receiving it, the server stops > the > >> burst. So that is not a big deal. If you are concerned about RAMS-T = being lost (which is repeated if the bust is not stopped), > >> then I will just remind you that this is a protocol where control = messages are not fully reliable (they are just repeated for > >> redundancy as frequently as 4585 allows). If you are really this = unlucky, you will have a problem but it will be only > >> temporary. > >>> > >> > >> I will agree that you can stop the burst, but you have biased your > >> protocol by design against sending any RAMS-R with the purpose of > >> updating the parameter because other things happens than what you > >> intended to. Thus it will in most cases be better to not send an = RAMS-R > >> update message and avoid the risk of tripping a second burst. > > > > Personally, I don't see the much benefit in using the RAMS-R = updates. That's why they are optional for those who want to > implement them. > > > >> > >>> I don't think there is anything here that requires for us to burn = our energy. FWIW, your proposal would not solve this > >> problem entirely, either. > >> > >> I agree that a RAMS-R sequence number would not resolve the issue = you > >> described. However, it resolves the issue I have tried to describe, = I > >> hope the above makes it clear. > >> > >>> > >>>>> > >>>>>>> > >>>>>>>> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a = globally > >>>>>>>> unique CNAME identifier." > >> [snip] > >> > >>>>> > >>>>>>>> If I understand the impact of a CNAME collision is that the = collision > >>>>>>>> clients request will be mixed up, for example terminating = each others > >>>>>>>> request, or update the values in the RAMS-R. > >>>>>>> > >>>>>>> When they are unique, this won't happen. > >>>>>> > >>>>>> Just checking, but if that is the case then I am missing a = discussion of > >>>>>> hijacking attacks in the security consideration section by = guessing your > >>>>>> targets CNAME. > >>>>> > >>>>> We should probably mention this but I am not sure how the server = can deal with this. Hijacking is not easy since the > >> attack > >>>> must take place at the same instant (more or less) with the = request from the authentic client. One of your family > >> members > >>>> can probably do this :) > >>>> > >>>> The real solution is where you have an more permanent id system = in place > >>>> that you can connect through source authentication of the = requests. > >>>> > >>>> In an SSM session that uses simple feedback model the RTP_Rx = cname may > >>>> leak as they are redistributed. > >>>> > >>>> Based on that you could bombard a BRS with RAMS-T for example for = all > >>>> known CNAMES and do that in a round-robin fashion across channels = and > >>>> time. Depending on source address spoofing you will more or less = easy to > >>>> find. But I do agree that it becomes a little bit more a brute = force > >>>> attack, but an attacker could gain knowledge about an important = piece of > >>>> information to mount the attack at all. > >>> > >>> SRTCP? > >> > >> SRTCP keyed with unique keys for each client will prevent anyone = else to > >> send RAMS-T to terminate a burst you have initiated. > > > > OK. > > > >>> > >>>>>>> > >>>>>>>> 7. Section 7.3: > >>>>>>>> "The MSN value SHALL > >>>>>>>> be set to zero only when a new RAMS request is = received." > >>>>>>>> > >>>>>>>> How is that actually known? And why reset it at all? Why not = increase if > >>>>>>>> for each new RAMS-I message with new content, independently = if it is an > >>>>>>>> update or a new request. > >>>>>>> > >>>>>>> If this is relating to a new burst request, then it is reset. = Ow, what is the point of having a seqnum? If something has > >>>>>> changed compared to the previous RAMS-I, then MSN is = incremented. If it is just a re-xmit, MSN stays the same. > >>>>>> > >>>>>> I fully agree with the need for separating retransmissions from = updates. > >>>>>> However, I wonder over the reset of the field for each new = RAMS-R. It > >>>>>> appears to me to be more robust to simply increment it rather = than > >>>>>> reset. Otherwise you can send RAMS-R(1) resulting in RAMS-I MSN = =3D 0. > >>>>> > >>>>> I think we discussed this before. The RAMS-R numbers are no way = correlated with the RAMS-I numbers. You are still > >> trying > >>>> to correlate them. > >>>> > >>>> Nope, the number here are still only to indicate that they are = different > >>>> to get the sequence right. My point is that the client can = determine > >>>> based on MSN if it is an repeat or a new RAMS-I based on a new = request. > >>> > >>> When the client receives a RAMS-I with MSN=3D0, it knows that = RAMS-I was sent for a RAMS-R message that was received > >> the first time by the server or an identical repeat of the initial = RAMS-I message. > >>> > >>> But even if the client sends an updated request, the server may = ignore it, may ignore the changes and subsequently > repeat > >> the earlier RAMS-I with no changes in it, which will have the = previous MSN. The server may not send anything at all or the > >> message may get lost. The client cannot assume the changes it = requested were honored by the server UNLESS there was > an > >> updated RAMS-I from the server. Even in that case, the RAMS-I = changes may be due to other things the server has > observed - > >> not the changes the client asked. > >>> > >>> So, the client should not really read too much in to the MSN = values received. That is what I have been trying to explain in > >> this discussion. > >> > >> Also in this case I don't think we have been considering the same = case. > >> My case was the following. > >> > >> 1. C->S RAMS-R > >> 2a. S->C RAMS-I (MSN=3D0) > >> 2b. S->C Burst starts > >> 3. C->S RAMS-R(Intended to update first RAMS-R) > >> 4. S: Burst ends > >> 5. S: RAMS-R from step 3 arrives in server and trigger new burst > >> 6. S->C RAMS-I (MSN=3D0) > >> 7. S->C Second burst transmitted > >> > >> When the RAMS-I message from step 6 arrives the client may think = this is > >> the same as the one in 2a. > >> > >> Are you assuming that there is a 4b RAMS-I message which indicates = that > >> the first burst will be terminated that has MSN=3D1? What if that = is lost > >> or not sent? > > > > Well that RAMS-I is not necessarily sent. And if sent, it may get = lost. Again, this is an ill scenario with RAMS-R updates. But > here the problem is the second burst not failing to identify the = second RAMS-I. When the 2nd burst starts, the client will > figure out, things were screwed up. > > > >>> > >>>>> > >>>>>> Then a RAMS-R(2) that is intended to be an update but becomes = an new > >>>>>> request results in an RAMS-I with MSN =3D 0. The client will = not know if > >>>>>> this is an retransmission of RAMS-R(1) info. The updated should = result > >>>>>> in MSN=3D1. So without comparing the RAMS-I you can't determine = if there > >>>>> > >>>>> The client checks the RAMS-I seqnum to see whether it is a = repeat or new info. If RAMS-I MSN is zero, that is the first > >>>> RAMS-I anyway so it must be fully parsed. Does not matter which = RAMS-R actually generated it since that is the info > from > >> the > >>>> server until an updated RAMS-I is received. This is how the = protocol works. > >>>> > >>>> As I try to explain there is a case where you can get two RAMS-I = with > >>>> MSN=3D0 in a row with different information. Thus not providing = any > >>>> relieve for the client in the need to compare the whole request = with the > >>>> previous one. > >>> > >>> So what? If you made a single request and received two RAMS-I = messages with MSN=3D0, that means they are identical. > No > >> need to compare them. If you made two requests and received two = RAMS-I messages with MSN=3D0, they are different > >> messages and you need to fully read them anyway. > >> > >> Okay, so your point is that as soon you have sent more than one = RAMS-R > >> message to a BRS you will need to look at all RAMS-I and the MSN = becomes > >> completely useless. But, then I think the document needs to point = out > >> that MSN is only reliable to detect repeat transmissions as long as = you > >> have sent no additional RAMS-R messages during a minute or so. > > > > We should put some text about this. IF the client sent RAMS-R = update(s), it should probably check every RAMS-I regardless > of MSN values. > > > > -acbegen > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From wwwrun@core3.amsl.com Tue Oct 5 09:39:45 2010 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 01AD73A6C9D; Tue, 5 Oct 2010 09:39:44 -0700 (PDT) To: tom.kristensen@tandberg.com, yekuiwang@huawei.com, ron.even.tlv@gmail.com, rjesup@wgate.com From: IETF Secretariat Message-Id: <20101005163945.01AD73A6C9D@core3.amsl.com> Date: Tue, 5 Oct 2010 09:39:44 -0700 (PDT) X-Mailman-Approved-At: Wed, 06 Oct 2010 13:36:06 -0700 Cc: keith.drage@alcatel-lucent.com, housley@vigilsec.com, gonzalo.camarillo@ericsson.com, avt@ietf.org, ipr-announce@ietf.org Subject: [AVT] IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-avt-rtp-rfc3984bis-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 16:39:49 -0000 Dear Tom Kristensen, Ye-Kui Wang, Roni Even, Randell Jesup: An IPR disclosure that pertains to your Internet-Draft entitled "RTP Payload Format for H.264 Video" (draft-ietf-avt-rtp-rfc3984bis) was submitted to the IETF Secretariat on 2010-10-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1415/). The title of the IPR disclosure is "Nokia Corporation's Statement about IPR related to draft-ietf-avt-rtp-rfc3984bis-11." The IETF Secretariat From abegen@cisco.com Wed Oct 6 15:09:49 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FDDD3A7218 for ; Wed, 6 Oct 2010 15:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1KsHvkaBG5X for ; Wed, 6 Oct 2010 15:09:48 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 539833A7207 for ; Wed, 6 Oct 2010 15:09:48 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA6RrEyrR7Hu/2dsb2JhbACiUXGpX5w2hUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,293,1283731200"; d="scan'208";a="196912838" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 06 Oct 2010 22:10:39 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o96MAddt019362; Wed, 6 Oct 2010 22:10:39 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 15:10:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 15:10:15 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEAD4@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Token or Cookie? Thread-Index: ActfJhB/YTjaJOWXQ1qhqlp2njG0wwGfQErg From: "Ali C. Begen (abegen)" To: , , X-OriginalArrivalTime: 06 Oct 2010 22:10:39.0759 (UTC) FILETIME=[4F78E9F0:01CB65A3] Subject: Re: [AVT] Token or Cookie? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 22:09:49 -0000 Co-chairs,=20 We are still waiting for your response about this issue. Will you let us = know on how to proceed? It will be a shame if we cannot make a single = bit progress between the meetings. -acbegen > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. Begen (abegen) > Sent: Wednesday, September 29, 2010 12:08 AM > To: Even.roni@huawei.com; keith.drage@alcatel-lucent.com; avt@ietf.org > Subject: [AVT] Token or Cookie? >=20 > Co-chairs, >=20 > The submission deadline is quickly approaching for the next meeting = and as the authors we are still waiting for a green light > to move forward on this issue. We have not made progress since the = last meeting. >=20 > Based on the discussion in the mailing list, I believe we will go with = the Token approach but could you make it formal in the > mailing list? >=20 > Thanks. > -acbegen > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From gonzalo.camarillo@ericsson.com Wed Oct 6 23:53:06 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2E93A6EA5 for ; Wed, 6 Oct 2010 23:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.434 X-Spam-Level: X-Spam-Status: No, score=-106.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyp+kX2YQUhD for ; Wed, 6 Oct 2010 23:53:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5504D3A6E14 for ; Wed, 6 Oct 2010 23:53:03 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-40-4cad6e8dfb02 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E4.2F.27351.D8E6DAC4; Thu, 7 Oct 2010 08:54:05 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Oct 2010 08:54:05 +0200 Received: from [131.160.126.209] ([131.160.126.209]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Oct 2010 08:54:04 +0200 Message-ID: <4CAD6E8C.7000404@ericsson.com> Date: Thu, 07 Oct 2010 09:54:04 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Tom Kristensen <2mkristensen@gmail.com> References: <4CA9AA1D.6030508@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2010 06:54:04.0979 (UTC) FILETIME=[6E713030:01CB65EC] X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" , Tom Kristensen Subject: Re: [AVT] AD review: draft-ietf-avt-rtp-h264-rcdo-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 06:53:06 -0000 Hi Tom, thanks for putting this new revision rogether. The next step is for me to start its IETF LC. I will do that as soon as I have a minute. Cheers, Gonzalo On 06/10/2010 5:50 PM, Tom Kristensen wrote: > On 4 October 2010 12:19, Gonzalo Camarillo > wrote: >> Hi, >> >> as part of a load balancing exercise between Robert and I, I will be >> acting as the responsible AD for this draft. >> >> https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-h264-rcdo/ >> >> Below you can find my AD review. As soon as the authors address these >> comments (it should be trivial to address them), I will IETF Last Call >> this draft. > > Great, thanks! I just submitted a new version addressing these > comments as detailed below. > > [...] >> The acronyms RTP and RCDO need to be expanded in the title of the >> draft. In general, all acronyms need to be expanded on their first >> use. > > RTP kept as is, cf. answer to SVC draft on this list. Other "not > well-known" acronyms are now expanded. > >> The document refers to [3] as RFC3984bis. Given that [3] is a >> normative reference, this document will not be published until [3] is >> published as well. So, referring to it as, say, RFCYYYY and then get >> the RFC Editor to update the text seems like a better option than >> calling it RFC3984bis. > > Done. We also have to remember syncing the identical parts of the > media subtype definition with draft-ietf-avt-rtp-rfc3984bis-11 when > it's 100% sure this will not change. > >> Page 19: section X should be section 9. > > Fixed. > >> Section 9: "although if suitable the usage of SRTP [11] is >> recommended". Should that be a normative RECOMMENDED instead? > > Not so sure, so in spirit of draft-ietf-avt-srtp-not-mandatory the > following sentence is used instead: > > "Usage of data origin authentication and data integrity protection of > at least the RTP packet is RECOMMENDED, for example by use of the > Secure Real-time Transport Protocol (SRTP) ." > >> The draft should have a reference to the SDP spec: RFC 4566. > > Yes, now referenced in the Introduction section. > > -- Tom > From magnus.westerlund@ericsson.com Thu Oct 7 00:06:53 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F3E3A6F41 for ; Thu, 7 Oct 2010 00:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.456 X-Spam-Level: X-Spam-Status: No, score=-106.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL4zhop9O3n9 for ; Thu, 7 Oct 2010 00:06:52 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5CE363A6DFA for ; Thu, 7 Oct 2010 00:06:52 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbfae00000264e-5a-4cad71c9c174 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F7.1F.09806.9C17DAC4; Thu, 7 Oct 2010 09:07:53 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Oct 2010 09:07:53 +0200 Received: from [147.214.153.84] ([147.214.153.84]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Oct 2010 09:07:53 +0200 Message-ID: <4CAD71C8.5000806@ericsson.com> Date: Thu, 07 Oct 2010 09:07:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <20100914165611.21618.35586.idtracker@localhost> <4CA33861.5070603@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com> <4CA9C1A5.9080508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com> <4CA9F4E5.2020402@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA9A8@xmb-sjc-215.amer.cisco.com> <4CAAE1BC.3080703@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FB165@xmb-sjc-215.amer.cisco.com> <4CAC85E9.2010508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FB20C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D4FB20C@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Oct 2010 07:07:53.0216 (UTC) FILETIME=[5C1C2000:01CB65EE] X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 07:06:53 -0000 Ali C. Begen (abegen) skrev 2010-10-06 17:53: > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, October 06, 2010 10:21 AM >> To: Ali C. Begen (abegen) >> Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org; avt@ietf.org >> Subject: Re: Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP >> Sessions) to Proposed Standard >> >> Hi, >> >> I would say that it is a failure of the design, to not make RAMS-R >> updates work well. I see one fix that would seem easy to avoid these >> problems. Create a new message type RAMS-U that is identical to RAMS-R >> except the message type and restrict it to work on a ongoing burst. The > > I don't think this is a good design choice. When the updates feature was desired by some folks, we only agreed to have it if it the messages still stayed "self-defining". Now, when a server receives a RAMS-U message but it does not have an ongoing burst since the first message (RAMS-R) was lost, it won't process it based on your definition. Yes, you are right that design would have such a impact. It was clearly not thought through in that dimension. > >> other way is to rip out update for now to avoid having this obviously >> broken mechanism stay in there. And if someone needs it in the future >> then define it properly. > > I think we can still keep the current text (about the update process) for those who are still planning to use it by putting a caution against such problems. Would that work for you? I think such a warning is the minimal change. As it appears that I am the only one that seems concerned despite the returning discussion of this issue I will hesitantly accept that. 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 tom.van_caenegem@alcatel-lucent.com Thu Oct 7 03:30:04 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839403A70CE for ; Thu, 7 Oct 2010 03:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.075 X-Spam-Level: X-Spam-Status: No, score=-4.075 tagged_above=-999 required=5 tests=[AWL=2.174, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEX2guxuQsaE for ; Thu, 7 Oct 2010 03:30:01 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id D24CA3A707C for ; Thu, 7 Oct 2010 03:30:00 -0700 (PDT) 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 o97AUvCv015783 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Oct 2010 12:30:57 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 7 Oct 2010 12:30:57 +0200 From: "Van Caenegem, Tom (Tom)" To: "Ali C. Begen (abegen)" , Magnus Westerlund Date: Thu, 7 Oct 2010 12:30:56 +0200 Thread-Topic: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard Thread-Index: ActlYcksLi1lQkpmQf2ZWFicKaMCdAAC80iAACZv2vA= Message-ID: References: <20100914165611.21618.35586.idtracker@localhost> <4CA33861.5070603@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com> <4CA9C1A5.9080508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com> <4CA9F4E5.2020402@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FA9A8@xmb-sjc-215.amer.cisco.com> <4CAAE1BC.3080703@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FB165@xmb-sjc-215.amer.cisco.com> <4CAC85E9.2010508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FB20C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D4FB20C@xmb-sjc-215.amer.cisco.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.64 on 155.132.188.83 Cc: "draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 10:30:04 -0000 Hi, I have never been in favour of the "UPDATE" usage of RAMS-R, and I guess we= did not think sufficiently through the corner cases that were created with= introducing/allowing it. Possibly a sequence number field for RAMS-R (and = proper usage definition) could have avoided the corner case Magnus mentions= . The least we should do is indeed mention the risks when a client uses RAM= S-R which could be also covered in the section "failure cases". Maybe it is= also worthwhile to restrict the usage of sending RAMS-R update message(s)= only after the RTP RX has received a RAMS-I message for the 1st RAMS-R mes= sage sent. I would be also in favour of having the possibility for a BRS to tell a RTP= -Rx NOT to make use of RAMS-R update messages (where for the same RAMS/bur= st transaction, at least one TLV field is provided with a different value o= r at least one TLV field is new, compared to the original RAMS-R). Such ind= ication could be by means of defining e.g. a 202 response code (RAMS reques= t has been accepted BUT no RAMS-R update messages allowed) in the 1st RAMS-= I message. Tom -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ali C= . Begen (abegen) Sent: woensdag 6 oktober 2010 17:53 To: Magnus Westerlund Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org; avt@ietf.org Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Propose= d Standard > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, October 06, 2010 10:21 AM > To: Ali C. Begen (abegen) > Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org; > avt@ietf.org > Subject: Re: Last Call: > (Unicast-Based Rapid > Acquisition of Multicast RTP > Sessions) to Proposed Standard > > Hi, > > I would say that it is a failure of the design, to not make RAMS-R > updates work well. I see one fix that would seem easy to avoid these > problems. Create a new message type RAMS-U that is identical to RAMS-R > except the message type and restrict it to work on a ongoing burst. > The I don't think this is a good design choice. When the updates feature was de= sired by some folks, we only agreed to have it if it the messages still sta= yed "self-defining". Now, when a server receives a RAMS-U message but it do= es not have an ongoing burst since the first message (RAMS-R) was lost, it = won't process it based on your definition. > other way is to rip out update for now to avoid having this obviously > broken mechanism stay in there. And if someone needs it in the future > then define it properly. I think we can still keep the current text (about the update process) for t= hose who are still planning to use it by putting a caution against such pro= blems. Would that work for you? -acbegen > I do want this finished up and published, but not with serious issue > part of the spec. > > Magnus > > > > > Ali C. Begen (abegen) skrev 2010-10-06 10:09: > > Dropping the ietf list off. > > > >>> Are you saying this: > >>> 1- The client makes a request but it gets lost. In the mean time, > >>> the client sends an update and the server thinks it is a > new > >> request and starts sending the burst > >> > >> No, > >> 1. the client sends a request intended to update an ongoing burst. > >> > >> 2. The RAMS-R (update) arrive to late. Thus triggering a second burst. > > > > Oh, Ok. Now I see your scenario (update arriving late and causing a > > new burst to start). Well, this is an ill scenario with > mid-session updates. While the chances are pretty slim for this > happen, it can happen. For this to happen, the client must really send an= update close to the join time and then the RAMS-R gets delayed for some re= ason. > > > > The only solution for this is that the client will send a RAMS-T for > > the second burst as soon as it detects it. Furthermore, if > the primary stream packets have a higher priority than the burst > packets (and they should if the network supports this), mcast stream won'= t be hurt. > > > > FWIW, mid-sessions updates are not problem-free. So if someone wants > > to implement it, they will have to live with the > complications. > > > >> 3. In the mean time, client gets an RAMS-I and joins the multicast > >> group > >> > >> 4. Burst + mcast creates a congestion. > >> > >>> > >>>> unwanted traffic. The client that detects this can surely > >>>> terminate the burst, but that will be after some delay, and traffic = has arrived. > >>> > >>> OK, so you are saying what I wrote above. Well, the client has to > >>> send a RAMS-T and upon receiving it, the server stops > the > >> burst. So that is not a big deal. If you are concerned about RAMS-T > >> being lost (which is repeated if the bust is not stopped), then I > >> will just remind you that this is a protocol where control messages > >> are not fully reliable (they are just repeated for redundancy as frequ= ently as 4585 allows). If you are really this unlucky, you will have a prob= lem but it will be only temporary. > >>> > >> > >> I will agree that you can stop the burst, but you have biased your > >> protocol by design against sending any RAMS-R with the purpose of > >> updating the parameter because other things happens than what you > >> intended to. Thus it will in most cases be better to not send an > >> RAMS-R update message and avoid the risk of tripping a second burst. > > > > Personally, I don't see the much benefit in using the RAMS-R > > updates. That's why they are optional for those who want to > implement them. > > > >> > >>> I don't think there is anything here that requires for us to burn > >>> our energy. FWIW, your proposal would not solve this > >> problem entirely, either. > >> > >> I agree that a RAMS-R sequence number would not resolve the issue > >> you described. However, it resolves the issue I have tried to > >> describe, I hope the above makes it clear. > >> > >>> > >>>>> > >>>>>>> > >>>>>>>> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a globa= lly > >>>>>>>> unique CNAME identifier." > >> [snip] > >> > >>>>> > >>>>>>>> If I understand the impact of a CNAME collision is that the > >>>>>>>> collision clients request will be mixed up, for example > >>>>>>>> terminating each others request, or update the values in the RAM= S-R. > >>>>>>> > >>>>>>> When they are unique, this won't happen. > >>>>>> > >>>>>> Just checking, but if that is the case then I am missing a > >>>>>> discussion of hijacking attacks in the security consideration > >>>>>> section by guessing your targets CNAME. > >>>>> > >>>>> We should probably mention this but I am not sure how the server > >>>>> can deal with this. Hijacking is not easy since the > >> attack > >>>> must take place at the same instant (more or less) with the > >>>> request from the authentic client. One of your family > >> members > >>>> can probably do this :) > >>>> > >>>> The real solution is where you have an more permanent id system > >>>> in place that you can connect through source authentication of the r= equests. > >>>> > >>>> In an SSM session that uses simple feedback model the RTP_Rx > >>>> cname may leak as they are redistributed. > >>>> > >>>> Based on that you could bombard a BRS with RAMS-T for example for > >>>> all known CNAMES and do that in a round-robin fashion across > >>>> channels and time. Depending on source address spoofing you will > >>>> more or less easy to find. But I do agree that it becomes a > >>>> little bit more a brute force attack, but an attacker could gain > >>>> knowledge about an important piece of information to mount the attac= k at all. > >>> > >>> SRTCP? > >> > >> SRTCP keyed with unique keys for each client will prevent anyone > >> else to send RAMS-T to terminate a burst you have initiated. > > > > OK. > > > >>> > >>>>>>> > >>>>>>>> 7. Section 7.3: > >>>>>>>> "The MSN value SHALL > >>>>>>>> be set to zero only when a new RAMS request is received." > >>>>>>>> > >>>>>>>> How is that actually known? And why reset it at all? Why not > >>>>>>>> increase if for each new RAMS-I message with new content, > >>>>>>>> independently if it is an update or a new request. > >>>>>>> > >>>>>>> If this is relating to a new burst request, then it is reset. > >>>>>>> Ow, what is the point of having a seqnum? If something has > >>>>>> changed compared to the previous RAMS-I, then MSN is incremented. = If it is just a re-xmit, MSN stays the same. > >>>>>> > >>>>>> I fully agree with the need for separating retransmissions from up= dates. > >>>>>> However, I wonder over the reset of the field for each new > >>>>>> RAMS-R. It appears to me to be more robust to simply increment > >>>>>> it rather than reset. Otherwise you can send RAMS-R(1) resulting i= n RAMS-I MSN =3D 0. > >>>>> > >>>>> I think we discussed this before. The RAMS-R numbers are no way > >>>>> correlated with the RAMS-I numbers. You are still > >> trying > >>>> to correlate them. > >>>> > >>>> Nope, the number here are still only to indicate that they are > >>>> different to get the sequence right. My point is that the client > >>>> can determine based on MSN if it is an repeat or a new RAMS-I based = on a new request. > >>> > >>> When the client receives a RAMS-I with MSN=3D0, it knows that RAMS-I > >>> was sent for a RAMS-R message that was received > >> the first time by the server or an identical repeat of the initial RAM= S-I message. > >>> > >>> But even if the client sends an updated request, the server may > >>> ignore it, may ignore the changes and subsequently > repeat > >> the earlier RAMS-I with no changes in it, which will have the > >> previous MSN. The server may not send anything at all or the > >> message may get lost. The client cannot assume the changes it > >> requested were honored by the server UNLESS there was > an > >> updated RAMS-I from the server. Even in that case, the RAMS-I > >> changes may be due to other things the server has > observed - > >> not the changes the client asked. > >>> > >>> So, the client should not really read too much in to the MSN > >>> values received. That is what I have been trying to explain in > >> this discussion. > >> > >> Also in this case I don't think we have been considering the same case= . > >> My case was the following. > >> > >> 1. C->S RAMS-R > >> 2a. S->C RAMS-I (MSN=3D0) > >> 2b. S->C Burst starts > >> 3. C->S RAMS-R(Intended to update first RAMS-R) 4. S: Burst ends 5. > >> S: RAMS-R from step 3 arrives in server and trigger new burst 6. > >> S->C RAMS-I (MSN=3D0) 7. S->C Second burst transmitted > >> > >> When the RAMS-I message from step 6 arrives the client may think > >> this is the same as the one in 2a. > >> > >> Are you assuming that there is a 4b RAMS-I message which indicates > >> that the first burst will be terminated that has MSN=3D1? What if > >> that is lost or not sent? > > > > Well that RAMS-I is not necessarily sent. And if sent, it may get > > lost. Again, this is an ill scenario with RAMS-R updates. But > here the problem is the second burst not failing to identify the > second RAMS-I. When the 2nd burst starts, the client will figure out, thi= ngs were screwed up. > > > >>> > >>>>> > >>>>>> Then a RAMS-R(2) that is intended to be an update but becomes > >>>>>> an new request results in an RAMS-I with MSN =3D 0. The client > >>>>>> will not know if this is an retransmission of RAMS-R(1) info. > >>>>>> The updated should result in MSN=3D1. So without comparing the > >>>>>> RAMS-I you can't determine if there > >>>>> > >>>>> The client checks the RAMS-I seqnum to see whether it is a > >>>>> repeat or new info. If RAMS-I MSN is zero, that is the first > >>>> RAMS-I anyway so it must be fully parsed. Does not matter which > >>>> RAMS-R actually generated it since that is the info > from > >> the > >>>> server until an updated RAMS-I is received. This is how the protocol= works. > >>>> > >>>> As I try to explain there is a case where you can get two RAMS-I > >>>> with MSN=3D0 in a row with different information. Thus not > >>>> providing any relieve for the client in the need to compare the > >>>> whole request with the previous one. > >>> > >>> So what? If you made a single request and received two RAMS-I message= s with MSN=3D0, that means they are identical. > No > >> need to compare them. If you made two requests and received two > >> RAMS-I messages with MSN=3D0, they are different messages and you need= to fully read them anyway. > >> > >> Okay, so your point is that as soon you have sent more than one > >> RAMS-R message to a BRS you will need to look at all RAMS-I and the > >> MSN becomes completely useless. But, then I think the document > >> needs to point out that MSN is only reliable to detect repeat > >> transmissions as long as you have sent no additional RAMS-R messages d= uring a minute or so. > > > > We should put some text about this. IF the client sent RAMS-R > > update(s), it should probably check every RAMS-I regardless > of MSN values. > > > > -acbegen > > > > > > > -- > > 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 Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From csp@csperkins.org Thu Oct 7 04:55:50 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1738B3A7106 for ; Thu, 7 Oct 2010 04:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.396 X-Spam-Level: X-Spam-Status: No, score=-103.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HH6xkWMbilrj for ; Thu, 7 Oct 2010 04:55:48 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 69BCC3A6F20 for ; Thu, 7 Oct 2010 04:55:48 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P3p5e-0006nE-aT; Thu, 07 Oct 2010 11:56:50 +0000 From: Colin Perkins To: Qin Wu In-Reply-To: <03b601cb5ed9$cd35f250$4f548a0a@china.huawei.com> X-Priority: 3 References: <03b601cb5ed9$cd35f250$4f548a0a@china.huawei.com> Message-Id: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 7 Oct 2010 12:56:47 +0100 X-Mailer: Apple Mail (2.936) Cc: Roland.Schott@telekom.de, avt@ietf.org Subject: Re: [AVT] Fw: I-D Action:draft-wu-avt-rtcp-xr-quality-monitoring-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 11:55:50 -0000 Qin, These changes generally look good, but I do still have some comments: - Section 4.2 has been rewritten as a General Synchronisation Offset =20 Metrics Block. This is a good direction, but the resulting text still =20= assumes that only two streams exist. In an RTP multimedia session =20 there can be an arbitrary number of streams, with the same RTCP CNAME, =20= not just two. I would suggest that this block be written such that one =20= stream reports a General Synchronisation Offset of zero, and other =20 streams with the same RTCP CNAME report their offset relative to that. =20= Note that the streams being synchronised are not necessarily audio and =20= video streams. - Section 5.1 updates the definition of the Frame Type Indicator to be =20= a Picture Type Indicator. The intent of the new definition is okay, =20 but the text is very unclear. Can you clarify? (same issue later) - Unlike the other metrics, the TR 101 290 decodability metrics report =20= block is entirely MPEG-2 specific. I suggest splitting this into a =20 separate draft, since it doesn=92t really relate to the other metrics =20= defined in this draft. Colin On 28 Sep 2010, at 07:53, Qin Wu wrote: > Hi, > The new version of draft-wu-avt-rtcp-xr-quality-monitoring-03 is =20 > available at: > = http://www.ietf.org/internet-drafts/draft-wu-avt-rtcp-xr-quality-monitorin= g-03.txt > which probably address the comments early received on the list. > Your further comments and suggestions are welcome! > > Regards! > -Qin > ----- Original Message ----- > From: > To: > Sent: Tuesday, September 28, 2010 2:15 PM > Subject: I-D Action:draft-wu-avt-rtcp-xr-quality-monitoring-03.txt > > >> A New Internet-Draft is available from the on-line Internet-Drafts =20= >> directories. >> >> Title : RTP Control Protocol Extended Reports (RTCP XR) =20 >> Report Blocks for Real- time Video Quality Monitoring >> Author(s) : W. Wu, et al. >> Filename : draft-wu-avt-rtcp-xr-quality-monitoring-03.txt >> Pages : 26 >> Date : 2010-09-27 >> >> This document defines a set of RTP Control Protocol Extended Reports >> (RTCP XR) Report Blocks and associated SDP parameters allowing the >> report of video quality metrics, primarily for video applications of >> RTP. >> >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-wu-avt-rtcp-xr-quality-monitorin= g-03.txt --=20 Colin Perkins http://csperkins.org/ From Even.roni@huawei.com Thu Oct 7 09:23:41 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6CC3A6F48 for ; Thu, 7 Oct 2010 09:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.309 X-Spam-Level: X-Spam-Status: No, score=-100.309 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0eCWgUvZwH3 for ; Thu, 7 Oct 2010 09:23:41 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C14783A6F2A for ; Thu, 7 Oct 2010 09:23:40 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9X009B2HKWW2@szxga04-in.huawei.com> for avt@ietf.org; Fri, 08 Oct 2010 00:24:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9X00FORHKVBU@szxga04-in.huawei.com> for avt@ietf.org; Fri, 08 Oct 2010 00:24:32 +0800 (CST) Received: from windows8d787f9 ([109.67.16.74]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9X00L2CHKFEN@szxml02-in.huawei.com>; Fri, 08 Oct 2010 00:24:32 +0800 (CST) Date: Thu, 07 Oct 2010 18:21:45 +0200 From: Roni Even In-reply-to: <01ec01cb5630$1ebf65f0$5c3e31d0$@net> To: 'Glen Zorn' , "'Ali C. Begen (abegen)'" , "'DRAGE, Keith (Keith)'" Message-id: <042601cb663b$c5317ed0$4f947c70$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: ActPUnSE8ENFPWaUQVel3aue0qsOJQGX7lUgAAE1QTAAAM1NkAAdEhQgA//NyNA= References: <00d801cb55b7$ffb41840$ff1c48c0$@net> <04CAD96D4C5A3D48B1919248A8FE0D540D2D23B0@xmb-sjc-215.amer.cisco.com> <01ec01cb5630$1ebf65f0$5c3e31d0$@net> Cc: 'IETF AVT WG' Subject: Re: [AVT] Consensus call - Token approach withindraft-ietf-avt-ports-for-ucast-mcast-rtp X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:23:42 -0000 Hi Glen, I will try to clarify the issue. The Port Mapping Between Unicast and Multicast RTP Sessions described in http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp-02 was discussed for a couple of IETF meeting and on the list. The initial approach that was agreed after we had a breakout session in previous IETF meeting was to use a cookie based solution even though it required more messages and you needed a cookie for every RTP session. Before the last IETF meeting there were proposal to update the solution to a token approach. In the token approach: - Tokens are port-independent (cookies are port-dependent) and only depend on the client's IP. That is, once a client gets its token, it can use it with any of its ports and with any Feedback Target. - Tokens address the concern raised by Magnus (http://www.ietf.org/mail-archive/web/avt/current/msg12617.html) - No need for keep-alives We had a discussion in Maastricht and the outcome is in http://www.ietf.org/proceedings/78/minutes/avt.txt There is a concern about the token solution as mentioned in the minutes in section 9 of http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 My understanding is that people wanted a token based solution but there are two approaches 1. Use the token only solution 2. Use a combination when if the request has only an IP address the response will be a token and if it will have both IP address and port the response will be a cookie. According to the minutes the support is for the second approach. We were trying to ask the list if this approach is OK. It is true that the begen individual draft as currently written is not a full replacement of the WG draft. Roni Even AVT co-chair > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Glen Zorn > Sent: Friday, September 17, 2010 8:18 AM > To: 'Ali C. Begen (abegen)'; 'DRAGE, Keith (Keith)' > Cc: 'IETF AVT WG' > Subject: Re: [AVT] Consensus call - Token approach withindraft-ietf- > avt-ports-for-ucast-mcast-rtp > > Ali C. Begen (abegen) [mailto://abegen@cisco.com] writes: > > ... > > > > 1) Incorporate material from draft-begen-avt-token-for-portmapping- > 01 > > into > > > draft-ietf-avt-ports-for-ucast-mcast-rtp > > > > The token draft, IMHO, is good enough and addresses our issues > > adequately. If we agree with this, we can simply continue working on > it > > and finish the work. > > > > If we disagree with this and think Cookie is what we need, then we > > finish the Cookie draft. > > Maybe I'm wrong but it sounds like you are proposing the wholesale > replacement of the text of a WG document with that your own individual > submission. It seems to me that in order for this to be a reasonable > course > the replacement text would need to be far superior to the existing > draft, > not just good enough/adequate for the purpose, unless, of course, the > existing WG draft is not good enough or inadequate; but if that is the > case, > it begs the question how it became a WG draft in the first place. > Furthermore, I would expect that such an outcome would necessarily be > the > result of strong consensus in the WG, not merely the absence of > complaint... > > ... > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From iesg-secretary@ietf.org Thu Oct 7 11:07:43 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3376A3A717D; Thu, 7 Oct 2010 11:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUUIGL2cETH8; Thu, 7 Oct 2010 11:07:42 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC7C3A716D; Thu, 7 Oct 2010 11:07:37 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20101007180737.12171.54613.idtracker@localhost> Date: Thu, 07 Oct 2010 11:07:37 -0700 Cc: avt@ietf.org Subject: [AVT] Last Call: (RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:07:43 -0000 The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video' as a 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 2010-10-21. 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. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-h264-rcdo/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-h264-rcdo/ The following IPR Declarations may be related to this I-D: /ipr/105/ /ipr/485/ From abegen@cisco.com Thu Oct 7 15:05:45 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765793A6C73 for ; Thu, 7 Oct 2010 15:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+PGwZ8VOLMw for ; Thu, 7 Oct 2010 15:05:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4CE543A6E30 for ; Thu, 7 Oct 2010 15:05:43 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK7grUyrR7Ht/2dsb2JhbACiPnGiEJxXAoJxglQEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,299,1283731200"; d="scan'208";a="600792003" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 07 Oct 2010 22:06:45 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o97M6jLu019609; Thu, 7 Oct 2010 22:06:45 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 15:06:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Oct 2010 15:06:15 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEF18@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard Thread-Index: ActlYcksLi1lQkpmQf2ZWFicKaMCdAAC80iAACZv2vAAGRa+oA== References: <20100914165611.21618.35586.idtracker@localhost><4CA33861.5070603@ericsson.com><04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com><4CA9C1A5.9080508@ericsson.com><04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com><4CA9F4E5.2020402@ericsson.com><04CAD96D4C5A3D48B1919248A8FE0D540D4FA9A8@xmb-sjc-215.amer.cisco.com><4CAAE1BC.3080703@ericsson.com><04CAD96D4C5A3D48B1919248A8FE0D540D4FB165@xmb-sjc-215.amer.cisco.com><4CAC85E9.2010508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FB20C@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Van Caenegem, Tom (Tom)" , "Magnus Westerlund" X-OriginalArrivalTime: 07 Oct 2010 22:06:45.0472 (UTC) FILETIME=[EE3D4E00:01CB666B] Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org, avt@ietf.org Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 22:05:45 -0000 > -----Original Message----- > From: Van Caenegem, Tom (Tom) = [mailto:tom.van_caenegem@alcatel-lucent.com] > Sent: Thursday, October 07, 2010 6:31 PM > To: Ali C. Begen (abegen); Magnus Westerlund > Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org; = avt@ietf.org > Subject: RE: [AVT] Last = Call: (Unicast-Based = Rapid Acquisition of Multicast RTP > Sessions) to Proposed Standard >=20 > Hi, >=20 > I have never been in favour of the "UPDATE" usage of RAMS-R, and I = guess we did not think sufficiently through the corner > cases that were created with introducing/allowing it. Possibly a = sequence number field for RAMS-R (and proper usage > definition) could have avoided the corner case Magnus mentions. The = least we should do is indeed mention the risks when a > client uses RAMS-R which could be also covered in the section "failure = cases". Maybe it is also worthwhile to restrict the > usage of sending RAMS-R update message(s) only after the RTP RX has = received a RAMS-I message for the 1st RAMS-R > message sent. >=20 > I would be also in favour of having the possibility for a BRS to tell = a RTP-Rx NOT to make use of RAMS-R update messages > (where for the same RAMS/burst transaction, at least one TLV field is = provided with a different value or at least one TLV field > is new, compared to the original RAMS-R). Such indication could be by = means of defining e.g. a 202 response code (RAMS > request has been accepted BUT no RAMS-R update messages allowed) in = the 1st RAMS-I message. If the rams-updates is not signaled in SDP, the client is not supposed = to send update messages. So, just don't put it in the SDP. -acbegen =20 > Tom >=20 >=20 >=20 >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. Begen (abegen) > Sent: woensdag 6 oktober 2010 17:53 > To: Magnus Westerlund > Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org; = avt@ietf.org > Subject: Re: [AVT] Last Call: = (Unicast-Based Rapid = Acquisition of Multicast RTP > Sessions) to Proposed Standard >=20 >=20 >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Wednesday, October 06, 2010 10:21 AM > > To: Ali C. Begen (abegen) > > Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org; > > avt@ietf.org > > Subject: Re: Last Call: > > (Unicast-Based = Rapid > > Acquisition of Multicast RTP > > Sessions) to Proposed Standard > > > > Hi, > > > > I would say that it is a failure of the design, to not make RAMS-R > > updates work well. I see one fix that would seem easy to avoid these > > problems. Create a new message type RAMS-U that is identical to = RAMS-R > > except the message type and restrict it to work on a ongoing burst. > > The >=20 > I don't think this is a good design choice. When the updates feature = was desired by some folks, we only agreed to have it if it > the messages still stayed "self-defining". Now, when a server receives = a RAMS-U message but it does not have an ongoing > burst since the first message (RAMS-R) was lost, it won't process it = based on your definition. >=20 > > other way is to rip out update for now to avoid having this = obviously > > broken mechanism stay in there. And if someone needs it in the = future > > then define it properly. >=20 > I think we can still keep the current text (about the update process) = for those who are still planning to use it by putting a > caution against such problems. Would that work for you? >=20 > -acbegen >=20 > > I do want this finished up and published, but not with serious issue > > part of the spec. > > > > Magnus > > > > > > > > > > Ali C. Begen (abegen) skrev 2010-10-06 10:09: > > > Dropping the ietf list off. > > > > > >>> Are you saying this: > > >>> 1- The client makes a request but it gets lost. In the mean = time, > > >>> the client sends an update and the server thinks it is a > > new > > >> request and starts sending the burst > > >> > > >> No, > > >> 1. the client sends a request intended to update an ongoing = burst. > > >> > > >> 2. The RAMS-R (update) arrive to late. Thus triggering a second = burst. > > > > > > Oh, Ok. Now I see your scenario (update arriving late and causing = a > > > new burst to start). Well, this is an ill scenario with > > mid-session updates. While the chances are pretty slim for this > > happen, it can happen. For this to happen, the client must really = send an update close to the join time and then the RAMS-R > gets delayed for some reason. > > > > > > The only solution for this is that the client will send a RAMS-T = for > > > the second burst as soon as it detects it. Furthermore, if > > the primary stream packets have a higher priority than the burst > > packets (and they should if the network supports this), mcast stream = won't be hurt. > > > > > > FWIW, mid-sessions updates are not problem-free. So if someone = wants > > > to implement it, they will have to live with the > > complications. > > > > > >> 3. In the mean time, client gets an RAMS-I and joins the = multicast > > >> group > > >> > > >> 4. Burst + mcast creates a congestion. > > >> > > >>> > > >>>> unwanted traffic. The client that detects this can surely > > >>>> terminate the burst, but that will be after some delay, and = traffic has arrived. > > >>> > > >>> OK, so you are saying what I wrote above. Well, the client has = to > > >>> send a RAMS-T and upon receiving it, the server stops > > the > > >> burst. So that is not a big deal. If you are concerned about = RAMS-T > > >> being lost (which is repeated if the bust is not stopped), then I > > >> will just remind you that this is a protocol where control = messages > > >> are not fully reliable (they are just repeated for redundancy as = frequently as 4585 allows). If you are really this unlucky, > you will have a problem but it will be only temporary. > > >>> > > >> > > >> I will agree that you can stop the burst, but you have biased = your > > >> protocol by design against sending any RAMS-R with the purpose of > > >> updating the parameter because other things happens than what you > > >> intended to. Thus it will in most cases be better to not send an > > >> RAMS-R update message and avoid the risk of tripping a second = burst. > > > > > > Personally, I don't see the much benefit in using the RAMS-R > > > updates. That's why they are optional for those who want to > > implement them. > > > > > >> > > >>> I don't think there is anything here that requires for us to = burn > > >>> our energy. FWIW, your proposal would not solve this > > >> problem entirely, either. > > >> > > >> I agree that a RAMS-R sequence number would not resolve the issue > > >> you described. However, it resolves the issue I have tried to > > >> describe, I hope the above makes it clear. > > >> > > >>> > > >>>>> > > >>>>>>> > > >>>>>>>> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a = globally > > >>>>>>>> unique CNAME identifier." > > >> [snip] > > >> > > >>>>> > > >>>>>>>> If I understand the impact of a CNAME collision is that the > > >>>>>>>> collision clients request will be mixed up, for example > > >>>>>>>> terminating each others request, or update the values in = the RAMS-R. > > >>>>>>> > > >>>>>>> When they are unique, this won't happen. > > >>>>>> > > >>>>>> Just checking, but if that is the case then I am missing a > > >>>>>> discussion of hijacking attacks in the security consideration > > >>>>>> section by guessing your targets CNAME. > > >>>>> > > >>>>> We should probably mention this but I am not sure how the = server > > >>>>> can deal with this. Hijacking is not easy since the > > >> attack > > >>>> must take place at the same instant (more or less) with the > > >>>> request from the authentic client. One of your family > > >> members > > >>>> can probably do this :) > > >>>> > > >>>> The real solution is where you have an more permanent id system > > >>>> in place that you can connect through source authentication of = the requests. > > >>>> > > >>>> In an SSM session that uses simple feedback model the RTP_Rx > > >>>> cname may leak as they are redistributed. > > >>>> > > >>>> Based on that you could bombard a BRS with RAMS-T for example = for > > >>>> all known CNAMES and do that in a round-robin fashion across > > >>>> channels and time. Depending on source address spoofing you = will > > >>>> more or less easy to find. But I do agree that it becomes a > > >>>> little bit more a brute force attack, but an attacker could = gain > > >>>> knowledge about an important piece of information to mount the = attack at all. > > >>> > > >>> SRTCP? > > >> > > >> SRTCP keyed with unique keys for each client will prevent anyone > > >> else to send RAMS-T to terminate a burst you have initiated. > > > > > > OK. > > > > > >>> > > >>>>>>> > > >>>>>>>> 7. Section 7.3: > > >>>>>>>> "The MSN value SHALL > > >>>>>>>> be set to zero only when a new RAMS request is = received." > > >>>>>>>> > > >>>>>>>> How is that actually known? And why reset it at all? Why = not > > >>>>>>>> increase if for each new RAMS-I message with new content, > > >>>>>>>> independently if it is an update or a new request. > > >>>>>>> > > >>>>>>> If this is relating to a new burst request, then it is = reset. > > >>>>>>> Ow, what is the point of having a seqnum? If something has > > >>>>>> changed compared to the previous RAMS-I, then MSN is = incremented. If it is just a re-xmit, MSN stays the same. > > >>>>>> > > >>>>>> I fully agree with the need for separating retransmissions = from updates. > > >>>>>> However, I wonder over the reset of the field for each new > > >>>>>> RAMS-R. It appears to me to be more robust to simply = increment > > >>>>>> it rather than reset. Otherwise you can send RAMS-R(1) = resulting in RAMS-I MSN =3D 0. > > >>>>> > > >>>>> I think we discussed this before. The RAMS-R numbers are no = way > > >>>>> correlated with the RAMS-I numbers. You are still > > >> trying > > >>>> to correlate them. > > >>>> > > >>>> Nope, the number here are still only to indicate that they are > > >>>> different to get the sequence right. My point is that the = client > > >>>> can determine based on MSN if it is an repeat or a new RAMS-I = based on a new request. > > >>> > > >>> When the client receives a RAMS-I with MSN=3D0, it knows that = RAMS-I > > >>> was sent for a RAMS-R message that was received > > >> the first time by the server or an identical repeat of the = initial RAMS-I message. > > >>> > > >>> But even if the client sends an updated request, the server may > > >>> ignore it, may ignore the changes and subsequently > > repeat > > >> the earlier RAMS-I with no changes in it, which will have the > > >> previous MSN. The server may not send anything at all or the > > >> message may get lost. The client cannot assume the changes it > > >> requested were honored by the server UNLESS there was > > an > > >> updated RAMS-I from the server. Even in that case, the RAMS-I > > >> changes may be due to other things the server has > > observed - > > >> not the changes the client asked. > > >>> > > >>> So, the client should not really read too much in to the MSN > > >>> values received. That is what I have been trying to explain in > > >> this discussion. > > >> > > >> Also in this case I don't think we have been considering the same = case. > > >> My case was the following. > > >> > > >> 1. C->S RAMS-R > > >> 2a. S->C RAMS-I (MSN=3D0) > > >> 2b. S->C Burst starts > > >> 3. C->S RAMS-R(Intended to update first RAMS-R) 4. S: Burst ends = 5. > > >> S: RAMS-R from step 3 arrives in server and trigger new burst 6. > > >> S->C RAMS-I (MSN=3D0) 7. S->C Second burst transmitted > > >> > > >> When the RAMS-I message from step 6 arrives the client may think > > >> this is the same as the one in 2a. > > >> > > >> Are you assuming that there is a 4b RAMS-I message which = indicates > > >> that the first burst will be terminated that has MSN=3D1? What if > > >> that is lost or not sent? > > > > > > Well that RAMS-I is not necessarily sent. And if sent, it may get > > > lost. Again, this is an ill scenario with RAMS-R updates. But > > here the problem is the second burst not failing to identify the > > second RAMS-I. When the 2nd burst starts, the client will figure = out, things were screwed up. > > > > > >>> > > >>>>> > > >>>>>> Then a RAMS-R(2) that is intended to be an update but becomes > > >>>>>> an new request results in an RAMS-I with MSN =3D 0. The = client > > >>>>>> will not know if this is an retransmission of RAMS-R(1) info. > > >>>>>> The updated should result in MSN=3D1. So without comparing = the > > >>>>>> RAMS-I you can't determine if there > > >>>>> > > >>>>> The client checks the RAMS-I seqnum to see whether it is a > > >>>>> repeat or new info. If RAMS-I MSN is zero, that is the first > > >>>> RAMS-I anyway so it must be fully parsed. Does not matter which > > >>>> RAMS-R actually generated it since that is the info > > from > > >> the > > >>>> server until an updated RAMS-I is received. This is how the = protocol works. > > >>>> > > >>>> As I try to explain there is a case where you can get two = RAMS-I > > >>>> with MSN=3D0 in a row with different information. Thus not > > >>>> providing any relieve for the client in the need to compare the > > >>>> whole request with the previous one. > > >>> > > >>> So what? If you made a single request and received two RAMS-I = messages with MSN=3D0, that means they are identical. > > No > > >> need to compare them. If you made two requests and received two > > >> RAMS-I messages with MSN=3D0, they are different messages and you = need to fully read them anyway. > > >> > > >> Okay, so your point is that as soon you have sent more than one > > >> RAMS-R message to a BRS you will need to look at all RAMS-I and = the > > >> MSN becomes completely useless. But, then I think the document > > >> needs to point out that MSN is only reliable to detect repeat > > >> transmissions as long as you have sent no additional RAMS-R = messages during a minute or so. > > > > > > We should put some text about this. IF the client sent RAMS-R > > > update(s), it should probably check every RAMS-I regardless > > of MSN values. > > > > > > -acbegen > > > > > > > > > > > > -- > > > > 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 Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From tom.van_caenegem@alcatel-lucent.com Fri Oct 8 01:20:40 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983FE3A6839 for ; Fri, 8 Oct 2010 01:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.386 X-Spam-Level: X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[AWL=1.863, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4LUY8je+6nW for ; Fri, 8 Oct 2010 01:20:38 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 506583A67A3 for ; Fri, 8 Oct 2010 01:20:37 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o988LXlx009873 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Oct 2010 10:21:37 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 8 Oct 2010 10:21:34 +0200 From: "Van Caenegem, Tom (Tom)" To: "Ali C. Begen (abegen)" , Magnus Westerlund Date: Fri, 8 Oct 2010 10:19:30 +0200 Thread-Topic: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard Thread-Index: ActlYcksLi1lQkpmQf2ZWFicKaMCdAAC80iAACZv2vAAGRa+oAAVJ/Vw Message-ID: References: <20100914165611.21618.35586.idtracker@localhost><4CA33861.5070603@ericsson.com><04CAD96D4C5A3D48B1919248A8FE0D540D45A769@xmb-sjc-215.amer.cisco.com><4CA9C1A5.9080508@ericsson.com><04CAD96D4C5A3D48B1919248A8FE0D540D4FA908@xmb-sjc-215.amer.cisco.com><4CA9F4E5.2020402@ericsson.com><04CAD96D4C5A3D48B1919248A8FE0D540D4FA9A8@xmb-sjc-215.amer.cisco.com><4CAAE1BC.3080703@ericsson.com><04CAD96D4C5A3D48B1919248A8FE0D540D4FB165@xmb-sjc-215.amer.cisco.com><4CAC85E9.2010508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D4FB20C@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEF18@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEF18@xmb-sjc-215.amer.cisco.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.64 on 155.132.188.80 Cc: "draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 08:20:40 -0000 Ali, My mistake, I forgot about the SDP att. This draft development and completi= on process has taken (too) much time... Tom -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: vrijdag 8 oktober 2010 0:06 To: Van Caenegem, Tom (Tom); Magnus Westerlund Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org; avt@ietf.org Subject: RE: [AVT] Last Call: (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed= Standard > -----Original Message----- > From: Van Caenegem, Tom (Tom) > [mailto:tom.van_caenegem@alcatel-lucent.com] > Sent: Thursday, October 07, 2010 6:31 PM > To: Ali C. Begen (abegen); Magnus Westerlund > Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org; > avt@ietf.org > Subject: RE: [AVT] Last > Call: (Unicast-Based > Rapid Acquisition of Multicast RTP > Sessions) to Proposed Standard > > Hi, > > I have never been in favour of the "UPDATE" usage of RAMS-R, and I > guess we did not think sufficiently through the corner cases that were > created with introducing/allowing it. Possibly a sequence number field > for RAMS-R (and proper usage > definition) could have avoided the corner case Magnus mentions. The > least we should do is indeed mention the risks when a client uses > RAMS-R which could be also covered in the section "failure cases". > Maybe it is also worthwhile to restrict the usage of sending RAMS-R upda= te message(s) only after the RTP RX has received a RAMS-I message for the 1= st RAMS-R message sent. > > I would be also in favour of having the possibility for a BRS to tell > a RTP-Rx NOT to make use of RAMS-R update messages (where for the same > RAMS/burst transaction, at least one TLV field is provided with a > different value or at least one TLV field is new, compared to the origina= l RAMS-R). Such indication could be by means of defining e.g. a 202 respons= e code (RAMS request has been accepted BUT no RAMS-R update messages allowe= d) in the 1st RAMS-I message. If the rams-updates is not signaled in SDP, the client is not supposed to s= end update messages. So, just don't put it in the SDP. -acbegen > Tom > > > > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Ali C. Begen (abegen) > Sent: woensdag 6 oktober 2010 17:53 > To: Magnus Westerlund > Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org; > avt@ietf.org > Subject: Re: [AVT] Last Call: > (Unicast-Based Rapid > Acquisition of Multicast RTP > Sessions) to Proposed Standard > > > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Wednesday, October 06, 2010 10:21 AM > > To: Ali C. Begen (abegen) > > Cc: draft-ietf-avt-rapid-acquisition-for-rtp@tools.ietf.org; > > avt@ietf.org > > Subject: Re: Last Call: > > (Unicast-Based > > Rapid Acquisition of Multicast RTP > > Sessions) to Proposed Standard > > > > Hi, > > > > I would say that it is a failure of the design, to not make RAMS-R > > updates work well. I see one fix that would seem easy to avoid these > > problems. Create a new message type RAMS-U that is identical to > > RAMS-R except the message type and restrict it to work on a ongoing bur= st. > > The > > I don't think this is a good design choice. When the updates feature > was desired by some folks, we only agreed to have it if it the > messages still stayed "self-defining". Now, when a server receives a RAMS= -U message but it does not have an ongoing burst since the first message (R= AMS-R) was lost, it won't process it based on your definition. > > > other way is to rip out update for now to avoid having this > > obviously broken mechanism stay in there. And if someone needs it in > > the future then define it properly. > > I think we can still keep the current text (about the update process) > for those who are still planning to use it by putting a caution against s= uch problems. Would that work for you? > > -acbegen > > > I do want this finished up and published, but not with serious issue > > part of the spec. > > > > Magnus > > > > > > > > > > Ali C. Begen (abegen) skrev 2010-10-06 10:09: > > > Dropping the ietf list off. > > > > > >>> Are you saying this: > > >>> 1- The client makes a request but it gets lost. In the mean > > >>> time, the client sends an update and the server thinks it is a > > new > > >> request and starts sending the burst > > >> > > >> No, > > >> 1. the client sends a request intended to update an ongoing burst. > > >> > > >> 2. The RAMS-R (update) arrive to late. Thus triggering a second burs= t. > > > > > > Oh, Ok. Now I see your scenario (update arriving late and causing > > > a new burst to start). Well, this is an ill scenario with > > mid-session updates. While the chances are pretty slim for this > > happen, it can happen. For this to happen, the client must really > > send an update close to the join time and then the RAMS-R > gets delayed for some reason. > > > > > > The only solution for this is that the client will send a RAMS-T > > > for the second burst as soon as it detects it. Furthermore, if > > the primary stream packets have a higher priority than the burst > > packets (and they should if the network supports this), mcast stream wo= n't be hurt. > > > > > > FWIW, mid-sessions updates are not problem-free. So if someone > > > wants to implement it, they will have to live with the > > complications. > > > > > >> 3. In the mean time, client gets an RAMS-I and joins the > > >> multicast group > > >> > > >> 4. Burst + mcast creates a congestion. > > >> > > >>> > > >>>> unwanted traffic. The client that detects this can surely > > >>>> terminate the burst, but that will be after some delay, and traffi= c has arrived. > > >>> > > >>> OK, so you are saying what I wrote above. Well, the client has > > >>> to send a RAMS-T and upon receiving it, the server stops > > the > > >> burst. So that is not a big deal. If you are concerned about > > >> RAMS-T being lost (which is repeated if the bust is not stopped), > > >> then I will just remind you that this is a protocol where control > > >> messages are not fully reliable (they are just repeated for > > >> redundancy as frequently as 4585 allows). If you are really this > > >> unlucky, > you will have a problem but it will be only temporary. > > >>> > > >> > > >> I will agree that you can stop the burst, but you have biased > > >> your protocol by design against sending any RAMS-R with the > > >> purpose of updating the parameter because other things happens > > >> than what you intended to. Thus it will in most cases be better > > >> to not send an RAMS-R update message and avoid the risk of tripping = a second burst. > > > > > > Personally, I don't see the much benefit in using the RAMS-R > > > updates. That's why they are optional for those who want to > > implement them. > > > > > >> > > >>> I don't think there is anything here that requires for us to > > >>> burn our energy. FWIW, your proposal would not solve this > > >> problem entirely, either. > > >> > > >> I agree that a RAMS-R sequence number would not resolve the issue > > >> you described. However, it resolves the issue I have tried to > > >> describe, I hope the above makes it clear. > > >> > > >>> > > >>>>> > > >>>>>>> > > >>>>>>>> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a glo= bally > > >>>>>>>> unique CNAME identifier." > > >> [snip] > > >> > > >>>>> > > >>>>>>>> If I understand the impact of a CNAME collision is that the > > >>>>>>>> collision clients request will be mixed up, for example > > >>>>>>>> terminating each others request, or update the values in the R= AMS-R. > > >>>>>>> > > >>>>>>> When they are unique, this won't happen. > > >>>>>> > > >>>>>> Just checking, but if that is the case then I am missing a > > >>>>>> discussion of hijacking attacks in the security consideration > > >>>>>> section by guessing your targets CNAME. > > >>>>> > > >>>>> We should probably mention this but I am not sure how the > > >>>>> server can deal with this. Hijacking is not easy since the > > >> attack > > >>>> must take place at the same instant (more or less) with the > > >>>> request from the authentic client. One of your family > > >> members > > >>>> can probably do this :) > > >>>> > > >>>> The real solution is where you have an more permanent id system > > >>>> in place that you can connect through source authentication of the= requests. > > >>>> > > >>>> In an SSM session that uses simple feedback model the RTP_Rx > > >>>> cname may leak as they are redistributed. > > >>>> > > >>>> Based on that you could bombard a BRS with RAMS-T for example > > >>>> for all known CNAMES and do that in a round-robin fashion > > >>>> across channels and time. Depending on source address spoofing > > >>>> you will more or less easy to find. But I do agree that it > > >>>> becomes a little bit more a brute force attack, but an attacker > > >>>> could gain knowledge about an important piece of information to mo= unt the attack at all. > > >>> > > >>> SRTCP? > > >> > > >> SRTCP keyed with unique keys for each client will prevent anyone > > >> else to send RAMS-T to terminate a burst you have initiated. > > > > > > OK. > > > > > >>> > > >>>>>>> > > >>>>>>>> 7. Section 7.3: > > >>>>>>>> "The MSN value SHALL > > >>>>>>>> be set to zero only when a new RAMS request is received.= " > > >>>>>>>> > > >>>>>>>> How is that actually known? And why reset it at all? Why > > >>>>>>>> not increase if for each new RAMS-I message with new > > >>>>>>>> content, independently if it is an update or a new request. > > >>>>>>> > > >>>>>>> If this is relating to a new burst request, then it is reset. > > >>>>>>> Ow, what is the point of having a seqnum? If something has > > >>>>>> changed compared to the previous RAMS-I, then MSN is incremented= . If it is just a re-xmit, MSN stays the same. > > >>>>>> > > >>>>>> I fully agree with the need for separating retransmissions from = updates. > > >>>>>> However, I wonder over the reset of the field for each new > > >>>>>> RAMS-R. It appears to me to be more robust to simply > > >>>>>> increment it rather than reset. Otherwise you can send RAMS-R(1)= resulting in RAMS-I MSN =3D 0. > > >>>>> > > >>>>> I think we discussed this before. The RAMS-R numbers are no > > >>>>> way correlated with the RAMS-I numbers. You are still > > >> trying > > >>>> to correlate them. > > >>>> > > >>>> Nope, the number here are still only to indicate that they are > > >>>> different to get the sequence right. My point is that the > > >>>> client can determine based on MSN if it is an repeat or a new RAMS= -I based on a new request. > > >>> > > >>> When the client receives a RAMS-I with MSN=3D0, it knows that > > >>> RAMS-I was sent for a RAMS-R message that was received > > >> the first time by the server or an identical repeat of the initial R= AMS-I message. > > >>> > > >>> But even if the client sends an updated request, the server may > > >>> ignore it, may ignore the changes and subsequently > > repeat > > >> the earlier RAMS-I with no changes in it, which will have the > > >> previous MSN. The server may not send anything at all or the > > >> message may get lost. The client cannot assume the changes it > > >> requested were honored by the server UNLESS there was > > an > > >> updated RAMS-I from the server. Even in that case, the RAMS-I > > >> changes may be due to other things the server has > > observed - > > >> not the changes the client asked. > > >>> > > >>> So, the client should not really read too much in to the MSN > > >>> values received. That is what I have been trying to explain in > > >> this discussion. > > >> > > >> Also in this case I don't think we have been considering the same ca= se. > > >> My case was the following. > > >> > > >> 1. C->S RAMS-R > > >> 2a. S->C RAMS-I (MSN=3D0) > > >> 2b. S->C Burst starts > > >> 3. C->S RAMS-R(Intended to update first RAMS-R) 4. S: Burst ends 5. > > >> S: RAMS-R from step 3 arrives in server and trigger new burst 6. > > >> S->C RAMS-I (MSN=3D0) 7. S->C Second burst transmitted > > >> > > >> When the RAMS-I message from step 6 arrives the client may think > > >> this is the same as the one in 2a. > > >> > > >> Are you assuming that there is a 4b RAMS-I message which > > >> indicates that the first burst will be terminated that has MSN=3D1? > > >> What if that is lost or not sent? > > > > > > Well that RAMS-I is not necessarily sent. And if sent, it may get > > > lost. Again, this is an ill scenario with RAMS-R updates. But > > here the problem is the second burst not failing to identify the > > second RAMS-I. When the 2nd burst starts, the client will figure out, t= hings were screwed up. > > > > > >>> > > >>>>> > > >>>>>> Then a RAMS-R(2) that is intended to be an update but becomes > > >>>>>> an new request results in an RAMS-I with MSN =3D 0. The client > > >>>>>> will not know if this is an retransmission of RAMS-R(1) info. > > >>>>>> The updated should result in MSN=3D1. So without comparing the > > >>>>>> RAMS-I you can't determine if there > > >>>>> > > >>>>> The client checks the RAMS-I seqnum to see whether it is a > > >>>>> repeat or new info. If RAMS-I MSN is zero, that is the first > > >>>> RAMS-I anyway so it must be fully parsed. Does not matter which > > >>>> RAMS-R actually generated it since that is the info > > from > > >> the > > >>>> server until an updated RAMS-I is received. This is how the protoc= ol works. > > >>>> > > >>>> As I try to explain there is a case where you can get two > > >>>> RAMS-I with MSN=3D0 in a row with different information. Thus not > > >>>> providing any relieve for the client in the need to compare the > > >>>> whole request with the previous one. > > >>> > > >>> So what? If you made a single request and received two RAMS-I messa= ges with MSN=3D0, that means they are identical. > > No > > >> need to compare them. If you made two requests and received two > > >> RAMS-I messages with MSN=3D0, they are different messages and you ne= ed to fully read them anyway. > > >> > > >> Okay, so your point is that as soon you have sent more than one > > >> RAMS-R message to a BRS you will need to look at all RAMS-I and > > >> the MSN becomes completely useless. But, then I think the > > >> document needs to point out that MSN is only reliable to detect > > >> repeat transmissions as long as you have sent no additional RAMS-R m= essages during a minute or so. > > > > > > We should put some text about this. IF the client sent RAMS-R > > > update(s), it should probably check every RAMS-I regardless > > of MSN values. > > > > > > -acbegen > > > > > > > > > > > > -- > > > > 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 Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From root@core3.amsl.com Fri Oct 8 01:30:03 2010 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2FA2C3A6866; Fri, 8 Oct 2010 01:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101008083003.2FA2C3A6866@core3.amsl.com> Date: Fri, 8 Oct 2010 01:30:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-svc-23.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 08:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for Scalable Video Coding Author(s) : S. Wenger, et al. Filename : draft-ietf-avt-rtp-svc-23.txt Pages : 104 Date : 2010-10-08 This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in_Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backwards compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in [I- D.ietf-avt-rtp-rfc3984bis]. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others.Table of Contents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-23.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-svc-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-08012343.I-D@ietf.org> --NextPart-- From yekuiwang@huawei.com Fri Oct 8 01:35:23 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817BE3A6867 for ; Fri, 8 Oct 2010 01:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5bJbKQ8xN1w for ; Fri, 8 Oct 2010 01:35:21 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id B20323A6864 for ; Fri, 8 Oct 2010 01:35:13 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9Y00JA7QKA4A@usaga02-in.huawei.com> for avt@ietf.org; Fri, 08 Oct 2010 01:36:10 -0700 (PDT) Received: from W90946 ([10.46.56.211]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9Y00LOXQJBFU@usaga02-in.huawei.com> for avt@ietf.org; Fri, 08 Oct 2010 01:36:10 -0700 (PDT) Date: Fri, 08 Oct 2010 04:35:34 -0400 From: Ye-Kui Wang In-reply-to: <4CA9CE38.1040802@ericsson.com> To: 'Gonzalo Camarillo' , avt@ietf.org Message-id: <9853AF4A6C71409584827E9EC137F553@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Actjw5++/xV4KeIJTpS911kBjCCG3gC/l+/g References: <4CA9CE38.1040802@ericsson.com> Subject: Re: [AVT] AD review: draft-ietf-avt-rtp-svc-22 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 08:35:23 -0000 Hi Gonzalo, Thanks for your AD reivew. I have just submitted -23 wherein all your comments were addressed. > The acronyms RTP and SVC need to be expanded in the title. > All acronyms in the draft need to be expanded on their first use. > 'SVC' expended in the title. 'RTP' was not, per your discussion with Colin. I did not find any other acronyms that are not expanded on their first use. > Section 1.2.2 has a few non-normative statements such as "SST > should be used...". This normatively specified at a later > point in the document (Section 4.4). If Section 1 is meant to > be a non-normative overview of the specification, the draft > should say so somewhere. > Done, the last sentence before section 1.1 has been changed to: A non-normative overview of the SVC codec and the payload is given in the remainder of this section. > Page 80. When specifying behavior beyond RFC 3264, the draft > should use normative language. However, when specifying > behavior that is already specified in RFC 3264, the draft > should not use normative language. For example: "the offer > SHOULD also be used in the answer, as specified in > [RFC3264]". This issue also appears in other sections in the > document (e.g., in page 85). Simply s/SHOULD/should/ would > resolve the issue, for instance. Done. I systematically checked all 'SHOULD', and did not find any other places with this issue. BR, YK From Even.roni@huawei.com Fri Oct 8 01:49:07 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184AA3A681F for ; Fri, 8 Oct 2010 01:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.333 X-Spam-Level: X-Spam-Status: No, score=-100.333 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNHf3sJ6Z+Oj for ; Fri, 8 Oct 2010 01:49:05 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BB6303A67A3 for ; Fri, 8 Oct 2010 01:49:05 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9Y000T2R7BXU@szxga05-in.huawei.com> for avt@ietf.org; Fri, 08 Oct 2010 16:49:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9Y000YGR7943@szxga05-in.huawei.com> for avt@ietf.org; Fri, 08 Oct 2010 16:49:59 +0800 (CST) Received: from windows8d787f9 ([109.67.2.53]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9Y00C6QR7053@szxml01-in.huawei.com>; Fri, 08 Oct 2010 16:49:58 +0800 (CST) Date: Fri, 08 Oct 2010 10:47:16 +0200 From: Roni Even In-reply-to: <042601cb663b$c5317ed0$4f947c70$%roni@huawei.com> To: 'Roni Even' Message-id: <04ce01cb66c5$6f425640$4dc702c0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: ActPUnSE8ENFPWaUQVel3aue0qsOJQGX7lUgAAE1QTAAAM1NkAAdEhQgA//NyNAAJMcpgA== References: <00d801cb55b7$ffb41840$ff1c48c0$@net> <04CAD96D4C5A3D48B1919248A8FE0D540D2D23B0@xmb-sjc-215.amer.cisco.com> <01ec01cb5630$1ebf65f0$5c3e31d0$@net> <042601cb663b$c5317ed0$4f947c70$%roni@huawei.com> Cc: "'DRAGE, Keith \(Keith\)'" , 'IETF AVT WG' , 'Dan Wing' Subject: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 08:49:07 -0000 Hi guys, There were some concerns about how we drafted the consensus call so I would like to try and give it another try. Sorry for the long message which I hope will clarify what are the proposed options. We would like to get feedback by October 18th. The Port Mapping Between Unicast and Multicast RTP Sessions described in http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp-02 was discussed for a couple of IETF meeting and on the list. The initial approach that was agreed after we had a breakout session in previous IETF meetings was to use a cookie based solution even though it required more messages and you needed a cookie for every RTP session. Before the last IETF meeting there were two proposals to update the solution to a token based approach. In the token approach: - Tokens are port-independent (cookies are port-dependent) and only depend on the client's IP. That is, once a client gets its token, it can use it with any of its ports and with any Feedback Target. - Tokens address the concern raised by Magnus (http://www.ietf.org/mail-archive/web/avt/current/msg12617.html) - No need for keep-alives We had a discussion in Maastricht and the outcome is in the meeting minutes http://www.ietf.org/proceedings/78/minutes/avt.txt (see the section on draft-begen-avt-token-for-portmapping). The token draft has Dan Wing (who is also BEHAVE co-chair) as a co-author and he looked at the solution verifying that it will work well with NATs At the meeting the preference was for a token based solution but there are were two approaches discussed. 1. Use the token only solution 2. Use a combination when if the request has only an IP address the response will be a token and if it will have both IP address and port the response will be a cookie. According to the minutes the support was for the second approach. The major reason was a concern that carrier grade NATs can allocate more than one IP address as the public address. The authors of http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 suggest that they addressed the concerns about the token only solution (see section 9 of the draft) and prefer to have a token only solution. This is a change from the meeting minutes and this is the reason for the second question in this consensus call. So here are two questions for the group !!! 1. Do the people in the mailing list support the proposal to use a token based solution instead on the cookie one. (this was the preference in the consensus call in Maastricht) and we would like to confirm it on the list. 2. We have two options for the token approach, please give your preferences. 2.1 Token only solution as proposed in http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 2.2 Token + cookie, in this case if the request will include only IP address the response is a token, if it also includes a port it will be a cookie. This approach is for cases were the NAT may use more than one IP address for mapping a local address. Please respond even if you did it on the previous consensus call. Roni Even AVT co-chair From gonzalo.camarillo@ericsson.com Fri Oct 8 04:06:12 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417FA3A6864 for ; Fri, 8 Oct 2010 04:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.443 X-Spam-Level: X-Spam-Status: No, score=-106.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p68xhe+xnkcj for ; Fri, 8 Oct 2010 04:06:11 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 06A9D3A6841 for ; Fri, 8 Oct 2010 04:06:10 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae000006ad7-55-4caefb62e80d Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A4.8A.27351.26BFEAC4; Fri, 8 Oct 2010 13:07:14 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Oct 2010 13:07:12 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Oct 2010 13:07:12 +0200 Message-ID: <4CAEFB60.80205@ericsson.com> Date: Fri, 08 Oct 2010 14:07:12 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ye-Kui Wang References: <4CA9CE38.1040802@ericsson.com> <9853AF4A6C71409584827E9EC137F553@china.huawei.com> In-Reply-To: <9853AF4A6C71409584827E9EC137F553@china.huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Oct 2010 11:07:12.0827 (UTC) FILETIME=[F584A0B0:01CB66D8] X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVT] AD review: draft-ietf-avt-rtp-svc-22 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 11:06:12 -0000 Hi, thanks for revising the draft. I have just requested its IETF LC. Cheers, Gonzalo On 08/10/2010 11:35 AM, Ye-Kui Wang wrote: > > Hi Gonzalo, > > Thanks for your AD reivew. I have just submitted -23 wherein all your > comments were addressed. > >> The acronyms RTP and SVC need to be expanded in the title. >> All acronyms in the draft need to be expanded on their first use. >> > > 'SVC' expended in the title. 'RTP' was not, per your discussion with Colin. > I did not find any other acronyms that are not expanded on their first use. > >> Section 1.2.2 has a few non-normative statements such as "SST >> should be used...". This normatively specified at a later >> point in the document (Section 4.4). If Section 1 is meant to >> be a non-normative overview of the specification, the draft >> should say so somewhere. >> > > Done, the last sentence before section 1.1 has been changed to: > A non-normative overview of the SVC codec and the payload is given > in the remainder of this section. > >> Page 80. When specifying behavior beyond RFC 3264, the draft >> should use normative language. However, when specifying >> behavior that is already specified in RFC 3264, the draft >> should not use normative language. For example: "the offer >> SHOULD also be used in the answer, as specified in >> [RFC3264]". This issue also appears in other sections in the >> document (e.g., in page 85). Simply s/SHOULD/should/ would >> resolve the issue, for instance. > > Done. I systematically checked all 'SHOULD', and did not find any other > places with this issue. > > BR, YK > > From iesg-secretary@ietf.org Fri Oct 8 08:09:39 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08E73A6903; Fri, 8 Oct 2010 08:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNDvcqj0KXwN; Fri, 8 Oct 2010 08:09:38 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F3D3A689C; Fri, 8 Oct 2010 08:09:38 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20101008150938.10104.93116.idtracker@localhost> Date: Fri, 08 Oct 2010 08:09:38 -0700 Cc: avt@ietf.org Subject: [AVT] Last Call: (RTP Payload Format for Scalable Video Coding) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:09:39 -0000 The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'RTP Payload Format for Scalable Video Coding' as a 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 2010-10-22. 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. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-svc/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-svc/ The following IPR Declarations may be related to this I-D: /ipr/24/ /ipr/105/ /ipr/286/ /ipr/451/ /ipr/485/ /ipr/496/ /ipr/502/ /ipr/675/ /ipr/678/ /ipr/697/ /ipr/832/ /ipr/852/ /ipr/854/ /ipr/910/ /ipr/939/ /ipr/996/ /ipr/1365/ /ipr/1415/ /ipr/1416/ /ipr/1417/ /ipr/1418/ From sunseawq@huawei.com Fri Oct 8 21:48:23 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D523A67B3 for ; Fri, 8 Oct 2010 21:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.077 X-Spam-Level: X-Spam-Status: No, score=0.077 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eetn75ajJIYz for ; Fri, 8 Oct 2010 21:48:18 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 335A33A67B8 for ; Fri, 8 Oct 2010 21:48:18 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA000CT2AQ19O@szxga04-in.huawei.com> for avt@ietf.org; Sat, 09 Oct 2010 12:49:13 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA000FU0AQ1LD@szxga04-in.huawei.com> for avt@ietf.org; Sat, 09 Oct 2010 12:49:13 +0800 (CST) Received: from w53375 ([10.138.84.79]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA000EPXAQ1V8@szxml06-in.huawei.com> for avt@ietf.org; Sat, 09 Oct 2010 12:49:13 +0800 (CST) Date: Sat, 09 Oct 2010 12:49:11 +0800 From: Qin Wu To: avt@ietf.org Message-id: <010101cb676d$513735a0$4f548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/mixed; boundary="Boundary_(ID_/z9ztjkRCL3LRAudatW6Dw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 04:48:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_/z9ztjkRCL3LRAudatW6Dw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Folks, We have updated draft-wu-avt-retransmission-suppression-rtp which should now reflect the discussion we had since IETF78. The feedback suppression solution has also been greatly generalized comparing to the previous version. Comments are solicited. Regards! -Qin ----- Original Message ----- From: To: Sent: Saturday, October 09, 2010 12:45 PM Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : RTCP Report Extension for Feedback Suppression > Author(s) : W. Wu, et al. > Filename : draft-wu-avt-retransmission-supression-rtp-03.txt > Pages : 24 > Date : 2010-10-08 > > This document specifies an extension to the RTCP feedback messages > defined in the Audio-Visual Profile with Feedback (AVPF). This > extension allows an intermediate node in the network (such as an RTP > translator) inform downstream receivers that sending a feedback > message concerning a specified set of RTP messages may be > unnecessary, or even harmful. For example, in a source-specific > multicast session with large fan-out, packet loss close to the media > or distribution source of the session is detected as a loss by a > large number of receivers. The RTCP NACK messages used to request > retransmission of the missing packets are all addressed to the media > sender, or a designated feedback target. This may result in a > phenomenon known variously as a "NACK implosion" or "feedback storm". > The Feedback Suppression message defined herein is used to notify > receivers that packet loss was detected and that the sender of the > report will either proactively recover, or no recovery is possible. > Receivers respond to receipt of a feedback suppression message by not > sending a feedback message (e.g. a NACK) that they otherwise would, > This in turn reduces load on both the feedback target and on the > network. This document registers two new RTCP messages for Feedback > Suppression. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --Boundary_(ID_/z9ztjkRCL3LRAudatW6Dw) Content-type: text/plain; name=draft-wu-avt-retransmission-supression-rtp-03.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-wu-avt-retransmission-supression-rtp-03.txt Content-Type: text/plain Content-ID: <2010-10-08213710.I-D@ietf.org> --Boundary_(ID_/z9ztjkRCL3LRAudatW6Dw)-- From root@core3.amsl.com Sat Oct 9 02:15:04 2010 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9F1453A6860; Sat, 9 Oct 2010 02:15:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101009091504.9F1453A6860@core3.amsl.com> Date: Sat, 9 Oct 2010 02:15:04 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-mvc-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 09:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for MVC Video Author(s) : Y. Wang, T. Schierl Filename : draft-ietf-avt-rtp-mvc-01.txt Pages : 25 Date : 2010-10-09 This memo describes an RTP payload format for the multiview extension of the ITU-T Recommendation H.264 video codec that is technically identical to ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units, produced by the video encoder, in each RTP payload. The payload format can be applied in RTP based 3D video transmissions such as such as 3D video streaming, free- viewpoint video, and 3DTV. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mvc-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mvc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-09020958.I-D@ietf.org> --NextPart-- From yekuiwang@huawei.com Sat Oct 9 02:31:23 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3E73A686E for ; Sat, 9 Oct 2010 02:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgnXB1d0xv+f for ; Sat, 9 Oct 2010 02:31:22 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 336AB3A681F for ; Sat, 9 Oct 2010 02:31:22 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA0004K0NU4ND@usaga03-in.huawei.com> for avt@ietf.org; Sat, 09 Oct 2010 04:32:28 -0500 (CDT) Received: from W90946 ([120.196.86.171]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA000B0NNRJCU@usaga03-in.huawei.com> for avt@ietf.org; Sat, 09 Oct 2010 04:32:28 -0500 (CDT) Date: Sat, 09 Oct 2010 05:30:55 -0400 From: Ye-Kui Wang In-reply-to: <20101009091504.9F1453A6860@core3.amsl.com> To: avt@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Actnkqmw15L0Th6CSlCLAY7v8l5RgQAAX7BQ References: <20101009091504.9F1453A6860@core3.amsl.com> Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-mvc-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 09:31:23 -0000 Changes in relative to -00: Updated the NAL unit header syntax and semantics in section 3.3 per the latest MVC specification, and made some other minor edits. BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Saturday, October 09, 2010 5:15 AM > To: i-d-announce@ietf.org > Cc: avt@ietf.org > Subject: [AVT] I-D Action:draft-ietf-avt-rtp-mvc-01.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport > Working Group of the IETF. > > > Title : RTP Payload Format for MVC Video > Author(s) : Y. Wang, T. Schierl > Filename : draft-ietf-avt-rtp-mvc-01.txt > Pages : 25 > Date : 2010-10-09 > > This memo describes an RTP payload format for the multiview > extension of the ITU-T Recommendation H.264 video codec that > is technically identical to ISO/IEC International Standard 14496-10. > The RTP payload format allows for packetization of one or > more Network Abstraction Layer (NAL) units, produced by the > video encoder, in each RTP payload. The payload format can > be applied in RTP based 3D video transmissions such as such > as 3D video streaming, free- viewpoint video, and 3DTV. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mvc-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > From root@core3.amsl.com Sat Oct 9 03:15:02 2010 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5DFA93A687D; Sat, 9 Oct 2010 03:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101009101502.5DFA93A687D@core3.amsl.com> Date: Sat, 9 Oct 2010 03:15:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-12.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 10:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for H.264 Video Author(s) : Y. Wang, et al. Filename : draft-ietf-avt-rtp-rfc3984bis-12.txt Pages : 104 Date : 2010-10-09 This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multivew Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in section 15. Issues on backward compatibility to RFC 3984 are discussed in section 14. Table of Contents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-rfc3984bis-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-rfc3984bis-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-09030719.I-D@ietf.org> --NextPart-- From yekuiwang@huawei.com Sat Oct 9 03:27:10 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56953A69E0 for ; Sat, 9 Oct 2010 03:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJMNmaQbdVAN for ; Sat, 9 Oct 2010 03:27:09 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 0B77E3A69DA for ; Sat, 9 Oct 2010 03:27:09 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA0007SIQF3S0@usaga03-in.huawei.com> for avt@ietf.org; Sat, 09 Oct 2010 05:28:15 -0500 (CDT) Received: from W90946 ([120.196.86.171]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA000B25QDCCU@usaga03-in.huawei.com> for avt@ietf.org; Sat, 09 Oct 2010 05:28:14 -0500 (CDT) Date: Sat, 09 Oct 2010 06:27:09 -0400 From: Ye-Kui Wang In-reply-to: <20101009101502.5DFA93A687D@core3.amsl.com> To: avt@ietf.org Message-id: <9C02E00394D44878975BBB22050D0E14@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Actnmy4HiYMZNR3gTgmRIZK/4pwfCQAAIS0A References: <20101009101502.5DFA93A687D@core3.amsl.com> Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-12.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 10:27:11 -0000 This revision addressed the max-smbps issue discussed in the list, with a change from "The value of max-smbps MUST be greater than the value of ..." to "The value of max-smbps MUST be equal to or greater than the value of ...", which was supported by a few persons and was not objected by anybody. In addition, some minor editorial changes were made. BR, YK > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Saturday, October 09, 2010 6:15 AM > To: i-d-announce@ietf.org > Cc: avt@ietf.org > Subject: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-12.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport > Working Group of the IETF. > > > Title : RTP Payload Format for H.264 Video > Author(s) : Y. Wang, et al. > Filename : draft-ietf-avt-rtp-rfc3984bis-12.txt > Pages : 104 > Date : 2010-10-09 > > This memo describes an RTP Payload format for the ITU-T > Recommendation H.264 video codec and the technically > identical ISO/IEC International Standard 14496-10 video > codec, excluding the Scalable Video Coding (SVC) extension > and the Multivew Video Coding extension, for which the RTP > payload formats are defined elsewhere. > The RTP payload format allows for packetization of one or > more Network Abstraction Layer Units (NALUs), produced by an > H.264 video encoder, in each RTP payload. The payload format > has wide applicability, as it supports applications from > simple low bit-rate conversational usage, to Internet video > streaming with interleaved transmission, to high bit-rate > video-on-demand. > > This memo obsoletes RFC 3984. Changes from RFC 3984 are > summarized in section 15. Issues on backward compatibility > to RFC 3984 are discussed in section 14. > > > > Table of Contents > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-rfc3984 > bis-12.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > From abegen@cisco.com Sat Oct 9 09:37:07 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3593A684A for ; Sat, 9 Oct 2010 09:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MACc3StsvXGz for ; Sat, 9 Oct 2010 09:37:06 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2CF5E3A687E for ; Sat, 9 Oct 2010 09:37:06 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEc3sEyrR7H+/2dsb2JhbACiRHGecZwphUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,308,1283731200"; d="scan'208";a="198313050" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2010 16:38:13 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o99GcDNo014691; Sat, 9 Oct 2010 16:38:13 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Oct 2010 09:38:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Oct 2010 09:38:06 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <010101cb676d$513735a0$4f548a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 Thread-Index: ActnbWQGEy4/dtD9Q5i8yf8alIiMjwAYvH8g References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> From: "Ali C. Begen (abegen)" To: "Qin Wu" , X-OriginalArrivalTime: 09 Oct 2010 16:38:13.0609 (UTC) FILETIME=[5DE13590:01CB67D0] Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 16:37:08 -0000 Comments: 1) Abstract is too long, could you shorten it? Typos in abstract: a) .. that *are* sending ... b) RTP messages -> RTP packets c) "the sender of the report will either proactively recover": Well, it = does not have to be the sender of the report who will attempt the = recovery. I would rephrase this. 2) Throughout the document, avoiding "sender" might be a good idea. For = the source, use media or distribution source. Sender may mean different = things in different contexts. 3) Intro 1st paragraph: The retransmission payload format is 4588 not = 4585. 4) Most of the discussion in the introduction section can be shortened = in a concrete way by referring to other existing RFC in this area. I am = actually quite surprised that RFC 5740 is not mentioned at all here. I = would rather refer to RFC 5740 (rather than DVB-IPTV). 5) Do not use (upper-case) 2119 keywords in the introduction. IESG does = not like it :) 6) Section 2: The definitions seem to evolve around SSM. Why would not = they apply to ASM? 7) Section 3 and further on: There are several lower-case 2119 keywords = in the text which you might wanna replace. 8) Section 6.1.1 says "If the loss reporter is part of group, the = Distribution source MUST filter this packet out and not forward it back = to this loss reporter." How does it filter that loss reporter out? 9) What about the cases where the receiver will actually not send a NACK = despite the packet loss? Consider where there is also a FEC stream that = can recover the lost packets. Should the loss reporter listen to the FEC = channel as well and act accordingly? 10) You seem to assume that different loss reporters will always see the = same losses. That is not necessarily true. What should be reported back = to the receivers if the reports coming to the FT are conflicting? Do you = report the union or intersection of the reports back to the receivers? 11) You also seem to be relating this NACK implosion to retransmission. = I would actually prefer to keep the retransmission stuff out of the text = here (just mention it in the introduction and then forget about it). = Whether the distribution source actually retransmits the missing packets = or not has nothing to do with the messages defined in this draft. -acbegen=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Qin Wu > Sent: Saturday, October 09, 2010 12:49 PM > To: avt@ietf.org > Subject: [AVT] New Version Notification for = draft-wu-avt-retransmission-supression-rtp-03 >=20 > Folks, >=20 > We have updated draft-wu-avt-retransmission-suppression-rtp which = should now reflect the discussion we had since IETF78. >=20 > The feedback suppression solution has also been greatly generalized = comparing to the previous version. >=20 > Comments are solicited. >=20 > Regards! > -Qin > ----- Original Message ----- > From: > To: > Sent: Saturday, October 09, 2010 12:45 PM > Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt >=20 >=20 > >A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > > > Title : RTCP Report Extension for Feedback Suppression > > Author(s) : W. Wu, et al. > > Filename : draft-wu-avt-retransmission-supression-rtp-03.txt > > Pages : 24 > > Date : 2010-10-08 > > > > This document specifies an extension to the RTCP feedback messages > > defined in the Audio-Visual Profile with Feedback (AVPF). This > > extension allows an intermediate node in the network (such as an RTP > > translator) inform downstream receivers that sending a feedback > > message concerning a specified set of RTP messages may be > > unnecessary, or even harmful. For example, in a source-specific > > multicast session with large fan-out, packet loss close to the media > > or distribution source of the session is detected as a loss by a > > large number of receivers. The RTCP NACK messages used to request > > retransmission of the missing packets are all addressed to the media > > sender, or a designated feedback target. This may result in a > > phenomenon known variously as a "NACK implosion" or "feedback = storm". > > The Feedback Suppression message defined herein is used to notify > > receivers that packet loss was detected and that the sender of the > > report will either proactively recover, or no recovery is possible. > > Receivers respond to receipt of a feedback suppression message by = not > > sending a feedback message (e.g. a NACK) that they otherwise would, > > This in turn reduces load on both the feedback target and on the > > network. This document registers two new RTCP messages for Feedback > > Suppression. > > > > A URL for this Internet-Draft is: > > = http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supressio= n-rtp-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > >=20 >=20 > = -------------------------------------------------------------------------= ------- >=20 >=20 > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From Even.roni@huawei.com Sun Oct 10 14:03:23 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275683A6832 for ; Sun, 10 Oct 2010 14:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp-cnH9VNaHU for ; Sun, 10 Oct 2010 14:03:22 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B2F293A6819 for ; Sun, 10 Oct 2010 14:03:21 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA300680EJ9O8@szxga04-in.huawei.com> for avt@ietf.org; Mon, 11 Oct 2010 05:04:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA3005LOEJ92N@szxga04-in.huawei.com> for avt@ietf.org; Mon, 11 Oct 2010 05:04:21 +0800 (CST) Received: from windows8d787f9 (bzq-79-180-19-128.red.bezeqint.net [79.180.19.128]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA30011TEIYGT@szxml01-in.huawei.com>; Mon, 11 Oct 2010 05:04:21 +0800 (CST) Date: Sun, 10 Oct 2010 23:01:28 +0200 From: Roni Even To: 'IETF AVT WG' Message-id: <05d401cb68be$550c8570$ff259050$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_66KiQgbVd+0DeUEk1N5RuA)" Content-language: en-us Thread-index: Actovk1IULw7qmZ3RdegKErV5rqWmg== Cc: avt-chairs@tools.ietf.org Subject: [AVT] Requests for agenda time in Beijing - IETF 79 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 21:03:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_66KiQgbVd+0DeUEk1N5RuA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, If you wish to have agenda time at the upcoming meeting in Beijing , please send an agenda request to the chairs. We are trying to prepare the agenda early and not wait for the last minute. We will allocate time for port mapping to finalize the token/cookie issue. We will use the rest of the time for presentations giving priority based on the AVT milestones and open issues. We have two time slot in the preliminary agenda: Monday, Afternoon Session I 13:00-15:00 Wednesday , Afternoon Session I 13:00-15:00 Please note that this is not the final agenda yet. Thanks Roni Even and Keith Drage AVT Chairs --Boundary_(ID_66KiQgbVd+0DeUEk1N5RuA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

 

If you wish to have agenda time at the upcoming meeting in Beijing , please send an agenda request to the = chairs. We are trying to prepare the agenda early and not wait for the last = minute.

 

We will allocate time for port mapping = to finalize the token/cookie issue.

 

We will use the rest of the time for = presentations giving priority based on the AVT milestones and open issues. =

 

 

We have two time slot in the = preliminary agenda:

 

Monday, Afternoon Session I 13:00-15:00

 

Wednesday , Afternoon Session I 13:00-15:00

 

 

Please note that this is not the final = agenda yet.

 
= 
Thanks
= 
Roni Even and Keith =
Drage
AVT =
Chairs
 
=

 =

--Boundary_(ID_66KiQgbVd+0DeUEk1N5RuA)-- From sunseawq@huawei.com Mon Oct 11 01:37:26 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0D53A690C for ; Mon, 11 Oct 2010 01:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.064 X-Spam-Level: X-Spam-Status: No, score=0.064 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOhw51Bh9eiP for ; Mon, 11 Oct 2010 01:37:24 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 570383A6916 for ; Mon, 11 Oct 2010 01:37:23 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA4005SBAO003@szxga05-in.huawei.com> for avt@ietf.org; Mon, 11 Oct 2010 16:38:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA400EZEANZ27@szxga05-in.huawei.com> for avt@ietf.org; Mon, 11 Oct 2010 16:38:24 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA400L3CANZ5M@szxml06-in.huawei.com> for avt@ietf.org; Mon, 11 Oct 2010 16:38:23 +0800 (CST) Date: Mon, 11 Oct 2010 16:38:22 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , avt@ietf.org Message-id: <011501cb691f$aa2efd60$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35C@xmb-sjc-215.amer.cisco.com> Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 08:37:26 -0000 Hi, Ali Thank for your comments, please see my reply inline. ----- Original Message ----- From: "Ali C. Begen (abegen)" To: "Qin Wu" ; Sent: Sunday, October 10, 2010 12:38 AM Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 Comments: 1) Abstract is too long, could you shorten it? [Qin] Okay. Typos in abstract: a) .. that *are* sending ... [Qin]: You may misunderstand, the subject is actually "sending a feedback message" b) RTP messages -> RTP packets [Qin]: yes. c) "the sender of the report will either proactively recover": Well, it does not have to be the sender of the report who will attempt the recovery. I would rephrase this. [Qin]: Okay. 2) Throughout the document, avoiding "sender" might be a good idea. For the source, use media or distribution source. Sender may mean different things in different contexts. [Qin]: Okay. 3) Intro 1st paragraph: The retransmission payload format is 4588 not 4585. [Qin]: Good catch, thanks. 4) Most of the discussion in the introduction section can be shortened in a concrete way by referring to other existing RFC in this area. I am actually quite surprised that RFC 5740 is not mentioned at all here. I would rather refer to RFC 5740 (rather than DVB-IPTV). [Qin]; Okay. 5) Do not use (upper-case) 2119 keywords in the introduction. IESG does not like it :) [Qin]: Okay. 6) Section 2: The definitions seem to evolve around SSM. Why would not they apply to ASM? [Qin]: Right, they should apply to ASM. 7) Section 3 and further on: There are several lower-case 2119 keywords in the text which you might wanna replace. [Qin]: Okay, thanks. 8) Section 6.1.1 says "If the loss reporter is part of group, the Distribution source MUST filter this packet out and not forward it back to this loss reporter." How does it filter that loss reporter out? [Qin]: It is one optimized behavior. One possible way to do this is that the Distribution Source knows the address of loss reporter or know in which port it can receive the RTCP message from the loss reporter. Is that reasonable? 9) What about the cases where the receiver will actually not send a NACK despite the packet loss? Consider where there is also a FEC stream that can recover the lost packets. Should the loss reporter listen to the FEC channel as well and act accordingly? [Qin]: Good question. I think if the reciever know it will not send a NACK, then the distribution source should know as well. In such case, the distribution source may choose not to send feedback suppression message to the receiver. 10) You seem to assume that different loss reporters will always see the same losses. That is not necessarily true. What should be reported back to the receivers if the reports coming to the FT are conflicting? Do you report the union or intersection of the reports back to the receivers? [Qin]: If there are duplication reports, the Distribution source should filter the duplicated report out and only send one copy of report to the reciever. What the distribution source does is to create one summary report which only append different loss in this summary report. 11) You also seem to be relating this NACK implosion to retransmission. I would actually prefer to keep the retransmission stuff out of the text here (just mention it in the introduction and then forget about it). Whether the distribution source actually retransmits the missing packets or not has nothing to do with the messages defined in this draft. [Qin] Okay. -acbegen > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin Wu > Sent: Saturday, October 09, 2010 12:49 PM > To: avt@ietf.org > Subject: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 > > Folks, > > We have updated draft-wu-avt-retransmission-suppression-rtp which should now reflect the discussion we had since IETF78. > > The feedback suppression solution has also been greatly generalized comparing to the previous version. > > Comments are solicited. > > Regards! > -Qin > ----- Original Message ----- > From: > To: > Sent: Saturday, October 09, 2010 12:45 PM > Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : RTCP Report Extension for Feedback Suppression > > Author(s) : W. Wu, et al. > > Filename : draft-wu-avt-retransmission-supression-rtp-03.txt > > Pages : 24 > > Date : 2010-10-08 > > > > This document specifies an extension to the RTCP feedback messages > > defined in the Audio-Visual Profile with Feedback (AVPF). This > > extension allows an intermediate node in the network (such as an RTP > > translator) inform downstream receivers that sending a feedback > > message concerning a specified set of RTP messages may be > > unnecessary, or even harmful. For example, in a source-specific > > multicast session with large fan-out, packet loss close to the media > > or distribution source of the session is detected as a loss by a > > large number of receivers. The RTCP NACK messages used to request > > retransmission of the missing packets are all addressed to the media > > sender, or a designated feedback target. This may result in a > > phenomenon known variously as a "NACK implosion" or "feedback storm". > > The Feedback Suppression message defined herein is used to notify > > receivers that packet loss was detected and that the sender of the > > report will either proactively recover, or no recovery is possible. > > Receivers respond to receipt of a feedback suppression message by not > > sending a feedback message (e.g. a NACK) that they otherwise would, > > This in turn reduces load on both the feedback target and on the > > network. This document registers two new RTCP messages for Feedback > > Suppression. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > -------------------------------------------------------------------------------- > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From csp@csperkins.org Mon Oct 11 04:02:05 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82023A69A3 for ; Mon, 11 Oct 2010 04:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRf9NvnJgywK for ; Mon, 11 Oct 2010 04:02:04 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by core3.amsl.com (Postfix) with ESMTP id EC8623A699D for ; Mon, 11 Oct 2010 04:02:03 -0700 (PDT) Received: from [86.43.4.93] by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P5G9y-0000br-pa; Mon, 11 Oct 2010 11:03:15 +0000 Message-Id: From: Colin Perkins To: Ali C. Begen (abegen) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35C@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 11 Oct 2010 12:03:13 +0100 References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35C@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.936) Cc: avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 11:02:05 -0000 This draft is generally along the right lines, and =96 as discussed in =20= Maastricht =96 we should consider adopting it as a working group draft. =20= That said, I have a number of comments, which generally echo Ali's =20 comments: - The abstract needs to be rewritten as an abstract, rather than an =20 introduction. - Should note, in the introduction, that the NACK storm respects the =20 RTCP bandwidth constraint on average, but that na=EFve implementations =20= that don=92t choose to dither their response can cause short term =20 overload. There is no risk of congestion collapse, if the receivers =20 are correctly implemented. While there is a real problem to be solved, =20= I believe the discussion in the introduction overplays the risks. - The introduction includes RFC 2119 language specifying requirements =20= =96 this should be moved into Section 3. Specifically, I suggest the =20 last six paragraphs of the Introduction be moved into Section 3. - Section 3 contains a lot of discussion of the loss reporter and the =20= SSM use case. Much of this seems unnecessary in this part of the =20 draft: discussion of SSM and the loss reporter concept should be in =20 section 6.1, leaving section 3 to specify the general protocol =20 behaviour, independent of particular use cases. - Section 4 has unnecessary subheadings. Suggest removing the 4.1 =20 header then renaming section 4.1.1 to =934.1 Transport Layer Feedback: =20= NACK Suppression Report=94, and also removing the 4.2 header then =20 renaming section 4.2.1 to =934.2 Payload Specific Feedback: FIR =20 suppression report=94. - Section 7 should note that middleboxes that are not visible at the =20 RTP layer that wish to send NACK/FIR suppression reports on behalf of =20= the sender can only do so if they spoof the SSRC of the sender. This =20 is difficult is SRTP is in use. If the middlebox is visible at the RTP =20= layer, this is not an issue, provided the middlebox is part of the =20 security context for the session. - Section 7 should note that endpoints that receive a NACK/FIR =20 suppression request would be well-advised to ignore it, unless it is =20 authenticated via SRTCP or similar. Accepting un-authenticated NACK/=20 FIR suppression requests can lead to a denial of service attack, where =20= the endpoint accepts poor quality media that could be repaired. None of these are fundamental, and I don't think there's anything that =20= should delay adoption as a working group draft. Colin On 9 Oct 2010, at 17:38, Ali C. Begen (abegen) wrote: > Comments: > 1) Abstract is too long, could you shorten it? > > Typos in abstract: > a) .. that *are* sending ... > b) RTP messages -> RTP packets > c) "the sender of the report will either proactively recover": Well, =20= > it does not have to be the sender of the report who will attempt the =20= > recovery. I would rephrase this. > > 2) Throughout the document, avoiding "sender" might be a good idea. =20= > For the source, use media or distribution source. Sender may mean =20 > different things in different contexts. > > 3) Intro 1st paragraph: The retransmission payload format is 4588 =20 > not 4585. > > 4) Most of the discussion in the introduction section can be =20 > shortened in a concrete way by referring to other existing RFC in =20 > this area. I am actually quite surprised that RFC 5740 is not =20 > mentioned at all here. I would rather refer to RFC 5740 (rather than =20= > DVB-IPTV). > > 5) Do not use (upper-case) 2119 keywords in the introduction. IESG =20 > does not like it :) > > 6) Section 2: The definitions seem to evolve around SSM. Why would =20 > not they apply to ASM? > > 7) Section 3 and further on: There are several lower-case 2119 =20 > keywords in the text which you might wanna replace. > > 8) Section 6.1.1 says "If the loss reporter is part of group, the =20 > Distribution source MUST filter this packet out and not forward it =20 > back to this loss reporter." How does it filter that loss reporter =20 > out? > > 9) What about the cases where the receiver will actually not send a =20= > NACK despite the packet loss? Consider where there is also a FEC =20 > stream that can recover the lost packets. Should the loss reporter =20 > listen to the FEC channel as well and act accordingly? > > 10) You seem to assume that different loss reporters will always see =20= > the same losses. That is not necessarily true. What should be =20 > reported back to the receivers if the reports coming to the FT are =20 > conflicting? Do you report the union or intersection of the reports =20= > back to the receivers? > > 11) You also seem to be relating this NACK implosion to =20 > retransmission. I would actually prefer to keep the retransmission =20 > stuff out of the text here (just mention it in the introduction and =20= > then forget about it). Whether the distribution source actually =20 > retransmits the missing packets or not has nothing to do with the =20 > messages defined in this draft. > > -acbegen > > > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf =20= >> Of Qin Wu >> Sent: Saturday, October 09, 2010 12:49 PM >> To: avt@ietf.org >> Subject: [AVT] New Version Notification for draft-wu-avt-=20 >> retransmission-supression-rtp-03 >> >> Folks, >> >> We have updated draft-wu-avt-retransmission-suppression-rtp which =20 >> should now reflect the discussion we had since IETF78. >> >> The feedback suppression solution has also been greatly generalized =20= >> comparing to the previous version. >> >> Comments are solicited. >> >> Regards! >> -Qin >> ----- Original Message ----- >> From: >> To: >> Sent: Saturday, October 09, 2010 12:45 PM >> Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts =20= >>> directories. >>> >>> Title : RTCP Report Extension for Feedback Suppression >>> Author(s) : W. Wu, et al. >>> Filename : draft-wu-avt-retransmission-supression-rtp-03.txt >>> Pages : 24 >>> Date : 2010-10-08 >>> >>> This document specifies an extension to the RTCP feedback messages >>> defined in the Audio-Visual Profile with Feedback (AVPF). This >>> extension allows an intermediate node in the network (such as an RTP >>> translator) inform downstream receivers that sending a feedback >>> message concerning a specified set of RTP messages may be >>> unnecessary, or even harmful. For example, in a source-specific >>> multicast session with large fan-out, packet loss close to the media >>> or distribution source of the session is detected as a loss by a >>> large number of receivers. The RTCP NACK messages used to request >>> retransmission of the missing packets are all addressed to the media >>> sender, or a designated feedback target. This may result in a >>> phenomenon known variously as a "NACK implosion" or "feedback =20 >>> storm". >>> The Feedback Suppression message defined herein is used to notify >>> receivers that packet loss was detected and that the sender of the >>> report will either proactively recover, or no recovery is possible. >>> Receivers respond to receipt of a feedback suppression message by =20= >>> not >>> sending a feedback message (e.g. a NACK) that they otherwise would, >>> This in turn reduces load on both the feedback target and on the >>> network. This document registers two new RTCP messages for Feedback >>> Suppression. >>> >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression= -rtp-03.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> >> >> = --------------------------------------------------------------------------= ------ >> >> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon Oct 11 04:27:28 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A80283A69BC for ; Mon, 11 Oct 2010 04:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.979 X-Spam-Level: X-Spam-Status: No, score=-102.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmJq9W5D4HyC for ; Mon, 11 Oct 2010 04:27:27 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id 08D8C3A69B8 for ; Mon, 11 Oct 2010 04:27:27 -0700 (PDT) Received: from [86.43.4.93] by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P5GYX-0002Di-iq; Mon, 11 Oct 2010 11:28:38 +0000 From: Colin Perkins To: Qin Wu In-Reply-To: <030201cb5896$ab249070$4f548a0a@china.huawei.com> X-Priority: 3 References: <066801cb50d1$d3b2d2d0$4f548a0a@china.huawei.com> <030201cb5896$ab249070$4f548a0a@china.huawei.com> Message-Id: <74B2E4DA-7EBC-47FE-BC14-DCC6B9B0F084@csperkins.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 11 Oct 2010 12:28:35 +0100 X-Mailer: Apple Mail (2.936) Cc: Roland.Schott@telekom.de, avt@ietf.org Subject: Re: [AVT] Fw: I-D Action:draft-wu-avt-rtcp-xr-quality-monitoring-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 11:27:28 -0000 On 20 Sep 2010, at 08:37, Qin Wu wrote: > Hi, Colin: > Thank for your valuable comments. Please see my reply inline. > > Regards! > -Qin > ----- Original Message ----- > From: "Colin Perkins" > To: "Qin Wu" > Cc: ; > Sent: Friday, September 17, 2010 5:50 PM > Subject: Re: [AVT] Fw: I-D Action:draft-wu-avt-rtcp-xr-quality-=20 > monitoring-02.txt > > > I've read this draft, and have some comments. In general, I think it's > on the right lines, but there are a number of details to be resolved. > > [Qin]: Yes, you are right. The main changes we made for this draft =20 > is try to align with Monitoring Architecture draft, > which more focus on how to extend metric report using RTCP XR for =20 > monitoring purpose in the latest version. > > Initial synchronisation delay: okay > > Audio-video playout offset: makes sense in principle, but is defined > in a way that=92s specific to a simple scenario with one audio and one > video stream. This may be better defined as a general synchronisation > offset metric, which reports the offset of this stream relative to > other streams sent with the same RTCP CNAME (where the reference > stream reports offset of zero, and the others are signed offsets > relative to it). That would allow it to be used to report on more > complex synchronisation scenarios, rather than define other similar > metrics for those scenarios later > > [Qin]: Good suggestion. One generic metric will benefit for a large =20= > broad appliations. it is reasonable to replace the audio-video =20 > playout offset report with one more genric reusable metric. I will =20 > do this in the next version. > > In the layered stream statistics report block, the layer type flag is > phrased in terms of H.264 SVC video, but there is nothing particularly > SVC-specific here. Can it be written in a more general way, just > specifying base and enhancement layers, so the same metric can be used > for other layered codecs? > > [Qin]: I am not sure whether we need more finely granularity of =20 > enchancement layers to distinguish one enhancment layer from in =20 > other layered codecs Is it reasonable to only specify base and =20 > enhancment layers? Probably - depends on your use case. > It=92s not clear that the loss and duplicate reports need to be = optional > in the layered streams statistics metric block. They are straight > forward to calculate, and making them optional seems to only introduce > unnecessary complexity into the protocol. Similar for the video > statistics summary report block. > > [Qin] Good point. It seems these two indication fields for loss and =20= > duplication are > over-designed, I will remove them in the new version. > > The definition of the lost_layered component packets and dup_layered > component packets is under-specified. > > [Qin]: Okay, thank for catching this. we will specify this in the =20 > new version. > > Is the frame type indicator field used in the video statistics report > block and the video stream loss and discard metrics block well > defined? The characterisation of video frames into I, P, and B frames > makes sense for MPEG-2, but is it appropriate for other codecs? > > [Qin]: I think classifying video media into I, P and frames also =20 > works for MPEG-4, but they may take the different name like > I-VOP, B-VOP and P-VOP, for the other video Codec like V6, it also =20 > characterize the video into different picture types like I and P. > > Therefore may I propose to use key frame and reference frame to =20 > replace I,P, and B frames, which is more generic and can be used to =20= > distinguish different picture types. I like the idea, but I'm not sure that terminology is clearer. > Unlike the other metrics, the TR 101 290 decodability metrics report > block is entirely MPEG-2 specific. I suggest splitting this into a > separate draft, since it doesn=92t really relate to the other metrics > defined in this draft. > > [Qin]: I am not sure whether we should leave TR101 290 decodability =20= > metrics out from this draft. But I think this metrics could be taken =20= > as one of input to calculate the MOS-V which reflects the MPEG-2 =20 > media quality in some way. Yes, but that doesn't mean they need to be specified in this draft. As =20= I said before, this is entirely MPEG-2 specific, and so would be =20 better if submitted as a separate draft, unrelated to this RTP-level =20 metrics draft. > The RTP Terminal Configuration Metrics Block seems ill-thought out. > The PLC type field doesn=92t seem appropriate to video - the = definition > looks to be copied from an audio metrics draft. The JBA field is ill- > defined, and doesn=92t give meaningful information. The FEC field is > very limited, and too tied to particular FEC schemes in a way that is > not desirable: the media types namespace should be used here, rather > than defining a new, very limited, two-bit field, if you need to do > this at all. It's not clear that this information should be reported > in RTCP, since the same information is available in the SDP signalling > channel. > > [Qin]: I agree the parameters defined in this metrics can be =20 > obtained in the SDP signaling. It seems this Terminal related =20 > metrics looks like a evil. :-) But what I like to argue about is =20 > different type of terminal with differnt capability may demonstrate =20= > different reception quality to the users. Are we aware of that? =20 > Isn't valuable to take this terminal associated metrics into accout =20= > when we evaluate the media quality in the comprehensive way? Sure, but the information is already available, and doesn't need to be =20= duplicated here. --=20 Colin Perkins http://csperkins.org/ From ray.vanbrandenburg@tno.nl Mon Oct 11 06:13:09 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D67243A67F7 for ; Mon, 11 Oct 2010 06:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.366 X-Spam-Level: * X-Spam-Status: No, score=1.366 tagged_above=-999 required=5 tests=[AWL=1.871, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUPy6RDwR5Ey for ; Mon, 11 Oct 2010 06:13:08 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 49C103A67F6 for ; Mon, 11 Oct 2010 06:13:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,313,1283724000"; d="scan'208";a="10253053" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 11 Oct 2010 15:14:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Oct 2010 15:14:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-brandenburg-avt-rtcp-for-idms-02 Thread-Index: ActpQiZhpoquwD2DR7q2r7b1WkI6YgAAq+Zg From: "Brandenburg, R. (Ray) van" To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [AVT] New Version Notification for draft-brandenburg-avt-rtcp-for-idms-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 13:13:10 -0000 Hi All, We have recently updated our internet-draft for inter-destination-media synchronization using RTCP XR blocks. The updated version includes more references and a shortened abstract. We are looking forward to your comments and are especially interested in how you think our ID relates to recent work within this WG to specify guidelines for new XR blocks.=20 Regards, Ray van Brandenburg -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: maandag 11 oktober 2010 14:44 To: Brandenburg, R. (Ray) van Subject: New Version Notification for draft-brandenburg-avt-rtcp-for-idms-02=20 A new version of I-D, draft-brandenburg-avt-rtcp-for-idms-02.txt has been successfully submitted by Ray Brandenburg and posted to the IETF repository. Filename: draft-brandenburg-avt-rtcp-for-idms Revision: 02 Title: RTCP XR Block Type for inter-destination media synchronization Creation_date: 2010-10-11 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document specifies an RTCP XR Block Type and associated SDP parameter for inter-destination media synchronization (IDMS). The RTCP Block Type is used to collect media play-out information from participants in a group watching a specific RTP media stream and to distribute a summary of the collected information so that the participants can synchronize play-out. Typical applications for inter-destination media synchronization are social TV, watching apart together and shared service control (i.e. applications where two or more geographically separated users are watching a media stream together). =20 The IETF Secretariat. This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From peter.musgrave@magorcorp.com Mon Oct 11 07:15:33 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD693A6A94 for ; Mon, 11 Oct 2010 07:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.85 X-Spam-Level: X-Spam-Status: No, score=-101.85 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbgMUcxLpYOA for ; Mon, 11 Oct 2010 07:15:32 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 2F4E03A6A9D for ; Mon, 11 Oct 2010 07:15:32 -0700 (PDT) Received: by qwc9 with SMTP id 9so1667193qwc.31 for ; Mon, 11 Oct 2010 07:16:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.229.195 with SMTP id jj3mr5123345qcb.239.1286806603675; Mon, 11 Oct 2010 07:16:43 -0700 (PDT) Received: by 10.229.42.196 with HTTP; Mon, 11 Oct 2010 07:16:43 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Oct 2010 10:16:43 -0400 Message-ID: From: Peter Musgrave To: "Brandenburg, R. (Ray) van" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-brandenburg-avt-rtcp-for-idms-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 14:15:33 -0000 HI Ray, I think this is a useful XR. I lack background in the IDMS application. Is the Boronat2009 reference available online anywhere? (I am interested in whether there are separate XRs for audio and video and how the lipsync alignment issues are handled within the overall synchronization strategy). Should the relationship of this doc to ETSI TISPAN be mentioned in the Abst= ract? Nits: 3. First use of MSAS is not expanded. 3.3 Typo s/SSCR/SSRC/ Regards, Peter Musgrave On Mon, Oct 11, 2010 at 9:14 AM, Brandenburg, R. (Ray) van wrote: > Hi All, > > We have recently updated our internet-draft for inter-destination-media > synchronization using RTCP XR blocks. The updated version includes more > references and a shortened abstract. > > We are looking forward to your comments and are especially interested in > how you think our ID relates to recent work within this WG to specify > guidelines for new XR blocks. > > Regards, > > Ray van Brandenburg > > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: maandag 11 oktober 2010 14:44 > To: Brandenburg, R. (Ray) van > Subject: New Version Notification for > draft-brandenburg-avt-rtcp-for-idms-02 > > > A new version of I-D, draft-brandenburg-avt-rtcp-for-idms-02.txt has > been successfully submitted by Ray Brandenburg and posted to the IETF > repository. > > Filename: =A0 =A0 =A0 =A0draft-brandenburg-avt-rtcp-for-idms > Revision: =A0 =A0 =A0 =A002 > Title: =A0 =A0 =A0 =A0 =A0 RTCP XR Block Type for inter-destination media > synchronization > Creation_date: =A0 2010-10-11 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 11 > > Abstract: > This document specifies an RTCP XR Block Type and associated SDP > parameter for inter-destination media synchronization (IDMS). The RTCP > Block Type is used to collect media play-out information from > participants in a group watching a specific RTP media stream and to > distribute a summary of the collected information so that the > participants can synchronize play-out. > > Typical applications for inter-destination media synchronization are > social TV, watching apart together and shared service control (i.e. > applications where two or more geographically separated users are > watching a media stream together). > > > > > The IETF Secretariat. > > > This e-mail and its contents are subject to the DISCLAIMER at http://www.= tno.nl/disclaimer/email.html > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From ishan.vaishnavi@gmail.com Mon Oct 11 08:39:15 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07793A682A for ; Mon, 11 Oct 2010 08:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTgLgdEyBh5h for ; Mon, 11 Oct 2010 08:39:10 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 758A53A68FF for ; Mon, 11 Oct 2010 08:39:10 -0700 (PDT) Received: by qyk8 with SMTP id 8so1081733qyk.10 for ; Mon, 11 Oct 2010 08:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=D7TojkNzbqBJ2mfDdWI+U3Y5w7674HtgDC0nMI421jg=; b=a+5miC8KvuGzH9wpGXtYKlrfMQT7NxBF8hj5Ua6/Qq3qqywUwnF8ew9JD35finXt2O M3GVZ7Bsjx9d4oY48zt2O7s8L5U1857uaT69KTvyBTERRkompmM8TKyOHP8HESpmIAt9 dgczSWdYx5LsLCCIA2CLJ84PYKDnZOzE9Wp50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EU3YNBkCAJ3bU39LhOPPAFlXcwM5I4s1R4FWcAgoLEqJLMtnjB7j1UBZeN99dhSyW4 ntVD5lMIAVYfP5496d8Pe/9Qsv/qwyMXNTQiyQlmXqLsm3oTsdGw0xNRVjIa3OZRxbGb iozEIPeouWgiIghzytz05DRb/kk757q4S7JMY= MIME-Version: 1.0 Received: by 10.229.212.82 with SMTP id gr18mr5180466qcb.177.1286811622236; Mon, 11 Oct 2010 08:40:22 -0700 (PDT) Received: by 10.229.86.75 with HTTP; Mon, 11 Oct 2010 08:40:22 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Oct 2010 17:40:22 +0200 Message-ID: From: Ishan Vaishnavi To: Peter Musgrave Content-Type: multipart/alternative; boundary=0016e686cd3aa2e2990492592d8c Cc: avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-brandenburg-avt-rtcp-for-idms-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 15:39:15 -0000 --0016e686cd3aa2e2990492592d8c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Peter, Thanks for taking time to review this document. Find my comments inline. Cheers, Ishan > I lack background in the IDMS application. Is the Boronat2009 > reference available online anywhere? You need either an Elsevier account or a Science Direct one. Hereis the link. Hope that helps. > (I am interested in whether there > are separate XRs for audio and video and how the lipsync alignment > issues are handled within the overall synchronization strategy). > > In my opinion lip synchronization is somewhat out of the scope of this document. The idea is that each distributed client reports its play-out position of its "primary" stream. This primary stream can be a virtual stream or a real audio, video, subtitles or images for that matter. All other streams locally on each client synchronize to that stream, this must be done by the respective application. The current XR specification relates to how to get these primary streams are synchronized across different geographically separated clients. Maybe it can be extended to include this local synchronization as well, but that's another discussion. > Should the relationship of this doc to ETSI TISPAN be mentioned in the > Abstract? > I will leave this one for Ray. --0016e686cd3aa2e2990492592d8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Peter,=A0

Thanks for taking time to review this docum= ent. Find my comments inline.

Cheers,
Is= han


=A0
I lack background in the IDMS application. =A0Is the Boronat2009
reference available online anywhere?

You ne= ed either an Elsevier account or a Science Direct one. Here is the link. Hope that helps.

=A0
(I am interes= ted in whether there
are separate XRs for audio and video and how the lipsync alignment
issues are handled within the overall synchronization strategy).


In my opinion lip synchronization is s= omewhat out of the scope of this document. The idea is that each distribute= d client reports its play-out position of its "primary" stream. T= his primary stream can be a virtual stream or a real audio, video, subtitle= s or images for that matter. =A0All other streams locally on each client sy= nchronize to that stream, this must be done by the respective application. = The current XR specification relates to how to get these primary streams ar= e synchronized across different geographically separated clients. Maybe it = can be extended to include this local synchronization as well, but that'= ;s another discussion.=A0

=A0
Should the relationship of this doc to ETSI TISPAN be mentioned in the Abst= ract?

I will leave this one for Ray.=A0=



--0016e686cd3aa2e2990492592d8c-- From abegen@cisco.com Mon Oct 11 16:37:43 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA24B3A6BA2 for ; Mon, 11 Oct 2010 16:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.558 X-Spam-Level: X-Spam-Status: No, score=-10.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSA6QZPsgq38 for ; Mon, 11 Oct 2010 16:37:42 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8C0013A67E6 for ; Mon, 11 Oct 2010 16:37:42 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPI8s0yrR7H+/2dsb2JhbACiDHGmTpx/hUgEhFKIeA X-IronPort-AV: E=Sophos;i="4.57,317,1283731200"; d="scan'208";a="199059470" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 11 Oct 2010 23:38:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9BNctlM003687; Mon, 11 Oct 2010 23:38:55 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Oct 2010 16:38:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Oct 2010 16:38:08 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF6E6@xmb-sjc-215.amer.cisco.com> In-Reply-To: <011501cb691f$aa2efd60$30298a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 Thread-Index: ActpH7kgfTe2z49qSseuM+ZpW7Ys1wAfLjIA References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35C@xmb-sjc-215.amer.cisco.com> <011501cb691f$aa2efd60$30298a0a@china.huawei.com> From: "Ali C. Begen (abegen)" To: "Qin Wu" , X-OriginalArrivalTime: 11 Oct 2010 23:38:55.0525 (UTC) FILETIME=[780F6D50:01CB699D] Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 23:37:44 -0000 ... > Typos in abstract: > a) .. that *are* sending ... >=20 > [Qin]: You may misunderstand, the subject is actually "sending a = feedback message" Right. Shortening the sentence would definitely help here. =20 ... > 8) Section 6.1.1 says "If the loss reporter is part of group, the = Distribution source MUST filter this packet out and not forward > it back to this loss reporter." How does it filter that loss reporter = out? >=20 > [Qin]: It is one optimized behavior. > One possible way to do this is that the Distribution Source knows the = address of loss reporter or know in which port it can > receive the RTCP message from the loss reporter. > Is that reasonable? Are your reports unicast or multicast? In the latter, how do you deal = with it? =20 > 9) What about the cases where the receiver will actually not send a = NACK despite the packet loss? Consider where there is > also a FEC stream that can recover the lost packets. Should the loss = reporter listen to the FEC channel as well and act > accordingly? >=20 > [Qin]: Good question. I think if the reciever know it will not send a = NACK, then the distribution source should know as well. In Not necessarily. If the FEC is on another distribution channel (which is = usually the case), the DS does not know what the receivers are getting = in terms of FEC. > such case, the distribution source may choose not to send feedback = suppression message to the receiver. I think we need to think about this a bit further. If FEC recovers most = of the errors for majority of the receivers, maybe doing this (feedback = suppression) will not be needed as much. =20 > 10) You seem to assume that different loss reporters will always see = the same losses. That is not necessarily true. What > should be reported back to the receivers if the reports coming to the = FT are conflicting? Do you report the union or > intersection of the reports back to the receivers? >=20 > [Qin]: If there are duplication reports, the Distribution source = should filter the duplicated report out and only send one copy > of report to the reciever. What the distribution source does is to = create one summary report which only append different loss > in this summary report. This does not answer my question. If the reports are identical, yes you = can remove the duplicate. But if the reports are not identical. Now you = have a decision to make? And whatever you do may actually change the = performance. =20 -acbegen From csp@csperkins.org Mon Oct 11 18:14:30 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F4C3A67B8 for ; Mon, 11 Oct 2010 18:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2wRPIIMO82E for ; Mon, 11 Oct 2010 18:14:28 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by core3.amsl.com (Postfix) with ESMTP id 972E63A68A0 for ; Mon, 11 Oct 2010 18:14:26 -0700 (PDT) Received: from [12.159.134.153] (helo=[10.0.0.64]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P5TSl-0002Ic-pW; Tue, 12 Oct 2010 01:15:39 +0000 Message-Id: <5AF80FBB-63A8-4C1B-A5FA-57C00548BDC8@csperkins.org> From: Colin Perkins To: Roni Even In-Reply-To: <04ce01cb66c5$6f425640$4dc702c0$%roni@huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 11 Oct 2010 17:50:31 +0100 References: <00d801cb55b7$ffb41840$ff1c48c0$@net> <04CAD96D4C5A3D48B1919248A8FE0D540D2D23B0@xmb-sjc-215.amer.cisco.com> <01ec01cb5630$1ebf65f0$5c3e31d0$@net> <042601cb663b$c5317ed0$4f947c70$%roni@huawei.com> <04ce01cb66c5$6f425640$4dc702c0$%roni@huawei.com> X-Mailer: Apple Mail (2.936) Cc: "'DRAGE, Keith \(Keith\)'" , 'IETF AVT WG' , 'Dan Wing' Subject: Re: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 01:14:30 -0000 On 8 Oct 2010, at 09:47, Roni Even wrote: > There were some concerns about how we drafted the consensus call so > I would like to try and give it another try. Sorry for the long > message which I hope will clarify what are the proposed options. We > would like to get feedback by October 18th. > > > The Port Mapping Between Unicast and Multicast RTP Sessions > described in http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp-02 > was discussed for a couple of IETF meeting and on the list. The > initial approach that was agreed after we had a breakout session in > previous IETF meetings was to use a cookie based solution even > though it required more messages and you needed a cookie for every > RTP session. > > Before the last IETF meeting there were two proposals to update the > solution to a token based approach. > > In the token approach: > - Tokens are port-independent (cookies are port-dependent) and only > depend on the client's IP. That is, once a client gets its token, it > can use it with any of its ports and with any Feedback Target. > - Tokens address the concern raised by Magnus (http://www.ietf.org/mail-archive/web/avt/current/msg12617.html > ) > - No need for keep-alives > > We had a discussion in Maastricht and the outcome is in the meeting > minutes http://www.ietf.org/proceedings/78/minutes/avt.txt (see the > section on draft-begen-avt-token-for-portmapping). The token draft > has Dan Wing (who is also BEHAVE co-chair) as a co-author and he > looked at the solution verifying that it will work well with NATs > > > At the meeting the preference was for a token based solution but > there are were two approaches discussed. > > 1. Use the token only solution > > 2. Use a combination when if the request has only an IP address the > response will be a token and if it will have both IP address and > port the response will be a cookie. > > According to the minutes the support was for the second approach. > The major reason was a concern that carrier grade NATs can allocate > more than one IP address as the public address. > > The authors of > http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 > suggest that they addressed the concerns about the token only > solution (see section 9 of the draft) and prefer to have a token > only solution. This is a change from the meeting minutes and this is > the reason for the second question in this consensus call. > > So here are two questions for the group !!! > > 1. Do the people in the mailing list support the proposal to use a > token based solution instead on the cookie one. (this was the > preference in the consensus call in Maastricht) and we would like to > confirm it on the list. > > 2. We have two options for the token approach, please give your > preferences. > > 2.1 Token only solution as proposed in > http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 > 2.2 Token + cookie, in this case if the request will include only IP > address the response is a token, if it also includes a port it will > be a cookie. This approach is for cases were the NAT may use more > than one IP address for mapping a local address. > > > Please respond even if you did it on the previous consensus call. The approach in draft-begen-avt-token-for-portmapping-01 looks to be sufficient to allow a server to determine that multiple requests come from the same client, provided the client isn't multi-homed and isn't sharing an IP address with other clients. The problem statement is not clear enough for me to be sure if that's sufficient. If it were important to do so, the server could distinguish multiple clients sharing the same IP address if each client supplied a random nonce that was taken into account when generating the token in addition to the client's IP address. This may be an issue with use of fractional IP addresses in future, and so might be something to consider adding. Distinguishing multi-homed clients, or clients where requests come from several different IP addresses, is more complex. Is this an issue, or is it sufficient to assume that a client requests a new token when changing the address it uses? I'd also like to note that the port mapping operation is independent of the RAMS drafts. It would be good if the draft the group ends up with is written as a standalone mechanism, with RAMS described as one example use case, rather than being written in a RAMS-specific manner as are the current drafts. Cheers, Colin -- Colin Perkins http://csperkins.org/ From sunseawq@huawei.com Tue Oct 12 00:04:13 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62DBC3A6405 for ; Tue, 12 Oct 2010 00:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.081 X-Spam-Level: X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlTN4p3D4KTD for ; Tue, 12 Oct 2010 00:04:12 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0EF993A63D3 for ; Tue, 12 Oct 2010 00:04:12 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA600CRF10Q8P@szxga01-in.huawei.com> for avt@ietf.org; Tue, 12 Oct 2010 15:05:15 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA6009O110QYA@szxga01-in.huawei.com> for avt@ietf.org; Tue, 12 Oct 2010 15:05:14 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA600CGI10PRL@szxml04-in.huawei.com> for avt@ietf.org; Tue, 12 Oct 2010 15:05:14 +0800 (CST) Date: Tue, 12 Oct 2010 15:05:13 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , avt@ietf.org Message-id: <03c601cb69db$d166f150$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35C@xmb-sjc-215.amer.cisco.com> <011501cb691f$aa2efd60$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF6E6@xmb-sjc-215.amer.cisco.com> Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 07:04:13 -0000 Hi, ----- Original Message ----- From: "Ali C. Begen (abegen)" To: "Qin Wu" ; Sent: Tuesday, October 12, 2010 7:38 AM Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 ... > Typos in abstract: > a) .. that *are* sending ... > > [Qin]: You may misunderstand, the subject is actually "sending a feedback message" Right. Shortening the sentence would definitely help here. [Qin]: Okay. ... > 8) Section 6.1.1 says "If the loss reporter is part of group, the Distribution source MUST filter this packet out and not forward > it back to this loss reporter." How does it filter that loss reporter out? > > [Qin]: It is one optimized behavior. > One possible way to do this is that the Distribution Source knows the address of loss reporter or know in which port it can > receive the RTCP message from the loss reporter. > Is that reasonable? Are your reports unicast or multicast? In the latter, how do you deal with it? [Qin]: In the current draft, we assume Report sent from loss reporter to the distribution source is unicast, the report sent from or created at distribution source is multicast. Suppose the loss report is separated from the distribution source and send multicast report to the distribution source, the distribution souce can identify this multicast report based on the dedicated RTCP port used for loss report. Is it acceptable? > 9) What about the cases where the receiver will actually not send a NACK despite the packet loss? Consider where there is > also a FEC stream that can recover the lost packets. Should the loss reporter listen to the FEC channel as well and act > accordingly? > > [Qin]: Good question. I think if the reciever know it will not send a NACK, then the distribution source should know as well. In Not necessarily. If the FEC is on another distribution channel (which is usually the case), the DS does not know what the receivers are getting in terms of FEC. [Qin]: Right. > such case, the distribution source may choose not to send feedback suppression message to the receiver. I think we need to think about this a bit further. If FEC recovers most of the errors for majority of the receivers, maybe doing this (feedback suppression) will not be needed as much. [Qin]: It seems we need media source or receiver to tell distribution source not suppress the specified stream sent from the media source. Right? Or we assume FEC schemes will not used with suppression mechanism at the same time? Do you have any proposal? > 10) You seem to assume that different loss reporters will always see the same losses. That is not necessarily true. What > should be reported back to the receivers if the reports coming to the FT are conflicting? Do you report the union or > intersection of the reports back to the receivers? > > [Qin]: If there are duplication reports, the Distribution source should filter the duplicated report out and only send one copy > of report to the reciever. What the distribution source does is to create one summary report which only append different loss > in this summary report. This does not answer my question. If the reports are identical, yes you can remove the duplicate. But if the reports are not identical. Now you have a decision to make? [Qin]: Append the different report to the summary report. And whatever you do may actually change the performance. [Qin] In my opinion, If the report is created at the distribution source and sent from the distribution source to all the reciever, the performance will not be influenced. If the loss report is not part of distribution source, i.e., separated from distribution source, we may ask the loss reporter to send unicast report to the distribution source and then the distribution source create the summary report in multicast and send it to the recievers. that is to say, the unicast report will be terminated at the distribution source, so the performance will be affected very little. If you really concern about this, we could only consider the case that the loss report is part of distribution source and distribution source create the multicast report. -acbegen From sunseawq@huawei.com Tue Oct 12 00:19:27 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463493A68E0 for ; Tue, 12 Oct 2010 00:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.566 X-Spam-Level: * X-Spam-Status: No, score=1.566 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UNU9xW7I4RJ for ; Tue, 12 Oct 2010 00:19:25 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 60EC93A6405 for ; Tue, 12 Oct 2010 00:19:25 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA600FRH1O72J@szxga04-in.huawei.com> for avt@ietf.org; Tue, 12 Oct 2010 15:19:20 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA6006FO1O79U@szxga04-in.huawei.com> for avt@ietf.org; Tue, 12 Oct 2010 15:19:19 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA600ERX1O73M@szxml04-in.huawei.com> for avt@ietf.org; Tue, 12 Oct 2010 15:19:19 +0800 (CST) Date: Tue, 12 Oct 2010 15:19:18 +0800 From: Qin Wu To: Colin Perkins , "Ali C. Begen (abegen)" Message-id: <03d401cb69dd$c9188f70$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35C@xmb-sjc-215.amer.cisco.com> Cc: avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 07:19:27 -0000 SGksDQpUaGFuayBmb3IgeW91ciB2YWx1YWJsZSBjb21tZW50cywgSSB3aWxsIHRha2UgdGhlbSBp biB0aGUgbmV3IHZlcnNpb24uDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIA0KRnJvbTogIkNvbGluIFBlcmtpbnMiIDxjc3BAY3NwZXJraW5zLm9yZz4NClRv OiAiQWxpIEMuIEJlZ2VuIChhYmVnZW4pIiA8YWJlZ2VuQGNpc2NvLmNvbT4NCkNjOiAiUWluIFd1 IiA8c3Vuc2Vhd3FAaHVhd2VpLmNvbT47IDxhdnRAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIE9j dG9iZXIgMTEsIDIwMTAgNzowMyBQTQ0KU3ViamVjdDogUmU6IFtBVlRdIE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtYXZ0LXJldHJhbnNtaXNzaW9uLXN1cHJlc3Npb24tcnRw LTAzDQoNCg0KVGhpcyBkcmFmdCBpcyBnZW5lcmFsbHkgYWxvbmcgdGhlIHJpZ2h0IGxpbmVzLCBh bmQgliBhcyBkaXNjdXNzZWQgaW4gIA0KTWFhc3RyaWNodCCWIHdlIHNob3VsZCBjb25zaWRlciBh ZG9wdGluZyBpdCBhcyBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuICANClRoYXQgc2FpZCwgSSBoYXZl IGEgbnVtYmVyIG9mIGNvbW1lbnRzLCB3aGljaCBnZW5lcmFsbHkgZWNobyBBbGkncyAgDQpjb21t ZW50czoNCg0KLSBUaGUgYWJzdHJhY3QgbmVlZHMgdG8gYmUgcmV3cml0dGVuIGFzIGFuIGFic3Ry YWN0LCByYXRoZXIgdGhhbiBhbiAgDQppbnRyb2R1Y3Rpb24uDQoNCltRaW5dOiBPa2F5Lg0KDQot IFNob3VsZCBub3RlLCBpbiB0aGUgaW50cm9kdWN0aW9uLCB0aGF0IHRoZSBOQUNLIHN0b3JtIHJl c3BlY3RzIHRoZSAgDQpSVENQIGJhbmR3aWR0aCBjb25zdHJhaW50IG9uIGF2ZXJhZ2UsIGJ1dCB0 aGF0IG5h73ZlIGltcGxlbWVudGF0aW9ucyAgDQp0aGF0IGRvbpJ0IGNob29zZSB0byBkaXRoZXIg dGhlaXIgcmVzcG9uc2UgY2FuIGNhdXNlIHNob3J0IHRlcm0gIA0Kb3ZlcmxvYWQuIFRoZXJlIGlz IG5vIHJpc2sgb2YgY29uZ2VzdGlvbiBjb2xsYXBzZSwgaWYgdGhlIHJlY2VpdmVycyAgDQphcmUg Y29ycmVjdGx5IGltcGxlbWVudGVkLiBXaGlsZSB0aGVyZSBpcyBhIHJlYWwgcHJvYmxlbSB0byBi ZSBzb2x2ZWQsICANCkkgYmVsaWV2ZSB0aGUgZGlzY3Vzc2lvbiBpbiB0aGUgaW50cm9kdWN0aW9u IG92ZXJwbGF5cyB0aGUgcmlza3MuDQoNCltRaW5dOiBHb29kIHBvaW50Lg0KDQotIFRoZSBpbnRy b2R1Y3Rpb24gaW5jbHVkZXMgUkZDIDIxMTkgbGFuZ3VhZ2Ugc3BlY2lmeWluZyByZXF1aXJlbWVu dHMgIA0KliB0aGlzIHNob3VsZCBiZSBtb3ZlZCBpbnRvIFNlY3Rpb24gMy4gU3BlY2lmaWNhbGx5 LCBJIHN1Z2dlc3QgdGhlICANCmxhc3Qgc2l4IHBhcmFncmFwaHMgb2YgdGhlIEludHJvZHVjdGlv biBiZSBtb3ZlZCBpbnRvIFNlY3Rpb24gMy4NCg0KLSBTZWN0aW9uIDMgY29udGFpbnMgYSBsb3Qg b2YgZGlzY3Vzc2lvbiBvZiB0aGUgbG9zcyByZXBvcnRlciBhbmQgdGhlICANClNTTSB1c2UgY2Fz ZS4gTXVjaCBvZiB0aGlzIHNlZW1zIHVubmVjZXNzYXJ5IGluIHRoaXMgcGFydCBvZiB0aGUgIA0K ZHJhZnQ6IGRpc2N1c3Npb24gb2YgU1NNIGFuZCB0aGUgbG9zcyByZXBvcnRlciBjb25jZXB0IHNo b3VsZCBiZSBpbiAgDQpzZWN0aW9uIDYuMSwgbGVhdmluZyBzZWN0aW9uIDMgdG8gc3BlY2lmeSB0 aGUgZ2VuZXJhbCBwcm90b2NvbCAgDQpiZWhhdmlvdXIsIGluZGVwZW5kZW50IG9mIHBhcnRpY3Vs YXIgdXNlIGNhc2VzLg0KDQotIFNlY3Rpb24gNCBoYXMgdW5uZWNlc3Nhcnkgc3ViaGVhZGluZ3Mu IFN1Z2dlc3QgcmVtb3ZpbmcgdGhlIDQuMSAgDQpoZWFkZXIgdGhlbiByZW5hbWluZyBzZWN0aW9u IDQuMS4xIHRvIJM0LjEgVHJhbnNwb3J0IExheWVyIEZlZWRiYWNrOiAgDQpOQUNLIFN1cHByZXNz aW9uIFJlcG9ydJQsIGFuZCBhbHNvIHJlbW92aW5nIHRoZSA0LjIgaGVhZGVyIHRoZW4gIA0KcmVu YW1pbmcgc2VjdGlvbiA0LjIuMSB0byCTNC4yIFBheWxvYWQgU3BlY2lmaWMgRmVlZGJhY2s6IEZJ UiAgDQpzdXBwcmVzc2lvbiByZXBvcnSULg0KDQpbUWluXTogT2theS4NCg0KLSBTZWN0aW9uIDcg c2hvdWxkIG5vdGUgdGhhdCBtaWRkbGVib3hlcyB0aGF0IGFyZSBub3QgdmlzaWJsZSBhdCB0aGUg IA0KUlRQIGxheWVyIHRoYXQgd2lzaCB0byBzZW5kIE5BQ0svRklSIHN1cHByZXNzaW9uIHJlcG9y dHMgb24gYmVoYWxmIG9mICANCnRoZSBzZW5kZXIgY2FuIG9ubHkgZG8gc28gaWYgdGhleSBzcG9v ZiB0aGUgU1NSQyBvZiB0aGUgc2VuZGVyLiBUaGlzICANCmlzIGRpZmZpY3VsdCBpcyBTUlRQIGlz IGluIHVzZS4gSWYgdGhlIG1pZGRsZWJveCBpcyB2aXNpYmxlIGF0IHRoZSBSVFAgIA0KbGF5ZXIs IHRoaXMgaXMgbm90IGFuIGlzc3VlLCBwcm92aWRlZCB0aGUgbWlkZGxlYm94IGlzIHBhcnQgb2Yg dGhlICANCnNlY3VyaXR5IGNvbnRleHQgZm9yIHRoZSBzZXNzaW9uLg0KDQotIFNlY3Rpb24gNyBz aG91bGQgbm90ZSB0aGF0IGVuZHBvaW50cyB0aGF0IHJlY2VpdmUgYSBOQUNLL0ZJUiAgDQpzdXBw cmVzc2lvbiByZXF1ZXN0IHdvdWxkIGJlIHdlbGwtYWR2aXNlZCB0byBpZ25vcmUgaXQsIHVubGVz cyBpdCBpcyAgDQphdXRoZW50aWNhdGVkIHZpYSBTUlRDUCBvciBzaW1pbGFyLiBBY2NlcHRpbmcg dW4tYXV0aGVudGljYXRlZCBOQUNLLyANCkZJUiBzdXBwcmVzc2lvbiByZXF1ZXN0cyBjYW4gbGVh ZCB0byBhIGRlbmlhbCBvZiBzZXJ2aWNlIGF0dGFjaywgd2hlcmUgIA0KdGhlIGVuZHBvaW50IGFj Y2VwdHMgcG9vciBxdWFsaXR5IG1lZGlhIHRoYXQgY291bGQgYmUgcmVwYWlyZWQuDQoNCltRaW5d OiBHb29kIGlucHV0LCB0aGFua3MuDQoNCk5vbmUgb2YgdGhlc2UgYXJlIGZ1bmRhbWVudGFsLCBh bmQgSSBkb24ndCB0aGluayB0aGVyZSdzIGFueXRoaW5nIHRoYXQgIA0Kc2hvdWxkIGRlbGF5IGFk b3B0aW9uIGFzIGEgd29ya2luZyBncm91cCBkcmFmdC4NCg0KQ29saW4NCg0KDQoNCk9uIDkgT2N0 IDIwMTAsIGF0IDE3OjM4LCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQo+IENvbW1lbnRz Og0KPiAxKSBBYnN0cmFjdCBpcyB0b28gbG9uZywgY291bGQgeW91IHNob3J0ZW4gaXQ/DQo+DQo+ IFR5cG9zIGluIGFic3RyYWN0Og0KPiBhKSAuLiB0aGF0ICphcmUqIHNlbmRpbmcgLi4uDQo+IGIp IFJUUCBtZXNzYWdlcyAtPiBSVFAgcGFja2V0cw0KPiBjKSAidGhlIHNlbmRlciBvZiB0aGUgcmVw b3J0IHdpbGwgZWl0aGVyIHByb2FjdGl2ZWx5IHJlY292ZXIiOiBXZWxsLCAgDQo+IGl0IGRvZXMg bm90IGhhdmUgdG8gYmUgdGhlIHNlbmRlciBvZiB0aGUgcmVwb3J0IHdobyB3aWxsIGF0dGVtcHQg dGhlICANCj4gcmVjb3ZlcnkuIEkgd291bGQgcmVwaHJhc2UgdGhpcy4NCj4NCj4gMikgVGhyb3Vn aG91dCB0aGUgZG9jdW1lbnQsIGF2b2lkaW5nICJzZW5kZXIiIG1pZ2h0IGJlIGEgZ29vZCBpZGVh LiAgDQo+IEZvciB0aGUgc291cmNlLCB1c2UgbWVkaWEgb3IgZGlzdHJpYnV0aW9uIHNvdXJjZS4g U2VuZGVyIG1heSBtZWFuICANCj4gZGlmZmVyZW50IHRoaW5ncyBpbiBkaWZmZXJlbnQgY29udGV4 dHMuDQo+DQo+IDMpIEludHJvIDFzdCBwYXJhZ3JhcGg6IFRoZSByZXRyYW5zbWlzc2lvbiBwYXls b2FkIGZvcm1hdCBpcyA0NTg4ICANCj4gbm90IDQ1ODUuDQo+DQo+IDQpIE1vc3Qgb2YgdGhlIGRp c2N1c3Npb24gaW4gdGhlIGludHJvZHVjdGlvbiBzZWN0aW9uIGNhbiBiZSAgDQo+IHNob3J0ZW5l ZCBpbiBhIGNvbmNyZXRlIHdheSBieSByZWZlcnJpbmcgdG8gb3RoZXIgZXhpc3RpbmcgUkZDIGlu ICANCj4gdGhpcyBhcmVhLiBJIGFtIGFjdHVhbGx5IHF1aXRlIHN1cnByaXNlZCB0aGF0IFJGQyA1 NzQwIGlzIG5vdCAgDQo+IG1lbnRpb25lZCBhdCBhbGwgaGVyZS4gSSB3b3VsZCByYXRoZXIgcmVm ZXIgdG8gUkZDIDU3NDAgKHJhdGhlciB0aGFuICANCj4gRFZCLUlQVFYpLg0KPg0KPiA1KSBEbyBu b3QgdXNlICh1cHBlci1jYXNlKSAyMTE5IGtleXdvcmRzIGluIHRoZSBpbnRyb2R1Y3Rpb24uIElF U0cgIA0KPiBkb2VzIG5vdCBsaWtlIGl0IDopDQo+DQo+IDYpIFNlY3Rpb24gMjogVGhlIGRlZmlu aXRpb25zIHNlZW0gdG8gZXZvbHZlIGFyb3VuZCBTU00uIFdoeSB3b3VsZCAgDQo+IG5vdCB0aGV5 IGFwcGx5IHRvIEFTTT8NCj4NCj4gNykgU2VjdGlvbiAzIGFuZCBmdXJ0aGVyIG9uOiBUaGVyZSBh cmUgc2V2ZXJhbCBsb3dlci1jYXNlIDIxMTkgIA0KPiBrZXl3b3JkcyBpbiB0aGUgdGV4dCB3aGlj aCB5b3UgbWlnaHQgd2FubmEgcmVwbGFjZS4NCj4NCj4gOCkgU2VjdGlvbiA2LjEuMSBzYXlzICJJ ZiB0aGUgbG9zcyByZXBvcnRlciBpcyBwYXJ0IG9mIGdyb3VwLCB0aGUgIA0KPiBEaXN0cmlidXRp b24gc291cmNlIE1VU1QgZmlsdGVyIHRoaXMgcGFja2V0IG91dCBhbmQgbm90IGZvcndhcmQgaXQg IA0KPiBiYWNrIHRvIHRoaXMgbG9zcyByZXBvcnRlci4iIEhvdyBkb2VzIGl0IGZpbHRlciB0aGF0 IGxvc3MgcmVwb3J0ZXIgIA0KPiBvdXQ/DQo+DQo+IDkpIFdoYXQgYWJvdXQgdGhlIGNhc2VzIHdo ZXJlIHRoZSByZWNlaXZlciB3aWxsIGFjdHVhbGx5IG5vdCBzZW5kIGEgIA0KPiBOQUNLIGRlc3Bp dGUgdGhlIHBhY2tldCBsb3NzPyBDb25zaWRlciB3aGVyZSB0aGVyZSBpcyBhbHNvIGEgRkVDICAN Cj4gc3RyZWFtIHRoYXQgY2FuIHJlY292ZXIgdGhlIGxvc3QgcGFja2V0cy4gU2hvdWxkIHRoZSBs b3NzIHJlcG9ydGVyICANCj4gbGlzdGVuIHRvIHRoZSBGRUMgY2hhbm5lbCBhcyB3ZWxsIGFuZCBh Y3QgYWNjb3JkaW5nbHk/DQo+DQo+IDEwKSBZb3Ugc2VlbSB0byBhc3N1bWUgdGhhdCBkaWZmZXJl bnQgbG9zcyByZXBvcnRlcnMgd2lsbCBhbHdheXMgc2VlICANCj4gdGhlIHNhbWUgbG9zc2VzLiBU aGF0IGlzIG5vdCBuZWNlc3NhcmlseSB0cnVlLiBXaGF0IHNob3VsZCBiZSAgDQo+IHJlcG9ydGVk IGJhY2sgdG8gdGhlIHJlY2VpdmVycyBpZiB0aGUgcmVwb3J0cyBjb21pbmcgdG8gdGhlIEZUIGFy ZSAgDQo+IGNvbmZsaWN0aW5nPyBEbyB5b3UgcmVwb3J0IHRoZSB1bmlvbiBvciBpbnRlcnNlY3Rp b24gb2YgdGhlIHJlcG9ydHMgIA0KPiBiYWNrIHRvIHRoZSByZWNlaXZlcnM/DQo+DQo+IDExKSBZ b3UgYWxzbyBzZWVtIHRvIGJlIHJlbGF0aW5nIHRoaXMgTkFDSyBpbXBsb3Npb24gdG8gIA0KPiBy ZXRyYW5zbWlzc2lvbi4gSSB3b3VsZCBhY3R1YWxseSBwcmVmZXIgdG8ga2VlcCB0aGUgcmV0cmFu c21pc3Npb24gIA0KPiBzdHVmZiBvdXQgb2YgdGhlIHRleHQgaGVyZSAoanVzdCBtZW50aW9uIGl0 IGluIHRoZSBpbnRyb2R1Y3Rpb24gYW5kICANCj4gdGhlbiBmb3JnZXQgYWJvdXQgaXQpLiBXaGV0 aGVyIHRoZSBkaXN0cmlidXRpb24gc291cmNlIGFjdHVhbGx5ICANCj4gcmV0cmFuc21pdHMgdGhl IG1pc3NpbmcgcGFja2V0cyBvciBub3QgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgIA0KPiBt ZXNzYWdlcyBkZWZpbmVkIGluIHRoaXMgZHJhZnQuDQo+DQo+IC1hY2JlZ2VuDQo+DQo+DQo+DQo+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogYXZ0LWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmICANCj4+IE9mIFFpbiBX dQ0KPj4gU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMDksIDIwMTAgMTI6NDkgUE0NCj4+IFRvOiBh dnRAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFtBVlRdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtd3UtYXZ0LSANCj4+IHJldHJhbnNtaXNzaW9uLXN1cHJlc3Npb24tcnRwLTAzDQo+ Pg0KPj4gRm9sa3MsDQo+Pg0KPj4gV2UgaGF2ZSB1cGRhdGVkIGRyYWZ0LXd1LWF2dC1yZXRyYW5z bWlzc2lvbi1zdXBwcmVzc2lvbi1ydHAgd2hpY2ggIA0KPj4gc2hvdWxkIG5vdyByZWZsZWN0IHRo ZSBkaXNjdXNzaW9uIHdlIGhhZCBzaW5jZSBJRVRGNzguDQo+Pg0KPj4gVGhlIGZlZWRiYWNrIHN1 cHByZXNzaW9uIHNvbHV0aW9uIGhhcyBhbHNvIGJlZW4gZ3JlYXRseSBnZW5lcmFsaXplZCAgDQo+ PiBjb21wYXJpbmcgdG8gdGhlIHByZXZpb3VzIHZlcnNpb24uDQo+Pg0KPj4gQ29tbWVudHMgYXJl IHNvbGljaXRlZC4NCj4+DQo+PiBSZWdhcmRzIQ0KPj4gLVFpbg0KPj4gLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLQ0KPj4gRnJvbTogPEludGVybmV0LURyYWZ0c0BpZXRmLm9yZz4NCj4+IFRv OiA8aS1kLWFubm91bmNlQGlldGYub3JnPg0KPj4gU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMDks IDIwMTAgMTI6NDUgUE0NCj4+IFN1YmplY3Q6IEktRCBBY3Rpb246ZHJhZnQtd3UtYXZ0LXJldHJh bnNtaXNzaW9uLXN1cHJlc3Npb24tcnRwLTAzLnR4dA0KPj4NCj4+DQo+Pj4gQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzICAN Cj4+PiBkaXJlY3Rvcmllcy4NCj4+Pg0KPj4+IFRpdGxlICAgICAgICAgICA6IFJUQ1AgUmVwb3J0 IEV4dGVuc2lvbiBmb3IgRmVlZGJhY2sgU3VwcHJlc3Npb24NCj4+PiBBdXRob3IocykgICAgICAg OiBXLiBXdSwgZXQgYWwuDQo+Pj4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQtd3UtYXZ0LXJldHJh bnNtaXNzaW9uLXN1cHJlc3Npb24tcnRwLTAzLnR4dA0KPj4+IFBhZ2VzICAgICAgICAgICA6IDI0 DQo+Pj4gRGF0ZSAgICAgICAgICAgIDogMjAxMC0xMC0wOA0KPj4+DQo+Pj4gVGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBSVENQIGZlZWRiYWNrIG1lc3NhZ2VzDQo+ Pj4gZGVmaW5lZCBpbiB0aGUgQXVkaW8tVmlzdWFsIFByb2ZpbGUgd2l0aCBGZWVkYmFjayAoQVZQ RikuICBUaGlzDQo+Pj4gZXh0ZW5zaW9uIGFsbG93cyBhbiBpbnRlcm1lZGlhdGUgbm9kZSBpbiB0 aGUgbmV0d29yayAoc3VjaCBhcyBhbiBSVFANCj4+PiB0cmFuc2xhdG9yKSBpbmZvcm0gZG93bnN0 cmVhbSByZWNlaXZlcnMgdGhhdCBzZW5kaW5nIGEgZmVlZGJhY2sNCj4+PiBtZXNzYWdlIGNvbmNl cm5pbmcgYSBzcGVjaWZpZWQgc2V0IG9mIFJUUCBtZXNzYWdlcyBtYXkgYmUNCj4+PiB1bm5lY2Vz c2FyeSwgb3IgZXZlbiBoYXJtZnVsLiAgRm9yIGV4YW1wbGUsIGluIGEgc291cmNlLXNwZWNpZmlj DQo+Pj4gbXVsdGljYXN0IHNlc3Npb24gd2l0aCBsYXJnZSBmYW4tb3V0LCBwYWNrZXQgbG9zcyBj bG9zZSB0byB0aGUgbWVkaWENCj4+PiBvciBkaXN0cmlidXRpb24gc291cmNlIG9mIHRoZSBzZXNz aW9uIGlzIGRldGVjdGVkIGFzIGEgbG9zcyBieSBhDQo+Pj4gbGFyZ2UgbnVtYmVyIG9mIHJlY2Vp dmVycy4gIFRoZSBSVENQIE5BQ0sgbWVzc2FnZXMgdXNlZCB0byByZXF1ZXN0DQo+Pj4gcmV0cmFu c21pc3Npb24gb2YgdGhlIG1pc3NpbmcgcGFja2V0cyBhcmUgYWxsIGFkZHJlc3NlZCB0byB0aGUg bWVkaWENCj4+PiBzZW5kZXIsIG9yIGEgZGVzaWduYXRlZCBmZWVkYmFjayB0YXJnZXQuICBUaGlz IG1heSByZXN1bHQgaW4gYQ0KPj4+IHBoZW5vbWVub24ga25vd24gdmFyaW91c2x5IGFzIGEgIk5B Q0sgaW1wbG9zaW9uIiBvciAiZmVlZGJhY2sgIA0KPj4+IHN0b3JtIi4NCj4+PiBUaGUgRmVlZGJh Y2sgU3VwcHJlc3Npb24gbWVzc2FnZSBkZWZpbmVkIGhlcmVpbiBpcyB1c2VkIHRvIG5vdGlmeQ0K Pj4+IHJlY2VpdmVycyB0aGF0IHBhY2tldCBsb3NzIHdhcyBkZXRlY3RlZCBhbmQgdGhhdCB0aGUg c2VuZGVyIG9mIHRoZQ0KPj4+IHJlcG9ydCB3aWxsIGVpdGhlciBwcm9hY3RpdmVseSByZWNvdmVy LCBvciBubyByZWNvdmVyeSBpcyBwb3NzaWJsZS4NCj4+PiBSZWNlaXZlcnMgcmVzcG9uZCB0byBy ZWNlaXB0IG9mIGEgZmVlZGJhY2sgc3VwcHJlc3Npb24gbWVzc2FnZSBieSAgDQo+Pj4gbm90DQo+ Pj4gc2VuZGluZyBhIGZlZWRiYWNrIG1lc3NhZ2UgKGUuZy4gYSBOQUNLKSB0aGF0IHRoZXkgb3Ro ZXJ3aXNlIHdvdWxkLA0KPj4+IFRoaXMgaW4gdHVybiByZWR1Y2VzIGxvYWQgb24gYm90aCB0aGUg ZmVlZGJhY2sgdGFyZ2V0IGFuZCBvbiB0aGUNCj4+PiBuZXR3b3JrLiAgVGhpcyBkb2N1bWVudCBy ZWdpc3RlcnMgdHdvIG5ldyBSVENQIG1lc3NhZ2VzIGZvciBGZWVkYmFjaw0KPj4+IFN1cHByZXNz aW9uLg0KPj4+DQo+Pj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+Pj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3UtYXZ0LXJldHJhbnNtaXNz aW9uLXN1cHJlc3Npb24tcnRwLTAzLnR4dA0KPj4+DQo+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+IGZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4NCj4+PiBCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxs IGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyDQo+Pj4gaW1wbGVtZW50YXRpb24g dG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUNCj4+PiBJ bnRlcm5ldC1EcmFmdC4NCj4+Pg0KPj4NCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4NCj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+Pj4gSS1ELUFubm91bmNlQGlldGYu b3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3Vu Y2UNCj4+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9z aGFkb3cuaHRtbA0KPj4+IG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMu dHh0DQo+Pj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IFdvcmtpbmcgR3JvdXANCj4gYXZ0QGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQoNCg0KDQotLSAN CkNvbGluIFBlcmtpbnMNCmh0dHA6Ly9jc3BlcmtpbnMub3JnLw0KDQoNCg== From Even.roni@huawei.com Tue Oct 12 00:36:10 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B5E3A6405 for ; Tue, 12 Oct 2010 00:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.439 X-Spam-Level: X-Spam-Status: No, score=-100.439 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUkbSLt1Elyn for ; Tue, 12 Oct 2010 00:36:07 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id EB4EF3A67B3 for ; Tue, 12 Oct 2010 00:36:06 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA600HSE2GPKG@szxga05-in.huawei.com> for avt@ietf.org; Tue, 12 Oct 2010 15:36:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA6005N92GO7O@szxga05-in.huawei.com> for avt@ietf.org; Tue, 12 Oct 2010 15:36:25 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-21-162.red.bezeqint.net [79.183.21.162]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA600FBY2GGCP@szxml02-in.huawei.com>; Tue, 12 Oct 2010 15:36:25 +0800 (CST) Date: Tue, 12 Oct 2010 09:33:40 +0200 From: Roni Even In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF6E6@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , 'Qin Wu' , avt@ietf.org Message-id: <00d701cb69df$d02c9fc0$7085df40$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: ActpH7kgfTe2z49qSseuM+ZpW7Ys1wAfLjIAABB5SpA= References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35C@xmb-sjc-215.amer.cisco.com> <011501cb691f$aa2efd60$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF6E6@xmb-sjc-215.amer.cisco.com> Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 07:36:10 -0000 Hi, > > ... > > 8) Section 6.1.1 says "If the loss reporter is part of group, the > Distribution source MUST filter this packet out and not forward > > it back to this loss reporter." How does it filter that loss reporter > out? > > > > [Qin]: It is one optimized behavior. > > One possible way to do this is that the Distribution Source knows the > address of loss reporter or know in which port it can > > receive the RTCP message from the loss reporter. > > Is that reasonable? > > Are your reports unicast or multicast? In the latter, how do you deal > with it? I think this has to do with your question about merging reports. > > > 9) What about the cases where the receiver will actually not send a > NACK despite the packet loss? Consider where there is > > also a FEC stream that can recover the lost packets. Should the loss > reporter listen to the FEC channel as well and act > > accordingly? > > > > [Qin]: Good question. I think if the reciever know it will not send a > NACK, then the distribution source should know as well. In > > Not necessarily. If the FEC is on another distribution channel (which > is usually the case), the DS does not know what the receivers are > getting in terms of FEC. >From the DS perspective there are packet losses and letting the receiver know even if it uses FEC may help the receiver giving him an earlier warning allowing him to use FEC without waiting. > > > such case, the distribution source may choose not to send feedback > suppression message to the receiver. > > I think we need to think about this a bit further. If FEC recovers most > of the errors for majority of the receivers, maybe doing this (feedback > suppression) will not be needed as much. > > > 10) You seem to assume that different loss reporters will always see > the same losses. That is not necessarily true. What > > should be reported back to the receivers if the reports coming to the > FT are conflicting? Do you report the union or > > intersection of the reports back to the receivers? > > > > [Qin]: If there are duplication reports, the Distribution source > should filter the duplicated report out and only send one copy > > of report to the reciever. What the distribution source does is to > create one summary report which only append different loss > > in this summary report. > > This does not answer my question. If the reports are identical, yes you > can remove the duplicate. But if the reports are not identical. Now you > have a decision to make? And whatever you do may actually change the > performance. This is a good feedback. I think that this is application dependent, the typical behavior can be union but if the DS knows the network topology it may take another policy. Anyhow even if the receiver gets the union and on his path the packet were not lost, it does not break since it will receive the packets. The suppression just tell the receiver to not sent NACKs. The draft does not address the behavior of the DS in the upstream direction and leave it open to the implementation. Roni Even > > -acbegen > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From ray.vanbrandenburg@tno.nl Tue Oct 12 00:46:51 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270CF3A6C7B for ; Tue, 12 Oct 2010 00:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.441 X-Spam-Level: * X-Spam-Status: No, score=1.441 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAZL8kG6RHrr for ; Tue, 12 Oct 2010 00:46:48 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id F40993A68ED for ; Tue, 12 Oct 2010 00:46:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,319,1283724000"; d="scan'208,217";a="10259442" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 12 Oct 2010 09:47:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB69E1.C978F2EA" Date: Tue, 12 Oct 2010 09:47:57 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New Version Notification for draft-brandenburg-avt-rtcp-for-idms-02 Thread-Index: ActpWp5OT4gPk6mPS/+09xKmx3FCSgAhHhog References: From: "Brandenburg, R. (Ray) van" To: "Peter Musgrave" Cc: avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-brandenburg-avt-rtcp-for-idms-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 07:46:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB69E1.C978F2EA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, =20 Thanks for your comments.=20 =20 Should the relationship of this doc to ETSI TISPAN be mentioned in the Abstract? =20 I agree and will add this in the next version. While we're on the subject: the main reason we have brought this work to the IETF is because we feel the AVT WG should be the place where XR blocks are specified. If there is enough interest around here, one option could be to have the AVT WG take the lead on the standardization of this XR block, either as an informational or standards track document. The relevant sections of the ETSI TISPAN spec could then reference the resulting RFC. How do you feel about this? =20 Regards, =20 Ray van Brandenburg =20 =20 =20 ________________________________ From: Ishan Vaishnavi [mailto:ishan.vaishnavi@gmail.com]=20 Sent: maandag 11 oktober 2010 17:40 To: Peter Musgrave Cc: Brandenburg, R. (Ray) van; avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-brandenburg-avt-rtcp-for-idms-02 Hi Peter, =20 Thanks for taking time to review this document. Find my comments inline. Cheers, Ishan =20 I lack background in the IDMS application. Is the Boronat2009 reference available online anywhere? You need either an Elsevier account or a Science Direct one. Here is the link. Hope that helps. =20 (I am interested in whether there are separate XRs for audio and video and how the lipsync alignment issues are handled within the overall synchronization strategy). =09 =09 In my opinion lip synchronization is somewhat out of the scope of this document. The idea is that each distributed client reports its play-out position of its "primary" stream. This primary stream can be a virtual stream or a real audio, video, subtitles or images for that matter. All other streams locally on each client synchronize to that stream, this must be done by the respective application. The current XR specification relates to how to get these primary streams are synchronized across different geographically separated clients. Maybe it can be extended to include this local synchronization as well, but that's another discussion.=20 =20 Should the relationship of this doc to ETSI TISPAN be mentioned in the Abstract? =09 I will leave this one for Ray.=20 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html ------_=_NextPart_001_01CB69E1.C978F2EA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Peter,
 
Thanks for your comments.
 
Should=20 the relationship of this doc to ETSI TISPAN be mentioned in the=20 Abstract?
 
I agree and will add this in the next version. W= hile=20 we're on the subject: the main reason we have brought this work to the IETF= is=20 because we feel the AVT WG should be the place where XR blocks are specifie= d. If=20 there is enough interest around here, one option could be to have the AVT W= G=20 take the lead on the standardization of this XR block, either as an=20 informational or standards track document. The relevant sections of the ETS= I=20 TISPAN spec could then reference the resulting RFC. How do you fe= el=20 about this?
 
Regards,
 
Ray van Brandenburg
 
 
 

From: Ishan Vaishnavi=20 [mailto:ishan.vaishnavi@gmail.com]
Sent: maandag 11 oktober 2010=20 17:40
To: Peter Musgrave
Cc: Brandenburg, R. (Ray) van;=20 avt@ietf.org
Subject: Re: [AVT] New Version Notification for=20 draft-brandenburg-avt-rtcp-for-idms-02

Hi Peter, 

Thanks for taking time to review this document. Find my comments=20 inline.

Cheers,
Ishan


 
I=20 lack background in the IDMS application.  Is the Boronat2009
refe= rence=20 available online anywhere?

You need either an Elsevier account or a Science Direct one. Here=20 is the link. Hope that helps.

 
(I=20 am interested in whether there
are separate XRs for audio and video an= d how=20 the lipsync alignment
issues are handled within the overall synchroniz= ation=20 strategy).


In my opinion lip synchronization is somewhat out of the scope of this=20 document. The idea is that each distributed client reports its play-out pos= ition=20 of its "primary" stream. This primary stream can be a virtual stream or a r= eal=20 audio, video, subtitles or images for that matter.  All other streams=20 locally on each client synchronize to that stream, this must be done by the=20 respective application. The current XR specification relates to how to get = these=20 primary streams are synchronized across different geographically separated=20 clients. Maybe it can be extended to include this local synchronization as = well,=20 but that's another discussion. 

 
Should=20 the relationship of this doc to ETSI TISPAN be mentioned in the=20 Abstract?

I will leave this one for Ray. 



This e-mail and its contents are subject to=
 the DISCLAIMER at http://www.tno.nl/disclaimer/email.html
------_=_NextPart_001_01CB69E1.C978F2EA-- From tom.van_caenegem@alcatel-lucent.com Tue Oct 12 03:22:10 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3321D3A63D2 for ; Tue, 12 Oct 2010 03:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.618 X-Spam-Level: X-Spam-Status: No, score=-4.618 tagged_above=-999 required=5 tests=[AWL=1.631, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LNn749rO4g6 for ; Tue, 12 Oct 2010 03:22:05 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 8F4B23A679C for ; Tue, 12 Oct 2010 03:22:03 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9CAN6M7021805 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Oct 2010 12:23:08 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 12 Oct 2010 12:23:07 +0200 From: "Van Caenegem, Tom (Tom)" To: Colin Perkins , Roni Even Date: Tue, 12 Oct 2010 12:23:05 +0200 Thread-Topic: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp Thread-Index: ActpqwOY5bvsgqvHRi6wcjLNi7xL6wASH9Jg Message-ID: References: <00d801cb55b7$ffb41840$ff1c48c0$@net> <04CAD96D4C5A3D48B1919248A8FE0D540D2D23B0@xmb-sjc-215.amer.cisco.com> <01ec01cb5630$1ebf65f0$5c3e31d0$@net> <042601cb663b$c5317ed0$4f947c70$%roni@huawei.com> <04ce01cb66c5$6f425640$4dc702c0$%roni@huawei.com> <5AF80FBB-63A8-4C1B-A5FA-57C00548BDC8@csperkins.org> In-Reply-To: <5AF80FBB-63A8-4C1B-A5FA-57C00548BDC8@csperkins.org> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "DRAGE, Keith \(Keith\)" , 'IETF AVT WG' , 'Dan Wing' Subject: Re: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 10:22:10 -0000 Hi Colin, See below, Tom=20 -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Colin= Perkins Sent: maandag 11 oktober 2010 18:51 To: Roni Even Cc: DRAGE, Keith (Keith); 'IETF AVT WG'; 'Dan Wing' Subject: Re: [AVT] Revised Consensus call - On Token approach for draft-iet= f-avt-ports-for-ucast-mcast-rtp On 8 Oct 2010, at 09:47, Roni Even wrote: > There were some concerns about how we drafted the consensus call so I=20 > would like to try and give it another try. Sorry for the long message=20 > which I hope will clarify what are the proposed options. We would like=20 > to get feedback by October 18th. > > > The Port Mapping Between Unicast and Multicast RTP Sessions described=20 > in=20 > http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp-02 > was discussed for a couple of IETF meeting and on the list. The=20 > initial approach that was agreed after we had a breakout session in=20 > previous IETF meetings was to use a cookie based solution even though=20 > it required more messages and you needed a cookie for every RTP=20 > session. > > Before the last IETF meeting there were two proposals to update the=20 > solution to a token based approach. > > In the token approach: > - Tokens are port-independent (cookies are port-dependent) and only=20 > depend on the client's IP. That is, once a client gets its token, it=20 > can use it with any of its ports and with any Feedback Target. > - Tokens address the concern raised by Magnus=20 > (http://www.ietf.org/mail-archive/web/avt/current/msg12617.html > ) > - No need for keep-alives > > We had a discussion in Maastricht and the outcome is in the meeting=20 > minutes http://www.ietf.org/proceedings/78/minutes/avt.txt (see the=20 > section on draft-begen-avt-token-for-portmapping). The token draft has=20 > Dan Wing (who is also BEHAVE co-chair) as a co-author and he looked at=20 > the solution verifying that it will work well with NATs > > > At the meeting the preference was for a token based solution but there=20 > are were two approaches discussed. > > 1. Use the token only solution > > 2. Use a combination when if the request has only an IP address the=20 > response will be a token and if it will have both IP address and port=20 > the response will be a cookie. > > According to the minutes the support was for the second approach. =20 > The major reason was a concern that carrier grade NATs can allocate=20 > more than one IP address as the public address. > > The authors of > http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 > suggest that they addressed the concerns about the token only solution=20 > (see section 9 of the draft) and prefer to have a token only solution.=20 > This is a change from the meeting minutes and this is the reason for=20 > the second question in this consensus call. > > So here are two questions for the group !!! > > 1. Do the people in the mailing list support the proposal to use a=20 > token based solution instead on the cookie one. (this was the=20 > preference in the consensus call in Maastricht) and we would like to=20 > confirm it on the list. > > 2. We have two options for the token approach, please give your=20 > preferences. > > 2.1 Token only solution as proposed in > http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 > 2.2 Token + cookie, in this case if the request will include only IP=20 > address the response is a token, if it also includes a port it will be=20 > a cookie. This approach is for cases were the NAT may use more than=20 > one IP address for mapping a local address. > > > Please respond even if you did it on the previous consensus call. The approach in draft-begen-avt-token-for-portmapping-01 looks to be suffic= ient to allow a server to determine that multiple requests come from the sa= me client, provided the client isn't multi-homed and isn't sharing an IP ad= dress with other clients. The problem statement is not clear enough for me = to be sure if that's sufficient. If it were important to do so, the server could distinguish multiple client= s sharing the same IP address if each client supplied a random nonce that w= as taken into account when generating the token in addition to the client's= IP address. This may be an issue with use of fractional IP addresses in fu= ture, and so might be something to consider adding. TOM: I think this is a good idea. The SSRC of the client associated with th= e SSM RTP session that is present in the portmapping request message could = be used for that purpose (hence token is determined by server on the basis = of IP address, time stamp and client SSRC) Distinguishing multi-homed clients, or clients where requests come from sev= eral different IP addresses, is more complex. Is this an issue, or is it su= fficient to assume that a client requests a new token when changing the add= ress it uses? TOM: IMO that will do..I think it is bad practice if a network stack on a h= ost device/ NAT device allocates different IP addresses towards a applicati= on/end-host=20 I'd also like to note that the port mapping operation is independent of the= RAMS drafts. It would be good if the draft the group ends up with is writt= en as a standalone mechanism, with RAMS described as one example use case, = rather than being written in a RAMS-specific manner as are the current draf= ts. TOM: The text is meant to be (only) applicable to scenarios building on SSM= sessions with unicast feedback, no? We wanted a fast -inband- way for a cl= ient to communicate the client receive port for a unicast connection that i= s linked to such a SSM. In that case, the text is sufficiently generic (e.g= . RAMS is not even mentioned in the text, whereas the example is about retr= ansmissions). I take it that any other parameter signaling (port, any attri= butes,..) for any other scenario needs to leverage the SDP offer-answer mod= el. =20 Cheers, Colin --=20 Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From csp@csperkins.org Tue Oct 12 04:32:44 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F61F3A67AE for ; Tue, 12 Oct 2010 04:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.065 X-Spam-Level: X-Spam-Status: No, score=-103.065 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWHhx6CLDTku for ; Tue, 12 Oct 2010 04:32:43 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 671AB3A692B for ; Tue, 12 Oct 2010 04:32:42 -0700 (PDT) Received: from [12.159.134.153] (helo=[10.0.0.64]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P5d7D-0001GN-bz; Tue, 12 Oct 2010 11:33:56 +0000 Message-Id: <25C8F1CC-8CBD-4AE0-B3C7-DBEF7A960B6A@csperkins.org> From: Colin Perkins To: "Van Caenegem, Tom (Tom)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 12 Oct 2010 07:33:51 -0400 References: <00d801cb55b7$ffb41840$ff1c48c0$@net> <04CAD96D4C5A3D48B1919248A8FE0D540D2D23B0@xmb-sjc-215.amer.cisco.com> <01ec01cb5630$1ebf65f0$5c3e31d0$@net> <042601cb663b$c5317ed0$4f947c70$%roni@huawei.com> <04ce01cb66c5$6f425640$4dc702c0$%roni@huawei.com> <5AF80FBB-63A8-4C1B-A5FA-57C00548BDC8@csperkins.org> X-Mailer: Apple Mail (2.936) Cc: 'Dan Wing' , "DRAGE, Keith \(Keith\)" , 'IETF AVT WG' , Roni Even Subject: Re: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 11:32:44 -0000 On 12 Oct 2010, at 06:23, Van Caenegem, Tom (Tom) wrote: > Hi Colin, > > See below, > Tom > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf > Of Colin Perkins > Sent: maandag 11 oktober 2010 18:51 > To: Roni Even > Cc: DRAGE, Keith (Keith); 'IETF AVT WG'; 'Dan Wing' > Subject: Re: [AVT] Revised Consensus call - On Token approach for > draft-ietf-avt-ports-for-ucast-mcast-rtp > > On 8 Oct 2010, at 09:47, Roni Even wrote: >> There were some concerns about how we drafted the consensus call so I >> would like to try and give it another try. Sorry for the long >> message >> which I hope will clarify what are the proposed options. We would >> like >> to get feedback by October 18th. >> >> >> The Port Mapping Between Unicast and Multicast RTP Sessions described >> in >> http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast- >> rtp-02 >> was discussed for a couple of IETF meeting and on the list. The >> initial approach that was agreed after we had a breakout session in >> previous IETF meetings was to use a cookie based solution even though >> it required more messages and you needed a cookie for every RTP >> session. >> >> Before the last IETF meeting there were two proposals to update the >> solution to a token based approach. >> >> In the token approach: >> - Tokens are port-independent (cookies are port-dependent) and only >> depend on the client's IP. That is, once a client gets its token, it >> can use it with any of its ports and with any Feedback Target. >> - Tokens address the concern raised by Magnus >> (http://www.ietf.org/mail-archive/web/avt/current/msg12617.html >> ) >> - No need for keep-alives >> >> We had a discussion in Maastricht and the outcome is in the meeting >> minutes http://www.ietf.org/proceedings/78/minutes/avt.txt (see the >> section on draft-begen-avt-token-for-portmapping). The token draft >> has >> Dan Wing (who is also BEHAVE co-chair) as a co-author and he looked >> at >> the solution verifying that it will work well with NATs >> >> >> At the meeting the preference was for a token based solution but >> there >> are were two approaches discussed. >> >> 1. Use the token only solution >> >> 2. Use a combination when if the request has only an IP address the >> response will be a token and if it will have both IP address and port >> the response will be a cookie. >> >> According to the minutes the support was for the second approach. >> The major reason was a concern that carrier grade NATs can allocate >> more than one IP address as the public address. >> >> The authors of >> http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 >> suggest that they addressed the concerns about the token only >> solution >> (see section 9 of the draft) and prefer to have a token only >> solution. >> This is a change from the meeting minutes and this is the reason for >> the second question in this consensus call. >> >> So here are two questions for the group !!! >> >> 1. Do the people in the mailing list support the proposal to use a >> token based solution instead on the cookie one. (this was the >> preference in the consensus call in Maastricht) and we would like to >> confirm it on the list. >> >> 2. We have two options for the token approach, please give your >> preferences. >> >> 2.1 Token only solution as proposed in >> http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 >> 2.2 Token + cookie, in this case if the request will include only IP >> address the response is a token, if it also includes a port it will >> be >> a cookie. This approach is for cases were the NAT may use more than >> one IP address for mapping a local address. >> >> >> Please respond even if you did it on the previous consensus call. > > > The approach in draft-begen-avt-token-for-portmapping-01 looks to be > sufficient to allow a server to determine that multiple requests > come from the same client, provided the client isn't multi-homed and > isn't sharing an IP address with other clients. The problem > statement is not clear enough for me to be sure if that's sufficient. > > If it were important to do so, the server could distinguish multiple > clients sharing the same IP address if each client supplied a random > nonce that was taken into account when generating the token in > addition to the client's IP address. This may be an issue with use > of fractional IP addresses in future, and so might be something to > consider adding. > > > TOM: I think this is a good idea. The SSRC of the client associated > with the SSM RTP session that is present in the portmapping request > message could be used for that purpose (hence token is determined by > server on the basis of IP address, time stamp and client SSRC) No, because the SSRC can change, and this should be persistent per client. > Distinguishing multi-homed clients, or clients where requests come > from several different IP addresses, is more complex. Is this an > issue, or is it sufficient to assume that a client requests a new > token when changing the address it uses? > > TOM: IMO that will do..I think it is bad practice if a network stack > on a host device/ NAT device allocates different IP addresses > towards a application/end-host > > I'd also like to note that the port mapping operation is independent > of the RAMS drafts. It would be good if the draft the group ends up > with is written as a standalone mechanism, with RAMS described as > one example use case, rather than being written in a RAMS-specific > manner as are the current drafts. > > TOM: The text is meant to be (only) applicable to scenarios building > on SSM sessions with unicast feedback, no? We wanted a fast -inband- > way for a client to communicate the client receive port for a > unicast connection that is linked to such a SSM. In that case, the > text is sufficiently generic (e.g. RAMS is not even mentioned in the > text, whereas the example is about retransmissions). I take it that > any other parameter signaling (port, any attributes,..) for any > other scenario needs to leverage the SDP offer-answer model. > > Cheers, > Colin > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ From tom.van_caenegem@alcatel-lucent.com Tue Oct 12 05:07:12 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6223A6909 for ; Tue, 12 Oct 2010 05:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSLHNcy1EP3N for ; Tue, 12 Oct 2010 05:07:10 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 25D0A3A67D3 for ; Tue, 12 Oct 2010 05:07:09 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9CC7Woc005854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Oct 2010 14:07:37 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 12 Oct 2010 14:06:55 +0200 From: "Van Caenegem, Tom (Tom)" To: Colin Perkins Date: Tue, 12 Oct 2010 14:06:54 +0200 Thread-Topic: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp Thread-Index: ActqAWg8OfwvyeXDQFqiWlE1VfhuLQAA/wtA Message-ID: References: <00d801cb55b7$ffb41840$ff1c48c0$@net> <04CAD96D4C5A3D48B1919248A8FE0D540D2D23B0@xmb-sjc-215.amer.cisco.com> <01ec01cb5630$1ebf65f0$5c3e31d0$@net> <042601cb663b$c5317ed0$4f947c70$%roni@huawei.com> <04ce01cb66c5$6f425640$4dc702c0$%roni@huawei.com> <5AF80FBB-63A8-4C1B-A5FA-57C00548BDC8@csperkins.org> <25C8F1CC-8CBD-4AE0-B3C7-DBEF7A960B6A@csperkins.org> In-Reply-To: <25C8F1CC-8CBD-4AE0-B3C7-DBEF7A960B6A@csperkins.org> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: 'Dan Wing' , "DRAGE, Keith \(Keith\)" , 'IETF AVT WG' , Roni Even Subject: Re: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 12:07:12 -0000 Yes, you are right on SSRC. A dedicated random nonce will be required.=20 Are you OK with my view on how wide (or narrow) the cookie method can be us= ed? Tom -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: dinsdag 12 oktober 2010 13:34 To: Van Caenegem, Tom (Tom) Cc: Roni Even; DRAGE, Keith (Keith); 'IETF AVT WG'; 'Dan Wing' Subject: Re: [AVT] Revised Consensus call - On Token approach for draft-iet= f-avt-ports-for-ucast-mcast-rtp On 12 Oct 2010, at 06:23, Van Caenegem, Tom (Tom) wrote: > Hi Colin, > > See below, > Tom > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of=20 > Colin Perkins > Sent: maandag 11 oktober 2010 18:51 > To: Roni Even > Cc: DRAGE, Keith (Keith); 'IETF AVT WG'; 'Dan Wing' > Subject: Re: [AVT] Revised Consensus call - On Token approach for=20 > draft-ietf-avt-ports-for-ucast-mcast-rtp > > On 8 Oct 2010, at 09:47, Roni Even wrote: >> There were some concerns about how we drafted the consensus call so I=20 >> would like to try and give it another try. Sorry for the long=20 >> message which I hope will clarify what are the proposed options. We=20 >> would like to get feedback by October 18th. >> >> >> The Port Mapping Between Unicast and Multicast RTP Sessions described=20 >> in >> http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast- >> rtp-02 >> was discussed for a couple of IETF meeting and on the list. The=20 >> initial approach that was agreed after we had a breakout session in=20 >> previous IETF meetings was to use a cookie based solution even though=20 >> it required more messages and you needed a cookie for every RTP=20 >> session. >> >> Before the last IETF meeting there were two proposals to update the=20 >> solution to a token based approach. >> >> In the token approach: >> - Tokens are port-independent (cookies are port-dependent) and only=20 >> depend on the client's IP. That is, once a client gets its token, it=20 >> can use it with any of its ports and with any Feedback Target. >> - Tokens address the concern raised by Magnus=20 >> (http://www.ietf.org/mail-archive/web/avt/current/msg12617.html >> ) >> - No need for keep-alives >> >> We had a discussion in Maastricht and the outcome is in the meeting=20 >> minutes http://www.ietf.org/proceedings/78/minutes/avt.txt (see the=20 >> section on draft-begen-avt-token-for-portmapping). The token draft=20 >> has Dan Wing (who is also BEHAVE co-chair) as a co-author and he=20 >> looked at the solution verifying that it will work well with NATs >> >> >> At the meeting the preference was for a token based solution but=20 >> there are were two approaches discussed. >> >> 1. Use the token only solution >> >> 2. Use a combination when if the request has only an IP address the=20 >> response will be a token and if it will have both IP address and port=20 >> the response will be a cookie. >> >> According to the minutes the support was for the second approach. >> The major reason was a concern that carrier grade NATs can allocate=20 >> more than one IP address as the public address. >> >> The authors of >> http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 >> suggest that they addressed the concerns about the token only=20 >> solution (see section 9 of the draft) and prefer to have a token only=20 >> solution. >> This is a change from the meeting minutes and this is the reason for=20 >> the second question in this consensus call. >> >> So here are two questions for the group !!! >> >> 1. Do the people in the mailing list support the proposal to use a=20 >> token based solution instead on the cookie one. (this was the=20 >> preference in the consensus call in Maastricht) and we would like to=20 >> confirm it on the list. >> >> 2. We have two options for the token approach, please give your=20 >> preferences. >> >> 2.1 Token only solution as proposed in >> http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 >> 2.2 Token + cookie, in this case if the request will include only IP=20 >> address the response is a token, if it also includes a port it will=20 >> be a cookie. This approach is for cases were the NAT may use more=20 >> than one IP address for mapping a local address. >> >> >> Please respond even if you did it on the previous consensus call. > > > The approach in draft-begen-avt-token-for-portmapping-01 looks to be=20 > sufficient to allow a server to determine that multiple requests come=20 > from the same client, provided the client isn't multi-homed and isn't=20 > sharing an IP address with other clients. The problem statement is not=20 > clear enough for me to be sure if that's sufficient. > > If it were important to do so, the server could distinguish multiple=20 > clients sharing the same IP address if each client supplied a random=20 > nonce that was taken into account when generating the token in=20 > addition to the client's IP address. This may be an issue with use of=20 > fractional IP addresses in future, and so might be something to=20 > consider adding. > > > TOM: I think this is a good idea. The SSRC of the client associated=20 > with the SSM RTP session that is present in the portmapping request=20 > message could be used for that purpose (hence token is determined by=20 > server on the basis of IP address, time stamp and client SSRC) No, because the SSRC can change, and this should be persistent per client. > Distinguishing multi-homed clients, or clients where requests come=20 > from several different IP addresses, is more complex. Is this an=20 > issue, or is it sufficient to assume that a client requests a new=20 > token when changing the address it uses? > > TOM: IMO that will do..I think it is bad practice if a network stack=20 > on a host device/ NAT device allocates different IP addresses towards=20 > a application/end-host > > I'd also like to note that the port mapping operation is independent=20 > of the RAMS drafts. It would be good if the draft the group ends up=20 > with is written as a standalone mechanism, with RAMS described as one=20 > example use case, rather than being written in a RAMS-specific manner=20 > as are the current drafts. > > TOM: The text is meant to be (only) applicable to scenarios building=20 > on SSM sessions with unicast feedback, no? We wanted a fast -inband-=20 > way for a client to communicate the client receive port for a unicast=20 > connection that is linked to such a SSM. In that case, the text is=20 > sufficiently generic (e.g. RAMS is not even mentioned in the text,=20 > whereas the example is about retransmissions). I take it that any=20 > other parameter signaling (port, any attributes,..) for any other=20 > scenario needs to leverage the SDP offer-answer model. > > Cheers, > Colin > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ From peter.musgrave@magorcorp.com Tue Oct 12 05:12:42 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE3B3A695D for ; Tue, 12 Oct 2010 05:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.851 X-Spam-Level: X-Spam-Status: No, score=-101.851 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQVkK-L14n20 for ; Tue, 12 Oct 2010 05:12:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 039823A6916 for ; Tue, 12 Oct 2010 05:12:10 -0700 (PDT) Received: by qwc9 with SMTP id 9so2338043qwc.31 for ; Tue, 12 Oct 2010 05:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.189.74 with SMTP id dd10mr6225509qcb.73.1286885603873; Tue, 12 Oct 2010 05:13:23 -0700 (PDT) Received: by 10.229.42.196 with HTTP; Tue, 12 Oct 2010 05:13:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Oct 2010 08:13:23 -0400 Message-ID: From: Peter Musgrave To: "Brandenburg, R. (Ray) van" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-brandenburg-avt-rtcp-for-idms-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 12:12:42 -0000 Hi Ray, That makes sense to me but I will defer to the AVT chairs w.r.t. the ETSI interaction... Peter Musgrave On Tue, Oct 12, 2010 at 3:47 AM, Brandenburg, R. (Ray) van wrote: > Hi Peter, > > Thanks for your comments. > >> >> Should the relationship of this doc to ETSI TISPAN be mentioned in the >> Abstract? > > > I agree and will add this in the next version. While we're on the subject= : > the main reason we have brought this work to the IETF is because we feel = the > AVT WG should be the place where XR blocks are specified. If there is eno= ugh > interest around here, one option could be to have the AVT WG take the lea= d > on the standardization of this XR block, either as an informational or > standards track document. The relevant sections of the ETSI TISPAN=A0spec > could then reference the resulting RFC.=A0How do you feel about this? > > Regards, > > Ray van Brandenburg > > > > ________________________________ > From: Ishan Vaishnavi [mailto:ishan.vaishnavi@gmail.com] > Sent: maandag 11 oktober 2010 17:40 > To: Peter Musgrave > Cc: Brandenburg, R. (Ray) van; avt@ietf.org > Subject: Re: [AVT] New Version Notification for > draft-brandenburg-avt-rtcp-for-idms-02 > > Hi Peter, > Thanks for taking time to review this document. Find my comments inline. > Cheers, > Ishan > > > >> >> I lack background in the IDMS application. =A0Is the Boronat2009 >> reference available online anywhere? > > You need either an Elsevier account or a Science Direct one. Here is the > link. Hope that helps. > >> >> (I am interested in whether there >> are separate XRs for audio and video and how the lipsync alignment >> issues are handled within the overall synchronization strategy). >> > > In my opinion lip synchronization is somewhat out of the scope of this > document. The idea is that each distributed client reports its play-out > position of its "primary" stream. This primary stream can be a virtual > stream or a real audio, video, subtitles or images for that matter. =A0Al= l > other streams locally on each client synchronize to that stream, this mus= t > be done by the respective application. The current XR specification relat= es > to how to get these primary streams are synchronized across different > geographically separated clients. Maybe it can be extended to include thi= s > local synchronization as well, but that's another discussion. > >> >> Should the relationship of this doc to ETSI TISPAN be mentioned in the >> Abstract? > > I will leave this one for Ray. > > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/disclaimer/email.html > From tom.van_caenegem@alcatel-lucent.com Tue Oct 12 07:34:25 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F6D3A69AA for ; Tue, 12 Oct 2010 07:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.745 X-Spam-Level: X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[AWL=1.504, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc5mMrocb8TP for ; Tue, 12 Oct 2010 07:34:23 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 87D563A69A1 for ; Tue, 12 Oct 2010 07:34:23 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9CEZ4Wk020877 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Oct 2010 16:35:28 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 12 Oct 2010 16:35:24 +0200 From: "Van Caenegem, Tom (Tom)" To: Qin Wu , "avt@ietf.org" Date: Tue, 12 Oct 2010 16:35:23 +0200 Thread-Topic: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 Thread-Index: ActnbV+R7zcHxWCTQUi0E0Q1YZ0jUQCrQ7bA Message-ID: References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> In-Reply-To: <010101cb676d$513735a0$4f548a0a@china.huawei.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 14:34:25 -0000 Hi Qin, these are my comments on the draft 3 version: -you know of course that DVB IPTV has defined a solution to addres NACK sto= rms. This solution was recently also adopted by OIPF. You propose to define= a new dedicated message for NACK suppression, whereas in DVB/OIPF we defin= ed that when an RTP receiver gets such a NACK message, this receiver should= not send a NACK itself (provided the NACK was received before the receiver= sends its own NACK). In a similar way, this could also be defined for FIR = messages. I have no fundamental problem if AVT decides to define a dedicat= ed message, but can you provide arguments why a NACK sent by the distributi= on source/translator in a SSM to the client is not good enough for imposing= NACK suppression to a receiver, by definition? -a general comment: suppressing NACKs from receivers is a very tricky thing= . Sometimes it may do more harm than do any good, and I feel this discussio= n and possible negative impact is not really addressed in this draft. -in your figure 1, the SSM is sourced by the intermediate source which host= s the feedback target and a "loss reporter". This does not represent a real= istic architecture as it would mean that for IPTV scenario the head-end rec= eives all RTCP messages from all receivers. You should include architecture= s where FT are decoupled from the SSM source. -the definition of the "loss reporter" is somewhat obscure to me. From vari= ous text fragments, it appears that a (NACK) FB message sent by the loss re= porter, will result in the intermediate source/distribution source sending = a NACK storm suppression or FFS message to the clients in the group. This= means to me that any packet loss reported by the "loss reporter" is packet= loss that will impact all receivers downstream of the intermediate/distrib= ution source. If this is not the case, you will provide unneeded retransmis= sions. Is this a correct interpretation? If so, please make this clear in t= he definition of "loss reporter". If it is not, then mandating that getting= a NACK from a loss reporter results in a FFS message, is not recommended I= MO. =20 -I do not understand why a "loss reporter" MUST not receive the FFS message= -which is meant to be sent on the SSM-, and I also do not get how you can = avoid that the "loss reporter" would receive this FFS message, as a "loss r= eporter" that is downstream of the intermediate source must be receiving th= e SSM in order to detect missing packets. -you introduce the "immediate reporting RTP client" terminology from the DV= B IPTV spec that is referenced, but its definition does not align with how = it is defined in the DVB spec. So, please, either stick to the DVB definit= ion or use a different term.=20 Regards Tom=20 -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Qin W= u Sent: zaterdag 9 oktober 2010 6:49 To: avt@ietf.org Subject: [AVT] New Version Notification for draft-wu-avt-retransmission-sup= ression-rtp-03 Folks, We have updated draft-wu-avt-retransmission-suppression-rtp which should no= w reflect the discussion we had since IETF78.=20 The feedback suppression solution has also been greatly generalized compari= ng to the previous version. Comments are solicited. Regards! -Qin ----- Original Message ----- From: To: Sent: Saturday, October 09, 2010 12:45 PM Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. >=20 > Title : RTCP Report Extension for Feedback Suppression > Author(s) : W. Wu, et al. > Filename : draft-wu-avt-retransmission-supression-rtp-03.txt > Pages : 24 > Date : 2010-10-08 >=20 > This document specifies an extension to the RTCP feedback messages > defined in the Audio-Visual Profile with Feedback (AVPF). This > extension allows an intermediate node in the network (such as an RTP > translator) inform downstream receivers that sending a feedback > message concerning a specified set of RTP messages may be > unnecessary, or even harmful. For example, in a source-specific > multicast session with large fan-out, packet loss close to the media > or distribution source of the session is detected as a loss by a > large number of receivers. The RTCP NACK messages used to request > retransmission of the missing packets are all addressed to the media > sender, or a designated feedback target. This may result in a > phenomenon known variously as a "NACK implosion" or "feedback storm". > The Feedback Suppression message defined herein is used to notify > receivers that packet loss was detected and that the sender of the > report will either proactively recover, or no recovery is possible. > Receivers respond to receipt of a feedback suppression message by not > sending a feedback message (e.g. a NACK) that they otherwise would, > This in turn reduces load on both the feedback target and on the > network. This document registers two new RTCP messages for Feedback > Suppression. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supressio= n-rtp-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ---------------------------------------------------------------------------= ----- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From abegen@cisco.com Tue Oct 12 07:34:43 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402473A69B5 for ; Tue, 12 Oct 2010 07:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ratD31RM6bEt for ; Tue, 12 Oct 2010 07:34:42 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BB60A3A69A1 for ; Tue, 12 Oct 2010 07:34:41 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALYOtEytJV2Y/2dsb2JhbAChUXGhO5x1hUgEhFKIeA X-IronPort-AV: E=Sophos;i="4.57,320,1283731200"; d="scan'208";a="169588090" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 12 Oct 2010 14:35:55 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o9CEZtdK010970; Tue, 12 Oct 2010 14:35:55 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Oct 2010 07:35:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Oct 2010 07:34:59 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF7F9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <00d701cb69df$d02c9fc0$7085df40$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] New Version Notification fordraft-wu-avt-retransmission-supression-rtp-03 Thread-Index: ActpH7kgfTe2z49qSseuM+ZpW7Ys1wAfLjIAABB5SpAADoByAA== References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35C@xmb-sjc-215.amer.cisco.com> <011501cb691f$aa2efd60$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF6E6@xmb-sjc-215.amer.cisco.com> <00d701cb69df$d02c9fc0$7085df40$%roni@huawei.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , "Qin Wu" , X-OriginalArrivalTime: 12 Oct 2010 14:35:55.0085 (UTC) FILETIME=[C7048FD0:01CB6A1A] Subject: Re: [AVT] New Version Notification fordraft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 14:34:43 -0000 > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Tuesday, October 12, 2010 3:34 AM > To: Ali C. Begen (abegen); 'Qin Wu'; avt@ietf.org > Subject: RE: [AVT] New Version Notification = fordraft-wu-avt-retransmission-supression-rtp-03 >=20 >=20 > Hi, > > > > ... > > > 8) Section 6.1.1 says "If the loss reporter is part of group, the > > Distribution source MUST filter this packet out and not forward > > > it back to this loss reporter." How does it filter that loss = reporter > > out? > > > > > > [Qin]: It is one optimized behavior. > > > One possible way to do this is that the Distribution Source knows = the > > address of loss reporter or know in which port it can > > > receive the RTCP message from the loss reporter. > > > Is that reasonable? > > > > Are your reports unicast or multicast? In the latter, how do you = deal > > with it? >=20 > I think this has to do with your question about merging reports. Sure, but either I am missing something or could not explain my question = clearly. But no hurry we can discuss it in the meeting. =20 > > > 9) What about the cases where the receiver will actually not send = a > > NACK despite the packet loss? Consider where there is > > > also a FEC stream that can recover the lost packets. Should the = loss > > reporter listen to the FEC channel as well and act > > > accordingly? > > > > > > [Qin]: Good question. I think if the reciever know it will not = send a > > NACK, then the distribution source should know as well. In > > > > Not necessarily. If the FEC is on another distribution channel = (which > > is usually the case), the DS does not know what the receivers are > > getting in terms of FEC. >=20 > From the DS perspective there are packet losses and letting the = receiver > know even if it uses FEC may help the receiver giving him an earlier = warning > allowing him to use FEC without waiting. Early warning is not bad, could be useful but FEC was just one example. = We probably need to think about this more. =20 > > > such case, the distribution source may choose not to send feedback > > suppression message to the receiver. > > > > I think we need to think about this a bit further. If FEC recovers = most > > of the errors for majority of the receivers, maybe doing this = (feedback > > suppression) will not be needed as much. > > > > > 10) You seem to assume that different loss reporters will always = see > > the same losses. That is not necessarily true. What > > > should be reported back to the receivers if the reports coming to = the > > FT are conflicting? Do you report the union or > > > intersection of the reports back to the receivers? > > > > > > [Qin]: If there are duplication reports, the Distribution source > > should filter the duplicated report out and only send one copy > > > of report to the reciever. What the distribution source does is to > > create one summary report which only append different loss > > > in this summary report. > > > > This does not answer my question. If the reports are identical, yes = you > > can remove the duplicate. But if the reports are not identical. Now = you > > have a decision to make? And whatever you do may actually change the > > performance. >=20 > This is a good feedback. I think that this is application dependent, = the > typical behavior can be union but if the DS knows the network topology = it > may take another policy. Anyhow even if the receiver gets the union = and on > his path the packet were not lost, it does not break since it will = receive > the packets. The suppression just tell the receiver to not sent NACKs. = The > draft does not address the behavior of the DS in the upstream = direction and > leave it open to the implementation. I think we need some guidelines presented in the draft since different = reports will show up from time to time and some recommendations would be = useful. -acbegen =20 > Roni Even >=20 > > > > -acbegen > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Tue Oct 12 08:37:11 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DDA3A63EB for ; Tue, 12 Oct 2010 08:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.445 X-Spam-Level: X-Spam-Status: No, score=-100.445 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv-WMCbdNkDt for ; Tue, 12 Oct 2010 08:37:10 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 8FF7A3A68E4 for ; Tue, 12 Oct 2010 08:37:09 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA600LBKORPC4@szxga02-in.huawei.com> for avt@ietf.org; Tue, 12 Oct 2010 23:38:13 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA600DWXORPLE@szxga02-in.huawei.com> for avt@ietf.org; Tue, 12 Oct 2010 23:38:13 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-21-162.red.bezeqint.net [79.183.21.162]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA600KWBORGDG@szxml01-in.huawei.com>; Tue, 12 Oct 2010 23:38:13 +0800 (CST) Date: Tue, 12 Oct 2010 17:35:28 +0200 From: Roni Even In-reply-to: To: "'Van Caenegem, Tom (Tom)'" , 'Qin Wu' , avt@ietf.org Message-id: <015e01cb6a23$1da20c70$58e62550$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: ActnbV+R7zcHxWCTQUi0E0Q1YZ0jUQCrQ7bAAAGRh+A= References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 15:37:11 -0000 Hi Tom, The semantics of sending NACK from the sender is not defined in RFC 4585. We could add the sender semantics to NACK but the consensus so far was to use a new message and not add new semantics to NACK. Note that the use of the message is not only for NACK suppression. See inline Roni > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Van Caenegem, Tom (Tom) > Sent: Tuesday, October 12, 2010 4:35 PM > To: Qin Wu; avt@ietf.org > Subject: Re: [AVT] New Version Notification for draft-wu-avt- > retransmission-supression-rtp-03 > > Hi Qin, > > these are my comments on the draft 3 version: > > -you know of course that DVB IPTV has defined a solution to addres NACK > storms. This solution was recently also adopted by OIPF. You propose to > define a new dedicated message for NACK suppression, whereas in > DVB/OIPF we defined that when an RTP receiver gets such a NACK message, > this receiver should not send a NACK itself (provided the NACK was > received before the receiver sends its own NACK). In a similar way, > this could also be defined for FIR messages. I have no fundamental > problem if AVT decides to define a dedicated message, but can you > provide arguments why a NACK sent by the distribution source/translator > in a SSM to the client is not good enough for imposing NACK suppression > to a receiver, by definition? > > -a general comment: suppressing NACKs from receivers is a very tricky > thing. Sometimes it may do more harm than do any good, and I feel this > discussion and possible negative impact is not really addressed in this > draft. I am not sure what you mean here. The receivers do not suppress NACKs, the NACK suppression is sent by intermediary devices. > > -in your figure 1, the SSM is sourced by the intermediate source which > hosts the feedback target and a "loss reporter". This does not > represent a realistic architecture as it would mean that for IPTV > scenario the head-end receives all RTCP messages from all receivers. > You should include architectures where FT are decoupled from the SSM > source. This is not IPTV specific feature so this is an example. There can be other cases. > > -the definition of the "loss reporter" is somewhat obscure to me. From > various text fragments, it appears that a (NACK) FB message sent by the > loss reporter, will result in the intermediate source/distribution > source sending a NACK storm suppression or FFS message to the clients > in the group. This means to me that any packet loss reported by the > "loss reporter" is packet loss that will impact all receivers > downstream of the intermediate/distribution source. If this is not the > case, you will provide unneeded retransmissions. Is this a correct > interpretation? If so, please make this clear in the definition of > "loss reporter". If it is not, then mandating that getting a NACK from > a loss reporter results in a FFS message, is not recommended IMO. The draft only says the intermediate device will send NACK suppression and leaves open the application behavior in the upstream side. The discussion so far suggested that it should be out of scope for the draft. > > -I do not understand why a "loss reporter" MUST not receive the FFS > message -which is meant to be sent on the SSM-, and I also do not get > how you can avoid that the "loss reporter" would receive this FFS > message, as a "loss reporter" that is downstream of the intermediate > source must be receiving the SSM in order to detect missing packets. > > -you introduce the "immediate reporting RTP client" terminology from > the DVB IPTV spec that is referenced, but its definition does not align > with how it is defined in the DVB spec. So, please, either stick to > the DVB definition or use a different term. > > Regards > Tom > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Qin Wu > Sent: zaterdag 9 oktober 2010 6:49 > To: avt@ietf.org > Subject: [AVT] New Version Notification for draft-wu-avt- > retransmission-supression-rtp-03 > > Folks, > > We have updated draft-wu-avt-retransmission-suppression-rtp which > should now reflect the discussion we had since IETF78. > > The feedback suppression solution has also been greatly generalized > comparing to the previous version. > > Comments are solicited. > > Regards! > -Qin > ----- Original Message ----- > From: > To: > Sent: Saturday, October 09, 2010 12:45 PM > Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : RTCP Report Extension for Feedback Suppression > > Author(s) : W. Wu, et al. > > Filename : draft-wu-avt-retransmission-supression-rtp-03.txt > > Pages : 24 > > Date : 2010-10-08 > > > > This document specifies an extension to the RTCP feedback messages > > defined in the Audio-Visual Profile with Feedback (AVPF). This > > extension allows an intermediate node in the network (such as an RTP > > translator) inform downstream receivers that sending a feedback > > message concerning a specified set of RTP messages may be > > unnecessary, or even harmful. For example, in a source-specific > > multicast session with large fan-out, packet loss close to the media > > or distribution source of the session is detected as a loss by a > > large number of receivers. The RTCP NACK messages used to request > > retransmission of the missing packets are all addressed to the media > > sender, or a designated feedback target. This may result in a > > phenomenon known variously as a "NACK implosion" or "feedback storm". > > The Feedback Suppression message defined herein is used to notify > > receivers that packet loss was detected and that the sender of the > > report will either proactively recover, or no recovery is possible. > > Receivers respond to receipt of a feedback suppression message by not > > sending a feedback message (e.g. a NACK) that they otherwise would, > > This in turn reduces load on both the feedback target and on the > > network. This document registers two new RTCP messages for Feedback > > Suppression. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission- > supression-rtp-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > ----------------------------------------------------------------------- > --------- > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Tue Oct 12 23:46:40 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E7A3A68C5 for ; Tue, 12 Oct 2010 23:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.456 X-Spam-Level: X-Spam-Status: No, score=-100.456 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqmz5kZQsVCW for ; Tue, 12 Oct 2010 23:46:39 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BAA5F3A6877 for ; Tue, 12 Oct 2010 23:46:39 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA700MYRUVLKI@szxga04-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 14:47:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA700MMNUVLVB@szxga04-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 14:47:45 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-21-162.red.bezeqint.net [79.183.21.162]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA700LEQUVBJD@szxml02-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 14:47:45 +0800 (CST) Date: Wed, 13 Oct 2010 08:44:52 +0200 From: Roni Even To: avt@ietf.org Message-id: <000201cb6aa2$2d3a9010$87afb030$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zWCCLcWfz4yyELIXbJLhoA)" Content-language: en-us Thread-index: ActqoiMHk8fNcIoMQkKPs9f6wTewAA== Subject: [AVT] probable change of session date X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 06:46:40 -0000 This is a multi-part message in MIME format. --Boundary_(ID_zWCCLcWfz4yyELIXbJLhoA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, There is a proposal to swap SIPREC Thursday pm with AVT Wednesday pm. This swap is not yet confirmed, but please for now ensure that your travel arrangements don't preclude either slot. The final agenda should be published this Friday, 2010-10-15. Regards Roni Even AVT co-chair --Boundary_(ID_zWCCLcWfz4yyELIXbJLhoA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

 

There is a proposal to swap SIPREC Thursday pm with AVT Wednesday pm. This swap is not yet confirmed, but please for now ensure that your travel arrangements don't preclude either slot. The final agenda should be published this Friday, 2010-10-15.

 

Regards

Roni Even

AVT co-chair

--Boundary_(ID_zWCCLcWfz4yyELIXbJLhoA)-- From sunseawq@huawei.com Wed Oct 13 01:13:11 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21903A6909 for ; Wed, 13 Oct 2010 01:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOka0+DjsHKY for ; Wed, 13 Oct 2010 01:13:09 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 280A93A67B6 for ; Wed, 13 Oct 2010 01:13:09 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA700CTLYTAL6@szxga03-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 16:12:46 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA700096YTARH@szxga03-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 16:12:46 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA700K1QYT9YT@szxml06-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 16:12:46 +0800 (CST) Date: Wed, 13 Oct 2010 16:12:46 +0800 From: Qin Wu To: Roni Even , "'Van Caenegem, Tom (Tom)'" , avt@ietf.org Message-id: <023301cb6aae$6b711d20$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> <015e01cb6a23$1da20c70$58e62550$%roni@huawei.com> Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 08:13:11 -0000 Hi,: Thank Tom for your valubable reviews. I agree with Roni's clarification in response to your comments. I will soon issue new version to address all the comments recieved on the list. Thank for all. Regards! -Qin ----- Original Message ----- From: "Roni Even" To: "'Van Caenegem, Tom (Tom)'" ; "'Qin Wu'" ; Sent: Tuesday, October 12, 2010 11:35 PM Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 > Hi Tom, > The semantics of sending NACK from the sender is not defined in RFC 4585. We > could add the sender semantics to NACK but the consensus so far was to use a > new message and not add new semantics to NACK. Note that the use of the > message is not only for NACK suppression. > > See inline > > Roni > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >> Van Caenegem, Tom (Tom) >> Sent: Tuesday, October 12, 2010 4:35 PM >> To: Qin Wu; avt@ietf.org >> Subject: Re: [AVT] New Version Notification for draft-wu-avt- >> retransmission-supression-rtp-03 >> >> Hi Qin, >> >> these are my comments on the draft 3 version: >> >> -you know of course that DVB IPTV has defined a solution to addres NACK >> storms. This solution was recently also adopted by OIPF. You propose to >> define a new dedicated message for NACK suppression, whereas in >> DVB/OIPF we defined that when an RTP receiver gets such a NACK message, >> this receiver should not send a NACK itself (provided the NACK was >> received before the receiver sends its own NACK). In a similar way, >> this could also be defined for FIR messages. I have no fundamental >> problem if AVT decides to define a dedicated message, but can you >> provide arguments why a NACK sent by the distribution source/translator >> in a SSM to the client is not good enough for imposing NACK suppression >> to a receiver, by definition? >> >> -a general comment: suppressing NACKs from receivers is a very tricky >> thing. Sometimes it may do more harm than do any good, and I feel this >> discussion and possible negative impact is not really addressed in this >> draft. > > I am not sure what you mean here. The receivers do not suppress NACKs, the > NACK suppression is sent by intermediary devices. [Qin]: It seems to me suppressing NACK from one dedicated reciever is not good choice as I talked with Ali on the list. Therefore our draft will focus on how to use distribution source to suppress NACK or Feedback message sent from downstream of distribution source. > >> >> -in your figure 1, the SSM is sourced by the intermediate source which >> hosts the feedback target and a "loss reporter". This does not >> represent a realistic architecture as it would mean that for IPTV >> scenario the head-end receives all RTCP messages from all receivers. >> You should include architectures where FT are decoupled from the SSM >> source. > > This is not IPTV specific feature so this is an example. There can be other > cases. > >> >> -the definition of the "loss reporter" is somewhat obscure to me. From >> various text fragments, it appears that a (NACK) FB message sent by the >> loss reporter, will result in the intermediate source/distribution >> source sending a NACK storm suppression or FFS message to the clients >> in the group. This means to me that any packet loss reported by the >> "loss reporter" is packet loss that will impact all receivers >> downstream of the intermediate/distribution source. If this is not the >> case, you will provide unneeded retransmissions. Is this a correct >> interpretation? If so, please make this clear in the definition of >> "loss reporter". If it is not, then mandating that getting a NACK from >> a loss reporter results in a FFS message, is not recommended IMO. > > The draft only says the intermediate device will send NACK suppression and > leaves open the application behavior in the upstream side. The discussion so > far suggested that it should be out of scope for the draft. [Qin]: Yes, the draft will focus on defining new NACK suppression message using RTCP and how to use such new message to suppression feedback implosion. > >> >> -I do not understand why a "loss reporter" MUST not receive the FFS >> message -which is meant to be sent on the SSM-, and I also do not get >> how you can avoid that the "loss reporter" would receive this FFS >> message, as a "loss reporter" that is downstream of the intermediate >> source must be receiving the SSM in order to detect missing packets. [Qin]: I think you raise the same issue as Ali. You are right, it does not make sense to avoid the loss reporter to receive Feedback Suppression message if the loss reporter is part of group. I will remove the following paragraph from the draft. " If the Loss Detector is part of group, the Distribution source MUST not send the summary report back to this Loss Detector. " >> -you introduce the "immediate reporting RTP client" terminology from >> the DVB IPTV spec that is referenced, but its definition does not align >> with how it is defined in the DVB spec. So, please, either stick to >> the DVB definition or use a different term. [Qin]: Okay, I will leave "immediate reporting RTP client" out of this draft. >> Regards >> Tom >> >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >> Qin Wu >> Sent: zaterdag 9 oktober 2010 6:49 >> To: avt@ietf.org >> Subject: [AVT] New Version Notification for draft-wu-avt- >> retransmission-supression-rtp-03 >> >> Folks, >> >> We have updated draft-wu-avt-retransmission-suppression-rtp which >> should now reflect the discussion we had since IETF78. >> >> The feedback suppression solution has also been greatly generalized >> comparing to the previous version. >> >> Comments are solicited. >> >> Regards! >> -Qin >> ----- Original Message ----- >> From: >> To: >> Sent: Saturday, October 09, 2010 12:45 PM >> Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt >> >> >> >A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > >> > Title : RTCP Report Extension for Feedback Suppression >> > Author(s) : W. Wu, et al. >> > Filename : draft-wu-avt-retransmission-supression-rtp-03.txt >> > Pages : 24 >> > Date : 2010-10-08 >> > >> > This document specifies an extension to the RTCP feedback messages >> > defined in the Audio-Visual Profile with Feedback (AVPF). This >> > extension allows an intermediate node in the network (such as an RTP >> > translator) inform downstream receivers that sending a feedback >> > message concerning a specified set of RTP messages may be >> > unnecessary, or even harmful. For example, in a source-specific >> > multicast session with large fan-out, packet loss close to the media >> > or distribution source of the session is detected as a loss by a >> > large number of receivers. The RTCP NACK messages used to request >> > retransmission of the missing packets are all addressed to the media >> > sender, or a designated feedback target. This may result in a >> > phenomenon known variously as a "NACK implosion" or "feedback storm". >> > The Feedback Suppression message defined herein is used to notify >> > receivers that packet loss was detected and that the sender of the >> > report will either proactively recover, or no recovery is possible. >> > Receivers respond to receipt of a feedback suppression message by not >> > sending a feedback message (e.g. a NACK) that they otherwise would, >> > This in turn reduces load on both the feedback target and on the >> > network. This document registers two new RTCP messages for Feedback >> > Suppression. >> > >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission- >> supression-rtp-03.txt >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > Below is the data which will enable a MIME compliant mail reader >> > implementation to automatically retrieve the ASCII version of the >> > Internet-Draft. >> > >> >> >> ----------------------------------------------------------------------- >> --------- >> >> >> > _______________________________________________ >> > I-D-Announce mailing list >> > I-D-Announce@ietf.org >> > https://www.ietf.org/mailman/listinfo/i-d-announce >> > Internet-Draft directories: http://www.ietf.org/shadow.html >> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > From sunseawq@huawei.com Wed Oct 13 01:47:24 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64AD93A6807 for ; Wed, 13 Oct 2010 01:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.077 X-Spam-Level: X-Spam-Status: No, score=0.077 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDI-xr5BN70H for ; Wed, 13 Oct 2010 01:47:23 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E588B3A6405 for ; Wed, 13 Oct 2010 01:47:22 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA800JOB0ENXJ@szxga04-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 16:47:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA800I3Z0ENUN@szxga04-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 16:47:11 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA800KOS0EMYQ@szxml06-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 16:47:11 +0800 (CST) Date: Wed, 13 Oct 2010 16:47:10 +0800 From: Qin Wu To: avt@ietf.org Message-id: <035f01cb6ab3$39ca4a80$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/mixed; boundary="Boundary_(ID_5udjgl0lkHBHKLVz5iMahQ)" X-Priority: 3 X-MSMail-priority: Normal Subject: [AVT] Fw: I-D Action:draft-wu-avt-retransmission-supression-rtp-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 08:47:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5udjgl0lkHBHKLVz5iMahQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, We have just issued the new version of Feedback Suppression draft. This addressed comments made by Ali, Colin and Tom. In particular, I've tried to make it clear that this draft specify what feedback suppression message look like and how they are used. How the packet loss is detected and repaired is not focus of this draft. A URL for this Draft is avaiable at: http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt Comments! Regards! -Qin ----- Original Message ----- From: To: Sent: Wednesday, October 13, 2010 4:30 PM Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-04.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : RTCP Report Extension for Feedback Suppression > Author(s) : W. Wu, et al. > Filename : draft-wu-avt-retransmission-supression-rtp-04.txt > Pages : 23 > Date : 2010-10-13 > > When packet loss close to the media source or intermediary of the > session is detected as a loss by a large number of receivers, large > number of feedback requests used to ask for the lost RTP packets are > all addressed to the same media source, or a designated feedback > target. This may result in a phenomenon known variously as a > "feedback storm " or "feedback implosion ". > > This document specifies an extension to the RTCP feedback messages > defined in the Audio-Visual Profile with Feedback (AVPF). This > extension allows an intermediate node in the network (such as an RTP > translator) inform downstream receivers that packet loss was detected > and sending a feedback message concerning a specified set of RTP > packets may be unnecessary, or even harmful. Receivers respond to > receipt of a feedback suppression message by not sending a feedback > message (e.g. a NACK) that they otherwise would, This in turn reduces > load on both the feedback target and on the network. The proposed > extension is useful for single-source multicast sessions. In > addition, it can be applied to any other types of RTP sessions and > topologies that might benefit from feedback suppression mechanism. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --Boundary_(ID_5udjgl0lkHBHKLVz5iMahQ) Content-type: text/plain; name=draft-wu-avt-retransmission-supression-rtp-04.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-wu-avt-retransmission-supression-rtp-04.txt Content-Type: text/plain Content-ID: <2010-10-13012546.I-D@ietf.org> --Boundary_(ID_5udjgl0lkHBHKLVz5iMahQ)-- From root@core3.amsl.com Wed Oct 13 02:15:02 2010 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 88C9C3A695A; Wed, 13 Oct 2010 02:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101013091502.88C9C3A695A@core3.amsl.com> Date: Wed, 13 Oct 2010 02:15:01 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-ipmr-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 09:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for IP-MR Speech Codec Author(s) : D. Yudin Filename : draft-ietf-avt-rtp-ipmr-14.txt Pages : 20 Date : 2010-10-13 This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the real-time transport protocol (RTP). The payload format supports transmission of multiple frames per packet and introduced redundancy for robustness against packet loss and bit errors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ipmr-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-ipmr-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-13021423.I-D@ietf.org> --NextPart-- From sunseawq@huawei.com Wed Oct 13 03:11:25 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94EC43A6954 for ; Wed, 13 Oct 2010 03:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.943 X-Spam-Level: X-Spam-Status: No, score=0.943 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYbrzxm3FELh for ; Wed, 13 Oct 2010 03:11:23 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 7AF753A68EE for ; Wed, 13 Oct 2010 03:11:10 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA800DH64CG2F@szxga02-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 18:12:16 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA800JJ44CG26@szxga02-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 18:12:16 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA800K9K4CFYQ@szxml06-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 18:12:16 +0800 (CST) Date: Wed, 13 Oct 2010 18:12:14 +0800 From: Qin Wu To: Colin Perkins Message-id: <041d01cb6abf$1c67e5e0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <066801cb50d1$d3b2d2d0$4f548a0a@china.huawei.com> <030201cb5896$ab249070$4f548a0a@china.huawei.com> <74B2E4DA-7EBC-47FE-BC14-DCC6B9B0F084@csperkins.org> Cc: Roland.Schott@telekom.de, avt@ietf.org Subject: Re: [AVT] Fw: I-D Action:draft-wu-avt-rtcp-xr-quality-monitoring-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 10:11:25 -0000 SGksDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNvbGluIFBlcmtpbnMi IDxjc3BAY3NwZXJraW5zLm9yZz4NClRvOiAiUWluIFd1IiA8c3Vuc2Vhd3FAaHVhd2VpLmNvbT4N CkNjOiA8Um9sYW5kLlNjaG90dEB0ZWxla29tLmRlPjsgPGF2dEBpZXRmLm9yZz4NClNlbnQ6IE1v bmRheSwgT2N0b2JlciAxMSwgMjAxMCA3OjI4IFBNDQpTdWJqZWN0OiBSZTogW0FWVF0gRnc6IEkt RCBBY3Rpb246ZHJhZnQtd3UtYXZ0LXJ0Y3AteHItcXVhbGl0eS1tb25pdG9yaW5nLTAyLnR4dA0K DQoNCk9uIDIwIFNlcCAyMDEwLCBhdCAwODozNywgUWluIFd1IHdyb3RlOg0KPiBIaSwgQ29saW46 DQo+IFRoYW5rIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlcGx5 IGlubGluZS4NCj4NCj4gUmVnYXJkcyENCj4gLVFpbg0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tDQo+IEZyb206ICJDb2xpbiBQZXJraW5zIiA8Y3NwQGNzcGVya2lucy5vcmc+DQo+IFRv OiAiUWluIFd1IiA8c3Vuc2Vhd3FAaHVhd2VpLmNvbT4NCj4gQ2M6IDxhdnRAaWV0Zi5vcmc+OyA8 Um9sYW5kLlNjaG90dEB0ZWxla29tLmRlPg0KPiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxNywg MjAxMCA1OjUwIFBNDQo+IFN1YmplY3Q6IFJlOiBbQVZUXSBGdzogSS1EIEFjdGlvbjpkcmFmdC13 dS1hdnQtcnRjcC14ci1xdWFsaXR5LSANCj4gbW9uaXRvcmluZy0wMi50eHQNCj4NCj4NCj4gSSd2 ZSByZWFkIHRoaXMgZHJhZnQsIGFuZCBoYXZlIHNvbWUgY29tbWVudHMuIEluIGdlbmVyYWwsIEkg dGhpbmsgaXQncw0KPiBvbiB0aGUgcmlnaHQgbGluZXMsIGJ1dCB0aGVyZSBhcmUgYSBudW1iZXIg b2YgZGV0YWlscyB0byBiZSByZXNvbHZlZC4NCj4NCj4gW1Fpbl06IFllcywgeW91IGFyZSByaWdo dC4gVGhlIG1haW4gY2hhbmdlcyB3ZSBtYWRlIGZvciB0aGlzIGRyYWZ0ICANCj4gaXMgdHJ5IHRv IGFsaWduIHdpdGggTW9uaXRvcmluZyBBcmNoaXRlY3R1cmUgZHJhZnQsDQo+IHdoaWNoIG1vcmUg Zm9jdXMgb24gaG93IHRvIGV4dGVuZCBtZXRyaWMgcmVwb3J0IHVzaW5nIFJUQ1AgWFIgZm9yICAN Cj4gbW9uaXRvcmluZyBwdXJwb3NlIGluIHRoZSBsYXRlc3QgdmVyc2lvbi4NCj4NCj4gSW5pdGlh bCBzeW5jaHJvbmlzYXRpb24gZGVsYXk6IG9rYXkNCj4NCj4gQXVkaW8tdmlkZW8gcGxheW91dCBv ZmZzZXQ6IG1ha2VzIHNlbnNlIGluIHByaW5jaXBsZSwgYnV0IGlzIGRlZmluZWQNCj4gaW4gYSB3 YXkgdGhhdJJzIHNwZWNpZmljIHRvIGEgc2ltcGxlIHNjZW5hcmlvIHdpdGggb25lIGF1ZGlvIGFu ZCBvbmUNCj4gdmlkZW8gc3RyZWFtLiBUaGlzIG1heSBiZSBiZXR0ZXIgZGVmaW5lZCBhcyBhIGdl bmVyYWwgc3luY2hyb25pc2F0aW9uDQo+IG9mZnNldCBtZXRyaWMsIHdoaWNoIHJlcG9ydHMgdGhl IG9mZnNldCBvZiB0aGlzIHN0cmVhbSByZWxhdGl2ZSB0bw0KPiBvdGhlciBzdHJlYW1zIHNlbnQg d2l0aCB0aGUgc2FtZSBSVENQIENOQU1FICh3aGVyZSB0aGUgcmVmZXJlbmNlDQo+IHN0cmVhbSBy ZXBvcnRzIG9mZnNldCBvZiB6ZXJvLCBhbmQgdGhlIG90aGVycyBhcmUgc2lnbmVkIG9mZnNldHMN Cj4gcmVsYXRpdmUgdG8gaXQpLiBUaGF0IHdvdWxkIGFsbG93IGl0IHRvIGJlIHVzZWQgdG8gcmVw b3J0IG9uIG1vcmUNCj4gY29tcGxleCBzeW5jaHJvbmlzYXRpb24gc2NlbmFyaW9zLCByYXRoZXIg dGhhbiBkZWZpbmUgb3RoZXIgc2ltaWxhcg0KPiBtZXRyaWNzIGZvciB0aG9zZSBzY2VuYXJpb3Mg bGF0ZXINCj4NCj4gW1Fpbl06IEdvb2Qgc3VnZ2VzdGlvbi4gT25lIGdlbmVyaWMgbWV0cmljIHdp bGwgYmVuZWZpdCBmb3IgYSBsYXJnZSAgDQo+IGJyb2FkIGFwcGxpYXRpb25zLiBpdCBpcyByZWFz b25hYmxlIHRvIHJlcGxhY2UgdGhlIGF1ZGlvLXZpZGVvICANCj4gcGxheW91dCBvZmZzZXQgcmVw b3J0IHdpdGggb25lIG1vcmUgZ2VucmljIHJldXNhYmxlIG1ldHJpYy4gSSB3aWxsICANCj4gZG8g dGhpcyAgaW4gdGhlIG5leHQgdmVyc2lvbi4NCj4NCj4gSW4gdGhlIGxheWVyZWQgc3RyZWFtIHN0 YXRpc3RpY3MgcmVwb3J0IGJsb2NrLCB0aGUgbGF5ZXIgdHlwZSBmbGFnIGlzDQo+IHBocmFzZWQg aW4gdGVybXMgb2YgSC4yNjQgU1ZDIHZpZGVvLCBidXQgdGhlcmUgaXMgbm90aGluZyBwYXJ0aWN1 bGFybHkNCj4gU1ZDLXNwZWNpZmljIGhlcmUuIENhbiBpdCBiZSB3cml0dGVuIGluIGEgbW9yZSBn ZW5lcmFsIHdheSwganVzdA0KPiBzcGVjaWZ5aW5nIGJhc2UgYW5kIGVuaGFuY2VtZW50IGxheWVy cywgc28gdGhlIHNhbWUgbWV0cmljIGNhbiBiZSB1c2VkDQo+IGZvciBvdGhlciBsYXllcmVkIGNv ZGVjcz8NCj4NCj4gW1Fpbl06IEkgYW0gbm90IHN1cmUgd2hldGhlciB3ZSBuZWVkIG1vcmUgZmlu ZWx5IGdyYW51bGFyaXR5IG9mICANCj4gZW5jaGFuY2VtZW50IGxheWVycyB0byBkaXN0aW5ndWlz aCBvbmUgZW5oYW5jbWVudCBsYXllciBmcm9tIGluICANCj4gb3RoZXIgbGF5ZXJlZCBjb2RlY3Mg SXMgaXQgcmVhc29uYWJsZSB0byBvbmx5IHNwZWNpZnkgYmFzZSBhbmQgIA0KPiBlbmhhbmNtZW50 IGxheWVycz8NCg0KUHJvYmFibHkgLSBkZXBlbmRzIG9uIHlvdXIgdXNlIGNhc2UuDQoNCltRaW5d OiBBY2NlcHRlZC4NCg0KPiBJdJJzIG5vdCBjbGVhciB0aGF0IHRoZSBsb3NzIGFuZCBkdXBsaWNh dGUgcmVwb3J0cyBuZWVkIHRvIGJlIG9wdGlvbmFsDQo+IGluIHRoZSBsYXllcmVkIHN0cmVhbXMg c3RhdGlzdGljcyBtZXRyaWMgYmxvY2suIFRoZXkgYXJlIHN0cmFpZ2h0DQo+IGZvcndhcmQgdG8g Y2FsY3VsYXRlLCBhbmQgbWFraW5nIHRoZW0gb3B0aW9uYWwgc2VlbXMgdG8gb25seSBpbnRyb2R1 Y2UNCj4gdW5uZWNlc3NhcnkgY29tcGxleGl0eSBpbnRvIHRoZSBwcm90b2NvbC4gU2ltaWxhciBm b3IgdGhlIHZpZGVvDQo+IHN0YXRpc3RpY3Mgc3VtbWFyeSByZXBvcnQgYmxvY2suDQo+DQo+IFtR aW5dIEdvb2QgcG9pbnQuIEl0IHNlZW1zIHRoZXNlIHR3byBpbmRpY2F0aW9uIGZpZWxkcyBmb3Ig bG9zcyBhbmQgIA0KPiBkdXBsaWNhdGlvbiBhcmUNCj4gb3Zlci1kZXNpZ25lZCwgSSB3aWxsIHJl bW92ZSB0aGVtIGluIHRoZSBuZXcgdmVyc2lvbi4NCj4NCj4gVGhlIGRlZmluaXRpb24gb2YgdGhl IGxvc3RfbGF5ZXJlZCBjb21wb25lbnQgcGFja2V0cyBhbmQgZHVwX2xheWVyZWQNCj4gY29tcG9u ZW50IHBhY2tldHMgaXMgdW5kZXItc3BlY2lmaWVkLg0KPg0KPiBbUWluXTogT2theSwgdGhhbmsg Zm9yIGNhdGNoaW5nIHRoaXMuIHdlIHdpbGwgc3BlY2lmeSB0aGlzIGluIHRoZSAgDQo+IG5ldyB2 ZXJzaW9uLg0KPg0KPiBJcyB0aGUgZnJhbWUgdHlwZSBpbmRpY2F0b3IgZmllbGQgdXNlZCBpbiB0 aGUgdmlkZW8gc3RhdGlzdGljcyByZXBvcnQNCj4gYmxvY2sgYW5kIHRoZSB2aWRlbyBzdHJlYW0g bG9zcyBhbmQgZGlzY2FyZCBtZXRyaWNzIGJsb2NrIHdlbGwNCj4gZGVmaW5lZD8gVGhlIGNoYXJh Y3RlcmlzYXRpb24gb2YgdmlkZW8gZnJhbWVzIGludG8gSSwgUCwgYW5kIEIgZnJhbWVzDQo+IG1h a2VzIHNlbnNlIGZvciBNUEVHLTIsIGJ1dCBpcyBpdCBhcHByb3ByaWF0ZSBmb3Igb3RoZXIgY29k ZWNzPw0KPg0KPiBbUWluXTogSSB0aGluayBjbGFzc2lmeWluZyB2aWRlbyBtZWRpYSBpbnRvICBJ LCBQIGFuZCBmcmFtZXMgYWxzbyAgDQo+IHdvcmtzIGZvciBNUEVHLTQsIGJ1dCB0aGV5IG1heSB0 YWtlIHRoZSBkaWZmZXJlbnQgbmFtZSBsaWtlDQo+IEktVk9QLCBCLVZPUCBhbmQgUC1WT1AsIGZv ciB0aGUgb3RoZXIgdmlkZW8gQ29kZWMgbGlrZSBWNiwgaXQgYWxzbyAgDQo+IGNoYXJhY3Rlcml6 ZSB0aGUgdmlkZW8gaW50byBkaWZmZXJlbnQgcGljdHVyZSB0eXBlcyBsaWtlIEkgYW5kIFAuDQo+ DQo+IFRoZXJlZm9yZSBtYXkgSSBwcm9wb3NlIHRvIHVzZSAga2V5IGZyYW1lIGFuZCByZWZlcmVu Y2UgZnJhbWUgdG8gIA0KPiByZXBsYWNlIEksUCwgYW5kIEIgZnJhbWVzLCB3aGljaCBpcyBtb3Jl IGdlbmVyaWMgYW5kIGNhbiBiZSB1c2VkIHRvICANCj4gZGlzdGluZ3Vpc2ggZGlmZmVyZW50IHBp Y3R1cmUgdHlwZXMuDQoNCkkgbGlrZSB0aGUgaWRlYSwgYnV0IEknbSBub3Qgc3VyZSB0aGF0IHRl cm1pbm9sb2d5IGlzIGNsZWFyZXIuDQoNCltRaW5dOiBPa2F5LCB3aWxsIGFkZCBuZXcgdGVybWlu b2xvZ3kgdG8gY2xhcmlmeSB0aGlzLg0KDQo+IFVubGlrZSB0aGUgb3RoZXIgbWV0cmljcywgdGhl IFRSIDEwMSAyOTAgZGVjb2RhYmlsaXR5IG1ldHJpY3MgcmVwb3J0DQo+IGJsb2NrIGlzIGVudGly ZWx5IE1QRUctMiBzcGVjaWZpYy4gSSBzdWdnZXN0IHNwbGl0dGluZyB0aGlzIGludG8gYQ0KPiBz ZXBhcmF0ZSBkcmFmdCwgc2luY2UgaXQgZG9lc26SdCByZWFsbHkgcmVsYXRlIHRvIHRoZSBvdGhl ciBtZXRyaWNzDQo+IGRlZmluZWQgaW4gdGhpcyBkcmFmdC4NCj4NCj4gW1Fpbl06IEkgYW0gbm90 IHN1cmUgd2hldGhlciB3ZSBzaG91bGQgbGVhdmUgVFIxMDEgMjkwIGRlY29kYWJpbGl0eSAgDQo+ IG1ldHJpY3Mgb3V0IGZyb20gdGhpcyBkcmFmdC4gQnV0IEkgdGhpbmsgdGhpcyBtZXRyaWNzIGNv dWxkIGJlIHRha2VuICANCj4gYXMgb25lIG9mIGlucHV0IHRvIGNhbGN1bGF0ZSB0aGUgTU9TLVYg d2hpY2ggcmVmbGVjdHMgdGhlIE1QRUctMiAgDQo+IG1lZGlhIHF1YWxpdHkgaW4gc29tZSB3YXku DQoNClllcywgYnV0IHRoYXQgZG9lc24ndCBtZWFuIHRoZXkgbmVlZCB0byBiZSBzcGVjaWZpZWQg aW4gdGhpcyBkcmFmdC4gQXMgIA0KSSBzYWlkIGJlZm9yZSwgdGhpcyBpcyBlbnRpcmVseSBNUEVH LTIgc3BlY2lmaWMsIGFuZCBzbyB3b3VsZCBiZSAgDQpiZXR0ZXIgaWYgc3VibWl0dGVkIGFzIGEg c2VwYXJhdGUgZHJhZnQsIHVucmVsYXRlZCB0byB0aGlzIFJUUC1sZXZlbCAgDQptZXRyaWNzIGRy YWZ0Lg0KDQpbUWluXTogT2theS4NCg0KPiBUaGUgUlRQIFRlcm1pbmFsIENvbmZpZ3VyYXRpb24g TWV0cmljcyBCbG9jayBzZWVtcyBpbGwtdGhvdWdodCBvdXQuDQo+IFRoZSBQTEMgdHlwZSBmaWVs ZCBkb2VzbpJ0IHNlZW0gYXBwcm9wcmlhdGUgdG8gdmlkZW8gLSB0aGUgZGVmaW5pdGlvbg0KPiBs b29rcyB0byBiZSBjb3BpZWQgZnJvbSBhbiBhdWRpbyBtZXRyaWNzIGRyYWZ0LiBUaGUgSkJBIGZp ZWxkIGlzIGlsbC0NCj4gZGVmaW5lZCwgYW5kIGRvZXNuknQgZ2l2ZSBtZWFuaW5nZnVsIGluZm9y bWF0aW9uLiBUaGUgRkVDIGZpZWxkIGlzDQo+IHZlcnkgbGltaXRlZCwgYW5kIHRvbyB0aWVkIHRv IHBhcnRpY3VsYXIgRkVDIHNjaGVtZXMgaW4gYSB3YXkgdGhhdCBpcw0KPiBub3QgZGVzaXJhYmxl OiB0aGUgbWVkaWEgdHlwZXMgbmFtZXNwYWNlIHNob3VsZCBiZSB1c2VkIGhlcmUsIHJhdGhlcg0K PiB0aGFuIGRlZmluaW5nIGEgbmV3LCB2ZXJ5IGxpbWl0ZWQsIHR3by1iaXQgZmllbGQsIGlmIHlv dSBuZWVkIHRvIGRvDQo+IHRoaXMgYXQgYWxsLiBJdCdzIG5vdCBjbGVhciB0aGF0IHRoaXMgaW5m b3JtYXRpb24gc2hvdWxkIGJlIHJlcG9ydGVkDQo+IGluIFJUQ1AsIHNpbmNlIHRoZSBzYW1lIGlu Zm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBpbiB0aGUgU0RQIHNpZ25hbGxpbmcNCj4gY2hhbm5lbC4N Cj4NCj4gW1Fpbl06IEkgYWdyZWUgdGhlIHBhcmFtZXRlcnMgZGVmaW5lZCBpbiB0aGlzIG1ldHJp Y3MgY2FuIGJlICANCj4gb2J0YWluZWQgaW4gdGhlIFNEUCBzaWduYWxpbmcuIEl0IHNlZW1zIHRo aXMgVGVybWluYWwgcmVsYXRlZCAgDQo+IG1ldHJpY3MgbG9va3MgbGlrZSBhIGV2aWwuIDotKSBC dXQgd2hhdCBJIGxpa2UgdG8gYXJndWUgYWJvdXQgaXMgIA0KPiBkaWZmZXJlbnQgdHlwZSBvZiB0 ZXJtaW5hbCB3aXRoIGRpZmZlcm50IGNhcGFiaWxpdHkgbWF5IGRlbW9uc3RyYXRlICANCj4gZGlm ZmVyZW50IHJlY2VwdGlvbiBxdWFsaXR5IHRvIHRoZSB1c2Vycy4gQXJlIHdlIGF3YXJlIG9mIHRo YXQ/ICANCj4gSXNuJ3QgdmFsdWFibGUgdG8gdGFrZSB0aGlzIHRlcm1pbmFsIGFzc29jaWF0ZWQg bWV0cmljcyBpbnRvICBhY2NvdXQgIA0KPiB3aGVuIHdlIGV2YWx1YXRlIHRoZSBtZWRpYSBxdWFs aXR5IGluIHRoZSBjb21wcmVoZW5zaXZlIHdheT8NCg0KDQpTdXJlLCBidXQgdGhlIGluZm9ybWF0 aW9uIGlzIGFscmVhZHkgYXZhaWxhYmxlLCBhbmQgZG9lc24ndCBuZWVkIHRvIGJlICANCmR1cGxp Y2F0ZWQgaGVyZS4NCg0KW1Fpbl06IE9rYXkuDQoNCi0tIA0KQ29saW4gUGVya2lucw0KaHR0cDov L2NzcGVya2lucy5vcmcvDQoNCg0K From sunseawq@huawei.com Wed Oct 13 04:37:58 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B3C3A6A05 for ; Wed, 13 Oct 2010 04:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5quPbyd8xT3q for ; Wed, 13 Oct 2010 04:37:57 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2277B3A69EB for ; Wed, 13 Oct 2010 04:37:57 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA800AS98D2JS@szxga03-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 19:39:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA800C5A8D2FK@szxga03-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 19:39:02 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA800E7X8D2HT@szxml04-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 19:39:02 +0800 (CST) Date: Wed, 13 Oct 2010 19:39:02 +0800 From: Qin Wu To: Colin Perkins Message-id: <04e201cb6acb$3c066af0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <03b601cb5ed9$cd35f250$4f548a0a@china.huawei.com> Cc: Roland.Schott@telekom.de, avt@ietf.org Subject: Re: [AVT] Fw: I-D Action:draft-wu-avt-rtcp-xr-quality-monitoring-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 11:37:58 -0000 SGksOg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJDb2xpbiBQZXJraW5z IiA8Y3NwQGNzcGVya2lucy5vcmc+DQpUbzogIlFpbiBXdSIgPHN1bnNlYXdxQGh1YXdlaS5jb20+ DQpDYzogPGF2dEBpZXRmLm9yZz47IDxSb2xhbmQuU2Nob3R0QHRlbGVrb20uZGU+DQpTZW50OiBU aHVyc2RheSwgT2N0b2JlciAwNywgMjAxMCA3OjU2IFBNDQpTdWJqZWN0OiBSZTogW0FWVF0gRnc6 IEktRCBBY3Rpb246ZHJhZnQtd3UtYXZ0LXJ0Y3AteHItcXVhbGl0eS1tb25pdG9yaW5nLTAzLnR4 dA0KDQoNClFpbiwNCg0KVGhlc2UgY2hhbmdlcyBnZW5lcmFsbHkgbG9vayBnb29kLCBidXQgSSBk byBzdGlsbCBoYXZlIHNvbWUgY29tbWVudHM6DQoNCi0gU2VjdGlvbiA0LjIgaGFzIGJlZW4gcmV3 cml0dGVuIGFzIGEgR2VuZXJhbCBTeW5jaHJvbmlzYXRpb24gT2Zmc2V0ICANCk1ldHJpY3MgQmxv Y2suIFRoaXMgaXMgYSBnb29kIGRpcmVjdGlvbiwgYnV0IHRoZSByZXN1bHRpbmcgdGV4dCBzdGls bCAgDQphc3N1bWVzIHRoYXQgb25seSB0d28gc3RyZWFtcyBleGlzdC4gSW4gYW4gUlRQIG11bHRp bWVkaWEgc2Vzc2lvbiAgDQp0aGVyZSBjYW4gYmUgYW4gYXJiaXRyYXJ5IG51bWJlciBvZiBzdHJl YW1zLCB3aXRoIHRoZSBzYW1lIFJUQ1AgQ05BTUUsICANCm5vdCBqdXN0IHR3by4gSSB3b3VsZCBz dWdnZXN0IHRoYXQgdGhpcyBibG9jayBiZSB3cml0dGVuIHN1Y2ggdGhhdCBvbmUgIA0Kc3RyZWFt IHJlcG9ydHMgYSBHZW5lcmFsIFN5bmNocm9uaXNhdGlvbiBPZmZzZXQgb2YgemVybywgYW5kIG90 aGVyICANCnN0cmVhbXMgd2l0aCB0aGUgc2FtZSBSVENQIENOQU1FIHJlcG9ydCB0aGVpciBvZmZz ZXQgcmVsYXRpdmUgdG8gdGhhdC4gIA0KTm90ZSB0aGF0IHRoZSBzdHJlYW1zIGJlaW5nIHN5bmNo cm9uaXNlZCBhcmUgbm90IG5lY2Vzc2FyaWx5IGF1ZGlvIGFuZCAgDQp2aWRlbyBzdHJlYW1zLg0K DQpbUWluXTogR29vZCBwb2ludCwgSSB3aWxsIGFkZCBzb21lIHRleHQgdG8gdGhlIGRvY3VtZW50 IHRvIGZpeCB0aGlzIGlzc3VlLg0KDQotIFNlY3Rpb24gNS4xIHVwZGF0ZXMgdGhlIGRlZmluaXRp b24gb2YgdGhlIEZyYW1lIFR5cGUgSW5kaWNhdG9yIHRvIGJlICANCmEgUGljdHVyZSBUeXBlIElu ZGljYXRvci4gVGhlIGludGVudCBvZiB0aGUgbmV3IGRlZmluaXRpb24gaXMgb2theSwgIA0KYnV0 IHRoZSB0ZXh0IGlzIHZlcnkgdW5jbGVhci4gQ2FuIHlvdSBjbGFyaWZ5PyAoc2FtZSBpc3N1ZSBs YXRlcikNCg0KW1Fpbl06IFllcywgSSB3aWxsIGZpeCB0aGlzIGJ5IGFkZGluZyBvbmUgbmV3IGRl ZmludGlvbiBvZiBQaWN0dXJlIFR5cGUuDQpJbnN0ZWFkIG9mIGRpc3Rpbmd1aXNoaW5nIGZyYW1l IGFzIEksIFAsIEIgZnJhbWUsIEkgd2lsbCBjbGFzc2lmeSB0aGUgcGljdHVyZQ0KdHlwZSB1c2Vk IGluIHRoZSBkaWZmZXJlbnQgdmlkZW8gYWxnb3JpdGhtIGludG8ga2V5IGZyYW1lcyBhbmQgZGVy aXZhdGlvbiBmcmFtZS4NCmtleSBmcmFtZSB3aWxsIGJlIHVzZWQgYXMgYSByZWZlcmVuY2UgZm9y IHByZWRpY3Rpbmcgb3RoZXIgcGljdHVyZXMgd2hpbGUgZGVyaXZhdGlvbiBmcmFtZQ0Kd2lsbCBk ZXJpdmVkIGZyb20gS2V5LWZyYW1lLiBEb2VzIGl0IG1ha2Ugc2Vuc2U/DQoNCi0gVW5saWtlIHRo ZSBvdGhlciBtZXRyaWNzLCB0aGUgVFIgMTAxIDI5MCBkZWNvZGFiaWxpdHkgbWV0cmljcyByZXBv cnQgIA0KYmxvY2sgaXMgZW50aXJlbHkgTVBFRy0yIHNwZWNpZmljLiBJIHN1Z2dlc3Qgc3BsaXR0 aW5nIHRoaXMgaW50byBhICANCnNlcGFyYXRlIGRyYWZ0LCBzaW5jZSBpdCBkb2VzbpJ0IHJlYWxs eSByZWxhdGUgdG8gdGhlIG90aGVyIG1ldHJpY3MgIA0KZGVmaW5lZCBpbiB0aGlzIGRyYWZ0Lg0K DQpbUWluXTogT2theS4NCg0KQ29saW4NCg0KDQoNCk9uIDI4IFNlcCAyMDEwLCBhdCAwNzo1Mywg UWluIFd1IHdyb3RlOg0KPiBIaSwNCj4gVGhlIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LXd1LWF2dC1y dGNwLXhyLXF1YWxpdHktbW9uaXRvcmluZy0wMyBpcyAgDQo+IGF2YWlsYWJsZSBhdDoNCj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3UtYXZ0LXJ0Y3AteHItcXVh bGl0eS1tb25pdG9yaW5nLTAzLnR4dA0KPiB3aGljaCBwcm9iYWJseSBhZGRyZXNzIHRoZSBjb21t ZW50cyBlYXJseSByZWNlaXZlZCBvbiB0aGUgbGlzdC4NCj4gWW91ciBmdXJ0aGVyIGNvbW1lbnRz IGFuZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZSENCj4NCj4gUmVnYXJkcyENCj4gLVFpbg0KPiAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206IDxJbnRlcm5ldC1EcmFmdHNAaWV0 Zi5vcmc+DQo+IFRvOiA8aS1kLWFubm91bmNlQGlldGYub3JnPg0KPiBTZW50OiBUdWVzZGF5LCBT ZXB0ZW1iZXIgMjgsIDIwMTAgMjoxNSBQTQ0KPiBTdWJqZWN0OiBJLUQgQWN0aW9uOmRyYWZ0LXd1 LWF2dC1ydGNwLXhyLXF1YWxpdHktbW9uaXRvcmluZy0wMy50eHQNCj4NCj4NCj4+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyAgDQo+PiBkaXJlY3Rvcmllcy4NCj4+DQo+PiBUaXRsZSAgICAgICAgICAgOiBSVFAgQ29udHJv bCBQcm90b2NvbCBFeHRlbmRlZCBSZXBvcnRzIChSVENQIFhSKSAgDQo+PiBSZXBvcnQgQmxvY2tz IGZvciBSZWFsLSB0aW1lIFZpZGVvIFF1YWxpdHkgTW9uaXRvcmluZw0KPj4gQXV0aG9yKHMpICAg ICAgIDogVy4gV3UsIGV0IGFsLg0KPj4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQtd3UtYXZ0LXJ0 Y3AteHItcXVhbGl0eS1tb25pdG9yaW5nLTAzLnR4dA0KPj4gUGFnZXMgICAgICAgICAgIDogMjYN Cj4+IERhdGUgICAgICAgICAgICA6IDIwMTAtMDktMjcNCj4+DQo+PiBUaGlzIGRvY3VtZW50IGRl ZmluZXMgYSBzZXQgb2YgUlRQIENvbnRyb2wgUHJvdG9jb2wgRXh0ZW5kZWQgUmVwb3J0cw0KPj4g KFJUQ1AgWFIpIFJlcG9ydCBCbG9ja3MgYW5kIGFzc29jaWF0ZWQgU0RQIHBhcmFtZXRlcnMgYWxs b3dpbmcgdGhlDQo+PiByZXBvcnQgb2YgdmlkZW8gcXVhbGl0eSBtZXRyaWNzLCBwcmltYXJpbHkg Zm9yIHZpZGVvIGFwcGxpY2F0aW9ucyBvZg0KPj4gUlRQLg0KPj4NCj4+IEEgVVJMIGZvciB0aGlz IEludGVybmV0LURyYWZ0IGlzOg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtd3UtYXZ0LXJ0Y3AteHItcXVhbGl0eS1tb25pdG9yaW5nLTAzLnR4dA0KDQoNCi0t IA0KQ29saW4gUGVya2lucw0KaHR0cDovL2NzcGVya2lucy5vcmcvDQoNCg0K From ray.vanbrandenburg@tno.nl Wed Oct 13 04:53:02 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D083A6938 for ; Wed, 13 Oct 2010 04:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSquNqFEGx6J for ; Wed, 13 Oct 2010 04:53:00 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 319693A6A05 for ; Wed, 13 Oct 2010 04:53:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,325,1283724000"; d="scan'208";a="10277653" Received: from ms-dt01thalia.tno.nl (HELO ms-dt01thalia.tsn.tno.nl) ([134.221.225.157]) by mailhost1b.tno.nl with ESMTP; 13 Oct 2010 13:54:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Oct 2010 13:54:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [AVT] New Version Notification for draft-brandenburg-avt-rtcp-for-idms-02 Thread-Index: ActqBt9LAige+0fVQCeB3foz4CzldQAxeHmQ From: "Brandenburg, R. (Ray) van" To: "Roni Even" , "DRAGE, Keith (Keith)" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-brandenburg-avt-rtcp-for-idms-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 11:53:02 -0000 =20 Hi Roni, Keith, As AVT chairs, what is your opinion on this? In other words, what role do y= ou think AVT can/should play in this?=20 If it helps, I'm planning to attend the upcoming IETF meeting in Beijing an= d would be willing to give a short introduction into IDMS and the proposed = XR block.=20 Ray van Brandenburg -----Original Message----- From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 Sent: dinsdag 12 oktober 2010 14:13 To: Brandenburg, R. (Ray) van Cc: avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-brandenburg-avt-rtcp-= for-idms-02 Hi Ray, That makes sense to me but I will defer to the AVT chairs w.r.t. the ETSI i= nteraction... Peter Musgrave On Tue, Oct 12, 2010 at 3:47 AM, Brandenburg, R. (Ray) van wrote: > Hi Peter, > > Thanks for your comments. > >> >> Should the relationship of this doc to ETSI TISPAN be mentioned in=20 >> the Abstract? > > > I agree and will add this in the next version. While we're on the subject: > the main reason we have brought this work to the IETF is because we=20 > feel the AVT WG should be the place where XR blocks are specified. If=20 > there is enough interest around here, one option could be to have the=20 > AVT WG take the lead on the standardization of this XR block, either=20 > as an informational or standards track document. The relevant sections=20 > of the ETSI TISPAN=A0spec could then reference the resulting RFC.=A0How d= o you feel about this? > > Regards, > > Ray van Brandenburg > > > > ________________________________ > From: Ishan Vaishnavi [mailto:ishan.vaishnavi@gmail.com] > Sent: maandag 11 oktober 2010 17:40 > To: Peter Musgrave > Cc: Brandenburg, R. (Ray) van; avt@ietf.org > Subject: Re: [AVT] New Version Notification for > draft-brandenburg-avt-rtcp-for-idms-02 > > Hi Peter, > Thanks for taking time to review this document. Find my comments inline. > Cheers, > Ishan > > > >> >> I lack background in the IDMS application. =A0Is the Boronat2009=20 >> reference available online anywhere? > > You need either an Elsevier account or a Science Direct one. Here is=20 > the link. Hope that helps. > >> >> (I am interested in whether there >> are separate XRs for audio and video and how the lipsync alignment=20 >> issues are handled within the overall synchronization strategy). >> > > In my opinion lip synchronization is somewhat out of the scope of this=20 > document. The idea is that each distributed client reports its=20 > play-out position of its "primary" stream. This primary stream can be=20 > a virtual stream or a real audio, video, subtitles or images for that=20 > matter. =A0All other streams locally on each client synchronize to that=20 > stream, this must be done by the respective application. The current=20 > XR specification relates to how to get these primary streams are=20 > synchronized across different geographically separated clients. Maybe=20 > it can be extended to include this local synchronization as well, but tha= t's another discussion. > >> >> Should the relationship of this doc to ETSI TISPAN be mentioned in=20 >> the Abstract? > > I will leave this one for Ray. > > > This e-mail and its contents are subject to the DISCLAIMER at=20 > http://www.tno.nl/disclaimer/email.html > This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From sunseawq@huawei.com Wed Oct 13 05:32:50 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDC53A6AC9 for ; Wed, 13 Oct 2010 05:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.077 X-Spam-Level: X-Spam-Status: No, score=0.077 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys4gI1+VrXD9 for ; Wed, 13 Oct 2010 05:32:44 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id BF7B93A6AF5 for ; Wed, 13 Oct 2010 05:32:32 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA800HN7AU6Q0@szxga01-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 20:32:30 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA800F9FAU63S@szxga01-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 20:32:30 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA800B7YAU6GT@szxml06-in.huawei.com> for avt@ietf.org; Wed, 13 Oct 2010 20:32:30 +0800 (CST) Date: Wed, 13 Oct 2010 20:32:30 +0800 From: Qin Wu To: avt@ietf.org Message-id: <057f01cb6ad2$b3e86760$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [AVT] Fw: New Version Notification for draft-wu-avt-rtcp-xr-quality-monitoring-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 12:32:50 -0000 Hi, folks: 04 version is posted which addresses the comments from Colin * Add some text to General Synchronisation Offset Metrics Block to allow more than two stream in the RTP multimedia session. * Clarify the Picture Type in the terminology section * Separate TR 101 290 decodability metrics report from this draft Your comments and suggestions are welcome! Regards! -Qin ----- Original Message ----- From: "IETF I-D Submission Tool" To: Cc: ; Sent: Wednesday, October 13, 2010 8:16 PM Subject: New Version Notification for draft-wu-avt-rtcp-xr-quality-monitoring-04 > > A new version of I-D, draft-wu-avt-rtcp-xr-quality-monitoring-04.txt has been successfully submitted by Wenson Wu and posted to the IETF repository. > > Filename: draft-wu-avt-rtcp-xr-quality-monitoring > Revision: 04 > Title: RTP Control Protocol Extended Reports (RTCP XR) Report Blocks for Real- time Video Quality Monitoring > Creation_date: 2010-10-13 > WG ID: Independent Submission > Number_of_pages: 22 > > Abstract: > This document defines a set of RTP Control Protocol Extended Reports > (RTCP XR) Report Blocks and associated SDP parameters allowing the > report of video quality metrics, primarily for video applications of > RTP. > > > > The IETF Secretariat. > > From Even.roni@huawei.com Wed Oct 13 13:38:22 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4F63A69AB for ; Wed, 13 Oct 2010 13:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.529 X-Spam-Level: X-Spam-Status: No, score=-99.529 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrSJc4sfR1Gr for ; Wed, 13 Oct 2010 13:38:21 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 07B393A696C for ; Wed, 13 Oct 2010 13:38:21 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA800AXMXDRJT@szxga03-in.huawei.com> for avt@ietf.org; Thu, 14 Oct 2010 04:39:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA800L09XDRJT@szxga03-in.huawei.com> for avt@ietf.org; Thu, 14 Oct 2010 04:39:27 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-39-236.red.bezeqint.net [79.183.39.236]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA800I2DXDKMF@szxml02-in.huawei.com> for avt@ietf.org; Thu, 14 Oct 2010 04:39:27 +0800 (CST) Date: Wed, 13 Oct 2010 22:36:39 +0200 From: Roni Even To: avt@ietf.org Message-id: <00c101cb6b16$5be8b120$13ba1360$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_VqnupK+PGH4+DRo/5RyX1A)" Content-language: en-us Thread-index: ActrFlTjh1qq/hNXT4iwji3f/xPGnA== Subject: [AVT] AVT sessions in Beijing - update X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 20:38:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_VqnupK+PGH4+DRo/5RyX1A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, This is the new schedule for AVT in Beijing Note that the second slot is on Thursday AVT Session 1 Monday, Afternoon Session I 1300-1500 Room Name: Valley Ballroom B ---------------------------------------------- AVT Session 2 Thursday, Afternoon Session I 1300-1500 Room Name: Garden Ballroom 1 ---------------------------------------------- Roni Even --Boundary_(ID_VqnupK+PGH4+DRo/5RyX1A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

This is the new schedule for AVT in = Beijing

Note that the second slot is on = Thursday

 

 

AVT Session 1 Monday,

Afternoon Session I 1300-1500

Room Name: Valley Ballroom B

----------------------------------------------<= /o:p>

AVT Session 2 Thursday,

Afternoon Session I 1300-1500

Room Name: Garden Ballroom 1

----------------------------------------------<= /o:p>

 

Roni Even

--Boundary_(ID_VqnupK+PGH4+DRo/5RyX1A)-- From tom.van_caenegem@alcatel-lucent.com Thu Oct 14 04:06:02 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469263A68E9 for ; Thu, 14 Oct 2010 04:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.881 X-Spam-Level: X-Spam-Status: No, score=-4.881 tagged_above=-999 required=5 tests=[AWL=1.368, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4u4Q0BZGRgl for ; Thu, 14 Oct 2010 04:06:00 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 6CD483A68B7 for ; Thu, 14 Oct 2010 04:05:59 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9EB2nhu011335 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 Oct 2010 13:07:09 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 14 Oct 2010 13:06:40 +0200 From: "Van Caenegem, Tom (Tom)" To: Roni Even , "'Qin Wu'" , "avt@ietf.org" Date: Thu, 14 Oct 2010 13:06:38 +0200 Thread-Topic: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 Thread-Index: ActnbV+R7zcHxWCTQUi0E0Q1YZ0jUQCrQ7bAAAGRh+AAWeCEYA== Message-ID: References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> <015e01cb6a23$1da20c70$58e62550$%roni@huawei.com> In-Reply-To: <015e01cb6a23$1da20c70$58e62550$%roni@huawei.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 11:06:02 -0000 Roni, thanks for your clarifying comments. See below.=20 -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: dinsdag 12 oktober 2010 17:35 To: Van Caenegem, Tom (Tom); 'Qin Wu'; avt@ietf.org Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission= -supression-rtp-03 Hi Tom, The semantics of sending NACK from the sender is not defined in RFC 4585. W= e could add the sender semantics to NACK but the consensus so far was to us= e a new message and not add new semantics to NACK. Note that the use of the= message is not only for NACK suppression. TOM: can you give me a pointer to where that concensus was reached, includi= ng the rationale? I must have missed it. See inline Roni > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of=20 > Van Caenegem, Tom (Tom) > Sent: Tuesday, October 12, 2010 4:35 PM > To: Qin Wu; avt@ietf.org > Subject: Re: [AVT] New Version Notification for draft-wu-avt- > retransmission-supression-rtp-03 >=20 > Hi Qin, >=20 > these are my comments on the draft 3 version: >=20 > -you know of course that DVB IPTV has defined a solution to addres=20 > NACK storms. This solution was recently also adopted by OIPF. You=20 > propose to define a new dedicated message for NACK suppression,=20 > whereas in DVB/OIPF we defined that when an RTP receiver gets such a=20 > NACK message, this receiver should not send a NACK itself (provided=20 > the NACK was received before the receiver sends its own NACK). In a=20 > similar way, this could also be defined for FIR messages. I have no=20 > fundamental problem if AVT decides to define a dedicated message, but=20 > can you provide arguments why a NACK sent by the distribution=20 > source/translator in a SSM to the client is not good enough for=20 > imposing NACK suppression to a receiver, by definition? >=20 > -a general comment: suppressing NACKs from receivers is a very tricky=20 > thing. Sometimes it may do more harm than do any good, and I feel this=20 > discussion and possible negative impact is not really addressed in=20 > this draft. I am not sure what you mean here. The receivers do not suppress NACKs, the = NACK suppression is sent by intermediary devices. TOM: Sure. The draft basically specifies the Suppression message. But in te= rms of intermediate source/receiver behaviour, my read-out is as follows:=20 1)a intermediate source can send at any time a NACK suppression 2)there is no normative language for the receiver what to do when this mess= age is received In the text, the intermediate source seems to rely on a NACK from a "loss r= eporter" for sending NACK suppression messages. Is this some kind of truste= d device? Can it always be guaranteed that the packets this loss reporter r= eceives or does not receive, are the same packets received/not received for= all receivers that get the NACK suppression (and optional the retransmissi= on afterwards)? Why would a receiver not systematically send the NACK anyho= w -even if it does understand the suppression message, to maximise its chan= ce of getting a retransmission.. This is the kind of discussion that should= be included IMO. >=20 > -in your figure 1, the SSM is sourced by the intermediate source which=20 > hosts the feedback target and a "loss reporter". This does not=20 > represent a realistic architecture as it would mean that for IPTV=20 > scenario the head-end receives all RTCP messages from all receivers. > You should include architectures where FT are decoupled from the SSM=20 > source. This is not IPTV specific feature so this is an example. There can be other= cases. TOM: The (only) figure in the draft (entitled "system architecture") shows = that the "intermediate source" is sourcing the SSM, hence is also the distr= ibution source. The draft is also explicit about this as it says: "The inte= rmediate source must be able to communicate with all group members in order= for either mechanism to be effective at suppressing feedback"=20 This means that scenarios/architectures as addressed with RAMS (where the B= RS is co-located with the FT which is in general separate from the DS) are = outside the scope of this work? >=20 > -the definition of the "loss reporter" is somewhat obscure to me. From=20 > various text fragments, it appears that a (NACK) FB message sent by=20 > the loss reporter, will result in the intermediate source/distribution=20 > source sending a NACK storm suppression or FFS message to the clients=20 > in the group. This means to me that any packet loss reported by the=20 > "loss reporter" is packet loss that will impact all receivers=20 > downstream of the intermediate/distribution source. If this is not the=20 > case, you will provide unneeded retransmissions. Is this a correct=20 > interpretation? If so, please make this clear in the definition of=20 > "loss reporter". If it is not, then mandating that getting a NACK from=20 > a loss reporter results in a FFS message, is not recommended IMO. The draft only says the intermediate device will send NACK suppression and = leaves open the application behavior in the upstream side. The discussion s= o far suggested that it should be out of scope for the draft. TOM: My remark here was about the "loss reporter" concept, not about how -"= plain normal"- receivers should respond on the NACK suppression message. As= written above, the draft's architecture in which you position the NACK sup= pression seems restricted and not covering RAMS architecture. >=20 > -I do not understand why a "loss reporter" MUST not receive the FFS=20 > message -which is meant to be sent on the SSM-, and I also do not get=20 > how you can avoid that the "loss reporter" would receive this FFS=20 > message, as a "loss reporter" that is downstream of the intermediate=20 > source must be receiving the SSM in order to detect missing packets. >=20 > -you introduce the "immediate reporting RTP client" terminology from=20 > the DVB IPTV spec that is referenced, but its definition does not=20 > align with how it is defined in the DVB spec. So, please, either=20 > stick to the DVB definition or use a different term. TOM: I hope above two comments will be addressed and further discussed as w= ell, and I have another question: the draft defines how one can signal in S= DP, support for the NACK suppression. Is that for SDP to be received by th= e RTP receivers? If so, why must that be declared in the SDP? Thx Tom >=20 > Regards > Tom >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of=20 > Qin Wu > Sent: zaterdag 9 oktober 2010 6:49 > To: avt@ietf.org > Subject: [AVT] New Version Notification for draft-wu-avt- > retransmission-supression-rtp-03 >=20 > Folks, >=20 > We have updated draft-wu-avt-retransmission-suppression-rtp which=20 > should now reflect the discussion we had since IETF78. >=20 > The feedback suppression solution has also been greatly generalized=20 > comparing to the previous version. >=20 > Comments are solicited. >=20 > Regards! > -Qin > ----- Original Message ----- > From: > To: > Sent: Saturday, October 09, 2010 12:45 PM > Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt >=20 >=20 > >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : RTCP Report Extension for Feedback Suppression > > Author(s) : W. Wu, et al. > > Filename : draft-wu-avt-retransmission-supression-rtp-03.txt > > Pages : 24 > > Date : 2010-10-08 > > > > This document specifies an extension to the RTCP feedback messages=20 > > defined in the Audio-Visual Profile with Feedback (AVPF). This=20 > > extension allows an intermediate node in the network (such as an RTP > > translator) inform downstream receivers that sending a feedback=20 > > message concerning a specified set of RTP messages may be=20 > > unnecessary, or even harmful. For example, in a source-specific=20 > > multicast session with large fan-out, packet loss close to the media=20 > > or distribution source of the session is detected as a loss by a=20 > > large number of receivers. The RTCP NACK messages used to request=20 > > retransmission of the missing packets are all addressed to the media=20 > > sender, or a designated feedback target. This may result in a=20 > > phenomenon known variously as a "NACK implosion" or "feedback storm". > > The Feedback Suppression message defined herein is used to notify=20 > > receivers that packet loss was detected and that the sender of the=20 > > report will either proactively recover, or no recovery is possible. > > Receivers respond to receipt of a feedback suppression message by=20 > > not sending a feedback message (e.g. a NACK) that they otherwise=20 > > would, This in turn reduces load on both the feedback target and on=20 > > the network. This document registers two new RTCP messages for=20 > > Feedback Suppression. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission- > supression-rtp-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > >=20 >=20 > ---------------------------------------------------------------------- > - > --------- >=20 >=20 > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From sunseawq@huawei.com Thu Oct 14 20:13:39 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D644E3A6A82 for ; Thu, 14 Oct 2010 20:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-x4dBuCpRRt for ; Thu, 14 Oct 2010 20:13:38 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C578B3A6A11 for ; Thu, 14 Oct 2010 20:13:37 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00HO2ACN78@szxga03-in.huawei.com> for avt@ietf.org; Fri, 15 Oct 2010 11:14:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB007LWACNS0@szxga03-in.huawei.com> for avt@ietf.org; Fri, 15 Oct 2010 11:14:47 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAB00I6ZACMZ8@szxml04-in.huawei.com> for avt@ietf.org; Fri, 15 Oct 2010 11:14:47 +0800 (CST) Date: Fri, 15 Oct 2010 11:14:46 +0800 From: Qin Wu To: "Van Caenegem, Tom (Tom)" , Roni Even , avt@ietf.org Message-id: <029901cb6c17$1ee828d0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <010101cb676d$513735a0$4f548a0a@china.huawei.com> <015e01cb6a23$1da20c70$58e62550$%roni@huawei.com> Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 03:13:40 -0000 I would like to mention that the new version of draft-wu-avt-retransmission-supression-rtp has been issued. http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Van Caenegem, Tom (Tom) > Sent: Tuesday, October 12, 2010 4:35 PM > To: Qin Wu; avt@ietf.org > Subject: Re: [AVT] New Version Notification for draft-wu-avt- > retransmission-supression-rtp-03 > > Hi Qin, > > these are my comments on the draft 3 version: > > -you know of course that DVB IPTV has defined a solution to addres > NACK storms. This solution was recently also adopted by OIPF. You > propose to define a new dedicated message for NACK suppression, > whereas in DVB/OIPF we defined that when an RTP receiver gets such a > NACK message, this receiver should not send a NACK itself (provided > the NACK was received before the receiver sends its own NACK). In a > similar way, this could also be defined for FIR messages. I have no > fundamental problem if AVT decides to define a dedicated message, but > can you provide arguments why a NACK sent by the distribution > source/translator in a SSM to the client is not good enough for > imposing NACK suppression to a receiver, by definition? > > -a general comment: suppressing NACKs from receivers is a very tricky > thing. Sometimes it may do more harm than do any good, and I feel this > discussion and possible negative impact is not really addressed in > this draft. I am not sure what you mean here. The receivers do not suppress NACKs, the NACK suppression is sent by intermediary devices. TOM: Sure. The draft basically specifies the Suppression message. But in terms of intermediate source/receiver behaviour, my read-out is as follows: 1)a intermediate source can send at any time a NACK suppression [Qin]: No, the intermediate source follows the timing of RTCP feedback messages defined in the Audio-Visual Profile with Feedback (AVPF). 2)there is no normative language for the receiver what to do when this message is received [Qin]: You may look at the new version of draft-wu-avt-retransmission-supression-rtp: http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt According to normatve text of section 3 of draft-wu-avt-retransmission-supression-rtp-04: the receiver will be silent when it receives feedback suppression message. A receiver may still have sent a Feedback message before receiving a feedback suppression message, but further feedback messages for those sequence numbers will be suppressed by this technique. In the text, the intermediate source seems to rely on a NACK from a "loss reporter" for sending NACK suppression messages. Is this some kind of trusted device? Can it always be guaranteed that the packets this loss reporter receives or does not receive, are the same packets received/not received for all receivers that get the NACK suppression (and optional the retransmission afterwards)? Why would a receiver not systematically send the NACK anyhow -even if it does understand the suppression message, to maximise its chance of getting a retransmission.. This is the kind of discussion that should be included IMO. [Qin]: No, according to discussion so far on the list, relying on dedicated reciever as loss reporter to report packet loss by sending existing NACK may have some impact the performance. the intermediate source may has its own loss detection functionality and should not rely on NACK from such dedicated receiver disjointed from intermediate source. So I have remove the case relying on NACK from a loss report from this draft. Hope this clarfiies. Also I have moved the text associated with use cases to the example use case section. So they are just one example. > > -in your figure 1, the SSM is sourced by the intermediate source which > hosts the feedback target and a "loss reporter". This does not > represent a realistic architecture as it would mean that for IPTV > scenario the head-end receives all RTCP messages from all receivers. > You should include architectures where FT are decoupled from the SSM > source. This is not IPTV specific feature so this is an example. There can be other cases. TOM: The (only) figure in the draft (entitled "system architecture") shows that the "intermediate source" is sourcing the SSM, hence is also the distribution source. The draft is also explicit about this as it says: "The intermediate source must be able to communicate with all group members in order for either mechanism to be effective at suppressing feedback" This means that scenarios/architectures as addressed with RAMS (where the BRS is co-located with the FT which is in general separate from the DS) are outside the scope of this work? [Qin]: Thank you for point out this. You may not realized we have removed this ambiguity in the new version of draft-wu-avt-retransmission-supression-rtp http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt The main changes is: a. Move the last 6 paragraph to the protocol overview section. b. Remove the ambiguity text from protocol overview section and add some text in the SSM use cases section. This architecture will focus on specifying more generic mechanism and discuss how the mechanism works in the different use cases including the scenario as addressed with RAMS. > > -the definition of the "loss reporter" is somewhat obscure to me. From > various text fragments, it appears that a (NACK) FB message sent by > the loss reporter, will result in the intermediate source/distribution > source sending a NACK storm suppression or FFS message to the clients > in the group. This means to me that any packet loss reported by the > "loss reporter" is packet loss that will impact all receivers > downstream of the intermediate/distribution source. If this is not the > case, you will provide unneeded retransmissions. Is this a correct > interpretation? If so, please make this clear in the definition of > "loss reporter". If it is not, then mandating that getting a NACK from > a loss reporter results in a FFS message, is not recommended IMO. The draft only says the intermediate device will send NACK suppression and leaves open the application behavior in the upstream side. The discussion so far suggested that it should be out of scope for the draft. TOM: My remark here was about the "loss reporter" concept, not about how -"plain normal"- receivers should respond on the NACK suppression message. As written above, the draft's architecture in which you position the NACK suppression seems restricted and not covering RAMS architecture. [Qin] See above. > > -I do not understand why a "loss reporter" MUST not receive the FFS > message -which is meant to be sent on the SSM-, and I also do not get > how you can avoid that the "loss reporter" would receive this FFS > message, as a "loss reporter" that is downstream of the intermediate > source must be receiving the SSM in order to detect missing packets. > > -you introduce the "immediate reporting RTP client" terminology from > the DVB IPTV spec that is referenced, but its definition does not > align with how it is defined in the DVB spec. So, please, either > stick to the DVB definition or use a different term. TOM: I hope above two comments will be addressed and further discussed as well, [Qin]: Based on the discussion with Ingemar, David, Ali and you, it seems the discussion suggest that relying on NACK from dedicated receiver is not a good idea and has some harm. So I have removed this use case from the draft. Do it make sense? and I have another question: the draft defines how one can signal in SDP, support for the NACK suppression. Is that for SDP to be received by the RTP receivers? [Qin]: Yes, the reciever should understand feedback suppression message. If so, why must that be declared in the SDP? [Qin]: Any other choice? what's your proposal? Thx Tom > > Regards > Tom > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Qin Wu > Sent: zaterdag 9 oktober 2010 6:49 > To: avt@ietf.org > Subject: [AVT] New Version Notification for draft-wu-avt- > retransmission-supression-rtp-03 > > Folks, > > We have updated draft-wu-avt-retransmission-suppression-rtp which > should now reflect the discussion we had since IETF78. > > The feedback suppression solution has also been greatly generalized > comparing to the previous version. > > Comments are solicited. > > Regards! > -Qin > ----- Original Message ----- > From: > To: > Sent: Saturday, October 09, 2010 12:45 PM > Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : RTCP Report Extension for Feedback Suppression > > Author(s) : W. Wu, et al. > > Filename : draft-wu-avt-retransmission-supression-rtp-03.txt > > Pages : 24 > > Date : 2010-10-08 > > > > This document specifies an extension to the RTCP feedback messages > > defined in the Audio-Visual Profile with Feedback (AVPF). This > > extension allows an intermediate node in the network (such as an RTP > > translator) inform downstream receivers that sending a feedback > > message concerning a specified set of RTP messages may be > > unnecessary, or even harmful. For example, in a source-specific > > multicast session with large fan-out, packet loss close to the media > > or distribution source of the session is detected as a loss by a > > large number of receivers. The RTCP NACK messages used to request > > retransmission of the missing packets are all addressed to the media > > sender, or a designated feedback target. This may result in a > > phenomenon known variously as a "NACK implosion" or "feedback storm". > > The Feedback Suppression message defined herein is used to notify > > receivers that packet loss was detected and that the sender of the > > report will either proactively recover, or no recovery is possible. > > Receivers respond to receipt of a feedback suppression message by > > not sending a feedback message (e.g. a NACK) that they otherwise > > would, This in turn reduces load on both the feedback target and on > > the network. This document registers two new RTCP messages for > > Feedback Suppression. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission- > supression-rtp-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > ---------------------------------------------------------------------- > - > --------- > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From sunseawq@huawei.com Fri Oct 15 00:17:04 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7965F3A6C5C for ; Fri, 15 Oct 2010 00:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.128 X-Spam-Level: * X-Spam-Status: No, score=1.128 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, FAKE_REPLY_C=2.012, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrFlfxlFjsvf for ; Fri, 15 Oct 2010 00:16:54 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A48ED3A68BC for ; Fri, 15 Oct 2010 00:16:49 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00ME5LLYIR@szxga04-in.huawei.com> for avt@ietf.org; Fri, 15 Oct 2010 15:17:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB0079PLLY5Q@szxga04-in.huawei.com> for avt@ietf.org; Fri, 15 Oct 2010 15:17:58 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAB004GWLLX5G@szxml04-in.huawei.com> for avt@ietf.org; Fri, 15 Oct 2010 15:17:58 +0800 (CST) Date: Fri, 15 Oct 2010 15:17:58 +0800 From: Qin Wu To: "Van Caenegem, Tom (Tom)" , Roni Even , avt@ietf.org Message-id: <054a01cb6c39$189d78a0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 07:17:05 -0000 Hi, Thank for your comments, please see my reply inline. Regards! -Qin > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Van Caenegem, Tom (Tom) > Sent: Tuesday, October 12, 2010 4:35 PM > To: Qin Wu; avt@ietf.org > Subject: Re: [AVT] New Version Notification for draft-wu-avt- > retransmission-supression-rtp-03 > > Hi Qin, > > these are my comments on the draft 3 version: > > -you know of course that DVB IPTV has defined a solution to addres > NACK storms. This solution was recently also adopted by OIPF. You > propose to define a new dedicated message for NACK suppression, > whereas in DVB/OIPF we defined that when an RTP receiver gets such a > NACK message, this receiver should not send a NACK itself (provided > the NACK was received before the receiver sends its own NACK). In a > similar way, this could also be defined for FIR messages. I have no > fundamental problem if AVT decides to define a dedicated message, but > can you provide arguments why a NACK sent by the distribution > source/translator in a SSM to the client is not good enough for > imposing NACK suppression to a receiver, by definition? > > -a general comment: suppressing NACKs from receivers is a very tricky > thing. Sometimes it may do more harm than do any good, and I feel this > discussion and possible negative impact is not really addressed in > this draft. I am not sure what you mean here. The receivers do not suppress NACKs, the NACK suppression is sent by intermediary devices. TOM: Sure. The draft basically specifies the Suppression message. But in terms of intermediate source/receiver behaviour, my read-out is as follows: 1)a intermediate source can send at any time a NACK suppression [Qin]: No, the intermediate source follows the timing of RTCP feedback messages defined in the Audio-Visual Profile with Feedback (AVPF). 2)there is no normative language for the receiver what to do when this message is received [Qin]: You may look at the new version of draft-wu-avt-retransmission-supression-rtp: http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt According to normatve text of section 3 of draft-wu-avt-retransmission-supression-rtp-04: the receiver will be silent when it receives feedback suppression message. A receiver may still have sent a Feedback message before receiving a feedback suppression message, but further feedback messages for those sequence numbers will be suppressed by this technique. In the text, the intermediate source seems to rely on a NACK from a "loss reporter" for sending NACK suppression messages. Is this some kind of trusted device? Can it always be guaranteed that the packets this loss reporter receives or does not receive, are the same packets received/not received for all receivers that get the NACK suppression (and optional the retransmission afterwards)? Why would a receiver not systematically send the NACK anyhow -even if it does understand the suppression message, to maximise its chance of getting a retransmission.. This is the kind of discussion that should be included IMO. [Qin]: No, according to discussion so far on the list, relying on dedicated reciever as loss reporter to report packet loss by sending existing NACK may have some impact the performance. the intermediate source may has its own loss detection functionality and should not rely on NACK from such dedicated receiver disjointed from intermediate source. So I have remove the case relying on NACK from a loss report from this draft. Hope this clarfiies. Also I have moved the text associated with use cases to the example use case section. So they are just one example. > > -in your figure 1, the SSM is sourced by the intermediate source which > hosts the feedback target and a "loss reporter". This does not > represent a realistic architecture as it would mean that for IPTV > scenario the head-end receives all RTCP messages from all receivers. > You should include architectures where FT are decoupled from the SSM > source. This is not IPTV specific feature so this is an example. There can be other cases. TOM: The (only) figure in the draft (entitled "system architecture") shows that the "intermediate source" is sourcing the SSM, hence is also the distribution source. The draft is also explicit about this as it says: "The intermediate source must be able to communicate with all group members in order for either mechanism to be effective at suppressing feedback" This means that scenarios/architectures as addressed with RAMS (where the BRS is co-located with the FT which is in general separate from the DS) are outside the scope of this work? [Qin]: Thank you for pointing out this. You may not realized we have removed this ambiguity in the new version of draft-wu-avt-retransmission-supression-rtp http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt The main changes is: a. Move the last 6 paragraph to the protocol overview section. b. Remove the ambiguity text from protocol overview section and add some text in the SSM use cases section. This architecture will focus on specifying more generic mechanism and discuss how the mechanism works in the different use cases including the scenario as addressed with RAMS. > > -the definition of the "loss reporter" is somewhat obscure to me. From > various text fragments, it appears that a (NACK) FB message sent by > the loss reporter, will result in the intermediate source/distribution > source sending a NACK storm suppression or FFS message to the clients > in the group. This means to me that any packet loss reported by the > "loss reporter" is packet loss that will impact all receivers > downstream of the intermediate/distribution source. If this is not the > case, you will provide unneeded retransmissions. Is this a correct > interpretation? If so, please make this clear in the definition of > "loss reporter". If it is not, then mandating that getting a NACK from > a loss reporter results in a FFS message, is not recommended IMO. The draft only says the intermediate device will send NACK suppression and leaves open the application behavior in the upstream side. The discussion so far suggested that it should be out of scope for the draft. TOM: My remark here was about the "loss reporter" concept, not about how -"plain normal"- receivers should respond on the NACK suppression message. As written above, the draft's architecture in which you position the NACK suppression seems restricted and not covering RAMS architecture. [Qin] See above. > > -I do not understand why a "loss reporter" MUST not receive the FFS > message -which is meant to be sent on the SSM-, and I also do not get > how you can avoid that the "loss reporter" would receive this FFS > message, as a "loss reporter" that is downstream of the intermediate > source must be receiving the SSM in order to detect missing packets. > > -you introduce the "immediate reporting RTP client" terminology from > the DVB IPTV spec that is referenced, but its definition does not > align with how it is defined in the DVB spec. So, please, either > stick to the DVB definition or use a different term. TOM: I hope above two comments will be addressed and further discussed as well, [Qin]: Based on the discussion with Ingemar, David, Ali and you, it seems the discussion suggest that relying on NACK from dedicated receiver is not a good idea and has some harm. So I have removed this use case from the draft. Do it make sense? and I have another question: the draft defines how one can signal in SDP, support for the NACK suppression. Is that for SDP to be received by the RTP receivers? [Qin]: Yes, the reciever should understand feedback suppression message. If so, why must that be declared in the SDP? [Qin]: Any other choice? what's your proposal? Thx Tom > > Regards > Tom > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Qin Wu > Sent: zaterdag 9 oktober 2010 6:49 > To: avt@ietf.org > Subject: [AVT] New Version Notification for draft-wu-avt- > retransmission-supression-rtp-03 > > Folks, > > We have updated draft-wu-avt-retransmission-suppression-rtp which > should now reflect the discussion we had since IETF78. > > The feedback suppression solution has also been greatly generalized > comparing to the previous version. > > Comments are solicited. > > Regards! > -Qin > ----- Original Message ----- > From: > To: > Sent: Saturday, October 09, 2010 12:45 PM > Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : RTCP Report Extension for Feedback Suppression > > Author(s) : W. Wu, et al. > > Filename : draft-wu-avt-retransmission-supression-rtp-03.txt > > Pages : 24 > > Date : 2010-10-08 > > > > This document specifies an extension to the RTCP feedback messages > > defined in the Audio-Visual Profile with Feedback (AVPF). This > > extension allows an intermediate node in the network (such as an RTP > > translator) inform downstream receivers that sending a feedback > > message concerning a specified set of RTP messages may be > > unnecessary, or even harmful. For example, in a source-specific > > multicast session with large fan-out, packet loss close to the media > > or distribution source of the session is detected as a loss by a > > large number of receivers. The RTCP NACK messages used to request > > retransmission of the missing packets are all addressed to the media > > sender, or a designated feedback target. This may result in a > > phenomenon known variously as a "NACK implosion" or "feedback storm". > > The Feedback Suppression message defined herein is used to notify > > receivers that packet loss was detected and that the sender of the > > report will either proactively recover, or no recovery is possible. > > Receivers respond to receipt of a feedback suppression message by > > not sending a feedback message (e.g. a NACK) that they otherwise > > would, This in turn reduces load on both the feedback target and on > > the network. This document registers two new RTCP messages for > > Feedback Suppression. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission- > supression-rtp-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > ---------------------------------------------------------------------- > - > --------- > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From xiajinwei@huawei.com Fri Oct 15 19:04:57 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1734E3A6A87 for ; Fri, 15 Oct 2010 19:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6c296AAtmv6 for ; Fri, 15 Oct 2010 19:04:56 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1A7533A6B0B for ; Fri, 15 Oct 2010 19:04:56 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAD00KRX1U866@szxga04-in.huawei.com> for avt@ietf.org; Sat, 16 Oct 2010 10:06:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAD007D61U85B@szxga04-in.huawei.com> for avt@ietf.org; Sat, 16 Oct 2010 10:06:08 +0800 (CST) Received: from x65217 ([10.138.41.60]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAD00BV91U7GR@szxml06-in.huawei.com> for avt@ietf.org; Sat, 16 Oct 2010 10:06:08 +0800 (CST) Date: Sat, 16 Oct 2010 10:06:07 +0800 From: Jinwei Xia To: 'IETF AVT WG' Message-id: <002d01cb6cd6$b24e2ce0$3c298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acts1brr6HYaFOwTTE+cVM7NeLndIwAADl8g Subject: [AVT] FW: New Version Notification for draft-xia-avt-splicing-for-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 02:04:57 -0000 Hi, >From the discussion on IETF 78th, there were some misunderstandings of the scope of splicing draft. So we discard previous problem statement draft while initiate new solution draft. In this new draft, We emphysize content insertion issue is indeed a RTP-generic rather than MPEG2 TS-specific. Hope the new draft can address most issues AVT concern, any comments are very appreciated! BR! Jinwei > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Saturday, October 16, 2010 9:58 AM > To: xiajinwei@huawei.com > Subject: New Version Notification for > draft-xia-avt-splicing-for-rtp-00 > > > A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt > has been successfully submitted by Jinwei Xia and posted to > the IETF repository. > > Filename: draft-xia-avt-splicing-for-rtp > Revision: 00 > Title: Content Splicing for RTP Sessions > Creation_date: 2010-10-16 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > This memo outlines RTP splicing. Splicing is a process that > allows a new multimedia stream to be inserted into current > multimedia stream and to be conveyed to receiver for a period > of time. This memo discusses the requirements of RTP > splicing. In order to satisfy the requirements, this memo > lists several existing intermediary network elements as > alternatives and evaluates whether one of alternatives can be > used to perform RTP splicing. > > > > > The IETF Secretariat. > > From sunseawq@huawei.com Fri Oct 15 21:17:41 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37CB83A6956 for ; Fri, 15 Oct 2010 21:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.083 X-Spam-Level: X-Spam-Status: No, score=0.083 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+-P+D+OPnJO for ; Fri, 15 Oct 2010 21:17:40 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 44F083A68BE for ; Fri, 15 Oct 2010 21:17:39 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAD00MH07ZEC7@szxga05-in.huawei.com> for avt@ietf.org; Sat, 16 Oct 2010 12:18:51 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAD005Y17ZEKB@szxga05-in.huawei.com> for avt@ietf.org; Sat, 16 Oct 2010 12:18:50 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAD007X37ZD8O@szxml06-in.huawei.com> for avt@ietf.org; Sat, 16 Oct 2010 12:18:50 +0800 (CST) Date: Sat, 16 Oct 2010 12:18:49 +0800 From: Qin Wu To: geoff.hunt@bt.com, avt@ietf.org Message-id: <048501cb6ce9$3c1770a0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1402EB0DEE32704AA45CC1CAA5ED718B093E1FF915@EMV68-UKRD.domain1.systemhost.net> Cc: philip.arden@bt.com Subject: Re: [AVT] Audio to discuss monitoring architecture for RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 04:17:41 -0000 Hi, Sorry for late reply. Thank geoff and philip for arranging this discussion. I am willing to work on the aspect of draft that describe transport metrics and application metrics. I think they are worth more works. I would like to contribute on these aspect. Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Tuesday, September 21, 2010 5:36 PM Subject: Re: [AVT] Audio to discuss monitoring architecture for RTP > Here are the notes of the informal AVT call to discuss a monitoring architecture for RTP, > held on 14-Sep-2010. > > In summary, a number of potential work areas were identified within the broad scope of a monitoring > architecture but there was no commitment of resource on the call to work on any of these topics. We > agreed that, if a consensus emerges on the list regarding area(s) of immediate interest where people > will commit to work, these area(s) could be taken forward. > > Thanks to Philip for taking these notes. If you were on the call and find any errors or omissions, > please let us know. > > Participants: > > Geoff Hunt (chair) > Philip Arden (notes) > Gunnar Heikkila > Keith Drage > Qin Wu > Glen Zorn > Marie Josee Drouin > Dan Romascanu > Michael Romalho > Christian Hoene > > Keith said that the audio was an informal IETF call and asked whether > there was agreement to adopt the conventions of the IETF Note well for > the call. All were in agreement. > > 1. Agenda > > Geoff introduced the agenda as follows and asked for any additions - > there were none. > > 1. Agenda bashing > 2. Scene setting > - Current chartered work > - Existing drafts and previous work > 3. What must be defined in an architecture? > - candidate topics > - transport metrics? > - application metrics? > - how to choose re-usable metrics > - source stream identification > - measurement point identification (where/what) > - measurement correlation keys > - destination entities > - delivery methods > - packaging of metrics (compact? re-usable?) > - security > 4. How much of this is within AVT remit? > 5. Proposal for scope of AVT deliverable > 6. Next steps > > Geoff saw two aims for the call: > > i) Agree on a short-term AVT deliverable > ii) Discuss any longer term deliverables, which may not necessarily be > part of AVT. > > Keith - work needs to be defined first and then a decision can be made > as to where it fits. Don't distinguish between short- and long-term > work on this call > > 2. Scene Setting > Geoff gave a brief summary of Monarch 01 and Monarch 00: > > Monarch 01 is narrower in scope and describes how to transport XR > metrics (independently of application) in RTCP and how to structure the > format of the packets whilst also making sure that the metrics are > transportable. > > Monarch 00 describes how to choose metrics for applications and is > wider in scope. It includes application metrics for voice and requires > expansion to include video metrics. > > Although AVT has a milestone for a monitoring architecture, neither > draft is adopted as an AVT WG work item > > Geoff - do other documents need to be considered? > > Qin - video quality monitoring needed to be addressed, and the > following documents need to be considered: > RFC 4710 > RFC 4712 > RFC 3611 > He also felt that the current scope was very narrow and needed to be > extended. The architecture title implied a broader scope. > > Keith - scope needs to reflect the available resource. There is no > point in having a work item that could cannot be resourced. > > Qin - a more suitable title for the document might be something like > "Guidelines for extending metrics blocks using RTCP-XR". > > 3. What must be defined in the architecture? > > i) Transport and application metrics > > Geoff - AVT has a primary obligation to define RTCP transport metric. > > Qin - RFC3611 contains both transport and application metrics and > transport metrics should be included as part of the architecture. The > architecture should also include metrics guidelines and how to classify > the information in metrics. > > Geoff - should northbound metrics be included as well as RTP peer > metrics. Do peer metrics need to be distinguished from northbound > metrics? > > Qin - agreed and said that translators play a role in extracting > information which may or may not be sent in RTCP. > > ii) Metric re-use > > Geoff - the architecture should describe transport metrics. When Colin > (Perkins) asked for a draft he was keen not to invent new metrics and > existing metrics should be re-used as far as possible for different > applications. > > Qin and Marie both agreed with this view. > > Keith - list of metrics needs to be reviewed and also assuming one > needs new metrics information is needed about how they can be made re-usable. > > Dan - agreed. Should the doc cover scalability in gathering and > reporting metrics based on experience gained in XR deployment, eg why > MIB development didn't succeed, and examples of probe deployments. > > iii) Security > > Geoff - there is also a related security issue about gathering and > transporting metrics. > > Dan - agreed. The impact of encrypted signals also needs to be > considered. > > Geoff - do we need all the topics on the list and are there any > omissions? > > iv) Source stream identification and measurement point ID > > Marie - Monarch draft 01 mentioned raised a number of questions. For > example in Section 4 about the identity block there are unresolved > questions about the overlap of identity information between XR and RR > information. > > Geoff - need to identify the overlaps and then take them to the AVT > list. Also, why does RTCP not have some of the identity information > mentioned in Monarch 01? > > Marie - missing from Monarch 01 is what could be transported in RTP as > opposed to RTCP. > > v) Measurement correlation keys > > Geoff - could we use the SSRC and IP address as a correlation key to ID > a stream from end to end? > > Michael - the SIPPING group is working on a session ID for this purpose. > > Geoff - you need a session ID to compare metrics from point A with > those from point B. > > Michael - could a hop count identifier be used? > > Geoff - measurements could be made at several nodes and then sent on, > but would this technique scale? > > Michael - if you only use RTCP metrics, then one possibility would be > to enable them as required. Ought not to enable all the metrics all > the time except for a basic set. The architecture needs to define a > rudimentary set of metrics. > > Geoff - so another aspect of the architecture would be methods for > control of metrics collection > > vi) Destination entities and delivery methods > > Geoff - is it appropriate to include a range of destination entities, > delivery methods and protocols? > > Michael - this is a hard problem. If you have separate RTP sessions, > all sorts of ID are different. The DSPs don't have access to all the > information required. Also provider A won't want to give metrics > relating to problems in its own network to provider B. > > Geoff - are you saying that it's not worth defining interfaces because > of inter-operator politics? > > Michael - one could define metrics for a single network. > > 6. Summary and next steps > > Geoff - next steps are to put out the notes. Should AVT be doing work > in this area? > > Keith - asked whether people are prepared to commit resource. > > Gunnar - the requirements for troubleshooting and for monitoring > end-user quality are different. Could collect application metrics from endpoints. > Should consider both sets of requirements. > > Geoff - need to decide how they fit into the architecture. > > Marie - would like to contribute, but scope needs to be narrowed. > > Keith - guidelines for defining reporting blocks would be useful - or > do we need a review? How much resource would be required to do this? > > Geoff - should we therefore suggest a work item on guidelines for > defining new XR blocks? > > Qin - the draft needs to be restructured as the title doesn't reflect > the content. > > Keith - keen not to propose work items that have no resource. From AVT > charter perspective, key criteria are that work must be useful and that > it must be resourced. Just "an idea and an editor" are not enough. > > Geoff - suggest putting the resource question to the AVT list and > propose a work item on draft guidelines for XR blocks. Also note what > was discussed on the call and see what topics elicit volunteers. > > Keith - mentioned next meeting in Beijing and asked whether it would be > possible to have a face to face meeting? This seemed unlikely for the > responses. He also suggested a follow-on call once responses had been > obtained form the list. > > Geoff - will arrange follow on call. > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From sunseawq@huawei.com Fri Oct 15 21:28:31 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E283A6A8E for ; Fri, 15 Oct 2010 21:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.076 X-Spam-Level: X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpOdVNVr8lE9 for ; Fri, 15 Oct 2010 21:28:28 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id DA0233A6956 for ; Fri, 15 Oct 2010 21:28:22 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAD0011W8H7V0@szxga01-in.huawei.com> for avt@ietf.org; Sat, 16 Oct 2010 12:29:31 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAD002ZU8H76P@szxga01-in.huawei.com> for avt@ietf.org; Sat, 16 Oct 2010 12:29:31 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAD007J68H68O@szxml06-in.huawei.com> for avt@ietf.org; Sat, 16 Oct 2010 12:29:31 +0800 (CST) Date: Sat, 16 Oct 2010 12:29:30 +0800 From: Qin Wu To: "DRAGE, Keith (Keith)" , geoff.hunt@bt.com, avt@ietf.org Message-id: <04a301cb6cea$ba184190$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1402EB0DEE32704AA45CC1CAA5ED718B093E1FF915@EMV68-UKRD.domain1.systemhost.net> Cc: philip.arden@bt.com Subject: Re: [AVT] Audio to discuss monitoring architecture for RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 04:28:31 -0000 Hi, Keith: It seems we have two things to do for the next step: a) contribute to some parts of monitoring architecture draft or b) contribute to monitoring topic by writing some new draft It is not clear to me what one you suggest us to do? Would you like to clarify this? Regards! -Qin ----- Original Message ----- From: "DRAGE, Keith (Keith)" To: ; Cc: Sent: Wednesday, September 22, 2010 9:48 PM Subject: Re: [AVT] Audio to discuss monitoring architecture for RTP > All, > > Please comment on the notes, and propose where we go next. It would be nice to see words like "I am prepared to work on the parts of a draft that describe this". > My understanding is that the relevant people will not be in Beijing, so we will not be scheduling it as part of the AVT meeting there. A further conference call (which could potentially be official) has been suggested, but that requires some input before we get to that point. If you want this work, please contribute. > > regards > > Keith > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >> Behalf Of geoff.hunt@bt.com >> Sent: Tuesday, September 21, 2010 10:36 AM >> To: avt@ietf.org >> Cc: philip.arden@bt.com >> Subject: Re: [AVT] Audio to discuss monitoring architecture for RTP >> >> Here are the notes of the informal AVT call to discuss a >> monitoring architecture for RTP, held on 14-Sep-2010. >> >> In summary, a number of potential work areas were identified >> within the broad scope of a monitoring architecture but there >> was no commitment of resource on the call to work on any of >> these topics. We agreed that, if a consensus emerges on the >> list regarding area(s) of immediate interest where people >> will commit to work, these area(s) could be taken forward. >> >> Thanks to Philip for taking these notes. If you were on the >> call and find any errors or omissions, please let us know. >> >> Participants: >> >> Geoff Hunt (chair) >> Philip Arden (notes) >> Gunnar Heikkila >> Keith Drage >> Qin Wu >> Glen Zorn >> Marie Josee Drouin >> Dan Romascanu >> Michael Romalho >> Christian Hoene >> >> Keith said that the audio was an informal IETF call and asked >> whether there was agreement to adopt the conventions of the >> IETF Note well for the call. All were in agreement. >> >> 1. Agenda >> >> Geoff introduced the agenda as follows and asked for any >> additions - there were none. >> >> 1. Agenda bashing >> 2. Scene setting >> - Current chartered work >> - Existing drafts and previous work >> 3. What must be defined in an architecture? >> - candidate topics >> - transport metrics? >> - application metrics? >> - how to choose re-usable metrics >> - source stream identification >> - measurement point identification (where/what) >> - measurement correlation keys >> - destination entities >> - delivery methods >> - packaging of metrics (compact? re-usable?) >> - security >> 4. How much of this is within AVT remit? >> 5. Proposal for scope of AVT deliverable >> 6. Next steps >> >> Geoff saw two aims for the call: >> >> i) Agree on a short-term AVT deliverable >> ii) Discuss any longer term deliverables, which may not >> necessarily be part of AVT. >> >> Keith - work needs to be defined first and then a decision >> can be made as to where it fits. Don't distinguish between >> short- and long-term work on this call >> >> 2. Scene Setting >> Geoff gave a brief summary of Monarch 01 and Monarch 00: >> >> Monarch 01 is narrower in scope and describes how to >> transport XR metrics (independently of application) in RTCP >> and how to structure the format of the packets whilst also >> making sure that the metrics are transportable. >> >> Monarch 00 describes how to choose metrics for applications >> and is wider in scope. It includes application metrics for >> voice and requires expansion to include video metrics. >> >> Although AVT has a milestone for a monitoring architecture, >> neither draft is adopted as an AVT WG work item >> >> Geoff - do other documents need to be considered? >> >> Qin - video quality monitoring needed to be addressed, and >> the following documents need to be considered: >> RFC 4710 >> RFC 4712 >> RFC 3611 >> He also felt that the current scope was very narrow and >> needed to be extended. The architecture title implied a >> broader scope. >> >> Keith - scope needs to reflect the available resource. There >> is no point in having a work item that could cannot be resourced. >> >> Qin - a more suitable title for the document might be >> something like "Guidelines for extending metrics blocks using >> RTCP-XR". >> >> 3. What must be defined in the architecture? >> >> i) Transport and application metrics >> >> Geoff - AVT has a primary obligation to define RTCP transport metric. >> >> Qin - RFC3611 contains both transport and application metrics >> and transport metrics should be included as part of the >> architecture. The architecture should also include metrics >> guidelines and how to classify the information in metrics. >> >> Geoff - should northbound metrics be included as well as RTP >> peer metrics. Do peer metrics need to be distinguished from >> northbound metrics? >> >> Qin - agreed and said that translators play a role in >> extracting information which may or may not be sent in RTCP. >> >> ii) Metric re-use >> >> Geoff - the architecture should describe transport metrics. >> When Colin >> (Perkins) asked for a draft he was keen not to invent new >> metrics and existing metrics should be re-used as far as >> possible for different applications. >> >> Qin and Marie both agreed with this view. >> >> Keith - list of metrics needs to be reviewed and also >> assuming one needs new metrics information is needed about >> how they can be made re-usable. >> >> Dan - agreed. Should the doc cover scalability in gathering >> and reporting metrics based on experience gained in XR >> deployment, eg why MIB development didn't succeed, and >> examples of probe deployments. >> >> iii) Security >> >> Geoff - there is also a related security issue about >> gathering and transporting metrics. >> >> Dan - agreed. The impact of encrypted signals also needs to >> be considered. >> >> Geoff - do we need all the topics on the list and are there >> any omissions? >> >> iv) Source stream identification and measurement point ID >> >> Marie - Monarch draft 01 mentioned raised a number of >> questions. For example in Section 4 about the identity block >> there are unresolved questions about the overlap of identity >> information between XR and RR information. >> >> Geoff - need to identify the overlaps and then take them to >> the AVT list. Also, why does RTCP not have some of the >> identity information mentioned in Monarch 01? >> >> Marie - missing from Monarch 01 is what could be transported >> in RTP as opposed to RTCP. >> >> v) Measurement correlation keys >> >> Geoff - could we use the SSRC and IP address as a correlation >> key to ID a stream from end to end? >> >> Michael - the SIPPING group is working on a session ID for >> this purpose. >> >> Geoff - you need a session ID to compare metrics from point A >> with those from point B. >> >> Michael - could a hop count identifier be used? >> >> Geoff - measurements could be made at several nodes and then >> sent on, but would this technique scale? >> >> Michael - if you only use RTCP metrics, then one possibility >> would be to enable them as required. Ought not to enable all >> the metrics all the time except for a basic set. The >> architecture needs to define a rudimentary set of metrics. >> >> Geoff - so another aspect of the architecture would be >> methods for control of metrics collection >> >> vi) Destination entities and delivery methods >> >> Geoff - is it appropriate to include a range of destination >> entities, delivery methods and protocols? >> >> Michael - this is a hard problem. If you have separate RTP >> sessions, all sorts of ID are different. The DSPs don't have >> access to all the information required. Also provider A >> won't want to give metrics relating to problems in its own >> network to provider B. >> >> Geoff - are you saying that it's not worth defining >> interfaces because of inter-operator politics? >> >> Michael - one could define metrics for a single network. >> >> 6. Summary and next steps >> >> Geoff - next steps are to put out the notes. Should AVT be >> doing work in this area? >> >> Keith - asked whether people are prepared to commit resource. >> >> Gunnar - the requirements for troubleshooting and for >> monitoring end-user quality are different. Could collect >> application metrics from endpoints. >> Should consider both sets of requirements. >> >> Geoff - need to decide how they fit into the architecture. >> >> Marie - would like to contribute, but scope needs to be narrowed. >> >> Keith - guidelines for defining reporting blocks would be >> useful - or do we need a review? How much resource would be >> required to do this? >> >> Geoff - should we therefore suggest a work item on guidelines >> for defining new XR blocks? >> >> Qin - the draft needs to be restructured as the title doesn't >> reflect the content. >> >> Keith - keen not to propose work items that have no resource. >> From AVT charter perspective, key criteria are that work must >> be useful and that it must be resourced. Just "an idea and an >> editor" are not enough. >> >> Geoff - suggest putting the resource question to the AVT list >> and propose a work item on draft guidelines for XR blocks. >> Also note what was discussed on the call and see what topics >> elicit volunteers. >> >> Keith - mentioned next meeting in Beijing and asked whether >> it would be possible to have a face to face meeting? This >> seemed unlikely for the responses. He also suggested a >> follow-on call once responses had been obtained form the list. >> >> Geoff - will arrange follow on call. >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From root@core3.amsl.com Sat Oct 16 20:30:03 2010 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 19C333A6B90; Sat, 16 Oct 2010 20:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101017033003.19C333A6B90@core3.amsl.com> Date: Sat, 16 Oct 2010 20:30:02 -0700 (PDT) Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rapid-acquisition-for-rtp-16.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 03:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Unicast-Based Rapid Acquisition of Multicast RTP Sessions Author(s) : B. Ver Steeg, et al. Filename : draft-ietf-avt-rapid-acquisition-for-rtp-16.txt Pages : 56 Date : 2010-10-16 When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information as well as the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes/accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, the proposed method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rapid-acquisition-for-rtp-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rapid-acquisition-for-rtp-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-16202656.I-D@ietf.org> --NextPart-- From abegen@cisco.com Sat Oct 16 20:30:45 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135BA3A6B90 for ; Sat, 16 Oct 2010 20:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvJXOZEZlmSv for ; Sat, 16 Oct 2010 20:30:42 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 98CB73A6B95 for ; Sat, 16 Oct 2010 20:30:39 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEwLukyrR7H+/2dsb2JhbACDH500V3GmWIoikQyBIoMzdASEVIkB X-IronPort-AV: E=Sophos;i="4.57,342,1283731200"; d="scan'208";a="270663922" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 17 Oct 2010 03:32:04 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9H3W4Ex009335; Sun, 17 Oct 2010 03:32:04 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Oct 2010 20:32:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sat, 16 Oct 2010 20:32:07 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D68980E@xmb-sjc-215.amer.cisco.com> In-Reply-To: <20101017032656.B038F3A6B90@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-avt-rapid-acquisition-for-rtp-16 Thread-Index: Acttq1oGJ+F2iWVtQ/iV8EbR7kHStAAAEhPw References: <20101017032656.B038F3A6B90@core3.amsl.com> From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 17 Oct 2010 03:32:04.0598 (UTC) FILETIME=[DE435160:01CB6DAB] Subject: [AVT] FW: New Version Notification for draft-ietf-avt-rapid-acquisition-for-rtp-16 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 03:30:45 -0000 VGhpcyByZXZpc2lvbiBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGZyb20gS2VpdGgs IE1hZ251cywgZ2VuZXJhbCBhcmVhIGFuZCBzZWN1cml0eSBhcmVhIHJldmlld2Vycy4NCg0KRGlm ZiBpcyBhdmFpbGFibGUgaGVyZToNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1hdnQtcmFwaWQtYWNxdWlzaXRpb24tZm9yLXJ0cC0xNg0KDQotYWNiZWdlbg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBU b29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IFNhdHVyZGF5LCBPY3Rv YmVyIDE2LCAyMDEwIDExOjI3IFBNDQpUbzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pDQpDYzogYmls bHZzQGNpc2NvLmNvbTsgVG9tLlZhbl9DYWVuZWdlbUBhbGNhdGVsLWx1Y2VudC5iZTsgemVldnZh eEBtaWNyb3NvZnQuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWlldGYtYXZ0LXJhcGlkLWFjcXVpc2l0aW9uLWZvci1ydHAtMTYgDQoNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtYXZ0LXJhcGlkLWFjcXVpc2l0aW9uLWZvci1ydHAtMTYu dHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWxpIEJlZ2VuIGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1pZXRmLWF2dC1y YXBpZC1hY3F1aXNpdGlvbi1mb3ItcnRwDQpSZXZpc2lvbjoJIDE2DQpUaXRsZToJCSBVbmljYXN0 LUJhc2VkIFJhcGlkIEFjcXVpc2l0aW9uIG9mIE11bHRpY2FzdCBSVFAgU2Vzc2lvbnMNCkNyZWF0 aW9uX2RhdGU6CSAyMDEwLTEwLTE2DQpXRyBJRDoJCSBhdnQNCk51bWJlcl9vZl9wYWdlczogNTYN Cg0KQWJzdHJhY3Q6DQpXaGVuIGFuIFJUUCByZWNlaXZlciBqb2lucyBhIG11bHRpY2FzdCBzZXNz aW9uLCBpdCBtYXkgbmVlZCB0bw0KYWNxdWlyZSBhbmQgcGFyc2UgY2VydGFpbiBSZWZlcmVuY2Ug SW5mb3JtYXRpb24gYmVmb3JlIGl0IGNhbiBwcm9jZXNzDQphbnkgZGF0YSBzZW50IGluIHRoZSBt dWx0aWNhc3Qgc2Vzc2lvbi4gIERlcGVuZGluZyBvbiB0aGUgam9pbiB0aW1lLA0KbGVuZ3RoIG9m IHRoZSBSZWZlcmVuY2UgSW5mb3JtYXRpb24gcmVwZXRpdGlvbiAob3IgYXBwZWFyYW5jZSkNCmlu dGVydmFsLCBzaXplIG9mIHRoZSBSZWZlcmVuY2UgSW5mb3JtYXRpb24gYXMgd2VsbCBhcyB0aGUN CmFwcGxpY2F0aW9uIGFuZCB0cmFuc3BvcnQgcHJvcGVydGllcywgdGhlIHRpbWUgbGFnIGJlZm9y ZSBhbiBSVFANCnJlY2VpdmVyIGNhbiB1c2VmdWxseSBjb25zdW1lIHRoZSBtdWx0aWNhc3QgZGF0 YSwgd2hpY2ggd2UgcmVmZXIgdG8NCmFzIHRoZSBBY3F1aXNpdGlvbiBEZWxheSwgdmFyaWVzIGFu ZCBjYW4gYmUgbGFyZ2UuICBUaGlzIGlzIGFuDQp1bmRlc2lyYWJsZSBwaGVub21lbm9uIGZvciBy ZWNlaXZlcnMgdGhhdCBmcmVxdWVudGx5IHN3aXRjaCBhbW9uZw0KZGlmZmVyZW50IG11bHRpY2Fz dCBzZXNzaW9ucywgc3VjaCBhcyB2aWRlbyBicm9hZGNhc3RzLg0KDQpJbiB0aGlzIGRvY3VtZW50 LCB3ZSBkZXNjcmliZSBhIG1ldGhvZCB1c2luZyB0aGUgZXhpc3RpbmcgUlRQIGFuZCBSVFANCkNv bnRyb2wgUHJvdG9jb2wgKFJUQ1ApIG1hY2hpbmVyeSB0aGF0IHJlZHVjZXMgdGhlIGFjcXVpc2l0 aW9uIGRlbGF5Lg0KSW4gdGhpcyBtZXRob2QsIGFuIGF1eGlsaWFyeSB1bmljYXN0IFJUUCBzZXNz aW9uIGNhcnJ5aW5nIHRoZQ0KUmVmZXJlbmNlIEluZm9ybWF0aW9uIHRvIHRoZSByZWNlaXZlciBw cmVjZWRlcy9hY2NvbXBhbmllcyB0aGUNCm11bHRpY2FzdCBzdHJlYW0uICBUaGlzIHVuaWNhc3Qg UlRQIGZsb3cgY2FuIGJlIHRyYW5zbWl0dGVkIGF0IGENCmZhc3RlciB0aGFuIG5hdHVyYWwgYml0 cmF0ZSB0byBmdXJ0aGVyIGFjY2VsZXJhdGUgdGhlIGFjcXVpc2l0aW9uLg0KVGhlIG1vdGl2YXRp bmcgdXNlIGNhc2UgZm9yIHRoaXMgY2FwYWJpbGl0eSBpcyBtdWx0aWNhc3QgYXBwbGljYXRpb25z DQp0aGF0IGNhcnJ5IHJlYWwtdGltZSBjb21wcmVzc2VkIGF1ZGlvIGFuZCB2aWRlby4gIEhvd2V2 ZXIsIHRoZQ0KcHJvcG9zZWQgbWV0aG9kIGNhbiBhbHNvIGJlIHVzZWQgaW4gb3RoZXIgdHlwZXMg b2YgbXVsdGljYXN0DQphcHBsaWNhdGlvbnMgd2hlcmUgdGhlIGFjcXVpc2l0aW9uIGRlbGF5IGlz IGxvbmcgZW5vdWdoIHRvIGJlIGENCnByb2JsZW0uDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0K From whkimbg@gmail.com Sun Oct 17 22:52:29 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38E43A6A8E for ; Sun, 17 Oct 2010 22:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRfErwTZOFCH for ; Sun, 17 Oct 2010 22:52:28 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 212C63A6A63 for ; Sun, 17 Oct 2010 22:52:27 -0700 (PDT) Received: by wyb29 with SMTP id 29so820618wyb.31 for ; Sun, 17 Oct 2010 22:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=3sA3E7uJlKw9Y3fYHTOO8nKhMlkeGIQtMc8z4PmjKPk=; b=QmTnyfrndCuyiiovjFxpeqkDxa8N5d9p5zTSfpuFtWFSpbhzeB9sjDN3lkClR7m8WV gVwi6fkawPcIn1t3bKEquGk2DHUzawBp0cK3RneWSbx9DSN6U/x+6YdhGE7E8FGuQzDH jyrk04X7pQiu2g6FokO6JO6kciRK6TMvwkh4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=VJQnbnwkOasTzZwhWoGzfWqC6DnDPR+xTTonAlLvat28zABHxrfggSmdRh36Cb850o rbvRbwfRNffEKEWLWjfJ4aBAjfoMX9hp7E3HMKkMZTBZjVmwe0S6f3cy7aL/3qvigVzc L2t3VWK+YuCzRFVhf/3ancBfQSHZMoM5iRCzk= MIME-Version: 1.0 Received: by 10.216.133.159 with SMTP id q31mr4071345wei.108.1287381232255; Sun, 17 Oct 2010 22:53:52 -0700 (PDT) Sender: whkimbg@gmail.com Received: by 10.216.179.139 with HTTP; Sun, 17 Oct 2010 22:53:52 -0700 (PDT) Date: Mon, 18 Oct 2010 14:53:52 +0900 X-Google-Sender-Auth: 7dc_WGBtXoxhvSIWx2axWw-9rHQ Message-ID: From: Woo-Hwan Kim To: avt@ietf.org Content-Type: multipart/alternative; boundary=0016e6dd961a0a02130492ddcdea Subject: [AVT] Request for review: ARIA algorithm and its use with SRTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 05:52:30 -0000 --0016e6dd961a0a02130492ddcdea Content-Type: text/plain; charset=ISO-8859-1 AVT experts, Let me make a request for the AVT WG review on the draft regarding ARIA cipher algorithm and its use with SRTP. ARIA is a general-purpose block cipher algorithm developed in 2003 and is published as a RFC (RFC 5794) in March 2010. As you know, there is another standard block cipher SEED in Korea and SEED-SRTP is published as a RFC in August 2010. Both SEED and ARIA were established as KS(Korean Standard) by the Ministry of Knowledge Economy of Korea. While SEED is mainly used for for electronic commerce and financial service, ARIA is for government use and public purpose. For example, ARIA is used by the followings in Korea. - Korea e-Government - electronic identification card - National Police Agency - Ministry of Health and Welfare - Korea Centers for Disease Control and Prevention In particular, ARIA will be used in VoIP for government and many international VoIP vendors are developing products supporting ARIA. We believe it increases the demand for standardization of protocols related to ARIA. Please find the internet draft from the below. http://tools.ietf.org/html/draft-nsri-avt-aria-srtp-00 Best regards, Woo-Hwan Kim --0016e6dd961a0a02130492ddcdea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AVT experts,

Let me make a request for the AVT WG review
on the = draft regarding ARIA cipher algorithm and its use with SRTP.

ARIA is= a general-purpose block cipher algorithm developed in 2003
and is publi= shed as a RFC (RFC 5794) in March 2010.

As you know, there is another standard block cipher SEED in Korea
an= d SEED-SRTP is published as a RFC in August 2010.
Both SEED and ARIA wer= e established as KS(Korean Standard)
by the Ministry of Knowledge Econo= my of Korea.
While SEED is mainly used for for electronic commerce and financial service= ,
ARIA is for government use and public purpose.

For example, ARI= A is used by the followings in Korea.
- Korea e-Government
- electron= ic identification card
- National Police Agency
- Ministry of Health and Welfare
- Korea Cen= ters for Disease Control and Prevention

In particular, ARIA will be = used in VoIP for government
and many international VoIP vendors are deve= loping products supporting ARIA.
We believe it increases the demand for standardization of protocols related= to ARIA.

Please find the internet draft from the below.

http://tools= .ietf.org/html/draft-nsri-avt-aria-srtp-00

Best regards,
Woo-Hwan Kim --0016e6dd961a0a02130492ddcdea-- From tom.van_caenegem@alcatel-lucent.com Mon Oct 18 09:07:13 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8712D3A6BDB for ; Mon, 18 Oct 2010 09:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.995 X-Spam-Level: X-Spam-Status: No, score=-4.995 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUalFVDZMOlO for ; Mon, 18 Oct 2010 09:07:11 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id BBB5B3A6DF4 for ; Mon, 18 Oct 2010 09:06:57 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9IG7wc8026652 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Oct 2010 18:08:20 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 18 Oct 2010 18:08:17 +0200 From: "Van Caenegem, Tom (Tom)" To: "avt@ietf.org" , Qin Wu Date: Mon, 18 Oct 2010 18:08:15 +0200 Thread-Topic: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 Thread-Index: Actu3qwQENLCB3eOT5GnWxez0BnfpQ== Message-ID: 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: multipart/alternative; boundary="_000_EC3FD58E75D43A4F8807FDE0749175460E4373DDFRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 16:07:13 -0000 --_000_EC3FD58E75D43A4F8807FDE0749175460E4373DDFRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Qin, I have some comments (look for TOM below) on the new draft version 4. Thx for addressing them, Tom Section 2 Terminology Loss Detector: The Loss Detector is one logical function which is used to detect the packet loss at the RTP layer and report it to the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. In this case, for a session defined as having a distribution source A, on ports n for the RTP channel and k for the RTCP channel, the Loss Detector are identified by an IP address of distribution source A on port k. The Loss Detector MAY also be implemented in one or more entities different from the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. TOM (1): ..same entity as what? i guess you mean the DS? TOM (2): I do not understand how you associate the port k to a loss detecto= r.. what do you mean with that? section 3 (..) In order to detect packet loss before the receivers perceive it, one or more intermediate nodes are placed between the media source and receiver (e.g., Distribution server, MCU, RTP translator). These intermediaries monitor for packet loss upstream of themselves by checking RTP sequence numbers, just as receivers do. Upon detecting (or suspecting) an upstream loss, the intermediary may send Feedback Suppression message towards the receivers as defined in this specification. TOM (3) : ...based on the two above definitions ...is an intermediate node = hence equal to a "Loss detector"? + How does a Loss detector differ from an RTP receiver? Section 6.1 In order to avoid the forms of NACK implosion described in section 1, the Loss Detector is introduced. The Loss Detector detects and reports packet loss, on both the upstream link and the downstream aggregate link. How the loss detector SHOULD detect the packet loss is beyond of scope of this document. When upstream link or downstream aggregate link packet loss occurs, the Loss Detector MAY inform distribution source of the detected packet loss using Feedback Suppression messages. In response, the distribution source either forwards packet loss suppression report received from Loss Detector or creates a Feedback Suppression report and sends it to all the RTP receivers, over the multicast channel. This loss suppression report tells the receivers that the lost packet will either be forthcoming from distribution source, or it irretrievably lost such that there is nothing to be gained by the receiver sending a NACK to the media source. The distribution source then can (optionally) ask for the lost packets from the media source on behalf of all the RTP receivers. TOM (4) : You probably do not want to have normative language in section 6.= 1, like "How the loss detector SHOULD (..)". TOM (5) : It is pretty clear how a Loss detector will detect packet loss on= its upstream link, I guess. TOM (6): What is the rationale for a loss detector to send a Feedback supp= ression message to the DS.. why NOT a RTCP NACK FB? Section 6.1.1 If there are multiple Loss Detectors looking at the same RTP stream, then the loss may be identified by more than one and those detecting the loss will all send requests for the same packet loss. In this case, the distribution source MUST filter the duplicated packet loss request out and only forward one copy of the RTCP Feedback report packet from the first Loss Detector to the group impacted by packet loss. TOM (7) : how will the DS send only a copy of the RTCP FB report packet to = the group impacted by packet loss. Is this done over the SSM? In your example you seem to focus only on architectures with a DS which als= o hosts the FT and the loss reporter. There should be sections covering ca= ses where the DS is disjoint from the FT, with several FTs and also several= loss reporters disjoint from the FT and the DS. TOM (8) : what do you mean in above text with "RTCP FB report".. is that th= e suppression message you define in this draft? TOM (9) : In section "6.1.2. Distribution Source Feedback Summary Model" = it is not clear what your architecture looks like. You talk about multiple = distribution sources.. whcih implies multiple SSMs.. Can you elaborate on t= hat? Tom (10) : In section 6.3. Multipoint Control Unit (MCU) use case, typi= cally an overlay of unicast is used... will the Feedback suppression messag= e be sent over unicast as well? If so, what is gain compared to just having= each RTCP receiver providing each their NACK to the MCU, even in case of a= packet loss impacting all receivers? Tom (11) : coming back to my previous comment on SDP description in this dr= aft : if this draft defines a RTCP feedback suppression message, why is the= re need for a "announcement" in the SDP for the receivers, that indicates t= hey may receive such feedback suppression messages? If a receiver supports= the message, it will simply act accordingly as described in the draft, no= need to announce that!.. Regards Tom --_000_EC3FD58E75D43A4F8807FDE0749175460E4373DDFRMRSSXCHMBSB1d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Qin,
 
I have = some=20 comments (look for TOM below) on the new draft version 4.
Thx for= addressing=20 them,
Tom
 
 
Section= 2=20 Terminology
 Loss Detector:

      The Loss Detector is one logical function which is used to detect
      the packet loss at the RTP layer and report it to the distribution
      source.  The function of the loss reporter may be collocated with
      or integrated into the same entity.  In this case, for a session
      defined as having a distribution source A, on ports n for the RTP
      channel and k for the RTCP channel, the Loss Detector are
      identified by an IP address of distribution source A on port k.
      The Loss Detector MAY also be implemented in one or more entities
      different from the distribution source.

 The function of the loss reporter may be collocated with
      or integrated into the same entity.
TOM (1): ..same entit=
y as what? i guess you mean the DS?
TOM (2): I do not understan=
d how you associate the port k to a loss detector.. what do you mean with t=
hat?
 
section 3
=
 
(..)
In order to detect packet loss before the receive=
rs perceive it, one
   or more intermediate nodes are placed between the media source and
   receiver (e.g., Distribution server, MCU, RTP translator).  These
   intermediaries monitor for packet loss upstream of themselves by
   checking RTP sequence numbers, just as receivers do.  Upon detecting
   (or suspecting) an upstream loss, the intermediary may send Feedback
   Suppression message towards the receivers as defined in this
   specification.
TOM (3) : ...based on the two above definitions=20 ...is an intermediate node hence equal to a "Loss=  detector"? =20
+ How does a Loss detector differ from an RTP=20 receiver?
 
Section= =20 6.1
In order to avoid=
 the forms of NACK implosion described in section 1,
   the Loss Detector is introduced.  The Loss Detector detects and
   reports packet loss, on both the upstream link and the downstream
   aggregate link.  How the loss detector SHOULD detect the packet loss
   is beyond of scope of this document.  When upstream link or
   downstream aggregate link packet loss occurs, the Loss Detector MAY
   inform distribution source of the detected packet loss using Feedback
   Suppression messages.  In response, the distribution source either
   forwards packet loss suppression report received from Loss Detector
   or creates a Feedback Suppression report and sends it to all the RTP
   receivers, over the multicast channel.  This loss suppression report
   tells the receivers that the lost packet will either be forthcoming
   from distribution source, or it irretrievably lost such that there is
   nothing to be gained by the receiver sending a NACK to the media
   source.  The distribution source then can (optionally) ask for the
   lost packets from the media source on behalf of all the RTP
   receivers.
TOM (4) : =
You probably do not want to have normative language in section 6.1, like "H=
ow the loss detector SHOULD (..)". 
TOM (5) :=
 It is pretty clear how a Loss detector will detect packet loss on its upst=
ream link, I guess.
TOM (6):  What is the rationale for =
a loss detector to send a Feedback suppression message to the DS.. why NOT =
a RTCP NACK FB?
 
Section 6.1.1
=
If there are multiple Loss Detectors looking at the same RTP stream,
   then the loss may be identified by more than one and those detecting
   the loss will all send requests for the same packet loss.  In this
   case, the distribution source MUST filter the duplicated packet loss
   request out and only forward one copy of the RTCP Feedback report
   packet from the first Loss Detector to the group impacted by packet
   loss.
TOM (7)= : how will=20 the DS send only a copy of the RTCP FB report packet to the group impacted = by=20 packet loss. Is this done over the SSM?
 
In your= example=20 you seem to focus only on architectures with a DS which also hosts the FT a= nd=20 the loss reporter.  There should be sections covering cases where the = DS is=20 disjoint from the FT, with several FTs and also several loss reporters disj= oint=20 from the FT and the DS.
 
TOM (8)= : what do=20 you mean in above text with "RTCP FB report".. is that the suppression mess= age=20 you define in this draft?
 
TOM (9)= : In=20 section  "6.1.2.  Distribution Source Feedback Summary Model" it = is=20 not clear what your architecture looks like. You talk about multiple=20 distribution sources.. whcih implies multiple SSMs.. Can you elaborate on=20 that?
 
Tom (10= ) : =20 In section  6.3.  Multipoint Control Unit (MCU) use case, =20 typically an overlay of unicast is used... will the Feedback suppression me= ssage=20 be sent over unicast as well? If so, what is gain compared to just having e= ach=20 RTCP receiver providing each their NACK to the MCU, even in case of a packe= t=20 loss impacting all receivers?
 
Tom (11= ) : coming=20 back to my previous comment on SDP description in this draft : if= this=20 draft defines a RTCP feedback suppression message, why is there need for a= =20 "announcement" in the SDP for the receivers, that indicates they may receiv= e=20 such feedback suppression messages?  If a receiver supports the messag= e, it=20 will  simply act accordingly as described in the draft, no need t= o=20 announce that!..
 
Regards
Tom
 
 
 
 
--_000_EC3FD58E75D43A4F8807FDE0749175460E4373DDFRMRSSXCHMBSB1d_-- From feher@tmit.bme.hu Mon Oct 18 16:25:25 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5173A6B17 for ; Mon, 18 Oct 2010 16:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wqu386NijhJE for ; Mon, 18 Oct 2010 16:25:24 -0700 (PDT) Received: from ruby.tmit.bme.hu (ruby.tmit.bme.hu [152.66.245.193]) by core3.amsl.com (Postfix) with ESMTP id 6C86C3A6AB6 for ; Mon, 18 Oct 2010 16:25:24 -0700 (PDT) Received: from anyo.tmit.bme.hu (anyo.tmit.bme.hu [152.66.246.7]) by ruby.tmit.bme.hu (Postfix) with ESMTP id 5FAD387344 for ; Tue, 19 Oct 2010 01:26:51 +0200 (CEST) Received: from [192.168.2.223] (94-21-43-9.pool.digikabel.hu [94.21.43.9]) (authenticated bits=0) by anyo.tmit.bme.hu (8.13.8/8.13.8/Debian-3) with ESMTP id o9INQqWN003614 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Oct 2010 01:26:52 +0200 Message-ID: <4CBCD7BB.7020700@tmit.bme.hu> Date: Tue, 19 Oct 2010 01:26:51 +0200 From: =?ISO-8859-1?Q?Feh=E9r_G=E1bor?= Organization: TMIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: avt@ietf.org Content-Type: multipart/alternative; boundary="------------000901000704080706060409" Subject: [AVT] Request for review: Approximate authentication in SRTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 23:25:25 -0000 This is a multi-part message in MIME format. --------------000901000704080706060409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear AVT experts! Today I have uploaded an initial draft "Using approximate authentication with Secure Real-time Transport Protocol (SRTP)" http://www.ietf.org/id/draft-feher-avt-approx-auth-srtp-00.txt I'm a new member of this mailing list, but during the past years I already get know RFCs coming from this workgroup. I use some of them. I'm working on a university and we do research on audio video transmission over wireless networks. We consider SRTP for content protection. However, unfortunately the current SRTP authentication algorithm (HMAC-SHA1) is inappropriate on wireless channels where there are natural bit errors. In RFC3711, SRTP allows to use a weak authentication in some scenarios. Approximate authentication is a weak authentication, but in other hand it is also a solution to have secure (even it is not fully secure) audio and video transmission over error-prone channels. The draft I have uploded describes a kind of framework, how to use an approximate authentication algorithm within SRTP. There is the definition, how to calculate the authentication tag and you can also find other requirements regarding the encryption, key derivation, etc.. It is intentional, that I suggest no particular approximate authentication algorithm in this draft. I plan to submit a draft later, when we all agree on the basics of approximate authentication usage inside SRTP. In the references you can find publications regarding approximate authentication. Please write your comments! I use/teach SRTP for over 5 years and I always thought that approximate authentication is missing. I would like to contribute to it. Also, I would like to give a short presentation related to the draft in Bejing. Best Regards, Gabor Feher --------------000901000704080706060409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear AVT experts!

Today I have uploaded an initial draft "Using approximate authentication with Secure Real-time Transport Protocol (SRTP)"
http://www.ietf.org/id/draft-feher-avt-approx-auth-srtp-00.txt

I'm a new member of this mailing list, but during the past years I already get know RFCs coming from this workgroup. I use some of them.

I'm working on a university and we do research on audio video transmission over wireless networks. We consider SRTP for content protection. However, unfortunately the current SRTP authentication algorithm (HMAC-SHA1) is inappropriate on wireless channels where there are natural bit errors. In RFC3711, SRTP allows to use a weak authentication in some scenarios. Approximate authentication is a weak authentication, but in other hand it is also a solution to have secure (even it is not fully secure) audio and video transmission over error-prone channels.

The draft I have uploded describes a kind of framework, how to use an approximate authentication algorithm within SRTP. There is the definition, how to calculate the authentication tag and you can also find other requirements regarding the encryption, key derivation, etc.. It is intentional, that I suggest no particular approximate authentication algorithm in this draft. I plan to submit a draft later, when we all agree on the basics of approximate authentication usage inside SRTP. In the references you can find publications regarding approximate authentication.

Please write your comments! I use/teach SRTP for over 5 years and I always thought that approximate authentication is missing. I would like to contribute to it. Also, I would like to give a short presentation related to the draft in Bejing.

Best Regards,
Gabor Feher
--------------000901000704080706060409-- From Even.roni@huawei.com Mon Oct 18 16:35:57 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803133A6BF6 for ; Mon, 18 Oct 2010 16:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.385 X-Spam-Level: X-Spam-Status: No, score=-99.385 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2PybeOoWRJZ for ; Mon, 18 Oct 2010 16:35:55 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 03E763A6B17 for ; Mon, 18 Oct 2010 16:35:55 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAI003NUEY2MZ@szxga04-in.huawei.com> for avt@ietf.org; Tue, 19 Oct 2010 07:37:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAI00ESQEY1NN@szxga04-in.huawei.com> for avt@ietf.org; Tue, 19 Oct 2010 07:37:13 +0800 (CST) Received: from windows8d787f9 ([109.66.23.7]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAI0047LEXTRS@szxml01-in.huawei.com>; Tue, 19 Oct 2010 07:37:13 +0800 (CST) Date: Tue, 19 Oct 2010 01:34:02 +0200 From: Roni Even In-reply-to: <4CBCD7BB.7020700@tmit.bme.hu> To: =?ISO-8859-1?Q?'Feh=E9r_G=E1bor'?= , avt@ietf.org Message-id: <037201cb6f1c$f7e92410$e7bb6c30$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_o/6VXr3iteosDFGJMmwnFA)" Content-language: en-us Thread-index: ActvG/s7tNKNHHdgRfCHgNITYdDLvgAANXvw References: <4CBCD7BB.7020700@tmit.bme.hu> Subject: Re: [AVT] Request for review: Approximate authentication in SRTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 23:35:57 -0000 This is a multi-part message in MIME format. --Boundary_(ID_o/6VXr3iteosDFGJMmwnFA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi, I will look at the draft and I noted your request for agenda time in Beijing Roni Even AVT co-chair From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Feh?r G?bor Sent: Tuesday, October 19, 2010 1:27 AM To: avt@ietf.org Subject: [AVT] Request for review: Approximate authentication in SRTP Dear AVT experts! Today I have uploaded an initial draft "Using approximate authentication with Secure Real-time Transport Protocol (SRTP)" http://www.ietf.org/id/draft-feher-avt-approx-auth-srtp-00.txt I'm a new member of this mailing list, but during the past years I already get know RFCs coming from this workgroup. I use some of them. I'm working on a university and we do research on audio video transmission over wireless networks. We consider SRTP for content protection. However, unfortunately the current SRTP authentication algorithm (HMAC-SHA1) is inappropriate on wireless channels where there are natural bit errors. In RFC3711, SRTP allows to use a weak authentication in some scenarios. Approximate authentication is a weak authentication, but in other hand it is also a solution to have secure (even it is not fully secure) audio and video transmission over error-prone channels. The draft I have uploded describes a kind of framework, how to use an approximate authentication algorithm within SRTP. There is the definition, how to calculate the authentication tag and you can also find other requirements regarding the encryption, key derivation, etc.. It is intentional, that I suggest no particular approximate authentication algorithm in this draft. I plan to submit a draft later, when we all agree on the basics of approximate authentication usage inside SRTP. In the references you can find publications regarding approximate authentication. Please write your comments! I use/teach SRTP for over 5 years and I always thought that approximate authentication is missing. I would like to contribute to it. Also, I would like to give a short presentation related to the draft in Bejing. Best Regards, Gabor Feher --Boundary_(ID_o/6VXr3iteosDFGJMmwnFA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT

Hi,

I will look at the draft and I noted your request for agenda time in Beijing

Roni Even

AVT co-chair

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Feh?r G?bor
Sent: Tuesday, October 19, 2010 1:27 AM
To: avt@ietf.org
Subject: [AVT] Request for review: Approximate authentication in SRTP

 

Dear AVT experts!

Today I have uploaded an initial draft "Using approximate authentication with Secure Real-time Transport Protocol (SRTP)"
http://www.ietf.org/id/draft-feher-avt-approx-auth-srtp-00.txt

I'm a new member of this mailing list, but during the past years I already get know RFCs coming from this workgroup. I use some of them.

I'm working on a university and we do research on audio video transmission over wireless networks. We consider SRTP for content protection. However, unfortunately the current SRTP authentication algorithm (HMAC-SHA1) is inappropriate on wireless channels where there are natural bit errors. In RFC3711, SRTP allows to use a weak authentication in some scenarios. Approximate authentication is a weak authentication, but in other hand it is also a solution to have secure (even it is not fully secure) audio and video transmission over error-prone channels.

The draft I have uploded describes a kind of framework, how to use an approximate authentication algorithm within SRTP. There is the definition, how to calculate the authentication tag and you can also find other requirements regarding the encryption, key derivation, etc.. It is intentional, that I suggest no particular approximate authentication algorithm in this draft. I plan to submit a draft later, when we all agree on the basics of approximate authentication usage inside SRTP. In the references you can find publications regarding approximate authentication.

Please write your comments! I use/teach SRTP for over 5 years and I always thought that approximate authentication is missing. I would like to contribute to it. Also, I would like to give a short presentation related to the draft in Bejing.

Best Regards,
Gabor Feher

--Boundary_(ID_o/6VXr3iteosDFGJMmwnFA)-- From sunseawq@huawei.com Mon Oct 18 20:02:50 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB553A6A01 for ; Mon, 18 Oct 2010 20:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.282 X-Spam-Level: **** X-Spam-Status: No, score=4.282 tagged_above=-999 required=5 tests=[AWL=-3.558, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_93=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgCtkBfPxAYy for ; Mon, 18 Oct 2010 20:02:48 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 82F603A6A84 for ; Mon, 18 Oct 2010 20:02:47 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAI00GGROIUPT@szxga02-in.huawei.com> for avt@ietf.org; Tue, 19 Oct 2010 11:04:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAI00B1JOIUEE@szxga02-in.huawei.com> for avt@ietf.org; Tue, 19 Oct 2010 11:04:06 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAI00271OIT1R@szxml06-in.huawei.com> for avt@ietf.org; Tue, 19 Oct 2010 11:04:06 +0800 (CST) Date: Tue, 19 Oct 2010 11:04:05 +0800 From: Qin Wu To: "Van Caenegem, Tom (Tom)" , avt@ietf.org Message-id: <048601cb6f3a$4a973180$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_DSXGJOuvniJMGX3vD9vlJw)" X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 03:02:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_DSXGJOuvniJMGX3vD9vlJw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Tom: Thank for your comments, please see my reply inline. Regards! -Qin ----- Original Message ----- From: Van Caenegem, Tom (Tom) To: avt@ietf.org ; Qin Wu Sent: Tuesday, October 19, 2010 12:08 AM Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 Hi Qin, I have some comments (look for TOM below) on the new draft version 4. Thx for addressing them, Tom Section 2 Terminology Loss Detector: The Loss Detector is one logical function which is used to detect the packet loss at the RTP layer and report it to the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. In this case, for a session defined as having a distribution source A, on ports n for the RTP channel and k for the RTCP channel, the Loss Detector are identified by an IP address of distribution source A on port k. The Loss Detector MAY also be implemented in one or more entities different from the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity.TOM (1): ..same entity as what? i guess you mean the DS?[Qin]: Your are right. In this draft, the loss detector is just functionality of DS. Furthermore we only consider the loss detector as part of feedback target within the distribution source.Also this is just one example use case to explain how feedback suppression works in SSM use case.TOM (2): I do not understand how you associate the port k to a loss detector.. what do you mean with that?[Qin]: Sorry for ambiguity of the description here. It actually means that the loss reporter is part of feedback target and share the same address and port.section 3 (..)In order to detect packet loss before the receivers perceive it, one or more intermediate nodes are placed between the media source and receiver (e.g., Distribution server, MCU, RTP translator). These intermediaries monitor for packet loss upstream of themselves by checking RTP sequence numbers, just as receivers do. Upon detecting (or suspecting) an upstream loss, the intermediary may send Feedback Suppression message towards the receivers as defined in this specification. TOM (3) : ...based on the two above definitions ...is an intermediate node hence equal to a "Loss detector"? + How does a Loss detector differ from an RTP receiver? [Qin]: The loss detector is just one functionality of Distribution Source in the SSM use case. Maybe we should interpret it as "Loss detection functionality". How the packet loss is detected is out of scope of this document. Different from dedicated RTP receiver, the intermediate node does not depend on existing NACK message for Retransmission request for packet loss. the intermediate node can create message by itself. Section 6.1 In order to avoid the forms of NACK implosion described in section 1, the Loss Detector is introduced. The Loss Detector detects and reports packet loss, on both the upstream link and the downstream aggregate link. How the loss detector SHOULD detect the packet loss is beyond of scope of this document. When upstream link or downstream aggregate link packet loss occurs, the Loss Detector MAY inform distribution source of the detected packet loss using Feedback Suppression messages. In response, the distribution source either forwards packet loss suppression report received from Loss Detector or creates a Feedback Suppression report and sends it to all the RTP receivers, over the multicast channel. This loss suppression report tells the receivers that the lost packet will either be forthcoming from distribution source, or it irretrievably lost such that there is nothing to be gained by the receiver sending a NACK to the media source. The distribution source then can (optionally) ask for the lost packets from the media source on behalf of all the RTP receivers.TOM (4) : You probably do not want to have normative language in section 6.1, like "How the loss detector SHOULD (..)". [Qin]:Sorry, I can't get it.TOM (5) : It is pretty clear how a Loss detector will detect packet loss on its upstream link, I guess.[Qin]: As I said above, Loss detector is just functionality of some Distribution sources. Also what it said here in section 6.1 is just one example use case.TOM (6): What is the rationale for a loss detector to send a Feedback suppression message to the DS.. why NOT a RTCP NACK FB?[Qin]: As I explained in the last IETF presentaion, this cause NACK scematics mismatch. That's why many people in the last IETF meeeting suggest to create new RTCP message during presentation.Section 6.1.1If there are multiple Loss Detectors looking at the same RTP stream, then the loss may be identified by more than one and those detecting the loss will all send requests for the same packet loss. In this case, the distribution source MUST filter the duplicated packet loss request out and only forward one copy of the RTCP Feedback report packet from the first Loss Detector to the group impacted by packet loss. TOM (7) : how will the DS send only a copy of the RTCP FB report packet to the group impacted by packet loss. Is this done over the SSM? [Qin]: Sorry, maybe I sould say " Section 6.1.1 If there are multiple Distrbitution Source with the loss detection support looking at the same RTP stream..... " Yes, in the SSM use case, DS send only a copy of the RTCP Feedback Suppression Report packet the group via SSM. In your example you seem to focus only on architectures with a DS which also hosts the FT and the loss reporter. There should be sections covering cases where the DS is disjoint from the FT, with several FTs and also several loss reporters disjoint from the FT and the DS. [Qin] I am not sure we need to address all the possible SSM use cases. In this draft, we just give some examples of SSM use case. TOM (8) : what do you mean in above text with "RTCP FB report".. is that the suppression message you define in this draft? [Qin]: Yes, RTCP Feedback Suppression Report. TOM (9) : In section "6.1.2. Distribution Source Feedback Summary Model" it is not clear what your architecture looks like. You talk about multiple distribution sources.. whcih implies multiple SSMs.. Can you elaborate on that? [Qin]: The scenario we are talking about in the section 6.1.2, is to allow multiple Distrbituion source between media source and the receiver. I will look at the this case as one special SSM case. because each of distrbituion source resides at the upstream direction or downstream direction of other distributions souces. Does it make sense? Tom (10) : In section 6.3. Multipoint Control Unit (MCU) use case, typically an overlay of unicast is used... will the Feedback suppression message be sent over unicast as well? If so, what is gain compared to just having each RTCP receiver providing each their NACK to the MCU, even in case of a packet loss impacting all receivers? [Qin]: First The MCU case will not cause NACK Implosion, instead, it may cause FIR implosion. Second, using Feedback suppression message can restrict the FIR message sent from receivers behind MCU and liberate the media source from FIR implosion. Tom (11) : coming back to my previous comment on SDP description in this draft : if this draft defines a RTCP feedback suppression message, why is there need for a "announcement" in the SDP for the receivers, that indicates they may receive such feedback suppression messages? If a receiver supports the message, it will simply act accordingly as described in the draft, no need to announce that!.. [Qin]: Okay, I get your point. I would like to put this as open issue, discuss it in the face to face IETF meeting. Regards Tom --Boundary_(ID_DSXGJOuvniJMGX3vD9vlJw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xODkyOCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2NjZThjZj4NCjxESVY+SGksIFRvbTo8L0RJVj4NCjxESVY+VGhh bmsgZm9yIHlvdXIgY29tbWVudHMsIHBsZWFzZSBzZWUgbXkgcmVwbHkgaW5saW5lLjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UmVnYXJkcyE8L0RJVj4NCjxESVY+LVFpbjwvRElWPg0K PEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURE SU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJH SU4tUklHSFQ6IDBweCIgDQpkaXI9bHRyPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQz NTsmIzIwMzA3OyI+PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+LS0tLS0gT3Jp Z2luYWwgDQogIE1lc3NhZ2UgLS0tLS0gPC9GT05UPjwvRElWPg0KICA8RElWIHN0eWxlPSJGT05U OiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgQkFDS0dST1VORDogI2U0ZTRlNDsgZm9udC1jb2xvcjog YmxhY2siPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIHNpemU9Mz48Qj5G cm9tOjwvQj4gPC9GT05UPjwvRk9OVD48QSANCiAgdGl0bGU9dG9tLnZhbl9jYWVuZWdlbUBhbGNh dGVsLWx1Y2VudC5jb20gDQogIGhyZWY9Im1haWx0bzp0b20udmFuX2NhZW5lZ2VtQGFsY2F0ZWwt bHVjZW50LmNvbSI+PEZPTlQgc2l6ZT0zIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlZhbiBD YWVuZWdlbSwgVG9tIChUb20pPC9GT05UPjwvQT48Rk9OVCBzaXplPTMgDQogIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+IDwvRk9OVD48L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzsiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEZPTlQgc2l6ZT0zPjxC PlRvOjwvQj4gDQogIDwvRk9OVD48L0ZPTlQ+PEEgdGl0bGU9YXZ0QGlldGYub3JnIGhyZWY9Im1h aWx0bzphdnRAaWV0Zi5vcmciPjxGT05UIHNpemU9MyANCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij5hdnRAaWV0Zi5vcmc8L0ZPTlQ+PC9BPjxGT05UIHNpemU9MyANCiAgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4gOyA8L0ZPTlQ+PEEgdGl0bGU9c3Vuc2Vhd3FAaHVhd2VpLmNvbSANCiAgaHJlZj0i bWFpbHRvOnN1bnNlYXdxQGh1YXdlaS5jb20iPjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPlFpbiANCiAgV3U8L0ZPTlQ+PC9BPjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPiA8L0ZPTlQ+PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYj MjAzMDc7Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIA0KICBzaXplPTM+PEI+ U2VudDo8L0I+IFR1ZXNkYXksIE9jdG9iZXIgMTksIDIwMTAgMTI6MDggQU08L0ZPTlQ+PC9GT05U PjwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCANCiAgc2l6ZT0zPjxCPlN1YmplY3Q6PC9CPiBS ZTogW0FWVF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCiAgZHJhZnQtd3UtYXZ0LXJl dHJhbnNtaXNzaW9uLXN1cHJlc3Npb24tcnRwLTA0PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgPERJ Vj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD48QlI+PC9ESVY+DQog IDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPkhpIFFpbiw8L1NQQU4+PC9ESVY+ DQogIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjwvU1BBTj4mbmJzcDs8L0RJ Vj4NCiAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+SSBoYXZlIHNvbWUgY29t bWVudHMgKGxvb2sgZm9yIFRPTSBiZWxvdykgDQogIG9uIHRoZSBuZXcgZHJhZnQgdmVyc2lvbiA0 LjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+VGh4 IGZvciBhZGRyZXNzaW5nIHRoZW0sPC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTIz NzA1MTAxMy0xODEwMjAxMD5Ub208L1NQQU4+PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQog IDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEw PlNlY3Rpb24gMiBUZXJtaW5vbG9neTwvU1BBTj48L0RJVj4NCiAgPERJVj48UFJFPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+IExvc3MgRGV0ZWN0b3I6DQoNCiAgICAgIFRoZSBMb3NzIERl dGVjdG9yIGlzIG9uZSBsb2dpY2FsIGZ1bmN0aW9uIHdoaWNoIGlzIHVzZWQgdG8gZGV0ZWN0DQog ICAgICB0aGUgcGFja2V0IGxvc3MgYXQgdGhlIFJUUCBsYXllciBhbmQgcmVwb3J0IGl0IHRvIHRo ZSBkaXN0cmlidXRpb24NCiAgICAgIHNvdXJjZS4gIFRoZSBmdW5jdGlvbiBvZiB0aGUgbG9zcyBy ZXBvcnRlciBtYXkgYmUgY29sbG9jYXRlZCB3aXRoDQogICAgICBvciBpbnRlZ3JhdGVkIGludG8g dGhlIHNhbWUgZW50aXR5LiAgSW4gdGhpcyBjYXNlLCBmb3IgYSBzZXNzaW9uDQogICAgICBkZWZp bmVkIGFzIGhhdmluZyBhIGRpc3RyaWJ1dGlvbiBzb3VyY2UgQSwgb24gcG9ydHMgbiBmb3IgdGhl IFJUUA0KICAgICAgY2hhbm5lbCBhbmQgayBmb3IgdGhlIFJUQ1AgY2hhbm5lbCwgdGhlIExvc3Mg RGV0ZWN0b3IgYXJlDQogICAgICBpZGVudGlmaWVkIGJ5IGFuIElQIGFkZHJlc3Mgb2YgZGlzdHJp YnV0aW9uIHNvdXJjZSBBIG9uIHBvcnQgay4NCiAgICAgIFRoZSBMb3NzIERldGVjdG9yIE1BWSBh bHNvIGJlIGltcGxlbWVudGVkIGluIG9uZSBvciBtb3JlIGVudGl0aWVzDQogICAgICBkaWZmZXJl bnQgZnJvbSB0aGUgZGlzdHJpYnV0aW9uIHNvdXJjZS4NCjwvRk9OVD48L1BSRT48UFJFPjxTUEFO IGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiBU aGUgZnVuY3Rpb24gb2YgdGhlIGxvc3MgcmVwb3J0ZXIgbWF5IGJlIGNvbGxvY2F0ZWQgd2l0aA0K ICAgICAgb3IgaW50ZWdyYXRlZCBpbnRvIHRoZSBzYW1lIGVudGl0eS48L0ZPTlQ+PC9TUEFOPjwv UFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+VE9NICgxKTogLi5zYW1lIGVudGl0eSBhcyB3aGF0PyBpIGd1ZXNzIHlvdSBt ZWFuIHRoZSBEUz88L0ZPTlQ+PC9TUEFOPjwvUFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEz LTE4MTAyMDEwPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+W1Fpbl06IFlvdXIgYXJlIHJp Z2h0LiAgSW4gdGhpcyBkcmFmdCwgdGhlIGxvc3MgZGV0ZWN0b3IgaXMganVzdCBmdW5jdGlvbmFs aXR5IG9mIERTLiAgRnVydGhlcm1vcmUgd2Ugb25seSBjb25zaWRlciB0aGUgbG9zcyBkZXRlY3Rv ciBhcyBwYXJ0IG9mIGZlZWRiYWNrIHRhcmdldCB3aXRoaW4gdGhlIGRpc3RyaWJ1dGlvbiBzb3Vy Y2UuPC9GT05UPjwvU1BBTj48L1BSRT48UFJFPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAx MD48L1NQQU4+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+QWxzbyB0aGlzIGlzIGp1c3Qgb25lIGV4YW1wbGUgdXNlIGNhc2UgdG8gZXhw bGFpbiBob3cgZmVlZGJhY2sgc3VwcHJlc3Npb24gd29ya3MgaW4gU1NNIHVzZSBjYXNlLjwvRk9O VD48L1NQQU4+PC9QUkU+PFBSRT48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UT00gKDIpOiBJIGRvIG5vdCB1bmRlcnN0YW5kIGhvdyB5 b3UgYXNzb2NpYXRlIHRoZSBwb3J0IGsgdG8gYSBsb3NzIGRldGVjdG9yLi4gd2hhdCBkbyB5b3Ug bWVhbiB3aXRoIHRoYXQ/PC9GT05UPjwvU1BBTj48L1BSRT48UFJFPjxTUEFOIGNsYXNzPTIzNzA1 MTAxMy0xODEwMjAxMD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltRaW5dOiAgU29ycnkg Zm9yIGFtYmlndWl0eSBvZiB0aGUgZGVzY3JpcHRpb24gaGVyZS4gSXQgYWN0dWFsbHkgbWVhbnMg dGhhdCB0aGUgbG9zcyByZXBvcnRlciBpcyBwYXJ0IG9mIGZlZWRiYWNrIHRhcmdldCBhbmQgc2hh cmUgdGhlIHNhbWUgYWRkcmVzcyBhbmQgcG9ydC48L0ZPTlQ+PC9TUEFOPjwvUFJFPjxQUkU+PFBS RT48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj5zZWN0aW9uIDM8L0ZPTlQ+PC9TUEFOPjwvUFJFPjxQUkU+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbmJzcDs8L0ZPTlQ+PC9QUkU+PFBSRT48U1BBTiBjbGFzcz0yMzcwNTEwMTMt MTgxMDIwMTA+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4oLi4pPC9GT05UPjwvU1BBTj48 L1BSRT48UFJFPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SW4gb3JkZXIgdG8gZGV0ZWN0 IHBhY2tldCBsb3NzIGJlZm9yZSB0aGUgcmVjZWl2ZXJzIHBlcmNlaXZlIGl0LCBvbmUNCiAgIG9y IG1vcmUgaW50ZXJtZWRpYXRlIG5vZGVzIGFyZSBwbGFjZWQgYmV0d2VlbiB0aGUgbWVkaWEgc291 cmNlIGFuZA0KICAgcmVjZWl2ZXIgKGUuZy4sIERpc3RyaWJ1dGlvbiBzZXJ2ZXIsIE1DVSwgUlRQ IHRyYW5zbGF0b3IpLiAgVGhlc2UNCiAgIGludGVybWVkaWFyaWVzIG1vbml0b3IgZm9yIHBhY2tl dCBsb3NzIHVwc3RyZWFtIG9mIHRoZW1zZWx2ZXMgYnkNCiAgIGNoZWNraW5nIFJUUCBzZXF1ZW5j ZSBudW1iZXJzLCBqdXN0IGFzIHJlY2VpdmVycyBkby4gIFVwb24gZGV0ZWN0aW5nDQogICAob3Ig c3VzcGVjdGluZykgYW4gdXBzdHJlYW0gbG9zcywgdGhlIGludGVybWVkaWFyeSBtYXkgc2VuZCBG ZWVkYmFjaw0KICAgU3VwcHJlc3Npb24gbWVzc2FnZSB0b3dhcmRzIHRoZSByZWNlaXZlcnMgYXMg ZGVmaW5lZCBpbiB0aGlzDQogICBzcGVjaWZpY2F0aW9uLg0KPC9GT05UPjwvUFJFPjwvUFJFPjwv RElWPg0KICA8RElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9ydGYgZm9ybWF0IC0tPjxTUEFO PlRPTSAoMykgDQogIDwvU1BBTj46Jm5ic3A7Li4uPFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAy MDEwPmJhc2VkIG9uIHRoZSB0d28gYWJvdmUgDQogIGRlZmluaXRpb25zIC4uLjwvU1BBTj5pcyZu YnNwO2FuJm5ic3A7aW50ZXJtZWRpYXRlJm5ic3A7bm9kZSZuYnNwO2g8U1BBTiANCiAgY2xhc3M9 MjM3MDUxMDEzLTE4MTAyMDEwPmU8L1NQQU4+bmNlJm5ic3A7ZXF1YWwmbmJzcDt0byZuYnNwO2Em bmJzcDsiTG9zcyZuYnNwO2RldGVjdG9yIj8mbmJzcDsgDQogIDwvRElWPg0KICA8RElWPjxTUEFO IGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48L1NQQU4+PFNQQU4gDQogIGNsYXNzPTIzNzA1MTAx My0xODEwMjAxMD48L1NQQU4+KzxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD4gSG93IGRv ZXMgYSANCiAgTG9zcyBkZXRlY3RvciBkaWZmZXIgZnJvbSBhbiBSVFAgcmVjZWl2ZXI/PC9TUEFO PjwvRElWPjxTUEFOIA0KICBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PC9TUEFOPjwvQkxPQ0tR VU9URT4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xp ZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVw eDsgTUFSR0lOLVJJR0hUOiAwcHgiIA0KZGlyPWx0cj4NCiAgPERJVj48U1BBTiBjbGFzcz0yMzcw NTEwMTMtMTgxMDIwMTA+W1Fpbl06IFRoZSBsb3NzIGRldGVjdG9yIGlzIGp1c3Qgb25lIA0KICBm dW5jdGlvbmFsaXR5IG9mIERpc3RyaWJ1dGlvbiBTb3VyY2UgaW4gdGhlIFNTTSB1c2UgY2FzZS48 L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPk1heWJl IHdlIHNob3VsZCZuYnNwO2ludGVycHJldCBpdCBhcyAiTG9zcyANCiAgZGV0ZWN0aW9uIGZ1bmN0 aW9uYWxpdHkiLiBIb3cgdGhlIHBhY2tldCBsb3NzIGlzIGRldGVjdGVkIGlzIG91dCBvZiBzY29w ZSBvZiANCiAgdGhpcyBkb2N1bWVudC48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9 MjM3MDUxMDEzLTE4MTAyMDEwPkRpZmZlcmVudCBmcm9tIGRlZGljYXRlZCBSVFAgcmVjZWl2ZXIs IHRoZSANCiAgaW50ZXJtZWRpYXRlIG5vZGUgZG9lcyBub3QgZGVwZW5kIG9uIGV4aXN0aW5nIE5B Q0sgbWVzc2FnZSBmb3IgUmV0cmFuc21pc3Npb24gDQogIHJlcXVlc3QgZm9yIHBhY2tldCBsb3Nz LjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+dGhl IGludGVybWVkaWF0ZSBub2RlIGNhbiBjcmVhdGUgbWVzc2FnZSANCiAgYnkgaXRzZWxmLjwvU1BB Tj48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEw MTMtMTgxMDIwMTA+U2VjdGlvbiA2LjE8L1NQQU4+PC9ESVY+PFBSRT48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPkluIG9yZGVyIHRvIGF2b2lkIHRoZSBmb3JtcyBvZiBOQUNLIGltcGxvc2lv biBkZXNjcmliZWQgaW4gc2VjdGlvbiAxLA0KICAgdGhlIExvc3MgRGV0ZWN0b3IgaXMgaW50cm9k dWNlZC4gIFRoZSBMb3NzIERldGVjdG9yIGRldGVjdHMgYW5kDQogICByZXBvcnRzIHBhY2tldCBs b3NzLCBvbiBib3RoIHRoZSB1cHN0cmVhbSBsaW5rIGFuZCB0aGUgZG93bnN0cmVhbQ0KICAgYWdn cmVnYXRlIGxpbmsuICBIb3cgdGhlIGxvc3MgZGV0ZWN0b3IgU0hPVUxEIGRldGVjdCB0aGUgcGFj a2V0IGxvc3MNCiAgIGlzIGJleW9uZCBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAgV2hlbiB1 cHN0cmVhbSBsaW5rIG9yDQogICBkb3duc3RyZWFtIGFnZ3JlZ2F0ZSBsaW5rIHBhY2tldCBsb3Nz IG9jY3VycywgdGhlIExvc3MgRGV0ZWN0b3IgTUFZDQogICBpbmZvcm0gZGlzdHJpYnV0aW9uIHNv dXJjZSBvZiB0aGUgZGV0ZWN0ZWQgcGFja2V0IGxvc3MgdXNpbmcgRmVlZGJhY2sNCiAgIFN1cHBy ZXNzaW9uIG1lc3NhZ2VzLiAgSW4gcmVzcG9uc2UsIHRoZSBkaXN0cmlidXRpb24gc291cmNlIGVp dGhlcg0KICAgZm9yd2FyZHMgcGFja2V0IGxvc3Mgc3VwcHJlc3Npb24gcmVwb3J0IHJlY2VpdmVk IGZyb20gTG9zcyBEZXRlY3Rvcg0KICAgb3IgY3JlYXRlcyBhIEZlZWRiYWNrIFN1cHByZXNzaW9u IHJlcG9ydCBhbmQgc2VuZHMgaXQgdG8gYWxsIHRoZSBSVFANCiAgIHJlY2VpdmVycywgb3ZlciB0 aGUgbXVsdGljYXN0IGNoYW5uZWwuICBUaGlzIGxvc3Mgc3VwcHJlc3Npb24gcmVwb3J0DQogICB0 ZWxscyB0aGUgcmVjZWl2ZXJzIHRoYXQgdGhlIGxvc3QgcGFja2V0IHdpbGwgZWl0aGVyIGJlIGZv cnRoY29taW5nDQogICBmcm9tIGRpc3RyaWJ1dGlvbiBzb3VyY2UsIG9yIGl0IGlycmV0cmlldmFi bHkgbG9zdCBzdWNoIHRoYXQgdGhlcmUgaXMNCiAgIG5vdGhpbmcgdG8gYmUgZ2FpbmVkIGJ5IHRo ZSByZWNlaXZlciBzZW5kaW5nIGEgTkFDSyB0byB0aGUgbWVkaWENCiAgIHNvdXJjZS4gIFRoZSBk aXN0cmlidXRpb24gc291cmNlIHRoZW4gY2FuIChvcHRpb25hbGx5KSBhc2sgZm9yIHRoZQ0KICAg bG9zdCBwYWNrZXRzIGZyb20gdGhlIG1lZGlhIHNvdXJjZSBvbiBiZWhhbGYgb2YgYWxsIHRoZSBS VFANCiAgIHJlY2VpdmVycy48L0ZPTlQ+PC9QUkU+PFBSRT48U1BBTiBjbGFzcz0yMzcwNTEwMTMt MTgxMDIwMTA+PC9TUEFOPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VDxTUEFOIGNsYXNz PTIzNzA1MTAxMy0xODEwMjAxMD5PTSAoNCkgOiBZb3UgcHJvYmFibHkgZG8gbm90IHdhbnQgdG8g aGF2ZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4gc2VjdGlvbiA2LjEsIGxpa2UgIkhvdyB0aGUgbG9z cyBkZXRlY3RvciBTSE9VTEQgKC4uKSIuIDwvU1BBTj48L0ZPTlQ+PC9QUkU+PFBSRT48U1BBTiBj bGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5bUWlu XTpTb3JyeSwgSSBjYW4ndCBnZXQgaXQuPC9GT05UPjwvU1BBTj48L1BSRT48UFJFPjxTUEFOIGNs YXNzPTIzNzA1MTAxMy0xODEwMjAxMD48L1NQQU4+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAy MDEwPjwvU1BBTj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlQ8U1BBTiBjbGFzcz0yMzcw NTEwMTMtMTgxMDIwMTA+T00gKDUpIDogSXQgaXMgcHJldHR5IGNsZWFyIGhvdyBhIExvc3MgZGV0 ZWN0b3Igd2lsbCBkZXRlY3QgcGFja2V0IGxvc3Mgb24gaXRzIHVwc3RyZWFtIGxpbmssIEkgZ3Vl c3MuPC9TUEFOPjwvRk9OVD48L1BSRT48UFJFPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAx MD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltRaW5dOiBBcyBJIHNhaWQgYWJvdmUsICBM b3NzIGRldGVjdG9yIGlzIGp1c3QgZnVuY3Rpb25hbGl0eSBvZiBzb21lIERpc3RyaWJ1dGlvbiBz b3VyY2VzLiAgQWxzbyB3aGF0IGl0IHNhaWQgaGVyZSBpbiBzZWN0aW9uIDYuMSA8L0ZPTlQ+PC9T UEFOPjwvUFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjxGT05UIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+aXMganVzdCBvbmUgZXhhbXBsZSB1c2UgY2FzZS48L0ZPTlQ+PC9T UEFOPjwvUFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjwvU1BBTj48U1BB TiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5U T00gKDYpOiAgV2hhdCBpcyB0aGUgcmF0aW9uYWxlIGZvciBhIGxvc3MgZGV0ZWN0b3IgdG8gc2Vu ZCBhIEZlZWRiYWNrIHN1cHByZXNzaW9uIG1lc3NhZ2UgdG8gdGhlIERTLi4gd2h5IE5PVCBhIFJU Q1AgTkFDSyBGQj88L0ZPTlQ+PC9TUEFOPjwvUFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEz LTE4MTAyMDEwPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+W1Fpbl06IEFzIEkgZXhwbGFp bmVkIGluIHRoZSBsYXN0IElFVEYgcHJlc2VudGFpb24sICB0aGlzIGNhdXNlIE5BQ0sgc2NlbWF0 aWNzIG1pc21hdGNoLiBUaGF0J3Mgd2h5IG1hbnkgcGVvcGxlIGluIHRoZSBsYXN0IElFVEYgbWVl ZXRpbmcgc3VnZ2VzdCB0byBjcmVhdGUgbmV3IFJUQ1AgbWVzc2FnZSBkdXJpbmcgcHJlc2VudGF0 aW9uLjwvRk9OVD48L1NQQU4+PC9QUkU+PFBSRT48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIw MTA+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5TZWN0aW9uIDYuMS4xPC9GT05UPjwvU1BB Tj48L1BSRT48UFJFPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SWYgdGhlcmUgYXJlIG11 bHRpcGxlIExvc3MgRGV0ZWN0b3JzIGxvb2tpbmcgYXQgdGhlIHNhbWUgUlRQIHN0cmVhbSwNCiAg IHRoZW4gdGhlIGxvc3MgbWF5IGJlIGlkZW50aWZpZWQgYnkgbW9yZSB0aGFuIG9uZSBhbmQgdGhv c2UgZGV0ZWN0aW5nDQogICB0aGUgbG9zcyB3aWxsIGFsbCBzZW5kIHJlcXVlc3RzIGZvciB0aGUg c2FtZSBwYWNrZXQgbG9zcy4gIEluIHRoaXMNCiAgIGNhc2UsIHRoZSBkaXN0cmlidXRpb24gc291 cmNlIE1VU1QgZmlsdGVyIHRoZSBkdXBsaWNhdGVkIHBhY2tldCBsb3NzDQogICByZXF1ZXN0IG91 dCBhbmQgb25seSBmb3J3YXJkIG9uZSBjb3B5IG9mIHRoZSBSVENQIEZlZWRiYWNrIHJlcG9ydA0K ICAgcGFja2V0IGZyb20gdGhlIGZpcnN0IExvc3MgRGV0ZWN0b3IgdG8gdGhlIGdyb3VwIGltcGFj dGVkIGJ5IHBhY2tldA0KICAgbG9zcy4NCjwvRk9OVD48L1BSRT4NCiAgPERJVj48U1BBTiBjbGFz cz0yMzcwNTEwMTMtMTgxMDIwMTA+VE9NICg3KSA6IGhvdyB3aWxsIHRoZSBEUyBzZW5kIG9ubHkg YSBjb3B5IA0KICBvZiB0aGUgUlRDUCBGQiByZXBvcnQgcGFja2V0IHRvIHRoZSBncm91cCBpbXBh Y3RlZCBieSBwYWNrZXQgbG9zcy4gSXMgdGhpcyANCiAgZG9uZSBvdmVyIHRoZSBTU00/IDwvU1BB Tj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PC9TUEFOPiZu YnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD5bUWluXTog U29ycnksIG1heWJlIEkgc291bGQgc2F5IA0KICA8L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4g Y2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPiI8L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xh c3M9MjM3MDUxMDEzLTE4MTAyMDEwPlNlY3Rpb24gNi4xLjE8L1NQQU4+PC9ESVY+DQogIDxESVY+ PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPklmIHRoZXJlIGFyZSBtdWx0aXBsZSBEaXN0 cmJpdHV0aW9uIFNvdXJjZSANCiAgd2l0aCB0aGUgbG9zcyBkZXRlY3Rpb24gc3VwcG9ydCBsb29r aW5nIGF0IHRoZSBzYW1lIFJUUCANCiAgc3RyZWFtLi4uLi48L1NQQU4+PC9ESVY+DQogIDxESVY+ PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPiI8L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQ QU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPlllcywmbmJzcDsgaW4gdGhlIFNTTSB1c2UgY2Fz ZSwgRFMgc2VuZCANCiAgb25seSBhIGNvcHkgb2YgdGhlIFJUQ1AgRmVlZGJhY2sgU3VwcHJlc3Np b24gUmVwb3J0IHBhY2tldCB0aGUgZ3JvdXAgdmlhIA0KICBTU00uPC9TUEFOPjwvRElWPg0KICA8 RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48L1NQQU4+Jm5ic3A7PC9ESVY+DQog IDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPkluIHlvdXIgZXhhbXBsZSB5b3Ug c2VlbSB0byBmb2N1cyBvbmx5IG9uIA0KICBhcmNoaXRlY3R1cmVzIHdpdGggYSBEUyB3aGljaCBh bHNvIGhvc3RzIHRoZSBGVCBhbmQgdGhlIGxvc3MgcmVwb3J0ZXIuJm5ic3A7IA0KICBUaGVyZSBz aG91bGQgYmUgc2VjdGlvbnMgY292ZXJpbmcgY2FzZXMgd2hlcmUgdGhlIERTIGlzIGRpc2pvaW50 IGZyb20gdGhlIEZULCANCiAgd2l0aCBzZXZlcmFsIEZUcyBhbmQgYWxzbyBzZXZlcmFsIGxvc3Mg cmVwb3J0ZXJzIGRpc2pvaW50IGZyb20gdGhlIEZUIGFuZCB0aGUgDQogIERTLjwvU1BBTj48L0RJ Vj4NCiAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PC9TUEFOPiZuYnNwOzwv RElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD5bUWluXSBJIGFtIG5v dCBzdXJlIHdlIG5lZWQgdG8gYWRkcmVzcyBhbGwgDQogIHRoZSBwb3NzaWJsZSBTU00gdXNlIGNh c2VzLiBJbiB0aGlzIGRyYWZ0LCB3ZSBqdXN0IGdpdmUmbmJzcDtzb21lIGV4YW1wbGVzIG9mIA0K ICBTU00gdXNlIGNhc2UuPC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAx My0xODEwMjAxMD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUx MDEzLTE4MTAyMDEwPlRPTSAoOCkgOiB3aGF0IGRvIHlvdSBtZWFuIGluIGFib3ZlIHRleHQgDQog IHdpdGggIlJUQ1AgRkIgcmVwb3J0Ii4uIGlzIHRoYXQgdGhlIHN1cHByZXNzaW9uIG1lc3NhZ2Ug eW91IGRlZmluZSBpbiB0aGlzIA0KICBkcmFmdD88L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4g Y2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BB TiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+W1Fpbl06IFllcywmbmJzcDsgUlRDUCBGZWVkYmFj ayANCiAgU3VwcHJlc3Npb24gUmVwb3J0LiA8L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xh c3M9MjM3MDUxMDEzLTE4MTAyMDEwPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBj bGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+VE9NICg5KSA6IEluIHNlY3Rpb24mbmJzcDsgIjYuMS4y LiZuYnNwOyANCiAgRGlzdHJpYnV0aW9uIFNvdXJjZSBGZWVkYmFjayBTdW1tYXJ5IE1vZGVsIiBp dCBpcyBub3QgY2xlYXIgd2hhdCB5b3VyIA0KICBhcmNoaXRlY3R1cmUgbG9va3MgbGlrZS4gWW91 IHRhbGsgYWJvdXQgbXVsdGlwbGUgZGlzdHJpYnV0aW9uIHNvdXJjZXMuLiB3aGNpaCANCiAgaW1w bGllcyBtdWx0aXBsZSBTU01zLi4gQ2FuIHlvdSBlbGFib3JhdGUgb24gdGhhdD88L1NQQU4+PC9E SVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjwvU1BBTj4mbmJzcDs8 L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+W1Fpbl06Jm5ic3A7 IFRoZSBzY2VuYXJpbyB3ZSBhcmUgdGFsa2luZyANCiAgYWJvdXQgaW4mbmJzcDsgdGhlIHNlY3Rp b24gNi4xLjIsIGlzJm5ic3A7dG8gJm5ic3A7YWxsb3cgbXVsdGlwbGUgRGlzdHJiaXR1aW9uIA0K ICBzb3VyY2UgYmV0d2VlbiBtZWRpYSBzb3VyY2UgYW5kIHRoZSByZWNlaXZlci4gSSB3aWxsIGxv b2sgYXQgdGhlIHRoaXMgY2FzZSBhcyANCiAgb25lIHNwZWNpYWwgU1NNIGNhc2UuIGJlY2F1c2Um bmJzcDsgZWFjaCBvZiBkaXN0cmJpdHVpb24gc291cmNlIDwvU1BBTj48U1BBTiANCiAgY2xhc3M9 MjM3MDUxMDEzLTE4MTAyMDEwPnJlc2lkZXMgYXQgdGhlIHVwc3RyZWFtIGRpcmVjdGlvbiBvciBk b3duc3RyZWFtIA0KICBkaXJlY3Rpb24gb2Ygb3RoZXIgZGlzdHJpYnV0aW9ucyBzb3VjZXMuIERv ZXMgaXQgbWFrZSBzZW5zZT88L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUx MDEzLTE4MTAyMDEwPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz0yMzcw NTEwMTMtMTgxMDIwMTA+VG9tICgxMCkgOiZuYnNwOyBJbiBzZWN0aW9uJm5ic3A7IA0KICA2LjMu Jm5ic3A7IE11bHRpcG9pbnQgQ29udHJvbCBVbml0IChNQ1UpIHVzZSBjYXNlLCZuYnNwOyB0eXBp Y2FsbHkgYW4gb3ZlcmxheSANCiAgb2YgdW5pY2FzdCBpcyB1c2VkLi4uIHdpbGwgdGhlIEZlZWRi YWNrIHN1cHByZXNzaW9uIG1lc3NhZ2UgYmUgc2VudCBvdmVyIA0KICB1bmljYXN0IGFzIHdlbGw/ IElmIHNvLCB3aGF0IGlzIGdhaW4gY29tcGFyZWQgdG8ganVzdCBoYXZpbmcgZWFjaCBSVENQIA0K ICByZWNlaXZlciBwcm92aWRpbmcgZWFjaCB0aGVpciBOQUNLIHRvIHRoZSBNQ1UsIGV2ZW4gaW4g Y2FzZSBvZiBhIHBhY2tldCBsb3NzIA0KICBpbXBhY3RpbmcgYWxsIHJlY2VpdmVycz88L1NQQU4+ PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjwvU1BBTj4mbmJz cDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+W1Fpbl06IEZp cnN0IFRoZSBNQ1UgY2FzZSB3aWxsIG5vdCBjYXVzZSANCiAgTkFDSyBJbXBsb3Npb24sIGluc3Rl YWQsIGl0IG1heSBjYXVzZSBGSVIgaW1wbG9zaW9uLjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BB TiANCiAgY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgU2Vjb25kLCB1c2luZyBGZWVk YmFjayBzdXBwcmVzc2lvbiBtZXNzYWdlIGNhbiByZXN0cmljdCB0aGUgRklSIG1lc3NhZ2Ugc2Vu dCANCiAgZnJvbSByZWNlaXZlcnMmbmJzcDtiZWhpbmQgTUNVIGFuZCBsaWJlcmF0ZSB0aGUgbWVk aWEgc291cmNlIGZyb20mbmJzcDsgRklSIA0KICBpbXBsb3Npb24uPC9TUEFOPjwvRElWPg0KICA8 RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48L1NQQU4+Jm5ic3A7PC9ESVY+DQog IDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPlRvbSAoMTEpIDogY29taW5nIGJh Y2sgdG8gbXkgcHJldmlvdXMgDQogIGNvbW1lbnQgb24gU0RQIGRlc2NyaXB0aW9uIGluIHRoaXMg ZHJhZnQmbmJzcDs6Jm5ic3A7aWYgdGhpcyBkcmFmdCBkZWZpbmVzIGEgDQogIFJUQ1AgZmVlZGJh Y2sgc3VwcHJlc3Npb24gbWVzc2FnZSwgd2h5IGlzIHRoZXJlIG5lZWQgZm9yIGEgImFubm91bmNl bWVudCIgaW4gDQogIHRoZSBTRFAgZm9yIHRoZSByZWNlaXZlcnMsIHRoYXQgaW5kaWNhdGVzIHRo ZXkgbWF5IHJlY2VpdmUgc3VjaCBmZWVkYmFjayANCiAgc3VwcHJlc3Npb24gbWVzc2FnZXM/Jm5i c3A7IElmIGEgcmVjZWl2ZXIgc3VwcG9ydHMgdGhlIG1lc3NhZ2UsIGl0IHdpbGwmbmJzcDsgDQog IHNpbXBseSZuYnNwO2FjdCBhY2NvcmRpbmdseSBhcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0LCBu byBuZWVkIHRvIGFubm91bmNlIA0KICB0aGF0IS4uIDwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BB TiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxT UEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD5bUWluXTogT2theSwgSSBnZXQgeW91ciBwb2lu dC4gSSB3b3VsZCANCiAgbGlrZSB0byBwdXQgdGhpcyBhcyBvcGVuIGlzc3VlLCBkaXNjdXNzIGl0 IGluIHRoZSBmYWNlIHRvIGZhY2UgSUVURiANCiAgbWVldGluZy48L1NQQU4+PC9ESVY+DQogIDxE SVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAg PERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+UmVnYXJkczwvU1BBTj48L0RJVj4N CiAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+VG9tPC9ESVY+DQogIDxESVY+ PEJSPjwvRElWPjwvU1BBTj4NCiAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+ PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAx MD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAy MDEwPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiANCmNsYXNzPTIzNzA1MTAxMy0x ODEwMjAxMD48L1NQQU4+Jm5ic3A7PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_DSXGJOuvniJMGX3vD9vlJw)-- From tom.van_caenegem@alcatel-lucent.com Tue Oct 19 01:25:34 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6FF3A6C10 for ; Tue, 19 Oct 2010 01:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-itUvPNpeDW for ; Tue, 19 Oct 2010 01:25:32 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 2BE733A6A96 for ; Tue, 19 Oct 2010 01:25:31 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9J8QQg1021906 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Oct 2010 10:26:54 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 19 Oct 2010 10:26:47 +0200 From: "Van Caenegem, Tom (Tom)" To: Qin Wu , "avt@ietf.org" Date: Tue, 19 Oct 2010 10:26:45 +0200 Thread-Topic: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 Thread-Index: ActvOmJJMyLM228TSZyF5vja0vwmiQAITiTA Message-ID: References: <048601cb6f3a$4a973180$30298a0a@china.huawei.com> In-Reply-To: <048601cb6f3a$4a973180$30298a0a@china.huawei.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: multipart/alternative; boundary="_000_EC3FD58E75D43A4F8807FDE0749175460E437545FRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 08:25:35 -0000 --_000_EC3FD58E75D43A4F8807FDE0749175460E437545FRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Qin, Thank you for your reply. Reading your responses,you seem to focus really on the SSM case with an ar= chitecture where the single DS (there can be only one DS per SSM) hosts the= sole feedback target, which also hosts the loss detector function. My inte= rpretation is also that in your draft the loss detector sends the FIR or NA= CK supression message to the DS, which then forwards/relays this message ov= er the SSM to all receivers, right? My main comment remains the same: you should at least incorporate the archi= tecture of RAMS (where there can be several FT colocated with the BRS, whi= ch are disjoint from the DS). In this case the FT/BRS should be able to pro= vide a suppression indication to all receivers that report to this FT (whic= h is a subset of all receivers that connect to the SSM), which means one sh= ould not make use of the (original) SSM for providing the suppression indic= ation. Your draft provides a possible solution for only a limited use case= , and not the most interesting one, IMO. Further down some responses to your answers below. Tom ________________________________ From: Qin Wu [mailto:sunseawq@huawei.com] Sent: dinsdag 19 oktober 2010 5:04 To: Van Caenegem, Tom (Tom); avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission= -supression-rtp-04 Hi, Tom: Thank for your comments, please see my reply inline. Regards! -Qin ----- Original Message ----- From: Van Caenegem, Tom (Tom) To: avt@ietf.org ; Qin Wu Sent: Tuesday, October 19, 2010 12:08 AM Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission= -supression-rtp-04 Hi Qin, I have some comments (look for TOM below) on the new draft version 4. Thx for addressing them, Tom Section 2 Terminology Loss Detector: The Loss Detector is one logical function which is used to detect the packet loss at the RTP layer and report it to the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. In this case, for a session defined as having a distribution source A, on ports n for the RTP channel and k for the RTCP channel, the Loss Detector are identified by an IP address of distribution source A on port k. The Loss Detector MAY also be implemented in one or more entities different from the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. TOM (1): ..same entity as what? i guess you mean the DS? [Qin]: Your are right. In this draft, the loss detector is just functional= ity of DS. Furthermore we only consider the loss detector as part of feedb= ack target within the distribution source. Also this is just one example use case to explain how feedback suppression = works in SSM use case. TOM (2): I do not understand how you associate the port k to a loss detecto= r.. what do you mean with that? [Qin]: Sorry for ambiguity of the description here. It actually means that= the loss reporter is part of feedback target and share the same address an= d port. section 3 (..) In order to detect packet loss before the receivers perceive it, one or more intermediate nodes are placed between the media source and receiver (e.g., Distribution server, MCU, RTP translator). These intermediaries monitor for packet loss upstream of themselves by checking RTP sequence numbers, just as receivers do. Upon detecting (or suspecting) an upstream loss, the intermediary may send Feedback Suppression message towards the receivers as defined in this specification. TOM (3) : ...based on the two above definitions ...is an intermediate node = hence equal to a "Loss detector"? + How does a Loss detector differ from an RTP receiver? [Qin]: The loss detector is just one functionality of Distribution Source i= n the SSM use case. Maybe we should interpret it as "Loss detection functionality". How the pac= ket loss is detected is out of scope of this document. Different from dedicated RTP receiver, the intermediate node does not depen= d on existing NACK message for Retransmission request for packet loss. the intermediate node can create message by itself. Section 6.1 In order to avoid the forms of NACK implosion described in section 1, the Loss Detector is introduced. The Loss Detector detects and reports packet loss, on both the upstream link and the downstream aggregate link. How the loss detector SHOULD detect the packet loss is beyond of scope of this document. When upstream link or downstream aggregate link packet loss occurs, the Loss Detector MAY inform distribution source of the detected packet loss using Feedback Suppression messages. In response, the distribution source either forwards packet loss suppression report received from Loss Detector or creates a Feedback Suppression report and sends it to all the RTP receivers, over the multicast channel. This loss suppression report tells the receivers that the lost packet will either be forthcoming from distribution source, or it irretrievably lost such that there is nothing to be gained by the receiver sending a NACK to the media source. The distribution source then can (optionally) ask for the lost packets from the media source on behalf of all the RTP receivers. TOM (4) : You probably do not want to have normative language in section 6.= 1, like "How the loss detector SHOULD (..)". [Qin]:Sorry, I can't get it. TOM: this is really a detail. If you want to keep the sentence, you should = e.g. say: "How the loss detector can detect the packet loss... TOM (5) : It is pretty clear how a Loss detector will detect packet loss on= its upstream link, I guess. [Qin]: As I said above, Loss detector is just functionality of some Distri= bution sources. Also what it said here in section 6.1 is just one example use case. TOM (6): What is the rationale for a loss detector to send a Feedback supp= ression message to the DS.. why NOT a RTCP NACK FB? [Qin]: As I explained in the last IETF presentaion, this cause NACK scemat= ics mismatch. That's why many people in the last IETF meeeting suggest to c= reate new RTCP message during presentation. TOM: As your assumption is that the loss reporter is part of the FT that is= part of the DS, then there is even no need to specify how the loss detecto= r reports the packet loss. In the more generic case, it makes more sense to = me that the loss reporter just uses a NACK (or a FIR) if it detects packet = loss, sent towards its FT or to the DS if this one hosts the FT that the lo= ss detector reports to . It is then up to the FT or the DS to decide whethe= r this message triggers a NACK or FIR suppression indication to (s subset of) the receivers. This suppression indication doe= s not necessarly require a new message format. A NACK/FIR that is sent to = a RTP receiver can be defined as a feedback suppression indication. I do no= t see a good use case why NACKs from receivers would be reflected back in= e.g. SSM use case by DS or FT to all the connected receivers. If we define that a NACK/FIR for a SSM may only be sent TOWARDS a RTP rece= iver, if this is for suppression indication, there is no ambiguity possibly= . Section 6.1.1 If there are multiple Loss Detectors looking at the same RTP stream, then the loss may be identified by more than one and those detecting the loss will all send requests for the same packet loss. In this case, the distribution source MUST filter the duplicated packet loss request out and only forward one copy of the RTCP Feedback report packet from the first Loss Detector to the group impacted by packet loss. TOM (7) : how will the DS send only a copy of the RTCP FB report packet to = the group impacted by packet loss. Is this done over the SSM? [Qin]: Sorry, maybe I sould say " Section 6.1.1 If there are multiple Distrbitution Source with the loss detection support = looking at the same RTP stream..... " Yes, in the SSM use case, DS send only a copy of the RTCP Feedback Suppres= sion Report packet the group via SSM. In your example you seem to focus only on architectures with a DS which als= o hosts the FT and the loss reporter. There should be sections covering ca= ses where the DS is disjoint from the FT, with several FTs and also several= loss reporters disjoint from the FT and the DS. [Qin] I am not sure we need to address all the possible SSM use cases. In t= his draft, we just give some examples of SSM use case. TOM (8) : what do you mean in above text with "RTCP FB report".. is that th= e suppression message you define in this draft? [Qin]: Yes, RTCP Feedback Suppression Report. TOM (9) : In section "6.1.2. Distribution Source Feedback Summary Model" = it is not clear what your architecture looks like. You talk about multiple = distribution sources.. whcih implies multiple SSMs.. Can you elaborate on t= hat? [Qin]: The scenario we are talking about in the section 6.1.2, is to all= ow multiple Distrbituion source between media source and the receiver. I wi= ll look at the this case as one special SSM case. because each of distrbit= uion source resides at the upstream direction or downstream direction of ot= her distributions souces. Does it make sense? TOM: RFC 5760 only defines one DS for a given SSM. If you depart from that,= you probably need to address and define this architecture in a better way = in your draft. Tom (10) : In section 6.3. Multipoint Control Unit (MCU) use case, typi= cally an overlay of unicast is used... will the Feedback suppression messag= e be sent over unicast as well? If so, what is gain compared to just having= each RTCP receiver providing each their NACK to the MCU, even in case of a= packet loss impacting all receivers? [Qin]: First The MCU case will not cause NACK Implosion, instead, it may ca= use FIR implosion. Second, using Feedback suppression message can restrict the FIR = message sent from receivers behind MCU and liberate the media source from = FIR implosion. TOM: it is not important whether this is about FIR or NACK. My point is tha= t iso having each receiver sending a NACK/FIR, you will now have to send to= each receiver a NACK/FIR suppression in the given scenario. There are no = differences in terms of Bandwdith overhead or server load in the two cases,= so why bother to send suppression messages? Tom (11) : coming back to my previous comment on SDP description in this dr= aft : if this draft defines a RTCP feedback suppression message, why is the= re need for a "announcement" in the SDP for the receivers, that indicates t= hey may receive such feedback suppression messages? If a receiver supports= the message, it will simply act accordingly as described in the draft, no= need to announce that!.. [Qin]: Okay, I get your point. I would like to put this as open issue, disc= uss it in the face to face IETF meeting. Regards Tom --_000_EC3FD58E75D43A4F8807FDE0749175460E437545FRMRSSXCHMBSB1d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Qin,
 
Thank you for your reply.
 
Reading your responses,you seem to focus really on= the=20 SSM  case with an architecture where the single DS (there can be only = one=20 DS per SSM) hosts the sole feedback target, which also hosts the loss detec= tor=20 function. My interpretation is also that in your draft the loss detector se= nds=20 the FIR or NACK supression message to the DS, which then forwards/relays=20 this message over the SSM to all receivers, right? =20
 
My main comment remains the same: you should at le= ast=20 incorporate the architecture of RAMS (where there can be several= =20 FT  colocated with the BRS, which are disjoint from the DS). In this c= ase=20 the FT/BRS should be able to provide a suppression indication to all receiv= ers=20 that report to this FT (which is a subset of all receivers that connect to = the=20 SSM), which means one should not make use of the (original) SSM for providi= ng=20 the suppression indication.  Your draft provides a possible solution f= or=20 only a limited use case, and not the most interesting one,=20 IMO.  
 
Further down some responses to your answ= ers=20 below.
 
Tom
 
<= /FONT>
From: Qin Wu [mailto:sunseawq@huawei.co= m]=20
Sent: dinsdag 19 oktober 2010 5:04
To: Van Caenegem, T= om=20 (Tom); avt@ietf.org
Subject: Re: [AVT] New Version Notification f= or=20 draft-wu-avt-retransmission-supression-rtp-04

Hi, Tom:
Thank for your comments, please see my reply inline.
 
Regards!
-Qin
----- Original=20 Message -----
From: Van Caenegem, Tom (Tom)=20
= Sent: Tuesday, October 19, 2010 12:08 AM
= Subject: Re: [AVT] New Version Notification for=20 draft-wu-avt-retransmission-supression-rtp-04

Hi Qin,
 
I have some comments (look for TOM = below)=20 on the new draft version 4.
Thx for addressing them,
Tom
 
 
Section 2 Terminology
 Loss Detector:

      The Loss Detector is one logical function which is used to detect
      the packet loss at the RTP layer and report it to the distribution
      source.  The function of the loss reporter may be collocated with
      or integrated into the same entity.  In this case, for a session
      defined as having a distribution source A, on ports n for the RTP
      channel and k for the RTCP channel, the Loss Detector are
      identified by an IP address of distribution source A on port k.
      The Loss Detector MAY also be implemented in one or more entities
      different from the distribution source.

 The function of the loss reporter may be collocated with
      or integrated into the same entity.
TOM (1): ..same enti=
ty as what? i guess you mean the DS?
[Qin]: Your are right.  I=
n this draft, the loss detector is just functionality of DS.  Furthermore w=
e only consider the loss detector as part of feedback target within the dis=
tribution source.
=
Also=
 this is just one example use case to explain how feedback suppression work=
s in SSM use case.
TOM (2): I do not understand how you associ=
ate the port k to a loss detector.. what do you mean with that?
section 3
 
=
(..)
In order to detect packet loss before the receivers perceiv=
e it, one
   or more intermediate nodes are placed between the media source and
   receiver (e.g., Distribution server, MCU, RTP translator).  These
   intermediaries monitor for packet loss upstream of themselves by
   checking RTP sequence numbers, just as receivers do.  Upon detecting
   (or suspecting) an upstream loss, the intermediary may send Feedback
   Suppression message towards the receivers as defined in this
   specification.
TOM (3)=20 : ...based on the two above= =20 definitions ...is an intermediate node hence equal to a "Lo= ss detector"? =20
+ How = does a=20 Loss detector differ from an RTP receiver?
[Qin]: The loss detector is just on= e=20 functionality of Distribution Source in the SSM use case.
Maybe we should interpret it a= s "Loss=20 detection functionality". How the packet loss is detected is out of scope= of=20 this document.
Different from dedicated RTP receiv= er, the=20 intermediate node does not depend on existing NACK message for Retransmis= sion=20 request for packet loss.
the intermediate node can create me= ssage=20 by itself.
 
Section 6.1
In order to avoid the forms of NACK implosion desc=
ribed in section 1,
   the Loss Detector is introduced.  The Loss Detector detects and
   reports packet loss, on both the upstream link and the downstream
   aggregate link.  How the loss detector SHOULD detect the packet loss
   is beyond of scope of this document.  When upstream link or
   downstream aggregate link packet loss occurs, the Loss Detector MAY
   inform distribution source of the detected packet loss using Feedback
   Suppression messages.  In response, the distribution source either
   forwards packet loss suppression report received from Loss Detector
   or creates a Feedback Suppression report and sends it to all the RTP
   receivers, over the multicast channel.  This loss suppression report
   tells the receivers that the lost packet will either be forthcoming
   from distribution source, or it irretrievably lost such that there is
   nothing to be gained by the receiver sending a NACK to the media
   source.  The distribution source then can (optionally) ask for the
   lost packets from the media source on behalf of all the RTP
   receivers.
TOM (4) : You p=
robably do not want to have normative language in section 6.1, like "How th=
e loss detector SHOULD (..)". 
[Qin]:Sorry, I can't get it. 
TOM: this is really a detail. If you want to keep the sentence, you sho=
uld e.g. say: "How the loss detector can detect the packet loss...
 
 
TOM (5) : It is pretty clear how a Loss detector will detect p=
acket loss on its upstream link, I guess.
[Qin]: As I said abo=
ve,  Loss detector is just functionality of some Distribution sources.  Als=
o what it said here in section 6.1 
is just one example use ca=
se.
TOM (6):  What is =
the rationale for a loss detector to send a Feedback suppression message to=
 the DS.. why NOT a RTCP NACK FB?
[Qin]: As I explained in the=
 last IETF presentaion,  this cause NACK scematics mismatch. That's why man=
y people in the last IETF meeeting suggest to create new RTCP message durin=
g presentation. 
 
TOM: As your assumption is that the loss reporter i=
s part of the FT that is part of the DS, then there is even no need to spec=
ify how the loss detector 
reports the packet loss.  In the more generic case, it ma=
kes more sense to me that the loss reporter just uses a NACK (or a FIR) if =
it detects packet loss, sent towards its FT or to the DS if this one hosts =
the FT that the loss detector reports to . It is then up to the FT or the D=
S to decide whether this message triggers a NACK or FIR suppression =

indication to (=
s subset of) the receivers.  This suppression indication does not necessarl=
y require a new message format. A NACK/FIR  that is sent to a RTP receiver =
can be defined as a feedback suppression indication. I do not see a good us=
e case why NACKs from  receivers  would be reflected back in e.g. SSM use c=
ase by DS or FT  to all the connected receivers. 
If we define that a NACK/FIR  for =
a SSM may only be sent TOWARDS a RTP receiver, if this is for suppression i=
ndication, there is no ambiguity possibly.   
 
 Section 6.= 1.1
If there are mul=
tiple Loss Detectors looking at the same RTP stream,
   then the loss may be identified by more than one and those detecting
   the loss will all send requests for the same packet loss.  In this
   case, the distribution source MUST filter the duplicated packet loss
   request out and only forward one copy of the RTCP Feedback report
   packet from the first Loss Detector to the group impacted by packet
   loss.
TOM (7) : how will the DS send only= a copy=20 of the RTCP FB report packet to the group impacted by packet loss. Is thi= s=20 done over the SSM?
 
[Qin]: Sorry, maybe I sould say=20
"
Section 6.1.1
If there are multiple Distrbitution= Source=20 with the loss detection support looking at the same RTP=20 stream.....
"
Yes,  in the SSM use case, DS = send=20 only a copy of the RTCP Feedback Suppression Report packet the group via= =20 SSM.
 
In your example you seem to focus o= nly on=20 architectures with a DS which also hosts the FT and the loss reporter.&nb= sp;=20 There should be sections covering cases where the DS is disjoint from the= FT,=20 with several FTs and also several loss reporters disjoint from the FT and= the=20 DS.
 
[Qin] I am not sure we need to addr= ess all=20 the possible SSM use cases. In this draft, we just give some example= s of=20 SSM use case.
 
TOM (8) : what do you mean in above= text=20 with "RTCP FB report".. is that the suppression message you define in thi= s=20 draft?
 
[Qin]: Yes,  RTCP Feedback=20 Suppression Report.
 
TOM (9) : In section  "6.1.2.&= nbsp;=20 Distribution Source Feedback Summary Model" it is not clear what your=20 architecture looks like. You talk about multiple distribution sources.. w= hcih=20 implies multiple SSMs.. Can you elaborate on that?
 
[Qin]:  The scenario we are ta= lking=20 about in  the section 6.1.2, is to  allow multiple Distrbi= tuion=20 source between media source and the receiver. I will look at the this cas= e as=20 one special SSM case. because  each of distrbituion source resides at the upstream direction or downstrea= m=20 direction of other distributions souces. Does it make sense? 
 
TOM: RFC 5760 only defines one DS f= or a given=20 SSM. If you depart from that, you probably need to address and=20 define this architecture in a better way in your=20 draft. 
 
Tom (10) :  In section =20 6.3.  Multipoint Control Unit (MCU) use case,  typically an ove= rlay=20 of unicast is used... will the Feedback suppression message be sent over= =20 unicast as well? If so, what is gain compared to just having each RTCP=20 receiver providing each their NACK to the MCU, even in case of a packet l= oss=20 impacting all receivers?
 
[Qin]: First The MCU case will not = cause=20 NACK Implosion, instead, it may cause FIR implosion.
       &nbs= p;  =20 Second, using Feedback suppression message can restrict the FIR message s= ent=20 from receivers behind MCU and liberate the media source from  F= IR=20 implosion. 
 
TOM: it is not important whether th= is is about=20 FIR or NACK. My point is that iso having each receiver sending a NACK/FIR= , you=20 will now have to send to each receiver a NACK/FIR  suppression in th= e=20 given scenario. There are no differences in terms of Bandwdith overhead o= r=20 server load in the two cases, so why bother to send suppression=20 messages?
 
 
Tom (11) : coming back to my previo= us=20 comment on SDP description in this draft : if this draft define= s a=20 RTCP feedback suppression message, why is there need for a "announcement"= in=20 the SDP for the receivers, that indicates they may receive such feedback= =20 suppression messages?  If a receiver supports the message, it will&n= bsp;=20 simply act accordingly as described in the draft, no need to announc= e=20 that!..
 
[Qin]: Okay, I get your point. I wo= uld=20 like to put this as open issue, discuss it in the face to face IETF=20 meeting.
 
Regards
Tom

 
 
 
 
--_000_EC3FD58E75D43A4F8807FDE0749175460E437545FRMRSSXCHMBSB1d_-- From sunseawq@huawei.com Tue Oct 19 03:48:46 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7F43A67A7 for ; Tue, 19 Oct 2010 03:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.326 X-Spam-Level: **** X-Spam-Status: No, score=4.326 tagged_above=-999 required=5 tests=[AWL=-3.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDgPLKio8i0Y for ; Tue, 19 Oct 2010 03:48:44 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5674A3A67A1 for ; Tue, 19 Oct 2010 03:48:43 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAJ00KGVA3FDR@szxga04-in.huawei.com> for avt@ietf.org; Tue, 19 Oct 2010 18:50:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAJ00B93A3ELF@szxga04-in.huawei.com> for avt@ietf.org; Tue, 19 Oct 2010 18:50:03 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAJ008HMA3E74@szxml06-in.huawei.com> for avt@ietf.org; Tue, 19 Oct 2010 18:50:02 +0800 (CST) Date: Tue, 19 Oct 2010 18:50:01 +0800 From: Qin Wu To: "Van Caenegem, Tom (Tom)" , avt@ietf.org Message-id: <061901cb6f7b$61d412a0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_64NZ7WKETdvs69DBTt28xQ)" X-Priority: 3 X-MSMail-priority: Normal References: <048601cb6f3a$4a973180$30298a0a@china.huawei.com> Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 10:48:46 -0000 This is a multi-part message in MIME format. --Boundary_(ID_64NZ7WKETdvs69DBTt28xQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGksIFRvbToNCg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBWYW4g Q2FlbmVnZW0sIFRvbSAoVG9tKSANCiAgVG86IFFpbiBXdSA7IGF2dEBpZXRmLm9yZyANCiAgU2Vu dDogVHVlc2RheSwgT2N0b2JlciAxOSwgMjAxMCA0OjI2IFBNDQogIFN1YmplY3Q6IFJFOiBbQVZU XSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LWF2dC1yZXRyYW5zbWlzc2lv bi1zdXByZXNzaW9uLXJ0cC0wNA0KDQoNCiAgSGkgUWluLA0KDQogIFRoYW5rIHlvdSBmb3IgeW91 ciByZXBseS4NCg0KICBSZWFkaW5nIHlvdXIgcmVzcG9uc2VzLHlvdSBzZWVtIHRvIGZvY3VzIHJl YWxseSBvbiB0aGUgU1NNICBjYXNlIHdpdGggYW4gYXJjaGl0ZWN0dXJlIHdoZXJlIHRoZSBzaW5n bGUgRFMgKHRoZXJlIGNhbiBiZSBvbmx5IG9uZSBEUyBwZXIgU1NNKSBob3N0cyB0aGUgc29sZSBm ZWVkYmFjayB0YXJnZXQsIHdoaWNoIGFsc28gaG9zdHMgdGhlIGxvc3MgZGV0ZWN0b3IgZnVuY3Rp b24uIE15IGludGVycHJldGF0aW9uIGlzIGFsc28gdGhhdCBpbiB5b3VyIGRyYWZ0IHRoZSBsb3Nz IGRldGVjdG9yIHNlbmRzIHRoZSBGSVIgb3IgTkFDSyBzdXByZXNzaW9uIG1lc3NhZ2UgdG8gdGhl IERTLCB3aGljaCB0aGVuIGZvcndhcmRzL3JlbGF5cyB0aGlzIG1lc3NhZ2Ugb3ZlciB0aGUgU1NN IHRvIGFsbCByZWNlaXZlcnMsIHJpZ2h0PyAgDQoNCiAgW1Fpbl06IFNTTSBjYXNlIGlzIGp1c3Qg b25lIGV4YW1wbGUgY2FzZSBpbiB0aGlzIGRyYWZ0LiBXZSBoYXZlIGFsc28gZGlzY3Vzc2VkIFRy YW5zcG9ydCB0cmFuc2xhdG9yIHVzZSBjYXNlIGFuZCBNQ1UgdXNlIGNhc2UuIFRoaXMgZHJhZnQg Zm9jdXMgb24gaG93IHRoZSBmZWVkYmFjayBzdXBwcmVzc2lvbiB3b3JrcyBpbiB0aGVzZSBkaWZm ZXJlbnQgdXNlIGNhc2VzLg0KICBGb3IgdGhlIFNTTSB1c2UgY2FzZSwgd2UgbWF5IGNvbnNpZGVy IG11bHRpcGxlIGRpc3RyaWJ1dGlvbiBzb3VyY2VzIHBsYWNlZCBiZXR3ZWVuIG1lZGlhIHNvdXJj ZSBhbmQgdGhlIHJlY2VpdmVyLiBUaGUgbG9zcyBkZXRlY3RvciBpcyBqdXN0IG9uZSBmdW5jdGlv bmFsaXR5IG9mIERpc3RyaWJ1dGlvbiBzb3VyY2UsIG9yIFJldHJhbnNtaXNzaW9uIFNlcnZlciBv ciBNQ1UsIG9yIFRyYW5zcG9ydCBUcmFuc2xhdG9yLiBJdCBkb2VzIG5vdCBoYXZlIHRvIGJlIHB1 dCBhcyBwYXJ0IG9mIGZlZWRiYWNrIHRhcmdldC4gSSBwcm9wb3NlIHRvIHJlbW92ZSB0aGUgc3R1 ZmYgb2YgIkxvc3MgZGV0ZWN0b3IiIGZyb20gdGhpcyBkcmFmdCwgaW5zdGVhZCwgdXNpbmcgRGlz dHJpYnV0aW9uIHNvdXJjZSB3aXRoIGxvc3MgZGV0ZWN0aW9uIHN1cHBvcnQuIFdoYXQgZG8geW91 IHRoaW5rIG9mIGl0Pw0KDQogIE15IG1haW4gY29tbWVudCByZW1haW5zIHRoZSBzYW1lOiB5b3Ug c2hvdWxkIGF0IGxlYXN0IGluY29ycG9yYXRlIHRoZSBhcmNoaXRlY3R1cmUgb2YgUkFNUyAod2hl cmUgdGhlcmUgY2FuIGJlIHNldmVyYWwgRlQgIGNvbG9jYXRlZCB3aXRoIHRoZSBCUlMsIHdoaWNo IGFyZSBkaXNqb2ludCBmcm9tIHRoZSBEUykuIEluIHRoaXMgY2FzZSB0aGUgRlQvQlJTIHNob3Vs ZCBiZSBhYmxlIHRvIHByb3ZpZGUgYSBzdXBwcmVzc2lvbiBpbmRpY2F0aW9uIHRvIGFsbCByZWNl aXZlcnMgdGhhdCByZXBvcnQgdG8gdGhpcyBGVCAod2hpY2ggaXMgYSBzdWJzZXQgb2YgYWxsIHJl Y2VpdmVycyB0aGF0IGNvbm5lY3QgdG8gdGhlIFNTTSksIHdoaWNoIG1lYW5zIG9uZSBzaG91bGQg bm90IG1ha2UgdXNlIG9mIHRoZSAob3JpZ2luYWwpIFNTTSBmb3IgcHJvdmlkaW5nIHRoZSBzdXBw cmVzc2lvbiBpbmRpY2F0aW9uLiAgWW91ciBkcmFmdCBwcm92aWRlcyBhIHBvc3NpYmxlIHNvbHV0 aW9uIGZvciBvbmx5IGEgbGltaXRlZCB1c2UgY2FzZSwgYW5kIG5vdCB0aGUgbW9zdCBpbnRlcmVz dGluZyBvbmUsIElNTy4gIA0KDQogIFtRaW5dOiBJIHRoaW5rIFJBTVMgY2FzZSBpcyBqdXN0IG9u ZSBzcGVjaWFsIGNhc2Ugb2YgU1NNIHVzZSBjYXNlLiBob3cgRmVlZGJhY2sgc3VwcHJlc3Npb24g d29ya3MgZm9yIFNTTSB1c2UgY2FzZSB0aGVyZm9yZSBpcyBxdWl0ZSBzaW1pbGFyIHRvIFJBTVMs IHRoZSBvbmx5IGRpZmZlcmVuY2UgaXMgRGlzdHJiaXR1aW9uIHNvdXJjZSBpbiB0aGUgU1NNIGNh c2UgaXMgcmVwbGFjZWQgd2l0aA0KICBCUlMgaW4gdGhlIFJBTVMuIEFzIHJlZ2FyZGluZyBhbm90 aGVyIFJBTVMgY2FzZSB3aGVyZSBzZXZlcmFsIEZUcyBzZXBhcmF0ZWQgZnJvbSBCUlMsICAgd2Ug Y2FuIGFkZHJlc3MgdGhpcyBjYXNlIGlmIHRoZXJlIGFyZSBzdHJvbmcgaW50ZXJlc3RzLiANCiAg QnV0IHRvIGJlIGNsZWFyLCB0aGlzIGRyYWZ0IGZvY3VzIG9uIGhvdyBGZWVkYmFjayBzdXBwcmVz c2lvbiBtZXNzYWdlIHdvcmtzIGluIGRpZmZlcmVudCB1c2UgY2FzZSwgbm90IGZvciBvbmUgc3Bl Y2lmaWMgdXNlIGNhc2UuDQoNCiAgRnVydGhlciBkb3duIHNvbWUgcmVzcG9uc2VzIHRvIHlvdXIg YW5zd2VycyBiZWxvdy4NCg0KICBUb20NCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog IEZyb206IFFpbiBXdSBbbWFpbHRvOnN1bnNlYXdxQGh1YXdlaS5jb21dIA0KICBTZW50OiBkaW5z ZGFnIDE5IG9rdG9iZXIgMjAxMCA1OjA0DQogIFRvOiBWYW4gQ2FlbmVnZW0sIFRvbSAoVG9tKTsg YXZ0QGlldGYub3JnDQogIFN1YmplY3Q6IFJlOiBbQVZUXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXd1LWF2dC1yZXRyYW5zbWlzc2lvbi1zdXByZXNzaW9uLXJ0cC0wNA0KDQoN CiAgSGksIFRvbToNCiAgVGhhbmsgZm9yIHlvdXIgY29tbWVudHMsIHBsZWFzZSBzZWUgbXkgcmVw bHkgaW5saW5lLg0KDQogIFJlZ2FyZHMhDQogIC1RaW4NCiAgICAtLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIA0KICAgIEZyb206IFZhbiBDYWVuZWdlbSwgVG9tIChUb20pIA0KICAgIFRvOiBh dnRAaWV0Zi5vcmcgOyBRaW4gV3UgDQogICAgU2VudDogVHVlc2RheSwgT2N0b2JlciAxOSwgMjAx MCAxMjowOCBBTQ0KICAgIFN1YmplY3Q6IFJlOiBbQVZUXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXd1LWF2dC1yZXRyYW5zbWlzc2lvbi1zdXByZXNzaW9uLXJ0cC0wNA0KDQoN CiAgICBIaSBRaW4sDQoNCiAgICBJIGhhdmUgc29tZSBjb21tZW50cyAobG9vayBmb3IgVE9NIGJl bG93KSBvbiB0aGUgbmV3IGRyYWZ0IHZlcnNpb24gNC4NCiAgICBUaHggZm9yIGFkZHJlc3Npbmcg dGhlbSwNCiAgICBUb20NCg0KDQogICAgU2VjdGlvbiAyIFRlcm1pbm9sb2d5DQogTG9zcyBEZXRl Y3RvcjoNCg0KICAgICAgVGhlIExvc3MgRGV0ZWN0b3IgaXMgb25lIGxvZ2ljYWwgZnVuY3Rpb24g d2hpY2ggaXMgdXNlZCB0byBkZXRlY3QNCiAgICAgIHRoZSBwYWNrZXQgbG9zcyBhdCB0aGUgUlRQ IGxheWVyIGFuZCByZXBvcnQgaXQgdG8gdGhlIGRpc3RyaWJ1dGlvbg0KICAgICAgc291cmNlLiAg VGhlIGZ1bmN0aW9uIG9mIHRoZSBsb3NzIHJlcG9ydGVyIG1heSBiZSBjb2xsb2NhdGVkIHdpdGgN CiAgICAgIG9yIGludGVncmF0ZWQgaW50byB0aGUgc2FtZSBlbnRpdHkuICBJbiB0aGlzIGNhc2Us IGZvciBhIHNlc3Npb24NCiAgICAgIGRlZmluZWQgYXMgaGF2aW5nIGEgZGlzdHJpYnV0aW9uIHNv dXJjZSBBLCBvbiBwb3J0cyBuIGZvciB0aGUgUlRQDQogICAgICBjaGFubmVsIGFuZCBrIGZvciB0 aGUgUlRDUCBjaGFubmVsLCB0aGUgTG9zcyBEZXRlY3RvciBhcmUNCiAgICAgIGlkZW50aWZpZWQg YnkgYW4gSVAgYWRkcmVzcyBvZiBkaXN0cmlidXRpb24gc291cmNlIEEgb24gcG9ydCBrLg0KICAg ICAgVGhlIExvc3MgRGV0ZWN0b3IgTUFZIGFsc28gYmUgaW1wbGVtZW50ZWQgaW4gb25lIG9yIG1v cmUgZW50aXRpZXMNCiAgICAgIGRpZmZlcmVudCBmcm9tIHRoZSBkaXN0cmlidXRpb24gc291cmNl Lg0KIFRoZSBmdW5jdGlvbiBvZiB0aGUgbG9zcyByZXBvcnRlciBtYXkgYmUgY29sbG9jYXRlZCB3 aXRoDQogICAgICBvciBpbnRlZ3JhdGVkIGludG8gdGhlIHNhbWUgZW50aXR5LlRPTSAoMSk6IC4u c2FtZSBlbnRpdHkgYXMgd2hhdD8gaSBndWVzcyB5b3UgbWVhbiB0aGUgRFM/W1Fpbl06IFlvdXIg YXJlIHJpZ2h0LiAgSW4gdGhpcyBkcmFmdCwgdGhlIGxvc3MgZGV0ZWN0b3IgaXMganVzdCBmdW5j dGlvbmFsaXR5IG9mIERTLiAgRnVydGhlcm1vcmUgd2Ugb25seSBjb25zaWRlciB0aGUgbG9zcyBk ZXRlY3RvciBhcyBwYXJ0IG9mIGZlZWRiYWNrIHRhcmdldCB3aXRoaW4gdGhlIGRpc3RyaWJ1dGlv biBzb3VyY2UuQWxzbyB0aGlzIGlzIGp1c3Qgb25lIGV4YW1wbGUgdXNlIGNhc2UgdG8gZXhwbGFp biBob3cgZmVlZGJhY2sgc3VwcHJlc3Npb24gd29ya3MgaW4gU1NNIHVzZSBjYXNlLlRPTSAoMik6 IEkgZG8gbm90IHVuZGVyc3RhbmQgaG93IHlvdSBhc3NvY2lhdGUgdGhlIHBvcnQgayB0byBhIGxv c3MgZGV0ZWN0b3IuLiB3aGF0IGRvIHlvdSBtZWFuIHdpdGggdGhhdD9bUWluXTogIFNvcnJ5IGZv ciBhbWJpZ3VpdHkgb2YgdGhlIGRlc2NyaXB0aW9uIGhlcmUuIEl0IGFjdHVhbGx5IG1lYW5zIHRo YXQgdGhlIGxvc3MgcmVwb3J0ZXIgaXMgcGFydCBvZiBmZWVkYmFjayB0YXJnZXQgYW5kIHNoYXJl IHRoZSBzYW1lIGFkZHJlc3MgYW5kIHBvcnQuc2VjdGlvbiAzICguLilJbiBvcmRlciB0byBkZXRl Y3QgcGFja2V0IGxvc3MgYmVmb3JlIHRoZSByZWNlaXZlcnMgcGVyY2VpdmUgaXQsIG9uZQ0KICAg b3IgbW9yZSBpbnRlcm1lZGlhdGUgbm9kZXMgYXJlIHBsYWNlZCBiZXR3ZWVuIHRoZSBtZWRpYSBz b3VyY2UgYW5kDQogICByZWNlaXZlciAoZS5nLiwgRGlzdHJpYnV0aW9uIHNlcnZlciwgTUNVLCBS VFAgdHJhbnNsYXRvcikuICBUaGVzZQ0KICAgaW50ZXJtZWRpYXJpZXMgbW9uaXRvciBmb3IgcGFj a2V0IGxvc3MgdXBzdHJlYW0gb2YgdGhlbXNlbHZlcyBieQ0KICAgY2hlY2tpbmcgUlRQIHNlcXVl bmNlIG51bWJlcnMsIGp1c3QgYXMgcmVjZWl2ZXJzIGRvLiAgVXBvbiBkZXRlY3RpbmcNCiAgIChv ciBzdXNwZWN0aW5nKSBhbiB1cHN0cmVhbSBsb3NzLCB0aGUgaW50ZXJtZWRpYXJ5IG1heSBzZW5k IEZlZWRiYWNrDQogICBTdXBwcmVzc2lvbiBtZXNzYWdlIHRvd2FyZHMgdGhlIHJlY2VpdmVycyBh cyBkZWZpbmVkIGluIHRoaXMNCiAgIHNwZWNpZmljYXRpb24uDQpUT00gKDMpIDogLi4uYmFzZWQg b24gdGhlIHR3byBhYm92ZSBkZWZpbml0aW9ucyAuLi5pcyBhbiBpbnRlcm1lZGlhdGUgbm9kZSBo ZW5jZSBlcXVhbCB0byBhICJMb3NzIGRldGVjdG9yIj8gIA0KICAgICsgSG93IGRvZXMgYSBMb3Nz IGRldGVjdG9yIGRpZmZlciBmcm9tIGFuIFJUUCByZWNlaXZlcj8NCiAgICBbUWluXTogVGhlIGxv c3MgZGV0ZWN0b3IgaXMganVzdCBvbmUgZnVuY3Rpb25hbGl0eSBvZiBEaXN0cmlidXRpb24gU291 cmNlIGluIHRoZSBTU00gdXNlIGNhc2UuDQogICAgTWF5YmUgd2Ugc2hvdWxkIGludGVycHJldCBp dCBhcyAiTG9zcyBkZXRlY3Rpb24gZnVuY3Rpb25hbGl0eSIuIEhvdyB0aGUgcGFja2V0IGxvc3Mg aXMgZGV0ZWN0ZWQgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQogICAgRGlmZmVy ZW50IGZyb20gZGVkaWNhdGVkIFJUUCByZWNlaXZlciwgdGhlIGludGVybWVkaWF0ZSBub2RlIGRv ZXMgbm90IGRlcGVuZCBvbiBleGlzdGluZyBOQUNLIG1lc3NhZ2UgZm9yIFJldHJhbnNtaXNzaW9u IHJlcXVlc3QgZm9yIHBhY2tldCBsb3NzLg0KICAgIHRoZSBpbnRlcm1lZGlhdGUgbm9kZSBjYW4g Y3JlYXRlIG1lc3NhZ2UgYnkgaXRzZWxmLg0KDQogICAgU2VjdGlvbiA2LjENCkluIG9yZGVyIHRv IGF2b2lkIHRoZSBmb3JtcyBvZiBOQUNLIGltcGxvc2lvbiBkZXNjcmliZWQgaW4gc2VjdGlvbiAx LA0KICAgdGhlIExvc3MgRGV0ZWN0b3IgaXMgaW50cm9kdWNlZC4gIFRoZSBMb3NzIERldGVjdG9y IGRldGVjdHMgYW5kDQogICByZXBvcnRzIHBhY2tldCBsb3NzLCBvbiBib3RoIHRoZSB1cHN0cmVh bSBsaW5rIGFuZCB0aGUgZG93bnN0cmVhbQ0KICAgYWdncmVnYXRlIGxpbmsuICBIb3cgdGhlIGxv c3MgZGV0ZWN0b3IgU0hPVUxEIGRldGVjdCB0aGUgcGFja2V0IGxvc3MNCiAgIGlzIGJleW9uZCBv ZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAgV2hlbiB1cHN0cmVhbSBsaW5rIG9yDQogICBkb3du c3RyZWFtIGFnZ3JlZ2F0ZSBsaW5rIHBhY2tldCBsb3NzIG9jY3VycywgdGhlIExvc3MgRGV0ZWN0 b3IgTUFZDQogICBpbmZvcm0gZGlzdHJpYnV0aW9uIHNvdXJjZSBvZiB0aGUgZGV0ZWN0ZWQgcGFj a2V0IGxvc3MgdXNpbmcgRmVlZGJhY2sNCiAgIFN1cHByZXNzaW9uIG1lc3NhZ2VzLiAgSW4gcmVz cG9uc2UsIHRoZSBkaXN0cmlidXRpb24gc291cmNlIGVpdGhlcg0KICAgZm9yd2FyZHMgcGFja2V0 IGxvc3Mgc3VwcHJlc3Npb24gcmVwb3J0IHJlY2VpdmVkIGZyb20gTG9zcyBEZXRlY3Rvcg0KICAg b3IgY3JlYXRlcyBhIEZlZWRiYWNrIFN1cHByZXNzaW9uIHJlcG9ydCBhbmQgc2VuZHMgaXQgdG8g YWxsIHRoZSBSVFANCiAgIHJlY2VpdmVycywgb3ZlciB0aGUgbXVsdGljYXN0IGNoYW5uZWwuICBU aGlzIGxvc3Mgc3VwcHJlc3Npb24gcmVwb3J0DQogICB0ZWxscyB0aGUgcmVjZWl2ZXJzIHRoYXQg dGhlIGxvc3QgcGFja2V0IHdpbGwgZWl0aGVyIGJlIGZvcnRoY29taW5nDQogICBmcm9tIGRpc3Ry aWJ1dGlvbiBzb3VyY2UsIG9yIGl0IGlycmV0cmlldmFibHkgbG9zdCBzdWNoIHRoYXQgdGhlcmUg aXMNCiAgIG5vdGhpbmcgdG8gYmUgZ2FpbmVkIGJ5IHRoZSByZWNlaXZlciBzZW5kaW5nIGEgTkFD SyB0byB0aGUgbWVkaWENCiAgIHNvdXJjZS4gIFRoZSBkaXN0cmlidXRpb24gc291cmNlIHRoZW4g Y2FuIChvcHRpb25hbGx5KSBhc2sgZm9yIHRoZQ0KICAgbG9zdCBwYWNrZXRzIGZyb20gdGhlIG1l ZGlhIHNvdXJjZSBvbiBiZWhhbGYgb2YgYWxsIHRoZSBSVFANCiAgIHJlY2VpdmVycy5UT00gKDQp IDogWW91IHByb2JhYmx5IGRvIG5vdCB3YW50IHRvIGhhdmUgbm9ybWF0aXZlIGxhbmd1YWdlIGlu IHNlY3Rpb24gNi4xLCBsaWtlICJIb3cgdGhlIGxvc3MgZGV0ZWN0b3IgU0hPVUxEICguLikiLiBb UWluXTpTb3JyeSwgSSBjYW4ndCBnZXQgaXQuIFRPTTogdGhpcyBpcyByZWFsbHkgYSBkZXRhaWwu IElmIHlvdSB3YW50IHRvIGtlZXAgdGhlIHNlbnRlbmNlLCB5b3Ugc2hvdWxkIGUuZy4gc2F5OiAi SG93IHRoZSBsb3NzIGRldGVjdG9yIGNhbiBkZXRlY3QgdGhlIHBhY2tldCBsb3NzLi4uIFtRaW5d T2theS5UT00gKDUpIDogSXQgaXMgcHJldHR5IGNsZWFyIGhvdyBhIExvc3MgZGV0ZWN0b3Igd2ls bCBkZXRlY3QgcGFja2V0IGxvc3Mgb24gaXRzIHVwc3RyZWFtIGxpbmssIEkgZ3Vlc3MuW1Fpbl06 IEFzIEkgc2FpZCBhYm92ZSwgIExvc3MgZGV0ZWN0b3IgaXMganVzdCBmdW5jdGlvbmFsaXR5IG9m IHNvbWUgRGlzdHJpYnV0aW9uIHNvdXJjZXMuICBBbHNvIHdoYXQgaXQgc2FpZCBoZXJlIGluIHNl Y3Rpb24gNi4xIGlzIGp1c3Qgb25lIGV4YW1wbGUgdXNlIGNhc2UuVE9NICg2KTogIFdoYXQgaXMg dGhlIHJhdGlvbmFsZSBmb3IgYSBsb3NzIGRldGVjdG9yIHRvIHNlbmQgYSBGZWVkYmFjayBzdXBw cmVzc2lvbiBtZXNzYWdlIHRvIHRoZSBEUy4uIHdoeSBOT1QgYSBSVENQIE5BQ0sgRkI/W1Fpbl06 IEFzIEkgZXhwbGFpbmVkIGluIHRoZSBsYXN0IElFVEYgcHJlc2VudGFpb24sICB0aGlzIGNhdXNl IE5BQ0sgc2NlbWF0aWNzIG1pc21hdGNoLiBUaGF0J3Mgd2h5IG1hbnkgcGVvcGxlIGluIHRoZSBs YXN0IElFVEYgbWVlZXRpbmcgc3VnZ2VzdCB0byBjcmVhdGUgbmV3IFJUQ1AgbWVzc2FnZSBkdXJp bmcgcHJlc2VudGF0aW9uLiBUT006IEFzIHlvdXIgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZSBsb3Nz IHJlcG9ydGVyIGlzIHBhcnQgb2YgdGhlIEZUIHRoYXQgaXMgcGFydCBvZiB0aGUgRFMsIHRoZW4g dGhlcmUgaXMgZXZlbiBubyBuZWVkIHRvIHNwZWNpZnkgaG93IHRoZSBsb3NzIGRldGVjdG9yIHJl cG9ydHMgdGhlIHBhY2tldCBsb3NzLiAgSW4gdGhlIG1vcmUgZ2VuZXJpYyBjYXNlLCBpdCBtYWtl cyBtb3JlIHNlbnNlIHRvIG1lIHRoYXQgdGhlIGxvc3MgcmVwb3J0ZXIganVzdCB1c2VzIGEgTkFD SyAob3IgYSBGSVIpIGlmIGl0IGRldGVjdHMgcGFja2V0IGxvc3MsIHNlbnQgdG93YXJkcyBpdHMg RlQgb3IgdG8gdGhlIERTIGlmIHRoaXMgb25lIGhvc3RzIHRoZSBGVCB0aGF0IHRoZSBsb3NzIGRl dGVjdG9yIHJlcG9ydHMgdG8gLiBJdCBpcyB0aGVuIHVwIHRvIHRoZSBGVCBvciB0aGUgRFMgdG8g ZGVjaWRlIHdoZXRoZXIgdGhpcyBtZXNzYWdlIHRyaWdnZXJzIGEgTkFDSyBvciBGSVIgc3VwcHJl c3Npb24gaW5kaWNhdGlvbiB0byAocyBzdWJzZXQgb2YpIHRoZSByZWNlaXZlcnMuICBUaGlzIHN1 cHByZXNzaW9uIGluZGljYXRpb24gZG9lcyBub3QgbmVjZXNzYXJseSByZXF1aXJlIGEgbmV3IG1l c3NhZ2UgZm9ybWF0LiBBIE5BQ0svRklSICB0aGF0IGlzIHNlbnQgdG8gYSBSVFAgcmVjZWl2ZXIg Y2FuIGJlIGRlZmluZWQgYXMgYSBmZWVkYmFjayBzdXBwcmVzc2lvbiBpbmRpY2F0aW9uLiBJIGRv IG5vdCBzZWUgYSBnb29kIHVzZSBjYXNlIHdoeSBOQUNLcyBmcm9tICByZWNlaXZlcnMgIHdvdWxk IGJlIHJlZmxlY3RlZCBiYWNrIGluIGUuZy4gU1NNIHVzZSBjYXNlIGJ5IERTIG9yIEZUICB0byBh bGwgdGhlIGNvbm5lY3RlZCByZWNlaXZlcnMuIElmIHdlIGRlZmluZSB0aGF0IGEgTkFDSy9GSVIg IGZvciBhIFNTTSBtYXkgb25seSBiZSBzZW50IFRPV0FSRFMgYSBSVFAgcmVjZWl2ZXIsIGlmIHRo aXMgaXMgZm9yIHN1cHByZXNzaW9uIGluZGljYXRpb24sIHRoZXJlIGlzIG5vIGFtYmlndWl0eSBw b3NzaWJseS4gICAgW1Fpbl06IFRvIG1lLCBOQUNLIGlzIHVlc2VkIHRvIHJlcXVlc3QgcGFja2V0 IGxvc3MgcmV0cmFuc21pc3Npb24gZnJvbSB0aGUgc2VydmVyLCBOQUNLIGhhcyBubyBzY2VtYW50 aWNzIGZvciBmZWVkYmFjayBzdXBwcmVzc2lvbi4gdGhlIGludGVybWVkaWF0ZSBub2RlIGUuZy4s IGRpc3RyaWJ1dGlvbnNvdXJjZSB3aWxsIGNvbmZ1cyB3aGV0aGVyIHRoZSBOQUNLIHNob3VsZCBi ZSBmb3J3YXJkZWQgdG8gdGhlIHNlcnZlciBvciB0aGUgcmVjZWl2ZXIudW5saWtlIE5BQ0ssIEZl ZWRiYWNrIFN1cHByZXNzaW9uIG1lc3NhZ2UgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0IGlzIHVzZWQg YnkgdGhlIGludGVybWVkaWF0ZSBub2RlL21pZGRsZWJveCB0byBub3RpZnkgYWxsIHRoZSByZWNl aXZlciB0aGF0IHNlbmRpbmcgTkFDSyBtYXkgYmUgbm90IG5lY2Vzc2FyeSBhbmQgaGFybWZ1bC50 aGUgaW50ZXJtZWRpYXRlIG5vZGUgd2lsbCBrbm93IGhvdyB0byBkZWFsIHdpdGggdGhlIEZlZWRi YWNrIFN1cHByZXNzaW9uIG1lc3NhZ2UgYW5kIHdpbGwgbm90IGNhdXNlIHNjZW1hbnRpY3MgY29u ZnVzaW9uIGxpa2UgcmVjZWl2aW5nIE5BQ0suT25lIGltcG9ydGFudCB0aGluZyBpcyBGZWVkYmFj ayBzdXBwcmVzc2lvbiBjYW4gYmUgdXNlZCB3aXRob3V0IHJlY2VpdmluZyBBTlkgTkFDS3MuIHRo YXQgaXMgd2h5IG1hbnkgcGVvcGxlIHRoaW5rIHdlIHNob3VsZCBkZWZpbmUgbmV3IG1lc3NhZ2Ug YWx0aHVnaCB0aGUgbmV3IG1lc3NhZ2UgaGFzIHRoZSBzaW1pbGFyIGZvcm1hdCBhcyBOQUNLLlRo ZXJlZm9yZSBJIHRoaW5rIHVzaW5nIE5BQ0sgc2VudCBmcm9tIHNvbWUgZGVkaWNhdGVkIHJlY2Vp dmVyIGlzIGp1c3Qgb25lIHdheSBmb3IgdGhlIGRpc3RyaWJ1dGlvbiBzb3VyY2UgdG8ga25vdyBw YWNrZXQgbG9zcyBoYXBwZW4uIEJ1dCBub3QgdGhlIG9ubHkgd2F5LlNlY3Rpb24gNi4xLjFJZiB0 aGVyZSBhcmUgbXVsdGlwbGUgTG9zcyBEZXRlY3RvcnMgbG9va2luZyBhdCB0aGUgc2FtZSBSVFAg c3RyZWFtLA0KICAgdGhlbiB0aGUgbG9zcyBtYXkgYmUgaWRlbnRpZmllZCBieSBtb3JlIHRoYW4g b25lIGFuZCB0aG9zZSBkZXRlY3RpbmcNCiAgIHRoZSBsb3NzIHdpbGwgYWxsIHNlbmQgcmVxdWVz dHMgZm9yIHRoZSBzYW1lIHBhY2tldCBsb3NzLiAgSW4gdGhpcw0KICAgY2FzZSwgdGhlIGRpc3Ry aWJ1dGlvbiBzb3VyY2UgTVVTVCBmaWx0ZXIgdGhlIGR1cGxpY2F0ZWQgcGFja2V0IGxvc3MNCiAg IHJlcXVlc3Qgb3V0IGFuZCBvbmx5IGZvcndhcmQgb25lIGNvcHkgb2YgdGhlIFJUQ1AgRmVlZGJh Y2sgcmVwb3J0DQogICBwYWNrZXQgZnJvbSB0aGUgZmlyc3QgTG9zcyBEZXRlY3RvciB0byB0aGUg Z3JvdXAgaW1wYWN0ZWQgYnkgcGFja2V0DQogICBsb3NzLg0KVE9NICg3KSA6IGhvdyB3aWxsIHRo ZSBEUyBzZW5kIG9ubHkgYSBjb3B5IG9mIHRoZSBSVENQIEZCIHJlcG9ydCBwYWNrZXQgdG8gdGhl IGdyb3VwIGltcGFjdGVkIGJ5IHBhY2tldCBsb3NzLiBJcyB0aGlzIGRvbmUgb3ZlciB0aGUgU1NN PyANCg0KICAgIFtRaW5dOiBTb3JyeSwgbWF5YmUgSSBzb3VsZCBzYXkgDQogICAgIg0KICAgIFNl Y3Rpb24gNi4xLjENCiAgICBJZiB0aGVyZSBhcmUgbXVsdGlwbGUgRGlzdHJiaXR1dGlvbiBTb3Vy Y2Ugd2l0aCB0aGUgbG9zcyBkZXRlY3Rpb24gc3VwcG9ydCBsb29raW5nIGF0IHRoZSBzYW1lIFJU UCBzdHJlYW0uLi4uLg0KICAgICINCiAgICBZZXMsICBpbiB0aGUgU1NNIHVzZSBjYXNlLCBEUyBz ZW5kIG9ubHkgYSBjb3B5IG9mIHRoZSBSVENQIEZlZWRiYWNrIFN1cHByZXNzaW9uIFJlcG9ydCBw YWNrZXQgdGhlIGdyb3VwIHZpYSBTU00uDQoNCiAgICBJbiB5b3VyIGV4YW1wbGUgeW91IHNlZW0g dG8gZm9jdXMgb25seSBvbiBhcmNoaXRlY3R1cmVzIHdpdGggYSBEUyB3aGljaCBhbHNvIGhvc3Rz IHRoZSBGVCBhbmQgdGhlIGxvc3MgcmVwb3J0ZXIuICBUaGVyZSBzaG91bGQgYmUgc2VjdGlvbnMg Y292ZXJpbmcgY2FzZXMgd2hlcmUgdGhlIERTIGlzIGRpc2pvaW50IGZyb20gdGhlIEZULCB3aXRo IHNldmVyYWwgRlRzIGFuZCBhbHNvIHNldmVyYWwgbG9zcyByZXBvcnRlcnMgZGlzam9pbnQgZnJv bSB0aGUgRlQgYW5kIHRoZSBEUy4NCg0KICAgIFtRaW5dIEkgYW0gbm90IHN1cmUgd2UgbmVlZCB0 byBhZGRyZXNzIGFsbCB0aGUgcG9zc2libGUgU1NNIHVzZSBjYXNlcy4gSW4gdGhpcyBkcmFmdCwg d2UganVzdCBnaXZlIHNvbWUgZXhhbXBsZXMgb2YgU1NNIHVzZSBjYXNlLg0KDQogICAgVE9NICg4 KSA6IHdoYXQgZG8geW91IG1lYW4gaW4gYWJvdmUgdGV4dCB3aXRoICJSVENQIEZCIHJlcG9ydCIu LiBpcyB0aGF0IHRoZSBzdXBwcmVzc2lvbiBtZXNzYWdlIHlvdSBkZWZpbmUgaW4gdGhpcyBkcmFm dD8NCg0KICAgIFtRaW5dOiBZZXMsICBSVENQIEZlZWRiYWNrIFN1cHByZXNzaW9uIFJlcG9ydC4g DQoNCiAgICBUT00gKDkpIDogSW4gc2VjdGlvbiAgIjYuMS4yLiAgRGlzdHJpYnV0aW9uIFNvdXJj ZSBGZWVkYmFjayBTdW1tYXJ5IE1vZGVsIiBpdCBpcyBub3QgY2xlYXIgd2hhdCB5b3VyIGFyY2hp dGVjdHVyZSBsb29rcyBsaWtlLiBZb3UgdGFsayBhYm91dCBtdWx0aXBsZSBkaXN0cmlidXRpb24g c291cmNlcy4uIHdoY2loIGltcGxpZXMgbXVsdGlwbGUgU1NNcy4uIENhbiB5b3UgZWxhYm9yYXRl IG9uIHRoYXQ/DQoNCiAgICBbUWluXTogIFRoZSBzY2VuYXJpbyB3ZSBhcmUgdGFsa2luZyBhYm91 dCBpbiAgdGhlIHNlY3Rpb24gNi4xLjIsIGlzIHRvICBhbGxvdyBtdWx0aXBsZSBEaXN0cmJpdHVp b24gc291cmNlIGJldHdlZW4gbWVkaWEgc291cmNlIGFuZCB0aGUgcmVjZWl2ZXIuIEkgd2lsbCBs b29rIGF0IHRoZSB0aGlzIGNhc2UgYXMgb25lIHNwZWNpYWwgU1NNIGNhc2UuIGJlY2F1c2UgIGVh Y2ggb2YgZGlzdHJiaXR1aW9uIHNvdXJjZSByZXNpZGVzIGF0IHRoZSB1cHN0cmVhbSBkaXJlY3Rp b24gb3IgZG93bnN0cmVhbSBkaXJlY3Rpb24gb2Ygb3RoZXIgZGlzdHJpYnV0aW9ucyBzb3VjZXMu IERvZXMgaXQgbWFrZSBzZW5zZT8gDQoNCiAgICBUT006IFJGQyA1NzYwIG9ubHkgZGVmaW5lcyBv bmUgRFMgZm9yIGEgZ2l2ZW4gU1NNLiBJZiB5b3UgZGVwYXJ0IGZyb20gdGhhdCwgeW91IHByb2Jh Ymx5IG5lZWQgdG8gYWRkcmVzcyBhbmQgZGVmaW5lIHRoaXMgYXJjaGl0ZWN0dXJlIGluIGEgYmV0 dGVyIHdheSBpbiB5b3VyIGRyYWZ0LiANCg0KICAgIFtRaW5dOiBPa2F5Lg0KDQogICAgVG9tICgx MCkgOiAgSW4gc2VjdGlvbiAgNi4zLiAgTXVsdGlwb2ludCBDb250cm9sIFVuaXQgKE1DVSkgdXNl IGNhc2UsICB0eXBpY2FsbHkgYW4gb3ZlcmxheSBvZiB1bmljYXN0IGlzIHVzZWQuLi4gd2lsbCB0 aGUgRmVlZGJhY2sgc3VwcHJlc3Npb24gbWVzc2FnZSBiZSBzZW50IG92ZXIgdW5pY2FzdCBhcyB3 ZWxsPyBJZiBzbywgd2hhdCBpcyBnYWluIGNvbXBhcmVkIHRvIGp1c3QgaGF2aW5nIGVhY2ggUlRD UCByZWNlaXZlciBwcm92aWRpbmcgZWFjaCB0aGVpciBOQUNLIHRvIHRoZSBNQ1UsIGV2ZW4gaW4g Y2FzZSBvZiBhIHBhY2tldCBsb3NzIGltcGFjdGluZyBhbGwgcmVjZWl2ZXJzPw0KDQogICAgW1Fp bl06IEZpcnN0IFRoZSBNQ1UgY2FzZSB3aWxsIG5vdCBjYXVzZSBOQUNLIEltcGxvc2lvbiwgaW5z dGVhZCwgaXQgbWF5IGNhdXNlIEZJUiBpbXBsb3Npb24uDQogICAgICAgICAgICAgICBTZWNvbmQs IHVzaW5nIEZlZWRiYWNrIHN1cHByZXNzaW9uIG1lc3NhZ2UgY2FuIHJlc3RyaWN0IHRoZSBGSVIg bWVzc2FnZSBzZW50IGZyb20gcmVjZWl2ZXJzIGJlaGluZCBNQ1UgYW5kIGxpYmVyYXRlIHRoZSBt ZWRpYSBzb3VyY2UgZnJvbSAgRklSIGltcGxvc2lvbi4gDQoNCiAgICBUT006IGl0IGlzIG5vdCBp bXBvcnRhbnQgd2hldGhlciB0aGlzIGlzIGFib3V0IEZJUiBvciBOQUNLLiBNeSBwb2ludCBpcyB0 aGF0IGlzbyBoYXZpbmcgZWFjaCByZWNlaXZlciBzZW5kaW5nIGEgTkFDSy9GSVIsIHlvdSB3aWxs IG5vdyBoYXZlIHRvIHNlbmQgdG8gZWFjaCByZWNlaXZlciBhIE5BQ0svRklSICBzdXBwcmVzc2lv biBpbiB0aGUgZ2l2ZW4gc2NlbmFyaW8uIFRoZXJlIGFyZSBubyBkaWZmZXJlbmNlcyBpbiB0ZXJt cyBvZiBCYW5kd2RpdGggb3ZlcmhlYWQgb3Igc2VydmVyIGxvYWQgaW4gdGhlIHR3byBjYXNlcywg c28gd2h5IGJvdGhlciB0byBzZW5kIHN1cHByZXNzaW9uIG1lc3NhZ2VzPw0KDQogICAgW1Fpbl06 IE5vLCBvbmUgZWZmZWN0aXZlIHVzZSBjYXNlIGlzIHN1cHBvc2UgcGFja2V0IGxvc3MgY2FuIG5v dCByZXBhaXJlZCwgdGhlIE1DVSBjYW4gdXNlIGZlZWRiYWNrIHN1cHByZXNzaW9uIG1lc3NhZ2Ug dG8gdGVsbCB0aGUgcmVjZWl2ZXIgbm90IGFzayBmb3IgbG9zdCBwYWNrZXQuDQoNCiAgICBUb20g KDExKSA6IGNvbWluZyBiYWNrIHRvIG15IHByZXZpb3VzIGNvbW1lbnQgb24gU0RQIGRlc2NyaXB0 aW9uIGluIHRoaXMgZHJhZnQgOiBpZiB0aGlzIGRyYWZ0IGRlZmluZXMgYSBSVENQIGZlZWRiYWNr IHN1cHByZXNzaW9uIG1lc3NhZ2UsIHdoeSBpcyB0aGVyZSBuZWVkIGZvciBhICJhbm5vdW5jZW1l bnQiIGluIHRoZSBTRFAgZm9yIHRoZSByZWNlaXZlcnMsIHRoYXQgaW5kaWNhdGVzIHRoZXkgbWF5 IHJlY2VpdmUgc3VjaCBmZWVkYmFjayBzdXBwcmVzc2lvbiBtZXNzYWdlcz8gIElmIGEgcmVjZWl2 ZXIgc3VwcG9ydHMgdGhlIG1lc3NhZ2UsIGl0IHdpbGwgIHNpbXBseSBhY3QgYWNjb3JkaW5nbHkg YXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCwgbm8gbmVlZCB0byBhbm5vdW5jZSB0aGF0IS4uIA0K DQogICAgW1Fpbl06IE9rYXksIEkgZ2V0IHlvdXIgcG9pbnQuIEkgd291bGQgbGlrZSB0byBwdXQg dGhpcyBhcyBvcGVuIGlzc3VlLCBkaXNjdXNzIGl0IGluIHRoZSBmYWNlIHRvIGZhY2UgSUVURiBt ZWV0aW5nLg0KDQogICAgUmVnYXJkcw0KICAgIFRvbQ0KDQoNCg0KDQoNCg== --Boundary_(ID_64NZ7WKETdvs69DBTt28xQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xODkyOCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2NjZThjZj4NCjxESVY+SGksIFRvbTo8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8QkxP Q0tRVU9URSANCnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJTkct TEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1S SUdIVDogMHB4IiANCmRpcj1sdHI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYj MjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgQkFDS0dST1VORDogI2U0ZTRlNDsgZm9udC1j b2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9dG9tLnZhbl9jYWVuZWdlbUBh bGNhdGVsLWx1Y2VudC5jb20gDQogIGhyZWY9Im1haWx0bzp0b20udmFuX2NhZW5lZ2VtQGFsY2F0 ZWwtbHVjZW50LmNvbSI+VmFuIENhZW5lZ2VtLCBUb20gKFRvbSk8L0E+IA0KICA8L0RJVj4NCiAg PERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0 bGU9c3Vuc2Vhd3FAaHVhd2VpLmNvbSANCiAgaHJlZj0ibWFpbHRvOnN1bnNlYXdxQGh1YXdlaS5j b20iPlFpbiBXdTwvQT4gOyA8QSB0aXRsZT1hdnRAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzph dnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4gVHVlc2RheSwgT2N0b2JlciAxOSwg MjAxMCA0OjI2IFBNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAz MDc7Ij48Qj5TdWJqZWN0OjwvQj4gUkU6IFtBVlRdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAN CiAgZm9yIGRyYWZ0LXd1LWF2dC1yZXRyYW5zbWlzc2lvbi1zdXByZXNzaW9uLXJ0cC0wNDwvRElW Pg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xh c3M9Mjg5MzQwMjA3LTE5MTAyMDEwPjxGT05UIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9MiBmYWNl PUFyaWFsPkhpIFFpbiw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249 bGVmdD48U1BBTiBjbGFzcz0yODkzNDAyMDctMTkxMDIwMTA+PEZPTlQgY29sb3I9IzAwMDBmZiAN CiAgc2l6ZT0yIGZhY2U9QXJpYWw+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBk aXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9Mjg5MzQwMjA3LTE5MTAyMDEwPjxGT05UIGNv bG9yPSMwMDAwZmYgDQogIHNpemU9MiBmYWNlPUFyaWFsPlRoYW5rIHlvdSBmb3IgeW91ciByZXBs eS48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz0yODkzNDAyMDctMTkxMDIwMTA+PEZPTlQgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yIGZh Y2U9QXJpYWw+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9Mjg5MzQwMjA3LTE5MTAyMDEwPjxGT05UIGNvbG9yPSMwMDAwZmYg DQogIHNpemU9MiBmYWNlPUFyaWFsPlJlYWRpbmcgeW91ciByZXNwb25zZXMseW91IHNlZW0gdG8g Zm9jdXMgcmVhbGx5IG9uIHRoZSANCiAgU1NNJm5ic3A7IGNhc2Ugd2l0aCBhbiBhcmNoaXRlY3R1 cmUgd2hlcmUgdGhlIHNpbmdsZSBEUyAodGhlcmUgY2FuIGJlIG9ubHkgb25lIA0KICBEUyBwZXIg U1NNKSBob3N0cyB0aGUgc29sZSBmZWVkYmFjayB0YXJnZXQsIHdoaWNoIGFsc28gaG9zdHMgdGhl IGxvc3MgZGV0ZWN0b3IgDQogIGZ1bmN0aW9uLiBNeSBpbnRlcnByZXRhdGlvbiBpcyBhbHNvIHRo YXQgaW4geW91ciBkcmFmdCB0aGUgbG9zcyBkZXRlY3RvciBzZW5kcyANCiAgdGhlIEZJUiBvciBO QUNLIHN1cHJlc3Npb24gbWVzc2FnZSB0byB0aGUgRFMsIHdoaWNoIHRoZW4gZm9yd2FyZHMvcmVs YXlzIA0KICB0aGlzJm5ic3A7bWVzc2FnZSBvdmVyIHRoZSBTU00gdG8gYWxsIHJlY2VpdmVycywg cmlnaHQ/Jm5ic3A7IA0KICA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxp Z249bGVmdD48U1BBTiBjbGFzcz0yODkzNDAyMDctMTkxMDIwMTA+PEZPTlQgY29sb3I9IzAwMDBm ZiANCiAgc2l6ZT0yIGZhY2U9QXJpYWw+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJ ViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9Mjg5MzQwMjA3LTE5MTAyMDEwPjxGT05U IHNpemU9MiANCiAgZmFjZT1BcmlhbD5bUWluXTogU1NNIGNhc2UgaXMganVzdCBvbmUgZXhhbXBs ZSBjYXNlIGluIHRoaXMgZHJhZnQuIFdlIGhhdmUgDQogIGFsc28gZGlzY3Vzc2VkIFRyYW5zcG9y dCB0cmFuc2xhdG9yIHVzZSBjYXNlIGFuZCBNQ1UgdXNlIGNhc2UuIFRoaXMgZHJhZnQgDQogIGZv Y3VzIG9uIGhvdyB0aGUgZmVlZGJhY2sgc3VwcHJlc3Npb24gd29ya3MgaW4gdGhlc2UgZGlmZmVy ZW50IHVzZSANCiAgY2FzZXMuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFs aWduPWxlZnQ+PFNQQU4gY2xhc3M9Mjg5MzQwMjA3LTE5MTAyMDEwPjxGT05UIHNpemU9MiANCiAg ZmFjZT1BcmlhbD5Gb3IgdGhlIFNTTSB1c2UgY2FzZSwgd2UgbWF5IGNvbnNpZGVyIG11bHRpcGxl IGRpc3RyaWJ1dGlvbiBzb3VyY2VzIA0KICBwbGFjZWQgYmV0d2VlbiBtZWRpYSBzb3VyY2UgYW5k IHRoZSByZWNlaXZlci4gVGhlIGxvc3MgZGV0ZWN0b3IgaXMganVzdCBvbmUgDQogIGZ1bmN0aW9u YWxpdHkgb2YgRGlzdHJpYnV0aW9uIHNvdXJjZSwgb3IgUmV0cmFuc21pc3Npb24gU2VydmVyIG9y IE1DVSwgb3IgDQogIFRyYW5zcG9ydCBUcmFuc2xhdG9yLiBJdCBkb2VzIG5vdCBoYXZlIHRvIGJl IHB1dCBhcyBwYXJ0IG9mIGZlZWRiYWNrIHRhcmdldC4gSSANCiAgcHJvcG9zZSB0byByZW1vdmUg dGhlIHN0dWZmJm5ic3A7b2YgIkxvc3MgZGV0ZWN0b3IiIGZyb20gdGhpcyBkcmFmdCwgaW5zdGVh ZCwgDQogIHVzaW5nIERpc3RyaWJ1dGlvbiBzb3VyY2Ugd2l0aCBsb3NzIGRldGVjdGlvbiBzdXBw b3J0LiBXaGF0IGRvIHlvdSB0aGluayBvZiANCiAgaXQ/PC9GT05UPjwvU1BBTj48L0RJVj4NCiAg PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9Mjg5MzQwMjA3LTE5MTAyMDEwPjxG T05UIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9MiBmYWNlPUFyaWFsPjwvRk9OVD48L1NQQU4+Jm5i c3A7PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTI4OTM0MDIw Ny0xOTEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTIgZmFjZT1BcmlhbD5NeSBt YWluIGNvbW1lbnQgcmVtYWlucyB0aGUgc2FtZTogeW91IHNob3VsZCBhdCBsZWFzdCANCiAgaW5j b3Jwb3JhdGUgdGhlIGFyY2hpdGVjdHVyZSBvZiBSQU1TICh3aGVyZSZuYnNwO3RoZXJlJm5ic3A7 Y2FuIGJlIHNldmVyYWwgDQogIEZUJm5ic3A7IGNvbG9jYXRlZCB3aXRoIHRoZSBCUlMsIHdoaWNo IGFyZSBkaXNqb2ludCBmcm9tIHRoZSBEUykuIEluIHRoaXMgY2FzZSANCiAgdGhlIEZUL0JSUyBz aG91bGQgYmUgYWJsZSB0byBwcm92aWRlIGEgc3VwcHJlc3Npb24gaW5kaWNhdGlvbiB0byBhbGwg cmVjZWl2ZXJzIA0KICB0aGF0IHJlcG9ydCB0byB0aGlzIEZUICh3aGljaCBpcyBhIHN1YnNldCBv ZiBhbGwgcmVjZWl2ZXJzIHRoYXQgY29ubmVjdCB0byB0aGUgDQogIFNTTSksIHdoaWNoIG1lYW5z IG9uZSBzaG91bGQgbm90IG1ha2UgdXNlIG9mIHRoZSAob3JpZ2luYWwpIFNTTSBmb3IgcHJvdmlk aW5nIA0KICB0aGUgc3VwcHJlc3Npb24gaW5kaWNhdGlvbi4mbmJzcDsgWW91ciBkcmFmdCBwcm92 aWRlcyBhIHBvc3NpYmxlIHNvbHV0aW9uIGZvciANCiAgb25seSBhIGxpbWl0ZWQgdXNlIGNhc2Us IGFuZCBub3QgdGhlIG1vc3QgaW50ZXJlc3Rpbmcgb25lLCANCiAgSU1PLiZuYnNwOyZuYnNwOzwv Rk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNz PTI4OTM0MDIwNy0xOTEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTIgZmFjZT1B cmlhbD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVm dD48U1BBTiBjbGFzcz0yODkzNDAyMDctMTkxMDIwMTA+PEZPTlQgc2l6ZT0yIA0KICBmYWNlPUFy aWFsPltRaW5dOiBJIHRoaW5rIFJBTVMgY2FzZSZuYnNwO2lzIGp1c3Qgb25lIHNwZWNpYWwgY2Fz ZSBvZiZuYnNwO1NTTSANCiAgdXNlIGNhc2UuJm5ic3A7aG93IEZlZWRiYWNrIHN1cHByZXNzaW9u IHdvcmtzIGZvciBTU00gdXNlIGNhc2UgdGhlcmZvcmUgaXMgDQogIHF1aXRlIHNpbWlsYXIgdG8g UkFNUywgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyBEaXN0cmJpdHVpb24gc291cmNlIGluIHRoZSBT U00gDQogIGNhc2UgaXMgcmVwbGFjZWQgd2l0aDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYg ZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTI4OTM0MDIwNy0xOTEwMjAxMD48Rk9OVCBz aXplPTIgDQogIGZhY2U9QXJpYWw+QlJTIGluIHRoZSBSQU1TLiBBcyByZWdhcmRpbmcmbmJzcDth bm90aGVyIFJBTVMgY2FzZSB3aGVyZSBzZXZlcmFsIA0KICBGVHMgc2VwYXJhdGVkIGZyb20gQlJT LCZuYnNwOyZuYnNwOyA8L0ZPTlQ+PC9TUEFOPjxTUEFOIA0KICBjbGFzcz0yODkzNDAyMDctMTkx MDIwMTA+PEZPTlQgc2l6ZT0yIGZhY2U9QXJpYWw+d2UgY2FuIGFkZHJlc3MgdGhpcyBjYXNlIGlm IA0KICB0aGVyZSZuYnNwO2FyZSBzdHJvbmcmbmJzcDtpbnRlcmVzdHMuJm5ic3A7PC9GT05UPjwv U1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9Mjg5MzQw MjA3LTE5MTAyMDEwPjxGT05UIHNpemU9MiANCiAgZmFjZT1BcmlhbD5CdXQgdG8gYmUgY2xlYXIs IHRoaXMgZHJhZnQgZm9jdXMgb24gaG93IEZlZWRiYWNrIHN1cHByZXNzaW9uIA0KICBtZXNzYWdl IHdvcmtzIGluIGRpZmZlcmVudCB1c2UgY2FzZSwgbm90IGZvciBvbmUgc3BlY2lmaWMgdXNlIA0K ICBjYXNlLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxT UEFOIGNsYXNzPTI4OTM0MDIwNy0xOTEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIA0KICBzaXpl PTIgZmFjZT1BcmlhbD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWIGRpcj1sdHIg YWxpZ249bGVmdD48U1BBTiBjbGFzcz0yODkzNDAyMDctMTkxMDIwMTA+PEZPTlQgY29sb3I9IzAw MDBmZiANCiAgc2l6ZT0yIGZhY2U9QXJpYWw+RnVydGhlciBkb3duJm5ic3A7c29tZSZuYnNwO3Jl c3BvbnNlcyB0byB5b3VyIGFuc3dlcnMgDQogIGJlbG93LjwvRk9OVD48L1NQQU4+PC9ESVY+DQog IDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTI4OTM0MDIwNy0xOTEwMjAxMD48 Rk9OVCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTIgZmFjZT1BcmlhbD48L0ZPTlQ+PC9TUEFOPiZu YnNwOzwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0yODkzNDAy MDctMTkxMDIwMTA+PEZPTlQgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yIGZhY2U9QXJpYWw+VG9t PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xh c3M9Mjg5MzQwMjA3LTE5MTAyMDEwPjxGT05UIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9MiBmYWNl PUFyaWFsPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+PEZPTlQgDQogIHN0eWxlPSJCQUNLR1JP VU5ELUNPTE9SOiAjZmZmZmZmIiBjb2xvcj0jMDAwMGZmIHNpemU9MiBmYWNlPUFyaWFsPjwvRk9O VD48QlI+DQogIDxESVYgZGlyPWx0ciBsYW5nPWVuLXVzIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVh ZGVyIGFsaWduPWxlZnQ+DQogIDxIUiB0YWJJbmRleD0tMT4NCiAgPEZPTlQgc2l6ZT0yIGZhY2U9 VGFob21hPjxCPkZyb206PC9CPiBRaW4gV3UgW21haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tXSAN CiAgPEJSPjxCPlNlbnQ6PC9CPiBkaW5zZGFnIDE5IG9rdG9iZXIgMjAxMCA1OjA0PEJSPjxCPlRv OjwvQj4gVmFuIENhZW5lZ2VtLCBUb20gDQogIChUb20pOyBhdnRAaWV0Zi5vcmc8QlI+PEI+U3Vi amVjdDo8L0I+IFJlOiBbQVZUXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KICBkcmFm dC13dS1hdnQtcmV0cmFuc21pc3Npb24tc3VwcmVzc2lvbi1ydHAtMDQ8QlI+PC9GT05UPjxCUj48 L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj5IaSwgVG9tOjwvRElWPg0KICA8RElWPlRoYW5r IGZvciB5b3VyIGNvbW1lbnRzLCBwbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZS48L0RJVj4NCiAg PERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj5SZWdhcmRzITwvRElWPg0KICA8RElWPi1RaW48L0RJ Vj4NCiAgPEJMT0NLUVVPVEUgDQogIHN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29s aWQ7IFBBRERJTkctTEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1 cHg7IE1BUkdJTi1SSUdIVDogMHB4IiANCiAgZGlyPWx0cj4NCiAgICA8RElWIHN0eWxlPSJGT05U OiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+LS0tLS0gT3JpZ2luYWwgDQogICAgTWVzc2FnZSAtLS0tLSA8L0ZPTlQ+PC9ESVY+DQogICAg PERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IEJBQ0tHUk9VTkQ6ICNlNGU0 ZTQ7IGZvbnQtY29sb3I6IGJsYWNrIj48Rk9OVCANCiAgICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxGT05UIHNpemU9Mz48Qj5Gcm9tOjwvQj4gPC9GT05UPjwvRk9OVD48QSANCiAgICB0aXRsZT10 b20udmFuX2NhZW5lZ2VtQGFsY2F0ZWwtbHVjZW50LmNvbSANCiAgICBocmVmPSJtYWlsdG86dG9t LnZhbl9jYWVuZWdlbUBhbGNhdGVsLWx1Y2VudC5jb20iPjxGT05UIHNpemU9MyANCiAgICBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPlZhbiBDYWVuZWdlbSwgVG9tIChUb20pPC9GT05UPjwvQT48Rk9O VCBzaXplPTMgDQogICAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9GT05UPjwvRElWPg0KICAg IDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxGT05UIA0KICAgIHNpemU9Mz48Qj5Ubzo8L0I+IDwvRk9OVD48L0ZPTlQ+ PEEgdGl0bGU9YXZ0QGlldGYub3JnIA0KICAgIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPjxG T05UIHNpemU9MyANCiAgICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmF2dEBpZXRmLm9yZzwvRk9O VD48L0E+PEZPTlQgc2l6ZT0zIA0KICAgIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDsgPC9GT05U PjxBIHRpdGxlPXN1bnNlYXdxQGh1YXdlaS5jb20gDQogICAgaHJlZj0ibWFpbHRvOnN1bnNlYXdx QGh1YXdlaS5jb20iPjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlFpbiANCiAg ICBXdTwvRk9OVD48L0E+PEZPTlQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvRk9O VD48L0RJVj4NCiAgICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCANCiAgICBzaXplPTM+PEI+U2VudDo8L0I+ IFR1ZXNkYXksIE9jdG9iZXIgMTksIDIwMTAgMTI6MDggQU08L0ZPTlQ+PC9GT05UPjwvRElWPg0K ICAgIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxGT05UIA0KICAgIHNpemU9Mz48Qj5TdWJqZWN0OjwvQj4gUmU6IFtB VlRdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQogICAgZHJhZnQtd3UtYXZ0LXJldHJh bnNtaXNzaW9uLXN1cHJlc3Npb24tcnRwLTA0PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgICA8RElW PjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPjxCUj48L0RJVj4NCiAg ICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD5IaSBRaW4sPC9TUEFOPjwvRElW Pg0KICAgIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjwvU1BBTj4mbmJzcDs8 L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD5JIGhhdmUgc29t ZSBjb21tZW50cyAobG9vayBmb3IgVE9NIA0KICAgIGJlbG93KSBvbiB0aGUgbmV3IGRyYWZ0IHZl cnNpb24gNC48L1NQQU4+PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgx MDIwMTA+VGh4IGZvciBhZGRyZXNzaW5nIHRoZW0sPC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQ QU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPlRvbTwvU1BBTj48L0RJVj4NCiAgICA8RElWPiZu YnNwOzwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0y MzcwNTEwMTMtMTgxMDIwMTA+U2VjdGlvbiAyIFRlcm1pbm9sb2d5PC9TUEFOPjwvRElWPg0KICAg IDxESVY+PFBSRT48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiBMb3NzIERldGVjdG9yOg0K DQogICAgICBUaGUgTG9zcyBEZXRlY3RvciBpcyBvbmUgbG9naWNhbCBmdW5jdGlvbiB3aGljaCBp cyB1c2VkIHRvIGRldGVjdA0KICAgICAgdGhlIHBhY2tldCBsb3NzIGF0IHRoZSBSVFAgbGF5ZXIg YW5kIHJlcG9ydCBpdCB0byB0aGUgZGlzdHJpYnV0aW9uDQogICAgICBzb3VyY2UuICBUaGUgZnVu Y3Rpb24gb2YgdGhlIGxvc3MgcmVwb3J0ZXIgbWF5IGJlIGNvbGxvY2F0ZWQgd2l0aA0KICAgICAg b3IgaW50ZWdyYXRlZCBpbnRvIHRoZSBzYW1lIGVudGl0eS4gIEluIHRoaXMgY2FzZSwgZm9yIGEg c2Vzc2lvbg0KICAgICAgZGVmaW5lZCBhcyBoYXZpbmcgYSBkaXN0cmlidXRpb24gc291cmNlIEEs IG9uIHBvcnRzIG4gZm9yIHRoZSBSVFANCiAgICAgIGNoYW5uZWwgYW5kIGsgZm9yIHRoZSBSVENQ IGNoYW5uZWwsIHRoZSBMb3NzIERldGVjdG9yIGFyZQ0KICAgICAgaWRlbnRpZmllZCBieSBhbiBJ UCBhZGRyZXNzIG9mIGRpc3RyaWJ1dGlvbiBzb3VyY2UgQSBvbiBwb3J0IGsuDQogICAgICBUaGUg TG9zcyBEZXRlY3RvciBNQVkgYWxzbyBiZSBpbXBsZW1lbnRlZCBpbiBvbmUgb3IgbW9yZSBlbnRp dGllcw0KICAgICAgZGlmZmVyZW50IGZyb20gdGhlIGRpc3RyaWJ1dGlvbiBzb3VyY2UuDQo8L0ZP TlQ+PC9QUkU+PFBSRT48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4gVGhlIGZ1bmN0aW9uIG9mIHRoZSBsb3NzIHJlcG9ydGVyIG1heSBi ZSBjb2xsb2NhdGVkIHdpdGgNCiAgICAgIG9yIGludGVncmF0ZWQgaW50byB0aGUgc2FtZSBlbnRp dHkuPC9GT05UPjwvU1BBTj48L1BSRT48UFJFPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAx MD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRPTSAoMSk6IC4uc2FtZSBlbnRpdHkgYXMg d2hhdD8gaSBndWVzcyB5b3UgbWVhbiB0aGUgRFM/PC9GT05UPjwvU1BBTj48L1BSRT48UFJFPjxT UEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PltRaW5dOiBZb3VyIGFyZSByaWdodC4gIEluIHRoaXMgZHJhZnQsIHRoZSBsb3NzIGRldGVjdG9y IGlzIGp1c3QgZnVuY3Rpb25hbGl0eSBvZiBEUy4gIEZ1cnRoZXJtb3JlIHdlIG9ubHkgY29uc2lk ZXIgdGhlIGxvc3MgZGV0ZWN0b3IgYXMgcGFydCBvZiBmZWVkYmFjayB0YXJnZXQgd2l0aGluIHRo ZSBkaXN0cmlidXRpb24gc291cmNlLjwvRk9OVD48L1NQQU4+PC9QUkU+PFBSRT48U1BBTiBjbGFz cz0yMzcwNTEwMTMtMTgxMDIwMTA+PC9TUEFOPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAx MD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkFsc28gdGhpcyBpcyBqdXN0IG9uZSBleGFt cGxlIHVzZSBjYXNlIHRvIGV4cGxhaW4gaG93IGZlZWRiYWNrIHN1cHByZXNzaW9uIHdvcmtzIGlu IFNTTSB1c2UgY2FzZS48L0ZPTlQ+PC9TUEFOPjwvUFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUx MDEzLTE4MTAyMDEwPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VE9NICgyKTogSSBkbyBu b3QgdW5kZXJzdGFuZCBob3cgeW91IGFzc29jaWF0ZSB0aGUgcG9ydCBrIHRvIGEgbG9zcyBkZXRl Y3Rvci4uIHdoYXQgZG8geW91IG1lYW4gd2l0aCB0aGF0PzwvRk9OVD48L1NQQU4+PC9QUkU+PFBS RT48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj5bUWluXTogIFNvcnJ5IGZvciBhbWJpZ3VpdHkgb2YgdGhlIGRlc2NyaXB0aW9uIGhlcmUu IEl0IGFjdHVhbGx5IG1lYW5zIHRoYXQgdGhlIGxvc3MgcmVwb3J0ZXIgaXMgcGFydCBvZiBmZWVk YmFjayB0YXJnZXQgYW5kIHNoYXJlIHRoZSBzYW1lIGFkZHJlc3MgYW5kIHBvcnQuPC9GT05UPjwv U1BBTj48L1BSRT48UFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjxGT05U IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+c2VjdGlvbiAzPC9GT05UPjwvU1BBTj48L1BSRT48UFJF PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9GT05UPjwvUFJFPjxQUkU+PFNQ QU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ KC4uKTwvRk9OVD48L1NQQU4+PC9QUkU+PFBSRT48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PkluIG9yZGVyIHRvIGRldGVjdCBwYWNrZXQgbG9zcyBiZWZvcmUgdGhlIHJlY2VpdmVycyBwZXJj ZWl2ZSBpdCwgb25lDQogICBvciBtb3JlIGludGVybWVkaWF0ZSBub2RlcyBhcmUgcGxhY2VkIGJl dHdlZW4gdGhlIG1lZGlhIHNvdXJjZSBhbmQNCiAgIHJlY2VpdmVyIChlLmcuLCBEaXN0cmlidXRp b24gc2VydmVyLCBNQ1UsIFJUUCB0cmFuc2xhdG9yKS4gIFRoZXNlDQogICBpbnRlcm1lZGlhcmll cyBtb25pdG9yIGZvciBwYWNrZXQgbG9zcyB1cHN0cmVhbSBvZiB0aGVtc2VsdmVzIGJ5DQogICBj aGVja2luZyBSVFAgc2VxdWVuY2UgbnVtYmVycywganVzdCBhcyByZWNlaXZlcnMgZG8uICBVcG9u IGRldGVjdGluZw0KICAgKG9yIHN1c3BlY3RpbmcpIGFuIHVwc3RyZWFtIGxvc3MsIHRoZSBpbnRl cm1lZGlhcnkgbWF5IHNlbmQgRmVlZGJhY2sNCiAgIFN1cHByZXNzaW9uIG1lc3NhZ2UgdG93YXJk cyB0aGUgcmVjZWl2ZXJzIGFzIGRlZmluZWQgaW4gdGhpcw0KICAgc3BlY2lmaWNhdGlvbi4NCjwv Rk9OVD48L1BSRT48L1BSRT48L0RJVj4NCiAgICA8RElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4 dC9ydGYgZm9ybWF0IC0tPjxTUEFOPlRPTSAoMykgDQogICAgPC9TUEFOPjombmJzcDsuLi48U1BB TiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+YmFzZWQgb24gdGhlIHR3byBhYm92ZSANCiAgICBk ZWZpbml0aW9ucyAuLi48L1NQQU4+aXMmbmJzcDthbiZuYnNwO2ludGVybWVkaWF0ZSZuYnNwO25v ZGUmbmJzcDtoPFNQQU4gDQogICAgY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPmU8L1NQQU4+bmNl Jm5ic3A7ZXF1YWwmbmJzcDt0byZuYnNwO2EmbmJzcDsiTG9zcyZuYnNwO2RldGVjdG9yIj8mbmJz cDsgDQogICAgPC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+ PC9TUEFOPjxTUEFOIA0KICAgIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48L1NQQU4+KzxTUEFO IGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD4gSG93IGRvZXMgYSANCiAgICBMb3NzIGRldGVjdG9y IGRpZmZlciBmcm9tIGFuIFJUUCByZWNlaXZlcj88L1NQQU4+PC9ESVY+PFNQQU4gDQogICAgY2xh c3M9MjM3MDUxMDEzLTE4MTAyMDEwPjwvU1BBTj48L0JMT0NLUVVPVEU+DQogIDxCTE9DS1FVT1RF IA0KICBzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6 IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6 IDBweCIgDQogIGRpcj1sdHI+DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIw MTA+W1Fpbl06IFRoZSBsb3NzIGRldGVjdG9yIGlzIGp1c3Qgb25lIA0KICAgIGZ1bmN0aW9uYWxp dHkgb2YgRGlzdHJpYnV0aW9uIFNvdXJjZSBpbiB0aGUgU1NNIHVzZSBjYXNlLjwvU1BBTj48L0RJ Vj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD5NYXliZSB3ZSBzaG91 bGQmbmJzcDtpbnRlcnByZXQgaXQgYXMgDQogICAgIkxvc3MgZGV0ZWN0aW9uIGZ1bmN0aW9uYWxp dHkiLiBIb3cgdGhlIHBhY2tldCBsb3NzIGlzIGRldGVjdGVkIGlzIG91dCBvZiANCiAgICBzY29w ZSBvZiB0aGlzIGRvY3VtZW50LjwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIz NzA1MTAxMy0xODEwMjAxMD5EaWZmZXJlbnQgZnJvbSBkZWRpY2F0ZWQgUlRQIHJlY2VpdmVyLCAN CiAgICB0aGUgaW50ZXJtZWRpYXRlIG5vZGUgZG9lcyBub3QgZGVwZW5kIG9uIGV4aXN0aW5nIE5B Q0sgbWVzc2FnZSBmb3IgDQogICAgUmV0cmFuc21pc3Npb24gcmVxdWVzdCBmb3IgcGFja2V0IGxv c3MuPC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEw PnRoZSBpbnRlcm1lZGlhdGUgbm9kZSBjYW4gY3JlYXRlIG1lc3NhZ2UgDQogICAgYnkgaXRzZWxm LjwvU1BBTj48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xh c3M9MjM3MDUxMDEzLTE4MTAyMDEwPlNlY3Rpb24gNi4xPC9TUEFOPjwvRElWPjxQUkU+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JbiBvcmRlciB0byBhdm9pZCB0aGUgZm9ybXMgb2YgTkFD SyBpbXBsb3Npb24gZGVzY3JpYmVkIGluIHNlY3Rpb24gMSwNCiAgIHRoZSBMb3NzIERldGVjdG9y IGlzIGludHJvZHVjZWQuICBUaGUgTG9zcyBEZXRlY3RvciBkZXRlY3RzIGFuZA0KICAgcmVwb3J0 cyBwYWNrZXQgbG9zcywgb24gYm90aCB0aGUgdXBzdHJlYW0gbGluayBhbmQgdGhlIGRvd25zdHJl YW0NCiAgIGFnZ3JlZ2F0ZSBsaW5rLiAgSG93IHRoZSBsb3NzIGRldGVjdG9yIFNIT1VMRCBkZXRl Y3QgdGhlIHBhY2tldCBsb3NzDQogICBpcyBiZXlvbmQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVu dC4gIFdoZW4gdXBzdHJlYW0gbGluayBvcg0KICAgZG93bnN0cmVhbSBhZ2dyZWdhdGUgbGluayBw YWNrZXQgbG9zcyBvY2N1cnMsIHRoZSBMb3NzIERldGVjdG9yIE1BWQ0KICAgaW5mb3JtIGRpc3Ry aWJ1dGlvbiBzb3VyY2Ugb2YgdGhlIGRldGVjdGVkIHBhY2tldCBsb3NzIHVzaW5nIEZlZWRiYWNr DQogICBTdXBwcmVzc2lvbiBtZXNzYWdlcy4gIEluIHJlc3BvbnNlLCB0aGUgZGlzdHJpYnV0aW9u IHNvdXJjZSBlaXRoZXINCiAgIGZvcndhcmRzIHBhY2tldCBsb3NzIHN1cHByZXNzaW9uIHJlcG9y dCByZWNlaXZlZCBmcm9tIExvc3MgRGV0ZWN0b3INCiAgIG9yIGNyZWF0ZXMgYSBGZWVkYmFjayBT dXBwcmVzc2lvbiByZXBvcnQgYW5kIHNlbmRzIGl0IHRvIGFsbCB0aGUgUlRQDQogICByZWNlaXZl cnMsIG92ZXIgdGhlIG11bHRpY2FzdCBjaGFubmVsLiAgVGhpcyBsb3NzIHN1cHByZXNzaW9uIHJl cG9ydA0KICAgdGVsbHMgdGhlIHJlY2VpdmVycyB0aGF0IHRoZSBsb3N0IHBhY2tldCB3aWxsIGVp dGhlciBiZSBmb3J0aGNvbWluZw0KICAgZnJvbSBkaXN0cmlidXRpb24gc291cmNlLCBvciBpdCBp cnJldHJpZXZhYmx5IGxvc3Qgc3VjaCB0aGF0IHRoZXJlIGlzDQogICBub3RoaW5nIHRvIGJlIGdh aW5lZCBieSB0aGUgcmVjZWl2ZXIgc2VuZGluZyBhIE5BQ0sgdG8gdGhlIG1lZGlhDQogICBzb3Vy Y2UuICBUaGUgZGlzdHJpYnV0aW9uIHNvdXJjZSB0aGVuIGNhbiAob3B0aW9uYWxseSkgYXNrIGZv ciB0aGUNCiAgIGxvc3QgcGFja2V0cyBmcm9tIHRoZSBtZWRpYSBzb3VyY2Ugb24gYmVoYWxmIG9m IGFsbCB0aGUgUlRQDQogICByZWNlaXZlcnMuPC9GT05UPjwvUFJFPjxQUkU+PFNQQU4gY2xhc3M9 MjM3MDUxMDEzLTE4MTAyMDEwPjwvU1BBTj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlQ8 U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+T00gKDQpIDogWW91IHByb2JhYmx5IGRvIG5v dCB3YW50IHRvIGhhdmUgbm9ybWF0aXZlIGxhbmd1YWdlIGluIHNlY3Rpb24gNi4xLCBsaWtlICJI b3cgdGhlIGxvc3MgZGV0ZWN0b3IgU0hPVUxEICguLikiLiA8L1NQQU4+PC9GT05UPjwvUFJFPjxQ UkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+W1Fpbl06U29ycnksIEkgY2FuJ3QgZ2V0IGl0LjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAw MGZmIHNpemU9MiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNzPTI4OTM0MDIwNy0xOTEwMjAxMD4mbmJz cDs8L1NQQU4+PC9GT05UPjwvU1BBTj48L1BSRT48UFJFPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0x ODEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNz PTI4OTM0MDIwNy0xOTEwMjAxMD5UT006IHRoaXMgaXMgcmVhbGx5IGEgZGV0YWlsLiBJZiB5b3Ug d2FudCB0byBrZWVwIHRoZSBzZW50ZW5jZSwgeW91IHNob3VsZCBlLmcuIHNheTogIkhvdyB0aGUg bG9zcyBkZXRlY3RvciBjYW4gZGV0ZWN0IHRoZSBwYWNrZXQgbG9zcy4uLjwvU1BBTj48L0ZPTlQ+ PC9TUEFOPjwvUFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjxGT05UIGNv bG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9QXJpYWw+PFNQQU4gY2xhc3M9Mjg5MzQwMjA3LTE5MTAy MDEwPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPiZuYnNwO1tRaW5dT2theS48L1BSRT48UFJFPjxTUEFO IGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiBmYWNl PUFyaWFsPjxTUEFOIGNsYXNzPTI4OTM0MDIwNy0xOTEwMjAxMD48L1NQQU4+PC9GT05UPjwvU1BB Tj48L1BSRT48UFJFPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48L1NQQU4+PFNQQU4g Y2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjwvU1BBTj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPlQ8U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+T00gKDUpIDogSXQgaXMgcHJldHR5 IGNsZWFyIGhvdyBhIExvc3MgZGV0ZWN0b3Igd2lsbCBkZXRlY3QgcGFja2V0IGxvc3Mgb24gaXRz IHVwc3RyZWFtIGxpbmssIEkgZ3Vlc3MuPC9TUEFOPjwvRk9OVD48L1BSRT48UFJFPjxTUEFOIGNs YXNzPTIzNzA1MTAxMy0xODEwMjAxMD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltRaW5d OiBBcyBJIHNhaWQgYWJvdmUsICBMb3NzIGRldGVjdG9yIGlzIGp1c3QgZnVuY3Rpb25hbGl0eSBv ZiBzb21lIERpc3RyaWJ1dGlvbiBzb3VyY2VzLiAgQWxzbyB3aGF0IGl0IHNhaWQgaGVyZSBpbiBz ZWN0aW9uIDYuMSA8L0ZPTlQ+PC9TUEFOPjwvUFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEz LTE4MTAyMDEwPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+aXMganVzdCBvbmUgZXhhbXBs ZSB1c2UgY2FzZS48L0ZPTlQ+PC9TUEFOPjwvUFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEz LTE4MTAyMDEwPjwvU1BBTj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj5UT00gKDYpOiAgV2hhdCBpcyB0aGUgcmF0aW9uYWxlIGZvciBh IGxvc3MgZGV0ZWN0b3IgdG8gc2VuZCBhIEZlZWRiYWNrIHN1cHByZXNzaW9uIG1lc3NhZ2UgdG8g dGhlIERTLi4gd2h5IE5PVCBhIFJUQ1AgTkFDSyBGQj88L0ZPTlQ+PC9TUEFOPjwvUFJFPjxQUkU+ PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+W1Fpbl06IEFzIEkgZXhwbGFpbmVkIGluIHRoZSBsYXN0IElFVEYgcHJlc2VudGFpb24sICB0 aGlzIGNhdXNlIE5BQ0sgc2NlbWF0aWNzIG1pc21hdGNoLiBUaGF0J3Mgd2h5IG1hbnkgcGVvcGxl IGluIHRoZSBsYXN0IElFVEYgbWVlZXRpbmcgc3VnZ2VzdCB0byBjcmVhdGUgbmV3IFJUQ1AgbWVz c2FnZSBkdXJpbmcgcHJlc2VudGF0aW9uLjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9 MiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNzPTI4OTM0MDIwNy0xOTEwMjAxMD4mbmJzcDs8L1NQQU4+ PC9GT05UPjwvU1BBTj48L1BSRT48UFJFPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48 Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNzPTI4OTM0MDIw Ny0xOTEwMjAxMD5UT006IEFzIHlvdXIgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZSBsb3NzIHJlcG9y dGVyIGlzIHBhcnQgb2YgdGhlIEZUIHRoYXQgaXMgcGFydCBvZiB0aGUgRFMsIHRoZW4gdGhlcmUg aXMgZXZlbiBubyBuZWVkIHRvIHNwZWNpZnkgaG93IHRoZSBsb3NzIGRldGVjdG9yIDwvU1BBTj48 L0ZPTlQ+PC9TUEFOPjwvUFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjxG T05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9QXJpYWw+PFNQQU4gY2xhc3M9Mjg5MzQwMjA3 LTE5MTAyMDEwPnJlcG9ydHMgdGhlIHBhY2tldCBsb3NzLiAgSW4gdGhlIG1vcmUgZ2VuZXJpYyBj YXNlLCBpdCBtYWtlcyBtb3JlIHNlbnNlIHRvIG1lIHRoYXQgdGhlIGxvc3MgcmVwb3J0ZXIganVz dCB1c2VzIGEgTkFDSyAob3IgYSBGSVIpIGlmIGl0IGRldGVjdHMgcGFja2V0IGxvc3MsIHNlbnQg dG93YXJkcyBpdHMgRlQgb3IgdG8gdGhlIERTIGlmIHRoaXMgb25lIGhvc3RzIHRoZSBGVCB0aGF0 IHRoZSBsb3NzIGRldGVjdG9yIHJlcG9ydHMgdG8gLiBJdCBpcyB0aGVuIHVwIHRvIHRoZSBGVCBv ciB0aGUgRFMgdG8gZGVjaWRlIHdoZXRoZXIgdGhpcyBtZXNzYWdlIHRyaWdnZXJzIGEgTkFDSyBv ciBGSVIgc3VwcHJlc3Npb24gPC9TUEFOPjwvRk9OVD48L1NQQU4+PC9QUkU+PFBSRT48U1BBTiBj bGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTIgZmFjZT1B cmlhbD48U1BBTiBjbGFzcz0yODkzNDAyMDctMTkxMDIwMTA+aW5kaWNhdGlvbiB0byAocyBzdWJz ZXQgb2YpIHRoZSByZWNlaXZlcnMuICBUaGlzIHN1cHByZXNzaW9uIGluZGljYXRpb24gZG9lcyBu b3QgbmVjZXNzYXJseSByZXF1aXJlIGEgbmV3IG1lc3NhZ2UgZm9ybWF0LiBBIE5BQ0svRklSICB0 aGF0IGlzIHNlbnQgdG8gYSBSVFAgcmVjZWl2ZXIgY2FuIGJlIGRlZmluZWQgYXMgYSBmZWVkYmFj ayBzdXBwcmVzc2lvbiBpbmRpY2F0aW9uLiBJIGRvIG5vdCBzZWUgYSBnb29kIHVzZSBjYXNlIHdo eSBOQUNLcyBmcm9tICByZWNlaXZlcnMgIHdvdWxkIGJlIHJlZmxlY3RlZCBiYWNrIGluIGUuZy4g U1NNIHVzZSBjYXNlIGJ5IERTIG9yIEZUICB0byBhbGwgdGhlIGNvbm5lY3RlZCByZWNlaXZlcnMu IDwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvUFJFPjxQUkU+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4 MTAyMDEwPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9QXJpYWw+PFNQQU4gY2xhc3M9 Mjg5MzQwMjA3LTE5MTAyMDEwPklmIHdlIGRlZmluZSB0aGF0IGEgTkFDSy9GSVIgIGZvciBhIFNT TSBtYXkgb25seSBiZSBzZW50IFRPV0FSRFMgYSBSVFAgcmVjZWl2ZXIsIGlmIHRoaXMgaXMgZm9y IHN1cHByZXNzaW9uIGluZGljYXRpb24sIHRoZXJlIGlzIG5vIGFtYmlndWl0eSBwb3NzaWJseS4g ICA8L1NQQU4+PC9GT05UPjwvU1BBTj48L1BSRT48UFJFPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0x ODEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiBmYWNlPUFyaWFsPjxTUEFOIGNsYXNz PTI4OTM0MDIwNy0xOTEwMjAxMD48L1NQQU4+PC9GT05UPjwvU1BBTj4mbmJzcDtbUWluXTogVG8g bWUsIE5BQ0sgaXMgdWVzZWQgdG8gcmVxdWVzdCBwYWNrZXQgbG9zcyByZXRyYW5zbWlzc2lvbiBm cm9tIHRoZSBzZXJ2ZXIsIE5BQ0sgaGFzIG5vIHNjZW1hbnRpY3MgZm9yIGZlZWRiYWNrIHN1cHBy ZXNzaW9uLiB0aGUgaW50ZXJtZWRpYXRlIG5vZGUgZS5nLiwgZGlzdHJpYnV0aW9uPC9QUkU+PFBS RT5zb3VyY2Ugd2lsbCBjb25mdXMgd2hldGhlciB0aGUgTkFDSyBzaG91bGQgYmUgZm9yd2FyZGVk IHRvIHRoZSBzZXJ2ZXIgb3IgdGhlIHJlY2VpdmVyLjwvUFJFPjxQUkU+dW5saWtlIE5BQ0ssIEZl ZWRiYWNrIFN1cHByZXNzaW9uIG1lc3NhZ2UgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0IGlzIHVzZWQg YnkgdGhlIGludGVybWVkaWF0ZSBub2RlL21pZGRsZWJveCB0byBub3RpZnkgYWxsIHRoZSByZWNl aXZlciB0aGF0IHNlbmRpbmcgTkFDSyBtYXkgYmUgbm90IG5lY2Vzc2FyeSBhbmQgaGFybWZ1bC48 L1BSRT48UFJFPnRoZSBpbnRlcm1lZGlhdGUgbm9kZSB3aWxsIGtub3cgaG93IHRvIGRlYWwgd2l0 aCB0aGUgRmVlZGJhY2sgU3VwcHJlc3Npb24gbWVzc2FnZSBhbmQgd2lsbCBub3QgY2F1c2Ugc2Nl bWFudGljcyBjb25mdXNpb24gbGlrZSByZWNlaXZpbmcgTkFDSy48L1BSRT48UFJFPk9uZSBpbXBv cnRhbnQgdGhpbmcgaXMgRmVlZGJhY2sgc3VwcHJlc3Npb24gY2FuIGJlIHVzZWQgd2l0aG91dCBy ZWNlaXZpbmcgQU5ZIE5BQ0tzLiA8L1BSRT48UFJFPnRoYXQgaXMgd2h5IG1hbnkgcGVvcGxlIHRo aW5rIHdlIHNob3VsZCBkZWZpbmUgbmV3IG1lc3NhZ2UgYWx0aHVnaCB0aGUgbmV3IG1lc3NhZ2Ug aGFzIHRoZSBzaW1pbGFyIGZvcm1hdCBhcyBOQUNLLjwvUFJFPjxQUkU+VGhlcmVmb3JlIEkgdGhp bmsgdXNpbmcgTkFDSyBzZW50IGZyb20gc29tZSBkZWRpY2F0ZWQgcmVjZWl2ZXIgaXMganVzdCBv bmUgd2F5IGZvciB0aGUgZGlzdHJpYnV0aW9uIHNvdXJjZSB0byBrbm93IHBhY2tldCBsb3NzIGhh cHBlbi4gQnV0IG5vdCB0aGUgb25seSB3YXkuPC9QUkU+PFBSRT48U1BBTiBjbGFzcz0yMzcwNTEw MTMtMTgxMDIwMTA+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5TZWN0aW9uIDYuMS4xPC9G T05UPjwvU1BBTj48L1BSRT48UFJFPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SWYgdGhl cmUgYXJlIG11bHRpcGxlIExvc3MgRGV0ZWN0b3JzIGxvb2tpbmcgYXQgdGhlIHNhbWUgUlRQIHN0 cmVhbSwNCiAgIHRoZW4gdGhlIGxvc3MgbWF5IGJlIGlkZW50aWZpZWQgYnkgbW9yZSB0aGFuIG9u ZSBhbmQgdGhvc2UgZGV0ZWN0aW5nDQogICB0aGUgbG9zcyB3aWxsIGFsbCBzZW5kIHJlcXVlc3Rz IGZvciB0aGUgc2FtZSBwYWNrZXQgbG9zcy4gIEluIHRoaXMNCiAgIGNhc2UsIHRoZSBkaXN0cmli dXRpb24gc291cmNlIE1VU1QgZmlsdGVyIHRoZSBkdXBsaWNhdGVkIHBhY2tldCBsb3NzDQogICBy ZXF1ZXN0IG91dCBhbmQgb25seSBmb3J3YXJkIG9uZSBjb3B5IG9mIHRoZSBSVENQIEZlZWRiYWNr IHJlcG9ydA0KICAgcGFja2V0IGZyb20gdGhlIGZpcnN0IExvc3MgRGV0ZWN0b3IgdG8gdGhlIGdy b3VwIGltcGFjdGVkIGJ5IHBhY2tldA0KICAgbG9zcy4NCjwvRk9OVD48L1BSRT4NCiAgICA8RElW PjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD5UT00gKDcpIDogaG93IHdpbGwgdGhlIERT IHNlbmQgb25seSBhIA0KICAgIGNvcHkgb2YgdGhlIFJUQ1AgRkIgcmVwb3J0IHBhY2tldCB0byB0 aGUgZ3JvdXAgaW1wYWN0ZWQgYnkgcGFja2V0IGxvc3MuIElzIA0KICAgIHRoaXMgZG9uZSBvdmVy IHRoZSBTU00/IDwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0x ODEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiANCiAgICBmYWNlPUFyaWFsPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgx MDIwMTA+W1Fpbl06IFNvcnJ5LCBtYXliZSBJIHNvdWxkIHNheSANCiAgICA8L1NQQU4+PC9ESVY+ DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+IjwvU1BBTj48L0RJVj4N CiAgICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD5TZWN0aW9uIDYuMS4xPC9T UEFOPjwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPklmIHRo ZXJlIGFyZSBtdWx0aXBsZSBEaXN0cmJpdHV0aW9uIA0KICAgIFNvdXJjZSB3aXRoIHRoZSBsb3Nz IGRldGVjdGlvbiBzdXBwb3J0IGxvb2tpbmcgYXQgdGhlIHNhbWUgUlRQIA0KICAgIHN0cmVhbS4u Li4uPC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEw PiI8L1NQQU4+PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+ WWVzLCZuYnNwOyBpbiB0aGUgU1NNIHVzZSBjYXNlLCBEUyBzZW5kIA0KICAgIG9ubHkgYSBjb3B5 IG9mIHRoZSBSVENQIEZlZWRiYWNrIFN1cHByZXNzaW9uIFJlcG9ydCBwYWNrZXQgdGhlIGdyb3Vw IHZpYSANCiAgICBTU00uPC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUx MDEzLTE4MTAyMDEwPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIA0KICAgIGZhY2U9QXJpYWw+ PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAx My0xODEwMjAxMD5JbiB5b3VyIGV4YW1wbGUgeW91IHNlZW0gdG8gZm9jdXMgb25seSANCiAgICBv biBhcmNoaXRlY3R1cmVzIHdpdGggYSBEUyB3aGljaCBhbHNvIGhvc3RzIHRoZSBGVCBhbmQgdGhl IGxvc3MgDQogICAgcmVwb3J0ZXIuJm5ic3A7IFRoZXJlIHNob3VsZCBiZSBzZWN0aW9ucyBjb3Zl cmluZyBjYXNlcyB3aGVyZSB0aGUgRFMgaXMgDQogICAgZGlzam9pbnQgZnJvbSB0aGUgRlQsIHdp dGggc2V2ZXJhbCBGVHMgYW5kIGFsc28gc2V2ZXJhbCBsb3NzIHJlcG9ydGVycyANCiAgICBkaXNq b2ludCBmcm9tIHRoZSBGVCBhbmQgdGhlIERTLjwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxTUEFO IGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiANCiAg ICBmYWNlPUFyaWFsPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BBTiBj bGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+W1Fpbl0gSSBhbSBub3Qgc3VyZSB3ZSBuZWVkIHRvIGFk ZHJlc3MgDQogICAgYWxsIHRoZSBwb3NzaWJsZSBTU00gdXNlIGNhc2VzLiBJbiB0aGlzIGRyYWZ0 LCB3ZSBqdXN0IGdpdmUmbmJzcDtzb21lIA0KICAgIGV4YW1wbGVzIG9mIFNTTSB1c2UgY2FzZS48 L1NQQU4+PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PEZP TlQgY29sb3I9IzAwMDBmZiBzaXplPTIgDQogICAgZmFjZT1BcmlhbD48L0ZPTlQ+PC9TUEFOPiZu YnNwOzwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPlRPTSAo OCkgOiB3aGF0IGRvIHlvdSBtZWFuIGluIGFib3ZlIHRleHQgDQogICAgd2l0aCAiUlRDUCBGQiBy ZXBvcnQiLi4gaXMgdGhhdCB0aGUgc3VwcHJlc3Npb24gbWVzc2FnZSB5b3UgZGVmaW5lIGluIHRo aXMgDQogICAgZHJhZnQ/PC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUx MDEzLTE4MTAyMDEwPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIA0KICAgIGZhY2U9QXJpYWw+ PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAx My0xODEwMjAxMD5bUWluXTogWWVzLCZuYnNwOyBSVENQIEZlZWRiYWNrIA0KICAgIFN1cHByZXNz aW9uIFJlcG9ydC4gPC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEz LTE4MTAyMDEwPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIA0KICAgIGZhY2U9QXJpYWw+PC9G T05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0x ODEwMjAxMD5UT00gKDkpIDogSW4gc2VjdGlvbiZuYnNwOyAiNi4xLjIuJm5ic3A7IA0KICAgIERp c3RyaWJ1dGlvbiBTb3VyY2UgRmVlZGJhY2sgU3VtbWFyeSBNb2RlbCIgaXQgaXMgbm90IGNsZWFy IHdoYXQgeW91ciANCiAgICBhcmNoaXRlY3R1cmUgbG9va3MgbGlrZS4gWW91IHRhbGsgYWJvdXQg bXVsdGlwbGUgZGlzdHJpYnV0aW9uIHNvdXJjZXMuLiANCiAgICB3aGNpaCBpbXBsaWVzIG11bHRp cGxlIFNTTXMuLiBDYW4geW91IGVsYWJvcmF0ZSBvbiB0aGF0PzwvU1BBTj48L0RJVj4NCiAgICA8 RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIHNp emU9MiANCiAgICBmYWNlPUFyaWFsPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJ Vj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+W1Fpbl06Jm5ic3A7IFRoZSBzY2VuYXJp byB3ZSBhcmUgdGFsa2luZyANCiAgICBhYm91dCBpbiZuYnNwOyB0aGUgc2VjdGlvbiA2LjEuMiwg aXMmbmJzcDt0byAmbmJzcDthbGxvdyBtdWx0aXBsZSANCiAgICBEaXN0cmJpdHVpb24gc291cmNl IGJldHdlZW4gbWVkaWEgc291cmNlIGFuZCB0aGUgcmVjZWl2ZXIuIEkgd2lsbCBsb29rIGF0IA0K ICAgIHRoZSB0aGlzIGNhc2UgYXMgb25lIHNwZWNpYWwgU1NNIGNhc2UuIGJlY2F1c2UmbmJzcDsg ZWFjaCBvZiBkaXN0cmJpdHVpb24gDQogICAgc291cmNlIDwvU1BBTj48U1BBTiBjbGFzcz0yMzcw NTEwMTMtMTgxMDIwMTA+cmVzaWRlcyBhdCB0aGUgdXBzdHJlYW0gDQogICAgZGlyZWN0aW9uIG9y IGRvd25zdHJlYW0gZGlyZWN0aW9uIG9mIG90aGVyIGRpc3RyaWJ1dGlvbnMgc291Y2VzLiBEb2Vz IGl0IA0KICAgIG1ha2Ugc2Vuc2U/PFNQQU4gY2xhc3M9Mjg5MzQwMjA3LTE5MTAyMDEwPjxGT05U IGNvbG9yPSMwMDAwZmYgc2l6ZT0yIA0KICAgIGZhY2U9QXJpYWw+Jm5ic3A7PC9GT05UPjwvU1BB Tj48L1NQQU4+PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+ PFNQQU4gY2xhc3M9Mjg5MzQwMjA3LTE5MTAyMDEwPjxGT05UIA0KICAgIGNvbG9yPSMwMDAwZmYg c2l6ZT0yIGZhY2U9QXJpYWw+PC9GT05UPjwvU1BBTj48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAg PERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PFNQQU4gY2xhc3M9Mjg5MzQwMjA3 LTE5MTAyMDEwPjxGT05UIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9QXJpYWw+VE9N OiBSRkMgNTc2MCBvbmx5IGRlZmluZXMgb25lIERTIGZvciBhIA0KICAgIGdpdmVuIFNTTS4gSWYg eW91IGRlcGFydCBmcm9tIHRoYXQsIHlvdSBwcm9iYWJseSBuZWVkIHRvIGFkZHJlc3MgYW5kIA0K ICAgIGRlZmluZSZuYnNwO3RoaXMgYXJjaGl0ZWN0dXJlIGluIGEgYmV0dGVyIHdheSBpbiB5b3Vy IA0KICAgIGRyYWZ0LjwvRk9OVD4mbmJzcDs8L1NQQU4+PC9TUEFOPjwvRElWPg0KICAgIDxESVY+ PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjxTUEFOIGNsYXNzPTI4OTM0MDIwNy0xOTEw MjAxMD48Rk9OVCANCiAgICBzaXplPTIgZmFjZT1BcmlhbD48L0ZPTlQ+PC9TUEFOPjwvU1BBTj4m bmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48U1BB TiBjbGFzcz0yODkzNDAyMDctMTkxMDIwMTA+PEZPTlQgDQogICAgc2l6ZT0yIGZhY2U9QXJpYWw+ W1Fpbl06IE9rYXkuPC9GT05UPjwvU1BBTj48L1NQQU4+PC9ESVY+DQogICAgPERJVj48U1BBTiBj bGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTIgDQogICAg ZmFjZT1BcmlhbD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xh c3M9MjM3MDUxMDEzLTE4MTAyMDEwPlRvbSAoMTApIDombmJzcDsgSW4gc2VjdGlvbiZuYnNwOyAN CiAgICA2LjMuJm5ic3A7IE11bHRpcG9pbnQgQ29udHJvbCBVbml0IChNQ1UpIHVzZSBjYXNlLCZu YnNwOyB0eXBpY2FsbHkgYW4gDQogICAgb3ZlcmxheSBvZiB1bmljYXN0IGlzIHVzZWQuLi4gd2ls bCB0aGUgRmVlZGJhY2sgc3VwcHJlc3Npb24gbWVzc2FnZSBiZSBzZW50IA0KICAgIG92ZXIgdW5p Y2FzdCBhcyB3ZWxsPyBJZiBzbywgd2hhdCBpcyBnYWluIGNvbXBhcmVkIHRvIGp1c3QgaGF2aW5n IGVhY2ggUlRDUCANCiAgICByZWNlaXZlciBwcm92aWRpbmcgZWFjaCB0aGVpciBOQUNLIHRvIHRo ZSBNQ1UsIGV2ZW4gaW4gY2FzZSBvZiBhIHBhY2tldCBsb3NzIA0KICAgIGltcGFjdGluZyBhbGwg cmVjZWl2ZXJzPzwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0x ODEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiANCiAgICBmYWNlPUFyaWFsPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgx MDIwMTA+W1Fpbl06IEZpcnN0IFRoZSBNQ1UgY2FzZSB3aWxsIG5vdCBjYXVzZSANCiAgICBOQUNL IEltcGxvc2lvbiwgaW5zdGVhZCwgaXQgbWF5IGNhdXNlIEZJUiBpbXBsb3Npb24uPC9TUEFOPjwv RElWPg0KICAgIDxESVY+PFNQQU4gDQogICAgY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgICBTZWNvbmQsIHVzaW5nIEZlZWRiYWNrIHN1cHByZXNzaW9uIG1lc3NhZ2UgY2FuIHJlc3Ry aWN0IHRoZSBGSVIgbWVzc2FnZSBzZW50IA0KICAgIGZyb20gcmVjZWl2ZXJzJm5ic3A7YmVoaW5k IE1DVSBhbmQgbGliZXJhdGUgdGhlIG1lZGlhIHNvdXJjZSBmcm9tJm5ic3A7IEZJUiANCiAgICBp bXBsb3Npb24uPFNQQU4gY2xhc3M9Mjg5MzQwMjA3LTE5MTAyMDEwPjxGT05UIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yIA0KICAgIGZhY2U9QXJpYWw+Jm5ic3A7PC9GT05UPjwvU1BBTj48L1NQQU4+PC9E SVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PFNQQU4gY2xhc3M9 Mjg5MzQwMjA3LTE5MTAyMDEwPjxGT05UIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9 QXJpYWw+PC9GT05UPjwvU1BBTj48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BBTiBj bGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PFNQQU4gY2xhc3M9Mjg5MzQwMjA3LTE5MTAyMDEwPjxG T05UIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9QXJpYWw+VE9NOiBpdCBpcyBub3Qg aW1wb3J0YW50IHdoZXRoZXIgdGhpcyBpcyANCiAgICBhYm91dCBGSVIgb3IgTkFDSy4gTXkgcG9p bnQgaXMgdGhhdCBpc28gaGF2aW5nIGVhY2ggcmVjZWl2ZXIgc2VuZGluZyBhIA0KICAgIE5BQ0sv RklSLCB5b3Ugd2lsbCBub3cgaGF2ZSB0byBzZW5kIHRvIGVhY2ggcmVjZWl2ZXIgYSBOQUNLL0ZJ UiZuYnNwOyANCiAgICBzdXBwcmVzc2lvbiBpbiB0aGUgZ2l2ZW4gc2NlbmFyaW8uIFRoZXJlIGFy ZSBubyBkaWZmZXJlbmNlcyBpbiB0ZXJtcyBvZiANCiAgICBCYW5kd2RpdGggb3ZlcmhlYWQgb3Ig c2VydmVyIGxvYWQgaW4gdGhlIHR3byBjYXNlcywgc28gd2h5IGJvdGhlciB0byBzZW5kIA0KICAg IHN1cHByZXNzaW9uIG1lc3NhZ2VzPzwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRElWPg0KICAgIDxE SVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjxGT05UIA0KICAgIGNvbG9yPSMwMDAw ZmY+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1 MTAxMy0xODEwMjAxMD5bUWluXTogTm8sIG9uZSBlZmZlY3RpdmUgdXNlIGNhc2UgaXMgDQogICAg c3VwcG9zZSBwYWNrZXQgbG9zcyBjYW4gbm90IHJlcGFpcmVkLCB0aGUgTUNVIGNhbiB1c2UgZmVl ZGJhY2sgc3VwcHJlc3Npb24gDQogICAgbWVzc2FnZSB0byB0ZWxsIHRoZSByZWNlaXZlciBub3Qg YXNrIGZvciBsb3N0IHBhY2tldC48L1NQQU4+PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0y MzcwNTEwMTMtMTgxMDIwMTA+PEZPTlQgc2l6ZT0yIA0KICAgIGZhY2U9JiMyMzQzNTsmIzIwMzA3 Oz48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUx MDEzLTE4MTAyMDEwPlRvbSAoMTEpIDogY29taW5nIGJhY2sgdG8gbXkgcHJldmlvdXMgDQogICAg Y29tbWVudCBvbiBTRFAgZGVzY3JpcHRpb24gaW4gdGhpcyBkcmFmdCZuYnNwOzombmJzcDtpZiB0 aGlzIGRyYWZ0IGRlZmluZXMgYSANCiAgICBSVENQIGZlZWRiYWNrIHN1cHByZXNzaW9uIG1lc3Nh Z2UsIHdoeSBpcyB0aGVyZSBuZWVkIGZvciBhICJhbm5vdW5jZW1lbnQiIGluIA0KICAgIHRoZSBT RFAgZm9yIHRoZSByZWNlaXZlcnMsIHRoYXQgaW5kaWNhdGVzIHRoZXkgbWF5IHJlY2VpdmUgc3Vj aCBmZWVkYmFjayANCiAgICBzdXBwcmVzc2lvbiBtZXNzYWdlcz8mbmJzcDsgSWYgYSByZWNlaXZl ciBzdXBwb3J0cyB0aGUgbWVzc2FnZSwgaXQgDQogICAgd2lsbCZuYnNwOyBzaW1wbHkmbmJzcDth Y3QgYWNjb3JkaW5nbHkgYXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCwgbm8gbmVlZCB0byANCiAg ICBhbm5vdW5jZSB0aGF0IS4uIDwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIz NzA1MTAxMy0xODEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiANCiAgICBmYWNlPUFy aWFsPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcw NTEwMTMtMTgxMDIwMTA+W1Fpbl06IE9rYXksIEkgZ2V0IHlvdXIgcG9pbnQuIEkgd291bGQgDQog ICAgbGlrZSB0byBwdXQgdGhpcyBhcyBvcGVuIGlzc3VlLCBkaXNjdXNzIGl0IGluIHRoZSBmYWNl IHRvIGZhY2UgSUVURiANCiAgICBtZWV0aW5nLjwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxTUEFO IGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiANCiAg ICBmYWNlPUFyaWFsPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BBTiBj bGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+UmVnYXJkczwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxT UEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAxMD5Ub208L0RJVj4NCiAgICA8RElWPjxCUj48L0RJ Vj48L1NQQU4+DQogICAgPERJVj48U1BBTiBjbGFzcz0yMzcwNTEwMTMtMTgxMDIwMTA+PC9TUEFO PiZuYnNwOzwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9MjM3MDUxMDEzLTE4MTAyMDEwPjwv U1BBTj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTIzNzA1MTAxMy0xODEwMjAx MD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BBTiANCmNsYXNzPTIzNzA1MTAxMy0x ODEwMjAxMD48L1NQQU4+Jm5ic3A7PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JP RFk+PC9IVE1MPg0K --Boundary_(ID_64NZ7WKETdvs69DBTt28xQ)-- From magnus.westerlund@ericsson.com Tue Oct 19 05:34:48 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7B13A67E6 for ; Tue, 19 Oct 2010 05:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmQkatiIYIin for ; Tue, 19 Oct 2010 05:34:47 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7E21C3A67B2 for ; Tue, 19 Oct 2010 05:34:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7b28ae00000135b-07-4cbd90c010e2 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 68.2A.04955.0C09DBC4; Tue, 19 Oct 2010 14:36:16 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Oct 2010 14:36:15 +0200 Received: from [147.214.183.82] ([147.214.183.82]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Oct 2010 14:36:15 +0200 Message-ID: <4CBD90BF.80803@ericsson.com> Date: Tue, 19 Oct 2010 14:36:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Bob Briscoe References: <201008052251.o75Mp7BH005112@bagheera.jungle.bt.co.uk> In-Reply-To: <201008052251.o75Mp7BH005112@bagheera.jungle.bt.co.uk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Oct 2010 12:36:15.0823 (UTC) FILETIME=[38BC5DF0:01CB6F8A] X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ecn-for-rtp@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 T1/ Combining pkts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 12:34:49 -0000 Bob Briscoe skrev 2010-08-06 00:36: > Magnus, Ingemar, Colin, Piers, Ken, > > Below are my main technical concerns with > draft-ietf-avt-ecn-for-rtp-02 as promised. > I have used the line numbering here: > > > T1/ Combining pkts <<<---THIS EMAIL > T2/ ECN-IP-RTCP > T3/ Anti-Cheating > T4/ Logging Not-ECT fall-back > T5/ Delivery %age ECT vs Not-ECT > T6/ Pkt Reordering around session start > > > T1/ Combining packets: Fragmentation and Reassembly > ------------------- > " > > > 317 * If the translator modifies the media stream to > combine or split > 318 RTP packets, but does not otherwise transcode the media, it > 319 must manage the ECN bits in a way analogous to that described > 320 in Section 5.3 of [RFC3168]: > > > " > Don't agree. The fragmentation and reassembly rules in RFC3168 were > designed around TCP. They aren't applicable to RTP. See the argument > about RFC3168 at the time it was in last call: > > This email refers to S.11 on fragmentation of this review of > draft-ietf-tsvwg-ecn-01 before it became RFC3168: > > > " > > > 322 identically to the original; if several ECN marked packets are > 323 combined into one, the outgoing packet must be either ECN-CE > 324 marked or dropped if any of the incoming packets are ECN-CE > 325 marked, > " > I suggest: > "...the outgoing packet SHOULD be ECN-CE marked with a probability > proportional to the ratio of ECN-CE bytes to total bytes in the > incoming packets being combined. However, for simplicity, the > outgoing packet MAY be ECN-CE marked if any of the incoming packets > are ECN-CE marked. This latter option will inflate the amount of > congestion indicated, but it is at least safe. > " Ok, that does make sense. I am fine with that suggestion. > > 325 and should be ECT marked if any of the > incoming packets > 326 are ECT marked. > > > " > I think this clause should shift to before the preceding one that > starts on line 323. It is a more logical order to first check whether > all packets being combined are ECN-capable before combining CE markings. > (I take it that the logic here is that some RTP sources may not be > ECN capable, but if ECT packets are being sent by other sources, it > implies all potential receivers are ECN-capable.) > Well, the issue here is that if one is in a probing phase and only send some fraction as ECT marked, and the rest without. If one combines them, we need to indicate which direction these markings should go. The current text proposes that if any are ECT, the outgoing packet is ECT. That way ensuring that any ECT are sent at all. In worst case all packets during the probing are ECT marked. Thus allowing a non-capable receiver to only detect this based on RTCP. But at least it is being detected during the probing phase rather than later which would be if one had a rule saying that if any of the packets being combined is Not-ECT then mark it as NOT-ECT would result in. > " > > > 1757 When rounding counter values in the translated RTCP packet, the > 1758 translator should try to ensure that they sum to the number of RTP > 1759 packets in the pre-translation sequence number space (numOrig). The > 1760 translator should also try to ensure that no non-zero counter is > 1761 rounded to a zero value, since that will lose information that a > 1762 particular type of event has occurred. > > > " > An idea: Include a field in the RTP ECN feedback packet for the > ratio, R. Then, rather than the translator translating all the > numbers in the report, the host receiving the message can do the > translations, but it also has the original information. > Hmm, that is possibly a good idea. I guess we need at least 8 bits for such a ratio, maybe a couple more would be advantageous to get sufficient resolution. And if I understand you correct you want the ratio to be measured as: R= (ECN-CE marked bytes since last report from this SSRC) / (Total bytes received since last report from this SSRC)? 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 Tue Oct 19 06:14:47 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DB63A680B for ; Tue, 19 Oct 2010 06:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhQcBRNoF33J for ; Tue, 19 Oct 2010 06:14:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2FF703A67F8 for ; Tue, 19 Oct 2010 06:14:41 -0700 (PDT) X-AuditID: c1b4fb39-b7b54ae000003464-7d-4cbd9a1cbea9 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D5.B0.13412.C1A9DBC4; Tue, 19 Oct 2010 15:16:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Oct 2010 15:16:09 +0200 Received: from [147.214.183.82] ([147.214.183.82]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Oct 2010 15:16:09 +0200 Message-ID: <4CBD9A19.5030408@ericsson.com> Date: Tue, 19 Oct 2010 15:16:09 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Bob Briscoe References: <201008052251.o75Mp7BJ005112@bagheera.jungle.bt.co.uk> <201008181629.o7IGTTgC024100@bagheera.jungle.bt.co.uk> In-Reply-To: <201008181629.o7IGTTgC024100@bagheera.jungle.bt.co.uk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Oct 2010 13:16:09.0740 (UTC) FILETIME=[CB9F1CC0:01CB6F8F] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-avt-ecn-for-rtp , Piers O'Hanlon , avt Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 T2/ ECN-IP-RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 13:14:47 -0000 Hi Bob, Thanks for these comments. I am sorry that I haven't responded earlier. I have finally gotten to the point of providing my view on the comments. So the benefit is that RTCP loss rates should be lower when congestion is high on the path the RTCP message takes. As RTCP packets aren't sequence nor reported on, there isn't a easy way of using them for congestion control directly. I am not saying impossible, but it will require significant amount of work and consume extra space in reports for fields related to RTCP. For the sender of the RTCP message to be able to influence the congestion levels on the path from itself to other end-point(s) it needs to have media flow over that path. If it has media flowing over that path, it can reduce its transmission rate and hope that it reduced the congestion level. If the RTCP sender doesn't have media flowing form it to the report consumer, which is true for unidirectional media, like streaming and for RTCP for SSM, or receiver only behavior in ASM. In those case the RTCP sending end-point can't affect the congestion level. In addition I think it is wrong to increase the delivery chance for RTCP when the RTCP sending end-point can't really reduce the rate of RTCP either, nor get report on that packets where ECN marked. >From my perspective the benefit is both questionable to utilize and minor compared to the additional complexities. Especially after we have improved your proposal, like getting the re-routing case working better. Because I think the obvious response to having had ECT working and suddenly detecting ECT failure is to turn of the ECT on RTCP when reporting this. If we in the end do want to enable this, we can write an extension or an update of the spec, where we override the SHALL. Cheers Magnus Bob Briscoe skrev 2010-08-18 18:29: > Piers, > > At 20:17 17/08/2010, Piers O'Hanlon wrote: >> Hi Bob, >> >> Thanks for the suggestion on ECN for RTCP - some comments in-line >> where appropriate and the rest here. >> >> One observation is that your mechanism generally relies on >> bi-directional flows to achieve the signalling > > Looking at your inline comments, I think you've misinterpreted my > attempt at careful wording. I said, "If B is a pure RTP receiver in a > unidirectional session, it will never get RTCP reports containing > counts of ECT and CE," which did not mean "it will never get RTCP > reports". It meant "Any RTCP reports it gets will never contain > counts of ECT or CE." > > Nonetheless, I agree my proposed variation to the protocol would only > ever turn on ECT for RTCP packets if there was some bidirectional RTP > traffic. That's the best I could do without requiring RTCP reports to > report on RTCP packets in the other direction. But that's better than nothing. > >> but when there are >> bidirectional RTP flows then the ECN status of the path would be >> provided already by the respective RTCP reports in each direction. > > Exactly. That's what I'm proposing to use in order to turn on ECT on > RTCP packets, which the current draft forbids. > >> It's hard to quantify the added benefit of knowing that the reverse >> path is getting congested and whether that is worth an extra >> 2xRTCP_reporting_period of loss.... > > You only get this amount of loss if there has been a re-route from a > working ECN path to a non-compliant one. As stated elesewhere in my > review, I think the draft is rather paranoid about this possibility. > 1) Some people already question how much effort the IETF should put > into making protocols robust to non-compliant muddleboxes > 2) Once a compliant path has been found, would any reasonable person > really expect us to worry about losses while timing out after being > re-routed onto a another path that happens to be non-compliant? The > conditional probability of being re-routed onto a non-compliant path > having previously been on a compliant path must surely be low? > >> I guess the probability of each >> should hopefully be quite different but it is still a potentially >> nasty hit to take if an ugly muddlebox falls in the way. > > I agree all this is hard to quantify, but this double jeopardy is > like the risk of a pimple growing on a spot. > >> The other snag is with asymmetric paths, as the fact that the RTCP >> path is congested may not be indicative of the forward [RTP] path. > > The proposed protocol doesn't require or assume symmetric paths. > > I agree the main /motivation/ I gave for ECT on RTCP is not losing > RTCP reports /if there is/ correlation between congestion in both > directions. But the protocol doesn't need this correlation in order > to work. And there are other motivations anyway. > >> On balance I agree with Ken that it probably isn't worth the extra >> effort, though I can see the attraction. > > There is little extra effort for the gain you get in typical cases > (see response to Ken). We certainly should not so emphatically > prohibit ECT on RTCP packets with the ""SHALL NOT" in the draft, > given it can 'just work' in most deployment cases, with my proposed variation. > > I think we have different assumptions about which obscure > possibilities should be considered. For instance, I think a lot of > the complexity dealing with re-routes onto non-compliant paths is overkill. > > Personally I would leave these choices to implementers, which was the > spirit behind my proposal to modularise the protocol spec more, so > certain parts could be made optional. > > > Bob > > >> Thanks, >> >> Piers >> >> On 5 August 2010 23:39, Bob Briscoe wrote: >>> Magnus, Ingemar, Colin, Piers, Ken, >>> >>> Below are my main technical concerns with draft-ietf-avt-ecn-for-rtp-02 as >>> promised. >>> I have used the line numbering here: >>> >> >>> >>> T1/ Combining pkts >>> T2/ ECN-IP-RTCP <<<---THIS EMAIL >>> T3/ Anti-Cheating >>> T4/ Logging Not-ECT fall-back >>> T5/ Delivery %age ECT vs Not-ECT >>> T6/ Pkt Reordering around session start >>> >>> >>> T2/ ECN in the IP header of RTCP reports. >>> ------------------- >>> " >>> >>> >>> 510 RTCP traffic MUST NOT be ECT marked for the following reason. >>> >>> >>> " >>> " >>> >>> >>> 1047 The sender SHALL NOT include ECT marks on outgoing RTCP packets, >>> and >>> 1048 SHOULD NOT include ECT marks on any other outgoing control >>> messages >>> 1049 (e.g. STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, >>> or >>> 1050 ZRTP [I-D.zimmermann-avt-zrtp] control packets) that are >>> multiplexed >>> 1051 on the same UDP port. >>> >>> >>> " >>> If congestion rises on the reverse path it /could/ be a sign that it is >>> rising on the forward path. Ideally, we want it to be possible >> for receivers >>> to mark RTCP reports as ECT so they are not more likely to be >> lost just when >>> they are needed to report rising congestion levels. E.g. if the congestion >>> level on the reverse path is say, 0.5%, then 1 in 200 RTCP reports will be >>> lost. >>> >>> I promised to propose a way to have ECT on RTCP packets that >> would be robust >>> to middleboxes dropping ECT packets following a re-route. The >> solution makes >>> the following assumptions: >>> A1) that an ECN-Blocking Muddlebox drops any ECT packet, irrespective of >>> whether it is RTP or RTCP at the app-layer. >>> A2) that an RTP source knows how often to expect RTCP reports from >>> receivers, so it can count when RTCP reporting intervals have >> passed without >>> an RTCP report. >>> >>> Here's the proposal:* As per the I-D, the session starts without ECT on any >>> packets. >>> * First sender(s) introduce ECT on RTP packets through the probing methods >>> already described in the I-D. >>> * Consider the unicast case of a session betw A & B. >>> - Once A has received 3 successive RTCP reports containing counts of ECT >>> and CE, it can send its own RTCP reports as ECT. >>> - If A subsequently notices that 3 RTCP reporting periods have passed >>> without a report, or A receives no traffic at all for time [TBA], then A >>> reverts to sending RTCP reports as Not-ECT. >>> - B follows the same two rules as A. >>> - If B is a pure RTP receiver in a unidirectional session, it will never >>> get RTCP reports containing counts of ECT and CE, so it will >> never switch to >>> sending its own RTCP reports as ECT. This is because it has no way to test >>> if ECT packets are getting through. >>> >> A 'pure RTP receiver', which doesn't send RTCP isn't compliant with >> the base RTP spec (rfc3550) - an RTP receiver [only] should still send >> periodic RTCP Receiver Reports. Though there are quite a few Voip >> phones do 'forget' to send RTCP. >> >> >>> - Then if a re-route sends B>A traffic through an ECN-Blocking Middlebox, >>> no B>A packets will get through. But after 3 RTCP reporting periods A tells >>> B in a Not-ECT RTCP report and B reverts to Not-ECT. >>> - If a re-route sends both B>A and A>B traffic through an ECN-Blocking >>> Middlebox, the above behaviour will also recover the session. >>> >>> * Multicast multi-source case, A -> B,C,D,E; B -> A,C,D,E; etc. >>> - Once A has decided it can safely turn on ECT in RTP packets it sends, it >>> watches for any RTCP reports that report reception of a positive Not-ECT >>> count but zero ECT or CE count on packets 'A' sent. Once it has received >>> none of these RTCP reports for three RTCP reporting rounds, 'A' can switch >>> on ECT for its own RTCP reports. 'A' determines 3 reporting rounds by >>> picking a couple of receivers and waiting until it receives 3 reports from >>> each. >>> - B,C,D,E follow the same rule. >>> >>> - A cannot test whether its own ECT RTCP reports continue to arrive at >>> their destinations, because the destinations do not know to expect traffic >>> from A. So if they are getting no traffic from A because of an >>> ECN-Blocking Muddlebox, the transport will never know, although >>> the application or human may miss the contribution from A and reset >>> the transport to use Not-ECT on RTCP reports. >>> >> Again the receivers should be sending periodic Receiver Reports so A >> should be able to know the situation. >> >>> - With receiver-initiated multicast, A also cannot test for all sorts of >>> other blockages that might suddenly appear on paths to some destinations. >>> Therefore, once an ECN-capable session has been established, it would be >>> reasonable to take a leap-of-faith that re-routes are likely to continue to >>> find ECN-capable paths. - And if the leap-of-faith is not warranted, the >>> session breaks until the application resets it to Not-ECT - but that's not >>> surprising if there are broken muddleboxes on some paths. >>> * Multicast single-source case, A -> P,Q,R,S etc. >>> - All follow the same rule as the multi-source case, with the same >>> limitations. >>> - As in the unicast and multi-source cases, if any hosts are pure RTP >>> receivers (P,Q,R,S), they won't ever get an RTCP report about RTP packets >>> they have sent, so they will never set ECT on RTCP reports. >>> >> There is the option for all parties exchange RTCP report when using >> SSM by employing RFC5760. >> >>> Comparison between ECT-RTCP and Not-ECT-RTCP: >>> * Session recovery time following a re-route through an ECN-Blocking >>> Middlebox: >>> - ECT-RTCP: 3 RTCP reporting intervals >>> - Not-ECT-RTCP: 1 RTCP reporting interval >>> * ECT-RTCP has more robust RTCP reporting during rising symmetric >> congestion >>> * Not-ECT-RTCP involves less implementation (unless using leap-of-faith, >>> when they are both the same). >>> >>> BTW, the assumption that an ECN-Muddlebox will drop any ECT >> packets, whether >>> RTP or RTCP, can be relaxed if we add reporting of RTCP packets from A>B in >>> reports from B>A. But it seems a reasonable assumption so reporting on RTCP >>> reports should not be necessary. >>> >>> Cheers >>> >>> >>> Bob >>> >>> >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>> > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tom.van_caenegem@alcatel-lucent.com Tue Oct 19 06:25:28 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1232C3A6824 for ; Tue, 19 Oct 2010 06:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=-2.867, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spFgxkCeZWix for ; Tue, 19 Oct 2010 06:25:19 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id EBF2A3A680F for ; Tue, 19 Oct 2010 06:25:10 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9JDPleE029310 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Oct 2010 15:26:29 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 19 Oct 2010 15:26:20 +0200 From: "Van Caenegem, Tom (Tom)" To: Qin Wu , "avt@ietf.org" Date: Tue, 19 Oct 2010 15:26:18 +0200 Thread-Topic: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 Thread-Index: Actve2pDQit6TVKtQLmzK100YbIcvwABELxw Message-ID: References: <048601cb6f3a$4a973180$30298a0a@china.huawei.com> <061901cb6f7b$61d412a0$30298a0a@china.huawei.com> In-Reply-To: <061901cb6f7b$61d412a0$30298a0a@china.huawei.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: multipart/alternative; boundary="_000_EC3FD58E75D43A4F8807FDE0749175460E497204FRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 13:25:28 -0000 --_000_EC3FD58E75D43A4F8807FDE0749175460E497204FRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Qin, focusing on just SSM arch: I quote from your earlier response: In this draft, the loss detector is just functionality of DS. Furthermore = we only consider the loss detector as part of feedback target within the di= stribution source. Also this is just one example use case to explain how fe= edback suppression works in SSM use case. Again, your draft does explain in detail how feedback suppression works for= a SSM as described here above, but does not address the RAMS case (which a= ssumes a single DS, one or multiple disjoint FTs, where a FT is co-position= ed with a BRS (same IP address). Just consider a DS with multiple disjoint FTs (as in RAMS, and also permitt= ed by RFC 5760). Typically each FT is connected to a different branch of th= e SSM tree. Currently your draft imposes that the feedback suppression message is sent = by the DS over the SSM. This is not a good solution as you either restrict = the solution to packet losses that are common to all SSM RTP receivers (cov= ering packet loss between media source and DS ) or you will send suppressio= n indications (and optionally forthcoming retransmission) to all receivers = even if some did not suffer from packet loss. Therefore the draft should al= so define how suppression information is sent to (a subset of) the receiver= s. It does not make sense to me that IETF would define FB suppression for a= architecture that does not take into account deployed SSM architectures fo= r IPTV. Even within the SSM architecture you are focusing on, I am very much confus= ed: you say there is one DS that hosts the FT and loss reporting function. = What is then the role of the intermediate sources downstream of the DS? I r= eally would appreciate you illustrate with some more architecture drawings. The other point I still am not convinced of, is the use of NACK versus ded= icated suppression message. There should be more clarity in the different a= rchitectures you consider before we can make any statements on whether havi= ng a NACK or FIR that is used as suppression message towards the SSM recei= vers, is confusing or not. I do not disagree that NACK as defined in RFC 45= 88 cannot be used as suppression message. But if we define it this way in a= this "suppression" draft/RFC, and no confusions can occur, I do not see t= he issue, especially as the syntax of the suppression message is completely= the same as a NACK/FIR. Regards Tom ________________________________ From: Qin Wu [mailto:sunseawq@huawei.com] Sent: dinsdag 19 oktober 2010 12:50 To: Van Caenegem, Tom (Tom); avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission= -supression-rtp-04 Hi, Tom: ----- Original Message ----- From: Van Caenegem, Tom (Tom) To: Qin Wu ; avt@ietf.org Sent: Tuesday, October 19, 2010 4:26 PM Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission= -supression-rtp-04 Hi Qin, Thank you for your reply. Reading your responses,you seem to focus really on the SSM case with an ar= chitecture where the single DS (there can be only one DS per SSM) hosts the= sole feedback target, which also hosts the loss detector function. My inte= rpretation is also that in your draft the loss detector sends the FIR or NA= CK supression message to the DS, which then forwards/relays this message ov= er the SSM to all receivers, right? [Qin]: SSM case is just one example case in this draft. We have also discus= sed Transport translator use case and MCU use case. This draft focus on how= the feedback suppression works in these different use cases. For the SSM use case, we may consider multiple distribution sources placed = between media source and the receiver. The loss detector is just one functi= onality of Distribution source, or Retransmission Server or MCU, or Transpo= rt Translator. It does not have to be put as part of feedback target. I pro= pose to remove the stuff of "Loss detector" from this draft, instead, using= Distribution source with loss detection support. What do you think of it? My main comment remains the same: you should at least incorporate the archi= tecture of RAMS (where there can be several FT colocated with the BRS, whi= ch are disjoint from the DS). In this case the FT/BRS should be able to pro= vide a suppression indication to all receivers that report to this FT (whic= h is a subset of all receivers that connect to the SSM), which means one sh= ould not make use of the (original) SSM for providing the suppression indic= ation. Your draft provides a possible solution for only a limited use case= , and not the most interesting one, IMO. [Qin]: I think RAMS case is just one special case of SSM use case. how Feed= back suppression works for SSM use case therfore is quite similar to RAMS, = the only difference is Distrbituion source in the SSM case is replaced with BRS in the RAMS. As regarding another RAMS case where several FTs separated= from BRS, we can address this case if there are strong interests. But to be clear, this draft focus on how Feedback suppression message works= in different use case, not for one specific use case. Further down some responses to your answers below. Tom ________________________________ From: Qin Wu [mailto:sunseawq@huawei.com] Sent: dinsdag 19 oktober 2010 5:04 To: Van Caenegem, Tom (Tom); avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission= -supression-rtp-04 Hi, Tom: Thank for your comments, please see my reply inline. Regards! -Qin ----- Original Message ----- From: Van Caenegem, Tom (Tom) To: avt@ietf.org ; Qin Wu Sent: Tuesday, October 19, 2010 12:08 AM Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission= -supression-rtp-04 Hi Qin, I have some comments (look for TOM below) on the new draft version 4. Thx for addressing them, Tom Section 2 Terminology Loss Detector: The Loss Detector is one logical function which is used to detect the packet loss at the RTP layer and report it to the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. In this case, for a session defined as having a distribution source A, on ports n for the RTP channel and k for the RTCP channel, the Loss Detector are identified by an IP address of distribution source A on port k. The Loss Detector MAY also be implemented in one or more entities different from the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. TOM (1): ..same entity as what? i guess you mean the DS? [Qin]: Your are right. In this draft, the loss detector is just functional= ity of DS. Furthermore we only consider the loss detector as part of feedb= ack target within the distribution source. Also this is just one example use case to explain how feedback suppression = works in SSM use case. TOM (2): I do not understand how you associate the port k to a loss detecto= r.. what do you mean with that? [Qin]: Sorry for ambiguity of the description here. It actually means that= the loss reporter is part of feedback target and share the same address an= d port. section 3 (..) In order to detect packet loss before the receivers perceive it, one or more intermediate nodes are placed between the media source and receiver (e.g., Distribution server, MCU, RTP translator). These intermediaries monitor for packet loss upstream of themselves by checking RTP sequence numbers, just as receivers do. Upon detecting (or suspecting) an upstream loss, the intermediary may send Feedback Suppression message towards the receivers as defined in this specification. TOM (3) : ...based on the two above definitions ...is an intermediate node = hence equal to a "Loss detector"? + How does a Loss detector differ from an RTP receiver? [Qin]: The loss detector is just one functionality of Distribution Source i= n the SSM use case. Maybe we should interpret it as "Loss detection functionality". How the pac= ket loss is detected is out of scope of this document. Different from dedicated RTP receiver, the intermediate node does not depen= d on existing NACK message for Retransmission request for packet loss. the intermediate node can create message by itself. Section 6.1 In order to avoid the forms of NACK implosion described in section 1, the Loss Detector is introduced. The Loss Detector detects and reports packet loss, on both the upstream link and the downstream aggregate link. How the loss detector SHOULD detect the packet loss is beyond of scope of this document. When upstream link or downstream aggregate link packet loss occurs, the Loss Detector MAY inform distribution source of the detected packet loss using Feedback Suppression messages. In response, the distribution source either forwards packet loss suppression report received from Loss Detector or creates a Feedback Suppression report and sends it to all the RTP receivers, over the multicast channel. This loss suppression report tells the receivers that the lost packet will either be forthcoming from distribution source, or it irretrievably lost such that there is nothing to be gained by the receiver sending a NACK to the media source. The distribution source then can (optionally) ask for the lost packets from the media source on behalf of all the RTP receivers. TOM (4) : You probably do not want to have normative language in section 6.= 1, like "How the loss detector SHOULD (..)". [Qin]:Sorry, I can't get it. TOM: this is really a detail. If you want to keep the sentence, you should = e.g. say: "How the loss detector can detect the packet loss... [Qin]Okay. TOM (5) : It is pretty clear how a Loss detector will detect packet loss on= its upstream link, I guess. [Qin]: As I said above, Loss detector is just functionality of some Distri= bution sources. Also what it said here in section 6.1 is just one example use case. TOM (6): What is the rationale for a loss detector to send a Feedback supp= ression message to the DS.. why NOT a RTCP NACK FB? [Qin]: As I explained in the last IETF presentaion, this cause NACK scemat= ics mismatch. That's why many people in the last IETF meeeting suggest to c= reate new RTCP message during presentation. TOM: As your assumption is that the loss reporter is part of the FT that is= part of the DS, then there is even no need to specify how the loss detecto= r reports the packet loss. In the more generic case, it makes more sense to = me that the loss reporter just uses a NACK (or a FIR) if it detects packet = loss, sent towards its FT or to the DS if this one hosts the FT that the lo= ss detector reports to . It is then up to the FT or the DS to decide whethe= r this message triggers a NACK or FIR suppression indication to (s subset of) the receivers. This suppression indication doe= s not necessarly require a new message format. A NACK/FIR that is sent to = a RTP receiver can be defined as a feedback suppression indication. I do no= t see a good use case why NACKs from receivers would be reflected back in= e.g. SSM use case by DS or FT to all the connected receivers. If we define that a NACK/FIR for a SSM may only be sent TOWARDS a RTP rece= iver, if this is for suppression indication, there is no ambiguity possibly= . [Qin]: To me, NACK is uesed to request packet loss retransmission from the= server, NACK has no scemantics for feedback suppression. the intermediate = node e.g., distribution source will confus whether the NACK should be forwarded to the server or th= e receiver. unlike NACK, Feedback Suppression message defined in this draft is used by = the intermediate node/middlebox to notify all the receiver that sending NAC= K may be not necessary and harmful. the intermediate node will know how to deal with the Feedback Suppression m= essage and will not cause scemantics confusion like receiving NACK. One important thing is Feedback suppression can be used without receiving A= NY NACKs. that is why many people think we should define new message althugh the new = message has the similar format as NACK. Therefore I think using NACK sent from some dedicated receiver is just one = way for the distribution source to know packet loss happen. But not the onl= y way. Section 6.1.1 If there are multiple Loss Detectors looking at the same RTP stream, then the loss may be identified by more than one and those detecting the loss will all send requests for the same packet loss. In this case, the distribution source MUST filter the duplicated packet loss request out and only forward one copy of the RTCP Feedback report packet from the first Loss Detector to the group impacted by packet loss. TOM (7) : how will the DS send only a copy of the RTCP FB report packet to = the group impacted by packet loss. Is this done over the SSM? [Qin]: Sorry, maybe I sould say " Section 6.1.1 If there are multiple Distrbitution Source with the loss detection support = looking at the same RTP stream..... " Yes, in the SSM use case, DS send only a copy of the RTCP Feedback Suppres= sion Report packet the group via SSM. In your example you seem to focus only on architectures with a DS which als= o hosts the FT and the loss reporter. There should be sections covering ca= ses where the DS is disjoint from the FT, with several FTs and also several= loss reporters disjoint from the FT and the DS. [Qin] I am not sure we need to address all the possible SSM use cases. In t= his draft, we just give some examples of SSM use case. TOM (8) : what do you mean in above text with "RTCP FB report".. is that th= e suppression message you define in this draft? [Qin]: Yes, RTCP Feedback Suppression Report. TOM (9) : In section "6.1.2. Distribution Source Feedback Summary Model" = it is not clear what your architecture looks like. You talk about multiple = distribution sources.. whcih implies multiple SSMs.. Can you elaborate on t= hat? [Qin]: The scenario we are talking about in the section 6.1.2, is to all= ow multiple Distrbituion source between media source and the receiver. I wi= ll look at the this case as one special SSM case. because each of distrbit= uion source resides at the upstream direction or downstream direction of ot= her distributions souces. Does it make sense? TOM: RFC 5760 only defines one DS for a given SSM. If you depart from that,= you probably need to address and define this architecture in a better way = in your draft. [Qin]: Okay. Tom (10) : In section 6.3. Multipoint Control Unit (MCU) use case, typi= cally an overlay of unicast is used... will the Feedback suppression messag= e be sent over unicast as well? If so, what is gain compared to just having= each RTCP receiver providing each their NACK to the MCU, even in case of a= packet loss impacting all receivers? [Qin]: First The MCU case will not cause NACK Implosion, instead, it may ca= use FIR implosion. Second, using Feedback suppression message can restrict the FIR = message sent from receivers behind MCU and liberate the media source from = FIR implosion. TOM: it is not important whether this is about FIR or NACK. My point is tha= t iso having each receiver sending a NACK/FIR, you will now have to send to= each receiver a NACK/FIR suppression in the given scenario. There are no = differences in terms of Bandwdith overhead or server load in the two cases,= so why bother to send suppression messages? [Qin]: No, one effective use case is suppose packet loss can not repaired, = the MCU can use feedback suppression message to tell the receiver not ask f= or lost packet. Tom (11) : coming back to my previous comment on SDP description in this dr= aft : if this draft defines a RTCP feedback suppression message, why is the= re need for a "announcement" in the SDP for the receivers, that indicates t= hey may receive such feedback suppression messages? If a receiver supports= the message, it will simply act accordingly as described in the draft, no= need to announce that!.. [Qin]: Okay, I get your point. I would like to put this as open issue, disc= uss it in the face to face IETF meeting. Regards Tom --_000_EC3FD58E75D43A4F8807FDE0749175460E497204FRMRSSXCHMBSB1d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Qin,
 
focusing on just SSM arch: I quote from your earli= er=20 response:
 
In this draft,= the loss=20 detector is just functionality of DS.  Furthermore we only consider th= e=20 loss detector as part of feedback target within the distribution source. Also this is just= one=20 example use case to explain how feedback suppression works in SSM use=20 case.
 
Agai= n, your draft=20 does explain in detail how feedback suppression works for a SSM as=20 described here above, but does not address the RAMS case (which assumes a s= ingle=20 DS, one or multiple disjoint FTs, where a FT is co-positioned with a B= RS=20 (same IP address).
 
Just= consider a=20 DS with multiple disjoint FTs (as in RAMS, and also permitted by RFC 5= 760).=20 Typically each FT is connected to a different branch of the SSM tree.= =20
 
Currently your draft imposes that the feedback suppression me= ssage=20 is sent by the DS over the SSM. This is not a good solution as you either=20 restrict the solution to packet losses that are common to all SSM RTP recei= vers=20 (covering packet loss between media source and DS ) or you will send suppre= ssion=20 indications (and optionally forthcoming retransmission) to all receivers ev= en if=20 some did not suffer from packet loss. Therefore the draft should= =20 also define how suppression information is sent to (a subset of) the=20 receivers. It does not make sense to me that IETF would define FB suppressi= on=20 for a architecture that does not take into account deployed SSM=20 architectures for IPTV.
 
Even within the SSM architecture you = are=20 focusing on, I am very much confused: you say there is one DS that hosts th= e FT=20 and loss reporting function. What is then the role of the intermediate sour= ces=20 downstream of the DS? I really would appreciate you illustrate with some mo= re=20 architecture drawings.
 
The other point I still am not convin= ced of, is=20  the use of NACK versus dedicated suppression message. There shou= ld be=20 more clarity in the different architectures you consider before we can make= any=20 statements on whether having a NACK or FIR  that is used as= =20 suppression message towards the SSM receivers, is confusing or not. I do no= t=20 disagree that NACK as defined in RFC 4588 cannot be used as suppression mes= sage.=20 But if we define it this way in a this "suppression"  draft/RFC, = and=20 no confusions can occur, I do not see the issue, especially as the syntax o= f the=20 suppression message is completely the same as a NACK/FIR.=20
 
Regards
Tom
 
 
 
 

From: Qin Wu [mailto:sunseawq@huawei.co= m]=20
Sent: dinsdag 19 oktober 2010 12:50
To: Van Caenegem, = Tom=20 (Tom); avt@ietf.org
Subject: Re: [AVT] New Version Notification f= or=20 draft-wu-avt-retransmission-supression-rtp-04

Hi, Tom:
 
----- Original Message -----
Sent: Tuesday, October 1= 9, 2010 4:26 PM
Subject: RE: [AVT] New V= ersion Notification=20 for draft-wu-avt-retransmission-supression-rtp-04

Hi Qin,
 
Thank you for your reply.
 
Reading your responses,you seem to focus really = on the=20 SSM  case with an architecture where the single DS (there can be onl= y one=20 DS per SSM) hosts the sole feedback target, which also hosts the loss det= ector=20 function. My interpretation is also that in your draft the loss detector = sends=20 the FIR or NACK supression message to the DS, which then forwards/relays= =20 this message over the SSM to all receivers, right? =20
 
[Qin]: SSM case is just one example case in this draft. We have = also=20 discussed Transport translator use case and MCU use case. This draft focu= s on=20 how the feedback suppression works in these different use=20 cases.
For the SSM use case, we may consider multiple distribution sour= ces=20 placed between media source and the receiver. The loss detector is just o= ne=20 functionality of Distribution source, or Retransmission Server or MCU, or= =20 Transport Translator. It does not have to be put as part of feedback targ= et. I=20 propose to remove the stuff of "Loss detector" from this draft, inst= ead,=20 using Distribution source with loss detection support. What do you think = of=20 it?
 
My main comment remains the same: you should at = least=20 incorporate the architecture of RAMS (where there can be severa= l=20 FT  colocated with the BRS, which are disjoint from the DS). In this= case=20 the FT/BRS should be able to provide a suppression indication to all rece= ivers=20 that report to this FT (which is a subset of all receivers that connect t= o the=20 SSM), which means one should not make use of the (original) SSM for provi= ding=20 the suppression indication.  Your draft provides a possible solution= for=20 only a limited use case, and not the most interesting one,=20 IMO.  
 
[Qin]: I think RAMS case is just one special case of S= SM use=20 case. how Feedback suppression works for SSM use case therfore is qu= ite=20 similar to RAMS, the only difference is Distrbituion source in the SSM ca= se is=20 replaced with
BRS in the RAMS. As regarding another RAMS case where sever= al FTs=20 separated from BRS,   we can address thi= s case if=20 there are strong interests. 
But to be clear, this draft focus on how Feedback suppression me= ssage=20 works in different use case, not for one specific use=20 case.
 
Further down some responses to your an= swers=20 below.
 
Tom
 

From: Qin Wu [mailto:sunseawq@huawei.= com]=20
Sent: dinsdag 19 oktober 2010 5:04
To: Van Caenegem,= Tom=20 (Tom); avt@ietf.org
Subject: Re: [AVT] New Version Notification= for=20 draft-wu-avt-retransmission-supression-rtp-04

Hi, Tom:
Thank for your comments, please see my reply inline.
 
Regards!
-Qin
From: Van Caenegem, Tom (Tom)
avt@ietf.org ;=20 Qin Wu
Loss Detector: The Loss Detector is one logical function which is used to detect the packet loss at the RTP layer and report it to the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. In this case, for a session defined as having a distribution source A, on ports n for the RTP channel and k for the RTCP channel, the Loss Detector are identified by an IP address of distribution source A on port k. The Loss Detector MAY also be implemented in one or more entities different from the distribution source. 
 The function of the loss reporter may be collocated with
      or integrated into the same entity.
TOM (1): ..same enti=
ty as what? i guess you mean the DS?
[Qin]: Your are right.  I=
n this draft, the loss detector is just functionality of DS.  Furthermore w=
e only consider the loss detector as part of feedback target within the dis=
tribution source.
=
Also=
 this is just one example use case to explain how feedback suppression work=
s in SSM use case.
TOM (2): I do not understand how you associ=
ate the port k to a loss detector.. what do you mean with that?
section 3
 
=
(..)
In order to detect packet loss before the receivers perceiv=
e it, one
   or more intermediate nodes are placed between the media source and
   receiver (e.g., Distribution server, MCU, RTP translator).  These
   intermediaries monitor for packet loss upstream of themselves by
   checking RTP sequence numbers, just as receivers do.  Upon detecting
   (or suspecting) an upstream loss, the intermediary may send Feedback
   Suppression message towards the receivers as defined in this
   specification.
TOM (3)=20 : ...based on the two abov= e=20 definitions ...is an intermediate node hence equal to a "= Loss detector"? =20
+ Ho= w does a=20 Loss detector differ from an RTP receiver?
[Qin]: The loss detector is just = one=20 functionality of Distribution Source in the SSM use case.
Maybe we should interpret it= as=20 "Loss detection functionality". How the packet loss is detected is out = of=20 scope of this document.
Different from dedicated RTP rece= iver,=20 the intermediate node does not depend on existing NACK message for=20 Retransmission request for packet loss.
the intermediate node can create = message=20 by itself.
 
Section 6.1
In order to avoid the forms of NACK implosion de=
scribed in section 1,
   the Loss Detector is introduced.  The Loss Detector detects and
   reports packet loss, on both the upstream link and the downstream
   aggregate link.  How the loss detector SHOULD detect the packet loss
   is beyond of scope of this document.  When upstream link or
   downstream aggregate link packet loss occurs, the Loss Detector MAY
   inform distribution source of the detected packet loss using Feedback
   Suppression messages.  In response, the distribution source either
   forwards packet loss suppression report received from Loss Detector
   or creates a Feedback Suppression report and sends it to all the RTP
   receivers, over the multicast channel.  This loss suppression report
   tells the receivers that the lost packet will either be forthcoming
   from distribution source, or it irretrievably lost such that there is
   nothing to be gained by the receiver sending a NACK to the media
   source.  The distribution source then can (optionally) ask for the
   lost packets from the media source on behalf of all the RTP
   receivers.
TOM (4) : You p=
robably do not want to have normative language in section 6.1, like "How th=
e loss detector SHOULD (..)". 
[Qin]:Sorry, I can't get it. 
TOM: this is really a detail. If you want to keep the sentence, you sho=
uld e.g. say: "How the loss detector can detect the packet loss...
 [Qin]Okay.
<=
/FONT>
TOM (5) : It is pretty clear how a Loss detector will det=
ect packet loss on its upstream link, I guess.
[Qin]: As I sai=
d above,  Loss detector is just functionality of some Distribution sources.=
  Also what it said here in section 6.1 
is just one example u=
se case.
TOM (6):  Wha=
t is the rationale for a loss detector to send a Feedback suppression messa=
ge to the DS.. why NOT a RTCP NACK FB?
[Qin]: As I explained =
in the last IETF presentaion,  this cause NACK scematics mismatch. That's w=
hy many people in the last IETF meeeting suggest to create new RTCP message=
 during presentation. 
TOM: As your assumption is that the loss report=
er is part of the FT that is part of the DS, then there is even no need to =
specify how the loss detector 
reports the packet loss.  In the more generic case,=
 it makes more sense to me that the loss reporter just uses a NACK (or a FI=
R) if it detects packet loss, sent towards its FT or to the DS if this one =
hosts the FT that the loss detector reports to . It is then up to the FT or=
 the DS to decide whether this message triggers a NACK or FIR suppression <=
/SPAN>
indicati=
on to (s subset of) the receivers.  This suppression indication does not ne=
cessarly require a new message format. A NACK/FIR  that is sent to a RTP re=
ceiver can be defined as a feedback suppression indication. I do not see a =
good use case why NACKs from  receivers  would be reflected back in e.g. SS=
M use case by DS or FT  to all the connected receivers. 
If we define that a NACK/FI=
R  for a SSM may only be sent TOWARDS a RTP receiver, if this is for suppre=
ssion indication, there is no ambiguity possibly.   
 [Qin=
]: To me, NACK is uesed to request packet loss retransmission from the serv=
er, NACK has no scemantics for feedback suppression. the intermediate node =
e.g., distribution
source will confus whether the NACK should be =
forwarded to the server or the receiver.
unlike NACK, Feedback Su=
ppression message defined in this draft is used by the intermediate node/mi=
ddlebox to notify all the receiver that sending NACK may be not necessary a=
nd harmful.
the intermediate node will know how to deal with the =
Feedback Suppression message and will not cause scemantics confusion like r=
eceiving NACK.
One important thing is Feedback suppression can be=
 used without receiving ANY NACKs. 
that is why many people think=
 we should define new message althugh the new message has the similar forma=
t as NACK.
Therefore I think using NACK sent from some dedicated =
receiver is just one way for the distribution source to know packet loss ha=
ppen. But not the only way.
Section 6.1.1
If there are multiple Loss Detectors looking at the sa=
me RTP stream,
   then the loss may be identified by more than one and those detecting
   the loss will all send requests for the same packet loss.  In this
   case, the distribution source MUST filter the duplicated packet loss
   request out and only forward one copy of the RTCP Feedback report
   packet from the first Loss Detector to the group impacted by packet
   loss.


    
TOM (7) : how will the DS send on=
ly a=20
    copy of the RTCP FB report packet to the group impacted by packet loss.=
 Is=20
    this done over the SSM? 

    
 

    
[Qin]: Sorry, maybe I sould say=20
    

    
"

    
Section 6.1.1

    
If there are multiple Distrbituti=
on=20
    Source with the loss detection support looking at the same RTP=20
    stream.....

    
"

    
Yes,  in the SSM use case, D=
S send=20
    only a copy of the RTCP Feedback Suppression Report packet the group vi=
a=20
    SSM.

    
 

    
In your example you seem to focus=
 only=20
    on architectures with a DS which also hosts the FT and the loss=20
    reporter.  There should be sections covering cases where the DS is=
=20
    disjoint from the FT, with several FTs and also several loss reporters=
=20
    disjoint from the FT and the DS.

    
 

    
[Qin] I am not sure we need to ad=
dress=20
    all the possible SSM use cases. In this draft, we just give some=20
    examples of SSM use case.

    
 

    
TOM (8) : what do you mean in abo=
ve text=20
    with "RTCP FB report".. is that the suppression message you define in t=
his=20
    draft?

    
 

    
[Qin]: Yes,  RTCP Feedback=20
    Suppression Report. 

    
 

    
TOM (9) : In section  "6.1.2=
. =20
    Distribution Source Feedback Summary Model" it is not clear what your=20
    architecture looks like. You talk about multiple distribution sources..=
=20
    whcih implies multiple SSMs.. Can you elaborate on that?

    
 

    
[Qin]:  The scenario we are =
talking=20
    about in  the section 6.1.2, is to  allow multiple=20
    Distrbituion source between media source and the receiver. I will look =
at=20
    the this case as one special SSM case. because  each of distrbitui=
on=20
    source resides at the upstream=
=20
    direction or downstream direction of other distributions souces. Does i=
t=20
    make sense? 

    
=
 

    
=
TOM: RFC 5760 only defines one DS=
 for a=20
    given SSM. If you depart from that, you probably need to address and=20
    define this architecture in a better way in your=20
    draft. 

    
=
 

    
=
[Qin]: Okay.

    
 

    
Tom (10) :  In section =
=20
    6.3.  Multipoint Control Unit (MCU) use case,  typically an=20
    overlay of unicast is used... will the Feedback suppression message be =
sent=20
    over unicast as well? If so, what is gain compared to just having each =
RTCP=20
    receiver providing each their NACK to the MCU, even in case of a packet=
 loss=20
    impacting all receivers?

    
 

    
[Qin]: First The MCU case will no=
t cause=20
    NACK Implosion, instead, it may cause FIR implosion.

    
       &n=
bsp;  =20
    Second, using Feedback suppression message can restrict the FIR message=
 sent=20
    from receivers behind MCU and liberate the media source from =
 FIR=20
    implosion. 

    
=
 

    
=
TOM: it is not important whether =
this is=20
    about FIR or NACK. My point is that iso having each receiver sending a=
=20
    NACK/FIR, you will now have to send to each receiver a NACK/FIR =20
    suppression in the given scenario. There are no differences in terms of=
=20
    Bandwdith overhead or server load in the two cases, so why bother to se=
nd=20
    suppression messages?

    
 

    
[Qin]: No, one effective use case=
 is=20
    suppose packet loss can not repaired, the MCU can use feedback suppress=
ion=20
    message to tell the receiver not ask for lost packet.

    
 

    
Tom (11) : coming back to my prev=
ious=20
    comment on SDP description in this draft : if this draft defi=
nes a=20
    RTCP feedback suppression message, why is there need for a "announcemen=
t" in=20
    the SDP for the receivers, that indicates they may receive such feedbac=
k=20
    suppression messages?  If a receiver supports the message, it=20
    will  simply act accordingly as described in the draft, no ne=
ed to=20
    announce that!.. 

    
 

    
[Qin]: Okay, I get your point. I =
would=20
    like to put this as open issue, discuss it in the face to face IETF=20
    meeting.

    
 

    
Regards

    
Tom

    


    
 

    
 

    
 

    
 
--_000_EC3FD58E75D43A4F8807FDE0749175460E497204FRMRSSXCHMBSB1d_-- From csp@csperkins.org Tue Oct 19 06:57:15 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA813A6837 for ; Tue, 19 Oct 2010 06:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXi+lpdBeZBY for ; Tue, 19 Oct 2010 06:57:14 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id BD68B3A6813 for ; Tue, 19 Oct 2010 06:57:13 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P8CiC-0000lI-X1; Tue, 19 Oct 2010 13:58:44 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4CBD90BF.80803@ericsson.com> Date: Tue, 19 Oct 2010 14:58:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1C809753-7A60-4308-9072-CA912DD1ED1C@csperkins.org> References: <201008052251.o75Mp7BH005112@bagheera.jungle.bt.co.uk> <4CBD90BF.80803@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1081) Cc: "draft-ietf-avt-ecn-for-rtp@tools.ietf.org" , Bob Briscoe , "avt@ietf.org" Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 T1/ Combining pkts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 13:57:15 -0000 On 19 Oct 2010, at 13:36, Magnus Westerlund wrote: > Bob Briscoe skrev 2010-08-06 00:36: >> Magnus, Ingemar, Colin, Piers, Ken, >>=20 >> Below are my main technical concerns with=20 >> draft-ietf-avt-ecn-for-rtp-02 as promised. >> I have used the line numbering here: >> = >>=20 >> T1/ Combining pkts <<<---THIS EMAIL >> T2/ ECN-IP-RTCP >> T3/ Anti-Cheating >> T4/ Logging Not-ECT fall-back >> T5/ Delivery %age ECT vs Not-ECT >> T6/ Pkt Reordering around session start >>=20 >>=20 >> T1/ Combining packets: Fragmentation and Reassembly >> ------------------- >> " >>=20 >>=20 >> 317 * If the translator modifies the media stream to=20 >> combine or split >> 318 RTP packets, but does not otherwise transcode the = media, it >> 319 must manage the ECN bits in a way analogous to that = described >> 320 in Section 5.3 of [RFC3168]: >>=20 >>=20 >> " >> Don't agree. The fragmentation and reassembly rules in RFC3168 were=20= >> designed around TCP. They aren't applicable to RTP. See the argument=20= >> about RFC3168 at the time it was in last call: >> >> This email refers to S.11 on fragmentation of this review of=20 >> draft-ietf-tsvwg-ecn-01 before it became RFC3168: >> = >>=20 >> " >>=20 >>=20 >> 322 identically to the original; if several ECN marked = packets are >> 323 combined into one, the outgoing packet must be = either ECN-CE >> 324 marked or dropped if any of the incoming packets are = ECN-CE >> 325 marked, >> " >> I suggest: >> "...the outgoing packet SHOULD be ECN-CE marked with a probability=20 >> proportional to the ratio of ECN-CE bytes to total bytes in the=20 >> incoming packets being combined. However, for simplicity, the=20 >> outgoing packet MAY be ECN-CE marked if any of the incoming packets=20= >> are ECN-CE marked. This latter option will inflate the amount of=20 >> congestion indicated, but it is at least safe. >> " >=20 > Ok, that does make sense. I am fine with that suggestion. That makes sense, although it seems more aggressive than the rules in = RFC 3168. What's the rationale for the change? I read = draft-ietf-tsvwg-byte-pkt-congest-02, but that doesn't help my = understanding. >> 325 and should be ECT marked if any of the=20 >> incoming packets >> 326 are ECT marked. >>=20 >>=20 >> " >> I think this clause should shift to before the preceding one that=20 >> starts on line 323. It is a more logical order to first check whether=20= >> all packets being combined are ECN-capable before combining CE = markings. >> (I take it that the logic here is that some RTP sources may not be=20 >> ECN capable, but if ECT packets are being sent by other sources, it=20= >> implies all potential receivers are ECN-capable.) >>=20 >=20 > Well, the issue here is that if one is in a probing phase and only = send > some fraction as ECT marked, and the rest without. If one combines = them, > we need to indicate which direction these markings should go. The > current text proposes that if any are ECT, the outgoing packet is ECT. > That way ensuring that any ECT are sent at all. In worst case all > packets during the probing are ECT marked. Thus allowing a non-capable > receiver to only detect this based on RTCP. But at least it is being > detected during the probing phase rather than later which would be if > one had a rule saying that if any of the packets being combined is > Not-ECT then mark it as NOT-ECT would result in. I'd suggest: "If the outgoing combined packet is not ECN-CE marked, then = it MUST be ECT marked if any of the incoming packets were ECT marked." >> " >>=20 >> 1757 When rounding counter values in the translated RTCP = packet, the >> 1758 translator should try to ensure that they sum to the = number of RTP >> 1759 packets in the pre-translation sequence number space = (numOrig). The >> 1760 translator should also try to ensure that no non-zero = counter is >> 1761 rounded to a zero value, since that will lose information = that a >> 1762 particular type of event has occurred. >>=20 >>=20 >> " >> An idea: Include a field in the RTP ECN feedback packet for the=20 >> ratio, R. Then, rather than the translator translating all the=20 >> numbers in the report, the host receiving the message can do the=20 >> translations, but it also has the original information. >>=20 >=20 > Hmm, that is possibly a good idea. I guess we need at least 8 bits for > such a ratio, maybe a couple more would be advantageous to get > sufficient resolution. And if I understand you correct you want the > ratio to be measured as: > R=3D (ECN-CE marked bytes since last report from this SSRC) / (Total = bytes received since last report from this SSRC)? What's the benefit? This introduces complexity to avoid what should only = be a small rounding error.=20 --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Tue Oct 19 07:08:12 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D24E3A680A for ; Tue, 19 Oct 2010 07:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF6tGWdMfr-u for ; Tue, 19 Oct 2010 07:08:10 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by core3.amsl.com (Postfix) with ESMTP id C437E3A6831 for ; Tue, 19 Oct 2010 07:08:09 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P8Csm-0002i6-dS; Tue, 19 Oct 2010 14:09:40 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4CBD9A19.5030408@ericsson.com> Date: Tue, 19 Oct 2010 15:09:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <966300E8-9A59-4D06-85A9-AED49D9363D3@csperkins.org> References: <201008052251.o75Mp7BJ005112@bagheera.jungle.bt.co.uk> <201008181629.o7IGTTgC024100@bagheera.jungle.bt.co.uk> <4CBD9A19.5030408@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1081) Cc: draft-ietf-avt-ecn-for-rtp , Piers O'Hanlon , Bob Briscoe , avt Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 T2/ ECN-IP-RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:08:12 -0000 Hi, I agree with Magnus, Piers and Ken: this extension doesn't seem worth = the complexity at this time, and can easily be added later if we see a = need. I also note that RTCP traffic is not congestion controlled. Putting ECT = marks on something that won't respond to ECN-CE marks seems undesirable. Colin On 19 Oct 2010, at 14:16, Magnus Westerlund wrote: > Hi Bob, >=20 > Thanks for these comments. I am sorry that I haven't responded = earlier. > I have finally gotten to the point of providing my view on the = comments. >=20 > So the benefit is that RTCP loss rates should be lower when congestion > is high on the path the RTCP message takes. As RTCP packets aren't > sequence nor reported on, there isn't a easy way of using them for > congestion control directly. I am not saying impossible, but it will > require significant amount of work and consume extra space in reports > for fields related to RTCP. >=20 > For the sender of the RTCP message to be able to influence the > congestion levels on the path from itself to other end-point(s) it = needs > to have media flow over that path. If it has media flowing over that > path, it can reduce its transmission rate and hope that it reduced the > congestion level. >=20 > If the RTCP sender doesn't have media flowing form it to the report > consumer, which is true for unidirectional media, like streaming and = for > RTCP for SSM, or receiver only behavior in ASM. In those case the RTCP > sending end-point can't affect the congestion level. In addition I = think > it is wrong to increase the delivery chance for RTCP when the RTCP > sending end-point can't really reduce the rate of RTCP either, nor get > report on that packets where ECN marked. >=20 > =46rom my perspective the benefit is both questionable to utilize and > minor compared to the additional complexities. Especially after we = have > improved your proposal, like getting the re-routing case working = better. > Because I think the obvious response to having had ECT working and > suddenly detecting ECT failure is to turn of the ECT on RTCP when > reporting this. >=20 > If we in the end do want to enable this, we can write an extension or = an > update of the spec, where we override the SHALL. >=20 > Cheers >=20 > Magnus >=20 >=20 > Bob Briscoe skrev 2010-08-18 18:29: >> Piers, >>=20 >> At 20:17 17/08/2010, Piers O'Hanlon wrote: >>> Hi Bob, >>>=20 >>> Thanks for the suggestion on ECN for RTCP - some comments in-line >>> where appropriate and the rest here. >>>=20 >>> One observation is that your mechanism generally relies on >>> bi-directional flows to achieve the signalling >>=20 >> Looking at your inline comments, I think you've misinterpreted my >> attempt at careful wording. I said, "If B is a pure RTP receiver in a >> unidirectional session, it will never get RTCP reports containing >> counts of ECT and CE," which did not mean "it will never get RTCP >> reports". It meant "Any RTCP reports it gets will never contain >> counts of ECT or CE." >>=20 >> Nonetheless, I agree my proposed variation to the protocol would only >> ever turn on ECT for RTCP packets if there was some bidirectional RTP >> traffic. That's the best I could do without requiring RTCP reports to >> report on RTCP packets in the other direction. But that's better than = nothing. >>=20 >>> but when there are >>> bidirectional RTP flows then the ECN status of the path would be >>> provided already by the respective RTCP reports in each direction. >>=20 >> Exactly. That's what I'm proposing to use in order to turn on ECT on >> RTCP packets, which the current draft forbids. >>=20 >>> It's hard to quantify the added benefit of knowing that the reverse >>> path is getting congested and whether that is worth an extra >>> 2xRTCP_reporting_period of loss.... >>=20 >> You only get this amount of loss if there has been a re-route from a >> working ECN path to a non-compliant one. As stated elesewhere in my >> review, I think the draft is rather paranoid about this possibility. >> 1) Some people already question how much effort the IETF should put >> into making protocols robust to non-compliant muddleboxes >> 2) Once a compliant path has been found, would any reasonable person >> really expect us to worry about losses while timing out after being >> re-routed onto a another path that happens to be non-compliant? The >> conditional probability of being re-routed onto a non-compliant path >> having previously been on a compliant path must surely be low? >>=20 >>> I guess the probability of each >>> should hopefully be quite different but it is still a potentially >>> nasty hit to take if an ugly muddlebox falls in the way. >>=20 >> I agree all this is hard to quantify, but this double jeopardy is >> like the risk of a pimple growing on a spot. >>=20 >>> The other snag is with asymmetric paths, as the fact that the RTCP >>> path is congested may not be indicative of the forward [RTP] path. >>=20 >> The proposed protocol doesn't require or assume symmetric paths. >>=20 >> I agree the main /motivation/ I gave for ECT on RTCP is not losing >> RTCP reports /if there is/ correlation between congestion in both >> directions. But the protocol doesn't need this correlation in order >> to work. And there are other motivations anyway. >>=20 >>> On balance I agree with Ken that it probably isn't worth the extra >>> effort, though I can see the attraction. >>=20 >> There is little extra effort for the gain you get in typical cases >> (see response to Ken). We certainly should not so emphatically >> prohibit ECT on RTCP packets with the ""SHALL NOT" in the draft, >> given it can 'just work' in most deployment cases, with my proposed = variation. >>=20 >> I think we have different assumptions about which obscure >> possibilities should be considered. For instance, I think a lot of >> the complexity dealing with re-routes onto non-compliant paths is = overkill. >>=20 >> Personally I would leave these choices to implementers, which was the >> spirit behind my proposal to modularise the protocol spec more, so >> certain parts could be made optional. >>=20 >>=20 >> Bob >>=20 >>=20 >>> Thanks, >>>=20 >>> Piers >>>=20 >>> On 5 August 2010 23:39, Bob Briscoe = wrote: >>>> Magnus, Ingemar, Colin, Piers, Ken, >>>>=20 >>>> Below are my main technical concerns with = draft-ietf-avt-ecn-for-rtp-02 as >>>> promised. >>>> I have used the line numbering here: >>>>=20 >>> = >>>>=20 >>>> T1/ Combining pkts >>>> T2/ ECN-IP-RTCP <<<---THIS EMAIL >>>> T3/ Anti-Cheating >>>> T4/ Logging Not-ECT fall-back >>>> T5/ Delivery %age ECT vs Not-ECT >>>> T6/ Pkt Reordering around session start >>>>=20 >>>>=20 >>>> T2/ ECN in the IP header of RTCP reports. >>>> ------------------- >>>> " >>>>=20 >>>>=20 >>>> 510 RTCP traffic MUST NOT be ECT marked for the following = reason. >>>>=20 >>>>=20 >>>> " >>>> " >>>>=20 >>>>=20 >>>> 1047 The sender SHALL NOT include ECT marks on outgoing RTCP = packets, >>>> and >>>> 1048 SHOULD NOT include ECT marks on any other outgoing = control >>>> messages >>>> 1049 (e.g. STUN [RFC5389] packets, DTLS [RFC4347] handshake = packets, >>>> or >>>> 1050 ZRTP [I-D.zimmermann-avt-zrtp] control packets) that are >>>> multiplexed >>>> 1051 on the same UDP port. >>>>=20 >>>>=20 >>>> " >>>> If congestion rises on the reverse path it /could/ be a sign that = it is >>>> rising on the forward path. Ideally, we want it to be possible >>> for receivers >>>> to mark RTCP reports as ECT so they are not more likely to be >>> lost just when >>>> they are needed to report rising congestion levels. E.g. if the = congestion >>>> level on the reverse path is say, 0.5%, then 1 in 200 RTCP reports = will be >>>> lost. >>>>=20 >>>> I promised to propose a way to have ECT on RTCP packets that >>> would be robust >>>> to middleboxes dropping ECT packets following a re-route. The >>> solution makes >>>> the following assumptions: >>>> A1) that an ECN-Blocking Muddlebox drops any ECT packet, = irrespective of >>>> whether it is RTP or RTCP at the app-layer. >>>> A2) that an RTP source knows how often to expect RTCP reports from >>>> receivers, so it can count when RTCP reporting intervals have >>> passed without >>>> an RTCP report. >>>>=20 >>>> Here's the proposal:* As per the I-D, the session starts without = ECT on any >>>> packets. >>>> * First sender(s) introduce ECT on RTP packets through the probing = methods >>>> already described in the I-D. >>>> * Consider the unicast case of a session betw A & B. >>>> - Once A has received 3 successive RTCP reports containing counts = of ECT >>>> and CE, it can send its own RTCP reports as ECT. >>>> - If A subsequently notices that 3 RTCP reporting periods have = passed >>>> without a report, or A receives no traffic at all for time [TBA], = then A >>>> reverts to sending RTCP reports as Not-ECT. >>>> - B follows the same two rules as A. >>>> - If B is a pure RTP receiver in a unidirectional session, it will = never >>>> get RTCP reports containing counts of ECT and CE, so it will >>> never switch to >>>> sending its own RTCP reports as ECT. This is because it has no way = to test >>>> if ECT packets are getting through. >>>>=20 >>> A 'pure RTP receiver', which doesn't send RTCP isn't compliant with >>> the base RTP spec (rfc3550) - an RTP receiver [only] should still = send >>> periodic RTCP Receiver Reports. Though there are quite a few Voip >>> phones do 'forget' to send RTCP. >>>=20 >>>=20 >>>> - Then if a re-route sends B>A traffic through an ECN-Blocking = Middlebox, >>>> no B>A packets will get through. But after 3 RTCP reporting periods = A tells >>>> B in a Not-ECT RTCP report and B reverts to Not-ECT. >>>> - If a re-route sends both B>A and A>B traffic through an = ECN-Blocking >>>> Middlebox, the above behaviour will also recover the session. >>>>=20 >>>> * Multicast multi-source case, A -> B,C,D,E; B -> A,C,D,E; etc. >>>> - Once A has decided it can safely turn on ECT in RTP packets it = sends, it >>>> watches for any RTCP reports that report reception of a positive = Not-ECT >>>> count but zero ECT or CE count on packets 'A' sent. Once it has = received >>>> none of these RTCP reports for three RTCP reporting rounds, 'A' can = switch >>>> on ECT for its own RTCP reports. 'A' determines 3 reporting rounds = by >>>> picking a couple of receivers and waiting until it receives 3 = reports from >>>> each. >>>> - B,C,D,E follow the same rule. >>>>=20 >>>> - A cannot test whether its own ECT RTCP reports continue to arrive = at >>>> their destinations, because the destinations do not know to expect = traffic >>>> from A. So if they are getting no traffic from A because of an >>>> ECN-Blocking Muddlebox, the transport will never know, although >>>> the application or human may miss the contribution from A and reset >>>> the transport to use Not-ECT on RTCP reports. >>>>=20 >>> Again the receivers should be sending periodic Receiver Reports so A >>> should be able to know the situation. >>>=20 >>>> - With receiver-initiated multicast, A also cannot test for all = sorts of >>>> other blockages that might suddenly appear on paths to some = destinations. >>>> Therefore, once an ECN-capable session has been established, it = would be >>>> reasonable to take a leap-of-faith that re-routes are likely to = continue to >>>> find ECN-capable paths. - And if the leap-of-faith is not = warranted, the >>>> session breaks until the application resets it to Not-ECT - but = that's not >>>> surprising if there are broken muddleboxes on some paths. >>>> * Multicast single-source case, A -> P,Q,R,S etc. >>>> - All follow the same rule as the multi-source case, with the same >>>> limitations. >>>> - As in the unicast and multi-source cases, if any hosts are pure = RTP >>>> receivers (P,Q,R,S), they won't ever get an RTCP report about RTP = packets >>>> they have sent, so they will never set ECT on RTCP reports. >>>>=20 >>> There is the option for all parties exchange RTCP report when using >>> SSM by employing RFC5760. >>>=20 >>>> Comparison between ECT-RTCP and Not-ECT-RTCP: >>>> * Session recovery time following a re-route through an = ECN-Blocking >>>> Middlebox: >>>> - ECT-RTCP: 3 RTCP reporting intervals >>>> - Not-ECT-RTCP: 1 RTCP reporting interval >>>> * ECT-RTCP has more robust RTCP reporting during rising symmetric >>> congestion >>>> * Not-ECT-RTCP involves less implementation (unless using = leap-of-faith, >>>> when they are both the same). >>>>=20 >>>> BTW, the assumption that an ECN-Muddlebox will drop any ECT >>> packets, whether >>>> RTP or RTCP, can be relaxed if we add reporting of RTCP packets = from A>B in >>>> reports from B>A. But it seems a reasonable assumption so reporting = on RTCP >>>> reports should not be necessary. >>>>=20 >>>> Cheers >>>>=20 >>>>=20 >>>> Bob >>>>=20 >>>>=20 >>>>=20 >>>> ________________________________________________________________ >>>> Bob Briscoe, BT Innovate & Design >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avt >>>>=20 >>=20 >> ________________________________________________________________ >> Bob Briscoe, BT Innovate & Design >>=20 >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Tue Oct 19 07:19:09 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1973A6840 for ; Tue, 19 Oct 2010 07:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.44 X-Spam-Level: X-Spam-Status: No, score=-103.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5W4cHIH6n-q for ; Tue, 19 Oct 2010 07:19:08 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id C95553A6831 for ; Tue, 19 Oct 2010 07:19:07 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P8D3O-0000AI-jz; Tue, 19 Oct 2010 14:20:38 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <201008252336.o7PNafwl030089@bagheera.jungle.bt.co.uk> Date: Tue, 19 Oct 2010 15:20:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D774CF6-FB7C-4710-A040-FCF40775FB8A@csperkins.org> References: <201008052251.o75Mp7BL005112@bagheera.jungle.bt.co.uk> <662B899F-09B5-48E5-B164-C61D278E4670@g11.org.uk> <201008252336.o7PNafwl030089@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1081) Cc: draft-ietf-avt-ecn-for-rtp@tools.ietf.org, avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:19:09 -0000 The ECN nonce support is pretty modular. I'm happy to rip it out of this = draft, since we can always resurrect it in a separate draft if there's a = need later. Colin On 26 Aug 2010, at 00:36, Bob Briscoe wrote: > Ken, >=20 > We're violently agreeing I think, modulo just a little more optimism = on my part about ConEx ;) >=20 > Colin already said (in a Maastricht corridor discussion) that he would = be happy to defer receiver misbehaviour stuff. But I don't think I had = put the specific proposal to him I put in my mail - modularising the = possibility of two alternative future approaches. I've cut all that text = from the thread now so, Colin, feel free to respond to Ken's request for = your view in the previous mail instead. >=20 > One response inline, altho I think that part of the conversation is = getting pretty obscure... >=20 > At 21:39 25/08/2010, ken carlberg wrote: >> Bob, >>=20 >> FYI. its been a while since this email was sent, so I'm not snipping = any of it, but my responses are few and scattered throughout. And in = this case, my opinions are not that strong, so I can probably be swayed = by my co-authors if they feel differently. That said... >>=20 >> On Aug 5, 2010, at 6:41 PM, Bob Briscoe wrote: >> > Magnus, Ingemar, Colin, Piers, Ken, >=20 > [snip] >=20 >> > T3c/ Misbehaving end-points >> > ------------------- >> > " >> > 1968 It is far = from certain >> > 1969 that a receiver would be able to get a significant = larger share of >> > 1970 the resources. That assumes a high enough level of = aggregation >> > 1971 that there are flows to acquire shares from. >> > " >> > Don't agree. It's completely certain that an unresponsive receiver = (or sender) can get a significantly larger share of the resources, = whether or not it uses ECN. Just try it. Send an unresponsive flow along = with some responsive flows (e.g TCP) and the TCPs reduce their rates = while the unresponsive flow gets whatever rate it chooses to send at. >> > " >>=20 >> well, it depends on context. if I have an aggregate of flows that = are only periodically and in a bursty manner triggering a congestive = state, as opposed to a sustained level of congestion condition (though = not collapse), then there are no guarantees that all the other flows = will be marked or even suffer packet loss. And... >=20 >=20 > [BB]: Going back to the para at issue in the I-D that I quoted: could = I paraphrase it as, "If there are only two flows sharing a bottleneck, a = cheating receiver cannot get more than twice as much as it would under = equality, which isn't so bad."? If that's what it means, nah! Capacity = sharing problems are surely better measured by how little others get, = rather than how much more the cheater gets. >=20 > Moving on to your periodic bursts scenario, I'm not quite sure I = understand what you are getting at or how it's relevant to the para in = the I-D. >=20 > Whatever, surely fair shares aren't an issue during any period when a = link isn't fully utilised. Becasue, if a link isn't fully utilised for = some period, however brief, it is impossible to take more than your fair = share over that period (for any definition of fairness) and it's = impossible to cause others to get less than their fair share, because = nothing you are doing stops others taking more than they are taking. >=20 > Then, during those bursts, it's only relevant that there would have = marking or loss if someone else had taken a greater share than they were = taking at that time. But while there's no marking or loss, it implies = no-one else is wanting more than they are taking. So lack of marking or = loss indicates there cannot have been any sharing problem. >=20 > Or am I missing your point? >=20 >=20 > Bob >=20 >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Tue Oct 19 07:44:34 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 234723A6823 for ; Tue, 19 Oct 2010 07:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOmqRCDZnrLl for ; Tue, 19 Oct 2010 07:44:28 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 149613A681F for ; Tue, 19 Oct 2010 07:44:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7b28ae00000135b-12-4cbdaf238f96 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8E.7F.04955.32FADBC4; Tue, 19 Oct 2010 16:45:55 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Oct 2010 16:45:55 +0200 Received: from [147.214.183.82] ([147.214.183.82]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Oct 2010 16:45:54 +0200 Message-ID: <4CBDAF22.5020307@ericsson.com> Date: Tue, 19 Oct 2010 16:45:54 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Bob Briscoe References: <201008052251.o75Mp7BN005112@bagheera.jungle.bt.co.uk> In-Reply-To: <201008052251.o75Mp7BN005112@bagheera.jungle.bt.co.uk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Oct 2010 14:45:54.0723 (UTC) FILETIME=[55524F30:01CB6F9C] X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ecn-for-rtp@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 Other Tech Concerns X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:44:34 -0000 Hi Bob, See inline for my comments on the three issues. Bob Briscoe skrev 2010-08-06 00:50: > Magnus, Ingemar, Colin, Piers, Ken, > > Below are my main technical concerns with > draft-ietf-avt-ecn-for-rtp-02 as promised. > I have used the line numbering here: > > > T1/ Combining pkts > T2/ ECN-IP-RTCP > T3/ Anti-Cheating > T4/ Logging Not-ECT fall-back <<<---THIS EMAIL > T5/ Delivery %age ECT vs Not-ECT <<<---THIS EMAIL > T6/ Pkt Reordering around session start <<<---THIS EMAIL > > T4/ Not just fall-back to Not-ECT, but logging or alarms too. > ------------------- > " > 783 loss of all packets with ECT or ECN-CE markings. If the > path between > 784 the sender and the receivers exhibits either of these behaviours one > 785 needs to stop using ECN immediately to protect both the network and > 786 the application. > " > " > 1332 Detecting clearing of ECN field: > 1337 Dropping of ECT packets: > " > As well as detecting ECN black holes and falling back to Not-ECT, the > source ought to log the IP address pair exhibiting this problem. This > could be used for later diagnostics, if someone ever tries to > systematically clear up this middlemess (e.g. in a corporate > environment, or anywhere that a network operator has access to these logs). > The logs might also be used as a database for selective leaps-of-faith. > > If an appropriate management alarm can be raised, it should be too. Agreed, I have no issues including that in the spec. > > T5/ Comparing Delivery percentage of ECT vs Not-ECT > ------------------- > " > 1337 Dropping of ECT packets: To determine if the packet drop ratio is > 1338 different between not-ECT and ECT marked transmission requires a mix > 1339 of transmitted traffic. The sender should compare if the delivery > 1340 percentage (delivered / transmitted) between ECT and not-ECT is > 1341 significantly different. Care must be taken if the number > of packets > 1342 are low in either of the categories. > " > Eh? This surely won't work. Under normal circumstances (ie no > ECN-Blocking Muddleboxes) Not-ECT packets will be dropped more due to > congestion and ECT packets will hardly ever be dropped. So the sender > cannot detect if ECT packets are getting some extra drop due to > Muddleboxes, by comparing with Not-ECT which will have extra drop for > another valid reason (congestion). Well, that depends on the relative frequency between the ECT and non-ECT and the actual packet loss rates. But, yes I think you might have spotted a short coming in our thinking. But I think this is not completely wrong but is lacking the factor from CE marking, see below. A very direct method of resolving this issue is to use explicit loss vectors by using RTCP XR packet loss vectors. The ECN Nonce one doesn't separate between ECN-CE and packet loss and although possible requires a bit of going around to find the packet loss rate for ECT. What I can understand the sender would need to keep its actual transmission pattern. First count and eliminate the not-ect packets that are lost from the NONCE vector. Then the remaining marked in the NONCE vector are CE and packet loss of ECT packets. By removing the number of CE marked ones from the same report interval based on the ECN report blocks you would arrive at an approximate number of lost ECT packets. I say approximate, because you still have the reordering issue that make the sender uncertain on exactly which packets has been reported in the ECN report between two RTCP packets. But lets look at what level of statistics is needed to be able to draw some conclusions. I agree that for certain operation points there will be a clear difference between ECT and non-ECT traffic. But lets look at some examples: No congestion at all: NON-ECT drop rate should be 0. ECT on capable transport drop rate 0, one path(s) that are incapable there will be a drop rate >0. Low levels of congestion: Non-ECT drop rate at a low level (0.5%). ECT on capable transport drop rate 0, with CE marking at low level (0.5%), ECT on incapable path will have a drop rate >0.5. High level of congestion: NON-ECT drop rate at high level (10%). ECT on capable transport will have some drop rate x, where 10 > x > 0, The CE marking rate will be approx 10 - x. ECT on incapable path will see a drop rate that is > 10. Based on the above, I think you can determine when there drops on ECT packets that are not related. This as you can take the CE marking rates into account. NON-ECT droped packets - CE marked packets should approximately equal the number of ECT marked drop packets. What I am unclear on in this case is how big fudge factor you do need. But that needs to be derived based on statics. Comments on the above reasoning. > > T6/ Pkt Reordering around session start------------------- > [Just for the record - I've already sent this point off list.] > > I will use the term "RTCP ECN Reports" for both the RTCP AVPF NACK > transport feedback format and the RTCP XR ECN summary report. > " > 1281 4.4.2. Interpretation of ECN Summary information > > 1306 The counters will be initiated to zero to provide value for the RTP > 1307 stream sender from the very first report. After the first > report the > 1308 changes between the latest received and the previous one is > 1309 determined by simply taking the values of the latest minus the > 1310 previous one, taking field wrapping into account. This > definition is > 1311 also robust to packet losses, since if one report is missing, the > 1312 reporting interval becomes longer, but is otherwise equally valid. > " > Both proposed RTCP ECN Reports insufficiently define the range of > packets they cover. They both define the range by the highest > sequence number and the number of packets covered by the report (the > sum of the various couters in the report, all counted since the start > of the receiver's session). > > This approach makes report accuracy vulnerable to reordering around > the start of the session. For instance, suppose teh receiver receives > the following packets, and imagine the receiver starts its session at > sequence #126. Then sends its first report after seq #135: > > ...119,122,123,124,125,126,127,128,120,121,129,130,132,133,134,135,... > > Highest seq no = #135 > Number of losses = 1 (#131) > packets received = 11 (which will be broken down into CE, ECT etc) > (Total pkts in report = 12) > > The sender will calculate that this report refers to the 12 packets > starting at 135-12=#123 and ending at #135. > > Then, the sender cannot accurately check whether the number of ECT & > CE (or Not-ECT) packets reported by the receiver matches the number > of ECT (or Not-ECT) it sent, because they are both talking about a > different set of packets. For instance, if the sender sets #123 and > #124 as ECT probes, these will be counted as ECT by the sender, but > the receiver puts them outside the range it is reporting on. > > This error will be repeated each time the receiver sends a report, > because it is always cumulative from the start of the session, and > the problem is an ill-defined session start. > > There are three possible solutions: > a) Add text to mandate that the receiver considers the session start > to be the lowest sequence number after it initialises its counters. > In the example, the receiver would count the session start as #120 > not #126, even though it initialised its counters at #126. When it > receives packet #120 it immediately rolls back the start seqno to > #120 and considers 121-125 as 5 losses. Ultimately, because it later > receives #121 it only reports #122-125 as 4 losses - even if these > packets did actually arrive before the counter was initialised. > > b) The receiver does not include any packets with seqnos below the > seqno when it initialised its variables (unless there has been a wrap > of course). In the example, the receever would not include packets > #120 & #121 in its RTCP ECN Reports. > > c) The RTCP ECN Report formats include an explicit start seqno. I > don't think this is necessary, given either a) or b) are easy to do. > > Am I correct, or have I overlooked something? Yes, you are correct that it is important that a receiver do keep track of which packet is the first to count from and thus either doing A or B. I think we should add a clarification on this issue. As long as you do either of A or B the sender wouldn't be fooled about the set. I think from a probing point of view doing B would actually be better. If one take this as an example the packet sender may could come to the conclusion that the ECT probes are lost due to incapability rather than re-ordering. The potential down side is that a probe that has been received may fall outside of the window and need an additional round. There are an alternative to B that I think will work, but most likely are more complex to implement. That is that the sender will move its start number back as long as possible from the initially received number as long as there is no hole. 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 Even.roni@huawei.com Tue Oct 19 07:48:00 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1C13A6851 for ; Tue, 19 Oct 2010 07:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.846 X-Spam-Level: X-Spam-Status: No, score=-98.846 tagged_above=-999 required=5 tests=[AWL=-1.648, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEoR7F6vyekP for ; Tue, 19 Oct 2010 07:47:58 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 43B023A681F for ; Tue, 19 Oct 2010 07:47:57 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAJ00CJBL65J5@szxga05-in.huawei.com> for avt@ietf.org; Tue, 19 Oct 2010 22:49:17 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAJ00381L6415@szxga05-in.huawei.com> for avt@ietf.org; Tue, 19 Oct 2010 22:49:17 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-11-74.red.bezeqint.net [79.177.11.74]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAJ00AJRL5NDO@szxml01-in.huawei.com>; Tue, 19 Oct 2010 22:49:16 +0800 (CST) Date: Tue, 19 Oct 2010 16:45:50 +0200 From: Roni Even In-reply-to: To: "'Van Caenegem, Tom (Tom)'" , 'Qin Wu' , avt@ietf.org Message-id: <041501cb6f9c$5c4db950$14e92bf0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_AyywcT0J2eS5iDLucO/JEw)" Content-language: en-us Thread-index: ActvOmJJMyLM228TSZyF5vja0vwmiQAITiTAAA/gm0A= References: <048601cb6f3a$4a973180$30298a0a@china.huawei.com> Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:48:00 -0000 This is a multi-part message in MIME format. --Boundary_(ID_AyywcT0J2eS5iDLucO/JEw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Tom, I want to clarify your example since I am not sure what is special here. The BRS sends separate unicast streams to each participant so there is reason for suppression on these unicast streams. As for the primary multicast stream from the DS it goes to all receivers. Now if the BRS identify packet loss on the primary stream it should send suppression indication to all members of the multicast group regardless to which FT they report. Can you clarify Roni Even From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Van Caenegem, Tom (Tom) Sent: Tuesday, October 19, 2010 10:27 AM To: Qin Wu; avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 Hi Qin, Thank you for your reply. Reading your responses,you seem to focus really on the SSM case with an architecture where the single DS (there can be only one DS per SSM) hosts the sole feedback target, which also hosts the loss detector function. My interpretation is also that in your draft the loss detector sends the FIR or NACK supression message to the DS, which then forwards/relays this message over the SSM to all receivers, right? My main comment remains the same: you should at least incorporate the architecture of RAMS (where there can be several FT colocated with the BRS, which are disjoint from the DS). In this case the FT/BRS should be able to provide a suppression indication to all receivers that report to this FT (which is a subset of all receivers that connect to the SSM), which means one should not make use of the (original) SSM for providing the suppression indication. Your draft provides a possible solution for only a limited use case, and not the most interesting one, IMO. Further down some responses to your answers below. Tom _____ From: Qin Wu [mailto:sunseawq@huawei.com] Sent: dinsdag 19 oktober 2010 5:04 To: Van Caenegem, Tom (Tom); avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 Hi, Tom: Thank for your comments, please see my reply inline. Regards! -Qin ----- Original Message ----- From: Van Caenegem, Tom (Tom) To: avt@ietf.org ; Qin Wu Sent: Tuesday, October 19, 2010 12:08 AM Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 Hi Qin, I have some comments (look for TOM below) on the new draft version 4. Thx for addressing them, Tom Section 2 Terminology Loss Detector: The Loss Detector is one logical function which is used to detect the packet loss at the RTP layer and report it to the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. In this case, for a session defined as having a distribution source A, on ports n for the RTP channel and k for the RTCP channel, the Loss Detector are identified by an IP address of distribution source A on port k. The Loss Detector MAY also be implemented in one or more entities different from the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. TOM (1): ..same entity as what? i guess you mean the DS? [Qin]: Your are right. In this draft, the loss detector is just functionality of DS. Furthermore we only consider the loss detector as part of feedback target within the distribution source. Also this is just one example use case to explain how feedback suppression works in SSM use case. TOM (2): I do not understand how you associate the port k to a loss detector.. what do you mean with that? [Qin]: Sorry for ambiguity of the description here. It actually means that the loss reporter is part of feedback target and share the same address and port. section 3 (..) In order to detect packet loss before the receivers perceive it, one or more intermediate nodes are placed between the media source and receiver (e.g., Distribution server, MCU, RTP translator). These intermediaries monitor for packet loss upstream of themselves by checking RTP sequence numbers, just as receivers do. Upon detecting (or suspecting) an upstream loss, the intermediary may send Feedback Suppression message towards the receivers as defined in this specification. TOM (3) : ...based on the two above definitions ...is an intermediate node hence equal to a "Loss detector"? + How does a Loss detector differ from an RTP receiver? [Qin]: The loss detector is just one functionality of Distribution Source in the SSM use case. Maybe we should interpret it as "Loss detection functionality". How the packet loss is detected is out of scope of this document. Different from dedicated RTP receiver, the intermediate node does not depend on existing NACK message for Retransmission request for packet loss. the intermediate node can create message by itself. Section 6.1 In order to avoid the forms of NACK implosion described in section 1, the Loss Detector is introduced. The Loss Detector detects and reports packet loss, on both the upstream link and the downstream aggregate link. How the loss detector SHOULD detect the packet loss is beyond of scope of this document. When upstream link or downstream aggregate link packet loss occurs, the Loss Detector MAY inform distribution source of the detected packet loss using Feedback Suppression messages. In response, the distribution source either forwards packet loss suppression report received from Loss Detector or creates a Feedback Suppression report and sends it to all the RTP receivers, over the multicast channel. This loss suppression report tells the receivers that the lost packet will either be forthcoming from distribution source, or it irretrievably lost such that there is nothing to be gained by the receiver sending a NACK to the media source. The distribution source then can (optionally) ask for the lost packets from the media source on behalf of all the RTP receivers. TOM (4) : You probably do not want to have normative language in section 6.1, like "How the loss detector SHOULD (..)". [Qin]:Sorry, I can't get it. TOM: this is really a detail. If you want to keep the sentence, you should e.g. say: "How the loss detector can detect the packet loss... TOM (5) : It is pretty clear how a Loss detector will detect packet loss on its upstream link, I guess. [Qin]: As I said above, Loss detector is just functionality of some Distribution sources. Also what it said here in section 6.1 is just one example use case. TOM (6): What is the rationale for a loss detector to send a Feedback suppression message to the DS.. why NOT a RTCP NACK FB? [Qin]: As I explained in the last IETF presentaion, this cause NACK scematics mismatch. That's why many people in the last IETF meeeting suggest to create new RTCP message during presentation. TOM: As your assumption is that the loss reporter is part of the FT that is part of the DS, then there is even no need to specify how the loss detector reports the packet loss. In the more generic case, it makes more sense to me that the loss reporter just uses a NACK (or a FIR) if it detects packet loss, sent towards its FT or to the DS if this one hosts the FT that the loss detector reports to . It is then up to the FT or the DS to decide whether this message triggers a NACK or FIR suppression indication to (s subset of) the receivers. This suppression indication does not necessarly require a new message format. A NACK/FIR that is sent to a RTP receiver can be defined as a feedback suppression indication. I do not see a good use case why NACKs from receivers would be reflected back in e.g. SSM use case by DS or FT to all the connected receivers. If we define that a NACK/FIR for a SSM may only be sent TOWARDS a RTP receiver, if this is for suppression indication, there is no ambiguity possibly. Section 6.1.1 If there are multiple Loss Detectors looking at the same RTP stream, then the loss may be identified by more than one and those detecting the loss will all send requests for the same packet loss. In this case, the distribution source MUST filter the duplicated packet loss request out and only forward one copy of the RTCP Feedback report packet from the first Loss Detector to the group impacted by packet loss. TOM (7) : how will the DS send only a copy of the RTCP FB report packet to the group impacted by packet loss. Is this done over the SSM? [Qin]: Sorry, maybe I sould say " Section 6.1.1 If there are multiple Distrbitution Source with the loss detection support looking at the same RTP stream..... " Yes, in the SSM use case, DS send only a copy of the RTCP Feedback Suppression Report packet the group via SSM. In your example you seem to focus only on architectures with a DS which also hosts the FT and the loss reporter. There should be sections covering cases where the DS is disjoint from the FT, with several FTs and also several loss reporters disjoint from the FT and the DS. [Qin] I am not sure we need to address all the possible SSM use cases. In this draft, we just give some examples of SSM use case. TOM (8) : what do you mean in above text with "RTCP FB report".. is that the suppression message you define in this draft? [Qin]: Yes, RTCP Feedback Suppression Report. TOM (9) : In section "6.1.2. Distribution Source Feedback Summary Model" it is not clear what your architecture looks like. You talk about multiple distribution sources.. whcih implies multiple SSMs.. Can you elaborate on that? [Qin]: The scenario we are talking about in the section 6.1.2, is to allow multiple Distrbituion source between media source and the receiver. I will look at the this case as one special SSM case. because each of distrbituion source resides at the upstream direction or downstream direction of other distributions souces. Does it make sense? TOM: RFC 5760 only defines one DS for a given SSM. If you depart from that, you probably need to address and define this architecture in a better way in your draft. Tom (10) : In section 6.3. Multipoint Control Unit (MCU) use case, typically an overlay of unicast is used... will the Feedback suppression message be sent over unicast as well? If so, what is gain compared to just having each RTCP receiver providing each their NACK to the MCU, even in case of a packet loss impacting all receivers? [Qin]: First The MCU case will not cause NACK Implosion, instead, it may cause FIR implosion. Second, using Feedback suppression message can restrict the FIR message sent from receivers behind MCU and liberate the media source from FIR implosion. TOM: it is not important whether this is about FIR or NACK. My point is that iso having each receiver sending a NACK/FIR, you will now have to send to each receiver a NACK/FIR suppression in the given scenario. There are no differences in terms of Bandwdith overhead or server load in the two cases, so why bother to send suppression messages? Tom (11) : coming back to my previous comment on SDP description in this draft : if this draft defines a RTCP feedback suppression message, why is there need for a "announcement" in the SDP for the receivers, that indicates they may receive such feedback suppression messages? If a receiver supports the message, it will simply act accordingly as described in the draft, no need to announce that!.. [Qin]: Okay, I get your point. I would like to put this as open issue, discuss it in the face to face IETF meeting. Regards Tom --Boundary_(ID_AyywcT0J2eS5iDLucO/JEw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Tom,

I want to clarify your example since I am not sure what is special here. The BRS sends separate unicast streams to each participant so there is reason for suppression on these unicast streams. As for the primary multicast stream from the DS it goes to all receivers. Now if the BRS identify packet loss on the primary stream it should send suppression indication to all members of the multicast group regardless to which FT they report.

Can you clarify

 

Roni Even

 

 

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Van Caenegem, Tom (Tom)
Sent: Tuesday, October 19, 2010 10:27 AM
To: Qin Wu; avt@ietf.org
Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04

 

Hi Qin,

 

Thank you for your reply.

 

Reading your responses,you seem to focus really on the SSM  case with an architecture where the single DS (there can be only one DS per SSM) hosts the sole feedback target, which also hosts the loss detector function. My interpretation is also that in your draft the loss detector sends the FIR or NACK supression message to the DS, which then forwards/relays this message over the SSM to all receivers, right? 

 

My main comment remains the same: you should at least incorporate the architecture of RAMS (where there can be several FT  colocated with the BRS, which are disjoint from the DS). In this case the FT/BRS should be able to provide a suppression indication to all receivers that report to this FT (which is a subset of all receivers that connect to the SSM), which means one should not make use of the (original) SSM for providing the suppression indication.  Your draft provides a possible solution for only a limited use case, and not the most interesting one, IMO.  

 

Further down some responses to your answers below.

 

Tom

 

 

From: Qin Wu [mailto:sunseawq@huawei.com]
Sent: dinsdag 19 oktober 2010 5:04
To: Van Caenegem, Tom (Tom); avt@ietf.org
Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04

Hi, Tom:

Thank for your comments, please see my reply inline.

 

Regards!

-Qin

----- Original Message -----

Sent: Tuesday, October 19, 2010 12:08 AM

Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04

 

Hi Qin,

 

I have some comments (look for TOM below) on the new draft version 4.

Thx for addressing them,

Tom

 

 

Section 2 Terminology

 Loss Detector:
 
      The Loss Detector is one logical function which is used to detect
      the packet loss at the RTP layer and report it to the distribution
      source.  The function of the loss reporter may be collocated with
      or integrated into the same entity.  In this case, for a session
      defined as having a distribution source A, on ports n for the RTP
      channel and k for the RTCP channel, the Loss Detector are
      identified by an IP address of distribution source A on port k.
      The Loss Detector MAY also be implemented in one or more entities
      different from the distribution source.
 The function of the loss reporter may be collocated with
      or integrated into the same entity.
TOM (1): ..same entity as what? i guess you mean the DS?
[Qin]: Your are right.  In this draft, the loss detector is just functionality of DS.  Furthermore we only consider the loss detector as part of feedback target within the distribution source.
Also this is just one example use case to explain how feedback suppression works in SSM use case.
TOM (2): I do not understand how you associate the port k to a loss detector.. what do you mean with that?
[Qin]:  Sorry for ambiguity of the description here. It actually means that the loss reporter is part of feedback target and share the same address and port.
section 3
 
(..)
In order to detect packet loss before the receivers perceive it, one
   or more intermediate nodes are placed between the media source and
   receiver (e.g., Distribution server, MCU, RTP translator).  These
   intermediaries monitor for packet loss upstream of themselves by
   checking RTP sequence numbers, just as receivers do.  Upon detecting
   (or suspecting) an upstream loss, the intermediary may send Feedback
   Suppression message towards the receivers as defined in this
   specification.

TOM (3) : ...based on the two above definitions ...is an intermediate node hence equal to a "Loss detector"? 

+ How does a Loss detector differ from an RTP receiver?

[Qin]: The loss detector is just one functionality of Distribution Source in the SSM use case.

Maybe we should interpret it as "Loss detection functionality". How the packet loss is detected is out of scope of this document.

Different from dedicated RTP receiver, the intermediate node does not depend on existing NACK message for Retransmission request for packet loss.

the intermediate node can create message by itself.

 

Section 6.1

In order to avoid the forms of NACK implosion described in section 1,
   the Loss Detector is introduced.  The Loss Detector detects and
   reports packet loss, on both the upstream link and the downstream
   aggregate link.  How the loss detector SHOULD detect the packet loss
   is beyond of scope of this document.  When upstream link or
   downstream aggregate link packet loss occurs, the Loss Detector MAY
   inform distribution source of the detected packet loss using Feedback
   Suppression messages.  In response, the distribution source either
   forwards packet loss suppression report received from Loss Detector
   or creates a Feedback Suppression report and sends it to all the RTP
   receivers, over the multicast channel.  This loss suppression report
   tells the receivers that the lost packet will either be forthcoming
   from distribution source, or it irretrievably lost such that there is
   nothing to be gained by the receiver sending a NACK to the media
   source.  The distribution source then can (optionally) ask for the
   lost packets from the media source on behalf of all the RTP
   receivers.
TOM (4) : You probably do not want to have normative language in section 6.1, like "How the loss detector SHOULD (..)". 
[Qin]:Sorry, I can't get it. 
TOM: this is really a detail. If you want to keep the sentence, you should e.g. say: "How the loss detector can detect the packet loss...
 
 
TOM (5) : It is pretty clear how a Loss detector will detect packet loss on its upstream link, I guess.
[Qin]: As I said above,  Loss detector is just functionality of some Distribution sources.  Also what it said here in section 6.1 
is just one example use case.
TOM (6):  What is the rationale for a loss detector to send a Feedback suppression message to the DS.. why NOT a RTCP NACK FB?
[Qin]: As I explained in the last IETF presentaion,  this cause NACK scematics mismatch. That's why many people in the last IETF meeeting suggest to create new RTCP message during presentation. 
 
TOM: As your assumption is that the loss reporter is part of the FT that is part of the DS, then there is even no need to specify how the loss detector 
reports the packet loss.  In the more generic case, it makes more sense to me that the loss reporter just uses a NACK (or a FIR) if it detects packet loss, sent towards its FT or to the DS if this one hosts the FT that the loss detector reports to . It is then up to the FT or the DS to decide whether this message triggers a NACK or FIR suppression 
indication to (s subset of) the receivers.  This suppression indication does not necessarly require a new message format. A NACK/FIR  that is sent to a RTP receiver can be defined as a feedback suppression indication. I do not see a good use case why NACKs from  receivers  would be reflected back in e.g. SSM use case by DS or FT  to all the connected receivers. 
If we define that a NACK/FIR  for a SSM may only be sent TOWARDS a RTP receiver, if this is for suppression indication, there is no ambiguity possibly.   
 
 
Section 6.1.1
If there are multiple Loss Detectors looking at the same RTP stream,
   then the loss may be identified by more than one and those detecting
   the loss will all send requests for the same packet loss.  In this
   case, the distribution source MUST filter the duplicated packet loss
   request out and only forward one copy of the RTCP Feedback report
   packet from the first Loss Detector to the group impacted by packet
   loss.

TOM (7) : how will the DS send only a copy of the RTCP FB report packet to the group impacted by packet loss. Is this done over the SSM?

 

[Qin]: Sorry, maybe I sould say

"

Section 6.1.1

If there are multiple Distrbitution Source with the loss detection support looking at the same RTP stream.....

"

Yes,  in the SSM use case, DS send only a copy of the RTCP Feedback Suppression Report packet the group via SSM.

 

In your example you seem to focus only on architectures with a DS which also hosts the FT and the loss reporter.  There should be sections covering cases where the DS is disjoint from the FT, with several FTs and also several loss reporters disjoint from the FT and the DS.

 

[Qin] I am not sure we need to address all the possible SSM use cases. In this draft, we just give some examples of SSM use case.

 

TOM (8) : what do you mean in above text with "RTCP FB report".. is that the suppression message you define in this draft?

 

[Qin]: Yes,  RTCP Feedback Suppression Report.

 

TOM (9) : In section  "6.1.2.  Distribution Source Feedback Summary Model" it is not clear what your architecture looks like. You talk about multiple distribution sources.. whcih implies multiple SSMs.. Can you elaborate on that?

 

[Qin]:  The scenario we are talking about in  the section 6.1.2, is to  allow multiple Distrbituion source between media source and the receiver. I will look at the this case as one special SSM case. because  each of distrbituion source resides at the upstream direction or downstream direction of other distributions souces. Does it make sense? 

 

TOM: RFC 5760 only defines one DS for a given SSM. If you depart from that, you probably need to address and define this architecture in a better way in your draft. 

 

Tom (10) :  In section  6.3.  Multipoint Control Unit (MCU) use case,  typically an overlay of unicast is used... will the Feedback suppression message be sent over unicast as well? If so, what is gain compared to just having each RTCP receiver providing each their NACK to the MCU, even in case of a packet loss impacting all receivers?

 

[Qin]: First The MCU case will not cause NACK Implosion, instead, it may cause FIR implosion.

           Second, using Feedback suppression message can restrict the FIR message sent from receivers behind MCU and liberate the media source from  FIR implosion. 

 

TOM: it is not important whether this is about FIR or NACK. My point is that iso having each receiver sending a NACK/FIR, you will now have to send to each receiver a NACK/FIR  suppression in the given scenario. There are no differences in terms of Bandwdith overhead or server load in the two cases, so why bother to send suppression messages?

 

 

Tom (11) : coming back to my previous comment on SDP description in this draft : if this draft defines a RTCP feedback suppression message, why is there need for a "announcement" in the SDP for the receivers, that indicates they may receive such feedback suppression messages?  If a receiver supports the message, it will  simply act accordingly as described in the draft, no need to announce that!..

 

[Qin]: Okay, I get your point. I would like to put this as open issue, discuss it in the face to face IETF meeting.

 

Regards

Tom

 

 

 

 

 

--Boundary_(ID_AyywcT0J2eS5iDLucO/JEw)-- From wwwrun@rfc-editor.org Tue Oct 19 07:53:43 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7344C3A684F; Tue, 19 Oct 2010 07:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.09 X-Spam-Level: X-Spam-Status: No, score=-102.09 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3YHjMVlZ0tM; Tue, 19 Oct 2010 07:53:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 7161C3A6849; Tue, 19 Oct 2010 07:53:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B5604E06EA; Tue, 19 Oct 2010 07:55:13 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101019145513.B5604E06EA@rfc-editor.org> Date: Tue, 19 Oct 2010 07:55:13 -0700 (PDT) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVT] RFC 5993 on RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 14:53:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5993 Title: RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR) Author: X. Duan, S. Wang, M. Westerlund, K. Hellwig, I. Johansson Status: Standards Track Stream: IETF Date: October 2010 Mailbox: duanxiaodong@chinamobile.com, wangshuaiyu@chinamobile.com, magnus.westerlund@ericsson.com, karl.hellwig@ericsson.com, ingemar.s.johansson@ericsson.com Pages: 18 Characters: 37824 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-gsm-hr-03.txt URL: http://www.rfc-editor.org/rfc/rfc5993.txt This document specifies the payload format for packetization of Global System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From tom.van_caenegem@alcatel-lucent.com Tue Oct 19 08:29:33 2010 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7672F3A688A for ; Tue, 19 Oct 2010 08:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, FRT_MEETING=2.697, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m23t8AAohQIP for ; Tue, 19 Oct 2010 08:29:30 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id E14D63A6807 for ; Tue, 19 Oct 2010 08:29:29 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9JFUpbf017721 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Oct 2010 17:30:52 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 19 Oct 2010 17:30:51 +0200 From: "Van Caenegem, Tom (Tom)" To: Roni Even , "'Qin Wu'" , "avt@ietf.org" Date: Tue, 19 Oct 2010 17:30:50 +0200 Thread-Topic: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 Thread-Index: ActvOmJJMyLM228TSZyF5vja0vwmiQAITiTAAA/gm0AAAIsbMA== Message-ID: References: <048601cb6f3a$4a973180$30298a0a@china.huawei.com> <041501cb6f9c$5c4db950$14e92bf0$%roni@huawei.com> In-Reply-To: <041501cb6f9c$5c4db950$14e92bf0$%roni@huawei.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: multipart/alternative; boundary="_000_EC3FD58E75D43A4F8807FDE0749175460E497311FRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 15:29:33 -0000 --_000_EC3FD58E75D43A4F8807FDE0749175460E497311FRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, In the typical RAMS architecture, the BRS will receive the SSM stream from = the DS. If there are several BRS-es, there may be just one BRS that detects= packet loss on its upstream link, but the others will perhaps not, as the = packet loss took place on SSM tree branch that does not impact the other BR= Ses. In that case those RTP receivers associated to the other BRS-es in gen= eral will not be impacted and do not need to receive the suppression indica= tion, while the one BRS that did sense the packet loss should probably best= send a suppression indication (although there is a chance that only this B= RS is impacted by packet loss, and not a single RTP receiver in the field r= eporting to this BRS/FT... this all depends on the considered topologies). As a BRS is 1-to-1 associated with a FT, this calls for consideration of ar= chitectures with (multiple) disjoint FT (and associated BRS in RAMS applica= tions) in the suppression draft. Such disjoint FT/BRS in general cannot ac= t as so-called "intermediate nodes" or "translators" because they are not o= n the direct SSM path between the DS and the RTP receivers. Another aspect I want to highlight is that feedback suppression is closely = aligned with retransmission. In the case described above, the one BRS that = detected packet loss on its upstream link, may try to recover the missing p= acket (outside the scope of the draft) and retransmit over multicast to the= receivers that report to the FT. This retransmission towards the receivers= is also outside the current scope of the current draft, but the two are so= mehow linked. In DVB IPTV, we introduced dedicated SSMs sourced by the BRS= for sending NACK suppression and the (optional) retransmission. In the con= sidered scenario, having a DS sending a missing packet -reported by a FT do= wnstream in the SSM tree- over the original SSM is not a good approach IMO,= as it results in general in unnecessary retransmissions for most receivers= . Hope this clarifies. Tom ________________________________ From: Roni Even [mailto:Even.roni@huawei.com] Sent: dinsdag 19 oktober 2010 16:46 To: Van Caenegem, Tom (Tom); 'Qin Wu'; avt@ietf.org Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission= -supression-rtp-04 Hi Tom, I want to clarify your example since I am not sure what is special here. Th= e BRS sends separate unicast streams to each participant so there is reason= for suppression on these unicast streams. As for the primary multicast str= eam from the DS it goes to all receivers. Now if the BRS identify packet lo= ss on the primary stream it should send suppression indication to all membe= rs of the multicast group regardless to which FT they report. Can you clarify Roni Even From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Van C= aenegem, Tom (Tom) Sent: Tuesday, October 19, 2010 10:27 AM To: Qin Wu; avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission= -supression-rtp-04 Hi Qin, Thank you for your reply. Reading your responses,you seem to focus really on the SSM case with an ar= chitecture where the single DS (there can be only one DS per SSM) hosts the= sole feedback target, which also hosts the loss detector function. My inte= rpretation is also that in your draft the loss detector sends the FIR or NA= CK supression message to the DS, which then forwards/relays this message ov= er the SSM to all receivers, right? My main comment remains the same: you should at least incorporate the archi= tecture of RAMS (where there can be several FT colocated with the BRS, whi= ch are disjoint from the DS). In this case the FT/BRS should be able to pro= vide a suppression indication to all receivers that report to this FT (whic= h is a subset of all receivers that connect to the SSM), which means one sh= ould not make use of the (original) SSM for providing the suppression indic= ation. Your draft provides a possible solution for only a limited use case= , and not the most interesting one, IMO. Further down some responses to your answers below. Tom ________________________________ From: Qin Wu [mailto:sunseawq@huawei.com] Sent: dinsdag 19 oktober 2010 5:04 To: Van Caenegem, Tom (Tom); avt@ietf.org Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission= -supression-rtp-04 Hi, Tom: Thank for your comments, please see my reply inline. Regards! -Qin ----- Original Message ----- From: Van Caenegem, Tom (Tom) To: avt@ietf.org ; Qin Wu Sent: Tuesday, October 19, 2010 12:08 AM Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission= -supression-rtp-04 Hi Qin, I have some comments (look for TOM below) on the new draft version 4. Thx for addressing them, Tom Section 2 Terminology Loss Detector: The Loss Detector is one logical function which is used to detect the packet loss at the RTP layer and report it to the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. In this case, for a session defined as having a distribution source A, on ports n for the RTP channel and k for the RTCP channel, the Loss Detector are identified by an IP address of distribution source A on port k. The Loss Detector MAY also be implemented in one or more entities different from the distribution source. The function of the loss reporter may be collocated with or integrated into the same entity. TOM (1): ..same entity as what? i guess you mean the DS? [Qin]: Your are right. In this draft, the loss detector is just functional= ity of DS. Furthermore we only consider the loss detector as part of feedb= ack target within the distribution source. Also this is just one example use case to explain how feedback suppression = works in SSM use case. TOM (2): I do not understand how you associate the port k to a loss detecto= r.. what do you mean with that? [Qin]: Sorry for ambiguity of the description here. It actually means that= the loss reporter is part of feedback target and share the same address an= d port. section 3 (..) In order to detect packet loss before the receivers perceive it, one or more intermediate nodes are placed between the media source and receiver (e.g., Distribution server, MCU, RTP translator). These intermediaries monitor for packet loss upstream of themselves by checking RTP sequence numbers, just as receivers do. Upon detecting (or suspecting) an upstream loss, the intermediary may send Feedback Suppression message towards the receivers as defined in this specification. TOM (3) : ...based on the two above definitions ...is an intermediate node = hence equal to a "Loss detector"? + How does a Loss detector differ from an RTP receiver? [Qin]: The loss detector is just one functionality of Distribution Source i= n the SSM use case. Maybe we should interpret it as "Loss detection functionality". How the pac= ket loss is detected is out of scope of this document. Different from dedicated RTP receiver, the intermediate node does not depen= d on existing NACK message for Retransmission request for packet loss. the intermediate node can create message by itself. Section 6.1 In order to avoid the forms of NACK implosion described in section 1, the Loss Detector is introduced. The Loss Detector detects and reports packet loss, on both the upstream link and the downstream aggregate link. How the loss detector SHOULD detect the packet loss is beyond of scope of this document. When upstream link or downstream aggregate link packet loss occurs, the Loss Detector MAY inform distribution source of the detected packet loss using Feedback Suppression messages. In response, the distribution source either forwards packet loss suppression report received from Loss Detector or creates a Feedback Suppression report and sends it to all the RTP receivers, over the multicast channel. This loss suppression report tells the receivers that the lost packet will either be forthcoming from distribution source, or it irretrievably lost such that there is nothing to be gained by the receiver sending a NACK to the media source. The distribution source then can (optionally) ask for the lost packets from the media source on behalf of all the RTP receivers. TOM (4) : You probably do not want to have normative language in section 6.= 1, like "How the loss detector SHOULD (..)". [Qin]:Sorry, I can't get it. TOM: this is really a detail. If you want to keep the sentence, you should = e.g. say: "How the loss detector can detect the packet loss... TOM (5) : It is pretty clear how a Loss detector will detect packet loss on= its upstream link, I guess. [Qin]: As I said above, Loss detector is just functionality of some Distri= bution sources. Also what it said here in section 6.1 is just one example use case. TOM (6): What is the rationale for a loss detector to send a Feedback supp= ression message to the DS.. why NOT a RTCP NACK FB? [Qin]: As I explained in the last IETF presentaion, this cause NACK scemat= ics mismatch. That's why many people in the last IETF meeeting suggest to c= reate new RTCP message during presentation. TOM: As your assumption is that the loss reporter is part of the FT that is= part of the DS, then there is even no need to specify how the loss detecto= r reports the packet loss. In the more generic case, it makes more sense to = me that the loss reporter just uses a NACK (or a FIR) if it detects packet = loss, sent towards its FT or to the DS if this one hosts the FT that the lo= ss detector reports to . It is then up to the FT or the DS to decide whethe= r this message triggers a NACK or FIR suppression indication to (s subset of) the receivers. This suppression indication doe= s not necessarly require a new message format. A NACK/FIR that is sent to = a RTP receiver can be defined as a feedback suppression indication. I do no= t see a good use case why NACKs from receivers would be reflected back in= e.g. SSM use case by DS or FT to all the connected receivers. If we define that a NACK/FIR for a SSM may only be sent TOWARDS a RTP rece= iver, if this is for suppression indication, there is no ambiguity possibly= . Section 6.1.1 If there are multiple Loss Detectors looking at the same RTP stream, then the loss may be identified by more than one and those detecting the loss will all send requests for the same packet loss. In this case, the distribution source MUST filter the duplicated packet loss request out and only forward one copy of the RTCP Feedback report packet from the first Loss Detector to the group impacted by packet loss. TOM (7) : how will the DS send only a copy of the RTCP FB report packet to = the group impacted by packet loss. Is this done over the SSM? [Qin]: Sorry, maybe I sould say " Section 6.1.1 If there are multiple Distrbitution Source with the loss detection support = looking at the same RTP stream..... " Yes, in the SSM use case, DS send only a copy of the RTCP Feedback Suppres= sion Report packet the group via SSM. In your example you seem to focus only on architectures with a DS which als= o hosts the FT and the loss reporter. There should be sections covering ca= ses where the DS is disjoint from the FT, with several FTs and also several= loss reporters disjoint from the FT and the DS. [Qin] I am not sure we need to address all the possible SSM use cases. In t= his draft, we just give some examples of SSM use case. TOM (8) : what do you mean in above text with "RTCP FB report".. is that th= e suppression message you define in this draft? [Qin]: Yes, RTCP Feedback Suppression Report. TOM (9) : In section "6.1.2. Distribution Source Feedback Summary Model" = it is not clear what your architecture looks like. You talk about multiple = distribution sources.. whcih implies multiple SSMs.. Can you elaborate on t= hat? [Qin]: The scenario we are talking about in the section 6.1.2, is to all= ow multiple Distrbituion source between media source and the receiver. I wi= ll look at the this case as one special SSM case. because each of distrbit= uion source resides at the upstream direction or downstream direction of ot= her distributions souces. Does it make sense? TOM: RFC 5760 only defines one DS for a given SSM. If you depart from that,= you probably need to address and define this architecture in a better way = in your draft. Tom (10) : In section 6.3. Multipoint Control Unit (MCU) use case, typi= cally an overlay of unicast is used... will the Feedback suppression messag= e be sent over unicast as well? If so, what is gain compared to just having= each RTCP receiver providing each their NACK to the MCU, even in case of a= packet loss impacting all receivers? [Qin]: First The MCU case will not cause NACK Implosion, instead, it may ca= use FIR implosion. Second, using Feedback suppression message can restrict the FIR = message sent from receivers behind MCU and liberate the media source from = FIR implosion. TOM: it is not important whether this is about FIR or NACK. My point is tha= t iso having each receiver sending a NACK/FIR, you will now have to send to= each receiver a NACK/FIR suppression in the given scenario. There are no = differences in terms of Bandwdith overhead or server load in the two cases,= so why bother to send suppression messages? Tom (11) : coming back to my previous comment on SDP description in this dr= aft : if this draft defines a RTCP feedback suppression message, why is the= re need for a "announcement" in the SDP for the receivers, that indicates t= hey may receive such feedback suppression messages? If a receiver supports= the message, it will simply act accordingly as described in the draft, no= need to announce that!.. [Qin]: Okay, I get your point. I would like to put this as open issue, disc= uss it in the face to face IETF meeting. Regards Tom --_000_EC3FD58E75D43A4F8807FDE0749175460E497311FRMRSSXCHMBSB1d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Roni,
 
In t= he typical=20 RAMS architecture, the BRS will receive the SSM stream from the DS. If ther= e are=20 several BRS-es, there may be just one BRS that detects packet loss on its=20 upstream link, but the others will perhaps not, as the packet loss took pla= ce on=20 SSM tree branch that does not impact the other BRSes. In that case tho= se=20 RTP receivers associated to the other BRS-es in general will not be impacte= d and=20 do not need to receive the suppression indication, while the one BRS that d= id=20 sense the packet loss should probably best send a suppression indication=20 (although there is a chance that only this BRS is impacted by packet l= oss,=20 and not a single RTP receiver in the field reporting to this BRS/FT... this= all=20 depends on the considered topologies).
 
As a= BRS is=20 1-to-1 associated with a FT, this calls for consideration of architectures = with=20 (multiple) disjoint FT (and associated BRS in RAMS applications)  in t= he=20 suppression draft. Such disjoint FT/BRS in general cannot act as so-called= =20 "intermediate nodes" or "translators" because they are not on the direct SS= M=20 path between the DS and the RTP receivers.
 
Anot= her aspect I=20 want to highlight is that feedback suppression is closely aligned with=20 retransmission. In the case described above, the one BRS that detected pack= et=20 loss on its upstream link, may try to recover the missing packet (outside t= he=20 scope of the draft) and retransmit over multicast to the receivers that rep= ort=20 to the FT. This retransmission towards the receivers is also outside the cu= rrent=20 scope of the current draft, but the two are somehow linked.  In DVB IP= TV,=20 we introduced dedicated SSMs sourced by the BRS for sending NACK=20 suppression and the (optional) retransmission. In the considered scena= rio,=20 having a DS sending a missing packet -reported by a FT downstream in the SS= M=20 tree- over the original SSM is not a good approach IMO, as it results = in=20 general in unnecessary retransmissions for most receivers.
 
Hope= this=20 clarifies.
 
Tom
 
From: Roni Even [mailto:Even.roni@huawei.com]
Sent:<= /B>=20 dinsdag 19 oktober 2010 16:46
To: Van Caenegem, Tom (Tom); 'Qin W= u';=20 avt@ietf.org
Subject: RE: [AVT] New Version Notification for=20 draft-wu-avt-retransmission-supression-rtp-04

Hi=20 Tom,

I=20 want to clarify your example since I am not sure what is special here. The = BRS=20 sends separate unicast streams to each participant so there is reason for=20 suppression on these unicast streams. As for the primary multicast stream f= rom=20 the DS it goes to all receivers. Now if the BRS identify packet loss on the= =20 primary stream it should send suppression indication to all members of the= =20 multicast group regardless to which FT they report.

Can=20 you clarify

 

Roni=20 Even

 

 

 

From:<= /B>=20 avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Van= =20 Caenegem, Tom (Tom)
Sent: Tuesday, October 19, 2010 10:27=20 AM
To: Qin Wu; avt@ietf.org
Subject: Re: [AVT] New Vers= ion=20 Notification for=20 draft-wu-avt-retransmission-supression-rtp-04

 

H= i=20 Qin,

 

T= hank=20 you for your reply.

 

R= eading=20 your responses,you seem to focus really on the SSM  case with an=20 architecture where the single DS (there can be only one DS per SSM) hosts t= he=20 sole feedback target, which also hosts the loss detector function. My=20 interpretation is also that in your draft the loss detector sends the FIR o= r=20 NACK supression message to the DS, which then forwards/relays this mes= sage=20 over the SSM to all receivers, right? 

 

M= y main=20 comment remains the same: you should at least incorporate the architecture = of=20 RAMS (where there can be several FT  colocated with the BRS,= =20 which are disjoint from the DS). In this case the FT/BRS should be able to= =20 provide a suppression indication to all receivers that report to this FT (w= hich=20 is a subset of all receivers that connect to the SSM), which means one shou= ld=20 not make use of the (original) SSM for providing the suppression=20 indication.  Your draft provides a possible solution for only a limite= d use=20 case, and not the most interesting one, IMO.  <= /P>

 

F= urther=20 down some responses to your answers below.

 

T= om

 

 

From:<= /B> Qin Wu=20 [mailto:sunseawq@huawei.com]
Sent: dinsdag 19 oktober 2010=20 5:04
To: Van Caenegem, Tom (Tom); avt@ietf.org
Subject:= Re:=20 [AVT] New Version Notification for=20 draft-wu-avt-retransmission-supression-rtp-04

Hi, Tom:

Thank for your comments, please see my reply=20 inline.

 

Regards!

-Qin

From: Van Cae= negem,=20 Tom (Tom)

To: avt@iet= f.org=20 ; Qin=20 Wu

Sent: Tuesday, October 19, 2010 12:08 AM

Subject: Re: [AVT] New Version Notification f= or=20 draft-wu-avt-retransmission-supression-rtp-04

 

Hi Qin,

 

I have some comments (look for TOM below) on the new= draft=20 version 4.

Thx for addressing them,

Tom

 

 

Section 2 Terminology

 Lo=
ss Detector:
 
      The Loss=
 Detector is one logical function which is used to detect=

 &nb=
sp;    the packet loss at the RTP layer and report it to the=
 distribution
      source.  The func=
tion of the loss reporter may be collocated with
   =    or integrated into the same entity.  In this case, for a = session
      defined as having a distribu=
tion source A, on ports n for the RTP
     =
; channel and k for the RTCP channel, the Loss Detector are
 &=
nbsp;    identified by an IP address of distribution source =
A on port k.
      The Loss Detector MAY a=
lso be implemented in one or more entities
    =
  different from the distribution source.
=
 The function of the=
 loss reporter may be collocated with
     =
; or integrated into the same entity.
TOM (1): ..same entity as wha=
t? i guess you mean the DS?
[Qin]: Your are right.  In this dr=
aft, the loss detector is just functionality of DS.  Furthermore we on=
ly consider the loss detector as part of feedback target within the distrib=
ution source.
Also this is just one example use case to explain how=
 feedback suppression works in SSM use case.
TOM (2): I do not unde=
rstand how you associate the port k to a loss detector.. what do you mean w=
ith that?
[Qin]:  Sorry for ambiguity of the description here.=
 It actually means that the loss reporter is part of feedback target and sh=
are the same address and port.
section 3
 = 
(..=
)
In order to detect packet loss before the receivers perceive it, =
one
   or more intermediate nodes are placed between the =
media source and
   receiver (e.g., Distribution server, =
MCU, RTP translator).  These
   intermediaries mon=
itor for packet loss upstream of themselves by
=
   checkin=
g RTP sequence numbers, just as receivers do.  Upon detecting
=
   (or suspecting) an upstream loss, the intermediary may send Fe=
edback
   Suppression message towards the receivers as de=
fined in this
   specification.

TOM (3) : ...based on the two above definitions= =20 ...is an intermediate node hence equal to&n= bsp;a "Loss detector"? =20

+ How does a Loss detector differ from an RTP=20 receiver?

Different from dedicated RTP receiver, the intermedi= ate=20 node does not depend on existing NACK message for Retransmission request = for=20 packet loss.

the intermediate node can create message by=20 itself.

 

Section 6.1

In order to avoid the forms of NACK=
 implosion described in section 1,
   the Loss Detector =
is introduced.  The Loss Detector detects and
<= PRE>   rep= orts packet loss, on both the upstream link and the downstream
&nbs=
p;  aggregate link.  How the loss detector SHOULD detect the pack=
et loss
   is beyond of scope of this document.  Whe=
n upstream link or
   downstream aggregate link packet lo=
ss occurs, the Loss Detector MAY
   inform distribution s=
ource of the detected packet loss using Feedback
   Suppr= ession messages.  In response, the distribution source either
=
   forwards packet loss suppression report received from Loss Det=
ector
   or creates a Feedback Suppression report and sen=
ds it to all the RTP
   receivers, over the multicast cha=
nnel.  This loss suppression report
   tells the rec=
eivers that the lost packet will either be forthcoming
  =
 from distribution source, or it irretrievably lost such that there is=

   nothing to be gained by the receiver sending a NACK to the=
 media
   source.  The distribution source then can =
(optionally) ask for the
   lost packets from the media s=
ource on behalf of all the RTP
   receivers.<=
/o:p>
TOM =
(4) : You probably do not want to have normative language in section 6.1, l=
ike "How the loss detector SHOULD (..)". 
[Qin]:Sorry, I can't get =
it.&n=
bsp;
TOM: this is really a detail. If you want to keep the =
sentence, you should e.g. say: "How the loss detector can detect the packet=
 loss...
 
 
TOM (5)=
 : It is pretty clear how a Loss detector will detect packet loss on its up=
stream link, I guess.
[Qin]: As I said above,  Loss detector i=
s just functionality of some Distribution sources.  Also what it said =
here in section 6.1 
is just one example use case.
TOM (6):=
  What is the rationale for a loss detector to send a Feedback suppres=
sion message to the DS.. why NOT a RTCP NACK FB?
[Qin]: As I explai=
ned in the last IETF presentaion,  this cause NACK scematics mismatch.=
 That's why many people in the last IETF meeeting suggest to create new RTC=
P message during presentation. 
 
TOM: As your assumption is that the loss reporter is part of the FT that i=
s part of the DS, then there is even no need to specify how the loss detect=
or 
reports the packet loss.  In the more generic case=
, it makes more sense to me that the loss reporter just uses a NACK (or a F=
IR) if it detects packet loss, sent towards its FT or to the DS if this one=
 hosts the FT that the loss detector reports to . It is then up to the FT o=
r the DS to decide whether this message triggers a NACK or FIR suppression =

indication to (s subset of) the receivers.  This supp=
ression indication does not necessarly require a new message format. A NACK=
/FIR  that is sent to a RTP receiver can be defined as a feedback supp=
ression indication. I do not see a good use case why NACKs from  recei=
vers  would be reflected back in e.g. SSM use case by DS or FT  t=
o all the connected receivers. 
If we define that a NACK/FI=
R  for a SSM may only be sent TOWARDS a RTP receiver, if this is for s=
uppression indication, there is no ambiguity possibly.   <=
o:p>
 
 
Section 6.1.1
I=
f there are multiple Loss Detectors looking at the same RTP stream,
   then the loss may be identified by more than one and those de=
tecting
   the loss will all send requests for the same p=
acket loss.  In this
   case, the distribution sourc=
e MUST filter the duplicated packet loss
   request out a=
nd only forward one copy of the RTCP Feedback report
   p=
acket from the first Loss Detector to the group impacted by packet
=
   loss.

  

  
TOM (7) : how will the DS send only a copy of the RT=
CP FB=20
  report packet to the group impacted by packet loss. Is this done over the=
 SSM?=20
  

  

  
 

  

  
[Qin]: Sorry, maybe I sould say 

  

  
"

  

  
Section 6.1.1

  

  
If there are multiple Distrbitution Source with the =
loss=20
  detection support looking at the same RTP stream.....

  

  
"

  

  
Yes,  in the SSM use case, DS send only a copy =
of the=20
  RTCP Feedback Suppression Report packet the group via=20
SSM.

  

  
 

  

  
In your example you seem to focus only on architectu=
res=20
  with a DS which also hosts the FT and the loss reporter.  There shou=
ld be=20
  sections covering cases where the DS is disjoint from the FT, with severa=
l FTs=20
  and also several loss reporters disjoint from the FT and the=20
  DS.

  

  
 

  

  
[Qin] I am not sure we need to address all the possi=
ble SSM=20
  use cases. In this draft, we just give some examples of SSM use=20
  case.

  

  
 

  

  
TOM (8) : what do you mean in above text with "RTCP =
FB=20
  report".. is that the suppression message you define in this=20
  draft?

  

  
 

  

  
[Qin]: Yes,  RTCP Feedback Suppression Report.=
=20
  

  

  
 

  

  
TOM (9) : In section  "6.1.2.  Distributio=
n=20
  Source Feedback Summary Model" it is not clear what your architecture loo=
ks=20
  like. You talk about multiple distribution sources.. whcih implies multip=
le=20
  SSMs.. Can you elaborate on that?

  

  
 

  

  
[Qin]:  The scenario we are talking about in&nb=
sp; the=20
  section 6.1.2, is to  allow multiple Distrbituion source betwee=
n=20
  media source and the receiver. I will look at the this case as one specia=
l SSM=20
  case. because  each of distrbituion source resides at the upstream=20
  direction or downstream direction of other distributions souces. Does it =
make=20
  sense? 

  

  
 

  

  
TOM:=20
  RFC 5760 only defines one DS for a given SSM. If you depart from that, yo=
u=20
  probably need to address and define this architecture in a better wa=
y in=20
  your draft. 

  

  
 

  

  
Tom (10) :  In section  6.3.  Multipo=
int=20
  Control Unit (MCU) use case,  typically an overlay of unicast is use=
d...=20
  will the Feedback suppression message be sent over unicast as well? If so=
,=20
  what is gain compared to just having each RTCP receiver providing each th=
eir=20
  NACK to the MCU, even in case of a packet loss impacting all=20
  receivers?

  

  
 

  

  
[Qin]: First The MCU case will not cause NACK Implos=
ion,=20
  instead, it may cause FIR implosion.

  

           &=
nbsp;=20
  Second, using Feedback suppression message can restrict the FIR message s=
ent=20
  from receivers behind MCU and liberate the media source from  F=
IR=20
  implosion. 

  

  
 

  

  
TOM:=20
  it is not important whether this is about FIR or NACK. My point is that i=
so=20
  having each receiver sending a NACK/FIR, you will now have to send to eac=
h=20
  receiver a NACK/FIR  suppression in the given scenario. There are no=
=20
  differences in terms of Bandwdith overhead or server load in the two case=
s, so=20
  why bother to send suppression messages?

  

  
 

  

  
 

  

  
Tom (11) : coming back to my previous comment on SDP=
=20
  description in this draft : if this draft defines a RTCP feedba=
ck=20
  suppression message, why is there need for a "announcement" in the SDP fo=
r the=20
  receivers, that indicates they may receive such feedback suppression=20
  messages?  If a receiver supports the message, it will =20
  simply act accordingly as described in the draft, no need to announc=
e=20
  that!.. 

  

  
 

  

  
[Qin]: Okay, I get your point. I would like to put t=
his as=20
  open issue, discuss it in the face to face IETF meeting.

  

  
 

  

  
Regards

  

  
Tom

  

  
 

  

  
 

  

  
 

  

  
 

  

   


--_000_EC3FD58E75D43A4F8807FDE0749175460E497311FRMRSSXCHMBSB1d_--

From magnus.westerlund@ericsson.com  Tue Oct 19 08:34:48 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589ED3A6891 for ; Tue, 19 Oct 2010 08:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.491
X-Spam-Level: 
X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmc4vgJYVPxZ for ; Tue, 19 Oct 2010 08:34:45 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 03CE93A688A for ; Tue, 19 Oct 2010 08:34:44 -0700 (PDT)
X-AuditID: c1b4fb39-b7b54ae000003464-51-4cbdbaef518a
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 45.94.13412.FEABDBC4; Tue, 19 Oct 2010 17:36:15 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Oct 2010 17:36:15 +0200
Received: from [147.214.183.82] ([147.214.183.82]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 19 Oct 2010 17:36:14 +0200
Message-ID: <4CBDBAEE.90307@ericsson.com>
Date: Tue, 19 Oct 2010 17:36:14 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Bob Briscoe 
References: <201008052251.o75Mp7BL005112@bagheera.jungle.bt.co.uk>
In-Reply-To: <201008052251.o75Mp7BL005112@bagheera.jungle.bt.co.uk>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 19 Oct 2010 15:36:14.0641 (UTC) FILETIME=[5D553A10:01CB6FA3]
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-ietf-avt-ecn-for-rtp@tools.ietf.org" , "avt@ietf.org" 
Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Oct 2010 15:34:48 -0000

Hi Bob,

I definitely see some points about what you write. I also think ECN for
RTP has made all effort it can to enable a future redefining of one of
the ECT values. As one of the ADs that was involved in chartering CONEX
I am pretty well aware of it. However, this is experimental work that
needs to prove its benefit and maybe more than anything else have a
deployment story. Based on this we have take a reasonable approach on
dealing with ECT(1).

I am the one that thought we should included the NONCE as a module in
the solution. I kind of agree that in the general case you simply have
to not support it to avoid it. In addition I agree that pushing TCP
flows out of the way is reasonably simple and does provide a benefit for
the app doing it. A lot of todays non-congestion controlled UDP based
real-time applications are based on doing exactly that. As long as you
are running at rates that are almost always supported you simply go grab
the space you need. Well, that work up to a certain limit and a certain
traffic mix. When sufficient many uncontrolled UDP flows share a
bottleneck you end up in heavy congestion. Fortunately most of these
flow are related to an actual human that will terminate that flow if it
is unusable.

I did perceive Nonce as mechanism some infrastructure devices may need.
Especially where there is incentive to lie and the traffic mix is RTP
heavy and have large flows. Take IPTV as an example. In those cases
there is a sender that desires to not over tax the infrastructure
because that brings down the quality of experience for several users.

However, I am fine with moving out the Nonce stuff into a separate
draft. I might come back to particular points later.

Cheers

Magnus



Bob Briscoe skrev 2010-08-06 00:41:
> Magnus, Ingemar, Colin, Piers, Ken,
> 
> Below are my main technical concerns with 
> draft-ietf-avt-ecn-for-rtp-02 as promised.
> I have used the line numbering here:
> 
> 
> T1/ Combining pkts
> T2/ ECN-IP-RTCP
> T3/ Anti-Cheating                       <<<---THIS EMAIL
> T4/ Logging Not-ECT fall-back
> T5/ Delivery %age ECT vs Not-ECT
> T6/ Pkt Reordering around session start
> 
> 
> T3a/ Nonce must be non-negotiable for a receiver
> -------------------
> The addition of ECN nonce support to RTP/RTCP adds considerable 
> complexity. In return we get protection against cheating in just one 
> rather contrived scenario - we have to assume the sender wants to 
> altruistically protect the network and other users against a cheating receiver.
> "
> 1204       The assumption about the senders acting on the behalf of the network
> 1205       may be reduced due to the nature of peer-to-peer use of 
> RTP.  Still a
> 1206       significant portion of RTP senders are infrastructure devices (for
> 1207       example, streaming media servers) that do have an interest in
> 1208       protecting both service quality and the network.
> "
> OK, perhaps not so contrived. We'll return to this in a second...
> 
> "
> 1208                                                         In addition, as
> 1209       real-time media is commonly sensitive to increased delay and packet
> 1210       loss, it will be in both media sender and receivers interest to
> 1211       minimise the number and duration of any congestion events as they
> 1212       will affect media quality.
> "
> "
> 1348       behavior.  We note that it appears counter-productive for a receiver
> 1349       to attempt to cheat as it most likely will have negative impact on
> 1350       its media quality.
> "
> Not so. Point to any evidence that cheating makes things worse for 
> yourself. This argument is one of those fallacies that keeps hanging 
> around from the 1990s. If others are responding to congestion, I get 
> higher rate and/or better quality media by not responding to 
> congestion. And on the current Internet most other traffic is 
> responding to congestion (TCP or BitTorrent uTP), so I can take 
> advantage of that.
> 
> Let's return to the infrastructure devices argument, which seems more 
> plausible...
> "
> 619        o  The "nonce" parameter may be used to signal whether the ECN nonce
> 620           is to be used in the session.  This parameter takes two values;
> 621           "nonce=1" for nonce proposed or shall be used, and 
> "nonce=0" for622             no nonce.  If this parameter is not 
> specified, the default is no
> 623           nonce."A receiver that intends to cheat will just claim 
> it does not support the nonce. Therefore, for any sender to have the 
> option to use the nonce, ideally it should have always been mandatory 
> for all receivers to implement nonce support.
> 
> However, many RTP receiver implementations already exist without ECN 
> support, let alone nonce support. Therefore any receiver that wishes 
> to cheat can just hide among the crowd who do not include or 
> recognise an "a=ecn-capable-rtp" attribute at all.
> 
> A sender could punish receivers that do not support the nonce, for 
> instance with a lower rate. But that makes initial deployment hard, 
> as few receivers support it to start with, so you cannot punish 
> nearly everyone who says they don't support ECN just in case they are lying.
> 
> Perhaps instead, a sender could reward receivers that support the 
> nonce. For instance the reward could be a higher rate. But higher 
> than what? Presumably higher than the rate that is 'fair' to everyone 
> else on the network.
> 
> But, let's go back over logic so far. A sender only uses the ECN 
> nonce if it is trying to altruistically protect the interests of 
> others on the network. But in order to create the necessary 
> incentives for receivers to use the nonce, a sender has to first take 
> more rate from others than its 'fair' entitlement, thus negating its 
> intended altruism.
> 
> If a bloke approached you saying, "Lend me $100 so I can reward any 
> thieves who can prove they have not stolen from you," would you give 
> the bloke $100?
> 
> T3b/ Avoid precluding future uses of the experimental ECT(1) codepoint.
> -------------------
> The IETF has just chartered a new working group on Congestion 
> Exposure (ConEx) as a way to more comprehensively handle cheating 
> with respect to congestion: ConEx is a proposed change to IP to give 
> a sender a field in which it can expose expected congestion to the 
> network. Those working on ConEx claim networks can negate any gain a 
> receiver might get from suppressing congestion feedback as well as 
> negating any gain a sender might get from suppressing congestion 
> exposure back to the network. Once truthful congestion is exposed to 
> the network by the sender, the network can encourage and ultimately 
> force senders to respond to congestion.
> 
> The aim is to allow and encourage a whole range of responses to 
> congestion, not to force a particular response (ie. not just TCP). So 
> low bit-rate inelastic sessions will typically be able to be 
> unresponsive to congestion, while high bit-rate inelastic sessions 
> would come under more pressure to be adaptive.
> 
> This 6pp paper describes how ConEx could be used to encourage one 
> site's elastic flows to compensate for its inelastic flows, but 
> ultimately, if high congestion persists, making even the inelastic 
> flows adapt or stop.
>          "Policing Freedom to Use the Internet Resource Pool"
>          
> 
> ConEx is currently chartered to produce an experimental protocol, so 
> we cannot yet know whether it will be successful in its goals (I led 
> the research behind ConEx, so I can only say that so far it has been 
> robust to all the attacks the research community has thrown at it).
> 
> The ECN nonce RFC is also experimental. Use of the nonce has been 
> specified in TCP and DCCP, but not implemented as far as anyone knows.
> 
> ConEx might well need to take over the ECT(1) codepoint that is 
> currently assigned to the ECN nonce experiment.
> 
> Therefore, I suggest the RTP-ECN spec suspends judgement between the 
> two approaches. Rather than building use of ECT(1) into RTP-ECN by 
> default, I suggest RTP-ECN is specified in two stages:
> i) without committing to either anti-cheating approach
> ii) an additional option (in a separate I-D) comitting to either the 
> ECN Nonce or ConEx
> 
> The downside is that this will create additional deployment options. 
> But the RTP-ECN draft already implies that implementation of nonce 
> support is optional.
> 
> If an RTP-ECN implementation does not use the ECN nonce for 
> anti-cheating, we need to ensure it will not use the ECT(1) codepoint 
> at all. Otherwise this would unnecessarily preclude using ECT(1) for 
> ConEx, or for some other purpose.
> 
> There is a considerable amount of text woven into the RTP-ECN draft 
> around using ECT(1) and the nonce. If you agree with this suggestion, 
> I can mark up which text needs removing.
> 
> T3c/ Misbehaving end-points
> -------------------
> "
> 1968                                                      It is far 
> from certain
> 1969          that a receiver would be able to get a significant 
> larger share of
> 1970          the resources.  That assumes a high enough level of aggregation
> 1971          that there are flows to acquire shares from.
> "
> Don't agree. It's completely certain that an unresponsive receiver 
> (or sender) can get a significantly larger share of the resources, 
> whether or not it uses ECN. Just try it. Send an unresponsive flow 
> along with some responsive flows (e.g TCP) and the TCPs reduce their 
> rates while the unresponsive flow gets whatever rate it chooses to send at.
> "
> 1971                                                        The risk 
> of cheating
> 1972          is that failure to react to congestion results in packet loss and
> 1973          increased path delay.
> "
> If a cheating unresponsive flow leaves N times less bandwidth 
> available than it would have done were it responsive, it will force 
> long-running TCP flows to each reduce their bit-rate by N times, 
> making their transfers last N times longer.
> These TCP flows will raise the ECN marking probability by about N^2 
> times (even if the TCP flows are not ECN-capable). So the marking 
> /rate/ will increase by N times. Any competing adaptive real-time 
> flows will reduce their rates in response to the increased 
> loss/marking probability as well.
> 
> If the bottleneck queue is ECN-capable the cheating flow won't care 
> about a higher ECN marking rate, as its own risk of loss will still 
> be extremely low if it is sending ECT packets.
> 
> Considering any short flows competing for the same bottleneck, the 
> amount of congestion they cause by overshooting as each leaves TCP 
> slow start should reduce by about N times. Therefore, by hogging more 
> capacity the unresponsive flow also reduces the risk that it will 
> suffer any losses from other TCPs overshooting slow start.
> If the bottleneck queue is not ECN-capable, delay to the cheating 
> flow should not be significantly increased by its own cheating, 
> whether the queue is drop-tail or AQM."
> 1973                                 To mitigate the risk of cheating receivers
> 1974          the solution include ECN-Nonce that makes it probabilistically
> 1975          unlikely that a receiver can cheat for more than a few packets
> 1976          before being found out.
> "
> See earlier point about the a nonce sender relying on a cheating 
> receiver choosing to volunteer to support the nonce. I really would 
> rather Internet Drafts stopped making unsubstantiated references to 
> the ECN nonce as if it solves the problem of a cheating receiver.
> 
> "
> 1979       Receivers misbehaving:  A receiver may
> 1980                                                         [...]  simple
> 1981          provide invalid ECN-nonce values.
> "
> This is not a workable attack. If a receiver provides invalid 
> ECN-nonce values, the sender will consider it has failed the nonce 
> test and be entitled to stop sending to it.
> 
> "
> 1979       Receivers misbehaving:  A receiver may prevent the usage 
> of ECN in an
> 1980          RTP session by reporting itself as non ECN capable [...]
> 1981                                             Thus forcing the 
> sender to turn
> 1982          off usage of ECN.  In a point-to-point scenario there is little
> 1983          incentive to do this as it will only affect the receiver.  Thus
> 1984          failing to utilise an optimisation.
> "
> Unlikely to be true. ECN provides very little benefit - it is a tiny 
> optimisation compared to the potential benefit to a receiver from not 
> reporting congestion events, which might allow it to receive at the 
> highest codec rate. Having just above normal loss levels might be a 
> little worse than no losses by using ECN. But getting a high codec 
> rate will surely be worth it, while other r-t flows will have to run 
> at the lowest codec, or other TCP flows will have to reduce to 
> whatever bandwidth is left.
> 
> "
> 1965       Receivers cheating
> 1979       Receivers misbehaving:
> 1997       Misbehaving Senders:
> "
> In all these cases, ConEx is intended to solve the problem, 
> particularly when ECN is used, whether with RTP or any other transport.
> 
> Cheers
> 
> Bob
> 
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design  
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

From Even.roni@huawei.com  Tue Oct 19 09:02:38 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B93E3A68A0 for ; Tue, 19 Oct 2010 09:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.021
X-Spam-Level: 
X-Spam-Status: No, score=-98.021 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYUkA8Usskv0 for ; Tue, 19 Oct 2010 09:02:35 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6499A3A6891 for ; Tue, 19 Oct 2010 09:02:34 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAJ00KJIOMGDF@szxga04-in.huawei.com> for avt@ietf.org; Wed, 20 Oct 2010 00:03:52 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAJ00AT0OMGU2@szxga04-in.huawei.com> for avt@ietf.org; Wed, 20 Oct 2010 00:03:52 +0800 (CST)
Received: from windows8d787f9 (bzq-79-177-11-74.red.bezeqint.net [79.177.11.74]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0LAJ00G36OM2ND@szxml01-in.huawei.com>; Wed, 20 Oct 2010 00:03:52 +0800 (CST)
Date: Tue, 19 Oct 2010 18:00:33 +0200
From: Roni Even 
In-reply-to: 
To: "'Van Caenegem, Tom (Tom)'" , 'Qin Wu' , avt@ietf.org
Message-id: <042f01cb6fa6$c800a1d0$5801e570$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_wTCxygx/L8SHrumIFpXDmw)"
Content-language: en-us
Thread-index: ActvOmJJMyLM228TSZyF5vja0vwmiQAITiTAAA/gm0AAAIsbMAABhUEw
References:  <048601cb6f3a$4a973180$30298a0a@china.huawei.com>  <041501cb6f9c$5c4db950$14e92bf0$%roni@huawei.com> 
Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Oct 2010 16:02:38 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_wTCxygx/L8SHrumIFpXDmw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Tom,

In the current RAMS there is no way for the BRS to send a suppression
indication , the only available way is in the main SSM stream. I think that
such BRS will be reporting nodes to the DS in the simple case. Are you
suggesting that we define a new SSM session that will be initiated by the
BRS. I think this will make more sense if we also address the retransmission
support you described since the SSM session will serve for the
retransmission.

Currently this part is not in scope but we may ask the WG if they want to
add this specific scenario

 

Roni Even

 

From: Van Caenegem, Tom (Tom) [mailto:tom.van_caenegem@alcatel-lucent.com] 
Sent: Tuesday, October 19, 2010 5:31 PM
To: Roni Even; 'Qin Wu'; avt@ietf.org
Subject: RE: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04

 

Hi Roni,

 

In the typical RAMS architecture, the BRS will receive the SSM stream from
the DS. If there are several BRS-es, there may be just one BRS that detects
packet loss on its upstream link, but the others will perhaps not, as the
packet loss took place on SSM tree branch that does not impact the other
BRSes. In that case those RTP receivers associated to the other BRS-es in
general will not be impacted and do not need to receive the suppression
indication, while the one BRS that did sense the packet loss should probably
best send a suppression indication (although there is a chance that only
this BRS is impacted by packet loss, and not a single RTP receiver in the
field reporting to this BRS/FT... this all depends on the considered
topologies). 

 

As a BRS is 1-to-1 associated with a FT, this calls for consideration of
architectures with (multiple) disjoint FT (and associated BRS in RAMS
applications)  in the suppression draft. Such disjoint FT/BRS in general
cannot act as so-called "intermediate nodes" or "translators" because they
are not on the direct SSM path between the DS and the RTP receivers. 

 

Another aspect I want to highlight is that feedback suppression is closely
aligned with retransmission. In the case described above, the one BRS that
detected packet loss on its upstream link, may try to recover the missing
packet (outside the scope of the draft) and retransmit over multicast to the
receivers that report to the FT. This retransmission towards the receivers
is also outside the current scope of the current draft, but the two are
somehow linked.  In DVB IPTV, we introduced dedicated SSMs sourced by the
BRS for sending NACK suppression and the (optional) retransmission. In the
considered scenario, having a DS sending a missing packet -reported by a FT
downstream in the SSM tree- over the original SSM is not a good approach
IMO, as it results in general in unnecessary retransmissions for most
receivers.

 

Hope this clarifies.

 

Tom

 

  _____  

From: Roni Even [mailto:Even.roni@huawei.com] 
Sent: dinsdag 19 oktober 2010 16:46
To: Van Caenegem, Tom (Tom); 'Qin Wu'; avt@ietf.org
Subject: RE: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04

Hi Tom,

I want to clarify your example since I am not sure what is special here. The
BRS sends separate unicast streams to each participant so there is reason
for suppression on these unicast streams. As for the primary multicast
stream from the DS it goes to all receivers. Now if the BRS identify packet
loss on the primary stream it should send suppression indication to all
members of the multicast group regardless to which FT they report.

Can you clarify

 

Roni Even

 

 

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Van
Caenegem, Tom (Tom)
Sent: Tuesday, October 19, 2010 10:27 AM
To: Qin Wu; avt@ietf.org
Subject: Re: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04

 

Hi Qin,

 

Thank you for your reply.

 

Reading your responses,you seem to focus really on the SSM  case with an
architecture where the single DS (there can be only one DS per SSM) hosts
the sole feedback target, which also hosts the loss detector function. My
interpretation is also that in your draft the loss detector sends the FIR or
NACK supression message to the DS, which then forwards/relays this message
over the SSM to all receivers, right?  

 

My main comment remains the same: you should at least incorporate the
architecture of RAMS (where there can be several FT  colocated with the BRS,
which are disjoint from the DS). In this case the FT/BRS should be able to
provide a suppression indication to all receivers that report to this FT
(which is a subset of all receivers that connect to the SSM), which means
one should not make use of the (original) SSM for providing the suppression
indication.  Your draft provides a possible solution for only a limited use
case, and not the most interesting one, IMO.  

 

Further down some responses to your answers below.

 

Tom

 

 

  _____  

From: Qin Wu [mailto:sunseawq@huawei.com] 
Sent: dinsdag 19 oktober 2010 5:04
To: Van Caenegem, Tom (Tom); avt@ietf.org
Subject: Re: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04

Hi, Tom:

Thank for your comments, please see my reply inline.

 

Regards!

-Qin

----- Original Message ----- 

From:   Van Caenegem, Tom (Tom) 

To:   avt@ietf.org ;   Qin
Wu 

Sent: Tuesday, October 19, 2010 12:08 AM

Subject: Re: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04

 

Hi Qin,

 

I have some comments (look for TOM below) on the new draft version 4.

Thx for addressing them,

Tom

 

 

Section 2 Terminology

 Loss Detector:
 
      The Loss Detector is one logical function which is used to detect
      the packet loss at the RTP layer and report it to the distribution
      source.  The function of the loss reporter may be collocated with
      or integrated into the same entity.  In this case, for a session
      defined as having a distribution source A, on ports n for the RTP
      channel and k for the RTCP channel, the Loss Detector are
      identified by an IP address of distribution source A on port k.
      The Loss Detector MAY also be implemented in one or more entities
      different from the distribution source.
 The function of the loss reporter may be collocated with
      or integrated into the same entity.
TOM (1): ..same entity as what? i guess you mean the DS?
[Qin]: Your are right.  In this draft, the loss detector is just
functionality of DS.  Furthermore we only consider the loss detector as part
of feedback target within the distribution source.
Also this is just one example use case to explain how feedback suppression
works in SSM use case.
TOM (2): I do not understand how you associate the port k to a loss
detector.. what do you mean with that?
[Qin]:  Sorry for ambiguity of the description here. It actually means that
the loss reporter is part of feedback target and share the same address and
port.
section 3
 
(..)
In order to detect packet loss before the receivers perceive it, one
   or more intermediate nodes are placed between the media source and
   receiver (e.g., Distribution server, MCU, RTP translator).  These
   intermediaries monitor for packet loss upstream of themselves by
   checking RTP sequence numbers, just as receivers do.  Upon detecting
   (or suspecting) an upstream loss, the intermediary may send Feedback
   Suppression message towards the receivers as defined in this
   specification.

TOM (3) : ...based on the two above definitions ...is an intermediate node
hence equal to a "Loss detector"?  

+ How does a Loss detector differ from an RTP receiver?

[Qin]: The loss detector is just one functionality of Distribution Source in
the SSM use case.

Maybe we should interpret it as "Loss detection functionality". How the
packet loss is detected is out of scope of this document.

Different from dedicated RTP receiver, the intermediate node does not depend
on existing NACK message for Retransmission request for packet loss.

the intermediate node can create message by itself.

 

Section 6.1

In order to avoid the forms of NACK implosion described in section 1,
   the Loss Detector is introduced.  The Loss Detector detects and
   reports packet loss, on both the upstream link and the downstream
   aggregate link.  How the loss detector SHOULD detect the packet loss
   is beyond of scope of this document.  When upstream link or
   downstream aggregate link packet loss occurs, the Loss Detector MAY
   inform distribution source of the detected packet loss using Feedback
   Suppression messages.  In response, the distribution source either
   forwards packet loss suppression report received from Loss Detector
   or creates a Feedback Suppression report and sends it to all the RTP
   receivers, over the multicast channel.  This loss suppression report
   tells the receivers that the lost packet will either be forthcoming
   from distribution source, or it irretrievably lost such that there is
   nothing to be gained by the receiver sending a NACK to the media
   source.  The distribution source then can (optionally) ask for the
   lost packets from the media source on behalf of all the RTP
   receivers.
TOM (4) : You probably do not want to have normative language in section
6.1, like "How the loss detector SHOULD (..)". 
[Qin]:Sorry, I can't get it. 
TOM: this is really a detail. If you want to keep the sentence, you should
e.g. say: "How the loss detector can detect the packet loss...
 
 
TOM (5) : It is pretty clear how a Loss detector will detect packet loss on
its upstream link, I guess.
[Qin]: As I said above,  Loss detector is just functionality of some
Distribution sources.  Also what it said here in section 6.1 
is just one example use case.
TOM (6):  What is the rationale for a loss detector to send a Feedback
suppression message to the DS.. why NOT a RTCP NACK FB?
[Qin]: As I explained in the last IETF presentaion,  this cause NACK
scematics mismatch. That's why many people in the last IETF meeeting suggest
to create new RTCP message during presentation. 
 
TOM: As your assumption is that the loss reporter is part of the FT that is
part of the DS, then there is even no need to specify how the loss detector 
reports the packet loss.  In the more generic case, it makes more sense to
me that the loss reporter just uses a NACK (or a FIR) if it detects packet
loss, sent towards its FT or to the DS if this one hosts the FT that the
loss detector reports to . It is then up to the FT or the DS to decide
whether this message triggers a NACK or FIR suppression 
indication to (s subset of) the receivers.  This suppression indication does
not necessarly require a new message format. A NACK/FIR  that is sent to a
RTP receiver can be defined as a feedback suppression indication. I do not
see a good use case why NACKs from  receivers  would be reflected back in
e.g. SSM use case by DS or FT  to all the connected receivers. 
If we define that a NACK/FIR  for a SSM may only be sent TOWARDS a RTP
receiver, if this is for suppression indication, there is no ambiguity
possibly.   
 
 
Section 6.1.1
If there are multiple Loss Detectors looking at the same RTP stream,
   then the loss may be identified by more than one and those detecting
   the loss will all send requests for the same packet loss.  In this
   case, the distribution source MUST filter the duplicated packet loss
   request out and only forward one copy of the RTCP Feedback report
   packet from the first Loss Detector to the group impacted by packet
   loss.

TOM (7) : how will the DS send only a copy of the RTCP FB report packet to
the group impacted by packet loss. Is this done over the SSM? 

 

[Qin]: Sorry, maybe I sould say 

"

Section 6.1.1

If there are multiple Distrbitution Source with the loss detection support
looking at the same RTP stream.....

"

Yes,  in the SSM use case, DS send only a copy of the RTCP Feedback
Suppression Report packet the group via SSM.

 

In your example you seem to focus only on architectures with a DS which also
hosts the FT and the loss reporter.  There should be sections covering cases
where the DS is disjoint from the FT, with several FTs and also several loss
reporters disjoint from the FT and the DS.

 

[Qin] I am not sure we need to address all the possible SSM use cases. In
this draft, we just give some examples of SSM use case.

 

TOM (8) : what do you mean in above text with "RTCP FB report".. is that the
suppression message you define in this draft?

 

[Qin]: Yes,  RTCP Feedback Suppression Report. 

 

TOM (9) : In section  "6.1.2.  Distribution Source Feedback Summary Model"
it is not clear what your architecture looks like. You talk about multiple
distribution sources.. whcih implies multiple SSMs.. Can you elaborate on
that?

 

[Qin]:  The scenario we are talking about in  the section 6.1.2, is to
allow multiple Distrbituion source between media source and the receiver. I
will look at the this case as one special SSM case. because  each of
distrbituion source resides at the upstream direction or downstream
direction of other distributions souces. Does it make sense? 

 

TOM: RFC 5760 only defines one DS for a given SSM. If you depart from that,
you probably need to address and define this architecture in a better way in
your draft. 

 

Tom (10) :  In section  6.3.  Multipoint Control Unit (MCU) use case,
typically an overlay of unicast is used... will the Feedback suppression
message be sent over unicast as well? If so, what is gain compared to just
having each RTCP receiver providing each their NACK to the MCU, even in case
of a packet loss impacting all receivers?

 

[Qin]: First The MCU case will not cause NACK Implosion, instead, it may
cause FIR implosion.

           Second, using Feedback suppression message can restrict the FIR
message sent from receivers behind MCU and liberate the media source from
FIR implosion. 

 

TOM: it is not important whether this is about FIR or NACK. My point is that
iso having each receiver sending a NACK/FIR, you will now have to send to
each receiver a NACK/FIR  suppression in the given scenario. There are no
differences in terms of Bandwdith overhead or server load in the two cases,
so why bother to send suppression messages?

 

 

Tom (11) : coming back to my previous comment on SDP description in this
draft : if this draft defines a RTCP feedback suppression message, why is
there need for a "announcement" in the SDP for the receivers, that indicates
they may receive such feedback suppression messages?  If a receiver supports
the message, it will  simply act accordingly as described in the draft, no
need to announce that!.. 

 

[Qin]: Okay, I get your point. I would like to put this as open issue,
discuss it in the face to face IETF meeting.

 

Regards

Tom

 

 

 

 

 


--Boundary_(ID_wTCxygx/L8SHrumIFpXDmw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

















Hi Tom,



In the current RAMS there is no way for the BRS to send a
suppression indication , the only available way is in the main SSM stream. I
think that such BRS will be reporting nodes to the DS in the simple case. Are
you suggesting that we define a new SSM session that will be initiated by the
BRS. I think this will make more sense if we also address the retransmission
support you described since the SSM session will serve for the retransmission.



Currently this part is not in scope but we may ask the WG if
they want to add this specific scenario



 



Roni Even



 












From: Van Caenegem, Tom
(Tom) [mailto:tom.van_caenegem@alcatel-lucent.com] 

Sent: Tuesday, October 19, 2010 5:31 PM

To: Roni Even; 'Qin Wu'; avt@ietf.org

Subject: RE: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04









 



Hi Roni,



 



In the typical RAMS architecture, the BRS will receive the SSM
stream from the DS. If there are several BRS-es, there may be just one BRS that
detects packet loss on its upstream link, but the others will perhaps not, as
the packet loss took place on SSM tree branch that does not impact the
other BRSes. In that case those RTP receivers associated to the other BRS-es in
general will not be impacted and do not need to receive the suppression
indication, while the one BRS that did sense the packet loss should probably
best send a suppression indication (although there is a chance that
only this BRS is impacted by packet loss, and not a single RTP receiver in
the field reporting to this BRS/FT... this all depends on the considered
topologies). 



 



As a BRS is 1-to-1 associated with a FT, this calls for
consideration of architectures with (multiple) disjoint FT (and associated BRS
in RAMS applications)  in the suppression draft. Such disjoint FT/BRS in
general cannot act as so-called "intermediate nodes" or "translators"
because they are not on the direct SSM path between the DS and the RTP
receivers. 



 



Another aspect I want to highlight is that feedback suppression is
closely aligned with retransmission. In the case described above, the one BRS
that detected packet loss on its upstream link, may try to recover the missing
packet (outside the scope of the draft) and retransmit over multicast to the
receivers that report to the FT. This retransmission towards the receivers is
also outside the current scope of the current draft, but the two are somehow
linked.  In DVB IPTV, we introduced dedicated SSMs sourced by the BRS
for sending NACK suppression and the (optional) retransmission. In
the considered scenario, having a DS sending a missing packet -reported by a FT
downstream in the SSM tree- over the original SSM is not a good approach
IMO, as it results in general in unnecessary retransmissions for most
receivers.



 



Hope this clarifies.



 



Tom



 












From: Roni Even [mailto:Even.roni@huawei.com] 

Sent: dinsdag 19 oktober 2010 16:46

To: Van Caenegem, Tom (Tom); 'Qin Wu'; avt@ietf.org

Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04



Hi Tom,



I want to clarify your example since I am not sure what is
special here. The BRS sends separate unicast streams to each participant so
there is reason for suppression on these unicast streams. As for the primary
multicast stream from the DS it goes to all receivers. Now if the BRS identify
packet loss on the primary stream it should send suppression indication to all
members of the multicast group regardless to which FT they report.



Can you clarify



 



Roni Even



 



 



 












From:
avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Van
Caenegem, Tom (Tom)

Sent: Tuesday, October 19, 2010 10:27 AM

To: Qin Wu; avt@ietf.org

Subject: Re: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04









 



Hi Qin,



 



Thank you for your reply.



 



Reading your responses,you seem to focus really on the SSM 
case with an architecture where the single DS (there can be only one DS per
SSM) hosts the sole feedback target, which also hosts the loss detector function.
My interpretation is also that in your draft the loss detector sends the FIR or
NACK supression message to the DS, which then forwards/relays this message
over the SSM to all receivers, right?  



 



My main comment remains the same: you should at least incorporate
the architecture of RAMS (where there can be several FT 
colocated with the BRS, which are disjoint from the DS). In this case the
FT/BRS should be able to provide a suppression indication to all receivers that
report to this FT (which is a subset of all receivers that connect to the SSM),
which means one should not make use of the (original) SSM for providing the
suppression indication.  Your draft provides a possible solution for only
a limited use case, and not the most interesting one, IMO.  



 



Further down some responses to your answers below.



 



Tom



 



 












From: Qin Wu [mailto:sunseawq@huawei.com] 

Sent: dinsdag 19 oktober 2010 5:04

To: Van Caenegem, Tom (Tom); avt@ietf.org

Subject: Re: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04






Hi, Tom:









Thank for your comments, please see my reply inline.









 









Regards!









-Qin












----- Original Message ----- 













Sent: Tuesday, October 19, 2010 12:08 AM









Subject: Re: [AVT] New Version Notification for
draft-wu-avt-retransmission-supression-rtp-04









 









Hi Qin,









 









I have some comments (look for TOM below) on the new draft
version 4.









Thx for addressing them,









Tom









 









 









Section 2 Terminology






 Loss Detector:
 
      The Loss Detector is one logical function which is used to detect
      the packet loss at the RTP layer and report it to the distribution
      source.  The function of the loss reporter may be collocated with
      or integrated into the same entity.  In this case, for a session
      defined as having a distribution source A, on ports n for the RTP
      channel and k for the RTCP channel, the Loss Detector are
      identified by an IP address of distribution source A on port k.
      The Loss Detector MAY also be implemented in one or more entities
      different from the distribution source.
 The function of the loss reporter may be collocated with
      or integrated into the same entity.
TOM (1): ..same entity as what? i guess you mean the DS?
[Qin]: Your are right.  In this draft, the loss detector is just functionality of DS.  Furthermore we only consider the loss detector as part of feedback target within the distribution source.
Also this is just one example use case to explain how feedback suppression works in SSM use case.
TOM (2): I do not understand how you associate the port k to a loss detector.. what do you mean with that?
[Qin]:  Sorry for ambiguity of the description here. It actually means that the loss reporter is part of feedback target and share the same address and port.
section 3
 
(..)
In order to detect packet loss before the receivers perceive it, one
   or more intermediate nodes are placed between the media source and
   receiver (e.g., Distribution server, MCU, RTP translator).  These
   intermediaries monitor for packet loss upstream of themselves by
   checking RTP sequence numbers, just as receivers do.  Upon detecting
   (or suspecting) an upstream loss, the intermediary may send Feedback
   Suppression message towards the receivers as defined in this
   specification.






TOM (3) : ...based on the two above definitions
...is an intermediate node hence equal to a "Loss detector"? 










+ How does a Loss detector differ from an RTP receiver?















[Qin]: The loss detector is just one functionality of
Distribution Source in the SSM use case.









Maybe we should interpret it as "Loss detection
functionality". How the packet loss is detected is out of scope of this
document.









Different from dedicated RTP receiver, the intermediate node
does not depend on existing NACK message for Retransmission request for packet
loss.









the intermediate node can create message by itself.









 









Section 6.1






In order to avoid the forms of NACK implosion described in section 1,
   the Loss Detector is introduced.  The Loss Detector detects and
   reports packet loss, on both the upstream link and the downstream
   aggregate link.  How the loss detector SHOULD detect the packet loss
   is beyond of scope of this document.  When upstream link or
   downstream aggregate link packet loss occurs, the Loss Detector MAY
   inform distribution source of the detected packet loss using Feedback
   Suppression messages.  In response, the distribution source either
   forwards packet loss suppression report received from Loss Detector
   or creates a Feedback Suppression report and sends it to all the RTP
   receivers, over the multicast channel.  This loss suppression report
   tells the receivers that the lost packet will either be forthcoming
   from distribution source, or it irretrievably lost such that there is
   nothing to be gained by the receiver sending a NACK to the media
   source.  The distribution source then can (optionally) ask for the
   lost packets from the media source on behalf of all the RTP
   receivers.
TOM (4) : You probably do not want to have normative language in section 6.1, like "How the loss detector SHOULD (..)". 
[Qin]:Sorry, I can't get it. 
TOM: this is really a detail. If you want to keep the sentence, you should e.g. say: "How the loss detector can detect the packet loss...
 
 
TOM (5) : It is pretty clear how a Loss detector will detect packet loss on its upstream link, I guess.
[Qin]: As I said above,  Loss detector is just functionality of some Distribution sources.  Also what it said here in section 6.1 
is just one example use case.
TOM (6):  What is the rationale for a loss detector to send a Feedback suppression message to the DS.. why NOT a RTCP NACK FB?
[Qin]: As I explained in the last IETF presentaion,  this cause NACK scematics mismatch. That's why many people in the last IETF meeeting suggest to create new RTCP message during presentation. 
 
TOM: As your assumption is that the loss reporter is part of the FT that is part of the DS, then there is even no need to specify how the loss detector 
reports the packet loss.  In the more generic case, it makes more sense to me that the loss reporter just uses a NACK (or a FIR) if it detects packet loss, sent towards its FT or to the DS if this one hosts the FT that the loss detector reports to . It is then up to the FT or the DS to decide whether this message triggers a NACK or FIR suppression 
indication to (s subset of) the receivers.  This suppression indication does not necessarly require a new message format. A NACK/FIR  that is sent to a RTP receiver can be defined as a feedback suppression indication. I do not see a good use case why NACKs from  receivers  would be reflected back in e.g. SSM use case by DS or FT  to all the connected receivers. 
If we define that a NACK/FIR  for a SSM may only be sent TOWARDS a RTP receiver, if this is for suppression indication, there is no ambiguity possibly.   
 
 
Section 6.1.1
If there are multiple Loss Detectors looking at the same RTP stream,
   then the loss may be identified by more than one and those detecting
   the loss will all send requests for the same packet loss.  In this
   case, the distribution source MUST filter the duplicated packet loss
   request out and only forward one copy of the RTCP Feedback report
   packet from the first Loss Detector to the group impacted by packet
   loss.






TOM (7) : how will the DS send only a copy of the RTCP FB
report packet to the group impacted by packet loss. Is this done over the SSM? 









 









[Qin]: Sorry, maybe I sould say 









"









Section 6.1.1









If there are multiple Distrbitution Source with the loss
detection support looking at the same RTP stream.....









"









Yes,  in the SSM use case, DS send only a copy of the
RTCP Feedback Suppression Report packet the group via SSM.









 









In your example you seem to focus only on architectures with
a DS which also hosts the FT and the loss reporter.  There should be
sections covering cases where the DS is disjoint from the FT, with several FTs
and also several loss reporters disjoint from the FT and the DS.









 









[Qin] I am not sure we need to address all the possible SSM
use cases. In this draft, we just give some examples of SSM use case.









 









TOM (8) : what do you mean in above text with "RTCP FB
report".. is that the suppression message you define in this draft?









 









[Qin]: Yes,  RTCP Feedback Suppression Report. 









 









TOM (9) : In section  "6.1.2.  Distribution Source
Feedback Summary Model" it is not clear what your architecture looks like.
You talk about multiple distribution sources.. whcih implies multiple SSMs..
Can you elaborate on that?









 









[Qin]:  The scenario we are talking about in  the
section 6.1.2, is to  allow multiple Distrbituion source between
media source and the receiver. I will look at the this case as one special SSM
case. because  each of distrbituion source resides at the upstream
direction or downstream direction of other distributions souces. Does it make
sense? 









 









TOM: RFC 5760 only defines one DS for a given SSM. If you depart
from that, you probably need to address and define this architecture in a
better way in your draft. 









 









Tom (10) :  In section  6.3.  Multipoint
Control Unit (MCU) use case,  typically an overlay of unicast is used...
will the Feedback suppression message be sent over unicast as well? If so, what
is gain compared to just having each RTCP receiver providing each their NACK to
the MCU, even in case of a packet loss impacting all receivers?









 









[Qin]: First The MCU case will not cause NACK Implosion,
instead, it may cause FIR implosion.









          
Second, using Feedback suppression message can restrict the FIR message sent
from receivers behind MCU and liberate the media source from  FIR
implosion. 









 









TOM: it is not important whether this is about FIR or NACK. My
point is that iso having each receiver sending a NACK/FIR, you will now have to
send to each receiver a NACK/FIR  suppression in the given scenario. There
are no differences in terms of Bandwdith overhead or server load in the two
cases, so why bother to send suppression messages?









 









 









Tom (11) : coming back to my previous comment on SDP
description in this draft : if this draft defines a RTCP feedback
suppression message, why is there need for a "announcement" in the
SDP for the receivers, that indicates they may receive such feedback
suppression messages?  If a receiver supports the message, it will 
simply act accordingly as described in the draft, no need to announce
that!.. 









 









[Qin]: Okay, I get your point. I would like to put this as
open issue, discuss it in the face to face IETF meeting.









 









Regards









Tom









 









 









 









 









 





















--Boundary_(ID_wTCxygx/L8SHrumIFpXDmw)--

From csp@csperkins.org  Tue Oct 19 14:52:49 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457543A6860 for ; Tue, 19 Oct 2010 14:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.95
X-Spam-Level: 
X-Spam-Status: No, score=-101.95 tagged_above=-999 required=5 tests=[AWL=-1.649, BAYES_00=-2.599, FRT_MEETING=2.697, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00wBPNrDupOR for ; Tue, 19 Oct 2010 14:52:45 -0700 (PDT)
Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 9A6473A67B8 for ; Tue, 19 Oct 2010 14:52:44 -0700 (PDT)
Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.22]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P8K8L-0001pp-aD; Tue, 19 Oct 2010 21:54:15 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary=Apple-Mail-233--19594483
From: Colin Perkins 
In-Reply-To: <042f01cb6fa6$c800a1d0$5801e570$%roni@huawei.com>
Date: Tue, 19 Oct 2010 22:54:10 +0100
Message-Id: 
References:  <048601cb6f3a$4a973180$30298a0a@china.huawei.com>  <041501cb6f9c$5c4db950$14e92bf0$%roni@huawei.com>  <042f01cb6fa6$c800a1d0$5801e570$%roni@huawei.com>
To: Roni Even 
X-Mailer: Apple Mail (2.1081)
X-Mailman-Approved-At: Tue, 19 Oct 2010 15:10:15 -0700
Cc: avt@ietf.org
Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Oct 2010 21:52:49 -0000

--Apple-Mail-233--19594483
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Roni, Tom,

I'd recommend moving the discussion away from specific scenarios to the =
extent possible, and focussing on the general mechanism. Yes, the draft =
should give examples of how retransmission suppression is used with the =
RAMS scenario, and probably with other scenarios, but those are just =
examples of how to use the general mechanism. If the semantics of that =
general mechanism are well-defined, then how it's used for the specific =
scenarios should become clearer.

Colin



On 19 Oct 2010, at 17:00, Roni Even wrote:
> Hi Tom,
> In the current RAMS there is no way for the BRS to send a suppression =
indication , the only available way is in the main SSM stream. I think =
that such BRS will be reporting nodes to the DS in the simple case. Are =
you suggesting that we define a new SSM session that will be initiated =
by the BRS. I think this will make more sense if we also address the =
retransmission support you described since the SSM session will serve =
for the retransmission.
> Currently this part is not in scope but we may ask the WG if they want =
to add this specific scenario
> =20
> Roni Even
> =20
> From: Van Caenegem, Tom (Tom) =
[mailto:tom.van_caenegem@alcatel-lucent.com]=20
> Sent: Tuesday, October 19, 2010 5:31 PM
> To: Roni Even; 'Qin Wu'; avt@ietf.org
> Subject: RE: [AVT] New Version Notification for =
draft-wu-avt-retransmission-supression-rtp-04
> =20
> Hi Roni,
> =20
> In the typical RAMS architecture, the BRS will receive the SSM stream =
from the DS. If there are several BRS-es, there may be just one BRS that =
detects packet loss on its upstream link, but the others will perhaps =
not, as the packet loss took place on SSM tree branch that does not =
impact the other BRSes. In that case those RTP receivers associated to =
the other BRS-es in general will not be impacted and do not need to =
receive the suppression indication, while the one BRS that did sense the =
packet loss should probably best send a suppression indication (although =
there is a chance that only this BRS is impacted by packet loss, and not =
a single RTP receiver in the field reporting to this BRS/FT... this all =
depends on the considered topologies).
> =20
> As a BRS is 1-to-1 associated with a FT, this calls for consideration =
of architectures with (multiple) disjoint FT (and associated BRS in RAMS =
applications)  in the suppression draft. Such disjoint FT/BRS in general =
cannot act as so-called "intermediate nodes" or "translators" because =
they are not on the direct SSM path between the DS and the RTP =
receivers.
> =20
> Another aspect I want to highlight is that feedback suppression is =
closely aligned with retransmission. In the case described above, the =
one BRS that detected packet loss on its upstream link, may try to =
recover the missing packet (outside the scope of the draft) and =
retransmit over multicast to the receivers that report to the FT. This =
retransmission towards the receivers is also outside the current scope =
of the current draft, but the two are somehow linked.  In DVB IPTV, we =
introduced dedicated SSMs sourced by the BRS for sending NACK =
suppression and the (optional) retransmission. In the considered =
scenario, having a DS sending a missing packet -reported by a FT =
downstream in the SSM tree- over the original SSM is not a good approach =
IMO, as it results in general in unnecessary retransmissions for most =
receivers.
> =20
> Hope this clarifies.
> =20
> Tom
> =20
> From: Roni Even [mailto:Even.roni@huawei.com]=20
> Sent: dinsdag 19 oktober 2010 16:46
> To: Van Caenegem, Tom (Tom); 'Qin Wu'; avt@ietf.org
> Subject: RE: [AVT] New Version Notification for =
draft-wu-avt-retransmission-supression-rtp-04
>=20
> Hi Tom,
> I want to clarify your example since I am not sure what is special =
here. The BRS sends separate unicast streams to each participant so =
there is reason for suppression on these unicast streams. As for the =
primary multicast stream from the DS it goes to all receivers. Now if =
the BRS identify packet loss on the primary stream it should send =
suppression indication to all members of the multicast group regardless =
to which FT they report.
> Can you clarify
> =20
> Roni Even
> =20
> =20
> =20
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of =
Van Caenegem, Tom (Tom)
> Sent: Tuesday, October 19, 2010 10:27 AM
> To: Qin Wu; avt@ietf.org
> Subject: Re: [AVT] New Version Notification for =
draft-wu-avt-retransmission-supression-rtp-04
> =20
> Hi Qin,
> =20
> Thank you for your reply.
> =20
> Reading your responses,you seem to focus really on the SSM  case with =
an architecture where the single DS (there can be only one DS per SSM) =
hosts the sole feedback target, which also hosts the loss detector =
function. My interpretation is also that in your draft the loss detector =
sends the FIR or NACK supression message to the DS, which then =
forwards/relays this message over the SSM to all receivers, right?=20
> =20
> My main comment remains the same: you should at least incorporate the =
architecture of RAMS (where there can be several FT  colocated with the =
BRS, which are disjoint from the DS). In this case the FT/BRS should be =
able to provide a suppression indication to all receivers that report to =
this FT (which is a subset of all receivers that connect to the SSM), =
which means one should not make use of the (original) SSM for providing =
the suppression indication.  Your draft provides a possible solution for =
only a limited use case, and not the most interesting one, IMO. =20
> =20
> Further down some responses to your answers below.
> =20
> Tom
> =20
> =20
> From: Qin Wu [mailto:sunseawq@huawei.com]=20
> Sent: dinsdag 19 oktober 2010 5:04
> To: Van Caenegem, Tom (Tom); avt@ietf.org
> Subject: Re: [AVT] New Version Notification for =
draft-wu-avt-retransmission-supression-rtp-04
>=20
> Hi, Tom:
> Thank for your comments, please see my reply inline.
> =20
> Regards!
> -Qin
> ----- Original Message -----
> From: Van Caenegem, Tom (Tom)
> To: avt@ietf.org ; Qin Wu
> Sent: Tuesday, October 19, 2010 12:08 AM
> Subject: Re: [AVT] New Version Notification for =
draft-wu-avt-retransmission-supression-rtp-04
> =20
> Hi Qin,
> =20
> I have some comments (look for TOM below) on the new draft version 4.
> Thx for addressing them,
> Tom
> =20
> =20
> Section 2 Terminology
>  Loss Detector:
> =20
>       The Loss Detector is one logical function which is used to =
detect
>       the packet loss at the RTP layer and report it to the =
distribution
>       source.  The function of the loss reporter may be collocated =
with
>       or integrated into the same entity.  In this case, for a session
>       defined as having a distribution source A, on ports n for the =
RTP
>       channel and k for the RTCP channel, the Loss Detector are
>       identified by an IP address of distribution source A on port k.
>       The Loss Detector MAY also be implemented in one or more =
entities
>       different from the distribution source.
>  The function of the loss reporter may be collocated with
>       or integrated into the same entity.
> TOM (1): ..same entity as what? i guess you mean the DS?
> [Qin]: Your are right.  In this draft, the loss detector is just =
functionality of DS.  Furthermore we only consider the loss detector as =
part of feedback target within the distribution source.
> Also this is just one example use case to explain how feedback =
suppression works in SSM use case.
> TOM (2): I do not understand how you associate the port k to a loss =
detector.. what do you mean with that?
> [Qin]:  Sorry for ambiguity of the description here. It actually means =
that the loss reporter is part of feedback target and share the same =
address and port.
> section 3
> =20
> (..)
> In order to detect packet loss before the receivers perceive it, one
>    or more intermediate nodes are placed between the media source and
>    receiver (e.g., Distribution server, MCU, RTP translator).  These
>    intermediaries monitor for packet loss upstream of themselves by
>    checking RTP sequence numbers, just as receivers do.  Upon =
detecting
>    (or suspecting) an upstream loss, the intermediary may send =
Feedback
>    Suppression message towards the receivers as defined in this
>    specification.
> TOM (3) : ...based on the two above definitions ...is an intermediate =
node hence equal to a "Loss detector"?=20
> + How does a Loss detector differ from an RTP receiver?
> [Qin]: The loss detector is just one functionality of Distribution =
Source in the SSM use case.
> Maybe we should interpret it as "Loss detection functionality". How =
the packet loss is detected is out of scope of this document.
> Different from dedicated RTP receiver, the intermediate node does not =
depend on existing NACK message for Retransmission request for packet =
loss.
> the intermediate node can create message by itself.
> =20
> Section 6.1
> In order to avoid the forms of NACK implosion described in section 1,
>    the Loss Detector is introduced.  The Loss Detector detects and
>    reports packet loss, on both the upstream link and the downstream
>    aggregate link.  How the loss detector SHOULD detect the packet =
loss
>    is beyond of scope of this document.  When upstream link or
>    downstream aggregate link packet loss occurs, the Loss Detector MAY
>    inform distribution source of the detected packet loss using =
Feedback
>    Suppression messages.  In response, the distribution source either
>    forwards packet loss suppression report received from Loss Detector
>    or creates a Feedback Suppression report and sends it to all the =
RTP
>    receivers, over the multicast channel.  This loss suppression =
report
>    tells the receivers that the lost packet will either be forthcoming
>    from distribution source, or it irretrievably lost such that there =
is
>    nothing to be gained by the receiver sending a NACK to the media
>    source.  The distribution source then can (optionally) ask for the
>    lost packets from the media source on behalf of all the RTP
>    receivers.
> TOM (4) : You probably do not want to have normative language in =
section 6.1, like "How the loss detector SHOULD (..)".=20
> [Qin]:Sorry, I can't get it.=20
> TOM: this is really a detail. If you want to keep the sentence, you =
should e.g. say: "How the loss detector can detect the packet loss...
> =20
> =20
> TOM (5) : It is pretty clear how a Loss detector will detect packet =
loss on its upstream link, I guess.
> [Qin]: As I said above,  Loss detector is just functionality of some =
Distribution sources.  Also what it said here in section 6.1=20
> is just one example use case.
> TOM (6):  What is the rationale for a loss detector to send a Feedback =
suppression message to the DS.. why NOT a RTCP NACK FB?
> [Qin]: As I explained in the last IETF presentaion,  this cause NACK =
scematics mismatch. That's why many people in the last IETF meeeting =
suggest to create new RTCP message during presentation.=20
> =20
> TOM: As your assumption is that the loss reporter is part of the FT =
that is part of the DS, then there is even no need to specify how the =
loss detector=20
> reports the packet loss.  In the more generic case, it makes more =
sense to me that the loss reporter just uses a NACK (or a FIR) if it =
detects packet loss, sent towards its FT or to the DS if this one hosts =
the FT that the loss detector reports to . It is then up to the FT or =
the DS to decide whether this message triggers a NACK or FIR suppression=20=

> indication to (s subset of) the receivers.  This suppression =
indication does not necessarly require a new message format. A NACK/FIR  =
that is sent to a RTP receiver can be defined as a feedback suppression =
indication. I do not see a good use case why NACKs from  receivers  =
would be reflected back in e.g. SSM use case by DS or FT  to all the =
connected receivers.=20
> If we define that a NACK/FIR  for a SSM may only be sent TOWARDS a RTP =
receiver, if this is for suppression indication, there is no ambiguity =
possibly.  =20
> =20
> =20
> Section 6.1.1
> If there are multiple Loss Detectors looking at the same RTP stream,
>    then the loss may be identified by more than one and those =
detecting
>    the loss will all send requests for the same packet loss.  In this
>    case, the distribution source MUST filter the duplicated packet =
loss
>    request out and only forward one copy of the RTCP Feedback report
>    packet from the first Loss Detector to the group impacted by packet
>    loss.
> TOM (7) : how will the DS send only a copy of the RTCP FB report =
packet to the group impacted by packet loss. Is this done over the SSM?
> =20
> [Qin]: Sorry, maybe I sould say
> "
> Section 6.1.1
> If there are multiple Distrbitution Source with the loss detection =
support looking at the same RTP stream.....
> "
> Yes,  in the SSM use case, DS send only a copy of the RTCP Feedback =
Suppression Report packet the group via SSM.
> =20
> In your example you seem to focus only on architectures with a DS =
which also hosts the FT and the loss reporter.  There should be sections =
covering cases where the DS is disjoint from the FT, with several FTs =
and also several loss reporters disjoint from the FT and the DS.
> =20
> [Qin] I am not sure we need to address all the possible SSM use cases. =
In this draft, we just give some examples of SSM use case.
> =20
> TOM (8) : what do you mean in above text with "RTCP FB report".. is =
that the suppression message you define in this draft?
> =20
> [Qin]: Yes,  RTCP Feedback Suppression Report.
> =20
> TOM (9) : In section  "6.1.2.  Distribution Source Feedback Summary =
Model" it is not clear what your architecture looks like. You talk about =
multiple distribution sources.. whcih implies multiple SSMs.. Can you =
elaborate on that?
> =20
> [Qin]:  The scenario we are talking about in  the section 6.1.2, is to =
 allow multiple Distrbituion source between media source and the =
receiver. I will look at the this case as one special SSM case. because  =
each of distrbituion source resides at the upstream direction or =
downstream direction of other distributions souces. Does it make sense?=20=

> =20
> TOM: RFC 5760 only defines one DS for a given SSM. If you depart from =
that, you probably need to address and define this architecture in a =
better way in your draft.=20
> =20
> Tom (10) :  In section  6.3.  Multipoint Control Unit (MCU) use case,  =
typically an overlay of unicast is used... will the Feedback suppression =
message be sent over unicast as well? If so, what is gain compared to =
just having each RTCP receiver providing each their NACK to the MCU, =
even in case of a packet loss impacting all receivers?
> =20
> [Qin]: First The MCU case will not cause NACK Implosion, instead, it =
may cause FIR implosion.
>            Second, using Feedback suppression message can restrict the =
FIR message sent from receivers behind MCU and liberate the media source =
from  FIR implosion.=20
> =20
> TOM: it is not important whether this is about FIR or NACK. My point =
is that iso having each receiver sending a NACK/FIR, you will now have =
to send to each receiver a NACK/FIR  suppression in the given scenario. =
There are no differences in terms of Bandwdith overhead or server load =
in the two cases, so why bother to send suppression messages?
> =20
> =20
> Tom (11) : coming back to my previous comment on SDP description in =
this draft : if this draft defines a RTCP feedback suppression message, =
why is there need for a "announcement" in the SDP for the receivers, =
that indicates they may receive such feedback suppression messages?  If =
a receiver supports the message, it will  simply act accordingly as =
described in the draft, no need to announce that!..
> =20
> [Qin]: Okay, I get your point. I would like to put this as open issue, =
discuss it in the face to face IETF meeting.
> =20
> Regards
> Tom
> =20
> =20
> =20
> =20
> =20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt



--=20
Colin Perkins
http://csperkins.org/




--Apple-Mail-233--19594483
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Hi =
Tom,
In the =
current RAMS there is no way for the BRS to send a suppression =
indication , the only available way is in the main SSM stream. I think =
that such BRS will be reporting nodes to the DS in the simple case. Are =
you suggesting that we define a new SSM session that will be initiated =
by the BRS. I think this will make more sense if we also address the =
retransmission support you described since the SSM session will serve =
for the retransmission.
Currently this part is not in scope but we may ask =
the WG if they want to add this specific =
scenario
Roni =
Even
 Van =
Caenegem, Tom (Tom) [mailto:tom.van_caenegem@alcatel-lucent.com] 
Sent: Tuesday, October 19, 2010 =
5:31 PM
To: Roni Even; 'Qin Wu'; avt@ietf.org
Subject: RE: [AVT] New Version =
Notification for =
draft-wu-avt-retransmission-supression-rtp-04
 
Hi =
Roni,
In the typical RAMS =
architecture, the BRS will receive the SSM stream from the DS. If there =
are several BRS-es, there may be just one BRS that detects packet loss =
on its upstream link, but the others will perhaps not, as the packet =
loss took place on SSM tree branch that does not impact the other =
BRSes. In that case those RTP receivers associated to the other BRS-es =
in general will not be impacted and do not need to receive the =
suppression indication, while the one BRS that did sense the packet loss =
should probably best send a suppression indication (although there is a =
chance that only this BRS is impacted by packet loss, and not a =
single RTP receiver in the field reporting to this BRS/FT... this all =
depends on the considered topologies).
 
As a BRS is 1-to-1 =
associated with a FT, this calls for consideration of architectures with =
(multiple) disjoint FT (and associated BRS in RAMS applications)  =
in the suppression draft. Such disjoint FT/BRS in general cannot act as =
so-called "intermediate nodes" or "translators" because they are not on =
the direct SSM path between the DS and the RTP =
receivers.
Another aspect I want to =
highlight is that feedback suppression is closely aligned with =
retransmission. In the case described above, the one BRS that detected =
packet loss on its upstream link, may try to recover the missing packet =
(outside the scope of the draft) and retransmit over multicast to the =
receivers that report to the FT. This retransmission towards the =
receivers is also outside the current scope of the current draft, but =
the two are somehow linked.  In DVB IPTV, we introduced dedicated =
SSMs sourced by the BRS for sending NACK suppression and the =
(optional) retransmission. In the considered scenario, having a DS =
sending a missing packet -reported by a FT downstream in the SSM tree- =
over the original SSM is not a good approach IMO, as it results in =
general in unnecessary retransmissions for most =
receivers.
Hope this =
clarifies.
 Roni =
Even [mailto:Even.roni@huawei.com] 
Sent: dinsdag 19 oktober 2010 =
16:46
To: Van =
Caenegem, Tom (Tom); 'Qin Wu'; avt@ietf.org
Subject: RE: [AVT] New Version =
Notification for =
draft-wu-avt-retransmission-supression-rtp-04
Hi =
Tom,
I want to =
clarify your example since I am not sure what is special here. The BRS =
sends separate unicast streams to each participant so there is reason =
for suppression on these unicast streams. As for the primary multicast =
stream from the DS it goes to all receivers. Now if the BRS identify =
packet loss on the primary stream it should send suppression indication =
to all members of the multicast group regardless to which FT they =
report.
Can =
you clarify
Roni =
Even
 avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]=
 On Behalf Of Van Caenegem, Tom =
(Tom)
Sent: Tuesday, October 19, 2010 =
10:27 AM
To: Qin Wu; avt@ietf.org
Subject: Re: [AVT] New Version =
Notification for =
draft-wu-avt-retransmission-supression-rtp-04
 
Hi =
Qin,
 
Thank you for your reply.
 
Reading your =
responses,you seem to focus really on the SSM  case with an =
architecture where the single DS (there can be only one DS per SSM) =
hosts the sole feedback target, which also hosts the loss detector =
function. My interpretation is also that in your draft the loss detector =
sends the FIR or NACK supression message to the DS, which then =
forwards/relays this message over the SSM to all receivers, =
right? 
My main comment remains =
the same: you should at least incorporate the architecture of RAMS =
(where there can be several FT  colocated with the BRS, =
which are disjoint from the DS). In this case the FT/BRS should be able =
to provide a suppression indication to all receivers that report to this =
FT (which is a subset of all receivers that connect to the SSM), which =
means one should not make use of the (original) SSM for providing the =
suppression indication.  Your draft provides a possible solution =
for only a limited use case, and not the most interesting one, =
IMO.  
Further =
down some responses to your answers =
below.
 
From: Qin Wu =
[mailto:sunseawq@huawei.com] 
Sent: dinsdag 19 oktober 2010 =
5:04
To: Van =
Caenegem, Tom (Tom); avt@ietf.org
Subject: Re: [AVT] New Version =
Notification for =
draft-wu-avt-retransmission-supression-rtp-04
Hi, Tom:
Thank for your =
comments, please see my reply inline.
 
----- Original Message ----- Van Caenegem, Tom =
(Tom)
Sent: Tuesday, October 19, 2010 =
12:08 AMSubject: Re: [AVT] New Version =
Notification for draft-wu-avt-retransmission-supression-rtp-04Hi =
Qin,
I have some comments =
(look for TOM below) on the new draft version =
4.
Thx for addressing =
them,
Section 2 =
Terminology
 Loss Detector:
      The Loss Detector is =
one logical function which is used to detect
      channel and =
k for the RTCP channel, the Loss Detector =
are
      identified by an IP =
address of distribution source A on port k.
 The function of the loss reporter may be =
collocated with
      or integrated into =
the same entity.
TOM (1): ..same entity as what? i guess you mean =
the DS?
[Qin]: Your are right.  In this draft, the =
loss detector is just functionality of DS.  Furthermore we only =
consider the loss detector as part of feedback target within the =
distribution source.
Also this is just one example use case to =
explain how feedback suppression works in SSM use =
case.
TOM (2): I do not understand how you associate the =
port k to a loss detector.. what do you mean with =
that?
[Qin]:  Sorry for ambiguity of the description =
here. It actually means that the loss reporter is part of feedback =
target and share the same address and port.
section =
3
 
(..)
In order to detect =
packet loss before the receivers perceive it, =
one
   or more intermediate nodes are placed =
between the media source and
   receiver =
(e.g., Distribution server, MCU, RTP translator).  =
These
   intermediaries monitor for packet loss =
upstream of themselves by
   checking RTP sequence numbers, =
just as receivers do.  Upon detecting
   (or =
suspecting) an upstream loss, the intermediary may send =
Feedback
   Suppression message towards the =
receivers as defined in this
   =
specification.
TOM (3) =
: ...based on the two above definitions =
...is an intermediate node hence equal to&nb=
sp;a "Loss detector"? 
+ How does a Loss detector differ from an RTP =
receiver?
[Qin]: The loss detector =
is just one functionality of Distribution Source in the SSM use =
case.
Maybe we =
should interpret it as "Loss detection functionality". How the =
packet loss is detected is out of scope of this =
document.
Different from dedicated =
RTP receiver, the intermediate node does not depend on existing NACK =
message for Retransmission request for packet =
loss.
the intermediate node can =
create message by itself.
 
Section =
6.1
In order to avoid the forms of NACK implosion described =
in section 1,
   the Loss Detector is introduced.  =
The Loss Detector detects and
   reports =
packet loss, on both the upstream link and the =
downstream
   aggregate link.  How the loss =
detector SHOULD detect the packet loss
   is beyond =
of scope of this document.  When upstream link =
or
   downstream aggregate link packet loss =
occurs, the Loss Detector MAY
   inform =
distribution source of the detected packet loss using =
Feedback
   Suppression messages.  In =
response, the distribution source either
   forwards =
packet loss suppression report received from Loss =
Detector
   or creates a Feedback Suppression =
report and sends it to all the RTP
   =
receivers, over the multicast channel.  This loss suppression =
report
   tells the receivers that the lost =
packet will either be forthcoming
   from =
distribution source, or it irretrievably lost such that there =
is
   nothing to be gained by the receiver =
sending a NACK to the media
   =
source.  The distribution source then can (optionally) ask for =
the
   lost packets from the media source on =
behalf of all the RTP
   =
receivers.
TOM (4) : You probably do not want to have =
normative language in section 6.1, like "How the loss detector SHOULD =
(..)". 
[Qin]:Sorry, I can't get it.TOM: this is really a detail. If you want to =
keep the sentence, you should e.g. say: "How the loss detector can =
detect the packet loss...
 
TOM (5) : It is pretty =
clear how a Loss detector will detect packet loss on its upstream link, =
I guess.
[Qin]: As I said above,  Loss detector is just =
functionality of some Distribution sources.  Also what it said here =
in section 6.1 
is just one example use =
case.
TOM (6):  What is the rationale for a loss =
detector to send a Feedback suppression message to the DS.. why NOT a =
RTCP NACK FB?
[Qin]: As I explained in the last IETF =
presentaion,  this cause NACK scematics mismatch. That's why many =
people in the last IETF meeeting suggest to create new RTCP message =
during presentation. 
TOM: As your assumption is that the loss =
reporter is part of the FT that is part of the DS, then there is even no =
need to specify how the loss detector 
reports the =
packet loss.  In the more generic case, it makes more sense to me =
that the loss reporter just uses a NACK (or a FIR) if it detects packet =
loss, sent towards its FT or to the DS if this one hosts the FT that the =
loss detector reports to . It is then up to the FT or the DS to decide =
whether this message triggers a NACK or FIR suppression =

indication to (s subset of) the =
receivers.  This suppression indication does not necessarly require =
a new message format. A NACK/FIR  that is sent to a RTP receiver =
can be defined as a feedback suppression indication. I do not see a good =
use case why NACKs from  receivers  would be reflected back in =
e.g. SSM use case by DS or FT  to all the connected receivers. =

If we define that a NACK/FIR  for a SSM =
may only be sent TOWARDS a RTP receiver, if this is for suppression =
indication, there is no ambiguity possibly.   =

 
Section 6.1.1
If there are multiple =
Loss Detectors looking at the same RTP =
stream,
   then the loss may be identified by =
more than one and those detecting
   the loss =
will all send requests for the same packet loss.  In =
this
   case, the distribution source MUST filter =
the duplicated packet loss
   request =
out and only forward one copy of the RTCP Feedback =
report
   packet from the first Loss Detector to =
the group impacted by packet
   =
loss.
TOM (7) : how will the DS =
send only a copy of the RTCP FB report packet to the group impacted by =
packet loss. Is this done over the SSM?
 
[Qin]: Sorry, =
maybe I sould say
Section =
6.1.1
If there are multiple =
Distrbitution Source with the loss detection support looking at the same =
RTP stream.....
Yes,  in the SSM use =
case, DS send only a copy of the RTCP Feedback Suppression Report packet =
the group via SSM.
In your example you seem =
to focus only on architectures with a DS which also hosts the FT and the =
loss reporter.  There should be sections covering cases where the =
DS is disjoint from the FT, with several FTs and also several loss =
reporters disjoint from the FT and the =
DS.
[Qin] I am not sure we =
need to address all the possible SSM use cases. In this draft, we just =
give some examples of SSM use case.
 
TOM (8) : what =
do you mean in above text with "RTCP FB report".. is that the =
suppression message you define in this =
draft?
[Qin]: Yes,  RTCP =
Feedback Suppression Report.
 
TOM (9) : In =
section  "6.1.2.  Distribution Source Feedback Summary Model" =
it is not clear what your architecture looks like. You talk about =
multiple distribution sources.. whcih implies multiple SSMs.. Can you =
elaborate on that?
[Qin]:  The scenario =
we are talking about in  the section 6.1.2, is to  allow =
multiple Distrbituion source between media source and the receiver. I =
will look at the this case as one special SSM case. because  each =
of distrbituion source resides at the upstream direction or downstream =
direction of other distributions souces. Does it make sense?TOM: RFC 5760 only =
defines one DS for a given SSM. If you depart from that, you probably =
need to address and define this architecture in a better way in =
your draft. 
 
Tom (10) =
:  In section  6.3.  Multipoint Control Unit (MCU) use =
case,  typically an overlay of unicast is used... will the Feedback =
suppression message be sent over unicast as well? If so, what is gain =
compared to just having each RTCP receiver providing each their NACK to =
the MCU, even in case of a packet loss impacting all =
receivers?
[Qin]: First The MCU case =
will not cause NACK Implosion, instead, it may cause FIR =
implosion.
 
 
Tom (11) : coming back to =
my previous comment on SDP description in this draft : if this =
draft defines a RTCP feedback suppression message, why is there need for =
a "announcement" in the SDP for the receivers, that indicates they may =
receive such feedback suppression messages?  If a receiver supports =
the message, it will  simply act accordingly as described in =
the draft, no need to announce that!..
 
[Qin]: Okay, I =
get your point. I would like to put this as open issue, discuss it in =
the face to face IETF meeting.
 


=

--Apple-Mail-233--19594483--

From sunseawq@huawei.com  Tue Oct 19 19:25:45 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178BC3A6984 for ; Tue, 19 Oct 2010 19:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.851
X-Spam-Level: 
X-Spam-Status: No, score=0.851 tagged_above=-999 required=5 tests=[AWL=0.145,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltQ+OwumnUsW for ; Tue, 19 Oct 2010 19:25:43 -0700 (PDT)
Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2183C3A697B for ; Tue, 19 Oct 2010 19:25:43 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAK00LPHHH43J@szxga05-in.huawei.com> for avt@ietf.org; Wed, 20 Oct 2010 10:27:04 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAK00ITCHH49T@szxga05-in.huawei.com> for avt@ietf.org; Wed, 20 Oct 2010 10:27:04 +0800 (CST)
Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAK007OGHH37T@szxml04-in.huawei.com> for avt@ietf.org; Wed, 20 Oct 2010 10:27:04 +0800 (CST)
Date: Wed, 20 Oct 2010 10:27:03 +0800
From: Qin Wu 
To: avt@ietf.org
Message-id: <02cb01cb6ffe$488b5be0$30298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: multipart/alternative; boundary="Boundary_(ID_pEdGKNX2QyibSs/ZBa2Evg)"
X-Priority: 3
X-MSMail-priority: Normal
Cc: VAN CAENEGEM Tom 
Subject: [AVT] Fw: New Version Notification for draft-wu-avt-retransmission-supression-rtp-04
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 02:25:45 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_pEdGKNX2QyibSs/ZBa2Evg)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Tom,
 Look at the new version of draft, you will find we focus on defining more general mechanism of "feedback suppression" to address different use cases of "feedback implosion".

SSM case is just one example use case we look at. We can address the case you suggested below(which assumes a single DS, one or multiple disjoint FTs, where a FT is co-positioned with a BRS (same IP address))
But I am not sure this case is referred to as "RAMS case". And also what confuse to me in the RAMS case is Retransmission Server is usually used for channel switching in the RAMS case and just used to send unicast RTP stream to one receiver when this receiver requests a unicast burst from Retransmission server. Suppose there is two Retransmission server (i.e., RS1 and RS2 )behind the DS,if the packet loss happens between the DS and  RS1 but there is no packet loss happened between DS and RS2, do you think RS1 should report the packet loss to its upstream DS.
This is not allowed in our draft.  In my understand, maybe there is only one receiver requesting unicast burst, it is not necessary to suppress such RAMS message for one receiver.

In our draft, one similar case is we allow multiple DSs in the SSM case, in such case, packet loss always happens at the upsteam of each DS, each DS should not report packet loss to the upstream DS, in this way, even DS is connected to a different branch of the SSM tree, it is not necessary to send feedback suppresion to all the receiver if some didn't suffer from packet loss.

If there is one downstream DS or intermediate node placed at the downstream of its upstream DS, the downstream may either simply forward the Feedback Suppression message received from upstream, or augment (or replace) it with a  feedback suppression message that reflects the loss pattern they have themselves seen. they should not initiate their own  additional feedback suppression messages for the same packet sequence numbers.  The role of such downstream DS has been clearly defined in the section 3 of draft-wu-avt-retransmission-suppression-rtp-04 as follows:
"
   RTCP Feedback Suppression follows the same semantic model as RTCP
   NACK - it conveys the packet receipt/loss events at the sequence
   number level and considers missing packets as unrepaired.  But unlike
   RTCP NACK, the Feedback Suppression messages can be generated at
   intermediate nodes who are not RTP receivers and sent to the
   corresponding receivers.  Intermediaries downstream of an
   intermediary detecting loss obviously SHOULD NOT initiate their own
   additional feedback suppression messages for the same packet sequence
   numbers.  They may either simply forward the Feedback Suppression
   message received from upstream, or augment (or replace) it with a
   feedback suppression message that reflects the loss pattern they have
   themselves seen.
"

As for why we creat new message instead of using existing NACK, 
NACK lacks scemantics for suppression and NACK as one feedback message terminate at the server, the intermediate node e.g., distribution
source as the server receiving NACK will confuse whether the NACK should be forwarded to the server or the receiver. And the distribution source
has no behavior to be defined for dealing with NACKs.
Also Feedback Suppression message can work without receiving NACKs sent from receiver. Using NACK for packet loss report from some dedicated receiver is
just a way for the distribution source or intermediate node to detect packet loss. But it is not the only way.


Regards!
-Qin
  ----- Original Message ----- 
  From: Van Caenegem, Tom (Tom) 
  To: Qin Wu ; avt@ietf.org 
  Sent: Tuesday, October 19, 2010 9:26 PM
  Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04


  Qin,

  focusing on just SSM arch: I quote from your earlier response:

  In this draft, the loss detector is just functionality of DS.  Furthermore we only consider the loss detector as part of feedback target within the distribution source. Also this is just one example use case to explain how feedback suppression works in SSM use case.

  Again, your draft does explain in detail how feedback suppression works for a SSM as described here above, but does not address the RAMS case (which assumes a single DS, one or multiple disjoint FTs, where a FT is co-positioned with a BRS (same IP address). 

  Just consider a DS with multiple disjoint FTs (as in RAMS, and also permitted by RFC 5760). Typically each FT is connected to a different branch of the SSM tree. 

  Currently your draft imposes that the feedback suppression message is sent by the DS over the SSM. This is not a good solution as you either restrict the solution to packet losses that are common to all SSM RTP receivers (covering packet loss between media source and DS ) or you will send suppression indications (and optionally forthcoming retransmission) to all receivers even if some did not suffer from packet loss. Therefore the draft should also define how suppression information is sent to (a subset of) the receivers. It does not make sense to me that IETF would define FB suppression for a architecture that does not take into account deployed SSM architectures for IPTV.

  Even within the SSM architecture you are focusing on, I am very much confused: you say there is one DS that hosts the FT and loss reporting function. What is then the role of the intermediate sources downstream of the DS? I really would appreciate you illustrate with some more architecture drawings.

  The other point I still am not convinced of, is  the use of NACK versus dedicated suppression message. There should be more clarity in the different architectures you consider before we can make any statements on whether having a NACK or FIR  that is used as suppression message towards the SSM receivers, is confusing or not. I do not disagree that NACK as defined in RFC 4588 cannot be used as suppression message. But if we define it this way in a this "suppression"  draft/RFC, and no confusions can occur, I do not see the issue, especially as the syntax of the suppression message is completely the same as a NACK/FIR. 

  Regards
  Tom







------------------------------------------------------------------------------

--Boundary_(ID_pEdGKNX2QyibSs/ZBa2Evg)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT









Tom,


 Look at the new version of draft, you will find we focus on 
defining more general mechanism of "feedback suppression" to address 
different use cases of "feedback implosion".


 


SSM case is just one example use case we look at. We can 
address the case you suggested below(which assumes a single DS, one or multiple disjoint FTs, 
where a FT is co-positioned with a BRS (same IP 
address))


But I am not sure this case is referred to as "RAMS case". And 
also what confuse to me in the RAMS case is Retransmission Server is usually 
used for channel switching in the RAMS case and just used to send unicast 
RTP stream to one receiver when this receiver requests a 
unicast burst from Retransmission server. Suppose there is two Retransmission 
server (i.e., RS1 and RS2 )behind the DS,if the packet loss happens between 
the DS and  RS1 but there is no packet loss happened between DS 
and RS2, do you think RS1 should report the packet loss to its upstream 
DS.


This is not allowed in our draft.  In my 
understand, maybe there is only one receiver requesting unicast burst, it is not 
necessary to suppress such RAMS message for one receiver.


 


In our draft, one similar case is we allow multiple DSs in the 
SSM case, in such case, packet loss always happens at the upsteam of each DS, 
each DS should not report packet loss to the upstream DS, in this way, even 
DS is connected to a different branch of the SSM tree, it is 
not necessary to send feedback suppresion to all the receiver if some didn't 
suffer from packet loss.


 


If there is one downstream DS or intermediate node placed at the 
downstream of its upstream DS, the downstream may either simply forward the 
Feedback Suppression message received from upstream, or augment (or 
replace) it with a  feedback suppression message that reflects the loss 
pattern they have themselves seen. they should not initiate their own  
additional feedback suppression messages for the same packet 
sequence numbers.  The role of such downstream DS has been clearly 
defined in the section 3 of draft-wu-avt-retransmission-suppression-rtp-04 as 
follows:


"


   RTCP Feedback Suppression follows the same semantic model as 
RTCP
   NACK - it conveys the packet receipt/loss events at the 
sequence
   number level and considers missing packets as 
unrepaired.  But unlike
   RTCP NACK, the Feedback Suppression 
messages can be generated at
   intermediate nodes who are not RTP 
receivers and sent to the
   corresponding receivers.  
Intermediaries downstream of an
   intermediary detecting loss 
obviously SHOULD NOT initiate their own
   additional feedback 
suppression messages for the same packet sequence
   numbers.  
They may either simply forward the Feedback Suppression
   message 
received from upstream, or augment (or replace) it with a
   
feedback suppression message that reflects the loss pattern they 
have
   themselves seen.


"


 


As for why we creat new message instead of using existing NACK, 



NACK lacks scemantics for suppression and NACK as one feedback 
message terminate at the server, the intermediate node e.g., 
distribution
source as the server receiving NACK will confuse whether the 
NACK should be forwarded to the server or the receiver. And the distribution 
source


has no behavior to be defined for dealing with 
NACKs.


Also Feedback Suppression message can work without receiving NACKs 
sent from receiver. Using NACK for packet loss report from some dedicated 
receiver is


just a way for the distribution source or intermediate node to 
detect packet loss. But it is not the only way.


 


Regards!


-Qin



  
----- Original Message ----- 

  
  
  
Sent: Tuesday, October 19, 2010 9:26 PM

  
Subject: RE: [AVT] New Version Notification 
  for draft-wu-avt-retransmission-supression-rtp-04

  


  
Qin,

  
 

  
focusing on just SSM arch: I quote from your earlier 
  response:

  
 

  
In this draft, the loss 
  detector is just functionality of DS.  Furthermore we only consider the 
  loss detector as part of feedback target within the distribution source. Also this is just one 
  example use case to explain how feedback suppression works in SSM use 
  case.

  
 

  
Again, your 
  draft does explain in detail how feedback suppression works for a SSM as 
  described here above, but does not address the RAMS case (which assumes a 
  single DS, one or multiple disjoint FTs, where a FT is co-positioned with 
  a BRS (same IP address). 

  
 

  
Just consider a 
  DS with multiple disjoint FTs (as in RAMS, and also permitted by RFC 
  5760). Typically each FT is connected to a different branch of the SSM 
  tree. 

  
 

  
Currently your draft imposes that the feedback suppression 
  message is sent by the DS over the SSM. This is not a good solution as you 
  either restrict the solution to packet losses that are common to all SSM RTP 
  receivers (covering packet loss between media source and DS ) or you will send 
  suppression indications (and optionally forthcoming retransmission) to all 
  receivers even if some did not suffer from packet 
  loss. Therefore the draft should also define how suppression 
  information is sent to (a subset of) the receivers. It does not make sense to 
  me that IETF would define FB suppression for a architecture that does not 
  take into account deployed SSM architectures for 
  IPTV.

  
 

  
Even within the SSM architecture you are 
  focusing on, I am very much confused: you say there is one DS that hosts the 
  FT and loss reporting function. What is then the role of the intermediate 
  sources downstream of the DS? I really would appreciate you illustrate with 
  some more architecture drawings.

  
 

  
The other point I still am not convinced of, 
  is  the use of NACK versus dedicated suppression message. There 
  should be more clarity in the different architectures you consider before we 
  can make any statements on whether having a NACK or FIR  that 
  is used as suppression message towards the SSM receivers, is confusing or 
  not. I do not disagree that NACK as defined in RFC 4588 cannot be used as 
  suppression message. But if we define it this way in a this "suppression" 
   draft/RFC, and no confusions can occur, I do not see the issue, 
  especially as the syntax of the suppression message is completely the same as 
  a NACK/FIR. 

  
 

  
Regards

  
Tom

  
 

  
 

  
 

  
 

  


  

  

  


--Boundary_(ID_pEdGKNX2QyibSs/ZBa2Evg)--

From sunseawq@huawei.com  Tue Oct 19 20:44:49 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BADB3A6997 for ; Tue, 19 Oct 2010 20:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.728
X-Spam-Level: 
X-Spam-Status: No, score=0.728 tagged_above=-999 required=5 tests=[AWL=0.338,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uus2Vx1FzGoJ for ; Tue, 19 Oct 2010 20:44:47 -0700 (PDT)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 653E03A68C5 for ; Tue, 19 Oct 2010 20:44:47 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAK0018HL4WN7@szxga02-in.huawei.com> for avt@ietf.org; Wed, 20 Oct 2010 11:46:09 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAK00GRPL4WWB@szxga02-in.huawei.com> for avt@ietf.org; Wed, 20 Oct 2010 11:46:08 +0800 (CST)
Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAK00CPQL4WPK@szxml06-in.huawei.com> for avt@ietf.org; Wed, 20 Oct 2010 11:46:08 +0800 (CST)
Date: Wed, 20 Oct 2010 11:46:08 +0800
From: Qin Wu 
To: avt@ietf.org
Message-id: <038f01cb7009$5481cb40$30298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: multipart/alternative; boundary="Boundary_(ID_27x1usNpWzQkE6HBs06giQ)"
X-Priority: 3
X-MSMail-priority: Normal
Cc: VAN CAENEGEM Tom , 'Roni Even' 
Subject: [AVT] Fw: New Version Notification for draft-wu-avt-retransmission-supression-rtp-04
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 03:44:49 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_27x1usNpWzQkE6HBs06giQ)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Tom:
I get your concern now. The RAMS architecure in your mind is one media source-> one distribution source -> multiple BRS in parallel-> the recievers behind each BRS.
In this scenario one distribution source is placed between media source and BRS for relaying SSM stream from media source. The BRS will receive the SSM stream from the DS. Suppose there are several BRSes behind the distribution source or media source, there may be just one BRS that detects packet loss on its upstream link between the distribution source and BRS, but the others will perhaps not, as the packet loss took place on SSM tree branch that does not impact the other BRSes. 

In this case, event the distribution source with loss detection functionality support can not detect packet loss at the downstream of itself, therefore the distribution source SHOULD NOT create new Feedback Suppression message and send it to all the BRS. In order to address this case, If BRS has loss detection support, the BRS MAY choose to create new  Feedback Suppression message and send it to the receivers behind this BRS.

In this way, the packet loss took place on SSM tree branch will not impact other BRSes.
Hope this clarifies.

BTW: I can add this use case to address your concern in the new version.

Regards!
-Qin
  ----- Original Message ----- 
  From: Van Caenegem, Tom (Tom) 
  To: Roni Even ; 'Qin Wu' ; avt@ietf.org 
  Sent: Tuesday, October 19, 2010 11:30 PM
  Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04


  Hi Roni,

  In the typical RAMS architecture, the BRS will receive the SSM stream from the DS. If there are several BRS-es, there may be just one BRS that detects packet loss on its upstream link, but the others will perhaps not, as the packet loss took place on SSM tree branch that does not impact the other BRSes. In that case those RTP receivers associated to the other BRS-es in general will not be impacted and do not need to receive the suppression indication, while the one BRS that did sense the packet loss should probably best send a suppression indication (although there is a chance that only this BRS is impacted by packet loss, and not a single RTP receiver in the field reporting to this BRS/FT... this all depends on the considered topologies). 

  As a BRS is 1-to-1 associated with a FT, this calls for consideration of architectures with (multiple) disjoint FT (and associated BRS in RAMS applications)  in the suppression draft. Such disjoint FT/BRS in general cannot act as so-called "intermediate nodes" or "translators" because they are not on the direct SSM path between the DS and the RTP receivers. 

  Another aspect I want to highlight is that feedback suppression is closely aligned with retransmission. In the case described above, the one BRS that detected packet loss on its upstream link, may try to recover the missing packet (outside the scope of the draft) and retransmit over multicast to the receivers that report to the FT. This retransmission towards the receivers is also outside the current scope of the current draft, but the two are somehow linked.  In DVB IPTV, we introduced dedicated SSMs sourced by the BRS for sending NACK suppression and the (optional) retransmission. In the considered scenario, having a DS sending a missing packet -reported by a FT downstream in the SSM tree- over the original SSM is not a good approach IMO, as it results in general in unnecessary retransmissions for most receivers.

  Hope this clarifies.

  Tom


------------------------------------------------------------------------------

  From: Roni Even [mailto:Even.roni@huawei.com] 
  Sent: dinsdag 19 oktober 2010 16:46
  To: Van Caenegem, Tom (Tom); 'Qin Wu'; avt@ietf.org
  Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-04


  Hi Tom,

  I want to clarify your example since I am not sure what is special here. The BRS sends separate unicast streams to each participant so there is reason for suppression on these unicast streams. As for the primary multicast stream from the DS it goes to all receivers. Now if the BRS identify packet loss on the primary stream it should send suppression indication to all members of the multicast group regardless to which FT they report.

  Can you clarify

   

  Roni Even

--Boundary_(ID_27x1usNpWzQkE6HBs06giQ)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT









Tom:


I get your concern now. The RAMS architecure in your mind is one media 
source-> one distribution source -> multiple BRS in parallel-> the 
recievers behind each BRS.


In this scenario one distribution source is placed between media source and 
BRS for relaying SSM stream from media source. The BRS will receive the SSM 
stream from the DS. Suppose there are several BRSes behind the distribution 
source or media source, there may be just one BRS that detects packet loss on 
its upstream link between the distribution source and BRS, but the others will 
perhaps not, as the packet loss took place on SSM tree branch that does not 
impact the other BRSes. 


 


In this case, event the distribution source with loss detection 
functionality support can not detect packet loss at the downstream of itself, 
therefore the distribution source SHOULD NOT create new Feedback Suppression 
message and send it to all the BRS. In order to address this case, If BRS has 
loss detection support, the BRS MAY choose to create 
new  Feedback Suppression message and send it to the receivers behind 
this BRS.


 


In this way, the packet loss took place on SSM tree branch will not impact 
other BRSes.


Hope this clarifies.


 


BTW: I can add this use case to address your concern in the new 
version.


 


Regards!


-Qin



  
----- Original Message ----- 

  
  
  
Sent: Tuesday, October 19, 2010 11:30 
PM

  
Subject: RE: [AVT] New Version Notification 
  for draft-wu-avt-retransmission-supression-rtp-04

  


  
Hi Roni,

  
 

  
In the typical 
  RAMS architecture, the BRS will receive the SSM stream from the DS. If there 
  are several BRS-es, there may be just one BRS that detects packet loss on its 
  upstream link, but the others will perhaps not, as the packet loss took place 
  on SSM tree branch that does not impact the other BRSes. In that case 
  those RTP receivers associated to the other BRS-es in general will not be 
  impacted and do not need to receive the suppression indication, while the one 
  BRS that did sense the packet loss should probably best send a suppression 
  indication (although there is a chance that only this BRS is impacted by 
  packet loss, and not a single RTP receiver in the field reporting to this 
  BRS/FT... this all depends on the considered topologies). 

  
 

  
As a BRS is 
  1-to-1 associated with a FT, this calls for consideration of architectures 
  with (multiple) disjoint FT (and associated BRS in RAMS applications)  in 
  the suppression draft. Such disjoint FT/BRS in general cannot act as so-called 
  "intermediate nodes" or "translators" because they are not on the direct SSM 
  path between the DS and the RTP receivers. 

  
 

  
Another aspect 
  I want to highlight is that feedback suppression is closely aligned with 
  retransmission. In the case described above, the one BRS that detected packet 
  loss on its upstream link, may try to recover the missing packet (outside the 
  scope of the draft) and retransmit over multicast to the receivers that report 
  to the FT. This retransmission towards the receivers is also outside the 
  current scope of the current draft, but the two are somehow linked.  In 
  DVB IPTV, we introduced dedicated SSMs sourced by the BRS for sending 
  NACK suppression and the (optional) retransmission. In the considered 
  scenario, having a DS sending a missing packet -reported by a FT downstream in 
  the SSM tree- over the original SSM is not a good approach IMO, as it 
  results in general in unnecessary retransmissions for most 
  receivers.

  
 

  
Hope this 
  clarifies.

  
 

  
Tom

  
 

  

  

  

  
From: Roni Even [mailto:Even.roni@huawei.com] 
  
Sent: dinsdag 19 oktober 2010 16:46
To: Van Caenegem, Tom 
  (Tom); 'Qin Wu'; avt@ietf.org
Subject: RE: [AVT] New Version 
  Notification for 
  draft-wu-avt-retransmission-supression-rtp-04


  

  

  
Hi 
  Tom,

  
I 
  want to clarify your example since I am not sure what is special here. The BRS 
  sends separate unicast streams to each participant so there is reason for 
  suppression on these unicast streams. As for the primary multicast stream from 
  the DS it goes to all receivers. Now if the BRS identify packet loss on the 
  primary stream it should send suppression indication to all members of the 
  multicast group regardless to which FT they report.

  
Can 
  you clarify

  
 

  
Roni 
  Even


--Boundary_(ID_27x1usNpWzQkE6HBs06giQ)--

From sunseawq@huawei.com  Tue Oct 19 22:41:53 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370063A69BE for ; Tue, 19 Oct 2010 22:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.281
X-Spam-Level: 
X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[AWL=0.776,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKZmFpKooncR for ; Tue, 19 Oct 2010 22:41:52 -0700 (PDT)
Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CE7A13A69C5 for ; Tue, 19 Oct 2010 22:41:50 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAK006DKQK0VX@szxga05-in.huawei.com> for avt@ietf.org; Wed, 20 Oct 2010 13:43:12 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAK0094OQK038@szxga05-in.huawei.com> for avt@ietf.org; Wed, 20 Oct 2010 13:43:12 +0800 (CST)
Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAK00GVUQJWFZ@szxml04-in.huawei.com> for avt@ietf.org; Wed, 20 Oct 2010 13:43:10 +0800 (CST)
Date: Wed, 20 Oct 2010 13:43:00 +0800
From: Qin Wu 
To: avt@ietf.org
Message-id: <049b01cb7019$adbe1500$30298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: multipart/mixed; boundary="Boundary_(ID_JsuVVJGM00InnParmOIafQ)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [AVT] Fw: I-D Action:draft-wu-avt-retransmission-supression-rtp-05.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 05:41:53 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_JsuVVJGM00InnParmOIafQ)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

Hi, folks:
The new version of draft-wu-avt-retransmission-supression-rtp is available at:
 http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-05.txt
We tried to address the comments regarding the example on how Feedback Suppression mechanism is used 
with the RAMS scenario in the new section 6.2 "Unicast based Rapid Acquisition of Multicast Stream (RAMS) use case".

To be clear, this mechanism is used as a suppression indication from the server (or  intermediary) to the client. It tells RTP receivers 
explicitly that feedback for a particular packet loss is  not needed before the RTP receiver reacts to the loss and invokes 
its packet loss repair machinery. This mechanism can works for all the Feedback implosion use case.

Regards!
-Qin
----- Original Message ----- 
From: 
To: 
Sent: Wednesday, October 20, 2010 12:45 PM
Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-05.txt


>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : RTCP Report Extension for Feedback Suppression
> Author(s)       : Q. Wu, et al.
> Filename        : draft-wu-avt-retransmission-supression-rtp-05.txt
> Pages           : 22
> Date            : 2010-10-19
> 
> When packet loss close to the media source or intermediary of the
> session is detected as a loss by a large number of receivers, large
> number of feedback requests used to ask for the lost RTP packets are
> all addressed to the same media source, or a designated feedback
> target.  This may result in a phenomenon known variously as a
> "feedback storm " or "feedback implosion ".
> 
> This document specifies an extension to the RTCP feedback messages
> defined in the Audio-Visual Profile with Feedback (AVPF).  This
> extension allows an intermediate node in the network (such as an RTP
> translator) inform downstream receivers that packet loss was detected
> and sending a feedback message concerning a specified set of RTP
> packets may be unnecessary, or even harmful.  Receivers respond to
> receipt of a feedback suppression message by not sending a feedback
> message (e.g. a NACK) that they otherwise would, This in turn reduces
> load on both the feedback target and on the network.  The proposed
> extension is useful for single-source multicast sessions.  In
> addition, it can be applied to any other types of RTP sessions and
> topologies that might benefit from feedback suppression mechanism.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-05.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>


--------------------------------------------------------------------------------


> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

--Boundary_(ID_JsuVVJGM00InnParmOIafQ)
Content-type: text/plain; name=draft-wu-avt-retransmission-supression-rtp-05.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment;
 filename=draft-wu-avt-retransmission-supression-rtp-05.txt

Content-Type: text/plain
Content-ID: <2010-10-19214430.I-D@ietf.org>


--Boundary_(ID_JsuVVJGM00InnParmOIafQ)--

From paromitaz@gmail.com  Wed Oct 20 01:24:26 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632883A681A for ; Wed, 20 Oct 2010 01:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozKE2igxQ1Qn for ; Wed, 20 Oct 2010 01:24:25 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 48DCB3A680E for ; Wed, 20 Oct 2010 01:24:24 -0700 (PDT)
Received: by bwz14 with SMTP id 14so2631691bwz.31 for ; Wed, 20 Oct 2010 01:25:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=BXCrt0ebXs3SwcIdIHB1YnsAmYGshqNCAqot2fy9oAE=; b=HN1B2XufPeZIfHhECvYT3Vu8/ddeuBlbreQ9bW7/CU0+yzpLK47Ci3YIFge/dKX6WP eQN+WKthLHRArr4pECOIHE6PlvWuO8he5G+gzoJKeAOwkfxbt5MNhuEt61rWdQhpx2jg ov1h9RUm14RaRGA8lzSiNdHMRA5pr1fkz90vo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VuvzzkTDPe7+l/PBhCX4kpaED7S68Q6EBoHJNMxOuk5owiI2LJmIwa19xrGEBWHmMk 16FBVTPxO+GSTYPvzjacWmjiRz7U1etaGVEjmjiPweb3OZOIn5hNEpbjmQz08YH3CUGH +e7a5IqOKxAwGvgNZtagooAA7CeHnThWdlcPI=
MIME-Version: 1.0
Received: by 10.204.76.205 with SMTP id d13mr6530254bkk.93.1287563156714; Wed, 20 Oct 2010 01:25:56 -0700 (PDT)
Received: by 10.204.62.75 with HTTP; Wed, 20 Oct 2010 01:25:56 -0700 (PDT)
Date: Wed, 20 Oct 2010 01:25:56 -0700
Message-ID: 
From: paromita chowdhury 
To: avt@ietf.org
Content-Type: multipart/alternative; boundary=00163649a2f594f4de0493082884
Subject: [AVT] SSRC change in a single RTP session
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 08:32:40 -0000

--00163649a2f594f4de0493082884
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have read the RTP rfc 3550 a couple of times, still have a doubt on the
following issue:

- If a RTP unicast session with no change in the source and destination
address, changes its SSRC during the call session is it permissible? In
other words, between the same pair of source and destination addresses, can
a change in the SSRC value acceptable at the destination?

I request the experts in this field to respond to this query?

Thanks
PC

--00163649a2f594f4de0493082884
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

I have read the RTP rfc 3550 a couple of times, still have a dou=
bt on the following issue:

- If a RTP unicast session with no change=
 in the source and destination address, changes its SSRC during the call se=
ssion is it permissible? In other words, between the same pair of source an=
d destination addresses, can a change in the SSRC value acceptable at the d=
estination?


I request the experts in this field to respond to this query?

Th=
anks
PC


--00163649a2f594f4de0493082884--

From csp@csperkins.org  Wed Oct 20 01:52:39 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C0D3A6867 for ; Wed, 20 Oct 2010 01:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.459
X-Spam-Level: 
X-Spam-Status: No, score=-103.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUhDwoArZVV8 for ; Wed, 20 Oct 2010 01:52:38 -0700 (PDT)
Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id EDDD73A684A for ; Wed, 20 Oct 2010 01:52:37 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P8UR0-00055Y-ad; Wed, 20 Oct 2010 08:54:10 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary=Apple-Mail-248-20003757
From: Colin Perkins 
In-Reply-To: 
Date: Wed, 20 Oct 2010 09:54:08 +0100
Message-Id: <2F4E0AC9-6542-4153-A652-9FEF6CB870B0@csperkins.org>
References: 
To: paromita chowdhury 
X-Mailer: Apple Mail (2.1081)
Cc: avt@ietf.org
Subject: Re: [AVT] SSRC change in a single RTP session
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 08:52:39 -0000

--Apple-Mail-248-20003757
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 20 Oct 2010, at 09:25, paromita chowdhury wrote:
> I have read the RTP rfc 3550 a couple of times, still have a doubt on =
the following issue:
>=20
> - If a RTP unicast session with no change in the source and =
destination address, changes its SSRC during the call session is it =
permissible? In other words, between the same pair of source and =
destination addresses, can a change in the SSRC value acceptable at the =
destination?


Yes, the SSRC can change. In addition, you might see multiple SSRCs on =
the session (a unicast session is not restricted to one single SSRC from =
each participant, or even only two participants, since one may be an RTP =
translator or mixer).=20

--=20
Colin Perkins
http://csperkins.org/




--Apple-Mail-248-20003757
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

I have read the RTP rfc 3550 a =
couple of times, still have a doubt on the following issue:

- If =
a RTP unicast session with no change in the source and destination =
address, changes its SSRC during the call session is it permissible? In =
other words, between the same pair of source and destination addresses, =
can a change in the SSRC value acceptable at the =
destination?

Yes, the SSRC =
can change. In addition, you might see multiple SSRCs on the session (a =
unicast session is not restricted to one single SSRC from each =
participant, or even only two participants, since one may be an RTP =
translator or mixer). 

-- 
Colin Perkins






=

--Apple-Mail-248-20003757--

From paromitaz@gmail.com  Wed Oct 20 02:08:40 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E683A6840 for ; Wed, 20 Oct 2010 02:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level: 
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUJU9LNvXhv3 for ; Wed, 20 Oct 2010 02:08:39 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E88233A67DA for ; Wed, 20 Oct 2010 02:08:38 -0700 (PDT)
Received: by bwz14 with SMTP id 14so2655791bwz.31 for ; Wed, 20 Oct 2010 02:10:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=l8X0HW9AELu1qPAyHwuz/gBpsBTT2s1dHYosQ0324D0=; b=QXPM3V1FaggXyGRqV/NgLy6M3w4KteZwblBOF9VnQFfPQkRZiRiq9A8YerbwhOyQaK M8eAesZ1vzAqD/G4KpMHCxtjNS8k0qCsKR3eUuZMoPGFK9Zkqk/Eov3GtWDMsHF6LSJS PhouysJ2TG8LKdvlhIcTa8p+2dpMFlqFUU1zQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UInL3TPlcNO+seCSMXfrDnxmYH2/QeMGG//0d/gU6KyZTtnJZAWk6F0wLpJ8TpjMd8 sJCFBPQwk3Dw081zkU/Ln3H9+/7jYzKUnfFWqS/Ce2uHmRFe2mK8ts9/vIUM+WRK/bKC ikk/aptaTzy8NuQFxxT7nG8DAOMOWikrL4QQM=
MIME-Version: 1.0
Received: by 10.204.136.71 with SMTP id q7mr6722725bkt.111.1287565809682; Wed, 20 Oct 2010 02:10:09 -0700 (PDT)
Received: by 10.204.62.75 with HTTP; Wed, 20 Oct 2010 02:10:09 -0700 (PDT)
In-Reply-To: <2F4E0AC9-6542-4153-A652-9FEF6CB870B0@csperkins.org>
References:  <2F4E0AC9-6542-4153-A652-9FEF6CB870B0@csperkins.org>
Date: Wed, 20 Oct 2010 02:10:09 -0700
Message-ID: 
From: paromita chowdhury 
To: avt@ietf.org
Content-Type: multipart/alternative; boundary=0015174befdcb60b0d049308c609
Cc: csp@csperkins.org
Subject: Re: [AVT] SSRC change in a single RTP session
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 09:08:40 -0000

--0015174befdcb60b0d049308c609
Content-Type: text/plain; charset=ISO-8859-1

I noticed in a audio(VoIP) call with no change in the source or destination
IP addresses, the ssrc value of side of the communication changed while the
call was still going.

I find in the RFC 3550 that ssrc may change when one of the endpoint changes
but it mentions nothing about the scenario when endpoints do not change. Can
you please point/direct me to the section of the RFC stating it?

Thanks

On 20 October 2010 01:54, Colin Perkins  wrote:

> On 20 Oct 2010, at 09:25, paromita chowdhury wrote:
>
> I have read the RTP rfc 3550 a couple of times, still have a doubt on the
> following issue:
>
> - If a RTP unicast session with no change in the source and destination
> address, changes its SSRC during the call session is it permissible? In
> other words, between the same pair of source and destination addresses, can
> a change in the SSRC value acceptable at the destination?
>
>
> Yes, the SSRC can change. In addition, you might see multiple SSRCs on the
> session (a unicast session is not restricted to one single SSRC from each
> participant, or even only two participants, since one may be an RTP
> translator or mixer).
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
>

--0015174befdcb60b0d049308c609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I noticed in a audio(VoIP) call with no change in the source or destination=
 IP addresses, the ssrc value of side of the communication changed while th=
e call was still going. 

I find in the RFC 3550 that ssrc may change=
 when one of the endpoint changes but it mentions nothing about the scenari=
o when endpoints do not change. Can you please point/direct me to the secti=
on of the RFC stating it?


Thanks

On 20 October 2010 01:54, Coli=
n Perkins <csp@cs=
perkins.org> wrote:


On 20 Oct=
 2010, at 09:25, paromita chowdhury wrote:
I=
 have read the RTP rfc 3550 a couple of times, still have a doubt on the fo=
llowing issue:


- If a RTP unicast session with no change in the source and destination=
 address, changes its SSRC during the call session is it permissible? In ot=
her words, between the same pair of source and destination addresses, can a=
 change in the SSRC value acceptable at the destination?




Yes, the SSRC can change. In addition, you might see multiple SSRCs on the =
session (a unicast session is not restricted to one single SSRC from each p=
articipant, or even only two participants, since one may be an RTP translat=
or or mixer).=A0


--=A0
Colin Perkins





--0015174befdcb60b0d049308c609--

From csp@csperkins.org  Wed Oct 20 02:42:25 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E923A6874 for ; Wed, 20 Oct 2010 02:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.467
X-Spam-Level: 
X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWQRZ-2VIYOd for ; Wed, 20 Oct 2010 02:42:23 -0700 (PDT)
Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by core3.amsl.com (Postfix) with ESMTP id 282763A693B for ; Wed, 20 Oct 2010 02:39:11 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P8V8D-00016r-eQ; Wed, 20 Oct 2010 09:39:23 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary=Apple-Mail-250-22682735
From: Colin Perkins 
In-Reply-To: 
Date: Wed, 20 Oct 2010 10:38:47 +0100
Message-Id: 
References:  <2F4E0AC9-6542-4153-A652-9FEF6CB870B0@csperkins.org> 
To: paromita chowdhury 
X-Mailer: Apple Mail (2.1081)
Cc: avt@ietf.org
Subject: Re: [AVT] SSRC change in a single RTP session
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 09:42:25 -0000

--Apple-Mail-250-22682735
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

An SSRC collision can happen at any time, and will force a change of =
SSRC. A new participant can join at any time, causing new SSRCs to =
appear. An existing participant may decide to send an additional media =
stream into a session, causing a new SSRC to appear. An application may =
restart, causing an SSRC change. A source may change its transport =
address requiring an SSRC change, but do so behind a NAT such that you =
don't see the change of transport address. An implementation may be =
broken, and change its SSRC for no reason.

Don't assume the SSRC is constant. Nothing in RFC 3550 requires it to =
be, and there are many things that may cause it to change.

Colin


On 20 Oct 2010, at 10:10, paromita chowdhury wrote:
> I noticed in a audio(VoIP) call with no change in the source or =
destination IP addresses, the ssrc value of side of the communication =
changed while the call was still going.=20
>=20
> I find in the RFC 3550 that ssrc may change when one of the endpoint =
changes but it mentions nothing about the scenario when endpoints do not =
change. Can you please point/direct me to the section of the RFC stating =
it?
>=20
> Thanks
>=20
> On 20 October 2010 01:54, Colin Perkins  wrote:
> On 20 Oct 2010, at 09:25, paromita chowdhury wrote:
>> I have read the RTP rfc 3550 a couple of times, still have a doubt on =
the following issue:
>>=20
>> - If a RTP unicast session with no change in the source and =
destination address, changes its SSRC during the call session is it =
permissible? In other words, between the same pair of source and =
destination addresses, can a change in the SSRC value acceptable at the =
destination?
>=20
>=20
> Yes, the SSRC can change. In addition, you might see multiple SSRCs on =
the session (a unicast session is not restricted to one single SSRC from =
each participant, or even only two participants, since one may be an RTP =
translator or mixer).=20
>=20
> --=20
> Colin Perkins
> http://csperkins.org/


--Apple-Mail-250-22682735
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

An =
SSRC collision can happen at any time, and will force a change of SSRC. =
A new participant can join at any time, causing new SSRCs to appear. An =
existing participant may decide to send an additional media stream into =
a session, causing a new SSRC to appear. An application may restart, =
causing an SSRC change. A source may change its transport address =
requiring an SSRC change, but do so behind a NAT such that you don't see =
the change of transport address. An implementation may be broken, and =
change its SSRC for no reason.

Don't assume the SSRC =
is constant. Nothing in RFC 3550 requires it to be, and there are many =
things that may cause it to =
change.

Colin


On 20 Oct 2010, at 10:10, paromita chowdhury =
wrote:
I noticed in a audio(VoIP) call =
with no change in the source or destination IP addresses, the ssrc value =
of side of the communication changed while the call was still going. =


I find in the RFC 3550 that ssrc may change when one of the =
endpoint changes but it mentions nothing about the scenario when =
endpoints do not change. Can you please point/direct me to the section =
of the RFC stating it?


Thanks

On 20 October 2010 01:54, =
Colin Perkins <csp@csperkins.org> =
wrote:


On 20 =
Oct 2010, at 09:25, paromita chowdhury wrote:
I have read the RTP rfc 3550 a couple of times, still have =
a doubt on the following issue:


- If a RTP unicast session with no change in the source and =
destination address, changes its SSRC during the call session is it =
permissible? In other words, between the same pair of source and =
destination addresses, can a change in the SSRC value acceptable at the =
destination?




Yes, the SSRC can change. In addition, you might see multiple SSRCs on =
the session (a unicast session is not restricted to one single SSRC from =
each participant, or even only two participants, since one may be an RTP =
translator or mixer). 


-- 
Colin Perkins

=

--Apple-Mail-250-22682735--

From paromitaz@gmail.com  Wed Oct 20 02:44:26 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981F03A63CB for ; Wed, 20 Oct 2010 02:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level: 
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x1ZtmYNB2C2 for ; Wed, 20 Oct 2010 02:44:25 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id F274A3A6359 for ; Wed, 20 Oct 2010 02:44:24 -0700 (PDT)
Received: by bwz14 with SMTP id 14so2676216bwz.31 for ; Wed, 20 Oct 2010 02:45:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=eqCvc4e7Y5Ncr727+VBJcy2zydpy6ihk9sY1tdBOOPY=; b=x7f1stdNg0LQpMjX/1bvtF2CxfqylxeiiQexrV3ari8Z7Orbxez+bMkREQS8N+wjfC m4UYRqaEXl100Bjlea/YkaUrgR0vPrvFoEC8EHd/x3Eynmu8ao9ThrTMX+12mbYrLFXn MwRyiRR5utAYXpEqsUTWkTa1nHgfsEa4xgyQY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=dgUd+94/qpo6m8wNU14/O4hmm+QsDR6Ys6DuHN0Azxm2CGOjMpNu4xWspn2QawDQ3i qYF7kb1wT2/r2uM0BGhbbs57vLKyAFTWLMZSdOLl/iRN8GVfF6ug14TIsfU/Zs9gGrvA eA7q/rMaDaXtZxDf7Jt4kh/EYl9YsS65ZniM4=
MIME-Version: 1.0
Received: by 10.204.80.97 with SMTP id s33mr6575518bkk.182.1287567956886; Wed, 20 Oct 2010 02:45:56 -0700 (PDT)
Received: by 10.204.62.75 with HTTP; Wed, 20 Oct 2010 02:45:56 -0700 (PDT)
In-Reply-To: 
References:  <2F4E0AC9-6542-4153-A652-9FEF6CB870B0@csperkins.org>  
Date: Wed, 20 Oct 2010 02:45:56 -0700
Message-ID: 
From: paromita chowdhury 
To: avt@ietf.org
Content-Type: multipart/alternative; boundary=0016e6dbdf47b1cbb70493094682
Subject: Re: [AVT] SSRC change in a single RTP session
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 09:44:26 -0000

--0016e6dbdf47b1cbb70493094682
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the response.. it clarified my doubt

On 20 October 2010 02:38, Colin Perkins  wrote:

> An SSRC collision can happen at any time, and will force a change of SSRC.
> A new participant can join at any time, causing new SSRCs to appear. An
> existing participant may decide to send an additional media stream into a
> session, causing a new SSRC to appear. An application may restart, causing
> an SSRC change. A source may change its transport address requiring an SSRC
> change, but do so behind a NAT such that you don't see the change of
> transport address. An implementation may be broken, and change its SSRC for
> no reason.
>
> Don't assume the SSRC is constant. Nothing in RFC 3550 requires it to be,
> and there are many things that may cause it to change.
>
> Colin
>
>
>
> On 20 Oct 2010, at 10:10, paromita chowdhury wrote:
>
> I noticed in a audio(VoIP) call with no change in the source or destination
> IP addresses, the ssrc value of side of the communication changed while the
> call was still going.
>
> I find in the RFC 3550 that ssrc may change when one of the endpoint
> changes but it mentions nothing about the scenario when endpoints do not
> change. Can you please point/direct me to the section of the RFC stating it?
>
> Thanks
>
> On 20 October 2010 01:54, Colin Perkins  wrote:
>
>> On 20 Oct 2010, at 09:25, paromita chowdhury wrote:
>>
>> I have read the RTP rfc 3550 a couple of times, still have a doubt on the
>> following issue:
>>
>> - If a RTP unicast session with no change in the source and destination
>> address, changes its SSRC during the call session is it permissible? In
>> other words, between the same pair of source and destination addresses, can
>> a change in the SSRC value acceptable at the destination?
>>
>>
>> Yes, the SSRC can change. In addition, you might see multiple SSRCs on the
>> session (a unicast session is not restricted to one single SSRC from each
>> participant, or even only two participants, since one may be an RTP
>> translator or mixer).
>>
>> --
>> Colin Perkins
>> http://csperkins.org/
>>
>
>

--0016e6dbdf47b1cbb70493094682
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for the response.. it clarified my doubt

On 20 October 2010 02:38, Colin Perkins <csp@csperkins.org> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2=
04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

An SSRC collision can happen at any t=
ime, and will force a change of SSRC. A new participant can join at any tim=
e, causing new SSRCs to appear. An existing participant may decide to send =
an additional media stream into a session, causing a new SSRC to appear. An=
 application may restart, causing an SSRC change. A source may change its t=
ransport address requiring an SSRC change, but do so behind a NAT such that=
 you don't see the change of transport address. An implementation may b=
e broken, and change its SSRC for no reason.


Don't assume the SSRC is constant. Nothing in RFC 3550 r=
equires it to be, and there are many things that may cause it to change.

Colin





On 20 Oct 2010=
, at 10:10, paromita chowdhury wrote:
I noti=
ced in a audio(VoIP) call with no change in the source or destination IP ad=
dresses, the ssrc value of side of the communication changed while the call=
 was still going. 


I find in the RFC 3550 that ssrc may change when one of the endpoint ch=
anges but it mentions nothing about the scenario when endpoints do not chan=
ge. Can you please point/direct me to the section of the RFC stating it?


Thanks

On 20 October 2010 01:54, Coli=
n Perkins <csp@csperkins.org> wrote:



On 20 Oct 2010, at 09:=
25, paromita chowdhury wrote:
I have read th=
e RTP rfc 3550 a couple of times, still have a doubt on the following issue=
:



- If a RTP unicast session with no change in the source and destination=
 address, changes its SSRC during the call session is it permissible? In ot=
her words, between the same pair of source and destination addresses, can a=
 change in the SSRC value acceptable at the destination?






Yes, the SSRC can change. In addition, you might see multiple SSRCs on the =
session (a unicast session is not restricted to one single SSRC from each p=
articipant, or even only two participants, since one may be an RTP translat=
or or mixer).=A0



--=A0
Colin Perkins






--0016e6dbdf47b1cbb70493094682--

From csp@csperkins.org  Wed Oct 20 06:50:19 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8162F3A67CF for ; Wed, 20 Oct 2010 06:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.475
X-Spam-Level: 
X-Spam-Status: No, score=-103.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRkkv0PA2GIz for ; Wed, 20 Oct 2010 06:50:18 -0700 (PDT)
Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id E64313A680D for ; Wed, 20 Oct 2010 06:50:17 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P8Z54-0003Pm-iS; Wed, 20 Oct 2010 13:51:50 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins 
In-Reply-To: <002d01cb6cd6$b24e2ce0$3c298a0a@china.huawei.com>
Date: Wed, 20 Oct 2010 14:51:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <002d01cb6cd6$b24e2ce0$3c298a0a@china.huawei.com>
To: Jinwei Xia 
X-Mailer: Apple Mail (2.1081)
Cc: 'IETF AVT WG' 
Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-splicing-for-rtp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 13:50:19 -0000

Hi Jinwei,

My impression is that this draft confuses the issue by focussing too =
much on scenarios where the content to be inserted is also delivered =
over RTP. Whether the content to be inserted is delivered as a real-time =
RTP stream or fetched from local file storage does not affect the =
insertion process, and so doesn't need to be mentioned in the draft. I =
still believe that a standard RTP translator is sufficient to solve this =
problem, although there may be useful things to say about how to =
efficiently implement such a translator.=20

Colin


On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
> Hi,
>=20
> =46rom the discussion on IETF 78th, there were some misunderstandings =
of the scope of splicing draft. So we discard previous problem statement =
draft while initiate new solution draft. In this new draft, We emphysize =
content insertion issue is indeed a RTP-generic rather than MPEG2 =
TS-specific.=20
>=20
> Hope the new draft can address most issues AVT concern, any comments =
are very appreciated!
>=20
>=20
> BR!
>=20
> Jinwei=20
>=20
>> -----Original Message-----
>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20
>> Sent: Saturday, October 16, 2010 9:58 AM
>> To: xiajinwei@huawei.com
>> Subject: New Version Notification for=20
>> draft-xia-avt-splicing-for-rtp-00
>>=20
>>=20
>> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt=20
>> has been successfully submitted by Jinwei Xia and posted to=20
>> the IETF repository.
>>=20
>> Filename:	 draft-xia-avt-splicing-for-rtp
>> Revision:	 00
>> Title:		 Content Splicing for RTP Sessions
>> Creation_date:	 2010-10-16
>> WG ID:		 Independent Submission
>> Number_of_pages: 12
>>=20
>> Abstract:
>> This memo outlines RTP splicing.  Splicing is a process that=20
>> allows a new multimedia stream to be inserted into current=20
>> multimedia stream and to be conveyed to receiver for a period=20
>> of time.  This memo discusses the requirements of RTP=20
>> splicing.  In order to satisfy the requirements, this memo=20
>> lists several existing intermediary network elements as=20
>> alternatives and evaluates whether one of alternatives can be=20
>> used to perform RTP splicing.
>>=20
>>=20
>>=20
>>=20
>> The IETF Secretariat.
>>=20
>>=20
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt



--=20
Colin Perkins
http://csperkins.org/




From csp@csperkins.org  Wed Oct 20 15:01:01 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BE603A69A5 for ; Wed, 20 Oct 2010 15:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.416
X-Spam-Level: 
X-Spam-Status: No, score=-103.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK5IPOAw3qcK for ; Wed, 20 Oct 2010 15:01:00 -0700 (PDT)
Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id 04ACB3A699D for ; Wed, 20 Oct 2010 15:01:00 -0700 (PDT)
Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.22]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P8gjx-0003GZ-YA; Wed, 20 Oct 2010 22:02:33 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins 
X-Priority: 3
In-Reply-To: <057f01cb6ad2$b3e86760$30298a0a@china.huawei.com>
Date: Wed, 20 Oct 2010 23:02:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057f01cb6ad2$b3e86760$30298a0a@china.huawei.com>
To: Qin Wu 
X-Mailer: Apple Mail (2.1081)
Cc: avt@ietf.org
Subject: Re: [AVT] Fw: New Version Notification for draft-wu-avt-rtcp-xr-quality-monitoring-04
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 22:01:01 -0000

Qin,

Thanks for updating this. These changes address my concerns.

Colin


On 13 Oct 2010, at 13:32, Qin Wu wrote:
> Hi, folks:
> 04 version is posted which addresses the comments from Colin
> * Add some text to General Synchronisation Offset Metrics Block to =
allow
>  more than two stream in the RTP multimedia session.
> * Clarify the Picture Type in the terminology section
> * Separate TR 101 290 decodability metrics report from this draft
> Your comments and suggestions are welcome!
>=20
> Regards!
> -Qin
> ----- Original Message -----=20
> From: "IETF I-D Submission Tool" 
> To: 
> Cc: ; 
> Sent: Wednesday, October 13, 2010 8:16 PM
> Subject: New Version Notification for =
draft-wu-avt-rtcp-xr-quality-monitoring-04
>=20
>=20
>>=20
>> A new version of I-D, draft-wu-avt-rtcp-xr-quality-monitoring-04.txt =
has been successfully submitted by Wenson Wu and posted to the IETF =
repository.
>>=20
>> Filename: draft-wu-avt-rtcp-xr-quality-monitoring
>> Revision: 04
>> Title: RTP Control Protocol Extended Reports (RTCP XR) Report Blocks =
for Real- time Video Quality Monitoring
>> Creation_date: 2010-10-13
>> WG ID: Independent Submission
>> Number_of_pages: 22
>>=20
>> Abstract:
>> This document defines a set of RTP Control Protocol Extended Reports
>> (RTCP XR) Report Blocks and associated SDP parameters allowing the
>> report of video quality metrics, primarily for video applications of
>> RTP.
>>=20
>>=20
>>=20
>> The IETF Secretariat.
>>=20
>>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt



--=20
Colin Perkins
http://csperkins.org/




From xiajinwei@huawei.com  Wed Oct 20 23:32:04 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845473A69A9 for ; Wed, 20 Oct 2010 23:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbrfHChZijBY for ; Wed, 20 Oct 2010 23:32:03 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6DEB63A6944 for ; Wed, 20 Oct 2010 23:32:02 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM00IH5NJQ4O@szxga03-in.huawei.com> for avt@ietf.org; Thu, 21 Oct 2010 14:33:26 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM008F6NJQ5K@szxga03-in.huawei.com> for avt@ietf.org; Thu, 21 Oct 2010 14:33:26 +0800 (CST)
Received: from x65217 ([10.138.41.60]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAM0056ONJQF6@szxml06-in.huawei.com> for avt@ietf.org; Thu, 21 Oct 2010 14:33:26 +0800 (CST)
Date: Thu, 21 Oct 2010 14:33:25 +0800
From: Jinwei Xia 
In-reply-to: 
To: 'Colin Perkins' 
Message-id: <005c01cb70e9$ddfbd1f0$3c298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: ActwXfOE1MgvvvDaTHGrv49r1tZLgQAY370g
Cc: 'IETF AVT WG' 
Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-splicing-for-rtp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 06:32:04 -0000

Hi Colin,

Thank your comments. The scenario description is given in problem statements
draft, it is unnecessary to repeat that in this draft. 

Indeed, a standard translator can handle splicing without any extension, and
it still needs instructions from media source to implement splicing. 

I will update the draft according to our maillist discussion. Any commets
from others are also very appreciated!


Thank you
Jinwei

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org] 
> Sent: Wednesday, October 20, 2010 9:52 PM
> To: Jinwei Xia
> Cc: 'IETF AVT WG'
> Subject: Re: [AVT] FW: New Version Notification for 
> draft-xia-avt-splicing-for-rtp-00
> 
> Hi Jinwei,
> 
> My impression is that this draft confuses the issue by 
> focussing too much on scenarios where the content to be 
> inserted is also delivered over RTP. Whether the content to 
> be inserted is delivered as a real-time RTP stream or fetched 
> from local file storage does not affect the insertion 
> process, and so doesn't need to be mentioned in the draft. I 
> still believe that a standard RTP translator is sufficient to 
> solve this problem, although there may be useful things to 
> say about how to efficiently implement such a translator. 
> 
> Colin
> 
> 
> On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
> > Hi,
> > 
> > From the discussion on IETF 78th, there were some 
> misunderstandings of the scope of splicing draft. So we 
> discard previous problem statement draft while initiate new 
> solution draft. In this new draft, We emphysize content 
> insertion issue is indeed a RTP-generic rather than MPEG2 
> TS-specific. 
> > 
> > Hope the new draft can address most issues AVT concern, any 
> comments are very appreciated!
> > 
> > 
> > BR!
> > 
> > Jinwei
> > 
> >> -----Original Message-----
> >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> >> Sent: Saturday, October 16, 2010 9:58 AM
> >> To: xiajinwei@huawei.com
> >> Subject: New Version Notification for 
> >> draft-xia-avt-splicing-for-rtp-00
> >> 
> >> 
> >> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt
> >> has been successfully submitted by Jinwei Xia and posted 
> to the IETF 
> >> repository.
> >> 
> >> Filename:	 draft-xia-avt-splicing-for-rtp
> >> Revision:	 00
> >> Title:		 Content Splicing for RTP Sessions
> >> Creation_date:	 2010-10-16
> >> WG ID:		 Independent Submission
> >> Number_of_pages: 12
> >> 
> >> Abstract:
> >> This memo outlines RTP splicing.  Splicing is a process 
> that allows a 
> >> new multimedia stream to be inserted into current 
> multimedia stream 
> >> and to be conveyed to receiver for a period of time.  This memo 
> >> discusses the requirements of RTP splicing.  In order to 
> satisfy the 
> >> requirements, this memo lists several existing 
> intermediary network 
> >> elements as alternatives and evaluates whether one of alternatives 
> >> can be used to perform RTP splicing.
> >> 
> >> 
> >> 
> >> 
> >> The IETF Secretariat.
> >> 
> >> 
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 


From Even.roni@huawei.com  Wed Oct 20 23:58:40 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4100F3A6944 for ; Wed, 20 Oct 2010 23:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.409
X-Spam-Level: 
X-Spam-Status: No, score=-100.409 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFV-RA7pfmWx for ; Wed, 20 Oct 2010 23:58:38 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A49963A691C for ; Wed, 20 Oct 2010 23:58:38 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM004QVORZWJ@szxga03-in.huawei.com> for avt@ietf.org; Thu, 21 Oct 2010 14:59:59 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM006O4ORZR7@szxga03-in.huawei.com> for avt@ietf.org; Thu, 21 Oct 2010 14:59:59 +0800 (CST)
Received: from windows8d787f9 (bzq-79-178-39-121.red.bezeqint.net [79.178.39.121]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAM00LKFORSW5@szxml01-in.huawei.com>; Thu, 21 Oct 2010 14:59:59 +0800 (CST)
Date: Thu, 21 Oct 2010 08:56:34 +0200
From: Roni Even 
In-reply-to: 
To: 'Colin Perkins' , 'Jinwei Xia' 
Message-id: <05e901cb70ed$1dca0510$595e0f30$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: en-us
Content-transfer-encoding: 7BIT
Thread-index: ActwXf9wE8vP6oOFQ7eGcbl9gSSWHgAjhueg
References: <002d01cb6cd6$b24e2ce0$3c298a0a@china.huawei.com> 
Cc: 'IETF AVT WG' 
Subject: Re: [AVT] FW: New Version Notification for	draft-xia-avt-splicing-for-rtp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 06:58:40 -0000

Hi Colin,
I am not so sure about this being a regular RTP translator. According To RFC
5117 " A Translator always keeps the SSRC for a stream across the
translation".
Also in the splicing case it is not point to point or multipoint but more
like multipoint to point or multipoint. This looks more like a mixer that
does not provide the CSRC since one of the requirements is to make it look
to the receiver that all the media is coming from the same source.
One issue that will need to be addressed is how to report the RTCP RR from
the receivers back to the sender of the primary or insertion streams. This
may need some state keeping in the splicer.

Roni Even 

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> Colin Perkins
> Sent: Wednesday, October 20, 2010 3:52 PM
> To: Jinwei Xia
> Cc: 'IETF AVT WG'
> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
> splicing-for-rtp-00
> 
> Hi Jinwei,
> 
> My impression is that this draft confuses the issue by focussing too
> much on scenarios where the content to be inserted is also delivered
> over RTP. Whether the content to be inserted is delivered as a real-
> time RTP stream or fetched from local file storage does not affect the
> insertion process, and so doesn't need to be mentioned in the draft. I
> still believe that a standard RTP translator is sufficient to solve
> this problem, although there may be useful things to say about how to
> efficiently implement such a translator.
> 
> Colin
> 
> 
> On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
> > Hi,
> >
> > From the discussion on IETF 78th, there were some misunderstandings
> of the scope of splicing draft. So we discard previous problem
> statement draft while initiate new solution draft. In this new draft,
> We emphysize content insertion issue is indeed a RTP-generic rather
> than MPEG2 TS-specific.
> >
> > Hope the new draft can address most issues AVT concern, any comments
> are very appreciated!
> >
> >
> > BR!
> >
> > Jinwei
> >
> >> -----Original Message-----
> >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> >> Sent: Saturday, October 16, 2010 9:58 AM
> >> To: xiajinwei@huawei.com
> >> Subject: New Version Notification for
> >> draft-xia-avt-splicing-for-rtp-00
> >>
> >>
> >> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt
> >> has been successfully submitted by Jinwei Xia and posted to
> >> the IETF repository.
> >>
> >> Filename:	 draft-xia-avt-splicing-for-rtp
> >> Revision:	 00
> >> Title:		 Content Splicing for RTP Sessions
> >> Creation_date:	 2010-10-16
> >> WG ID:		 Independent Submission
> >> Number_of_pages: 12
> >>
> >> Abstract:
> >> This memo outlines RTP splicing.  Splicing is a process that
> >> allows a new multimedia stream to be inserted into current
> >> multimedia stream and to be conveyed to receiver for a period
> >> of time.  This memo discusses the requirements of RTP
> >> splicing.  In order to satisfy the requirements, this memo
> >> lists several existing intermediary network elements as
> >> alternatives and evaluates whether one of alternatives can be
> >> used to perform RTP splicing.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat.
> >>
> >>
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt


From ingemar.s.johansson@ericsson.com  Thu Oct 21 00:22:27 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9D13A69BD for ; Thu, 21 Oct 2010 00:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.498
X-Spam-Level: 
X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=1.101,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88RifJwVAGqF for ; Thu, 21 Oct 2010 00:22:25 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 51B383A69A6 for ; Thu, 21 Oct 2010 00:22:25 -0700 (PDT)
X-AuditID: c1b4fb39-b7b54ae000003464-68-4cbfea8f4690
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 55.2B.13412.F8AEFBC4; Thu, 21 Oct 2010 09:23:59 +0200 (CEST)
Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 21 Oct 2010 09:23:59 +0200
From: Ingemar Johansson S 
To: Colin Perkins , Bob Briscoe 
Date: Thu, 21 Oct 2010 09:23:57 +0200
Thread-Topic: Removing nonce (WAS RE: [AVT] draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
Thread-Index: ActvmNOeScMToERzRymxmHO9KyCS0QBV1puQ
Message-ID: 
References: <201008052251.o75Mp7BL005112@bagheera.jungle.bt.co.uk> <662B899F-09B5-48E5-B164-C61D278E4670@g11.org.uk> <201008252336.o7PNafwl030089@bagheera.jungle.bt.co.uk> <6D774CF6-FB7C-4710-A040-FCF40775FB8A@csperkins.org>
In-Reply-To: <6D774CF6-FB7C-4710-A040-FCF40775FB8A@csperkins.org>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: sv-SE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-ietf-avt-ecn-for-rtp@tools.ietf.org" , "avt@ietf.org" 
Subject: [AVT] Removing nonce (WAS RE: draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 07:22:27 -0000

Hi

I am working on the draft, removing the nonce stuff. As I understand it, se=
ction 5.3 can be removed entirely, but I guess some text is needed to indic=
ated that RFC3611 (4.1) can be used to indicate packets that are lost or EC=
N-CE marked.=20
ECN-CE is not mentioned in RFC3611, do you believe that it is valid to use =
RFC3611 for indication on ECN-CE. I guess it is if one stick to the princip=
le that ECN-CE should be reacted on in the same way as a packet loss. What =
is your opinion.

/Ingemar

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]=20
> Sent: den 19 oktober 2010 16:21
> To: Bob Briscoe
> Cc: ken carlberg; draft-ietf-avt-ecn-for-rtp@tools.ietf.org;=20
> avt@ietf.org
> Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating
>=20
> The ECN nonce support is pretty modular. I'm happy to rip it=20
> out of this draft, since we can always resurrect it in a=20
> separate draft if there's a need later.
>=20
> Colin
>=20
>=20
> On 26 Aug 2010, at 00:36, Bob Briscoe wrote:
> > Ken,
> >=20
> > We're violently agreeing I think, modulo just a little more=20
> optimism=20
> > on my part about ConEx ;)
> >=20
> > Colin already said (in a Maastricht corridor discussion)=20
> that he would be happy to defer receiver misbehaviour stuff.=20
> But I don't think I had put the specific proposal to him I=20
> put in my mail - modularising the possibility of two=20
> alternative future approaches. I've cut all that text from=20
> the thread now so, Colin, feel free to respond to Ken's=20
> request for your view in the previous mail instead.
> >=20
> > One response inline, altho I think that part of the=20
> conversation is getting pretty obscure...
> >=20
> > At 21:39 25/08/2010, ken carlberg wrote:
> >> Bob,
> >>=20
> >> FYI. its been a while since this email was sent, so I'm=20
> not snipping any of it, but my responses are few and=20
> scattered throughout.  And in this case, my opinions are not=20
> that strong, so I can probably be swayed by my co-authors if=20
> they feel differently.  That said...
> >>=20
> >> On Aug 5, 2010, at 6:41 PM, Bob Briscoe wrote:
> >> > Magnus, Ingemar, Colin, Piers, Ken,
> >=20
> > [snip]
> >=20
> >> > T3c/ Misbehaving end-points
> >> > -------------------
> >> > "
> >> > 1968                                                    =20
>  It is far from certain
> >> > 1969          that a receiver would be able to get a=20
> significant larger share of
> >> > 1970          the resources.  That assumes a high enough=20
> level of aggregation
> >> > 1971          that there are flows to acquire shares from.
> >> > "
> >> > Don't agree. It's completely certain that an=20
> unresponsive receiver (or sender) can get a significantly=20
> larger share of the resources, whether or not it uses ECN.=20
> Just try it. Send an unresponsive flow along with some=20
> responsive flows (e.g TCP) and the TCPs reduce their rates=20
> while the unresponsive flow gets whatever rate it chooses to send at.
> >> > "
> >>=20
> >> well, it depends on context.  if I have an aggregate of=20
> flows that are only periodically and in a bursty manner=20
> triggering a  congestive state, as opposed to a sustained=20
> level of congestion condition (though not collapse), then=20
> there are no guarantees that all the other flows will be=20
> marked or even suffer packet loss.  And...
> >=20
> >=20
> > [BB]: Going back to the para at issue in the I-D that I=20
> quoted: could I paraphrase it as, "If there are only two=20
> flows sharing a bottleneck, a cheating receiver cannot get=20
> more than twice as much as it would under equality, which=20
> isn't so bad."? If that's what it means, nah! Capacity=20
> sharing problems are surely better measured by how little=20
> others get, rather than how much more the cheater gets.
> >=20
> > Moving on to your periodic bursts scenario, I'm not quite=20
> sure I understand what you are getting at or how it's=20
> relevant to the para in the I-D.
> >=20
> > Whatever, surely fair shares aren't an issue during any=20
> period when a link isn't fully utilised. Becasue, if a link=20
> isn't fully utilised for some period, however brief, it is=20
> impossible to take more than your fair share over that period=20
> (for any definition of fairness) and it's impossible to cause=20
> others to get less than their fair share, because nothing you=20
> are doing stops others taking more than they are taking.
> >=20
> > Then,  during those bursts, it's only relevant that there=20
> would have marking or loss if someone else had taken a=20
> greater share than they were taking at that time. But while=20
> there's no marking or loss, it implies no-one else is wanting=20
> more than they are taking. So lack of marking or loss=20
> indicates there cannot have been any sharing problem.
> >=20
> > Or am I missing your point?
> >=20
> >=20
> > Bob
> >=20
> >=20
> >=20
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design=20
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
>=20
>=20
>=20
> --
> Colin Perkins
> http://csperkins.org/
>=20
>=20
>=20
> =

From magnus.westerlund@ericsson.com  Thu Oct 21 00:30:15 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F343A69D5 for ; Thu, 21 Oct 2010 00:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.493
X-Spam-Level: 
X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgkMz6zAAgkd for ; Thu, 21 Oct 2010 00:30:14 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5478E3A6805 for ; Thu, 21 Oct 2010 00:30:14 -0700 (PDT)
X-AuditID: c1b4fb39-b7b54ae000003464-c5-4cbfec64306c
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 81.6C.13412.46CEFBC4; Thu, 21 Oct 2010 09:31:48 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Oct 2010 09:31:47 +0200
Received: from [147.214.183.82] ([147.214.183.82]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Oct 2010 09:31:48 +0200
Message-ID: <4CBFEC63.7090003@ericsson.com>
Date: Thu, 21 Oct 2010 09:31:47 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: Ingemar Johansson S 
References: <201008052251.o75Mp7BL005112@bagheera.jungle.bt.co.uk>	<662B899F-09B5-48E5-B164-C61D278E4670@g11.org.uk>	<201008252336.o7PNafwl030089@bagheera.jungle.bt.co.uk>	<6D774CF6-FB7C-4710-A040-FCF40775FB8A@csperkins.org> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 21 Oct 2010 07:31:48.0042 (UTC) FILETIME=[051DB2A0:01CB70F2]
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-ietf-avt-ecn-for-rtp@tools.ietf.org" , Bob Briscoe , Colin Perkins , "avt@ietf.org" 
Subject: Re: [AVT] Removing nonce (WAS RE: draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 07:30:15 -0000

Ingemar Johansson S skrev 2010-10-21 09:23:
> Hi
> 
> I am working on the draft, removing the nonce stuff. As I understand it, section 5.3 can be removed entirely, but I guess some text is needed to indicated that RFC3611 (4.1) can be used to indicate packets that are lost or ECN-CE marked. 
> ECN-CE is not mentioned in RFC3611, do you believe that it is valid to use RFC3611 for indication on ECN-CE. I guess it is if one stick to the principle that ECN-CE should be reacted on in the same way as a packet loss. What is your opinion.

I at least are of the opinion that if a packet arrived with a CE mark,
it is still delivered. It shall not be marked as lost in the RTCP XR
packet loss vector. If we want/need to know exactly which packets where
CE marked, then we should define a CE marking XR vector for that.
Overloading of this would reduce the utility of the packet loss vector.

Did you have any specific need for explicit CE markings?

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 ingemar.s.johansson@ericsson.com  Thu Oct 21 00:49:49 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36BD3A69EA for ; Thu, 21 Oct 2010 00:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.53
X-Spam-Level: 
X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[AWL=1.069,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6foQo8KdtYF for ; Thu, 21 Oct 2010 00:49:48 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 947253A6985 for ; Thu, 21 Oct 2010 00:49:48 -0700 (PDT)
X-AuditID: c1b4fb39-b7b54ae000003464-ab-4cbff0fa2104
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0C.8F.13412.AF0FFBC4; Thu, 21 Oct 2010 09:51:22 +0200 (CEST)
Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 21 Oct 2010 09:51:15 +0200
From: Ingemar Johansson S 
To: Magnus Westerlund 
Date: Thu, 21 Oct 2010 09:51:14 +0200
Thread-Topic: [AVT] Removing nonce (WAS RE: draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
Thread-Index: Actw8gVz/uCJMXFfTBKE25ssDbIvtQAATIjg
Message-ID: 
References: <201008052251.o75Mp7BL005112@bagheera.jungle.bt.co.uk> <662B899F-09B5-48E5-B164-C61D278E4670@g11.org.uk> <201008252336.o7PNafwl030089@bagheera.jungle.bt.co.uk> <6D774CF6-FB7C-4710-A040-FCF40775FB8A@csperkins.org>  <4CBFEC63.7090003@ericsson.com>
In-Reply-To: <4CBFEC63.7090003@ericsson.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: sv-SE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-ietf-avt-ecn-for-rtp@tools.ietf.org" , Bob Briscoe , Colin Perkins , "avt@ietf.org" 
Subject: Re: [AVT] Removing nonce (WAS RE: draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 07:49:50 -0000

Hi=20

Sounds like we should define a CE report block similar to 4.1 in RFC3611 th=
en. If both CE and loss occur during a report interval one will of course g=
et both Loss and CE report blocks. A solution is of course a combined Loss/=
CE report block to reduce some of the overhead (I believe I can live with s=
eparate Loss and CE blocks and the extra overhead)

I can imagine that one can consider a more relaxed behavior to CE than Loss=
 although I have not seen much evidence of it sofar a least in wireless acc=
ess scenarios, one is there likely to see CE shortly before a loss or exces=
sive delay. Wireline may be a different story though..

/Ingemar=20

> -----Original Message-----
> From: Magnus Westerlund=20
> Sent: den 21 oktober 2010 09:32
> To: Ingemar Johansson S
> Cc: Colin Perkins; Bob Briscoe;=20
> draft-ietf-avt-ecn-for-rtp@tools.ietf.org; avt@ietf.org
> Subject: Re: [AVT] Removing nonce (WAS RE:=20
> draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
>=20
> Ingemar Johansson S skrev 2010-10-21 09:23:
> > Hi
> >=20
> > I am working on the draft, removing the nonce stuff. As I=20
> understand it, section 5.3 can be removed entirely, but I=20
> guess some text is needed to indicated that RFC3611 (4.1) can=20
> be used to indicate packets that are lost or ECN-CE marked.=20
> > ECN-CE is not mentioned in RFC3611, do you believe that it=20
> is valid to use RFC3611 for indication on ECN-CE. I guess it=20
> is if one stick to the principle that ECN-CE should be=20
> reacted on in the same way as a packet loss. What is your opinion.
>=20
> I at least are of the opinion that if a packet arrived with a=20
> CE mark, it is still delivered. It shall not be marked as=20
> lost in the RTCP XR packet loss vector. If we want/need to=20
> know exactly which packets where CE marked, then we should=20
> define a CE marking XR vector for that.
> Overloading of this would reduce the utility of the packet=20
> loss vector.
>=20
> Did you have any specific need for explicit CE markings?
>=20
> Cheers
>=20
> Magnus Westerlund
>=20
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> F=E4r=F6gatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> =

From ingemar.s.johansson@ericsson.com  Thu Oct 21 02:17:55 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A023A6A07 for ; Thu, 21 Oct 2010 02:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.561
X-Spam-Level: 
X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=1.038,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHOff2tpYRH1 for ; Thu, 21 Oct 2010 02:17:54 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 525B23A691D for ; Thu, 21 Oct 2010 02:17:54 -0700 (PDT)
X-AuditID: c1b4fb39-b7b54ae000003464-26-4cc005a0346e
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.01.13412.0A500CC4; Thu, 21 Oct 2010 11:19:28 +0200 (CEST)
Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 21 Oct 2010 11:19:28 +0200
From: Ingemar Johansson S 
To: Ingemar Johansson S , Magnus Westerlund 
Date: Thu, 21 Oct 2010 11:19:27 +0200
Thread-Topic: [AVT] Removing nonce (WAS RE: draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
Thread-Index: Actw8gVz/uCJMXFfTBKE25ssDbIvtQAATIjgAAL3veA=
Message-ID: 
References: <201008052251.o75Mp7BL005112@bagheera.jungle.bt.co.uk> <662B899F-09B5-48E5-B164-C61D278E4670@g11.org.uk> <201008252336.o7PNafwl030089@bagheera.jungle.bt.co.uk> <6D774CF6-FB7C-4710-A040-FCF40775FB8A@csperkins.org>  <4CBFEC63.7090003@ericsson.com> 
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: sv-SE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-ietf-avt-ecn-for-rtp@tools.ietf.org" , Bob Briscoe , Colin Perkins , "avt@ietf.org" 
Subject: Re: [AVT] Removing nonce (WAS RE: draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 09:17:55 -0000

Hi

After some consideration I believe that it is better to skip the RLE XR blo=
ck altogether. I don't see a clear need now to explicitly see if specific p=
ackets are CE marked. But should such a need occur later on, then we can ad=
d perhaps add this, this addition is also quite simple.

BTW.. It was not my intention to flood the AVT list with this thread, sorry=
 for the extra noise...

/Ingemar

> -----Original Message-----
> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]=20
> Sent: den 21 oktober 2010 09:51
> To: Magnus Westerlund
> Cc: Colin Perkins; Bob Briscoe;=20
> draft-ietf-avt-ecn-for-rtp@tools.ietf.org; avt@ietf.org
> Subject: RE: [AVT] Removing nonce (WAS RE:=20
> draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
>=20
> Hi=20
>=20
> Sounds like we should define a CE report block similar to 4.1=20
> in RFC3611 then. If both CE and loss occur during a report=20
> interval one will of course get both Loss and CE report=20
> blocks. A solution is of course a combined Loss/CE report=20
> block to reduce some of the overhead (I believe I can live=20
> with separate Loss and CE blocks and the extra overhead)
>=20
> I can imagine that one can consider a more relaxed behavior=20
> to CE than Loss although I have not seen much evidence of it=20
> sofar a least in wireless access scenarios, one is there=20
> likely to see CE shortly before a loss or excessive delay.=20
> Wireline may be a different story though..
>=20
> /Ingemar=20
>=20
> > -----Original Message-----
> > From: Magnus Westerlund
> > Sent: den 21 oktober 2010 09:32
> > To: Ingemar Johansson S
> > Cc: Colin Perkins; Bob Briscoe;
> > draft-ietf-avt-ecn-for-rtp@tools.ietf.org; avt@ietf.org
> > Subject: Re: [AVT] Removing nonce (WAS RE:=20
> > draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
> >=20
> > Ingemar Johansson S skrev 2010-10-21 09:23:
> > > Hi
> > >=20
> > > I am working on the draft, removing the nonce stuff. As I
> > understand it, section 5.3 can be removed entirely, but I=20
> guess some=20
> > text is needed to indicated that RFC3611 (4.1) can be used=20
> to indicate=20
> > packets that are lost or ECN-CE marked.
> > > ECN-CE is not mentioned in RFC3611, do you believe that it
> > is valid to use RFC3611 for indication on ECN-CE. I guess=20
> it is if one=20
> > stick to the principle that ECN-CE should be reacted on in the same=20
> > way as a packet loss. What is your opinion.
> >=20
> > I at least are of the opinion that if a packet arrived with=20
> a CE mark,=20
> > it is still delivered. It shall not be marked as lost in=20
> the RTCP XR=20
> > packet loss vector. If we want/need to know exactly which packets=20
> > where CE marked, then we should define a CE marking XR vector for=20
> > that.
> > Overloading of this would reduce the utility of the packet loss=20
> > vector.
> >=20
> > Did you have any specific need for explicit CE markings?
> >=20
> > Cheers
> >=20
> > Magnus Westerlund
> >=20
> >=20
> ----------------------------------------------------------------------
> > Multimedia Technologies, Ericsson Research EAB/TVM
> >=20
> ----------------------------------------------------------------------
> > Ericsson AB                | Phone  +46 10 7148287
> > F=E4r=F6gatan 6                | Mobile +46 73 0949079
> > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> >=20
> ----------------------------------------------------------------------
> > =

From csp@csperkins.org  Thu Oct 21 10:21:18 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0503A698E for ; Thu, 21 Oct 2010 10:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.487
X-Spam-Level: 
X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNPQ93yxKXJh for ; Thu, 21 Oct 2010 10:21:17 -0700 (PDT)
Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by core3.amsl.com (Postfix) with ESMTP id E82BE3A680F for ; Thu, 21 Oct 2010 10:21:16 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P8yqg-0006ok-eZ; Thu, 21 Oct 2010 17:22:51 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins 
In-Reply-To: <05e901cb70ed$1dca0510$595e0f30$%roni@huawei.com>
Date: Thu, 21 Oct 2010 18:22:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <242A9169-3AE9-4C55-817A-B7B93F6005C9@csperkins.org>
References: <002d01cb6cd6$b24e2ce0$3c298a0a@china.huawei.com>  <05e901cb70ed$1dca0510$595e0f30$%roni@huawei.com>
To: Roni Even 
X-Mailer: Apple Mail (2.1081)
Cc: 'IETF AVT WG' 
Subject: Re: [AVT] FW: New Version Notification for	draft-xia-avt-splicing-for-rtp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 17:21:18 -0000

Hi Roni,

I think this problem becomes clearer if you consider a splicer that is =
reading the content to be inserted from a local file on disk. In that =
case, the splicer is unquestionably a standard RTP translator, in the =
middle of a one-to-one or one-to-many RTP session.=20

That there are also some cases where an entirely separate RTP session is =
used to deliver the content to be inserted doesn't (conceptually) affect =
the translation process at all.=20

Colin



On 21 Oct 2010, at 07:56, Roni Even wrote:
> Hi Colin,
> I am not so sure about this being a regular RTP translator. According =
To RFC 5117 " A Translator always keeps the SSRC for a stream across the =
translation". Also in the splicing case it is not point to point or =
multipoint but more like multipoint to point or multipoint. This looks =
more like a mixer that does not provide the CSRC since one of the =
requirements is to make it look to the receiver that all the media is =
coming from the same source. One issue that will need to be addressed is =
how to report the RTCP RR from the receivers back to the sender of the =
primary or insertion streams. This may need some state keeping in the =
splicer.
>=20
> Roni Even=20
>=20
>> -----Original Message-----
>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
>> Colin Perkins
>> Sent: Wednesday, October 20, 2010 3:52 PM
>> To: Jinwei Xia
>> Cc: 'IETF AVT WG'
>> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
>> splicing-for-rtp-00
>>=20
>> Hi Jinwei,
>>=20
>> My impression is that this draft confuses the issue by focussing too =
much on scenarios where the content to be inserted is also delivered =
over RTP. Whether the content to be inserted is delivered as a real- =
time RTP stream or fetched from local file storage does not affect the =
insertion process, and so doesn't need to be mentioned in the draft. I =
still believe that a standard RTP translator is sufficient to solve this =
problem, although there may be useful things to say about how to =
efficiently implement such a translator.
>>=20
>> Colin
>>=20
>>=20
>> On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
>>> Hi,
>>>=20
>>> =46rom the discussion on IETF 78th, there were some =
misunderstandings
>> of the scope of splicing draft. So we discard previous problem
>> statement draft while initiate new solution draft. In this new draft,
>> We emphysize content insertion issue is indeed a RTP-generic rather
>> than MPEG2 TS-specific.
>>>=20
>>> Hope the new draft can address most issues AVT concern, any comments
>> are very appreciated!
>>>=20
>>>=20
>>> BR!
>>>=20
>>> Jinwei
>>>=20
>>>> -----Original Message-----
>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
>>>> Sent: Saturday, October 16, 2010 9:58 AM
>>>> To: xiajinwei@huawei.com
>>>> Subject: New Version Notification for
>>>> draft-xia-avt-splicing-for-rtp-00
>>>>=20
>>>>=20
>>>> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt
>>>> has been successfully submitted by Jinwei Xia and posted to
>>>> the IETF repository.
>>>>=20
>>>> Filename:	 draft-xia-avt-splicing-for-rtp
>>>> Revision:	 00
>>>> Title:		 Content Splicing for RTP Sessions
>>>> Creation_date:	 2010-10-16
>>>> WG ID:		 Independent Submission
>>>> Number_of_pages: 12
>>>>=20
>>>> Abstract:
>>>> This memo outlines RTP splicing.  Splicing is a process that
>>>> allows a new multimedia stream to be inserted into current
>>>> multimedia stream and to be conveyed to receiver for a period
>>>> of time.  This memo discusses the requirements of RTP
>>>> splicing.  In order to satisfy the requirements, this memo
>>>> lists several existing intermediary network elements as
>>>> alternatives and evaluates whether one of alternatives can be
>>>> used to perform RTP splicing.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> The IETF Secretariat.
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> Audio/Video Transport Working Group
>>> avt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt
>>=20
>> --
>> Colin Perkins
>> http://csperkins.org/


From Even.roni@huawei.com  Thu Oct 21 11:28:10 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633CF3A6822 for ; Thu, 21 Oct 2010 11:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.42
X-Spam-Level: 
X-Spam-Status: No, score=-100.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I2dVnHCaoQf for ; Thu, 21 Oct 2010 11:28:09 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 4DA5E3A689B for ; Thu, 21 Oct 2010 11:28:08 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAN00DEGKP9ML@szxga01-in.huawei.com> for avt@ietf.org; Fri, 22 Oct 2010 02:29:33 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAN00CFIKP975@szxga01-in.huawei.com> for avt@ietf.org; Fri, 22 Oct 2010 02:29:33 +0800 (CST)
Received: from windows8d787f9 (bzq-79-178-39-121.red.bezeqint.net [79.178.39.121]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAN00MCCKOZQ8@szxml02-in.huawei.com>; Fri, 22 Oct 2010 02:29:33 +0800 (CST)
Date: Thu, 21 Oct 2010 20:26:18 +0200
From: Roni Even 
In-reply-to: <242A9169-3AE9-4C55-817A-B7B93F6005C9@csperkins.org>
To: 'Colin Perkins' 
Message-id: <006601cb714d$7b22f4a0$7168dde0$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: en-us
Content-transfer-encoding: 7BIT
Thread-index: ActxRJkSqGaFb11VRzqsMxotb9dedAACBA2Q
References: <002d01cb6cd6$b24e2ce0$3c298a0a@china.huawei.com>  <05e901cb70ed$1dca0510$595e0f30$%roni@huawei.com> <242A9169-3AE9-4C55-817A-B7B93F6005C9@csperkins.org>
Cc: 'IETF AVT WG' 
Subject: Re: [AVT] FW: New Version Notification for	draft-xia-avt-splicing-for-rtp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 18:28:10 -0000

Hi Colin,
In this use case the inserted content is not an RTP stream but comes from a
local storage. For this use case the splicer is a translator. It will still
need to handle the RTCP RR depending on who originated the data that was
sent by the translator.
My question will be if this is the typical use case or is there a use case
where the inserted data is not local and may arrive as RTP stream. In which
case there is more than one topology

Roni

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Thursday, October 21, 2010 7:23 PM
> To: Roni Even
> Cc: 'Jinwei Xia'; 'IETF AVT WG'
> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
> splicing-for-rtp-00
> 
> Hi Roni,
> 
> I think this problem becomes clearer if you consider a splicer that is
> reading the content to be inserted from a local file on disk. In that
> case, the splicer is unquestionably a standard RTP translator, in the
> middle of a one-to-one or one-to-many RTP session.
> 
> That there are also some cases where an entirely separate RTP session
> is used to deliver the content to be inserted doesn't (conceptually)
> affect the translation process at all.
> 
> Colin
> 
> 
> 
> On 21 Oct 2010, at 07:56, Roni Even wrote:
> > Hi Colin,
> > I am not so sure about this being a regular RTP translator. According
> To RFC 5117 " A Translator always keeps the SSRC for a stream across
> the translation". Also in the splicing case it is not point to point or
> multipoint but more like multipoint to point or multipoint. This looks
> more like a mixer that does not provide the CSRC since one of the
> requirements is to make it look to the receiver that all the media is
> coming from the same source. One issue that will need to be addressed
> is how to report the RTCP RR from the receivers back to the sender of
> the primary or insertion streams. This may need some state keeping in
> the splicer.
> >
> > Roni Even
> >
> >> -----Original Message-----
> >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf
> Of
> >> Colin Perkins
> >> Sent: Wednesday, October 20, 2010 3:52 PM
> >> To: Jinwei Xia
> >> Cc: 'IETF AVT WG'
> >> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
> >> splicing-for-rtp-00
> >>
> >> Hi Jinwei,
> >>
> >> My impression is that this draft confuses the issue by focussing too
> much on scenarios where the content to be inserted is also delivered
> over RTP. Whether the content to be inserted is delivered as a real-
> time RTP stream or fetched from local file storage does not affect the
> insertion process, and so doesn't need to be mentioned in the draft. I
> still believe that a standard RTP translator is sufficient to solve
> this problem, although there may be useful things to say about how to
> efficiently implement such a translator.
> >>
> >> Colin
> >>
> >>
> >> On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
> >>> Hi,
> >>>
> >>> From the discussion on IETF 78th, there were some misunderstandings
> >> of the scope of splicing draft. So we discard previous problem
> >> statement draft while initiate new solution draft. In this new
> draft,
> >> We emphysize content insertion issue is indeed a RTP-generic rather
> >> than MPEG2 TS-specific.
> >>>
> >>> Hope the new draft can address most issues AVT concern, any
> comments
> >> are very appreciated!
> >>>
> >>>
> >>> BR!
> >>>
> >>> Jinwei
> >>>
> >>>> -----Original Message-----
> >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> >>>> Sent: Saturday, October 16, 2010 9:58 AM
> >>>> To: xiajinwei@huawei.com
> >>>> Subject: New Version Notification for
> >>>> draft-xia-avt-splicing-for-rtp-00
> >>>>
> >>>>
> >>>> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt
> >>>> has been successfully submitted by Jinwei Xia and posted to
> >>>> the IETF repository.
> >>>>
> >>>> Filename:	 draft-xia-avt-splicing-for-rtp
> >>>> Revision:	 00
> >>>> Title:		 Content Splicing for RTP Sessions
> >>>> Creation_date:	 2010-10-16
> >>>> WG ID:		 Independent Submission
> >>>> Number_of_pages: 12
> >>>>
> >>>> Abstract:
> >>>> This memo outlines RTP splicing.  Splicing is a process that
> >>>> allows a new multimedia stream to be inserted into current
> >>>> multimedia stream and to be conveyed to receiver for a period
> >>>> of time.  This memo discusses the requirements of RTP
> >>>> splicing.  In order to satisfy the requirements, this memo
> >>>> lists several existing intermediary network elements as
> >>>> alternatives and evaluates whether one of alternatives can be
> >>>> used to perform RTP splicing.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> The IETF Secretariat.
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Audio/Video Transport Working Group
> >>> avt@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/avt
> >>
> >> --
> >> Colin Perkins
> >> http://csperkins.org/


From csp@csperkins.org  Thu Oct 21 13:15:36 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BAA43A690C for ; Thu, 21 Oct 2010 13:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.434
X-Spam-Level: 
X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6t1KtaB6bHU for ; Thu, 21 Oct 2010 13:15:29 -0700 (PDT)
Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id B6E853A67F6 for ; Thu, 21 Oct 2010 13:15:28 -0700 (PDT)
Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.22]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P91ZQ-0007UT-aX; Thu, 21 Oct 2010 20:17:04 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins 
In-Reply-To: <006601cb714d$7b22f4a0$7168dde0$%roni@huawei.com>
Date: Thu, 21 Oct 2010 21:17:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8DB5DBDB-E336-4826-9128-FC4CD8404305@csperkins.org>
References: <002d01cb6cd6$b24e2ce0$3c298a0a@china.huawei.com>  <05e901cb70ed$1dca0510$595e0f30$%roni@huawei.com> <242A9169-3AE9-4C55-817A-B7B93F6005C9@csperkins.org> <006601cb714d$7b22f4a0$7168dde0$%roni@huawei.com>
To: Roni Even 
X-Mailer: Apple Mail (2.1081)
Cc: 'IETF AVT WG' 
Subject: Re: [AVT] FW: New Version Notification for	draft-xia-avt-splicing-for-rtp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 20:15:36 -0000

Roni,

I don't think it matters that the content arrives as an RTP stream. It's =
an entirely separate stream, and doesn't affect the translation process. =
They're logically separate.

Colin



On 21 Oct 2010, at 19:26, Roni Even wrote:
> Hi Colin,
> In this use case the inserted content is not an RTP stream but comes =
from a local storage. For this use case the splicer is a translator. It =
will still need to handle the RTCP RR depending on who originated the =
data that was sent by the translator.
> My question will be if this is the typical use case or is there a use =
case where the inserted data is not local and may arrive as RTP stream. =
In which case there is more than one topology
>=20
> Roni
>=20
>> -----Original Message-----
>> From: Colin Perkins [mailto:csp@csperkins.org]
>> Sent: Thursday, October 21, 2010 7:23 PM
>> To: Roni Even
>> Cc: 'Jinwei Xia'; 'IETF AVT WG'
>> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
>> splicing-for-rtp-00
>>=20
>> Hi Roni,
>>=20
>> I think this problem becomes clearer if you consider a splicer that =
is
>> reading the content to be inserted from a local file on disk. In that
>> case, the splicer is unquestionably a standard RTP translator, in the
>> middle of a one-to-one or one-to-many RTP session.
>>=20
>> That there are also some cases where an entirely separate RTP session
>> is used to deliver the content to be inserted doesn't (conceptually)
>> affect the translation process at all.
>>=20
>> Colin
>>=20
>>=20
>>=20
>> On 21 Oct 2010, at 07:56, Roni Even wrote:
>>> Hi Colin,
>>> I am not so sure about this being a regular RTP translator. =
According
>> To RFC 5117 " A Translator always keeps the SSRC for a stream across
>> the translation". Also in the splicing case it is not point to point =
or
>> multipoint but more like multipoint to point or multipoint. This =
looks
>> more like a mixer that does not provide the CSRC since one of the
>> requirements is to make it look to the receiver that all the media is
>> coming from the same source. One issue that will need to be addressed
>> is how to report the RTCP RR from the receivers back to the sender of
>> the primary or insertion streams. This may need some state keeping in
>> the splicer.
>>>=20
>>> Roni Even
>>>=20
>>>> -----Original Message-----
>>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf
>> Of
>>>> Colin Perkins
>>>> Sent: Wednesday, October 20, 2010 3:52 PM
>>>> To: Jinwei Xia
>>>> Cc: 'IETF AVT WG'
>>>> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
>>>> splicing-for-rtp-00
>>>>=20
>>>> Hi Jinwei,
>>>>=20
>>>> My impression is that this draft confuses the issue by focussing =
too
>> much on scenarios where the content to be inserted is also delivered
>> over RTP. Whether the content to be inserted is delivered as a real-
>> time RTP stream or fetched from local file storage does not affect =
the
>> insertion process, and so doesn't need to be mentioned in the draft. =
I
>> still believe that a standard RTP translator is sufficient to solve
>> this problem, although there may be useful things to say about how to
>> efficiently implement such a translator.
>>>>=20
>>>> Colin
>>>>=20
>>>>=20
>>>> On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
>>>>> Hi,
>>>>>=20
>>>>> =46rom the discussion on IETF 78th, there were some =
misunderstandings
>>>> of the scope of splicing draft. So we discard previous problem
>>>> statement draft while initiate new solution draft. In this new
>> draft,
>>>> We emphysize content insertion issue is indeed a RTP-generic rather
>>>> than MPEG2 TS-specific.
>>>>>=20
>>>>> Hope the new draft can address most issues AVT concern, any
>> comments
>>>> are very appreciated!
>>>>>=20
>>>>>=20
>>>>> BR!
>>>>>=20
>>>>> Jinwei
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
>>>>>> Sent: Saturday, October 16, 2010 9:58 AM
>>>>>> To: xiajinwei@huawei.com
>>>>>> Subject: New Version Notification for
>>>>>> draft-xia-avt-splicing-for-rtp-00
>>>>>>=20
>>>>>>=20
>>>>>> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt
>>>>>> has been successfully submitted by Jinwei Xia and posted to
>>>>>> the IETF repository.
>>>>>>=20
>>>>>> Filename:	 draft-xia-avt-splicing-for-rtp
>>>>>> Revision:	 00
>>>>>> Title:		 Content Splicing for RTP Sessions
>>>>>> Creation_date:	 2010-10-16
>>>>>> WG ID:		 Independent Submission
>>>>>> Number_of_pages: 12
>>>>>>=20
>>>>>> Abstract:
>>>>>> This memo outlines RTP splicing.  Splicing is a process that
>>>>>> allows a new multimedia stream to be inserted into current
>>>>>> multimedia stream and to be conveyed to receiver for a period
>>>>>> of time.  This memo discusses the requirements of RTP
>>>>>> splicing.  In order to satisfy the requirements, this memo
>>>>>> lists several existing intermediary network elements as
>>>>>> alternatives and evaluates whether one of alternatives can be
>>>>>> used to perform RTP splicing.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> The IETF Secretariat.
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> Audio/Video Transport Working Group
>>>>> avt@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/avt
>>>>=20
>>>> --
>>>> Colin Perkins
>>>> http://csperkins.org/
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt



--=20
Colin Perkins
http://csperkins.org/




From peter.musgrave@magorcorp.com  Thu Oct 21 13:20:01 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014523A683A for ; Thu, 21 Oct 2010 13:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.555
X-Spam-Level: 
X-Spam-Status: No, score=-101.555 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9uk9NsT9OpP for ; Thu, 21 Oct 2010 13:20:00 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id E67ED3A6838 for ; Thu, 21 Oct 2010 13:19:59 -0700 (PDT)
Received: by qwb7 with SMTP id 7so39070qwb.31 for ; Thu, 21 Oct 2010 13:21:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.240.213 with SMTP id lb21mr1194714qcb.185.1287692495544; Thu, 21 Oct 2010 13:21:35 -0700 (PDT)
Received: by 10.229.225.207 with HTTP; Thu, 21 Oct 2010 13:21:35 -0700 (PDT)
Date: Thu, 21 Oct 2010 16:21:35 -0400
Message-ID: 
From: Peter Musgrave 
To: Robert Sparks , IETF AVT WG 
Content-Type: multipart/alternative; boundary=00163630f66dc6e168049326457c
Subject: [AVT] Errata Updates for AVT RFC4696/RFC5109
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 20:20:01 -0000

--00163630f66dc6e168049326457c
Content-Type: text/plain; charset=ISO-8859-1

Hi Rob/AVT,

Here are my notes on some of the reported errata:

RFC4695
http://www.rfc-editor.org/errata_search.php?eid=861
Errata correctly notes error in ASCII characters for P and Q
Action:Hold For Doc Update (unlikely to stump anyone implementing)

RFC5109
http://www.rfc-editor.org/errata_search.php?eid=1225
Editorial: clarrifies a sentence in the introduction
Action: Hold for doc update

http://www.rfc-editor.org/errata_search.php?eid=1226
Editorial: rephrases a step in the instructions for RTP header
reconstruction
Action: Rejected (In my opinion the new text is not significantly clearer
and the use of the word cumulative is a bit confusing).

http://www.rfc-editor.org/errata_search.php?eid=1227
Editorial: clarifies and adds a useful internal reference
Action: Hold for Doc Update

http://www.rfc-editor.org/errata_search.php?eid=1228
Editorial: Correct figure to indicate RTP header is 12 octets (6 is shown)
Action: Hold for Doc Update

http://www.rfc-editor.org/errata_search.php?eid=1229
Editorial: Correct figure to indicate RTP header is 12 octets (6 is shown)
Action: Hold for Doc Update

http://www.rfc-editor.org/errata_search.php?eid=1230
Editorial: An error in an example with RTP head as 6 octets and a
mis-ordering of one header field
Action: Hold for Doc Update

Regards,

Peter Musgrave

--00163630f66dc6e168049326457c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Rob/AVT,=A0

Here are my notes on some of the reported=
 errata:

RFC4695


Errata correctly notes error in ASCII characters for P and Q
Action:Hold For Doc Update (unlikely to stump anyone implementing)

RFC5109


Editorial: clarrifies a sentence in the introduction
Action:=
 Hold for doc update



Editorial: rephrases a step in the instructions for RTP header reconst=
ruction=A0
Action: Rejected (In my opinion the new text is not si=
gnificantly clearer and the use of the word cumulative is a bit confusing).=
=A0



Editorial: clarifies and adds a useful internal reference
<=
/div>

Action: Hold for Doc Update

Editorial: Correct f=
igure to indicate RTP header is 12 octets (6 is shown)


Action: Hold for Doc Update

Editorial: Corr=
ect figure to indicate RTP header is 12 octets (6 is shown)


Action: Hold for Doc Update

Editorial: An error in an=
 example with RTP head as 6 octets and a mis-ordering of one header field

Action: Hold for Doc Update

Regards,=A0
=


Peter Musgrave


=






--00163630f66dc6e168049326457c--

From oran@cisco.com  Thu Oct 21 13:25:20 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831253A686A for ; Thu, 21 Oct 2010 13:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.371
X-Spam-Level: 
X-Spam-Status: No, score=-110.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KDCAogEygNT for ; Thu, 21 Oct 2010 13:25:19 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1598C3A67F6 for ; Thu, 21 Oct 2010 13:25:19 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: PGP.sig : 194
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAD4+wEyrR7Hu/2dsb2JhbAChXnGkT5xChUoEik2DBA
X-IronPort-AV: E=Sophos;i="4.58,219,1286150400";  d="sig'?scan'208";a="204681306"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 Oct 2010 20:26:55 +0000
Received: from OranMBP.local (stealth-10-32-245-153.cisco.com [10.32.245.153]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9LKQdZp022883 for ; Thu, 21 Oct 2010 20:26:54 GMT
Received: from [127.0.0.1] by OranMBP.local (PGP Universal service); Thu, 21 Oct 2010 16:26:55 -0400
X-PGP-Universal: processed; by OranMBP.local on Thu, 21 Oct 2010 16:26:55 -0400
Mime-Version: 1.0 (Apple Message framework v1081)
From: David R Oran 
In-Reply-To: <8DB5DBDB-E336-4826-9128-FC4CD8404305@csperkins.org>
Date: Thu, 21 Oct 2010 16:26:33 -0400
Message-Id: <72B2F4CF-DC7A-4A03-B358-276E8C5DECFE@cisco.com>
References: <002d01cb6cd6$b24e2ce0$3c298a0a@china.huawei.com>  <05e901cb70ed$1dca0510$595e0f30$%roni@huawei.com> <242A9169-3AE9-4C55-817A-B7B93F6005C9@csperkins.org> <006601cb714d$7b22f4a0$7168dde0$%roni@huawei.com> <8DB5DBDB-E336-4826-9128-FC4CD8404305@csperkins.org>
To: Colin Perkins 
X-Mailer: Apple Mail (2.1081)
X-PGP-Encoding-Format: MIME
X-PGP-Encoding-Version: 2.0.2
Content-Type: multipart/signed; boundary="PGP_Universal_7E90D295_CFA14739_42A76F8A_41380B46"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Cc: 'IETF AVT WG' , Roni Even 
Subject: Re: [AVT] FW: New Version Notification for	draft-xia-avt-splicing-for-rtp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 20:25:20 -0000

--PGP_Universal_7E90D295_CFA14739_42A76F8A_41380B46
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable


On Oct 21, 2010, at 4:17 PM, Colin Perkins wrote:

> Roni,
>=20
> I don't think it matters that the content arrives as an RTP stream. =
It's an entirely separate stream, and doesn't affect the translation =
process. They're logically separate.
>=20
I agree with Colin here.=20

Either you treat the streams as equal inputs to a mixer, and the case =
reduces to the problem of a video mixer doing input switching, or you =
treat all the other inputs as external stuff that gets inserted into the =
main stream using a translator.

If you choose the mixer approach, you have to be a legal mixer, which =
means you keep state, use your own SSRC, and report CSRCs.

If you choose the translator approach, you have to "consume" the other =
stream and then emit it as if it were emitted by the original stream's =
source.

I don't see what the other approaches would be or how they might work =
better.

DaveO.

> Colin
>=20
>=20
>=20
> On 21 Oct 2010, at 19:26, Roni Even wrote:
>> Hi Colin,
>> In this use case the inserted content is not an RTP stream but comes =
from a local storage. For this use case the splicer is a translator. It =
will still need to handle the RTCP RR depending on who originated the =
data that was sent by the translator.
>> My question will be if this is the typical use case or is there a use =
case where the inserted data is not local and may arrive as RTP stream. =
In which case there is more than one topology
>>=20
>> Roni
>>=20
>>> -----Original Message-----
>>> From: Colin Perkins [mailto:csp@csperkins.org]
>>> Sent: Thursday, October 21, 2010 7:23 PM
>>> To: Roni Even
>>> Cc: 'Jinwei Xia'; 'IETF AVT WG'
>>> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
>>> splicing-for-rtp-00
>>>=20
>>> Hi Roni,
>>>=20
>>> I think this problem becomes clearer if you consider a splicer that =
is
>>> reading the content to be inserted from a local file on disk. In =
that
>>> case, the splicer is unquestionably a standard RTP translator, in =
the
>>> middle of a one-to-one or one-to-many RTP session.
>>>=20
>>> That there are also some cases where an entirely separate RTP =
session
>>> is used to deliver the content to be inserted doesn't (conceptually)
>>> affect the translation process at all.
>>>=20
>>> Colin
>>>=20
>>>=20
>>>=20
>>> On 21 Oct 2010, at 07:56, Roni Even wrote:
>>>> Hi Colin,
>>>> I am not so sure about this being a regular RTP translator. =
According
>>> To RFC 5117 " A Translator always keeps the SSRC for a stream across
>>> the translation". Also in the splicing case it is not point to point =
or
>>> multipoint but more like multipoint to point or multipoint. This =
looks
>>> more like a mixer that does not provide the CSRC since one of the
>>> requirements is to make it look to the receiver that all the media =
is
>>> coming from the same source. One issue that will need to be =
addressed
>>> is how to report the RTCP RR from the receivers back to the sender =
of
>>> the primary or insertion streams. This may need some state keeping =
in
>>> the splicer.
>>>>=20
>>>> Roni Even
>>>>=20
>>>>> -----Original Message-----
>>>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf
>>> Of
>>>>> Colin Perkins
>>>>> Sent: Wednesday, October 20, 2010 3:52 PM
>>>>> To: Jinwei Xia
>>>>> Cc: 'IETF AVT WG'
>>>>> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
>>>>> splicing-for-rtp-00
>>>>>=20
>>>>> Hi Jinwei,
>>>>>=20
>>>>> My impression is that this draft confuses the issue by focussing =
too
>>> much on scenarios where the content to be inserted is also delivered
>>> over RTP. Whether the content to be inserted is delivered as a real-
>>> time RTP stream or fetched from local file storage does not affect =
the
>>> insertion process, and so doesn't need to be mentioned in the draft. =
I
>>> still believe that a standard RTP translator is sufficient to solve
>>> this problem, although there may be useful things to say about how =
to
>>> efficiently implement such a translator.
>>>>>=20
>>>>> Colin
>>>>>=20
>>>>>=20
>>>>> On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
>>>>>> Hi,
>>>>>>=20
>>>>>> =46rom the discussion on IETF 78th, there were some =
misunderstandings
>>>>> of the scope of splicing draft. So we discard previous problem
>>>>> statement draft while initiate new solution draft. In this new
>>> draft,
>>>>> We emphysize content insertion issue is indeed a RTP-generic =
rather
>>>>> than MPEG2 TS-specific.
>>>>>>=20
>>>>>> Hope the new draft can address most issues AVT concern, any
>>> comments
>>>>> are very appreciated!
>>>>>>=20
>>>>>>=20
>>>>>> BR!
>>>>>>=20
>>>>>> Jinwei
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
>>>>>>> Sent: Saturday, October 16, 2010 9:58 AM
>>>>>>> To: xiajinwei@huawei.com
>>>>>>> Subject: New Version Notification for
>>>>>>> draft-xia-avt-splicing-for-rtp-00
>>>>>>>=20
>>>>>>>=20
>>>>>>> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt
>>>>>>> has been successfully submitted by Jinwei Xia and posted to
>>>>>>> the IETF repository.
>>>>>>>=20
>>>>>>> Filename:	 draft-xia-avt-splicing-for-rtp
>>>>>>> Revision:	 00
>>>>>>> Title:		 Content Splicing for RTP Sessions
>>>>>>> Creation_date:	 2010-10-16
>>>>>>> WG ID:		 Independent Submission
>>>>>>> Number_of_pages: 12
>>>>>>>=20
>>>>>>> Abstract:
>>>>>>> This memo outlines RTP splicing.  Splicing is a process that
>>>>>>> allows a new multimedia stream to be inserted into current
>>>>>>> multimedia stream and to be conveyed to receiver for a period
>>>>>>> of time.  This memo discusses the requirements of RTP
>>>>>>> splicing.  In order to satisfy the requirements, this memo
>>>>>>> lists several existing intermediary network elements as
>>>>>>> alternatives and evaluates whether one of alternatives can be
>>>>>>> used to perform RTP splicing.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> The IETF Secretariat.
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> Audio/Video Transport Working Group
>>>>>> avt@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/avt
>>>>>=20
>>>>> --
>>>>> Colin Perkins
>>>>> http://csperkins.org/
>>=20
>> _______________________________________________
>> Audio/Video Transport Working Group
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>=20
>=20
>=20
> --=20
> Colin Perkins
> http://csperkins.org/
>=20
>=20
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt


--PGP_Universal_7E90D295_CFA14739_42A76F8A_41380B46
Content-Type: application/pgp-signature;
	x-mac-type=70674453;
	name=PGP.sig
Content-Disposition: attachment; filename=PGP.sig

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 10.0.2 (Build 13)

iQA/AwUBTMCiB41mhLZU3SrmEQIotACgljgEklZiONtbM+L2TNYbErmPJVYAnRY6
02IQfrAf7Mdv2os+Sci3afsu
=UE07
-----END PGP SIGNATURE-----

--PGP_Universal_7E90D295_CFA14739_42A76F8A_41380B46--

From Even.roni@huawei.com  Thu Oct 21 13:49:00 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B241F3A682D for ; Thu, 21 Oct 2010 13:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.435
X-Spam-Level: 
X-Spam-Status: No, score=-100.435 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVtvJl-27kVG for ; Thu, 21 Oct 2010 13:48:59 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0319F3A67B3 for ; Thu, 21 Oct 2010 13:48:59 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAN00315R806H@szxga04-in.huawei.com> for avt@ietf.org; Fri, 22 Oct 2010 04:50:25 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAN004IRR80RK@szxga04-in.huawei.com> for avt@ietf.org; Fri, 22 Oct 2010 04:50:24 +0800 (CST)
Received: from windows8d787f9 (bzq-79-178-39-121.red.bezeqint.net [79.178.39.121]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAN005UPR7OFH@szxml01-in.huawei.com>; Fri, 22 Oct 2010 04:50:24 +0800 (CST)
Date: Thu, 21 Oct 2010 22:47:08 +0200
From: Roni Even 
In-reply-to: <72B2F4CF-DC7A-4A03-B358-276E8C5DECFE@cisco.com>
To: 'David R Oran' , 'Colin Perkins' 
Message-id: <008301cb7161$27c1a680$7744f380$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: en-us
Content-transfer-encoding: 7BIT
Thread-index: ActxXk6dGcj6xFEHRGe2cZ01/QAcmgAARCQw
References: <002d01cb6cd6$b24e2ce0$3c298a0a@china.huawei.com>  <05e901cb70ed$1dca0510$595e0f30$%roni@huawei.com> <242A9169-3AE9-4C55-817A-B7B93F6005C9@csperkins.org> <006601cb714d$7b22f4a0$7168dde0$%roni@huawei.com> <8DB5DBDB-E336-4826-9128-FC4CD8404305@csperkins.org> <72B2F4CF-DC7A-4A03-B358-276E8C5DECFE@cisco.com>
Cc: 'IETF AVT WG' 
Subject: Re: [AVT] FW: New Version Notification for	draft-xia-avt-splicing-for-rtp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 20:49:00 -0000

Dave,
So the first question is if this is really one stream or is it two mixed
streams. My feeling was that it is two mixed streams and not one.

Now if it is two mixed streams than one of the requirements is that the
receiver will not identify which one is the inserted stream easily. So I am
not sure if CSRC is not contradictory.

I thought that we are talking here about a mixer but the case that Colin
provided when the inserted stream is local to splicer makes it more of a
translator except maybe the handling of the RTCP.

BTW: RTP translator and mixer are two of the topologies in RFC 5117, you can
also suggest that this is a Topo-RTCP-terminating-MCU doing video and audio
switch.

Roni Even



> -----Original Message-----
> From: David R Oran [mailto:oran@cisco.com]
> Sent: Thursday, October 21, 2010 10:27 PM
> To: Colin Perkins
> Cc: Roni Even; 'IETF AVT WG'
> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
> splicing-for-rtp-00
> 
> 
> On Oct 21, 2010, at 4:17 PM, Colin Perkins wrote:
> 
> > Roni,
> >
> > I don't think it matters that the content arrives as an RTP stream.
> It's an entirely separate stream, and doesn't affect the translation
> process. They're logically separate.
> >
> I agree with Colin here.
> 
> Either you treat the streams as equal inputs to a mixer, and the case
> reduces to the problem of a video mixer doing input switching, or you
> treat all the other inputs as external stuff that gets inserted into
> the main stream using a translator.
> 
> If you choose the mixer approach, you have to be a legal mixer, which
> means you keep state, use your own SSRC, and report CSRCs.
> 
> If you choose the translator approach, you have to "consume" the other
> stream and then emit it as if it were emitted by the original stream's
> source.
> 
> I don't see what the other approaches would be or how they might work
> better.
> 
> DaveO.
> 
> > Colin
> >
> >
> >
> > On 21 Oct 2010, at 19:26, Roni Even wrote:
> >> Hi Colin,
> >> In this use case the inserted content is not an RTP stream but comes
> from a local storage. For this use case the splicer is a translator. It
> will still need to handle the RTCP RR depending on who originated the
> data that was sent by the translator.
> >> My question will be if this is the typical use case or is there a
> use case where the inserted data is not local and may arrive as RTP
> stream. In which case there is more than one topology
> >>
> >> Roni
> >>
> >>> -----Original Message-----
> >>> From: Colin Perkins [mailto:csp@csperkins.org]
> >>> Sent: Thursday, October 21, 2010 7:23 PM
> >>> To: Roni Even
> >>> Cc: 'Jinwei Xia'; 'IETF AVT WG'
> >>> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
> >>> splicing-for-rtp-00
> >>>
> >>> Hi Roni,
> >>>
> >>> I think this problem becomes clearer if you consider a splicer that
> is
> >>> reading the content to be inserted from a local file on disk. In
> that
> >>> case, the splicer is unquestionably a standard RTP translator, in
> the
> >>> middle of a one-to-one or one-to-many RTP session.
> >>>
> >>> That there are also some cases where an entirely separate RTP
> session
> >>> is used to deliver the content to be inserted doesn't
> (conceptually)
> >>> affect the translation process at all.
> >>>
> >>> Colin
> >>>
> >>>
> >>>
> >>> On 21 Oct 2010, at 07:56, Roni Even wrote:
> >>>> Hi Colin,
> >>>> I am not so sure about this being a regular RTP translator.
> According
> >>> To RFC 5117 " A Translator always keeps the SSRC for a stream
> across
> >>> the translation". Also in the splicing case it is not point to
> point or
> >>> multipoint but more like multipoint to point or multipoint. This
> looks
> >>> more like a mixer that does not provide the CSRC since one of the
> >>> requirements is to make it look to the receiver that all the media
> is
> >>> coming from the same source. One issue that will need to be
> addressed
> >>> is how to report the RTCP RR from the receivers back to the sender
> of
> >>> the primary or insertion streams. This may need some state keeping
> in
> >>> the splicer.
> >>>>
> >>>> Roni Even
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On
> Behalf
> >>> Of
> >>>>> Colin Perkins
> >>>>> Sent: Wednesday, October 20, 2010 3:52 PM
> >>>>> To: Jinwei Xia
> >>>>> Cc: 'IETF AVT WG'
> >>>>> Subject: Re: [AVT] FW: New Version Notification for draft-xia-
> avt-
> >>>>> splicing-for-rtp-00
> >>>>>
> >>>>> Hi Jinwei,
> >>>>>
> >>>>> My impression is that this draft confuses the issue by focussing
> too
> >>> much on scenarios where the content to be inserted is also
> delivered
> >>> over RTP. Whether the content to be inserted is delivered as a
> real-
> >>> time RTP stream or fetched from local file storage does not affect
> the
> >>> insertion process, and so doesn't need to be mentioned in the
> draft. I
> >>> still believe that a standard RTP translator is sufficient to solve
> >>> this problem, although there may be useful things to say about how
> to
> >>> efficiently implement such a translator.
> >>>>>
> >>>>> Colin
> >>>>>
> >>>>>
> >>>>> On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> From the discussion on IETF 78th, there were some
> misunderstandings
> >>>>> of the scope of splicing draft. So we discard previous problem
> >>>>> statement draft while initiate new solution draft. In this new
> >>> draft,
> >>>>> We emphysize content insertion issue is indeed a RTP-generic
> rather
> >>>>> than MPEG2 TS-specific.
> >>>>>>
> >>>>>> Hope the new draft can address most issues AVT concern, any
> >>> comments
> >>>>> are very appreciated!
> >>>>>>
> >>>>>>
> >>>>>> BR!
> >>>>>>
> >>>>>> Jinwei
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> >>>>>>> Sent: Saturday, October 16, 2010 9:58 AM
> >>>>>>> To: xiajinwei@huawei.com
> >>>>>>> Subject: New Version Notification for
> >>>>>>> draft-xia-avt-splicing-for-rtp-00
> >>>>>>>
> >>>>>>>
> >>>>>>> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt
> >>>>>>> has been successfully submitted by Jinwei Xia and posted to
> >>>>>>> the IETF repository.
> >>>>>>>
> >>>>>>> Filename:	 draft-xia-avt-splicing-for-rtp
> >>>>>>> Revision:	 00
> >>>>>>> Title:		 Content Splicing for RTP Sessions
> >>>>>>> Creation_date:	 2010-10-16
> >>>>>>> WG ID:		 Independent Submission
> >>>>>>> Number_of_pages: 12
> >>>>>>>
> >>>>>>> Abstract:
> >>>>>>> This memo outlines RTP splicing.  Splicing is a process that
> >>>>>>> allows a new multimedia stream to be inserted into current
> >>>>>>> multimedia stream and to be conveyed to receiver for a period
> >>>>>>> of time.  This memo discusses the requirements of RTP
> >>>>>>> splicing.  In order to satisfy the requirements, this memo
> >>>>>>> lists several existing intermediary network elements as
> >>>>>>> alternatives and evaluates whether one of alternatives can be
> >>>>>>> used to perform RTP splicing.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> The IETF Secretariat.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Audio/Video Transport Working Group
> >>>>>> avt@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/avt
> >>>>>
> >>>>> --
> >>>>> Colin Perkins
> >>>>> http://csperkins.org/
> >>
> >> _______________________________________________
> >> Audio/Video Transport Working Group
> >> avt@ietf.org
> >> https://www.ietf.org/mailman/listinfo/avt
> >
> >
> >
> > --
> > Colin Perkins
> > http://csperkins.org/
> >
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt


From john.lazzaro@gmail.com  Thu Oct 21 13:52:51 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0D73A67F6 for ; Thu, 21 Oct 2010 13:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bw77U8DdUtP3 for ; Thu, 21 Oct 2010 13:52:50 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B6EE23A67AB for ; Thu, 21 Oct 2010 13:52:50 -0700 (PDT)
Received: by qwb7 with SMTP id 7so56202qwb.31 for ; Thu, 21 Oct 2010 13:54:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=7jQc+QR+A3KGCV9QoYvJRwTQB6f7vMqX7fvsgjdPI2c=; b=KFCDNjIxopoIK2j8nwkMbEpc01EpGjJqodIlpnCSdMsoJIc4+IdgR+Roxh3HhBUDNW 5NaVpfgo9TuMS/q44COAeooBnqRs/amCpc6rNYfkLrMacyREDkSoZlb5z/bvOq6L+k2B khnrw+VAyKOuGU2LCi8PNdX/dEq52sIepoI6M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HQ+k1R4N4tMveJgaRgryRPc4IvdX8E5XpQugM+Jj2i9uKiQTzNrBXhGOCQJJCuBL0E K7SqYgRHa89CAy+8hQ7dwmpsLFC5m8mnjB3qBzebMP2Zb4/mMH4fYbjaNGS5lC9pFUf6 Y6emmDAd6jMNSeuQWY5is8C9cTRNDmoAyEiok=
MIME-Version: 1.0
Received: by 10.229.211.71 with SMTP id gn7mr1228324qcb.209.1287694466559; Thu, 21 Oct 2010 13:54:26 -0700 (PDT)
Received: by 10.229.89.9 with HTTP; Thu, 21 Oct 2010 13:54:25 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 21 Oct 2010 13:54:25 -0700
Message-ID: 
From: John Lazzaro 
To: Peter Musgrave 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF AVT WG 
Subject: Re: [AVT] Errata Updates for AVT RFC4696/RFC5109
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 20:52:51 -0000

Hi Peter,

I'm maintaining the RFC 4695 bis I-D, and had a
question on your email that was CC'd to AVT:

On Thu, Oct 21, 2010 at 1:21 PM, Peter Musgrave
 wrote:
> RFC4695
> http://www.rfc-editor.org/errata_search.php?eid=861
> Errata correctly notes error in ASCII characters for P and Q
> Action:Hold For Doc Update (unlikely to stump anyone implementing)

Does this imply that you don't think we
should moving the RFC 4695 bis out
of the current cycle of "refresh the I-D
as-is every six months" mode at this time?

Or is this "action" orthogonal to the
decision to do a "Last Call" on the bis?

Thanks,

-- 
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
john [dot] lazzaro [at] gmail [dot] com

From peter.musgrave@magorcorp.com  Thu Oct 21 14:05:06 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52953A6870 for ; Thu, 21 Oct 2010 14:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.603
X-Spam-Level: 
X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHNZxIjUBBAT for ; Thu, 21 Oct 2010 14:05:05 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 47B6A3A68B0 for ; Thu, 21 Oct 2010 14:05:05 -0700 (PDT)
Received: by ywo32 with SMTP id 32so74969ywo.31 for ; Thu, 21 Oct 2010 14:06:41 -0700 (PDT)
Received: by 10.150.12.15 with SMTP id 15mr4630279ybl.175.1287695201107; Thu, 21 Oct 2010 14:06:41 -0700 (PDT)
Received: from [10.126.98.159] ([24.114.235.34]) by mx.google.com with ESMTPS id q14sm2676654ybk.19.2010.10.21.14.06.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Oct 2010 14:06:40 -0700 (PDT)
References:  
In-Reply-To: 
Mime-Version: 1.0 (iPhone Mail 8B117)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <68E9EA17-880E-4B51-8A49-CAE9E1C374E6@magorcorp.com>
X-Mailer: iPhone Mail (8B117)
From: Peter Musgrave 
Date: Thu, 21 Oct 2010 17:06:18 -0400
To: John Lazzaro 
Cc: IETF AVT WG 
Subject: Re: [AVT] Errata Updates for AVT RFC4696/RFC5109
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 21:05:06 -0000

Hi John,

I was unaware of the bis.

This was part of an orthogonal effort to deal with reported errata backlog. I=
f it gets considered next time around I see no issues...

Regards

Peter Musgrave

Sent from my iPhone

On 2010-10-21, at 4:54 PM, John Lazzaro  wrote:

> Hi Peter,
>=20
> I'm maintaining the RFC 4695 bis I-D, and had a
> question on your email that was CC'd to AVT:
>=20
> On Thu, Oct 21, 2010 at 1:21 PM, Peter Musgrave
>  wrote:
>> RFC4695
>> http://www.rfc-editor.org/errata_search.php?eid=3D861
>> Errata correctly notes error in ASCII characters for P and Q
>> Action:Hold For Doc Update (unlikely to stump anyone implementing)
>=20
> Does this imply that you don't think we
> should moving the RFC 4695 bis out
> of the current cycle of "refresh the I-D
> as-is every six months" mode at this time?
>=20
> Or is this "action" orthogonal to the
> decision to do a "Last Call" on the bis?
>=20
> Thanks,
>=20
> --=20
> John Lazzaro
> http://www.cs.berkeley.edu/~lazzaro
> john [dot] lazzaro [at] gmail [dot] com

From oran@cisco.com  Thu Oct 21 15:25:14 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9539D3A63EB for ; Thu, 21 Oct 2010 15:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4QVfX6GzlBC for ; Thu, 21 Oct 2010 15:25:13 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0BDEC3A63CA for ; Thu, 21 Oct 2010 15:25:13 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: PGP.sig : 194
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAF9awEyrRN+J/2dsb2JhbAChX3GjZ5w9gnWCVQSKTYME
X-IronPort-AV: E=Sophos;i="4.58,219,1286150400";  d="sig'?scan'208";a="204737037"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 21 Oct 2010 22:26:49 +0000
Received: from OranMBP.local (stealth-10-32-245-153.cisco.com [10.32.245.153]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9LMQa8T016938 for ; Thu, 21 Oct 2010 22:26:48 GMT
Received: from [127.0.0.1] by OranMBP.local (PGP Universal service); Thu, 21 Oct 2010 18:26:49 -0400
X-PGP-Universal: processed; by OranMBP.local on Thu, 21 Oct 2010 18:26:49 -0400
Mime-Version: 1.0 (Apple Message framework v1081)
From: David R Oran 
In-Reply-To: <008301cb7161$27c1a680$7744f380$%roni@huawei.com>
Date: Thu, 21 Oct 2010 18:26:31 -0400
Message-Id: 
References: <002d01cb6cd6$b24e2ce0$3c298a0a@china.huawei.com>  <05e901cb70ed$1dca0510$595e0f30$%roni@huawei.com> <242A9169-3AE9-4C55-817A-B7B93F6005C9@csperkins.org> <006601cb714d$7b22f4a0$7168dde0$%roni@huawei.com> <8DB5DBDB-E336-4826-9128-FC4CD8404305@csperkins.org> <72B2F4CF-DC7A-4A03-B358-276E8C5DECFE@cisco.com> <008301cb7161$27c1a680$7744f380$%roni@huawei.com>
To: Roni Even 
X-Mailer: Apple Mail (2.1081)
X-PGP-Encoding-Format: MIME
X-PGP-Encoding-Version: 2.0.2
Content-Type: multipart/signed; boundary="PGP_Universal_46D5A4A9_2E9F932B_5897F78E_0D08BE5D"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Cc: 'Colin Perkins' , 'IETF AVT WG' 
Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-splicing-for-rtp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Oct 2010 22:25:14 -0000

--PGP_Universal_46D5A4A9_2E9F932B_5897F78E_0D08BE5D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable


On Oct 21, 2010, at 4:47 PM, Roni Even wrote:

> Dave,
> So the first question is if this is really one stream or is it two =
mixed
> streams. My feeling was that it is two mixed streams and not one.
>=20
> Now if it is two mixed streams than one of the requirements is that =
the
> receiver will not identify which one is the inserted stream easily.
So he can't skip ads, or something else?

> So I am
> not sure if CSRC is not contradictory.
>=20
Interesting conundrum, no?

> I thought that we are talking here about a mixer but the case that =
Colin
> provided when the inserted stream is local to splicer makes it more of =
a
> translator except maybe the handling of the RTCP.
>=20
> BTW: RTP translator and mixer are two of the topologies in RFC 5117, =
you can
> also suggest that this is a Topo-RTCP-terminating-MCU doing video and =
audio
> switch.
>=20
Right, in which case we're back to the CSRC-related conflicting goals.

> Roni Even
>=20
>=20
>=20
>> -----Original Message-----
>> From: David R Oran [mailto:oran@cisco.com]
>> Sent: Thursday, October 21, 2010 10:27 PM
>> To: Colin Perkins
>> Cc: Roni Even; 'IETF AVT WG'
>> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
>> splicing-for-rtp-00
>>=20
>>=20
>> On Oct 21, 2010, at 4:17 PM, Colin Perkins wrote:
>>=20
>>> Roni,
>>>=20
>>> I don't think it matters that the content arrives as an RTP stream.
>> It's an entirely separate stream, and doesn't affect the translation
>> process. They're logically separate.
>>>=20
>> I agree with Colin here.
>>=20
>> Either you treat the streams as equal inputs to a mixer, and the case
>> reduces to the problem of a video mixer doing input switching, or you
>> treat all the other inputs as external stuff that gets inserted into
>> the main stream using a translator.
>>=20
>> If you choose the mixer approach, you have to be a legal mixer, which
>> means you keep state, use your own SSRC, and report CSRCs.
>>=20
>> If you choose the translator approach, you have to "consume" the =
other
>> stream and then emit it as if it were emitted by the original =
stream's
>> source.
>>=20
>> I don't see what the other approaches would be or how they might work
>> better.
>>=20
>> DaveO.
>>=20
>>> Colin
>>>=20
>>>=20
>>>=20
>>> On 21 Oct 2010, at 19:26, Roni Even wrote:
>>>> Hi Colin,
>>>> In this use case the inserted content is not an RTP stream but =
comes
>> from a local storage. For this use case the splicer is a translator. =
It
>> will still need to handle the RTCP RR depending on who originated the
>> data that was sent by the translator.
>>>> My question will be if this is the typical use case or is there a
>> use case where the inserted data is not local and may arrive as RTP
>> stream. In which case there is more than one topology
>>>>=20
>>>> Roni
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Colin Perkins [mailto:csp@csperkins.org]
>>>>> Sent: Thursday, October 21, 2010 7:23 PM
>>>>> To: Roni Even
>>>>> Cc: 'Jinwei Xia'; 'IETF AVT WG'
>>>>> Subject: Re: [AVT] FW: New Version Notification for draft-xia-avt-
>>>>> splicing-for-rtp-00
>>>>>=20
>>>>> Hi Roni,
>>>>>=20
>>>>> I think this problem becomes clearer if you consider a splicer =
that
>> is
>>>>> reading the content to be inserted from a local file on disk. In
>> that
>>>>> case, the splicer is unquestionably a standard RTP translator, in
>> the
>>>>> middle of a one-to-one or one-to-many RTP session.
>>>>>=20
>>>>> That there are also some cases where an entirely separate RTP
>> session
>>>>> is used to deliver the content to be inserted doesn't
>> (conceptually)
>>>>> affect the translation process at all.
>>>>>=20
>>>>> Colin
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 21 Oct 2010, at 07:56, Roni Even wrote:
>>>>>> Hi Colin,
>>>>>> I am not so sure about this being a regular RTP translator.
>> According
>>>>> To RFC 5117 " A Translator always keeps the SSRC for a stream
>> across
>>>>> the translation". Also in the splicing case it is not point to
>> point or
>>>>> multipoint but more like multipoint to point or multipoint. This
>> looks
>>>>> more like a mixer that does not provide the CSRC since one of the
>>>>> requirements is to make it look to the receiver that all the media
>> is
>>>>> coming from the same source. One issue that will need to be
>> addressed
>>>>> is how to report the RTCP RR from the receivers back to the sender
>> of
>>>>> the primary or insertion streams. This may need some state keeping
>> in
>>>>> the splicer.
>>>>>>=20
>>>>>> Roni Even
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On
>> Behalf
>>>>> Of
>>>>>>> Colin Perkins
>>>>>>> Sent: Wednesday, October 20, 2010 3:52 PM
>>>>>>> To: Jinwei Xia
>>>>>>> Cc: 'IETF AVT WG'
>>>>>>> Subject: Re: [AVT] FW: New Version Notification for draft-xia-
>> avt-
>>>>>>> splicing-for-rtp-00
>>>>>>>=20
>>>>>>> Hi Jinwei,
>>>>>>>=20
>>>>>>> My impression is that this draft confuses the issue by focussing
>> too
>>>>> much on scenarios where the content to be inserted is also
>> delivered
>>>>> over RTP. Whether the content to be inserted is delivered as a
>> real-
>>>>> time RTP stream or fetched from local file storage does not affect
>> the
>>>>> insertion process, and so doesn't need to be mentioned in the
>> draft. I
>>>>> still believe that a standard RTP translator is sufficient to =
solve
>>>>> this problem, although there may be useful things to say about how
>> to
>>>>> efficiently implement such a translator.
>>>>>>>=20
>>>>>>> Colin
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
>>>>>>>> Hi,
>>>>>>>>=20
>>>>>>>> =46rom the discussion on IETF 78th, there were some
>> misunderstandings
>>>>>>> of the scope of splicing draft. So we discard previous problem
>>>>>>> statement draft while initiate new solution draft. In this new
>>>>> draft,
>>>>>>> We emphysize content insertion issue is indeed a RTP-generic
>> rather
>>>>>>> than MPEG2 TS-specific.
>>>>>>>>=20
>>>>>>>> Hope the new draft can address most issues AVT concern, any
>>>>> comments
>>>>>>> are very appreciated!
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> BR!
>>>>>>>>=20
>>>>>>>> Jinwei
>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
>>>>>>>>> Sent: Saturday, October 16, 2010 9:58 AM
>>>>>>>>> To: xiajinwei@huawei.com
>>>>>>>>> Subject: New Version Notification for
>>>>>>>>> draft-xia-avt-splicing-for-rtp-00
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt
>>>>>>>>> has been successfully submitted by Jinwei Xia and posted to
>>>>>>>>> the IETF repository.
>>>>>>>>>=20
>>>>>>>>> Filename:	 draft-xia-avt-splicing-for-rtp
>>>>>>>>> Revision:	 00
>>>>>>>>> Title:		 Content Splicing for RTP Sessions
>>>>>>>>> Creation_date:	 2010-10-16
>>>>>>>>> WG ID:		 Independent Submission
>>>>>>>>> Number_of_pages: 12
>>>>>>>>>=20
>>>>>>>>> Abstract:
>>>>>>>>> This memo outlines RTP splicing.  Splicing is a process that
>>>>>>>>> allows a new multimedia stream to be inserted into current
>>>>>>>>> multimedia stream and to be conveyed to receiver for a period
>>>>>>>>> of time.  This memo discusses the requirements of RTP
>>>>>>>>> splicing.  In order to satisfy the requirements, this memo
>>>>>>>>> lists several existing intermediary network elements as
>>>>>>>>> alternatives and evaluates whether one of alternatives can be
>>>>>>>>> used to perform RTP splicing.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> The IETF Secretariat.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> Audio/Video Transport Working Group
>>>>>>>> avt@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/avt
>>>>>>>=20
>>>>>>> --
>>>>>>> Colin Perkins
>>>>>>> http://csperkins.org/
>>>>=20
>>>> _______________________________________________
>>>> Audio/Video Transport Working Group
>>>> avt@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/avt
>>>=20
>>>=20
>>>=20
>>> --
>>> Colin Perkins
>>> http://csperkins.org/
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> Audio/Video Transport Working Group
>>> avt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt
>=20


--PGP_Universal_46D5A4A9_2E9F932B_5897F78E_0D08BE5D
Content-Type: application/pgp-signature;
	x-mac-type=70674453;
	name=PGP.sig
Content-Disposition: attachment; filename=PGP.sig

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 10.0.2 (Build 13)

iQA/AwUBTMC+Io1mhLZU3SrmEQICrwCfWK6s7JIH4iPnh3InrVMKfjLnb3QAoK9u
ShJgWqY3ZyQJfC9t9pFGdKt0
=JM0o
-----END PGP SIGNATURE-----

--PGP_Universal_46D5A4A9_2E9F932B_5897F78E_0D08BE5D--

From Bing.He@alcatel-sbell.com.cn  Thu Oct 21 17:58:25 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77ADB3A67FA for ; Thu, 21 Oct 2010 17:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLU3eeaWggSi for ; Thu, 21 Oct 2010 17:58:24 -0700 (PDT)
Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by core3.amsl.com (Postfix) with ESMTP id 368493A67DA for ; Thu, 21 Oct 2010 17:58:24 -0700 (PDT)
X-AuditID: ac189297-b7c7aae000003d42-08-4cc0e20d4c7b
Received: from cnshgsbhs02.ad4.ad.alcatel.com (Unknown_Domain [172.24.146.147]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Brightmail Gateway) with SMTP id 7A.F8.15682.D02E0CC4; Fri, 22 Oct 2010 08:59:58 +0800 (HKT)
Received: from CNSHGSMBS04.ad4.ad.alcatel.com ([172.24.146.175]) by cnshgsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Oct 2010 08:59:57 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7184.71A82C21"
Date: Fri, 22 Oct 2010 08:59:57 +0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC4733/2833 related: Should volume field value be used in regenerating DTMF tone?
Thread-Index: ActxhHICPsCv10GQTOmPFOfevAAHBw==
From: "HE Bing" 
To: , , , 
X-OriginalArrivalTime: 22 Oct 2010 00:59:57.0124 (UTC) FILETIME=[71EE1040:01CB7184]
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: AAAAAA==
Cc: XU Hui N , Felizardo Jose 
Subject: [AVT] RFC4733/2833 related: Should volume field value be used in regenerating DTMF tone?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 00:58:25 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB7184.71A82C21
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hello Mr Schulzrinne, et. all

We got a different understanding from our DSP vendor regrading the DTMF
relay based on NTE packet defined in RFC 2833 and later 4733, thus we
need your help for clarification.

Our DSP vendor uses a hardcoded power level instead of the valid value
carried by the volume field in NTE packet and declare this does not
violate RFC 2833 and RFC 4733 due to no explicit statement telling that
value SHALL or SHOULD be used.

We can say nothing bu we do think the volume field value SHALL be used
in generating DTMF tone as long as it is valid. Each DSP vendor may have
different implementation, but if support of RFC 2833 or 4733 is
declared, use of volume field has to be supported at least as an option.
We already run into problem in a customer project where the terminal
expect DTMF signal with power level higher than the hardcoded value.

Could you share with your opinion? If the volume field is not used in
reconstructing the relayed DTMF and other tone, then any other
motivation to design such a field within NTE packet?

Thanks a lot for your clarification!
Best regard.
He Bing

------_=_NextPart_001_01CB7184.71A82C21
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable






RFC4733/2833 related: Should volume field value be used in =
regenerating DTMF tone?





Hello Mr =
Schulzrinne, et. all




We got a =
different understanding from our DSP vendor regrading the DTMF relay =
based on NTE packet defined in RFC 2833 and later 4733, thus we need =
your help for clarification.



Our DSP vendor =
uses a hardcoded power level instead of the valid value carried by the =
volume field in NTE packet and declare this does not violate RFC 2833 =
and RFC 4733 due to no explicit statement telling that value SHALL or =
SHOULD be used.



We can say =
nothing bu we do think the volume field value SHALL be used in =
generating DTMF tone as long as it is valid. Each DSP vendor may have =
different implementation, but if support of RFC 2833 or 4733 is =
declared, use of volume field has to be supported at least as an =
option.



We already run =
into problem in a customer project where the terminal expect DTMF signal =
with power level higher than the hardcoded value.



Could you =
share with your opinion? If the volume field is not used in =
reconstructing the relayed DTMF and other tone, then any other =
motivation to design such a field within NTE packet?



Thanks a lot =
for your clarification!


Best =
regard.


He =
Bing





------_=_NextPart_001_01CB7184.71A82C21--

From yangpeilin@huawei.com  Thu Oct 21 18:48:37 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D96C3A67DB for ; Thu, 21 Oct 2010 18:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.688
X-Spam-Level: 
X-Spam-Status: No, score=-96.688 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_39=0.6, J_CHICKENPOX_73=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eID8SIdpbr5h for ; Thu, 21 Oct 2010 18:48:35 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9B57B3A6359 for ; Thu, 21 Oct 2010 18:48:34 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAO001NV53C3A@szxga04-in.huawei.com> for avt@ietf.org; Fri, 22 Oct 2010 09:50:00 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAO00ARS53CWX@szxga04-in.huawei.com> for avt@ietf.org; Fri, 22 Oct 2010 09:50:00 +0800 (CST)
Received: from [172.24.1.33] (Forwarded-For: [10.138.41.38]) by szxmc03-in.huawei.com (mshttpd); Fri, 22 Oct 2010 09:50:00 +0800
Date: Fri, 22 Oct 2010 09:50:00 +0800
From: Peilin YANG 
In-reply-to: <20101018083510.47F373A6CC4@core3.amsl.com>
To: avt@ietf.org
Message-id: 
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug  8 2006)
Content-type: multipart/mixed; boundary="Boundary_(ID_bYWwj9XuKpPo+NXpxFhQcA)"
Content-language: zh-CN
X-Accept-Language: zh-CN
Priority: normal
References: <20101018083510.47F373A6CC4@core3.amsl.com>
Subject: [AVT] FW: New Version Notification for draft-yang-avt-switch-multicast-short-timeshift-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 01:48:37 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_bYWwj9XuKpPo+NXpxFhQcA)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable
Content-disposition: inline

Hi=2C

Please check the attached -00 draft on =22Switching from unicast to multi=
cast for multicast short time-shift=22=2E Also=2C URI is as below=3A
http=3A//www=2Eietf=2Eorg/id/draft-yang-avt-switch-multicast-short-timesh=
ift-00=2Etxt

Any comments are welcome=2E =


Best regards=2C

Peilin


----- =D4=AD=D3=CA=BC=FE -----
=B7=A2=BC=FE=C8=CB=3A IETF I-D Submission Tool =3Cidsubmission=40ietf=2Eo=
rg=3E
=C8=D5=C6=DA=3A =D0=C7=C6=DA=D2=BB=2C =CA=AE=D4=C2 18=C8=D5=2C 2010 =CF=C2=
=CE=E74=3A37
=D6=F7=CC=E2=3A New Version Notification for draft-yang-avt-switch-multic=
ast-short-timeshift-00
=CA=D5=BC=FE=C8=CB=3A yangpeilin=40huawei=2Ecom
=B3=AD=CB=CD=3A Even=2Eroni=40huawei=2Ecom=2C hassnaa=2Emoustafa=40orange=
-ftgroup=2Ecom=2C tena=40huawei=2Ecom=2C guyingjie=40huawei=2Ecom

A new version of I-D=2C draft-yang-avt-switch-multicast-short-timeshift-0=
0=2Etxt has been successfully submitted by Peilin Yang and posted to the =
IETF repository=2E

Filename=3A         draft-yang-avt-switch-multicast-short-timeshift
Revision=3A         00
Title=3A                 Switching from unicast to multicast for multicas=
t short time-shift
Creation=5Fdate=3A         2010-10-18
WG ID=3A                 Independent Submission
Number=5Fof=5Fpages=3A 11

Abstract=3A
When a client requests a time-shift service for a multicast session
using RTP for media transport=2C like pause=2C instant replay=2C slow-
motion video=2C frame-by-frame viewing=2C rewind=2C fast-forward=2C etc=2E=
=2C it
needs to switch from multicast session to unicast session=2E  This
unicast session will always serve for the time-shift service unless
the client manually switches back to the multicast session=2E  Actually
a time- shift request may happens for all clients=2E  That is=2C
multicast session stream will be replaced by many unicast time-shift
streams having significant impact on network bandwidth usage=2E

In this document=2C we describe a method using existing RTP and RTCP
protocol infrastructure that switches back to multicast session from
unicast session of time-shift=2E  In this method=2C a burst RTP flow
which is a little faster than the primary multicast rate may be
transmitted so that unicast session may catch up and switch back to
multicast session=2E
                                                                         =
         =



The IETF Secretariat=2E


--Boundary_(ID_bYWwj9XuKpPo+NXpxFhQcA)
Content-type: text/plain;
 NAME=draft-yang-avt-switch-multicast-short-timeshift-00.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment;
 filename=draft-yang-avt-switch-multicast-short-timeshift-00.txt



Audio/Video Transport                                            P. Yang
Internet-Draft                                                   R. Even
Intended status: Standards Track           Huawei Technologies Co., Ltd.
Expires: April 21, 2011                                      H. Moustafa
                                                 France Telecom - Orange
                                                        October 18, 2010


   Switching from unicast to multicast for multicast short time-shift
         draft-yang-avt-switch-multicast-short-timeshift-00.txt

Abstract

   When a client requests a time-shift service for a multicast session
   using RTP for media transport, like pause, instant replay, slow-
   motion video, frame-by-frame viewing, rewind, fast-forward, etc., it
   needs to switch from multicast session to unicast session.  This
   unicast session will always serve for the time-shift service unless
   the client manually switches back to the multicast session.  Actually
   a time- shift request may happens for all clients.  That is,
   multicast session stream will be replaced by many unicast time-shift
   streams having significant impact on network bandwidth usage.

   In this document, we describe a method using existing RTP and RTCP
   protocol infrastructure that switches back to multicast session from
   unicast session of time-shift.  In this method, a burst RTP flow
   which is a little faster than the primary multicast rate may be
   transmitted so that unicast session may catch up and switch back to
   multicast session.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 21, 2011.

Copyright Notice



Yang, et al.             Expires April 21, 2011                 [Page 1]

Internet-Draft  Switching for multicast short time-shift    October 2010


   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  RTSP Time-shift and MST Reverse Switch . . . . . . . . . .  5
     1.2.  RAMS and MST Reverse Switch  . . . . . . . . . . . . . . .  6
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Reverse switch for multicast short time-shift  . . . . . . . .  7
     4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Message Flows  . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10






















Yang, et al.             Expires April 21, 2011                 [Page 2]

Internet-Draft  Switching for multicast short time-shift    October 2010


1.  Introduction

   Interactive time-shift is an important service for media application.
   Through time-shift control operations (e.g. pause, instant replay,
   slow-motion video, frame-by-frame viewing, rewind and fast-forward),
   viewers can access recorded programming and live streams.  The time-
   shift service is available for recorded media and real-time
   streaming.  For the real-time streaming, time-shift service requires
   recording/caching of the information.  The time-shifted information
   can be sent by the original media source or by a server in the
   network that caches the stream and provides the time-shift service.

   Note that time-shift service may run on the client side but this
   requires the client to be able to cache the stream and
   synchronization to the main multicast stream needs to be managed by
   the client and does not require any specific protocol.

   This document looks at time-shift services where the original content
   is delivered using multicast.  In this use case the time-shift
   service is using a unicast stream from a Multicast Short Time-shift
   (MST) server to the client.  The synchronization between the
   multicast and unicast stream can be achieved by the client if he is
   using control commands like fast forward or RTSP [ref] Scale request.
   The MST can notice that the client is receiving in the unicast stream
   the same information that is current in the multicast stream.

   Network traffic will rise with the increase in the number of clients
   using time-shift service, because the time-shift service traffic
   changes from a multicast stream (one multicast stream for all
   clients) to a large number of unicast streams (one unicast stream per
   client).  Time- shift services like slow-motion view, instant replay,
   frame-by-frame viewing, pause and rewind may often occur for most of
   viewers in prime-time (e.g. when watching sports events).

   We can separate the time-shift services of primary live streams
   delivered over multicast/broadcast into multicast long time-shift and
   multicast short time-shift.  Some of the manipulations requested by
   the viewers are multicast short time-shift (e.g. short pause, instant
   replay, slow-motion video and frame-by-frame viewing).  For the
   multicast short time-shift, the time offset between the unicast time-
   shift playback, after the time-shift request, and the current time of
   the primary multicast stream is small enabling the unicast stream to
   catch up with primary multicast stream by speeding up the playback,
   and then switch back to the original multicast session.

   In this document, we propose a solution for enabling the time-shifted
   stream receivers to catch up with the original multicast stream using
   the tools offered by the existing RTP and RTCP protocols.  The



Yang, et al.             Expires April 21, 2011                 [Page 3]

Internet-Draft  Switching for multicast short time-shift    October 2010


   document also describes how to switch back to the primary multicast
   session from the unicast session initiated by either the client or
   the server.  Using this solution allows the network bandwidth to be
   effectively saved for the time-shift service of multicast
   application.

   In the scenario that we consider in this draft, an intermediary
   network element (that we refer to as Multicast Short Time-shift
   server) joins the multicast session and continuously caches the
   multicast stream.  When an RTP receiver sends a time-shift request,
   the MST server starts a new unicast RTP session and transmits the
   unicast stream to the RTP receiver over that session.  A simplified
   network diagram showing this scenario employing an intermediary
   network element is shown in Figure 1, where the hashed lines show the
   unicast stream.
                  +--------------------------------+
                  |  Intermediary Network Element  |
                  |                                |
                  |          MST Server            |
                  +--------------------------------+
                                 ^ :
                                 | :
                                 | :
                                 | v
      +-----------+        +-------------+           +-------------+
      | Multicast |        |             |---------->|  Time-shift |
      |           |------->|   Router    |           |     RTP     |
      |  Source   |        |             |..........>|   Receiver  |
      +-----------+        +-------------+           +-------------+
                                   |
                                   |                 +-------------+
                                   |                 |   Existing  |
                                   +---------------->|     RTP     |
                                                     |   Receiver  |
                                                     +-------------+
         Figure 1: Reverse switch for multicast short time-shift
               through an intermediary network element

   The proposed solution is not dependent on a specific streaming
   control protocol like RTSP [ref].  It addresses the synchronization
   between a primary multicast RTP stream and a parallel time-shifted
   unicast RTP stream.  A principle design goal is to use an existing
   protocol to define this solution.  This improves the versatility of
   the existing implementations, and promotes faster deployment and
   better interoperability.  To this effect, the proposal is to use the
   switching of flows from unicast stream to multicast stream described
   in RAMS [draft-ietf-avt-rapid-acquisition-for-rtp], and use the
   capabilities of RTCP to handle the signaling needed to accomplish



Yang, et al.             Expires April 21, 2011                 [Page 4]

Internet-Draft  Switching for multicast short time-shift    October 2010


   this automatic reverse switch for multicast short time-shift.

1.1.  RTSP Time-shift and MST Reverse Switch

   RTSP 2.0[draft-ietf-mmusic-rfc2326bis] is an application-level
   protocol for setup and control of the media delivery with real-time
   properties, and provides an extensible framework to enable
   controlled, on-demand delivery of real-time data, typically streaming
   media.

   RTSP defines any necessary media transport signalling with regards to
   RTP.  In appendix C.1 it defines the interaction of RTSP with respect
   to the RTP protocol [RFC3550].  Yet RTSP is not limited to RTP media
   delivery control but any delivery type of data.  It provides a
   general media delivery control mechanism to play out the media, pause
   media, or stop media over different delivery channels, such as UDP,
   multicast UDP, TCP, RTP over UDP, etc.

   RTSP can also provide interactive time-shift function with different
   scale and speed.  Section 13.4.8 in [draft-ietf-mmusic-rfc2326bis]
   has a scenario for Playing Live with time-shift where a certain media
   server may offer time-shift services to their clients.  The usage of
   this play method can implement time- shift for Live Media or On-
   demand Media.  Section 16.44 in [draft-ietf-mmusic-rfc2326bis]
   addresses the scaling for video and audio, it suggests sending only
   key frames for video but this may not achieve the right scale speed
   since it depends on the locality of such frames in the stream.  It
   also requires analysis of the media payload for all supported codecs
   to find the key frames.  In this document we call the interactive
   time-shift function in [draft-ietf-mmusic-rfc2326bis] as "RTSP Time-
   shift".

   For Live Media using RTP multicast over UDP, RTSP Time-shift can
   provide an initial switch from multicast session to unicast session
   when time-shift happens, but it cannot complete the reverse switch
   from unicast session of time-shift to the original multicast session.

   An MST server can for example transmit the unicast stream of the
   time-shift by a short burst stream and indicate to the receivers to
   speed up the playback through Non-perceptual Speedup Playback.  After
   the burst of the unicast stream of time-shift catches up with the
   primary multicast stream, the client can switch back to the primary
   multicast stream so that the network bandwidth can be effectively
   saved.  The synchronization due to catch up with the primary
   multicast session may also happen due to the client operation like
   the fast forward.





Yang, et al.             Expires April 21, 2011                 [Page 5]

Internet-Draft  Switching for multicast short time-shift    October 2010


1.2.  RAMS and MST Reverse Switch

   RAMS [draft-ietf-avt-rapid-acquisition-for-rtp] describes a method
   using the existing RTP and RTCP protocol for reducing the acquisition
   delay, allowing fast channel switch.  RAMS defines the reverse switch
   from unicast burst session to the primary multicast session.


2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Definitions

   This document uses the following acronyms and definitions frequently:

   Time-shift Control: Refers to the manipulation control of time-shift
   service (e.g. pause, slow-motion video, frame-by-frame viewing,
   rewind, fast- forward, etc.), not include the play method.

   Time-shift Playback: Refers to the normal playback with a natural
   playback rate after the time-shift control.

   Multicast Time-shift Interval: Refers to the time interval or the
   number of packets between the primary multicast stream and the normal
   playback during the unicast session after the time-shift control.  In
   other words, it presents the time interval between the start point
   frame of the unicast session and the frame of the current location of
   the primary multicast session.

   Multicast Short Time-shift: The case when the multicast Time-shift
   Interval is short, such as 30 seconds.  The normal playback during
   the unicast session after the time-shift control means that viewers
   finish the time-shift control (e.g. pause, rewind and fast-
   forward)and start to receive the unicast stream and play back again
   at the speed of the Primary multicast stream.

   Primary multicast stream: The multicast stream before time-shift
   request.

   Instant Replay: It is the case of the replaying of video footage of
   an event or incident directly after its occurrence.  In television
   broadcasting of sports events, instant replay is often used during
   live broadcast, to show a passage of play which was important or
   remarkable, or which was unclear on the first sight.



Yang, et al.             Expires April 21, 2011                 [Page 6]

Internet-Draft  Switching for multicast short time-shift    October 2010


   Slow-motion Video: The case when the playback of a video clip appears
   to be slower than the natural speed of the events.

   Non-perceptual Speedup Playback: During the speedup playback, after
   each interval of some frames, one frame is skipped as if it was not
   present, the next frame is directly rendered to take the place of the
   skipped frame, while keeping a fixed Frame Per Second (FPS)during the
   playback speedup.


4.  Reverse switch for multicast short time-shift

   This section gives an overview on the proposed method for reverse
   multicast time- shift switch from unicast time-shift RTP Sessions.

4.1.  Overview

   RTP Control Protocol (RTCP) Extensions for Single-Source Multicast
   Sessions with Unicast Feedback [RFC5760] specifies an extension to
   the RTCP to use unicast feedback to a multicast sender.  The (Unicast
   RTCP) Feedback Target is a logical function to which RTCP unicast
   feedback traffic is addressed.  The functions of the Feedback Target
   and the Distribution Source MAY be co-located or integrated in the
   same entity.  In this case, The (Unicast RTCP) Feedback Target MAY be
   co-located or integrated in the Multicast Time-shift Server.

   This section presents a proposed method to switch back to the
   multicast session from the unicast session of time-shift considering
   multicast short time-shift.  The proposed method allows the network
   bandwidth to be effectively saved when an RTP receiver finishes its
   time-shift request and starts its time- shift playback by unicast
   stream.  A Multicast Short Time-shift Server (MST) and new RTCP
   feedback messages are also introduced for the proposed method.

   The MST server has a cache where the most recent packets from the
   primary multicast stream are continuously stored for some time.  When
   a viewer wants to normally playback the unicast stream after time-
   shift request, the RTP receiver needs to send a playback request to
   the feedback target, and then receives the unicast stream from the
   MST server.  In order to switch back to the original multicast
   stream, the MST server needs to transmit a burst unicast stream to
   RTP receivers.  Using an accelerated bitrate (as compared to the
   bitrate of the original multicast stream).  This means that at a
   certain point in time, the unicast burst will catch up with the
   original multicast stream.  At this point, the RTP receiver no longer
   needs to receive the unicast burst and can switch back to the
   original multicast session.




Yang, et al.             Expires April 21, 2011                 [Page 7]

Internet-Draft  Switching for multicast short time-shift    October 2010


   The transmission of the unicast burst stream of time-shift playback
   depends on the time-shift buffer size of RTP receivers and the
   Multicast Short Time-shift Interval.  In the case when the time-shift
   buffer size of an RTP receiver can inadequately accommodate the
   number of packets of the Multicast Short Time-shift Interval, the
   receiver needs to playback for the duration of the speeding-up until
   the remaining number of packets does not overflow at the time-shift
   buffer.  During the playback of the speeding-up, the receiver may
   speed up video playback by the non-perceptual speedup playback so
   that viewers could never perceived the existence of the speeding-up.
   Refer to [I-D.yang-avt-rtp-synced-playback]

4.2.  Message Flows

   This section introduces the different messages for the proposed
   method and the related messages flows.

   - MST(Multicast Short Time-shift) synchronization
   transmission(MSTST): This is the generic form of the different
   messages that will be transmitted during the proposed method in this
   draft for reverse switch multicast short time-shift.

   -Time-Shift-Control-Commands: This message presents the request for
   the Time-Shift service (e.g. fast forward, pause, reverse, ..etc.).
   This message may be addressed by the MST server or other time-shift
   server.

   - MSTST Playback Request(MSTST-PReq): It's the message sent from the
   RTP receiver to the MST to request the playback after the time-shift
   request.

   - MSTST Playback Response(MSTST-PRes): It's the response message sent
   from the MST to the RTP receiver to confirm the playback process
   initiation.  Following this message, the RTP receiver will receive
   the unicast burst RTP stream from the MST.

   - MSTST Synchronization Indication(MSTST-SInd): When the unicast
   burst catch up with the original multicast stream, this message is
   sent from the MST to the RTP receiver to indicate this fact.

   - MSTST Synchronization Response(MSTST-SRes): This message is sent by
   the RTP receiver as a response to the MST confirming the need to
   switch back to the original multicast session.  Following this
   message the RTP receiver is able to receive the multicast stream.

   - MSTST Termination Request(MSTST-TReq): This message is sent by the
   RTP receiver to the MST to terminate the process of the time-shift.




Yang, et al.             Expires April 21, 2011                 [Page 8]

Internet-Draft  Switching for multicast short time-shift    October 2010


   - MSTST Termination Response(MSTST-TRes): This message is a reply
   sent by the MST to the RTP to confirm to the MSTST-TReq.

                 -------------------------
                 |        MST  Server      |
    -----------  |  ------   ------------  |   --------    ------------
   | Multicast | | |  FT  | | Burst/Ret. | |  |        |  |    RTP     |
   |  Source   | | |      | |   Source   | |  | Router |  |  Receiver  |
   |           | |  ------   ------------  |  |        |  |  (RTP_Rx)  |
    -----------  |                         |   --------    ------------
         |        -------------------------       |             |
         |                   |                    |             |
         |--- RTP Multicast->-------------------->|             |
         |                   |                    |             |
         |             ................................................
         |             .                                              .
         |             .      <::Time-shift control commands ::>      .
         |             .       ..Time-shift media stream     ..>      .
         |             ................................................
         |                   |                    |             |
         |                   |<''''''''' RTCP MSTST-PReq''''''''|
         |                   |'''''''''' RTCP MSTST-PRes'''''''>|
         |                   |                    |             |
         |                   |                    |             |
         |                   |....... Unicast RTP Burst .......>|
         |                   |                    |             |
         |                   |                    |             |
         |                   |'''''''''' RTCP MSTST-SInd'''''''>|
         |                   |<''''''''' RTCP MSTST-SRes''''''''|
         |                   |                    |             |
         |                   |                    |             |
         |                   |                    |<~SFGMP Join~|
         |                   |                    |             |
         |                   |                    |             |
         |------------------ RTP Multicast -------------------->|
         |                   |                    |             |
         |                   |                    |             |
         |                   |<''''''''' RTCP MSTST-TReq''''''''|
         |                   |'''''''''' RTCP MSTST-TRes ''''''>|
         |                   |                    |             |
         |                   |                    |             |
         |                   |<''''''''' (RTCP BYE) ''''''''''''|
         |                   |                    |             |








Yang, et al.             Expires April 21, 2011                 [Page 9]

Internet-Draft  Switching for multicast short time-shift    October 2010


5.  Security Considerations

   TBD.


6.  IANA Considerations

   TBD.


7.  Acknowledgements

   TBD.


8.  Normative References

   [I-D.ietf-mmusic-rfc2326bis]
              Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
              and M. Stiemerling, "Real Time Streaming Protocol 2.0
              (RTSP)", draft-ietf-mmusic-rfc2326bis-24 (work in
              progress), July 2010.

   [I-D.yang-avt-rtp-synced-playback]
              Yang, P. and Y. Wang, "Synchronized Playback in Rapid
              Acquisition of Multicast Sessions",
              draft-yang-avt-rtp-synced-playback-04 (work in progress),
              March 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.


Authors' Addresses

   Peilin Yang
   Huawei Technologies Co., Ltd.
   101 Software Avenue, Yuhua District, Nanjing 210012
   P.R.China

   Phone: +86-25-56622638
   Email: yangpeilin@huawei.com





Yang, et al.             Expires April 21, 2011                [Page 10]

Internet-Draft  Switching for multicast short time-shift    October 2010


   Roni Even
   Huawei Technologies Co., Ltd.
   14 David Hamelech, Tel Aviv 64953
   Israel

   Email: even.roni@huawei.com


   Hassnaa Moustafa
   France Telecom - Orange
   38-40 rue du General Leclerc Issy Les Moulineaux, 92794 Cedex 9
   France

   Email: hassnaa.moustafa@orange-ftgroup.com


   Tina Tsou (editor)
   Huawei Technologies
   Section F, Huawei Industrial Base
   Bantian Longgang, Shenzhen  518129
   P.R. China

   Phone: +86 755 28972912
   Email: tena@huawei.com


   Gu Yingjie
   Huawei Technologies Co., Ltd.
   101 Software Avenue, Yuhua District, Nanjing 210012
   P.R.China

   Email: guyingjie@huawei.com



















Yang, et al.             Expires April 21, 2011                [Page 11]



--Boundary_(ID_bYWwj9XuKpPo+NXpxFhQcA)--

From xiajinwei@huawei.com  Thu Oct 21 20:28:52 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160983A6825 for ; Thu, 21 Oct 2010 20:28:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VjJLVq+Mb2K for ; Thu, 21 Oct 2010 20:28:50 -0700 (PDT)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 3B5A33A6801 for ; Thu, 21 Oct 2010 20:28:50 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAO00MPJ9QG9N@szxga02-in.huawei.com> for avt@ietf.org; Fri, 22 Oct 2010 11:30:16 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAO009AN9QGFE@szxga02-in.huawei.com> for avt@ietf.org; Fri, 22 Oct 2010 11:30:16 +0800 (CST)
Received: from x65217 ([10.138.41.60]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAO002IX9QF8O@szxml04-in.huawei.com> for avt@ietf.org; Fri, 22 Oct 2010 11:30:16 +0800 (CST)
Date: Fri, 22 Oct 2010 11:30:15 +0800
From: Jinwei Xia 
In-reply-to: <72B2F4CF-DC7A-4A03-B358-276E8C5DECFE@cisco.com>
To: 'David R Oran' , 'Colin Perkins' 
Message-id: <005001cb7199$714ce1b0$3c298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: ActxXlXE/QSDS2OjTUWG74b64rmQXQAM0Cmw
Cc: 'IETF AVT WG' , 'Roni Even' 
Subject: Re: [AVT] FW: New Version Notification	fordraft-xia-avt-splicing-for-rtp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 03:28:52 -0000

Hi Dave,

Please see inline. 

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On 
> Behalf Of David R Oran
> Sent: Friday, October 22, 2010 4:27 AM
> To: Colin Perkins
> Cc: 'IETF AVT WG'; Roni Even
> Subject: Re: [AVT] FW: New Version Notification 
> fordraft-xia-avt-splicing-for-rtp-00
> 
> 
> On Oct 21, 2010, at 4:17 PM, Colin Perkins wrote:
> 
> > Roni,
> > 
> > I don't think it matters that the content arrives as an RTP 
> stream. It's an entirely separate stream, and doesn't affect 
> the translation process. They're logically separate.
> > 
> I agree with Colin here. 
> 
> Either you treat the streams as equal inputs to a mixer, and 
> the case reduces to the problem of a video mixer doing input 
> switching, or you treat all the other inputs as external 
> stuff that gets inserted into the main stream using a translator.
> 
> If you choose the mixer approach, you have to be a legal 
> mixer, which means you keep state, use your own SSRC, and 
> report CSRCs.

 A standard mixer may not work well, it mix all the streams rather than
select one of them.

> 
> If you choose the translator approach, you have to "consume" 
> the other stream and then emit it as if it were emitted by 
> the original stream's source.

Translator acts as a client and terminate inserted stream from inserted
stream source view compared to acting as translator from original stream
source view.  But the RTCP RR issue mentioned by Roni is unsolved, I also
mark this issue as TBD in draft.  

> 
> I don't see what the other approaches would be or how they 
> might work better.

MCU is not well defined in IETF, I agree to limit the scope in mixer and
translator.

> 
> DaveO.
> 
> > Colin
> > 
> > 
> > 
> > On 21 Oct 2010, at 19:26, Roni Even wrote:
> >> Hi Colin,
> >> In this use case the inserted content is not an RTP stream 
> but comes from a local storage. For this use case the splicer 
> is a translator. It will still need to handle the RTCP RR 
> depending on who originated the data that was sent by the translator.
> >> My question will be if this is the typical use case or is 
> there a use 
> >> case where the inserted data is not local and may arrive as RTP 
> >> stream. In which case there is more than one topology
> >> 
> >> Roni
> >> 
> >>> -----Original Message-----
> >>> From: Colin Perkins [mailto:csp@csperkins.org]
> >>> Sent: Thursday, October 21, 2010 7:23 PM
> >>> To: Roni Even
> >>> Cc: 'Jinwei Xia'; 'IETF AVT WG'
> >>> Subject: Re: [AVT] FW: New Version Notification for 
> draft-xia-avt- 
> >>> splicing-for-rtp-00
> >>> 
> >>> Hi Roni,
> >>> 
> >>> I think this problem becomes clearer if you consider a 
> splicer that 
> >>> is reading the content to be inserted from a local file 
> on disk. In 
> >>> that case, the splicer is unquestionably a standard RTP 
> translator, 
> >>> in the middle of a one-to-one or one-to-many RTP session.
> >>> 
> >>> That there are also some cases where an entirely separate RTP 
> >>> session is used to deliver the content to be inserted doesn't 
> >>> (conceptually) affect the translation process at all.
> >>> 
> >>> Colin
> >>> 
> >>> 
> >>> 
> >>> On 21 Oct 2010, at 07:56, Roni Even wrote:
> >>>> Hi Colin,
> >>>> I am not so sure about this being a regular RTP translator. 
> >>>> According
> >>> To RFC 5117 " A Translator always keeps the SSRC for a 
> stream across 
> >>> the translation". Also in the splicing case it is not 
> point to point 
> >>> or multipoint but more like multipoint to point or 
> multipoint. This 
> >>> looks more like a mixer that does not provide the CSRC 
> since one of 
> >>> the requirements is to make it look to the receiver that all the 
> >>> media is coming from the same source. One issue that will 
> need to be 
> >>> addressed is how to report the RTCP RR from the receivers back to 
> >>> the sender of the primary or insertion streams. This may 
> need some 
> >>> state keeping in the splicer.
> >>>> 
> >>>> Roni Even
> >>>> 
> >>>>> -----Original Message-----
> >>>>> From: avt-bounces@ietf.org 
> [mailto:avt-bounces@ietf.org] On Behalf
> >>> Of
> >>>>> Colin Perkins
> >>>>> Sent: Wednesday, October 20, 2010 3:52 PM
> >>>>> To: Jinwei Xia
> >>>>> Cc: 'IETF AVT WG'
> >>>>> Subject: Re: [AVT] FW: New Version Notification for 
> draft-xia-avt- 
> >>>>> splicing-for-rtp-00
> >>>>> 
> >>>>> Hi Jinwei,
> >>>>> 
> >>>>> My impression is that this draft confuses the issue by 
> focussing 
> >>>>> too
> >>> much on scenarios where the content to be inserted is 
> also delivered 
> >>> over RTP. Whether the content to be inserted is delivered 
> as a real- 
> >>> time RTP stream or fetched from local file storage does 
> not affect 
> >>> the insertion process, and so doesn't need to be mentioned in the 
> >>> draft. I still believe that a standard RTP translator is 
> sufficient 
> >>> to solve this problem, although there may be useful things to say 
> >>> about how to efficiently implement such a translator.
> >>>>> 
> >>>>> Colin
> >>>>> 
> >>>>> 
> >>>>> On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
> >>>>>> Hi,
> >>>>>> 
> >>>>>> From the discussion on IETF 78th, there were some 
> >>>>>> misunderstandings
> >>>>> of the scope of splicing draft. So we discard previous problem 
> >>>>> statement draft while initiate new solution draft. In this new
> >>> draft,
> >>>>> We emphysize content insertion issue is indeed a RTP-generic 
> >>>>> rather than MPEG2 TS-specific.
> >>>>>> 
> >>>>>> Hope the new draft can address most issues AVT concern, any
> >>> comments
> >>>>> are very appreciated!
> >>>>>> 
> >>>>>> 
> >>>>>> BR!
> >>>>>> 
> >>>>>> Jinwei
> >>>>>> 
> >>>>>>> -----Original Message-----
> >>>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> >>>>>>> Sent: Saturday, October 16, 2010 9:58 AM
> >>>>>>> To: xiajinwei@huawei.com
> >>>>>>> Subject: New Version Notification for 
> >>>>>>> draft-xia-avt-splicing-for-rtp-00
> >>>>>>> 
> >>>>>>> 
> >>>>>>> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt
> >>>>>>> has been successfully submitted by Jinwei Xia and 
> posted to the 
> >>>>>>> IETF repository.
> >>>>>>> 
> >>>>>>> Filename:	 draft-xia-avt-splicing-for-rtp
> >>>>>>> Revision:	 00
> >>>>>>> Title:		 Content Splicing for RTP Sessions
> >>>>>>> Creation_date:	 2010-10-16
> >>>>>>> WG ID:		 Independent Submission
> >>>>>>> Number_of_pages: 12
> >>>>>>> 
> >>>>>>> Abstract:
> >>>>>>> This memo outlines RTP splicing.  Splicing is a process that 
> >>>>>>> allows a new multimedia stream to be inserted into current 
> >>>>>>> multimedia stream and to be conveyed to receiver for 
> a period of 
> >>>>>>> time.  This memo discusses the requirements of RTP 
> splicing.  In 
> >>>>>>> order to satisfy the requirements, this memo lists several 
> >>>>>>> existing intermediary network elements as alternatives and 
> >>>>>>> evaluates whether one of alternatives can be used to 
> perform RTP 
> >>>>>>> splicing.
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> The IETF Secretariat.
> >>>>>>> 
> >>>>>>> 
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> Audio/Video Transport Working Group avt@ietf.org 
> >>>>>> https://www.ietf.org/mailman/listinfo/avt
> >>>>> 
> >>>>> --
> >>>>> Colin Perkins
> >>>>> http://csperkins.org/
> >> 
> >> _______________________________________________
> >> Audio/Video Transport Working Group
> >> avt@ietf.org
> >> https://www.ietf.org/mailman/listinfo/avt
> > 
> > 
> > 
> > --
> > Colin Perkins
> > http://csperkins.org/
> > 
> > 
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 


From p.ohanlon@gmail.com  Fri Oct 22 03:16:43 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40023A68B7 for ; Fri, 22 Oct 2010 03:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sLcw9fr8ipO for ; Fri, 22 Oct 2010 03:16:35 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4271C3A686D for ; Fri, 22 Oct 2010 03:16:30 -0700 (PDT)
Received: by iwn41 with SMTP id 41so85890iwn.31 for ; Fri, 22 Oct 2010 03:18:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=X5TKdBwOXWBeSYIdVz7UAZpkmm0ndovd9KmeBvyGdN8=; b=iW0DjitSG+RZeMb6pgEhIFEvNF8YEVIle9FllgnsEAdLo8nw0ELiswkNTWKgKAWGAO vmwk4K4ypQxTOBm/pBcOqPwHIa29CkfQ0XkSKvk+PtEnRiuym405nmj4qK4UuddwFgsL 0X6kny+dmwMbwEtyHOrUYvsYRu1Zkr0+FjAcY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=gESb/6Vbf/sS5pbTem0MXFr5Fi8VIJTDmMn3oaQeGMrRtmELzlB1sEhsCt4qReAmuh wQL8hje230fkE4yN/BKlen9oz7u3qTM9Bi/8h0p6wEdwSc3h6r149PIhHVKQm4f3RPeg VGwbybXY0eTiAu1i/fflQeIa/kOqm3Hlx7vcc=
Received: by 10.42.29.133 with SMTP id r5mr2082921icc.235.1287742687077; Fri, 22 Oct 2010 03:18:07 -0700 (PDT)
MIME-Version: 1.0
Sender: p.ohanlon@gmail.com
Received: by 10.229.39.84 with HTTP; Fri, 22 Oct 2010 03:17:46 -0700 (PDT)
In-Reply-To: <4CBDAF22.5020307@ericsson.com>
References: <201008052251.o75Mp7BN005112@bagheera.jungle.bt.co.uk> <4CBDAF22.5020307@ericsson.com>
From: "Piers O'Hanlon" 
Date: Fri, 22 Oct 2010 11:17:46 +0100
X-Google-Sender-Auth: gZIDWTEAdjn6gqo8cLbmeDqfGNc
Message-ID: 
To: Bob Briscoe ,  Magnus Westerlund 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "draft-ietf-avt-ecn-for-rtp@tools.ietf.org" , "avt@ietf.org" 
Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 Other Tech Concerns
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 10:16:43 -0000

Bob,

I took another look at things and realised there was an error in your
calculations regarding T6 - see below.

On 19 October 2010 15:45, Magnus Westerlund
 wrote:
> Hi Bob,
>
> See inline for my comments on the three issues.
>
> Bob Briscoe skrev 2010-08-06 00:50:
>> Magnus, Ingemar, Colin, Piers, Ken,
>>
>> Below are my main technical concerns with
>> draft-ietf-avt-ecn-for-rtp-02 as promised.
>> I have used the line numbering here:
>> 
>>
>> T1/ Combining pkts
>> T2/ ECN-IP-RTCP
>> T3/ Anti-Cheating
>> T4/ Logging Not-ECT fall-back =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <<<---=
THIS EMAIL
>> T5/ Delivery %age ECT vs Not-ECT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<<<---TH=
IS EMAIL
>> T6/ Pkt Reordering around session start <<<---THIS EMAIL
>>
>> T4/ Not just fall-back to Not-ECT, but logging or alarms too.
>> -------------------
>> "
>> 783 =A0 =A0 =A0 =A0loss of all packets with ECT or ECN-CE markings. =A0I=
f the
>> path between
>> 784 =A0 =A0 =A0 =A0the sender and the receivers exhibits either of these=
 behaviours one
>> 785 =A0 =A0 =A0 =A0needs to stop using ECN immediately to protect both t=
he network and
>> 786 =A0 =A0 =A0 =A0the application.
>> "
>> "
>> 1332 =A0 =A0 =A0 Detecting clearing of ECN field:
>> 1337 =A0 =A0 =A0 Dropping of ECT packets:
>> "
>> As well as detecting ECN black holes and falling back to Not-ECT, the
>> source ought to log the IP address pair exhibiting this problem. This
>> could be used for later diagnostics, if someone ever tries to
>> systematically clear up this middlemess (e.g. in a corporate
>> environment, or anywhere that a network operator has access to these log=
s).
>> The logs might also be used as a database for selective leaps-of-faith.
>>
>> If an appropriate management alarm can be raised, it should be too.
>
> Agreed, I have no issues including that in the spec.
>
That's fine.

>>
>> T5/ Comparing Delivery percentage of ECT vs Not-ECT
>> -------------------
>> "
>> 1337 =A0 =A0 =A0 Dropping of ECT packets: To determine if the packet dro=
p ratio is
>> 1338 =A0 =A0 =A0 different between not-ECT and ECT marked transmission r=
equires a mix
>> 1339 =A0 =A0 =A0 of transmitted traffic. =A0The sender should compare if=
 the delivery
>> 1340 =A0 =A0 =A0 percentage (delivered / transmitted) between ECT and no=
t-ECT is
>> 1341 =A0 =A0 =A0 significantly different. =A0Care must be taken if the n=
umber
>> of packets
>> 1342 =A0 =A0 =A0 are low in either of the categories.
>> "
>> Eh? This surely won't work. Under normal circumstances (ie no
>> ECN-Blocking Muddleboxes) Not-ECT packets will be dropped more due to
>> congestion and ECT packets will hardly ever be dropped. So the sender
>> cannot detect if ECT packets are getting some extra drop due to
>> Muddleboxes, by comparing with Not-ECT which will have extra drop for
>> another valid reason (congestion).
>
> Well, that depends on the relative frequency between the ECT and non-ECT
> and the actual packet loss rates. But, yes I think you might have
> spotted a short coming in our thinking. But I think this is not
> completely wrong but is lacking the factor from CE marking, see below.
>
> A very direct method of resolving this issue is to use explicit loss
> vectors by using RTCP XR packet loss vectors. The ECN Nonce one doesn't
> separate between ECN-CE and packet loss and although possible requires a
> bit of going around to find the packet loss rate for ECT. What I can
> understand the sender would need to keep its actual transmission
> pattern. First count and eliminate the not-ect packets that are lost
> from the NONCE vector. Then the remaining marked in the NONCE vector are
> CE and packet loss of ECT packets. By removing the number of CE marked
> ones from the same report interval based on the ECN report blocks you
> would arrive at an approximate number of lost ECT packets. I say
> approximate, because you still have the reordering issue that make the
> sender uncertain on exactly which packets has been reported in the ECN
> report between two RTCP packets.
>
> But lets look at what level of statistics is needed to be able to draw
> some conclusions. I agree that for certain operation points there will
> be a clear difference between ECT and non-ECT traffic. But lets look at
> some examples:
>
> No congestion at all: NON-ECT drop rate should be 0. ECT on capable
> transport drop rate 0, one path(s) that are incapable there will be a
> drop rate >0.
>
> Low levels of congestion: Non-ECT drop rate at a low level (0.5%). ECT
> on capable transport drop rate 0, with CE marking at low level (0.5%),
> ECT on incapable path will have a drop rate >0.5.
>
> High level of congestion: NON-ECT drop rate at high level (10%). ECT on
> capable transport will have some drop rate x, where 10 > x > 0, The CE
> marking rate will be approx 10 - x. ECT on incapable path will see a
> drop rate that is > 10.
>
> Based on the above, I think you can determine when there drops on ECT
> packets that are not related. This as you can take the CE marking rates
> into account. NON-ECT droped packets - CE marked packets should
> approximately equal the number of ECT marked drop packets. What I am
> unclear on in this case is how big fudge factor you do need. But that
> needs to be derived based on statics.
>
> Comments on the above reasoning.
>
>
>>
>> T6/ Pkt Reordering around session start-------------------
>> [Just for the record - I've already sent this point off list.]
>>
>> I will use the term "RTCP ECN Reports" for both the RTCP AVPF NACK
>> transport feedback format and the RTCP XR ECN summary report.
>> "
>> 1281 =A0 =A04.4.2. =A0Interpretation of ECN Summary information
>>
>> 1306 =A0 =A0 =A0 The counters will be initiated to zero to provide value=
 for the RTP
>> 1307 =A0 =A0 =A0 stream sender from the very first report. =A0After the =
first
>> report the
>> 1308 =A0 =A0 =A0 changes between the latest received and the previous on=
e is
>> 1309 =A0 =A0 =A0 determined by simply taking the values of the latest mi=
nus the
>> 1310 =A0 =A0 =A0 previous one, taking field wrapping into account. =A0Th=
is
>> definition is
>> 1311 =A0 =A0 =A0 also robust to packet losses, since if one report is mi=
ssing, the
>> 1312 =A0 =A0 =A0 reporting interval becomes longer, but is otherwise equ=
ally valid.
>> "
>> Both proposed RTCP ECN Reports insufficiently define the range of
>> packets they cover. They both define the range by the highest
>> sequence number and the number of packets covered by the report (the
>> sum of the various couters in the report, all counted since the start
>> of the receiver's session).
>>
>> This approach makes report accuracy vulnerable to reordering around
>> the start of the session. For instance, suppose teh receiver receives
>> the following packets, and imagine the receiver starts its session at
>> sequence #126. Then =A0sends its first report after seq #135:
>>
>> ...119,122,123,124,125,126,127,128,120,121,129,130,132,133,134,135,...
>>
>> Highest seq no =A0=3D #135
>> Number of losses =A0 =A0 =A0 =A0=3D 1 (#131)

This is not what is conveyed in this RTCP report - The 'Lost packets
counter' is a signed quantity and is calculated as follows from
RFC3550 (S6.4.1 and/or A.3):

Lost packets counter  =3D expected - num_received
In your example:  expected =3D 135 - 126 +1 =3D 10
So the 'Lost packets counter' (=3D 10 - 11) =3D -1

Thus one can always calculate the correct number of expected packets
at the sender. So there is not a mismatch of state between the sender
and receiver.

>> packets received =A0 =A0 =A0 =A0=3D 11 (which will be broken down into C=
E, ECT etc)
>> (Total pkts in report =A0 =3D 12)
>>
>> The sender will calculate that this report refers to the 12 packets
>> starting at 135-12=3D#123 and ending at #135.
>>
>> Then, the sender cannot accurately check whether the number of ECT &
>> CE (or Not-ECT) packets reported by the receiver matches the number
>> of ECT (or Not-ECT) it sent, because they are both talking about a
>> different set of packets. For instance, if the sender sets #123 and
>> #124 as ECT probes, these will be counted as ECT by the sender, but
>> the receiver puts them outside the range it is reporting on.
>>
>> This error will be repeated each time the receiver sends a report,
>> because it is always cumulative from the start of the session, and
>> the problem is an ill-defined session start.
>>
I'm not sure if this is the case as the cumulative counts allow for
relative checks by comparing the max_seq numbers (and losses) of two
(or more) reports, thus one can ignore the ill-defined start. The
absolute numbers may be wrong but they're less useful than keeping
tabs on the current reporting periods. In RFC3550 it talks of making
such a comparison (e.g. S6.4.4) which means one needs to wait till
there are at least two RTCP reports before one can make such a
comparison.

>> There are three possible solutions:
>> a) Add text to mandate that the receiver considers the session start
>> to be the lowest sequence number after it initialises its counters.
>> In the example, the receiver would count the session start as #120
>> not #126, even though it initialised its counters at #126. When it
>> receives packet #120 it immediately rolls back the start seqno to
>> #120 and considers 121-125 as 5 losses. Ultimately, because it later
>> receives #121 it only reports #122-125 as 4 losses - even if these
>> packets did actually arrive before the counter was initialised.
>>
>> b) The receiver does not include any packets with seqnos below the
>> seqno when it initialised its variables (unless there has been a wrap
>> of course). In the example, the receever would not include packets
>> #120 & #121 in its RTCP ECN Reports.
>>
>> c) The RTCP ECN Report formats include an explicit start seqno. I
>> don't think this is necessary, given either a) or b) are easy to do.
>>
>> Am I correct, or have I overlooked something?
>
> Yes, you are correct that it is important that a receiver do keep track
> of which packet is the first to count from and thus either doing A or B.
> I think we should add a clarification on this issue. As long as you do
> either of A or B the sender wouldn't be fooled about the set.
>
> I think from a probing point of view doing B would actually be better.
> If one take this as an example the packet sender may could come to the
> conclusion that the ECT probes are lost due to incapability rather than
> re-ordering. The potential down side is that a probe that has been
> received may fall outside of the window and need an additional round.
>
> There are an alternative to B that I think will work, but most likely
> are more complex to implement. That is that the sender will move its
> start number back as long as possible from the initially received number
> as long as there is no hole.
>
I have looked more closely at RFC3550 and it seems that I was wrong
when I said it covered this but our draft's approach is different as
it also includes the number of received packets. Looking more closely
at rfc3550 it seems to me that this may instead be an issue for it -
In Appendix A.3 the base_seq is mentioned as being the "first sequence
number received". Thus reordering at the start of the receiver's
session would lead to mismatch between the sender and receiver state,
though in the case of general RTCP this probably isn't such of a
problem - as one can always check relative counts.

So it seems to me that the existing approach would work ok.

Piers


> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>

From oran@cisco.com  Fri Oct 22 04:44:14 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7BBE3A6900 for ; Fri, 22 Oct 2010 04:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.396
X-Spam-Level: 
X-Spam-Status: No, score=-110.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPQSHCZRsfoO for ; Fri, 22 Oct 2010 04:44:12 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BFF9E3A68FF for ; Fri, 22 Oct 2010 04:44:12 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: PGP.sig : 194
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJMWwUyrR7Ht/2dsb2JhbAChYHGjRJwRhUoEik2DBA
X-IronPort-AV: E=Sophos;i="4.58,222,1286150400";  d="sig'?scan'208";a="608019122"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 22 Oct 2010 11:45:50 +0000
Received: from OranMBP.local (stealth-10-32-245-153.cisco.com [10.32.245.153]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9MBjZkW006158 for ; Fri, 22 Oct 2010 11:45:50 GMT
Received: from [127.0.0.1] by OranMBP.local (PGP Universal service); Fri, 22 Oct 2010 07:45:50 -0400
X-PGP-Universal: processed; by OranMBP.local on Fri, 22 Oct 2010 07:45:50 -0400
Mime-Version: 1.0 (Apple Message framework v1081)
From: David R Oran 
In-Reply-To: <005001cb7199$714ce1b0$3c298a0a@china.huawei.com>
Date: Fri, 22 Oct 2010 07:45:28 -0400
Message-Id: 
References: <005001cb7199$714ce1b0$3c298a0a@china.huawei.com>
To: Jinwei Xia 
X-Mailer: Apple Mail (2.1081)
X-PGP-Encoding-Format: MIME
X-PGP-Encoding-Version: 2.0.2
Content-Type: multipart/signed; boundary="PGP_Universal_9F814F75_5361936E_3220FAFB_ABE4EA82"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Cc: 'Colin Perkins' , 'Roni Even' , 'IETF AVT WG' 
Subject: Re: [AVT] FW: New Version Notification	fordraft-xia-avt-splicing-for-rtp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 11:44:15 -0000

--PGP_Universal_9F814F75_5361936E_3220FAFB_ABE4EA82
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


On Oct 21, 2010, at 11:30 PM, Jinwei Xia wrote:

>=20
> Hi Dave,
>=20
> Please see inline.=20
>=20
>> -----Original Message-----
>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20
>> Behalf Of David R Oran
>> Sent: Friday, October 22, 2010 4:27 AM
>> To: Colin Perkins
>> Cc: 'IETF AVT WG'; Roni Even
>> Subject: Re: [AVT] FW: New Version Notification=20
>> fordraft-xia-avt-splicing-for-rtp-00
>>=20
>>=20
>> On Oct 21, 2010, at 4:17 PM, Colin Perkins wrote:
>>=20
>>> Roni,
>>>=20
>>> I don't think it matters that the content arrives as an RTP=20
>> stream. It's an entirely separate stream, and doesn't affect=20
>> the translation process. They're logically separate.
>>>=20
>> I agree with Colin here.=20
>>=20
>> Either you treat the streams as equal inputs to a mixer, and=20
>> the case reduces to the problem of a video mixer doing input=20
>> switching, or you treat all the other inputs as external=20
>> stuff that gets inserted into the main stream using a translator.
>>=20
>> If you choose the mixer approach, you have to be a legal=20
>> mixer, which means you keep state, use your own SSRC, and=20
>> report CSRCs.
>=20
> A standard mixer may not work well, it mix all the streams rather than
> select one of them.
>=20
Mixers are perfectly allowed to do simple stream selection/switching. =
Nearly all video "mixers" in fact do that rather than actually =
compositing or other forms of "mixing". I think you're being misled by =
the name.

>>=20
>> If you choose the translator approach, you have to "consume"=20
>> the other stream and then emit it as if it were emitted by=20
>> the original stream's source.
>=20
> Translator acts as a client and terminate inserted stream from =
inserted
> stream source view compared to acting as translator from original =
stream
> source view.  But the RTCP RR issue mentioned by Roni is unsolved, I =
also
> mark this issue as TBD in draft. =20
>=20
Ok, but I'm still not seeing much of an issue.. Maybe I'm being na=EFve...=


>>=20
>> I don't see what the other approaches would be or how they=20
>> might work better.
>=20
> MCU is not well defined in IETF, I agree to limit the scope in mixer =
and
> translator.
>=20
Well, let's not get hung up too much on terminology; what's important is =
the function that have to be performed (or not performed), ensuring =
interoperability among the elements, and not making architectural =
changes to RTP unless no other approach satisfies the requirments.


>>=20
>> DaveO.
>>=20
>>> Colin
>>>=20
>>>=20
>>>=20
>>> On 21 Oct 2010, at 19:26, Roni Even wrote:
>>>> Hi Colin,
>>>> In this use case the inserted content is not an RTP stream=20
>> but comes from a local storage. For this use case the splicer=20
>> is a translator. It will still need to handle the RTCP RR=20
>> depending on who originated the data that was sent by the translator.
>>>> My question will be if this is the typical use case or is=20
>> there a use=20
>>>> case where the inserted data is not local and may arrive as RTP=20
>>>> stream. In which case there is more than one topology
>>>>=20
>>>> Roni
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Colin Perkins [mailto:csp@csperkins.org]
>>>>> Sent: Thursday, October 21, 2010 7:23 PM
>>>>> To: Roni Even
>>>>> Cc: 'Jinwei Xia'; 'IETF AVT WG'
>>>>> Subject: Re: [AVT] FW: New Version Notification for=20
>> draft-xia-avt-=20
>>>>> splicing-for-rtp-00
>>>>>=20
>>>>> Hi Roni,
>>>>>=20
>>>>> I think this problem becomes clearer if you consider a=20
>> splicer that=20
>>>>> is reading the content to be inserted from a local file=20
>> on disk. In=20
>>>>> that case, the splicer is unquestionably a standard RTP=20
>> translator,=20
>>>>> in the middle of a one-to-one or one-to-many RTP session.
>>>>>=20
>>>>> That there are also some cases where an entirely separate RTP=20
>>>>> session is used to deliver the content to be inserted doesn't=20
>>>>> (conceptually) affect the translation process at all.
>>>>>=20
>>>>> Colin
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 21 Oct 2010, at 07:56, Roni Even wrote:
>>>>>> Hi Colin,
>>>>>> I am not so sure about this being a regular RTP translator.=20
>>>>>> According
>>>>> To RFC 5117 " A Translator always keeps the SSRC for a=20
>> stream across=20
>>>>> the translation". Also in the splicing case it is not=20
>> point to point=20
>>>>> or multipoint but more like multipoint to point or=20
>> multipoint. This=20
>>>>> looks more like a mixer that does not provide the CSRC=20
>> since one of=20
>>>>> the requirements is to make it look to the receiver that all the=20=

>>>>> media is coming from the same source. One issue that will=20
>> need to be=20
>>>>> addressed is how to report the RTCP RR from the receivers back to=20=

>>>>> the sender of the primary or insertion streams. This may=20
>> need some=20
>>>>> state keeping in the splicer.
>>>>>>=20
>>>>>> Roni Even
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: avt-bounces@ietf.org=20
>> [mailto:avt-bounces@ietf.org] On Behalf
>>>>> Of
>>>>>>> Colin Perkins
>>>>>>> Sent: Wednesday, October 20, 2010 3:52 PM
>>>>>>> To: Jinwei Xia
>>>>>>> Cc: 'IETF AVT WG'
>>>>>>> Subject: Re: [AVT] FW: New Version Notification for=20
>> draft-xia-avt-=20
>>>>>>> splicing-for-rtp-00
>>>>>>>=20
>>>>>>> Hi Jinwei,
>>>>>>>=20
>>>>>>> My impression is that this draft confuses the issue by=20
>> focussing=20
>>>>>>> too
>>>>> much on scenarios where the content to be inserted is=20
>> also delivered=20
>>>>> over RTP. Whether the content to be inserted is delivered=20
>> as a real-=20
>>>>> time RTP stream or fetched from local file storage does=20
>> not affect=20
>>>>> the insertion process, and so doesn't need to be mentioned in the=20=

>>>>> draft. I still believe that a standard RTP translator is=20
>> sufficient=20
>>>>> to solve this problem, although there may be useful things to say=20=

>>>>> about how to efficiently implement such a translator.
>>>>>>>=20
>>>>>>> Colin
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 16 Oct 2010, at 03:06, Jinwei Xia wrote:
>>>>>>>> Hi,
>>>>>>>>=20
>>>>>>>> =46rom the discussion on IETF 78th, there were some=20
>>>>>>>> misunderstandings
>>>>>>> of the scope of splicing draft. So we discard previous problem=20=

>>>>>>> statement draft while initiate new solution draft. In this new
>>>>> draft,
>>>>>>> We emphysize content insertion issue is indeed a RTP-generic=20
>>>>>>> rather than MPEG2 TS-specific.
>>>>>>>>=20
>>>>>>>> Hope the new draft can address most issues AVT concern, any
>>>>> comments
>>>>>>> are very appreciated!
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> BR!
>>>>>>>>=20
>>>>>>>> Jinwei
>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
>>>>>>>>> Sent: Saturday, October 16, 2010 9:58 AM
>>>>>>>>> To: xiajinwei@huawei.com
>>>>>>>>> Subject: New Version Notification for=20
>>>>>>>>> draft-xia-avt-splicing-for-rtp-00
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> A new version of I-D, draft-xia-avt-splicing-for-rtp-00.txt
>>>>>>>>> has been successfully submitted by Jinwei Xia and=20
>> posted to the=20
>>>>>>>>> IETF repository.
>>>>>>>>>=20
>>>>>>>>> Filename:	 draft-xia-avt-splicing-for-rtp
>>>>>>>>> Revision:	 00
>>>>>>>>> Title:		 Content Splicing for RTP Sessions
>>>>>>>>> Creation_date:	 2010-10-16
>>>>>>>>> WG ID:		 Independent Submission
>>>>>>>>> Number_of_pages: 12
>>>>>>>>>=20
>>>>>>>>> Abstract:
>>>>>>>>> This memo outlines RTP splicing.  Splicing is a process that=20=

>>>>>>>>> allows a new multimedia stream to be inserted into current=20
>>>>>>>>> multimedia stream and to be conveyed to receiver for=20
>> a period of=20
>>>>>>>>> time.  This memo discusses the requirements of RTP=20
>> splicing.  In=20
>>>>>>>>> order to satisfy the requirements, this memo lists several=20
>>>>>>>>> existing intermediary network elements as alternatives and=20
>>>>>>>>> evaluates whether one of alternatives can be used to=20
>> perform RTP=20
>>>>>>>>> splicing.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> The IETF Secretariat.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> Audio/Video Transport Working Group avt@ietf.org=20
>>>>>>>> https://www.ietf.org/mailman/listinfo/avt
>>>>>>>=20
>>>>>>> --
>>>>>>> Colin Perkins
>>>>>>> http://csperkins.org/
>>>>=20
>>>> _______________________________________________
>>>> Audio/Video Transport Working Group
>>>> avt@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/avt
>>>=20
>>>=20
>>>=20
>>> --
>>> Colin Perkins
>>> http://csperkins.org/
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> Audio/Video Transport Working Group
>>> avt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt
>>=20
>>=20
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt


--PGP_Universal_9F814F75_5361936E_3220FAFB_ABE4EA82
Content-Type: application/pgp-signature;
	x-mac-type=70674453;
	name=PGP.sig
Content-Disposition: attachment; filename=PGP.sig

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 10.0.2 (Build 13)

iQA/AwUBTMF5aI1mhLZU3SrmEQLyuACcD+WFOnp/48K1MfjX80E0Ifovl+QAoKTs
Y+FDrdBosCu4nXPG1/P8H+oV
=cPy1
-----END PGP SIGNATURE-----

--PGP_Universal_9F814F75_5361936E_3220FAFB_ABE4EA82--

From Even.roni@huawei.com  Fri Oct 22 14:12:17 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AEC53A68EE for ; Fri, 22 Oct 2010 14:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.846
X-Spam-Level: 
X-Spam-Status: No, score=-100.846 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJqcsWSkWeRK for ; Fri, 22 Oct 2010 14:12:16 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 7033F3A68E1 for ; Fri, 22 Oct 2010 14:12:16 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAP002LJMYWMA@szxga01-in.huawei.com> for avt@ietf.org; Sat, 23 Oct 2010 05:13:44 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAP00G64MYWS4@szxga01-in.huawei.com> for avt@ietf.org; Sat, 23 Oct 2010 05:13:44 +0800 (CST)
Received: from windows8d787f9 (bzq-109-65-7-2.red.bezeqint.net [109.65.7.2]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0LAP007Z4MYLJ8@szxml01-in.huawei.com>; Sat, 23 Oct 2010 05:13:44 +0800 (CST)
Date: Fri, 22 Oct 2010 23:10:24 +0200
From: Roni Even 
In-reply-to: 
To: "'Brandenburg, R. (Ray) van'" 
Message-id: <010901cb722d$92532b50$b6f981f0$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: en-us
Content-transfer-encoding: 7BIT
Thread-index: ActqBt9LAige+0fVQCeB3foz4CzldQAxeHmQAdfNpkA=
x-cr-hashedpuzzle: AM0Y GT6J KlGg K9v6 ME2v RoZd SNVn VCH5 VTe9 V3AE aZnL bsRY dKDK dSBk d+NT fzki; 3; YQB2AHQAQABpAGUAdABmAC4AbwByAGcAOwBrAGUAaQB0AGgALgBkAHIAYQBnAGUAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AHIAYQB5AC4AdgBhAG4AYgByAGEAbgBkAGUAbgBiAHUAcgBnAEAAdABuAG8ALgBuAGwA; Sosha1_v1; 7; {7A24198F-4E35-4A19-B6A3-A3E519FBF8C5}; ZQB2AGUAbgAuAHIAbwBuAGkAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Fri, 22 Oct 2010 21:10:02 GMT; ZAByAGEAZgB0AC0AYgByAGEAbgBkAGUAbgBiAHUAcgBnAC0AYQB2AHQALQByAHQAYwBwAC0AZgBvAHIALQBpAGQAbQBzAC0AMAAyACAALQAgAGcAbwBpAG4AZwAgAGYAbwByAHcAYQByAGQA
x-cr-puzzleid: {7A24198F-4E35-4A19-B6A3-A3E519FBF8C5}
References: 
Cc: "'DRAGE, Keith \(Keith\)'" , avt@ietf.org
Subject: [AVT] draft-brandenburg-avt-rtcp-for-idms-02 - going forward
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Oct 2010 21:12:17 -0000

Hi,
I read the draft and looked also at annex W of TS 183 063 v3.4.1 which
specifies this XR block and SDP. 
I appreciate you brining this document to the IETF AVT WG even though it
would have been enough to have it in TS 183 063 according to the
specification required policy in RFC 3611 section 6.2.

I think it will be good to present it in Beijing and we can ask if people in
AVT would like to have it as a work item or just help by reviewing leaving
it in TS 183 063.

Regards
Roni Even
AVT co-chair




From sunseawq@huawei.com  Sun Oct 24 18:54:17 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05473A63D3 for ; Sun, 24 Oct 2010 18:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.255
X-Spam-Level: 
X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[AWL=0.750,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZNCVb+gSt0C for ; Sun, 24 Oct 2010 18:54:17 -0700 (PDT)
Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0C1583A6767 for ; Sun, 24 Oct 2010 18:54:17 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAT00C36PD276@szxga05-in.huawei.com> for avt@ietf.org; Mon, 25 Oct 2010 09:55:50 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAT003W0PD1EV@szxga05-in.huawei.com> for avt@ietf.org; Mon, 25 Oct 2010 09:55:50 +0800 (CST)
Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAT00BA8PD0K7@szxml04-in.huawei.com> for avt@ietf.org; Mon, 25 Oct 2010 09:55:49 +0800 (CST)
Date: Mon, 25 Oct 2010 09:55:48 +0800
From: Qin Wu 
To: avt@ietf.org
Message-id: <023501cb73e7$bf138c00$30298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <20101025014502.555663A6767@core3.amsl.com>
Subject: Re: [AVT] I-D Action:draft-wu-avt-retransmission-supression-rtp-06.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 01:54:18 -0000

Hi, folks:
06 version of draft-wu-avt-retransmission-supression-rtp is posted which address the remaining comments:
* shorten the abstract
* simplify the introduction section
* remove the appdendix
* rephrase the section 6.1.1 to define only the behaviour of a single distribution source
* keeps retransmission as packet loss repair mechanism out.
* Add RAMS case to explain how feedback suppression works.
A URL for this Internet-Draft is:
 http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-06.txt
Thank for Ali, Colin and Tom's comments.

Regards!
-Qin
----- Original Message ----- 
From: 
To: 
Sent: Monday, October 25, 2010 9:45 AM
Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-06.txt


>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : RTCP Report Extension for Feedback Suppression
> Author(s)       : Q. Wu, et al.
> Filename        : draft-wu-avt-retransmission-supression-rtp-06.txt
> Pages           : 17
> Date            : 2010-10-24
> 
> In a large RTP session using the RTCP feedback mechanism defined in
> RFC 4585, a media source or middlebox may experience transient
> overload if some event causes a large number of receivers to send
> feedback at once.  This feedback implosion can be mitigated if the
> device suffering from overload can send a feedback suppression
> message to the receivers to inhibit further feedback.  This memo
> defines RTCP extensions for feedback suppression, to suppress NACK
> and FIR feedback requests.  It also defines associated SDP
> signalling."
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-06.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>


--------------------------------------------------------------------------------


> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

From csp@csperkins.org  Mon Oct 25 04:00:43 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200FE3A69ED for ; Mon, 25 Oct 2010 04:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.493
X-Spam-Level: 
X-Spam-Status: No, score=-103.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLCGCCOrb1c2 for ; Mon, 25 Oct 2010 04:00:41 -0700 (PDT)
Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id E68E93A69CF for ; Mon, 25 Oct 2010 04:00:39 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PAKoq-0006LU-js; Mon, 25 Oct 2010 11:02:24 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins 
In-Reply-To: <4CBFEC63.7090003@ericsson.com>
Date: Mon, 25 Oct 2010 12:02:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <512FD7F6-BA15-46A9-BF08-1EC575BAB678@csperkins.org>
References: <201008052251.o75Mp7BL005112@bagheera.jungle.bt.co.uk>	<662B899F-09B5-48E5-B164-C61D278E4670@g11.org.uk>	<201008252336.o7PNafwl030089@bagheera.jungle.bt.co.uk>	<6D774CF6-FB7C-4710-A040-FCF40775FB8A@csperkins.org>  <4CBFEC63.7090003@ericsson.com>
To: Magnus Westerlund 
X-Mailer: Apple Mail (2.1081)
Cc: Ingemar Johansson S , Bob Briscoe , IETF AVT WG 
Subject: Re: [AVT] Removing nonce (WAS RE: draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 11:00:43 -0000

On 21 Oct 2010, at 08:31, Magnus Westerlund wrote:
> Ingemar Johansson S skrev 2010-10-21 09:23:
>> I am working on the draft, removing the nonce stuff. As I understand =
it, section 5.3 can be removed entirely, but I guess some text is needed =
to indicated that RFC3611 (4.1) can be used to indicate packets that are =
lost or ECN-CE marked.=20
>> ECN-CE is not mentioned in RFC3611, do you believe that it is valid =
to use RFC3611 for indication on ECN-CE. I guess it is if one stick to =
the principle that ECN-CE should be reacted on in the same way as a =
packet loss. What is your opinion.
>=20
> I at least are of the opinion that if a packet arrived with a CE mark,
> it is still delivered. It shall not be marked as lost in the RTCP XR
> packet loss vector. If we want/need to know exactly which packets =
where
> CE marked, then we should define a CE marking XR vector for that.
> Overloading of this would reduce the utility of the packet loss =
vector.


Agreed. The congestion response should be the same for a packet that's =
lost or CE marked, but the effect on the user experience will be quite =
different, so they should be reported differently.=20

--=20
Colin Perkins
http://csperkins.org/




From rbriscoe@jungle.bt.co.uk  Mon Oct 25 07:50:14 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10BC3A6A58 for ; Mon, 25 Oct 2010 07:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.451
X-Spam-Level: 
X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=0.666,  BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnBGcrEjM-9M for ; Mon, 25 Oct 2010 07:50:07 -0700 (PDT)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 492953A6A4E for ; Mon, 25 Oct 2010 07:50:05 -0700 (PDT)
Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 25 Oct 2010 15:51:50 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 15:51:49 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1288018305330; Mon, 25 Oct 2010 15:51:45 +0100
Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o9PEpiNM001150; Mon, 25 Oct 2010 15:51:44 +0100
Message-Id: <201010251451.o9PEpiNM001150@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 25 Oct 2010 15:51:44 +0100
To: Colin Perkins 
From: Bob Briscoe 
In-Reply-To: <512FD7F6-BA15-46A9-BF08-1EC575BAB678@csperkins.org>
References: <201008052251.o75Mp7BL005112@bagheera.jungle.bt.co.uk> <662B899F-09B5-48E5-B164-C61D278E4670@g11.org.uk> <201008252336.o7PNafwl030089@bagheera.jungle.bt.co.uk> <6D774CF6-FB7C-4710-A040-FCF40775FB8A@csperkins.org>  <4CBFEC63.7090003@ericsson.com> <512FD7F6-BA15-46A9-BF08-1EC575BAB678@csperkins.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 25 Oct 2010 14:51:49.0641 (UTC) FILETIME=[2758FF90:01CB7454]
Cc: Ingemar Johansson S , Magnus Westerlund , IETF AVT WG 
Subject: Re: [AVT] Removing nonce (WAS RE: draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 14:50:15 -0000

Folks,

May not get time to respond to all these responses on ECN-for-RTP. 
Too many of my own drafts in process for today's deadlines.


Bob

At 12:02 25/10/2010, Colin Perkins wrote:
>On 21 Oct 2010, at 08:31, Magnus Westerlund wrote:
> > Ingemar Johansson S skrev 2010-10-21 09:23:
> >> I am working on the draft, removing the nonce stuff. As I 
> understand it, section 5.3 can be removed entirely, but I guess 
> some text is needed to indicated that RFC3611 (4.1) can be used to 
> indicate packets that are lost or ECN-CE marked.
> >> ECN-CE is not mentioned in RFC3611, do you believe that it is 
> valid to use RFC3611 for indication on ECN-CE. I guess it is if one 
> stick to the principle that ECN-CE should be reacted on in the same 
> way as a packet loss. What is your opinion.
> >
> > I at least are of the opinion that if a packet arrived with a CE mark,
> > it is still delivered. It shall not be marked as lost in the RTCP XR
> > packet loss vector. If we want/need to know exactly which packets where
> > CE marked, then we should define a CE marking XR vector for that.
> > Overloading of this would reduce the utility of the packet loss vector.
>
>
>Agreed. The congestion response should be the same for a packet 
>that's lost or CE marked, but the effect on the user experience will 
>be quite different, so they should be reported differently.
>
>--
>Colin Perkins
>http://csperkins.org/

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 


From root@core3.amsl.com  Mon Oct 25 12:45:48 2010
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id C85AB3A68DE; Mon, 25 Oct 2010 12:45:27 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20101025194547.C85AB3A68DE@core3.amsl.com>
Date: Mon, 25 Oct 2010 12:45:27 -0700 (PDT)
Cc: avt@ietf.org
Subject: [AVT] I-D Action:draft-ietf-avt-rtcp-port-for-ssm-03.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 19:45:48 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.


	Title           : RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions
	Author(s)       : A. Begen
	Filename        : draft-ietf-avt-rtcp-port-for-ssm-03.txt
	Pages           : 7
	Date            : 2010-10-25

The Session Description Protocol (SDP) has an attribute that allows
RTP applications to specify an address and a port associated with the
RTP Control Protocol (RTCP) traffic.  In RTP-based source-specific
multicast (SSM) sessions, the same attribute is used to designate the
address and the RTCP port of the Feedback Target in the SDP
description.  However, the RTCP port associated with the SSM session
itself cannot be specified by the same attribute to avoid ambiguity,
and thus, is required to be derived from the "m=" line of the media
description.  Deriving the RTCP port from the "m=" line imposes an
unnecessary restriction.  This document removes this restriction by
introducing a new SDP attribute.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-port-for-ssm-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-avt-rtcp-port-for-ssm-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-10-25123028.I-D@ietf.org>


--NextPart--

From root@core3.amsl.com  Mon Oct 25 14:45:02 2010
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id A0AF53A68E5; Mon, 25 Oct 2010 14:45:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20101025214502.A0AF53A68E5@core3.amsl.com>
Date: Mon, 25 Oct 2010 14:45:02 -0700 (PDT)
Cc: avt@ietf.org
Subject: [AVT] I-D Action:draft-ietf-avt-ecn-for-rtp-03.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 21:45:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.


	Title           : Explicit Congestion Notification (ECN) for RTP over UDP
	Author(s)       : M. Westerlund, et al.
	Filename        : draft-ietf-avt-ecn-for-rtp-03.txt
	Pages           : 44
	Date            : 2010-10-25

This document specifies how explicit congestion notification (ECN)
can be used with RTP/UDP flows that use RTCP as feedback mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-ecn-for-rtp-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-avt-ecn-for-rtp-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-10-25144044.I-D@ietf.org>


--NextPart--

From yangpeilin@huawei.com  Mon Oct 25 20:14:10 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1463A67AF for ; Mon, 25 Oct 2010 20:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.251
X-Spam-Level: 
X-Spam-Status: No, score=-97.251 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghC0IVZbiV+W for ; Mon, 25 Oct 2010 20:14:08 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 775053A6784 for ; Mon, 25 Oct 2010 20:14:08 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAV008DNNQ8MX@szxga01-in.huawei.com> for avt@ietf.org; Tue, 26 Oct 2010 11:15:44 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAV0097ZNQ890@szxga01-in.huawei.com> for avt@ietf.org; Tue, 26 Oct 2010 11:15:44 +0800 (CST)
Received: from [172.24.1.33] (Forwarded-For: [10.138.41.38]) by szxmc03-in.huawei.com (mshttpd); Tue, 26 Oct 2010 11:15:44 +0800
Date: Tue, 26 Oct 2010 11:15:44 +0800
From: Peilin YANG 
In-reply-to: <20101025060231.B8FEF3A6947@core3.amsl.com>
To: avt@ietf.org
Message-id: 
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug  8 2006)
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: quoted-printable
Content-disposition: inline
X-Accept-Language: zh-CN
Priority: normal
References: <20101025060231.B8FEF3A6947@core3.amsl.com>
Subject: [AVT] New Version Notification for draft-xia-avt-mpeg2ts-preamble-04
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 03:14:10 -0000

Hi=2C

New Version for draft-xia-avt-mpeg2ts-preamble-04 has been submitted=2E =


This new version mainly adds the text about the timing of the MPEG2-TS Pr=
eamble at section 6=2E

Any comments are welcome=2E

Peilin




----- =D4=AD=D3=CA=BC=FE -----
=B7=A2=BC=FE=C8=CB=3A IETF I-D Submission Tool =3Cidsubmission=40ietf=2Eo=
rg=3E
=C8=D5=C6=DA=3A =D0=C7=C6=DA=D2=BB=2C =CA=AE=D4=C2 25=C8=D5=2C 2010 =CF=C2=
=CE=E72=3A04
=D6=F7=CC=E2=3A New Version Notification for draft-xia-avt-mpeg2ts-preamb=
le-04
=CA=D5=BC=FE=C8=CB=3A yangpeilin=40huawei=2Ecom
=B3=AD=CB=CD=3A xiayangsong=40huawei=2Ecom=2C wuxingfen=40huawei=2Ecom

A new version of I-D=2C draft-xia-avt-mpeg2ts-preamble-04=2Etxt has been =
successfully submitted by Peilin Yang and posted to the IETF repository=2E=


Filename=3A         draft-xia-avt-mpeg2ts-preamble
Revision=3A         04
Title=3A                 Preamble Acquisition of MPEG2-TS Multicast Sessi=
ons
Creation=5Fdate=3A         2010-10-25
WG ID=3A                 Independent Submission
Number=5Fof=5Fpages=3A 23

Abstract=3A
The ITU-T Rec=2E H=2E222=2E0 =7C ISO/IEC 13818-1 Transport Stream (MPEG2-=
TS)
addresses the combining of one or more elementary streams of video
and audio=2C as well as other data=2C into single or multiple streams
which are suitable for storage or transmission=2E  The necessary and
sufficient information contained in the Program Specific
Information(PSI) tables to demultiplex and present programs must be
acquired before a RTP receiver can process any data received in
MPEG2-TS=2E  In this document=2C a Retransmission Server is specified to
deliver MPEG2-TS preamble prior to unicast burst RTP packets=2E  The
Retransmission Server caches raw RTP packets with MPEG2-TS preamble
information=2C and sends them to the RTP receiver which initiates rapid
acquisition of MPEG2-TS multicast sessions=2E
                                                                         =
         =



The IETF Secretariat=2E


From Even.roni@huawei.com  Mon Oct 25 22:11:52 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A183A67E4 for ; Mon, 25 Oct 2010 22:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.814
X-Spam-Level: 
X-Spam-Status: No, score=-98.814 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_74=0.6, RDNS_NONE=0.1, T_TVD_FW_GRAPHIC_ID1=0.01, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQRy62376fos for ; Mon, 25 Oct 2010 22:11:47 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5F4173A67E2 for ; Mon, 25 Oct 2010 22:11:46 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAV000H3T6A5J@szxga04-in.huawei.com> for avt@ietf.org; Tue, 26 Oct 2010 13:13:22 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAV00HF9T69AZ@szxga04-in.huawei.com> for avt@ietf.org; Tue, 26 Oct 2010 13:13:21 +0800 (CST)
Received: from windows8d787f9 ([109.64.15.67]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAV0022PT60QH@szxml01-in.huawei.com> for avt@ietf.org; Tue, 26 Oct 2010 13:13:21 +0800 (CST)
Date: Tue, 26 Oct 2010 07:12:58 +0200
From: Roni Even 
To: avt@ietf.org
Message-id: <02ce01cb74cc$799f1410$6cdd3c30$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/related; boundary="Boundary_(ID_e9eJIdthGPOzCcazyAUL/w)"
Content-language: en-us
Thread-index: Act0FWeD0ZYTCuxIQe2/Ms/JRQQIZQAtr0JA
Subject: [AVT] FW: The interworking issue for RTP Payload Format for AMR
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 05:11:52 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_e9eJIdthGPOzCcazyAUL/w)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_lDVUgHp7LdLeEhpY1PcEFA)"


--Boundary_(ID_lDVUgHp7LdLeEhpY1PcEFA)
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: quoted-printable

Hi,

I assume that the problem is because in TRAU you can send either CMR or =
CMI while RFC4867 allows both in the same packet. Is this correct?

Roni Even

=20

From: Xie Lei [mailto:xielei57471@huawei.com]=20
Sent: Monday, October 25, 2010 9:14 AM
To: avt@ietf.org
Cc: keith.drage@alcatel-lucent.com; 'Roni Even'
Subject: [AVT]The interworking issue for RTP Payload Format for AMR

=20

Hello All

I work on one interworking task between AMR RTP Payload and TRAU frame =
in TDM network, and find it is very difficult to map the =
Codec_Mode_Request(CMR) value in RTP to Request or Indication Flag (RIF) =
in TRAU frame which is defined in 3GPP 48.060/48.061.=20

As defined in RFC4867, RTP frame can take CMR and CMI(FT field) both in =
payload and the codec mode change period could be 20ms. However,TRAU =
speech frame can only take one of CMR or CMI, and the RIF should follow =
rigorous mode change peroid, that means, TRAU speech frame could only =
take CMR every 40ms and between each CMR frame, the TRAU speech frame =
must be CMI frame.=20

The issue happens when two consequent RTP payload takeing valide CMR =
value in each payload, at this scenario, we do not know how to set the =
RIF value. For instance, the first RTP payload takes CMR=3D4, and we map =
this CMR value to RIF flag to indicate the TRAU speech frame is for CMR, =
and the second RTP payload comes with CMR=3D1, then we really do not =
know how to do now. according to the RTP payload CMR valude, we should =
indicate RIF as CMR. However, according to the TRAU frame definition, =
the RIF must be CMI which following with last CMR frame.

RFC4867 has some decription on reqirements for encoder in GSM. However, =
it is not enough, i think there needs some description on how to map CMR =
and CMI value in RTP frame to RIF defined TRAU when interworking between =
IP and TDM network. currentlly , we can not find such mapping table in =
any specification. We hope avt groud could work on this and resolve this =
issue.

=20

Best Regards

Rock

=20

=20

=20

=E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8 =
huawei_logo


=E5=9C=B0=E5=9D=80=EF=BC=9A=E6=B7=B1=E5=9C=B3=E5=B8=82=E9=BE=99=E5=B2=97=E5=
=8C=BA=E5=9D=82=E7=94=B0=E5=8D=8E=E4=B8=BA=E5=9F=BA=E5=9C=B0 =
=E9=82=AE=E7=BC=96=EF=BC=9A518129
http://www.huawei.com
-------------------------------------------------------------------------=
------------------------------------------------------------
=E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=E6=
=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4=BF=
=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=99=
=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84=E4=
=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81
=E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=E4=
=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4=BD=
=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88=86=
=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=E6=
=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD
=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E6=
=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=AB=
=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=A5=
=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=E4=
=BB=B6=EF=BC=81
This e-mail and its attachments contain confidential information from =
HUAWEI, which=20
is intended only for the person or entity whose address is listed above. =
Any use of the=20
information contained herein in any way (including, but not limited to, =
total or partial=20
disclosure, reproduction, or dissemination) by persons other than the =
intended=20
recipient(s) is prohibited. If you receive this e-mail in error, please =
notify the sender by=20
phone or email immediately and delete it!


--Boundary_(ID_lDVUgHp7LdLeEhpY1PcEFA)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: quoted-printable

















Hi,



I assume that the problem is because in TRAU you can send =
either
CMR or CMI while RFC4867 allows both in the same packet. Is this =
correct?



Roni Even



 









From:=
 Xie Lei
[mailto:xielei57471@huawei.com] 

Sent: Monday, October 25, 2010 9:14 AM

To: avt@ietf.org

Cc: keith.drage@alcatel-lucent.com; 'Roni Even'

Subject: [AVT]The interworking issue for RTP Payload Format for =
AMR









 






Hello
All









I work
on one interworking task between AMR RTP Payload and TRAU frame =
in TDM
network, and find it is very difficult to map the C=
odec_Mode_Request(CMR)
value in RTP to Request or Indication Flag (RIF) in TRAU frame which =
is
defined in =
3=
GPP
48.060/48.061. 









As defined in RFC4867, RTP frame can take CMR and CMI(FT =
field)
both in payload and the codec mode change period could =
be 20ms.
However,TRAU speech frame can only =
take one of
CMR or CMI, and the RIF should follow rigorous mode change peroid, that means, =
TRAU speech frame could only take CMR every =
40ms
and between each CMR frame, the TRAU =
speech
frame must be CMI frame. 









The issue happens when two consequent RTP payload
takeing valide CMR value in each payload, at this scenario, we do not =
know how
to set the RIF value. For instance, the first RTP payload takes CMR=3D4, =
and we
map this CMR value to RIF flag to indicate the TRAU
speech frame is for CMR, and the =
second RTP
payload comes with CMR=3D1, then we really do not know how to do now. =
according
to the RTP payload CMR valude, we should indicate RIF as CMR. However,
according to the TRAU frame definition, the RIF must be CMI
which following with last CMR frame.









RFC4867 has some decription on reqirements for encoder in =
GSM.
However, it is not enough, i think there needs some description
on how to map CMR and CMI value in RTP frame to
RIF defined TRAU when interworking between IP and TDM network.
currentlly , we can not find such mapping table in any specification. We =
hope
avt groud could work on this and resolve this =
issue.









 









Best Regards









Rock









 









 









 









=E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90=E5=85=AC=
=E5=8F=B8
3D"huawei_logo"





=E5=9C=B0=E5=9D=80=EF=BC=9A=E6=B7=B1=E5=9C=B3=E5=B8=82=
=E9=BE=99=E5=B2=97=E5=8C=BA=E5=9D=82=E7=94=B0=
=E5=8D=8E=E4=B8=BA=E5=9F=BA=E5=9C=B0 =E9=82=AE=E7=BC=96=EF=BC=9A518129

http://www.huawei.com

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

=E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=
=E4=BB=B6=E5=90=AB=E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=
=BF=9D=E5=AF=86=E4=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=
=91=E9=80=81=E7=BB=99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=
=E5=87=BA=E7=9A=84=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=
=A6=81

=E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=
=E4=BB=A5=E4=BB=BB=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=
=8C=85=E6=8B=AC=E4=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=
=96=E9=83=A8=E5=88=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=E6=95=A3=
=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD

=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=
=E6=82=A8=E9=94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=
=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=
=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=
=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=81

This e-mail and its attachments contain confidential =
information
from HUAWEI, which 

is intended only for the person or entity whose address is listed above. =
Any
use of the 

information contained herein in any way (including, but not limited to, =
total
or partial 

disclosure, reproduction, or dissemination) by persons other than the =
intended 

recipient(s) is prohibited. If you receive this e-mail in error, please =
notify
the sender by 

phone or email immediately and delete it!












--Boundary_(ID_lDVUgHp7LdLeEhpY1PcEFA)--

--Boundary_(ID_e9eJIdthGPOzCcazyAUL/w)
Content-id: <00d001cb7414$389703a0$5f106f0a@china.huawei.com>
Content-type: image/jpeg; name=outlook_huawei_logo_cn.jpg
Content-transfer-encoding: base64
Content-disposition: attachment; filename=outlook_huawei_logo_cn.jpg

/9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA
AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA
AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA
AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB
AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A
AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA////////
/////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD/////////
////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA
AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A
AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA
AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA
AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg
AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS
AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF
U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA
AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA
TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA
AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA
AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB
bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA
AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl
QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u
ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN
BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA
AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM
QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT
ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O
Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB
IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB
AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR
obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF
tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR
AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV
NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA
AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6
6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs
VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns
U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9
w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh
fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX
146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh
SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t
bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo
JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb
qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv
/QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F
ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4
HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v
6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m
+u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6
tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ
JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r
WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z
OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB
AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA
AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq
AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8
CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox
ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA
BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB
AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf
Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM
DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM
DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED
EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA
AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV
UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0
pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB
UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz
hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/
APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3
0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl
/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP
UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+
qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW
9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq
FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp
VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku
cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf
Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0
PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C
OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us
XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j
QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6
jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n
0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT
gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf
UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj
Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI
BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04
MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA
AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh
CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp
anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV
1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK
C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy
0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD
hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm
5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge
ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn
yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr
aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g
dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf
03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l
6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo
9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai
uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45
RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV
zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc
TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM
v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S
reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8
V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM
qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/
thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le
LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x
ke3tRX0lRQB//9k=

--Boundary_(ID_e9eJIdthGPOzCcazyAUL/w)--

From xielei57471@huawei.com  Mon Oct 25 23:03:08 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0BA3A688D for ; Mon, 25 Oct 2010 23:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.571
X-Spam-Level: ****
X-Spam-Status: No, score=4.571 tagged_above=-999 required=5 tests=[AWL=2.405,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_74=0.6, MY_CID_AND_ARIAL2=1.46, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut9v86NJQl0I for ; Mon, 25 Oct 2010 23:02:57 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2B5F53A67F1 for ; Mon, 25 Oct 2010 23:02:55 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAV00144VJHKC@szxga03-in.huawei.com> for avt@ietf.org; Tue, 26 Oct 2010 14:04:30 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAV008TIVJG5X@szxga03-in.huawei.com> for avt@ietf.org; Tue, 26 Oct 2010 14:04:28 +0800 (CST)
Received: from x57471 ([10.111.16.95]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAV00D5FVJG9J@szxml04-in.huawei.com> for avt@ietf.org; Tue, 26 Oct 2010 14:04:28 +0800 (CST)
Date: Tue, 26 Oct 2010 14:04:28 +0800
From: Xie Lei 
To: Roni Even , avt@ietf.org
Message-id: <001701cb74d3$a6362980$5f106f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: multipart/alternative; boundary="Boundary_(ID_JH2Zd4v/D3XrOlBs5ow2BA)"
X-Priority: 3
X-MSMail-priority: Normal
References: <02ce01cb74cc$799f1410$6cdd3c30$%roni@huawei.com>
Subject: Re: [AVT] The interworking issue for RTP Payload Format for AMR
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 06:03:08 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_JH2Zd4v/D3XrOlBs5ow2BA)
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: 7BIT

Hi
Yes, the TRAU can only take either CMR or CMI, and in GSM network, TRAU frame sequence must strictly be one CMR frame following with one CMI frame , however, RFC4867 allows take both CMR and CMI one packet and there is no indication to indentify the packet is CMR frame or not, that makes the problem.

BR
Rock
  ----- Original Message ----- 
  From: Roni Even 
  To: avt@ietf.org 
  Cc: 'Xie Lei' 
  Sent: Tuesday, October 26, 2010 1:12 PM
  Subject: FW: [AVT]The interworking issue for RTP Payload Format for AMR


  Hi,

  I assume that the problem is because in TRAU you can send either CMR or CMI while RFC4867 allows both in the same packet. Is this correct?

  Roni Even

   

  From: Xie Lei [mailto:xielei57471@huawei.com] 
  Sent: Monday, October 25, 2010 9:14 AM
  To: avt@ietf.org
  Cc: keith.drage@alcatel-lucent.com; 'Roni Even'
  Subject: [AVT]The interworking issue for RTP Payload Format for AMR

   

  Hello All

  I work on one interworking task between AMR RTP Payload and TRAU frame in TDM network, and find it is very difficult to map the Codec_Mode_Request(CMR) value in RTP to Request or Indication Flag (RIF) in TRAU frame which is defined in 3GPP 48.060/48.061. 

  As defined in RFC4867, RTP frame can take CMR and CMI(FT field) both in payload and the codec mode change period could be 20ms. However,TRAU speech frame can only take one of CMR or CMI, and the RIF should follow rigorous mode change peroid, that means, TRAU speech frame could only take CMR every 40ms and between each CMR frame, the TRAU speech frame must be CMI frame. 

  The issue happens when two consequent RTP payload takeing valide CMR value in each payload, at this scenario, we do not know how to set the RIF value. For instance, the first RTP payload takes CMR=4, and we map this CMR value to RIF flag to indicate the TRAU speech frame is for CMR, and the second RTP payload comes with CMR=1, then we really do not know how to do now. according to the RTP payload CMR valude, we should indicate RIF as CMR. However, according to the TRAU frame definition, the RIF must be CMI which following with last CMR frame.

  RFC4867 has some decription on reqirements for encoder in GSM. However, it is not enough, i think there needs some description on how to map CMR and CMI value in RTP frame to RIF defined TRAU when interworking between IP and TDM network. currentlly , we can not find such mapping table in any specification. We hope avt groud could work on this and resolve this issue.

   

  Best Regards

  Rock

   



--Boundary_(ID_JH2Zd4v/D3XrOlBs5ow2BA)
Content-type: text/html; charset=UTF-8
Content-transfer-encoding: base64

77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4
bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1
cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4ID0gDQoidXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnAgPSANCiJ1cm46c2NoZW1hcy1t
aWNyb3NvZnQtY29tOm9mZmljZTpwb3dlcnBvaW50IiB4bWxuczphID0gDQoidXJuOnNjaGVtYXMt
bWljcm9zb2Z0LWNvbTpvZmZpY2U6YWNjZXNzIiB4bWxuczpkdCA9IA0KInV1aWQ6QzJGNDEwMTAt
NjVCMy0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzID0gDQoidXVpZDpCREM2RTNGMC02
REEzLTExZDEtQTJBMy0wMEFBMDBDMTQ4ODIiIHhtbG5zOnJzID0gDQoidXJuOnNjaGVtYXMtbWlj
cm9zb2Z0LWNvbTpyb3dzZXQiIHhtbG5zOnogPSAiI1Jvd3NldFNjaGVtYSIgeG1sbnM6YiA9IA0K
InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnB1Ymxpc2hlciIgeG1sbnM6c3MgPSAN
CiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6YyA9
IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmNvbXBvbmVudDpzcHJlYWRzaGVl
dCIgeG1sbnM6b2RjID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2RjIiB4
bWxuczpvYSA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2YXRpb24i
IHhtbG5zOmh0bWwgPSANCiJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxuczpx
ID0gDQoiaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOnJ0
YyA9IA0KImh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIFhNTE5T
OkQgPSAiREFWOiIgWE1MTlM6UmVwbCA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20v
cmVwbC8iIHhtbG5zOm10ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBv
aW50L3NvYXAvbWVldGluZ3MvIiB4bWxuczp4MiA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m
dC5jb20vb2ZmaWNlL2V4Y2VsLzIwMDMveG1sIiB4bWxuczpwcGRhID0gDQoiaHR0cDovL3d3dy5w
YXNzcG9ydC5jb20vTmFtZVNwYWNlLnhzZCIgeG1sbnM6b2lzID0gDQoiaHR0cDovL3NjaGVtYXMu
bWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyID0gDQoiaHR0cDov
L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvZGlyZWN0b3J5LyIgeG1sbnM6
ZHMgPSANCiJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3AgPSAN
CiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvZHNwIiB4bWxuczp1ZGMg
PSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjIiB4bWxuczp4c2QgPSAN
CiJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViID0gDQoiaHR0cDov
L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvMjAwMi8xL2FsZXJ0cy8iIHht
bG5zOmVjID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjIiB4bWxuczpzcCA9
IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcyA9
IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIgeG1sbnM6
eHNpID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5z
OnVkY3MgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHht
bG5zOnVkY3hmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy94bWxm
aWxlIiB4bWxuczp1ZGNwMnAgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEv
dWRjL3BhcnR0b3BhcnQiIHhtbG5zOndmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv
bS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cvIiB4bWxuczpkc3NzID0gDQoiaHR0cDovL3NjaGVt
YXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9kaWdzaWctc2V0dXAiIHhtbG5zOmRzc2kgPSAN
CiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2RpZ3NpZyIgeG1sbnM6
bWRzc2kgPSANCiJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2
L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyID0gDQoiaHR0cDovL3NjaGVtYXMub3Blbnht
bGZvcm1hdHMub3JnL21hcmt1cC1jb21wYXRpYmlsaXR5LzIwMDYiIHhtbG5zOm0gPSANCiJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxz
ID0gDQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9yZWxh
dGlvbnNoaXBzIiB4bWxuczpzcHdwID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC93ZWJwYXJ0cGFnZXMiIHhtbG5zOmV4MTJ0ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0
LmNvbS9leGNoYW5nZS9zZXJ2aWNlcy8yMDA2L3R5cGVzIiB4bWxuczpleDEybSA9IA0KImh0dHA6
Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIg
eG1sbnM6cHB0c2wgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQv
c29hcC9TbGlkZUxpYnJhcnkvIiB4bWxuczpzcHNsID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20v
d2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRhbFNlcnZlci9QdWJsaXNoZWRMaW5rc1NlcnZpY2Ui
IA0KWE1MTlM6WiA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3QgPSAiASI+
PEhFQUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7
IGNoYXJzZXQ9dXRmLTgiPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC4zNjk4IiBu
YW1lPUdFTkVSQVRPUj48IS0tW2lmICFtc29dPg0KPFNUWUxFPnZcOiogew0KCUJFSEFWSU9SOiB1
cmwoI2RlZmF1bHQjVk1MKQ0KfQ0Kb1w6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwp
DQp9DQp3XDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0NCi5zaGFwZSB7DQoJ
QkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQo8L1NUWUxFPg0KPCFbZW5kaWZdLS0+DQo8
U1RZTEU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx
IDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFu
b3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJB
cmlhbCBVbmljb2RlIE1TIjsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx
MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4i
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAQXJpYWwgVW5pY29kZSBNUyI7DQoJcGFu
b3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi
XEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTrlrovkvZM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrljY7m
lofnu4bpu5E7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1z
b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz
aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp
Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy
aWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp
emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt
YXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh
Z2U6V29yZFNlY3Rpb24xO30NCi0tPg0KPC9TVFlMRT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjciIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2
OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpz
aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L0hFQUQ+DQo8Qk9EWSBsYW5nPUVOLVVTIHZM
aW5rPXB1cnBsZSBsaW5rPWJsdWUgYmdDb2xvcj13aGl0ZT4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh
bCBzaXplPTI+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhpPC9GT05UPjwvRElWPg0K
PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5ZZXMsIHRoZSBUUkFVIGNhbiBvbmx5IHRha2Ug
ZWl0aGVyIENNUiBvciBDTUksIGFuZCANCmluIEdTTSBuZXR3b3JrLCBUUkFVIGZyYW1lIHNlcXVl
bmNlIG11c3Qgc3RyaWN0bHkgYmUgb25lIENNUiBmcmFtZSBmb2xsb3dpbmcgDQp3aXRoIG9uZSBD
TUkgZnJhbWUgLCBob3dldmVyLCBSRkM0ODY3IGFsbG93cyB0YWtlIGJvdGggQ01SIGFuZCBDTUkg
b25lIHBhY2tldCANCmFuZCB0aGVyZSBpcyBubyBpbmRpY2F0aW9uIHRvIGluZGVudGlmeSZuYnNw
O3RoZSBwYWNrZXQgaXMmbmJzcDtDTVIgZnJhbWUgb3IgDQpub3QsIHRoYXQgbWFrZXMmbmJzcDt0
aGUgcHJvYmxlbS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwv
Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QlI8L0ZPTlQ+
PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlJvY2s8L0ZPTlQ+PC9ESVY+PC9G
T05UPjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAw
cHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAw
MDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDog
OXB0IOWui+S9kyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBz
dHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0IOWui+S9kzsgZm9udC1jb2xvcjog
YmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9RXZlbi5yb25pQGh1YXdlaS5jb20gaHJl
Zj0ibWFpbHRvOkV2ZW4ucm9uaUBodWF3ZWkuY29tIj5Sb25pIEV2ZW48L0E+IA0KICA8L0RJVj4N
CiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+VG86PC9CPiA8QSB0aXRsZT1hdnRA
aWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvQT4g
PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPkNjOjwvQj4gPEEgdGl0
bGU9eGllbGVpNTc0NzFAaHVhd2VpLmNvbSANCiAgaHJlZj0ibWFpbHRvOnhpZWxlaTU3NDcxQGh1
YXdlaS5jb20iPidYaWUgTGVpJzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDl
rovkvZMiPjxCPlNlbnQ6PC9CPiBUdWVzZGF5LCBPY3RvYmVyIDI2LCAyMDEwIDE6MTIgUE08L0RJ
Vj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+U3ViamVjdDo8L0I+IEZXOiBb
QVZUXVRoZSBpbnRlcndvcmtpbmcgaXNzdWUgZm9yIA0KICBSVFAgUGF5bG9hZCBGb3JtYXQgZm9y
IEFNUjwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJViBjbGFzcz1Xb3JkU2VjdGlvbjE+
DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsg
Q09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj5IaSw8
bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5
bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnQ2FsaWJy
aScsJ3NhbnMtc2VyaWYnIj5JIA0KICBhc3N1bWUgdGhhdCB0aGUgcHJvYmxlbSBpcyBiZWNhdXNl
IGluIFRSQVUgeW91IGNhbiBzZW5kIGVpdGhlciBDTVIgb3IgQ01JIA0KICB3aGlsZSBSRkM0ODY3
IGFsbG93cyBib3RoIGluIHRoZSBzYW1lIHBhY2tldC4gSXMgdGhpcyANCiAgY29ycmVjdD88bzpw
PjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9
IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScs
J3NhbnMtc2VyaWYnIj5Sb25pIA0KICBFdmVuPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBj
bGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiAj
MWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+PG86cD4mbmJzcDs8
L286cD48L1NQQU4+PC9QPg0KICA8RElWPg0KICA8RElWIA0KICBzdHlsZT0iQk9SREVSLVJJR0hU
OiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFw
dCBzb2xpZDsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctQk9UVE9NOiAwaW47IEJPUkRFUi1M
RUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdDsgQk9SREVSLUJPVFRPTTogbWVkaXVt
IG5vbmUiPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ
WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPkZyb206PC9TUEFO
PjwvQj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdUYWhv
bWEnLCdzYW5zLXNlcmlmJyI+IFhpZSBMZWkgDQogIFttYWlsdG86eGllbGVpNTc0NzFAaHVhd2Vp
LmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiBNb25kYXksIE9jdG9iZXIgMjUsIDIwMTAgOToxNCANCiAg
QU08QlI+PEI+VG86PC9CPiA8QSBocmVmPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5v
cmc8L0E+PEJSPjxCPkNjOjwvQj4gDQogIDxBIA0KICBocmVmPSJtYWlsdG86a2VpdGguZHJhZ2VA
YWxjYXRlbC1sdWNlbnQuY29tIj5rZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb208L0E+OyAN
CiAgJ1JvbmkgRXZlbic8QlI+PEI+U3ViamVjdDo8L0I+IFtBVlRdVGhlIGludGVyd29ya2luZyBp
c3N1ZSBmb3IgUlRQIFBheWxvYWQgDQogIEZvcm1hdCBmb3IgQU1SPG86cD48L286cD48L1NQQU4+
PC9QPjwvRElWPjwvRElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48
L1A+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQt
U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5IZWxsbyANCiAg
QWxsPC9TUEFOPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29O
b3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQXJp
YWwnLCdzYW5zLXNlcmlmJyI+SSZuYnNwO3dvcmsgb24gb25lIA0KICBpbnRlcndvcmtpbmcgdGFz
ayBiZXR3ZWVuIEFNUiBSVFAgUGF5bG9hZCBhbmQgPC9TUEFOPjxTUEFOIGxhbmc9RlIgDQogIHN0
eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+
VFJBVSBmcmFtZSBpbiBURE0gDQogIG5ldHdvcmssIGFuZCBmaW5kIGl0IGlzIHZlcnkgZGlmZmlj
dWx0IHRvIG1hcCB0aGUgPC9TUEFOPjxTUEFOIGxhbmc9RlIgDQogIHN0eWxlPSJGT05ULVNJWkU6
IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5D
b2RlY19Nb2RlX1JlcXVlc3QoQ01SKSANCiAgdmFsdWUgaW4gUlRQIHRvIDwvU1BBTj48U1BBTiAN
CiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogJ0Fy
aWFsJywnc2Fucy1zZXJpZiciPlJlcXVlc3Q8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ
WkU6IDEwcHQ7IENPTE9SOiByZWQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+
IA0KICA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFj
azsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5vciANCiAgSW5kaWNhdGlvbiBG
bGFnPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogcmVkOyBG
T05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPiANCiAgPC9TUEFOPjxTUEFOIA0KICBz
dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiAnQXJpYWwn
LCdzYW5zLXNlcmlmJyI+KFJJRikgDQogIGluIFRSQVUgZnJhbWUgd2hpY2ggaXMgZGVmaW5lZCBp
bjwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0OyBDT0xPUjogYmxhY2si
PiA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsg
Rk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj4zR1BQIA0KICA0OC4wNjAvNDguMDYx
LiA8L1NQQU4+PG86cD48L286cD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05v
cm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05U
LUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPkFzIA0KICBkZWZpbmVkIGluIFJGQzQ4Njcs
IFJUUCBmcmFtZSBjYW4gdGFrZSBDTVIgYW5kIENNSShGVCBmaWVsZCkgYm90aCBpbiBwYXlsb2Fk
IA0KICBhbmQgdGhlIGNvZGVjIG1vZGUgY2hhbmdlIHBlcmlvZCZuYnNwO2NvdWxkIGJlJm5ic3A7
MjBtcy4gSG93ZXZlciw8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJDT0xPUjogYmxhY2siPlRSQVUg
c3BlZWNoIGZyYW1lIGNhbiBvbmx5IHRha2Ugb25lIG9mIENNUiBvciBDTUksIGFuZCANCiAgdGhl
IFJJRiA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFj
azsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5zaG91bGQgDQogIGZvbGxvdyZu
YnNwO3JpZ29yb3VzIG1vZGUgY2hhbmdlIHBlcm9pZCwgdGhhdCBtZWFucywgPC9TUEFOPjxTUEFO
IA0KICBzdHlsZT0iQ09MT1I6IGJsYWNrIj5UUkFVIHNwZWVjaCBmcmFtZTwvU1BBTj48U1BBTiAN
CiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogJ0Fy
aWFsJywnc2Fucy1zZXJpZiciPiANCiAgY291bGQgb25seSB0YWtlIENNUiBldmVyeSA0MG1zIGFu
ZCBiZXR3ZWVuIGVhY2ggQ01SIGZyYW1lLCB0aGUgPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iQ09M
T1I6IGJsYWNrIj5UUkFVIHNwZWVjaCBmcmFtZSZuYnNwOzwvU1BBTj48U1BBTiANCiAgc3R5bGU9
IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fu
cy1zZXJpZiciPm11c3QgDQogIGJlIENNSSBmcmFtZS4gPC9TUEFOPjxvOnA+PC9vOnA+PC9QPjwv
RElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05U
LVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2Vy
aWYnIj5UaGUmbmJzcDtpc3N1ZSANCiAgaGFwcGVucyB3aGVuIHR3byBjb25zZXF1ZW50IFJUUCZu
YnNwO3BheWxvYWQgdGFrZWluZyB2YWxpZGUgQ01SIHZhbHVlIGluIGVhY2ggDQogIHBheWxvYWQs
IGF0IHRoaXMgc2NlbmFyaW8sIHdlIGRvIG5vdCBrbm93IGhvdyB0byBzZXQgdGhlIFJJRiB2YWx1
ZS4gRm9yIA0KICBpbnN0YW5jZSwgdGhlIGZpcnN0IFJUUCBwYXlsb2FkIHRha2VzIENNUj00LCBh
bmQgd2UgbWFwIHRoaXMgQ01SIHZhbHVlIHRvIFJJRiANCiAgZmxhZyB0byBpbmRpY2F0ZSB0aGUg
PC9TUEFOPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2siPlRSQVUgc3BlZWNoIA0KICBmcmFtZTwv
U1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05U
LUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPiANCiAgPC9TUEFOPjxTUEFOIHN0eWxlPSJD
T0xPUjogYmxhY2siPmlzIGZvciBDTVIsIGFuZCB0aGUgc2Vjb25kIFJUUCBwYXlsb2FkIGNvbWVz
IA0KICB3aXRoIENNUj0xLCB0aGVuIHdlIHJlYWxseSBkbyBub3Qga25vdyBob3cgdG8gZG8gbm93
LiBhY2NvcmRpbmcgdG8gdGhlIFJUUCANCiAgcGF5bG9hZCBDTVIgdmFsdWRlLCB3ZSBzaG91bGQg
aW5kaWNhdGUgUklGIGFzIENNUi4gSG93ZXZlciwgYWNjb3JkaW5nIHRvIHRoZSANCiAgVFJBVSBm
cmFtZSBkZWZpbml0aW9uLCB0aGUgUklGJm5ic3A7bXVzdCBiZSBDTUkgd2hpY2gmbmJzcDtmb2xs
b3dpbmcgd2l0aCBsYXN0IA0KICBDTVIgZnJhbWUuPC9TUEFOPjxvOnA+PC9vOnA+PC9QPjwvRElW
Pg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ
WkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYn
Ij5SRkM0ODY3IA0KICBoYXMgc29tZSBkZWNyaXB0aW9uIG9uIHJlcWlyZW1lbnRzIGZvciBlbmNv
ZGVyIGluIEdTTS4gSG93ZXZlciwgaXQgaXMgbm90IA0KICBlbm91Z2gsJm5ic3A7aSB0aGluayB0
aGVyZSBuZWVkcyBzb21lIGRlc2NyaXB0aW9uIG9uJm5ic3A7aG93IHRvIG1hcCBDTVIgYW5kIA0K
ICBDTUkgdmFsdWUgaW4gUlRQIGZyYW1lJm5ic3A7dG8gUklGJm5ic3A7ZGVmaW5lZCZuYnNwO1RS
QVUgd2hlbiBpbnRlcndvcmtpbmcgDQogIGJldHdlZW4gSVAgYW5kIFRETSBuZXR3b3JrLiBjdXJy
ZW50bGx5ICwgd2UgY2FuIG5vdCBmaW5kIHN1Y2ggbWFwcGluZyB0YWJsZSBpbiANCiAgYW55IHNw
ZWNpZmljYXRpb24uIFdlIGhvcGUgYXZ0IGdyb3VkIGNvdWxkIHdvcmsgb24gdGhpcyBhbmQmbmJz
cDtyZXNvbHZlIHRoaXMgDQogIGlzc3VlLjwvU1BBTj48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAg
PERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9QPjwvRElWPg0K
ICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6
IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5C
ZXN0IA0KICBSZWdhcmRzPC9TUEFOPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8RElWPg0KICA8
UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjayI+Um9jazwvU1BBTj48
bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPiZuYnNw
OzxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PCEt
LVtpZiBndGUgdm1sIDFdPjx2OnNoYXBldHlwZSBpZD0iX3gwMDAwX3Q3NSIgY29vcmRzaXplPSIy
MTYwMCwyMTYwMCIgDQogbzpzcHQ9Ijc1IiBvOnByZWZlcnJlbGF0aXZlPSJ0IiBwYXRoPSJtQDRA
NWxANEAxMUA5QDExQDlANXhlIiBmaWxsZWQ9ImYiIA0KIHN0cm9rZWQ9ImYiPg0KIDx2OnN0cm9r
ZSBqb2luc3R5bGU9Im1pdGVyIiAvPg0KIDx2OmZvcm11bGFzPg0KICA8djpmIGVxbj0iaWYgbGlu
ZURyYXduIHBpeGVsTGluZVdpZHRoIDAiIC8+DQogIDx2OmYgZXFuPSJzdW0gQDAgMSAwIiAvPg0K
ICA8djpmIGVxbj0ic3VtIDAgMCBAMSIgLz4NCiAgPHY6ZiBlcW49InByb2QgQDIgMSAyIiAvPg0K
ICA8djpmIGVxbj0icHJvZCBAMyAyMTYwMCBwaXhlbFdpZHRoIiAvPg0KICA8djpmIGVxbj0icHJv
ZCBAMyAyMTYwMCBwaXhlbEhlaWdodCIgLz4NCiAgPHY6ZiBlcW49InN1bSBAMCAwIDEiIC8+DQog
IDx2OmYgZXFuPSJwcm9kIEA2IDEgMiIgLz4NCiAgPHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4
ZWxXaWR0aCIgLz4NCiAgPHY6ZiBlcW49InN1bSBAOCAyMTYwMCAwIiAvPg0KICA8djpmIGVxbj0i
cHJvZCBANyAyMTYwMCBwaXhlbEhlaWdodCIgLz4NCiAgPHY6ZiBlcW49InN1bSBAMTAgMjE2MDAg
MCIgLz4NCiA8L3Y6Zm9ybXVsYXM+DQogPHY6cGF0aCBvOmV4dHJ1c2lvbm9rPSJmIiBncmFkaWVu
dHNoYXBlb2s9InQiIG86Y29ubmVjdHR5cGU9InJlY3QiIC8+DQogPG86bG9jayB2OmV4dD0iZWRp
dCIgYXNwZWN0cmF0aW89InQiIC8+DQo8L3Y6c2hhcGV0eXBlPjx2OnNoYXBlIGlkPSJyaWRJbWci
IG86c3BpZD0iX3gwMDAwX3MxMDI2IiB0eXBlPSIjX3gwMDAwX3Q3NSIgDQogYWx0PSJodWF3ZWlf
bG9nbyIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjA7bWFyZ2luLXRvcDow
O3dpZHRoOjc2LjVwdDsNCiBoZWlnaHQ6MjRwdDt6LWluZGV4OjI1MTY1ODI0MDttc28td3JhcC1k
aXN0YW5jZS1sZWZ0OjA7DQogbXNvLXdyYXAtZGlzdGFuY2UtdG9wOjA7bXNvLXdyYXAtZGlzdGFu
Y2UtcmlnaHQ6MDttc28td3JhcC1kaXN0YW5jZS1ib3R0b206MDsNCiBtc28tcG9zaXRpb24taG9y
aXpvbnRhbDpsZWZ0O21zby1wb3NpdGlvbi1ob3Jpem9udGFsLXJlbGF0aXZlOnRleHQ7DQogbXNv
LXBvc2l0aW9uLXZlcnRpY2FsLXJlbGF0aXZlOmxpbmUnIG86YWxsb3dvdmVybGFwPSJmIj4NCiA8
djppbWFnZWRhdGEgc3JjPSJjaWQ6MDBkMDAxY2I3NDE0JDM4OTcwM2EwJDVmMTA2ZjBhQGNoaW5h
Lmh1YXdlaS5jb20iIA0KICBvOnRpdGxlPSIwMGQwMDFjYjc0MTQkMzg5NzAzYTAkNWYxMDZmMGFA
Y2hpbmEuaHVhd2VpIiAvPg0KIDx3OndyYXAgdHlwZT0ic3F1YXJlIi8+DQo8L3Y6c2hhcGU+PCFb
ZW5kaWZdLS0+PCFbaWYgIXZtbF0+PCFbZW5kaWZdPjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9
Mj48L0ZPTlQ+Jm5ic3A7PC9QPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1M
Pg0K

--Boundary_(ID_JH2Zd4v/D3XrOlBs5ow2BA)--

From varun.singh@gmail.com  Mon Oct 25 23:52:13 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09ABB3A6923 for ; Mon, 25 Oct 2010 23:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhJtODetDd4x for ; Mon, 25 Oct 2010 23:52:11 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A0F433A691E for ; Mon, 25 Oct 2010 23:52:11 -0700 (PDT)
Received: by iwn40 with SMTP id 40so5020597iwn.31 for ; Mon, 25 Oct 2010 23:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:cc:content-type; bh=PSNtmHWCoYq7pBtx8Qf7vOfKLVN3sBN+sB2qTUfJyOM=; b=jixLUDhraQjdK7tDjDv1M3BZNkAmxvitMWviBL6Gt6OPs0I2ucZQt/h89rJ0v37zx5 w53xgLAfrwIiOBzM3Bk0KJsc+0tJkgPGLasYDIrbBTvttqvgcFeOSAerlytrGF5hHjUM C0BIbdQnsV5kM+N3BrEdx1ARVTj6HPMGuGYSU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=AJ+jKR3Odpo/yK+YwAQt7gv9oSbcSqyI3X2kYH3efkes99xa3D1sOUY1i17+xSjd1a uZ7FwTdYotNdfGsTigvx1eJleE5VrkUsrgCK3hHNVEXTdaWZrTeYL3GCPAVRpF9lSva1 okfULVd4klx+De7KQjEAgP+mpEljtGd1BaV6A=
Received: by 10.42.140.136 with SMTP id k8mr142652icu.224.1288076037607; Mon, 25 Oct 2010 23:53:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.173.193 with HTTP; Mon, 25 Oct 2010 23:53:37 -0700 (PDT)
From: Varun Singh 
Date: Tue, 26 Oct 2010 09:53:37 +0300
Message-ID: 
To: avt@ietf.org
Content-Type: text/plain; charset=UTF-8
Cc: Roni Even , =?UTF-8?B?SsO2cmcgT3R0?= , Keith Drage , =?UTF-8?B?VGVlbXUgS8Okcmtrw6RpbmVu?= , Varun Singh , Lars Eggert , Saba Ahsan 
Subject: [AVT] Fwd: New Version Notification for draft-singh-avt-mprtp-01
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 06:52:13 -0000

Hi,

This is an update to the Multipath RTP draft presented at Maastricht.
We have made additions in Section 8 and 9. (diff:
http://tools.ietf.org/rfcdiff?url2=draft-singh-avt-mprtp-01.txt).
Comments are welcome.

A brief summary, Multipath RTP picks up ideas from MPTCP and SCTP, it
aims to exploit the multiple interfaces for increasing throughput
and/or robustness.

Regards,
Varun

Begin forwarded message:

From: IETF I-D Submission Tool 
Date: October 25, 2010 10:34:20 PM GMT+03:00
To: varun@comnet.tkk.fi
Cc: sahsan@cc.hut.fi,jo@comnet.tkk.fi,teemuk@comnet.tkk.fi,lars.eggert@nokia.com
Subject: New Version Notification for draft-singh-avt-mprtp-01


A new version of I-D, draft-singh-avt-mprtp-01.txt has been
successfully submitted by Varun Singh and posted to the IETF
repository.

Filename:	 draft-singh-avt-mprtp
Revision:	 01
Title:		 Multipath RTP (MPRTP)
Creation_date:	 2010-10-25
WG ID:		 Independent Submission
Number_of_pages: 23

Abstract:
The Real-time Transport Protocol (RTP) is used to deliver real-time
content and, along with the RTP Control Protocol (RTCP), forms the
control channel between the sender and receiver.  However, RTP and
RTCP assume a single delivery path between the sender and receiver
and make decisions based on the measured characteristics of this
single path.  Increasingly, endpoints are becoming multi-homed, which
means that they are connected via multiple Internet paths.  Network
utilization can be improved when endpoints use multiple parallel
paths for communication.  The resulting increase in reliability and
throughput can also enhance the user experience.  This document
extends the Real-time Transport Protocol (RTP) so that a single
session can take advantage of the availability of multiple paths
between two endpoints.



The IETF Secretariat.


Varun Singh
http://www.netlab.tkk.fi/~varun

From 2mkristensen@gmail.com  Tue Oct 26 02:04:17 2010
Return-Path: <2mkristensen@gmail.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ECEC3A67DA for ; Tue, 26 Oct 2010 02:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbffYY8mzAhG for ; Tue, 26 Oct 2010 02:04:16 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 05D663A67CF for ; Tue, 26 Oct 2010 02:04:15 -0700 (PDT)
Received: by qwb7 with SMTP id 7so2370305qwb.31 for ; Tue, 26 Oct 2010 02:06:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DPpeW2C/zYHMKnwGnyIWchT1LQcoEI5pg+C9wQELupw=; b=OEgIaFPMvm8lD7lWDzUyckw9OLHy//+wICQ9jAozAYIytCTY//OPl6uImhILRnni8x d4lynKeVrYiK5NRwF0mgq37hd+lX73MZMyrZ3X8ejVDSuZmov8zlJQGZhFQUeHkLVUz4 96ukMJA25uKUeDOyBW7HvTCDYDls4rGVuoX8o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BMekERyNNiL5t63DCqhAxvHO2E/As3sSof1mOIIQBMffdHhNdTPbr7kxqAkf/yqD/S /jA7lwQuI7BH5aQf01Zcw/LgwqSYAVsXZnFaO2GO9PZhWQEbJhZLy+PtUGidc/AaObLM z7NonelU6B+x8lp+OeddRPXDrfzeMrqj4zbao=
MIME-Version: 1.0
Received: by 10.229.218.69 with SMTP id hp5mr3104432qcb.18.1288083962679; Tue, 26 Oct 2010 02:06:02 -0700 (PDT)
Received: by 10.229.13.16 with HTTP; Tue, 26 Oct 2010 02:06:02 -0700 (PDT)
In-Reply-To: <20101025160005.C16AE3A69B1@core3.amsl.com>
References: <20101025160005.C16AE3A69B1@core3.amsl.com>
Date: Tue, 26 Oct 2010 11:06:02 +0200
Message-ID: 
From: Tom Kristensen <2mkristensen@gmail.com>
To: IETF AVT WG 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Malcolm Walters , Tom Kristensen 
Subject: Re: [AVT] I-D Action:draft-kristensen-avt-rtp-h241param-01.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 09:04:17 -0000

On 25 October 2010 18:00,   wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Additional H.241 Parameter in =
the RTP Payload Format for H.264 Video
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Kristensen, M. Walters
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kristensen-avt-rtp-h241par=
am-01.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-10-25
>
> As systems increasingly are able to run video at 60 frames per
> second, there is a need to signal desired frame rate to optimise
> resolution choices and to avoid unnecessary resource or energy usage.
> This document defines a new optional parameter addressing recent
> extensions currently supported in H.323 systems: The signalling of
> the maximum frames per second that can be efficiently received or
> that can be sent.
>
> A URL for this Internet-Draft is:
http://tools.ietf.org/html/draft-kristensen-avt-rtp-h241param-01

The -01 version was submitted yesterday, before the IETF-79 great wall
surrounded the draft submission tool.

This version addresses the feedback and handles the issues from the
AVT mailing list discussion on this draft. Most important:
- Emphasize the resolution choice optimization and energy
consumption/battery duration as motivation for max-fps
- Underline ease of gatewaying between SIP and H.323 as a reason
- Added graphs as an aid visualizing the effect of max-fps, together
with macroblock and frame size signalling
- Changed the normative text in the media type registration along the
lines of for instance sar-supported in RFC3984bis
- Tightened text describing "a=3Dmaxprate" and H.26x frame rate
signalling parameters, to get the real message clearer through
- A better text regarding co-existence with "a=3Dframerate" added

(The -00/-01 diff:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-kristensen-avt-rtp-h241param-01.=
txt
)

-- Tom

From tom.kristensen@tandberg.com  Tue Oct 26 02:15:11 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69B733A6778 for ; Tue, 26 Oct 2010 02:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKfYGFGpP6no for ; Tue, 26 Oct 2010 02:15:06 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 49DD03A6844 for ; Tue, 26 Oct 2010 02:15:04 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKc5xkytJV2a/2dsb2JhbAChTHGgdJw+hUgEjVMG
X-IronPort-AV: E=Sophos;i="4.58,240,1286150400"; d="scan'208";a="175265039"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2010 09:16:50 +0000
Received: from OSLEXCP11.eu.tandberg.int ([173.38.136.5]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o9Q9Ggf8020648;  Tue, 26 Oct 2010 09:16:50 GMT
Received: from ultra.eu.tandberg.int ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Oct 2010 11:15:07 +0200
Received: from [10.47.13.116] ([10.47.13.116]) by ultra.eu.tandberg.int (8.13.1/8.13.1) with ESMTP id o9Q9F789000746;  Tue, 26 Oct 2010 11:15:07 +0200
Message-ID: <4CC69C1B.7090108@tandberg.com>
Date: Tue, 26 Oct 2010 11:15:07 +0200
From: Tom Kristensen 
Organization: Cisco
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.7
MIME-Version: 1.0
To: Tom Kristensen <2mkristensen@gmail.com>
References: <20101025160005.C16AE3A69B1@core3.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Oct 2010 09:15:07.0659 (UTC) FILETIME=[4870EDB0:01CB74EE]
Cc: Malcolm Walters , IETF AVT WG , Tom Kristensen 
Subject: Re: [AVT] I-D Action:draft-kristensen-avt-rtp-h241param-01.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 09:15:11 -0000

On 10/26/2010 11:06 AM, Tom Kristensen wrote:
> On 25 October 2010 18:00,  wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>         Title           : Additional H.241 Parameter in the RTP Payload Format for H.264 Video
>>         Author(s)       : T. Kristensen, M. Walters
>>         Filename        : draft-kristensen-avt-rtp-h241param-01.txt
[...]

I forgot to flag this "errata" in the announce message. Noticed just as 
-01 was submitted that we accidentally changed the normative text for 
the mediatype parameter registration.

Cf. 
http://tools.ietf.org/html/draft-kristensen-avt-rtp-h241param-01#section-3.1

As max-fps is an OPTIONAL parameter the right thing to say is
"This parameter MAY be used to indicate the maximum [...]" not
"This parameter SHOULD be used to indicate the maximum [...]"
as currently said in -01. Will be fixed in next version.

-- Tom

From ray.vanbrandenburg@tno.nl  Tue Oct 26 02:58:32 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053E53A6933 for ; Tue, 26 Oct 2010 02:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.384
X-Spam-Level: 
X-Spam-Status: No, score=0.384 tagged_above=-999 required=5 tests=[AWL=0.888,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaqvaVtNxNsj for ; Tue, 26 Oct 2010 02:58:31 -0700 (PDT)
Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id B39B33A6929 for ; Tue, 26 Oct 2010 02:58:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,240,1286143200"; d="scan'208";a="10413061"
Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 26 Oct 2010 12:00:14 +0200
Received: from ms-dt01thalia.tsn.tno.nl (134.221.225.157) by EXC-CASHUB01.tsn.tno.nl (134.221.225.220) with Microsoft SMTP Server id 14.1.255.0; Tue, 26 Oct 2010 12:00:14 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 26 Oct 2010 12:00:14 +0200
Message-ID: 
In-Reply-To: <010901cb722d$92532b50$b6f981f0$%roni@huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-brandenburg-avt-rtcp-for-idms-02 - going forward
Thread-Index: ActqBt9LAige+0fVQCeB3foz4CzldQAxeHmQAdfNpkAAsbGyoA==
References:  <010901cb722d$92532b50$b6f981f0$%roni@huawei.com>
From: "Brandenburg, R. (Ray) van" 
To: 
Content-Transfer-Encoding: quoted-printable
Subject: Re: [AVT] draft-brandenburg-avt-rtcp-for-idms-02 - going forward
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 09:58:32 -0000

Hi all,

Roni, thanks for the support. I will prepare a presentation for Beijing.


For those that would like some more background on IDMS; on request I can
send you some papers on the topic.

Regards,

Ray van Brandenburg


-----Original Message-----
From: Roni Even [mailto:Even.roni@huawei.com]=20
Sent: vrijdag 22 oktober 2010 23:10
To: Brandenburg, R. (Ray) van
Cc: avt@ietf.org; 'DRAGE, Keith (Keith)'
Subject: draft-brandenburg-avt-rtcp-for-idms-02 - going forward

Hi,
I read the draft and looked also at annex W of TS 183 063 v3.4.1 which
specifies this XR block and SDP.=20
I appreciate you brining this document to the IETF AVT WG even though it
would have been enough to have it in TS 183 063 according to the
specification required policy in RFC 3611 section 6.2.

I think it will be good to present it in Beijing and we can ask if
people in AVT would like to have it as a work item or just help by
reviewing leaving it in TS 183 063.

Regards
Roni Even
AVT co-chair



This e-mail and its contents are subject to the DISCLAIMER at http://www.tn=
o.nl/disclaimer/email.html


From Even.roni@huawei.com  Tue Oct 26 13:42:18 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801B43A68EA for ; Tue, 26 Oct 2010 13:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.106
X-Spam-Level: 
X-Spam-Status: No, score=-100.106 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKeFxDJBmcuy for ; Tue, 26 Oct 2010 13:42:15 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id AE5BA3A68D6 for ; Tue, 26 Oct 2010 13:42:14 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAX008BF094K7@szxga01-in.huawei.com> for avt@ietf.org; Wed, 27 Oct 2010 04:43:52 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAX00AGH094RR@szxga01-in.huawei.com> for avt@ietf.org; Wed, 27 Oct 2010 04:43:52 +0800 (CST)
Received: from windows8d787f9 ([109.64.15.67]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAX00L0708WPV@szxml02-in.huawei.com>; Wed, 27 Oct 2010 04:43:52 +0800 (CST)
Date: Tue, 26 Oct 2010 22:43:28 +0200
From: Roni Even 
To: avt@ietf.org
Message-id: <03bc01cb754e$759e5240$60daf6c0$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_YPWvOxEGI+ZFlZGhqVDpfw)"
Content-language: en-us
Thread-index: Act1TnD4ARAt3a+SQiS089RRPXGFMg==
Cc: 'Keith Drage' 
Subject: [AVT] Initial AVT Agenda for IETF 79
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 20:42:19 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_YPWvOxEGI+ZFlZGhqVDpfw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi,

This is the initial agenda for AVT in the Beijing meeting.

Please review 

Regards

Keith Drage and Roni Even

 

 

Audio/Video Transport (AVT) Working Group

=========================================

 

CHAIRS:  Keith Drage        

         Roni Even         

 

AGENDA

 

Monday, 8 November 2010 at 13:00-15:00 (Valley Ballroom B)

----------------------------------------------------------

13:00   Introduction and Status Update                      (Chairs, 15)

 

13:15   Port Mapping Between Unicast and Multicast RTP Sessions(Begen, 20)

        draft-begen-avt-token-for-portmapping-01

 

13:35   Explicit Congestion Notification for RTP over UDP  (Perkins, 20)

        draft-ietf-avt-ecn-for-rtp-03

 

13:55   RTCP Report Extension for Feedback Suppression      (Qin Wu, 15)

        draft-wu-avt-retransmission-supression-rtp-05

 

14:10   RTCP XR for inter-destination media synchronization(Ray van
Brandenburg , 10)

        draft-brandenburg-avt-rtcp-for-idms-02

 

14:20   Additional Parameters in for H.264 Video    (Tom Kristensen, 10)

        draft-kristensen-avt-rtp-h241param-01

 

14:30   End

 

 

Thursday, 11 November 2010 at 13:00-15:00 (Garden Ballroom 3)

-------------------------------------------------------------

13:00   Introduction and Status Update                       (Chairs, 5)

 

13:05   Audio Levels status                                 (Chairs, 10)

 

13:15   Content Splicing for RTP Sessions               (Jinwei Xia, 15)

        draft-xia-avt-splicing-for-rtp-00

 

13:30   Monitoring Architectures for RTP                      (Even, 20)

        draft-hunt-avt-monarch-01

 

13:50   RTCP XR Report Blocks for Realtime Video Quality Monitoring(Qin Wu,
10)

        draft-wu-avt-rtcp-xr-quality-monitoring-04

 

14:00   Switching from unicast to multicast for multicast short
time-shift(Peilin Yang, 15)

        draft-yang-avt-switch-multicast-short-timeshift-00

 

14:15   Using approximate authentication SRTP          (Gabor Feher, 10)

        draft-feher-avt-approx-auth-srtp-00

 

14:25   End

 


--Boundary_(ID_YPWvOxEGI+ZFlZGhqVDpfw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable
















Hi,



This is the initial agenda for AVT in the Beijing =
meeting.



Please review 



Regards



Keith Drage and Roni Even



 



 



Audio/Video Transport (AVT) Working =
Group



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



 



CHAIRS:  Keith =
Drage       
<keith.drage@alcatel-lucent.com>



         =
Roni Even         =
<even.roni@huawei.com>



 



AGENDA



 



Monday, 8 November 2010 at 13:00-15:00 (Valley =
Ballroom B)



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



13:00   Introduction and Status =
Update           &=
nbsp;         
(Chairs, 15)



 



13:15   Port Mapping Between Unicast and =
Multicast RTP
Sessions(Begen, 20)



        =
draft-begen-avt-token-for-portmapping-01



 



13:35   Explicit Congestion Notification =
for RTP over UDP 
(Perkins, 20)



        =
draft-ietf-avt-ecn-for-rtp-03



 



13:55   RTCP Report Extension for =
Feedback Suppression     
(Qin Wu, 15)



        =
draft-wu-avt-retransmission-supression-rtp-05



 



14:10   RTCP XR for inter-destination =
media
synchronization(Ray van Brandenburg , 10)



        =
draft-brandenburg-avt-rtcp-for-idms-02



 



14:20   Additional Parameters in for =
H.264 Video    (Tom
Kristensen, 10)



        =
draft-kristensen-avt-rtp-h241param-01



 



14:30   End



 



 



Thursday, 11 November 2010 at 13:00-15:00 (Garden =
Ballroom
3)



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



13:00   Introduction and Status =
Update           &=
nbsp;          
(Chairs, 5)



 



13:05   Audio Levels =
status           &=
nbsp;           &n=
bsp;        
(Chairs, 10)



 



13:15   Content Splicing for RTP =
Sessions           =
;   
(Jinwei Xia, 15)



        =
draft-xia-avt-splicing-for-rtp-00



 



13:30   Monitoring Architectures for
RTP           &nbs=
p;          (Even, =
20)



        =
draft-hunt-avt-monarch-01



 



13:50   RTCP XR Report Blocks for =
Realtime Video Quality
Monitoring(Qin Wu, 10)



        =
draft-wu-avt-rtcp-xr-quality-monitoring-04



 



14:00   Switching from unicast to =
multicast for multicast
short time-shift(Peilin Yang, 15)



        =
draft-yang-avt-switch-multicast-short-timeshift-00



 



14:15   Using approximate authentication =
SRTP         
(Gabor Feher, 10)



        =
draft-feher-avt-approx-auth-srtp-00



 



14:25   End



 









--Boundary_(ID_YPWvOxEGI+ZFlZGhqVDpfw)--

From keith.drage@alcatel-lucent.com  Wed Oct 27 05:56:33 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC29E3A69D4 for ; Wed, 27 Oct 2010 05:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.21
X-Spam-Level: 
X-Spam-Status: No, score=-105.21 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46oC5fX9fX0d for ; Wed, 27 Oct 2010 05:56:32 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 03E283A694A for ; Wed, 27 Oct 2010 05:56:31 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9RCwK5Q030093 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 27 Oct 2010 14:58:20 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 27 Oct 2010 14:58:20 +0200
From: "DRAGE, Keith (Keith)" 
To: "avt@ietf.org" 
Date: Wed, 27 Oct 2010 14:58:18 +0200
Thread-Topic: Publication request for draft-ietf-avt-rtcp-port-for-ssm-03
Thread-Index: Act11qB1drnL+N17QXWT4ZITgD1OUA==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83
Subject: [AVT] Publication request for draft-ietf-avt-rtcp-port-for-ssm-03
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Oct 2010 12:56:33 -0000

I have just requested publication of draft-ietf-avt-rtcp-port-for-ssm-03 as=
 proposed standard.

The writeup follows at the end of this mail.

-03 was produced as a result of this review. It contains two small changes.=
 One reference changes from normative to informative. An additional sentenc=
e is introduced "Except where stated otherwise in this document, the rules =
of [RFC3550] apply." as RFC 3550 is currently a normative reference, and th=
is text is only implied in the introduction.


regards

Keith

-----------------------------------------------------------
Shepherd writeup for draft-ietf-avt-rtcp-port-for-ssm-03 "RTP Control=20
Protocol (RTCP) Port for Multicast Sessions" as proposed standard.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the=20
        document and, in particular, does he or she believe this=20
        version is ready for forwarding to the IESG for publication?=20

The document shepherd for this document is Keith Drage.

The document shepherd has reviewed the document and believes it is ready fo=
r=20
forwarding to the IESG for publication.

Document history:

-	draft-begen-avt-rtcp-port-for-ssm-00 was submitted 22nd March=20
2010 and expires 23rd September 2010;
-	draft-begen-avt-rtcp-port-for-ssm-01 was submitted 3rd April 2010=20
and expires 5th October 2010;
-	draft-ietf-avt-rtcp-port-for-ssm-00 was submitted 16th June 2010=20
and expires 18th December 2010;
-	draft-ietf-avt-rtcp-port-for-ssm-01 was submitted 3rd August 2010=20
and expires 4th February 2010;
-	draft-ietf-avt-rtcp-port-for-ssm-02 was submitted 25th August=20
2010 and expires 26th February 2011;
-	draft-ietf-avt-rtcp-port-for-ssm-03 was submitted 25th October=20
2010 and expires 28th April 2011;

Call for adoption of baseline as WG item was made 4th June 2010 and=20
acceptance declared 16th June 2010.

Working group last call was initiated on -01 version on 4th August 2010=20
for completion 25th August 2010 as proposed standard. The MMUSIC was=20
also asked to review this version at the same time as working group=20
last call as this document is substantially an SDP definition. Reviews=20
were received from Keith Drage.

Prior to working group last call, the document received comments from=20
Peter Musgrave.

  (1.b) Has the document had adequate review both from key WG members=20
        and from key non-WG members? Does the Document Shepherd have=20
        any concerns about the depth or breadth of the reviews that=20
        have been performed? =20

The document has been adequately reviewed (see 1a above). This is a very si=
mple=20
document and substantial comments would not be expected.

  (1.c) Does the Document Shepherd have concerns that the document=20
        needs more review from a particular or broader perspective,=20
        e.g., security, operational complexity, someone familiar with=20
        AAA, internationalization or XML?=20

There are no such concerns from the document shepherd.

  (1.d) Does the Document Shepherd have any specific concerns or=20
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he=20
        or she is uncomfortable with certain parts of the document, or=20
        has concerns whether there really is a need for it. In any=20
        event, if the WG has discussed those issues and has indicated=20
        that it still wishes to advance the document, detail those=20
        concerns here. Has an IPR disclosure related to this document=20
        been filed? If so, please include a reference to the=20
        disclosure and summarize the WG discussion and conclusion on=20
        this issue.=20

There are no concerns from the document shepherd from this perspective with=
 the=20
document.

No IPR disclosures have been made against this document (and indeed none=20
previously in the area of SSM).

  (1.e) How solid is the WG consensus behind this document? Does it=20
        represent the strong concurrence of a few individuals, with=20
        others being silent, or does the WG as a whole understand and=20
        agree with it?  =20

>From a reviewing perspective, the interest in this specific document has be=
en=20
relatively small, but it forms an essential part of draft-ietf-avt-rapid-
acquisition-for-rtp which has been well and substantially reviewed. It=20
is assumed that the interested parties in that document have also reviewed =
this=20
document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20
        discontent? If so, please summarise the areas of conflict in=20
        separate email messages to the Responsible Area Director. (It=20
        should be in a separate email because this questionnaire is=20
        entered into the ID Tracker.)=20

No appeals or areas of conflict or discontent have been identified.

  (1.g) Has the Document Shepherd personally verified that the=20
        document satisfies all ID nits? (See the Internet-Drafts Checklist=
=20
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20
        not enough; this check needs to be thorough. Has the document=20
        met all formal review criteria it needs to, such as the MIB=20
        Doctor, media type and URI type reviews?=20

Version 2.12.05 of ID nits identifies no issues.

No other formal reviews outside of the AVT working group are perceived as=20
necessary for this document.

  (1.h) Has the document split its references into normative and=20
        informative? Are there normative references to documents that=20
        are not ready for advancement or are otherwise in an unclear=20
        state? If such normative references exist, what is the=20
        strategy for their completion? Are there normative references=20
        that are downward references, as described in [RFC3967]? If=20
        so, list these downward references to support the Area=20
        Director in the Last Call procedure for them [RFC3967].=20

The document does split normative and informative references. All the norma=
tive=20
references have been reviewed and are correctly allocated as normative=20
references. None of these normative references constitute a down reference.

  (1.i) Has the Document Shepherd verified that the document IANA=20
        consideration section exists and is consistent with the body=20
        of the document? If the document specifies protocol=20
        extensions, are reservations requested in appropriate IANA=20
        registries? Are the IANA registries clearly identified? If=20
        the document creates a new registry, does it define the=20
        proposed initial contents of the registry and an allocation=20
        procedure for future registrations? Does it suggest a=20
        reasonable name for the new registry? See [RFC5226]. If the=20
        document describes an Expert Review process has Shepherd=20
        conferred with the Responsible Area Director so that the IESG=20
        can appoint the needed Expert during the IESG Evaluation?=20

An IANA considerations section is included and the sole IANA registration, =
the=20
registration of a new SDP attribute, has been verified against the registra=
tion=20
requirements of RFC 4566.

  (1.j) Has the Document Shepherd verified that sections of the=20
        document that are written in a formal language, such as XML=20
        code, BNF rules, MIB definitions, etc., validate correctly in=20
        an automated checker?=20

The only formal language is contained in one line of ABNF. This has been=20
verified manually by the document shepherd.

  (1.k) The IESG approval announcement includes a Document=20
        Announcement Write-Up. Please provide such a Document=20
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval=20
        announcement contains the following sections:=20
     Technical Summary=20
        Relevant content can frequently be found in the abstract=20
        and/or introduction of the document. If not, this may be=20
        an indication that there are deficiencies in the abstract=20
        or introduction.=20
     Working Group Summary=20
        Was there anything in WG process that is worth noting? For=20
        example, was there controversy about particular points or=20
        were there decisions where the consensus was particularly=20
        rough?=20
     Document Quality=20
        Are there existing implementations of the protocol? Have a=20
        significant number of vendors indicated their plan to=20
        implement the specification? Are there any reviewers that=20
        merit special mention as having done a thorough review,=20
        e.g., one that resulted in important changes or a=20
        conclusion that the document had no substantive issues? If=20
        there was a MIB Doctor, Media Type or other expert review,=20
        what was its course (briefly)? In the case of a Media Type=20
        review, on what date was the request posted?

The Session Description Protocol (SDP) has an attribute that allows RTP=20
applications to specify an address and a port associated with the RTP=20
Control Protocol (RTCP) traffic.  In RTP-based source-specific=20
multicast (SSM) sessions, the same attribute is used to designate the=20
address and the RTCP port of the Feedback Target in the SDP description. =20
However, the RTCP port associated with the SSM session itself cannot be=20
specified by the same attribute to avoid ambiguity, and thus, is=20
required to be derived from the "m=3D" line of the media description. =20
Deriving the RTCP port from the "m=3D" line imposes an unnecessary=20
restriction.  This document removes this restriction by introducing a=20
new SDP attribute.

The document achieved consensus in the AVT working group.

From wwwrun@core3.amsl.com  Wed Oct 27 09:37:30 2010
Return-Path: 
X-Original-To: avt@ietf.org
Delivered-To: avt@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 02BA03A6A1B; Wed, 27 Oct 2010 09:35:49 -0700 (PDT)
To: tom.kristensen@tandberg.com, yekuiwang@huawei.com, ron.even.tlv@gmail.com, rjesup@wgate.com
From: IETF Secretariat 
Message-Id: <20101027163636.02BA03A6A1B@core3.amsl.com>
Date: Wed, 27 Oct 2010 09:35:50 -0700 (PDT)
X-Mailman-Approved-At: Thu, 28 Oct 2010 08:05:51 -0700
Cc: keith.drage@alcatel-lucent.com, housley@vigilsec.com, gonzalo.camarillo@ericsson.com, avt@ietf.org, ipr-announce@ietf.org
Subject: [AVT] IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-avt-rtp-rfc3984bis-12
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Oct 2010 16:37:35 -0000

Dear Tom Kristensen, Ye-Kui Wang, Roni Even, Randell Jesup:

An IPR disclosure that pertains to your Internet-Draft entitled "RTP Payload
Format for H.264 Video" (draft-ietf-avt-rtp-rfc3984bis) was submitted to the
IETF Secretariat on 2010-10-27 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/1431/). The title of the IPR disclosure is
"Nokia Corporation's Statement about IPR related to
draft-ietf-avt-rtp-rfc3984bis-12."

The IETF Secretariat



From stewe@stewe.org  Fri Oct 29 09:56:40 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F403A6800; Fri, 29 Oct 2010 09:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjEe6honV-nv; Fri, 29 Oct 2010 09:56:39 -0700 (PDT)
Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 085EB3A67F3; Fri, 29 Oct 2010 09:56:36 -0700 (PDT)
Received: from [192.168.1.108] (unverified [24.5.132.232])  by stewe.org (SurgeMail 3.9e) with ESMTP id 8650-1743317  for multiple; Fri, 29 Oct 2010 18:57:41 +0200
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Fri, 29 Oct 2010 09:57:34 -0700
From: Stephan Wenger 
To: , , , , 
Message-ID: 
Thread-Topic: MPEG liaison statements received
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3371191060_918748"
X-Originating-IP: 24.5.132.232
X-Authenticated-User: stewe@stewe.org 
X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net
Cc: ietfdbh@comcast.net, lars.eggert@nokia.com
Subject: [AVT] MPEG liaison statements received
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 16:56:40 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3371191060_918748
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi all,

The IETF has received from MPEG two liaison statements for our information.
No actions from the IETF side are requested or required.  Both statements
will appear shortly on the IETF's liaison website
https://datatracker.ietf.org/liaison/

n11632 informs us that their http streaming project has reached the
Committee Draft" (CD) approval level.

n11633 informs us that the joint IPTV project with the ITU Q13/16 has also
reached CD level.  Some of you may remember those assorted IPTV workshops of
the ITU and MPEG in 2008 and 2009; this is the outcome of the project
started back then.  In contrast to n11632, n11633 contains the CD text of
four future standards in winword format.

For those unaware of ISO's approval process, a CD is the first step in a
five (?) step approval process that ultimately ends in an International
Standard (IS).  At CD level, the key architectural design decisions are
frozen, but other technical input is still possible.  In IETF terms, it's
probably a maturity level that a WG I-D has after a couple of iterations.

Regards,
Stephan




--B_3371191060_918748
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable


Hi all,

=

The IETF has received from MPEG two liaison statements for our informat=
ion.  No actions from the IETF side are requested or required.  Bo=
th statements will appear shortly on the IETF's liaison website https://datatracker.ietf.org/liaison=
/

n11632 informs us that their http streaming p=
roject has reached the Committee Draft" (CD) approval level.  

n11633 informs us that the joint IPTV project with the ITU =
Q13/16 has also reached CD level.  Some of you may remember those assor=
ted IPTV workshops of the ITU and MPEG in 2008 and 2009; this is the outcome=
 of the project started back then.  In contrast to n11632, n11633 conta=
ins the CD text of four future standards in winword format.

For those unaware of ISO's approval process, a CD is the first step=
 in a five (?) step approval process that ultimately ends in an Internationa=
l Standard (IS).  At CD level, the key architectural design decisions a=
re frozen, but other technical input is still possible.  In IETF terms,=
 it's probably a maturity level that a WG I-D has after a couple of iteratio=
ns.

Regards,
Stephan

=


--B_3371191060_918748--



From garysull@microsoft.com  Fri Oct 29 11:29:43 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39183A6A0B; Fri, 29 Oct 2010 11:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucixFFz1csFp; Fri, 29 Oct 2010 11:29:38 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 05C773A69EF; Fri, 29 Oct 2010 11:29:37 -0700 (PDT)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Oct 2010 11:31:33 -0700
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.255.3; Fri, 29 Oct 2010 11:31:32 -0700
Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.101]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Fri, 29 Oct 2010 11:31:32 -0700
From: Gary Sullivan 
To: Stephan Wenger , "rai@ietf.org" , "fecframe@ietf.org" , "rmt@ietf.org" ,  "avt@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: MPEG liaison statements received
Thread-Index: AQHLd4qzxj2f9Vklnk2szPXEGRJnDpNYOMlA
Date: Fri, 29 Oct 2010 18:31:31 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_A7561C1FA8E37045B3D795A072417429B656TK5EX14MBXW652wingr_"
MIME-Version: 1.0
Cc: "ietfdbh@comcast.net" , "lars.eggert@nokia.com" 
Subject: Re: [AVT] MPEG liaison statements received
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 18:29:43 -0000

--_000_A7561C1FA8E37045B3D795A072417429B656TK5EX14MBXW652wingr_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI (responding to the comment about the approval process steps):  If you c=
ount producing a CD ballot text as being the first step, I would say that t=
here are basically three main steps in the current ISO/IEC approval process=
 - where the other two are the production of DIS and FDIS. (For those who m=
ay have been familiar with the way things were a couple years ago, the DIS =
stage was previously called an FCD.) After an FDIS is produced, there are n=
o changes (other than such things as typo fixes or rephrasing a garbled sen=
tence or two) - except, of course, by issuing subsequent amendments and cor=
rigenda. There is a ballot of an FDIS before it is considered a fully-appro=
ved standard, but the only outcome of that ballot is "Yes" or "No", not "Le=
t's change section 7" - and I have personally never witnessed a "No" outcom=
e on such a ballot. So, for practical purposes, an FDIS is the final standa=
rd.

The time between issuing a CD and issuing an FDIS takes a minimum of about =
9 months, but would more typically take about one year (or longer).

Best regards,

Gary Sullivan

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Steph=
an Wenger
Sent: Friday, October 29, 2010 09:58 AM
To: rai@ietf.org; fecframe@ietf.org; rmt@ietf.org; avt@ietf.org; mmusic@iet=
f.org
Cc: ietfdbh@comcast.net; lars.eggert@nokia.com
Subject: [AVT] MPEG liaison statements received

Hi all,

The IETF has received from MPEG two liaison statements for our information.=
  No actions from the IETF side are requested or required.  Both statements=
 will appear shortly on the IETF's liaison website https://datatracker.ietf=
.org/liaison/

n11632 informs us that their http streaming project has reached the Committ=
ee Draft" (CD) approval level.

n11633 informs us that the joint IPTV project with the ITU Q13/16 has also =
reached CD level.  Some of you may remember those assorted IPTV workshops o=
f the ITU and MPEG in 2008 and 2009; this is the outcome of the project sta=
rted back then.  In contrast to n11632, n11633 contains the CD text of four=
 future standards in winword format.

For those unaware of ISO's approval process, a CD is the first step in a fi=
ve (?) step approval process that ultimately ends in an International Stand=
ard (IS).  At CD level, the key architectural design decisions are frozen, =
but other technical input is still possible.  In IETF terms, it's probably =
a maturity level that a WG I-D has after a couple of iterations.

Regards,
Stephan


--_000_A7561C1FA8E37045B3D795A072417429B656TK5EX14MBXW652wingr_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















FYI (responding to the comment about the approval process st=
eps): 
If you count producing a CD ballot text as being the first step, I would sa=
y
that there are basically three main steps in the current ISO/IEC approval
process – where the other two are the production of DIS and FDIS. (Fo=
r
those who may have been familiar with the way things were a couple years ag=
o,
the DIS stage was previously called an FCD.) After an FDIS is produced, the=
re
are no changes (other than such things as typo fixes or rephrasing a garble=
d
sentence or two) – except, of course, by issuing subsequent amendment=
s
and corrigenda. There is a ballot of an FDIS before it is considered a full=
y-approved
standard, but the only outcome of that ballot is "Yes" or "N=
o",
not "Let's change section 7" – and I have personally never =
witnessed
a "No" outcome on such a ballot. So, for practical purposes, an F=
DIS
is the final standard.



 



The time between issuing a CD and issuing an FDIS takes a
minimum of about 9 months, but would more typically take about one year (or=
 longer).



 



Best regards,



 



Gary Sullivan



 









From:
avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Step=
han
Wenger

Sent: Friday, October 29, 2010 09:58 AM

To: rai@ietf.org; fecframe@ietf.org; rmt@ietf.org; avt@ietf.org;
mmusic@ietf.org

Cc: ietfdbh@comcast.net; lars.eggert@nokia.com

Subject: [AVT] MPEG liaison statements received








 






Hi all,









 









The IETF has received from MPEG two liaison statements for our
information.  No actions from the IETF side are requested or required.
 Both statements will appear shortly on the IETF's liaison website&nbs=
p;https://datatracker.ietf.org/=
liaison/









 









n11632 informs us that their http streaming project has reache=
d
the Committee Draft" (CD) approval level.  









 









n11633 informs us that the joint IPTV project with the ITU Q13=
/16
has also reached CD level.  Some of you may remember those assorted IP=
TV
workshops of the ITU and MPEG in 2008 and 2009; this is the outcome of the
project started back then.  In contrast to n11632, n11633 contains the=
 CD
text of four future standards in winword format.









 









For those unaware of ISO's approval process, a CD is the first
step in a five (?) step approval process that ultimately ends in an
International Standard (IS).  At CD level, the key architectural desig=
n
decisions are frozen, but other technical input is still possible.  In
IETF terms, it's probably a maturity level that a WG I-D has after a couple=
 of
iterations.









 









Regards,









Stephan









 












--_000_A7561C1FA8E37045B3D795A072417429B656TK5EX14MBXW652wingr_--

From xielei57471@huawei.com  Sat Oct 30 03:03:59 2010
Return-Path: 
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59C93A67B2 for ; Sat, 30 Oct 2010 03:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.976
X-Spam-Level: ****
X-Spam-Status: No, score=4.976 tagged_above=-999 required=5 tests=[AWL=0.798,  BAYES_00=-2.599, FAKE_REPLY_C=2.012, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_74=0.6, MY_CID_AND_ARIAL2=1.46, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKiYITPmMesA for ; Sat, 30 Oct 2010 03:03:58 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0EEDD3A6407 for ; Sat, 30 Oct 2010 03:03:58 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB300BCXLDJFS@szxga03-in.huawei.com> for avt@ietf.org; Sat, 30 Oct 2010 18:05:44 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB300EZ2LDJK5@szxga03-in.huawei.com> for avt@ietf.org; Sat, 30 Oct 2010 18:05:43 +0800 (CST)
Received: from x57471 ([10.111.16.95]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LB300H7QLDJG9@szxml04-in.huawei.com> for avt@ietf.org; Sat, 30 Oct 2010 18:05:43 +0800 (CST)
Date: Sat, 30 Oct 2010 18:05:43 +0800
From: Xie Lei 
To: avt@ietf.org
Message-id: <006001cb781a$043b9e90$5f106f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: multipart/alternative; boundary="Boundary_(ID_V84BVtk5LjyCmM4NocVSkQ)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: Re: [AVT] The interworking issue for RTP Payload Format for AMR
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Oct 2010 10:04:00 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_V84BVtk5LjyCmM4NocVSkQ)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT

Hi
Are there any comments for this interworking issue? I hope any RFC4867 experts could give me some suggestions. Thanks. 

BR
Rock




  ----- Original Message ----- 
  From: Xie Lei 
  To: Roni Even ; avt@ietf.org 
  Sent: Tuesday, October 26, 2010 2:04 PM
  Subject: Re: [AVT]The interworking issue for RTP Payload Format for AMR


  Hi
  Yes, the TRAU can only take either CMR or CMI, and in GSM network, TRAU frame sequence must strictly be one CMR frame following with one CMI frame , however, RFC4867 allows take both CMR and CMI one packet and there is no indication to indentify the packet is CMR frame or not, that makes the problem.

  BR
  Rock
    ----- Original Message ----- 
    From: Roni Even 
    To: avt@ietf.org 
    Cc: 'Xie Lei' 
    Sent: Tuesday, October 26, 2010 1:12 PM
    Subject: FW: [AVT]The interworking issue for RTP Payload Format for AMR


    Hi,

    I assume that the problem is because in TRAU you can send either CMR or CMI while RFC4867 allows both in the same packet. Is this correct?

    Roni Even

     

    From: Xie Lei [mailto:xielei57471@huawei.com] 
    Sent: Monday, October 25, 2010 9:14 AM
    To: avt@ietf.org
    Cc: keith.drage@alcatel-lucent.com; 'Roni Even'
    Subject: [AVT]The interworking issue for RTP Payload Format for AMR

     

    Hello All

    I work on one interworking task between AMR RTP Payload and TRAU frame in TDM network, and find it is very difficult to map the Codec_Mode_Request(CMR) value in RTP to Request or Indication Flag (RIF) in TRAU frame which is defined in 3GPP 48.060/48.061. 

    As defined in RFC4867, RTP frame can take CMR and CMI(FT field) both in payload and the codec mode change period could be 20ms. However,TRAU speech frame can only take one of CMR or CMI, and the RIF should follow rigorous mode change peroid, that means, TRAU speech frame could only take CMR every 40ms and between each CMR frame, the TRAU speech frame must be CMI frame. 

    The issue happens when two consequent RTP payload takeing valide CMR value in each payload, at this scenario, we do not know how to set the RIF value. For instance, the first RTP payload takes CMR=4, and we map this CMR value to RIF flag to indicate the TRAU speech frame is for CMR, and the second RTP payload comes with CMR=1, then we really do not know how to do now. according to the RTP payload CMR valude, we should indicate RIF as CMR. However, according to the TRAU frame definition, the RIF must be CMI which following with last CMR frame.

    RFC4867 has some decription on reqirements for encoder in GSM. However, it is not enough, i think there needs some description on how to map CMR and CMI value in RTP frame to RIF defined TRAU when interworking between IP and TDM network. currentlly , we can not find such mapping table in any specification. We hope avt groud could work on this and resolve this issue.

     

    Best Regards

    Rock

     



--Boundary_(ID_V84BVtk5LjyCmM4NocVSkQ)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: base64

77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4
bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1
cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4ID0gDQoidXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnAgPSANCiJ1cm46c2NoZW1hcy1t
aWNyb3NvZnQtY29tOm9mZmljZTpwb3dlcnBvaW50IiB4bWxuczphID0gDQoidXJuOnNjaGVtYXMt
bWljcm9zb2Z0LWNvbTpvZmZpY2U6YWNjZXNzIiB4bWxuczpkdCA9IA0KInV1aWQ6QzJGNDEwMTAt
NjVCMy0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczpzID0gDQoidXVpZDpCREM2RTNGMC02
REEzLTExZDEtQTJBMy0wMEFBMDBDMTQ4ODIiIHhtbG5zOnJzID0gDQoidXJuOnNjaGVtYXMtbWlj
cm9zb2Z0LWNvbTpyb3dzZXQiIHhtbG5zOnogPSAiI1Jvd3NldFNjaGVtYSIgeG1sbnM6YiA9IA0K
InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnB1Ymxpc2hlciIgeG1sbnM6c3MgPSAN
CiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJlYWRzaGVldCIgeG1sbnM6YyA9
IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmNvbXBvbmVudDpzcHJlYWRzaGVl
dCIgeG1sbnM6b2RjID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2RjIiB4
bWxuczpvYSA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2YXRpb24i
IHhtbG5zOmh0bWwgPSANCiJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxuczpx
ID0gDQoiaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOnJ0
YyA9IA0KImh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIFhNTE5T
OkQgPSAiREFWOiIgWE1MTlM6UmVwbCA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20v
cmVwbC8iIHhtbG5zOm10ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBv
aW50L3NvYXAvbWVldGluZ3MvIiB4bWxuczp4MiA9IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29m
dC5jb20vb2ZmaWNlL2V4Y2VsLzIwMDMveG1sIiB4bWxuczpwcGRhID0gDQoiaHR0cDovL3d3dy5w
YXNzcG9ydC5jb20vTmFtZVNwYWNlLnhzZCIgeG1sbnM6b2lzID0gDQoiaHR0cDovL3NjaGVtYXMu
bWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvb2lzLyIgeG1sbnM6ZGlyID0gDQoiaHR0cDov
L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvZGlyZWN0b3J5LyIgeG1sbnM6
ZHMgPSANCiJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiB4bWxuczpkc3AgPSAN
CiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvZHNwIiB4bWxuczp1ZGMg
PSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjIiB4bWxuczp4c2QgPSAN
CiJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViID0gDQoiaHR0cDov
L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvMjAwMi8xL2FsZXJ0cy8iIHht
bG5zOmVjID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjIiB4bWxuczpzcCA9
IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcyA9
IA0KImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIgeG1sbnM6
eHNpID0gDQoiaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5z
OnVkY3MgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHht
bG5zOnVkY3hmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy94bWxm
aWxlIiB4bWxuczp1ZGNwMnAgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEv
dWRjL3BhcnR0b3BhcnQiIHhtbG5zOndmID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv
bS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cvIiB4bWxuczpkc3NzID0gDQoiaHR0cDovL3NjaGVt
YXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNi9kaWdzaWctc2V0dXAiIHhtbG5zOmRzc2kgPSAN
CiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2RpZ3NpZyIgeG1sbnM6
bWRzc2kgPSANCiJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvcGFja2FnZS8yMDA2
L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyID0gDQoiaHR0cDovL3NjaGVtYXMub3Blbnht
bGZvcm1hdHMub3JnL21hcmt1cC1jb21wYXRpYmlsaXR5LzIwMDYiIHhtbG5zOm0gPSANCiJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm1yZWxz
ID0gDQoiaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAwNi9yZWxh
dGlvbnNoaXBzIiB4bWxuczpzcHdwID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC93ZWJwYXJ0cGFnZXMiIHhtbG5zOmV4MTJ0ID0gDQoiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0
LmNvbS9leGNoYW5nZS9zZXJ2aWNlcy8yMDA2L3R5cGVzIiB4bWxuczpleDEybSA9IA0KImh0dHA6
Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIg
eG1sbnM6cHB0c2wgPSANCiJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQv
c29hcC9TbGlkZUxpYnJhcnkvIiB4bWxuczpzcHNsID0gDQoiaHR0cDovL21pY3Jvc29mdC5jb20v
d2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRhbFNlcnZlci9QdWJsaXNoZWRMaW5rc1NlcnZpY2Ui
IA0KWE1MTlM6WiA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3QgPSAiASI+
PEhFQUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7
IGNoYXJzZXQ9dXRmLTgiPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC4zNjk4IiBu
YW1lPUdFTkVSQVRPUj48IS0tW2lmICFtc29dPg0KPFNUWUxFPnZcOiogew0KCUJFSEFWSU9SOiB1
cmwoI2RlZmF1bHQjVk1MKQ0KfQ0Kb1w6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwp
DQp9DQp3XDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0NCi5zaGFwZSB7DQoJ
QkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQo8L1NUWUxFPg0KPCFbZW5kaWZdLS0+DQo8
U1RZTEU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx
IDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFu
b3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJB
cmlhbCBVbmljb2RlIE1TIjsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx
MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4i
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAQXJpYWwgVW5pY29kZSBNUyI7DQoJcGFu
b3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi
XEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTrlrovkvZM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrljY7m
lofnu4bpu5E7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1z
b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz
aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp
Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy
aWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp
emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt
YXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh
Z2U6V29yZFNlY3Rpb24xO30NCi0tPg0KPC9TVFlMRT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjciIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2
OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpz
aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L0hFQUQ+DQo8Qk9EWSBsYW5nPUVOLVVTIHZM
aW5rPXB1cnBsZSBsaW5rPWJsdWUgYmdDb2xvcj13aGl0ZT4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh
bCBzaXplPTI+SGk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFy
ZSB0aGVyZSBhbnkgY29tbWVudHMgZm9yIHRoaXMgaW50ZXJ3b3JraW5nIGlzc3VlPyANCkkgaG9w
ZSBhbnkgUkZDNDg2NyBleHBlcnRzIGNvdWxkIGdpdmUgbWUgc29tZSBzdWdnZXN0aW9ucy4gVGhh
bmtzLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4m
bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QlI8L0ZPTlQ+PC9ESVY+
DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlJvY2s8L0ZPTlQ+PC9ESVY+DQo8RElWPg0K
PFA+PC9QPg0KPFA+PC9QPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Z3JheSBzaXplPTE+PEJSPjwv
Rk9OVD48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1SSUdIVDog
MHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMw
MDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6
IDlwdCDlrovkvZMiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYg
c3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlwdCDlrovkvZM7IGZvbnQtY29sb3I6
IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPXhpZWxlaTU3NDcxQGh1YXdlaS5jb20g
aHJlZj0ibWFpbHRvOnhpZWxlaTU3NDcxQGh1YXdlaS5jb20iPlhpZSANCiAgTGVpPC9BPiA8L0RJ
Vj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+VG86PC9CPiA8QSB0aXRsZT1F
dmVuLnJvbmlAaHVhd2VpLmNvbSANCiAgaHJlZj0ibWFpbHRvOkV2ZW4ucm9uaUBodWF3ZWkuY29t
Ij5Sb25pIEV2ZW48L0E+IDsgPEEgdGl0bGU9YXZ0QGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86
YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05U
OiA5cHQg5a6L5L2TIj48Qj5TZW50OjwvQj4gVHVlc2RheSwgT2N0b2JlciAyNiwgMjAxMCAyOjA0
IFBNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlN1YmplY3Q6PC9C
PiBSZTogW0FWVF1UaGUgaW50ZXJ3b3JraW5nIGlzc3VlIGZvciANCiAgUlRQIFBheWxvYWQgRm9y
bWF0IGZvciBBTVI8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1B
cmlhbCBzaXplPTI+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SGk8L0ZPTlQ+PC9E
SVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+WWVzLCB0aGUgVFJBVSBjYW4gb25s
eSB0YWtlIGVpdGhlciBDTVIgb3IgQ01JLCANCiAgYW5kIGluIEdTTSBuZXR3b3JrLCBUUkFVIGZy
YW1lIHNlcXVlbmNlIG11c3Qgc3RyaWN0bHkgYmUgb25lIENNUiBmcmFtZSANCiAgZm9sbG93aW5n
IHdpdGggb25lIENNSSBmcmFtZSAsIGhvd2V2ZXIsIFJGQzQ4NjcgYWxsb3dzIHRha2UgYm90aCBD
TVIgYW5kIENNSSANCiAgb25lIHBhY2tldCBhbmQgdGhlcmUgaXMgbm8gaW5kaWNhdGlvbiB0byBp
bmRlbnRpZnkmbmJzcDt0aGUgcGFja2V0IGlzJm5ic3A7Q01SIA0KICBmcmFtZSBvciBub3QsIHRo
YXQgbWFrZXMmbmJzcDt0aGUgcHJvYmxlbS48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFj
ZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJp
YWwgc2l6ZT0yPkJSPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y
PlJvY2s8L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRElWPg0KICA8QkxPQ0tRVU9URSBkaXI9bHRyIA0K
ICBzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxF
RlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBw
eCI+DQogICAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+LS0tLS0gT3JpZ2luYWwgTWVz
c2FnZSAtLS0tLSA8L0RJVj4NCiAgICA8RElWIA0KICAgIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRl
NGU0OyBGT05UOiA5cHQg5a6L5L2TOyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IDxB
IA0KICAgIHRpdGxlPUV2ZW4ucm9uaUBodWF3ZWkuY29tIGhyZWY9Im1haWx0bzpFdmVuLnJvbmlA
aHVhd2VpLmNvbSI+Um9uaSBFdmVuPC9BPiANCiAgICA8L0RJVj4NCiAgICA8RElWIHN0eWxlPSJG
T05UOiA5cHQg5a6L5L2TIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPWF2dEBpZXRmLm9yZyANCiAgICBo
cmVmPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICAgIDxE
SVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPkNjOjwvQj4gPEEgdGl0bGU9eGllbGVpNTc0
NzFAaHVhd2VpLmNvbSANCiAgICBocmVmPSJtYWlsdG86eGllbGVpNTc0NzFAaHVhd2VpLmNvbSI+
J1hpZSBMZWknPC9BPiA8L0RJVj4NCiAgICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48
Qj5TZW50OjwvQj4gVHVlc2RheSwgT2N0b2JlciAyNiwgMjAxMCAxOjEyIA0KICAgIFBNPC9ESVY+
DQogICAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+U3ViamVjdDo8L0I+IEZXOiBb
QVZUXVRoZSBpbnRlcndvcmtpbmcgaXNzdWUgDQogICAgZm9yIFJUUCBQYXlsb2FkIEZvcm1hdCBm
b3IgQU1SPC9ESVY+DQogICAgPERJVj48QlI+PC9ESVY+DQogICAgPERJViBjbGFzcz1Xb3JkU2Vj
dGlvbjE+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJ
WkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNl
cmlmJyI+SGksPG86cD48L286cD48L1NQQU4+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48
U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1G
QU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPkkgDQogICAgYXNzdW1lIHRoYXQgdGhlIHBy
b2JsZW0gaXMgYmVjYXVzZSBpbiBUUkFVIHlvdSBjYW4gc2VuZCBlaXRoZXIgQ01SIG9yIENNSSAN
CiAgICB3aGlsZSBSRkM0ODY3IGFsbG93cyBib3RoIGluIHRoZSBzYW1lIHBhY2tldC4gSXMgdGhp
cyANCiAgICBjb3JyZWN0PzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29O
b3JtYWw+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6ICMxZjQ5N2Q7
IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj5Sb25pIA0KICAgIEV2ZW48bzpw
PjwvbzpwPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0
eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGli
cmknLCdzYW5zLXNlcmlmJyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICAgIDxESVY+
DQogICAgPERJViANCiAgICBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElO
Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgUEFERElORy1MRUZU
OiAwaW47IFBBRERJTkctQk9UVE9NOiAwaW47IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFE
RElORy1UT1A6IDNwdDsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgIDxQIGNsYXNz
PU1zb05vcm1hbD48Qj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB
TUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnIj5Gcm9tOjwvU1BBTj48L0I+PFNQQU4gDQogICAg
c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlm
JyI+IFhpZSBMZWkgDQogICAgW21haWx0bzp4aWVsZWk1NzQ3MUBodWF3ZWkuY29tXSA8QlI+PEI+
U2VudDo8L0I+IE1vbmRheSwgT2N0b2JlciAyNSwgMjAxMCANCiAgICA5OjE0IEFNPEJSPjxCPlRv
OjwvQj4gPEEgDQogICAgaHJlZj0ibWFpbHRvOmF2dEBpZXRmLm9yZyI+YXZ0QGlldGYub3JnPC9B
PjxCUj48Qj5DYzo8L0I+IDxBIA0KICAgIGhyZWY9Im1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVs
LWx1Y2VudC5jb20iPmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbTwvQT47IA0KICAgICdS
b25pIEV2ZW4nPEJSPjxCPlN1YmplY3Q6PC9CPiBbQVZUXVRoZSBpbnRlcndvcmtpbmcgaXNzdWUg
Zm9yIFJUUCBQYXlsb2FkIA0KICAgIEZvcm1hdCBmb3IgQU1SPG86cD48L286cD48L1NQQU4+PC9Q
PjwvRElWPjwvRElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv
UD4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgICBzdHlsZT0i
Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPkhlbGxv
IA0KICAgIEFsbDwvU1BBTj48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQ
IGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U
LUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPkkmbmJzcDt3b3JrIG9uIA0KICAgIG9uZSBp
bnRlcndvcmtpbmcgdGFzayBiZXR3ZWVuIEFNUiBSVFAgUGF5bG9hZCBhbmQgPC9TUEFOPjxTUEFO
IGxhbmc9RlIgDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdBcmlh
bCcsJ3NhbnMtc2VyaWYnIj5UUkFVIGZyYW1lIGluIFRETSANCiAgICBuZXR3b3JrLCBhbmQgZmlu
ZCBpdCBpcyB2ZXJ5IGRpZmZpY3VsdCB0byBtYXAgdGhlIDwvU1BBTj48U1BBTiBsYW5nPUZSIA0K
ICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICdB
cmlhbCcsJ3NhbnMtc2VyaWYnIj5Db2RlY19Nb2RlX1JlcXVlc3QoQ01SKSANCiAgICB2YWx1ZSBp
biBSVFAgdG8gPC9TUEFOPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S
OiBibGFjazsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5SZXF1ZXN0PC9TUEFO
PjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiByZWQ7IEZPTlQtRkFN
SUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+IA0KICAgIDwvU1BBTj48U1BBTiANCiAgICBzdHls
ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdz
YW5zLXNlcmlmJyI+b3IgDQogICAgSW5kaWNhdGlvbiBGbGFnPC9TUEFOPjxTUEFOIA0KICAgIHN0
eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiByZWQ7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdz
YW5zLXNlcmlmJyI+IA0KICAgIDwvU1BBTj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAx
MHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+KFJJ
RikgDQogICAgaW4gVFJBVSBmcmFtZSB3aGljaCBpcyBkZWZpbmVkIGluPC9TUEFOPjxTUEFOIA0K
ICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwLjVwdDsgQ09MT1I6IGJsYWNrIj4gPC9TUEFOPjxTUEFO
IA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6
ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj4zR1BQIA0KICAgIDQ4LjA2MC80OC4wNjEuIDwvU1BBTj48
bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48
U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFN
SUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+QXMgDQogICAgZGVmaW5lZCBpbiBSRkM0ODY3LCBS
VFAgZnJhbWUgY2FuIHRha2UgQ01SIGFuZCBDTUkoRlQgZmllbGQpIGJvdGggaW4gcGF5bG9hZCAN
CiAgICBhbmQgdGhlIGNvZGVjIG1vZGUgY2hhbmdlIHBlcmlvZCZuYnNwO2NvdWxkIGJlJm5ic3A7
MjBtcy4gDQogICAgSG93ZXZlciw8L1NQQU4+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjayI+VFJB
VSBzcGVlY2ggZnJhbWUgY2FuIG9ubHkgdGFrZSANCiAgICBvbmUgb2YgQ01SIG9yIENNSSwgYW5k
IHRoZSBSSUYgPC9TUEFOPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S
OiBibGFjazsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5zaG91bGQgDQogICAg
Zm9sbG93Jm5ic3A7cmlnb3JvdXMgbW9kZSBjaGFuZ2UgcGVyb2lkLCB0aGF0IG1lYW5zLCA8L1NQ
QU4+PFNQQU4gDQogICAgc3R5bGU9IkNPTE9SOiBibGFjayI+VFJBVSBzcGVlY2ggZnJhbWU8L1NQ
QU4+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05U
LUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPiANCiAgICBjb3VsZCBvbmx5IHRha2UgQ01S
IGV2ZXJ5IDQwbXMgYW5kIGJldHdlZW4gZWFjaCBDTVIgZnJhbWUsIHRoZSA8L1NQQU4+PFNQQU4g
DQogICAgc3R5bGU9IkNPTE9SOiBibGFjayI+VFJBVSBzcGVlY2ggZnJhbWUmbmJzcDs8L1NQQU4+
PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZB
TUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPm11c3QgDQogICAgYmUgQ01JIGZyYW1lLiA8L1NQ
QU4+PG86cD48L286cD48L1A+PC9ESVY+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3Jt
YWw+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05U
LUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPlRoZSZuYnNwO2lzc3VlIA0KICAgIGhhcHBl
bnMgd2hlbiB0d28gY29uc2VxdWVudCBSVFAmbmJzcDtwYXlsb2FkIHRha2VpbmcgdmFsaWRlIENN
UiB2YWx1ZSBpbiANCiAgICBlYWNoIHBheWxvYWQsIGF0IHRoaXMgc2NlbmFyaW8sIHdlIGRvIG5v
dCBrbm93IGhvdyB0byBzZXQgdGhlIFJJRiB2YWx1ZS4gRm9yIA0KICAgIGluc3RhbmNlLCB0aGUg
Zmlyc3QgUlRQIHBheWxvYWQgdGFrZXMgQ01SPTQsIGFuZCB3ZSBtYXAgdGhpcyBDTVIgdmFsdWUg
dG8gDQogICAgUklGIGZsYWcgdG8gaW5kaWNhdGUgdGhlIDwvU1BBTj48U1BBTiBzdHlsZT0iQ09M
T1I6IGJsYWNrIj5UUkFVIHNwZWVjaCANCiAgICBmcmFtZTwvU1BBTj48U1BBTiANCiAgICBzdHls
ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdz
YW5zLXNlcmlmJyI+IA0KICAgIDwvU1BBTj48U1BBTiBzdHlsZT0iQ09MT1I6IGJsYWNrIj5pcyBm
b3IgQ01SLCBhbmQgdGhlIHNlY29uZCBSVFAgcGF5bG9hZCANCiAgICBjb21lcyB3aXRoIENNUj0x
LCB0aGVuIHdlIHJlYWxseSBkbyBub3Qga25vdyBob3cgdG8gZG8gbm93LiBhY2NvcmRpbmcgdG8g
dGhlIA0KICAgIFJUUCBwYXlsb2FkIENNUiB2YWx1ZGUsIHdlIHNob3VsZCBpbmRpY2F0ZSBSSUYg
YXMgQ01SLiBIb3dldmVyLCBhY2NvcmRpbmcgdG8gDQogICAgdGhlIFRSQVUgZnJhbWUgZGVmaW5p
dGlvbiwgdGhlIFJJRiZuYnNwO211c3QgYmUgQ01JIHdoaWNoJm5ic3A7Zm9sbG93aW5nIA0KICAg
IHdpdGggbGFzdCBDTVIgZnJhbWUuPC9TUEFOPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxE
SVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6
IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5S
RkM0ODY3IA0KICAgIGhhcyBzb21lIGRlY3JpcHRpb24gb24gcmVxaXJlbWVudHMgZm9yIGVuY29k
ZXIgaW4gR1NNLiBIb3dldmVyLCBpdCBpcyBub3QgDQogICAgZW5vdWdoLCZuYnNwO2kgdGhpbmsg
dGhlcmUgbmVlZHMgc29tZSBkZXNjcmlwdGlvbiBvbiZuYnNwO2hvdyB0byBtYXAgQ01SIGFuZCAN
CiAgICBDTUkgdmFsdWUgaW4gUlRQIGZyYW1lJm5ic3A7dG8gUklGJm5ic3A7ZGVmaW5lZCZuYnNw
O1RSQVUgd2hlbiBpbnRlcndvcmtpbmcgDQogICAgYmV0d2VlbiBJUCBhbmQgVERNIG5ldHdvcmsu
IGN1cnJlbnRsbHkgLCB3ZSBjYW4gbm90IGZpbmQgc3VjaCBtYXBwaW5nIHRhYmxlIA0KICAgIGlu
IGFueSBzcGVjaWZpY2F0aW9uLiBXZSBob3BlIGF2dCBncm91ZCBjb3VsZCB3b3JrIG9uIHRoaXMg
YW5kJm5ic3A7cmVzb2x2ZSANCiAgICB0aGlzIGlzc3VlLjwvU1BBTj48bzpwPjwvbzpwPjwvUD48
L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpw
PjwvUD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAg
ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiAnQXJp
YWwnLCdzYW5zLXNlcmlmJyI+QmVzdCANCiAgICBSZWdhcmRzPC9TUEFOPjxvOnA+PC9vOnA+PC9Q
PjwvRElWPg0KICAgIDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0
eWxlPSJDT0xPUjogYmxhY2siPlJvY2s8L1NQQU4+PG86cD48L286cD48L1A+PC9ESVY+DQogICAg
PERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L1A+PC9ESVY+
DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PCEtLVtpZiBndGUgdm1sIDFdPjx2
OnNoYXBldHlwZSBpZD0iX3gwMDAwX3Q3NSIgY29vcmRzaXplPSIyMTYwMCwyMTYwMCIgDQogbzpz
cHQ9Ijc1IiBvOnByZWZlcnJlbGF0aXZlPSJ0IiBwYXRoPSJtQDRANWxANEAxMUA5QDExQDlANXhl
IiBmaWxsZWQ9ImYiIA0KIHN0cm9rZWQ9ImYiPg0KIDx2OnN0cm9rZSBqb2luc3R5bGU9Im1pdGVy
IiAvPg0KIDx2OmZvcm11bGFzPg0KICA8djpmIGVxbj0iaWYgbGluZURyYXduIHBpeGVsTGluZVdp
ZHRoIDAiIC8+DQogIDx2OmYgZXFuPSJzdW0gQDAgMSAwIiAvPg0KICA8djpmIGVxbj0ic3VtIDAg
MCBAMSIgLz4NCiAgPHY6ZiBlcW49InByb2QgQDIgMSAyIiAvPg0KICA8djpmIGVxbj0icHJvZCBA
MyAyMTYwMCBwaXhlbFdpZHRoIiAvPg0KICA8djpmIGVxbj0icHJvZCBAMyAyMTYwMCBwaXhlbEhl
aWdodCIgLz4NCiAgPHY6ZiBlcW49InN1bSBAMCAwIDEiIC8+DQogIDx2OmYgZXFuPSJwcm9kIEA2
IDEgMiIgLz4NCiAgPHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxXaWR0aCIgLz4NCiAgPHY6
ZiBlcW49InN1bSBAOCAyMTYwMCAwIiAvPg0KICA8djpmIGVxbj0icHJvZCBANyAyMTYwMCBwaXhl
bEhlaWdodCIgLz4NCiAgPHY6ZiBlcW49InN1bSBAMTAgMjE2MDAgMCIgLz4NCiA8L3Y6Zm9ybXVs
YXM+DQogPHY6cGF0aCBvOmV4dHJ1c2lvbm9rPSJmIiBncmFkaWVudHNoYXBlb2s9InQiIG86Y29u
bmVjdHR5cGU9InJlY3QiIC8+DQogPG86bG9jayB2OmV4dD0iZWRpdCIgYXNwZWN0cmF0aW89InQi
IC8+DQo8L3Y6c2hhcGV0eXBlPjx2OnNoYXBlIGlkPSJyaWRJbWciIG86c3BpZD0iX3gwMDAwX3Mx
MDI2IiB0eXBlPSIjX3gwMDAwX3Q3NSIgDQogYWx0PSJodWF3ZWlfbG9nbyIgc3R5bGU9J3Bvc2l0
aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjA7bWFyZ2luLXRvcDowO3dpZHRoOjc2LjVwdDsNCiBo
ZWlnaHQ6MjRwdDt6LWluZGV4OjI1MTY1ODI0MDttc28td3JhcC1kaXN0YW5jZS1sZWZ0OjA7DQog
bXNvLXdyYXAtZGlzdGFuY2UtdG9wOjA7bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6MDttc28td3Jh
cC1kaXN0YW5jZS1ib3R0b206MDsNCiBtc28tcG9zaXRpb24taG9yaXpvbnRhbDpsZWZ0O21zby1w
b3NpdGlvbi1ob3Jpem9udGFsLXJlbGF0aXZlOnRleHQ7DQogbXNvLXBvc2l0aW9uLXZlcnRpY2Fs
LXJlbGF0aXZlOmxpbmUnIG86YWxsb3dvdmVybGFwPSJmIj4NCiA8djppbWFnZWRhdGEgc3JjPSJj
aWQ6MDBkMDAxY2I3NDE0JDM4OTcwM2EwJDVmMTA2ZjBhQGNoaW5hLmh1YXdlaS5jb20iIA0KICBv
OnRpdGxlPSIwMGQwMDFjYjc0MTQkMzg5NzAzYTAkNWYxMDZmMGFAY2hpbmEuaHVhd2VpIiAvPg0K
IDx3OndyYXAgdHlwZT0ic3F1YXJlIi8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFbaWYgIXZt
bF0+PCFbZW5kaWZdPjxGT05UIGZhY2U9QXJpYWwgDQogICAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8
L1A+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K

--Boundary_(ID_V84BVtk5LjyCmM4NocVSkQ)--