From magnus.westerlund@ericsson.com Wed Jun 1 01:09:52 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3C9E075F for ; Wed, 1 Jun 2011 01:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.28 X-Spam-Level: X-Spam-Status: No, score=-106.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueoLA+7pf4fS for ; Wed, 1 Jun 2011 01:09:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D46BAE0750 for ; Wed, 1 Jun 2011 01:09:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-be-4de5f3cc14b9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 69.AC.09774.CC3F5ED4; Wed, 1 Jun 2011 10:09:48 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 1 Jun 2011 10:09:47 +0200 Message-ID: <4DE5F3CB.80304@ericsson.com> Date: Wed, 1 Jun 2011 10:09:47 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Igoe, Kevin M." References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <4DE4AC77.9050501@ericsson.com> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B19@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B19@MSIS-GH1-UEA06.corp.nsa.gov> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 08:09:52 -0000 On 2011-05-31 14:24, Igoe, Kevin M. wrote: > Magnus: > > Thanks for your input. We'll put this under avtcore per your request. > As to allowing keying methods other than DTLS, we have no objections > (obviously) to non-Suite B implementations using them, but in an > effort to maximize interoperability betwixt Suite B SRTP implementations > policy dictates that only DTLS keying will be allowed in Suite B mode. > If another keying methods is used, it is by definition not Suite B compliant. Ok, so SuiteB also contains beyond the crypto algorithms also usage rules that affects key management. Are these rulse also forbidding use cases like Broadcast or multicast where using DTLS-SRTP is in fact impossible? > > If you think it would be helpful, we could mention the existence of the MIKEY > and Security description keying mechanisms, but only with the caveat that their > use is forbidden when running in Suite B mode. My immediate reaction is if one can define profiles that are not SuiteB but use the same encryption and authentication algorithm so they are bit compatible, but not policy compatible? Independent I think you need to make it clear in the document that SuiteB does contain these policy rules. 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 gwz@net-zen.net Wed Jun 1 03:27:03 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE8CE07B4 for ; Wed, 1 Jun 2011 03:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+vVuK6NBaGt for ; Wed, 1 Jun 2011 03:27:02 -0700 (PDT) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by ietfa.amsl.com (Postfix) with SMTP id 668A3E07AA for ; Wed, 1 Jun 2011 03:27:02 -0700 (PDT) Received: (qmail 9944 invoked from network); 1 Jun 2011 10:27:01 -0000 Received: from unknown (115.87.116.114) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 01 Jun 2011 10:27:00 -0000 Message-ID: <4DE613ED.6090503@net-zen.net> Date: Wed, 01 Jun 2011 17:26:53 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Magnus Westerlund References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <4DE4AC77.9050501@ericsson.com> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B19@MSIS-GH1-UEA06.corp.nsa.gov> <4DE5F3CB.80304@ericsson.com> In-Reply-To: <4DE5F3CB.80304@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------030608040900010409080400" Cc: "avt@ietf.org" , "Igoe, Kevin M." Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 10:27:03 -0000 This is a multi-part message in MIME format. --------------030608040900010409080400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 6/1/2011 3:09 PM, Magnus Westerlund wrote: ... > My immediate reaction is if one can define profiles that are not SuiteB > but use the same encryption and authentication algorithm so they are bit > compatible, but not policy compatible? My understanding is that Suite B is all about policy & packaging; no new algorithms are defined (thankfully!). > > Independent I think you need to make it clear in the document that > SuiteB does contain these policy rules. I don't really understand this comment: the very first sentence of the Abstract says The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. ^^^^^^ I don't know how it could be made much clearer or more obvious. ... --------------030608040900010409080400 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------030608040900010409080400-- From gwz@net-zen.net Wed Jun 1 03:56:13 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE88E0784 for ; Wed, 1 Jun 2011 03:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaUqAoUBcICc for ; Wed, 1 Jun 2011 03:56:12 -0700 (PDT) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by ietfa.amsl.com (Postfix) with SMTP id 94CA5E0703 for ; Wed, 1 Jun 2011 03:56:12 -0700 (PDT) Received: (qmail 17127 invoked from network); 1 Jun 2011 10:56:12 -0000 Received: from unknown (115.87.116.114) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 01 Jun 2011 10:56:11 -0000 Message-ID: <4DE61AC4.10009@net-zen.net> Date: Wed, 01 Jun 2011 17:56:04 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Magnus Westerlund References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <4DE4AC77.9050501@ericsson.com> In-Reply-To: <4DE4AC77.9050501@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------060101020100030403060503" Cc: "avt@ietf.org" , "kmigoe@nsa.gov" Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 10:56:13 -0000 This is a multi-part message in MIME format. --------------060101020100030403060503 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/31/2011 3:53 PM, Magnus Westerlund wrote: > Hi, > > If I understand this document correctly there are actually three pieces > to it: > > - The SuiteB Crypto algorithms for SRTP > - The SuiteB specific DTLS-SRTP procedures > - Registration of DTLS-SRTP protection profiles > > Thus in light of this document and also the ARIA SRTP registration I > think we should discuss how to handle SRTP crypto algorithms and their > connection to the keying mechanisms. > > SRTP has at least three different IETF define ways to be keyed: > - DTLS-SRTP [RFC5764] > - MIKEY [3830] > - Security Descriptions [RFC 4568] > > And to my understanding they are all used somewhere. > >>From my perspective as WG chair I wonder if shouldn't require anyone > that creates a new crypto suit for SRTP to also create the suite > profiles / identifiers for all of these three keying mechanisms? > > Opinions? I think that that is wholly unnecessary; however, if the WG wants to do so, I have no problem with doing it. ... --------------060101020100030403060503 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------060101020100030403060503-- From magnus.westerlund@ericsson.com Wed Jun 1 04:36:21 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E44E0692 for ; Wed, 1 Jun 2011 04:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50rVruuy9ZxY for ; Wed, 1 Jun 2011 04:36:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 03816E0670 for ; Wed, 1 Jun 2011 04:36:20 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-93-4de62433d95d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D9.74.20773.33426ED4; Wed, 1 Jun 2011 13:36:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 1 Jun 2011 13:32:42 +0200 Message-ID: <4DE6235A.1030703@ericsson.com> Date: Wed, 1 Jun 2011 13:32:42 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Glen Zorn References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <4DE4AC77.9050501@ericsson.com> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B19@MSIS-GH1-UEA06.corp.nsa.gov> <4DE5F3CB.80304@ericsson.com> <4DE613ED.6090503@net-zen.net> In-Reply-To: <4DE613ED.6090503@net-zen.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" , "Igoe, Kevin M." Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 11:36:22 -0000 On 2011-06-01 12:26, Glen Zorn wrote: > On 6/1/2011 3:09 PM, Magnus Westerlund wrote: > > ... > >> My immediate reaction is if one can define profiles that are not SuiteB >> but use the same encryption and authentication algorithm so they are bit >> compatible, but not policy compatible? > > My understanding is that Suite B is all about policy & packaging; no new > algorithms are defined (thankfully!). I am not certain about that. RFC 6188 appears to define the crypto part matching SuiteB requirement for SRTP, but not the authentication algorithm, thus from an SRTP perspective there appear to be new stuff in here. I am uncertain if there is differences between the PRF for the RFC 6188 and the SuiteB draft. So, this specification clearly brings new combinations of encryption and authentication and might in fact be a completely new crypto suite if the PRF is different with RFC 6188. The question I have to the WG is if it is worth handling the actual SRTP crypto transform defintion from the actual profiles and the additional requirements on key management. Thus allowing the usage of the crypto transforms themselves outside of a SuiteB context, which clearly can't be called SuiteB but which for example is AES-256 with SHA-256 in SRTP and some other key management. > >> >> Independent I think you need to make it clear in the document that >> SuiteB does contain these policy rules. > > I don't really understand this comment: the very first sentence of the > Abstract says The United States government has published guidelines for > "NSA Suite B Cryptography", which defines cryptographic algorithm policy > for national security applications. > ^^^^^^ > > I don't know how it could be made much clearer or more obvious. > > ... What I meant is the fact that SuiteB key management is not allowed to use Security Descriptions nor MIKEY per policy. The stress on the quoted sentence are "these" where "these" referring to forcing usage of DTLS. 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 mpeck@mitre.org Wed Jun 1 05:59:10 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FFAE071A for ; Wed, 1 Jun 2011 05:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHa+TNfQrxRq for ; Wed, 1 Jun 2011 05:59:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EA91E130620 for ; Wed, 1 Jun 2011 05:35:54 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3D9D621B207E; Wed, 1 Jun 2011 08:35:54 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3873721B146D; Wed, 1 Jun 2011 08:35:54 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 1 Jun 2011 08:35:54 -0400 From: "Peck, Michael A" To: Magnus Westerlund , Glen Zorn Date: Wed, 1 Jun 2011 08:35:52 -0400 Thread-Topic: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft Thread-Index: AcwgUCK2UZG3846pQQG5nP2oNcwzOAABN6Jg Message-ID: <4FD125153A070D45BC87645D3B880288025A13D4AB@IMCMBX3.MITRE.ORG> References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <4DE4AC77.9050501@ericsson.com> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B19@MSIS-GH1-UEA06.corp.nsa.gov> <4DE5F3CB.80304@ericsson.com> <4DE613ED.6090503@net-zen.net> <4DE6235A.1030703@ericsson.com> In-Reply-To: <4DE6235A.1030703@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" , "Igoe, Kevin M." Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 12:59:10 -0000 Magnus, Glen, Thanks for your comments. Replies below. >-----Original Message----- >From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >Magnus Westerlund >Sent: Wednesday, June 01, 2011 7:33 AM >To: Glen Zorn >Cc: avt@ietf.org; Igoe, Kevin M. >Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft > >On 2011-06-01 12:26, Glen Zorn wrote: >> On 6/1/2011 3:09 PM, Magnus Westerlund wrote: >> >> ... >> >>> My immediate reaction is if one can define profiles that are not SuiteB >>> but use the same encryption and authentication algorithm so they are bi= t >>> compatible, but not policy compatible? >> >> My understanding is that Suite B is all about policy & packaging; no new >> algorithms are defined (thankfully!). > >I am not certain about that. RFC 6188 appears to define the crypto part >matching SuiteB requirement for SRTP, but not the authentication >algorithm, thus from an SRTP perspective there appear to be new stuff in >here. > >I am uncertain if there is differences between the PRF for the RFC 6188 >and the SuiteB draft. > >So, this specification clearly brings new combinations of encryption and >authentication and might in fact be a completely new crypto suite if the >PRF is different with RFC 6188. > >The question I have to the WG is if it is worth handling the actual SRTP >crypto transform defintion from the actual profiles and the additional >requirements on key management. Thus allowing the usage of the crypto >transforms themselves outside of a SuiteB context, which clearly can't >be called SuiteB but which for example is AES-256 with SHA-256 in SRTP >and some other key management. The Suite B Profile does not define its own SRTP crypto suites, key derivat= ion, TLS cipher suites, or authentication mechanism but instead makes use o= f definitions in existing RFCs or other Internet-Drafts. The Suite B Profil= e describes the Suite B compliant use of all of these to promote interopera= bility. (The Suite B profiles of other protocols follow a similar pattern.= ) RFC 6188 is not used by our draft (RFC 6188 defines AES-192 and AES-256 SRT= P crypto suites using counter mode. We do not use counter mode or AES-192 = in this profile. We use AES-128 and AES-256 in GCM mode.) The Suite B Profile makes use of AES-GCM. As described in section 7 and 8 = of our draft, the SRTP crypto suites and DTLS-SRTP SRTP Protection Profiles= used by the Suite B Profile are defined in draft-ietf-avt-srtp-aes-gcm. As described in section 9 of our draft (and in draft-ietf-avt-srtp-aes-gcm)= , the AES Counter Mode based key derivation function from RFC3711 is used. > >> >>> >>> Independent I think you need to make it clear in the document that >>> SuiteB does contain these policy rules. >> >> I don't really understand this comment: the very first sentence of the >> Abstract says The United States government has published guidelines for >> "NSA Suite B Cryptography", which defines cryptographic algorithm policy >> for national security applications. >> ^^^^^^ >> >> I don't know how it could be made much clearer or more obvious. >> >> ... > >What I meant is the fact that SuiteB key management is not allowed to >use Security Descriptions nor MIKEY per policy. The stress on the quoted >sentence are "these" where "these" referring to forcing usage of DTLS. This profile specifies the use of DTLS-SRTP as the key management mechanism= . In response to Magnus's other email, I don't think that broadcast and multi= cast SRTP are forbidden, but rather are just out of scope for this document= . Thanks Mike Peck > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >Audio/Video Transport Core Maintenance >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt From gwz@net-zen.net Wed Jun 1 06:13:04 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625F5E0833 for ; Wed, 1 Jun 2011 06:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3yGa8tWaoLV for ; Wed, 1 Jun 2011 06:13:03 -0700 (PDT) Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net [173.201.192.104]) by ietfa.amsl.com (Postfix) with SMTP id 1372AE084D for ; Wed, 1 Jun 2011 06:13:03 -0700 (PDT) Received: (qmail 13444 invoked from network); 1 Jun 2011 13:13:02 -0000 Received: from unknown (115.87.116.114) by p3plsmtpa06-03.prod.phx3.secureserver.net (173.201.192.104) with ESMTP; 01 Jun 2011 13:13:02 -0000 Message-ID: <4DE63AD8.6020301@net-zen.net> Date: Wed, 01 Jun 2011 20:12:56 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Magnus Westerlund References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <4DE4AC77.9050501@ericsson.com> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B19@MSIS-GH1-UEA06.corp.nsa.gov> <4DE5F3CB.80304@ericsson.com> <4DE613ED.6090503@net-zen.net> <4DE6235A.1030703@ericsson.com> In-Reply-To: <4DE6235A.1030703@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------020807060605090800010307" Cc: "avt@ietf.org" , "Igoe, Kevin M." Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:13:04 -0000 This is a multi-part message in MIME format. --------------020807060605090800010307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 6/1/2011 6:32 PM, Magnus Westerlund wrote: > On 2011-06-01 12:26, Glen Zorn wrote: >> On 6/1/2011 3:09 PM, Magnus Westerlund wrote: >> >> ... >> >>> My immediate reaction is if one can define profiles that are not SuiteB >>> but use the same encryption and authentication algorithm so they are bit >>> compatible, but not policy compatible? >> >> My understanding is that Suite B is all about policy & packaging; no new >> algorithms are defined (thankfully!). > > I am not certain about that. RFC 6188 appears to define the crypto part > matching SuiteB requirement for SRTP, but not the authentication > algorithm, thus from an SRTP perspective there appear to be new stuff in > here. > > I am uncertain if there is differences between the PRF for the RFC 6188 > and the SuiteB draft. I think that they are the same, though the draft under discussion could use a bit more discussion a la 6188. > > So, this specification clearly brings new combinations of encryption and > authentication and might in fact be a completely new crypto suite if the > PRF is different with RFC 6188. [disclaimer: I am _not_ a cryptographer!] RFC 6188 specifies the use of AES-CM (AKA AES-CTR) with 192- and 256-bit keys for the encryption of data, but the draft in question specifies the use of AES-GCM with 128- and 256-bit keys. My understanding is that CM & GCM are significantly different; in addition, 6188 uses HMAC-SHA1 for authentication, while the use of AES-GCM obviates the need for a separate authentication function. So it appears to me that a new cryptosuite is being defined, regardless of whether or not the PRF is identical... > > The question I have to the WG is if it is worth handling the actual SRTP > crypto transform defintion from the actual profiles and the additional > requirements on key management. Thus allowing the usage of the crypto > transforms themselves outside of a SuiteB context, which clearly can't > be called SuiteB but which for example is AES-256 with SHA-256 in SRTP > and some other key management. Maybe I'm just dull, but I'm still not getting the point. It looks to me as if the authors are just stating what it will take to get an SRTP implementation approved for US government usage in certain situations. Why would you want to tell them that they can't? Further (if my presumption is correct), why is it necessary for the document to go through this WG at all, given the intended status of Informational? If avtcore wants to specify a million different ciphersuites that's fine, but what does it have to do with this draft? > >> >>> >>> Independent I think you need to make it clear in the document that >>> SuiteB does contain these policy rules. >> >> I don't really understand this comment: the very first sentence of the >> Abstract says The United States government has published guidelines for >> "NSA Suite B Cryptography", which defines cryptographic algorithm policy >> for national security applications. >> ^^^^^^ >> >> I don't know how it could be made much clearer or more obvious. >> >> ... > > What I meant is the fact that SuiteB key management is not allowed to > use Security Descriptions nor MIKEY per policy. I'm not sure that it is solely a matter of policy; does MIKEY have a profile that uses elliptic-curve cryptography? IIRC, that was intentionally omitted due to IPR concerns. Furthermore, SDP is an unauthenticated protocol. > The stress on the quoted > sentence are "these" where "these" referring to forcing usage of DTLS. > > 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 > ---------------------------------------------------------------------- > > > --------------020807060605090800010307 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------020807060605090800010307-- From magnus.westerlund@ericsson.com Wed Jun 1 06:57:37 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEB1E07FD for ; Wed, 1 Jun 2011 06:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.307 X-Spam-Level: X-Spam-Status: No, score=-106.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhZd+tWZOt+U for ; Wed, 1 Jun 2011 06:57:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 65E2BE07FE for ; Wed, 1 Jun 2011 06:57:23 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ea-4de64542e731 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A2.D1.20773.24546ED4; Wed, 1 Jun 2011 15:57:22 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 1 Jun 2011 15:57:22 +0200 Message-ID: <4DE64541.2070603@ericsson.com> Date: Wed, 1 Jun 2011 15:57:21 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Glen Zorn References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <4DE4AC77.9050501@ericsson.com> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B19@MSIS-GH1-UEA06.corp.nsa.gov> <4DE5F3CB.80304@ericsson.com> <4DE613ED.6090503@net-zen.net> <4DE6235A.1030703@ericsson.com> <4DE63AD8.6020301@net-zen.net> In-Reply-To: <4DE63AD8.6020301@net-zen.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" , "Igoe, Kevin M." Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:57:37 -0000 Glen and Kevin Please see inline. On 2011-06-01 15:12, Glen Zorn wrote: > On 6/1/2011 6:32 PM, Magnus Westerlund wrote: > >> On 2011-06-01 12:26, Glen Zorn wrote: >>> On 6/1/2011 3:09 PM, Magnus Westerlund wrote: > >> >> So, this specification clearly brings new combinations of encryption and >> authentication and might in fact be a completely new crypto suite if the >> PRF is different with RFC 6188. > > [disclaimer: I am _not_ a cryptographer!] > RFC 6188 specifies the use of AES-CM (AKA AES-CTR) with 192- and 256-bit > keys for the encryption of data, but the draft in question specifies the > use of AES-GCM with 128- and 256-bit keys. My understanding is that CM > & GCM are significantly different; in addition, 6188 uses HMAC-SHA1 for > authentication, while the use of AES-GCM obviates the need for a > separate authentication function. So it appears to me that a new > cryptosuite is being defined, regardless of whether or not the PRF is > identical... Yes, I agree with that assessment. It is a new crypto suite, I missed the CM vesus GCM difference. I am also not a cryptographer. But the procedural point here is that they SuiteB does define a not previous existing definitions of combinations of crypto operations in the SRTP context. > >> >> The question I have to the WG is if it is worth handling the actual SRTP >> crypto transform defintion from the actual profiles and the additional >> requirements on key management. Thus allowing the usage of the crypto >> transforms themselves outside of a SuiteB context, which clearly can't >> be called SuiteB but which for example is AES-256 with SHA-256 in SRTP >> and some other key management. > > Maybe I'm just dull, but I'm still not getting the point. It looks to > me as if the authors are just stating what it will take to get an SRTP > implementation approved for US government usage in certain situations. > Why would you want to tell them that they can't? Further (if my > presumption is correct), why is it necessary for the document to go > through this WG at all, given the intended status of Informational? If > avtcore wants to specify a million different ciphersuites that's fine, > but what does it have to do with this draft? Lets separate the issues here. The first one is if they need to go through the WG. I think to be strictly correct they are not required to go through the WG. The only procedural point they are strictly required to meet are the one of the DTLS protection profiles, which is specification required. So NSA could based on a NIST specification with all these details that are in the draft request IANA to register the DTLS protection profile identifiers. I do however hope they are here for getting a bit of IETF review of it and the potential benefit in visibility for the profiles by having an RFC. So assuming that they want an RFC: The draft is defining procedures for SRTP crypto transforms that doesn't exist before. If someone like to reuse those for other key management systems like Mikey or Security Descriptions they need something to reference. It would be preferable that this is published as an RFC. And maybe we should discuss intended status also. I also don't think I have said anything that they can't get it done. I have only raised a few things that I think the WG should discuss. And the reason for that is the following charter text for this WG: The AVTCORE working group will coordinate closely with the Security Area while working on maintenance and enhancements to the SRTP Profile. I would claim that new crypto suits are "enhancements" to SRTP and thus falls under the this charter item if they want to publish an RFC. There is an downside to a large amount of crypto suits as it hurts interoperability. At the same time I think we need to be very permitting against different nations desire to define how their national standards are used in SRTP. > >> >>> >>>> >>>> Independent I think you need to make it clear in the document that >>>> SuiteB does contain these policy rules. >>> >>> I don't really understand this comment: the very first sentence of the >>> Abstract says The United States government has published guidelines for >>> "NSA Suite B Cryptography", which defines cryptographic algorithm policy >>> for national security applications. >>> ^^^^^^ >>> >>> I don't know how it could be made much clearer or more obvious. >>> >>> ... >> >> What I meant is the fact that SuiteB key management is not allowed to >> use Security Descriptions nor MIKEY per policy. > > I'm not sure that it is solely a matter of policy; does MIKEY have a > profile that uses elliptic-curve cryptography? IIRC, that was > intentionally omitted due to IPR concerns. Furthermore, SDP is an > unauthenticated protocol. I fully understand that there are security concerns here also. And it depends on the whole combination in the system if it meets the security requirements one has. From that perspective I am understanding why SuiteB defines DTLS only. Please understand that the main case I try to avoid is that we get unnecessarily many crypto suit definitions when in a SuiteB and "foobar" specification both uses AES-256 CGM and SHA-256 authentication but in fact has different definitions of everything that has to do with SRTP except the underlying crypto algorithms. I rather see that foobar can reuse most aspect of it and just have its own variations for certain aspects. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Jun 1 08:23:17 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9DEE0850 for ; Wed, 1 Jun 2011 08:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.315 X-Spam-Level: X-Spam-Status: No, score=-106.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9QSZ+omv7ZA for ; Wed, 1 Jun 2011 08:23:16 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 061FAE083D for ; Wed, 1 Jun 2011 08:22:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-95-4de6593b1ada Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2F.C3.09774.B3956ED4; Wed, 1 Jun 2011 17:22:36 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Wed, 1 Jun 2011 17:22:35 +0200 Message-ID: <4DE6593B.5050005@ericsson.com> Date: Wed, 1 Jun 2011 17:22:35 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF AVTCore WG References: <4DAC4F69.1080707@ericsson.com> In-Reply-To: <4DAC4F69.1080707@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] Call for WG item on RTCP for inter-destination media synchronization X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:23:17 -0000 WG, This call ended some time ago, but I clearly dropped the ball on concluding the call. I am sorry for this. There has been 7 persons being clearly positive, 2 additional persons have commented on this in non-negative way. The shown interest is likely sufficient to get the work done, but I wished it was stronger. The WG chairs will immediately start a dialog with our AD to discuss if we should create a milestone for this or not. Thanks, Magnus WG chair On 2011-04-18 16:49, Magnus Westerlund wrote: > WG, > > At the WG meeting in Prague we had a show of hands if we should create a > WG work item for RTCP for inter-destination media synchronization. Along > the lines described by > https://datatracker.ietf.org/doc/draft-brandenburg-avtcore-rtcp-for-idms/. > > There where 5 persons in the room indicating interest. We now would like > to judge the interest on the mailing list for a new WG item. Please > indicate your support and willingness to contribute. If you think it > shouldn't be done please voice that opinion also. > > This call runs for 2 weeks until Wednesday the 4th of May. > > Regards > > Magnus Westerlund > > AVTCore chair > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From kmigoe@nsa.gov Wed Jun 1 11:58:56 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7E4E07F4 for ; Wed, 1 Jun 2011 11:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c6M48y2xKh8 for ; Wed, 1 Jun 2011 11:58:55 -0700 (PDT) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by ietfa.amsl.com (Postfix) with ESMTP id E4185E0711 for ; Wed, 1 Jun 2011 11:58:54 -0700 (PDT) Received: from MSCS-GH1-UEA01.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p51IwpKt006022; Wed, 1 Jun 2011 18:58:51 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jun 2011 14:58:51 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC208D.F21FD85C" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 1 Jun 2011 14:58:51 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B1D@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <4DE64541.2070603@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft Thread-Index: AcwgY9W5pEEFC464QUqcJzeBM2dNEwAJLMtA References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <4DE4AC77.9050501@ericsson.com> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B19@MSIS-GH1-UEA06.corp.nsa.gov> <4DE5F3CB.80304@ericsson.com> <4DE613ED.6090503@net-zen.net> <4DE6235A.1030703@ericsson.com> <4DE63AD8.6020301@net-zen.net> <4DE64541.2070603@ericsson.com> From: "Igoe, Kevin M." To: "Magnus Westerlund" , "Glen Zorn" X-OriginalArrivalTime: 01 Jun 2011 18:58:51.0506 (UTC) FILETIME=[F2555D20:01CC208D] Cc: avt@ietf.org Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 18:58:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC208D.F21FD85C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Our intent wasn't to break new ground by introducing a new primitives = (GCM) and DTLS) into SRTP, but rather to follow in the footsteps of an = existing work:=20 =20 For GCM we have: -------------------------------------------------------------------------= Network Working Group D. McGrew Internet Draft Cisco Systems, Inc. Intended Status: Informational January 26, 2011 Expires: July 30, 2011 =20 =20 AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) draft-ietf-avt-srtp-aes-gcm-01 =20 Abstract =20 This document defines how AES-GCM, AES-CCM, and other Authenticated Encryption with Associated Data (AEAD) algorithms, can be used to provide confidentiality and data authentication mechanisms in the SRTP protocol. -------------------------------------------------------------------------= (This had an earlier incarnation as draft-mcgrew-srtp-aes-gcm-01, but = this draft eventually expired.) =20 For DTLS we have: -------------------------------------------------------------------------= Internet Engineering Task Force (IETF) D. McGrew Request for Comments: 5764 Cisco Systems Category: Standards Track E. Rescorla ISSN: 2070-1721 RTFM, Inc. May 2010 =20 =20 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) =20 Abstract =20 This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. --------------------------------------------------------------------- =20 There is an existing Suite B for TLS (currently undergoing a "bis"): --------------------------------------------------------------------- Network Working Group M. Salter Request for Comments: 5430 National Security Agency Category: Informational E. Rescorla Network Resonance R. Housley Vigil Security March 2009 =20 =20 Suite B Profile for Transport Layer Security (TLS) =20 Status of This Memo =20 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. ---------------------------------------------------------------------- =20 =20 We wish only to show how to put these three documents together to get Suite B for DTLS-SRTP. =20 Do you still think we should go thru avtcore? =20 P.S. Thanks for looking at this, we've gotten next to no feedback. =20 =20 =20 =20 =20 =20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, June 01, 2011 9:57 AM > To: Glen Zorn > Cc: Igoe, Kevin M.; avt@ietf.org > Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft >=20 > Glen and Kevin >=20 > Please see inline. >=20 > On 2011-06-01 15:12, Glen Zorn wrote: > > On 6/1/2011 6:32 PM, Magnus Westerlund wrote: > > > >> On 2011-06-01 12:26, Glen Zorn wrote: > >>> On 6/1/2011 3:09 PM, Magnus Westerlund wrote: >=20 > > > >> > >> So, this specification clearly brings new combinations of = encryption > and > >> authentication and might in fact be a completely new crypto suite = if > the > >> PRF is different with RFC 6188. > > > > [disclaimer: I am _not_ a cryptographer!] > > RFC 6188 specifies the use of AES-CM (AKA AES-CTR) with 192- and = 256- > bit > > keys for the encryption of data, but the draft in question specifies > the > > use of AES-GCM with 128- and 256-bit keys. My understanding is that > CM > > & GCM are significantly different; in addition, 6188 uses HMAC-SHA1 > for > > authentication, while the use of AES-GCM obviates the need for a > > separate authentication function. So it appears to me that a new > > cryptosuite is being defined, regardless of whether or not the PRF = is > > identical... >=20 > Yes, I agree with that assessment. It is a new crypto suite, I missed > the CM vesus GCM difference. I am also not a cryptographer. >=20 > But the procedural point here is that they SuiteB does define a not > previous existing definitions of combinations of crypto operations in > the SRTP context. >=20 > > > >> > >> The question I have to the WG is if it is worth handling the actual > SRTP > >> crypto transform defintion from the actual profiles and the > additional > >> requirements on key management. Thus allowing the usage of the > crypto > >> transforms themselves outside of a SuiteB context, which clearly > can't > >> be called SuiteB but which for example is AES-256 with SHA-256 in > SRTP > >> and some other key management. > > > > Maybe I'm just dull, but I'm still not getting the point. It looks > to > > me as if the authors are just stating what it will take to get an > SRTP > > implementation approved for US government usage in certain > situations. > > Why would you want to tell them that they can't? Further (if my > > presumption is correct), why is it necessary for the document to go > > through this WG at all, given the intended status of Informational? > If > > avtcore wants to specify a million different ciphersuites that's > fine, > > but what does it have to do with this draft? >=20 > Lets separate the issues here. The first one is if they need to go > through the WG. I think to be strictly correct they are not required = to > go through the WG. The only procedural point they are strictly = required > to meet are the one of the DTLS protection profiles, which is > specification required. So NSA could based on a NIST specification = with > all these details that are in the draft request IANA to register the > DTLS protection profile identifiers. >=20 > I do however hope they are here for getting a bit of IETF review of it > and the potential benefit in visibility for the profiles by having an > RFC. So assuming that they want an RFC: >=20 > The draft is defining procedures for SRTP crypto transforms that > doesn't > exist before. If someone like to reuse those for other key management > systems like Mikey or Security Descriptions they need something to > reference. It would be preferable that this is published as an RFC. = And > maybe we should discuss intended status also. >=20 > I also don't think I have said anything that they can't get it done. I > have only raised a few things that I think the WG should discuss. And > the reason for that is the following charter text for this WG: >=20 > The AVTCORE working group will coordinate closely with the Security > Area > while working on maintenance and enhancements to the SRTP Profile. >=20 > I would claim that new crypto suits are "enhancements" to SRTP and = thus > falls under the this charter item if they want to publish an RFC. >=20 > There is an downside to a large amount of crypto suits as it hurts > interoperability. At the same time I think we need to be very > permitting > against different nations desire to define how their national = standards > are used in SRTP. >=20 > > > >> > >>> > >>>> > >>>> Independent I think you need to make it clear in the document = that > >>>> SuiteB does contain these policy rules. > >>> > >>> I don't really understand this comment: the very first sentence of > the > >>> Abstract says The United States government has published = guidelines > for > >>> "NSA Suite B Cryptography", which defines cryptographic algorithm > policy > >>> for national security applications. > >>> ^^^^^^ > >>> > >>> I don't know how it could be made much clearer or more obvious. > >>> > >>> ... > >> > >> What I meant is the fact that SuiteB key management is not allowed > to > >> use Security Descriptions nor MIKEY per policy. > > > > I'm not sure that it is solely a matter of policy; does MIKEY have a > > profile that uses elliptic-curve cryptography? IIRC, that was > > intentionally omitted due to IPR concerns. Furthermore, SDP is an > > unauthenticated protocol. >=20 > I fully understand that there are security concerns here also. And it > depends on the whole combination in the system if it meets the = security > requirements one has. From that perspective I am understanding why > SuiteB defines DTLS only. >=20 > Please understand that the main case I try to avoid is that we get > unnecessarily many crypto suit definitions when in a SuiteB and > "foobar" > specification both uses AES-256 CGM and SHA-256 authentication but in > fact has different definitions of everything that has to do with SRTP > except the underlying crypto algorithms. I rather see that foobar can > reuse most aspect of it and just have its own variations for certain > aspects. >=20 > cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- =20 ------_=_NextPart_001_01CC208D.F21FD85C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Our intent = wasn't to break new ground by introducing a new primitives = (GCM)

and DTLS) into SRTP, but rather = to follow in the footsteps of an existing =A0work:

 <= /p>

For GCM we = have:

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

Network = Working Group=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0D. McGrew

Internet = Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Cisco Systems, = Inc.

Intended Status: = Informational=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 January 26, 2011

Expires: July 30, 2011

 

 

=A0=A0=A0 AES-GCM and AES-CCM Authenticated = Encryption in Secure RTP (SRTP)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 draft-ietf-avt-srtp-aes-gcm-01

 

Abstract

 

=A0=A0 = This document defines how AES-GCM, AES-CCM, and other = Authenticated

=A0=A0 Encryption = with Associated Data (AEAD) algorithms, can be used to

=A0=A0 provide confidentiality and data = authentication mechanisms in the

=A0=A0 SRTP protocol.

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

(This had an = earlier incarnation as draft-mcgrew-srtp-aes-gcm= -01, but this

draft eventually = expired.)

 <= /p>

For DTLS we = have:

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

Internet Engineering = Task Force = (IETF)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 D. McGrew

Request for Comments: = 5764=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Cisco Systems

Category: Standards = Track=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0E. Rescorla

ISSN: = 2070-1721=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = RTFM, Inc.

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 May 2010

 <= /p>

 <= /p>

=A0 Datagram Transport = Layer Security (DTLS) Extension to Establish = Keys

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 for the Secure Real-time Transport Protocol = (SRTP)

 <= /p>

Abstract

 <= /p>

=A0=A0 This document = describes a Datagram Transport Layer Security = (DTLS)

=A0=A0 extension to = establish keys for Secure RTP (SRTP) and Secure = RTP

=A0=A0 Control Protocol = (SRTCP) flows.=A0 DTLS keying happens on the = media

=A0=A0 path, independent = of any out-of-band signalling channel present.

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

 

There = is an existing Suite B for TLS (currently undergoing a = "bis"):

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

Network Working = Group=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 M. = Salter

Request for Comments: = 5430=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = National Security Agency

Category: = Informational=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 E. = Rescorla

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Network = Resonance

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 R. = Housley

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Vigil = Security

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 March = 2009

 

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Suite B Profile for = Transport Layer Security (TLS)

 

Status = of This Memo

 

=A0=A0 = This memo provides information for the Internet community.=A0 It = does

=A0=A0 not specify an = Internet standard of any kind.=A0 Distribution of this

=A0=A0 memo is unlimited.

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

 

 

We = wish only to show how to put these three documents together to = get

Suite B for = DTLS-SRTP.

 

Do you still think we should go thru = avtcore?

 

P.S.=A0 Thanks for looking at this, we've gotten = next to no feedback.

 

 

 

 

 

 

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

> = From: Magnus Westerlund = [mailto:magnus.westerlund@ericsson.com]

> Sent: Wednesday, June 01, 2011 9:57 = AM

> To: Glen = Zorn

> Cc: Igoe, Kevin M.; = avt@ietf.org

> Subject: Re: = [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft

>

> = Glen and Kevin

> =

> Please see = inline.

>

> On 2011-06-01 15:12, Glen Zorn = wrote:

> > On 6/1/2011 6:32 = PM, Magnus Westerlund wrote:

> = >

> >> On 2011-06-01 = 12:26, Glen Zorn wrote:

> = >>> On 6/1/2011 3:09 PM, Magnus Westerlund = wrote:

>

> >

> >>

> >> So, this specification clearly brings = new combinations of encryption

> and

> = >> authentication and might in fact be a completely new crypto = suite if

> the

> >> PRF is different with RFC = 6188.

> >

> > [disclaimer: I am _not_ a = cryptographer!]

> > RFC 6188 = specifies the use of AES-CM (AKA AES-CTR) with 192- and = 256-

> bit

> > keys for the encryption of data, but the = draft in question specifies

> = the

> > use of AES-GCM with = 128- and 256-bit keys.=A0 My understanding is that

> CM

> = > & GCM are significantly different; in addition, 6188 uses = HMAC-SHA1

> = for

> > authentication, = while the use of AES-GCM obviates the need for a

> > separate authentication function.=A0 So = it appears to me that a new

> = > cryptosuite is being defined, regardless of whether or not the PRF = is

> > = identical...

> =

> Yes, I agree with that = assessment. It is a new crypto suite, I missed

> the CM vesus GCM difference. I am also not a = cryptographer.

> =

> But the procedural point = here is that they SuiteB does define a not

> previous existing definitions of combinations = of crypto operations in

> the = SRTP context.

> =

> >

> >>

> >> The question I have to the WG is if = it is worth handling the actual

> SRTP

> >> crypto transform defintion from the = actual profiles and the

> = additional

> >> = requirements on key management. Thus allowing the usage of = the

> crypto

> >> transforms themselves outside of a = SuiteB context, which clearly

> = can't

> >> be called = SuiteB but which for example is AES-256 with SHA-256 in

> SRTP

> >> and some other key = management.

> = >

> > Maybe I'm just = dull, but I'm still not getting the point.=A0 It looks

> to

> = > me as if the authors are just stating what it will take to get = an

> SRTP

> > implementation approved for US government = usage in certain

> = situations.

> > Why would = you want to tell them that they can't?=A0 Further (if = my

> > presumption is = correct), why is it necessary for the document to go

> > through this WG at all, given the = intended status of Informational?

> If

> = > avtcore wants to specify a million different ciphersuites = that's

> fine,

> > but what does it have to do with this = draft?

>

> Lets separate the issues here. The first one = is if they need to go

> through = the WG. I think to be strictly correct they are not required = to

> go through the WG. The = only procedural point they are strictly required

> to meet are the one of the DTLS protection = profiles, which is

> = specification required. So NSA could based on a NIST specification = with

> all these details that = are in the draft request IANA to register the

> DTLS protection profile = identifiers.

> =

> I do however hope they are = here for getting a bit of IETF review of it

> and the potential benefit in visibility for = the profiles by having an

> = RFC. So assuming that they want an RFC:

>

> = The draft is defining procedures for SRTP crypto transforms = that

> doesn't

> exist before. If someone like to reuse those = for other key management

> = systems like Mikey or Security Descriptions they need something = to

> reference. It would be = preferable that this is published as an RFC. And

> maybe we should discuss intended status = also.

>

> I also don't think I have said anything that = they can't get it done. I

> = have only raised a few things that I think the WG should discuss. = And

> the reason for that is = the following charter text for this WG:

>

> = The AVTCORE working group will coordinate closely with the = Security

> = Area

> while working on = maintenance and enhancements to the SRTP Profile.

>

> I = would claim that new crypto suits are "enhancements" to SRTP = and thus

> falls under the this = charter item if they want to publish an RFC.

>

> = There is an downside to a large amount of crypto suits as it = hurts

> interoperability. At = the same time I think we need to be very

> permitting

> against different nations desire to define how = their national standards

> are = used in SRTP.

> =

> >

> >>

> >>>

> >>>>

> >>>> Independent I think you need = to make it clear in the document that

> >>>> SuiteB does contain these = policy rules.

> = >>>

> >>> I = don't really understand this comment: the very first sentence = of

> the

> >>> Abstract says The United States = government has published guidelines

> for

> = >>> "NSA Suite B Cryptography", which defines = cryptographic algorithm

> = policy

> >>> for = national security applications.

> >>> ^^^^^^

> >>>

> >>> I don't know how it could be made = much clearer or more obvious.

> = >>>

> >>> = ...

> >>

> >> What I meant is the fact that SuiteB = key management is not allowed

> = to

> >> use Security = Descriptions nor MIKEY per policy.

> >

> > I'm not sure that it is solely a matter = of policy; does MIKEY have a

> = > profile that uses elliptic-curve cryptography?=A0 IIRC, that = was

> > intentionally = omitted due to IPR concerns.=A0 Furthermore, SDP is an

> > unauthenticated = protocol.

>

> I fully understand that there are security = concerns here also. And it

> = depends on the whole combination in the system if it meets the = security

> requirements one = has. From that perspective I am understanding why

> SuiteB defines DTLS only.

>

> = Please understand that the main case I try to avoid is that we = get

> unnecessarily many crypto = suit definitions when in a SuiteB and

> "foobar"

> specification both uses AES-256 CGM and = SHA-256 authentication but in

> = fact has different definitions of everything that has to do with = SRTP

> except the underlying = crypto algorithms. I rather see that foobar can

> reuse most aspect of it and just have its own = variations for certain

> = aspects.

>

> cheers

>

> = Magnus Westerlund

> =

> = ----------------------------------------------------------------------

> Multimedia Technologies, = Ericsson Research EAB/TVM

> = ----------------------------------------------------------------------

> Ericsson = AB=A0=A0=A0=A0=A0=A0=A0=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=A0=A0=A0=A0=A0=A0=A0 | Mobile +46 73 = 0949079

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

> = ----------------------------------------------------------------------

 

------_=_NextPart_001_01CC208D.F21FD85C-- From internet-drafts@ietf.org Tue Jun 7 01:44:13 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C2D21F8559; Tue, 7 Jun 2011 01:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZIeZE-wAfMW; Tue, 7 Jun 2011 01:44:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0D521F8554; Tue, 7 Jun 2011 01:44:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110607084412.16038.596.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2011 01:44:12 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 08:44:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Encryption of Header Extensions in the Secure Real-Time = Transport Protocol (SRTP) Author(s) : Jonathan Lennox Filename : draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt Pages : 9 Date : 2011-06-01 The Secure Real-Time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-Time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-encrypted-heade= r-ext-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-encrypted-header= -ext-00.txt From magnus.westerlund@ericsson.com Tue Jun 7 04:35:30 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B9411E80D2 for ; Tue, 7 Jun 2011 04:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDBllpQpcKFF for ; Tue, 7 Jun 2011 04:35:29 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 26DAA21F847C for ; Tue, 7 Jun 2011 04:34:48 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a7-4dee0cd718b3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E9.EF.20773.7DC0EED4; Tue, 7 Jun 2011 13:34:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 7 Jun 2011 13:34:23 +0200 Message-ID: <4DEE0CBE.8060007@ericsson.com> Date: Tue, 7 Jun 2011 13:34:22 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: avt@ietf.org References: <20110531075015.28779.24807.idtracker@ietfa.amsl.com> In-Reply-To: <20110531075015.28779.24807.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 11:35:30 -0000 Hi, We finally managed to get ready to submit this update. It is quite a lot of changes in this version is both attempts to address the open issues we have discussed in the meeting and a complete editorial pass. The diff to previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-ecn-for-rtp-02 However, I would recommend that people read through the whole document due to the amount of changes. The really major change in this version is the change of the data formats to address the counter wrap issue that was discussed. A list of the other substantial changes are (not 100% complete): 1. Changed the applicability statement for Topo-Translators to remove normative ECN treatment behavior from this section and move it into section 8. - Added a new subsection in 8 for transport translator - Added in the applicability statement that additional rules applies for ICE initiation with transport translators. 2. Added a SHALL NOT instead of "cannot" in the Topo-Video-switch-MCU applicability statement. 3. Changed back the text regarding media level attribute in Section 6.1: 4. changed a "will" to "SHALL" in the Generating ECN Probe Packets text in Section 7.2.1 5. Section 7.2.1, Generating RTCP ECN Feedback, making clear that XR summary blocks MUST be sent independently if any ECT or ECN-CE marked packets are received. 6. Implemented an CNAME based optimization. I will respond to mailing list on how my considerations for trade-off looks. 7. Added text in 7.2.2 about ICE init and Translators. 8. Section 7.3.2, changed a SHOULD send RR/SR to "will send RR/SR unless reduced size RTCP is used." 9. Removed a note in 7.3.2 talking about possible optimizations. 10. Section 7.3.3: Changed the formulation of the must statement based on feedback from Thomas Belling: The default reaction on the reception of these ECN-CE marked packets MUST be to provide the congestion control algorithm with a congestion notification, that triggers the algorithm to react as when packet loss would be encountered. 11. Section 7.3.3. last paragraph, additional sentence: As it is possible to detect flows that are non-responsive to CE and punish such flow it appears best if the application is well behaved. 12. Updated text in Section 8.2 (Fragmentation/assembling translators) 13. Added reduced size RTCP to the O/A SDP example. 14. Added a clarification in Section 3 on that RTCP feedback is in packets, thus byte counting is difficult. 15. Added clarification on the usage of non symmetric init methods that they can be done when mixers or translators are part of the picture. 16. Removed the limitation to not try ICE init over TURN. This would be an artificial limitation as TURN can support ECN. 17. Added an applicability statement on ICE init method. So please review and comment to the list. Cheers Magnus On 2011-05-31 09:50, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Explicit Congestion Notification (ECN) for RTP over UDP > Author(s) : Magnus Westerlund > Ingemar Johansson > Colin Perkins > Piers O'Hanlon > Ken Carlberg > Filename : draft-ietf-avtcore-ecn-for-rtp-02.txt > Pages : 56 > Date : 2011-05-31 > > This memo specifies how Explicit Congestion Notification (ECN) can be > used with Real-time Transport Protocol (RTP) running over UDP, using > RTP Control Protocol (RTCP) as a feedback mechanism. It defines a > new RTCP Extended Report (XR) block for periodic ECN feedback, a new > RTCP transport feedback message for timely reporting of congestion > events, and a Session Traversal Utilities for NAT (STUN) extension > used in the optional initilization method using Interactive > Connectivity Establishment (ICE). Signalling and procedures for > negotiation of capabilities and initilization methods are also > defined. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-02.txt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jonathan@vidyo.com Tue Jun 7 09:41:36 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7567711E81D6 for ; Tue, 7 Jun 2011 09:41:36 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxJFyUJyGZDv for ; Tue, 7 Jun 2011 09:41:35 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by ietfa.amsl.com (Postfix) with ESMTP id A292611E81D5 for ; Tue, 7 Jun 2011 09:41:35 -0700 (PDT) Received: from st21.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 0327E554577 for ; Tue, 7 Jun 2011 12:41:35 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 7FA06553669 for ; Tue, 7 Jun 2011 12:40:17 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Tue, 7 Jun 2011 12:39:04 -0400 From: Jonathan Lennox To: "avt@ietf.org" Date: Tue, 7 Jun 2011 12:40:16 -0400 Thread-Topic: New Version Notification for draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt Thread-Index: AcwlMZRXouhvRM62TbSL5uJJaxcjqA== Message-ID: References: <20110607084413.16038.95268.idtracker@ietfa.amsl.com> In-Reply-To: <20110607084413.16038.95268.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:41:36 -0000 Hi, all -- The header extension encryption draft is now published as a WG document. There are no technical changes from the final individual submission, but I = wanted to call people's attention to two issues I've introduced discussion = about in this version of the draft. 1. We've seen additional discussion on the list recently (in the context o= f the Suite B work) about the draft defining AES-GCM for SRTP. I'm not ter= ribly familiar with AES-GCM, so it's not clear to me how its encryption tra= nsforms (or other AEAD transforms) should apply to the encrypted header ext= ension mechanism. Since both encrypted header extensions and AES-GCM SRTP are AVTCORE working= group items, I think it's important that we understand how these pieces fi= t together. I'd need guidance from someone who understands AES-GCM better. 2. The two-byte form of header extensions (with "defined by profile" field= 0x100x) allows zero-length header extension elements, and also can use the= low four bits of the "defined by profile" field as an extra extension fiel= d. The mechanism in this draft doesn't provide protection for either of th= ese cases. I don't think this is a problem -- in either case, switching to= a one-byte header extension element that carries the relevant information = is perfectly possible, and would also allow transport over the 0xBEDE one-b= yte form of header extensions -- but I wanted to get working group consensu= s that this is okay. Comments on other aspects of the draft are also welcome, of course.=20 On Jun 7, 2011, at 4:44 AM, wrote: > A new version of I-D, draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt= has been successfully submitted by Jonathan Lennox and posted to the IETF = repository. >=20 > Filename: draft-ietf-avtcore-srtp-encrypted-header-ext > Revision: 00 > Title: Encryption of Header Extensions in the Secure Real-Time Transpor= t Protocol (SRTP) > Creation date: 2011-06-01 > WG ID: avtcore > Number of pages: 9 >=20 > Abstract: > The Secure Real-Time Transport Protocol (SRTP) provides > authentication, but not encryption, of the headers of Real-Time > Transport Protocol (RTP) packets. However, RTP header extensions may > carry sensitive information for which participants in multimedia > sessions want confidentiality. This document provides a mechanism, > extending the mechanisms of SRTP, to selectively encrypt RTP header > extensions in SRTP. >=20 >=20 >=20 >=20 > The IETF Secretariat -- Jonathan Lennox jonathan@vidyo.com From csp@csperkins.org Thu Jun 9 07:00:42 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC0321F8513; Thu, 9 Jun 2011 07:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.505 X-Spam-Level: X-Spam-Status: No, score=-103.505 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7LE3i0gArqg; Thu, 9 Jun 2011 07:00:41 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id B86E821F8512; Thu, 9 Jun 2011 07:00:41 -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 1QUfky-0007Pl-kn; Thu, 09 Jun 2011 13:58:44 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins X-Priority: 3 In-Reply-To: <01c501cc1c16$ebad8ea0$46298a0a@china.huawei.com> Date: Thu, 9 Jun 2011 14:58:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01c501cc1c16$ebad8ea0$46298a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1084) Cc: magnus.westerlund@ericsson.com, avt@ietf.org, xrblock@ietf.org Subject: Re: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:00:42 -0000 On 27 May 2011, at 03:36, Qin Wu wrote: > This version addresses the open issues regarding identity information = repetition and acknowledge section. > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt >=20 > The diff is: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-02 >=20 > Comments are welcome! This helps, but to my mind doesn't go far enough. We have the SSRC to = identify participants. I don't see much benefit from having a separate = identity tag in XR blocks. --=20 Colin Perkins http://csperkins.org/ From sunseawq@huawei.com Fri Jun 10 01:55:02 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BF411E80DC; Fri, 10 Jun 2011 01:55:02 -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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkLLbBVbs5iX; Fri, 10 Jun 2011 01:55:01 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A143511E8092; Fri, 10 Jun 2011 01:55:00 -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 <0LMK0089FGRN9L@szxga05-in.huawei.com>; Fri, 10 Jun 2011 16:54: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 <0LMK00KR3GRMMO@szxga05-in.huawei.com>; Fri, 10 Jun 2011 16:54:58 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMK00BRGGRL7V@szxml06-in.huawei.com>; Fri, 10 Jun 2011 16:54:58 +0800 (CST) Date: Fri, 10 Jun 2011 16:59:35 +0800 From: Qin Wu To: Colin Perkins Message-id: <029f01cc274c$b8fe19c0$46298a0a@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: <01c501cc1c16$ebad8ea0$46298a0a@china.huawei.com> Cc: magnus.westerlund@ericsson.com, avt@ietf.org, xrblock@ietf.org Subject: Re: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 08:55:02 -0000 Hi, ----- Original Message ----- From: "Colin Perkins" To: "Qin Wu" Cc: ; ; Sent: Thursday, June 09, 2011 9:58 PM Subject: Re: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt On 27 May 2011, at 03:36, Qin Wu wrote: > This version addresses the open issues regarding identity information repetition and acknowledge section. > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt > > The diff is: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-02 > > Comments are welcome! This helps, but to my mind doesn't go far enough. We have the SSRC to identify participants. I don't see much benefit from having a separate identity tag in XR blocks. [Qin]: I think that we are talking about how to define future RTCP XR Block. It seems to me the rule we are following to define the new RTCP XR BLock in the avtcore-monarch is a little different from the rule of we are doing to the existing RTCP XR described in RFC3611. As for the existing XR Block defined in RFC3611, each of the existing XR Block has allocated a field for SSRC of source. However such identity information can be repeated several times if several metric blocks reporting one stream from one source is carried in the same RTCP Packet. In order to reduce overhead to carry duplicated SSRC of source in each metric block, in the new XR Block, we separate such SSRC of source out from each metric block. One way is to allocate identity tag field in each metric block which can be used to tell which metric block report on stream from which source. Another way is to follow the existing rules defined in RFC3611. put back the SSRC of source field into each metric block which also can be used to tell which metric block report on stream from which source. However this rule seems to contradict to the rule of reducing identity information repetition discussed in avtcore-monarch. Which way we should follow? -- Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Fri Jun 10 08:28:51 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB9C11E81E5 for ; Fri, 10 Jun 2011 08:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4A+F5tYHU2S for ; Fri, 10 Jun 2011 08:28:50 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 31DDF11E80E0 for ; Fri, 10 Jun 2011 08:28:50 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-40-4df23831264f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CD.2A.20773.13832FD4; Fri, 10 Jun 2011 17:28:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 10 Jun 2011 17:28:49 +0200 Message-ID: <4DF2382E.6030303@ericsson.com> Date: Fri, 10 Jun 2011 17:28:46 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Igoe, Kevin M." References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <4DE4AC77.9050501@ericsson.com> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B19@MSIS-GH1-UEA06.corp.nsa.gov> <4DE5F3CB.80304@ericsson.com> <4DE613ED.6090503@net-zen.net> <4DE6235A.1030703@ericsson.com> <4DE63AD8.6020301@net-zen.net> <4DE64541.2070603@ericsson.com> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B1D@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B1D@MSIS-GH1-UEA06.corp.nsa.gov> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 15:28:51 -0000 Hi Igor, I have now actually reviewed your document in a bit more detail. And I am sorry for having confused the matter a bit. I didn't quite understand the purpose of this document initially. But it is clear to me now that your draft doesn't define new components to SRTP. My understanding is that it really only specifies the DTLS-SRTP protection profile and acceptable procedures to meet the suite-B requirements when it comes to the DTLS procedures. Thus I don't think it is necessary for us to have it as a WG item. Although I think it would be good that you inform the WG on the progress and let us know about any ongoing last calls. Do you plan to continue to publish this as an individual submission directly to the Area Director, or find a WG home for it? As an suggestion for how to improve the document, I note that you appear to be lacking an IANA consideration section. You need such a one to request that the 4 specified DTLS-SRTP protection profiles are registered. Best Regards Magnus On 2011-06-01 20:58, Igoe, Kevin M. wrote: > Our intent wasn't to break new ground by introducing a new primitives (GCM) > > and DTLS) into SRTP, but rather to follow in the footsteps of an > existing work: > > > > For GCM we have: > > ------------------------------------------------------------------------- > > Network Working Group D. McGrew > > Internet Draft Cisco Systems, Inc. > > Intended Status: Informational January 26, 2011 > > Expires: July 30, 2011 > > > > > > AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) > > draft-ietf-avt-srtp-aes-gcm-01 > > > > Abstract > > > > This document defines how AES-GCM, AES-CCM, and other Authenticated > > Encryption with Associated Data (AEAD) algorithms, can be used to > > provide confidentiality and data authentication mechanisms in the > > SRTP protocol. > > ------------------------------------------------------------------------- > > (This had an earlier incarnation as draft-mcgrew-srtp-aes-gcm-01, but this > > draft eventually expired.) > > > > For DTLS we have: > > ------------------------------------------------------------------------- > > Internet Engineering Task Force (IETF) D. McGrew > > Request for Comments: 5764 Cisco Systems > > Category: Standards Track E. Rescorla > > ISSN: 2070-1721 RTFM, Inc. > > May 2010 > > > > > > Datagram Transport Layer Security (DTLS) Extension to Establish Keys > > for the Secure Real-time Transport Protocol (SRTP) > > > > Abstract > > > > This document describes a Datagram Transport Layer Security (DTLS) > > extension to establish keys for Secure RTP (SRTP) and Secure RTP > > Control Protocol (SRTCP) flows. DTLS keying happens on the media > > path, independent of any out-of-band signalling channel present. > > --------------------------------------------------------------------- > > > > There is an existing Suite B for TLS (currently undergoing a "bis"): > > --------------------------------------------------------------------- > > Network Working Group M. Salter > > Request for Comments: 5430 National Security Agency > > Category: Informational E. Rescorla > > Network Resonance > > R. Housley > > Vigil Security > > March 2009 > > > > > > Suite B Profile for Transport Layer Security (TLS) > > > > Status of This Memo > > > > This memo provides information for the Internet community. It does > > not specify an Internet standard of any kind. Distribution of this > > memo is unlimited. > > ---------------------------------------------------------------------- > > > > > > We wish only to show how to put these three documents together to get > > Suite B for DTLS-SRTP. > > > > Do you still think we should go thru avtcore? -- 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 kmigoe@nsa.gov Fri Jun 10 08:34:17 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1564C11E8090 for ; Fri, 10 Jun 2011 08:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBdooG9e4oeF for ; Fri, 10 Jun 2011 08:34:16 -0700 (PDT) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by ietfa.amsl.com (Postfix) with ESMTP id 364D211E81F8 for ; Fri, 10 Jun 2011 08:34:15 -0700 (PDT) Received: from MSCS-GH1-UEA02.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p5AFYCRk029036; Fri, 10 Jun 2011 15:34:13 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jun 2011 11:34:12 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 10 Jun 2011 11:33:49 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B27@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <4DF2382E.6030303@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft Thread-Index: Acwngxoj5iWN615HQyG6i+bJvz5jRQAADHTQ References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <4DE4AC77.9050501@ericsson.com> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B19@MSIS-GH1-UEA06.corp.nsa.gov> <4DE5F3CB.80304@ericsson.com> <4DE613ED.6090503@net-zen.net> <4DE6235A.1030703@ericsson.com> <4DE63AD8.6020301@net-zen.net> <4DE64541.2070603@ericsson.com> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B1D@MSIS-GH1-UEA06.corp.nsa.gov> <4DF2382E.6030303@ericsson.com> From: "Igoe, Kevin M." To: "Magnus Westerlund" X-OriginalArrivalTime: 10 Jun 2011 15:34:12.0355 (UTC) FILETIME=[D91B5D30:01CC2783] Cc: avt@ietf.org Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 15:34:17 -0000 Thanks for sparing the time to review this. At this late date we'll keep going as an individual submission. With a bit of luck this=20 will be finished before the snow flies. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, June 10, 2011 11:29 AM > To: Igoe, Kevin M. > Cc: Glen Zorn; avt@ietf.org > Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft >=20 > Hi Igor, >=20 > I have now actually reviewed your document in a bit more detail. And I > am sorry for having confused the matter a bit. I didn't quite > understand > the purpose of this document initially. But it is clear to me now that > your draft doesn't define new components to SRTP. >=20 > My understanding is that it really only specifies the DTLS-SRTP > protection profile and acceptable procedures to meet the suite-B > requirements when it comes to the DTLS procedures. >=20 > Thus I don't think it is necessary for us to have it as a WG item. > Although I think it would be good that you inform the WG on the > progress > and let us know about any ongoing last calls. >=20 > Do you plan to continue to publish this as an individual submission > directly to the Area Director, or find a WG home for it? >=20 >=20 >=20 > As an suggestion for how to improve the document, I note that you > appear > to be lacking an IANA consideration section. You need such a one to > request that the 4 specified DTLS-SRTP protection profiles are > registered. >=20 > Best Regards >=20 > Magnus >=20 >=20 >=20 >=20 > On 2011-06-01 20:58, Igoe, Kevin M. wrote: > > Our intent wasn't to break new ground by introducing a new = primitives > (GCM) > > > > and DTLS) into SRTP, but rather to follow in the footsteps of an > > existing work: > > > > > > > > For GCM we have: > > > > = --------------------------------------------------------------------- > ---- > > > > Network Working Group D. > McGrew > > > > Internet Draft Cisco Systems, > Inc. > > > > Intended Status: Informational January 26, > 2011 > > > > Expires: July 30, 2011 > > > > > > > > > > > > AES-GCM and AES-CCM Authenticated Encryption in Secure RTP = (SRTP) > > > > draft-ietf-avt-srtp-aes-gcm-01 > > > > > > > > Abstract > > > > > > > > This document defines how AES-GCM, AES-CCM, and other > Authenticated > > > > Encryption with Associated Data (AEAD) algorithms, can be used to > > > > provide confidentiality and data authentication mechanisms in the > > > > SRTP protocol. > > > > = --------------------------------------------------------------------- > ---- > > > > (This had an earlier incarnation as draft-mcgrew-srtp-aes-gcm-01, = but > this > > > > draft eventually expired.) > > > > > > > > For DTLS we have: > > > > = --------------------------------------------------------------------- > ---- > > > > Internet Engineering Task Force (IETF) D. > McGrew > > > > Request for Comments: 5764 Cisco > Systems > > > > Category: Standards Track E. > Rescorla > > > > ISSN: 2070-1721 RTFM, > Inc. > > > > May > 2010 > > > > > > > > > > > > Datagram Transport Layer Security (DTLS) Extension to Establish > Keys > > > > for the Secure Real-time Transport Protocol (SRTP) > > > > > > > > Abstract > > > > > > > > This document describes a Datagram Transport Layer Security = (DTLS) > > > > extension to establish keys for Secure RTP (SRTP) and Secure RTP > > > > Control Protocol (SRTCP) flows. DTLS keying happens on the media > > > > path, independent of any out-of-band signalling channel present. > > > > = --------------------------------------------------------------------- > > > > > > > > There is an existing Suite B for TLS (currently undergoing a "bis"): > > > > = --------------------------------------------------------------------- > > > > Network Working Group M. > Salter > > > > Request for Comments: 5430 National Security > Agency > > > > Category: Informational E. > Rescorla > > > > Network > Resonance > > > > R. > Housley > > > > Vigil > Security > > > > March > 2009 > > > > > > > > > > > > Suite B Profile for Transport Layer Security (TLS) > > > > > > > > Status of This Memo > > > > > > > > This memo provides information for the Internet community. It > does > > > > not specify an Internet standard of any kind. Distribution of > this > > > > memo is unlimited. > > > > = --------------------------------------------------------------------- > - > > > > > > > > > > > > We wish only to show how to put these three documents together to = get > > > > Suite B for DTLS-SRTP. > > > > > > > > Do you still think we should go thru avtcore? >=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 Internet-Drafts@ietf.org Fri Jun 10 14:15:04 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E39E9E8007; Fri, 10 Jun 2011 14:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsvH+P5NcVSm; Fri, 10 Jun 2011 14:15:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145519E8016; Fri, 10 Jun 2011 14:15:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110610211503.31945.47398.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2011 14:15:03 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D ACTION:draft-ietf-avt-forward-shifted-red-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 21: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 Core Maintenance Working Group of the IETF. Title : Forward-shifted RTP Redundancy Payload Support Author(s) : Q. Xie Filename : draft-ietf-avt-forward-shifted-red-07.txt Pages : 13 Date : 2011-06-10 This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-forward-shifted-red-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-forward-shifted-red-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-06-10140257.I-D@ietf.org> --NextPart-- From abegen@cisco.com Sun Jun 12 15:17:43 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B809311E8121 for ; Sun, 12 Jun 2011 15:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVonax29R7up for ; Sun, 12 Jun 2011 15:17:43 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5249D11E8118 for ; Sun, 12 Jun 2011 15:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=966; q=dns/txt; s=iport; t=1307917063; x=1309126663; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=8EwLlgwUPqw+D2+jWepfmUbL1aAmZ6N/h0PIQaseDOQ=; b=iTiGiL2YcUdM1P6YKcT6KY9M3mLCrd5IOH7ZCijIHw7qJXmx06R1iZ0n n9nLjzF96kXuGBfah4Jds2NBx8sPAUkDAoF8BCRh9bpfxBXxAjZE/b7Gx XarSwEwpgHclIlD2CnTqRA+PYmYljTu0tlsdlS27ZndcbaPw8ifuJk6S0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8BAIA69U2rRDoG/2dsb2JhbABSl1dBjjd3qGuBH5x8hiQEhw2Of4sl X-IronPort-AV: E=Sophos;i="4.65,356,1304294400"; d="scan'208";a="335439522" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 12 Jun 2011 22:17:39 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5CMHd4d022056 for ; Sun, 12 Jun 2011 22:17:39 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); Sun, 12 Jun 2011 15:17: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: Sun, 12 Jun 2011 15:17:36 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F38FC7E@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised redundancy grouping semantics drafts Thread-Index: AcwpTba3qvKFKsQnTnGOfBv6srn/AQAAIrBg From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 12 Jun 2011 22:17:39.0519 (UTC) FILETIME=[8A86F4F0:01CC294E] Subject: [AVTCORE] FW: Revised redundancy grouping semantics drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 22:17:43 -0000 FYI.=20 The following two drafts are MMUSIC drafts. However, since they are very = relevant to RTP and RTCP, we would like to get a review from AVTCORE as = well. The initial versions were presented in MMUSIC during the last = meeting and we plan to present the revisions in AVTCORE during the next = meeting. Thanks. -acbegen -----Original Message----- From: Ali C. Begen (abegen)=20 Sent: Sunday, June 12, 2011 6:16 PM To: mmusic Subject: Revised redundancy grouping semantics drafts Hi everyone, We revised the following two drafts: https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ https://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving= /=20 Drafts are almost complete for your review. Problems regarding RTCP = reporting have been addressed. I will be forwarding this email to = AVTCORE as well as there was a request that AVTCORE also reviewed these = drafts. Thanks. -acbegen From wwwrun@rfc-editor.org Mon Jun 13 20:50:25 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA7B21F8519; Mon, 13 Jun 2011 20:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.133 X-Spam-Level: X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=-0.133, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhaK6IU3IYZc; Mon, 13 Jun 2011 20:50:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 47D4721F8517; Mon, 13 Jun 2011 20:50:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4511398C505; Mon, 13 Jun 2011 20:50:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110614035024.4511398C505@rfc-editor.org> Date: Mon, 13 Jun 2011 20:50:24 -0700 (PDT) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6263 on Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 03:50:25 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6263 Title: Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows Author: X. Marjou, A. Sollaud Status: Standards Track Stream: IETF Date: June 2011 Mailbox: xavier.marjou@orange-ftgroup.com, aurelien.sollaud@orange-ftgroup.com Pages: 12 Characters: 23345 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-app-rtp-keepalive-10.txt URL: http://www.rfc-editor.org/rfc/rfc6263.txt This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP Control Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Core Maintenance 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 csp@csperkins.org Tue Jun 14 03:27:04 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C3B11E808E; Tue, 14 Jun 2011 03:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.441 X-Spam-Level: X-Spam-Status: No, score=-103.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSlH7YqIgxFW; Tue, 14 Jun 2011 03:27:04 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id E9DEA11E8071; Tue, 14 Jun 2011 03:27:03 -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 1QWQpr-0003fU-gb; Tue, 14 Jun 2011 10:27:03 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins X-Priority: 3 In-Reply-To: <029f01cc274c$b8fe19c0$46298a0a@china.huawei.com> Date: Tue, 14 Jun 2011 11:27:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01c501cc1c16$ebad8ea0$46298a0a@china.huawei.com> <029f01cc274c$b8fe19c0$46298a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1084) Cc: avt@ietf.org, xrblock@ietf.org Subject: Re: [AVTCORE] [xrblock] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 10:27:04 -0000 On 10 Jun 2011, at 09:59, Qin Wu wrote: > Hi, >> ----- Original Message -----=20 >> From: "Colin Perkins" >> To: "Qin Wu" >> Cc: ; ; = >> Sent: Thursday, June 09, 2011 9:58 PM >> Subject: Re: [AVTCORE] Fw: I-D Action: = draft-ietf-avtcore-monarch-02.txt >>=20 >>=20 >> On 27 May 2011, at 03:36, Qin Wu wrote: >>> This version addresses the open issues regarding identity = information repetition and acknowledge section. >>> = http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt >>>=20 >>> The diff is: >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-02 >>>=20 >>> Comments are welcome! >>=20 >> This helps, but to my mind doesn't go far enough. We have the SSRC to = identify participants. I don't see much benefit from having a separate = identity tag in XR blocks. >>=20 > [Qin]: I think that we are talking about how to define future RTCP XR = Block. It seems to me the rule we are following to define the new RTCP = XR BLock in the avtcore-monarch is a little different from the rule of = we are doing to the existing RTCP XR described in RFC3611. >=20 > As for the existing XR Block defined in RFC3611, each of the existing = XR Block has allocated a field for SSRC of source. However such = identity information can be repeated several times if several metric = blocks reporting one stream from one source is carried in the same RTCP = Packet. >=20 > In order to reduce overhead to carry duplicated SSRC of source in each = metric block, in the new XR Block, we separate such SSRC of source out = from each metric block. >=20 > One way is to allocate identity tag field in each metric block which = can be used to tell which metric block report on stream from which = source.=20 >=20 > Another way is to follow the existing rules defined in RFC3611. put = back the SSRC of source field into each metric block which also can be = used to tell which metric block report on stream from which source.=20 > However this rule seems to contradict to the rule of reducing identity = information repetition discussed in avtcore-monarch. >=20 > Which way we should follow? I think you should follow RFC 3611.=20 The savings from using the new identity tag don't seem worth the added = complexity. --=20 Colin Perkins http://csperkins.org/ From musgravepj@gmail.com Wed Jun 15 05:41:26 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3D721F84FB; Wed, 15 Jun 2011 05:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.045 X-Spam-Level: X-Spam-Status: No, score=-3.045 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGOG2nKkP8IH; Wed, 15 Jun 2011 05:41:24 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC42F21F84F8; Wed, 15 Jun 2011 05:41:23 -0700 (PDT) Received: by fxm15 with SMTP id 15so426666fxm.31 for ; Wed, 15 Jun 2011 05:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f60UB0zSm6EWNFns8OFxYA/GQ4LlBxLoDGkWmy3FOYA=; b=hOevUO9nxFqB75rdDpOVaQbqH7ABQeU2P6455yYovmWmSnz9+AIqXkdaNKLpLURe1m IHzl1aASOSL56k8ArAyOkkoe2V4wO5nku8G/2B9b0h9pPjM74DgywbWgkRrnquQyTfSL QACcjx6YHJ2fjh40sLWOeW68tDnKbBfDOdi2Y= 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=Xd7R4dr+HmQwPVQxjhN2+DnaIgYCN1QhmAfJHmkcLlZbxmcUsvgCI89zrfGlf29Xjh vpP4ZSYrJY0CmVAmCwZc/B3528bmCqtoKQdrcHqU0jPtjxPpDLY9cF559zoH0jJkEk98 el6m5wn/j2mCcCw2I8dUvMw0+WNt1zHmyPabU= MIME-Version: 1.0 Received: by 10.223.97.219 with SMTP id m27mr548751fan.81.1308141682974; Wed, 15 Jun 2011 05:41:22 -0700 (PDT) Received: by 10.223.109.17 with HTTP; Wed, 15 Jun 2011 05:41:22 -0700 (PDT) In-Reply-To: References: <01c501cc1c16$ebad8ea0$46298a0a@china.huawei.com> <029f01cc274c$b8fe19c0$46298a0a@china.huawei.com> Date: Wed, 15 Jun 2011 08:41:22 -0400 Message-ID: From: Peter Musgrave To: Colin Perkins Content-Type: multipart/alternative; boundary=0015174bdf6e545e8504a5bf787b Cc: avt@ietf.org, xrblock@ietf.org Subject: Re: [AVTCORE] [xrblock] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 12:41:26 -0000 --0015174bdf6e545e8504a5bf787b Content-Type: text/plain; charset=ISO-8859-1 I agree with Colin Peter Musgrave (as individual) On Tue, Jun 14, 2011 at 6:27 AM, Colin Perkins wrote: > On 10 Jun 2011, at 09:59, Qin Wu wrote: > > Hi, > >> ----- Original Message ----- > >> From: "Colin Perkins" > >> To: "Qin Wu" > >> Cc: ; ; > > >> Sent: Thursday, June 09, 2011 9:58 PM > >> Subject: Re: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt > >> > >> > >> On 27 May 2011, at 03:36, Qin Wu wrote: > >>> This version addresses the open issues regarding identity information > repetition and acknowledge section. > >>> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt > >>> > >>> The diff is: > >>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-02 > >>> > >>> Comments are welcome! > >> > >> This helps, but to my mind doesn't go far enough. We have the SSRC to > identify participants. I don't see much benefit from having a separate > identity tag in XR blocks. > >> > > [Qin]: I think that we are talking about how to define future RTCP XR > Block. It seems to me the rule we are following to define the new RTCP XR > BLock in the avtcore-monarch is a little different from the rule of we are > doing to the existing RTCP XR described in RFC3611. > > > > As for the existing XR Block defined in RFC3611, each of the existing XR > Block has allocated a field for SSRC of source. However such identity > information can be repeated several times if several metric blocks reporting > one stream from one source is carried in the same RTCP Packet. > > > > In order to reduce overhead to carry duplicated SSRC of source in each > metric block, in the new XR Block, we separate such SSRC of source out from > each metric block. > > > > One way is to allocate identity tag field in each metric block which can > be used to tell which metric block report on stream from which source. > > > > Another way is to follow the existing rules defined in RFC3611. put back > the SSRC of source field into each metric block which also can be used to > tell which metric block report on stream from which source. > > However this rule seems to contradict to the rule of reducing identity > information repetition discussed in avtcore-monarch. > > > > Which way we should follow? > > > I think you should follow RFC 3611. > > The savings from using the new identity tag don't seem worth the added > complexity. > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --0015174bdf6e545e8504a5bf787b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Colin

Peter Musgrave
(as individu= al)

On Tue, Jun 14, 2011 at 6:27 AM, Coli= n Perkins <csp@cs= perkins.org> wrote:
On 10 Jun= 2011, at 09:59, Qin Wu wrote:
> Hi,
>> ----- Original Message -----
>> From: "Colin Perkins" <csp@csperkins.org>
>> To: "Qin Wu" <= sunseawq@huawei.com>
>> Cc: <avt@ietf.org>; <= xrblock@ietf.org>; <magnus.westerlund@ericsson.com>
>> Sent: Thursday, June 09, 2011 9:58 PM
>> Subject: Re: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-= 02.txt
>>
>>
>> On 27 May 2011, at 03:36, Qin Wu wrote:
>>> This version addresses the open issues regarding identity info= rmation repetition and acknowledge section.
>>> http://www.ietf.org/internet-drafts/d= raft-ietf-avtcore-monarch-02.txt
>>>
>>> The diff is:
>>> http://tools.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-avtcore-monarch-02
>>>
>>> Comments are welcome!
>>
>> This helps, but to my mind doesn't go far enough. We have the = SSRC to identify participants. I don't see much benefit from having a s= eparate identity tag in XR blocks.
>>
> [Qin]: =A0I think that we are talking about how to define future RTCP = XR Block. It seems to me the rule we are following =A0to define the new RTC= P XR BLock in the avtcore-monarch is a little different from the rule of we= are doing to the existing RTCP XR described in RFC3611.
>
> As for the existing XR Block defined in RFC3611, each of the existing = XR Block has allocated =A0a field for SSRC of source. However such identity= information can be repeated several times if several metric blocks reporti= ng one stream from one source =A0is carried in the same RTCP Packet.
>
> In order to reduce overhead to carry duplicated SSRC of source in each= metric block, =A0in the new XR Block, we separate such SSRC of source out = from each metric block.
>
> One way is to =A0allocate identity tag field in each metric block whic= h can be used to tell which metric block report on stream from which source= .
>
> Another way is to follow the existing rules defined in RFC3611. put ba= ck the SSRC of source field into each metric block which also can be used t= o tell which metric block report on stream from which source.
> However this rule seems to contradict to the rule of reducing identity= information repetition discussed in avtcore-monarch.
>
> Which way we should follow?


I think you should follow RFC 3611.

The savings from using the new identity tag don't seem worth the added = complexity.

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



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

--0015174bdf6e545e8504a5bf787b-- From john.elwell@siemens-enterprise.com Thu Jun 16 01:32:53 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F4911E8112 for ; Thu, 16 Jun 2011 01:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6ypQYfid11F for ; Thu, 16 Jun 2011 01:32:53 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id E015311E8111 for ; Thu, 16 Jun 2011 01:32:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1308213164!25135981!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 29029 invoked from network); 16 Jun 2011 08:32:44 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-14.tower-27.messagelabs.com with SMTP; 16 Jun 2011 08:32:44 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id EE48F1EB83EE; Thu, 16 Jun 2011 10:32:51 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 16 Jun 2011 10:32:51 +0200 From: "Elwell, John" To: "avt@ietf.org" Date: Thu, 16 Jun 2011 10:32:50 +0200 Thread-Topic: RTP expert comments requested on draft-eckel-siprec-rtp-rec Thread-Index: Acwr/4xAmi/8cskSSDGspZRcAv19DA== 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 Cc: "Brian.Rosen@neustar.biz" Subject: [AVTCORE] RTP expert comments requested on draft-eckel-siprec-rtp-rec X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 08:32:54 -0000 RTP experts, Charles Eckel has posted the following draft: https://datatracker.ietf.org/doc/draft-eckel-siprec-rtp-rec/ relating to the use of RTP for session recording between a session recordin= g client (SRC) and a session recording server (SRS). The idea is that event= ually material from this draft will find its way into the SIPREC deliverabl= es. However, first it needs review, not only by the SIPREC WG but also by R= TP experts. I would like to invite folks to review the draft (about 6 pages= of substance) and comment on the SIPREC mailing list (not to the AVTCORE l= ist). Thanks, John From internet-drafts@ietf.org Thu Jun 16 02:21:10 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E851C11E81FD; Thu, 16 Jun 2011 02:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nkc6zy4oCz0t; Thu, 16 Jun 2011 02:21:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EC511E81F3; Thu, 16 Jun 2011 02:21:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110616092110.1754.68542.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 02:21:10 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:21:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Monitoring Architectures for RTP Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-03.txt Pages : 23 Date : 2011-06-16 This memo proposes an architecture for extending RTCP with a new RTCP XR (RFC3611) block type to report new metrics regarding media transmission or reception quality, as proposed in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt From sunseawq@huawei.com Thu Jun 16 02:29:22 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EAC1F0C3D for ; Thu, 16 Jun 2011 02:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mor8cA-fRUZv for ; Thu, 16 Jun 2011 02:29:21 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9219D1F0C38 for ; Thu, 16 Jun 2011 02:29:21 -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 <0LMV00008MCTLC@szxga05-in.huawei.com> for avt@ietf.org; Thu, 16 Jun 2011 17:29: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 <0LMV00MGWMCS24@szxga05-in.huawei.com> for avt@ietf.org; Thu, 16 Jun 2011 17:29:17 +0800 (CST) Received: from w53375q ([10.138.41.76]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMV004VLMCRAB@szxml06-in.huawei.com> for avt@ietf.org; Thu, 16 Jun 2011 17:29:16 +0800 (CST) Date: Thu, 16 Jun 2011 17:29:15 +0800 From: Qin Wu To: avt@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20110616092110.1754.68542.idtracker@ietfa.amsl.com> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:29:22 -0000 Hi,: In response to the recent comments and suggestion on the list, a new version of draft-ietf-avtcore-monarch is just submitted. http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt The diff is: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-03 Please check if your comments are addressed in this version. Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Thursday, June 16, 2011 5:21 PM Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.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 Core Maintenance Working Group of the IETF. > > Title : Monitoring Architectures for RTP > Author(s) : Qin Wu > Geoff Hunt > Philip Arden > Filename : draft-ietf-avtcore-monarch-03.txt > Pages : 23 > Date : 2011-06-16 > > This memo proposes an architecture for extending RTCP with a new RTCP > XR (RFC3611) block type to report new metrics regarding media > transmission or reception quality, as proposed in RFC5968. This memo > suggests that a new block should contain a single metric or a small > number of metrics relevant to a single parameter of interest or > concern, rather than containing a number of metrics which attempt to > provide full coverage of all those parameters of concern to a > specific application. Applications may then "mix and match" to > create a set of blocks which covers their set of concerns. Where > possible, a specific block should be designed to be re-usable across > more than one application, for example, for all of voice, streaming > audio and video. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From sunseawq@huawei.com Thu Jun 16 02:33:53 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410231F0C3D; Thu, 16 Jun 2011 02:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.065 X-Spam-Level: X-Spam-Status: No, score=-5.065 tagged_above=-999 required=5 tests=[AWL=1.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-D-dCJ7NAn8; Thu, 16 Jun 2011 02:33:52 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E299D1F0C38; Thu, 16 Jun 2011 02:33:51 -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 <0LMV00HRMMJLYS@szxga03-in.huawei.com>; Thu, 16 Jun 2011 17:33:21 +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 <0LMV00DNDMJKI8@szxga03-in.huawei.com>; Thu, 16 Jun 2011 17:33:20 +0800 (CST) Received: from w53375q ([10.138.41.76]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMV004WRMJGAB@szxml06-in.huawei.com>; Thu, 16 Jun 2011 17:33:20 +0800 (CST) Date: Thu, 16 Jun 2011 17:33:16 +0800 From: Qin Wu To: Peter Musgrave , Colin Perkins Message-id: <86AC8D83FDFA4C8F93EBA22B583E2515@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_IlC9YBBUEI0Q8XYbgbN+UA)" X-Priority: 3 X-MSMail-priority: Normal References: <01c501cc1c16$ebad8ea0$46298a0a@china.huawei.com> <029f01cc274c$b8fe19c0$46298a0a@china.huawei.com> Cc: avt@ietf.org, xrblock@ietf.org Subject: Re: [AVTCORE] [xrblock] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:33:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_IlC9YBBUEI0Q8XYbgbN+UA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Okay, I will revise the draft based on the rule in RFC3611. ----- Original Message ----- From: Peter Musgrave To: Colin Perkins Cc: Qin Wu ; avt@ietf.org ; xrblock@ietf.org Sent: Wednesday, June 15, 2011 8:41 PM Subject: Re: [AVTCORE] [xrblock] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt I agree with Colin Peter Musgrave (as individual) On Tue, Jun 14, 2011 at 6:27 AM, Colin Perkins wrote: On 10 Jun 2011, at 09:59, Qin Wu wrote: > Hi, >> ----- Original Message ----- >> From: "Colin Perkins" >> To: "Qin Wu" >> Cc: ; ; >> Sent: Thursday, June 09, 2011 9:58 PM >> Subject: Re: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt >> >> >> On 27 May 2011, at 03:36, Qin Wu wrote: >>> This version addresses the open issues regarding identity information repetition and acknowledge section. >>> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt >>> >>> The diff is: >>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-02 >>> >>> Comments are welcome! >> >> This helps, but to my mind doesn't go far enough. We have the SSRC to identify participants. I don't see much benefit from having a separate identity tag in XR blocks. >> > [Qin]: I think that we are talking about how to define future RTCP XR Block. It seems to me the rule we are following to define the new RTCP XR BLock in the avtcore-monarch is a little different from the rule of we are doing to the existing RTCP XR described in RFC3611. > > As for the existing XR Block defined in RFC3611, each of the existing XR Block has allocated a field for SSRC of source. However such identity information can be repeated several times if several metric blocks reporting one stream from one source is carried in the same RTCP Packet. > > In order to reduce overhead to carry duplicated SSRC of source in each metric block, in the new XR Block, we separate such SSRC of source out from each metric block. > > One way is to allocate identity tag field in each metric block which can be used to tell which metric block report on stream from which source. > > Another way is to follow the existing rules defined in RFC3611. put back the SSRC of source field into each metric block which also can be used to tell which metric block report on stream from which source. > However this rule seems to contradict to the rule of reducing identity information repetition discussed in avtcore-monarch. > > Which way we should follow? I think you should follow RFC 3611. The savings from using the new identity tag don't seem worth the added complexity. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_IlC9YBBUEI0Q8XYbgbN+UA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Okay, I will revise the draft based on the rule in RFC3611.
----- Original Message -----
Sent: Wednesday, June 15, 2011 8:41 PM
Subject: Re: [AVTCORE] [xrblock] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt

I agree with Colin

Peter Musgrave
(as individual)

On Tue, Jun 14, 2011 at 6:27 AM, Colin Perkins <csp@csperkins.org> wrote:
On 10 Jun 2011, at 09:59, Qin Wu wrote:
> Hi,
>> ----- Original Message -----
>> From: "Colin Perkins" <csp@csperkins.org>
>> To: "Qin Wu" <sunseawq@huawei.com>
>> Cc: <avt@ietf.org>; <xrblock@ietf.org>; <magnus.westerlund@ericsson.com>
>> Sent: Thursday, June 09, 2011 9:58 PM
>> Subject: Re: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt
>>
>>
>> On 27 May 2011, at 03:36, Qin Wu wrote:
>>> This version addresses the open issues regarding identity information repetition and acknowledge section.
>>> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt
>>>
>>> The diff is:
>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-02
>>>
>>> Comments are welcome!
>>
>> This helps, but to my mind doesn't go far enough. We have the SSRC to identify participants. I don't see much benefit from having a separate identity tag in XR blocks.
>>
> [Qin]:  I think that we are talking about how to define future RTCP XR Block. It seems to me the rule we are following  to define the new RTCP XR BLock in the avtcore-monarch is a little different from the rule of we are doing to the existing RTCP XR described in RFC3611.
>
> As for the existing XR Block defined in RFC3611, each of the existing XR Block has allocated  a field for SSRC of source. However such identity information can be repeated several times if several metric blocks reporting one stream from one source  is carried in the same RTCP Packet.
>
> In order to reduce overhead to carry duplicated SSRC of source in each metric block,  in the new XR Block, we separate such SSRC of source out from each metric block.
>
> One way is to  allocate identity tag field in each metric block which can be used to tell which metric block report on stream from which source.
>
> Another way is to follow the existing rules defined in RFC3611. put back the SSRC of source field into each metric block which also can be used to tell which metric block report on stream from which source.
> However this rule seems to contradict to the rule of reducing identity information repetition discussed in avtcore-monarch.
>
> Which way we should follow?


I think you should follow RFC 3611.

The savings from using the new identity tag don't seem worth the added complexity.

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



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

--Boundary_(ID_IlC9YBBUEI0Q8XYbgbN+UA)-- From Internet-Drafts@ietf.org Fri Jun 17 14:15:06 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BF421F846F; Fri, 17 Jun 2011 14:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGcw0mKYmuH6; Fri, 17 Jun 2011 14:15:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16BD21F846B; Fri, 17 Jun 2011 14:15:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110617211504.32001.68151.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2011 14:15:04 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D ACTION:draft-ietf-avt-forward-shifted-red-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 21:15:06 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Forward-shifted RTP Redundancy Payload Support Author(s) : Q. Xie Filename : draft-ietf-avt-forward-shifted-red-08.txt Pages : 13 Date : 2011-06-17 This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-forward-shifted-red-08.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-forward-shifted-red-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-06-17140142.I-D@ietf.org> --NextPart-- From abegen@cisco.com Fri Jun 17 15:14:35 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF7111E813C for ; Fri, 17 Jun 2011 15:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9wvS4AVKyPm for ; Fri, 17 Jun 2011 15:14:35 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 02A3B11E812F for ; Fri, 17 Jun 2011 15:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=716; q=dns/txt; s=iport; t=1308348874; x=1309558474; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=hEGRN7FdvDMMjnJ48a57YeVQZYZntWj6qsrWr1bTRGk=; b=S+ZR6LQsv87q3ss/u2dAV7X5PnN1WQQYdjRb2wU0his8O8pRVAwIdZfP KgDmkatYlu28tfJHCU8Z+Msw+8Ujj0WGdu2RjjLnS1t/fIj6JgVkXG9Uf MkMC1twZUV+JQ3RP9i4QDhrGxZ8wr5a7zY9ctBhm//XMUbZGg/3jEthI3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAHAJPQ+02rRDoJ/2dsb2JhbABSmBaOSXeqfp14hicEhyCPJos1 X-IronPort-AV: E=Sophos;i="4.65,383,1304294400"; d="scan'208";a="379493374" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 17 Jun 2011 22:14:33 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5HMEWjC008670; Fri, 17 Jun 2011 22:14:32 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); Fri, 17 Jun 2011 15:14:32 -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, 17 Jun 2011 15:14:30 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F4407DE@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ABNF change in the port mapping draft Thread-Index: AcwtO2EZmWz4toY8TmCS13YD91mPew== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 17 Jun 2011 22:14:32.0891 (UTC) FILETIME=[EF5A88B0:01CC2D3B] Cc: magnus.westerlund@ericsson.com, rjs@nostrum.com Subject: [AVTCORE] ABNF change in the port mapping draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 22:14:35 -0000 Hi everyone, Regarding the draft: https://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast= -rtp/=20 During AUTH48, we discovered that the port parameter was optional in the = following ABNF (section 7.1.1): portmapping-req-attr =3D "a=3Dportmapping-req" [":" port [SP nettype SP addrtype SP connection-address]] CRLF However, as it is clear from the text, port is essential for this = attribute, while the address is still optional. So, we suggest to change = the ABNF as follows: portmapping-req-attr =3D "a=3Dportmapping-req:" port [SP nettype SP addrtype SP connection-address] CRLF If you have any objection, now would be a good time to raise it. Thanks. -acbegen From Even.roni@huawei.com Sun Jun 19 06:48:40 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75E311E8072 for ; Sun, 19 Jun 2011 06:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVqRwuEwA12K for ; Sun, 19 Jun 2011 06:48:39 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4756B11E8095 for ; Sun, 19 Jun 2011 06:48: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 <0LN100E0TICY2I@szxga05-in.huawei.com> for avt@ietf.org; Sun, 19 Jun 2011 21:48:35 +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 <0LN1007IYICYXN@szxga05-in.huawei.com> for avt@ietf.org; Sun, 19 Jun 2011 21:48:34 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-47-132.red.bezeqint.net [79.181.47.132]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN1001PQICONR@szxml12-in.huawei.com>; Sun, 19 Jun 2011 21:48:34 +0800 (CST) Date: Sun, 19 Jun 2011 16:46:31 +0300 From: Roni Even In-reply-to: <4D8DBEDB.4090406@ericsson.com> To: 'IETF AVTCore WG' , 'VAN CAENEGEM Tom' Message-id: <004401cc2e87$523c06b0$f6b41410$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcvroApIveZeR4mXT1CxBcCiD4iXBxC5bN+g References: <4D8DBEDB.4090406@ericsson.com> Cc: 'Magnus Westerlund' Subject: Re: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and-retransm-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 13:48:40 -0000 Hi, I have finally found the time to read the document. I agree with Magnus = that the issue of retransmission in the RAMS architecture where the RS and FT = are collocated is not specified and it should also be reflected in the = feedback suppression draft. I think the draft has good text on the analysis of the feedback = suppression and this should be added to the WG document. Maybe Tom and Qin can work = on the WG document on this topic. As for the retransmission, I am not sure if this should be as part of = the suppression draft. If the issue is only for the case where we have the = FT/RS collocated with unicast feedback as in the RAMS case maybe it can be in = the RAMS scenario draft. If we are looking at a broader retransmission case (that is not well specified in current draft) that includes also the multicast retransmission from the RS or from the DS it may be good to discuss it as part of the WG document. Regards Roni > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: Saturday, March 26, 2011 12:24 PM > To: IETF AVTCore WG; VAN CAENEGEM Tom > Subject: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and- > retransm-00 >=20 > Tom, AVTCORE, >=20 > I have reviewed this draft and have the following comment. >=20 > To me it appears that one big reason for the issues is actually that = we > haven't specified how RTP retransmission in SSM with unicast delivery > is > supposed to work. Because if that was well defined we would likely = have > concluded that one should not forward NACK request to the DS from a FT > for any request it service locally. >=20 > Thus as I raised before in relation to the RAMS work that there > appeared > to be a need for defining this properly, including this aspect. Do we > have anyone that is interested in defining this? >=20 > Secondly I think there clearly are some improvements needed of the WG > document based on what you comment. One thing is clearly to clarify = the > WG document on its usages, and then map those usages of suppression to > different topologies. >=20 > My personal opinion on how to handle your comments are to include your > concerns in the WG document. >=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 > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Sun Jun 19 11:07:33 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E9F11E80AF for ; Sun, 19 Jun 2011 11:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpREYJSnLLZJ for ; Sun, 19 Jun 2011 11:07:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFFD11E80AB for ; Sun, 19 Jun 2011 11:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3767; q=dns/txt; s=iport; t=1308506852; x=1309716452; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3li2kQMEIIQIDnvRrbEHZn3JAyyjVZ5s1DxLraEx0iU=; b=ADGpoQ4CcEjXS9Hpb/+v6hEnVV0JvZg6DhjKLoqqW2YPTpQYhRfRnd+H J9Zxh9CfLt3Pz3AzGeAlZ/3uJwG1IzJkDmHuTX/QmPD/euIZNkiHlX1bu 43pFZngdwyjj04hiZdwXEN7FTZxwcgQP4r1IPPhhSafgHffnpUqit1tdC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEBAHc6/k2rRDoJ/2dsb2JhbABSl1GPCneoRZ0ZAoYoBIcgjyeLOA X-IronPort-AV: E=Sophos;i="4.65,389,1304294400"; d="scan'208";a="716825533" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2011 18:07:32 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5JI7VYH013942; Sun, 19 Jun 2011 18:07:31 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); Sun, 19 Jun 2011 11:07:31 -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: Sun, 19 Jun 2011 11:07:17 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F4408AF@xmb-sjc-215.amer.cisco.com> In-Reply-To: <004401cc2e87$523c06b0$f6b41410$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Commentson draft-vancaenegem-avtcore-fb-supp-and-retransm-00 Thread-Index: AcvroApIveZeR4mXT1CxBcCiD4iXBxC5bN+gAAl5A5A= References: <4D8DBEDB.4090406@ericsson.com> <004401cc2e87$523c06b0$f6b41410$%roni@huawei.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , "IETF AVTCore WG" , "VAN CAENEGEM Tom" X-OriginalArrivalTime: 19 Jun 2011 18:07:31.0681 (UTC) FILETIME=[C20CDD10:01CC2EAB] Cc: Magnus Westerlund Subject: Re: [AVTCORE] Commentson draft-vancaenegem-avtcore-fb-supp-and-retransm-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 18:07:33 -0000 Did you check https://datatracker.ietf.org/doc/draft-vancaenegem-avtcore-retransmission= -for-ssm/ ? It addresses at least some of the points you made below. -acbegen > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Roni Even > Sent: Sunday, June 19, 2011 6:47 AM > To: 'IETF AVTCore WG'; 'VAN CAENEGEM Tom' > Cc: 'Magnus Westerlund' > Subject: Re: [AVTCORE] Commentson = draft-vancaenegem-avtcore-fb-supp-and-retransm-00 >=20 > Hi, > I have finally found the time to read the document. I agree with = Magnus that > the issue of retransmission in the RAMS architecture where the RS and = FT are > collocated is not specified and it should also be reflected in the = feedback > suppression draft. > I think the draft has good text on the analysis of the feedback = suppression > and this should be added to the WG document. Maybe Tom and Qin can = work on > the WG document on this topic. > As for the retransmission, I am not sure if this should be as part of = the > suppression draft. If the issue is only for the case where we have the = FT/RS > collocated with unicast feedback as in the RAMS case maybe it can be = in the > RAMS scenario draft. If we are looking at a broader retransmission = case > (that is not well specified in current draft) that includes also the > multicast retransmission from the RS or from the DS it may be good to > discuss it as part of the WG document. >=20 > Regards > Roni >=20 >=20 >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of > > Magnus Westerlund > > Sent: Saturday, March 26, 2011 12:24 PM > > To: IETF AVTCore WG; VAN CAENEGEM Tom > > Subject: [AVTCORE] Comments on = draft-vancaenegem-avtcore-fb-supp-and- > > retransm-00 > > > > Tom, AVTCORE, > > > > I have reviewed this draft and have the following comment. > > > > To me it appears that one big reason for the issues is actually that = we > > haven't specified how RTP retransmission in SSM with unicast = delivery > > is > > supposed to work. Because if that was well defined we would likely = have > > concluded that one should not forward NACK request to the DS from a = FT > > for any request it service locally. > > > > Thus as I raised before in relation to the RAMS work that there > > appeared > > to be a need for defining this properly, including this aspect. Do = we > > have anyone that is interested in defining this? > > > > Secondly I think there clearly are some improvements needed of the = WG > > document based on what you comment. One thing is clearly to clarify = the > > WG document on its usages, and then map those usages of suppression = to > > different topologies. > > > > My personal opinion on how to handle your comments are to include = your > > concerns in the WG document. > > > > Cheers > > > > Magnus Westerlund > > > > = ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > = ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > = ---------------------------------------------------------------------- > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Sun Jun 19 13:38:39 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B8911E80E0 for ; Sun, 19 Jun 2011 13:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0GOLOIC1ntj for ; Sun, 19 Jun 2011 13:38:38 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6C34811E8077 for ; Sun, 19 Jun 2011 13:38:38 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN200MWA1CDG6@szxga04-in.huawei.com> for avt@ietf.org; Mon, 20 Jun 2011 04:38:37 +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 <0LN200ARW1CD3K@szxga04-in.huawei.com> for avt@ietf.org; Mon, 20 Jun 2011 04:38:37 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-47-132.red.bezeqint.net [79.181.47.132]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN200E2H1C7I6@szxml12-in.huawei.com>; Mon, 20 Jun 2011 04:38:37 +0800 (CST) Date: Sun, 19 Jun 2011 23:36:38 +0300 From: Roni Even In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540F4408AF@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , 'IETF AVTCore WG' , 'VAN CAENEGEM Tom' Message-id: <004801cc2ec0$9ac3e630$d04bb290$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcvroApIveZeR4mXT1CxBcCiD4iXBxC5bN+gAAl5A5AABTWEAA== References: <4D8DBEDB.4090406@ericsson.com> <004401cc2e87$523c06b0$f6b41410$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540F4408AF@xmb-sjc-215.amer.cisco.com> Cc: 'Magnus Westerlund' Subject: Re: [AVTCORE] Commentson draft-vancaenegem-avtcore-fb-supp-and-retransm-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 20:38:39 -0000 Hi Ali, Sorry about my email, I read the retransmission-for-ssm and my comments are on that draft. Roni > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Sunday, June 19, 2011 9:07 PM > To: Roni Even; IETF AVTCore WG; VAN CAENEGEM Tom > Cc: Magnus Westerlund > Subject: RE: [AVTCORE] Commentson draft-vancaenegem-avtcore-fb-supp- > and-retransm-00 >=20 > Did you check > https://datatracker.ietf.org/doc/draft-vancaenegem-avtcore- > retransmission-for-ssm/ > ? It addresses at least some of the points you made below. >=20 > -acbegen >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of > Roni Even > > Sent: Sunday, June 19, 2011 6:47 AM > > To: 'IETF AVTCore WG'; 'VAN CAENEGEM Tom' > > Cc: 'Magnus Westerlund' > > Subject: Re: [AVTCORE] Commentson draft-vancaenegem-avtcore-fb-supp- > and-retransm-00 > > > > Hi, > > I have finally found the time to read the document. I agree with > Magnus that > > the issue of retransmission in the RAMS architecture where the RS = and > FT are > > collocated is not specified and it should also be reflected in the > feedback > > suppression draft. > > I think the draft has good text on the analysis of the feedback > suppression > > and this should be added to the WG document. Maybe Tom and Qin can > work on > > the WG document on this topic. > > As for the retransmission, I am not sure if this should be as part = of > the > > suppression draft. If the issue is only for the case where we have > the FT/RS > > collocated with unicast feedback as in the RAMS case maybe it can be > in the > > RAMS scenario draft. If we are looking at a broader retransmission > case > > (that is not well specified in current draft) that includes also the > > multicast retransmission from the RS or from the DS it may be good = to > > discuss it as part of the WG document. > > > > Regards > > Roni > > > > > > > > > -----Original Message----- > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf > Of > > > Magnus Westerlund > > > Sent: Saturday, March 26, 2011 12:24 PM > > > To: IETF AVTCore WG; VAN CAENEGEM Tom > > > Subject: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp- > and- > > > retransm-00 > > > > > > Tom, AVTCORE, > > > > > > I have reviewed this draft and have the following comment. > > > > > > To me it appears that one big reason for the issues is actually > that we > > > haven't specified how RTP retransmission in SSM with unicast > delivery > > > is > > > supposed to work. Because if that was well defined we would likely > have > > > concluded that one should not forward NACK request to the DS from = a > FT > > > for any request it service locally. > > > > > > Thus as I raised before in relation to the RAMS work that there > > > appeared > > > to be a need for defining this properly, including this aspect. Do > we > > > have anyone that is interested in defining this? > > > > > > Secondly I think there clearly are some improvements needed of the > WG > > > document based on what you comment. One thing is clearly to = clarify > the > > > WG document on its usages, and then map those usages of = suppression > to > > > different topologies. > > > > > > My personal opinion on how to handle your comments are to include > your > > > concerns in the WG document. > > > > > > Cheers > > > > > > Magnus Westerlund > > > > > > = ------------------------------------------------------------------- > --- > > > Multimedia Technologies, Ericsson Research EAB/TVM > > > = ------------------------------------------------------------------- > --- > > > Ericsson AB | Phone +46 10 7148287 > > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > > SE-164 80 Stockholm, Sweden| mailto: = magnus.westerlund@ericsson.com > > > = ------------------------------------------------------------------- > --- > > > _______________________________________________ > > > Audio/Video Transport Core Maintenance > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Sun Jun 19 14:14:18 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE5D21F84FD for ; Sun, 19 Jun 2011 14:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS9M8dUsALqU for ; Sun, 19 Jun 2011 14:14:18 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 296A921F84B3 for ; Sun, 19 Jun 2011 14:14:18 -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 <0LN2005332ZRIG@szxga03-in.huawei.com> for avt@ietf.org; Mon, 20 Jun 2011 05:14:15 +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 <0LN20086X2ZR8R@szxga03-in.huawei.com> for avt@ietf.org; Mon, 20 Jun 2011 05:14:15 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-47-132.red.bezeqint.net [79.181.47.132]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN200EDQ2ZJI6@szxml12-in.huawei.com>; Mon, 20 Jun 2011 05:14:15 +0800 (CST) Date: Mon, 20 Jun 2011 00:12:14 +0300 From: Roni Even In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540F4408AF@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , 'IETF AVTCore WG' , 'VAN CAENEGEM Tom' Message-id: <004c01cc2ec5$94e125c0$bea37140$%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: AcvroApIveZeR4mXT1CxBcCiD4iXBxC5bN+gAAl5A5AABWgJcA== References: <4D8DBEDB.4090406@ericsson.com> <004401cc2e87$523c06b0$f6b41410$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540F4408AF@xmb-sjc-215.amer.cisco.com> Cc: 'Magnus Westerlund' Subject: Re: [AVTCORE] Comments ondraft-vancaenegem-avtcore-retransmission-for-ssm X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 21:14:19 -0000 Hi, Here are more detailed comments on the draft. Still I think that part of it should be in the WG draft on feedback suppression while I am not sure about the RAMS with retransmission case. 1. The draft starts in the introduction with general view but talks about SSM with unicast retransmission where the RS is co-located with FT and the Burst Source. 2. The third paragraph of the introduction " it will particularly focus on the impact of packet loss events experienced in an SSM distribution , and how the elements in the SSM architecture interact best to ensure impacted RTP_Rx's are provided with appropriate RTP retransmissions." But reading the draft I think that the focus is on the case where there is also a RS with the FT and this is not the general SSM but more the RAMS case or at least the case of SSM with unicast retransmission support from the FT and not from the DS. 3.In the introduction the third bullet should also mention the third party packet loss report 4. the introduction says " This document describes the behavior for all entities defined in an SSM architecture with unicast feedback as described in [RFC5760] (DS, FT, RS and RTP_Rx) addressing feedback implosion (avoidance), retransmission efficacy and congestion concerns.". this is what being discussed in the WG retransmission suppression f=draft and no need to repeat it here. RFC5760 does not discuss the retransmission which is what I assumed is the focus of this draft. 5. I am not sure why section 4.1 and 4.2 repeat text that is in suppression draft (section 3 and 6). If it is not complete there than suggest text update to the draft. 6. In section 5.1 " When the DS is capable of recovering the lost packet in due time, it may send an unsolicited retransmission to all RTP_Rx's". I was wondering if the DS cannot send the recovered packets as regular packets if did not receive and NACKs from down stream. No need for retransmission at all. 7.in section 5.3 "Note that we again assume that the RTP_Rx's behave compliant to [RFC4585], inclusive conformance to the feedback suppression rule. " I think it will be good to reference also the suppression draft to explain the conformance. 8. Section 6 title is " Rules for SSM with Retransmissions" I think it should be "Rules for SSM with Retransmissions where RS is collocated with FT" 9. In section 6.2 for the in-band mode how does the DS know the ssrcs of the FT when sending the in-band message. 10. In section 6.3 the draft says " Unsolicited retransmissions can be provided over each of the established unicast retransmission sessions or only once in a single multicast retransmission session, sourced either by the DS or by the RS.". the discussion before was talking about the RS with FT and not DS. I think that when the DS sends the retransmission there is no need to add text to the current drafts. 11.in section 6.3 second bullet, it is generally true but unicast will work in the RAMS case. 12. In section 6.3 the second requirement for unsolicited retransmission. I think that for the multicast case the RS will not know what the receivers support but it can send the retransmission anyhow since my assumption is that it got at least one NACK message that will trigger the retransmission. 13. On the editor note in 6.3. For the unicast case the RTP-Rx will need to support the port mapping draft. Regards Roni From magnus.westerlund@ericsson.com Mon Jun 20 07:42:58 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F0A11E8123 for ; Mon, 20 Jun 2011 07:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfEZH5x+ndtU for ; Mon, 20 Jun 2011 07:42:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF4F11E80A4 for ; Mon, 20 Jun 2011 07:42:57 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-09-4dff5c70c26e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9E.5E.20773.07C5FFD4; Mon, 20 Jun 2011 16:42:56 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 20 Jun 2011 16:42:55 +0200 Message-ID: <4DFF5C6F.10006@ericsson.com> Date: Mon, 20 Jun 2011 16:42:55 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF AVTCore WG References: <20110617211504.32001.68151.idtracker@ietfa.amsl.com> In-Reply-To: <20110617211504.32001.68151.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] I-D ACTION:draft-ietf-avt-forward-shifted-red-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 14:42:58 -0000 WG, Please be aware that this document is now ready for being approved. In the discuss clearing process the media type was changed to make to make the "forwardshift" parameter mandatory. There was also make clear that the rest of the parameters that exist for the regular RED type also are needed for this one. Diff for all the discuss clearing changes: https://tools.ietf.org/rfcdiff?url1=draft-ietf-avt-forward-shifted-red-06&difftype=--html&submit=Go!&url2=draft-ietf-avt-forward-shifted-red-08 If you have issues yell ASAP as I don't see any issues with it and recommend progression in a timely manner. Cheers Magnus On 2011-06-17 23:15, Internet-Drafts@ietf.org wrote: > A new Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Forward-shifted RTP Redundancy Payload Support > Author(s) : Q. Xie > Filename : draft-ietf-avt-forward-shifted-red-08.txt > Pages : 13 > Date : 2011-06-17 > > > This document defines a simple enhancement to support RTP sessions > with forward-shifted redundant encodings, i.e., redundant data sent > before the corresponding primary data. Forward-shifted redundancy > can be used to conceal losses of a large number of consecutive media > frames (e.g., consecutive loss of seconds or even tens of seconds of > media). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-forward-shifted-red-08.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. -- 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 Mon Jun 20 08:56:50 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8109E802F for ; Mon, 20 Jun 2011 08:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lzd5sXmcj04o for ; Mon, 20 Jun 2011 08:56:50 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id E445C9E800D for ; Mon, 20 Jun 2011 08:56:49 -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 p5KFud16008570 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 Jun 2011 17:56:39 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 20 Jun 2011 17:56:39 +0200 From: "Van Caenegem, Tom (Tom)" To: Roni Even , "'IETF AVTCore WG'" Date: Mon, 20 Jun 2011 17:56:37 +0200 Thread-Topic: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and-retransm-00 Thread-Index: AcvroApIveZeR4mXT1CxBcCiD4iXBxC5bN+gADSqsTA= Message-ID: References: <4D8DBEDB.4090406@ericsson.com> <004401cc2e87$523c06b0$f6b41410$%roni@huawei.com> In-Reply-To: <004401cc2e87$523c06b0$f6b41410$%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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: 'Magnus Westerlund' Subject: Re: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and-retransm-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:56:50 -0000 Hi Roni, At the meeting in Prague I got indeed some positive feedback on "draft-vanc= aenegem-avtcore-fb-supp-and-retransm-00", which I submitted because the way= one does feedback suppression is very much impacting the retransmission. T= here is also a strong dependency on topology where the RAMS architecture (S= SM with multiple disjoint FT) represents my main interest. Because Magnus h= as expressed several times he felt that even though RAMS includes elements = related to retransmission, still some holes were left related to retransmis= sion for SSM with a RAMS-like architecture. So, I made a new submission dra= ft-vancaenegem-avtcore-retransmission-for-ssm, in line with Magnus' comment= s. This draft takes over the main elements from "draft-vancaenegem-avtcore-= fb-supp-and-retransm-00" (in fact replaces it) and adds new items such as = congestion avoidance considerations/rules , as well as multicast/unsollicit= ed retransmission, and is focusing on SSM with disjoint FT/RS architecture. The WG draft on feedback suppression has nothing to do with retransmission = (this has been discussed on the mailing list quite some time ago), and basi= cally defines the suppression message. So, I disagree with your view here. = I still have comments on this draft (some of them are outstanding and have = not really been resolved -also part of the reason I submitted "draft-vancae= negem-avtcore-fb-supp-and-retransm-00"). I will provide my comments on the = most recent version soon. Regards, Tom=20 =20 -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: zondag 19 juni 2011 15:47 To: 'IETF AVTCore WG'; Van Caenegem, Tom (Tom) Cc: 'Magnus Westerlund' Subject: RE: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and-re= transm-00 Hi, I have finally found the time to read the document. I agree with Magnus tha= t the issue of retransmission in the RAMS architecture where the RS and FT = are collocated is not specified and it should also be reflected in the feed= back suppression draft. I think the draft has good text on the analysis of the feedback suppression= and this should be added to the WG document. Maybe Tom and Qin can work on= the WG document on this topic. As for the retransmission, I am not sure if this should be as part of the s= uppression draft. If the issue is only for the case where we have the FT/RS= collocated with unicast feedback as in the RAMS case maybe it can be in th= e RAMS scenario draft. If we are looking at a broader retransmission case (= that is not well specified in current draft) that includes also the multica= st retransmission from the RS or from the DS it may be good to discuss it a= s part of the WG document. Regards Roni > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of=20 > Magnus Westerlund > Sent: Saturday, March 26, 2011 12:24 PM > To: IETF AVTCore WG; VAN CAENEGEM Tom > Subject: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and- > retransm-00 >=20 > Tom, AVTCORE, >=20 > I have reviewed this draft and have the following comment. >=20 > To me it appears that one big reason for the issues is actually that=20 > we haven't specified how RTP retransmission in SSM with unicast=20 > delivery is supposed to work. Because if that was well defined we=20 > would likely have concluded that one should not forward NACK request=20 > to the DS from a FT for any request it service locally. >=20 > Thus as I raised before in relation to the RAMS work that there=20 > appeared to be a need for defining this properly, including this=20 > aspect. Do we have anyone that is interested in defining this? >=20 > Secondly I think there clearly are some improvements needed of the WG=20 > document based on what you comment. One thing is clearly to clarify=20 > the WG document on its usages, and then map those usages of=20 > suppression to different topologies. >=20 > My personal opinion on how to handle your comments are to include your=20 > concerns in the WG document. >=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 > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance avt@ietf.org=20 > https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Mon Jun 20 14:29:34 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7390611E8213 for ; Mon, 20 Jun 2011 14:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[AWL=1.369, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mudkxFvJjHdu for ; Mon, 20 Jun 2011 14:29:33 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2932911E81FC for ; Mon, 20 Jun 2011 14:29:32 -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 <0LN300KR6YCIVS@szxga03-in.huawei.com> for avt@ietf.org; Tue, 21 Jun 2011 05:29:06 +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 <0LN300KLRYCISZ@szxga03-in.huawei.com> for avt@ietf.org; Tue, 21 Jun 2011 05:29:06 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-35-190.red.bezeqint.net [79.176.35.190]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN3000ZTYCBHA@szxml12-in.huawei.com>; Tue, 21 Jun 2011 05:29:06 +0800 (CST) Date: Tue, 21 Jun 2011 00:27:06 +0300 From: Roni Even In-reply-to: To: "'Van Caenegem, Tom (Tom)'" , 'IETF AVTCore WG' Message-id: <00bc01cc2f90$d2637030$772a5090$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcvroApIveZeR4mXT1CxBcCiD4iXBxC5bN+gADSqsTAADePiMA== References: <4D8DBEDB.4090406@ericsson.com> <004401cc2e87$523c06b0$f6b41410$%roni@huawei.com> Cc: 'Magnus Westerlund' Subject: Re: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp-and-retransm-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 21:29:34 -0000 Hi Tom, I see two separate issues as I mentioned in my other email. My commentes were about the ssm and not about the fb-supp-and-retansm The first comment is that the ssm draft should be in line with the WG suppression draft where the issue of when NACKs can be sent is = explained.=20 The second comment is that the ssm draft focus on the case where the RS = is located with the FT which is one case for SSM (this is more the RAMS architecture). THe RS can reside with the DS or be a separate entity. = Also the retransmission can be done using unicast or multicast. If the draft = want to address the general retransmission issue for SSM all these options = should be discussed. Roni > -----Original Message----- > From: Van Caenegem, Tom (Tom) [mailto:tom.van_caenegem@alcatel- > lucent.com] > Sent: Monday, June 20, 2011 6:57 PM > To: Roni Even; 'IETF AVTCore WG' > Cc: 'Magnus Westerlund' > Subject: RE: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp- > and-retransm-00 >=20 > Hi Roni, >=20 > At the meeting in Prague I got indeed some positive feedback on = "draft- > vancaenegem-avtcore-fb-supp-and-retransm-00", which I submitted = because > the way one does feedback suppression is very much impacting the > retransmission. There is also a strong dependency on topology where = the > RAMS architecture (SSM with multiple disjoint FT) represents my main > interest. Because Magnus has expressed several times he felt that even > though RAMS includes elements related to retransmission, still some > holes were left related to retransmission for SSM with a RAMS-like > architecture. So, I made a new submission draft-vancaenegem-avtcore- > retransmission-for-ssm, in line with Magnus' comments. This draft = takes > over the main elements from "draft-vancaenegem-avtcore-fb-supp-and- > retransm-00" (in fact replaces it) and adds new items such as > congestion avoidance considerations/rules , as well as > multicast/unsollicited retransmission, and is focusing on SSM with > disjoint FT/RS architecture. >=20 > The WG draft on feedback suppression has nothing to do with > retransmission (this has been discussed on the mailing list quite some > time ago), and basically defines the suppression message. So, I > disagree with your view here. I still have comments on this draft = (some > of them are outstanding and have not really been resolved -also part = of > the reason I submitted = "draft-vancaenegem-avtcore-fb-supp-and-retransm- > 00"). I will provide my comments on the most recent version soon. >=20 > Regards, >=20 > Tom >=20 >=20 >=20 >=20 > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: zondag 19 juni 2011 15:47 > To: 'IETF AVTCore WG'; Van Caenegem, Tom (Tom) > Cc: 'Magnus Westerlund' > Subject: RE: [AVTCORE] Comments on draft-vancaenegem-avtcore-fb-supp- > and-retransm-00 >=20 > Hi, > I have finally found the time to read the document. I agree with = Magnus > that the issue of retransmission in the RAMS architecture where the RS > and FT are collocated is not specified and it should also be reflected > in the feedback suppression draft. > I think the draft has good text on the analysis of the feedback > suppression and this should be added to the WG document. Maybe Tom and > Qin can work on the WG document on this topic. > As for the retransmission, I am not sure if this should be as part of > the suppression draft. If the issue is only for the case where we have > the FT/RS collocated with unicast feedback as in the RAMS case maybe = it > can be in the RAMS scenario draft. If we are looking at a broader > retransmission case (that is not well specified in current draft) that > includes also the multicast retransmission from the RS or from the DS > it may be good to discuss it as part of the WG document. >=20 > Regards > Roni >=20 >=20 >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of > > Magnus Westerlund > > Sent: Saturday, March 26, 2011 12:24 PM > > To: IETF AVTCore WG; VAN CAENEGEM Tom > > Subject: [AVTCORE] Comments on = draft-vancaenegem-avtcore-fb-supp-and- > > retransm-00 > > > > Tom, AVTCORE, > > > > I have reviewed this draft and have the following comment. > > > > To me it appears that one big reason for the issues is actually that > > we haven't specified how RTP retransmission in SSM with unicast > > delivery is supposed to work. Because if that was well defined we > > would likely have concluded that one should not forward NACK request > > to the DS from a FT for any request it service locally. > > > > Thus as I raised before in relation to the RAMS work that there > > appeared to be a need for defining this properly, including this > > aspect. Do we have anyone that is interested in defining this? > > > > Secondly I think there clearly are some improvements needed of the = WG > > document based on what you comment. One thing is clearly to clarify > > the WG document on its usages, and then map those usages of > > suppression to different topologies. > > > > My personal opinion on how to handle your comments are to include > your > > concerns in the WG document. > > > > Cheers > > > > Magnus Westerlund > > > > = --------------------------------------------------------------------- > - > > Multimedia Technologies, Ericsson Research EAB/TVM > > = --------------------------------------------------------------------- > - > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > = --------------------------------------------------------------------- > - > > _______________________________________________ > > Audio/Video Transport Core Maintenance avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt From tom.van_caenegem@alcatel-lucent.com Tue Jun 21 01:36:27 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7F69E8011 for ; Tue, 21 Jun 2011 01:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 153ydpShwB1m for ; Tue, 21 Jun 2011 01:36:26 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEFF9E8008 for ; Tue, 21 Jun 2011 01:36:26 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5L8a7UF020450 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Jun 2011 10:36:13 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 21 Jun 2011 10:36:11 +0200 From: "Van Caenegem, Tom (Tom)" To: Roni Even , "'Ali C. Begen (abegen)'" , "'IETF AVTCore WG'" Date: Tue, 21 Jun 2011 10:36:09 +0200 Thread-Topic: [AVTCORE] Comments ondraft-vancaenegem-avtcore-retransmission-for-ssm Thread-Index: AcvroApIveZeR4mXT1CxBcCiD4iXBxC5bN+gAAl5A5AABWgJcAAr6Qzg Message-ID: References: <4D8DBEDB.4090406@ericsson.com> <004401cc2e87$523c06b0$f6b41410$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540F4408AF@xmb-sjc-215.amer.cisco.com> <004c01cc2ec5$94e125c0$bea37140$%roni@huawei.com> In-Reply-To: <004c01cc2ec5$94e125c0$bea37140$%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.13 Cc: 'Magnus Westerlund' Subject: Re: [AVTCORE] Comments ondraft-vancaenegem-avtcore-retransmission-for-ssm X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 08:36:27 -0000 Hi Roni, See also my previous post on the subject. Please, find below my responses o= n your comments. Tom=20 -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: zondag 19 juni 2011 23:12 To: 'Ali C. Begen (abegen)'; 'IETF AVTCore WG'; Van Caenegem, Tom (Tom) Cc: 'Magnus Westerlund' Subject: RE: [AVTCORE] Comments ondraft-vancaenegem-avtcore-retransmission-= for-ssm Hi, Here are more detailed comments on the draft. Still I think that part of it= should be in the WG draft on feedback suppression while I am not sure abou= t the RAMS with retransmission case. 1. The draft starts in the introduction with general view but talks about S= SM with unicast retransmission where the RS is co-located with FT and the B= urst Source. Tom: not sure where you see a conflict?=20 2. The third paragraph of the introduction " it will particularly focus on = the impact of packet loss events experienced in an SSM distribution , and h= ow the elements in the SSM architecture interact best to ensure impacted RT= P_Rx's are provided with appropriate RTP retransmissions." But reading the = draft I think that the focus is on the case where there is also a RS with t= he FT and this is not the general SSM but more the RAMS case or at least th= e case of SSM with unicast retransmission support from the FT and not from = the DS. Tom: the draft only considers retransmission-capable RFC 5760 architectures= , that is SSM with unicast feedback. This includes the case where the FT i= s integrated within the DS, and in that case also the RSo is hosted at the = DS. Then of course retransmission is sourced from the DS.=20 But even if FTs are disjoint from the DS and which host also a Rso, nothing= prevents a DS to also host a RSo providing retransmissions over multicast = as indicated in section 6.3 =20 Question: What is for you the general SSM architecture with retransmission = enabled? Is this an architecture where an FT is not co-located with a Retra= nsmission Source? I do not see which advantage that brings, but we can add = text that mentions this possibility. 3.In the introduction the third bullet should also mention the third party = packet loss report Tom: the 3rd party loss report is a RTCP FB message, so it is covered by th= e third bullet 4. the introduction says " This document describes the behavior for all ent= ities defined in an SSM architecture with unicast feedback as described in = [RFC5760] (DS, FT, RS and RTP_Rx) addressing feedback implosion (avoidance), retransmi= ssion efficacy and congestion concerns.". this is what being discussed in t= he WG retransmission suppression f=3Ddraft and no need to repeat it here. R= FC5760 does not discuss the retransmission which is what I assumed is the f= ocus of this draft. Tom: (nearly) the whole point of this draft is that the behaviour as prescr= ibed in RFC5760 is not well suited for retransmission-enabled SSM architect= ures with unicast feedback. We describe some rules here that are different = from RFC 5760. Moreover the WG suppression draft is not about retransmissio= n. 5. I am not sure why section 4.1 and 4.2 repeat text that is in suppression= draft (section 3 and 6). If it is not complete there than suggest text upd= ate to the draft. Tom: see my previous point. 6. In section 5.1 " When the DS is capable of recovering the lost packet in= due time, it may send an unsolicited retransmission to all RTP_Rx's". I wa= s wondering if the DS cannot send the recovered packets as regular packets = if did not receive and NACKs from down stream. No need for retransmission a= t all. Tom: The situation is that the DS has already sent the original packet(s) a= nd RTP Rx did detect the original packet(s) as missing. So, we are talking = about retransmission 7.in section 5.3 "Note that we again assume that the RTP_Rx's behave compli= ant to [RFC4585], inclusive conformance to the feedback suppression rule. "= I think it will be good to reference also the suppression draft to explain= the conformance. Tom: The WG draft -for some reason- expresses that an RTP Rx should suppres= s its FB, whereas RFC 4585 has a MUST indication =20 8. Section 6 title is " Rules for SSM with Retransmissions" I think it shou= ld be "Rules for SSM with Retransmissions where RS is collocated with FT" Tom: I can add that, but I do not want to exclude that also the DS hosts a = retransmission source. 9. In section 6.2 for the in-band mode how does the DS know the ssrcs of th= e FT when sending the in-band message. Tom: the different modes I listed relate to informing the RTP receivers (no= t the DS) of the SSRC of their FT. The DS can be configured with an out-of= -band method. 10. In section 6.3 the draft says " Unsolicited retransmissions can be prov= ided over each of the established unicast retransmission sessions or only o= nce in a single multicast retransmission session, sourced either by the DS or by= the RS.". the discussion before was talking about the RS with FT and not D= S. I think that when the DS sends the retransmission there is no need to add t= ext to the current drafts. Tom: I do not see the problem here? Unsolicited retransmission AFAIK have n= ot been addressed in other drafts/RFCs. 11.in section 6.3 second bullet, it is generally true but unicast will work= in the RAMS case. Tom: OK 12. In section 6.3 the second requirement for unsolicited retransmission. = I think that for the multicast case the RS will not know what the receivers= support but it can send the retransmission anyhow since my assumption is t= hat it got at least one NACK message that will trigger the retransmission. Tom: this rule is there in order to make sure that unsolicited retransmissi= on are in the majority of cases only sent to receivers that really "require= " this retransmission, but they suppressed their FB, so the RS does not alw= ays know whether receivers have detected a missing packet.=20 13. On the editor note in 6.3. For the unicast case the RTP-Rx will need to= support the port mapping draft.=20 Tom: I agree, but how is this related to the note? Regards Roni From tom.van_caenegem@alcatel-lucent.com Tue Jun 21 02:30:18 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C14821F850B for ; Tue, 21 Jun 2011 02:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eAc6Rla9DAm for ; Tue, 21 Jun 2011 02:30:17 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7207321F84D2 for ; Tue, 21 Jun 2011 02:30:17 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5L9Sfq7001909 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Jun 2011 11:30:10 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 21 Jun 2011 11:29:55 +0200 From: "Van Caenegem, Tom (Tom)" To: Qin Wu , "'IETF AVTCore WG'" , Roni Even Date: Tue, 21 Jun 2011 11:29:53 +0200 Thread-Topic: Comments on draft-ietf-avtcore-feedback-supression-rtp-04 Thread-Index: Acwv9cbj3rppvW+LTjeQyurT6E3Z7w== 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: 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: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 09:30:18 -0000 Hi, as promised, these are comments I have on the draft " RTCP Extension for Th= ird-party Loss Report" =20 -IMO the draft does not provide a good rationale on the use case for sendin= g this new report. The section 3 (protocol overview) says: =20 "If an intermediary receives a NACK from another system, it should redistri= bute that NACK to all other systems that would not otherwise receive it. A= n example of this is RTCP-SSM in simple feedback model [RFC5760], where the= distribution source reflects NACKs to other systems. =20 If an intermediary receives a NACK from another system, but, for some reaso= n, cannot redistribute that NACK, then it may send a third-party loss repor= t to the systems that were unable to receive the NACK, and won't receive th= e NACK via other means. An example would be a distribution source using RTC= P-SSM in Distribution Source Feedback Summary model [RFC5760]." My questions:=20 -why would the intermediary not be able or capable to send the received NAC= K to the "systems" that were unable to receive the NACK, whereas it would b= e able or capable to send the 3rd party loss report to those same "systems"= ?=20 -The DS in RTCP-SSM operating in FB summary mode is mentioned as an example= for a case where a NACK cannnot be forwarded. Why is this? RFC5760 does n= ot prevent a DS to foward the NACK (see the RFC 5760 and my quote from that= RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00" -This section 3 makes a distinction between an intermediate that does check= the RTP stream for missing packets itself, and an intermediate that does n= ot, but still the behaviour in terms of FW-ing the NACKs received from othe= r "systems" is exactly the same. Why make this distinction then? I still have an outstanding comment which has not been resolved yet. The se= ction 6.1. and 6.1.1. take RFC 5760 as use case architectures, but section = 6.1.1. talks about two distribution sources, whereas RFC 5760 only defined = ONE SINGLE DS. Please clarify this. Regards Tom= From csp@csperkins.org Tue Jun 21 07:08:05 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847A111E815A for ; Tue, 21 Jun 2011 07:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.481 X-Spam-Level: X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO889jgN3vkz for ; Tue, 21 Jun 2011 07:08:04 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id AB5F011E814F for ; Tue, 21 Jun 2011 07:08:04 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QZ1cZ-0001PB-nh; Tue, 21 Jun 2011 14:08:03 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Tue, 21 Jun 2011 15:07:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Van Caenegem, Tom (Tom)" X-Mailer: Apple Mail (2.1084) Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 14:08:05 -0000 On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: > Hi, >=20 > as promised, these are comments I have on the draft " RTCP Extension = for Third-party Loss Report" >=20 > -IMO the draft does not provide a good rationale on the use case for = sending this new report. The section 3 (protocol overview) says: >=20 > "If an intermediary receives a NACK from another system, it should = redistribute that NACK to all other systems that would not otherwise = receive it. An example of this is RTCP-SSM in simple feedback model = [RFC5760], where the distribution source reflects NACKs to other = systems. =20 > If an intermediary receives a NACK from another system, but, for some = reason, cannot redistribute that NACK, then it may send a third-party = loss report to the systems that were unable to receive the NACK, and = won't receive the NACK via other means. An example would be a = distribution source using RTCP-SSM in Distribution Source Feedback = Summary model [RFC5760]." >=20 > My questions:=20 >=20 > -why would the intermediary not be able or capable to send the = received NACK to the "systems" that were unable to receive the NACK, = whereas it would be able or capable to send the 3rd party loss report to = those same "systems"?=20 Because the intermediary is trying to hide the identity or existence of = those systems, and cannot forward the NACK from them without revealing = that information. > -The DS in RTCP-SSM operating in FB summary mode is mentioned as an = example for a case where a NACK cannnot be forwarded. Why is this? = RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and = my quote from that RFC in = "draft-vancaenegem-avtcore-retransmission-for-ssm-00" RFC 5760 allows the NACK to be forwarded, but this would cause the other = receivers to become aware of, and keep state for, the participant that = sent the NACK. If a third-party loss report is used, the other receivers = don't become aware of the participant that signalled the loss, they just = know that the loss occurred.=20 > -This section 3 makes a distinction between an intermediate that does = check the RTP stream for missing packets itself, and an intermediate = that does not, but still the behaviour in terms of FW-ing the NACKs = received from other "systems" is exactly the same. Why make this = distinction then? >=20 > I still have an outstanding comment which has not been resolved yet. = The section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but = section 6.1.1. talks about two distribution sources, whereas RFC 5760 = only defined ONE SINGLE DS. Please clarify this. >=20 > Regards > Tom > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Tue Jun 21 07:57:42 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E77411E8249 for ; Tue, 21 Jun 2011 07:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.489 X-Spam-Level: X-Spam-Status: No, score=-103.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4-oZPhi-Afk for ; Tue, 21 Jun 2011 07:57:41 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4B21311E807E for ; Tue, 21 Jun 2011 07:57:41 -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 1QZ2MW-0002eL-dc; Tue, 21 Jun 2011 14:55:39 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins X-Priority: 3 In-Reply-To: Date: Tue, 21 Jun 2011 15:55:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110616092110.1754.68542.idtracker@ietfa.amsl.com> To: Qin Wu X-Mailer: Apple Mail (2.1084) Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 14:57:42 -0000 Qin, This does address many of my comments on the earlier versions. Some = quick comments on this draft: - In Section 5.2, there is no need to report the CNAME, since this is = redundant with RTCP SDES information.=20 - Section 5.2 suggests reporting =93the sequence number of the first = packet of the RTP session=94. A receiver cannot know what is the first = packet of the session, only what was the first packet it received, so = this should be clarified to =93the sequence number of the first packet = received in the RTP session=94. The first sequence number received also = becomes less useful after the sequence number space wraps around, so it = might make sense to include a count of sequence number cycles since = then. - Section 5.3 discusses sending information that can be used to = correlate an RTP source with non-RTP protocols. This seems like a = reasonable thing to add. However, since it is describing the source, = rather than providing a quality report, should this be an new RTCP SDES = block type, rather than an RTCP XR block? Colin On 16 Jun 2011, at 10:29, Qin Wu wrote: > Hi,: > In response to the recent comments and suggestion on the list, a new = version of draft-ietf-avtcore-monarch is just submitted. > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt > The diff is: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-03 >=20 > Please check if your comments are addressed in this version. >=20 > Regards! > -Qin >=20 > ----- Original Message -----=20 > From: > To: > Cc: > Sent: Thursday, June 16, 2011 5:21 PM > Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt >=20 >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >>=20 >> Title : Monitoring Architectures for RTP >> Author(s) : Qin Wu >> Geoff Hunt >> Philip Arden >> Filename : draft-ietf-avtcore-monarch-03.txt >> Pages : 23 >> Date : 2011-06-16 >>=20 >> This memo proposes an architecture for extending RTCP with a new = RTCP >> XR (RFC3611) block type to report new metrics regarding media >> transmission or reception quality, as proposed in RFC5968. This = memo >> suggests that a new block should contain a single metric or a small >> number of metrics relevant to a single parameter of interest or >> concern, rather than containing a number of metrics which attempt to >> provide full coverage of all those parameters of concern to a >> specific application. Applications may then "mix and = match" to >> create a set of blocks which covers their set of concerns. Where >> possible, a specific block should be designed to be re-usable across >> more than one application, for example, for all of voice, streaming >> audio and video. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >>=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From tom.van_caenegem@alcatel-lucent.com Tue Jun 21 08:05:47 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4893C21F852F for ; Tue, 21 Jun 2011 08:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0GqLqnulaOM for ; Tue, 21 Jun 2011 08:05:45 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id A84E921F851D for ; Tue, 21 Jun 2011 08:05:16 -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 p5LF2esB017765 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Jun 2011 17:04:29 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 21 Jun 2011 17:04:24 +0200 From: "Van Caenegem, Tom (Tom)" To: Colin Perkins Date: Tue, 21 Jun 2011 17:04:23 +0200 Thread-Topic: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 Thread-Index: AcwwHKalQ95WlpeDR6qJrzuC9hudKwAALRNw Message-ID: References: In-Reply-To: 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 Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:05:47 -0000 Hi Colin, Thx for sharing your view. See below.=20 -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: dinsdag 21 juni 2011 16:08 To: Van Caenegem, Tom (Tom) Cc: Qin Wu; 'IETF AVTCore WG'; Roni Even Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-r= tp-04 On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: > Hi, >=20 > as promised, these are comments I have on the draft " RTCP Extension for = Third-party Loss Report" >=20 > -IMO the draft does not provide a good rationale on the use case for send= ing this new report. The section 3 (protocol overview) says: >=20 > "If an intermediary receives a NACK from another system, it should redist= ribute that NACK to all other systems that would not otherwise receive it. = An example of this is RTCP-SSM in simple feedback model [RFC5760], where t= he distribution source reflects NACKs to other systems. =20 > If an intermediary receives a NACK from another system, but, for some rea= son, cannot redistribute that NACK, then it may send a third-party loss rep= ort to the systems that were unable to receive the NACK, and won't receive = the NACK via other means. An example would be a distribution source using R= TCP-SSM in Distribution Source Feedback Summary model [RFC5760]." >=20 > My questions:=20 >=20 > -why would the intermediary not be able or capable to send the received N= ACK to the "systems" that were unable to receive the NACK, whereas it would= be able or capable to send the 3rd party loss report to those same "system= s"?=20 Because the intermediary is trying to hide the identity or existence of tho= se systems, and cannot forward the NACK from them without revealing that in= formation. Tom: well.. This is a new element you bring in here.. I can only guess why= this rationale has not been explicitly included before in a WG document? D= id I miss this discussion? It is certainly not aligned with the text/reason= ing in the draft because a DS operating in simple FB mode is an example whe= re the forwarding of NACKs seems to be the right thing to do (and not sendi= ng the 3rd party loss report) whereas a DS in summary FB mode is an example= that would send 3rd party loss message. Why is hiding the identity an issu= e for the latter case (SSM in summary mode) and not for the former case (si= mple FB mode)?=20 Also, the draft is about FB storm suppression which is also realised with N= ACKs as you know... An incoming NACK can also be "anonimised" by having the= DS or the FT acting as a translator for this NACK message. See draft-vanca= enegem-avtcore-retransmission-for-ssm-00. > -The DS in RTCP-SSM operating in FB summary mode is mentioned as an examp= le for a case where a NACK cannnot be forwarded. Why is this? RFC5760 does= not prevent a DS to foward the NACK (see the RFC 5760 and my quote from th= at RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00" RFC 5760 allows the NACK to be forwarded, but this would cause the other re= ceivers to become aware of, and keep state for, the participant that sent t= he NACK. If a third-party loss report is used, the other receivers don't be= come aware of the participant that signalled the loss, they just know that = the loss occurred.=20 Tom: why is keeping state "required" here? Keeping state of what?=20 > -This section 3 makes a distinction between an intermediate that does che= ck the RTP stream for missing packets itself, and an intermediate that does= not, but still the behaviour in terms of FW-ing the NACKs received from ot= her "systems" is exactly the same. Why make this distinction then? >=20 > I still have an outstanding comment which has not been resolved yet. The = section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but sectio= n 6.1.1. talks about two distribution sources, whereas RFC 5760 only define= d ONE SINGLE DS. Please clarify this. >=20 > Regards > Tom > _______________________________________________ > Audio/Video Transport Core Maintenance avt@ietf.org=20 > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Tue Jun 21 08:12:47 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80CF11E8088 for ; Tue, 21 Jun 2011 08:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.496 X-Spam-Level: X-Spam-Status: No, score=-103.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fvxq1mN-+SEd for ; Tue, 21 Jun 2011 08:12:46 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id A3FFB11E807E for ; Tue, 21 Jun 2011 08:12:46 -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 1QZ2dB-00016n-bQ; Tue, 21 Jun 2011 15:12:45 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Tue, 21 Jun 2011 16:12:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <02B1CB36-0760-4295-8BE2-1DFBD0C7BE55@csperkins.org> References: To: "Van Caenegem, Tom (Tom)" X-Mailer: Apple Mail (2.1084) Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:12:47 -0000 On 21 Jun 2011, at 16:04, Van Caenegem, Tom (Tom) wrote: > Hi Colin, >=20 > Thx for sharing your view. See below.=20 >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org]=20 >> Sent: dinsdag 21 juni 2011 16:08 >> To: Van Caenegem, Tom (Tom) >> Cc: Qin Wu; 'IETF AVTCore WG'; Roni Even >> Subject: Re: [AVTCORE] Comments on = draft-ietf-avtcore-feedback-supression-rtp-04 >>=20 >> On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: >>> Hi, >>>=20 >>> as promised, these are comments I have on the draft " RTCP Extension = for Third-party Loss Report" >>>=20 >>> -IMO the draft does not provide a good rationale on the use case for = sending this new report. The section 3 (protocol overview) says: >>>=20 >>> "If an intermediary receives a NACK from another system, it should = redistribute that NACK to all other systems that would not otherwise = receive it. An example of this is RTCP-SSM in simple feedback model = [RFC5760], where the distribution source reflects NACKs to other = systems. =20 >>> If an intermediary receives a NACK from another system, but, for = some reason, cannot redistribute that NACK, then it may send a = third-party loss report to the systems that were unable to receive the = NACK, and won't receive the NACK via other means. An example would be a = distribution source using RTCP-SSM in Distribution Source Feedback = Summary model [RFC5760]." >>>=20 >>> My questions:=20 >>>=20 >>> -why would the intermediary not be able or capable to send the = received NACK to the "systems" that were unable to receive the NACK, = whereas it would be able or capable to send the 3rd party loss report to = those same "systems"?=20 >>=20 >> Because the intermediary is trying to hide the identity or existence = of those systems, and cannot forward the NACK from them without = revealing that information. >>=20 > Tom: well.. This is a new element you bring in here.. I can only = guess why this rationale has not been explicitly included before in a WG = document? Did I miss this discussion? It is certainly not aligned with = the text/reasoning in the draft because a DS operating in simple FB mode = is an example where the forwarding of NACKs seems to be the right thing = to do (and not sending the 3rd party loss report) whereas a DS in = summary FB mode is an example that would send 3rd party loss message. = Why is hiding the identity an issue for the latter case (SSM in summary = mode) and not for the former case (simple FB mode)?=20 This is the purpose of summary feedback mode of RTCP-SSM: to limit the = distribution of state for all participants, and instead give a summary.=20= > Also, the draft is about FB storm suppression which is also realised = with NACKs as you know... An incoming NACK can also be "anonimised" by = having the DS or the FT acting as a translator for this NACK message. = See draft-vancaenegem-avtcore-retransmission-for-ssm-00. I know that NACKs suppress feedback. That doesn't invalidate the need = for a third party loss report that also suppresses feedback, for the = cases where it's not appropriate to use a NACK, such as the summary = feedback mode of RTCP-SSM. >>> -The DS in RTCP-SSM operating in FB summary mode is mentioned as an = example for a case where a NACK cannnot be forwarded. Why is this? = RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and = my quote from that RFC in = "draft-vancaenegem-avtcore-retransmission-for-ssm-00" >>=20 >> RFC 5760 allows the NACK to be forwarded, but this would cause the = other receivers to become aware of, and keep state for, the participant = that sent the NACK. If a third-party loss report is used, the other = receivers don't become aware of the participant that signalled the loss, = they just know that the loss occurred.=20 >>=20 > Tom: why is keeping state "required" here? Keeping state of what?=20 RTCP state, since they'll see a NACK from a participant of which they = were previously unaware. >> -This section 3 makes a distinction between an intermediate that does = check the RTP stream for missing packets itself, and an intermediate = that does not, but still the behaviour in terms of FW-ing the NACKs = received from other "systems" is exactly the same. Why make this = distinction then? >>=20 >> I still have an outstanding comment which has not been resolved yet. = The section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but = section 6.1.1. talks about two distribution sources, whereas RFC 5760 = only defined ONE SINGLE DS. Please clarify this. >>=20 >> Regards >> Tom >> _______________________________________________ >> Audio/Video Transport Core Maintenance avt@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 --=20 Colin Perkins http://csperkins.org/ From abegen@cisco.com Tue Jun 21 08:39:32 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6878911E8267 for ; Tue, 21 Jun 2011 08:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u45xyZ24B6xg for ; Tue, 21 Jun 2011 08:39:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id E7ED311E8270 for ; Tue, 21 Jun 2011 08:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=629; q=dns/txt; s=iport; t=1308670772; x=1309880372; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+1zZSL/8xynM4GWmrwYWmuxQB4v96DzMSx6J9R/yF14=; b=aSxse6U9CsBbm6HgmTZjnwwc+S5uT2lUM0JRiwDbNRKFVqeYFM79PNQd FyCKZebxpJGoSZSveoOwHUJcg+buf4MgI7YmbPct00dZVrWqcfQs+FQyV klM2yKgdNtRYw3ovBI+AM05ffRhbIRo2y7KuY5y+ymp8yTuE4fF3c1em+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK66AE6rRDoH/2dsb2JhbABUpnF3iHOhMZ5GhioEhyKPL4s7 X-IronPort-AV: E=Sophos;i="4.65,401,1304294400"; d="scan'208";a="343073443" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2011 15:39:18 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5LFdIqw012116; Tue, 21 Jun 2011 15:39:18 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); Tue, 21 Jun 2011 08:39:18 -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, 21 Jun 2011 08:39:14 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F5003B4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <02B1CB36-0760-4295-8BE2-1DFBD0C7BE55@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-04 Thread-Index: AcwwJbpQaS/Y+oWnTkWcX/0BXu8CcwAA4pTQ References: <02B1CB36-0760-4295-8BE2-1DFBD0C7BE55@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" , "Van Caenegem, Tom (Tom)" X-OriginalArrivalTime: 21 Jun 2011 15:39:18.0548 (UTC) FILETIME=[6227F540:01CC3029] Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:39:32 -0000 > >> RFC 5760 allows the NACK to be forwarded, but this would cause the = other receivers to become aware of, and keep state > for, the participant that sent the NACK. If a third-party loss report = is used, the other receivers don't become aware of the > participant that signalled the loss, they just know that the loss = occurred. > >> > > Tom: why is keeping state "required" here? Keeping state of what? >=20 > RTCP state, since they'll see a NACK from a participant of which they = were previously unaware. But, they could be keeping that state anyway for other RTCP they saw = from other peers. -acbegen From tom.van_caenegem@alcatel-lucent.com Tue Jun 21 08:43:15 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485C811E8279 for ; Tue, 21 Jun 2011 08:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 376VGE7qwkEB for ; Tue, 21 Jun 2011 08:43:14 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id F060411E8278 for ; Tue, 21 Jun 2011 08:43:13 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5LFgjga007187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Jun 2011 17:42:46 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 21 Jun 2011 17:42:45 +0200 From: "Van Caenegem, Tom (Tom)" To: Colin Perkins Date: Tue, 21 Jun 2011 17:42:44 +0200 Thread-Topic: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 Thread-Index: AcwwJbSU9PT3BiG4SN6O7sipchw8ugAAkLvg Message-ID: References: <02B1CB36-0760-4295-8BE2-1DFBD0C7BE55@csperkins.org> In-Reply-To: <02B1CB36-0760-4295-8BE2-1DFBD0C7BE55@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.80 Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:43:15 -0000 Colin, What you say makes sense, but my feeling is that the rationale for defining= the 3rd party loss report should be much better defined in the WG document= , potentially along the lines you mentioned (but does it go beyond SSM in s= ummary mode architectures?). The only rationale explicitly provided, is the= one in the introduction which contains other reasoning which are partly in= correct. So I call upon the authors of the WG draft to revise the text.=20 Tom -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: dinsdag 21 juni 2011 17:13 To: Van Caenegem, Tom (Tom) Cc: Qin Wu; 'IETF AVTCore WG'; Roni Even Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-r= tp-04 On 21 Jun 2011, at 16:04, Van Caenegem, Tom (Tom) wrote: > Hi Colin, >=20 > Thx for sharing your view. See below.=20 >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: dinsdag 21 juni 2011 16:08 >> To: Van Caenegem, Tom (Tom) >> Cc: Qin Wu; 'IETF AVTCore WG'; Roni Even >> Subject: Re: [AVTCORE] Comments on=20 >> draft-ietf-avtcore-feedback-supression-rtp-04 >>=20 >> On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: >>> Hi, >>>=20 >>> as promised, these are comments I have on the draft " RTCP Extension fo= r Third-party Loss Report" >>>=20 >>> -IMO the draft does not provide a good rationale on the use case for se= nding this new report. The section 3 (protocol overview) says: >>>=20 >>> "If an intermediary receives a NACK from another system, it should redi= stribute that NACK to all other systems that would not otherwise receive it= . An example of this is RTCP-SSM in simple feedback model [RFC5760], where= the distribution source reflects NACKs to other systems. =20 >>> If an intermediary receives a NACK from another system, but, for some r= eason, cannot redistribute that NACK, then it may send a third-party loss r= eport to the systems that were unable to receive the NACK, and won't receiv= e the NACK via other means. An example would be a distribution source using= RTCP-SSM in Distribution Source Feedback Summary model [RFC5760]." >>>=20 >>> My questions:=20 >>>=20 >>> -why would the intermediary not be able or capable to send the received= NACK to the "systems" that were unable to receive the NACK, whereas it wou= ld be able or capable to send the 3rd party loss report to those same "syst= ems"?=20 >>=20 >> Because the intermediary is trying to hide the identity or existence of = those systems, and cannot forward the NACK from them without revealing that= information. >>=20 > Tom: well.. This is a new element you bring in here.. I can only guess w= hy this rationale has not been explicitly included before in a WG document?= Did I miss this discussion? It is certainly not aligned with the text/reas= oning in the draft because a DS operating in simple FB mode is an example w= here the forwarding of NACKs seems to be the right thing to do (and not sen= ding the 3rd party loss report) whereas a DS in summary FB mode is an examp= le that would send 3rd party loss message. Why is hiding the identity an is= sue for the latter case (SSM in summary mode) and not for the former case (= simple FB mode)?=20 This is the purpose of summary feedback mode of RTCP-SSM: to limit the dist= ribution of state for all participants, and instead give a summary.=20 > Also, the draft is about FB storm suppression which is also realised with= NACKs as you know... An incoming NACK can also be "anonimised" by having t= he DS or the FT acting as a translator for this NACK message. See draft-van= caenegem-avtcore-retransmission-for-ssm-00. I know that NACKs suppress feedback. That doesn't invalidate the need for a= third party loss report that also suppresses feedback, for the cases where= it's not appropriate to use a NACK, such as the summary feedback mode of R= TCP-SSM. >>> -The DS in RTCP-SSM operating in FB summary mode is mentioned as an exa= mple for a case where a NACK cannnot be forwarded. Why is this? RFC5760 do= es not prevent a DS to foward the NACK (see the RFC 5760 and my quote from = that RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00" >>=20 >> RFC 5760 allows the NACK to be forwarded, but this would cause the other= receivers to become aware of, and keep state for, the participant that sen= t the NACK. If a third-party loss report is used, the other receivers don't= become aware of the participant that signalled the loss, they just know th= at the loss occurred.=20 >>=20 > Tom: why is keeping state "required" here? Keeping state of what?=20 RTCP state, since they'll see a NACK from a participant of which they were = previously unaware. >> -This section 3 makes a distinction between an intermediate that does ch= eck the RTP stream for missing packets itself, and an intermediate that doe= s not, but still the behaviour in terms of FW-ing the NACKs received from o= ther "systems" is exactly the same. Why make this distinction then? >>=20 >> I still have an outstanding comment which has not been resolved yet. The= section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but secti= on 6.1.1. talks about two distribution sources, whereas RFC 5760 only defin= ed ONE SINGLE DS. Please clarify this. >>=20 >> Regards >> Tom >> _______________________________________________ >> Audio/Video Transport Core Maintenance avt@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 -- Colin Perkins http://csperkins.org/ From csp@csperkins.org Tue Jun 21 08:44:08 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367EA11E8278 for ; Tue, 21 Jun 2011 08:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.502 X-Spam-Level: X-Spam-Status: No, score=-103.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtEfTy-LYCc1 for ; Tue, 21 Jun 2011 08:44:07 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id A043E11E80AE for ; Tue, 21 Jun 2011 08:44:07 -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 1QZ35c-0001mp-eb; Tue, 21 Jun 2011 15:42:08 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F5003B4@xmb-sjc-215.amer.cisco.com> Date: Tue, 21 Jun 2011 16:42:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <56E4A49C-3769-4B42-AE7E-ADD95FFD4297@csperkins.org> References: <02B1CB36-0760-4295-8BE2-1DFBD0C7BE55@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D540F5003B4@xmb-sjc-215.amer.cisco.com> To: "Ali C. Begen (abegen)" X-Mailer: Apple Mail (2.1084) Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:44:08 -0000 On 21 Jun 2011, at 16:39, Ali C. Begen (abegen) wrote: >>>> RFC 5760 allows the NACK to be forwarded, but this would cause the = other receivers to become aware of, and keep state for, the participant = that sent the NACK. If a third-party loss report is used, the other = receivers don't become aware of the participant that signalled the loss, = they just know that the loss occurred. >>>>=20 >>> Tom: why is keeping state "required" here? Keeping state of what? >>=20 >> RTCP state, since they'll see a NACK from a participant of which they = were previously unaware. >=20 > But, they could be keeping that state anyway for other RTCP they saw = from other peers. In summary feedback mode, they don't see the RTCP from the other peers, = just the summary reports from the DS.=20 --=20 Colin Perkins http://csperkins.org/ From abegen@cisco.com Tue Jun 21 08:47:52 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8074711E8284 for ; Tue, 21 Jun 2011 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZJaVwGUDC77 for ; Tue, 21 Jun 2011 08:47:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD3311E807E for ; Tue, 21 Jun 2011 08:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1570; q=dns/txt; s=iport; t=1308671272; x=1309880872; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rOxLgZAU9ta/EYbLRKjI/MMBUyDTDQWtPSK5V8gL2NU=; b=HvcdbWw4NuU067Ia6/P7jp03BkIOAWWS9LLrifXrmnGEBC4R1UkTOkck wDivNv6wVx02wDiF4iZIUUOdtF6qfdeRj0K0cDkMwYXJchaUZqestqKJE CB1MHfTOh+U0XTfVBXl/8xHrjqkwlAeTdHZXHGhzm+opdUs44LpysKtff U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAB28AE6rRDoJ/2dsb2JhbABUl12PFHeqLZ5HhioEhyKPL4s7 X-IronPort-AV: E=Sophos;i="4.65,401,1304294400"; d="scan'208";a="382301355" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2011 15:47:51 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5LFlpop012522; Tue, 21 Jun 2011 15:47:51 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); Tue, 21 Jun 2011 08:47:51 -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, 21 Jun 2011 08:47:23 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F5003BE@xmb-sjc-215.amer.cisco.com> In-Reply-To: <56E4A49C-3769-4B42-AE7E-ADD95FFD4297@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-04 Thread-Index: AcwwKh90HmCu0vnARlaGSojmywuYlwAACfvA References: <02B1CB36-0760-4295-8BE2-1DFBD0C7BE55@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D540F5003B4@xmb-sjc-215.amer.cisco.com> <56E4A49C-3769-4B42-AE7E-ADD95FFD4297@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" X-OriginalArrivalTime: 21 Jun 2011 15:47:51.0564 (UTC) FILETIME=[93EFFCC0:01CC302A] Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:47:52 -0000 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Tuesday, June 21, 2011 5:42 PM > To: Ali C. Begen (abegen) > Cc: Van Caenegem, Tom (Tom); IETF AVTCore WG > Subject: Re: [AVTCORE] Comments = ondraft-ietf-avtcore-feedback-supression-rtp-04 >=20 > On 21 Jun 2011, at 16:39, Ali C. Begen (abegen) wrote: > >>>> RFC 5760 allows the NACK to be forwarded, but this would cause = the other receivers to become aware of, and keep > state for, the participant that sent the NACK. If a third-party loss = report is used, the other receivers don't become aware of > the participant that signalled the loss, they just know that the loss = occurred. > >>>> > >>> Tom: why is keeping state "required" here? Keeping state of what? > >> > >> RTCP state, since they'll see a NACK from a participant of which = they were previously unaware. > > > > But, they could be keeping that state anyway for other RTCP they saw = from other peers. > =20 > In summary feedback mode, they don't see the RTCP from the other = peers, just the summary reports from the DS. Agreed. What I was trying to say is that in the simple feedback model, = seeing the NACKs from others will not necessarily increase the amount of = state information since sooner or later, peers will see each other's = RTCP anyway. In the summary mode, using a new report is fine with me = (and I agree with Tom that the draft needs a bit improvement on the = motivation part). -acbegen =20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From csp@csperkins.org Tue Jun 21 08:52:28 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6925D11E828C for ; Tue, 21 Jun 2011 08:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.507 X-Spam-Level: X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VOzydCi-j2X for ; Tue, 21 Jun 2011 08:52:25 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 18C5711E807E for ; Tue, 21 Jun 2011 08:52:24 -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 1QZ3FX-0001XS-b0; Tue, 21 Jun 2011 15:52:23 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F5003BE@xmb-sjc-215.amer.cisco.com> Date: Tue, 21 Jun 2011 16:52:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <639DD2EB-840C-4B01-9F94-2BD75FF1FDBA@csperkins.org> References: <02B1CB36-0760-4295-8BE2-1DFBD0C7BE55@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D540F5003B4@xmb-sjc-215.amer.cisco.com> <56E4A49C-3769-4B42-AE7E-ADD95FFD4297@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D540F5003BE@xmb-sjc-215.amer.cisco.com> To: "Ali C. Begen (abegen)" X-Mailer: Apple Mail (2.1084) Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:52:28 -0000 On 21 Jun 2011, at 16:47, Ali C. Begen (abegen) wrote: >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Tuesday, June 21, 2011 5:42 PM >> To: Ali C. Begen (abegen) >> Cc: Van Caenegem, Tom (Tom); IETF AVTCore WG >> Subject: Re: [AVTCORE] Comments = ondraft-ietf-avtcore-feedback-supression-rtp-04 >>=20 >> On 21 Jun 2011, at 16:39, Ali C. Begen (abegen) wrote: >>>>>> RFC 5760 allows the NACK to be forwarded, but this would cause = the other receivers to become aware of, and keep state for, the = participant that sent the NACK. If a third-party loss report is used, = the other receivers don't become aware of the participant that signalled = the loss, they just know that the loss occurred. >>>>>>=20 >>>>> Tom: why is keeping state "required" here? Keeping state of what? >>>>=20 >>>> RTCP state, since they'll see a NACK from a participant of which = they were previously unaware. >>>=20 >>> But, they could be keeping that state anyway for other RTCP they saw = from other peers. >>=20 >> In summary feedback mode, they don't see the RTCP from the other = peers, just the summary reports from the DS. >=20 > Agreed. What I was trying to say is that in the simple feedback model, = seeing the NACKs from others will not necessarily increase the amount of = state information since sooner or later, peers will see each other's = RTCP anyway. In the summary mode, using a new report is fine with me = (and I agree with Tom that the draft needs a bit improvement on the = motivation part). Sure, make sense. --=20 Colin Perkins http://csperkins.org/ From sunseawq@huawei.com Tue Jun 21 19:40:17 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADC211E80C8 for ; Tue, 21 Jun 2011 19:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.285 X-Spam-Level: X-Spam-Status: No, score=-5.285 tagged_above=-999 required=5 tests=[AWL=1.314, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC1q6IazomFs for ; Tue, 21 Jun 2011 19:40:16 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 604E811E8090 for ; Tue, 21 Jun 2011 19:40:16 -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 <0LN600M3Q7EPCQ@szxga04-in.huawei.com> for avt@ietf.org; Wed, 22 Jun 2011 10:40:01 +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 <0LN600JIA7EPUM@szxga04-in.huawei.com> for avt@ietf.org; Wed, 22 Jun 2011 10:40:01 +0800 (CST) Received: from w53375q ([10.138.41.76]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN600F9T7ENBK@szxml04-in.huawei.com> for avt@ietf.org; Wed, 22 Jun 2011 10:40:01 +0800 (CST) Date: Wed, 22 Jun 2011 10:39:59 +0800 From: Qin Wu To: Colin Perkins , "Van Caenegem, Tom (Tom)" Message-id: <7C8D947749B24396AA011FB286CC69E1@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 02:40:18 -0000 I agree with Colin's observation. Another basic rational I think is we should use NACK and new report appropriately. i.e., both new report and NACK can not be used in any cases. NACK and new report defined in this document are both feedback message, however they should have different uses. we don't expect to see that when NACK is sent from A to B, the new report can replace NACK as one alternative and is also sent from A to B. But we allow that NACK and new report work together in the same sceanrio, e.g.,when NACK is sent from A to B, the new report is sent from B to C. The basic reason is NACK and new report has totally different semantics, i.e., when the middlebox or media source detect the packet loss by himself, the middlebox or media source SHOULD send NACK message, when the middlebox is told by another middlebox or RTP_Reciever about the packet loss, the middlebox SHOULD send new report defined in this draft. In that case, we can clearly distinguish the semantics and use of both NACK and new report. Such rational is clearly described in the last paragraph of section 1 and the fifth paragraph of section 2 Regards! -Qin ----- Original Message ----- From: "Colin Perkins" To: "Van Caenegem, Tom (Tom)" Cc: "Qin Wu" ; "'IETF AVTCore WG'" ; "Roni Even" Sent: Tuesday, June 21, 2011 10:07 PM Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: > Hi, > > as promised, these are comments I have on the draft " RTCP Extension for Third-party Loss Report" > > -IMO the draft does not provide a good rationale on the use case for sending this new report. The section 3 (protocol overview) says: > > "If an intermediary receives a NACK from another system, it should redistribute that NACK to all other systems that would not otherwise receive it. An example of this is RTCP-SSM in simple feedback model [RFC5760], where the distribution source reflects NACKs to other systems. > If an intermediary receives a NACK from another system, but, for some reason, cannot redistribute that NACK, then it may send a third-party loss report to the systems that were unable to receive the NACK, and won't receive the NACK via other means. An example would be a distribution source using RTCP-SSM in Distribution Source Feedback Summary model [RFC5760]." > > My questions: > > -why would the intermediary not be able or capable to send the received NACK to the "systems" that were unable to receive the NACK, whereas it would be able or capable to send the 3rd party loss report to those same "systems"? Because the intermediary is trying to hide the identity or existence of those systems, and cannot forward the NACK from them without revealing that information. > -The DS in RTCP-SSM operating in FB summary mode is mentioned as an example for a case where a NACK cannnot be forwarded. Why is this? RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and my quote from that RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00" RFC 5760 allows the NACK to be forwarded, but this would cause the other receivers to become aware of, and keep state for, the participant that sent the NACK. If a third-party loss report is used, the other receivers don't become aware of the participant that signalled the loss, they just know that the loss occurred. > -This section 3 makes a distinction between an intermediate that does check the RTP stream for missing packets itself, and an intermediate that does not, but still the behaviour in terms of FW-ing the NACKs received from other "systems" is exactly the same. Why make this distinction then? > > I still have an outstanding comment which has not been resolved yet. The section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but section 6.1.1. talks about two distribution sources, whereas RFC 5760 only defined ONE SINGLE DS. Please clarify this. [Qin]: two distribution sources means we have two levels of SSM communication, one distribution souce is placed at the upstream of the other distribution source. two distribution sources case is just one exmaple to discuss how to use new report when there are multiple middleboxs or intermediaries between media source and the receivers. The middlebox can be distribution source and can be other intermediary. > > Regards > Tom > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ From sunseawq@huawei.com Tue Jun 21 20:44:46 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC65911E80C3 for ; Tue, 21 Jun 2011 20:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=-1.747, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY1NiKKbekza for ; Tue, 21 Jun 2011 20:44:46 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C38C811E8090 for ; Tue, 21 Jun 2011 20:44:45 -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 <0LN600F6CADPHS@szxga05-in.huawei.com> for avt@ietf.org; Wed, 22 Jun 2011 11:44:14 +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 <0LN600EQAADLF4@szxga05-in.huawei.com> for avt@ietf.org; Wed, 22 Jun 2011 11:44:09 +0800 (CST) Received: from w53375q ([10.138.41.76]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN6004EBADI72@szxml06-in.huawei.com> for avt@ietf.org; Wed, 22 Jun 2011 11:44:09 +0800 (CST) Date: Wed, 22 Jun 2011 11:44:06 +0800 From: Qin Wu To: Colin Perkins Message-id: <9024847511C5485294C7E31B75122CE1@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <20110616092110.1754.68542.idtracker@ietfa.amsl.com> Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 03:44:47 -0000 SGksDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNvbGluIFBlcmtpbnMi IDxjc3BAY3NwZXJraW5zLm9yZz4NClRvOiAiUWluIFd1IiA8c3Vuc2Vhd3FAaHVhd2VpLmNvbT4N CkNjOiA8YXZ0QGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgSnVuZSAyMSwgMjAxMSAxMDo1NSBQ TQ0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWF2dGNvcmUt bW9uYXJjaC0wMy50eHQNCg0KDQpRaW4sDQoNClRoaXMgZG9lcyBhZGRyZXNzIG1hbnkgb2YgbXkg Y29tbWVudHMgb24gdGhlIGVhcmxpZXIgdmVyc2lvbnMuIFNvbWUgcXVpY2sgY29tbWVudHMgb24g dGhpcyBkcmFmdDoNCg0KLSBJbiBTZWN0aW9uIDUuMiwgdGhlcmUgaXMgbm8gbmVlZCB0byByZXBv cnQgdGhlIENOQU1FLCBzaW5jZSB0aGlzIGlzIHJlZHVuZGFudCB3aXRoIFJUQ1AgU0RFUyBpbmZv cm1hdGlvbi4gDQoNCltRaW5dIEFncmVlLCBDTkFNRSBhcyB0aGUgc291cmNlIG9mIG1lYXN1cmVk IHN0cmVhbSBpcyBvdmVybGFwcGVkIHdpdGggUlRDUCBTREVTLg0KSSB3aWxsIHJlbW92ZSBDTkFN RSBhcyBhIGV4YW1wbGUgZnJvbSB0aGlzIGRvY3VtZW50LiBBbHNvIEkgdGhpbmsgZXhhbXBsZSBm b3Igc291cmNlIG9mDQptZWFzdXJlZCBzdHJlYW0gY291bGQgYmUgb3RoZXIgaWRlbnRpdHkgaW5m b3JtYXRpb24gaW4gb3RoZXIgbm9uLVJUUCBzZXNzaW9uLg0KDQotIFNlY3Rpb24gNS4yIHN1Z2dl c3RzIHJlcG9ydGluZyCTdGhlIHNlcXVlbmNlIG51bWJlciBvZiB0aGUgZmlyc3QgcGFja2V0IG9m IHRoZSBSVFAgc2Vzc2lvbpQuIEEgcmVjZWl2ZXIgY2Fubm90IGtub3cgd2hhdCBpcyB0aGUgZmly c3QgcGFja2V0IG9mIHRoZSBzZXNzaW9uLCBvbmx5IHdoYXQgd2FzIHRoZSBmaXJzdCBwYWNrZXQg aXQgcmVjZWl2ZWQsIHNvIHRoaXMgc2hvdWxkIGJlIGNsYXJpZmllZCB0byCTdGhlIHNlcXVlbmNl IG51bWJlciBvZiB0aGUgZmlyc3QgcGFja2V0IHJlY2VpdmVkIGluIHRoZSBSVFAgc2Vzc2lvbpQu IA0KDQpbUWluXTogWWVzLCBpdCBsb29rcyByZWFzb25hYmxlIHRvIG1lLg0KDQpUaGUgZmlyc3Qg c2VxdWVuY2UgbnVtYmVyIHJlY2VpdmVkIGFsc28gYmVjb21lcyBsZXNzIHVzZWZ1bCBhZnRlciB0 aGUgc2VxdWVuY2UgbnVtYmVyIHNwYWNlIHdyYXBzIGFyb3VuZCwgc28gaXQgbWlnaHQgbWFrZSBz ZW5zZSB0byBpbmNsdWRlIGEgY291bnQgb2Ygc2VxdWVuY2UgbnVtYmVyIGN5Y2xlcyBzaW5jZSB0 aGVuLg0KDQpbUWluXTogR29vZCBzdWdnZXN0aW9uLiBJIGFtIG9rYXkgd2l0aCB0aGlzIGlmIHRo ZXJlIGlzIG5vIG9iamVjdGlvbi4NCg0KLSBTZWN0aW9uIDUuMyBkaXNjdXNzZXMgc2VuZGluZyBp bmZvcm1hdGlvbiB0aGF0IGNhbiBiZSB1c2VkIHRvIGNvcnJlbGF0ZSBhbiBSVFAgc291cmNlIHdp dGggbm9uLVJUUCBwcm90b2NvbHMuIFRoaXMgc2VlbXMgbGlrZSBhIHJlYXNvbmFibGUgdGhpbmcg dG8gYWRkLiBIb3dldmVyLCBzaW5jZSBpdCBpcyBkZXNjcmliaW5nIHRoZSBzb3VyY2UsIHJhdGhl ciB0aGFuIHByb3ZpZGluZyBhIHF1YWxpdHkgcmVwb3J0LCBzaG91bGQgdGhpcyBiZSBhbiBuZXcg UlRDUCBTREVTIGJsb2NrIHR5cGUsIHJhdGhlciB0aGFuIGFuIFJUQ1AgWFIgYmxvY2s/DQoNCltR aW5dOiBZb3UgYXNrIGEgR29vZCBxdWVzdGlvbiwgYWNjb3JkaW5nIHRvIFJGQzU5NjgsIEkgYW0g dGhpbmtpbmcgd2hpY2ggcnVsZSBzaG91bGQgYmUgYXBwbGllZCB3aGVuIGNob29zZSB0aGUgYXBw cm9wcmlvYXRlIGV4dGVuc2lvbiBwb2ludC4NCkl0IGxvb2tzIHRvIG1lIHRoZSBpbmZvcm1hdGlv biBkaXNjdXNzZWQgaW4gdGhlIHNlY3Rpb24gNS4zIGlzIHNvbWV0aGluZyBsaWtlIHByb2ZpbGUt c3BlY2lmaWMgZXh0ZW5zaW9uIHRvICBSVENQIFNSIGFuZC9vciBSUiBwYWNrZXRzLCBzbyBpdCBz ZWVtcyANCmJvdGggbmV3IFJUQ1AgWFIgYW5kIG5ldyBSVENQIG1lc3NhZ2UgY2FuIGJlIGNob29z ZW4uIA0KDQpBbmQgdGhlIGluZm9ybWF0aW9uIGhlcmUgaXMgc29tZXRoaW5nIHJlbGV2YW50IHRv IHRoZSBxdWFsaXR5IHJlcG9ydCwgU28gSSBhbSBzdXJlIGlmIGl0IGlzIGJldHRlciB0byBjaG9v c2UgdG8gZGVmaW5lIG5ldyBSVENQIFNERVMgaW5zdGVhZCBvZiBSVENQIFhSLiANCg0KQ29saW4N Cg0KDQpPbiAxNiBKdW4gMjAxMSwgYXQgMTA6MjksIFFpbiBXdSB3cm90ZToNCg0KPiBIaSw6DQo+ IEluIHJlc3BvbnNlIHRvIHRoZSByZWNlbnQgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb24gb24gdGhl IGxpc3QsIGEgbmV3IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2ggaXMganVz dCBzdWJtaXR0ZWQuDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtYXZ0Y29yZS1tb25hcmNoLTAzLnR4dA0KPiBUaGUgZGlmZiBpczoNCj4gaHR0cDovL3Rv b2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0wMw0K PiANCj4gUGxlYXNlIGNoZWNrIGlmIHlvdXIgY29tbWVudHMgYXJlIGFkZHJlc3NlZCBpbiB0aGlz IHZlcnNpb24uDQo+IA0KPiBSZWdhcmRzIQ0KPiAtUWluDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KPiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiBUbzog PGktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCj4gQ2M6IDxhdnRAaWV0Zi5vcmc+DQo+IFNlbnQ6IFRo dXJzZGF5LCBKdW5lIDE2LCAyMDExIDU6MjEgUE0NCj4gU3ViamVjdDogW0FWVENPUkVdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTAzLnR4dA0KPiANCj4gDQo+PiBBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEF1ZGlv L1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElF VEYuDQo+PiANCj4+IFRpdGxlICAgICAgICAgICA6IE1vbml0b3JpbmcgQXJjaGl0ZWN0dXJlcyBm b3IgUlRQDQo+PiBBdXRob3IocykgICAgICAgOiBRaW4gV3UNCj4+ICAgICAgICAgICAgICAgICAg ICAgICAgIEdlb2ZmIEh1bnQNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgIFBoaWxpcCBBcmRl bg0KPj4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMDMudHh0 DQo+PiBQYWdlcyAgICAgICAgICAgOiAyMw0KPj4gRGF0ZSAgICAgICAgICAgIDogMjAxMS0wNi0x Ng0KPj4gDQo+PiAgVGhpcyBtZW1vIHByb3Bvc2VzIGFuIGFyY2hpdGVjdHVyZSBmb3IgZXh0ZW5k aW5nIFJUQ1Agd2l0aCBhIG5ldyBSVENQDQo+PiAgWFIgKFJGQzM2MTEpIGJsb2NrIHR5cGUgdG8g cmVwb3J0IG5ldyBtZXRyaWNzIHJlZ2FyZGluZyBtZWRpYQ0KPj4gIHRyYW5zbWlzc2lvbiBvciBy ZWNlcHRpb24gcXVhbGl0eSwgYXMgcHJvcG9zZWQgaW4gUkZDNTk2OC4gIFRoaXMgbWVtbw0KPj4g IHN1Z2dlc3RzIHRoYXQgYSBuZXcgYmxvY2sgc2hvdWxkIGNvbnRhaW4gYSBzaW5nbGUgbWV0cmlj IG9yIGEgc21hbGwNCj4+ICBudW1iZXIgb2YgbWV0cmljcyByZWxldmFudCB0byBhIHNpbmdsZSBw YXJhbWV0ZXIgb2YgaW50ZXJlc3Qgb3INCj4+ICBjb25jZXJuLCByYXRoZXIgdGhhbiBjb250YWlu aW5nIGEgbnVtYmVyIG9mIG1ldHJpY3Mgd2hpY2ggYXR0ZW1wdCB0bw0KPj4gIHByb3ZpZGUgZnVs bCBjb3ZlcmFnZSBvZiBhbGwgdGhvc2UgcGFyYW1ldGVycyBvZiBjb25jZXJuIHRvIGENCj4+ICBz cGVjaWZpYyBhcHBsaWNhdGlvbi4gIEFwcGxpY2F0aW9ucyBtYXkgdGhlbiAmcXVvdDttaXggYW5k IG1hdGNoJnF1b3Q7IHRvDQo+PiAgY3JlYXRlIGEgc2V0IG9mIGJsb2NrcyB3aGljaCBjb3ZlcnMg dGhlaXIgc2V0IG9mIGNvbmNlcm5zLiAgV2hlcmUNCj4+ICBwb3NzaWJsZSwgYSBzcGVjaWZpYyBi bG9jayBzaG91bGQgYmUgZGVzaWduZWQgdG8gYmUgcmUtdXNhYmxlIGFjcm9zcw0KPj4gIG1vcmUg dGhhbiBvbmUgYXBwbGljYXRpb24sIGZvciBleGFtcGxlLCBmb3IgYWxsIG9mIHZvaWNlLCBzdHJl YW1pbmcNCj4+ICBhdWRpbyBhbmQgdmlkZW8uDQo+PiANCj4+IA0KPj4gQSBVUkwgZm9yIHRoaXMg SW50ZXJuZXQtRHJhZnQgaXM6DQo+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0wMy50eHQNCj4+IA0KPj4gSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4gZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+IA0KPj4gVGhpcyBJbnRlcm5ldC1EcmFmdCBj YW4gYmUgcmV0cmlldmVkIGF0Og0KPj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaC0wMy50eHQNCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBBdWRpby9WaWRlbyBUcmFuc3BvcnQg Q29yZSBNYWludGVuYW5jZQ0KPj4gYXZ0QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50 ZW5hbmNlDQo+IGF2dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2F2dA0KDQoNCg0KLS0gDQpDb2xpbiBQZXJraW5zDQpodHRwOi8vY3NwZXJraW5zLm9y Zy8NCg0KDQoNCg== From magnus.westerlund@ericsson.com Wed Jun 22 07:21:27 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91E311E807A for ; Wed, 22 Jun 2011 07:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJWalIHEB2hx for ; Wed, 22 Jun 2011 07:21:25 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4606E11E809F for ; Wed, 22 Jun 2011 07:21:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-10-4e01fa636413 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3C.A8.09774.36AF10E4; Wed, 22 Jun 2011 16:21:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 22 Jun 2011 16:21:22 +0200 Message-ID: <4E01FA62.8070803@ericsson.com> Date: Wed, 22 Jun 2011 16:21:22 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Please review draft-ietf-avt-srtp-aes-gcm-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:21:27 -0000 WG, We have so far made very slow progress on this draft. I would like to get some reviews of this document. So that we can see if it is ready for publication or needs to be improved. Please review it. Cheers Magnus Westerlund WG chair ---------------------------------------------------------------------- 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 tena@huawei.com Wed Jun 22 12:00:09 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BB511E8188; Wed, 22 Jun 2011 12:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.239 X-Spam-Level: X-Spam-Status: No, score=-106.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHsJNrQM8jPg; Wed, 22 Jun 2011 12:00:08 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5A11111E8131; Wed, 22 Jun 2011 12:00:04 -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 <0LN700J75GS3B3@usaga02-in.huawei.com>; Wed, 22 Jun 2011 14:00:03 -0500 (CDT) Received: from TingZousc1 ([10.193.34.119]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN7009CKGS2OS@usaga02-in.huawei.com>; Wed, 22 Jun 2011 14:00:02 -0500 (CDT) Date: Wed, 22 Jun 2011 12:00:03 -0700 From: Tina Tsou To: agenda@ietf.org Message-id: <028101cc310e$988d9320$c9a8b960$@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: AQHMMMcB8UsA4rkLR0+H45FE9ASlfpTJeI8AgAA8uvA= Cc: 'Ronald Bonica' , avt@ietf.org, 'Ralph Droms' , 'Jari Arkko' , multrans@ietf.org, 'David Harrington' Subject: [AVTCORE] FW: [multrans] Scheduling of MULTRANS BoF X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 19:00:09 -0000 Hi colleagues at 'agenda@ietf.org', Would you add AVTCore Working Group to the second-priority "avoid collision" list? Thanks. --------------------------------------------------------- Name: Multitrans BOF Conflicts to Avoid: First Priority: PIM, MBONED, RMT, V6OPS, BEHAVE, SOFTWIRE Second Priority: tsvarea, intarea, AVTCore --------------------------------------------------------- Tina -----Original Message----- From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On Behalf Of Lee, Yiu Sent: Wednesday, June 22, 2011 4:00 AM To: Tom Taylor Cc: multrans@ietf.org; Roni Even; Ron Bonica Subject: Re: [multrans] Scheduling of MULTRANS BoF +1 On Jun 22, 2011, at 6:27 AM, "Tom Taylor" wrote: > It has just occurred to me that the AVTCore Working Group might have > some interest in the Multicast Transition BoF. We might want to add > that group at least to the second-priority "avoid collision" list. > > Tom Taylor > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans _______________________________________________ multrans mailing list multrans@ietf.org https://www.ietf.org/mailman/listinfo/multrans From cris.pascual.gonzalez@gmail.com Wed Jun 22 19:04:20 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8039A11E8080 for ; Wed, 22 Jun 2011 19:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.153 X-Spam-Level: X-Spam-Status: No, score=-4.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoc-wSoz6sVl for ; Wed, 22 Jun 2011 19:04:20 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id BB45011E8075 for ; Wed, 22 Jun 2011 19:04:19 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p5N24I8Z030732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Jun 2011 04:04:18 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p5N24IoS009868 for ; Thu, 23 Jun 2011 04:04:18 +0200 Received: from JLLORET (vpn245-14.vpns.upv.es [158.42.245.14]) by smtp.upv.es (8.13.6/8.13.6) with SMTP id p5N24HVe026788 for ; Thu, 23 Jun 2011 04:04:17 +0200 Date: Thu, 23 Jun 2011 04:04:17 +0200 Message-Id: <201106230204.p5N24HVe026788@smtp.upv.es> From: Cristina Pascual To: avt@ietf.org CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [AVTCORE] Last 10 Days: EMERGING 2011 || November 20-25, 2011 - Lisbon, Portugal X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 02:04:20 -0000 INVITATION: ================= Note that the submission deadline has been extended to July 1st, 2011. Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== EMERGING 2011 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS EMERGING 2011: The Third International Conference on Emerging Network Intelligence November 20-25, 2011 - Lisbon, Portugal General page: http://www.iaria.org/conferences2011/EMERGING11.html Call for Papers: http://www.iaria.org/conferences2011/CfPEMERGING11.html - regular papers - short papers (work in progress) - industrial presentations - posters - ideas Submission page: http://www.iaria.org/conferences2011/SubmitEMERGING11.html Submission deadline: July 1st, 2011 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the Editorial rules: http://www.iaria.org/editorialrules.html EMERGING 2011 Topics (topics and submission details: see CfP on the site) Evolution of telecommunications network architectures Advanced communications systems; New configurable protocols stacks and real-time mechanisms; Applications and services for next-generation architectures; Scalability and manageability of network architectures; Opportunistic and cooperative communications; Next generation networks (NGN); Optical networks; Wireless networks, Mobile networks; Ad-Hoc, Sensor, Vehicle networks; Access, Residential, Last mile networks; Home, Body and Personal area Networks; Active networks; Self Organizing networks; Storage area networks; Peer-to-Peer and overlay networks; Network measurements and testbeds; Transmission technologies (e.g., Ultra Wideband) Applications and services Peer-to-Peer applications and services; Web services; Mobile applications; Entertainment and games; Home automation; Surveillance, Home monitoring; Medical and health applications; e-commerce, m-commerce; Location-based services; Real-time and multimedia applications; Real-time services over IP Networking and service differentiation Network design and planning; Network management and control; Traffic engineering; Traffic control, Flow control; Congestion and admission control; QoS support and Performance; Routing, Switching, QoS routing; Mobility management; Multicast; Service reliability, availability Emerging networking Network coding; Visualization of network behavior; Semantic routing; Network flow processing; Cross-layer design and optimization; High-speed networking; Context-aware mobile networking Advanced network elements Network processors; Content addressable memories; Multi-core processors; Context-aware reconfigurable devices; Portable and wearable devices; Mobile multimedia devices Optimization Power optimization in data centers; Delay and fault tolerant networks; Video conferencing and telepresence systems; Resource optimization; Context-aware optimization Quality Quality of service; Quality of performance; Quality of experience; Quality of data; Quality of modeling; Quality-oriented routing; Quality of context /degradation, trust, uncertainty, consistency/ Smartness Cognitive radio; Autonomic and dependable communications; Ambient systems; Identity and location in mobile environments; Smart homes; Brain-like networking and computing Discovery Resource discovery; Service discovery; Content discovery; Flaws/anomaly discovery Protection Anticipative control and management; Data protection strategies; Collaborative Internet attack containment; Micro-kernels and robustness Security Trust and credential negotiations; Privacy; Intrusion prevention and containment; Security in virtualization approach; Architectural support for security; Security, privacy, and dependability; Security in cooperative networks Programmability Programmable and real-time network traffic measurements; Adaptive scheduling; Network and application load balancing; High-performance capabilities-based networks; Software techniques to improve virtualized I/O performance End-user Frequently changing user profile; User mobility and ubiquity; Scalable and resource intensive multi-user distributed applications; User identity and multi-service access technologies; End-user perception; End-user based networking and service orchestration; End-user activity recognition with multiple goals Mobility Mobile Internet services; Mobility-oriented protocols /Mobile IP, etc./; Wearable and/or mobile technologies; Self-discovery and localizing entities; Seamless handover Ubiquity Ubiquitous computing; Pervasive and embedded systems; Ubiquitous sustainability; Sensing location; Activity patterns; Smart environments in the workplaces; Ubiquitous cities Semantics and Adaptiveness Content-aware networks; Network-aware applications; Semantic Web; Adaptive systems; Adaptive applications; Self-adaptiveness; Ontology-based adaptation; Semantic profile; Semantic service orchestration; Multi-technology semantic integration /sensors, ehealth, geosensing, etc./ Wireless Wireless access technologies / WLANs, WiMAX, satellite, 3G, etc./; Multi-hop wireless networks /sensor, ad hoc, mesh, etc./; Wireless QoS and reliability; Wireless body area networks; Energy optimization Emerging technologies and applications Vehicular ad hoc networks; Bio-inspired networks; Tele-medicine/e-health networks; User-centric services and applications; Autonomous and autonomic systems; Self-manageable systems; Emerging computation business models; Social networks; eSociety --------------- EMERGING Advisory Chairs Raj Jain, Washington University in St. Louis, USA Michael D. Logothetis, University of Patras, Greece Tulin Atmaca, IT/Telecom&Management SudParis, France Phuoc Tran-Gia, University of Wuerzburg, Germany Nuno M. Garcia, Universidade Lusófonas de Humanidades e Tecnologias, Lisboa, Portugal EMERGING 2011 Industry Liaison Chairs Krishna Murthy, Quintiles, USA Tadashi Araragi, Nippon Telegraph and Telephone Corporation – Kyoto, Japan Robert Foster, Edgemount Solutions - Plano, USA EMERGING 2011 Research Chair David Carrera, Barcelona Supercomputing Center (BSC) / Universitat Politecnica de Catalunya (UPC), Spain Committee: http://www.iaria.org/conferences2011/ComEMERGING11.html ==================== From cris.pascual.gonzalez@gmail.com Wed Jun 22 19:54:49 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD2722800F for ; Wed, 22 Jun 2011 19:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.177 X-Spam-Level: X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj7COyuk8RBJ for ; Wed, 22 Jun 2011 19:54:49 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7761F0C38 for ; Wed, 22 Jun 2011 19:54:48 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p5N2slIe003245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Jun 2011 04:54:47 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p5N2sldO019224 for ; Thu, 23 Jun 2011 04:54:47 +0200 Received: from JLLORET (vpn245-16.vpns.upv.es [158.42.245.16]) by smtp.upv.es (8.13.6/8.13.6) with SMTP id p5N2skxF005471 for ; Thu, 23 Jun 2011 04:54:46 +0200 Date: Thu, 23 Jun 2011 04:54:46 +0200 Message-Id: <201106230254.p5N2skxF005471@smtp.upv.es> From: Cristina Pascual To: avt@ietf.org CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [AVTCORE] Last 10 Days!: AP2PS 2011 || November 20-25, 2011 - Lisbon, Portugal X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 02:54:49 -0000 INVITATION: ================= Note that the submission deadline has been extended to July 1st, 2011. Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== AP2PS 2011 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS AP2PS 2011: The Third International Conference on Advances in P2P Systems November 20-25, 2011 - Lisbon, Portugal General page: http://www.iaria.org/conferences2011/AP2PS11.html Call for Papers: http://www.iaria.org/conferences2011/CfPAP2PS11.html - regular papers - short papers (work in progress) - industrial presentations - posters - ideas Submission page: http://www.iaria.org/conferences2011/SubmitAP2PS11.html Submission deadline: July 1st, 2011 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum and Work in Progress (short papers) options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the Editorial rules: http://www.iaria.org/editorialrules.html AP2PS 2011 Topics (topics and submission details: see CfP on the site) Architectures and protocols Search protocols; Publish and subscribe systems; Overlay based multicast; Multilayer systems; Locality awareness; Gossip-based and epidemic protocols; Integration with network operators and service providers; Autonomic computing and networking; Semantic P2P; Opportunistic networking Applications Content delivery networks; Cloud computing; Public resource computing; Aggregate computing; Web services; Computational, service, and storage Grids; Voice and video streaming and IPTV; Collaborative platforms and social networks ; Network management; Wireless sensor networks; Scientific computing and workflow management systems; Green computing Prototypes and simulations Implementations; Comparative performance analysis; Dependability, resilience and availability; Scalability; Stability; Benchmarking and optimization; Quality of experience Security, trust and reputation Privacy & Anonymity; Trust and reputation management; Free-riding prevention; Authentication and identity management; Fairness and Incentive models; Virtual economies; Digital rights management; Content filtering P2P and wireless convergence P2P in cellular networks; P2P in wireless networks; P2P in ad hoc networks; Integrated approaches; Energy efficiency ---------------------- AP2PS General Chairs Nick Antonopoulos, University of Derby, UK Antonio Liotta, Eindhoven University of Technology, The Netherlands Giuseppe Di Fatta, The University of Reading, UK AP2PS Advisory Chairs Marco Aiello, University of Groningen, The Netherlands Takahiro Hara, University of Osaka, Japan Ouri Wolfson, University of Illinois at Chicago, USA AP2PS 2011 Industry Liaison Chair Christoph Schuba, Oracle Corp., USA Roman Y. Shtykh, Rakuten, Inc., Japan AP2PS 2011 Research Chairs Yasushi Kambayashi, Nippon Institute of Technology, Japan Anders Fongen, Norwegian Defense Research Establishment, Norway Quang Hieu Vu, ETISALAT BT Innovation Center (EBTIC)/ Khalifa University, UAE Committee: http://www.iaria.org/conferences2011/ComAP2PS11.html ==================== From iesg-secretary@ietf.org Thu Jun 23 08:52:17 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C1B11E8171; Thu, 23 Jun 2011 08:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pznPoBVIYzz; Thu, 23 Jun 2011 08:52:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84ED11E8170; Thu, 23 Jun 2011 08:52:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110623155212.30574.63739.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2011 08:52:12 -0700 Cc: avtcore chair , avtcore mailing list , RFC Editor Subject: [AVTCORE] Protocol Action: 'Forward-shifted RTP Redundancy Payload Support' to Proposed Standard (draft-ietf-avt-forward-shifted-red-08.txt) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 15:52:17 -0000 The IESG has approved the following document: - 'Forward-shifted RTP Redundancy Payload Support' (draft-ietf-avt-forward-shifted-red-08.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avt-forward-shifted-red/ Technical Summary This document defines a simple enhancement to RFC 2198 to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). Working Group Summary The need for this work was questioned at the outset, but the arguments advanced in its favour were sufficient to satisfy the people concerned. As a result of its very specific scope, the work drew comments from few people, but the Document Shepherd is satisfied that the reviews were sufficient. Document Quality Colin Perkins bears special mention for his careful reviews at the beginning and during Working Group Last Call. Media type review was posted on January 4, 2010. Personnel The document shepherd is Tom Taylor. The responsible AD is Robert Sparks From Even.roni@huawei.com Fri Jun 24 08:29:51 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798D711E80E7; Fri, 24 Jun 2011 08:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAIe4rmlan6H; Fri, 24 Jun 2011 08:29:50 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DD7C411E80E0; Fri, 24 Jun 2011 08:29:49 -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 <0LNA008LJWDO6G@szxga03-in.huawei.com>; Fri, 24 Jun 2011 23:29:48 +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 <0LNA00FZHWDOAJ@szxga03-in.huawei.com>; Fri, 24 Jun 2011 23:29:48 +0800 (CST) Received: from windows8d787f9 ([109.67.30.132]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LNA00M19WD6K0@szxml12-in.huawei.com>; Fri, 24 Jun 2011 23:29:48 +0800 (CST) Date: Fri, 24 Jun 2011 18:27:28 +0300 From: Roni Even To: 'IETF AVTCore WG' Message-id: <006001cc3283$423f6fe0$c6be4fa0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1F459OcT4m4bpyAh35xQEQ)" Content-language: en-us Thread-index: Acwygzm+B8gOCiLvR1SE24etEXXlhg== Cc: 'Magnus Westerlund' , payload@ietf.org, xrblock@ietf.org Subject: [AVTCORE] Requests for agenda time in Quebec City IETF81 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:29:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_1F459OcT4m4bpyAh35xQEQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, At the IETF 81 we will have one time slot for AVTCore and we will use this timeslot also to present the status of the payload and xrblock working groups for information. As we announced on the mailing lists, the payload and xrblocks WGs are not going to meet in Quebec but we may present open issues if there are any. If you wish to have agenda time at the upcoming meeting in Quebec City regarding AVTcore work, please send an agenda request to the AVTcore chairs. We are trying to prepare the agenda early and not wait for the last minute. We will use the time for presentations giving priority based on the AVTCore milestones and open issues. The draft agenda shows that AVTCore will meet on Wednesday 09:00-11:30 in room 208 AB. Note that this is not the final agenda and the slot for AVTcore may change, the final agenda will be publish on July 1st. Thanks Magnus Westerlund and Roni Even AVTCore Chairs. Ali Begen and Roni Even Payload Chairs Peter Musgrave and Roni Even XRblock Chairs. --Boundary_(ID_1F459OcT4m4bpyAh35xQEQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

At the IETF 81 we will have one time slot for AVTCore and we will use this timeslot also to present the status of the payload and xrblock working groups for information.

 

As we announced on the mailing lists, the payload and xrblocks WGs are not going to meet in Quebec but we may present open issues if there are any.

 

 

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

 

 

We will use the time for pre sentatio on the AVTCore milestones and open issues.

 

 

The draft agenda shows that AVTCore will meet on Wednesday 09:00-11:30 in room 208 AB.

 

Note that this is not the final agenda and the slot for AVTcore may change, the final agenda will be publish on July 1st.

 

 
 
 
 
Thanks
Magnus Westerlund and Roni Even AVTCore Chairs.
 
Ali Begen and Roni Even Payload Chairs
 
Peter Musgrave and Roni Even XRblock Chairs.
  
--Boundary_(ID_1F459OcT4m4bpyAh35xQEQ)-- From Mark.Espe@NetMotionWireless.com Fri Jun 24 13:00:26 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111F311E8212 for ; Fri, 24 Jun 2011 13:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPHqYmStRGB7 for ; Fri, 24 Jun 2011 13:00:25 -0700 (PDT) Received: from DB3EHSOBE004.bigfish.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0A51111E80BA for ; Fri, 24 Jun 2011 13:00:23 -0700 (PDT) Received: from mail122-db3-R.bigfish.com (10.3.81.243) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.22; Fri, 24 Jun 2011 20:00:23 +0000 Received: from mail122-db3 (localhost.localdomain [127.0.0.1]) by mail122-db3-R.bigfish.com (Postfix) with ESMTP id 1ABAADF029A for ; Fri, 24 Jun 2011 20:00:23 +0000 (UTC) X-SpamScore: 0 X-BigFish: VPS0(zzzz1202hzz8275bh8275dhz2fh2a8h668h839h67h) X-Spam-TCS-SCL: 6:0 X-Forefront-Antispam-Report: CIP:66.195.191.12; KIP:(null); UIP:(null); IPVD:NLI; H:NMSEALMAIL02.nmwco.com; RD:66-195-191-12.static.twtelecom.net; EFVD:NLI Received-SPF: pass (mail122-db3: domain of NetMotionWireless.com designates 66.195.191.12 as permitted sender) client-ip=66.195.191.12; envelope-from=Mark.Espe@NetMotionWireless.com; helo=NMSEALMAIL02.nmwco.com ; 02.nmwco.com ; Received: from mail122-db3 (localhost.localdomain [127.0.0.1]) by mail122-db3 (MessageSwitch) id 1308945622696318_2192; Fri, 24 Jun 2011 20:00:22 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.244]) by mail122-db3.bigfish.com (Postfix) with ESMTP id 9E24AD6804B for ; Fri, 24 Jun 2011 20:00:22 +0000 (UTC) Received: from NMSEALMAIL02.nmwco.com (66.195.191.12) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 24 Jun 2011 20:00:22 +0000 Received: from NMSEALMAIL02.nmwco.com ([fe80::493e:9f62:724c:4fd5]) by NMSEALMAIL02.nmwco.com ([fe80::493e:9f62:724c:4fd5%12]) with mapi id 14.01.0270.001; Fri, 24 Jun 2011 13:00:20 -0700 From: Mark Espe To: "avt@ietf.org" Thread-Topic: Nits about draft-ietf-avt-srtp-aes-gcm Thread-Index: AcwyqVP7F7r7j2wkTJeLShbmsfmeAQ== Date: Fri, 24 Jun 2011 20:00:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AeDN BLx5 BThu BfhM CfDw ESig EdjG FxPw HgBM IH1w IObh JYk7 Jybj J6wL KKcn LFXG; 1; YQB2AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {EB415098-3428-4AEC-8865-3BD4B27A4B57}; bQBhAHIAawAuAGUAcwBwAGUAQABuAGUAdABtAG8AdABpAG8AbgB3AGkAcgBlAGwAZQBzAHMALgBjAG8AbQA=; Fri, 24 Jun 2011 20:00:12 GMT; TgBpAHQAcwAgAGEAYgBvAHUAdAAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBhAHYAdAAtAHMAcgB0AHAALQBhAGUAcwAtAGcAYwBtAA== x-cr-puzzleid: {EB415098-3428-4AEC-8865-3BD4B27A4B57} x-originating-ip: [10.128.115.254] Content-Type: multipart/alternative; boundary="_000_F30B43D21A55244BBCC917CEE84E8ECE30AD79A5NMSEALMAIL02nmw_" MIME-Version: 1.0 X-OriginatorOrg: netmotionwireless.com X-Mailman-Approved-At: Sat, 25 Jun 2011 07:56:56 -0700 Subject: [AVTCORE] Nits about draft-ietf-avt-srtp-aes-gcm X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 20:01:40 -0000 --_000_F30B43D21A55244BBCC917CEE84E8ECE30AD79A5NMSEALMAIL02nmw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The draft seems very readable and understandable. I don't think anyone rea= ding the draft as it is will be confused but I have a few suggestions. Section 1.2.3 "... concatenating a 2-octets ..." - lose the 'a' Section 1.2.4 Says Figure 3 but should be Figure 2 After Table 1 'ant' should be 'and' Section 2.3 is about AES-CCM but the second sentence has AES-GCM The discussion of the block counters say they start as "1" or "0" which I a= lways think of as the ASCII characters rather than just a binary one or zer= o which I think is the intent. How about using notation like 0x1 and 0x0? = That would also work later for the CCM flag bytes - they could be 0x5A etc= . Like I said, nits. mark --_000_F30B43D21A55244BBCC917CEE84E8ECE30AD79A5NMSEALMAIL02nmw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The draft seems very readable and understandable.&nb= sp; I don’t think anyone reading the draft as it is will be confused = but I have a few suggestions.  

 

Section 1.2.3  “… concatenating a 2= -octets …” -   lose the ‘a’

 

Section 1.2.4 Says Figure 3 but should be Figure 2

 

After Table 1 ‘ant’ should be ‘and= ’

 

Section 2.3 is about AES-CCM but the second sentence= has AES-GCM

 

The discussion of the block counters say they start = as “1” or “0” which I always think of as the ASCII = characters rather than just a binary one or zero which I think is the inten= t.  How about using notation like 0x1 and 0x0?  That would also work later for the CCM flag bytes – they could be 0x5A etc.&nbs= p;  

 

Like I said, nits.

 

mark

 

 

--_000_F30B43D21A55244BBCC917CEE84E8ECE30AD79A5NMSEALMAIL02nmw_-- From mramalho@cisco.com Sat Jun 25 15:43:49 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DDE11E80CC; Sat, 25 Jun 2011 15:43:49 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhTm-ToJSl8h; Sat, 25 Jun 2011 15:43:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DD41B11E80B1; Sat, 25 Jun 2011 15:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=15103; q=dns/txt; s=iport; t=1309041826; x=1310251426; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=JhyB/SrD1D9XtDYTV8oIL0l/ndcKWzmKVlQR0N4rijQ=; b=mJ3Yk8uKX10/qIyx0aiaHzHOyXZ+Y4vv6cdYD6bbGXiHYMwP1d2643yj Ha0kntJh3cHcvgh9h4yaQXavJhbgVveB8ZR9Wlt5zuPY2GQpUSZE//G/8 CSUHgvxX/gLj/G9M5TD3EEikCAb40bBzMpjxP7v298Ee4IL0s1Tw5KKAL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAOhjBk6tJXG9/2dsb2JhbABTglGVTI8td61QnQ2GMASHLI9Oi0I X-IronPort-AV: E=Sophos;i="4.65,426,1304294400"; d="scan'208,217";a="386284112" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2011 22:43:45 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5PMhjvA020798; Sat, 25 Jun 2011 22:43:45 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Jun 2011 17:43:45 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3389.56B85341" Date: Sat, 25 Jun 2011 17:43:39 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A00414137D@XMB-RCD-209.cisco.com> In-Reply-To: <006001cc3283$423f6fe0$c6be4fa0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Requests for agenda time in Quebec City IETF81 Thread-Index: Acwygzm+B8gOCiLvR1SE24etEXXlhgBBEptg References: <006001cc3283$423f6fe0$c6be4fa0$%roni@huawei.com> From: "Michael Ramalho (mramalho)" To: "Roni Even" , "IETF AVTCore WG" , , "Ali C. Begen (abegen)" X-OriginalArrivalTime: 25 Jun 2011 22:43:45.0221 (UTC) FILETIME=[5720DF50:01CC3389] X-Mailman-Approved-At: Sun, 26 Jun 2011 08:34:47 -0700 Cc: Magnus Westerlund , jacek@ti.com, xrblock@ietf.org, payload@ietf.org, Miaolei , "Paul Jones \(paulej\)" , harada.noboru@lab.ntt.co.jp Subject: Re: [AVTCORE] Requests for agenda time in Quebec City IETF81 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 22:43:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3389.56B85341 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: (Below thread) "please send an agenda request to the AVTcore chairs" =20 Magnus/Roni, =20 As per the recommendation of the Payload Chairs, Ali Begen and Roni Even, I have created a "00" draft for the RTP payload format for ITU-T G.711.0 (lossless and stateless compression of G.711, http://datatracker.ietf.org/doc/draft-ramalho-payload-g7110/ ). =20 Via experience I have found that there is often confusion about G.711.0 - as it is essentially a data compression algorithm. When negotiated end-to-end, it is negotiated as IF it were a traditional lossy codec. However, it can also be employed as a lossless data compression for G.711 payloads in the middle of G.711 negotiated sessions. =20 Thus, it might be beneficial for me to say a few words about the G.711.0 draft if there is sufficient interest. =20 If you believe a short presentation would be beneficial, then I would request a few minutes at the AVTcore agenda to describe the G.711.0 draft. =20 Please advise. =20 Regards, =20 Michael Ramalho =20 =20 =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, June 24, 2011 11:27 AM To: 'IETF AVTCore WG' Cc: 'Magnus Westerlund'; payload@ietf.org; xrblock@ietf.org Subject: [AVTCORE] Requests for agenda time in Quebec City IETF81 =20 Hi, At the IETF 81 we will have one time slot for AVTCore and we will use this timeslot also to present the status of the payload and xrblock working groups for information. =20 As we announced on the mailing lists, the payload and xrblocks WGs are not going to meet in Quebec but we may present open issues if there are any. =20 =20 If you wish to have agenda time at the upcoming meeting in Quebec City regarding AVTcore work, please send an agenda request to the AVTcore chairs. We are trying to prepare the agenda early and not wait for the last minute. =20 =20 We will use the time for pre sentatio on the AVTCore milestones and open issues.=20 =20 =20 The draft agenda shows that AVTCore will meet on Wednesday 09:00-11:30 in room 208 AB.=20 =20 Note that this is not the final agenda and the slot for AVTcore may change, the final agenda will be publish on July 1st. =20 =20 =20 =20 =20 Thanks Magnus Westerlund and Roni Even AVTCore Chairs. =20 Ali Begen and Roni Even Payload Chairs =20 Peter Musgrave and Roni Even XRblock Chairs. =20 ------_=_NextPart_001_01CC3389.56B85341 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Re: (Below thread) “please send an agenda request to the = AVTcore chairs”

 

Magnus/Roni,

 

As per the recommendation of the Payload Chairs, Ali = Begen and Roni Even, I have created a “00” draft for the RTP payload = format for ITU-T G.711.0 (lossless and stateless compression of G.711, htt= p://datatracker.ietf.org/doc/draft-ramalho-payload-g7110/ ).

 

Via experience I have found that there is often confusion = about G.711.0 – as it is essentially a data compression algorithm. When negotiated end-to-end, it is negotiated as IF it were a traditional = lossy codec. However, it can also be employed as a lossless data compression = for G.711 payloads in the middle of G.711 negotiated = sessions.

 

Thus, it might be beneficial for me to say a few words = about the G.711.0 draft if there is sufficient interest.

 

If you believe a short presentation would be beneficial, = then I would request a few minutes at the AVTcore agenda to describe the = G.711.0 draft.

 

Please advise.

 

Regards,

 

Michael Ramalho

 

 

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Friday, June 24, 2011 11:27 AM
To: 'IETF AVTCore WG'
Cc: 'Magnus Westerlund'; payload@ietf.org; xrblock@ietf.org
Subject: [AVTCORE] Requests for agenda time in Quebec City = IETF81

 

Hi,

At the IETF = 81 we will have one time slot for AVTCore and we will use this timeslot also = to present the status of the payload and xrblock working groups for = information.

 

As we = announced on the mailing lists, the payload and xrblocks WGs are not going to meet in = Quebec but we may present open issues if there are any.

 

 

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

 

 

We will use = the time for pre sentatio on the AVTCore milestones and open issues. =

 

 

The draft = agenda shows that AVTCore will meet on Wednesday 09:00-11:30 in room 208 AB. =

 

Note that = this is not the final agenda and the slot for AVTcore may change, the final agenda = will be publish on July 1st.

 

 
= 
 
= 
 
= 
 
= 
Thanks
= 
Magnus Westerlund and Roni =
Even AVTCore Chairs.
 
= 
Ali Begen and Roni Even =
Payload Chairs
 
= 
Peter Musgrave and Roni Even =
XRblock Chairs.
 =
------_=_NextPart_001_01CC3389.56B85341-- From Even.roni@huawei.com Sat Jun 25 22:03:59 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FC521F84A9; Sat, 25 Jun 2011 22:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4K97sV+oqjC; Sat, 25 Jun 2011 22:03:57 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5290A21F84A7; Sat, 25 Jun 2011 22:03: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 <0LND00GGQSQGGA@szxga04-in.huawei.com>; Sun, 26 Jun 2011 13: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 <0LND00DD0SQGTA@szxga04-in.huawei.com>; Sun, 26 Jun 2011 13:03:52 +0800 (CST) Received: from windows8d787f9 ([109.66.27.190]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LND003HJSQ0CB@szxml11-in.huawei.com>; Sun, 26 Jun 2011 13:03:52 +0800 (CST) Date: Sun, 26 Jun 2011 08:01:30 +0300 From: Roni Even In-reply-to: <999109E6BC528947A871CDEB5EB908A00414137D@XMB-RCD-209.cisco.com> To: "'Michael Ramalho (mramalho)'" , 'IETF AVTCore WG' , magnus.westerlund@ericsson.com, "'Ali C. Begen (abegen)'" Message-id: <001a01cc33be$26158890$724099b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_cibZKm5l8y3B5CeYhD+Rtg)" Content-language: en-us Thread-index: Acwygzm+B8gOCiLvR1SE24etEXXlhgBBEptgAA1HabA= References: <006001cc3283$423f6fe0$c6be4fa0$%roni@huawei.com> <999109E6BC528947A871CDEB5EB908A00414137D@XMB-RCD-209.cisco.com> X-Mailman-Approved-At: Sun, 26 Jun 2011 08:34:48 -0700 Cc: 'Magnus Westerlund' , jacek@ti.com, xrblock@ietf.org, payload@ietf.org, 'Miaolei' , "'Paul Jones \(paulej\)'" , harada.noboru@lab.ntt.co.jp Subject: Re: [AVTCORE] Requests for agenda time in Quebec City IETF81 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 05:03:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_cibZKm5l8y3B5CeYhD+Rtg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Michael, We will consider your request based on time available. I also think it will be good to post this information to the payload list with a title like "G.711.0 a data compression payload" or G.711.0 an audio data compression payload" Regards Roni From: Michael Ramalho (mramalho) [mailto:mramalho@cisco.com] Sent: Sunday, June 26, 2011 1:44 AM To: Roni Even; IETF AVTCore WG; magnus.westerlund@ericsson.com; Ali C. Begen (abegen) Cc: Magnus Westerlund; payload@ietf.org; xrblock@ietf.org; Paul Jones (paulej); harada.noboru@lab.ntt.co.jp; Muthu Arul Mozhi Perumal (mperumal); Miaolei; jacek@ti.com Subject: RE: [AVTCORE] Requests for agenda time in Quebec City IETF81 Re: (Below thread) "please send an agenda request to the AVTcore chairs" Magnus/Roni, As per the recommendation of the Payload Chairs, Ali Begen and Roni Even, I have created a "00" draft for the RTP payload format for ITU-T G.711.0 (lossless and stateless compression of G.711, http://datatracker.ietf.org/doc/draft-ramalho-payload-g7110/ ). Via experience I have found that there is often confusion about G.711.0 - as it is essentially a data compression algorithm. When negotiated end-to-end, it is negotiated as IF it were a traditional lossy codec. However, it can also be employed as a lossless data compression for G.711 payloads in the middle of G.711 negotiated sessions. Thus, it might be beneficial for me to say a few words about the G.711.0 draft if there is sufficient interest. If you believe a short presentation would be beneficial, then I would request a few minutes at the AVTcore agenda to describe the G.711.0 draft. Please advise. Regards, Michael Ramalho From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, June 24, 2011 11:27 AM To: 'IETF AVTCore WG' Cc: 'Magnus Westerlund'; payload@ietf.org; xrblock@ietf.org Subject: [AVTCORE] Requests for agenda time in Quebec City IETF81 Hi, At the IETF 81 we will have one time slot for AVTCore and we will use this timeslot also to present the status of the payload and xrblock working groups for information. As we announced on the mailing lists, the payload and xrblocks WGs are not going to meet in Quebec but we may present open issues if there are any. If you wish to have agenda time at the upcoming meeting in Quebec City regarding AVTcore work, please send an agenda request to the AVTcore chairs. We are trying to prepare the agenda early and not wait for the last minute. We will use the time for pre sentatio on the AVTCore milestones and open issues. The draft agenda shows that AVTCore will meet on Wednesday 09:00-11:30 in room 208 AB. Note that this is not the final agenda and the slot for AVTcore may change, the final agenda will be publish on July 1st. Thanks Magnus Westerlund and Roni Even AVTCore Chairs. Ali Begen and Roni Even Payload Chairs Peter Musgrave and Roni Even XRblock Chairs. --Boundary_(ID_cibZKm5l8y3B5CeYhD+Rtg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Michael,

We will consider your request based on time available. I also think = it will be good to post this information to the payload list with a = title like "G.711.0 a  data compression payload" or = G.711.0 an audio data compression payload"

 

Regards

Roni

 

From:= = Michael Ramalho (mramalho) [mailto:mramalho@cisco.com]
Sent: = Sunday, June 26, 2011 1:44 AM
To: Roni Even; IETF AVTCore WG; = magnus.westerlund@ericsson.com; Ali C. Begen (abegen)
Cc: = Magnus Westerlund; payload@ietf.org; xrblock@ietf.org; Paul Jones = (paulej); harada.noboru@lab.ntt.co.jp; Muthu Arul Mozhi Perumal = (mperumal); Miaolei; jacek@ti.com
Subject: RE: [AVTCORE] = Requests for agenda time in Quebec City = IETF81

 

Re: (Below thread) “please send = an agenda request to the AVTcore chairs”

 

Magnus/Roni,

 

As per the recommendation of the Payload Chairs, Ali Begen and Roni = Even, I have created a “00” draft for the RTP payload format = for ITU-T G.711.0 (lossless and stateless compression of G.711, htt= p://datatracker.ietf.org/doc/draft-ramalho-payload-g7110/ = ).

 

Via experience I have found that there is often confusion about = G.711.0 – as it is essentially a data compression algorithm. When = negotiated end-to-end, it is negotiated as IF it were a traditional = lossy codec. However, it can also be employed as a lossless data = compression for G.711 payloads in the middle of G.711 negotiated = sessions.

 

Thus, it might be beneficial for me to say a few words about the = G.711.0 draft if there is sufficient interest.

 

If you believe a short presentation would be beneficial, then I would = request a few minutes at the AVTcore agenda to describe the G.711.0 = draft.

 

Please advise.

 

Regards,

 

Michael Ramalho

 

 

 

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Friday, June 24, 2011 11:27 = AM
To: 'IETF AVTCore WG'
Cc: 'Magnus Westerlund'; = payload@ietf.org; xrblock@ietf.org
Subject: [AVTCORE] Requests = for agenda time in Quebec City = IETF81

 

Hi,

At the IETF = 81 we will have one time slot for AVTCore and we will use this timeslot = also to present the status of the payload and xrblock working groups for = information.

 

As we = announced on the mailing lists, the payload and xrblocks WGs are not = going to meet in Quebec but we may present open issues if there are = any.

 

 

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

 

 

We will use = the time for pre sentatio on the AVTCore milestones and open issues. =

 

 

The draft = agenda shows that AVTCore will meet on Wednesday 09:00-11:30 in room 208 = AB.

 

Note that = this is not the final agenda and the slot for AVTcore may change, the = final agenda will be publish on July = 1st.

 

 
= 
 
= 
 
= 
 
= 
Thanks
= 
Magnus Westerlund and Roni =
Even AVTCore Chairs.
 
= 
Ali Begen and Roni Even =
Payload Chairs
 
= 
Peter Musgrave and Roni Even =
XRblock Chairs.
 =
= --Boundary_(ID_cibZKm5l8y3B5CeYhD+Rtg)-- From whkimbg@gmail.com Mon Jun 27 17:17:57 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3266C9E800A for ; Mon, 27 Jun 2011 17:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6fM6mGlT4Ih for ; Mon, 27 Jun 2011 17:17:56 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA269E8009 for ; Mon, 27 Jun 2011 17:17:56 -0700 (PDT) Received: by wyj26 with SMTP id 26so4010685wyj.31 for ; Mon, 27 Jun 2011 17:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=nG6luZfz49VmQqoO7mn593o5VYexWwCaCgnAlLj3vr8=; b=eQQoQm7NAPLLGEwqAQksGshUz0MYc7emvtSniO8jj9K0+A6YzuuEUhIWiQ1u6nUr2q 0rkzflDpeLZGhqacSdOQsjGoPA1kCaqlFCbDhy5cqhQbcTPwE+xHs7yIYGLrqjuTmO6W KpzVoef44frz7i98gd25vPnLwhp9yzBcR+rhs= 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:cc:content-type; b=jq1J4QxX2iJdmUhToXbyZP3lOmClrj0veohVVnaJ+0fEwiAiqG23/CTJuzhB8qFqDs 6wG7vnYEjWByo51YVIRtvzqjBiw2CDrxon5o60FKUecOUGQa8Wn6dWSDBTpC2KbmWLtN sNqdJa5gVk+pEEsp/GH3MEY0ZMhr1vVVBAj3I= MIME-Version: 1.0 Received: by 10.216.187.75 with SMTP id x53mr168884wem.92.1309220273868; Mon, 27 Jun 2011 17:17:53 -0700 (PDT) Sender: whkimbg@gmail.com Received: by 10.216.170.75 with HTTP; Mon, 27 Jun 2011 17:17:53 -0700 (PDT) Date: Tue, 28 Jun 2011 09:17:53 +0900 X-Google-Sender-Auth: OgFi4awyURiwb9eHbu2WmtwdGFU Message-ID: From: Woo-Hwan Kim To: avt@ietf.org Content-Type: multipart/alternative; boundary=001485f1d81e5b4e7804a6ba998d Cc: magnus.westerlund@ericsson.com, ds_kwon@ensec.re.kr, jklee@ensec.re.kr, jhpark@ensec.re.kr Subject: [AVTCORE] New Version Notification for draft-nsri-avt-aria-srtp-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 00:17:57 -0000 --001485f1d81e5b4e7804a6ba998d Content-Type: text/plain; charset=ISO-8859-1 Hi. We revised the draft(-02 version) "The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP)" http://datatracker.ietf.org/doc/draft-nsri-avt-aria-srtp/ Let me make a request for the AVT WG review. Woo-Hwan Kim From: To: Cc: ; ; ; < jhpark@ensec.re.kr>; Sent: Monday, June 27, 2011 10:32 AM Subject: New Version Notification for draft-nsri-avt-aria-srtp-02.txt A new version of I-D, draft-nsri-avt-aria-srtp-02.txt has been successfully submitted by Woo-Hwan Kim and posted to the IETF repository. Filename: draft-nsri-avt-aria-srtp Revision: 02 Title: The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) Creation date: 2011-06-24 WG ID: Individual Submission Number of pages: 8 Abstract: This document describes the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). It details three modes of operation (CTR, CCM, GCM) and a SRTP Key Derivation Function for ARIA. The IETF Secretariat --001485f1d81e5b4e7804a6ba998d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi.

We revised the draft(-02 version)
"The ARIA Algorit= hm and Its Use with the Secure Real-time Transport Protocol (SRTP)"

Let me = make a request for the AVT WG review.

Woo-Hwan Kim=A0

<= div>
Cc: <ds_kwon@ensec.re.kr= >;=20 <whkim5@ensec.re.kr>; <<= a href=3D"mailto:dongchan@ensec.re.kr">dongchan@ensec.re.kr>; <jhpark@ensec.re.kr>; <jklee@ensec.re.kr>
Sent: Monday, June 27, 2011 10:32 AM
Subject: New Version Notification for=20 draft-nsri-avt-aria-srtp-02.txt

A new version of I-D, draft-nsri-avt-aria-srtp-02.txt has be= en=20 successfully submitted by Woo-Hwan Kim and posted to the IETF=20 repository.

Filename: draft-nsri-avt-aria-srtp
Revision: 02
Ti= tle:=20 The ARIA Algorithm and Its Use with the Secure Real-time Transport=20 Protocol(SRTP)
Creation date: 2011-06-24
WG ID: Individual=20 Submission
Number of pages: 8

Abstract:
=A0=A0 This document d= escribes=20 the use of the ARIA block cipher algorithm
=A0=A0 within the Secure Real= -time=20 Transport Protocol (SRTP) for providing
=A0=A0 confidentiality for the R= eal-time=20 Transport Protocol (RTP) traffic
=A0=A0 and for the control traffic for = RTP, the=20 Real-time Transport Control
=A0=A0 Protocol (RTCP). It details three mod= es of=20 operation (CTR, CCM, GCM)
=A0=A0 and a SRTP Key Derivation Function for= =20 ARIA.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0=A0
The IETF Secretariat
--001485f1d81e5b4e7804a6ba998d-- From magnus.westerlund@ericsson.com Tue Jun 28 01:51:43 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F300521F8636 for ; Tue, 28 Jun 2011 01:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNbD52WTRCqn for ; Tue, 28 Jun 2011 01:51:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DFDE611E80C5 for ; Tue, 28 Jun 2011 01:51:42 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d0-4e09961c11ac Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 64.37.20773.C16990E4; Tue, 28 Jun 2011 10:51:41 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 28 Jun 2011 10:51:39 +0200 Message-ID: <4E09961B.9020601@ericsson.com> Date: Tue, 28 Jun 2011 10:51:39 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] WG adoption of draft-brandenburg-avtcore-rtcp-for-idms-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 08:51:44 -0000 WG, We have approval from our AD to go ahead and taking on Inter Destination Media Playout Synchronization (IDMS) as WG Item. The milestone has been requested and should show up soon. It is: Mar 2012 Submit Specification for Inter-destination Media Playout Synchronization in RTP to IESG for publication as Proposed Standard As we have seen no indication of any competing document, I will hereby declare the existing individual document: https://datatracker.ietf.org/doc/draft-brandenburg-avtcore-rtcp-for-idms/ adopted as WG document. 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 Tue Jun 28 02:22:05 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7274311E8098 for ; Tue, 28 Jun 2011 02:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BfTCq5qcOlT for ; Tue, 28 Jun 2011 02:22:04 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3E53211E807F for ; Tue, 28 Jun 2011 02:22:04 -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 p5S9LC0m009136 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Jun 2011 11:21:22 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 28 Jun 2011 11:21:19 +0200 From: "Van Caenegem, Tom (Tom)" To: Qin Wu , Colin Perkins Date: Tue, 28 Jun 2011 11:21:17 +0200 Thread-Topic: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 Thread-Index: Acwwhf13q16z4B8AR9KTU7srgwqBdAE7LPLA Message-ID: References: <7C8D947749B24396AA011FB286CC69E1@china.huawei.com> In-Reply-To: <7C8D947749B24396AA011FB286CC69E1@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.80 Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 09:22:05 -0000 Qin, See my comments below, Tom -----Original Message----- From: Qin Wu [mailto:sunseawq@huawei.com]=20 Sent: woensdag 22 juni 2011 4:40 To: Colin Perkins; Van Caenegem, Tom (Tom) Cc: 'IETF AVTCore WG'; Roni Even Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-r= tp-04 I agree with Colin's observation.=20 Tom: I suggest you to then include this new rationale in an updated version= of the draft Another basic rational I think is we should use NACK and new report appropr= iately. i.e., both new report and NACK can not be used in any cases. NACK and new report defined in this document are both feedback message, how= ever they should have different uses. we don't expect to see that when NACK is sent from A to B, the new report c= an replace NACK as one alternative and is also sent from A to B. But we al= low that NACK and new report work together in the same sceanrio, e.g.,when = NACK is sent from A to B, the new report is sent from B to C.=20 The basic reason is NACK and new report has totally different semantics, i.= e., when the middlebox or media source detect the packet loss by himself, t= he middlebox or media source SHOULD send NACK message, when the middlebox i= s told by another middlebox or RTP_Reciever about the packet loss, the midd= lebox SHOULD send new report defined in this draft. In that case, we can clearly distinguish the semantics and use of both NACK= and new report.=20 Such rational is clearly described in the last paragraph of section 1 and t= he fifth paragraph of section 2 Tom: what you say above seems to be in conflict with the behaviour you spec= ify in section 3: "Alternatively, the media source may directly monitor th= e amount of feedback reports it receives from downstream. If the media source receives a NACK from another system, it should redistribute that NACK to all other systems that would not otherwise receive it. An example of this is RTCP-SSM in simple feedback model" [Qin]: two distribution sources means we have two levels of SSM communicati= on, one distribution souce is placed at the upstream of the other distribut= ion source. two distribution sources case is just one exmaple to discuss how to use new= report when there are multiple middleboxs or intermediaries between media = source and the receivers.=20 The middlebox can be distribution source and can be other intermediary. Tom: Again, if your provide an example of an RFC 5760 architecture, you can= only talk about one DS! Please clarify your architecture. If you have two DS, then you have two SSM= RTP sessions.. What's the point of linking these? What is your use case? Regards! -Qin ----- Original Message ----- From: "Colin Perkins" To: "Van Caenegem, Tom (Tom)" Cc: "Qin Wu" ; "'IETF AVTCore WG'" ; "Ro= ni Even" Sent: Tuesday, June 21, 2011 10:07 PM Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-r= tp-04 On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: > Hi, >=20 > as promised, these are comments I have on the draft " RTCP Extension for = Third-party Loss Report" >=20 > -IMO the draft does not provide a good rationale on the use case for send= ing this new report. The section 3 (protocol overview) says: >=20 > "If an intermediary receives a NACK from another system, it should redist= ribute that NACK to all other systems that would not otherwise receive it. = An example of this is RTCP-SSM in simple feedback model [RFC5760], where t= he distribution source reflects NACKs to other systems. =20 > If an intermediary receives a NACK from another system, but, for some rea= son, cannot redistribute that NACK, then it may send a third-party loss rep= ort to the systems that were unable to receive the NACK, and won't receive = the NACK via other means. An example would be a distribution source using R= TCP-SSM in Distribution Source Feedback Summary model [RFC5760]." >=20 > My questions:=20 >=20 > -why would the intermediary not be able or capable to send the received N= ACK to the "systems" that were unable to receive the NACK, whereas it would= be able or capable to send the 3rd party loss report to those same "system= s"?=20 Because the intermediary is trying to hide the identity or existence of tho= se systems, and cannot forward the NACK from them without revealing that in= formation > -The DS in RTCP-SSM operating in FB summary mode is mentioned as an examp= le for a case where a NACK cannnot be forwarded. Why is this? RFC5760 does= not prevent a DS to foward the NACK (see the RFC 5760 and my quote from th= at RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00" RFC 5760 allows the NACK to be forwarded, but this would cause the other re= ceivers to become aware of, and keep state for, the participant that sent t= he NACK. If a third-party loss report is used, the other receivers don't be= come aware of the participant that signalled the loss, they just know that = the loss occurred.=20 > -This section 3 makes a distinction between an intermediate that does che= ck the RTP stream for missing packets itself, and an intermediate that does= not, but still the behaviour in terms of FW-ing the NACKs received from ot= her "systems" is exactly the same. Why make this distinction then? >=20 > I still have an outstanding comment which has not been resolved yet. The = section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but sectio= n 6.1.1. talks about two distribution sources, whereas RFC 5760 only define= d ONE SINGLE DS. Please clarify this. [Qin]: two distribution sources means we have two levels of SSM communicati= on, one distribution souce is placed at the upstream of the other distribut= ion source. two distribution sources case is just one exmaple to discuss how to use new= report when there are multiple middleboxs or intermediaries between media = source and the receivers.=20 The middlebox can be distribution source and can be other intermediary. >=20 > Regards > Tom > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From albrecht.schwarz@alcatel-lucent.com Tue Jun 28 05:47:52 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC5321F85DB; Tue, 28 Jun 2011 05:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkaNERNxvmFz; Tue, 28 Jun 2011 05:47:51 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 65A4E21F85E5; Tue, 28 Jun 2011 05:47:47 -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 p5SCkuWj009414 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Jun 2011 14:47:37 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 28 Jun 2011 14:47:34 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Peter Musgrave , Colin Perkins Date: Tue, 28 Jun 2011 14:47:32 +0200 Thread-Topic: [AVTCORE] [xrblock] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt Thread-Index: AcwrWZXiMHWlXe0gSbKRw5gcP95QVQKNy0EQ Message-ID: <5F7BCCF5541B7444830A2288ABBEBC96215F28F7F8@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <01c501cc1c16$ebad8ea0$46298a0a@china.huawei.com> <029f01cc274c$b8fe19c0$46298a0a@china.huawei.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC96215F28F7F8FRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "avt@ietf.org" , "xrblock@ietf.org" Subject: Re: [AVTCORE] [xrblock] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 12:47:52 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC96215F28F7F8FRMRSSXCHMBSD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >> This helps, but to my mind doesn't go far enough. We have the SSRC to id= entify participants. I don't see much benefit from having a separate identi= ty tag in XR blocks. Question for clarification: do you question just the tag element of the proposed measurement identity b= lock (draft-ietf-avt-rtcp-xr-meas-identity-02.txt), or do you want to get c= ompletely rid of the the measurement identity block as such? Keeping in mind that the measurement identity block provides much more capa= bilities when just the SSRC of the measured stream. Thanks, Albrecht ________________________________ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Peter= Musgrave Sent: Mittwoch, 15. Juni 2011 14:41 To: Colin Perkins Cc: avt@ietf.org; xrblock@ietf.org Subject: Re: [AVTCORE] [xrblock] Fw: I-D Action: draft-ietf-avtcore-monarch= -02.txt I agree with Colin Peter Musgrave (as individual) On Tue, Jun 14, 2011 at 6:27 AM, Colin Perkins > wrote: On 10 Jun 2011, at 09:59, Qin Wu wrote: > Hi, >> ----- Original Message ----- >> From: "Colin Perkins" > >> To: "Qin Wu" > >> Cc: >; >; > >> Sent: Thursday, June 09, 2011 9:58 PM >> Subject: Re: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt >> >> >> On 27 May 2011, at 03:36, Qin Wu wrote: >>> This version addresses the open issues regarding identity information r= epetition and acknowledge section. >>> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt >>> >>> The diff is: >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-02 >>> >>> Comments are welcome! >> >> This helps, but to my mind doesn't go far enough. We have the SSRC to id= entify participants. I don't see much benefit from having a separate identi= ty tag in XR blocks. >> > [Qin]: I think that we are talking about how to define future RTCP XR Bl= ock. It seems to me the rule we are following to define the new RTCP XR BL= ock in the avtcore-monarch is a little different from the rule of we are do= ing to the existing RTCP XR described in RFC3611. > > As for the existing XR Block defined in RFC3611, each of the existing XR = Block has allocated a field for SSRC of source. However such identity info= rmation can be repeated several times if several metric blocks reporting on= e stream from one source is carried in the same RTCP Packet. > > In order to reduce overhead to carry duplicated SSRC of source in each me= tric block, in the new XR Block, we separate such SSRC of source out from = each metric block. > > One way is to allocate identity tag field in each metric block which can= be used to tell which metric block report on stream from which source. > > Another way is to follow the existing rules defined in RFC3611. put back = the SSRC of source field into each metric block which also can be used to t= ell which metric block report on stream from which source. > However this rule seems to contradict to the rule of reducing identity in= formation repetition discussed in avtcore-monarch. > > Which way we should follow? I think you should follow RFC 3611. The savings from using the new identity tag don't seem worth the added comp= lexity. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --_000_5F7BCCF5541B7444830A2288ABBEBC96215F28F7F8FRMRSSXCHMBSD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
>> This helps, but = to my mind=20 doesn't go far enough. We have the SSRC to identify participants. I don't s= ee=20 much benefit from having a separate identity tag in XR=20 blocks.
Question for clarification:
do you question just the tag element of the prop= osed=20 measurement identity block (draft-ietf-avt-rtcp-xr-meas-identity-02.txt), or do you w= ant to=20 get completely rid of the the measurement identity block as=20 such?
 
Keeping in mind that the measurement identity bl= ock=20 provides much more capabilities when just the SSRC of the measured=20 stream.
 
Thanks,
Albrecht
 

From: avt-bounces@ietf.org=20 [mailto:avt-bounces@ietf.org] On Behalf Of Peter=20 Musgrave
Sent: Mittwoch, 15. Juni 2011 14:41
To: Coli= n=20 Perkins
Cc: avt@ietf.org; xrblock@ietf.org
Subject: R= e:=20 [AVTCORE] [xrblock] Fw: I-D Action:=20 draft-ietf-avtcore-monarch-02.txt

I agree with Colin

Peter Musgrave
(as individual)

On Tue, Jun 14, 2011 at 6:27 AM, Colin Perkins <= SPAN=20 dir=3Dltr><csp@csperkins.org> wrote:=
On 10 Jun 2011, at 09:59, Qin Wu wrote:
>=20 Hi,
>> ----- Original Message -----
>> From: "Colin=20 Perkins" <csp@csperkins.org>
>>= To:=20 "Qin Wu" <sunseawq@huawei.com>
>= >=20 Cc: <avt@ietf.org>; <xrblock@ietf.org>; <magnus.westerlund@ericss= on.com>
>>=20 Sent: Thursday, June 09, 2011 9:58 PM
>> Subject: Re: [AVTCORE= ] Fw:=20 I-D Action:=20 draft-ietf-avtcore-monarch-02.txt
>>
>>
>> O= n 27=20 May 2011, at 03:36, Qin Wu wrote:
>>> This version addresse= s the=20 open issues regarding identity information repetition and acknowledge=20 section.
>>> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-= monarch-02.txt
>>>
>>>=20 The diff is:
>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore= -monarch-02
>>>
>>>=20 Comments are welcome!
>>
>> This helps, but to my min= d=20 doesn't go far enough. We have the SSRC to identify participants. I don= 't=20 see much benefit from having a separate identity tag in XR=20 blocks.
>>
> [Qin]:  I think that we are talking ab= out=20 how to define future RTCP XR Block. It seems to me the rule we are foll= owing=20  to define the new RTCP XR BLock in the avtcore-monarch is a littl= e=20 different from the rule of we are doing to the existing RTCP XR describ= ed in=20 RFC3611.
>
> As for the existing XR Block defined in RFC361= 1,=20 each of the existing XR Block has allocated  a field for SSRC of=20 source. However such identity information can be repeated several times= if=20 several metric blocks reporting one stream from one source  is car= ried=20 in the same RTCP Packet.
>
> In order to reduce overhead to= =20 carry duplicated SSRC of source in each metric block,  in the new = XR=20 Block, we separate such SSRC of source out from each metric=20 block.
>
> One way is to  allocate identity tag field = in=20 each metric block which can be used to tell which metric block report o= n=20 stream from which source.
>
> Another way is to follow the= =20 existing rules defined in RFC3611. put back the SSRC of source field in= to=20 each metric block which also can be used to tell which metric block rep= ort=20 on stream from which source.
> However this rule seems to contrad= ict=20 to the rule of reducing identity information repetition discussed in=20 avtcore-monarch.
>
> Which way we should=20 follow?


I think you should follow RFC=20 3611.

The savings from using the new identity tag don't seem wor= th=20 the added complexity.

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



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

--_000_5F7BCCF5541B7444830A2288ABBEBC96215F28F7F8FRMRSSXCHMBSD_-- From wwwrun@rfc-editor.org Tue Jun 28 15:36:40 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9788C11E81C5; Tue, 28 Jun 2011 15:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.083 X-Spam-Level: X-Spam-Status: No, score=-102.083 tagged_above=-999 required=5 tests=[AWL=-0.083, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg1xD-MVg9SA; Tue, 28 Jun 2011 15:36:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5050B11E81BB; Tue, 28 Jun 2011 15:36:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3BF8B98C514; Tue, 28 Jun 2011 15:36:39 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110628223639.3BF8B98C514@rfc-editor.org> Date: Tue, 28 Jun 2011 15:36:39 -0700 (PDT) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6285 on Unicast-Based Rapid Acquisition of Multicast RTP Sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 22:36:40 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6285 Title: Unicast-Based Rapid Acquisition of Multicast RTP Sessions Author: B. Ver Steeg, A. Begen, T. Van Caenegem, Z. Vax Status: Standards Track Stream: IETF Date: June 2011 Mailbox: billvs@cisco.com, abegen@cisco.com, Tom.Van_Caenegem@alcatel-lucent.be, zeevvax@microsoft.com Pages: 56 Characters: 141497 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rapid-acquisition-for-rtp-17.txt URL: http://www.rfc-editor.org/rfc/rfc6285.txt 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, and 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 or 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, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. [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 wwwrun@rfc-editor.org Tue Jun 28 15:46:39 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E084B11E8203; Tue, 28 Jun 2011 15:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.1 X-Spam-Level: X-Spam-Status: No, score=-102.1 tagged_above=-999 required=5 tests=[AWL=-0.100, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tGVpiFZhcW4; Tue, 28 Jun 2011 15:46:39 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD6611E81FA; Tue, 28 Jun 2011 15:46:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 882CF98C53D; Tue, 28 Jun 2011 15:35:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110628223542.882CF98C53D@rfc-editor.org> Date: Tue, 28 Jun 2011 15:35:42 -0700 (PDT) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6284 on Port Mapping between Unicast and Multicast RTP Sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 22:46:40 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6284 Title: Port Mapping between Unicast and Multicast RTP Sessions Author: A. Begen, D. Wing, T. Van Caenegem Status: Standards Track Stream: IETF Date: June 2011 Mailbox: abegen@cisco.com, dwing@cisco.com, Tom.Van_Caenegem@alcatel-lucent.com Pages: 30 Characters: 73289 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02.txt URL: http://www.rfc-editor.org/rfc/rfc6284.txt This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Core Maintenance 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 csp@csperkins.org Tue Jun 28 08:53:26 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF2D21F8630; Tue, 28 Jun 2011 08:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bnb+2d73eoeT; Tue, 28 Jun 2011 08:53:25 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id DEEE121F8628; Tue, 28 Jun 2011 08:53:24 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QbabL-0006eU-p1; Tue, 28 Jun 2011 15:53:23 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-50-256720653 From: Colin Perkins In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC96215F28F7F8@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Date: Tue, 28 Jun 2011 16:53:22 +0100 Message-Id: <4517B809-F006-4FD3-8B78-6FB0A26CC450@csperkins.org> References: <01c501cc1c16$ebad8ea0$46298a0a@china.huawei.com> <029f01cc274c$b8fe19c0$46298a0a@china.huawei.com> <5F7BCCF5541B7444830A2288ABBEBC96215F28F7F8@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> To: "Schwarz, Albrecht (Albrecht)" X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 29 Jun 2011 10:50:10 -0700 Cc: xrblock@ietf.org Subject: Re: [AVTCORE] [xrblock] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 15:53:26 -0000 --Apple-Mail-50-256720653 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I was talking about the tag mechanism. Colin On 28 Jun 2011, at 13:47, Schwarz, Albrecht (Albrecht) wrote: > >> This helps, but to my mind doesn't go far enough. We have the SSRC = to identify participants. I don't see much benefit from having a = separate identity tag in XR blocks. > Question for clarification: > do you question just the tag element of the proposed measurement = identity block (draft-ietf-avt-rtcp-xr-meas-identity-02.txt), or do you = want to get completely rid of the the measurement identity block as = such? > =20 > Keeping in mind that the measurement identity block provides much more = capabilities when just the SSRC of the measured stream. > =20 > Thanks, > Albrecht > =20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Peter Musgrave > Sent: Mittwoch, 15. Juni 2011 14:41 > To: Colin Perkins > Cc: avt@ietf.org; xrblock@ietf.org > Subject: Re: [AVTCORE] [xrblock] Fw: I-D Action: = draft-ietf-avtcore-monarch-02.txt >=20 > I agree with Colin >=20 > Peter Musgrave > (as individual) >=20 > On Tue, Jun 14, 2011 at 6:27 AM, Colin Perkins = wrote: > On 10 Jun 2011, at 09:59, Qin Wu wrote: > > Hi, > >> ----- Original Message ----- > >> From: "Colin Perkins" > >> To: "Qin Wu" > >> Cc: ; ; = > >> Sent: Thursday, June 09, 2011 9:58 PM > >> Subject: Re: [AVTCORE] Fw: I-D Action: = draft-ietf-avtcore-monarch-02.txt > >> > >> > >> On 27 May 2011, at 03:36, Qin Wu wrote: > >>> This version addresses the open issues regarding identity = information repetition and acknowledge section. > >>> = http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt > >>> > >>> The diff is: > >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-02 > >>> > >>> Comments are welcome! > >> > >> This helps, but to my mind doesn't go far enough. We have the SSRC = to identify participants. I don't see much benefit from having a = separate identity tag in XR blocks. > >> > > [Qin]: I think that we are talking about how to define future RTCP = XR Block. It seems to me the rule we are following to define the new = RTCP XR BLock in the avtcore-monarch is a little different from the rule = of we are doing to the existing RTCP XR described in RFC3611. > > > > As for the existing XR Block defined in RFC3611, each of the = existing XR Block has allocated a field for SSRC of source. However = such identity information can be repeated several times if several = metric blocks reporting one stream from one source is carried in the = same RTCP Packet. > > > > In order to reduce overhead to carry duplicated SSRC of source in = each metric block, in the new XR Block, we separate such SSRC of source = out from each metric block. > > > > One way is to allocate identity tag field in each metric block = which can be used to tell which metric block report on stream from which = source. > > > > Another way is to follow the existing rules defined in RFC3611. put = back the SSRC of source field into each metric block which also can be = used to tell which metric block report on stream from which source. > > However this rule seems to contradict to the rule of reducing = identity information repetition discussed in avtcore-monarch. > > > > Which way we should follow? >=20 >=20 > I think you should follow RFC 3611. >=20 > The savings from using the new identity tag don't seem worth the added = complexity. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-50-256720653 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
>> This helps, but to my mind=20 doesn't go far enough. We have the SSRC to identify participants. I = don't see=20 much benefit from having a separate identity tag in XR=20 blocks.
Question = for clarification:
do you = question just the tag element of the proposed=20 measurement identity block (draft-ietf-avt-rtcp-xr-meas-identity-02.txt), or do = you want to=20 get completely rid of the the measurement identity block as=20 such?
 
Keeping = in mind that the measurement identity block=20 provides much more capabilities when just the SSRC of the measured=20 stream.
 
Thanks,
Albrecht
 

From: avt-bounces@ietf.org=20 [mailto:avt-bounces@ietf.org] On Behalf Of Peter=20 Musgrave
Sent: Mittwoch, 15. Juni 2011 14:41
To: = Colin=20 Perkins
Cc: avt@ietf.org; = xrblock@ietf.org
Subject: = Re:=20 [AVTCORE] [xrblock] Fw: I-D Action:=20 draft-ietf-avtcore-monarch-02.txt

I agree with Colin

Peter Musgrave
(as individual)

On Tue, Jun 14, 2011 at 6:27 AM, Colin = Perkins <csp@csperkins.org> = wrote:
On 10 Jun 2011, at 09:59, Qin Wu wrote:
>=20 Hi,
>> ----- Original Message -----
>> From: = "Colin=20 Perkins" <csp@csperkins.org>
>> = To:=20 "Qin Wu" <sunseawq@huawei.com>
>>= ;=20 Cc: <avt@ietf.org>; <xrblock@ietf.org>; <magnus.westerlund@ericsson.= com>
>>=20 Sent: Thursday, June 09, 2011 9:58 PM
>> Subject: Re: = [AVTCORE] Fw:=20 I-D Action:=20 = draft-ietf-avtcore-monarch-02.txt
>>
>>
>> On = 27=20 May 2011, at 03:36, Qin Wu wrote:
>>> This version = addresses the=20 open issues regarding identity information repetition and = acknowledge=20 section.
>>> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-m= onarch-02.txt
>>>
>>>=20 The diff is:
>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-= monarch-02
>>>
>>>=20 Comments are welcome!
>>
>> This helps, but to my = mind=20 doesn't go far enough. We have the SSRC to identify participants. I = don't=20 see much benefit from having a separate identity tag in XR=20 blocks.
>>
> [Qin]:  I think that we are talking = about=20 how to define future RTCP XR Block. It seems to me the rule we are = following=20  to define the new RTCP XR BLock in the avtcore-monarch is a = little=20 different from the rule of we are doing to the existing RTCP XR = described in=20 RFC3611.
>
> As for the existing XR Block defined in = RFC3611,=20 each of the existing XR Block has allocated  a field for SSRC = of=20 source. However such identity information can be repeated several = times if=20 several metric blocks reporting one stream from one source  is = carried=20 in the same RTCP Packet.
>
> In order to reduce overhead = to=20 carry duplicated SSRC of source in each metric block,  in the = new XR=20 Block, we separate such SSRC of source out from each metric=20 block.
>
> One way is to  allocate identity tag = field in=20 each metric block which can be used to tell which metric block = report on=20 stream from which source.
>
> Another way is to follow = the=20 existing rules defined in RFC3611. put back the SSRC of source field = into=20 each metric block which also can be used to tell which metric block = report=20 on stream from which source.
> However this rule seems to = contradict=20 to the rule of reducing identity information repetition discussed in=20= avtcore-monarch.
>
> Which way we should=20 follow?


I think you should follow RFC=20 3611.

The savings from using the new identity tag don't seem = worth=20 the added complexity.

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



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

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



-- 
Colin Perkins



= --Apple-Mail-50-256720653-- From tom.van_caenegem@alcatel-lucent.com Thu Jun 30 02:08:32 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B9621F86AD for ; Thu, 30 Jun 2011 02:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrFvUerR90C3 for ; Thu, 30 Jun 2011 02:08:31 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 19F3221F867E for ; Thu, 30 Jun 2011 02:08:30 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5U97v2d006233 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jun 2011 11:08:15 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 30 Jun 2011 11:08:00 +0200 From: "Van Caenegem, Tom (Tom)" To: Qin Wu , Colin Perkins Date: Thu, 30 Jun 2011 11:07:59 +0200 Thread-Topic: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 Thread-Index: Acw2Dxz3+w9d+HmbQDeZ1sE8x85IhwA76SPg Message-ID: References: <7C8D947749B24396AA011FB286CC69E1@china.huawei.com> <489F755BBD284D18AE9AD47F17317B6F@china.huawei.com> In-Reply-To: <489F755BBD284D18AE9AD47F17317B6F@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.80 Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 09:08:32 -0000 Qin, See below, =20 [Qin]: Okay, maybe there is some ambiguity on describing media source behav= ior. I will add some texts to get consistent with=20 Intermediary behavior of suppressing feedback described in the previous par= agraph. The proposed text may look like: " Alternatively, the media source may directly monitor the amount of feedback reports it receives from downstream. If the media source notic= es the loss itself, then it may send a NACK downstream towards the receivers to suppress feedback. I= f the media source receives a NACK from another system, it should redistribute that NACK to all other systems that would not otherwise receive it. An example of this is RTCP-SSM in simple feedback model [RFC5760], where the distribution source reflects NACKs to other systems. If the media sourc= e receives a NACK from another system, but, for some reason, cannot redistribute that NACK, then it may send a third-party loss report to the systems that were unable to receive the NACK, and won't receive the NACK via other means. An example would be a distribution source using RTCP-SSM in Distribution Source Feedback Summary model [RFC5760]. " Tom: the "for some reason" will have to be clarified. I also do not underst= and: "may send a third-party loss report to the systems that were unable t= o receive the NACK" Based on the rationale provided by Colin why one may n= ot always simply forward/redistribute NACKs, this is not a matter of system= s being "UNABLE" to receive the NACK. They are always able, it is just a de= cision from the intermediate to not FW the received NACKs.. [Qin]: I agree we should follow RFC5760 architecture. But I am not sure the= example I give in the section 6.1.1 conflict with RFC5760 architecture. The architecture I bulild looks like this: Suppose there are 100 RTP receivers, in these receivers, 50 RTP receivers b= elong to DS A, 50 RTP receivers belong to DS B, DS A may be placed at the u= pstream of DS B or DS A is adjacent to DS B at the same level, Do this kind archite= cture conflict with RFC5760? If yes, please point out. Tom: a DS represents the source/RTP sender of the SSM RTP session. Receiver= s send out NACKs related to packet loss in a particular SSM RTP session. If= a receiver is not "belonging" to a DS X (I guess you mean ..is not receivi= ng packets from that DS X), then why would you implement some kind of FB su= ppression for such receiver(s) within the SSM RTP session that is sourced b= y that DS X ??? Regards! -Qin ----- Original Message ----- From: "Colin Perkins" To: "Van Caenegem, Tom (Tom)" Cc: "Qin Wu" ; "'IETF AVTCore WG'" ; "Ro= ni Even" Sent: Tuesday, June 21, 2011 10:07 PM Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-r= tp-04 On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: > Hi, >=20 > as promised, these are comments I have on the draft " RTCP Extension for = Third-party Loss Report" >=20 > -IMO the draft does not provide a good rationale on the use case for send= ing this new report. The section 3 (protocol overview) says: >=20 > "If an intermediary receives a NACK from another system, it should redist= ribute that NACK to all other systems that would not otherwise receive it. = An example of this is RTCP-SSM in simple feedback model [RFC5760], where t= he distribution source reflects NACKs to other systems. =20 > If an intermediary receives a NACK from another system, but, for some rea= son, cannot redistribute that NACK, then it may send a third-party loss rep= ort to the systems that were unable to receive the NACK, and won't receive = the NACK via other means. An example would be a distribution source using R= TCP-SSM in Distribution Source Feedback Summary model [RFC5760]." >=20 > My questions:=20 >=20 > -why would the intermediary not be able or capable to send the received N= ACK to the "systems" that were unable to receive the NACK, whereas it would= be able or capable to send the 3rd party loss report to those same "system= s"?=20 Because the intermediary is trying to hide the identity or existence of tho= se systems, and cannot forward the NACK from them without revealing that in= formation > -The DS in RTCP-SSM operating in FB summary mode is mentioned as an examp= le for a case where a NACK cannnot be forwarded. Why is this? RFC5760 does= not prevent a DS to foward the NACK (see the RFC 5760 and my quote from th= at RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00" RFC 5760 allows the NACK to be forwarded, but this would cause the other re= ceivers to become aware of, and keep state for, the participant that sent t= he NACK. If a third-party loss report is used, the other receivers don't be= come aware of the participant that signalled the loss, they just know that = the loss occurred.=20 > -This section 3 makes a distinction between an intermediate that does che= ck the RTP stream for missing packets itself, and an intermediate that does= not, but still the behaviour in terms of FW-ing the NACKs received from ot= her "systems" is exactly the same. Why make this distinction then? >=20 > I still have an outstanding comment which has not been resolved yet. The = section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but sectio= n 6.1.1. talks about two distribution sources, whereas RFC 5760 only define= d ONE SINGLE DS. Please clarify this. [Qin]: two distribution sources means we have two levels of SSM communicati= on, one distribution souce is placed at the upstream of the other distribut= ion source. two distribution sources case is just one exmaple to discuss how to use new= report when there are multiple middleboxs or intermediaries between media = source and the receivers.=20 The middlebox can be distribution source and can be other intermediary. >=20 > Regards > Tom > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From bill.wu@huawei.com Thu Jun 30 02:36:23 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A798321F872B for ; Thu, 30 Jun 2011 02:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onPot2OHbsu1 for ; Thu, 30 Jun 2011 02:36:22 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 44D7A21F863B for ; Thu, 30 Jun 2011 02:36:17 -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 <0LNL00K3BJZITG@szxga03-in.huawei.com> for avt@ietf.org; Thu, 30 Jun 2011 17:35:42 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNL00KI3JY3MD@szxga03-in.huawei.com> for avt@ietf.org; Thu, 30 Jun 2011 17:35:42 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABQ01835; Thu, 30 Jun 2011 17:35:40 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 30 Jun 2011 17:35:35 +0800 Received: from w53375q (10.138.41.76) by smtpscn.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 30 Jun 2011 17:35:36 +0800 Date: Thu, 30 Jun 2011 17:35:36 +0800 From: Qin Wu X-Originating-IP: [10.138.41.76] To: "Van Caenegem, Tom (Tom)" , Colin Perkins Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <7C8D947749B24396AA011FB286CC69E1@china.huawei.com> <489F755BBD284D18AE9AD47F17317B6F@china.huawei.com> Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 09:36:23 -0000 Hi, ----- Original Message ----- From: "Van Caenegem, Tom (Tom)" To: "Qin Wu" ; "Colin Perkins" Cc: "'IETF AVTCore WG'" ; "Roni Even" Sent: Thursday, June 30, 2011 5:07 PM Subject: RE: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 Qin, See below, [Qin]: Okay, maybe there is some ambiguity on describing media source behavior. I will add some texts to get consistent with Intermediary behavior of suppressing feedback described in the previous paragraph. The proposed text may look like: " Alternatively, the media source may directly monitor the amount of feedback reports it receives from downstream. If the media source notices the loss itself, then it may send a NACK downstream towards the receivers to suppress feedback. If the media source receives a NACK from another system, it should redistribute that NACK to all other systems that would not otherwise receive it. An example of this is RTCP-SSM in simple feedback model [RFC5760], where the distribution source reflects NACKs to other systems. If the media source receives a NACK from another system, but, for some reason, cannot redistribute that NACK, then it may send a third-party loss report to the systems that were unable to receive the NACK, and won't receive the NACK via other means. An example would be a distribution source using RTCP-SSM in Distribution Source Feedback Summary model [RFC5760]. " Tom: the "for some reason" will have to be clarified. I also do not understand: "may send a third-party loss report to the systems that were unable to receive the NACK" Based on the rationale provided by Colin why one may not always simply forward/redistribute NACKs, this is not a matter of systems being "UNABLE" to receive the NACK. They are always able, it is just a decision from the intermediate to not FW the received NACKs. [Qin]: No, basic rationale is prevent the receivers know who send NACK. In SSM case, the rationale is Distribution Source Feedback Summary model does not allow the NACK to be forwarded downstream. [Qin]: I agree we should follow RFC5760 architecture. But I am not sure the example I give in the section 6.1.1 conflict with RFC5760 architecture. The architecture I bulild looks like this: Suppose there are 100 RTP receivers, in these receivers, 50 RTP receivers belong to DS A, 50 RTP receivers belong to DS B, DS A may be placed at the upstream of DS B or DS A is adjacent to DS B at the same level, Do this kind architecture conflict with RFC5760? If yes, please point out. Tom: a DS represents the source/RTP sender of the SSM RTP session. Receivers send out NACKs related to packet loss in a particular SSM RTP session. If a receiver is not "belonging" to a DS X (I guess you mean ..is not receiving packets from that DS X), then why would you implement some kind of FB suppression for such receiver(s) within the SSM RTP session that is sourced by that DS X ??? [Qin]: What I am saying here each DS has its own coverage for receivers. You can implement FB suppression for each DS. But you are not necessary to prevent interaction between DS. Anyway since you or other folks may think this multiple DS case introduce ambiguity and complexity, I will remove this case from the draft, Is that okay with you? Regards! -Qin ----- Original Message ----- From: "Colin Perkins" To: "Van Caenegem, Tom (Tom)" Cc: "Qin Wu" ; "'IETF AVTCore WG'" ; "Roni Even" Sent: Tuesday, June 21, 2011 10:07 PM Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: > Hi, > > as promised, these are comments I have on the draft " RTCP Extension for Third-party Loss Report" > > -IMO the draft does not provide a good rationale on the use case for sending this new report. The section 3 (protocol overview) says: > > "If an intermediary receives a NACK from another system, it should redistribute that NACK to all other systems that would not otherwise receive it. An example of this is RTCP-SSM in simple feedback model [RFC5760], where the distribution source reflects NACKs to other systems. > If an intermediary receives a NACK from another system, but, for some reason, cannot redistribute that NACK, then it may send a third-party loss report to the systems that were unable to receive the NACK, and won't receive the NACK via other means. An example would be a distribution source using RTCP-SSM in Distribution Source Feedback Summary model [RFC5760]." > > My questions: > > -why would the intermediary not be able or capable to send the received NACK to the "systems" that were unable to receive the NACK, whereas it would be able or capable to send the 3rd party loss report to those same "systems"? Because the intermediary is trying to hide the identity or existence of those systems, and cannot forward the NACK from them without revealing that information > -The DS in RTCP-SSM operating in FB summary mode is mentioned as an example for a case where a NACK cannnot be forwarded. Why is this? RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and my quote from that RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00" RFC 5760 allows the NACK to be forwarded, but this would cause the other receivers to become aware of, and keep state for, the participant that sent the NACK. If a third-party loss report is used, the other receivers don't become aware of the participant that signalled the loss, they just know that the loss occurred. > -This section 3 makes a distinction between an intermediate that does check the RTP stream for missing packets itself, and an intermediate that does not, but still the behaviour in terms of FW-ing the NACKs received from other "systems" is exactly the same. Why make this distinction then? > > I still have an outstanding comment which has not been resolved yet. The section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but section 6.1.1. talks about two distribution sources, whereas RFC 5760 only defined ONE SINGLE DS. Please clarify this. [Qin]: two distribution sources means we have two levels of SSM communication, one distribution souce is placed at the upstream of the other distribution source. two distribution sources case is just one exmaple to discuss how to use new report when there are multiple middleboxs or intermediaries between media source and the receivers. The middlebox can be distribution source and can be other intermediary. > > Regards > Tom > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ From tom.van_caenegem@alcatel-lucent.com Thu Jun 30 02:48:51 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C0021F87BA for ; Thu, 30 Jun 2011 02:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHDV3jWq2YwZ for ; Thu, 30 Jun 2011 02:48:50 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id D577821F87B4 for ; Thu, 30 Jun 2011 02:48:49 -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 p5U9keuw002244 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jun 2011 11:48:07 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 30 Jun 2011 11:47:45 +0200 From: "Van Caenegem, Tom (Tom)" To: Qin Wu , Colin Perkins Date: Thu, 30 Jun 2011 11:47:44 +0200 Thread-Topic: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 Thread-Index: Acw3CSzo8aknAo+RTU+VDPkYB5HGLAAAJDgA Message-ID: References: <7C8D947749B24396AA011FB286CC69E1@china.huawei.com> <489F755BBD284D18AE9AD47F17317B6F@china.huawei.com> In-Reply-To: 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 Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 09:48:51 -0000 Qin, See below Tom -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: donderdag 30 juni 2011 11:36 To: Van Caenegem, Tom (Tom); Colin Perkins Cc: 'IETF AVTCore WG'; Roni Even; Qin Wu Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-r= tp-04 Hi, ----- Original Message ----- From: "Van Caenegem, Tom (Tom)" To: "Qin Wu" ; "Colin Perkins" Cc: "'IETF AVTCore WG'" ; "Roni Even" Sent: Thursday, June 30, 2011 5:07 PM Subject: RE: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-r= tp-04 Qin, See below, =20 [Qin]: Okay, maybe there is some ambiguity on describing media source behav= ior. I will add some texts to get consistent with=20 Intermediary behavior of suppressing feedback described in the previous par= agraph. The proposed text may look like: " Alternatively, the media source may directly monitor the amount of feedback reports it receives from downstream. If the media source notic= es the loss itself, then it may send a NACK downstream towards the receivers to suppress feedback. I= f the media source receives a NACK from another system, it should redistribute that NACK to all other systems that would not otherwise receive it. An example of this is RTCP-SSM in simple feedback model [RFC5760], where the distribution source reflects NACKs to other systems. If the media sourc= e receives a NACK from another system, but, for some reason, cannot redistribute that NACK, then it may send a third-party loss report to the systems that were unable to receive the NACK, and won't receive the NACK via other means. An example would be a distribution source using RTCP-SSM in Distribution Source Feedback Summary model [RFC5760]. " Tom: the "for some reason" will have to be clarified. I also do not underst= and: "may send a third-party loss report to the systems that were unable t= o receive the NACK" Based on the rationale provided by Colin why one may n= ot always simply forward/redistribute NACKs, this is not a matter of system= s being "UNABLE" to receive the NACK. They are always able, it is just a de= cision from the intermediate to not FW the received NACKs. [Qin]: No, basic rationale is prevent the receivers know who send NACK.=20 In SSM case, the rationale is Distribution Source Feedback Summary model do= es not allow the NACK to be forwarded downstream. Tom: In RFC 5760 for SSM in FB summary mode, the DS might also forward RTCP= feedback messages and transmit them in the SSM session, when this is expli= citly signaled. It is a service/deployment decision whether NACKs are hence= FW-ed or not, and there may be good reasons to not do so, but saying that = such systems(i..e RTP Rx) are unable to receive the NACK is not justified I= MO. [Qin]: I agree we should follow RFC5760 architecture. But I am not sure the= example I give in the section 6.1.1 conflict with RFC5760 architecture. The architecture I bulild looks like this: Suppose there are 100 RTP receivers, in these receivers, 50 RTP receivers b= elong to DS A, 50 RTP receivers belong to DS B, DS A may be placed at the u= pstream of DS B or DS A is adjacent to DS B at the same level, Do this kind archite= cture conflict with RFC5760? If yes, please point out. Tom: a DS represents the source/RTP sender of the SSM RTP session. Receiver= s send out NACKs related to packet loss in a particular SSM RTP session. If= a receiver is not "belonging" to a DS X (I guess you mean ..is not receivi= ng packets from that DS X), then why would you implement some kind of FB su= ppression for such receiver(s) within the SSM RTP session that is sourced b= y that DS X ??? [Qin]: What I am saying here each DS has its own coverage for receivers. Yo= u can implement FB suppression for each DS. But you are not necessary to pr= event interaction between DS. Anyway since you or other folks may think this multiple DS case introduce a= mbiguity and complexity, I will remove this case from the draft, Is that ok= ay with you? Tom: Fine!=20 Regards! -Qin ----- Original Message ----- From: "Colin Perkins" To: "Van Caenegem, Tom (Tom)" Cc: "Qin Wu" ; "'IETF AVTCore WG'" ; "Ro= ni Even" Sent: Tuesday, June 21, 2011 10:07 PM Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-r= tp-04 On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: > Hi, >=20 > as promised, these are comments I have on the draft " RTCP Extension for = Third-party Loss Report" >=20 > -IMO the draft does not provide a good rationale on the use case for send= ing this new report. The section 3 (protocol overview) says: >=20 > "If an intermediary receives a NACK from another system, it should redist= ribute that NACK to all other systems that would not otherwise receive it. = An example of this is RTCP-SSM in simple feedback model [RFC5760], where t= he distribution source reflects NACKs to other systems. =20 > If an intermediary receives a NACK from another system, but, for some rea= son, cannot redistribute that NACK, then it may send a third-party loss rep= ort to the systems that were unable to receive the NACK, and won't receive = the NACK via other means. An example would be a distribution source using R= TCP-SSM in Distribution Source Feedback Summary model [RFC5760]." >=20 > My questions:=20 >=20 > -why would the intermediary not be able or capable to send the received N= ACK to the "systems" that were unable to receive the NACK, whereas it would= be able or capable to send the 3rd party loss report to those same "system= s"?=20 Because the intermediary is trying to hide the identity or existence of tho= se systems, and cannot forward the NACK from them without revealing that in= formation > -The DS in RTCP-SSM operating in FB summary mode is mentioned as an examp= le for a case where a NACK cannnot be forwarded. Why is this? RFC5760 does= not prevent a DS to foward the NACK (see the RFC 5760 and my quote from th= at RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00" RFC 5760 allows the NACK to be forwarded, but this would cause the other re= ceivers to become aware of, and keep state for, the participant that sent t= he NACK. If a third-party loss report is used, the other receivers don't be= come aware of the participant that signalled the loss, they just know that = the loss occurred.=20 > -This section 3 makes a distinction between an intermediate that does che= ck the RTP stream for missing packets itself, and an intermediate that does= not, but still the behaviour in terms of FW-ing the NACKs received from ot= her "systems" is exactly the same. Why make this distinction then? >=20 > I still have an outstanding comment which has not been resolved yet. The = section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but sectio= n 6.1.1. talks about two distribution sources, whereas RFC 5760 only define= d ONE SINGLE DS. Please clarify this. [Qin]: two distribution sources means we have two levels of SSM communicati= on, one distribution souce is placed at the upstream of the other distribut= ion source. two distribution sources case is just one exmaple to discuss how to use new= report when there are multiple middleboxs or intermediaries between media = source and the receivers.=20 The middlebox can be distribution source and can be other intermediary. >=20 > Regards > Tom > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From Internet-Drafts@ietf.org Thu Jun 30 14:45:03 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9350611E832E; Thu, 30 Jun 2011 14:45:03 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9d9RCZRYS6K; Thu, 30 Jun 2011 14:45:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E88711E8326; Thu, 30 Jun 2011 14:45:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110630214502.29563.16557.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 14:45:02 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D ACTION:draft-ietf-avtcore-idms-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 21:45: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 Core Maintenance Working Group of the IETF. Title : RTCP for inter-destination media synchronization Author(s) : O. van Deventer, et al Filename : draft-ietf-avtcore-idms-00.txt Pages : 21 Date : 2011-06-30 This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for inter-destination media synchronization (IDMS). The RTCP XR Block Type, registered with IANA based on an ETSI specification, is used to collect media play- out information from participants in a group playing-out (watching, listening, etc.) a specific RTP media stream. The RTCP packet type specified by this document is used to distribute a summary of the collected information so that the participants can synchronize play- out. Typical applications for IDMS are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, network quiz shows, multi-playing online games, etc. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-idms-00.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-avtcore-idms-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-06-30143832.I-D@ietf.org> --NextPart--