From nobody Sat Apr 2 08:47:35 2016 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 E750212D12C for ; Sat, 2 Apr 2016 08:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJGXORpUr76e for ; Sat, 2 Apr 2016 08:47:33 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3772C12D0FE for ; Sat, 2 Apr 2016 08:47:33 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-de-56ffe993a480 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 90.15.22880.399EFF65; Sat, 2 Apr 2016 17:47:31 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.248.2; Sat, 2 Apr 2016 17:47:30 +0200 From: Magnus Westerlund To: IETF AVTCore WG , Stephen Casner Message-ID: <56FFE98E.2070406@ericsson.com> Date: Sat, 2 Apr 2016 12:47:26 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM2K7uu7kl//DDLr2q1m87FnJbvFi1RwW ByaPy1e8PZYs+ckUwBTFZZOSmpNZllqkb5fAlXF72hPmgl8CFW/6zjI3MF7m7WLk5JAQMJGY Oe0ZK4QtJnHh3nq2LkYuDiGBI4wSmw9/ZYVwljFKtF7fyAhSxSZgIXHzRyMbiC0soCVx9scJ IJuDQ0TAWeLmnyCQMK+AtsT3ea+YQWwWARWJw+cmgpWLCsRIHH93jhGiRlDi5MwnLCCtzAL2 Eg+2loGEmQXkJZq3zgZrFQIa09DUwTqBkW8Wko5ZCB2zkHQsYGRexShanFpcnJtuZKyXWpSZ XFycn6eXl1qyiREYYAe3/Nbdwbj6teMhRgEORiUe3gXq/8OEWBPLiitzDzFKcDArifDaPgcK 8aYkVlalFuXHF5XmpBYfYpTmYFES582J/BcmJJCeWJKanZpakFoEk2Xi4JRqYDRjj5y14mFZ iOoBPbfIYqVn6htMdjsv4/8svFDj/c4bNSwaHsrv78hKu3xPP1bt58L7LcbZ0C2MxePC89KM oqeNC67r2y5hvqlRsKBb0GzRkcSU7b/3x+YuiyxJq9/AzLml1vTTkeMm83psMjSfhB17zPDG OzVWpMzzVo/j6S8mt4xeXEoJVmIpzkg01GIuKk4EANrX6UksAgAA Archived-At: Subject: [AVTCORE] Header Compression and RFC5285bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 15:47:35 -0000 Hi, Stephen Casner raised a private comment on the draft-ietf-avtext-sdes-hdr-ext-05 when he did the IANA expert review. This was that both draft-ietf-avtext-sdes-hdr-ext-05 and RFC5285bis doesn't discuss impact of header compression due to the presence of RTP header extensions. I have to agree that this is something that at least RFC5285bis should have a discussion on. There are some impact. In the case of Robust Header Compression (ROHC) (RFC 5795 and RFC 5225) the impact to my understanding is the following. RFC5225 and the RTP profile don't compress the actual header extension at all. The X bit in the header is compressed and it is classified in Section A.5 as Rarely changing. The assumption here is that what value is set on a previous packet will be maintained on the next. Looking at the emerging usages that is mostly right, but there will be periods where the x bit may be flipping its value. The usage I am considering is these initial inclusion of the MID, CNAME etc. However for example a video stream, it is sufficient to include the header extension in a single packet out potentially many for an particular video image/frame. Thus one might have a on, off, next TS, on, then off on subsequent packets. The impact of the classification as Rarely changing is that when a change is needed a larger header than otherwise needed will be sent. Thus the impact will be that each on and off behaviour will result in one and maybe two larger ROHC headers to get the change across compared to if no RTP header extensions would have been present. I haven't looked at CRTP, but I would guess similar impact. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Mon Apr 4 10:24:53 2016 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 E0A4512D158 for ; Mon, 4 Apr 2016 10:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP9bCd-O9bwU for ; Mon, 4 Apr 2016 10:24:49 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683A912D115 for ; Mon, 4 Apr 2016 10:24:49 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-05-5702a35fbfc0 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F3.87.22880.F53A2075; Mon, 4 Apr 2016 19:24:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.248.2; Mon, 4 Apr 2016 19:24:46 +0200 From: Magnus Westerlund To: , , , , , References: <20160122061024.2C4AA18046C@rfc-editor.org> Message-ID: <5702A356.1090900@ericsson.com> Date: Mon, 4 Apr 2016 14:24:38 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160122061024.2C4AA18046C@rfc-editor.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7um78YqZwg9W7FS2u3etnt5h+5i+j xcuelewW8ztPs1s8bTzLaPGk5QezxboDf1ks7szYwe7A4bF4xRRWj9Zne1k9vjx5yeSxZMlP Jo+9W7I8dmx+wOoxa+cTFo9j888xBnBEcdmkpOZklqUW6dslcGUc29vAWtAgUrGg7yZTA+N9 /i5GTg4JAROJTbtms0PYYhIX7q1n62Lk4hASOMIo8ejDXSYIZxmjxJIfj5hAqtgELCRu/mhk A7GFBcwlDtybyAhSJCIwj1Hi6CcQhwOow1xi16kYkBpmAVWJHZPXMIPYvALaEi+PHwezWQRU JM6/+gu2WVQgRuL4u3OMEDWCEidnPmEBsTmBdm3q+cACMpJZwF7iwdYyiJHyEs1bZ4ONEQIa 2dDUwTqBUXAWku5ZCB2zkHQsYGRexShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYIwe3/Nbd wbj6teMhRgEORiUe3gWnGMOFWBPLiitzDzFKcDArifBKLWAKF+JNSaysSi3Kjy8qzUktPsQo zcGiJM6bE/kvTEggPbEkNTs1tSC1CCbLxMEp1cDIU/gmwm7GQd1Or7pTKb/fMwo+mMyn8rz3 4BWzghP5FenXokw1HNZVdfK4H6jsMBeyWe/14cvlw+JKIX9L2n/ucZj9+cTxyvz9+66/8Ldp Trukbvfes+bOEjN7c+fTp71to39Yn5jyomtL2aYD9zZN+nT9/21BLZWthROv1CVMXR4juXJK g0O5EktxRqKhFnNRcSIAZNdAuY0CAAA= Archived-At: Cc: avt@ietf.org, timebow@163.com Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3611 (4597) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:24:52 -0000 Hi, I have looked at this errata. It appears to be correct. I checked Liu's calculation and get the same value. I think the reason the wrong value is in the RFC is due that the authors calculated the 33% loss value and used that to calculate the burst density, rather than 4/12s. As this can be confusing when implementing I propose that we verify this Errata. Please provide any feedback on this proposal no later than the 18th of April. Cheers Magnus Westerlund Den 2016-01-22 kl. 03:10, skrev RFC Errata System: > The following errata report has been submitted for RFC3611, > "RTP Control Protocol Extended Reports (RTCP XR)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3611&eid=4597 > > -------------------------------------- > Type: Technical > Reported by: Liu Yuanlong > > Section: 4.7.2 > > Original Text > ------------- > burst density 84, which corresponds to 33% > > Corrected Text > -------------- > burst density 85, which corresponds to 33% > > Notes > ----- > error calculation for burst density, burst density=4/12*256=85.33...≈85 > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC3611 (draft-ietf-avt-rtcp-report-extns-06) > -------------------------------------- > Title : RTP Control Protocol Extended Reports (RTCP XR) > Publication Date : November 2003 > Author(s) : T. Friedman, Ed., R. Caceres, Ed., A. Clark, Ed. > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Mon Apr 4 10:28:04 2016 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 70C8612D115 for ; Mon, 4 Apr 2016 10:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q4H5OlT-v_V for ; Mon, 4 Apr 2016 10:28:01 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB3812D7E5 for ; Mon, 4 Apr 2016 10:27:06 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-dd-5702a3e89d14 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4D.40.23401.8E3A2075; Mon, 4 Apr 2016 19:27:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.248.2; Mon, 4 Apr 2016 19:27:03 +0200 To: , References: <20150722191648.2D97918020A@rfc-editor.org> <55B0A8A7.7060005@ericsson.com> From: Magnus Westerlund Message-ID: <5702A3E2.2050106@ericsson.com> Date: Mon, 4 Apr 2016 14:26:58 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <55B0A8A7.7060005@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM2K7lu6LxUzhBjMPalpMP/OX0eJlz0p2 i/mdp9ktpjb+Z3Vg8fjy5CWTx5IlP5k8Vi/5w+oxa+cTlgCWKC6blNSczLLUIn27BK6M/tlv mAva5StmTc9qYGwT72Lk5JAQMJGY/GcZE4QtJnHh3nq2LkYuDiGBI4wSi+duZ4FwljFK7Ly9 h72LkYNDWMBR4tNiaZAGEQEtiWmXfoCFhQQiJSb+kgQJMwtoS1yecQlsJpuAhcTNH41sIDYv UPxhxwxWEJtFQEViwYGZzCC2qECMxPF35xghagQlTs58wgJicwroSOy+d48NZDyzgL3Eg61l EOPlJZq3zgZrFQIa2dDUwTqBUXAWku5ZCB2zkHQsYGRexShanFpcnJtuZKSXWpSZXFycn6eX l1qyiREYzge3/LbawXjwueMhRgEORiUe3gWnGMOFWBPLiitzDzFKcDArifBKLWAKF+JNSays Si3Kjy8qzUktPsQozcGiJM6bE/kvTEggPbEkNTs1tSC1CCbLxMEp1cCoMZ1tkqPP7Ef1XtmO Z85K8Rm2/Le7sbbzacvVO7c8rPyzJmp2XN7W6qCc/fLb5GcKty3ib//oNd16WHJpBcekpK// ee68uxbOuON5xO1DMi3TtSa9sxX98fhB3ZkbYntfsVqGmfKLMHQx9HyYNq9JRmLBYrMTx7wu vA6J5QvYe6X/QsM/9Z0FSizFGYmGWsxFxYkA733uOmMCAAA= Archived-At: Cc: finlayson@live555.com, avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3711 (4425) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:28:03 -0000 Ben, Can you please put this Errata into Held for Document update. I think you can change it to Editorial rather than Technical. Cheers Magnus Den 2015-07-23 kl. 05:41, skrev Magnus Westerlund: > Hi, > > I think this errata is editorial rather than technical. This as the > error is in the part not specified by this RFC, rather as you say > RFC3550. I don't think it is likely to cause any interoperability issue, > but it should be retain. Thus I propose that it is put into the > > HOLD for Document update > > Category. Please provide an further comments on this. > > Cheers > > Magnus Westerlund > (Chair) > > > Den 2015-07-22 kl. 21:16, skrev RFC Errata System: >> The following errata report has been submitted for RFC3711, >> "The Secure Real-time Transport Protocol (SRTP)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3711&eid=4425 >> >> -------------------------------------- >> Type: Technical b>> Reported by: Ross Finlayson >> >> Section: 3.4 >> >> Original Text >> ------------- >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ >> |V=2|P| RC | PT=SR or RR | length | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> >> >> Corrected Text >> -------------- >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ >> |V=2|P| RC | PT=SR or RR | length | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> >> >> Notes >> ----- >> The boundary between the "PT=SR or RR" and the "length" fields is >> wrong: The boundary is shown as being between bits 16 and 17; it >> should be between bits 15 and 16. I.e., the "PT=SR or RR" field >> should be 8 bits long, not 9. >> >> This is just a minor bug, because the equivalent diagram in RFC 3550 >> (the normative reference for RTCP) is correct. Nonetheless, this bug >> should probably be added to the errata for RFC 3711 >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3711 (draft-ietf-avt-srtp-09) >> -------------------------------------- >> Title : The Secure Real-time Transport Protocol (SRTP) >> Publication Date : March 2004 >> Author(s) : M. Baugher, D. McGrew, M. Naslund, E. Carrara, >> K. Norrman >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Mon Apr 4 10:37:26 2016 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 8922112D614 for ; Mon, 4 Apr 2016 10:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSysB9Q4_ku8 for ; Mon, 4 Apr 2016 10:37:22 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4C012D115 for ; Mon, 4 Apr 2016 10:37:21 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-96-5702a6505c02 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E4.B6.16394.056A2075; Mon, 4 Apr 2016 19:37:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.248.2; Mon, 4 Apr 2016 19:37:19 +0200 To: , , , References: <20150427154813.ECA28180092@rfc-editor.org> From: Magnus Westerlund Message-ID: <5702A648.4010502@ericsson.com> Date: Mon, 4 Apr 2016 14:37:12 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20150427154813.ECA28180092@rfc-editor.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2K7tG7AMqZwg89/pCymn/nLaPGyZyW7 xfzO0+wWTxvPMlo8afnBbHHyyw4WBzaP1md7WT2+PHnJ5LFkyU8mjx2bH7B63L11iclj1s4n LAFsUVw2Kak5mWWpRfp2CVwZ+2bvYC64IlWx8O4BtgbG/yJdjJwcEgImEjf3HmWGsMUkLtxb z9bFyMUhJHCEUWLrk73sEM4yRomZd6eyglQJC5hLnFu1AswWEciV6D3+DaiDA6jIXOL8S34Q k1lAT6L7WylIBZuAhcTNH41sIDavgLbEnmdtYDaLgIpE28a9jCC2qECMxPF35xghagQlTs58 wgIyhhOo90JDPsREe4kHW8tAKpgF5CWat84Gu1gIaGJDUwfrBEbBWUiaZyF0zELSsYCReRWj aHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYNgf3PJbdQfj5TeOhxgFOBiVeHgXnGIMF2JNLCuu zD3EKMHBrCTCe34JU7gQb0piZVVqUX58UWlOavEhRmkOFiVx3uzIf2FCAumJJanZqakFqUUw WSYOTqkGxqniR086NO66o7p8GecX77WHzhtld0kop0wpcBLSDNFtc7bcejzN6JnWtJlvm9ks jE5/XSXLLXk9W+uu97m83Kd3Co7fShDbzs6nZXAiZEUg+3VrgzPSOxYpbLb4+PeNcI/dd5X1 9r0szV3bTubLVdrc/fe6fs2xrI2bdtWf2nBo05+9cj6F15RYijMSDbWYi4oTAemLObJ3AgAA Archived-At: Cc: Thomas.Belling@nokia.com, avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4867 (4348) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:37:25 -0000 WG, I am co-author of this document. If there are any controversy around the consensus here I will let my co-chair or the AD judge that. However, the WG should progress this Errata. It has been created due to actual interoperability issues that has been discussed in 3GPP SA4. From my perspective the errata also represents the intention of the document. Thus I propose that this errata is verified. Please provide any feedback by the 18th of April. Cheers Magnus Westerlund Den 2015-04-27 kl. 12:48, skrev RFC Errata System: > The following errata report has been submitted for RFC4867, > "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4867&eid=4348 > > -------------------------------------- > Type: Technical > Reported by: Thomas Belling > > Section: 4.3.1 > > Original Text > ------------- > The encoder SHOULD follow a received codec mode request, but MAY > change to a lower-numbered mode if it so chooses, for example, to > control congestion. > > > Corrected Text > -------------- > The encoder MUST follow a received codec mode request as soon as > possible. It SHOULD use the requested mode, but MAY change to a > lower-numbered mode if it so chooses, for example, to > control congestion. However, the encoder MUST NOT use a > higher-numbered mode than the received codec mode request. > > > Notes > ----- > This seems to be the intention of the existing text, but is not explicitly stated. It is essential for the end-to-end mode control and interoperability with 3GPP CS networks that a peer does not send higher modes than requested. > > This erratum has been discussed and endorsed by the 3GPP SA4 group before submission to IETF. > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4867 (draft-ietf-avt-rtp-amr-bis-06) > -------------------------------------- > Title : RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs > Publication Date : April 2007 > Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Mon Apr 4 10:39:21 2016 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 D4F3D12D173 for ; Mon, 4 Apr 2016 10:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggmMwwVcaagA for ; Mon, 4 Apr 2016 10:39:17 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693F912D115 for ; Mon, 4 Apr 2016 10:39:17 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-ae-5702a6c32fac Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 07.77.30858.3C6A2075; Mon, 4 Apr 2016 19:39:15 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.248.2; Mon, 4 Apr 2016 19:39:14 +0200 To: , , , References: <20150427155709.23479180092@rfc-editor.org> From: Magnus Westerlund Message-ID: <5702A6BB.3080402@ericsson.com> Date: Mon, 4 Apr 2016 14:39:07 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20150427155709.23479180092@rfc-editor.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM2K7n+7hZUzhBh9uaVlMP/OX0eJlz0p2 i/mdp9ktnjaeZbR40vKD2eLklx0sDmwerc/2snp8efKSyWPJkp9MHjs2P2D1uHvrEpPHrJ1P WALYorhsUlJzMstSi/TtErgyZs/8yFSwQaViz4GdjA2MB6S6GDk5JARMJD43P2WGsMUkLtxb z9bFyMUhJHCEUeLo1QmMEM4yRonW94fAqoQFzCUmTljEBGKLCORK9B7/xgZiCwHF1y9eC9TA wcEsoCfR/a0UJMwmYCFx80cjWAmvgLbEt8MbwcawCKhIXJm0C8wWFYiROP7uHCNEjaDEyZlP WEBsTqDejj8wI+0lHmwtAwkzC8hLNG+dzQyxVVuioamDdQKj4Cwk3bMQOmYh6VjAyLyKUbQ4 tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzD0D275bbCD8eVzx0OMAhyMSjy8C04xhguxJpYVV+Ye YpTgYFYS4T2/hClciDclsbIqtSg/vqg0J7X4EKM0B4uSOG925L8wIYH0xJLU7NTUgtQimCwT B6dUA2MBv5RDvo6J8ruHnGUOVg99Pp+c/KpCXNHuukLm3PTQ/En+SlIyK5QLMvmtpnRxunkY bj0xuXKO+YNF/5Um8ymvXTjx3OlKtwuy6Z2l0daZDzpSjr4SNza7ekoi75bm0jlfb0ov9S1X MTvqPHPtwqk3bN+YfPZ/kbltZsRt76MMXDxXc+udPymxFGckGmoxFxUnAgDRMrhHeQIAAA== Archived-At: Cc: Thomas.Belling@nokia.com, avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4867 (4349) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:39:20 -0000 WG, I am co-author of this document. If there are any controversy around the consensus here I will let my co-chair or the AD judge that. However, the WG should progress this Errata. It has been created due to actual interoperability issues that has been discussed in 3GPP SA4. From my perspective the errata also represents the intention of the document. Thus I propose that this errata is verified. Please provide any feedback by the 18th of April. Cheers Magnus Westerlund Den 2015-04-27 kl. 12:57, skrev RFC Errata System: > The following errata report has been submitted for RFC4867, > "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4867&eid=4349 > > -------------------------------------- > Type: Technical > Reported by: Thomas Belling > > Section: 8.1 > > Original Text > ------------- > mode-set: Restricts the active codec mode set to a subset of all > modes, for example, to be able to support transport > channels such as GSM networks in gateway use cases. > Possible values are a comma separated list of modes from > the set: 0,...,7 (see Table 1a [2]). The SID frame type > 8 and NO_DATA (frame type 15) are never included in the > mode set, but can always be used. If mode-set is > specified, it MUST be abided, and frames encoded with > modes outside of the subset MUST NOT be sent in any RTP > payload or used in codec mode requests. If not present, > all codec modes are allowed for the payload type. > > > Corrected Text > -------------- > mode-set: Restricts the active codec mode set to a subset of all > modes, for example, to be able to support transport > channels such as GSM networks in gateway use cases. > Possible values are a comma separated list of modes from > the set: 0,...,7 (see Table 1a [2]). The SID frame type > 8 and NO_DATA (frame type 15) are never included in the > mode set, but can always be used. If mode-set is > specified, it MUST be abided, i.e. frames encoded with > modes outside of the subset MUST NOT be sent in any RTP > payload and codec mode requests MUST only use modes > within the mode-set or CMR=15. If the mode-set parameter > is not present, then all codec modes are allowed for the > payload type. > > > Notes > ----- > The existing text rules out that CMR=15 is used when a mode-set has been negotiated. However, this contradicts a statement in .clause 4.3.1 that if a terminal has no preference in which mode to receive, it SHOULD set CMR=15 in all its outbound payloads. > > This erratum has been discussed and endorsed by the 3GPP SA4 group before submission to IETF. > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4867 (draft-ietf-avt-rtp-amr-bis-06) > -------------------------------------- > Title : RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs > Publication Date : April 2007 > Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Mon Apr 4 10:41:47 2016 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 405B912D14E for ; Mon, 4 Apr 2016 10:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFhIN3jb4yIg for ; Mon, 4 Apr 2016 10:41:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CEE212D60F for ; Mon, 4 Apr 2016 10:36:28 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-cb-5702a61ba63b Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CD.71.23401.B16A2075; Mon, 4 Apr 2016 19:36:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Mon, 4 Apr 2016 19:36:26 +0200 To: , , , References: <20150427154444.78210180092@rfc-editor.org> From: Magnus Westerlund Message-ID: <5702A612.4090802@ericsson.com> Date: Mon, 4 Apr 2016 14:36:18 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20150427154444.78210180092@rfc-editor.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM2K7hK70MqZwg77tchbTz/xltHjZs5Ld Yn7naXaLp41nGS2etPxgtjj5ZQeLA5tH67O9rB5fnrxk8liy5CeTx47ND1g97t66xOQxa+cT lgC2KC6blNSczLLUIn27BK6Mq89XMxfsMak4Nf05UwPjXo0uRk4OCQETia6fDxkhbDGJC/fW s3UxcnEICRxhlDi/+j8jhLOMUWLK/wcsIFXCAuYS0xdtYQOxRQRyJXqPfwOzhYDil1+/Z+1i 5OBgFtCT6P5WChJmE7CQuPmjEayEV0BbYv+RV2BjWARUJFacW8QKYosKxEgcf3eOEaJGUOLk zCdgNZxAvT+ufGWHGGkv8WBrGUiYWUBeonnrbGaIrdoSDU0drBMYBWch6Z6F0DELSccCRuZV jKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIGhf3DLb6sdjAefOx5iFOBgVOLhXXCKMVyINbGs uDL3EKMEB7OSCO/5JUzhQrwpiZVVqUX58UWlOanFhxilOViUxHlzIv+FCQmkJ5akZqemFqQW wWSZODilGhiLFOPq8nt/sCvzqUz+lCL0Sb8y8vUj2xuyWw8zl/ILfL40v++3+YETV/qWt7DZ +b5lEDaSqIierB67c2mCwa2Z6m3HXD8LP5nk+C2OZW/a4gpBtYO324/lz/tst6LDyH71ln17 17euT1Dc6/7W55L0Y6vDBV6na9gTD7o86/ZiKA0TuCLw5IISS3FGoqEWc1FxIgD+7ReLeQIA AA== Archived-At: Cc: Thomas.Belling@nokia.com, avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4867 (4347) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:41:45 -0000 WG, I am co-author of this document. If there are any controversy around the consensus here I will let my co-chair or the AD judge that. However, the WG should progress this Errata. It has been created due to actual interoperability issues that has been discussed in 3GPP SA4. From my perspective the errata also represents the intention of the document. Thus I propose that this errata is verified. Please provide any feedback by the 18th of April. Cheers Magnus Westerlund Den 2015-04-27 kl. 12:44, skrev RFC Errata System: > The following errata report has been submitted for RFC4867, > "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4867&eid=4347 > > -------------------------------------- > Type: Technical > Reported by: Thomas Belling > > Section: 4.3.1 > > Original Text > ------------- > CMR (4 bits): Indicates a codec mode request sent to the speech > encoder at the site of the receiver of this payload. The value of > the CMR field is set to the frame type index of the corresponding > speech mode being requested. The frame type index may be 0-7 for > AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined > in Table 1a in [4]. CMR value 15 indicates that no mode request > is present, and other values are for future use. > > The codec mode request received in the CMR field is valid until the > next codec mode request is received, i.e., a newly received CMR value > corresponding to a speech mode, or NO_DATA overrides the previously > received CMR value corresponding to a speech mode or NO_DATA. > Therefore, if a terminal continuously wishes to receive frames in the > same mode X, it needs to set CMR=X for all its outbound payloads, and > if a terminal has no preference in which mode to receive, it SHOULD > set CMR=15 in all its outbound payloads. > > If receiving a payload with a CMR value that is not a speech mode or > NO_DATA, the CMR MUST be ignored by the receiver. > > > Corrected Text > -------------- > CMR (4 bits): Indicates a codec mode request sent to the speech > encoder at the site of the receiver of this payload. The value of > the CMR field is set to the frame type index of the corresponding > speech mode being requested. The frame type index may be 0-7 for > AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined > in Table 1a in [4]. CMR value 15 indicates that the receiver has > no preference in which mode within the negotiated mode set to > receive, and other values are for future use. > > The codec mode request received in the CMR field is valid until the > next codec mode request is received, i.e., a newly received CMR value > corresponding to a speech mode, or CMR=15 overrides the previously > received CMR value corresponding to a speech mode or CMR=15. > Therefore, if a terminal continuously wishes to receive frames not > higher than mode X, it needs to set CMR=X for all its outbound > payloads, and if a terminal has no preference in which mode within > the negotiated mode set to receive, it SHOULD set CMR=15 in all its > outbound payloads. > > If receiving a payload with a CMR value that is not a speech mode or > CMR=15, the CMR MUST be ignored by the receiver. > > > Notes > ----- > The definition of CMR 15 as "no mode request is present", could be understood to suggest that other previously received CMR values remain applicable. However, this contradicts text in the subsequent paragraphs suggesting CMR=15 should be used when the "terminal has no preference in which mode to receive", and stating that any previously received CMR value is overridden by CMR=15. > > It is thus unclear for a receiving entity that has previously > received a CMR value requesting a lower AMR mode and then receives a CMR value 15 if it should continue to send using the lower AMR mode or if it can select a higher mode within the negotiated mode set based on own preferences. > > CMR 15 is referred to as "NO_DATA" in subsequent text, but "NO_DATA" is not well defined. This value appears in the quoted references, but these references are only quoted for CMR values 0 to 7/8. > > It is also not perfectly clear if CMR=15 allows for any mode, or > only modes within the negotiated mode set. However, the definition of the mode-set parameter in Clause 8.1 suggests that only modes within the negotiated mode-set can be sent when a mode-set has been negotiated. > > The text "if a terminal continuously wishes to receive frames in the same mode X, it needs to set CMR=X for all its outbound payloads" seems to suggest that the receiver will always follow the request, although it may also choose to send lower modes, as explained in text further below. > > This erratum has been discussed and endorsed by the 3GPP SA4 group before submission to IETF. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4867 (draft-ietf-avt-rtp-amr-bis-06) > -------------------------------------- > Title : RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs > Publication Date : April 2007 > Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Mon Apr 4 11:28:22 2016 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 4406312D191 for ; Mon, 4 Apr 2016 11:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWTXsl8jLQ-T for ; Mon, 4 Apr 2016 11:28:10 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FF612D198 for ; Mon, 4 Apr 2016 11:28:08 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-f1-5702b236934e Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0C.38.23401.632B2075; Mon, 4 Apr 2016 20:28:07 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.248.2; Mon, 4 Apr 2016 20:28:05 +0200 To: Kevin Gross , "avt@ietf.org" , Ben Campbell References: <20150818173656.46E36180092@rfc-editor.org> <55EFEFF0.5060502@ericsson.com> <5613956B.1090501@ericsson.com> From: Magnus Westerlund Message-ID: <5702B22D.4080304@ericsson.com> Date: Mon, 4 Apr 2016 15:27:57 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM2K7sa75JqZwg2U1Fi97VrJbzO88zW7x 4lA7mwOzx7+r25k9liz5yeQxa+cTlgDmKC6blNSczLLUIn27BK6M22fnsBd8N6xoaLVtYLyt 3MXIySEhYCIx++oZVghbTOLCvfVsXYxcHEICRxglrq6ayAjhLGOU2P3iKliVsECExIzNbUA2 B4eIQIbEs8MlEDVLWST2dk9kB6lhE7CQuPmjkQ3E5hXQljg1fRUTiM0ioCKxv/cWmC0qECNx /N05RogaQYmTM5+wgMzkFAiUuLDNCsRkFrCXeLC1DKSCWUBeonnrbGYQWwhoYkNTB+sERoFZ SJpnIXTMQtKxgJF5FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgiB7c8ttqB+PB546HGAU4 GJV4eBecYgwXYk0sK67MPcQowcGsJMJrtY4pXIg3JbGyKrUoP76oNCe1+BCjNAeLkjhvTuS/ MCGB9MSS1OzU1ILUIpgsEwenVAOj4pb3Z8r/1Ld3L2dfwRYiqjG94a3VWZ5nv/MeHeKVrinh c5r+fK8pr4Tx5ze94poZu2Z1FbD91LgeM/3hlhXZCU+nskgVsX4JZfG9+OGJr9aqb0afXmrK LVi87Nt/lmUZFisnshzRS2TWPscbVe/otVJvrdSB23n6+X8UJSpVtigrBjWzO9YosRRnJBpq MRcVJwIAJBPRkE0CAAA= Archived-At: Subject: Re: [AVTCORE] Fwd: Technical - Re: [Editorial Errata Reported] RFC7273 (4450) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:28:19 -0000 Ben, Can you please update the Errata with the below original and edited text. This has been available on the list for quite some time so I suggest that you verify it after editing it. Section 4.8: Original Text ------------- ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002) ptp-domain-name = "domain-name=" 1*16ptp-domain-char ptp-domain-char = %x21-7E ; PTP domain allowed number range: 0-127 (IEEE 1588-2008) ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3 ptp-domain-n1 = DIGIT ; 0-9 ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99 ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119 / "12" %x30-37 ; 120-127 Corrected Text -------------- ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002) ptp-domain-name = 1*16ptp-domain-char ptp-domain-char = %x21-7E ; PTP domain allowed number range: 0-127 (IEEE 1588-2008) ptp-domain-nmbr = ptp-domain-dgts ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3 ptp-domain-n1 = DIGIT ; 0-9 ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99 ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119 / "12" %x30-37 ; 120-127 The Note should also be updated: There is an inconsistency between ABNF in section 4.8 and examples in section 5.5. Due to evidence, that current implementations are working to what is shown in the examples, this is resolved by updating the ABNF specification. cheers Magnus Den 2016-01-19 kl. 23:16, skrev Kevin Gross: > The authors are in agreement that the most recent proposal is the > desired fix and there doesn't seem to be any dissent in AVTCORE about > it. Can we get the errata updated to reflect this most recent proposal? > It is still showing my original report - > https://www.rfc-editor.org/errata_search.php?rfc=7273 > > Kevin Gross - AVA Networks > > On Sun, Dec 6, 2015 at 1:00 PM, Kevin Gross > wrote: > > The authors and I propose the following fix for the reported RFC > 7273 errata. These ABNF changes bring the ABNF specification into > agreement with the examples in the RFC. Current RFC 7273 > implementations have been based on the examples. > > Original Text > ------------- > ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002) > ptp-domain-name = "domain-name=" 1*16ptp-domain-char > ptp-domain-char = %x21-7E > > ; PTP domain allowed number range: 0-127 (IEEE 1588-2008) > ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts > ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3 > ptp-domain-n1 = DIGIT ; 0-9 > ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99 > ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119 > / "12" %x30-37 ; 120-127 > > Corrected Text > -------------- > ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002) > ptp-domain-name = 1*16ptp-domain-char > ptp-domain-char = %x21-7E > > ; PTP domain allowed number range: 0-127 (IEEE 1588-2008) > ptp-domain-nmbr = ptp-domain-dgts > ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3 > ptp-domain-n1 = DIGIT ; 0-9 > ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99 > ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119 > / "12" %x30-37 ; 120-127 > > > Kevin Gross - AVA Networks > > On Thu, Oct 8, 2015 at 12:37 PM, Kevin Gross > wrote: > > Yes, I will take your discussion into account when proposing > final ABNF changes. I wanted first to make sure there were no > objection to the general proposal of fixing this by conforming > ABNF to examples. Since we have seen no objections, I will > proceed to prepare a revision. > > Kevin Gross - AVA Networks > > On Tue, Oct 6, 2015 at 3:33 AM, Magnus Westerlund > > wrote: > > Hi Kevin, > > Can you please review my previous email in detail: > https://mailarchive.ietf.org/arch/msg/avt/kjoyUZh-9c4lYMM6pXQhH30TebY > > I think you need to confirm on what changes that is really > proposed here, and thus my feedback is relevant for this. > > However, I have so far seen no one objecting to the general > intention to at least make alignment with the examples? > > Cheers > > Magnus Westerlund > (AVTCORE chair) > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Mon Apr 4 14:14:20 2016 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 78B2A12D8A9 for ; Mon, 4 Apr 2016 14:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWC1AgwHj68U for ; Mon, 4 Apr 2016 14:14:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598A812D89B for ; Mon, 4 Apr 2016 14:14:16 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-f8-5702d926fb00 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C2.9B.23401.629D2075; Mon, 4 Apr 2016 23:14:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.248.2; Mon, 4 Apr 2016 23:14:12 +0200 To: Kevin Gross References: <20151201081617.45982180004@rfc-editor.org> From: Magnus Westerlund Message-ID: <5702D919.3040407@ericsson.com> Date: Mon, 4 Apr 2016 18:14:01 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbE9RFftJlO4wYb/Ihb3Ht9isph+5i+j xcuelewW8ztPs1s0/r/OajGz6QK7xYtD7WwW3zZfZ7R40vKD2YHT48ffVywe/65uZ/Z4sHkF m8eXJy+ZPJYs+cnksWPzA1aPWTufsHgcXHeBOYAjissmJTUnsyy1SN8ugSujZV4He8FkiYrp Rw6xNDC2CXUxcnJICJhIXFrynBXCFpO4cG89WxcjF4eQwBFGifWNy5ggnGWMEh/3z2YBqRIW MJe49GgeO4gtIqAu8WjXQyYQW0igTqL723YWkAZmgdNMEi3TZ4EVsQlYSNz80cgGYvMKaEt8 nzkNbB2LgIpEz+NjYENFBWIkjr87xwhRIyhxcuYTsDinQKDE3a9TweqZgebMnH+eEcKWl2je OpsZYrG2RENTB+sERsFZSNpnIWmZhaRlASPzKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzA qDm45bfVDsaDzx0PMQpwMCrx8C44xRguxJpYVlyZe4hRgoNZSYT3wWWmcCHelMTKqtSi/Pii 0pzU4kOM0hwsSuK8OZH/woQE0hNLUrNTUwtSi2CyTBycUg2MiVeip5w1nxC0yup2lJOF/IWZ 2mdaCrrybm+wv5N4TGOxv71kr+cnoeqr7VppJXl7ZUz3Pj1tpS639lP3zAVy+g7zLaN1/soq L/q22vs895/9+9LOszk9i2D4drjWMDQoZ9vNqzU2VTZtPzVbuo3e3DL5tMLWLq9acNnh5fyT NXsu5TMsnfNRiaU4I9FQi7moOBEAB3gvMJYCAAA= Archived-At: Cc: "avt@ietf.org" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC7273 (4548) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 21:14:18 -0000 Den 2015-12-06 kl. 15:37, skrev Kevin Gross: > The authors and I have discussed this with John Fletcher (the reporter). > The proposed change here does clarify the intent of the draft and I am > not opposed to adopting this. WG, I concur with the authors view and propose that this Errata is Verified. Please provide any disagreement or comments no later than 18th of April. Cheers Magnus Westerlund (Chair) > > Kevin Gross - AVA Networks > > On Tue, Dec 1, 2015 at 1:16 AM, RFC Errata System > > wrote: > > The following errata report has been submitted for RFC7273, > "RTP Clock Source Signalling". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7273&eid=4548 > > -------------------------------------- > Type: Technical > Reported by: John Fletcher > > > Section: 5.2 > > Original Text > ------------- > A rate modifier may be specified. The modifier is expressed as the > ratio of two integers and modifies the rate specified or implied by > the media description by this ratio. > > Corrected Text > -------------- > A rate modifier may be specified. The modifier is expressed as the > ratio of two integers and multiplies the rate specified or implied by > the media description by this ratio. > > Notes > ----- > Original text says that the rate modifier \\"modifies the rate\\" > but does not say how. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7273 (draft-ietf-avtcore-clksrc-11) > -------------------------------------- > Title : RTP Clock Source Signalling > Publication Date : June 2014 > Author(s) : A. Williams, K. Gross, R. van Brandenburg, H. > Stokking > Category : PROPOSED STANDARD > Source : Audio/Video Transport Core Maintenance RAI > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Mon Apr 4 14:18:57 2016 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DE412D8BB for ; Mon, 4 Apr 2016 14:18:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160404211855.15614.44485.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 14:18:55 -0700 From: IETF Secretariat Archived-At: Subject: [AVTCORE] Milestones changed for avtcore WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 21:18:55 -0000 Changed milestone "Submit RTP Congestion Control: Circuit Breakers for Unicast Sessions for publication as proposed standard", resolved as "Done". URL: https://datatracker.ietf.org/wg/avtcore/charter/ From nobody Tue Apr 5 11:33:01 2016 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 B744012D60D for ; Tue, 5 Apr 2016 11:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Qzj7JgoVLBR for ; Tue, 5 Apr 2016 11:32:58 -0700 (PDT) Received: from omx.cbeyond.com (omx.cbeyond.com [50.20.30.29]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0515912D612 for ; Tue, 5 Apr 2016 11:32:57 -0700 (PDT) X-SBRS: None X-HAT: Sender Group GREYLIST_RELAY_PORT587, Policy $GREYLIST_RELAY applied. X-Hostname: omx07bay.sys.cbeyond.net X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D3AQACBARX/8HTD0VEGoM3HjV9uSmCDwENgXIhhWwCgT84FAEBAQEBAQFlJ4RCAQEEMgEFQRALDQsJJQ8CRgYBDAYCAQGIIwUJLMAKAQEBAQEBAQMBAQEBARuKa4E4iF0BBIdvCocGiQKPcIRNgxyFPo8aHgEBQoIEDQyBaCAwAROIIwEBAQ X-IPAS-Result: A2D3AQACBARX/8HTD0VEGoM3HjV9uSmCDwENgXIhhWwCgT84FAEBAQEBAQFlJ4RCAQEEMgEFQRALDQsJJQ8CRgYBDAYCAQGIIwUJLMAKAQEBAQEBAQMBAQEBARuKa4E4iF0BBIdvCocGiQKPcIRNgxyFPo8aHgEBQoIEDQyBaCAwAROIIwEBAQ X-IronPort-AV: E=Sophos;i="5.24,445,1454994000"; d="scan'208";a="206221684" Received: from unknown (HELO Alans-MBP.telchemy.com) ([69.15.211.193]) by omx.cbeyond.com with ESMTP/TLS/DHE-RSA-AES128-SHA; 05 Apr 2016 14:32:57 -0400 To: Magnus Westerlund , timur.friedman@lip6.fr, ben@nostrum.com, alissa@cooperw.in, keith.drage@alcatel-lucent.com, roni.even@mail01.huawei.com References: <20160122061024.2C4AA18046C@rfc-editor.org> <5702A356.1090900@ericsson.com> From: Alan Clark Message-ID: <570404D7.70407@telchemy.com> Date: Tue, 5 Apr 2016 14:32:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <5702A356.1090900@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: avt@ietf.org, timebow@163.com Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3611 (4597) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 18:32:59 -0000 Hi Magnus As the author of that section of RFC 3611 I concur that the errata report is correct and the suggested change should be made. Regards Alan Clark On 4/4/16 1:24 PM, Magnus Westerlund wrote: > Hi, > > I have looked at this errata. It appears to be correct. I checked > Liu's calculation and get the same value. I think the reason the wrong > value is in the RFC is due that the authors calculated the 33% loss > value and used that to calculate the burst density, rather than 4/12s. > > As this can be confusing when implementing I propose that we verify > this Errata. > > Please provide any feedback on this proposal no later than the 18th of > April. > > Cheers > > Magnus Westerlund > > > Den 2016-01-22 kl. 03:10, skrev RFC Errata System: >> The following errata report has been submitted for RFC3611, >> "RTP Control Protocol Extended Reports (RTCP XR)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3611&eid=4597 >> >> -------------------------------------- >> Type: Technical >> Reported by: Liu Yuanlong >> >> Section: 4.7.2 >> >> Original Text >> ------------- >> burst density 84, which corresponds to 33% >> >> Corrected Text >> -------------- >> burst density 85, which corresponds to 33% >> >> Notes >> ----- >> error calculation for burst density, burst >> density=4/12*256=85.33...≈85 >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3611 (draft-ietf-avt-rtcp-report-extns-06) >> -------------------------------------- >> Title : RTP Control Protocol Extended Reports (RTCP XR) >> Publication Date : November 2003 >> Author(s) : T. Friedman, Ed., R. Caceres, Ed., A. Clark, Ed. >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> > > From nobody Wed Apr 6 13:08:35 2016 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 4845112D5AB; Wed, 6 Apr 2016 13:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVG3toTh4jnC; Wed, 6 Apr 2016 13:08:33 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F6C12D1D2; Wed, 6 Apr 2016 13:08:32 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-99-57056cbe1b3e Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0B.BA.22880.EBC65075; Wed, 6 Apr 2016 22:08:30 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Wed, 6 Apr 2016 22:07:40 +0200 To: , , , References: <20150427154444.78210180092@rfc-editor.org> <5702A612.4090802@ericsson.com> From: Magnus Westerlund Message-ID: <57056C85.5050106@ericsson.com> Date: Wed, 6 Apr 2016 17:07:33 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5702A612.4090802@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM2K7ru6+HNZwg5kbVSymn/nLaPGyZyW7 xfzO0+wWTxvPMlpcuniWyeJJyw9mi5NfdrA4sHu0PtvL6vHlyUsmjyVLfjJ57Nj8gNXj7q1L TB6zdj5hCWCL4rJJSc3JLEst0rdL4MqY+PU6U8Ft84quJa2MDYxt2l2MHBwSAiYSZ+/kdTFy ApliEhfurWfrYuTiEBI4wiixaspjRghnGaPEu6NX2ECqhAUcJc419bCD2CICuRK9x7+BxYUE IiUWbL8BZjMLhEs8m/uQBcRmE7CQuPmjkQ1kGa+AtsTtmSUgYRYBFYkr02aClYsKxEgcf3eO EcTmFRCUODnzCQtIOaeAjsS2m44gJrOAvcSDrWUQw+UlmrfOZoZYqi3R0NTBOoFRcBaS5lkI HbOQdCxgZF7FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERgBB7f81t3BuPq14yFGAQ5GJR7e Bbks4UKsiWXFlbmHGCU4mJVEeMOyWcOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+ZE/gsTEkhP LEnNTk0tSC2CyTJxcEo1MJpZFt1Id/5b8Cb4Wqilc8hl1z42Q7+ybsXln4ylW8XzPZiMDlcV K+vvmeknpP5ykQbP8tOFomlcmfzxn2T1Ze9k9JoFF1mwOZ7TvbPj5RruLsO4k3JCyXealYwn e5Z2Sl+c0Sr6RKahv3valtae7qwJ52x+n7yz2KCTlbtm5xnbb9eS/I4psRRnJBpqMRcVJwIA AflOjnwCAAA= Archived-At: Cc: Thomas.Belling@nokia.com, avt@ietf.org, "payload@ietf.org" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4867 (4347) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:08:35 -0000 Payload, I should have included you from start. Please provide any input on this Errata as its relate to an RTP Payload format. Cheers Magnus Westerlund (AVTCORE WG chair) Den 2016-04-04 kl. 14:36, skrev Magnus Westerlund: > WG, > > I am co-author of this document. If there are any controversy around the > consensus here I will let my co-chair or the AD judge that. > > However, the WG should progress this Errata. It has been created due to > actual interoperability issues that has been discussed in 3GPP SA4. From > my perspective the errata also represents the intention of the document. > Thus I propose that this errata is verified. Please provide any feedback > by the 18th of April. > > Cheers > > Magnus Westerlund > > > > > Den 2015-04-27 kl. 12:44, skrev RFC Errata System: >> The following errata report has been submitted for RFC4867, >> "RTP Payload Format and File Storage Format for the Adaptive >> Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4867&eid=4347 >> >> -------------------------------------- >> Type: Technical >> Reported by: Thomas Belling >> >> Section: 4.3.1 >> >> Original Text >> ------------- >> CMR (4 bits): Indicates a codec mode request sent to the speech >> encoder at the site of the receiver of this payload. The value of >> the CMR field is set to the frame type index of the corresponding >> speech mode being requested. The frame type index may be 0-7 for >> AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined >> in Table 1a in [4]. CMR value 15 indicates that no mode request >> is present, and other values are for future use. >> >> The codec mode request received in the CMR field is valid until the >> next codec mode request is received, i.e., a newly received CMR value >> corresponding to a speech mode, or NO_DATA overrides the previously >> received CMR value corresponding to a speech mode or NO_DATA. >> Therefore, if a terminal continuously wishes to receive frames in the >> same mode X, it needs to set CMR=X for all its outbound payloads, and >> if a terminal has no preference in which mode to receive, it SHOULD >> set CMR=15 in all its outbound payloads. >> >> If receiving a payload with a CMR value that is not a speech mode or >> NO_DATA, the CMR MUST be ignored by the receiver. >> >> >> Corrected Text >> -------------- >> CMR (4 bits): Indicates a codec mode request sent to the speech >> encoder at the site of the receiver of this payload. The value of >> the CMR field is set to the frame type index of the corresponding >> speech mode being requested. The frame type index may be 0-7 for >> AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined >> in Table 1a in [4]. CMR value 15 indicates that the receiver has >> no preference in which mode within the negotiated mode set to >> receive, and other values are for future use. >> >> The codec mode request received in the CMR field is valid until the >> next codec mode request is received, i.e., a newly received CMR value >> corresponding to a speech mode, or CMR=15 overrides the previously >> received CMR value corresponding to a speech mode or CMR=15. >> Therefore, if a terminal continuously wishes to receive frames not >> higher than mode X, it needs to set CMR=X for all its outbound >> payloads, and if a terminal has no preference in which mode within >> the negotiated mode set to receive, it SHOULD set CMR=15 in all its >> outbound payloads. >> >> If receiving a payload with a CMR value that is not a speech mode or >> CMR=15, the CMR MUST be ignored by the receiver. >> >> >> Notes >> ----- >> The definition of CMR 15 as "no mode request is present", could be > understood to suggest that other previously received CMR values remain > applicable. However, this contradicts text in the subsequent paragraphs > suggesting CMR=15 should be used when the "terminal has no preference in > which mode to receive", and stating that any previously received CMR > value is overridden by CMR=15. >> >> It is thus unclear for a receiving entity that has previously >> received > a CMR value requesting a lower AMR mode and then receives a CMR value 15 > if it should continue to send using the lower AMR mode or if it can > select a higher mode within the negotiated mode set based on own > preferences. >> >> CMR 15 is referred to as "NO_DATA" in subsequent text, but "NO_DATA" > is not well defined. This value appears in the quoted references, but > these references are only quoted for CMR values 0 to 7/8. >> >> It is also not perfectly clear if CMR=15 allows for any mode, or >> only > modes within the negotiated mode set. However, the definition of the > mode-set parameter in Clause 8.1 suggests that only modes within the > negotiated mode-set can be sent when a mode-set has been negotiated. >> >> The text "if a terminal continuously wishes to receive frames in the > same mode X, it needs to set CMR=X for all its outbound payloads" seems > to suggest that the receiver will always follow the request, although it > may also choose to send lower modes, as explained in text further below. >> >> This erratum has been discussed and endorsed by the 3GPP SA4 group > before submission to IETF. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4867 (draft-ietf-avt-rtp-amr-bis-06) >> -------------------------------------- >> Title : RTP Payload Format and File Storage Format for >> the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband >> (AMR-WB) Audio Codecs >> Publication Date : April 2007 >> Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Wed Apr 6 13:08:54 2016 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 DC67C12D79D; Wed, 6 Apr 2016 13:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2VH63XOYp8k; Wed, 6 Apr 2016 13:08:35 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CADF12D135; Wed, 6 Apr 2016 13:08:35 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-90-57056cc1a39d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 11.BE.23401.1CC65075; Wed, 6 Apr 2016 22:08:33 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.248.2; Wed, 6 Apr 2016 22:08:31 +0200 To: , , , References: <20150427154813.ECA28180092@rfc-editor.org> <5702A648.4010502@ericsson.com> From: Magnus Westerlund Message-ID: <57056C9E.3040605@ericsson.com> Date: Wed, 6 Apr 2016 17:07:58 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5702A648.4010502@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM2K7q+7BHNZwg+9rZCymn/nLaPGyZyW7 xfzO0+wWTxvPMlpcuniWyeJJyw9mi5NfdrA4sHu0PtvL6vHlyUsmjyVLfjJ57Nj8gNXj7q1L TB6zdj5hCWCL4rJJSc3JLEst0rdL4Mq40X+dpWCVbMXKhfuZGhh7xbsYOTkkBEwkZv67wwhh i0lcuLeerYuRi0NI4AijxKNnq9hAEkICyxgltvwNB7GFBRwldr9cxwJiiwjkSvQe/wZVEykx 6fVudhCbWSBc4tnch2A1bAIWEjd/NALVcHDwCmhL7J6QCxJmEVCRmDxjBSuILSoQI3H83Tmw G3gFBCVOznwC1sopoCNx6OhUFpBWZgF7iQdbyyCmy0s0b53NDLFVW6KhqYN1AqPgLCTdsxA6 ZiHpWMDIvIpRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMAYObvlttYPx4HPHQ4wCHIxKPLwL clnChVgTy4orcw8xSnAwK4nwLk5jDRfiTUmsrEotyo8vKs1JLT7EKM3BoiTOmxP5L0xIID2x JDU7NbUgtQgmy8TBKdXAGNVksfrppWyH+7uzNS/eWHyqfOmKnB1b4xbIXfvC57C9VFrRe9Xm shQdjn1PnoVIMS3a+G7i6pP+k1RydgSv0mG6wr3H9SmPr9j5qhDnV1tnvE6L5Cv7/PbuYxX1 vXdi9YRW33tie/aKl8Eb6UzNz3dYpryIb5z0Sun7hCdFC9qEfh85McVv1nMlluKMREMt5qLi RAA8SWmIfQIAAA== Archived-At: Cc: Thomas.Belling@nokia.com, avt@ietf.org, "payload@ietf.org" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4867 (4348) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:08:38 -0000 Payload, I should have included you from start. Please provide any input on this Errata as its relate to an RTP Payload format. Cheers Magnus Westerlund (AVTCORE WG chair) Den 2016-04-04 kl. 14:37, skrev Magnus Westerlund: > WG, > > I am co-author of this document. If there are any controversy around the > consensus here I will let my co-chair or the AD judge that. > > However, the WG should progress this Errata. It has been created due to > actual interoperability issues that has been discussed in 3GPP SA4. From > my perspective the errata also represents the intention of the document. > Thus I propose that this errata is verified. Please provide any feedback > by the 18th of April. > > Cheers > > Magnus Westerlund > > Den 2015-04-27 kl. 12:48, skrev RFC Errata System: >> The following errata report has been submitted for RFC4867, >> "RTP Payload Format and File Storage Format for the Adaptive >> Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4867&eid=4348 >> >> -------------------------------------- >> Type: Technical >> Reported by: Thomas Belling >> >> Section: 4.3.1 >> >> Original Text >> ------------- >> The encoder SHOULD follow a received codec mode request, but MAY >> change to a lower-numbered mode if it so chooses, for example, to >> control congestion. >> >> >> Corrected Text >> -------------- >> The encoder MUST follow a received codec mode request as soon as >> possible. It SHOULD use the requested mode, but MAY change to a >> lower-numbered mode if it so chooses, for example, to >> control congestion. However, the encoder MUST NOT use a >> higher-numbered mode than the received codec mode request. >> >> >> Notes >> ----- >> This seems to be the intention of the existing text, but is not > explicitly stated. It is essential for the end-to-end mode control and > interoperability with 3GPP CS networks that a peer does not send higher > modes than requested. >> >> This erratum has been discussed and endorsed by the 3GPP SA4 group > before submission to IETF. > >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4867 (draft-ietf-avt-rtp-amr-bis-06) >> -------------------------------------- >> Title : RTP Payload Format and File Storage Format for >> the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband >> (AMR-WB) Audio Codecs >> Publication Date : April 2007 >> Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Wed Apr 6 13:09:15 2016 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 1A06D12D1DD; Wed, 6 Apr 2016 13:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuQM-CSOqeVO; Wed, 6 Apr 2016 13:08:49 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4DC12D135; Wed, 6 Apr 2016 13:08:38 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-a5-57056cc628d0 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A4.BE.23401.6CC65075; Wed, 6 Apr 2016 22:08:38 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Wed, 6 Apr 2016 22:08:35 +0200 To: , , , References: <20150427155709.23479180092@rfc-editor.org> <5702A6BB.3080402@ericsson.com> From: Magnus Westerlund Message-ID: <57056CBD.1080500@ericsson.com> Date: Wed, 6 Apr 2016 17:08:29 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5702A6BB.3080402@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM2K7je6xHNZwgy+/FS2mn/nLaPGyZyW7 xfzO0+wWTxvPMlpcuniWyeJJyw9mi5NfdrA4sHu0PtvL6vHlyUsmjyVLfjJ57Nj8gNXj7q1L TB6zdj5hCWCL4rJJSc3JLEst0rdL4Mq4v28me8F09YqbS5tYGhjvy3QxcnJICJhITNl/lRXC FpO4cG89WxcjF4eQwBFGickzZrKBJIQEljFKHFiYD2ILCzhK3D3RBNYgIpAr0Xv8G1RNpMTl zkNgNrNAuMSzuQ9ZQGw2AQuJmz8aweK8AtoSz+e0g9ksAioSLx7MYgexRQViJI6/O8cIUSMo cXLmE7BeTgEdiaXXtzF1MXIAzbSXeLC1DGK8vETz1tnMEGu1JRqaOlgnMArOQtI9C6FjFpKO BYzMqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECo+Dglt9WOxgPPnc8xCjAwajEw7sglyVc iDWxrLgy9xCjBAezkgjv4jTWcCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8OZH/woQE0hNLUrNT UwtSi2CyTBycUg2M4oe7j3i+DQ/dz7+DTzxx5qwKiz+fp27cn7Prmal12bQse+trsVejKydJ 6vmYvOczXSVvuujFZil+rbpJJ1xTv67cVq/qU3JI2cXj3gsb4073tCATHRUblg8Pt/qvd/a0 2rHpdnkI+/LofaYn7za6b+p/v/Ly3ZJdB5x9Dtsxz7i3R9hQtp5JiaU4I9FQi7moOBEAm6SV rH4CAAA= Archived-At: Cc: Thomas.Belling@nokia.com, avt@ietf.org, "payload@ietf.org" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4867 (4349) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:08:52 -0000 Payload, I should have included you from start. Please provide any input on this Errata as its relate to an RTP Payload format. Cheers Magnus Westerlund (AVTCORE WG chair) Den 2016-04-04 kl. 14:39, skrev Magnus Westerlund: > WG, > > I am co-author of this document. If there are any controversy around the > consensus here I will let my co-chair or the AD judge that. > > However, the WG should progress this Errata. It has been created due to > actual interoperability issues that has been discussed in 3GPP SA4. From > my perspective the errata also represents the intention of the document. > Thus I propose that this errata is verified. Please provide any feedback > by the 18th of April. > > Cheers > > Magnus Westerlund > > > Den 2015-04-27 kl. 12:57, skrev RFC Errata System: >> The following errata report has been submitted for RFC4867, >> "RTP Payload Format and File Storage Format for the Adaptive >> Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4867&eid=4349 >> >> -------------------------------------- >> Type: Technical >> Reported by: Thomas Belling >> >> Section: 8.1 >> >> Original Text >> ------------- >> mode-set: Restricts the active codec mode set to a subset of all >> modes, for example, to be able to support transport >> channels such as GSM networks in gateway use cases. >> Possible values are a comma separated list of modes from >> the set: 0,...,7 (see Table 1a [2]). The SID frame type >> 8 and NO_DATA (frame type 15) are never included in the >> mode set, but can always be used. If mode-set is >> specified, it MUST be abided, and frames encoded with >> modes outside of the subset MUST NOT be sent in any RTP >> payload or used in codec mode requests. If not present, >> all codec modes are allowed for the payload type. >> >> >> Corrected Text >> -------------- >> mode-set: Restricts the active codec mode set to a subset of all >> modes, for example, to be able to support transport >> channels such as GSM networks in gateway use cases. >> Possible values are a comma separated list of modes from >> the set: 0,...,7 (see Table 1a [2]). The SID frame type >> 8 and NO_DATA (frame type 15) are never included in the >> mode set, but can always be used. If mode-set is >> specified, it MUST be abided, i.e. frames encoded with >> modes outside of the subset MUST NOT be sent in any RTP >> payload and codec mode requests MUST only use modes >> within the mode-set or CMR=15. If the mode-set parameter >> is not present, then all codec modes are allowed for the >> payload type. >> >> >> Notes >> ----- >> The existing text rules out that CMR=15 is used when a mode-set has > been negotiated. However, this contradicts a statement in .clause 4.3.1 > that if a terminal has no preference in which mode to receive, it SHOULD > set CMR=15 in all its outbound payloads. >> >> This erratum has been discussed and endorsed by the 3GPP SA4 group > before submission to IETF. > >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4867 (draft-ietf-avt-rtp-amr-bis-06) >> -------------------------------------- >> Title : RTP Payload Format and File Storage Format for >> the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband >> (AMR-WB) Audio Codecs >> Publication Date : April 2007 >> Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Wed Apr 6 13:22:35 2016 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 C7E5612D667 for ; Wed, 6 Apr 2016 13:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTthVITiXv3O for ; Wed, 6 Apr 2016 13:22:31 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF2912D5E3 for ; Wed, 6 Apr 2016 13:22:30 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-13-570570058a3e Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B9.8C.22880.50075075; Wed, 6 Apr 2016 22:22:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.248.2; Wed, 6 Apr 2016 22:22:28 +0200 To: IETF AVTCore WG From: Magnus Westerlund Message-ID: <57056FFF.1080709@ericsson.com> Date: Wed, 6 Apr 2016 17:22:23 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM2K7gS5rAWu4waZnghYve1ayW8zvPM3u wOSxZMlPJo9ZO5+wBDBFcdmkpOZklqUW6dslcGWc7NzLWrCIs2L1kW3sDYwH2LsYOTkkBEwk FkxvhLLFJC7cW8/WxcjFISRwhFFiy7JnrBDOMkaJ3Z07mECqRASUJHZM2sYMYrMJWEjc/NHI BmILC/hKXNqxiBXEZgaq2bf9CJjNK6AtMXX6HzCbRUBForH9Adg2UYEYiePvzjFC1AhKnJz5 hKWLkQOo117iwdYyiDHyEs1bZ4OtEgIa09DUwTqBkX8Wko5ZCB2zkHQsYGRexShanFpcnJtu ZKyXWpSZXFycn6eXl1qyiREYfAe3/Nbdwbj6teMhRgEORiUe3gW5LOFCrIllxZW5hxglOJiV RHjDslnDhXhTEiurUovy44tKc1KLDzFKc7AoifPmRP4LExJITyxJzU5NLUgtgskycXBKNTAu iP/X3HTVMHly8mzWHq8ixYca6t/zNx78LlYtacsSvkx661y/pzliPj9irL7dmuWxuGZqUYKb kztbsxL75Z8Tj8vIlNx6r15fbuE0bw/T3KzmA+m7jbdVN6ft/rVZ1u56y4/sjqtyU9hOHN5v 3FF58p399cTH+3TOzJgz++k0QcN300/VGu9XYinOSDTUYi4qTgQAzNHWXDoCAAA= Archived-At: Subject: [AVTCORE] Moving the Encrypted Key Transport Milestone from AVTCORE to PERC WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:22:33 -0000 AVTCORE WG, The PERC WG is taking on the Encrypted Key Transport (EKT) specification work. Last version of our ID was: https://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-03 However, PERC WG only plan to work on the key transport in SRTP and how you establish the EKT key using DTLS-SRTP. The establishment of EKT keys using MIKEY and Security Descriptions they don't intended to do. Are there any in this WG that has a need for either of those mechanisms? If you do, please speak up! If there are no need then we will simple remove the AVTCORE milestone. If there are need we will discuss how to deal with this. Please provide input no later than 20th of April. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Wed Apr 13 14:06:10 2016 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 2349912D800 for ; Wed, 13 Apr 2016 14:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Hm81T2mXiLi for ; Wed, 13 Apr 2016 14:06:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B254B12D645 for ; Wed, 13 Apr 2016 14:06:08 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3DL61Js036583 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 13 Apr 2016 16:06:02 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Magnus Westerlund" Date: Wed, 13 Apr 2016 16:06:01 -0500 Message-ID: <50ABDC0F-1902-4DF9-9383-92F01A293BF6@nostrum.com> In-Reply-To: <5702A3E2.2050106@ericsson.com> References: <20150722191648.2D97918020A@rfc-editor.org> <55B0A8A7.7060005@ericsson.com> <5702A3E2.2050106@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: finlayson@live555.com, avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3711 (4425) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 21:06:10 -0000 Done. On 4 Apr 2016, at 12:26, Magnus Westerlund wrote: > Ben, > > Can you please put this Errata into Held for Document update. I think > you can change it to Editorial rather than Technical. > > Cheers > > Magnus > > > Den 2015-07-23 kl. 05:41, skrev Magnus Westerlund: >> Hi, >> >> I think this errata is editorial rather than technical. This as the >> error is in the part not specified by this RFC, rather as you say >> RFC3550. I don't think it is likely to cause any interoperability >> issue, >> but it should be retain. Thus I propose that it is put into the >> >> HOLD for Document update >> >> Category. Please provide an further comments on this. >> >> Cheers >> >> Magnus Westerlund >> (Chair) >> >> >> Den 2015-07-22 kl. 21:16, skrev RFC Errata System: >>> The following errata report has been submitted for RFC3711, >>> "The Secure Real-time Transport Protocol (SRTP)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3711&eid=4425 >>> >>> -------------------------------------- >>> Type: Technical > b>> Reported by: Ross Finlayson >>> >>> Section: 3.4 >>> >>> Original Text >>> ------------- >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 >>> 1 >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ >>> |V=2|P| RC | PT=SR or RR | length >>> | | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> >>> >>> Corrected Text >>> -------------- >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 >>> 1 >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ >>> |V=2|P| RC | PT=SR or RR | length >>> | | >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >>> >>> >>> Notes >>> ----- >>> The boundary between the "PT=SR or RR" and the "length" fields is >>> wrong: The boundary is shown as being between bits 16 and 17; it >>> should be between bits 15 and 16. I.e., the "PT=SR or RR" field >>> should be 8 bits long, not 9. >>> >>> This is just a minor bug, because the equivalent diagram in RFC 3550 >>> (the normative reference for RTCP) is correct. Nonetheless, this >>> bug >>> should probably be added to the errata for RFC 3711 >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC3711 (draft-ietf-avt-srtp-09) >>> -------------------------------------- >>> Title : The Secure Real-time Transport Protocol (SRTP) >>> Publication Date : March 2004 >>> Author(s) : M. Baugher, D. McGrew, M. Naslund, E. Carrara, >>> K. Norrman >>> Category : PROPOSED STANDARD >>> Source : Audio/Video Transport >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG >>> >>> _______________________________________________ >>> Audio/Video Transport Core Maintenance >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>> >> >> > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > 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 nobody Wed Apr 13 14:17:17 2016 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 71F9C12D6B3 for ; Wed, 13 Apr 2016 14:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eVf1r2WFKKb for ; Wed, 13 Apr 2016 14:17:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB56912D6B0 for ; Wed, 13 Apr 2016 14:17:14 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3DLH6li062154 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 13 Apr 2016 16:17:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Magnus Westerlund" Date: Wed, 13 Apr 2016 16:17:06 -0500 Message-ID: <6F982752-E525-4CB7-84FF-BE59E3E6D170@nostrum.com> In-Reply-To: <5702B22D.4080304@ericsson.com> References: <20150818173656.46E36180092@rfc-editor.org> <55EFEFF0.5060502@ericsson.com> <5613956B.1090501@ericsson.com> <5702B22D.4080304@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Technical - Re: [Editorial Errata Reported] RFC7273 (4450) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 21:17:16 -0000 I made the edits, but have not yet verified it. Please double check that the edits are correct, then I will verify. Thanks! Ben. On 4 Apr 2016, at 13:27, Magnus Westerlund wrote: > Ben, > > Can you please update the Errata with the below original and edited > text. This has been available on the list for quite some time so I > suggest that you verify it after editing it. > > > Section 4.8: > > Original Text > ------------- > ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002) > ptp-domain-name = "domain-name=" 1*16ptp-domain-char > ptp-domain-char = %x21-7E > > ; PTP domain allowed number range: 0-127 (IEEE 1588-2008) > ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts > ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3 > ptp-domain-n1 = DIGIT ; 0-9 > ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99 > ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119 > / "12" %x30-37 ; 120-127 > > Corrected Text > -------------- > ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002) > ptp-domain-name = 1*16ptp-domain-char > ptp-domain-char = %x21-7E > > ; PTP domain allowed number range: 0-127 (IEEE 1588-2008) > ptp-domain-nmbr = ptp-domain-dgts > ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3 > ptp-domain-n1 = DIGIT ; 0-9 > ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99 > ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119 > / "12" %x30-37 ; 120-127 > > > > > > The Note should also be updated: > > There is an inconsistency between ABNF in section 4.8 and examples in > section 5.5. Due to evidence, that current implementations are working > to what is shown in the examples, this is resolved by updating the > ABNF specification. > > cheers > > Magnus > > > Den 2016-01-19 kl. 23:16, skrev Kevin Gross: >> The authors are in agreement that the most recent proposal is the >> desired fix and there doesn't seem to be any dissent in AVTCORE about >> it. Can we get the errata updated to reflect this most recent >> proposal? >> It is still showing my original report - >> https://www.rfc-editor.org/errata_search.php?rfc=7273 >> >> Kevin Gross - AVA Networks >> >> On Sun, Dec 6, 2015 at 1:00 PM, Kevin Gross > > wrote: >> >> The authors and I propose the following fix for the reported RFC >> 7273 errata. These ABNF changes bring the ABNF specification into >> agreement with the examples in the RFC. Current RFC 7273 >> implementations have been based on the examples. >> >> Original Text >> ------------- >> ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002) >> ptp-domain-name = "domain-name=" 1*16ptp-domain-char >> ptp-domain-char = %x21-7E >> >> ; PTP domain allowed number range: 0-127 (IEEE 1588-2008) >> ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts >> ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / >> ptp-domain-n3 >> ptp-domain-n1 = DIGIT ; 0-9 >> ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99 >> ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119 >> / "12" %x30-37 ; 120-127 >> >> Corrected Text >> -------------- >> ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002) >> ptp-domain-name = 1*16ptp-domain-char >> ptp-domain-char = %x21-7E >> >> ; PTP domain allowed number range: 0-127 (IEEE 1588-2008) >> ptp-domain-nmbr = ptp-domain-dgts >> ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / >> ptp-domain-n3 >> ptp-domain-n1 = DIGIT ; 0-9 >> ptp-domain-n2 = POS-DIGIT DIGIT ; 10-99 >> ptp-domain-n3 = ("10"/"11") DIGIT ; 100-119 >> / "12" %x30-37 ; 120-127 >> >> >> Kevin Gross - AVA Networks >> >> On Thu, Oct 8, 2015 at 12:37 PM, Kevin Gross >> > > wrote: >> >> Yes, I will take your discussion into account when proposing >> final ABNF changes. I wanted first to make sure there were no >> objection to the general proposal of fixing this by >> conforming >> ABNF to examples. Since we have seen no objections, I will >> proceed to prepare a revision. >> >> Kevin Gross - AVA Networks >> >> On Tue, Oct 6, 2015 at 3:33 AM, Magnus Westerlund >> > > wrote: >> >> Hi Kevin, >> >> Can you please review my previous email in detail: >> >> https://mailarchive.ietf.org/arch/msg/avt/kjoyUZh-9c4lYMM6pXQhH30TebY >> >> I think you need to confirm on what changes that is >> really >> proposed here, and thus my feedback is relevant for this. >> >> However, I have so far seen no one objecting to the >> general >> intention to at least make alignment with the examples? >> >> Cheers >> >> Magnus Westerlund >> (AVTCORE chair) >> >> >> -- >> >> Magnus Westerlund >> >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research >> EAB/TXM >> >> ---------------------------------------------------------------------- >> 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 > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > 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 nobody Fri Apr 15 02:20:11 2016 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 64ACB12D6C3; Wed, 13 Apr 2016 14:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FIAj_XmTxWg; Wed, 13 Apr 2016 14:05:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182A512D645; Wed, 13 Apr 2016 14:05:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D85C418000F; Wed, 13 Apr 2016 14:05:26 -0700 (PDT) To: finlayson@live555.com, mbaugher@cisco.com, elisabetta.carrara@ericsson.com, mcgrew@cisco.com, mats.naslund@ericsson.com, karl.norrman@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160413210526.D85C418000F@rfc-editor.org> Date: Wed, 13 Apr 2016 14:05:26 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 15 Apr 2016 02:20:10 -0700 Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, avt@ietf.org Subject: [AVTCORE] [Errata Held for Document Update] RFC3711 (4425) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 21:05:41 -0000 The following errata report has been held for document update for RFC3711, "The Secure Real-time Transport Protocol (SRTP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3711&eid=4425 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Ross Finlayson Date Reported: 2015-07-22 Held by: Ben Campbell (IESG) Section: 3.4 Original Text ------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P| RC | PT=SR or RR | length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Corrected Text -------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P| RC | PT=SR or RR | length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Notes ----- The boundary between the "PT=SR or RR" and the "length" fields is wrong: The boundary is shown as being between bits 16 and 17; it should be between bits 15 and 16. I.e., the "PT=SR or RR" field should be 8 bits long, not 9. This is just a minor bug, because the equivalent diagram in RFC 3550 (the normative reference for RTCP) is correct. Nonetheless, this bug should probably be added to the errata for RFC 3711 -------------------------------------- RFC3711 (draft-ietf-avt-srtp-09) -------------------------------------- Title : The Secure Real-time Transport Protocol (SRTP) Publication Date : March 2004 Author(s) : M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman Category : PROPOSED STANDARD Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Mon Apr 18 02:06:51 2016 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 F417712DAC1 for ; Mon, 18 Apr 2016 02:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZgOiXncEyT9 for ; Mon, 18 Apr 2016 02:06:47 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9437612D8A2 for ; Mon, 18 Apr 2016 02:06:47 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-86-5714a3a45f30 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.8D.12926.4A3A4175; Mon, 18 Apr 2016 11:06:44 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.248.2; Mon, 18 Apr 2016 11:06:00 +0200 To: IETF AVTCore WG From: Magnus Westerlund Message-ID: <5714A378.40100@ericsson.com> Date: Mon, 18 Apr 2016 11:06:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM2J7lO6SxSLhBl8PGlq87FnJ7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEV7T7EU/GSpmPZnO3sD40SWLkZODgkBE4nJLUeZIGwxiQv3 1rN1MXJxCAkcYZTou3KLHcJZzihx69xWVpAqEQEliR2TtjGD2GwCFhI3fzQCdXBwCAN1r79t BxLmFdCU6J/SDVbCIqAqcXvpFbBlogIxEo0PTjFB1AhKnJz5hAWklVnAXuLB1jKQMLOAvETz 1tlgrUIC2hINTR2sExj5ZiHpmIXQMQtJxwJG5lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsY geF0cMtv1R2Ml984HmIU4GBU4uFNYBcJF2JNLCuuzD3EKMHBrCTC+2QeUIg3JbGyKrUoP76o NCe1+BCjNAeLkjhvduS/MCGB9MSS1OzU1ILUIpgsEwenVANjbk+NjO60RzIyF7f9cM777ta1 Xa3yHvOUlSKp1pmpardtfwT82HR1721fhnyZT1dWtWUXHn80b+0l/9b5jDcurZowm3ndaRun ZykF/y1yhdql//swPn5h8lXfUy8tJulw5ZfKh+de7D1w+0/VkqI+13y1RM/rW26y5gccnWwj ffjnH7Pl+XYGSizFGYmGWsxFxYkAt5xdxCMCAAA= Archived-At: Subject: [AVTCORE] Draft minutes X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 09:06:50 -0000 WG, The draft minutes have been uploaded. Please provide any feedback. https://www.ietf.org/proceedings/95/minutes/minutes-95-avtcore Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Tue Apr 19 18:20:46 2016 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8102612D6DA; Tue, 19 Apr 2016 18:20:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160420012041.31613.87215.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 18:20:41 -0700 Archived-At: Cc: avtcore-chairs@ietf.org, magnus.westerlund@ericsson.com, draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, avt@ietf.org Subject: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 01:20:41 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-avtcore-rtp-circuit-breakers-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I really like this specification, and have two questions I'd like to understand before balloting YES ... I'm looking at this text: 4.5. Ceasing Transmission What it means to cease transmission depends on the application. The intention is that the application will stop sending RTP data packets to a particular destination 3-tuple (transport protocol, destination port, IP address), until the user makes an explicit attempt to restart the call. It is important that a human user is involved in the decision to try to restart the call, since that user will eventually give up if the calls repeatedly trigger the circuit breaker. This will help avoid problems with automatic redial systems from congesting the network. Accordingly, RTP flows halted by the circuit breaker SHOULD NOT be restarted automatically unless the ^^^^^^^^^^ sender has received information that the congestion has dissipated, or can reasonably be expected to have dissipated. and trying to understand why this is not MUST NOT. I'm trying to reconcile this with the RFC 2119 definition of SHOULD NOT, which is 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Could you help me understand when automatic restarts might be "acceptable or even useful"? Reading on, I'm wondering if this text is anticipating It is recognised that the RTP implementation in some systems might not be able to determine if a call set-up request was initiated by a human user, or automatically by some scripted higher-level component of the system. but definitely want to understand what you're thinking here. I have a similar question about this text ECN-CE marked packets SHOULD be treated as if it were lost for the purposes of congestion control, when determining the optimal media sending rate for an RTP flow. If an RTP sender has negotiated ECN support for an RTP session, and has successfully initiated ECN use on the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD ^^^^^^ be treated as if they were lost when calculating if the congestion- based RTP circuit breaker (Section 4.3) has been met. Could you help me understand why an implementation wouldn't do this? From nobody Thu Apr 21 00:38:35 2016 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 DAEDE12D796; Thu, 21 Apr 2016 00:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMce3TDjcV8Q; Thu, 21 Apr 2016 00:38:30 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15B012E3AD; Thu, 21 Apr 2016 00:38:28 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-fd-571883729328 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.25.12926.27388175; Thu, 21 Apr 2016 09:38:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.248.2; Thu, 21 Apr 2016 09:38:21 +0200 To: Ben Campbell From: Magnus Westerlund Message-ID: <5718836A.8040906@ericsson.com> Date: Thu, 21 Apr 2016 09:38:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2K7t25Rs0S4QfMaEYuXPSvZLeZ3nma3 uHTxLJMDs8eSJT+ZPGbtfMISwBTFZZOSmpNZllqkb5fAlfFpOUvBHe6KzyemMjcwfuHsYuTk kBAwkWh+sZ0dwhaTuHBvPVsXIxeHkMARRolJ21ewQzjLGSUO3FjGBFIlIqAk8bx5KwuIzSzg KbG0dz8biM0mYCFx80cjkM3BISwgL7F0cxhImFdAW+LehJdg5SwCqhLNMxcwgtiiAjESjQ9O MUHUCEqcnPmEBaSVWcBe4sHWMojp8hLNW2czg9hCQGMamjpYJzDyz0LSMQuhYxaSjgWMzKsY RYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAkPw4JbfqjsYL79xPMQowMGoxMOrYCIRLsSaWFZc mXuIUYKDWUmE90AjUIg3JbGyKrUoP76oNCe1+BCjNAeLkjhvduS/MCGB9MSS1OzU1ILUIpgs EwenVAOj9K2E/geVO9L5LCb8M/r92VraWOtNeVef0HX9/lNlLDVvlm20Debt+ZQdPP9ZvEj0 U/5tS/uuhX7IqnsoMX1yae2Ki8fL723fa5rlE94qfv7nkoesLqc6btiYxm6WDDKfqybMVXbl dt68wsVabTeYvWX40+fwr/Y2d2V59fqsg9SnV1mPAsWUWIozEg21mIuKEwFcfbmQPQIAAA== Archived-At: Cc: IETF AVTCore WG , "payload@ietf.org" Subject: [AVTCORE] Result of errata calls X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 07:38:32 -0000 Hi Ben (cc AVTCORE and Payload WG) Here is a summary of the WG's proposal for how to handle the outstanding Erratas for AVT and AVTCORE WG's RFCs. RFC 3611: Errata 4597: https://www.rfc-editor.org/errata_search.php?eid=4597 Recommendation: Verified RFC 4867: Errata 4347: https://www.rfc-editor.org/errata_search.php?eid=4347 Recommendation: Verified Errata 4348: https://www.rfc-editor.org/errata_search.php?eid=4348 Recommendation: Verified Errata 4349: https://www.rfc-editor.org/errata_search.php?eid=4349 Recommendation: Verified RFC 7273: Errata 4450: https://www.rfc-editor.org/errata_search.php?eid=4450 Recommendation: Verified Note: I have looked at the edits, and it appears to match what was proposed to put in. Errata 4548: https://www.rfc-editor.org/errata_search.php?eid=4548 Recommendation: Verified Note to WG: Errata 4425 on RFC 3711: http://www.rfc-editor.org/errata_search.php?rfc=3711&eid=4425 Was already put in held for document update. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 nobody Tue Apr 26 08:16:37 2016 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 0D1B912D1E8; Tue, 26 Apr 2016 08:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3_fG1ydXrDX; Tue, 26 Apr 2016 08:16:34 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9CB12D1E7; Tue, 26 Apr 2016 08:16:33 -0700 (PDT) Received: from [130.209.247.112] (port=55825 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1av4Co-0004UE-Kj; Tue, 26 Apr 2016 15:43:16 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <20160420012041.31613.87215.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2016 15:43:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <78034C12-57A3-4680-8B86-5C8F22E8ED19@csperkins.org> References: <20160420012041.31613.87215.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: avtcore-chairs@ietf.org, Magnus Westerlund , draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, The IESG , avt@ietf.org Subject: Re: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 15:16:36 -0000 Spencer, > On 20 Apr 2016, at 02:20, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-avtcore-rtp-circuit-breakers-14: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I really like this specification, and have two questions I'd like to > understand before balloting YES ... >=20 > I'm looking at this text: >=20 > 4.5. Ceasing Transmission >=20 > What it means to cease transmission depends on the application. The > intention is that the application will stop sending RTP data packets > to a particular destination 3-tuple (transport protocol, destination > port, IP address), until the user makes an explicit attempt to > restart the call. It is important that a human user is involved in > the decision to try to restart the call, since that user will > eventually give up if the calls repeatedly trigger the circuit > breaker. This will help avoid problems with automatic redial = systems > from congesting the network. Accordingly, RTP flows halted by the > circuit breaker SHOULD NOT be restarted automatically unless the > ^^^^^^^^^^ > sender has received information that the congestion has dissipated, > or can reasonably be expected to have dissipated.=20 >=20 > and trying to understand why this is not MUST NOT. I'm trying to > reconcile this with the RFC 2119 definition of SHOULD NOT, which is >=20 > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. >=20 > Could you help me understand when automatic restarts might be = =E2=80=9Cacceptable or even useful=E2=80=9D? As stated, automatic restarts might be acceptable or even useful if the = sender receives information that the congestion has dissipated, or can = reasonably be expected to have dissipated. This is why it says =E2=80=9CSH= OULD NOT =E2=80=A6 unless =E2=80=9D rather than =E2=80=9CMUST = NOT=E2=80=9D.=20 > Reading on, I'm wondering if this text is anticipating=20 >=20 > It is recognised that the RTP implementation in some systems might > not be able to determine if a call set-up request was initiated by a > human user, or automatically by some scripted higher-level component > of the system. >=20 > but definitely want to understand what you're thinking here. >=20 > I have a similar question about this text=20 >=20 > ECN-CE marked packets SHOULD be treated as if it were lost for the > purposes of congestion control, when determining the optimal media > sending rate for an RTP flow. If an RTP sender has negotiated ECN > support for an RTP session, and has successfully initiated ECN use = on > the path to the receiver [RFC6679], then ECN-CE marked packets = SHOULD > = ^^^^^^ > be treated as if they were lost when calculating if the congestion- > based RTP circuit breaker (Section 4.3) has been met. =20 >=20 > Could you help me understand why an implementation wouldn't do this? Because there are a small number of paths that misbehave when ECN marked = packet are sent. I wanted to allow leeway for an end-point to not = respond to ECN-CE marks on paths that spuriously mark packets, so = falling back to the behaving as-if ECN was not used. I don=E2=80=99t = believe this is harmful to the network, since the result will be the = same as achieved by a non-ECN capable transport. --=20 Colin Perkins https://csperkins.org/ From nobody Tue Apr 26 15:08:23 2016 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 DAD6612D126; Tue, 26 Apr 2016 15:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6wZRzrjfdTV; Tue, 26 Apr 2016 15:08:16 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD2512D0CF; Tue, 26 Apr 2016 15:08:13 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g133so36972414ywb.2; Tue, 26 Apr 2016 15:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rkIfB+Z3tCWDNxw4F8wfQHqOPCncTTllbrcC1TGFgbc=; b=vVpwNW+xfZaPZKQN/rZa7rWKhvShGqgWh6F8UfEkS/dWtllMvxHsqHpTJZlkUNCtYl FUpPo9oKfKyOHKu24oMkrIH/CVF8mxnxKELbr73xK/BneP72c4YbchbJI5aeJGOOGQiD n72tLtKYj9bdUXh3lvkExbk/QK1VbMCNiT5dL6b4QqeiHJFP1CuYlEPWTf9cLXdsb5La qbaFOTu0EiC+xIy9F251nmcSinSWq/PcFItjv+tv2/f3euDroXOWvOC7nXsCNJ0RDu/V gvSKB96pJ6u/q9+ph9lE1Fi5hOJJg6+/EfhIeyWdgzJn17hHj4VQ/8NQdJcPGW/XTo1d QarQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rkIfB+Z3tCWDNxw4F8wfQHqOPCncTTllbrcC1TGFgbc=; b=ZLuM9ysj8gqpLXV+38lDIebLvCHk1h4YVnbd4FkyMd6LlA9zuNbKB51cS9rEYE47zJ pwWeqn2Jh5bKbl7Ww9JmgIOPX0ge2i8cRz9sa9ZkvQvHuDviZnZUHo5zKa0zE6UPtQN3 0tUs/n9PIQd2sAC8sTRISrd4RDMIVFuTkGmCO6uwJz0w27qtz552IWpDwBcHH/M39lQy PZVbnUbF/zoDBh8Uo1MtBNRWosVOdvnYt85/m5JLYkgOWBiAPeGyFXPP57uHY2U8AVSS NwVh99HnXmABh2SXPEKwrBSP/mkN8S12r/Iy33jQrBF0exVind7ktLeKxCeizZh2YvhZ zXbA== X-Gm-Message-State: AOPr4FWAEUdJo+8WASC4sIX/ois6c1E/fYFNv2xxvAF9OA1mkT5sCwsP/nHm9IiJve8CqKSDV3A3aFwztAr1xA== MIME-Version: 1.0 X-Received: by 10.129.46.80 with SMTP id u77mr2786912ywu.143.1461708492392; Tue, 26 Apr 2016 15:08:12 -0700 (PDT) Received: by 10.37.224.212 with HTTP; Tue, 26 Apr 2016 15:08:12 -0700 (PDT) In-Reply-To: <78034C12-57A3-4680-8B86-5C8F22E8ED19@csperkins.org> References: <20160420012041.31613.87215.idtracker@ietfa.amsl.com> <78034C12-57A3-4680-8B86-5C8F22E8ED19@csperkins.org> Date: Tue, 26 Apr 2016 17:08:12 -0500 Message-ID: From: Spencer Dawkins at IETF To: Colin Perkins Content-Type: multipart/alternative; boundary=001a11409dae74513f05316a878f Archived-At: Cc: avtcore-chairs@ietf.org, Magnus Westerlund , draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, The IESG , avt@ietf.org Subject: Re: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 22:08:19 -0000 --001a11409dae74513f05316a878f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Colin, On Tue, Apr 26, 2016 at 9:43 AM, Colin Perkins wrote: > Spencer, > > > On 20 Apr 2016, at 02:20, Spencer Dawkins > wrote: > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-avtcore-rtp-circuit-breakers-14: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I really like this specification, and have two questions I'd like to > > understand before balloting YES ... > > > > I'm looking at this text: > > > > 4.5. Ceasing Transmission > > > > What it means to cease transmission depends on the application. The > > intention is that the application will stop sending RTP data packets > > to a particular destination 3-tuple (transport protocol, destination > > port, IP address), until the user makes an explicit attempt to > > restart the call. It is important that a human user is involved in > > the decision to try to restart the call, since that user will > > eventually give up if the calls repeatedly trigger the circuit > > breaker. This will help avoid problems with automatic redial systems > > from congesting the network. Accordingly, RTP flows halted by the > > circuit breaker SHOULD NOT be restarted automatically unless the > > ^^^^^^^^^^ > > sender has received information that the congestion has dissipated, > > or can reasonably be expected to have dissipated. > > > > and trying to understand why this is not MUST NOT. I'm trying to > > reconcile this with the RFC 2119 definition of SHOULD NOT, which is > > > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > > there may exist valid reasons in particular circumstances when the > > particular behavior is acceptable or even useful, but the full > > implications should be understood and the case carefully weighed > > before implementing any behavior described with this label. > > > > Could you help me understand when automatic restarts might be > =E2=80=9Cacceptable or even useful=E2=80=9D? > > As stated, automatic restarts might be acceptable or even useful if the > sender receives information that the congestion has dissipated, or can > reasonably be expected to have dissipated. This is why it says =E2=80=9CS= HOULD NOT > =E2=80=A6 unless =E2=80=9D rather than =E2=80=9CMUST NOT=E2=80= =9D. Hi, Colin, On this one, I was getting tripped up on "or can be reasonably expected to have dissipated" for an automatic restart, but if this means that an implementer has thought about what has to happen before an implementation does a restart with no user involvement, I can see that. I was getting tied up with the subsequent text, but perhaps I shouldn't have been. Thanks for the help on that one. > > Reading on, I'm wondering if this text is anticipating > > > > It is recognised that the RTP implementation in some systems might > > not be able to determine if a call set-up request was initiated by a > > human user, or automatically by some scripted higher-level component > > of the system. > > > > but definitely want to understand what you're thinking here. > > > > I have a similar question about this text > > > > ECN-CE marked packets SHOULD be treated as if it were lost for the > > purposes of congestion control, when determining the optimal media > > sending rate for an RTP flow. If an RTP sender has negotiated ECN > > support for an RTP session, and has successfully initiated ECN use on > > the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD > > ^^^^^^ > > be treated as if they were lost when calculating if the congestion- > > based RTP circuit breaker (Section 4.3) has been met. > > > > Could you help me understand why an implementation wouldn't do this? > > Because there are a small number of paths that misbehave when ECN marked > packet are sent. I wanted to allow leeway for an end-point to not respond > to ECN-CE marks on paths that spuriously mark packets, so falling back to > the behaving as-if ECN was not used. I don=E2=80=99t believe this is harm= ful to the > network, since the result will be the same as achieved by a non-ECN capab= le > transport. So, the scenario you're thinking of, is that you and I negotiated ECN support for a session, I started marking packets, and a path started marking packets with ECN-CE whether congestion was being encountered or not, and I realize that's happening (by some logic not specified), so I can't trust ECN-CE. Do I have that right? Assuming I'm close ... So, since I can't trust ECN-CE, I keep sending as if I wasn't getting ECN-CE, and either that works (so, I did the right thing), or I manage to cause enough congestion that it shows up in RTCP reports (so, I did the wrong thing before, but I'll react to the less problematic RTCP reports and do the right thing now, and that won't be any worse than what would have happened if we hadn't been able to negotiate ECN support in the first place). Do I have that right? Again, assuming that I'm at least close ... I think what you're doing is "safe enough" that this isn't Discuss-worthy, so I'll clear, but I wish the explanation of what's going on here was more explicit. If you want to try to make that happen, I'm happy to chat further= . Thanks, Spencer > -- > Colin Perkins > https://csperkins.org/ > > > > > --001a11409dae74513f05316a878f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Colin,

On Tue, Apr 26, 2016 at 9:43 AM, Colin Perkins = <csp@csperkins.or= g> wrote:
Spencer,

> On 20 Apr 2016, at 02:20, Spencer Dawkins <spencer.dawkins@huawei.com> wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-avtcore-rtp-circuit-breakers-14: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ie= tf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I really like this specification, and have two questions I'd like = to
> understand before balloting YES ...
>
> I'm looking at this text:
>
> 4.5.=C2=A0 Ceasing Transmission
>
>=C2=A0 =C2=A0What it means to cease transmission depends on the applica= tion.=C2=A0 The
>=C2=A0 =C2=A0intention is that the application will stop sending RTP da= ta packets
>=C2=A0 =C2=A0to a particular destination 3-tuple (transport protocol, d= estination
>=C2=A0 =C2=A0port, IP address), until the user makes an explicit attemp= t to
>=C2=A0 =C2=A0restart the call.=C2=A0 It is important that a human user = is involved in
>=C2=A0 =C2=A0the decision to try to restart the call, since that user w= ill
>=C2=A0 =C2=A0eventually give up if the calls repeatedly trigger the cir= cuit
>=C2=A0 =C2=A0breaker.=C2=A0 This will help avoid problems with automati= c redial systems
>=C2=A0 =C2=A0from congesting the network.=C2=A0 Accordingly, RTP flows = halted by the
>=C2=A0 =C2=A0circuit breaker SHOULD NOT be restarted automatically unle= ss the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^= ^^^^^^^^
>=C2=A0 =C2=A0sender has received information that the congestion has di= ssipated,
>=C2=A0 =C2=A0or can reasonably be expected to have dissipated.
>
> and trying to understand why this is not MUST NOT. I'm trying to > reconcile this with the RFC 2119 definition of SHOULD NOT, which is >
> 4. SHOULD NOT=C2=A0 =C2=A0This phrase, or the phrase "NOT RECOMME= NDED" mean that
>=C2=A0 =C2=A0there may exist valid reasons in particular circumstances = when the
>=C2=A0 =C2=A0particular behavior is acceptable or even useful, but the = full
>=C2=A0 =C2=A0implications should be understood and the case carefully w= eighed
>=C2=A0 =C2=A0before implementing any behavior described with this label= .
>
> Could you help me understand when automatic restarts might be =E2=80= =9Cacceptable or even useful=E2=80=9D?

As stated, automatic restarts might be acceptable or even usefu= l if the sender receives information that the congestion has dissipated, or= can reasonably be expected to have dissipated. This is why it says =E2=80= =9CSHOULD NOT =E2=80=A6 unless <reasons>=E2=80=9D rather than =E2=80= =9CMUST NOT=E2=80=9D.

Hi, Colin,=C2=A0

On this one, I was getting tripped up on "or can = be reasonably expected to have dissipated" for an automatic restart, b= ut if this means that an implementer has thought about what has to happen b= efore an implementation does a restart with no user involvement, I can see = that.=C2=A0

I was getting tied up with the subsequ= ent text, but perhaps I shouldn't have been.

T= hanks for the help on that one.
=C2=A0
= > Reading on, I'm wondering if this text is anticip= ating
>
>=C2=A0 =C2=A0It is recognised that the RTP implementation in some syste= ms might
>=C2=A0 =C2=A0not be able to determine if a call set-up request was init= iated by a
>=C2=A0 =C2=A0human user, or automatically by some scripted higher-level= component
>=C2=A0 =C2=A0of the system.
>
> but definitely want to understand what you're thinking here.
>
> I have a similar question about this text
>
>=C2=A0 =C2=A0ECN-CE marked packets SHOULD be treated as if it were lost= for the
>=C2=A0 =C2=A0purposes of congestion control, when determining the optim= al media
>=C2=A0 =C2=A0sending rate for an RTP flow.=C2=A0 If an RTP sender has n= egotiated ECN
>=C2=A0 =C2=A0support for an RTP session, and has successfully initiated= ECN use on
>=C2=A0 =C2=A0the path to the receiver [RFC6679], then ECN-CE marked pac= kets SHOULD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ^^^^^^
>=C2=A0 =C2=A0be treated as if they were lost when calculating if the co= ngestion-
>=C2=A0 =C2=A0based RTP circuit breaker (Section 4.3) has been met.
>
> Could you help me understand why an implementation wouldn't do thi= s?

Because there are a small number of paths that misbehave when ECN ma= rked packet are sent. I wanted to allow leeway for an end-point to not resp= ond to ECN-CE marks on paths that spuriously mark packets, so falling back = to the behaving as-if ECN was not used. I don=E2=80=99t believe this is har= mful to the network, since the result will be the same as achieved by a non= -ECN capable transport.

So, the scenario yo= u're thinking of, is that you and I negotiated ECN support for a sessio= n, I started marking packets, and a path started marking packets with ECN-C= E whether congestion was being encountered or not, and I realize that's= happening (by some logic not specified), so I can't trust ECN-CE.=C2= =A0

Do I have that right? Assuming I'm close .= ..

So, since I can't trust ECN-CE, I keep send= ing as if I wasn't getting ECN-CE, and either that works (so, I did the= right thing), or I manage to cause enough congestion that it shows up in R= TCP reports (so, I did the wrong thing before, but I'll react to the le= ss problematic RTCP reports and do the right thing now, and that won't = be any worse than what would have happened if we hadn't been able to ne= gotiate ECN support in the first place).=C2=A0

Do = I have that right? Again, assuming that I'm at least close ...

I think what you're doing is "safe enough" t= hat this isn't Discuss-worthy, so I'll clear, but I wish the explan= ation of what's going on here was more explicit. If you want to try to = make that happen, I'm happy to chat further.

T= hanks,

Spencer
=C2=A0
--
Colin Perkins
htt= ps://csperkins.org/





--001a11409dae74513f05316a878f-- From nobody Tue Apr 26 15:09:24 2016 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C895012D0CF; Tue, 26 Apr 2016 15:09:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160426220919.30160.97952.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2016 15:09:19 -0700 Archived-At: Cc: avtcore-chairs@ietf.org, magnus.westerlund@ericsson.com, draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, avt@ietf.org Subject: [AVTCORE] Spencer Dawkins' Yes on draft-ietf-avtcore-rtp-circuit-breakers-14: (with COMMENT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 22:09:20 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-avtcore-rtp-circuit-breakers-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for working with me on my Discuss. From nobody Tue Apr 26 15:28:15 2016 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 0E88412D0FA; Tue, 26 Apr 2016 15:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjBra8oNomjY; Tue, 26 Apr 2016 15:28:06 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B7612D0B0; Tue, 26 Apr 2016 15:28:06 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id o66so42613274ywc.3; Tue, 26 Apr 2016 15:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=MzE/sAKHtsmmJH1FN0df65zarXuttsPRxgVGU0ie3/A=; b=QwR0wN9jO2uB/PlQZcI1nYD8waWhJctgSyCQ/BGoFQrju/OGPZ66EiJycctYAM6C8K fH2SdcZsynKL8DzhZq6RVbF3J5PBcVIcE51SZDtvlcFJePdjrv1jjkSxt4Fsyv0xgO/d n08htTfTj5lKCLRRpsEKAFGln26w9KKmBethzCoTp5rTqwwwxmogjEZnUNmvd7hA1ZUI 71OaqHT9rughCuxWSU0vXps/nwU0dhp0ycBOYD8UMUVv+dkiMxPmy+hDyp6WB4pIAc4q wxmsiZkWXZquOADptYvmP52YjLyjg5xzQ5TWXqD3+99Pe6an0L51Ogc++FypLX9c8QoI pbkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MzE/sAKHtsmmJH1FN0df65zarXuttsPRxgVGU0ie3/A=; b=FsWyfIls1xQfi0DeV3PNsUNacg3Hwzo5YqKwEFhESmAYv7dZ/Wf4otDwY9oR3WH+JX ldj/R6B+ENcWGKlbqmhnlKz8p9U31OvkBMDtyJvMizmoMvine8NIXbaHCZ45GanODALr EQ//b0J5zln8kGnJKhNclDpvgK1ZLlzDnC1bBvwEid3JmzL/Ov/qWKek1cU0pY/TXgQq Arf7ixs/4fW65RPD4p0/1N2uh5jNl/iPl01OP5Vh4MZlR81Wu1Y6Z21c8bS+e12GaKxI 2vq5SWXdILgaVg5JlHi307ZZ6nuFIsvISenclQx8m0y+WjApKxu8b4pH6ihAFaez0n9Q zr7A== X-Gm-Message-State: AOPr4FVF6oONudRZCaVFK+xVTsugjEz2fsB8ZMtTeW04Mr7uZW40fkTF3CZQhJmiQ2IL0QYWHZMcFBRUeKmwXQ== MIME-Version: 1.0 X-Received: by 10.13.196.132 with SMTP id g126mr3255017ywd.258.1461709685916; Tue, 26 Apr 2016 15:28:05 -0700 (PDT) Received: by 10.37.224.212 with HTTP; Tue, 26 Apr 2016 15:28:05 -0700 (PDT) In-Reply-To: <8AFC0439-D9C8-458C-B413-8610AC187A37@csperkins.org> References: <20160420012041.31613.87215.idtracker@ietfa.amsl.com> <78034C12-57A3-4680-8B86-5C8F22E8ED19@csperkins.org> <8AFC0439-D9C8-458C-B413-8610AC187A37@csperkins.org> Date: Tue, 26 Apr 2016 17:28:05 -0500 Message-ID: From: Spencer Dawkins at IETF To: Colin Perkins Content-Type: multipart/alternative; boundary=001a114d7ed4980c6305316aceb5 Archived-At: Cc: avtcore-chairs@ietf.org, Magnus Westerlund , draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, The IESG , avt@ietf.org Subject: Re: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 22:28:09 -0000 --001a114d7ed4980c6305316aceb5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Colin, On Tue, Apr 26, 2016 at 5:13 PM, Colin Perkins wrote: > Hi, > > > On 26 Apr 2016, at 23:08, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Hi, Colin, > > > > On Tue, Apr 26, 2016 at 9:43 AM, Colin Perkins > wrote: > > > >> Spencer, > >> > >>> On 20 Apr 2016, at 02:20, Spencer Dawkins > wrote: > >>> > >>> Spencer Dawkins has entered the following ballot position for > >>> draft-ietf-avtcore-rtp-circuit-breakers-14: Discuss > >>> > >>> When responding, please keep the subject line intact and reply to all > >>> email addresses included in the To and CC lines. (Feel free to cut th= is > >>> introductory paragraph, however.) > >>> > >>> > >>> Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > >>> for more information about IESG DISCUSS and COMMENT positions. > >>> > >>> > >>> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ > >>> > >>> > >>> > >>> ---------------------------------------------------------------------= - > >>> DISCUSS: > >>> ---------------------------------------------------------------------= - > >>> > >>> I really like this specification, and have two questions I'd like to > >>> understand before balloting YES ... > >>> > >>> I'm looking at this text: > >>> > >>> 4.5. Ceasing Transmission > >>> > >>> What it means to cease transmission depends on the application. The > >>> intention is that the application will stop sending RTP data packets > >>> to a particular destination 3-tuple (transport protocol, destination > >>> port, IP address), until the user makes an explicit attempt to > >>> restart the call. It is important that a human user is involved in > >>> the decision to try to restart the call, since that user will > >>> eventually give up if the calls repeatedly trigger the circuit > >>> breaker. This will help avoid problems with automatic redial system= s > >>> from congesting the network. Accordingly, RTP flows halted by the > >>> circuit breaker SHOULD NOT be restarted automatically unless the > >>> ^^^^^^^^^^ > >>> sender has received information that the congestion has dissipated, > >>> or can reasonably be expected to have dissipated. > >>> > >>> and trying to understand why this is not MUST NOT. I'm trying to > >>> reconcile this with the RFC 2119 definition of SHOULD NOT, which is > >>> > >>> 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean tha= t > >>> there may exist valid reasons in particular circumstances when the > >>> particular behavior is acceptable or even useful, but the full > >>> implications should be understood and the case carefully weighed > >>> before implementing any behavior described with this label. > >>> > >>> Could you help me understand when automatic restarts might be > >> =E2=80=9Cacceptable or even useful=E2=80=9D? > >> > >> As stated, automatic restarts might be acceptable or even useful if th= e > >> sender receives information that the congestion has dissipated, or can > >> reasonably be expected to have dissipated. This is why it says =E2=80= =9CSHOULD > NOT > >> =E2=80=A6 unless =E2=80=9D rather than =E2=80=9CMUST NOT=E2= =80=9D. > > > > > > Hi, Colin, > > > > On this one, I was getting tripped up on "or can be reasonably expected > to > > have dissipated" for an automatic restart, but if this means that an > > implementer has thought about what has to happen before an implementati= on > > does a restart with no user involvement, I can see that. > > > > I was getting tied up with the subsequent text, but perhaps I shouldn't > > have been. > > > > Thanks for the help on that one. > > Thanks. Happy to clarify, if you have suggestions. I think the point that had my shoelaces tied together was the incongruity of an RTP implementation itself with expectations. If you can come up with text that says something like "or can be reasonably expected to have dissipated, based on the amount of time that has elapsed since the circuit breaker has tripped", or whatever else you're thinking of, that would have helped me. (I'm assuming that the only thing an implementation has to work with when it hasn't received information that congestion has dissipated, would be the passage of time, but you'd know better what would be reasonable here) > >>> Reading on, I'm wondering if this text is anticipating > >>> > >>> It is recognised that the RTP implementation in some systems might > >>> not be able to determine if a call set-up request was initiated by a > >>> human user, or automatically by some scripted higher-level component > >>> of the system. > >>> > >>> but definitely want to understand what you're thinking here. > >>> > >>> I have a similar question about this text > >>> > >>> ECN-CE marked packets SHOULD be treated as if it were lost for the > >>> purposes of congestion control, when determining the optimal media > >>> sending rate for an RTP flow. If an RTP sender has negotiated ECN > >>> support for an RTP session, and has successfully initiated ECN use o= n > >>> the path to the receiver [RFC6679], then ECN-CE marked packets SHOUL= D > >>> ^^^^^= ^ > >>> be treated as if they were lost when calculating if the congestion- > >>> based RTP circuit breaker (Section 4.3) has been met. > >>> > >>> Could you help me understand why an implementation wouldn't do this? > >> > >> Because there are a small number of paths that misbehave when ECN mark= ed > >> packet are sent. I wanted to allow leeway for an end-point to not > respond > >> to ECN-CE marks on paths that spuriously mark packets, so falling back > to > >> the behaving as-if ECN was not used. I don=E2=80=99t believe this is h= armful to > the > >> network, since the result will be the same as achieved by a non-ECN > capable > >> transport. > > > > > > So, the scenario you're thinking of, is that you and I negotiated ECN > > support for a session, I started marking packets, and a path started > > marking packets with ECN-CE whether congestion was being encountered or > > not, and I realize that's happening (by some logic not specified), so I > > can't trust ECN-CE. > > > > Do I have that right? Assuming I=E2=80=99m close ... > > Yes, that=E2=80=99s one possible scenario. I can=E2=80=99t find it now, b= ut I also seem to > recall Apple reporting on strange experiences with ECN at a recent IETF. Yum. > > So, since I can't trust ECN-CE, I keep sending as if I wasn't getting > > ECN-CE, and either that works (so, I did the right thing), or I manage = to > > cause enough congestion that it shows up in RTCP reports (so, I did the > > wrong thing before, but I'll react to the less problematic RTCP reports > and > > do the right thing now, and that won't be any worse than what would hav= e > > happened if we hadn't been able to negotiate ECN support in the first > > place). > > > > Do I have that right? Again, assuming that I=E2=80=99m at least close .= .. > > Yup. > > > I think what you're doing is "safe enough" that this isn't > Discuss-worthy, > > so I'll clear, but I wish the explanation of what's going on here was > more > > explicit. If you want to try to make that happen, I'm happy to chat > further > > Happy to revise, if you think it would help. It=E2=80=99s better to make = this > clear, if we can. So, at the risk of making an impressively long sentence longer ... I'm thinking of something like If an RTP sender has negotiated ECN support for an RTP session, and has successfully initiated ECN use on the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD be treated as if they were lost when calculating if the congestion-based RTP circuit breaker (Section 4.3) has been met, unless the RTP implementation can determine that ECN-CE marking on this path is not reliable. Is that something like what we were saying in the previous exchange? Thanks, Spencer -- > Colin Perkins > https://csperkins.org/ > > > > > --001a114d7ed4980c6305316aceb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Colin,

On Tue, Apr 26, 2016 at 5:13 PM, Colin Perkins = <csp@csperkins.or= g> wrote:
Hi,

> On 26 Apr 2016, at 23:08, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrot= e:
>
> Hi, Colin,
>
> On Tue, Apr 26, 2016 at 9:43 AM, Colin Perkins <csp@csperkins.org> wrote:
>
>> Spencer,
>>
>>> On 20 Apr 2016, at 02:20, Spencer Dawkins <spencer.dawkins@huawei.com> wrote:
>>>
>>> Spencer Dawkins has entered the following ballot position for<= br> >>> draft-ietf-avtcore-rtp-circuit-breakers-14: Discuss
>>>
>>> When responding, please keep the subject line intact and reply= to all
>>> email addresses included in the To and CC lines. (Feel free to= cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to https://www.ie= tf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.=
>>>
>>>
>>> The document, along with other ballot positions, can be found = here: https://datatracker.i= etf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/
>>>
>>>
>>>
>>> --------------------------------------------------------------= --------
>>> DISCUSS:
>>> --------------------------------------------------------------= --------
>>>
>>> I really like this specification, and have two questions I'= ;d like to
>>> understand before balloting YES ...
>>>
>>> I'm looking at this text:
>>>
>>> 4.5.=C2=A0 Ceasing Transmission
>>>
>>>=C2=A0 What it means to cease transmission depends on the appli= cation.=C2=A0 The
>>>=C2=A0 intention is that the application will stop sending RTP = data packets
>>>=C2=A0 to a particular destination 3-tuple (transport protocol,= destination
>>>=C2=A0 port, IP address), until the user makes an explicit atte= mpt to
>>>=C2=A0 restart the call.=C2=A0 It is important that a human use= r is involved in
>>>=C2=A0 the decision to try to restart the call, since that user= will
>>>=C2=A0 eventually give up if the calls repeatedly trigger the c= ircuit
>>>=C2=A0 breaker.=C2=A0 This will help avoid problems with automa= tic redial systems
>>>=C2=A0 from congesting the network.=C2=A0 Accordingly, RTP flow= s halted by the
>>>=C2=A0 circuit breaker SHOULD NOT be restarted automatically un= less the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = ^^^^^^^^^^
>>>=C2=A0 sender has received information that the congestion has = dissipated,
>>>=C2=A0 or can reasonably be expected to have dissipated.
>>>
>>> and trying to understand why this is not MUST NOT. I'm try= ing to
>>> reconcile this with the RFC 2119 definition of SHOULD NOT, whi= ch is
>>>
>>> 4. SHOULD NOT=C2=A0 =C2=A0This phrase, or the phrase "NOT= RECOMMENDED" mean that
>>>=C2=A0 there may exist valid reasons in particular circumstance= s when the
>>>=C2=A0 particular behavior is acceptable or even useful, but th= e full
>>>=C2=A0 implications should be understood and the case carefully= weighed
>>>=C2=A0 before implementing any behavior described with this lab= el.
>>>
>>> Could you help me understand when automatic restarts might be<= br> >> =E2=80=9Cacceptable or even useful=E2=80=9D?
>>
>> As stated, automatic restarts might be acceptable or even useful i= f the
>> sender receives information that the congestion has dissipated, or= can
>> reasonably be expected to have dissipated. This is why it says =E2= =80=9CSHOULD NOT
>> =E2=80=A6 unless <reasons>=E2=80=9D rather than =E2=80=9CMUS= T NOT=E2=80=9D.
>
>
> Hi, Colin,
>
> On this one, I was getting tripped up on "or can be reasonably ex= pected to
> have dissipated" for an automatic restart, but if this means that= an
> implementer has thought about what has to happen before an implementat= ion
> does a restart with no user involvement, I can see that.
>
> I was getting tied up with the subsequent text, but perhaps I shouldn&= #39;t
> have been.
>
> Thanks for the help on that one.

Thanks. Happy to clarify, if you have suggestions.
=

I think the point that had my shoelaces tied together w= as the incongruity of an RTP implementation itself with expectations.=C2=A0=

If you can come up with text that says something = like "or can be reasonably expected to have dissipated, based on the a= mount of time that has elapsed since the circuit breaker has tripped",= or whatever else you're thinking of, that would have helped me.
<= div>
(I'm assuming that the only thing an implementation = has to work with when it hasn't received information that congestion ha= s dissipated, would be the passage of time, but you'd know better what = would be reasonable here)
=C2=A0
>>> Reading on, I'm wondering if this= text is anticipating
>>>
>>>=C2=A0 It is recognised that the RTP implementation in some sys= tems might
>>>=C2=A0 not be able to determine if a call set-up request was in= itiated by a
>>>=C2=A0 human user, or automatically by some scripted higher-lev= el component
>>>=C2=A0 of the system.
>>>
>>> but definitely want to understand what you're thinking her= e.
>>>
>>> I have a similar question about this text
>>>
>>>=C2=A0 ECN-CE marked packets SHOULD be treated as if it were lo= st for the
>>>=C2=A0 purposes of congestion control, when determining the opt= imal media
>>>=C2=A0 sending rate for an RTP flow.=C2=A0 If an RTP sender has= negotiated ECN
>>>=C2=A0 support for an RTP session, and has successfully initiat= ed ECN use on
>>>=C2=A0 the path to the receiver [RFC6679], then ECN-CE marked p= ackets SHOULD
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0^^^^^^
>>>=C2=A0 be treated as if they were lost when calculating if the = congestion-
>>>=C2=A0 based RTP circuit breaker (Section 4.3) has been met. >>>
>>> Could you help me understand why an implementation wouldn'= t do this?
>>
>> Because there are a small number of paths that misbehave when ECN = marked
>> packet are sent. I wanted to allow leeway for an end-point to not = respond
>> to ECN-CE marks on paths that spuriously mark packets, so falling = back to
>> the behaving as-if ECN was not used. I don=E2=80=99t believe this = is harmful to the
>> network, since the result will be the same as achieved by a non-EC= N capable
>> transport.
>
>
> So, the scenario you're thinking of, is that you and I negotiated = ECN
> support for a session, I started marking packets, and a path started > marking packets with ECN-CE whether congestion was being encountered o= r
> not, and I realize that's happening (by some logic not specified),= so I
> can't trust ECN-CE.
>
> Do I have that right? Assuming I=E2=80=99m close ...

Yes, that=E2=80=99s one possible scenario. I can=E2=80=99t find= it now, but I also seem to recall Apple reporting on strange experiences w= ith ECN at a recent IETF.

Yum.
= =C2=A0
> So, since I can't tr= ust ECN-CE, I keep sending as if I wasn't getting
> ECN-CE, and either that works (so, I did the right thing), or I manage= to
> cause enough congestion that it shows up in RTCP reports (so, I did th= e
> wrong thing before, but I'll react to the less problematic RTCP re= ports and
> do the right thing now, and that won't be any worse than what woul= d have
> happened if we hadn't been able to negotiate ECN support in the fi= rst
> place).
>
> Do I have that right? Again, assuming that I=E2=80=99m at least close = ...

Yup.

> I think what you're doing is "safe enough" that this isn= 't Discuss-worthy,
> so I'll clear, but I wish the explanation of what's going on h= ere was more
> explicit. If you want to try to make that happen, I'm happy to cha= t further

Happy to revise, if you think it would help. It=E2=80=99s better to = make this clear, if we can.

So, at the risk= of making an impressively long sentence longer ... I'm thinking of som= ething like

If an RTP sender has negotiated ECN=C2= =A0support for an RTP session, and has successfully initiated ECN use on=C2= =A0the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD=C2= =A0be treated as if they were lost when calculating if the congestion-based= RTP circuit breaker (Section 4.3) has been met, unless the RTP implementat= ion can determine that ECN-CE marking on this path is not reliable.

Is that something like what we were saying in the pre= vious exchange?

Thanks,

S= pencer

--
Colin Perkins
htt= ps://csperkins.org/





--001a114d7ed4980c6305316aceb5-- From nobody Tue Apr 26 15:36:42 2016 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 D200112D15C; Tue, 26 Apr 2016 15:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHW7hsAQ6CK1; Tue, 26 Apr 2016 15:36:33 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6456212B020; Tue, 26 Apr 2016 15:36:33 -0700 (PDT) Received: from [130.209.254.12] (port=58470 helo=vpn12.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1avBan-0000TM-Fd; Tue, 26 Apr 2016 23:36:31 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_1429AF80-A4D7-40A5-B635-3F98A11A2773" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Tue, 26 Apr 2016 23:36:27 +0100 Message-Id: References: <20160420012041.31613.87215.idtracker@ietfa.amsl.com> <78034C12-57A3-4680-8B86-5C8F22E8ED19@csperkins.org> <8AFC0439-D9C8-458C-B413-8610AC187A37@csperkins.org> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: avtcore-chairs@ietf.org, Magnus Westerlund , draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, The IESG , avt@ietf.org Subject: Re: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 22:36:37 -0000 --Apple-Mail=_1429AF80-A4D7-40A5-B635-3F98A11A2773 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 26 Apr 2016, at 23:28, Spencer Dawkins at IETF = wrote: >=20 > Hi, Colin, >=20 > On Tue, Apr 26, 2016 at 5:13 PM, Colin Perkins > wrote: > Hi, >=20 > > On 26 Apr 2016, at 23:08, Spencer Dawkins at IETF = > = wrote: > > > > Hi, Colin, > > > > On Tue, Apr 26, 2016 at 9:43 AM, Colin Perkins > wrote: > > > >> Spencer, > >> > >>> On 20 Apr 2016, at 02:20, Spencer Dawkins = > wrote: > >>> > >>> Spencer Dawkins has entered the following ballot position for > >>> draft-ietf-avtcore-rtp-circuit-breakers-14: Discuss > >>> > >>> When responding, please keep the subject line intact and reply to = all > >>> email addresses included in the To and CC lines. (Feel free to cut = this > >>> introductory paragraph, however.) > >>> > >>> > >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > >>> for more information about IESG DISCUSS and COMMENT positions. > >>> > >>> > >>> The document, along with other ballot positions, can be found = here: = https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ = > >>> > >>> > >>> > >>> = ---------------------------------------------------------------------- > >>> DISCUSS: > >>> = ---------------------------------------------------------------------- > >>> > >>> I really like this specification, and have two questions I'd like = to > >>> understand before balloting YES ... > >>> > >>> I'm looking at this text: > >>> > >>> 4.5. Ceasing Transmission > >>> > >>> What it means to cease transmission depends on the application. = The > >>> intention is that the application will stop sending RTP data = packets > >>> to a particular destination 3-tuple (transport protocol, = destination > >>> port, IP address), until the user makes an explicit attempt to > >>> restart the call. It is important that a human user is involved = in > >>> the decision to try to restart the call, since that user will > >>> eventually give up if the calls repeatedly trigger the circuit > >>> breaker. This will help avoid problems with automatic redial = systems > >>> from congesting the network. Accordingly, RTP flows halted by = the > >>> circuit breaker SHOULD NOT be restarted automatically unless the > >>> ^^^^^^^^^^ > >>> sender has received information that the congestion has = dissipated, > >>> or can reasonably be expected to have dissipated. > >>> > >>> and trying to understand why this is not MUST NOT. I'm trying to > >>> reconcile this with the RFC 2119 definition of SHOULD NOT, which = is > >>> > >>> 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean = that > >>> there may exist valid reasons in particular circumstances when = the > >>> particular behavior is acceptable or even useful, but the full > >>> implications should be understood and the case carefully weighed > >>> before implementing any behavior described with this label. > >>> > >>> Could you help me understand when automatic restarts might be > >> =E2=80=9Cacceptable or even useful=E2=80=9D? > >> > >> As stated, automatic restarts might be acceptable or even useful if = the > >> sender receives information that the congestion has dissipated, or = can > >> reasonably be expected to have dissipated. This is why it says = =E2=80=9CSHOULD NOT > >> =E2=80=A6 unless =E2=80=9D rather than =E2=80=9CMUST = NOT=E2=80=9D. > > > > > > Hi, Colin, > > > > On this one, I was getting tripped up on "or can be reasonably = expected to > > have dissipated" for an automatic restart, but if this means that an > > implementer has thought about what has to happen before an = implementation > > does a restart with no user involvement, I can see that. > > > > I was getting tied up with the subsequent text, but perhaps I = shouldn't > > have been. > > > > Thanks for the help on that one. >=20 > Thanks. Happy to clarify, if you have suggestions. >=20 > I think the point that had my shoelaces tied together was the = incongruity of an RTP implementation itself with expectations.=20 >=20 > If you can come up with text that says something like "or can be = reasonably expected to have dissipated, based on the amount of time that = has elapsed since the circuit breaker has tripped", or whatever else = you're thinking of, that would have helped me. >=20 > (I=E2=80=99m assuming that the only thing an implementation has to = work with when it hasn't received information that congestion has = dissipated, would be the passage of time, but you'd know better what = would be reasonable here) It could also be something like a mobile device, that knows it=E2=80=99s = now in a new location, and so might have a different path. I can give = some examples, maybe? > >>> Reading on, I'm wondering if this text is anticipating > >>> > >>> It is recognised that the RTP implementation in some systems = might > >>> not be able to determine if a call set-up request was initiated = by a > >>> human user, or automatically by some scripted higher-level = component > >>> of the system. > >>> > >>> but definitely want to understand what you're thinking here. > >>> > >>> I have a similar question about this text > >>> > >>> ECN-CE marked packets SHOULD be treated as if it were lost for = the > >>> purposes of congestion control, when determining the optimal = media > >>> sending rate for an RTP flow. If an RTP sender has negotiated = ECN > >>> support for an RTP session, and has successfully initiated ECN = use on > >>> the path to the receiver [RFC6679], then ECN-CE marked packets = SHOULD > >>> = ^^^^^^ > >>> be treated as if they were lost when calculating if the = congestion- > >>> based RTP circuit breaker (Section 4.3) has been met. > >>> > >>> Could you help me understand why an implementation wouldn't do = this? > >> > >> Because there are a small number of paths that misbehave when ECN = marked > >> packet are sent. I wanted to allow leeway for an end-point to not = respond > >> to ECN-CE marks on paths that spuriously mark packets, so falling = back to > >> the behaving as-if ECN was not used. I don=E2=80=99t believe this = is harmful to the > >> network, since the result will be the same as achieved by a non-ECN = capable > >> transport. > > > > > > So, the scenario you're thinking of, is that you and I negotiated = ECN > > support for a session, I started marking packets, and a path started > > marking packets with ECN-CE whether congestion was being encountered = or > > not, and I realize that's happening (by some logic not specified), = so I > > can't trust ECN-CE. > > > > Do I have that right? Assuming I=E2=80=99m close ... >=20 > Yes, that=E2=80=99s one possible scenario. I can=E2=80=99t find it = now, but I also seem to recall Apple reporting on strange experiences = with ECN at a recent IETF. >=20 > Yum. > =20 > > So, since I can't trust ECN-CE, I keep sending as if I wasn't = getting > > ECN-CE, and either that works (so, I did the right thing), or I = manage to > > cause enough congestion that it shows up in RTCP reports (so, I did = the > > wrong thing before, but I'll react to the less problematic RTCP = reports and > > do the right thing now, and that won't be any worse than what would = have > > happened if we hadn't been able to negotiate ECN support in the = first > > place). > > > > Do I have that right? Again, assuming that I=E2=80=99m at least = close ... >=20 > Yup. >=20 > > I think what you're doing is "safe enough" that this isn't = Discuss-worthy, > > so I'll clear, but I wish the explanation of what's going on here = was more > > explicit. If you want to try to make that happen, I'm happy to chat = further >=20 > Happy to revise, if you think it would help. It=E2=80=99s better to = make this clear, if we can. >=20 > So, at the risk of making an impressively long sentence longer ... I'm = thinking of something like >=20 > If an RTP sender has negotiated ECN support for an RTP session, and = has successfully initiated ECN use on the path to the receiver = [RFC6679], then ECN-CE marked packets SHOULD be treated as if they were = lost when calculating if the congestion-based RTP circuit breaker = (Section 4.3) has been met, unless the RTP implementation can determine = that ECN-CE marking on this path is not reliable. >=20 > Is that something like what we were saying in the previous exchange? Makes sense. Do you want me to submit an update now, or hold off for a while? --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_1429AF80-A4D7-40A5-B635-3F98A11A2773 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On = 26 Apr 2016, at 23:28, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Colin,

On Tue, = Apr 26, 2016 at 5:13 PM, Colin Perkins <csp@csperkins.org> wrote:
Hi,

> On 26 Apr 2016, at = 23:08, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>
> Hi, Colin,
>
> On Tue, Apr 26, 2016 at 9:43 AM, Colin Perkins <csp@csperkins.org> = wrote:
>
>> Spencer,
>>
>>> On 20 Apr 2016, at 02:20, = Spencer Dawkins <spencer.dawkins@huawei.com> wrote:
>>>
>>> Spencer Dawkins has = entered the following ballot position for
>>> = draft-ietf-avtcore-rtp-circuit-breakers-14: Discuss
>>>
>>> When responding, = please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. = (Feel free to cut this
>>> introductory = paragraph, however.)
>>>
>>>
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html>>> for more information about IESG DISCUSS and = COMMENT positions.
>>>
>>>
>>> The document, along = with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit= -breakers/
>>>
>>>
>>>
>>> = ----------------------------------------------------------------------
>>> DISCUSS:
>>> = ----------------------------------------------------------------------
>>>
>>> I really like this = specification, and have two questions I'd like to
>>> understand before balloting YES ...
>>>
>>> I'm looking at this = text:
>>>
>>> 4.5.  = Ceasing Transmission
>>>
>>>  What it means to cease transmission = depends on the application.  The
>>>  = intention is that the application will stop sending RTP data packets
>>>  to a particular destination 3-tuple = (transport protocol, destination
>>>  port, = IP address), until the user makes an explicit attempt to
>>>  restart the call.  It is important = that a human user is involved in
>>>  the = decision to try to restart the call, since that user will
>>>  eventually give up if the calls repeatedly = trigger the circuit
>>>  breaker.  This = will help avoid problems with automatic redial systems
>>>  from congesting the network.  = Accordingly, RTP flows halted by the
>>>  = circuit breaker SHOULD NOT be restarted automatically unless the
>>>              =     ^^^^^^^^^^
>>>  sender has = received information that the congestion has dissipated,
>>>  or can reasonably be expected to have = dissipated.
>>>
>>> and = trying to understand why this is not MUST NOT. I'm trying to
>>> reconcile this with the RFC 2119 definition of = SHOULD NOT, which is
>>>
>>>= 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" = mean that
>>>  there may exist valid reasons = in particular circumstances when the
>>>  = particular behavior is acceptable or even useful, but the full
>>>  implications should be understood and the = case carefully weighed
>>>  before = implementing any behavior described with this label.
>>>
>>> Could you help me = understand when automatic restarts might be
>> = =E2=80=9Cacceptable or even useful=E2=80=9D?
>>
>> As stated, automatic restarts might be acceptable or = even useful if the
>> sender receives information = that the congestion has dissipated, or can
>> = reasonably be expected to have dissipated. This is why it says =E2=80=9CSH= OULD NOT
>> =E2=80=A6 unless <reasons>=E2=80=9D = rather than =E2=80=9CMUST NOT=E2=80=9D.
>
>
> Hi, Colin,
>
> On this one, I was getting tripped up on "or can be = reasonably expected to
> have dissipated" for an = automatic restart, but if this means that an
> = implementer has thought about what has to happen before an = implementation
> does a restart with no user = involvement, I can see that.
>
> I was = getting tied up with the subsequent text, but perhaps I shouldn't
> have been.
>
> Thanks = for the help on that one.

Thanks.= Happy to clarify, if you have suggestions.

I think the point that = had my shoelaces tied together was the incongruity of an RTP = implementation itself with expectations. 

If you can come up with text that says = something like "or can be reasonably expected to have dissipated, based = on the amount of time that has elapsed since the circuit breaker has = tripped", or whatever else you're thinking of, that would have helped = me.

(I=E2=80=99m= assuming that the only thing an implementation has to work with when it = hasn't received information that congestion has dissipated, would be the = passage of time, but you'd know better what would be reasonable = here)

It could also be something like a mobile device, = that knows it=E2=80=99s now in a new location, and so might have a = different path. I can give some examples, maybe?

>>> Reading on, I'm wondering if = this text is anticipating
>>>
>>>  It is = recognised that the RTP implementation in some systems might
>>>  not be able to determine if a call set-up = request was initiated by a
>>>  human user, = or automatically by some scripted higher-level component
>>>  of the system.
>>>>>> but definitely want to understand what you're = thinking here.
>>>
>>> I = have a similar question about this text
>>>
>>>  ECN-CE marked packets SHOULD be treated as = if it were lost for the
>>>  purposes of = congestion control, when determining the optimal media
>>>  sending rate for an RTP flow.  If an = RTP sender has negotiated ECN
>>>  support = for an RTP session, and has successfully initiated ECN use on
>>>  the path to the receiver [RFC6679], then = ECN-CE marked packets SHOULD
>>>    =                     =                     =                     =  ^^^^^^
>>>  be treated as if they were = lost when calculating if the congestion-
>>>  = based RTP circuit breaker (Section 4.3) has been met.
>>>
>>> Could you help me = understand why an implementation wouldn't do this?
>>
>> Because there are a small = number of paths that misbehave when ECN marked
>> = packet are sent. I wanted to allow leeway for an end-point to not = respond
>> to ECN-CE marks on paths that spuriously = mark packets, so falling back to
>> the behaving = as-if ECN was not used. I don=E2=80=99t believe this is harmful to = the
>> network, since the result will be the same as = achieved by a non-ECN capable
>> transport.
>
>
> So, the scenario = you're thinking of, is that you and I negotiated ECN
> = support for a session, I started marking packets, and a path started
> marking packets with ECN-CE whether congestion was being = encountered or
> not, and I realize that's happening = (by some logic not specified), so I
> can't trust = ECN-CE.
>
> Do I have that right? = Assuming I=E2=80=99m close ...

Yes, that=E2=80=99s one possible scenario. I = can=E2=80=99t find it now, but I also seem to recall Apple reporting on = strange experiences with ECN at a recent IETF.

Yum.
 
> So, since I can't trust ECN-CE, I keep sending as if I = wasn't getting
> ECN-CE, and either that works (so, I = did the right thing), or I manage to
> cause enough = congestion that it shows up in RTCP reports (so, I did the
> wrong thing before, but I'll react to the less = problematic RTCP reports and
> do the right thing now, = and that won't be any worse than what would have
> = happened if we hadn't been able to negotiate ECN support in the first
> place).
>
> Do I have = that right? Again, assuming that I=E2=80=99m at least close ...

Yup.

> I think what you're doing is "safe enough" that this = isn't Discuss-worthy,
> so I'll clear, but I wish the = explanation of what's going on here was more
> = explicit. If you want to try to make that happen, I'm happy to chat = further

Happy to revise, if you = think it would help. It=E2=80=99s better to make this clear, if we = can.

So, = at the risk of making an impressively long sentence longer ... I'm = thinking of something like

If an RTP sender has negotiated ECN support for an RTP = session, and has successfully initiated ECN use on the path to the = receiver [RFC6679], then ECN-CE marked packets SHOULD be treated as = if they were lost when calculating if the congestion-based RTP circuit = breaker (Section 4.3) has been met, unless the RTP implementation can = determine that ECN-CE marking on this path is not reliable.

Is = that something like what we were saying in the previous = exchange?

Makes sense.

Do you want me to submit an = update now, or hold off for a while?

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



= --Apple-Mail=_1429AF80-A4D7-40A5-B635-3F98A11A2773-- From nobody Tue Apr 26 15:41:18 2016 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 CD7CA12D57A; Tue, 26 Apr 2016 15:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWfq6BOUcYvG; Tue, 26 Apr 2016 15:41:16 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE0712D15C; Tue, 26 Apr 2016 15:41:15 -0700 (PDT) Received: from [81.187.2.149] (port=38775 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1avBEY-0006f3-Sm; Tue, 26 Apr 2016 23:13:32 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Tue, 26 Apr 2016 23:13:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AFC0439-D9C8-458C-B413-8610AC187A37@csperkins.org> References: <20160420012041.31613.87215.idtracker@ietfa.amsl.com> <78034C12-57A3-4680-8B86-5C8F22E8ED19@csperkins.org> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: avtcore-chairs@ietf.org, Magnus Westerlund , draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, The IESG , avt@ietf.org Subject: Re: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 22:41:18 -0000 Hi, > On 26 Apr 2016, at 23:08, Spencer Dawkins at IETF = wrote: >=20 > Hi, Colin, >=20 > On Tue, Apr 26, 2016 at 9:43 AM, Colin Perkins = wrote: >=20 >> Spencer, >>=20 >>> On 20 Apr 2016, at 02:20, Spencer Dawkins = wrote: >>>=20 >>> Spencer Dawkins has entered the following ballot position for >>> draft-ietf-avtcore-rtp-circuit-breakers-14: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: = https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> I really like this specification, and have two questions I'd like to >>> understand before balloting YES ... >>>=20 >>> I'm looking at this text: >>>=20 >>> 4.5. Ceasing Transmission >>>=20 >>> What it means to cease transmission depends on the application. = The >>> intention is that the application will stop sending RTP data = packets >>> to a particular destination 3-tuple (transport protocol, = destination >>> port, IP address), until the user makes an explicit attempt to >>> restart the call. It is important that a human user is involved in >>> the decision to try to restart the call, since that user will >>> eventually give up if the calls repeatedly trigger the circuit >>> breaker. This will help avoid problems with automatic redial = systems >>> from congesting the network. Accordingly, RTP flows halted by the >>> circuit breaker SHOULD NOT be restarted automatically unless the >>> ^^^^^^^^^^ >>> sender has received information that the congestion has dissipated, >>> or can reasonably be expected to have dissipated. >>>=20 >>> and trying to understand why this is not MUST NOT. I'm trying to >>> reconcile this with the RFC 2119 definition of SHOULD NOT, which is >>>=20 >>> 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean = that >>> there may exist valid reasons in particular circumstances when the >>> particular behavior is acceptable or even useful, but the full >>> implications should be understood and the case carefully weighed >>> before implementing any behavior described with this label. >>>=20 >>> Could you help me understand when automatic restarts might be >> =E2=80=9Cacceptable or even useful=E2=80=9D? >>=20 >> As stated, automatic restarts might be acceptable or even useful if = the >> sender receives information that the congestion has dissipated, or = can >> reasonably be expected to have dissipated. This is why it says = =E2=80=9CSHOULD NOT >> =E2=80=A6 unless =E2=80=9D rather than =E2=80=9CMUST NOT=E2=80= =9D. >=20 >=20 > Hi, Colin, >=20 > On this one, I was getting tripped up on "or can be reasonably = expected to > have dissipated" for an automatic restart, but if this means that an > implementer has thought about what has to happen before an = implementation > does a restart with no user involvement, I can see that. >=20 > I was getting tied up with the subsequent text, but perhaps I = shouldn't > have been. >=20 > Thanks for the help on that one. Thanks. Happy to clarify, if you have suggestions. >>> Reading on, I'm wondering if this text is anticipating >>>=20 >>> It is recognised that the RTP implementation in some systems might >>> not be able to determine if a call set-up request was initiated by = a >>> human user, or automatically by some scripted higher-level = component >>> of the system. >>>=20 >>> but definitely want to understand what you're thinking here. >>>=20 >>> I have a similar question about this text >>>=20 >>> ECN-CE marked packets SHOULD be treated as if it were lost for the >>> purposes of congestion control, when determining the optimal media >>> sending rate for an RTP flow. If an RTP sender has negotiated ECN >>> support for an RTP session, and has successfully initiated ECN use = on >>> the path to the receiver [RFC6679], then ECN-CE marked packets = SHOULD >>> = ^^^^^^ >>> be treated as if they were lost when calculating if the congestion- >>> based RTP circuit breaker (Section 4.3) has been met. >>>=20 >>> Could you help me understand why an implementation wouldn't do this? >>=20 >> Because there are a small number of paths that misbehave when ECN = marked >> packet are sent. I wanted to allow leeway for an end-point to not = respond >> to ECN-CE marks on paths that spuriously mark packets, so falling = back to >> the behaving as-if ECN was not used. I don=E2=80=99t believe this is = harmful to the >> network, since the result will be the same as achieved by a non-ECN = capable >> transport. >=20 >=20 > So, the scenario you're thinking of, is that you and I negotiated ECN > support for a session, I started marking packets, and a path started > marking packets with ECN-CE whether congestion was being encountered = or > not, and I realize that's happening (by some logic not specified), so = I > can't trust ECN-CE. >=20 > Do I have that right? Assuming I=E2=80=99m close ... Yes, that=E2=80=99s one possible scenario. I can=E2=80=99t find it now, = but I also seem to recall Apple reporting on strange experiences with = ECN at a recent IETF. > So, since I can't trust ECN-CE, I keep sending as if I wasn't getting > ECN-CE, and either that works (so, I did the right thing), or I manage = to > cause enough congestion that it shows up in RTCP reports (so, I did = the > wrong thing before, but I'll react to the less problematic RTCP = reports and > do the right thing now, and that won't be any worse than what would = have > happened if we hadn't been able to negotiate ECN support in the first > place). >=20 > Do I have that right? Again, assuming that I=E2=80=99m at least close = ... Yup. > I think what you're doing is "safe enough" that this isn't = Discuss-worthy, > so I'll clear, but I wish the explanation of what's going on here was = more > explicit. If you want to try to make that happen, I'm happy to chat = further Happy to revise, if you think it would help. It=E2=80=99s better to make = this clear, if we can. --=20 Colin Perkins https://csperkins.org/ From nobody Tue Apr 26 16:06:02 2016 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 A354812B063; Tue, 26 Apr 2016 16:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8cROdFstx8c; Tue, 26 Apr 2016 16:05:54 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B2C12B020; Tue, 26 Apr 2016 16:05:53 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id j74so39132350ywg.1; Tue, 26 Apr 2016 16:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OsdkQe1WiTY0ozenVtRSu9iK7ai4AGSrfHJ5FbFnWBY=; b=dwOTZpkq2NEqQjt50mtoo5SUQqF36WuPBMzps5n8SoXeJ19IuOcsOEruPzKARpDIeK xuCoKTYTqfVT3ulYaP9bOKFeOAMgsv5MqDFdk7BQFxCPOlV52ecfqJ12+wNGJfW9NyVC N6MUdFOmN/aIRsbPcRtEEwrZ/Dgl9L8YVeR4P5jFTQPgbHYrMNzY5TEWVNRJfMDYryK+ RDTqmTIawbVkNpBxKxCJ5nH5qY9eG7E4WbaButpQdD+osfqKcC1QCsDRiIW1Np+Lxnao otu5mjfkF23aMJdpP3omwJhMLmomy/yqhDfTYA4qmeh8NrAu60JyjF+oOn0ps2dFEpnx TMtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OsdkQe1WiTY0ozenVtRSu9iK7ai4AGSrfHJ5FbFnWBY=; b=ETmzE9MN230DDnGUHuemC6JiyosnNXbj3bzZOk/BBxZcXZMboGofh7dorWAgSPYull M/ErCpEH1G+l7iOJmQ6RDt3d8L7Gfpiyrvql8HdjVokwRRduqz20OBRW4ucg94QHs9T/ t0eH06avuK/7xIetgtAWvVWQ1CNEW2vprcwl04CYzLmrwxYIvLkzL47rKJ5QwrmiPDVo Ml8c7LO3YyQ+IVNf3+3FMexTWCbgV8zfa7NZkK+vcHbPcT/8ldLf/C+8BReGeTU4/dHV CN/gxKjX9TB28hsTVkCPN2oZgFk1o3IzaPpDwuU9ORABZN1YPIx2l1n6Xj/2VP+L0SqA uPkA== X-Gm-Message-State: AOPr4FX4hfrONGOw0ah3KmYR1uLIRz6wqbMoUYqEIPSwig5zXKphfdoKFLcdthnpIK3pGhCoPFC9r9jQXrxQ7A== MIME-Version: 1.0 X-Received: by 10.129.152.8 with SMTP id p8mr2981858ywg.157.1461711953248; Tue, 26 Apr 2016 16:05:53 -0700 (PDT) Received: by 10.37.224.212 with HTTP; Tue, 26 Apr 2016 16:05:53 -0700 (PDT) In-Reply-To: References: <20160420012041.31613.87215.idtracker@ietfa.amsl.com> <78034C12-57A3-4680-8B86-5C8F22E8ED19@csperkins.org> <8AFC0439-D9C8-458C-B413-8610AC187A37@csperkins.org> Date: Tue, 26 Apr 2016 18:05:53 -0500 Message-ID: From: Spencer Dawkins at IETF To: Colin Perkins Content-Type: multipart/alternative; boundary=94eb2c0bc490bcc66b05316b5552 Archived-At: Cc: avtcore-chairs@ietf.org, Magnus Westerlund , draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, The IESG , avt@ietf.org Subject: Re: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 23:05:56 -0000 --94eb2c0bc490bcc66b05316b5552 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Colin, On Tue, Apr 26, 2016 at 5:36 PM, Colin Perkins wrote: > Hi, > > On 26 Apr 2016, at 23:28, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Hi, Colin, > > On Tue, Apr 26, 2016 at 5:13 PM, Colin Perkins wrote: > >> Hi, >> >> > On 26 Apr 2016, at 23:08, Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com> wrote: >> > >> > Hi, Colin, >> > >> > On Tue, Apr 26, 2016 at 9:43 AM, Colin Perkins >> wrote: >> > >> >> Spencer, >> >> >> >>> On 20 Apr 2016, at 02:20, Spencer Dawkins >> wrote: >> >>> >> >>> Spencer Dawkins has entered the following ballot position for >> >>> draft-ietf-avtcore-rtp-circuit-breakers-14: Discuss >> >>> >> >>> When responding, please keep the subject line intact and reply to al= l >> >>> email addresses included in the To and CC lines. (Feel free to cut >> this >> >>> introductory paragraph, however.) >> >>> >> >>> >> >>> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> >>> for more information about IESG DISCUSS and COMMENT positions. >> >>> >> >>> >> >>> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers= / >> >>> >> >>> >> >>> >> >>> --------------------------------------------------------------------= -- >> >>> DISCUSS: >> >>> --------------------------------------------------------------------= -- >> >>> >> >>> I really like this specification, and have two questions I'd like to >> >>> understand before balloting YES ... >> >>> >> >>> I'm looking at this text: >> >>> >> >>> 4.5. Ceasing Transmission >> >>> >> >>> What it means to cease transmission depends on the application. Th= e >> >>> intention is that the application will stop sending RTP data packet= s >> >>> to a particular destination 3-tuple (transport protocol, destinatio= n >> >>> port, IP address), until the user makes an explicit attempt to >> >>> restart the call. It is important that a human user is involved in >> >>> the decision to try to restart the call, since that user will >> >>> eventually give up if the calls repeatedly trigger the circuit >> >>> breaker. This will help avoid problems with automatic redial syste= ms >> >>> from congesting the network. Accordingly, RTP flows halted by the >> >>> circuit breaker SHOULD NOT be restarted automatically unless the >> >>> ^^^^^^^^^^ >> >>> sender has received information that the congestion has dissipated, >> >>> or can reasonably be expected to have dissipated. >> >>> >> >>> and trying to understand why this is not MUST NOT. I'm trying to >> >>> reconcile this with the RFC 2119 definition of SHOULD NOT, which is >> >>> >> >>> 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean th= at >> >>> there may exist valid reasons in particular circumstances when the >> >>> particular behavior is acceptable or even useful, but the full >> >>> implications should be understood and the case carefully weighed >> >>> before implementing any behavior described with this label. >> >>> >> >>> Could you help me understand when automatic restarts might be >> >> =E2=80=9Cacceptable or even useful=E2=80=9D? >> >> >> >> As stated, automatic restarts might be acceptable or even useful if t= he >> >> sender receives information that the congestion has dissipated, or ca= n >> >> reasonably be expected to have dissipated. This is why it says =E2=80= =9CSHOULD >> NOT >> >> =E2=80=A6 unless =E2=80=9D rather than =E2=80=9CMUST NOT=E2= =80=9D. >> > >> > >> > Hi, Colin, >> > >> > On this one, I was getting tripped up on "or can be reasonably expecte= d >> to >> > have dissipated" for an automatic restart, but if this means that an >> > implementer has thought about what has to happen before an >> implementation >> > does a restart with no user involvement, I can see that. >> > >> > I was getting tied up with the subsequent text, but perhaps I shouldn'= t >> > have been. >> > >> > Thanks for the help on that one. >> >> Thanks. Happy to clarify, if you have suggestions. > > > I think the point that had my shoelaces tied together was the incongruity > of an RTP implementation itself with expectations. > > If you can come up with text that says something like "or can be > reasonably expected to have dissipated, based on the amount of time that > has elapsed since the circuit breaker has tripped", or whatever else you'= re > thinking of, that would have helped me. > > (I=E2=80=99m assuming that the only thing an implementation has to work w= ith when > it hasn't received information that congestion has dissipated, would be t= he > passage of time, but you'd know better what would be reasonable here) > > > It could also be something like a mobile device, that knows it=E2=80=99s = now in a > new location, and so might have a different path. I can give some example= s, > maybe? > That would be terrific. This is my own personality quirk (and yes, there's a recall procedure for quirky ADs), but I prefer "SHOULD unless reasons like" to bare SHOULDs, which in my experience have tended to turn up as "SHOULD unless it's inconvenient to implement" for some implementers. But beyond my own quirkiness, it's likely that in five years, most new implementations will be done by people who don't have the depth of experience with RTP that you do, so giving them examples may be pretty helpful ... > >>> Reading on, I'm wondering if this text is anticipating >> >>> >> >>> It is recognised that the RTP implementation in some systems might >> >>> not be able to determine if a call set-up request was initiated by = a >> >>> human user, or automatically by some scripted higher-level componen= t >> >>> of the system. >> >>> >> >>> but definitely want to understand what you're thinking here. >> >>> >> >>> I have a similar question about this text >> >>> >> >>> ECN-CE marked packets SHOULD be treated as if it were lost for the >> >>> purposes of congestion control, when determining the optimal media >> >>> sending rate for an RTP flow. If an RTP sender has negotiated ECN >> >>> support for an RTP session, and has successfully initiated ECN use = on >> >>> the path to the receiver [RFC6679], then ECN-CE marked packets SHOU= LD >> >>> ^^^^= ^^ >> >>> be treated as if they were lost when calculating if the congestion- >> >>> based RTP circuit breaker (Section 4.3) has been met. >> >>> >> >>> Could you help me understand why an implementation wouldn't do this? >> >> >> >> Because there are a small number of paths that misbehave when ECN >> marked >> >> packet are sent. I wanted to allow leeway for an end-point to not >> respond >> >> to ECN-CE marks on paths that spuriously mark packets, so falling bac= k >> to >> >> the behaving as-if ECN was not used. I don=E2=80=99t believe this is = harmful >> to the >> >> network, since the result will be the same as achieved by a non-ECN >> capable >> >> transport. >> > >> > >> > So, the scenario you're thinking of, is that you and I negotiated ECN >> > support for a session, I started marking packets, and a path started >> > marking packets with ECN-CE whether congestion was being encountered o= r >> > not, and I realize that's happening (by some logic not specified), so = I >> > can't trust ECN-CE. >> > >> > Do I have that right? Assuming I=E2=80=99m close ... >> >> Yes, that=E2=80=99s one possible scenario. I can=E2=80=99t find it now, = but I also seem >> to recall Apple reporting on strange experiences with ECN at a recent IE= TF. > > > Yum. > > >> > So, since I can't trust ECN-CE, I keep sending as if I wasn't getting >> > ECN-CE, and either that works (so, I did the right thing), or I manage >> to >> > cause enough congestion that it shows up in RTCP reports (so, I did th= e >> > wrong thing before, but I'll react to the less problematic RTCP report= s >> and >> > do the right thing now, and that won't be any worse than what would ha= ve >> > happened if we hadn't been able to negotiate ECN support in the first >> > place). >> > >> > Do I have that right? Again, assuming that I=E2=80=99m at least close = ... >> >> Yup. >> >> > I think what you're doing is "safe enough" that this isn't >> Discuss-worthy, >> > so I'll clear, but I wish the explanation of what's going on here was >> more >> > explicit. If you want to try to make that happen, I'm happy to chat >> further >> >> Happy to revise, if you think it would help. It=E2=80=99s better to make= this >> clear, if we can. > > > So, at the risk of making an impressively long sentence longer ... I'm > thinking of something like > > If an RTP sender has negotiated ECN support for an RTP session, and has > successfully initiated ECN use on the path to the receiver [RFC6679], the= n > ECN-CE marked packets SHOULD be treated as if they were lost when > calculating if the congestion-based RTP circuit breaker (Section 4.3) has > been met, unless the RTP implementation can determine that ECN-CE marking > on this path is not reliable. > > Is that something like what we were saying in the previous exchange? > > > Makes sense. > > Do you want me to submit an update now, or hold off for a while? > I'll defer to Magnus and Ben, but I'm going to be happy with whatever you do above. And thanks again. Spencer > > -- > Colin Perkins > https://csperkins.org/ > > > > > --94eb2c0bc490bcc66b05316b5552 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Colin,

On Tue, Apr 26, 2016 at 5:36 PM, Colin Perkins = <csp@csperkins.or= g> wrote:
Hi,

On 26 Apr 2016, at 23:28, Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com" target=3D"_blank">spencerda= wkins.ietf@gmail.com> wrote:

Hi, Colin,

On Tue, Apr 26, 2016 at 5:13 PM, C= olin Perkins=C2=A0<csp@csperkins.org>=C2= =A0wrote:
Hi,

> On 26 Apr 20= 16, at 23:08, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wro= te:
>
> Hi, Colin,
>
> On Tue, Apr 26, 2016 at 9:43= AM, Colin Perkins <csp@csperkins.org> wrote:
>
>> Spencer,
>>= ;
>>> On 20 Apr 2016, at 02:20, Spencer Dawkins <spencer.dawkins@huawei= .com> wrote:
>>>
>>> Spencer Dawkins has ent= ered the following ballot position for
>>> draft-ietf-avtcore-r= tp-circuit-breakers-14: Discuss
>>>
>>> When respon= ding, please keep the subject line intact and reply to all
>>> = email addresses included in the To and CC lines. (Feel free to cut this
= >>> introductory paragraph, however.)
>>>
>>&= gt;
>>> Please refer to=C2=A0https://www.ietf.org/iesg/statement/discuss-criteria.html>>> for more information about IESG DISCUSS and COMMENT position= s.
>>>
>>>
>>> The document, along with= other ballot positions, can be found here:=C2=A0https://datatracker.ietf.org/doc/draft-i= etf-avtcore-rtp-circuit-breakers/
>>>
>>>
&g= t;>>
>>> ------------------------------------------------= ----------------------
>>> DISCUSS:
>>> -----------= -----------------------------------------------------------
>>>=
>>> I really like this specification, and have two questions I= 'd like to
>>> understand before balloting YES ...
>&= gt;>
>>> I'm looking at this text:
>>>
&g= t;>> 4.5.=C2=A0 Ceasing Transmission
>>>
>>>= =C2=A0 What it means to cease transmission depends on the application.=C2= =A0 The
>>>=C2=A0 intention is that the application will stop s= ending RTP data packets
>>>=C2=A0 to a particular destination 3= -tuple (transport protocol, destination
>>>=C2=A0 port, IP addr= ess), until the user makes an explicit attempt to
>>>=C2=A0 res= tart the call.=C2=A0 It is important that a human user is involved in
&g= t;>>=C2=A0 the decision to try to restart the call, since that user w= ill
>>>=C2=A0 eventually give up if the calls repeatedly trigge= r the circuit
>>>=C2=A0 breaker.=C2=A0 This will help avoid pro= blems with automatic redial systems
>>>=C2=A0 from congesting t= he network.=C2=A0 Accordingly, RTP flows halted by the
>>>=C2= =A0 circuit breaker SHOULD NOT be restarted automatically unless the
>= ;>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^= ^^^^^^^
>>>=C2=A0 sender has received information that the cong= estion has dissipated,
>>>=C2=A0 or can reasonably be expected = to have dissipated.
>>>
>>> and trying to understan= d why this is not MUST NOT. I'm trying to
>>> reconcile thi= s with the RFC 2119 definition of SHOULD NOT, which is
>>>
&= gt;>> 4. SHOULD NOT=C2=A0 =C2=A0This phrase, or the phrase "NOT = RECOMMENDED" mean that
>>>=C2=A0 there may exist valid rea= sons in particular circumstances when the
>>>=C2=A0 particular = behavior is acceptable or even useful, but the full
>>>=C2=A0 i= mplications should be understood and the case carefully weighed
>>= >=C2=A0 before implementing any behavior described with this label.
&= gt;>>
>>> Could you help me understand when automatic res= tarts might be
>> =E2=80=9Cacceptable or even useful=E2=80=9D?
= >>
>> As stated, automatic restarts might be acceptable or e= ven useful if the
>> sender receives information that the congesti= on has dissipated, or can
>> reasonably be expected to have dissip= ated. This is why it says =E2=80=9CSHOULD NOT
>> =E2=80=A6 unless = <reasons>=E2=80=9D rather than =E2=80=9CMUST NOT=E2=80=9D.
>>
> Hi, Colin,
>
> On this one, I was getting tripped= up on "or can be reasonably expected to
> have dissipated"= for an automatic restart, but if this means that an
> implementer ha= s thought about what has to happen before an implementation
> does a = restart with no user involvement, I can see that.
>
> I was get= ting tied up with the subsequent text, but perhaps I shouldn't
> = have been.
>
> Thanks for the help on that one.

Thanks. Happy to clarify, if you have suggestions.
I think the point that had my shoelaces tied together was the i= ncongruity of an RTP implementation itself with expectations.=C2=A0

If you can come up with text that says something like &qu= ot;or can be reasonably expected to have dissipated, based on the amount of= time that has elapsed since the circuit breaker has tripped", or what= ever else you're thinking of, that would have helped me.

=
(I=E2=80=99m assuming that the only thing an implementation has = to work with when it hasn't received information that congestion has di= ssipated, would be the passage of time, but you'd know better what woul= d be reasonable here)

It could also be something like a mobile device, that = knows it=E2=80=99s now in a new location, and so might have a different pat= h. I can give some examples, maybe?

That would be terrific.=C2=A0

This is my own personality quirk (and yes, there's a recall procedur= e for quirky ADs), but I prefer "SHOULD unless reasons like" to b= are SHOULDs, which in my experience have tended to turn up as "SHOULD = unless it's inconvenient to implement" for some implementers.

But beyond my own quirkiness, it's likely that in = five years, most new implementations will be done by people who don't h= ave the depth of experience with RTP that you do, so giving them examples m= ay be pretty helpful ...
=C2=A0
>>> = Reading on, I'm wondering if this text is anticipating
= >>>
>>>=C2=A0 It is recognised that the RTP implementa= tion in some systems might
>>>=C2=A0 not be able to determine i= f a call set-up request was initiated by a
>>>=C2=A0 human user= , or automatically by some scripted higher-level component
>>>= =C2=A0 of the system.
>>>
>>> but definitely want t= o understand what you're thinking here.
>>>
>>>= I have a similar question about this text
>>>
>>>= =C2=A0 ECN-CE marked packets SHOULD be treated as if it were lost for the>>>=C2=A0 purposes of congestion control, when determining the o= ptimal media
>>>=C2=A0 sending rate for an RTP flow.=C2=A0 If a= n RTP sender has negotiated ECN
>>>=C2=A0 support for an RTP se= ssion, and has successfully initiated ECN use on
>>>=C2=A0 the = path to the receiver [RFC6679], then ECN-CE marked packets SHOULD
>&g= t;>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0^^^^^^
>>>=C2=A0 be treated as if they were lost w= hen calculating if the congestion-
>>>=C2=A0 based RTP circuit = breaker (Section 4.3) has been met.
>>>
>>> Could y= ou help me understand why an implementation wouldn't do this?
>&g= t;
>> Because there are a small number of paths that misbehave whe= n ECN marked
>> packet are sent. I wanted to allow leeway for an e= nd-point to not respond
>> to ECN-CE marks on paths that spuriousl= y mark packets, so falling back to
>> the behaving as-if ECN was n= ot used. I don=E2=80=99t believe this is harmful to the
>> network= , since the result will be the same as achieved by a non-ECN capable
>= ;> transport.
>
>
> So, the scenario you're thinki= ng of, is that you and I negotiated ECN
> support for a session, I st= arted marking packets, and a path started
> marking packets with ECN-= CE whether congestion was being encountered or
> not, and I realize t= hat's happening (by some logic not specified), so I
> can't t= rust ECN-CE.
>
> Do I have that right? Assuming I=E2=80=99m clo= se ...

Yes, that=E2=80=99s one possible scenario. I can= =E2=80=99t find it now, but I also seem to recall Apple reporting on strang= e experiences with ECN at a recent IETF.

Yu= m.
=C2=A0
> So, since I can't = trust ECN-CE, I keep sending as if I wasn't getting
> ECN-CE, and= either that works (so, I did the right thing), or I manage to
> caus= e enough congestion that it shows up in RTCP reports (so, I did the
>= wrong thing before, but I'll react to the less problematic RTCP report= s and
> do the right thing now, and that won't be any worse than = what would have
> happened if we hadn't been able to negotiate EC= N support in the first
> place).
>
> Do I have that right= ? Again, assuming that I=E2=80=99m at least close ...

Yup.
> I think what you're doing is "safe enough" th= at this isn't Discuss-worthy,
> so I'll clear, but I wish the= explanation of what's going on here was more
> explicit. If you = want to try to make that happen, I'm happy to chat further

Happy to revise, if you think it would help. It=E2=80=99s better to make = this clear, if we can.

So, at the risk of m= aking an impressively long sentence longer ... I'm thinking of somethin= g like

If an RTP sender has negotiated ECN=C2=A0su= pport for an RTP session, and has successfully initiated ECN use on=C2=A0th= e path to the receiver [RFC6679], then ECN-CE marked packets SHOULD=C2=A0be= treated as if they were lost when calculating if the congestion-based RTP = circuit breaker (Section 4.3) has been met, unless the RTP implementation c= an determine that ECN-CE marking on this path is not reliable.

Is that something like what we were saying in the previous= exchange?

<= /div>Makes sense.

Do you want me to submit an update now, or hold off for = a while?
<= br>
I'll defer to Magnus and Ben, but I'm going to be hap= py with whatever you do above.

And thanks again.

Spencer
=C2=A0

--=C2= =A0
Colin Perkins

<= /span>



--94eb2c0bc490bcc66b05316b5552-- From nobody Wed Apr 27 09:21:00 2016 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 948C712D506; Wed, 27 Apr 2016 09:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUvQkjJRCzxE; Wed, 27 Apr 2016 09:20:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9BF12D4FD; Wed, 27 Apr 2016 09:20:53 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3RGKhVB093481 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 Apr 2016 11:20:44 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Spencer Dawkins at IETF" , "Colin Perkins" Date: Wed, 27 Apr 2016 11:20:43 -0500 Message-ID: <732B5177-88F6-4777-9987-95540094C485@nostrum.com> In-Reply-To: References: <20160420012041.31613.87215.idtracker@ietfa.amsl.com> <78034C12-57A3-4680-8B86-5C8F22E8ED19@csperkins.org> <8AFC0439-D9C8-458C-B413-8610AC187A37@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: avtcore-chairs@ietf.org, Magnus Westerlund , draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, avt@ietf.org, "Spencer Dawkins@IETF" , The IESG Subject: Re: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 16:20:53 -0000 On 26 Apr 2016, at 18:05, Spencer Dawkins at IETF wrote: > Makes sense. > >> >> Do you want me to submit an update now, or hold off for a while? > > > > I'll defer to Magnus and Ben, but I'm going to be happy with whatever > you do above. Colin: Please submit the update as soon as you can. (But warn me if the update is likely to happen in the last few days before the telechat--i.e. later than this week.) Thanks! Ben. From nobody Wed Apr 27 23:04:01 2016 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 319FC12B049; Wed, 27 Apr 2016 23:04:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160428060400.25245.64659.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 23:04:00 -0700 Archived-At: Cc: avtcore-chairs@ietf.org, avt@ietf.org Subject: [AVTCORE] avtcore - New Meeting Session Request for IETF 96 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 06:04:00 -0000 A new meeting session request has just been submitted by Roni Even, a Chair of the avtcore working group. --------------------------------------------------------- Working Group Name: Audio/Video Transport Core Maintenance Area Name: Applications and Real-Time Area Session Requester: Roni Even Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: tsvwg rmcat xrblock rtcweb payload mmusic dispatch avtext netvc perc Second Priority: tram sipcore lmap stir Third Priority: tls Special Requests: --------------------------------------------------------- From nobody Sat Apr 30 15:01:49 2016 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7B12D10E; Sat, 30 Apr 2016 15:01:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160430220146.31163.26775.idtracker@ietfa.amsl.com> Date: Sat, 30 Apr 2016 15:01:46 -0700 Archived-At: Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-15.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 22:01:46 -0000 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 of the IETF. Title : Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions Authors : Colin Perkins Varun Singh Filename : draft-ietf-avtcore-rtp-circuit-breakers-15.txt Pages : 24 Date : 2016-04-30 Abstract: The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss, and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure, stopping RTP flows from using excessive resources, and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data, to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. Future RTP congestion control specifications will be expected to operate within the constraints defined by these circuit breakers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 30 16:02:56 2016 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 0505B12D1A1; Sat, 30 Apr 2016 16:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrkIlaD4z2VW; Sat, 30 Apr 2016 16:02:46 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA3412B034; Sat, 30 Apr 2016 16:02:46 -0700 (PDT) Received: from [81.187.2.149] (port=35594 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1awcyx-0003zu-0D; Sat, 30 Apr 2016 23:03:24 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <732B5177-88F6-4777-9987-95540094C485@nostrum.com> Date: Sat, 30 Apr 2016 23:03:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160420012041.31613.87215.idtracker@ietfa.amsl.com> <78034C12-57A3-4680-8B86-5C8F22E8ED19@csperkins.org> <8AFC0439-D9C8-458C-B413-8610AC187A37@csperkins.org> <732B5177-88F6-4777-9987-95540094C485@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: avtcore-chairs@ietf.org, Magnus Westerlund , draft-ietf-avtcore-rtp-circuit-breakers@ietf.org, avt@ietf.org, Spencer Dawkins at IETF , The IESG Subject: Re: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-circuit-breakers-14: (with DISCUSS) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 23:02:50 -0000 > On 27 Apr 2016, at 17:20, Ben Campbell wrote: >=20 > On 26 Apr 2016, at 18:05, Spencer Dawkins at IETF wrote: >=20 >> Makes sense. >>=20 >>>=20 >>> Do you want me to submit an update now, or hold off for a while? >>=20 >>=20 >> I'll defer to Magnus and Ben, but I'm going to be happy with whatever = you do above. >=20 > Colin: Please submit the update as soon as you can. (But warn me if = the update is likely to happen in the last few days before the = telechat=E2=80=94i.e. later than this week.) Done. Changes are as follows: In Section 4.5, clarify the end of the first paragraph, about when an = implementation might reasonably expect congestion to have dissipated. In Section 7, clarify why ECN-CE marked packets =E2=80=9CSHOULD=E2=80=9D = be treated as lost, rather than "MUST" be treated as lost, due to the = unreliability of ECN marking on some paths. Cheers, Colin --=20 Colin Perkins https://csperkins.org/