From nobody Tue Apr 1 15:14:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350751A0A3E for ; Tue, 1 Apr 2014 15:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Y_9CTD6tUcVF for ; Tue, 1 Apr 2014 15:14:31 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4217E1A0A29 for ; Tue, 1 Apr 2014 15:14:31 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so10472267pbb.25 for ; Tue, 01 Apr 2014 15:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=CN3n1KmEn0B5GJgJa+YO01zAQeiQfPXIoYd5HxCVEr8=; b=mUAL2ARphaGkPFp9Jzt38kgM3fElgRY4gUXI0LVYfY3lgC/43hHuftX5qQ+0yqD05X BG0KzkfMQvchFeUV9keFRIwsYyl07ppi3sNqItVHyRNMmTQffM5K2OAgc4snoUBM+lMs ANo5YSDgSoPTGG0M+HvPf8umk6768QDFsJgLBketyICPM1+B3TuHo9NdTTxROrmiPLcg 0YlUGFsJz0ek/1bOmVo6A/YCY4p1HrmgVQLwfGi+d53MUL8HjHB5iqi5RfkN8xsTzvQS LmPR8EWt7hueBYC6rrYgWcHdWgW9H4gajY6YNiggUoclKO/2MCHowRjyPMhwRtMK2l3R 51tA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=indolering.com; s=google; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=CN3n1KmEn0B5GJgJa+YO01zAQeiQfPXIoYd5HxCVEr8=; b=hRsAmC5JnsAZ2kPA5bw9E79CRy9O172AFCGw5TSr/2TojNtpwpl81BTPOY+/zLnsYu QvYSxfW7qwuMAxLcdluJjca+b8mUN4t0d9rSX0YH2XdtfUMzgxxpLZ1KU9Fz4AGZfWH3 l0JYqitfYk+MFYx1/YN4gmeVokbPveEA0Ve0k= X-Received: by 10.66.176.143 with SMTP id ci15mr34151931pac.35.1396390467673; Tue, 01 Apr 2014 15:14:27 -0700 (PDT) MIME-Version: 1.0 Sender: indolering@gmail.com Received: by 10.70.64.194 with HTTP; Tue, 1 Apr 2014 15:13:47 -0700 (PDT) From: Zach Lym Date: Tue, 1 Apr 2014 15:13:47 -0700 X-Google-Sender-Auth: rr614pzkz7oBvwlfMmKFFyFJxM4 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7bd75160cb24c904f6027dd7 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rwpTgiL2ErCNijkbOqQyE0zZw48 Subject: [rtcweb] JS friendly codec compromise? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 22:14:34 -0000 --047d7bd75160cb24c904f6027dd7 Content-Type: text/plain; charset=ISO-8859-1 After reviewing the discussion on the codec mandate (particularly h.261) I was reminded of ORBX.js. While I have my reservations regarding ORBX, the approach (a JS friendly codec) would be more backwards compatible than h.261 and give better performance. If a "submarine" patent surfaces the codec can be altered and clients can be "updated" on the next page refresh. I should stress the "JS friendly" aspect of the codec, "VP8 like H.264 does not parallelize as well via WebGL as ORBX does, so a "JS shim" is not going to compete." - Brendan Eich Thank you, -Zach Lym P.S. For those who are not familiar with ORBX, it is a codec which is decoded in JS and transmitted over websockets. Their timeline ( http://render.otoy.com/newsblog/?p=317) mentions a FOSS encoder sometime this summer, funding for a pure WebGL/CL encoder, and fee-free AMI's for video transcoding. --047d7bd75160cb24c904f6027dd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
After reviewing the discussion on the codec mandate (= particularly h.261) I was reminded of ORBX.js.

While I have my reser= vations regarding ORBX, the approach (a JS friendly codec) would be more ba= ckwards compatible than h.261 and give better performance.  If a "= ;submarine" patent surfaces the codec can be altered and clients can b= e "updated" on the next page refresh.

I should stress the "JS friendly" aspect of the codec, "= VP8 like H.264 does not parallelize as well via WebGL as ORBX does, so a &l= dquo;JS shim” is not going to compete."  - Brendan Eich
=
Thank you,
-Zach Lym
P.S. For those who are not familiar with ORBX, it is a c= odec which is decoded in JS and transmitted over websockets.  Their timeline=20 (http://render.otoy.co= m/newsblog/?p=3D317) mentions a FOSS encoder=20 sometime this summer, funding for a pure WebGL/CL encoder, and fee-free=20 AMI's for video transcoding. 
--047d7bd75160cb24c904f6027dd7-- From nobody Tue Apr 1 15:25:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53A71A0A0E for ; Tue, 1 Apr 2014 15:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ldRR22tWR16f for ; Tue, 1 Apr 2014 15:25:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 826411A08DE for ; Tue, 1 Apr 2014 15:25:12 -0700 (PDT) Received: from netb ([89.204.135.154]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LeeNW-1WpXNX0Kh4-00qSzm; Wed, 02 Apr 2014 00:25:06 +0200 From: Bjoern Hoehrmann To: Zach Lym Date: Wed, 02 Apr 2014 00:25:05 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:nV04ADS/i23F01xEF6XUntLBy969ukzhZfs8nqXO9NL9UepJ7+W PtiKdj0mWa36IB73FvYI1UrEAni2V2UR+g7okVHliZLvVusARXUCk2sOAmRAm3G9LtRCaF7 lkoBMjwoE7s7l/MRinx9QoBTp1Uu/qsWzuVnpPWJ1NV4tI4cs0JwF4OQoFXOitGmkYDWsNQ Y8sslkC7I3X2+MFbqJj9w== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1wR0xOywqP9mBpjm27GlrXau0qc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JS friendly codec compromise? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 22:25:14 -0000 * Zach Lym wrote: >While I have my reservations regarding ORBX, the approach (a JS friendly >codec) would be more backwards compatible than h.261 and give better >performance. If a "submarine" patent surfaces the codec can be altered and >clients can be "updated" on the next page refresh. Which aspect of "performance" do you mean here, and could you share some references to support the claim? References to a legal analysis would be helpful aswell. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From nobody Tue Apr 1 16:16:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223F51A0004 for ; Tue, 1 Apr 2014 16:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 6CLXTH1EmH4i for ; Tue, 1 Apr 2014 16:16:40 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id EFBE91A0002 for ; Tue, 1 Apr 2014 16:16:39 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id uo5so10618497pbc.10 for ; Tue, 01 Apr 2014 16:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=RPfsTGtMDjq2zkkFe38TNg7eRw1JxT2dtR2KDpNpDMk=; b=E8H4ylnMArpc6XIaICegcdeKXB0miobPfVnhxoPeghqQYuOGtV7WdqLT807ZkdOirE YF8NxZxJGskfXBtafK7S1hnfimxdlzKya6+NBu9amWFjFff/eM9pzUTVvmtRRKBgiqCB sHzEwbyJf3CBOCB9EfwpzUN92hRhBBhHo3Eo6/z0HsKzxX/db6wX57r+B8dkTIWtrFDY YZOfHSwnpCvBzGHPUdEgXlEf4lULjMa7iqqUNJcTnnuqjYDBJ5oWSqlb4vBV3m0C8CXN xavB5x1G/jwbrrWvkULzkP4x0lCeBjNXqBFWRn09y52zCmWuXFXXACLgyWmZ5DKwDOh8 p17Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=indolering.com; s=google; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=RPfsTGtMDjq2zkkFe38TNg7eRw1JxT2dtR2KDpNpDMk=; b=Mj1nCrcv1N3EzpKsD4VaxoBjmmWiX6Hf3ac4wHy9OpMCpTcLy3C6GDvcDck7y+Npgj /reoVtE1AYNy8UEgyrFDh7esea3r7Apeb+78V3dL37kvduqsVcj/y1V0C/r1Ms626roI z4lSr2vvneHvLPjF6dXFA1KczGGAoLTKZ40KI= X-Received: by 10.67.1.202 with SMTP id bi10mr34152176pad.68.1396394196401; Tue, 01 Apr 2014 16:16:36 -0700 (PDT) Received: from mba-4.local (71-212-116-249.tukw.qwest.net. [71.212.116.249]) by mx.google.com with ESMTPSA id qw8sm152368pbb.27.2014.04.01.16.16.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 16:16:33 -0700 (PDT) Sender: Zach Lym Message-ID: <533B48CF.1030705@indolering.com> Date: Tue, 01 Apr 2014 16:16:31 -0700 From: Zach Lym User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AIQgFMTQC1FXcCOcJrLO7LeXLFvCQV1B9" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/k8blt50lLM3Y1cYwlc_pV_balZU Subject: Re: [rtcweb] JS friendly codec compromise? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: zachlym@indolering.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 23:16:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AIQgFMTQC1FXcCOcJrLO7LeXLFvCQV1B9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Which aspect of "performance" do you mean here, and could you share som= e > references to support the claim? References to a legal analysis would b= e > helpful aswell. ORBX claims performance on par with H.264. We all know that's probably marketing hype, but it's hard to imagine not being able to outperform H.261. Even if the working group chose to hack together a custom codec which is worse than H.261, an upgradeable client means we can update the spec as performance improvements are made by the browser vendors. I know of no formal legal analysis of ORBX, but being able to update the decoder means that any submarine patent would have to knock out every known video encoding technique. Software patents are generally simple to work around, codecs may be more so but Google's due-diligence team thought that VP8 managed to pull it off. They paid shut-up money to make the FUD go away but if you are really that concerned about potential patents we could partner with Daala. Mozilla was smart with Opus and patented their "new methods" so they could force cross-licensing deals with the trolls. They are doing the same with Daala, so the FUD around a submarine threat against Daala is no better or worse than with H.264. I don't know how well Daala's encoding could be adapted to WebCL, but we could include some patented methods of the codec. Come to think of it, the Daala group is looking to recreate the development process they had for Opus. Skype and Mumble, both VOIP clients, were able to push updates to client software silently, providing the Opus team with a live test-bed which they used to benchmark their various tweaks. They are also actively seeking "killer features" for the codec. H.26X designed to compress movies, not low-motion talking heads and screencasts: https://www.youtube.com/watch?v=3Du3Yc5Hn9bhQ --AIQgFMTQC1FXcCOcJrLO7LeXLFvCQV1B9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTO0jTAAoJEDqf4tbaGwDsbLEIALBW3UOxHtgwODbBfIbJqkoC 8VQppRl+Qs3zuh1HzXq6zV7Tm+k845IX7bDS+3uMdMyFTyJ33FUySX1y1A2HvQ4v ZNa0N5ST95Vi2SbPxDvPUytx2DUDq/AhwUymDU5t02bkGCICcaG6mBP8eGfyTE25 hsOCwNwHkK3dKZqr0aubW1I+OYMXfTSIDN7rykQ+3xTMdLDU3RQ+aJCdZY9N2W/l VWh5b/+98n5UGV+0SJ6c9oPX54IuiO1BNcP1xiCyKQl+C4n9TNIdIym5ITBMHZiF ukPi1Gjtb5CeRo9XB7/FYTUqTxLpe6g17HiVh07IsTEBDYmyDChyNd8TuTEyMZY= =LGnw -----END PGP SIGNATURE----- --AIQgFMTQC1FXcCOcJrLO7LeXLFvCQV1B9-- From nobody Tue Apr 1 16:40:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269481A0020 for ; Tue, 1 Apr 2014 16:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 dLqCkyVMa74l for ; Tue, 1 Apr 2014 16:40:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 79D631A0011 for ; Tue, 1 Apr 2014 16:40:17 -0700 (PDT) Received: from netb ([89.204.135.154]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LrqNe-1XBZIt3SZS-013fPL; Wed, 02 Apr 2014 01:40:12 +0200 From: Bjoern Hoehrmann To: zachlym@indolering.com Date: Wed, 02 Apr 2014 01:40:10 +0200 Message-ID: References: <533B48CF.1030705@indolering.com> In-Reply-To: <533B48CF.1030705@indolering.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:5Uso8TG/HB46Ls42GSmbCv5KhkOiApP0lUy7lhyfgcnpdhYbfMH U079vYGSMbe/AgJpHYMJRWVSPRhe420vbI0HzaDry5qg+qetg4JUGgiCeSTujnOVIIH0b9d 0sR1ZpRa/J688f31eUZtwTi4rJZgvAbt7FmScQHSRo1aqto/I4R/OzYZQyB2pD4/fPmkEzc yAiB/ZNaTTPN6pBEOB+3A== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XSBgbPhbcN9jXS9eJOg-uvraUog Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JS friendly codec compromise? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 23:40:19 -0000 * Zach Lym wrote: >> Which aspect of "performance" do you mean here, and could you share some >> references to support the claim? References to a legal analysis would be >> helpful aswell. > >ORBX claims performance on par with H.264. We all know that's probably >marketing hype, but it's hard to imagine not being able to outperform >H.261. Even if the working group chose to hack together a custom codec >which is worse than H.261, an upgradeable client means we can update the >spec as performance improvements are made by the browser vendors. I meant performance characteristics like, say, battery life per second of decoded video at H.261 resolutions and GPRS bitrates, to throw in a couple of metrics. Or something like "ORBX needs more CPU but produces smaller files at the same quality level". Maybe ORBX is cheap to decode but expensive to encode, while with H.261 both is cheap? Comparisons along those lines supported by references would be useful. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From nobody Tue Apr 1 18:40:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9011A005F for ; Tue, 1 Apr 2014 18:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 qjwEXrIm6WSL for ; Tue, 1 Apr 2014 18:40:09 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 20EF91A005E for ; Tue, 1 Apr 2014 18:40:09 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id up15so10723077pbc.20 for ; Tue, 01 Apr 2014 18:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=gHwHlWtPI7ESQno5WWWZynKXkbVosbHlTXo+4okSlsk=; b=s81FDmeAIMzScp0RcowLHTl5BW9iqXi1Vdi733vBsYxtsLaDFAdwD1jy7+GtBlNrAd xY/eRAUHuovAW3nGJoc11879/3y3EGeLMlpxnVMsy7CHPv9+vljiITANRZmbBrGqlloB CCXfiHBOFEqnbKwkpt003rFBK77T64stmYCgebcC6pCSi4Mfimi3MpDG2Bjih5X/29aH r56/Ek+j7hxR6i5E6OM5UJEXMUkBzgnW23RIrj7sZINxYhEUEagCpAiFdTjpB+1VD0pw b+ftYqRStTRy3TMVJ20sFNvUFCQ7R2fXhXfppoPoGAISi+FwckkwtXs6m8Vugs0GtvBV THcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=indolering.com; s=google; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=gHwHlWtPI7ESQno5WWWZynKXkbVosbHlTXo+4okSlsk=; b=VFnn2r4rVXtUo7R6c1L/hlO9+NAoTktMlYXwmlQKue3lxdLuH8Nkr7WwPbORbTD8B4 ij1OyHHT3oFkQWWbzQHJo0grRap48mzKV3EQZI/vE7AgSFmSqYff/q7Opi2HfjX/wVam u8DfMVqNK00HFfu07YI6yubbESZjdKotI0w1I= X-Received: by 10.69.2.2 with SMTP id bk2mr34442225pbd.75.1396402805496; Tue, 01 Apr 2014 18:40:05 -0700 (PDT) Received: from mba-4.local (71-212-116-249.tukw.qwest.net. [71.212.116.249]) by mx.google.com with ESMTPSA id st4sm1735811pab.34.2014.04.01.18.40.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 18:40:03 -0700 (PDT) Sender: Zach Lym Message-ID: <533B6A6E.7070208@indolering.com> Date: Tue, 01 Apr 2014 18:39:58 -0700 From: Zach Lym User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <533B48CF.1030705@indolering.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hsw8K3Q7B2CPBvINm65I60jI22DPOWi9o" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bwmgsZsTHOaukW__HEJ0YcpzhVE Cc: brendan@mozilla.org Subject: Re: [rtcweb] JS friendly codec compromise? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: zachlym@indolering.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 01:40:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hsw8K3Q7B2CPBvINm65I60jI22DPOWi9o Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I cannot find the exact analysis you appear to be looking for. You can=20 boot up some AMI instances and check for yourself, if you like. =20 Brendan Eich apparently saw a demo of ORBX streaming to an iPhone 4s in=20 Safari. There is some discussion of performance on this thread: https://brendaneich.com/2013/12/orbx-js-and-related-news/#div-comment-176= 27 And there is a whitepaper detailing ORBX2 here (although they have=20 already moved on to ORBX3): http://aws.otoy.com/docs/ORBX2_Whitepaper.pdf However, the larger point Brendan Eich makes, and what I am trying to=20 convey here, is that eschewing a fixed bit-stream format in favor of a=20 living standard would make such comparisons moot. Clients could even=20 send the JS needed to decode their custom format to each other. The=20 web is based on specifying interfaces, think of this as an interface=20 for codecs. The only reason we are having this argument is because H.264 is etched=20 into custom hardware. The above stats show performance comparable with=20 H.264 and they chalk it up to their ability to do everything on the=20 GPU/WebGL, which you can't do with H.264 or VP8. As long as we can=20 offload to the GPU efficiently, there is no argument to be had. On Tue Apr 1 16:40:10 2014, Bjoern Hoehrmann wrote: > * Zach Lym wrote: >>> Which aspect of "performance" do you mean here, and could you share s= ome >>> references to support the claim? References to a legal analysis would= be >>> helpful aswell. >> >> ORBX claims performance on par with H.264. We all know that's probabl= y >> marketing hype, but it's hard to imagine not being able to outperform >> H.261. Even if the working group chose to hack together a custom code= c >> which is worse than H.261, an upgradeable client means we can update t= he >> spec as performance improvements are made by the browser vendors. > > I meant performance characteristics like, say, battery life per second > of decoded video at H.261 resolutions and GPRS bitrates, to throw in a > couple of metrics. Or something like "ORBX needs more CPU but produces > smaller files at the same quality level". Maybe ORBX is cheap to decode= > but expensive to encode, while with H.261 both is cheap? Comparisons > along those lines supported by references would be useful. --hsw8K3Q7B2CPBvINm65I60jI22DPOWi9o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTO2pyAAoJEDqf4tbaGwDs3+QIAKR8c6mK3NhsyGIozeDXddyt +m21XauQ5rbEBnGpkWEYUVqX673VHH3eItjInLZYrluFepWWAgdRLvAzZ1PWUK2M RmjytMu4B6PrJllq5Dq6CNLRYvsXVUeu/s3GshwZZSmWeq/7uDFgI6+JWnQF0ONK SuGYmzIHRL+p3Qy3C5ZWflnVGCLLctrpgItut7ajZm/c/OaTHIjQy6h3gsjzf2d/ SC3MLyl93doiqwb4leRPFk/0B5mvE4Z1vEbdXkW/wC9NZlSzznR8b7ZyoVbnzH09 CdgDsJJ5QK+RS2qh/KbG46L1Z0s6t7HhQpwLyPzPlbdpkLpw0AM2QcKX66pOdjI= =Kocn -----END PGP SIGNATURE----- --hsw8K3Q7B2CPBvINm65I60jI22DPOWi9o-- From nobody Wed Apr 2 09:24:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C57E1A0254 for ; Wed, 2 Apr 2014 09:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 0g6Z5-FmOpRb for ; Wed, 2 Apr 2014 09:24:26 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD091A02CC for ; Wed, 2 Apr 2014 09:24:26 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so494734wgg.21 for ; Wed, 02 Apr 2014 09:24:22 -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:content-type; bh=xtVQe8AJoTQyxF8WV6s2+MAhibQ47toRb98drxVCuH8=; b=nXPnXc5f4vpw/WSnoUCLilFIGdNFhxqJBE9QNx2aikoVTLifos37exvQ1OG0ojqi5H Eg9jlRR2ilWTPCKdwsDiqNPg1QwWuAv74IHOpc+6D2LD5+9J6p2KRT/4hOgWrsXU9yOa Jt+maCrS5QDkC2yqvDiqvnppHhVx1YnhGbSjX5Auud8Xqg51qGjKC3RqNRKvllV03RVc nUhBx5GnXwSv3j0dHf9csbbiCeOJIUShgoP4emS3H2yI0qRpXj7lnwGRdCsHuSbPE4tC hJWgdX9WLwqQhX3LVIfV6BIvip2BUt1uLZ2cYLBS9oDHlhl1mug+xoShNbPR6LQlC1s8 8qsg== MIME-Version: 1.0 X-Received: by 10.194.192.132 with SMTP id hg4mr2292379wjc.28.1396455862318; Wed, 02 Apr 2014 09:24:22 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Wed, 2 Apr 2014 09:24:22 -0700 (PDT) In-Reply-To: <533B6A6E.7070208@indolering.com> References: <533B48CF.1030705@indolering.com> <533B6A6E.7070208@indolering.com> Date: Wed, 2 Apr 2014 09:24:22 -0700 Message-ID: From: Martin Thomson To: zachlym@indolering.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Oz1nva_0uVrifl6lrX_HhAsew5U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JS friendly codec compromise? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:24:31 -0000 On 1 April 2014 18:39, Zach Lym wrote: > However, the larger point Brendan Eich makes, and what I am trying to > convey here, is that eschewing a fixed bit-stream format in favor of a > living standard would make such comparisons moot. Clients could even > send the JS needed to decode their custom format to each other. The > web is based on specifying interfaces, think of this as an interface > for codecs. Unfortunately, a JS-implemented codec does not play well with isolated sessions, otherwise we can't establish true private calling. In that context, we still need something that the browser can control. Perhaps with the right sandbox it could work, but I think that it's a little too early to be considering that option. Soon, perhaps. From nobody Wed Apr 2 09:32:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5791A01FB for ; Wed, 2 Apr 2014 09:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 49u_oGJfENA1 for ; Wed, 2 Apr 2014 09:32:40 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECD81A01C8 for ; Wed, 2 Apr 2014 09:32:40 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so433042pbb.19 for ; Wed, 02 Apr 2014 09:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=yw7foIjGlvugptBceu1EvjLkfYLLckv72gNhpNKz8q8=; b=hQSXsZGH8TseCJB3/ZXE1/RhSQXEKy/U8V9B3Llhq1acu0AG1fyIw7nVp1nsX9oD9l lOS4InMkSC6Vo7U55Ypol6+UudKEm2G4z6JPhFs4jHem2vaYUgyHWTGeQ60nwoi0hxvT raoTWN8y9oTz1mUfq20rddiCUZWdk8jte0wnHMmJJkHZq5u0sqLOce1dD4gBjoLKrBkE seJVLlraZZA4f7GkQMz1ODMqY1/PglFmRY6bDEc6qmKkYtaEEQX+k9fEjSLbOcPSInyD M5m8ltHHql6gs69YyW0Ul1lQMjE8Ee3HgmnyHtAk7X9UtJ9gqCvZPdr4mX7IjcxBZljz u8hQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=indolering.com; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=yw7foIjGlvugptBceu1EvjLkfYLLckv72gNhpNKz8q8=; b=lDGxKTEvsTaFciUt1+jGNV7MQ+NkwIm3snj95fO+9s8q7HrIy7Jx5vQlSISR7HfIp0 TY0M5rraVYB8wGuFqwV4VatGq5CaAHIFw/FD62YATppxgoLwklFy8iVIUH/X9/nyBpMk rxS5hnBGe7VwUMrekj/hhrWmk5uVmmehV3Jag= MIME-Version: 1.0 X-Received: by 10.66.164.135 with SMTP id yq7mr1177451pab.126.1396456356727; Wed, 02 Apr 2014 09:32:36 -0700 (PDT) Sender: indolering@gmail.com Received: by 10.70.64.194 with HTTP; Wed, 2 Apr 2014 09:32:36 -0700 (PDT) In-Reply-To: References: <533B48CF.1030705@indolering.com> <533B6A6E.7070208@indolering.com> Date: Wed, 2 Apr 2014 09:32:36 -0700 X-Google-Sender-Auth: bx0XR37HJLPcHGtqsTsgOzrq2Ks Message-ID: From: Zach Lym To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7b6d7fb416558904f611d527 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dbkZxbUva-oVshlbfjzzQbHO8KU Subject: Re: [rtcweb] JS friendly codec compromise? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:32:45 -0000 --047d7b6d7fb416558904f611d527 Content-Type: text/plain; charset=ISO-8859-1 My apologies, I am rather ignorant of the gritty implementation details. Maybe ORBX.js will be of some use, I guess we will see what the summer brings. I'll get back to my corner of expertise, -Zach On Wednesday, April 2, 2014, Martin Thomson wrote: > On 1 April 2014 18:39, Zach Lym > > wrote: > > However, the larger point Brendan Eich makes, and what I am trying to > > convey here, is that eschewing a fixed bit-stream format in favor of a > > living standard would make such comparisons moot. Clients could even > > send the JS needed to decode their custom format to each other. The > > web is based on specifying interfaces, think of this as an interface > > for codecs. > > Unfortunately, a JS-implemented codec does not play well with isolated > sessions, otherwise we can't establish true private calling. In that > context, we still need something that the browser can control. > Perhaps with the right sandbox it could work, but I think that it's a > little too early to be considering that option. Soon, perhaps. > -- Thank you, -Zach Lym --047d7b6d7fb416558904f611d527 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My apologies, I am rather ignorant of the gritty implementation details. = =A0

Maybe ORBX.js will be of some use, I guess we will = see what the summer brings.

I'll get back to my corner of = expertise,
-Zach
On Wednesday, April 2, 2014, Martin Thomson <= martin.thomson@gmail.com>= ; wrote:
On 1 April 2014 18:39, Zach Lym <zachlym@indolerin= g.com> wrote:
> However, the larger point Brendan Eich makes, and what I am trying to<= br> > convey here, is that eschewing a fixed bit-stream format in favor of a=
> living standard would make such comparisons moot. =A0Clients could eve= n
> send the JS needed to decode their custom format to each other. =A0The=
> web is based on specifying interfaces, think of this as an interface > for codecs.

Unfortunately, a JS-implemented codec does not play well with isolated
sessions, otherwise we can't establish true private calling. =A0In that=
context, we still need something that the browser can control.
Perhaps with the right sandbox it could work, but I think that it's a little too early to be considering that option. =A0Soon, perhaps.


--
Thank you,
-Zach Lym

--047d7b6d7fb416558904f611d527-- From nobody Thu Apr 3 08:40:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666C61A020A for ; Thu, 3 Apr 2014 08:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 I7X6E3czH6PO for ; Thu, 3 Apr 2014 08:40:28 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id A106B1A01FA for ; Thu, 3 Apr 2014 08:40:23 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404031740154007; Thu, 03 Apr 2014 17:40:15 +0200 From: "Karl Stahl" To: "'Harald Alvestrand'" , , "'Magnus Westerlund'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> <530C56CD.3010003@ericsson.com> <025d01cf3e9a$f4267340$dc7359c0$@stahl@intertex.se> <532716F1.4030109@alvestrand.no> In-Reply-To: <532716F1.4030109@alvestrand.no> Date: Thu, 3 Apr 2014 17:40:16 +0200 Message-ID: <009801cf4f53$02c1d110$08457330$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01CF4F63.C64AA110" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9B9vxwJd+obSIiS4eQo5UFm/Y58ANRNjvw Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-EnI0NbQ_PIiFd1_yYHrUR4iT-I Subject: Re: [rtcweb] [tram] Payload Types assignments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:40:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0099_01CF4F63.C64AA110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald,=20 =20 I think my intention was misunderstood. It was not to change the = DTLS/SCTP structure or format of the data channel (It was to insert the traffic bandwidth and type information between the UDP and DTLS headers.). =20 However, having dug deeper into the data channel (and also found the quality/priority obstacles introduced by SCTP with the p2p file transfer (see next email), a better way to introduce the traffic info would be to = use a new DTLS ContentType (e.g. 24 instead of current 23) where the content would be the unencrypted traffic info (preferable the same as in the RTP header extension[1]) followed by the SCTP as it is today (where it today comes directly in the DTLS as the only content).: =20 TODAY: Content Type: 23 (1 byte) content type 23 means =93application data=94 DTLS version: 0xfeff (2 byte) Epoch: 0001 (2 byte) Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 byte Encrypted application data: ...... =3D the SCTP =20 SUGGESTION WITH ADDED TRAFFIC INFO FOR LOWER LEVELS:=20 Content Type: 24 (1 byte) content type 24 meaning =93application data = preceded by traffic info=94 DTLS version: 0xfeff (2 byte) Epoch: 0001 (2 byte) Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 byte: length of the encrypted application data = after the new header extension TRAFFIC INFO, Same as suggested for the RTP Header extension:=20 Encrypted application data: ...... ...... =3D the SCTP unchanged =20 Shouldn=92t this be doable? (As you see from next email, this kind of information is also required = to make the data channel work, separating prioritized data chunks from a = file transfer data channel that must NOT be prioritized.) =20 /Karl =20 =20 =20 =20 Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Harald Alvestrand Skickat: den 17 mars 2014 16:38 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] [tram] Payload Types assignments =20 On 03/13/2014 10:02 AM, Karl Stahl wrote: For the =93mission to bring quality to real-time traffic over our best = effort Internet=94 I have started http://www.ietf.org/mail-archive/web/tram/current/msg00331.html [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2] =20 Hi Magnus, =20 With the response just sent to P=E5l http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, = skipping all the QoS methods and functions that really does not belong here when creating an =93Interface to QoS=94, I only see the suggestion of =93data = channel information=94, i.e. also marking each data channel packet with traffic bandwidth and type information to be relevant and interesting. I = checked with one of our developers and I think the same traffic information as = for RTP can be transferred in data channel packets as follows: =20 The RTP header has the following format (RFC 3550): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | RFC5285 header extension ... | | 2 bytes Max Bandwidth | 2 bytes Traffic Type | | .... | RTP Payload (often encrypted) =20 A Data Channel header could have the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Channel Magic Cookie | (sequence number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | RFC5285 header extension ... | | 2 bytes Max Bandwidth | 2 bytes Traffic Type | | .... | DTLS Header 13 bytes SCTP =20 The RFC5285 header extension is not in a fixed position in any of these cases, but still trivial to find (especially when in a TURN flow). This could be introduced in http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-5=20 by making room for these bytes after the UDP header, but before the DTLS header. =20 What do you think? No. We've chosen to make Data Channel a protocol within DTLS, and not use = any unencrypted headers for it. Neither does the data channel have any = concept resembling SSRC, CSRC or timestamp. Changing to an RTP-based format such = as the one you propose would be a drastic revision of the spec. There's no reason to believe such a revision at this time has any = traction in the WG. ------=_NextPart_000_0099_01CF4F63.C64AA110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ha= rald,

 

I = think my intention was misunderstood. It was not to change the DTLS/SCTP = structure or format of the data channel (It was to insert the = tr= affic bandwidth and type information between the UDP and DTLS = headers.).

 

Ho= wever, having dug deeper into the data channel (and also found the = quality/priority obstacles introduced by SCTP with the p2p file transfer = (see next email), a better way to introduce the traffic info would be to = use a new DTLS ContentType (e.g. 24 instead of current 23) where the = content would be the unencrypted traffic info (preferable the same as in = the RTP header extension[1]) followed by the SCTP as it is today (where = it today comes directly in the DTLS as the only = content).:

 

TO= DAY:

Content Type: 23 (1 byte) content type 23 = means “application data”

DTLS version:  = 0xfeff (2 byte)

Epoch: 0001 (2 byte)

Sequence = number (e.g. 00 00 00 00 00 01) 6 byte<= /span>

Length (e.g. 01 c0) 2 byte<= /span>

Encrypted application data: ...... = =3D the = SCTP<= /span>

 <= /o:p>

S= UGGESTION WITH ADDED TRAFFIC INFO FOR LOWER LEVELS:

Content = Type: 24 (1 byte) = content type 24 meaning “application data preceded by traffic = info”<= /span>

DTLS = version:  0xfeff (2 byte)<= /span>

Epoch: = 0001 (2 byte)<= /span>

Sequence number (e.g. 00 00 00 00 00 01) 6 = byte<= /span>

Length (e.g. 01 c0) 2 byte: length of the = encrypted application data after the new header extension<= /span>

TRAFFIC = INFO, Same as suggested for the RTP Header extension: = <= /span>

Encrypted application data: ...... ...... = =3D the = SCTP unchanged<= /span>

 

Sh= ouldn’t this be doable?

(A= s you see from next email, this kind of information is also required to = make the data channel work, separating prioritized data chunks from a = file transfer data channel that must NOT be = prioritized.)

 

/K= arl

 

 

 

 

Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Harald = Alvestrand
Skickat: den 17 mars 2014 16:38
Till: = rtcweb@ietf.org
=C4mne: Re: [rtcweb] [tram] Payload Types = assignments

 

On = 03/13/2014 10:02 AM, Karl Stahl wrote:

Fo= r the &#= 8220;mission to bring quality to real-time = traffic over our best effort Internet”&n= bsp;I have started = http://www.ietf.org/mail-archive/web/tram/current/msg00331.h= tml

[tram] = [rtcweb] The way to "Interfacing to QoS", A level 3-5 = IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff = [= 1] [2]

&n= bsp;

Hi= Magnus,

&n= bsp;

Wi= th the response just sent to P=E5l http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, = skipping all the QoS methods and functions that really does not belong = here when creating an “Interface to QoS”, I only see the = suggestion of “data channel = information&#= 8221;, i.e. also marking each data channel packet with traffic bandwidth = and type information  to be relevant and interesting. I checked = with one of our developers and I think the same traffic information as = for RTP can be transferred in data channel packets as = follows:

&n= bsp;

The RTP header has the following format (RFC = 3550):

    = 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

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |V=3D2|P|X|  CC   = |M|     PT      = |       sequence = number         = |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   = |            =             &= nbsp;  = timestamp          &nbs= p;            = ;    |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   = |           = synchronization source (SSRC) = identifier          &nb= sp; |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = contributing source (CSRC) = identifiers          &n= bsp;  |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = RFC5285 header extension = ...           &nbs= p;          = |

   |     2 = bytes Max Bandwidth     |   2 bytes = Traffic Type        = |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

RTP = Payload (often encrypted)

 

A Data = Channel header could have the following format:

    = 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

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   |   Data Channel Magic = Cookie   |      (sequence = number)        = |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   = |            =             &= nbsp;  = timestamp          &nbs= p;            = ;    |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= o:p>

   = |           = synchronization source (SSRC) = identifier          &nb= sp; |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = contributing source (CSRC) = identifiers          &n= bsp;  |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

   = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+

   = |            = RFC5285 header extension = ...           &nbs= p;          = |

   |     2 = bytes Max Bandwidth     |   2 bytes = Traffic Type        = |

   = |            =             &= nbsp;    = ....           &nb= sp;           &nbs= p;      |

  = DTLS Header 13 bytes

  = SCTP

 

Th= e RFC5285 header extension is not in a fixed position in any of these = cases, but still trivial to find (especially when in  a TURN flow). = This could be introduced in http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#secti= on-5

by= making room for these bytes after the UDP header, but before the DTLS = header.

&n= bsp;

Wh= at do you think?



No.

We've chosen to make Data Channel a = protocol within DTLS, and not use any unencrypted headers for it. = Neither does the data channel have any concept resembling SSRC, CSRC or = timestamp. Changing to an RTP-based format such as the one you propose = would be a drastic revision of the spec.

There's no reason to = believe such a revision at this time has any traction in the = WG.

------=_NextPart_000_0099_01CF4F63.C64AA110-- From nobody Thu Apr 3 08:52:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C16A1A027B for ; Thu, 3 Apr 2014 08:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 95pBBA8AO0LB for ; Thu, 3 Apr 2014 08:52:28 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD4C1A0212 for ; Thu, 3 Apr 2014 08:52:28 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id lx4so2051119iec.10 for ; Thu, 03 Apr 2014 08:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zkjeESAJkwJe4VpxjpTD/61JzE1jQxBhGtSyxMgauQE=; b=AV5LwsiBzP8ICXpxyhMBYi/MWwtlvjDbA+swe8KaUG9vJIyd1jq1Xw8NJ99E+CHvVf gDI8anMAxC9lWKdZMooUnOb30zFaHPHuQcnXVRbpoR8XQ94NMTZ6LrLkzGyzCiH1GVKh hpGvNotmcjzXfI6wACo0+lwgRIYhWZLUWRphY36SZTfRrc8fPoZAjciSPHZQY+FK11Ig zbpr9gm1pmXccTfsfoV7Ex1vMBUx6cdXrY2pOPwjFfMfFfShGUDZKTz1BYGFPle/+Rbf R+zsWsvZXutXYJfj9DZiCYxFuhMGQcwv2lM+9CqftCO2Ehwh5JJiqXmzpOhhR6znzA11 SZOA== MIME-Version: 1.0 X-Received: by 10.50.83.38 with SMTP id n6mr8949781igy.30.1396540343971; Thu, 03 Apr 2014 08:52:23 -0700 (PDT) Received: by 10.42.237.206 with HTTP; Thu, 3 Apr 2014 08:52:23 -0700 (PDT) Date: Thu, 3 Apr 2014 08:52:23 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Magnus Westerlund , Cullen Jennings , =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= , Harald Tveit Alvestrand Content-Type: multipart/alternative; boundary=089e010d97f81e5d4304f62563cf Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_f3UsM7pwAMdgFx8VOyqvJMqYNw Subject: [rtcweb] Joint Interim meeting May 19-21, 2014 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:52:32 -0000 --089e010d97f81e5d4304f62563cf Content-Type: text/plain; charset=ISO-8859-1 The upcoming joint interim meeting will be held in Washington, D.C. at the Google offices at 1101 New York Ave NW, Washington, DC on May 19-21, 2014. The office is about two blocks from Metro Centro. A doodle to track participation for the meeting in order to prepare badges is here: http://doodle.com/qewq4xvszbc6d4sn Please complete the form by May 16th, 2014 so that the badges will be available. For travel arrangements, please note that the final day's ending time, 16:30, is intended to be a hard stop. regards, Ted, Cullen, Magnus --089e010d97f81e5d4304f62563cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The upcoming joint interim meeting will be held in Washington, D.C. = at the Google offices at 1101 New York Ave NW,=A0Washington, DC on May 19-21, 2014. =A0The office is about two blocks from= =A0Metro Centro.=A0 A doodle to track participatio= n for the meeting in order to prepare badges is here:

http://doodle.com/qewq4x= vszbc6d4sn

Please complete the form by May 16th, 2014 so that the ba= dges will be available.=A0 For travel arrangements, please note that the fi= nal day's ending time, 16:30, is intended to be a hard stop.

regards,

Ted, Cullen, Magnus
--089e010d97f81e5d4304f62563cf-- From nobody Thu Apr 3 09:31:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002D31A01F4 for ; Thu, 3 Apr 2014 09:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1] autolearn=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 yxTtA_oromIU for ; Thu, 3 Apr 2014 09:30:54 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id 33F1C1A0246 for ; Thu, 3 Apr 2014 09:30:14 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404031830070228; Thu, 03 Apr 2014 18:30:07 +0200 From: "Karl Stahl" To: "'Matthew Kaufman \(SKYPE\)'" , "'Harald Alvestrand'" , "'Magnus Westerlund'" References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> In-Reply-To: <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> Date: Thu, 3 Apr 2014 18:30:08 +0200 Message-ID: <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPTQQB2UV1VISa20ivIvWZybl59Jr7de0AgAABWoCAAAFxAIAAAHRfgAHi2oA= Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/miexlKHUf7TbIuOUl0Uu-XrWrwE Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 16:30:58 -0000 The questions raised here don't have simple "local or endpoint answers". There are overall and basic things to be made clear first.=20 Combining P2P file transfer over the rtcweb data channels with=20 prioritized traffic chunks, brings further complications to the=20 prioritization/QoS issue. This cannot be handled/done by endpoint or=20 applications without considering the transport network (The congestion=20 to handle by prioritization is in the network - NOT in the endpoints)!=20 There are below (A), (B) and (C) - to get us back to normal - then there = is (D) to improve - to allow the network level to give us the=20 prioritization required for WebRTC critical traffic=20 (real-time and data chunks). Without (D) - an interface to network QoS=20 equipment - the network does not even know what to prioritize. I am afraid that this will be considered "back to the drawing board"=20 rather than "some language" but I cannot see the way forward if not=20 considered.=20 Has the SCTP data channel been constructed with hopes of=20 prioritization/quality functionality that simply are not there=20 (cannot be there)? (I have browsed the (complex) SCTP spec and some=20 rtcweb drafts to get an understanding of the prioritization/QoS thoughts = and means in this rtcweb context and the intended usage. Is there an=20 overall design/thought somewhere that I missed/am unaware of?) File transfer - getting a larger amount of data through between = endpoints=20 as quickly as possible - CANNOT be prioritized over IP networks! For = file=20 transfer we normally use TCP, meaning we fill the pipe, until THE=20 ENDPOINTS see packet drop and regulate down their traffic flow. File=20 transfer over IP networks works this way and cannot be improved upon=20 ("Internet would stop" if we prioritized such traffic! The available=20 bandwidth at congestion points are shared between everyone's TCP-flows=20 hitting such congestion points in the network.) File transfer's nature = is=20 to have "infinite bandwidth demand" - the mechanism to handle this is to = allow file transfer to "take the rest of the bandwidth" after = prioritized=20 media and chunks have taken their needed share.=20 The improvement to make - prioritization of media traffic and data = chunks=20 - is to allow level 3 QoS methods - not only relying on the level 4 TCP=20 backing off process. Without level 3 QoS (diffserve/DSCP, reservation or = separate pipes) media and data chunks packets are also lost in the=20 level 4 TCP backing off process (=3Dtoday's situation over best effort=20 Internet). That is where the prioritization/QoS measures that we need = for=20 rtcweb have to be. SCTP in itself (instead of TLS/TCP) does not/cannot/will not improve = things. It can destroy though if wrongly/badly implemented or used! >From the SCTP RFC4960: 7. Congestion Control=20 ...adequate resources will be allocated to SCTP traffic=20 to ensure prompt delivery of time-critical data ... unlikely,=20 during normal operations, that transmissions encounter severe=20 congestion conditions. =20 However, SCTP must operate under adverse operational conditions, which can develop upon partial network failures=20 or unexpected traffic surges. In such situations, SCTP must=20 follow correct congestion control steps to recover from=20 congestion quickly in order to get data delivered as soon as=20 possible. =20 ... SCTP congestion control is always applied to the entire=20 association, and not to individual streams. Doing file transfer with the data channel will use SCTP in the "adverse=20 operational conditions, which can develop upon partial network failures=20 or unexpected traffic surges"-mode! Has that been considered when=20 constructing the data channel? Hope so... Assuming SCTP is implemented correctly and as good as TCP for file=20 transfer (even though file transfer =3D filling the pipe mode is an=20 "adverse condition..." for SCTP). Then we must specify: (A) Rtcweb file transfer MUST NOT use the same data channel as data=20 chunks expected to have prioritized delivery (otherwise, as per=20 above, SCTP will regulate the "the entire association" to share the=20 available bandwidth at the congestion point - self-destroying the=20 expected prioritized delivery of data chunks in the same channel). (B) Each rtcweb file transfer MUST use its own data channel (if=20 combined they risk being regulated randomly/unfairly by SCTP itself=20 and all files will have just have one single TCP-like flow at the=20 network congestion point when sharing the available bandwidth with=20 everyone else's flows at that congestion point - That would be=20 "negative priority" compared to what we are used to in a browser.). FURTHER, to allow the underlying network the ability to handle the=20 real-time and data chunks as least as good as "before rtcweb"=20 (Unfortunately this will make NAT-firewall less good - not sending=20 everything P2P in a single bundle/flow - I don't like it either...=20 Sorry...): (C) File transfer using the data channel MUST NOT be bundled with=20 media and data chunk traffic in the same flow - file transfer must=20 use a separate socket creating another flow/5-tuple over the network.=20 (In reservation type of networks (e.g. mobile OTT, cable), file=20 transfer - having no bandwidth limitation - would otherwise overflow=20 the reserved bandwidth for media and chunck traffic - destroying=20 prioritized delivery of media and chunck traffic over that flow.)=20 Such file transfer data channels MUST NOT be prioritized by the=20 underlying network (applies to all IP network types, network=20 prioritization of file transfer will STOP traffic between endpoints=20 - Endpoint's TCP-like regulation has to function!). Several file=20 transfers could share such a separate flow (without specifying in=20 SDP I guess) but the underlying network must be able to separate=20 such flows (not to be prioritized) from media and chunk flows.=20 In the API, such file transfer data channel could be mapped to the=20 "below normal" classification (but would it not be better with a=20 "file transfer channel" API instead?). (And notice that without (D)=20 below, the network is not informed how to separate a file transfer=20 data channel flow from a prioritized data channel flow.) Having (A), (B) and (C) in place we are BACK TO THE CURRENT=20 Internet prioritization/QoS level - before the rtcweb p2p data=20 channel file transfer was introduced... Now remains the prioritization improvement required for quality=20 hungry rtcweb! Both for the real-time media and the data chuncks. (D) The underlying transport network needs to be informed about=20 the traffic requirements.=20 - In RTP media this traffic info could be inserted by the rtcweb=20 browser in the RTP header extension [1] depending on codec usage=20 etc. The API classification could be mapped to the=20 "Prioritize X(2 bits)" suggested in [1] below. - for the data channel, the traffic info could be inserted as=20 suggested in previous email ([2] below)=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973.html =20 Note that the required bandwidth (only known by the=20 browser/application) has to be passed to reservation types of=20 network. Requested prioritization from the API or DSCP bits are=20 not sufficient. The browser knows the bandwidth requirements for=20 codecs, but for data chunks, the application has the knowledge.=20 In lack of a bandwidth parameter in the data channel API, a simple=20 convention - e.g. reserve 200 kbps for data chunks could serve as=20 a compromise (or 4 bandwidths mapped to the API prioritize=20 classifications...). A modified API with the bandwidth requirement=20 spelled out would of course be better for the chuck data channel.=20 For a file transfer data channel - prioritization classification=20 does not even apply. =20 Having prioritization over the network cleared, the application=20 should use that transport properly - having media and data chunks=20 transported with prioritization (as produced/inserted), NOT queuing=20 them up, rearranged by protocols or applications and NOT involving=20 file transfer (that has to be unprioritized).=20 Using DSCP bits if available through the OS in some situations does=20 not help either, as already pointed out in the transport document.=20 For (D) above, DSCP bits could in a few situations function locally,=20 but not end-to-end, so of no use generally.=20 =20 /Karl [1] Traffic type information to encode (recreating the=20 idea/intention of the RTP payload type (PT) header that is not=20 available for the network level anymore, by instead having the=20 browser filling the RTP header extension with relevant traffic=20 info that all IP network types can use.), as suggested already=20 October 22. Two parameters to encode=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html=20 A) The maximum bandwidth requirement: Two bytes could contain=20 everything from some bps for real-time text to Gbps for future 3D=20 supersize telepresence on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest=20 bit set to 1, we could allocate a bit each for quality type e.g:=20 Best Effort, Audio, Video, Supplemental Video, Gaming, Data,=20 Delay Insensitive (e.g. video streaming), Minimum Delay,=20 Reliable Delivery, Prioritize X(2 bits), Variation Y(2 bits),=20 that could be combined as required to describe the stream. And with the highest bit set to 0, there could instead be a number=20 for special usage that does not fit the general description of=20 the individual bits. Without this information, how could e.g. a reservation type=20 network (e.g. mobile OTT and cable) reserve the bandwidth=20 required for incoming rtcweb media or data chunks from a diffserve=20 network (carrying no bandwidth requirement)?=20 =20 [2] A new DTLS ContentType (e.g. 24 instead of current 23) for the=20 rtcweb data channel, where the content would be the unencrypted=20 traffic info (preferable the same as in the RTP header extension)=20 followed by the SCTP data as it is today (where it today comes=20 directly in the DTLS as the only content).: TODAY: Content Type: 23 (1 byte) content type 23 means =93application data=94 DTLS version: 0xfeff (2 byte) Epoch: 0001 (2 byte) Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 byte Encrypted application data: ...... =3D the SCTP =20 SUGGESTION WITH ADDED TRAFFIC INFO FOR LOWER LEVELS:=20 Content Type: 24 (1 byte) content type 24 meaning =93application data = preceded by traffic info=94 DTLS version: 0xfeff (2 byte) Epoch: 0001 (2 byte) Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 byte: length of the encrypted application data = after the new header extension TRAFFIC INFO, Same as suggested for the RTP Header extension:=20 Encrypted application data: ...... ...... =3D the SCTP unchanged -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Matthew Kaufman = (SKYPE) Skickat: den 31 mars 2014 19:50 Till: Harald Alvestrand Kopia: rtcweb@ietf.org =C4mne: Re: [rtcweb] Some language on "prioritization" And if SCTP and RTP have packets to send, which goes first, why, and = under what circumstances? Matthew Kaufman (Sent from my iPhone) > On Mar 31, 2014, at 10:48 AM, "Harald Alvestrand" = wrote: >=20 >> On 03/31/2014 07:42 PM, Michael Tuexen wrote: >>> On 31 Mar 2014, at 19:38, Martin Thomson wrote: >>>=20 >>>> On 31 March 2014 10:08, Harald Alvestrand = wrote: >>>> -- TODO: Specify a relative priority scheme that makes sense with=20 >>>> SCTP, with an appropriate reference.=20 >>>> [draft-ietf-tsvwg-sctp-prpolicies] >>>> specifies a priority policy, but it's about discarding packets, not = >>>> deciding which packets to send first, and it also makes it=20 >>>> impossible to specify time-bounded retransmission. -- >>>=20 >>> Why would SCTP need special treatment? I can understand if there=20 >>> are particular time-sensitive control messages that need to be given = >>> higher priority, but this is all time-sensitive. >> A single transport connection (in this case an SCTP association) can=20 >> only use a single DSCP. So it would be OK to use the same priority=20 >> for all data channels, but things get complicated when when some data = >> channels would have different priorities requiring different DSCP markings. >=20 > The SCTP protocol machine will, at some given moment in time, have=20 > packets in its send buffers that belong to multiple data channels.=20 > Only one of them can go on the wire first. >=20 > Which packet does it choose to send first, and why? >=20 > That's the question I'm looking for an answer to. >=20 > If the answer has an RFC number, chapter and section, I'd be very = happy. > If it doesn't - perhaps we have to invent one. > Or say that it's "implementation dependent". >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Apr 3 12:12:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C211A02AC for ; Thu, 3 Apr 2014 12:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.338 X-Spam-Level: X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ZBTvSCzVTtmC for ; Thu, 3 Apr 2014 12:12:00 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id BFB831A02A9 for ; Thu, 3 Apr 2014 12:11:59 -0700 (PDT) Received: from [192.168.1.103] (p508F0F22.dip0.t-ipconnect.de [80.143.15.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 18D5B1C10466A; Thu, 3 Apr 2014 21:11:51 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> Date: Thu, 3 Apr 2014 21:11:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> To: Karl Stahl X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IImP3TSTVM_RzuBGXUnYxzW8nqo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 19:12:05 -0000 On 03 Apr 2014, at 18:30, Karl Stahl wrote: > The questions raised here don't have simple "local or endpoint = answers". > There are overall and basic things to be made clear first.=20 > Combining P2P file transfer over the rtcweb data channels with=20 > prioritized traffic chunks, brings further complications to the=20 > prioritization/QoS issue. This cannot be handled/done by endpoint or=20= > applications without considering the transport network (The congestion=20= > to handle by prioritization is in the network - NOT in the endpoints)!=20= >=20 > There are below (A), (B) and (C) - to get us back to normal - then = there=20 > is (D) to improve - to allow the network level to give us the=20 > prioritization required for WebRTC critical traffic=20 > (real-time and data chunks). Without (D) - an interface to network QoS=20= > equipment - the network does not even know what to prioritize. >=20 > I am afraid that this will be considered "back to the drawing board"=20= > rather than "some language" but I cannot see the way forward if not=20 > considered.=20 >=20 > Has the SCTP data channel been constructed with hopes of=20 > prioritization/quality functionality that simply are not there=20 > (cannot be there)? (I have browsed the (complex) SCTP spec and some=20 > rtcweb drafts to get an understanding of the prioritization/QoS = thoughts=20 > and means in this rtcweb context and the intended usage. Is there an=20= > overall design/thought somewhere that I missed/am unaware of?) The basis idea is to use a stream scheduler to handle streams different. Some data channels can get a higher bandwidth than others. Since the priority stuff is still in flux in W3C, it hasn't been nailed down in the SCTP spec. I guess, the place will be in http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00 This document is not finalized yet. >=20 > File transfer - getting a larger amount of data through between = endpoints=20 > as quickly as possible - CANNOT be prioritized over IP networks! For = file=20 > transfer we normally use TCP, meaning we fill the pipe, until THE=20 > ENDPOINTS see packet drop and regulate down their traffic flow. File=20= > transfer over IP networks works this way and cannot be improved upon=20= > ("Internet would stop" if we prioritized such traffic! The available=20= > bandwidth at congestion points are shared between everyone's TCP-flows=20= > hitting such congestion points in the network.) File transfer's nature = is=20 > to have "infinite bandwidth demand" - the mechanism to handle this is = to=20 > allow file transfer to "take the rest of the bandwidth" after = prioritized=20 > media and chunks have taken their needed share.=20 >=20 > The improvement to make - prioritization of media traffic and data = chunks=20 > - is to allow level 3 QoS methods - not only relying on the level 4 = TCP=20 > backing off process. Without level 3 QoS (diffserve/DSCP, reservation = or=20 > separate pipes) media and data chunks packets are also lost in the=20 > level 4 TCP backing off process (=3Dtoday's situation over best effort=20= > Internet). That is where the prioritization/QoS measures that we need = for=20 > rtcweb have to be. >=20 > SCTP in itself (instead of TLS/TCP) does not/cannot/will not improve = things. > It can destroy though if wrongly/badly implemented or used! >=20 >> =46rom the SCTP RFC4960: 7. Congestion Control=20 > ...adequate resources will be allocated to SCTP traffic=20 > to ensure prompt delivery of time-critical data ... unlikely,=20 > during normal operations, that transmissions encounter severe=20 > congestion conditions. =20 >=20 > However, SCTP must operate under adverse operational > conditions, which can develop upon partial network failures=20 > or unexpected traffic surges. In such situations, SCTP must=20 > follow correct congestion control steps to recover from=20 > congestion quickly in order to get data delivered as soon as=20 > possible. =20 >=20 > ... SCTP congestion control is always applied to the entire=20 > association, and not to individual streams. >=20 > Doing file transfer with the data channel will use SCTP in the = "adverse=20 > operational conditions, which can develop upon partial network = failures=20 > or unexpected traffic surges"-mode! Has that been considered when=20 > constructing the data channel? Hope so... >=20 > Assuming SCTP is implemented correctly and as good as TCP for file=20 > transfer (even though file transfer =3D filling the pipe mode is an=20 > "adverse condition..." for SCTP). Then we must specify: >=20 >=20 > (A) Rtcweb file transfer MUST NOT use the same data channel as data=20 > chunks expected to have prioritized delivery (otherwise, as per=20 > above, SCTP will regulate the "the entire association" to share the=20 > available bandwidth at the congestion point - self-destroying the=20 > expected prioritized delivery of data chunks in the same channel). If you use a data channel for file transfer, why would you put anything else there? If has no sequencing constraints with the file transfer. >=20 >=20 > (B) Each rtcweb file transfer MUST use its own data channel (if=20 Yepp. I would do that anyway... > combined they risk being regulated randomly/unfairly by SCTP itself=20 > and all files will have just have one single TCP-like flow at the=20 > network congestion point when sharing the available bandwidth with=20 > everyone else's flows at that congestion point - That would be=20 > "negative priority" compared to what we are used to in a browser.). >=20 >=20 > FURTHER, to allow the underlying network the ability to handle the=20 > real-time and data chunks as least as good as "before rtcweb"=20 > (Unfortunately this will make NAT-firewall less good - not sending=20 > everything P2P in a single bundle/flow - I don't like it either...=20 > Sorry...): >=20 > (C) File transfer using the data channel MUST NOT be bundled with=20 > media and data chunk traffic in the same flow - file transfer must=20 > use a separate socket creating another flow/5-tuple over the network.=20= > (In reservation type of networks (e.g. mobile OTT, cable), file=20 > transfer - having no bandwidth limitation - would otherwise overflow=20= > the reserved bandwidth for media and chunck traffic - destroying=20 > prioritized delivery of media and chunck traffic over that flow.)=20 > Such file transfer data channels MUST NOT be prioritized by the=20 > underlying network (applies to all IP network types, network=20 > prioritization of file transfer will STOP traffic between endpoints=20 > - Endpoint's TCP-like regulation has to function!). Several file=20 > transfers could share such a separate flow (without specifying in=20 > SDP I guess) but the underlying network must be able to separate=20 > such flows (not to be prioritized) from media and chunk flows.=20 >=20 > In the API, such file transfer data channel could be mapped to the=20 > "below normal" classification (but would it not be better with a=20 > "file transfer channel" API instead?). (And notice that without (D)=20 > below, the network is not informed how to separate a file transfer=20 > data channel flow from a prioritized data channel flow.) >=20 >=20 > Having (A), (B) and (C) in place we are BACK TO THE CURRENT=20 > Internet prioritization/QoS level - before the rtcweb p2p data=20 > channel file transfer was introduced... >=20 > Now remains the prioritization improvement required for quality=20 > hungry rtcweb! Both for the real-time media and the data chuncks. >=20 >=20 > (D) The underlying transport network needs to be informed about=20 > the traffic requirements.=20 >=20 > - In RTP media this traffic info could be inserted by the rtcweb=20 > browser in the RTP header extension [1] depending on codec usage=20 > etc. The API classification could be mapped to the=20 > "Prioritize X(2 bits)" suggested in [1] below. >=20 > - for the data channel, the traffic info could be inserted as=20 > suggested in previous email ([2] below)=20 > http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973.html =20 >=20 > Note that the required bandwidth (only known by the=20 > browser/application) has to be passed to reservation types of=20 > network. Requested prioritization from the API or DSCP bits are=20 > not sufficient. The browser knows the bandwidth requirements for=20 > codecs, but for data chunks, the application has the knowledge.=20 > In lack of a bandwidth parameter in the data channel API, a simple=20 > convention - e.g. reserve 200 kbps for data chunks could serve as=20 > a compromise (or 4 bandwidths mapped to the API prioritize=20 > classifications...). A modified API with the bandwidth requirement=20 > spelled out would of course be better for the chuck data channel.=20 > For a file transfer data channel - prioritization classification=20 > does not even apply. =20 >=20 >=20 > Having prioritization over the network cleared, the application=20 > should use that transport properly - having media and data chunks=20 > transported with prioritization (as produced/inserted), NOT queuing=20 > them up, rearranged by protocols or applications and NOT involving=20 > file transfer (that has to be unprioritized).=20 >=20 > Using DSCP bits if available through the OS in some situations does=20 > not help either, as already pointed out in the transport document.=20 > For (D) above, DSCP bits could in a few situations function locally,=20= > but not end-to-end, so of no use generally.=20 >=20 > /Karl >=20 >=20 > [1] Traffic type information to encode (recreating the=20 > idea/intention of the RTP payload type (PT) header that is not=20 > available for the network level anymore, by instead having the=20 > browser filling the RTP header extension with relevant traffic=20 > info that all IP network types can use.), as suggested already=20 > October 22. Two parameters to encode=20 > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html=20 >=20 > A) The maximum bandwidth requirement: Two bytes could contain=20 > everything from some bps for real-time text to Gbps for future 3D=20 > supersize telepresence on a logarithmic scale. >=20 > B) The quality characteristics for the stream, with the highest=20 > bit set to 1, we could allocate a bit each for quality type e.g:=20 > Best Effort, Audio, Video, Supplemental Video, Gaming, Data,=20 > Delay Insensitive (e.g. video streaming), Minimum Delay,=20 > Reliable Delivery, Prioritize X(2 bits), Variation Y(2 bits),=20 > that could be combined as required to describe the stream. >=20 > And with the highest bit set to 0, there could instead be a number=20 > for special usage that does not fit the general description of=20 > the individual bits. >=20 > Without this information, how could e.g. a reservation type=20 > network (e.g. mobile OTT and cable) reserve the bandwidth=20 > required for incoming rtcweb media or data chunks from a diffserve=20 > network (carrying no bandwidth requirement)?=20 >=20 >=20 > [2] A new DTLS ContentType (e.g. 24 instead of current 23) for the=20 > rtcweb data channel, where the content would be the unencrypted=20 > traffic info (preferable the same as in the RTP header extension)=20 > followed by the SCTP data as it is today (where it today comes=20 > directly in the DTLS as the only content).: >=20 > TODAY: > Content Type: 23 (1 byte) content type 23 means =93application data=94 > DTLS version: 0xfeff (2 byte) > Epoch: 0001 (2 byte) > Sequence number (e.g. 00 00 00 00 00 01) 6 byte > Length (e.g. 01 c0) 2 byte > Encrypted application data: ...... =3D the SCTP >=20 > SUGGESTION WITH ADDED TRAFFIC INFO FOR LOWER LEVELS:=20 > Content Type: 24 (1 byte) content type 24 meaning =93application data = preceded > by traffic info=94 > DTLS version: 0xfeff (2 byte) > Epoch: 0001 (2 byte) > Sequence number (e.g. 00 00 00 00 00 01) 6 byte > Length (e.g. 01 c0) 2 byte: length of the encrypted application data = after > the new header extension > TRAFFIC INFO, Same as suggested for the RTP Header extension:=20 > Encrypted application data: ...... ...... =3D the SCTP unchanged >=20 >=20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Matthew Kaufman = (SKYPE) > Skickat: den 31 mars 2014 19:50 > Till: Harald Alvestrand > Kopia: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Some language on "prioritization" >=20 > And if SCTP and RTP have packets to send, which goes first, why, and = under > what circumstances? >=20 > Matthew Kaufman >=20 > (Sent from my iPhone) >=20 >> On Mar 31, 2014, at 10:48 AM, "Harald Alvestrand" = > wrote: >>=20 >>> On 03/31/2014 07:42 PM, Michael Tuexen wrote: >>>> On 31 Mar 2014, at 19:38, Martin Thomson > wrote: >>>>=20 >>>>> On 31 March 2014 10:08, Harald Alvestrand = wrote: >>>>> -- TODO: Specify a relative priority scheme that makes sense with=20= >>>>> SCTP, with an appropriate reference.=20 >>>>> [draft-ietf-tsvwg-sctp-prpolicies] >>>>> specifies a priority policy, but it's about discarding packets, = not=20 >>>>> deciding which packets to send first, and it also makes it=20 >>>>> impossible to specify time-bounded retransmission. -- >>>>=20 >>>> Why would SCTP need special treatment? I can understand if there=20= >>>> are particular time-sensitive control messages that need to be = given=20 >>>> higher priority, but this is all time-sensitive. >>> A single transport connection (in this case an SCTP association) can=20= >>> only use a single DSCP. So it would be OK to use the same priority=20= >>> for all data channels, but things get complicated when when some = data=20 >>> channels would have different priorities requiring different DSCP > markings. >>=20 >> The SCTP protocol machine will, at some given moment in time, have=20 >> packets in its send buffers that belong to multiple data channels.=20 >> Only one of them can go on the wire first. >>=20 >> Which packet does it choose to send first, and why? >>=20 >> That's the question I'm looking for an answer to. >>=20 >> If the answer has an RFC number, chapter and section, I'd be very = happy. >> If it doesn't - perhaps we have to invent one. >> Or say that it's "implementation dependent". >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Thu Apr 3 12:14:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447E71A028D for ; Thu, 3 Apr 2014 12:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 pwoWvt0QkC59 for ; Thu, 3 Apr 2014 12:13:58 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8E85B1A0116 for ; Thu, 3 Apr 2014 12:13:58 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id z2so8106537wiv.0 for ; Thu, 03 Apr 2014 12:13: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:from:date:message-id:subject:to :cc:content-type; bh=BEIHnT/ZupaykPCio/Nj1p5V4NiR7UuA8sKMJRkuVu0=; b=K9l4R0uV0qIGwL2Y1cIGEnDReDLXz6hF2qBd8FUKrhG1nZM9oPheCIwWSNvznE1C+k sLqZ4sVKRL/mo0a2SqA01930VJi+SEJAQwPhT9dzelk/4Osc4i52urof0YXnTZIEy6jH aI+OT4hxBbZTGEmOlGosQnUFPV6+ZxMHjnUHqmyWCqguyPV+MDs4QaMXJPSrcgqsAI+O d3K6IbEj+7ND2iHs+iTddu2jKNY2fa2gv9w8dF6hN589qAN9xVqJbjDw4Da2uQxaVSYg K6TSctBXKB0VCxWtHvplJNoCYKydynXEXz4+O3mEmPZYeSyVGZP3piioGQzOrBfpMBDr SLoQ== X-Received: by 10.180.11.36 with SMTP id n4mr14043999wib.4.1396552433655; Thu, 03 Apr 2014 12:13:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.102.130 with HTTP; Thu, 3 Apr 2014 12:13:33 -0700 (PDT) In-Reply-To: <533984DD.2020804@alvestrand.no> References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> <5339385D.6070006@ericsson.com> <53397036.5050104@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF82B7921@DEMUMBX005.nsn-intra.net> <533984DD.2020804@alvestrand.no> From: Bernard Aboba Date: Thu, 3 Apr 2014 12:13:33 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11c258f0b7e70504f6283327 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lfFLlgpRr-kJxIAgbPTIIZDqJoE Cc: "rtcweb@ietf.org" , Harald Alvestrand Subject: Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 19:14:04 -0000 --001a11c258f0b7e70504f6283327 Content-Type: text/plain; charset=ISO-8859-1 Harald said: "My memory was faulty; I had thought that the same conclusion had applied for TCP ICE candidates as for TURN ICE candidates. Version -04 will have this fixed." [BA] My memory was similarly faulty. But assuming the problem is with my memory as opposed to the minutes, the decision to require support for ICE TCP brings to mind other questions such as: a. Is support for RFC 4571 (framing of RTP/RTCP over connection oriented transport) also mandated? With respect to JSEP, what about RFC 4145 (TCP-based media transport in SDP )? b. Are there any implications for transport of DTLS/SRTP key management? (e.g. if ICE TCP is needed because UDP transport is blocked, wouldn't that also cause the DTLS/SRTP key exchange to fail?) c. Are there any implications for the data channel? (e.g. if UDP transport is blocked, wouldn't SCTP/DTLS/UDP also not work?) On Mon, Mar 31, 2014 at 8:08 AM, Harald Alvestrand wrote: > On 03/31/2014 03:54 PM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > > Hi Harald, > > The decision in London to make ICE-TCP a "MUST" has not been implemented in the -03 draft > (I have noticed you have reflected the related TURN-TCP discussion already). > > What are your plans for addressing the ICE-TCP decision? > > > Thanks! > > Checking the minutes, I find: > > > Chairs called a hum between the alternatives: > > 1) TCP ICE Candidates are MUST implement > 2) TCP ICE Candidates are SHOULD/MAY implement > 3) TCP ICE Candidates will not be discussed in document. > > The hum indicated very strong support for 1). > > > My memory was faulty; I had thought that the same conclusion had applied > for TCP ICE candidates as for TURN ICE candidates. Version -04 will have > this fixed. > > > > Kind regards, > Uwe > > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org ] On Behalf Of ext Harald > Alvestrand > Sent: Monday, March 31, 2014 3:40 PM > To: Magnus Westerlund; rtcweb@ietf.org; Harald Alvestrand > Subject: [rtcweb] Transport -03, bundling question (Re: Comments on > draft-ietf-rtcweb-transports-02) > > Version -03 is now published. I hope you like it! > > New outstanding item: > > I added requirements for implementations to be able to generate both > fully bundled (one 5-tuple for everything) and fully unbundled (one > 5-tuple for each flow) configurations, and for implementations to be > able to tolerate being hit with any combination of bundling schemes. > > Is there a need to specify at MUST, SHOULD or MAY levels other > combinations? > > Harald > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c258f0b7e70504f6283327 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Harald said:=A0
"My memory was faulty; I had thought that the sa= me conclusion had applied for TCP ICE candidates as for TURN ICE candidates= . Version -04 will have this fixed."

[BA= ] =A0My memory was similarly faulty. But assuming the problem is with my me= mory as opposed to the minutes, the decision to require support for ICE TCP= brings to mind other questions such as:

a. = Is=A0sup= port for RFC 4571 (framing of RTP/RTCP over connection oriented transport) = =A0also mandated? =A0With respect to JSEP, what about RFC 4145 (TCP-based m= edia transport in SDP )?=A0
b. Are the= re any implications for transport of DTLS/SRTP key management? =A0(e.g. if = ICE TCP is needed because UDP transport is blocked, wouldn't that also = cause the DTLS/SRTP key exchange to fail?)
c. Are the= re any implications for the data channel? =A0(e.g. if UDP transport is bloc= ked, wouldn't SCTP/DTLS/UDP also not work?)


On Mon, Mar 31, 2014 at 8:08 AM, Harald = Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 03/31/2014 03:54 PM, Rauschenbach, Uwe (NSN - DE/Munich) wrote:
Hi Harald,

The decision in London to make ICE-TCP a "MUST" has not been impl=
emented in the -03 draft
(I have noticed you have reflected the related TURN-TCP discussion already)=
.

What are your plans for addressing the ICE-TCP decision?

Thanks!

Checking the minutes, I find:

=20 

Chairs called a hum between the alternatives:

1) TCP ICE Candidates are MUST implement
2) TCP ICE Candidates are SHOULD/MAY implement
3) TCP ICE Candidates will not be discussed in document.=20

The hum indicated very strong support for 1).=20

My memory was faulty; I had thought that the same conclusion had applied for TCP ICE candidates as for TURN ICE candidates. Version -04 will have this fixed.


Kind regards,
Uwe=20



-----Original Message-----
From: rtcweb [=
mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Harald
Alvestrand
Sent: Monday, March 31, 2014 3:40 PM
To: Magnus Westerlund; rtcweb@ietf.org; Harald Alvestrand
Subject: [rtcweb] Transport -03, bundling question (Re: Comments on
draft-ietf-rtcweb-transports-02)

Version -03 is now published. I hope you like it!

New outstanding item:

I added requirements for implementations to be able to generate both
fully bundled (one 5-tuple for everything) and fully unbundled (one
5-tuple for each flow) configurations, and for implementations to be
able to tolerate being hit with any combination of bundling schemes.

Is there a need to specify at MUST, SHOULD or MAY levels other
combinations?

Harald

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb



-=
-=20
Surveillance is pervasive. Go Dark.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--001a11c258f0b7e70504f6283327-- From nobody Thu Apr 3 13:26:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5813B1A011B for ; Thu, 3 Apr 2014 13:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 d_w60pR7kvqi for ; Thu, 3 Apr 2014 13:25:56 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id B039B1A005F for ; Thu, 3 Apr 2014 13:25:55 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so75373wiv.3 for ; Thu, 03 Apr 2014 13:25:50 -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:content-type; bh=+sffXSWqcPHtuuP+iaXyGa4DlMVcV1A7QEypuP3gMNQ=; b=kynq+RK2oDzWwxurTxngZyCZs0+E3hwDtDc9T+UlJrNbdXbhXaOS4siiSAeMwVvLky xwaxpZ+eWqrfA157zIra7KIu68A+b4KjQo0s5XHweOz7bicQO0TbRh1P7jUlLKEte2U9 zvU7jfFpDJbt4bGQSKfYP/eMjZxjIz8aduNkjkqmCbT+G0CUDelDR7U6DkE+98ryMy0z n8bYOq7QfAH60WvAMqfrctKwgX0LH9772xK8tVjdhosriZSKA4WeWMaPBZUIZxlNe5XZ q6oZ1RL67z7lxkz+VbddICNeKA7/CDUNJemNUnbsYX04j6VKw/EugzVeFepSKSYKf623 vvYQ== MIME-Version: 1.0 X-Received: by 10.180.89.211 with SMTP id bq19mr40694221wib.58.1396556750916; Thu, 03 Apr 2014 13:25:50 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Thu, 3 Apr 2014 13:25:50 -0700 (PDT) In-Reply-To: References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> <5339385D.6070006@ericsson.com> <53397036.5050104@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF82B7921@DEMUMBX005.nsn-intra.net> <533984DD.2020804@alvestrand.no> Date: Thu, 3 Apr 2014 13:25:50 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HOklkV1WPJMBh08FvtsCsqL5cd8 Cc: "rtcweb@ietf.org" , Harald Alvestrand Subject: Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 20:26:02 -0000 On 3 April 2014 12:13, Bernard Aboba wrote: > "My memory was faulty; I had thought that the same conclusion had applied > for TCP ICE candidates as for TURN ICE candidates. Version -04 will have > this fixed." > > [BA] My memory was similarly faulty. But assuming the problem is with my > memory as opposed to the minutes, the decision to require support for ICE > TCP brings to mind other questions such as: That makes three with faulty memories. But perhaps that's my prejudice at play. The marginal benefit remains...tiny relative to the cost. From nobody Thu Apr 3 13:45:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736481A0193 for ; Thu, 3 Apr 2014 13:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 vBg4RjlE03GJ for ; Thu, 3 Apr 2014 13:45:24 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9571A0185 for ; Thu, 3 Apr 2014 13:45:24 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so2482710wes.11 for ; Thu, 03 Apr 2014 13:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8CnmxvQUyaleAp/U1mutJDzL97pOvoxUqoHZyse933Q=; b=OT8BKXczavC7t51mN/kSYvHZ1cDPGcm5Nw/jR1G/1x8Eh/4CbonmqW2o0gHceaYSIA UtEluyTBQ+/vaWMG/Pg9n+TbZjDAtNPSO6pfmAqGLeRbD/B2G2bhT+R8sNDTJxwRALic UEUfohghSYw7LyOpjMRh2kYGALWoyOkSflsV8BLy+fb+ho4bVWhne7tCVhoE6l8w52me C7SFgGOmpXy99UKCf5H5dOrT5UNPlrC28L1VDMBNOJ9NnH2X9TQ8MRbmfpOVyE2cdz6a X6K3LRwin0+tyh9qdWXQCNoKrbAQvFeFxOfAF0lYR4avJoY5JkhWh3Yxb6L6y9VRz/1k 2nfg== X-Received: by 10.194.92.228 with SMTP id cp4mr13692231wjb.81.1396557919723; Thu, 03 Apr 2014 13:45:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.102.130 with HTTP; Thu, 3 Apr 2014 13:44:59 -0700 (PDT) In-Reply-To: References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> <5339385D.6070006@ericsson.com> <53397036.5050104@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF82B7921@DEMUMBX005.nsn-intra.net> <533984DD.2020804@alvestrand.no> From: Bernard Aboba Date: Thu, 3 Apr 2014 13:44:59 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bfd0bdeb6aad504f6297a56 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UAa3EHqGLSFTxT-vjf-zBT7R3UM Cc: "rtcweb@ietf.org" , Harald Alvestrand Subject: Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 20:45:30 -0000 --047d7bfd0bdeb6aad504f6297a56 Content-Type: text/plain; charset=ISO-8859-1 Martin said: "The marginal benefit remains...tiny relative to the cost" [BA] This is particularly true if you consider *all* of the additional work items required to enable the usage scenario. It is one thing to support SRTP/SRTCP over RFC 4571 framing, but without also encapsulating DTLS/SRTP over RFC 4571 framing, how do you reliably obtain the SRTP/SRTCP master keys? Similarly, do we also run SCTP/DTLS data channel over RFC 4571 framing? In my experience, without a great deal of care, running one reliable transport over another can works poorly if packet loss is encountered (e.g. the time-out periods interfere with one another). On Thu, Apr 3, 2014 at 1:25 PM, Martin Thomson wrote: > On 3 April 2014 12:13, Bernard Aboba wrote: > > "My memory was faulty; I had thought that the same conclusion had applied > > for TCP ICE candidates as for TURN ICE candidates. Version -04 will have > > this fixed." > > > > [BA] My memory was similarly faulty. But assuming the problem is with my > > memory as opposed to the minutes, the decision to require support for ICE > > TCP brings to mind other questions such as: > > That makes three with faulty memories. But perhaps that's my > prejudice at play. The marginal benefit remains...tiny relative to > the cost. > --047d7bfd0bdeb6aad504f6297a56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Martin said:=A0

"The marginal benefit remains...t= iny relative to=A0the cost"

[BA= ] This is particularly true if you consider *all* of the additional work it= ems required to enable the usage scenario. =A0It is one thing to support SR= TP/SRTCP over RFC 4571 framing, but without also =A0encapsulating DTLS/SRTP= over RFC 4571 framing, how do you reliably obtain the SRTP/SRTCP master ke= ys? =A0Similarly, do we also run SCTP/DTLS data channel over RFC 4571 frami= ng? =A0 In my experience, without a great deal of care, running one reliabl= e transport over another can works poorly if packet loss is encountered (e.= g. the time-out periods interfere with one another). =A0=A0


On Thu,= Apr 3, 2014 at 1:25 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 3 April 2014 12:13, Berna= rd Aboba <bernard.aboba@gmail= .com> wrote:
> "My memory was faulty; I had thought that the same conclusion had= applied
> for TCP ICE candidates as for TURN ICE candidates. Version -04 will ha= ve
> this fixed."
>
> [BA] =A0My memory was similarly faulty. But assuming the problem is wi= th my
> memory as opposed to the minutes, the decision to require support for = ICE
> TCP brings to mind other questions such as:

That makes three with faulty memories. =A0But perhaps that's my prejudice at play. =A0The marginal benefit remains...tiny relative to
the cost.

--047d7bfd0bdeb6aad504f6297a56-- From nobody Thu Apr 3 17:14:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389B61A0407 for ; Thu, 3 Apr 2014 17:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 8yqB5DG4VN0m for ; Thu, 3 Apr 2014 17:14:24 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 05D401A0406 for ; Thu, 3 Apr 2014 17:14:23 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id gq1so2767917obb.4 for ; Thu, 03 Apr 2014 17:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MQIC5TeNwAiVQDJX0ul+kLU/M8jMxCWCzj+6gTlPpLI=; b=DNdzFIJQFM+7DaVn9K4zAblE+cMHRuP0pPMieOfXC1TOtBSS36RtTt1Oop3jMmM4wp Fp4gbMkZjMzDcKlOqWvJLSgJTEhWZ/UBTBWg9R/ZoC2Nh0BUsHMMN4WD5wv2u4wQBovP 6B5POT2zJIy2nohnaZUNTQa+m9eMYVeSFX1UoFjcEKwEQCA6I7Nmix7UZrOr1++Vs7k4 /r5/RvNo4/ebL+LUtyi5J181mJhKE+p15hspQlGPIo45gA5omp1mOsv8Q6NcM2c+jZuS Gcwgq3MQwPWyxFm9TRB8LM8qpSYiz0RizJQBFykew5sGvkYCQB4y2w25YM0TCSRFLkiW VcNQ== MIME-Version: 1.0 X-Received: by 10.60.15.38 with SMTP id u6mr13205867oec.26.1396570459624; Thu, 03 Apr 2014 17:14:19 -0700 (PDT) Received: by 10.60.118.37 with HTTP; Thu, 3 Apr 2014 17:14:19 -0700 (PDT) Date: Thu, 3 Apr 2014 17:14:19 -0700 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dVoCdDDk2NzXFmVSLYoUg6vNq6E Subject: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 00:14:30 -0000 As I described briefly at the last meeting, ensuring that media is isolated from the application or web site is a key part of addressing our security goals. The key part of that is making sure that any media that is isolated on the sending side of RTCPeerConnection remains isolated when it reaches the other side. As I noted, this is also necessary in order to ensure the integrity of the same origin model. In that model, cross origin media is required to be inaccessible to content, and as it stands RTCPeerConnection could be used to work around those restrictions (implementations can implement other protections, as Firefox already does). The alternatives as I see them (and I hope that this is sufficiently exhaustive) are: 1. ask the TLS working group for a TLS-based solution 2. build something into the session signaling (i.e., new SDP bits) 3. give up on the idea I prefer 1 for reasons already outlined. I propose that we formally request the TLS working group recommend or define a mechanism whereby we can signal in the TLS handshake that the session contents are to be protected from access (where the description of that protection may need to our responsibility). I have pointed to draft-thomson-tls-acp as a potential solution here, but others have noted that ALPN tokens could be used. I expect that TLS are capable of making the right decision here. From nobody Thu Apr 3 18:51:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC89C1A0390 for ; Thu, 3 Apr 2014 18:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 wOQokyTDrYQw for ; Thu, 3 Apr 2014 18:51:29 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 19A001A0401 for ; Thu, 3 Apr 2014 18:51:28 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id v1so2573432yhn.0 for ; Thu, 03 Apr 2014 18:51:24 -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:content-type; bh=8gt0kfSPJ9d/2dtrTyh/qt1xniUFgnEEpUHjg0BEGlM=; b=gDLb4f1uVr8cq8zcGjol4XTbgcCsLOTdqofWk8tWRQ/opGL/lMwUl+4hLD95Fmao+F 383NdF0ABbYOFhOEE9rIUgEymbaNovbfRr9wHL0g5/OvGjEXiDs19KJUmLTYk447/oqf aKAlut35l/Ebo9D5UeVzsQuti83YbtW/Pnt5AQfFF1NbgRUes/+N7C/CFP28cZdhWp0g w/4psjAHuKKUyraZagEZmOYZOjUtikgXB/8gAo1+8Y5u3DhEUEpX5xbsWjuR5zSW7JbC 9RAnOavPtWjh1c6w5RkEK69rQADI1p2xRuyo0QibDhScAUyGpv2ciCrBRuZDlvZnzHJI 5EMg== MIME-Version: 1.0 X-Received: by 10.236.200.67 with SMTP id y43mr12931927yhn.77.1396576284528; Thu, 03 Apr 2014 18:51:24 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Thu, 3 Apr 2014 18:51:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Apr 2014 18:51:24 -0700 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OSzlA6reV6tKQ-w6kX90ckDhZD0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 01:51:34 -0000 On Thu, Apr 3, 2014 at 5:14 PM, Martin Thomson wrote: > As I described briefly at the last meeting, ensuring that media is > isolated from the application or web site is a key part of addressing > our security goals. > > The key part of that is making sure that any media that is isolated on > the sending side of RTCPeerConnection remains isolated when it reaches > the other side. > > As I noted, this is also necessary in order to ensure the integrity of > the same origin model. In that model, cross origin media is required > to be inaccessible to content, and as it stands RTCPeerConnection > could be used to work around those restrictions (implementations can > implement other protections, as Firefox already does). > > The alternatives as I see them (and I hope that this is sufficiently > exhaustive) are: > > 1. ask the TLS working group for a TLS-based solution > 2. build something into the session signaling (i.e., new SDP bits) > 3. give up on the idea > > I prefer 1 for reasons already outlined. Putting on my TLS hat, TLS already lets you send data across the network securely. Why does this bit need to be treated differently from all others? Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Apr 3 19:30:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9DE1A0538 for ; Thu, 3 Apr 2014 19:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 Mi6XoL7XzmjR for ; Thu, 3 Apr 2014 19:30:14 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id C5E1B1A053B for ; Thu, 3 Apr 2014 19:30:13 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id bs8so381788wib.17 for ; Thu, 03 Apr 2014 19:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TcZOWO9jf8m1Fm19v37FHLjuquDoEdGLwDxYqcpEmaY=; b=K4XJuH1/vWIydQpilKRfzfU9H078oq9LsXjbqP1jKT1xGoC1Jrfk2ojyv0ThnhuAU4 9ZlVLOf5/F4AaQCuCFYhHSN1HnZlbaK+JNpC+WrrX0ffDA80WZqawounNPN8CZLk/Bui 1yY8RnuZHj85M95m20Tmt+SnzYYY1Zz8kwcX1rZblsuflE3LoabHDmv4nH3Nv/k4nEI5 HjVZbVpROfuTNgOUSSzu4rd1INISdKuDyJ0s3fxTM0Tyj8yD/AWJH5V1fJ9fiTtNcEGn P844v98roQP2GR+mwrDTdUNvnhnDIzODAaDLtMYC0GpJVdl98nZgfXENzu+3uBt8GFYk OKaw== X-Received: by 10.194.174.197 with SMTP id bu5mr15091371wjc.71.1396578608993; Thu, 03 Apr 2014 19:30:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.102.130 with HTTP; Thu, 3 Apr 2014 19:29:48 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 3 Apr 2014 19:29:48 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=089e013d1a60e3debe04f62e4bae Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8ZxBDykmyu48gS8YiHb2YgyuufE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 02:30:20 -0000 --089e013d1a60e3debe04f62e4bae Content-Type: text/plain; charset=ISO-8859-1 Martin said: "I have pointed to draft-thomson-tls-acp as a potential solution here, but others have noted that ALPN tokens could be used." Watson said: "Putting on my TLS hat, TLS already lets you send data across the network securely. Why does this bit need to be treated differently from all others? [BA] As Martin indicates, the desire for isolation needs to be communicated to ensure that remote media is not misused. With either of the TLS approaches that Martin has suggested, the desire for isolation is communicated directly between the peers. Having this occur E2E via media, not hop-by-hop via signaling avoids the risk of a MITM preventing isolation from being negotiated. However once the desire for isolation is communicated E2E (either via ACP or ALPN tokens), there is nothing in the SRTP traffic (keyed by DTLS/SRTP) that indicates that the traffic is to be isolated. On Thu, Apr 3, 2014 at 6:51 PM, Watson Ladd wrote: > On Thu, Apr 3, 2014 at 5:14 PM, Martin Thomson > wrote: > > As I described briefly at the last meeting, ensuring that media is > > isolated from the application or web site is a key part of addressing > > our security goals. > > > > The key part of that is making sure that any media that is isolated on > > the sending side of RTCPeerConnection remains isolated when it reaches > > the other side. > > > > As I noted, this is also necessary in order to ensure the integrity of > > the same origin model. In that model, cross origin media is required > > to be inaccessible to content, and as it stands RTCPeerConnection > > could be used to work around those restrictions (implementations can > > implement other protections, as Firefox already does). > > > > The alternatives as I see them (and I hope that this is sufficiently > > exhaustive) are: > > > > 1. ask the TLS working group for a TLS-based solution > > 2. build something into the session signaling (i.e., new SDP bits) > > 3. give up on the idea > > > > I prefer 1 for reasons already outlined. > > Putting on my TLS hat, TLS already lets you send data across the > network securely. Why does this bit need to be treated differently > from all others? > > Sincerely, > Watson Ladd > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e013d1a60e3debe04f62e4bae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Martin said:=A0

"I have pointed to draft-thomson-= tls-acp as a potential solution here,
but others have noted that ALPN tok= ens could be used."=A0

Watson said:=A0

"Putting on my TLS hat, TLS al= ready lets you send data across the
network securely. Why does this bit need t= o be treated differently
from all others= ?

[BA] As Martin indicates, the desire for isolation needs to be commu= nicated to ensure that remote media is not misused. =A0With either of the TLS approaches that Ma= rtin has suggested, =A0the desire for isolation is communicated directly be= tween the peers. =A0 Having this occur E2E via media, not hop-by-hop via si= gnaling avoids the risk of a MITM preventing isolation from being negotiate= d. =A0

However once the desire for isola= tion is communicated E2E (either via ACP or ALPN tokens), there is nothing = in the SRTP traffic (keyed by DTLS/SRTP) that indicates that the traffic is= to be isolated. =A0


On Thu,= Apr 3, 2014 at 6:51 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
On Thu, Apr 3, 2014 at 5:14 = PM, Martin Thomson <martin.t= homson@gmail.com> wrote:
> As I described briefly at the last meeting, ensuring that media is
> isolated from the application or web site is a key part of addressing<= br> > our security goals.
>
> The key part of that is making sure that any media that is isolated on=
> the sending side of RTCPeerConnection remains isolated when it reaches=
> the other side.
>
> As I noted, this is also necessary in order to ensure the integrity of=
> the same origin model. =A0In that model, cross origin media is require= d
> to be inaccessible to content, and as it stands RTCPeerConnection
> could be used to work around those restrictions (implementations can > implement other protections, as Firefox already does).
>
> The alternatives as I see them (and I hope that this is sufficiently > exhaustive) are:
>
> =A01. ask the TLS working group for a TLS-based solution
> =A02. build something into the session signaling (i.e., new SDP bits)<= br> > =A03. give up on the idea
>
> I prefer 1 for reasons already outlined.

Putting on my TLS hat, TLS already lets you send data across the
network securely. Why does this bit need to be treated differently
from all others?

Sincerely,
Watson Ladd


--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither =A0Liberty nor Safety."
-- Benjamin Franklin

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e013d1a60e3debe04f62e4bae-- From nobody Thu Apr 3 19:49:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22641A0077 for ; Thu, 3 Apr 2014 19:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 r9d1-q4B3DKM for ; Thu, 3 Apr 2014 19:49:39 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 90B1B1A008A for ; Thu, 3 Apr 2014 19:49:39 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id z6so2581608yhz.8 for ; Thu, 03 Apr 2014 19:49:34 -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:content-type; bh=3H67km2LfIOoHh98o/vigyTwKOpKBh2xpPZdavCyPoU=; b=nA8CFRED2cXfItXl8djTE5dwqAgdREiTL7gX3kyYmp1PkFT/S7OAVUO3oC8VGMHsuo H4IcpJ/846M7mmEwVmHrhbS9JMYAp09FuB/FJmiHvvCz+HFA8+76f9KUTQAk9ZVM+qn8 GlDv4ltb9HElLVwGF7JfghuuKl72FKpLi9B1yaI7viPrXcaKJV0I1BW5v/zbzSslTVYf 5EJP9yZLGqqsVZ5leNHEsCYzsVRnbshSlGBZZqp2zki/FpGMC4sfA0GeN6oQw3/4i6Om UAmFNLK7rz94IbcMH9CDUrbIoTEEY2xjnvSVXulUoxgmE8JNgfGIok7PeVPkjMWIm+pS 1zyg== MIME-Version: 1.0 X-Received: by 10.236.230.41 with SMTP id i39mr13416492yhq.14.1396579774017; Thu, 03 Apr 2014 19:49:34 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Thu, 3 Apr 2014 19:49:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Apr 2014 19:49:33 -0700 Message-ID: From: Watson Ladd To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F256057P1fMo_epLjHbfyNbfZ6Q Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 02:49:45 -0000 On Thu, Apr 3, 2014 at 7:29 PM, Bernard Aboba wrote: > Martin said: > > "I have pointed to draft-thomson-tls-acp as a potential solution here, > but others have noted that ALPN tokens could be used." > > Watson said: > > "Putting on my TLS hat, TLS already lets you send data across the > network securely. Why does this bit need to be treated differently > from all others? > > [BA] As Martin indicates, the desire for isolation needs to be communicated > to ensure that remote media is not misused. With either of the TLS > approaches that Martin has suggested, the desire for isolation is > communicated directly between the peers. Having this occur E2E via media, > not hop-by-hop via signaling avoids the risk of a MITM preventing isolation > from being negotiated. The MITM can kill any TLS connection containing the extension. My understanding is that signalling data is immutable, hence the need to ask the browser to generate it. > > However once the desire for isolation is communicated E2E (either via ACP or > ALPN tokens), there is nothing in the SRTP traffic (keyed by DTLS/SRTP) that > indicates that the traffic is to be isolated. I don't see why the isolation status cannot be included as an extension to SRTP. You aren't asking TLS to make extensions for video resolution and codec after all. Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Apr 3 20:21:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066BF1A036D for ; Thu, 3 Apr 2014 20:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 IQxhKs3W9PkA for ; Thu, 3 Apr 2014 20:21:27 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 51BEC1A030B for ; Thu, 3 Apr 2014 20:21:27 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id um1so2814133pbc.30 for ; Thu, 03 Apr 2014 20:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=q20xNMXCRsrvFSsSgUuklnlOTZU9thWrWITdwpevwTU=; b=Av4kzO5EsJU7JM2Dy9EJJwJdJfTzGn3ZfNKYmP7eKTVUQiqTcuX67OZ2cLhLen0/Uj E3yGaviFsRw9S5z8ns/7np9VIQjoleU+/+jCvpfra1wdl082vxDkGJ/zqP269G+iCMqI 5GSk7BcvxQc/iD0PKz4kfS2SdZ6fAoHt5aFVwKTnQAupZHUnxf/z6gih/j6AcawkpJli njdJhVW4vzC6efLqfi76fJEPyXsHqlE4MKf0caS4AAjm7XCD3A4oWmiQHLMWilnlb2rs 6SJ/YKD1yLBMlz9BHoZ51DLtIg+d1mYLIiN1YqzI+3IG+/IH0gJ1XyJYTK6YrJixiNLC jdVA== X-Received: by 10.66.136.71 with SMTP id py7mr12162841pab.2.1396581683055; Thu, 03 Apr 2014 20:21:23 -0700 (PDT) Received: from [192.168.1.112] (c-24-19-246-140.hsd1.wa.comcast.net. [24.19.246.140]) by mx.google.com with ESMTPSA id kl1sm14368051pbd.73.2014.04.03.20.21.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 20:21:21 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4D1601F5-27FA-441C-9EE8-4069D14B2351@gmail.com> X-Mailer: iPad Mail (11D167) From: Bernard Aboba Date: Thu, 3 Apr 2014 20:21:20 -0700 To: Watson Ladd Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bQLI2JDOjuhKkc6X6-4rXjndY3o Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 03:21:33 -0000 > On Apr 3, 2014, at 19:49, Watson Ladd wrote: >=20 > I don't see why the isolation status cannot be included as an > extension to SRTP. You aren't asking TLS to make extensions for video > resolution and codec after all. [BA] The isolation request could be carried in an RTP header extension until= , for example, a RR was obtained by the sender confirming it was received. H= owever, RTP extensions are optional and the sender wouldn't have confirmatio= n from the receiver via the media plane that the isolation request was honor= ed. So the TLS approach provides better semantics.= From nobody Thu Apr 3 20:25:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B8C1A008D for ; Thu, 3 Apr 2014 20:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 fALUo4FCHJXg for ; Thu, 3 Apr 2014 20:25:26 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id CCCD21A03E8 for ; Thu, 3 Apr 2014 20:25:25 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id f73so2614661yha.13 for ; Thu, 03 Apr 2014 20:25:21 -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:content-type:content-transfer-encoding; bh=yOWA897ANrOwB/8WK1trsFoM07deXiM1fAuXqKlJlS0=; b=J3GTmk7BptIN+6YyV0gghq9OCbYD3Bgl/DL22kBEWQj6mXvJ+N8J267nZ50RwwVTnA hw19UTAQMI2gu2CpL7taXWkwj9D/jof9kJb0in8g0WRuA48ylJDK9gGWKrgKZhhSeNZk FYVIkmWDRk5dHzVOVlgynB+j+WvMQMK/eLYexIYZBR38eCb2cIvDg090DxuTK9ELqTcY kLJhf/eHs9aYcqOWdhF3890dYmIN2Zd7g7Tn4rpskqIW4es+J7M2SUhcSYG5WmiGp3/q LMTeWF1utbdHQD1gziRj+TEGuTjlPLffCkQrxUj8aJmg6upW3O3MhY7/z5dm2JbrMl6b gQkA== MIME-Version: 1.0 X-Received: by 10.236.148.143 with SMTP id v15mr13488608yhj.58.1396581921385; Thu, 03 Apr 2014 20:25:21 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Thu, 3 Apr 2014 20:25:21 -0700 (PDT) In-Reply-To: <4D1601F5-27FA-441C-9EE8-4069D14B2351@gmail.com> References: <4D1601F5-27FA-441C-9EE8-4069D14B2351@gmail.com> Date: Thu, 3 Apr 2014 20:25:21 -0700 Message-ID: From: Watson Ladd To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ANhaudluUsoYq1LHWuxYtTEKPjU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 03:25:33 -0000 On Thu, Apr 3, 2014 at 8:21 PM, Bernard Aboba wro= te: > > >> On Apr 3, 2014, at 19:49, Watson Ladd wrote: >> >> I don't see why the isolation status cannot be included as an >> extension to SRTP. You aren't asking TLS to make extensions for video >> resolution and codec after all. > > [BA] The isolation request could be carried in an RTP header extension un= til, for example, a RR was obtained by the sender confirming it was receive= d. However, RTP extensions are optional and the sender wouldn't have confi= rmation from the receiver via the media plane that the isolation request wa= s honored. So the TLS approach provides better semantics. I feel this isn't worth changing TLS for, because you don't change transports for each application because the application didn't do it right the first time. But we have ALPN, so maybe a tag on that could work. The right fix IMHO, is clearly to fix RTP to send this data and keep the transport layer clean. Sincerely, Watson Ladd From nobody Thu Apr 3 20:26:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FF61A03CD for ; Thu, 3 Apr 2014 20:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 4IPbNgOIkkFL for ; Thu, 3 Apr 2014 20:25:57 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id CEE481A042B for ; Thu, 3 Apr 2014 20:25:56 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u57so2707554wes.22 for ; Thu, 03 Apr 2014 20:25:52 -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:content-type; bh=k1Esk/IphZuHorG1mQmgs/r/0kFmE7J/0dZxzOkoxz0=; b=r04avJLcr/ZXpM4FNKIo33+K53j65Qqq0orxwL43t/5vNR8JzWi7NKpRD1F55moNOh cSyO9ZAsPCOnbQuY8Pz6Cjcws+lQdYpqsidw+w3EKxegJDT8vXn0XydeQxRHRL6ENTmp 8UxUWcKPngv6gIkfKrCR5Z1+y8ex982cajJZNQfCBuBTErrl3NkaKdNCgkjjLHPmIsIB FIpn1wnmFzZH8syE/jqiIEopJLuOi3MErs9avWpZqqVzWyXd+gHCv2+MjiB/xZ5/m+cM D63w9pLoN8Gv0nx64JeaAjsJIiv+T6/uAjKEzyqXiBYUsdBgttHlXAuC8zylla6eDdCr u3zg== MIME-Version: 1.0 X-Received: by 10.194.204.199 with SMTP id la7mr16206554wjc.4.1396581952033; Thu, 03 Apr 2014 20:25:52 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Thu, 3 Apr 2014 20:25:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Apr 2014 20:25:51 -0700 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BaWDWz97KpuPbYNwQltnpwXtDsw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 03:26:05 -0000 Perhaps some more context is necessary. (D)TLS provides us good protection against network attackers. The problem is that this protection ends at the browser, and our security story doesn't. Media streams in the browser are an extension of those that traverse the network, and we need something of a gentlemen's agreement between browsers to be reached. That agreement says that your browser and mine will agree between themselves to protect media from the application that is running in their sandbox: all that nasty JavaScript that came from a site (or sites) that we might not want to include in our conversation. On 3 April 2014 19:49, Watson Ladd wrote: > The MITM can kill any TLS connection containing the extension. My > understanding is that signalling data is immutable, hence the need to > ask the browser to generate it. Signaling is totally mutable, which is a big problem. Once an application gets it, there's a lot that can be changed between peers. >> However once the desire for isolation is communicated E2E (either via ACP or >> ALPN tokens), there is nothing in the SRTP traffic (keyed by DTLS/SRTP) that >> indicates that the traffic is to be isolated. > > I don't see why the isolation status cannot be included as an > extension to SRTP. You aren't asking TLS to make extensions for video > resolution and codec after all. That's a good question, and it's an option I should have added to the list. The problem there is that nothing in RTP is reliable, and this signal needs to be reliable. Combine that with the fact that the extent of an RTP session is essentially unknowable, and you end up having to put an RTP header extension on every packet. RTP header extensions have other drawback as well, though I suspect most of those aren't applicable in this context. With the TLS handshake, you either get a marked session, or you don't get a session at all. That's a big advantage with this approach. And it costs far fewer bytes. From nobody Fri Apr 4 01:51:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899C91A0453 for ; Fri, 4 Apr 2014 01:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bnPj_jZAXEue for ; Fri, 4 Apr 2014 01:51:52 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id BA6A91A0452 for ; Fri, 4 Apr 2014 01:51:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6FEFE7C5267; Fri, 4 Apr 2014 10:51:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLb5GVkKubeP; Fri, 4 Apr 2014 10:51:46 +0200 (CEST) Received: from [10.20.1.105] (114.red-80-28-236.adsl.static.ccgg.telefonica.net [80.28.236.114]) by mork.alvestrand.no (Postfix) with ESMTPSA id 953EC7C5266; Fri, 4 Apr 2014 10:51:45 +0200 (CEST) Message-ID: <533E729F.4000302@alvestrand.no> Date: Fri, 04 Apr 2014 10:51:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Tuexen References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------000409000804030407070504" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/P8c8rz26W8_M1pxCtCo7M7zJtFM Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 08:51:57 -0000 This is a multi-part message in MIME format. --------------000409000804030407070504 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit I assume this is the scheduler envisioned in -ndata: SCTP_SS_PRIORITY: Scheduling with different priorities is used. Streams having a higher priority will be scheduled first and when multiple streams have the same priority, the default scheduling should be used for them. The priority can be assigned with the sctp_stream_value struct. The higher the assigned value, the lower the priority, that is the default value 0 is the highest priority and therefore the default scheduling will be used if no priorities have been assigned. This sounds like a "strict" scheduler, in that higher priority queues will starve out lower priority ones completely. I remember having the discussion at an IETF meeting about whether we wanted a "strict" scheduler or a "weighted round robin" scheduler for this, but I wouldn't trust my memory with what the conclusion was. Was the conclusion that we should do "strict" scheduling? If so, it may be best to make that consistent across the board - I had written in a "weighted" scheduler for media into the prioritization text that I started this thread with, but I think there's value to consistency. (Note: -ndata has SS_PRIORITY in one place and SS_PRIO / SS_PRIO_INTER in another place. Is there a subtlety here I'm not seeing?) --------------000409000804030407070504 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit I assume this is the scheduler envisioned in -ndata:


      SCTP_SS_PRIORITY:  Scheduling with different priorities is used.
         Streams having a higher priority will be scheduled first and
         when multiple streams have the same priority, the default
         scheduling should be used for them.  The priority can be
         assigned with the sctp_stream_value struct.  The higher the
         assigned value, the lower the priority, that is the default
         value 0 is the highest priority and therefore the default
         scheduling will be used if no priorities have been assigned.

This sounds like a "strict" scheduler, in that higher priority queues will starve out lower priority ones completely. I remember having the discussion at an IETF meeting about whether we wanted a "strict" scheduler or a "weighted round robin" scheduler for this, but I wouldn't trust my memory with what the conclusion was.

Was the conclusion that we should do "strict" scheduling? If so, it may be best to make that consistent across the board - I had written in a "weighted" scheduler for media into the prioritization text that I started this thread with, but I think there's value to consistency.

(Note: -ndata has SS_PRIORITY in one place and SS_PRIO / SS_PRIO_INTER in another place. Is there a subtlety here I'm not seeing?)



--------------000409000804030407070504-- From nobody Fri Apr 4 02:03:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEED91A00E3 for ; Fri, 4 Apr 2014 02:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7xuRFLMu_Jfb for ; Fri, 4 Apr 2014 02:03:07 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8B61A043C for ; Fri, 4 Apr 2014 02:03:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C880D7C526A; Fri, 4 Apr 2014 11:03:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP6SBNy7RFcu; Fri, 4 Apr 2014 11:03:00 +0200 (CEST) Received: from [10.20.1.105] (114.red-80-28-236.adsl.static.ccgg.telefonica.net [80.28.236.114]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2D6EF7C5266; Fri, 4 Apr 2014 11:02:58 +0200 (CEST) Message-ID: <533E753F.4090902@alvestrand.no> Date: Fri, 04 Apr 2014 11:02:55 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Bernard Aboba , Martin Thomson References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> <5339385D.6070006@ericsson.com> <53397036.5050104@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF82B7921@DEMUMBX005.nsn-intra.net> <533984DD.2020804@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------060809030006020309050001" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CtxqkBekf9iXraI7sE7L-NaiZGs Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:03:15 -0000 This is a multi-part message in MIME format. --------------060809030006020309050001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/03/2014 10:44 PM, Bernard Aboba wrote: > Martin said: > > "The marginal benefit remains...tiny relative to the cost" > > [BA] This is particularly true if you consider *all* of the additional > work items required to enable the usage scenario. It is one thing to > support SRTP/SRTCP over RFC 4571 framing, but without also > encapsulating DTLS/SRTP over RFC 4571 framing, how do you reliably > obtain the SRTP/SRTCP master keys? Similarly, do we also run > SCTP/DTLS data channel over RFC 4571 framing? In my experience, > without a great deal of care, running one reliable transport over > another can works poorly if packet loss is encountered (e.g. the > time-out periods interfere with one another). One result of the London discussion was that I read the TCP TURN candidate specification, and found that it most explicitly states that you use 4571 framing for DTLS. Since it would be very silly to have two types of TCP candidates with different encapsulation strategies, I wrote in 4571 framing for DTLS too. "The absence of alternatives clears the mind marvellously". RFC 4571 is a framing protocol without support for resynchronization. So it depends on getting whole frames through - something that seems to be hard to achieve with POSIX TCP send() semantics. A simple implementation would use blocking writes, in which case packet loss at the higher level could not occur; another implementation strategy would use non-blocking mode and drop packets from a higher level buffer if the TCP transmission buffer filled up, leading to the two-level packet loss issue mentioned. Which implementation strategy would people expect to use? -- Surveillance is pervasive. Go Dark. --------------060809030006020309050001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 04/03/2014 10:44 PM, Bernard Aboba wrote:
Martin said: 

"The marginal benefit remains...tiny relative to the cost"

[BA] This is particularly true if you consider *all* of the additional work items required to enable the usage scenario.  It is one thing to support SRTP/SRTCP over RFC 4571 framing, but without also  encapsulating DTLS/SRTP over RFC 4571 framing, how do you reliably obtain the SRTP/SRTCP master keys?  Similarly, do we also run SCTP/DTLS data channel over RFC 4571 framing?   In my experience, without a great deal of care, running one reliable transport over another can works poorly if packet loss is encountered (e.g. the time-out periods interfere with one another).  

One result of the London discussion was that I read the TCP TURN candidate specification, and found that it most explicitly states that you use 4571 framing for DTLS.

Since it would be very silly to have two types of TCP candidates with different encapsulation strategies, I wrote in 4571 framing for DTLS too.

"The absence of alternatives clears the mind marvellously".

RFC 4571 is a framing protocol without support for resynchronization. So it depends on getting whole frames through - something that seems to be hard to achieve with POSIX TCP send() semantics. A simple implementation would use blocking writes, in which case packet loss at the higher level could not occur; another implementation strategy would use non-blocking mode and drop packets from a higher level buffer if the TCP transmission buffer filled up, leading to the two-level packet loss issue mentioned.

Which implementation strategy would people expect to use?
-- 
Surveillance is pervasive. Go Dark.
--------------060809030006020309050001-- From nobody Fri Apr 4 02:09:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124B11A03D1 for ; Fri, 4 Apr 2014 02:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 AmNKQr83hg0p for ; Fri, 4 Apr 2014 02:09:07 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7BF1A03C2 for ; Fri, 4 Apr 2014 02:09:06 -0700 (PDT) X-AuditID: c1b4fb32-b7fe98e0000034f3-8b-533e76acd444 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id BC.39.13555.CA67E335; Fri, 4 Apr 2014 11:09:01 +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.174.1; Fri, 4 Apr 2014 11:09:00 +0200 Message-ID: <533E76AC.7030003@ericsson.com> Date: Fri, 4 Apr 2014 11:09:00 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42KZGfG3RndtmV2wwdEXHBbLX55gtFj7r53d gclj2v37bB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY/3A/W8ENy4ofr/cwNjBO0O1i5OCQEDCR mPWpoIuRE8gUk7hwbz1bFyMXh5DASUaJs/fb2SGcZYwSH2asZQOp4hXQlrjZtJoVxGYRUJFY fPUVO4jNJmAhcfNHI1iNqECwxNI5i1kg6gUlTs58AmaLCKhLXH54AayeWUBV4vy+82BzhAXs JW5/+sgKcZC4RE9jEESJnsSUqy2MELa8RPPW2cwgthDQCQ1NHawTGAVmIdkwC0nLLCQtCxiZ VzFKFqcWF+emGxno5abnluilFmUmFxfn5+kVp25iBAbnwS2/jXYwntxjf4hRmoNFSZz3OmtN kJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGoWYzg+o96hbvituZ6jkq/l0Sun9cTe/s4U69 CWncxZO3B0QxlUzfKSRyL9DwGr+Lxa/Z+360m8T/vZN/8uSmO92SU2tm/d3TzyLFlTj16mdp 7Uip3ZkSk2qm7G5yZeXsPlXNZrTgmdYSxidcFt82HpSInZvW7x12qWDTFnXVavWKhIyIwmYl luKMREMt5qLiRAAnqeU7HAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HBQMsXjDrVPsyYM24llO__T5eFo Cc: Colin Perkins Subject: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:09:11 -0000 WG, (As author) Based on the discussion we authors have drafted a proposal for changing the CNAME creation usage to be created unique between PeerConnections. Our draft text is the below one. Please review. If we receive no feedback we will include this in the next version of the draft that we hope to be able to produce next week. Section 4.1: o Support for multiple synchronisation contexts. Participants that send multiple simultaneous RTP packet streams do so as part of a single synchronisation context, using a single RTCP CNAME for all streams and allowing receivers to play the streams out in a synchronised manner. Receivers MUST support reception of multiple RTCP CNAMEs in an RTP session, and hence multiple synchronisation contexts, to support RTP middleboxes, and future evolution needing multiple CNAMEs in an endpoint. See also Section 4.9. Section 4.9: 4.9. Generation of the RTCP Canonical Name (CNAME) The RTCP Canonical Name (CNAME) provides a persistent transport-level identifier for an RTP end-point. While the Synchronisation Source (SSRC) identifier for an RTP end-point can change if a collision is detected, or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP end-points can be uniquely identified and associated with their RTP packet streams within a set of related RTP sessions. For proper functionality, each RTP end- point needs to have at least one unique RTCP CNAME value. From an RTP perspective an end-point can have multiple CNAMEs, as the CNAME also identifies a particular synchronisation context, i.e. all SSRC associated with a CNAME share a common reference clock, and if an end-point have SSRCs associated with different reference clocks it will need to use multiple CNAMEs. This ought not be common, and if possible reference clocks ought to be mapped to each other and one chosen to be used with RTP and RTCP. Taking the discussion in Section 11 into account a regular WebRTC end-point MUST NOT use more than a single CNAME in the RTP sessions belonging to single RTCPeerConnection. RTP middleboxes MAY send RTP packet streams identified by more than one CNAME, to allow them to avoid having to resynchronize media from multiple different end-points part of a multi-party RTP session. The RTP specification [RFC3550] includes guidelines for choosing a unique RTP CNAME, but these are not sufficient in the presence of NAT devices. In addition, long-term persistent identifiers can be problematic from a privacy viewpoint (Section 13). Accordingly, support for generating a short-term persistent RTCP CNAMEs following [RFC7022] is REQUIRED to be implemented and RECOMMENDED to be used. Unless a persistent CNAME is explicitly configured, a unique CNAME(s) MUST be generated for each synchronization context an end-point has within each RTCPeerConnection, i.e. normally one across all the RTP sessions within the scope of the RTCPeerConnection. There are no known reasons for WebRTC end-points that aren't RTP middleboxes or servers to configure a persistent identifiers, these considerations are limited to RTP middleboxes. Thus, such configuration options SHOULD NOT be present in most WebRTC end- point implementations to prevent misconfiguration or malicious configuration that allows tracking or linking of a user. An WebRTC end-point MUST support reception of any CNAME that matches the syntax limitations specified by the RTP specification [RFC3550] and cannot assume that any CNAME will be chosen according to the form suggested above. Section 11: The same MediaStreamTrack can also be included in multiple MediaStreams, thus multiple sets of MediaStreams can implicitly need to use the same synchronisation base. To ensure that this works in all cases, and don't forces a end-point to change synchronisation base and CNAME in the middle of a ongoing delivery of any packet streams, which would cause media disruption; all MediaStreamTracks and their associated SSRCs originating from the same end-point needs to be sent using the same CNAME within one RTCPeerConnection. This is motivating the strong recommendation in Section 4.9 to only use a single CNAME. Note: It is important that the same CNAME is not used in different communication session contexts or origins, as that could enable tracking of a user and its device usage of different services. See Section 4.4.1 of Security Considerations for WebRTC [I-D.ietf-rtcweb-security] for further discussion. The requirement on using the same CNAME for all SSRCs that originates from the same end-point, does not require middleboxes that forwards traffic from multiple end-points to only use a single CNAME. The above will currently force a WebRTC end-point that receives an MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing on any RTCPeerConnection to perform resynchronisation of the stream. This, as the sending party needs to change the CNAME, which implies that it has to use a locally available system clock as timebase for the synchronisation. Thus, the relative relation between the timebase of the incoming stream and the system sending out needs to defined. This relation also needs monitoring for clock drift and likely adjustments of the synchronisation. The sending entity is also responsible for congestion control for its the sent streams. In cases of packet loss the loss of incoming data also needs to be handled. This leads to the observation that the method that is least likely to cause issues or interruptions in the outgoing source packet stream is a model of full decoding, including repair etc followed by encoding of the media again into the outgoing packet stream. Optimisations of this method is clearly possible and implementation specific. A WebRTC end-point MUST support receiving multiple MediaStreamTracks, where each of different MediaStreamTracks (and their sets of associated packet streams) uses different CNAMEs. However, MediaStreamTracks that are received with different CNAMEs have no defined synchronisation. Note: The motivation for supporting reception of multiple CNAMEs are to allow for forward compatibility with any future changes that enables more efficient stream handling when end-points relay/ forward streams. It also ensures that end-points can interoperate with certain types of multi-stream middleboxes or end-points that are not WebRTC. -- 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 4 02:24:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CD61A0213 for ; Fri, 4 Apr 2014 02:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 AxGNTVOhB3x9 for ; Fri, 4 Apr 2014 02:24:38 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id CB5991A001D for ; Fri, 4 Apr 2014 02:24:37 -0700 (PDT) X-AuditID: c1b4fb32-b7fe98e0000034f3-dd-533e7a5091bb Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 03.FA.13555.05A7E335; Fri, 4 Apr 2014 11:24:32 +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.174.1; Fri, 4 Apr 2014 11:24:32 +0200 Message-ID: <533E7A50.5040909@ericsson.com> Date: Fri, 4 Apr 2014 11:24:32 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupiluLIzCtJLcpLzFFi42KZGfG3Rjegyi7Y4OciY4vlL08wWqz9187u wOQx7f59No8lS34yBTBFcdmkpOZklqUW6dslcGUc//yGtWCDWsXuafdZGhhvyXUxcnJICJhI PFiwnA3CFpO4cG89kM3FISRwklFixa4prBDOMkaJ2Yt/MoNU8QpoSzyb/Z8FxGYRUJFY8v8+ K4jNJmAhcfNHI9gkUYFgiaVzFrNA1AtKnJz5BMwWEVCXuPzwAjuIzSygKnF+33mwXmGBSIm/ u1cD9XIAXSEu0dMYBFGiJzHlagsjhC0v0bx1NtgJQkAnNDR1sE5gFJiFZMMsJC2zkLQsYGRe xShZnFpcnJtuZKCXm55bopdalJlcXJyfp1ecuokRGJ4Ht/w22sF4co/9IUZpDhYlcd7rrDVB QgLpiSWp2ampBalF8UWlOanFhxiZODilGhhD69YYvciYyLn/8veGMwdlVKb6P9v02F/u5h2b mxcWnaxSdun/o/1gKnPgS03fHY59yQfbCl/bivccONedJvHQbi/H40OTdtjnzXl75opRzeII b/Xfr9cWaDEwdt606ltx0EboQZ9W1po7u/yOOr7kVmUN2XfGkaFqU9rSEAbd6i3GUefCT+xT YinOSDTUYi4qTgQAN2/XDB0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Tbyay8-zE9sm-QIGfkg1jr2phlQ Cc: Colin Perkins Subject: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:24:42 -0000 WG, (As Author) Colin and I have been working on resolving terminology usage and in general giving the draft a polish over before the WG last call. One section that has gotten quite some attention from us is the below one. The changes are significantly from an editorial stand point. However, the intended content has not been intended to be changed, although clarified and better motivated. So please review it, we intended to include this in the upcoming draft update. Feedback appreciated. 5.1. Conferencing Extensions and Topologies RTP is a protocol that inherently supports group communication. Groups can be implemented by having each endpoint sending its RTP packet streams to an RTP middlebox that redistributes the traffic, by using a mesh of unicast RTP packet streams between endpoints, or by using an IP multicast group to distribute the RTP packet streams. These topologies can be implemented in a number of ways as discussed in [I-D.ietf-avtcore-rtp-topologies-update]. While the use of IP multicast groups is popular in IPTV systems, the topologies based on RTP middleboxes are dominant in interactive video conferencing environments. Topologies based on a mesh of unicast transport-layer flows to create a common RTP session have not seen widespread deployment. Accordingly, WebRTC implementations are not expected to support topologies based on IP multicast groups. WebRTC implementations are also not expected to support mesh-based topologies, such as a point-to-multipoint mesh configured as a single RTP session (Topo-Mesh in the terminology of [I-D.ietf-avtcore-rtp-topologies-update]). However, a point-to- multipoint mesh constructed using several RTP sessions, in the WebRTC context using independent RTCPeerConnections can be expected to be utilised by WebRTC applications. WebRTC implementations of RTP endpoints implemented according to this memo are expected to support all the topologies described in [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send and receive unicast RTP packet streams to some peer device, provided that peer can participate in performing congestion control on the RTP packet streams. The peer device could be another RTP endpoint, or it could be an RTP middlebox that redistributes the RTP packet streams to other RTP endpoints. This limitation means that some of the RTP middlebox-based topologies are not suitable for use in the WebRTC environment. Specifically: o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, since they make the use of RTCP for congestion control and quality of service reports problematic (see Section 3.6.2 of [I-D.ietf-avtcore-rtp-topologies-update]). o Content modifying MCUs with RTCP termination (Topo-RTCP- terminating-MCU) SHOULD NOT be used since they break RTP loop detection, and prevent receivers from identifying active senders (see section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]). o The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology SHOULD NOT be used because its safe use requires a point to multipoint congestion control algorithm or RTP circuit breaker, which has not yet been standardised. The RTP extensions described in Section 5.1.1 to Section 5.1.6 are designed to be used with centralised conferencing, where an RTP middlebox (e.g., a conference bridge) receives a participant's RTP packet streams and distributes them to the other participants. These extensions are not necessary for interoperability; an RTP end-point that does not implement these extensions will work correctly, but might offer poor performance. Support for the listed extensions will greatly improve the quality of experience and, to provide a reasonable baseline quality, some of these extensions are mandatory to be supported by WebRTC end-points. The RTCP conferencing extensions are defined in Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio- Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124]. 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 Fri Apr 4 02:31:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94561A0127 for ; Fri, 4 Apr 2014 02:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 1E0mggdmH65F for ; Fri, 4 Apr 2014 02:31:17 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 173B41A001D for ; Fri, 4 Apr 2014 02:31:16 -0700 (PDT) X-AuditID: c1b4fb38-b7f518e000000889-f9-533e7bdf970d Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id A1.50.02185.FDB7E335; Fri, 4 Apr 2014 11:31:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.174.1; Fri, 4 Apr 2014 11:31:11 +0200 Message-ID: <533E7BDF.8030903@ericsson.com> Date: Fri, 4 Apr 2014 11:31:11 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvje79artgg4eXdCyWvzzBaLH2Xzu7 A5PHtPv32TyWLPnJFMAUxWWTkpqTWZZapG+XwJXx69dBxoIfshU37z1jbGB8L97FyMkhIWAi cWLqBzYIW0ziwr31QDYXh5DAUUaJS7O7WCGcZYwSL37PYQKp4hXQlji+bTsziM0ioCLxYc86 sG42AQuJmz8awWxRgWCJpXMWs0DUC0qcnPkEzBYRUJe4/PACO4jNLKAqcX7feVYQW1ggXmLP 5xtANRxAV4hL9DQGQZToSUy52sIIYctLNG+dDbZWCOiEhqYO1gmMArOQbJiFpGUWkpYFjMyr GDmKU4uTctONDDYxAoPv4JbfFjsYL/+1OcQozcGiJM778a1zkJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQZGG5lJxa8WR2zYV1XweFn4YUth37Ur75ifaYuMclAsSXs/2fn/9G/fch5P3rx9 0cy3/Wk5XdEeeeaTM6uKupk+6KbxBGdmXb2ypUd9eYrxdZkstt3hMcZHPy45/z3ytNfLUzdX ZMxNMjS5a3kw+/QM07OJYZaJWw+1yczZUHr3yIrSgEur7WKYlFiKMxINtZiLihMBQxm9SwwC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/l20gSkm75SV67qoE_XlEJ3mtQlk Cc: Colin Perkins Subject: [rtcweb] Text proposal for change regarding Audio level security in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:31:22 -0000 WG, (As Author) There was some discussion at the meeting and afterwards regarding the encryption of the audio level header extensions. This made us authors review the text on this. We have clarified the text to require implementation of header extension encryption and recommend usage, unless explicitly requested to turn it off. See text below from Section 5.2.2., 5.2.3 and Section 13. We appreciate feedback on this change. We plan to include this in the next draft update. 5.2.2. Client-to-Mixer Audio Level The Client to Mixer Audio Level extension [RFC6464] is an RTP header extension used by a client to inform a mixer about the level of audio activity in the packet to which the header is attached. This enables an RTP middlebox to make mixing or selection decisions without decoding or detailed inspection of the payload, reducing the complexity in some types of mixer. It can also save decoding resources in receivers, which can choose to decode only the most relevant RTP packet streams based on audio activity levels. The Client-to-Mixer Audio Level [RFC6464] extension is RECOMMENDED to be implemented. If the header extension is implemented, it is REQUIRED that implementations is capable of encrypting the header extension according to [RFC6904] since the information contained in these header extensions can be considered sensitive. It is further RECOMMENDED that this encryption is used, unless the encryption has been explicitly requested to be turned off through API or signalling. 5.2.3. Mixer-to-Client Audio Level The Mixer to Client Audio Level header extension [RFC6465] provides the client with the audio level of the different sources mixed into a common mix by a RTP mixer. This enables a user interface to indicate the relative activity level of each session participant, rather than just being included or not based on the CSRC field. This is a pure optimisations of non critical functions, and is hence OPTIONAL to implement. If the header extension is implemented, it is REQUIRED that implementations are capable of encrypting the header extension according to [RFC6904] since the information contained in these header extensions can be considered sensitive. It is further RECOMMENDED that this encryption is used, unless the encryption has been explicitly requested to be turned off through API or signalling. Section 13: The guidelines in [RFC6562] apply when using variable bit rate (VBR) audio codecs such as Opus (see Section 4.3 for discussion of mandated audio codecs). These guidelines in [RFC6562] also apply, but are of lesser importance, when using the client-to-mixer audio level header extensions (Section 5.2.2) or the mixer-to-client audio level header extensions (Section 5.2.3). The use of the encryption of the header extensions are RECOMMENDED, unless there are known reasons, like middleboxes or third party monitoring that will greatly benefit from the information, and this has been expressed using API or signalling. If further evidence are produced to show that information leakage is significant from audio level indications, then use of encryption needs to be mandated at that time. 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 Fri Apr 4 03:48:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01391A010E for ; Fri, 4 Apr 2014 03:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Xnel5Z-7qHLi for ; Fri, 4 Apr 2014 03:48:42 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 31D731A0090 for ; Fri, 4 Apr 2014 03:48:41 -0700 (PDT) Received: from [192.168.1.103] (p508F0F22.dip0.t-ipconnect.de [80.143.15.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 300B21C103E45; Fri, 4 Apr 2014 12:48:35 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <533E729F.4000302@alvestrand.no> Date: Fri, 4 Apr 2014 12:48:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E33D629-994C-49A9-A28B-72EE8B5EC10C@lurchi.franken.de> References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> <533E729F.4000302@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aBeib9OAMhHfyh5ljhHg3aUkbtk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 10:48:46 -0000 On 04 Apr 2014, at 10:51, Harald Alvestrand = wrote: > I assume this is the scheduler envisioned in -ndata: >=20 >=20 > SCTP_SS_PRIORITY: Scheduling with different priorities is used. > Streams having a higher priority will be scheduled first and > when multiple streams have the same priority, the default > scheduling should be used for them. The priority can be > assigned with the sctp_stream_value struct. The higher the > assigned value, the lower the priority, that is the default > value 0 is the highest priority and therefore the default > scheduling will be used if no priorities have been assigned. >=20 >=20 >=20 > This sounds like a "strict" scheduler, in that higher priority queues = will starve out lower priority ones completely. I remember having the = discussion at an IETF meeting about whether we wanted a "strict" = scheduler or a "weighted round robin" scheduler for this, but I wouldn't = trust my memory with what the conclusion was. It is. >=20 > Was the conclusion that we should do "strict" scheduling? If so, it = may be best to make that consistent across the board - I had written in = a "weighted" scheduler for media into the prioritization text that I = started this thread with, but I think there's value to consistency. No, in an IETF WG meeting we discussed this a while ago and the result = was a non-strict priority, weighted fair queueing. This scheduling discipline in not = there yet. >=20 > (Note: -ndata has SS_PRIORITY in one place and SS_PRIO / SS_PRIO_INTER = in another place. Is there a subtlety here I'm not seeing?) Yes, there is a difference. It is about interleaving. You can use = SS_PRIO with or without NDATA, SS_PRIO_INTER only with NDATA. This document still needs some work... Even the constant names might = change... Best regards Michael >=20 >=20 >=20 From nobody Fri Apr 4 04:56:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5681A0159 for ; Fri, 4 Apr 2014 04:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 aETQtxGRHABF for ; Fri, 4 Apr 2014 04:55:57 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE031A0150 for ; Fri, 4 Apr 2014 04:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5140; q=dns/txt; s=iport; t=1396612553; x=1397822153; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Je8mcw7zBUrGBn4dx4YgekYjWptGPntHeRle9J/wMcI=; b=fpgquRvlv51sudB4hcwBFKVZx3RNM08XNiURrg4Femaq380Jsscmhnfk hG287e77PpfE35c8X4NLLpPLr3bpDj/jOM/UMr1wvgEMnZVUt64UEZnni +PYRB3Zlnd7+IEnL5/xl6gcsduRTZcdGKvMQbUv6LHwKxtMO4d/TBW2PW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFABydPlOtJV2Z/2dsb2JhbABXgwY7vS2GZlGBIRZ0giYBAQQBAQFrCxACAQgEOwcnCxQRAgQOBYd5Dc9FEwSObQQHgySBFASYW5I/gzA X-IronPort-AV: E=Sophos; i="4.97,794,1389744000"; d="scan'208,217"; a="32873017" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 04 Apr 2014 11:55:52 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s34BtqD0005374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Apr 2014 11:55:52 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.223]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 4 Apr 2014 06:55:52 -0500 From: "Jeremy Laurenson (jlaurens)" To: Harald Alvestrand Thread-Topic: [rtcweb] Some language on "prioritization" Thread-Index: AQHPTQQDWxs70GX+sEyRTuoH7KG0U5r7yb4AgAABW4CAAAFwAIAAAHSAgASgwACAAC0sgIAA5RSA///foSE= Date: Fri, 4 Apr 2014 11:55:50 +0000 Message-ID: References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> , <533E729F.4000302@alvestrand.no> In-Reply-To: <533E729F.4000302@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CC8CDB3B530D40FAA3F491177C64A6BFciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mqiLYQLxQK0fD8lHk8qJtYrjOK0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 11:56:01 -0000 --_000_CC8CDB3B530D40FAA3F491177C64A6BFciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do we really want the default (lazy coder) behavior to be highest priority = in this case? I assume the priority is browser-wide and so this could disrupt other app's= streams? J On Apr 4, 2014, at 4:52 AM, "Harald Alvestrand" > wrote: I assume this is the scheduler envisioned in -ndata: SCTP_SS_PRIORITY: Scheduling with different priorities is used. Streams having a higher priority will be scheduled first and when multiple streams have the same priority, the default scheduling should be used for them. The priority can be assigned with the sctp_stream_value struct. The higher the assigned value, the lower the priority, that is the default value 0 is the highest priority and therefore the default scheduling will be used if no priorities have been assigned. This sounds like a "strict" scheduler, in that higher priority queues will = starve out lower priority ones completely. I remember having the discussion= at an IETF meeting about whether we wanted a "strict" scheduler or a "weig= hted round robin" scheduler for this, but I wouldn't trust my memory with w= hat the conclusion was. Was the conclusion that we should do "strict" scheduling? If so, it may be = best to make that consistent across the board - I had written in a "weighte= d" scheduler for media into the prioritization text that I started this thr= ead with, but I think there's value to consistency. (Note: -ndata has SS_PRIORITY in one place and SS_PRIO / SS_PRIO_INTER in a= nother place. Is there a subtlety here I'm not seeing?) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CC8CDB3B530D40FAA3F491177C64A6BFciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Do we really want the default (lazy coder) behavior to be highest prio= rity in this case?

I assume the priority is browser-wide and so this could disrupt other = app's streams?

J


On Apr 4, 2014, at 4:52 AM, "Harald Alvestrand" <harald@alvestrand.no> wrote:

I assume this is the scheduler envisioned in -ndata:

      SCTP_SS_PRIORITY:  Scheduling with different priorities is used.
         Streams having a higher priority will be scheduled first and
         when multiple streams have the same priority, the default
         scheduling should be used for them.  The priority can be
         assigned with the sctp_stream_value struct.  The higher the
         assigned value, the lower the priority, that is the default
         value 0 is the highest priority and therefore the default
         scheduling will be used if no priorities have been assigned.

This sounds like a "strict" scheduler, in that higher priority qu= eues will starve out lower priority ones completely. I remember having the = discussion at an IETF meeting about whether we wanted a "strict" = scheduler or a "weighted round robin" scheduler for this, but I wouldn't trust my memory with what the conclusion was.

Was the conclusion that we should do "strict" scheduling? If so, = it may be best to make that consistent across the board - I had written in = a "weighted" scheduler for media into the prioritization text tha= t I started this thread with, but I think there's value to consistency.

(Note: -ndata has SS_PRIORITY in one place and SS_PRIO / SS_PRIO_INTER in a= nother place. Is there a subtlety here I'm not seeing?)



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_CC8CDB3B530D40FAA3F491177C64A6BFciscocom_-- From nobody Fri Apr 4 05:49:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02521A016B for ; Fri, 4 Apr 2014 05:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ZjH0lqTzMi59 for ; Fri, 4 Apr 2014 05:49:50 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id B02DE1A0141 for ; Fri, 4 Apr 2014 05:49:49 -0700 (PDT) Received: from [192.168.1.103] (p508F0F22.dip0.t-ipconnect.de [80.143.15.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DB89E1C1047F6; Fri, 4 Apr 2014 14:49:42 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: Date: Fri, 4 Apr 2014 14:49:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> , <533E729F.4000302@alvestrand.no> To: "Jeremy Laurenson (jlaurens)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sXLtUM7Qq9HhoC_CpF5HCojifn8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 12:49:53 -0000 On 04 Apr 2014, at 13:55, Jeremy Laurenson (jlaurens) = wrote: > Do we really want the default (lazy coder) behavior to be highest = priority in this case? Harald is referring to the SCTP socket API description. This won't be = exposed to the JS user. What will be exposed there needs to be defined by W3C = and will be mapped to the API of the SCTP implementation. >=20 > I assume the priority is browser-wide and so this could disrupt other = app's streams? The priories described below are only relevant for the streams of an = SCTP association. It is just a scheduler which deals with the streams of an = SCTP association. Best regards Michael >=20 > J >>=20 >=20 > On Apr 4, 2014, at 4:52 AM, "Harald Alvestrand" = wrote: >=20 >> I assume this is the scheduler envisioned in -ndata: >>=20 >> SCTP_SS_PRIORITY: Scheduling with different priorities is = used. >> Streams having a higher priority will be scheduled first and >> when multiple streams have the same priority, the default >> scheduling should be used for them. The priority can be >> assigned with the sctp_stream_value struct. The higher the >> assigned value, the lower the priority, that is the default >> value 0 is the highest priority and therefore the default >> scheduling will be used if no priorities have been assigned. >>=20 >>=20 >>=20 >> This sounds like a "strict" scheduler, in that higher priority queues = will starve out lower priority ones completely. I remember having the = discussion at an IETF meeting about whether we wanted a "strict" = scheduler or a "weighted round robin" scheduler for this, but I = wouldn't trust my memory with what the conclusion was. >>=20 >> Was the conclusion that we should do "strict" scheduling? If so, it = may be best to make that consistent across the board - I had written in = a "weighted" scheduler for media into the prioritization text that I = started this thread with, but I think there's value to consistency. >>=20 >> (Note: -ndata has SS_PRIORITY in one place and SS_PRIO / = SS_PRIO_INTER in another place. Is there a subtlety here I'm not = seeing?) >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Apr 4 08:41:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D001A021E for ; Fri, 4 Apr 2014 08:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 qsbOUWwN8dJn for ; Fri, 4 Apr 2014 08:41:51 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4830C1A0152 for ; Fri, 4 Apr 2014 08:41:51 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so3566330wes.25 for ; Fri, 04 Apr 2014 08:41:46 -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:content-type; bh=rzGjZYNP0rXRMYXM+8fud7yIf7p7Jwbyozt+iJsOTbA=; b=pzGfGyBJ53tyV0JPPNK9xGftWoSO5XLb3F/7hk+RFVp69Arjd5iYkVw83JLEEQS0lW KDRRhCxziVIgxgmowLaM73ncHxzMGK383CuQocqY0KXffgi1NUTmRBjrNZUKo3xK+sWr 2DYtlXQGz6fJoJ5/afEi+S4N/mtqYR3CwFCGjlcS44vJxWI1O0YAPzMeChy/GNKH5QV6 oKY25fIk5X1SHbdk+Kj+RsRSZNIBF2F1SuUc3xOnxjQKCIuD7lKrmAua58lzk7meH0rc KYrgGShxS0psw2sZVGGX8FBKdqqBGdUXU6dCpajmJPpTzhxqsOgkTPouF5+Vg9uGGzgO 71RQ== MIME-Version: 1.0 X-Received: by 10.180.84.73 with SMTP id w9mr5535941wiy.58.1396626106321; Fri, 04 Apr 2014 08:41:46 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Fri, 4 Apr 2014 08:41:46 -0700 (PDT) In-Reply-To: <533E753F.4090902@alvestrand.no> References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> <5339385D.6070006@ericsson.com> <53397036.5050104@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF82B7921@DEMUMBX005.nsn-intra.net> <533984DD.2020804@alvestrand.no> <533E753F.4090902@alvestrand.no> Date: Fri, 4 Apr 2014 08:41:46 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/C2BZsd6s5rbBPGROj3UQ5Xlb7y4 Cc: Harald Alvestrand , "rtcweb@ietf.org" Subject: Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 15:41:56 -0000 On 4 April 2014 02:02, Harald Alvestrand wrote: > Which implementation strategy would people expect to use? I think that for TURN, we were planning on using non-blocking writes and discard packets that didn't make the cut. This means that a blocked congestion window would manifest as packet loss to upper layers. That way, at least congestion indications make it through to SCTP in some fashion. It's certainly not ideal, but I'm not sure that there is a good solution in this space (I do know some people who claim to have solved the problem of TCP congestion control within a TCP congestion controlled envelope, maybe you can ask them. From nobody Fri Apr 4 08:59:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87971A01F2 for ; Fri, 4 Apr 2014 08:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 7khrs-31d03D for ; Fri, 4 Apr 2014 08:59:44 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 39AB91A01E0 for ; Fri, 4 Apr 2014 08:59:44 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so3648255wgg.21 for ; Fri, 04 Apr 2014 08:59:39 -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:content-type:content-transfer-encoding; bh=NE5RAMWMhvVvt5/RprfersEBunHE7hOg55yg9x2FXpc=; b=HA3qqdX3vbS3+BwIvom9iJebB5Ph8lZd7+kDGe/INAIgnwnVbiWs/vWDL6o/En7otA wA74tsfn5z6T8zhYyVjsYRGO+BAkcvr5QwSMVR9hboKCJuyB55Xc1sgf9xJPhdQG3FmM q1jsGKxKXfMNJch/QaScOAyHRyADxUDV5breq/sb9AZg9o18UKbAdIS1zHvs9471/wYC 8ksCL3N390Fj2g1otafKumuP+m2Fn0IITlgQhiQz1NBxZxa+NJUFO3PdDp5tl6d4lKSE Of1D0iIqcf82mJexksQyV9FyiYVc6fozO1cPffPI1/1C4XX77LHjm/ZzqUPgGplYMQvX oMQA== MIME-Version: 1.0 X-Received: by 10.194.236.9 with SMTP id uq9mr21124487wjc.31.1396627179034; Fri, 04 Apr 2014 08:59:39 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Fri, 4 Apr 2014 08:59:38 -0700 (PDT) In-Reply-To: <533E76AC.7030003@ericsson.com> References: <533E76AC.7030003@ericsson.com> Date: Fri, 4 Apr 2014 08:59:38 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/J2-6bNZceUQbMtf31YzFPRfy95g Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 15:59:48 -0000 That's a lot of text. In the interests of maintaining privacy (specifically unlinkability), or the ability to do so, applications should be able to request that a given RTCPeerConnection use a different CNAME to other RTCPeerConnection instances in the same session context. Otherwise, a site operating a service would be unable to provide callers with anonymity or pseudonymity toward different remote peers. That's my minimum ask, but even that isn't ideal. Better yet would be to be privacy protecting by default. To avoid issues where CNAME needs to be consistent, allow sites to link RTCPeerConnections to allow for consistent CNAME use across "sessions". I haven't thought it through, but I can't think of a reason off the top of my head not to allow sites to specify a CNAME directly. After all, a site is perfectly able to use signaling to link sessions, so we're not giving anything away. A random value could be chosen in the absence of an explicit one. I realize that this does - to some extent - compromise the purity and integrity of your RTP usage. I think that it's worth it. The text you've provided gives good context for that. It just needs a different conclusion. Nits: This ought not be common, and if possible reference clocks ought to be mapped to each other and one chosen to be used with RTP and RTCP. I can't parse this. Accordingly, support for generating a short-term persistent RTCP CNAMEs following [RFC7022] is REQUIRED to be implemented and RECOMMENDED to be used. That's a strange statement. How will you know if someone has implemented 7022 if they aren't using it? Seems like a SHOULD to me. On 4 April 2014 02:09, Magnus Westerlund w= rote: > WG, > (As author) > > Based on the discussion we authors have drafted a proposal for changing > the CNAME creation usage to be created unique between PeerConnections. > Our draft text is the below one. Please review. If we receive no > feedback we will include this in the next version of the draft that we > hope to be able to produce next week. > > Section 4.1: > > o Support for multiple synchronisation contexts. Participants that > send multiple simultaneous RTP packet streams do so as part of a > single synchronisation context, using a single RTCP CNAME for all > streams and allowing receivers to play the streams out in a > synchronised manner. Receivers MUST support reception of multiple > RTCP CNAMEs in an RTP session, and hence multiple synchronisation > contexts, to support RTP middleboxes, and future evolution needing > multiple CNAMEs in an endpoint. See also Section 4.9. > > > Section 4.9: > > 4.9. Generation of the RTCP Canonical Name (CNAME) > > The RTCP Canonical Name (CNAME) provides a persistent transport-level > identifier for an RTP end-point. While the Synchronisation Source > (SSRC) identifier for an RTP end-point can change if a collision is > detected, or when the RTP application is restarted, its RTCP CNAME is > meant to stay unchanged, so that RTP end-points can be uniquely > identified and associated with their RTP packet streams within a set > of related RTP sessions. For proper functionality, each RTP end- > point needs to have at least one unique RTCP CNAME value. From an > RTP perspective an end-point can have multiple CNAMEs, as the CNAME > also identifies a particular synchronisation context, i.e. all SSRC > associated with a CNAME share a common reference clock, and if an > end-point have SSRCs associated with different reference clocks it > will need to use multiple CNAMEs. This ought not be common, and if > possible reference clocks ought to be mapped to each other and one > chosen to be used with RTP and RTCP. Taking the discussion in > Section 11 into account a regular WebRTC end-point MUST NOT use more > than a single CNAME in the RTP sessions belonging to single > RTCPeerConnection. RTP middleboxes MAY send RTP packet streams > identified by more than one CNAME, to allow them to avoid having to > resynchronize media from multiple different end-points part of a > multi-party RTP session. > > The RTP specification [RFC3550] includes guidelines for choosing a > unique RTP CNAME, but these are not sufficient in the presence of NAT > devices. In addition, long-term persistent identifiers can be > problematic from a privacy viewpoint (Section 13). Accordingly, > support for generating a short-term persistent RTCP CNAMEs following > [RFC7022] is REQUIRED to be implemented and RECOMMENDED to be used. > Unless a persistent CNAME is explicitly configured, a unique CNAME(s) > MUST be generated for each synchronization context an end-point has > within each RTCPeerConnection, i.e. normally one across all the RTP > sessions within the scope of the RTCPeerConnection. > > There are no known reasons for WebRTC end-points that aren't RTP > middleboxes or servers to configure a persistent identifiers, > these considerations are limited to RTP middleboxes. Thus, such > configuration options SHOULD NOT be present in most WebRTC end- > point implementations to prevent misconfiguration or malicious > configuration that allows tracking or linking of a user. > > An WebRTC end-point MUST support reception of any CNAME that matches > the syntax limitations specified by the RTP specification [RFC3550] > and cannot assume that any CNAME will be chosen according to the form > suggested above. > > Section 11: > > The same MediaStreamTrack can also be included in multiple > MediaStreams, thus multiple sets of MediaStreams can implicitly need > to use the same synchronisation base. To ensure that this works in > all cases, and don't forces a end-point to change synchronisation > base and CNAME in the middle of a ongoing delivery of any packet > streams, which would cause media disruption; all MediaStreamTracks > and their associated SSRCs originating from the same end-point needs > to be sent using the same CNAME within one RTCPeerConnection. This > is motivating the strong recommendation in Section 4.9 to only use a > single CNAME. > > Note: It is important that the same CNAME is not used in different > communication session contexts or origins, as that could enable > tracking of a user and its device usage of different services. > See Section 4.4.1 of Security Considerations for WebRTC > [I-D.ietf-rtcweb-security] for further discussion. > > The requirement on using the same CNAME for all SSRCs that > originates from the same end-point, does not require middleboxes > that forwards traffic from multiple end-points to only use a > single CNAME. > > The above will currently force a WebRTC end-point that receives an > MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing > on any RTCPeerConnection to perform resynchronisation of the stream. > This, as the sending party needs to change the CNAME, which implies > that it has to use a locally available system clock as timebase for > the synchronisation. Thus, the relative relation between the > timebase of the incoming stream and the system sending out needs to > defined. This relation also needs monitoring for clock drift and > likely adjustments of the synchronisation. The sending entity is > also responsible for congestion control for its the sent streams. In > cases of packet loss the loss of incoming data also needs to be > handled. This leads to the observation that the method that is least > likely to cause issues or interruptions in the outgoing source packet > stream is a model of full decoding, including repair etc followed by > encoding of the media again into the outgoing packet stream. > Optimisations of this method is clearly possible and implementation > specific. > > A WebRTC end-point MUST support receiving multiple MediaStreamTracks, > where each of different MediaStreamTracks (and their sets of > associated packet streams) uses different CNAMEs. However, > MediaStreamTracks that are received with different CNAMEs have no > defined synchronisation. > > Note: The motivation for supporting reception of multiple CNAMEs > are to allow for forward compatibility with any future changes > that enables more efficient stream handling when end-points relay/ > forward streams. It also ensures that end-points can interoperate > with certain types of multi-stream middleboxes or end-points that > are not WebRTC. > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Apr 4 09:35:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A611A020B for ; Fri, 4 Apr 2014 09:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Mk760geo8Zfi for ; Fri, 4 Apr 2014 09:35:06 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 372501A01F3 for ; Fri, 4 Apr 2014 09:35:06 -0700 (PDT) Received: from [130.209.247.112] (port=62100 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WW74y-0003up-AJ; Fri, 04 Apr 2014 17:35:00 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Colin Perkins In-Reply-To: Date: Fri, 4 Apr 2014 17:34:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org> References: <533E76AC.7030003@ericsson.com> To: Martin Thomson X-Mailer: Apple Mail (2.1874) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/imqrLzQMV9cLaHKFdUgVfgF7T1Q Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 16:35:11 -0000 Martin, I=92m perhaps misunderstanding something, or we may not have phrased the = text clearly, but what you say you want generally matches my = understanding of what the draft provides. Can you expand on what parts = of the text you think are problematic? Colin On 4 Apr 2014, at 16:59, Martin Thomson = wrote: > That's a lot of text. >=20 > In the interests of maintaining privacy (specifically unlinkability), > or the ability to do so, applications should be able to request that a > given RTCPeerConnection use a different CNAME to other > RTCPeerConnection instances in the same session context. Otherwise, a > site operating a service would be unable to provide callers with > anonymity or pseudonymity toward different remote peers. >=20 > That's my minimum ask, but even that isn't ideal. >=20 > Better yet would be to be privacy protecting by default. To avoid > issues where CNAME needs to be consistent, allow sites to link > RTCPeerConnections to allow for consistent CNAME use across > "sessions". >=20 > I haven't thought it through, but I can't think of a reason off the > top of my head not to allow sites to specify a CNAME directly. After > all, a site is perfectly able to use signaling to link sessions, so > we're not giving anything away. A random value could be chosen in the > absence of an explicit one. >=20 > I realize that this does - to some extent - compromise the purity and > integrity of your RTP usage. I think that it's worth it. The text > you've provided gives good context for that. It just needs a > different conclusion. >=20 > Nits: >=20 > This ought not be common, and if > possible reference clocks ought to be mapped to each other and one > chosen to be used with RTP and RTCP. >=20 > I can't parse this. >=20 > Accordingly, > support for generating a short-term persistent RTCP CNAMEs following > [RFC7022] is REQUIRED to be implemented and RECOMMENDED to be used. >=20 > That's a strange statement. How will you know if someone has > implemented 7022 if they aren't using it? Seems like a SHOULD to me. >=20 >=20 > On 4 April 2014 02:09, Magnus Westerlund = wrote: >> WG, >> (As author) >>=20 >> Based on the discussion we authors have drafted a proposal for = changing >> the CNAME creation usage to be created unique between = PeerConnections. >> Our draft text is the below one. Please review. If we receive no >> feedback we will include this in the next version of the draft that = we >> hope to be able to produce next week. >>=20 >> Section 4.1: >>=20 >> o Support for multiple synchronisation contexts. Participants = that >> send multiple simultaneous RTP packet streams do so as part of a >> single synchronisation context, using a single RTCP CNAME for = all >> streams and allowing receivers to play the streams out in a >> synchronised manner. Receivers MUST support reception of = multiple >> RTCP CNAMEs in an RTP session, and hence multiple = synchronisation >> contexts, to support RTP middleboxes, and future evolution = needing >> multiple CNAMEs in an endpoint. See also Section 4.9. >>=20 >>=20 >> Section 4.9: >>=20 >> 4.9. Generation of the RTCP Canonical Name (CNAME) >>=20 >> The RTCP Canonical Name (CNAME) provides a persistent = transport-level >> identifier for an RTP end-point. While the Synchronisation Source >> (SSRC) identifier for an RTP end-point can change if a collision is >> detected, or when the RTP application is restarted, its RTCP CNAME = is >> meant to stay unchanged, so that RTP end-points can be uniquely >> identified and associated with their RTP packet streams within a = set >> of related RTP sessions. For proper functionality, each RTP end- >> point needs to have at least one unique RTCP CNAME value. =46rom = an >> RTP perspective an end-point can have multiple CNAMEs, as the CNAME >> also identifies a particular synchronisation context, i.e. all SSRC >> associated with a CNAME share a common reference clock, and if an >> end-point have SSRCs associated with different reference clocks it >> will need to use multiple CNAMEs. This ought not be common, and if >> possible reference clocks ought to be mapped to each other and one >> chosen to be used with RTP and RTCP. Taking the discussion in >> Section 11 into account a regular WebRTC end-point MUST NOT use = more >> than a single CNAME in the RTP sessions belonging to single >> RTCPeerConnection. RTP middleboxes MAY send RTP packet streams >> identified by more than one CNAME, to allow them to avoid having to >> resynchronize media from multiple different end-points part of a >> multi-party RTP session. >>=20 >> The RTP specification [RFC3550] includes guidelines for choosing a >> unique RTP CNAME, but these are not sufficient in the presence of = NAT >> devices. In addition, long-term persistent identifiers can be >> problematic from a privacy viewpoint (Section 13). Accordingly, >> support for generating a short-term persistent RTCP CNAMEs = following >> [RFC7022] is REQUIRED to be implemented and RECOMMENDED to be used. >> Unless a persistent CNAME is explicitly configured, a unique = CNAME(s) >> MUST be generated for each synchronization context an end-point has >> within each RTCPeerConnection, i.e. normally one across all the RTP >> sessions within the scope of the RTCPeerConnection. >>=20 >> There are no known reasons for WebRTC end-points that aren't RTP >> middleboxes or servers to configure a persistent identifiers, >> these considerations are limited to RTP middleboxes. Thus, such >> configuration options SHOULD NOT be present in most WebRTC end- >> point implementations to prevent misconfiguration or malicious >> configuration that allows tracking or linking of a user. >>=20 >> An WebRTC end-point MUST support reception of any CNAME that = matches >> the syntax limitations specified by the RTP specification [RFC3550] >> and cannot assume that any CNAME will be chosen according to the = form >> suggested above. >>=20 >> Section 11: >>=20 >> The same MediaStreamTrack can also be included in multiple >> MediaStreams, thus multiple sets of MediaStreams can implicitly = need >> to use the same synchronisation base. To ensure that this works in >> all cases, and don't forces a end-point to change synchronisation >> base and CNAME in the middle of a ongoing delivery of any packet >> streams, which would cause media disruption; all MediaStreamTracks >> and their associated SSRCs originating from the same end-point = needs >> to be sent using the same CNAME within one RTCPeerConnection. This >> is motivating the strong recommendation in Section 4.9 to only use = a >> single CNAME. >>=20 >> Note: It is important that the same CNAME is not used in = different >> communication session contexts or origins, as that could enable >> tracking of a user and its device usage of different services. >> See Section 4.4.1 of Security Considerations for WebRTC >> [I-D.ietf-rtcweb-security] for further discussion. >>=20 >> The requirement on using the same CNAME for all SSRCs that >> originates from the same end-point, does not require middleboxes >> that forwards traffic from multiple end-points to only use a >> single CNAME. >>=20 >> The above will currently force a WebRTC end-point that receives an >> MediaStreamTrack on one RTCPeerConnection and adds it as an = outgoing >> on any RTCPeerConnection to perform resynchronisation of the = stream. >> This, as the sending party needs to change the CNAME, which implies >> that it has to use a locally available system clock as timebase for >> the synchronisation. Thus, the relative relation between the >> timebase of the incoming stream and the system sending out needs to >> defined. This relation also needs monitoring for clock drift and >> likely adjustments of the synchronisation. The sending entity is >> also responsible for congestion control for its the sent streams. = In >> cases of packet loss the loss of incoming data also needs to be >> handled. This leads to the observation that the method that is = least >> likely to cause issues or interruptions in the outgoing source = packet >> stream is a model of full decoding, including repair etc followed = by >> encoding of the media again into the outgoing packet stream. >> Optimisations of this method is clearly possible and implementation >> specific. >>=20 >> A WebRTC end-point MUST support receiving multiple = MediaStreamTracks, >> where each of different MediaStreamTracks (and their sets of >> associated packet streams) uses different CNAMEs. However, >> MediaStreamTracks that are received with different CNAMEs have no >> defined synchronisation. >>=20 >> Note: The motivation for supporting reception of multiple CNAMEs >> are to allow for forward compatibility with any future changes >> that enables more efficient stream handling when end-points = relay/ >> forward streams. It also ensures that end-points can = interoperate >> with certain types of multi-stream middleboxes or end-points = that >> are not WebRTC. >>=20 >> -- >>=20 >> Magnus Westerlund >>=20 >> = ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From nobody Fri Apr 4 10:37:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022AD1A0239 for ; Fri, 4 Apr 2014 10:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 ywrdMT8-zijQ for ; Fri, 4 Apr 2014 10:37:26 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 819C01A0224 for ; Fri, 4 Apr 2014 10:37:12 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q58so3791052wes.12 for ; Fri, 04 Apr 2014 10:37:07 -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:content-type:content-transfer-encoding; bh=Wv/eoS8rLqXZcQi78Cxk7rYyk6GFwhvgg6BAoxOQtvI=; b=YKWqNA+fll8vYY1CywnKMZf8nD41egzLfBLzw7JJ8hJEd2SLZLcWgCHr5YeUxOF2f9 nsMrZnaDmZSA4iMDOa5EFDfXA5lkMmiDv3x4Vp6Jtg41xBueXUHst4WvAD4PjYJ26a0r ZHZstlh4Xcb5/GxUBsKn4BNmVPNIO/q/Pc/Kly2XYdD8S7TCMm0Wt4d3+iFzTvxIrfXH wLKXRdBTXkEIZ3vm+LWdyrhmHjy44+Vhhxl8FSqmvKk/GC3xdGEtHDGK7wvD7MnzH+wM r3Fbhzh2SauAQ2rvghD0D0dc33wDBomzeuSka9pjFJNy9C+mMQQFgowtE7LOI2u5tjPc oRFg== MIME-Version: 1.0 X-Received: by 10.194.94.39 with SMTP id cz7mr7736233wjb.78.1396633027465; Fri, 04 Apr 2014 10:37:07 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Fri, 4 Apr 2014 10:37:07 -0700 (PDT) In-Reply-To: <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org> References: <533E76AC.7030003@ericsson.com> <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org> Date: Fri, 4 Apr 2014 10:37:07 -0700 Message-ID: From: Martin Thomson To: Colin Perkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aquS7rgm1_g5ns99fJO2p4DSh7Q Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 17:37:35 -0000 On 4 April 2014 09:34, Colin Perkins wrote: > I=E2=80=99m perhaps misunderstanding something, or we may not have phrase= d the text clearly, but what you say you want generally matches my understa= nding of what the draft provides. Can you expand on what parts of the text = you think are problematic? The first paragraph of Section 11 seems directly contrary to what I outline= d. I don't know how you interpret this, but I read the following text as saying the complete opposite of my suggestion to allow setting of CNAME: There are no known reasons for WebRTC end-points that aren't RTP middleboxes or servers to configure a persistent identifiers, these considerations are limited to RTP middleboxes. Thus, such configuration options SHOULD NOT be present in most WebRTC end- point implementations to prevent misconfiguration or malicious configuration that allows tracking or linking of a user. Now that I've gone back and re-read again, I think that this text is possibly confused, and certainly confusing, with respect to use of the various contexts in play. * The text uses RTP end-point, which I infer corresponds to the (local) end of the ICE component in use (i.e., the selected transport 5-tuple). An RTP end-point is required to have a unique CNAME, but that's not consistent with unbundled (SDP negotiated) sessions (i.e., what corresponds to a single unbundled RTCPeerConnection), which I assume will want to use a consistent CNAME if at all possible. * We also have guidance regarding RTCPeerConnection. * And there is also guidance regarding the browser session, presumably scoped to a given origin [RFC6454]. * I'll list RTP session for completeness, though I don't think it's a useful context to use in any case. I think that the advice could be much clearer, once all the context is properly established: 1. MUST use the same CNAME for an RTP end-point, unless different SSRCs are on a different time base (i.e., the uncommon case) 2. MUST use different CNAME for different RTCPeerConnection instances, following RFC 7022, unless the using application explicitly provides a CNAME. The latter point covers the origin case adequately. Servers and middleboxes can be given a blanket exemption if you like, allowing for the fact that they should be doing all the normal and proper RTP things. From nobody Fri Apr 4 13:42:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C9E1A028E for ; Fri, 4 Apr 2014 13:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 SlOWVnHDYW5R for ; Fri, 4 Apr 2014 13:42:11 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA151A01BD for ; Fri, 4 Apr 2014 13:42:10 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id lnx91n0071ei1Bg5Awi6Wz; Fri, 04 Apr 2014 20:42:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id lwi51n00g3ZTu2S3kwi6uF; Fri, 04 Apr 2014 20:42:06 +0000 Message-ID: <533F191D.8050109@alum.mit.edu> Date: Fri, 04 Apr 2014 16:42:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396644126; bh=XajOGkw4YAcXgo+S5h31EzW5R0211xAgrlI7rBWSn7c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iGwyxej4Xp+aSzbPvNw561onIR3CJFtyLYg0cXH8Phw0bcyjpnfwkZuXI/5QLtwu2 W5P6tJlOuol70yhBk25Wg1wcETXZwS/B5JcbRnH1qS4WsiiA3x1eNd0/CLR2RMMWbj d9UbJUzSXfc6VVdIVu+v5vdYnkf+UuD4evFjHecU4uYNR3pu+c1uNhes3AuAJqZYfZ i4eQTwOteFdpX7/VD5dAEVHqFzEC+8n5gwrvKFxVduM/xgs7HkJnbk+nZIBlgxPkBE Z+jhPEh/qZJh6dQjb+hL2A/CptmS2fK3i8r8MjVTn2OzIBH/EuMrRVShMQ4aJabfg1 2qCnjXhbB0avw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OxdF06-SqZKaXEK8Xipnjy-GmBo Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:42:15 -0000 I'm confused by this, in at least a couple of respects: - IIUC this isolation is a browser thing. If the other end doesn't have a browser then what does it mean? - Isn't the isolation supposed to be on a per-stream basis? (Or is it really on a peer-connection basis.) If it is per-stream then how does signaling it on a per-TLS basis work? - The use of DTLS to do SRTP keying is a sort of hack, since it isn't about the DTLS payload at all. I would think that whatever new you introduce into TLS for this would most naturally apply to the DTLS payload (the data channels). Thanks, Paul On 4/3/14 8:14 PM, Martin Thomson wrote: > As I described briefly at the last meeting, ensuring that media is > isolated from the application or web site is a key part of addressing > our security goals. > > The key part of that is making sure that any media that is isolated on > the sending side of RTCPeerConnection remains isolated when it reaches > the other side. > > As I noted, this is also necessary in order to ensure the integrity of > the same origin model. In that model, cross origin media is required > to be inaccessible to content, and as it stands RTCPeerConnection > could be used to work around those restrictions (implementations can > implement other protections, as Firefox already does). > > The alternatives as I see them (and I hope that this is sufficiently > exhaustive) are: > > 1. ask the TLS working group for a TLS-based solution > 2. build something into the session signaling (i.e., new SDP bits) > 3. give up on the idea > > I prefer 1 for reasons already outlined. > > I propose that we formally request the TLS working group recommend or > define a mechanism whereby we can signal in the TLS handshake that the > session contents are to be protected from access (where the > description of that protection may need to our responsibility). > > I have pointed to draft-thomson-tls-acp as a potential solution here, > but others have noted that ALPN tokens could be used. I expect that > TLS are capable of making the right decision here. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Fri Apr 4 13:50:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176061A0116 for ; Fri, 4 Apr 2014 13:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 RI_nwusXPTu2 for ; Fri, 4 Apr 2014 13:50:49 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7422C1A010B for ; Fri, 4 Apr 2014 13:50:49 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so1993683wiv.9 for ; Fri, 04 Apr 2014 13:50:44 -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:content-type; bh=mQTAdQD4z5U6ekCNKxYHu/Ifi/yoGVClmoyCb6CGhBo=; b=sOWGeWLX8kIETgz8j9U5vHr9nJ8SZGdlyYipkhNbDQXsA5+NF/PPMEx+7yePmOwUho HbvFqOHPxmmV4XMWnPGCDaANskDLhkAdctMA79/EtYR6jyK0zvJUzgUp7+05CGxMZwfr CpvpdtasTDiK2cz/ziJZLbVuV9JNT02O3Ur3N2HYpA9bkZc9TjwgBETKUHrlgyNE8ozl kYQYzyAm8ot6OYF+OzW0HY68NgzrZqyFEknuok2abbir2yCvleKKIat8ZHoWHOmIRrdK bzho4AQDfM95e29tEEGLD5BPSBU+M5bDL3wPkpcBFEWKM4fIN8sOwyJBcsJEA84L1paC vvpQ== MIME-Version: 1.0 X-Received: by 10.180.89.211 with SMTP id bq19mr7333505wib.58.1396644644091; Fri, 04 Apr 2014 13:50:44 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Fri, 4 Apr 2014 13:50:44 -0700 (PDT) In-Reply-To: <533F191D.8050109@alum.mit.edu> References: <533F191D.8050109@alum.mit.edu> Date: Fri, 4 Apr 2014 13:50:44 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_AyC979J88pK_ORD96VplUYU_UU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:50:55 -0000 Fair questions... On 4 April 2014 13:42, Paul Kyzivat wrote: > - IIUC this isolation is a browser thing. If the other end doesn't > have a browser then what does it mean? Yes, this is specific to a browser. A non-browser peer would probably respect this isolation property without any effort at all. After all, few non-browser applications permit the running of arbitrary, remotely-source code in the way that a browser does. > - Isn't the isolation supposed to be on a per-stream basis? > (Or is it really on a peer-connection basis.) If it is per-stream > then how does signaling it on a per-TLS basis work? The question of scope is an important one. The isolation property is, at least at the most abstract layer, applicable to a MediaStreamTrack. I believe that the right approach is to broaden this scope to RTCPeerConnection, where the identity controls exist. This means that you won't be able to mix isolated and non-isolated streams in the same RTCPeerConnection. > - The use of DTLS to do SRTP keying is a sort of hack, since it > isn't about the DTLS payload at all. I would think that whatever > new you introduce into TLS for this would most naturally apply > to the DTLS payload (the data channels). This is true only in the strictest academic or abstract sense. We are already taking things from the DTLS handshake and using those things to make assertions about the properties of the SRTP. Certificates. Since you raise data channels, I'll note that we have no way to use data channels in an isolated fashion. Thus, I conclude that if we intend to make this property consistent, we should not be using data channels in the same RTCPeerConnection as media streams. Of course, I'm open to taking the pragmatists approach too, unless we think that there is a use case for - say, file transfer - where it makes sense for data to be isolated in the same way I'm proposing that media be. From nobody Sun Apr 6 11:37:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DB51A04C1 for ; Sun, 6 Apr 2014 11:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 FqeAcXjhyjre for ; Sun, 6 Apr 2014 11:37:14 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 35C9C1A04B8 for ; Sun, 6 Apr 2014 11:37:14 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta14.westchester.pa.mail.comcast.net with comcast id miSu1n0031ei1Bg5Eid8Cl; Sun, 06 Apr 2014 18:37:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id mid81n00f3ZTu2S3kid8jD; Sun, 06 Apr 2014 18:37:08 +0000 Message-ID: <53419ED4.8020102@alum.mit.edu> Date: Sun, 06 Apr 2014 14:37:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Martin Thomson References: <533F191D.8050109@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396809428; bh=T7sKLC0ASoO5dbFxEo1/8RQe/axFfta36Gac7vgNrpw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EpHeya/NtFxWchvVeAGCQYvba6BXlPgo5L+SwUWzV/nJGZG83BwB7xP3ZuJGdK80T /i8OQdRcqRMhoIhTAYVwXT4o6RrcZaHMGJnELFfzaANaafVdK00di5P/BYY9VEsoLx nky0w1HjEEhqVDTpkspMnPderezpbT4MWmpBAPvN6zku1+3yNan/VUQXlRp2tYSPuY nktaSC41Osco+flMjkDui3HhNIpzeJ/G4FsU0sNYKQpGMbn5cq3UIsxJROyE/eAGoc 8Gk30FvaZ4B7PhYOQIp0if5jUjPtDZyviwLYK2T+dsBXjS1jR6Tl9ZHeP/O7eygw6y rWKz4gZrH6H6Q== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JFAdDVSnEDI-bBmElUwd2JG9M6c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 18:37:19 -0000 On 4/4/14 4:50 PM, Martin Thomson wrote: > Fair questions... > > On 4 April 2014 13:42, Paul Kyzivat wrote: >> - IIUC this isolation is a browser thing. If the other end doesn't >> have a browser then what does it mean? > > Yes, this is specific to a browser. A non-browser peer would probably > respect this isolation property without any effort at all. After all, > few non-browser applications permit the running of arbitrary, > remotely-source code in the way that a browser does. But ISTM there would need to be a different set of limitations for non-browsers. For instance, to not echo the stream back to the source. And not to store the stream in a place that the sender can retrieve. Maybe it is possible to define a set of rules, but I don't have a vision of what that would be. >> - Isn't the isolation supposed to be on a per-stream basis? >> (Or is it really on a peer-connection basis.) If it is per-stream >> then how does signaling it on a per-TLS basis work? > > The question of scope is an important one. The isolation property is, > at least at the most abstract layer, applicable to a MediaStreamTrack. > I believe that the right approach is to broaden this scope to > RTCPeerConnection, where the identity controls exist. This means that > you won't be able to mix isolated and non-isolated streams in the same > RTCPeerConnection. I'll wait to see what others have to say about this. I haven't been able to wrap my head around it. >> - The use of DTLS to do SRTP keying is a sort of hack, since it >> isn't about the DTLS payload at all. I would think that whatever >> new you introduce into TLS for this would most naturally apply >> to the DTLS payload (the data channels). > > This is true only in the strictest academic or abstract sense. We are > already taking things from the DTLS handshake and using those things > to make assertions about the properties of the SRTP. Certificates. > > Since you raise data channels, I'll note that we have no way to use > data channels in an isolated fashion. Thus, I conclude that if we > intend to make this property consistent, we should not be using data > channels in the same RTCPeerConnection as media streams. Of course, > I'm open to taking the pragmatists approach too, unless we think that > there is a use case for - say, file transfer - where it makes sense > for data to be isolated in the same way I'm proposing that media be. Again I'm interested to hear what others have to say about this. Thanks, Paul From nobody Sun Apr 6 19:42:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7EF1A0658 for ; Sun, 6 Apr 2014 19:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham 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 hTSAnRTscUp7 for ; Sun, 6 Apr 2014 19:42:25 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D5C1A065D for ; Sun, 6 Apr 2014 19:42:24 -0700 (PDT) Received: from ppp118-209-187-61.lns20.mel6.internode.on.net ([118.209.187.61]:63578 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WWzVm-0002ks-9i for rtcweb@ietf.org; Mon, 07 Apr 2014 12:42:14 +1000 Message-ID: <53421089.3050506@nteczone.com> Date: Mon, 07 Apr 2014 12:42:17 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <533E7A50.5040909@ericsson.com> In-Reply-To: <533E7A50.5040909@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QvDv-woroT3KvylfKLJAtYw2x98 Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 02:42:29 -0000 Hello Magnus, Please see my comments marked CNG below. Regards, Christian On 4/04/2014 8:24 PM, Magnus Westerlund wrote: > WG, > (As Author) > > Colin and I have been working on resolving terminology usage and in > general giving the draft a polish over before the WG last call. One > section that has gotten quite some attention from us is the below one. > The changes are significantly from an editorial stand point. However, > the intended content has not been intended to be changed, although > clarified and better motivated. So please review it, we intended to > include this in the upcoming draft update. Feedback appreciated. > > 5.1. Conferencing Extensions and Topologies > > RTP is a protocol that inherently supports group communication. > Groups can be implemented by having each endpoint sending its RTP > packet streams to an RTP middlebox that redistributes the traffic, by > using a mesh of unicast RTP packet streams between endpoints, or by > using an IP multicast group to distribute the RTP packet streams. > These topologies can be implemented in a number of ways as discussed > in [I-D.ietf-avtcore-rtp-topologies-update]. > > While the use of IP multicast groups is popular in IPTV systems, the > topologies based on RTP middleboxes are dominant in interactive video > conferencing environments. Topologies based on a mesh of unicast > transport-layer flows to create a common RTP session have not seen > widespread deployment. Accordingly, WebRTC implementations are not > expected to support topologies based on IP multicast groups. WebRTC > implementations are also not expected to support mesh-based > topologies, such as a point-to-multipoint mesh configured as a single > RTP session (Topo-Mesh in the terminology of > [I-D.ietf-avtcore-rtp-topologies-update]). However, a point-to- > multipoint mesh constructed using several RTP sessions, in the WebRTC > context using independent RTCPeerConnections can be expected to be > utilised by WebRTC applications. > > WebRTC implementations of RTP endpoints implemented according to this > memo are expected to support all the topologies described in > [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send > and receive unicast RTP packet streams to some peer device, provided > that peer can participate in performing congestion control on the RTP > packet streams. The peer device could be another RTP endpoint, or it > could be an RTP middlebox that redistributes the RTP packet streams > to other RTP endpoints. This limitation means that some of the RTP > middlebox-based topologies are not suitable for use in the WebRTC > environment. Specifically: > > o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, > since they make the use of RTCP for congestion control and quality > of service reports problematic (see Section 3.6.2 of > [I-D.ietf-avtcore-rtp-topologies-update]). [CNG] Is 3.6.2 the right reference? clause 3.8 talks about Topo-Video-switch-MCU and the reports problem. > > o Content modifying MCUs with RTCP termination (Topo-RTCP- > terminating-MCU) SHOULD NOT be used since they break RTP loop > detection, and prevent receivers from identifying active senders > (see section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]). [CNG] Is 3.8 the right reference? clause 3.9 talks about loop detection for Topo-RTCP- terminating-MCU. > > o The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology > SHOULD NOT be used because its safe use requires a point to > multipoint congestion control algorithm or RTP circuit breaker, > which has not yet been standardised. > > The RTP extensions described in Section 5.1.1 to Section 5.1.6 are > designed to be used with centralised conferencing, where an RTP > middlebox (e.g., a conference bridge) receives a participant's RTP > packet streams and distributes them to the other participants. These > extensions are not necessary for interoperability; an RTP end-point > that does not implement these extensions will work correctly, but > might offer poor performance. Support for the listed extensions will > greatly improve the quality of experience and, to provide a > reasonable baseline quality, some of these extensions are mandatory > to be supported by WebRTC end-points. > > The RTCP conferencing extensions are defined in Extended RTP Profile > for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ > AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio- > Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully > usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124]. > > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Apr 7 01:03:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654D31A069E for ; Mon, 7 Apr 2014 01:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TTAClhpBHj_c for ; Mon, 7 Apr 2014 01:03:04 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4C31A06A0 for ; Mon, 7 Apr 2014 01:03:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 08C7C7C50A4 for ; Mon, 7 Apr 2014 10:02:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTBQdrRtoEqV for ; Mon, 7 Apr 2014 10:02:56 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 49C3F7C50A1 for ; Mon, 7 Apr 2014 10:02:56 +0200 (CEST) Message-ID: <53425BAF.4070105@alvestrand.no> Date: Mon, 07 Apr 2014 10:02:55 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <533F191D.8050109@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yDCTFOriQlgz0W4eKgv_UKLIRBc Subject: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 08:03:09 -0000 On 04/04/2014 10:50 PM, Martin Thomson wrote: > Since you raise data channels, I'll note that we have no way to use > data channels in an isolated fashion. Thus, I conclude that if we > intend to make this property consistent, we should not be using data > channels in the same RTCPeerConnection as media streams. Of course, > I'm open to taking the pragmatists approach too, unless we think that > there is a use case for - say, file transfer - where it makes sense > for data to be isolated in the same way I'm proposing that media be. Focusing on the "should we ever isolate data channels" question: If we ever define a protocol carried *over* data channels that is interpreted in the browser, not in the Javascript, and exposes a different API to Javascript than the datachannel API, this might make sense. In that case, I think we should investigate whether it's possible to make use of the "protocol" field (put some reserved values into it saying "for protocols that look like *this*, Javascript can't set them?), it's the logical place to say "this is datachannels, but with some extra rules". Wild suggestion: if you want per-track isolation properties, open up a data channel with a protocol called '*WebRTCIsolationInfo' and use it to send information about the isolation status of each track, thereby also providing a working example for the rule 'all data channels that have protocols starting with "*" are for browser internal usage'..... From nobody Mon Apr 7 01:08:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7BE1A0694 for ; Mon, 7 Apr 2014 01:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 N7ZqFZ-V5gdy for ; Mon, 7 Apr 2014 01:08:08 -0700 (PDT) Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id A118D1A069C for ; Mon, 7 Apr 2014 01:08:07 -0700 (PDT) X-AuditID: c1b4fb28-b7fd58e000007bb5-48-53425ce15d64 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 7C.EF.31669.1EC52435; Mon, 7 Apr 2014 10:08:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Mon, 7 Apr 2014 10:08:00 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-06.txt Thread-Index: AQHPUjcOMpViHIusMkmAOn1B8VKhFZsFzH3g Date: Mon, 7 Apr 2014 08:08:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2AB28C@ESESSMB209.ericsson.se> References: <20140407075603.16879.85415.idtracker@ietfa.amsl.com> In-Reply-To: <20140407075603.16879.85415.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvje7DGKdggzmn5SzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrov79kLfgpVLJn7nLGB8QdfFyMnh4SAicSSphWsELaYxIV7 69m6GLk4hAROMkp8uXCMGcJZzCixesYsoCoODjYBC4nuf9ogDSIC6hKXH15gB7GFBYIlfn5Z xwYRD5E43fiPHcI2kri3tA8sziKgItH2ciYzyBheAV+Jzi5hkLCQgKPE0j/nwUo4BZwkps88 ywJiMwLd8/3UGiYQm1lAXOLWk/lMEHcKSCzZc54ZwhaVePn4H9T9ihJXpy+HqteRWLD7ExuE rS2xbOFrsHpeAUGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNkcWpxcW66kaFebnpuiV5q UWZycXF+nl5x6iZGYGQc3PJbYwdj9zX7Q4zSHCxK4rxVMzuDhATSE0tSs1NTC1KL4otKc1KL DzEycXBKNTBq7do9qXRFpdKdx6xyf2bfS2/cfez3oj3pdTPW919gMTpUeu4Rn5/w3uh5qxVa l7f/uhPT7FHwJMbGeRmDdUTH4/0M/OsDX0uknVJ8w3tL8NBGLrcDSRe3VaoWXZf4mfOwVeDc UtFfx9YXiGge/pNs0RsZkKIWuO1XgQD3a6+DS//++dp64vw6JZbijERDLeai4kQA66IbG1oC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kCWcojPR1ZB4SkBAs2LzhqLHnfM Subject: [rtcweb] FW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-06.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 08:08:12 -0000 FYI, To avoid cross-posting, if you have any comments on the document, please po= st them on the MMUSIC list. Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: 7. huhtikuuta 2014 10:56 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-06.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Multiplexing Negotiation Using Session Descriptio= n Protocol (SDP) Port Numbers Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-06.txt Pages : 38 Date : 2014-04-07 Abstract: This specification defines a new SDP Grouping Framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for sending and receiving media associated with multiple SDP media descriptions ("m=3D" lines). This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264, in order to allow an answerer to in an SDP answer assign a non- zero port value to an "m=3D" line, even if the offerer in the associated SDP offer had assigned a zero port value to the "m=3D" line. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-bundle-negotiation= -06 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Apr 7 01:12:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDC21A069C for ; Mon, 7 Apr 2014 01:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pc4VdHJgubYN for ; Mon, 7 Apr 2014 01:12:33 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 47F4B1A017A for ; Mon, 7 Apr 2014 01:12:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 517AC7C08EA for ; Mon, 7 Apr 2014 10:12:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0urUprkQgp4U for ; Mon, 7 Apr 2014 10:12:14 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id B5BDE7C03E5 for ; Mon, 7 Apr 2014 10:12:14 +0200 (CEST) Message-ID: <53425DDE.2030005@alvestrand.no> Date: Mon, 07 Apr 2014 10:12:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <533E7A50.5040909@ericsson.com> In-Reply-To: <533E7A50.5040909@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rpymcZgM6viiq7Lwdvr5d7HbyIk Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 08:12:38 -0000 Thanks for the update! It does seem reasonably clear now - clear enough that I found one point that I violently disagree with (if I'm interpreting it correctly). See below. I don't have any negative comments on the rest of the section. On 04/04/2014 11:24 AM, Magnus Westerlund wrote: > WG, > (As Author) > > Colin and I have been working on resolving terminology usage and in > general giving the draft a polish over before the WG last call. One > section that has gotten quite some attention from us is the below one. > The changes are significantly from an editorial stand point. However, > the intended content has not been intended to be changed, although > clarified and better motivated. So please review it, we intended to > include this in the upcoming draft update. Feedback appreciated. > > 5.1. Conferencing Extensions and Topologies > > RTP is a protocol that inherently supports group communication. > Groups can be implemented by having each endpoint sending its RTP > packet streams to an RTP middlebox that redistributes the traffic, by > using a mesh of unicast RTP packet streams between endpoints, or by > using an IP multicast group to distribute the RTP packet streams. > These topologies can be implemented in a number of ways as discussed > in [I-D.ietf-avtcore-rtp-topologies-update]. > > While the use of IP multicast groups is popular in IPTV systems, the > topologies based on RTP middleboxes are dominant in interactive video > conferencing environments. Topologies based on a mesh of unicast > transport-layer flows to create a common RTP session have not seen > widespread deployment. Accordingly, WebRTC implementations are not > expected to support topologies based on IP multicast groups. WebRTC > implementations are also not expected to support mesh-based > topologies, such as a point-to-multipoint mesh configured as a single > RTP session (Topo-Mesh in the terminology of > [I-D.ietf-avtcore-rtp-topologies-update]). However, a point-to- > multipoint mesh constructed using several RTP sessions, in the WebRTC > context using independent RTCPeerConnections can be expected to be > utilised by WebRTC applications. > > WebRTC implementations of RTP endpoints implemented according to this > memo are expected to support all the topologies described in > [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send > and receive unicast RTP packet streams to some peer device, provided > that peer can participate in performing congestion control on the RTP > packet streams. The peer device could be another RTP endpoint, or it > could be an RTP middlebox that redistributes the RTP packet streams > to other RTP endpoints. This limitation means that some of the RTP > middlebox-based topologies are not suitable for use in the WebRTC > environment. Specifically: > > o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, > since they make the use of RTCP for congestion control and quality > of service reports problematic (see Section 3.6.2 of > [I-D.ietf-avtcore-rtp-topologies-update]). > > o Content modifying MCUs with RTCP termination (Topo-RTCP- > terminating-MCU) SHOULD NOT be used since they break RTP loop > detection, and prevent receivers from identifying active senders > (see section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]). In my (strong) opinion: This recommendation is wrong. All central conferencing units that use individual RTP sessions with clients fall into this category. This includes, I believe, every single multiuser video conferencing system based on WebRTC in existence (and there are many of them). I believe the recommendation should be: * Content modifying MCUs with RTCP termination (Topo-RTCP-terminating-MCU) MAY be used. Note that in this scenario, RTP loop detection and identification of active senders is the resposibility of the application; since the clients are isolated from each other at the RTP layer, RTP cannot assist with these functions. > > o The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology > SHOULD NOT be used because its safe use requires a point to > multipoint congestion control algorithm or RTP circuit breaker, > which has not yet been standardised. > > The RTP extensions described in Section 5.1.1 to Section 5.1.6 are > designed to be used with centralised conferencing, where an RTP > middlebox (e.g., a conference bridge) receives a participant's RTP > packet streams and distributes them to the other participants. These > extensions are not necessary for interoperability; an RTP end-point > that does not implement these extensions will work correctly, but > might offer poor performance. Support for the listed extensions will > greatly improve the quality of experience and, to provide a > reasonable baseline quality, some of these extensions are mandatory > to be supported by WebRTC end-points. > > The RTCP conferencing extensions are defined in Extended RTP Profile > for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ > AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio- > Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully > usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124]. > > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Apr 7 03:58:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42761A03C3 for ; Mon, 7 Apr 2014 03:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 eahBYYCjNFJc for ; Mon, 7 Apr 2014 03:58:06 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEC61A03B7 for ; Mon, 7 Apr 2014 03:58:06 -0700 (PDT) X-AuditID: c1b4fb38-b7f518e000000889-15-534284b7da97 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 51.7A.02185.7B482435; Mon, 7 Apr 2014 12:58:00 +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.174.1; Mon, 7 Apr 2014 12:57:59 +0200 Message-ID: <534284B7.7010103@ericsson.com> Date: Mon, 7 Apr 2014 12:57:59 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Martin Thomson , Colin Perkins References: <533E76AC.7030003@ericsson.com> <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvje6OFqdgg/2rWS2WvzzBaHHtzD9G i7X/2tkdmD2m3b/P5rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZaz79p+14LxsxZNdi5gb GK+KdzFyckgImEic33GRCcIWk7hwbz1bFyMXh5DAUUaJHbvfMUM4yxglWtesZAGp4hXQltjz +zwjiM0ioCJx6P1tMJtNwELi5o9GNhBbVCBYYumcxVD1ghInZz4Bsjk4RASCJPr7ikHCzALq EncWn2MHsYUFfCRuXf7HCrHrFaPEjRVzwBKcAoESu+d/YgTplRAQl+hpDILo1ZRo3f6bHcKW l2jeOpsZxBYCOq2hqYN1AqPQLCSbZyFpmYWkZQEj8ypGjuLU4qTcdCODTYzAAD645bfFDsbL f20OMUpzsCiJ83586xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZFNekWIUGJ6zMsjtvzS +7oPO1V67T+xaYlczLtHimkzYiW3rezXPHd5/ZGG60+1Ni9PWG0o1zLlj8LWjR8Kp9rOsdJU dDmcuazy6qSvRRNtyj943H92g1lS8cTELTd/Gca+XXBs/+LOPPZA79kbo88160xbcc9m9a/A J5JiISqOTz7ubasJcVmoxFKckWioxVxUnAgAPDw7PS4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GDciSQrzmDWBOJH0g8OMTJmsD6E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 10:58:11 -0000 On 2014-04-04 19:37, Martin Thomson wrote: > On 4 April 2014 09:34, Colin Perkins wrote: >> I’m perhaps misunderstanding something, or we may not have phrased the text clearly, but what you say you want generally matches my understanding of what the draft provides. Can you expand on what parts of the text you think are problematic? > > The first paragraph of Section 11 seems directly contrary to what I outlined. > > I don't know how you interpret this, but I read the following text as > saying the complete opposite of my suggestion to allow setting of > CNAME: > > There are no known reasons for WebRTC end-points that aren't RTP > middleboxes or servers to configure a persistent identifiers, > these considerations are limited to RTP middleboxes. Thus, such > configuration options SHOULD NOT be present in most WebRTC end- > point implementations to prevent misconfiguration or malicious > configuration that allows tracking or linking of a user. > > Now that I've gone back and re-read again, I think that this text is > possibly confused, and certainly confusing, with respect to use of the > various contexts in play. > > * The text uses RTP end-point, which I infer corresponds to the > (local) end of the ICE component in use (i.e., the selected transport > 5-tuple). An RTP end-point is required to have a unique CNAME, but > that's not consistent with unbundled (SDP negotiated) sessions (i.e., > what corresponds to a single unbundled RTCPeerConnection), which I > assume will want to use a consistent CNAME if at all possible. > > * We also have guidance regarding RTCPeerConnection. > > * And there is also guidance regarding the browser session, > presumably scoped to a given origin [RFC6454]. > > * I'll list RTP session for completeness, though I don't think it's a > useful context to use in any case. > > I think that the advice could be much clearer, once all the context is > properly established: > > 1. MUST use the same CNAME for an RTP end-point, unless different > SSRCs are on a different time base (i.e., the uncommon case) > > 2. MUST use different CNAME for different RTCPeerConnection > instances, following RFC 7022, unless the using application explicitly > provides a CNAME. This is the intent of the text provided. So, I guess it is further work on how things are formulated that are needed, not the intended content. In fact regarding the first we have been stricter than that, the reason is to avoid the synchronization issues that arises from creating MediaStreams from MediaStreamTracks with different time-bases. That issue would disappear if MediaStream are abandoned in the API, and then I would prefer your notice of exception when handling multiple timebases locally. > > The latter point covers the origin case adequately. Servers and > middleboxes can be given a blanket exemption if you like, allowing for > the fact that they should be doing all the normal and proper RTP > things. I think a important aspect from a middlebox why multiple CNAMEs is to be expected and not necessariyl follow the default rules, is that they may not be controlled as normal WebRTC endpoint, i.e. no normal JS API. 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 7 04:15:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADE61A06E8 for ; Mon, 7 Apr 2014 04:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 3WxiDABjzaCm for ; Mon, 7 Apr 2014 04:15:24 -0700 (PDT) Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id A69D21A03BF for ; Mon, 7 Apr 2014 04:15:21 -0700 (PDT) X-AuditID: c1b4fb28-b7fd58e000007bb5-b1-534288c31cf7 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 09.06.31669.3C882435; Mon, 7 Apr 2014 13:15:15 +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.174.1; Mon, 7 Apr 2014 13:15:14 +0200 Message-ID: <534288C2.6010906@ericsson.com> Date: Mon, 7 Apr 2014 13:15:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Harald Alvestrand , References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no> In-Reply-To: <53425DDE.2030005@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvje7hDqdgg9lNohbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJ2/XvGWLBct2LpyuksDYz9Kl2MHBwSAiYS f+8ZdDFyApliEhfurWcDsYUETjJK7FgqCmEvY5R4ckoIxOYV0JY4f/0FC4jNIqAiMevFK1YQ m03AQuLmj0awXlGBYImlcxazQNQLSpyc+QTMFhGwl7g45yWYLSyQITGtaTPULh+JxYd7mUFs TgFdia0f5rJDnCYu0dMYBBJmFtCTmHK1hRHClpdo3jqbGaJVW6KhqYN1AqPgLCTbZiFpmYWk ZQEj8ypGyeLU4uLcdCNDvdz03BK91KLM5OLi/Dy94tRNjMCAPbjlt8YOxu5r9ocYpTlYlMR5 q2Z2BgkJpCeWpGanphakFsUXleakFh9iZOLglGpgVFy8v7K22zGK2cOWNdlrmtVtR9G9p1+V JHF9ypNXYfS+yeTr96ptZ/fK9jVa+p2Tl6ZFnAswntIbIu7m55ac0jtnt+lEZa3ewJDM6P/c D/f1NbLPlDx2mlV2X1C7VozEhj87A06+endm4gND81ThohNR8YGae0+fP7WxseiUTsGdIJF8 diklluKMREMt5qLiRABPdsx9JgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iyBw_9KuqQ2Gt2VGcXYlb3u7OX8 Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 11:15:29 -0000 On 2014-04-07 10:12, Harald Alvestrand wrote: > Thanks for the update! > > It does seem reasonably clear now - clear enough that I found one point > that I violently disagree with (if I'm interpreting it correctly). See > below. > > I don't have any negative comments on the rest of the section. > > On 04/04/2014 11:24 AM, Magnus Westerlund wrote: >> WG, >> (As Author) >> >> Colin and I have been working on resolving terminology usage and in >> general giving the draft a polish over before the WG last call. One >> section that has gotten quite some attention from us is the below one. >> The changes are significantly from an editorial stand point. However, >> the intended content has not been intended to be changed, although >> clarified and better motivated. So please review it, we intended to >> include this in the upcoming draft update. Feedback appreciated. >> >> 5.1. Conferencing Extensions and Topologies >> >> RTP is a protocol that inherently supports group communication. >> Groups can be implemented by having each endpoint sending its RTP >> packet streams to an RTP middlebox that redistributes the traffic, by >> using a mesh of unicast RTP packet streams between endpoints, or by >> using an IP multicast group to distribute the RTP packet streams. >> These topologies can be implemented in a number of ways as discussed >> in [I-D.ietf-avtcore-rtp-topologies-update]. >> >> While the use of IP multicast groups is popular in IPTV systems, the >> topologies based on RTP middleboxes are dominant in interactive video >> conferencing environments. Topologies based on a mesh of unicast >> transport-layer flows to create a common RTP session have not seen >> widespread deployment. Accordingly, WebRTC implementations are not >> expected to support topologies based on IP multicast groups. WebRTC >> implementations are also not expected to support mesh-based >> topologies, such as a point-to-multipoint mesh configured as a single >> RTP session (Topo-Mesh in the terminology of >> [I-D.ietf-avtcore-rtp-topologies-update]). However, a point-to- >> multipoint mesh constructed using several RTP sessions, in the WebRTC >> context using independent RTCPeerConnections can be expected to be >> utilised by WebRTC applications. >> >> WebRTC implementations of RTP endpoints implemented according to this >> memo are expected to support all the topologies described in >> [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send >> and receive unicast RTP packet streams to some peer device, provided >> that peer can participate in performing congestion control on the RTP >> packet streams. The peer device could be another RTP endpoint, or it >> could be an RTP middlebox that redistributes the RTP packet streams >> to other RTP endpoints. This limitation means that some of the RTP >> middlebox-based topologies are not suitable for use in the WebRTC >> environment. Specifically: >> >> o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, >> since they make the use of RTCP for congestion control and quality >> of service reports problematic (see Section 3.6.2 of >> [I-D.ietf-avtcore-rtp-topologies-update]). >> >> o Content modifying MCUs with RTCP termination (Topo-RTCP- >> terminating-MCU) SHOULD NOT be used since they break RTP loop >> detection, and prevent receivers from identifying active senders >> (see section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]). > > In my (strong) opinion: This recommendation is wrong. > > All central conferencing units that use individual RTP sessions with > clients fall into this category. This includes, I believe, every single > multiuser video conferencing system based on WebRTC in existence (and > there are many of them). Do they? The point of this topology is that it terminates the source identification and hides when it is performing any type of mixing or switching operation. You can perform this with a back to back RTP session style without breaking this property. Just by correctly linking information between the sessions. Which means that the individual RTP session is from the identification part inseparable from an SFM or classic RTP mixer. Only the SSRC level loop detection gets impacted. I do understand that people have implemented it this way. Implementation are not necessarily equivalent to recommended practice. > > I believe the recommendation should be: > > * Content modifying MCUs with RTCP termination > (Topo-RTCP-terminating-MCU) MAY be used. Note that in this scenario, RTP > loop detection and identification of active senders is the resposibility > of the application; since the clients are isolated from each other at > the RTP layer, RTP cannot assist with these functions. > If this topology was without issues, then one would simply remove the bullet, and let it fall under the general clause. However, it clearly needs that warning. Which results in this topology being both positively and negatively treated in regards to the other "you may encounter this topology". 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 7 04:16:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFA01A03CB for ; Mon, 7 Apr 2014 04:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 xTD60BDg12bK for ; Mon, 7 Apr 2014 04:16:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F19741A03A2 for ; Mon, 7 Apr 2014 04:16:41 -0700 (PDT) X-AuditID: c1b4fb2d-b7f328e0000012ab-13-53428913093e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 67.BC.04779.31982435; Mon, 7 Apr 2014 13:16:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.174.1; Mon, 7 Apr 2014 13:16:35 +0200 Message-ID: <53428913.10808@ericsson.com> Date: Mon, 7 Apr 2014 13:16:35 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Christian Groves , References: <533E7A50.5040909@ericsson.com> <53421089.3050506@nteczone.com> In-Reply-To: <53421089.3050506@nteczone.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42KZGfG3Rle40ynY4PpdK4sv7xtZLNb+a2d3 YPJYsuQnk8eK8zNZApiiuGxSUnMyy1KL9O0SuDJ2rpjAWrDEuOLx3DNsDYw3NLoYOTgkBEwk Pk206GLkBDLFJC7cW8/WxcjFISRwmFFibccPRpCEkMAyRoml5z1AbF4BTYlNkzeBxVkEVCTu rn7IDGKzCVhI3PzRyAZiiwoESyyds5gFol5Q4uTMJ2C2iIC7xP27b8FqhAUyJKY1bWaDmO8t sXHvbhaQezgFdCT274+DOE1coqcxCKSCWUBPYsrVFkYIW16ieetsZohObYmGpg7WCYyCs5As m4WkZRaSlgWMzKsY2XMTM3PSyw03MQKD8eCW37o7GE+dEznEKM3BoiTO++Gtc5CQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGRvueExz31otYO82srF+tc/1T8kpZMS/jr/FpAU8lxRPe2TgJ eWmuFbB4nmis2LM0lEeJTzt2tsvH9w2Xvf9u2pCwnmXxez2HR3YzQ9e9slJxZXzR/a8mf86P 99/XO31flFPadFHqrX58H0/LRraX0qcfHTVmlooLtvkXxMa63P1euvuzqoe8SizFGYmGWsxF xYkAWAxx5xQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4IT_ouyY6ZVR-qbYB3UEvwtk6Ag Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 11:16:47 -0000 Thanks Christian, You are correct, these section references points to the wrong sections, will address. /Magnus On 2014-04-07 04:42, Christian Groves wrote: > Hello Magnus, > > Please see my comments marked CNG below. > > Regards, Christian > > On 4/04/2014 8:24 PM, Magnus Westerlund wrote: >> WG, >> (As Author) >> >> Colin and I have been working on resolving terminology usage and in >> general giving the draft a polish over before the WG last call. One >> section that has gotten quite some attention from us is the below one. >> The changes are significantly from an editorial stand point. However, >> the intended content has not been intended to be changed, although >> clarified and better motivated. So please review it, we intended to >> include this in the upcoming draft update. Feedback appreciated. >> >> 5.1. Conferencing Extensions and Topologies >> >> RTP is a protocol that inherently supports group communication. >> Groups can be implemented by having each endpoint sending its RTP >> packet streams to an RTP middlebox that redistributes the traffic, by >> using a mesh of unicast RTP packet streams between endpoints, or by >> using an IP multicast group to distribute the RTP packet streams. >> These topologies can be implemented in a number of ways as discussed >> in [I-D.ietf-avtcore-rtp-topologies-update]. >> >> While the use of IP multicast groups is popular in IPTV systems, the >> topologies based on RTP middleboxes are dominant in interactive video >> conferencing environments. Topologies based on a mesh of unicast >> transport-layer flows to create a common RTP session have not seen >> widespread deployment. Accordingly, WebRTC implementations are not >> expected to support topologies based on IP multicast groups. WebRTC >> implementations are also not expected to support mesh-based >> topologies, such as a point-to-multipoint mesh configured as a single >> RTP session (Topo-Mesh in the terminology of >> [I-D.ietf-avtcore-rtp-topologies-update]). However, a point-to- >> multipoint mesh constructed using several RTP sessions, in the WebRTC >> context using independent RTCPeerConnections can be expected to be >> utilised by WebRTC applications. >> >> WebRTC implementations of RTP endpoints implemented according to this >> memo are expected to support all the topologies described in >> [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send >> and receive unicast RTP packet streams to some peer device, provided >> that peer can participate in performing congestion control on the RTP >> packet streams. The peer device could be another RTP endpoint, or it >> could be an RTP middlebox that redistributes the RTP packet streams >> to other RTP endpoints. This limitation means that some of the RTP >> middlebox-based topologies are not suitable for use in the WebRTC >> environment. Specifically: >> >> o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, >> since they make the use of RTCP for congestion control and quality >> of service reports problematic (see Section 3.6.2 of >> [I-D.ietf-avtcore-rtp-topologies-update]). > [CNG] Is 3.6.2 the right reference? clause 3.8 talks about > Topo-Video-switch-MCU and the reports problem. >> >> o Content modifying MCUs with RTCP termination (Topo-RTCP- >> terminating-MCU) SHOULD NOT be used since they break RTP loop >> detection, and prevent receivers from identifying active senders >> (see section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]). > [CNG] Is 3.8 the right reference? clause 3.9 talks about loop detection > for Topo-RTCP- > terminating-MCU. >> >> o The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology >> SHOULD NOT be used because its safe use requires a point to >> multipoint congestion control algorithm or RTP circuit breaker, >> which has not yet been standardised. >> >> The RTP extensions described in Section 5.1.1 to Section 5.1.6 are >> designed to be used with centralised conferencing, where an RTP >> middlebox (e.g., a conference bridge) receives a participant's RTP >> packet streams and distributes them to the other participants. These >> extensions are not necessary for interoperability; an RTP end-point >> that does not implement these extensions will work correctly, but >> might offer poor performance. Support for the listed extensions will >> greatly improve the quality of experience and, to provide a >> reasonable baseline quality, some of these extensions are mandatory >> to be supported by WebRTC end-points. >> >> The RTCP conferencing extensions are defined in Extended RTP Profile >> for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ >> AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio- >> Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully >> usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124]. >> >> >> 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 >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- 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 7 06:45:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC16A1A0429 for ; Mon, 7 Apr 2014 06:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2crImysKsf12 for ; Mon, 7 Apr 2014 06:44:55 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE7F1A0708 for ; Mon, 7 Apr 2014 06:44:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 19DA47C50D4; Mon, 7 Apr 2014 15:44:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIZ-Fsgb2IAJ; Mon, 7 Apr 2014 15:44:30 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id D423A7C50C7; Mon, 7 Apr 2014 15:44:29 +0200 (CEST) Message-ID: <5342ABBB.9050300@alvestrand.no> Date: Mon, 07 Apr 2014 15:44:27 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Magnus Westerlund , rtcweb@ietf.org References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no> <534288C2.6010906@ericsson.com> In-Reply-To: <534288C2.6010906@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/c5MVIwXou0G_2Nnlr7aIljCU6PE Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 13:45:05 -0000 On 04/07/2014 01:15 PM, Magnus Westerlund wrote: > On 2014-04-07 10:12, Harald Alvestrand wrote: >> Thanks for the update! >> >> It does seem reasonably clear now - clear enough that I found one point >> that I violently disagree with (if I'm interpreting it correctly). See >> below. >> >> I don't have any negative comments on the rest of the section. >> >> On 04/04/2014 11:24 AM, Magnus Westerlund wrote: >>> WG, >>> (As Author) >>> >>> Colin and I have been working on resolving terminology usage and in >>> general giving the draft a polish over before the WG last call. One >>> section that has gotten quite some attention from us is the below one. >>> The changes are significantly from an editorial stand point. However, >>> the intended content has not been intended to be changed, although >>> clarified and better motivated. So please review it, we intended to >>> include this in the upcoming draft update. Feedback appreciated. >>> >>> 5.1. Conferencing Extensions and Topologies >>> >>> RTP is a protocol that inherently supports group communication. >>> Groups can be implemented by having each endpoint sending its RTP >>> packet streams to an RTP middlebox that redistributes the traffic, by >>> using a mesh of unicast RTP packet streams between endpoints, or by >>> using an IP multicast group to distribute the RTP packet streams. >>> These topologies can be implemented in a number of ways as discussed >>> in [I-D.ietf-avtcore-rtp-topologies-update]. >>> >>> While the use of IP multicast groups is popular in IPTV systems, the >>> topologies based on RTP middleboxes are dominant in interactive video >>> conferencing environments. Topologies based on a mesh of unicast >>> transport-layer flows to create a common RTP session have not seen >>> widespread deployment. Accordingly, WebRTC implementations are not >>> expected to support topologies based on IP multicast groups. WebRTC >>> implementations are also not expected to support mesh-based >>> topologies, such as a point-to-multipoint mesh configured as a single >>> RTP session (Topo-Mesh in the terminology of >>> [I-D.ietf-avtcore-rtp-topologies-update]). However, a point-to- >>> multipoint mesh constructed using several RTP sessions, in the WebRTC >>> context using independent RTCPeerConnections can be expected to be >>> utilised by WebRTC applications. >>> >>> WebRTC implementations of RTP endpoints implemented according to this >>> memo are expected to support all the topologies described in >>> [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send >>> and receive unicast RTP packet streams to some peer device, provided >>> that peer can participate in performing congestion control on the RTP >>> packet streams. The peer device could be another RTP endpoint, or it >>> could be an RTP middlebox that redistributes the RTP packet streams >>> to other RTP endpoints. This limitation means that some of the RTP >>> middlebox-based topologies are not suitable for use in the WebRTC >>> environment. Specifically: >>> >>> o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, >>> since they make the use of RTCP for congestion control and quality >>> of service reports problematic (see Section 3.6.2 of >>> [I-D.ietf-avtcore-rtp-topologies-update]). >>> >>> o Content modifying MCUs with RTCP termination (Topo-RTCP- >>> terminating-MCU) SHOULD NOT be used since they break RTP loop >>> detection, and prevent receivers from identifying active senders >>> (see section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]). >> In my (strong) opinion: This recommendation is wrong. >> >> All central conferencing units that use individual RTP sessions with >> clients fall into this category. This includes, I believe, every single >> multiuser video conferencing system based on WebRTC in existence (and >> there are many of them). > Do they? The point of this topology is that it terminates the source > identification and hides when it is performing any type of mixing or > switching operation. You can perform this with a back to back RTP > session style without breaking this property. Just by correctly linking > information between the sessions. Is there a definition for "correctly linking information"? In particular, are you thinking of mappings that preserve SSRC? Because that's not the ones I'm thinking of. > Which means that the individual RTP > session is from the identification part inseparable from an SFM or > classic RTP mixer. Only the SSRC level loop detection gets impacted. > > I do understand that people have implemented it this way. Implementation > are not necessarily equivalent to recommended practice. But when there's one common practice, and no recommended practice, that might be a gentle hint that there's a reason why people are doing it - indeed, it might be worth making it a recommended practice. > >> I believe the recommendation should be: >> >> * Content modifying MCUs with RTCP termination >> (Topo-RTCP-terminating-MCU) MAY be used. Note that in this scenario, RTP >> loop detection and identification of active senders is the resposibility >> of the application; since the clients are isolated from each other at >> the RTP layer, RTP cannot assist with these functions. >> > If this topology was without issues, then one would simply remove the > bullet, and let it fall under the general clause. However, it clearly > needs that warning. Which results in this topology being both positively > and negatively treated in regards to the other "you may encounter this > topology". It might need that warning - I'm not sure it's a real issue; loop detection is only an issue when you have potential loops, and in a single-mixer architecture, that potential is minimal (each endpoint knows perfectly well the difference between what it's sourcing and what it's receiving). Identification of active senders can be an application-layer thing. Anyway, I stand by my statement: SHOULD NOT is the wrong thing to say. > > 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 7 09:32:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95E51A070E for ; Mon, 7 Apr 2014 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 f8SwWweL2ZTW for ; Mon, 7 Apr 2014 09:32:23 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 55F481A01A9 for ; Mon, 7 Apr 2014 09:32:23 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so5430792wiv.15 for ; Mon, 07 Apr 2014 09:32:17 -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:content-type; bh=HCO5tBQpfHzGFvd+xzd0nyMKG0v7o/92hRkh3S/3bY4=; b=z5zZwUr26kJZyzWrATB5qPdA/eUL9qCcv6Rh7VrtZ6IHndndHefvtK97W7jiMQchr/ AsQ4R61oQFqppt3ut6Tg3lhf5W66OubZEYwfH+Ak9AjLr0ayBAjCkHF/9QcDuF6u49Ig ZonLvh0XpCmN48tECShgrMNbNhO/FdPgq4Xz85k8GvAExrSyqBvNf3ob20tWkMuME7gg hP8dwi2E0P7W6LfFkYpXimg1EYP8XFQsF0wy4cvXt81mcvt6IVrK04qIRUdozZjILXeP yf6eUA/mInuvPxaod8dhEUTmyFnWF0RcmMLqiRfHc6pCNKp1C3+pP4Z0Gs3cOlyhoIoU nALg== MIME-Version: 1.0 X-Received: by 10.180.92.196 with SMTP id co4mr26175992wib.50.1396888336934; Mon, 07 Apr 2014 09:32:16 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Mon, 7 Apr 2014 09:32:16 -0700 (PDT) In-Reply-To: <53419ED4.8020102@alum.mit.edu> References: <533F191D.8050109@alum.mit.edu> <53419ED4.8020102@alum.mit.edu> Date: Mon, 7 Apr 2014 09:32:16 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VXvs1yxQaE8jd4hwwi8X98DN5lg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 16:32:29 -0000 On 6 April 2014 11:37, Paul Kyzivat wrote: > But ISTM there would need to be a different set of limitations for > non-browsers. For instance, to not echo the stream back to the source. And > not to store the stream in a place that the sender can retrieve. Yes. At the most abstract level, the requirements are the same. Don't pass the media on to someone else. From nobody Mon Apr 7 10:01:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4EA1A07AE for ; Mon, 7 Apr 2014 10:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 S8OacO-L03GX for ; Mon, 7 Apr 2014 10:01:17 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8C15D1A07C1 for ; Mon, 7 Apr 2014 10:01:16 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id w62so7149608wes.0 for ; Mon, 07 Apr 2014 10:01:10 -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:content-type; bh=CTET50qn25cN5sNl2dMdAMWt7do1UuS+STtZK6zwIN4=; b=ugtVhxgwPpvxg5EMfo8w01Ffv2sZO483b56HDbqvGGqKxtto3XWL8lzE1MpXecl5ht s7tuHAg3znkdno6ZmuRO8NulMoewYdB6STCTTNGm9J6ox3PaOsw/9UNzDLELvPqKrcD1 yNFdxOYYoLCIeWIEydRFd2WB9OVdP8wQr0fub//DdI0muFw4KdokKDSAVP6uF7HZdwNl I5xBMZJ0hg4fNB4A/ncfzxkC9LTDrvhZC6PcQIgHHXlhFHslZzOKlcrZTm9rufHZcs7I 26p3LvDmmTCusXi922BYz83UUznHrzJMf90DIh70drNp9U2YaUAYqYwGUtbaern2wpnT Sj6Q== MIME-Version: 1.0 X-Received: by 10.180.185.197 with SMTP id fe5mr26695200wic.56.1396890070374; Mon, 07 Apr 2014 10:01:10 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Mon, 7 Apr 2014 10:01:10 -0700 (PDT) In-Reply-To: <53425BAF.4070105@alvestrand.no> References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> Date: Mon, 7 Apr 2014 10:01:10 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vdchn6bPqkSqD_uPWx80RKREvp4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:01:22 -0000 The subject is largely speculative, but when it comes to solutions, the problem will not be a lack of options, but an inability to choose a "right" one. On 7 April 2014 01:02, Harald Alvestrand wrote: > Wild suggestion: if you want per-track isolation properties, open up a data > channel with a protocol called '*WebRTCIsolationInfo' and use it to send > information about the isolation status of each track, thereby also providing > a working example for the rule 'all data channels that have protocols > starting with "*" are for browser internal usage'..... I assume that you are talking PPID here. Given that it's off limits for JavaScript currently, then it does provide an opportunity for this communication. The problem there is that you need to spin up data channels, even if the application has no need of them. That's a fairly high cost. From nobody Mon Apr 7 10:07:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9D81A07C5 for ; Mon, 7 Apr 2014 10:07:54 -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 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 gVjbPuTLUBqR for ; Mon, 7 Apr 2014 10:07:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB2F1A01E0 for ; Mon, 7 Apr 2014 10:07:48 -0700 (PDT) Received: from CH1PR03CA008.namprd03.prod.outlook.com (10.255.156.153) by BLUPR03MB083.namprd03.prod.outlook.com (10.255.209.159) with Microsoft SMTP Server (TLS) id 15.0.918.8; Mon, 7 Apr 2014 17:07:42 +0000 Received: from BY2FFO11FD037.protection.gbl (10.255.156.132) by CH1PR03CA008.outlook.office365.com (10.255.156.153) with Microsoft SMTP Server (TLS) id 15.0.913.9 via Frontend Transport; Mon, 7 Apr 2014 17:07:41 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD037.mail.protection.outlook.com (10.1.14.222) with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Mon, 7 Apr 2014 17:07:41 +0000 Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.124]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0181.007; Mon, 7 Apr 2014 17:07:01 +0000 From: "Matthew Kaufman (SKYPE)" To: Martin Thomson , Harald Alvestrand Thread-Topic: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) Thread-Index: AQHPUjfRb53lyS9CtEOLJeBSW/E7VJsGYYMAgAABZTA= Date: Mon, 7 Apr 2014 17:07:00 +0000 Message-ID: References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(189002)(199002)(80022001)(2656002)(55846006)(69226001)(65816001)(66066001)(92566001)(93136001)(83072002)(81686001)(90146001)(81816001)(97736001)(56816005)(92726001)(85852003)(95416001)(81342001)(94946001)(31966008)(99396002)(80976001)(87266001)(97336001)(97756001)(98676001)(2009001)(76796001)(20776003)(87936001)(44976005)(86362001)(74502001)(53806001)(95666003)(97186001)(84676001)(47446002)(63696002)(93516002)(81542001)(59766001)(85306002)(76482001)(74366001)(56776001)(54316002)(77982001)(74662001)(6806004)(74706001)(4396001)(94316002)(74876001)(19580395003)(76786001)(54356001)(23726002)(79102001)(46406003)(77096001)(47736001)(49866001)(50986001)(50466002)(19580405001)(47976001)(46102001)(33656001)(47776003)(83322001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB083; H:mail.microsoft.com; FPR:9EEA3D.8CF42FCE.9EC4B10E.4466AFA9.200CF; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0174BD4BDA Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9RSN5Ok8NlKAB9SOJGCYQ3-yMWo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:07:54 -0000 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin > Thomson >... The problem there is that you need to spin up data > channels, even if the application has no need of them. That's a fairly h= igh > cost. But only because the working group chose poorly for how data channels are t= ransported. Matthew Kaufman From nobody Mon Apr 7 10:11:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6B71A04A7 for ; Mon, 7 Apr 2014 10:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 lbkcBvPbnthW for ; Mon, 7 Apr 2014 10:11:35 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 879701A047B for ; Mon, 7 Apr 2014 10:11:35 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so5508270wiv.9 for ; Mon, 07 Apr 2014 10:11:29 -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:content-type; bh=OwYKcfEcxi+8PMuryX4YhyX3yBSXvuArWE8hj+KjRxc=; b=xENArN6Bk9NOb/ceh2rrugVn30Ro5x9gC6S1zIa4rZZQ8Q2sbztLC2FR5N1/u39pOP dMC9o0cmmnn62BNOqJMBBEiDZYLWPA8tqYqNoBrNkatp79LRPzTTNBHXC0SjAi9dEua8 JVyGnSNdjwUVLNXpBy55Lceh82bfsVRBGEG+m+Hv5pbKIrGO8Axtw4M2vp86xWU+ZqRu 88L/QDTIPXKdBeXgUZSkqzC6sI/NN10y1Xw01Awga+UP+UNfXxL8xhpuYMukLOL0oGjj 4PVNZyyYmseJxN5+BT7SU35QG7tlpWsICXX30zs6RH+T1xraY8gzHg4Tsgeq89th1E6r KAoA== MIME-Version: 1.0 X-Received: by 10.194.94.39 with SMTP id cz7mr3330955wjb.78.1396890689387; Mon, 07 Apr 2014 10:11:29 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Mon, 7 Apr 2014 10:11:29 -0700 (PDT) In-Reply-To: References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> Date: Mon, 7 Apr 2014 10:11:29 -0700 Message-ID: From: Martin Thomson To: "Matthew Kaufman (SKYPE)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WXn0CLL2P8VULYNoJjKkOluyC1A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:11:40 -0000 On 7 April 2014 10:07, Matthew Kaufman (SKYPE) wrote: > the working group chose poorly Yes, thanks. That seems to be a pattern. It's just not always obvious immediately. Sometimes it doesn't matter. Especially when you haven't noticed yet. From nobody Mon Apr 7 10:21:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECA31A047A for ; Mon, 7 Apr 2014 10:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dlrIQZsavxIs for ; Mon, 7 Apr 2014 10:20:54 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 886C21A027A for ; Mon, 7 Apr 2014 10:20:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8A3B57C50FA; Mon, 7 Apr 2014 19:20:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1HAcb3U2huY; Mon, 7 Apr 2014 19:20:47 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id B80AF7C50F2; Mon, 7 Apr 2014 19:20:47 +0200 (CEST) Message-ID: <5342DE6F.6040306@alvestrand.no> Date: Mon, 07 Apr 2014 19:20:47 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Thomson References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KTAwNhbCqUgSdikqVmdh45TSXzA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:21:00 -0000 On 04/07/2014 07:01 PM, Martin Thomson wrote: > The subject is largely speculative, but when it comes to solutions, > the problem will not be a lack of options, but an inability to choose > a "right" one. > > On 7 April 2014 01:02, Harald Alvestrand wrote: >> Wild suggestion: if you want per-track isolation properties, open up a data >> channel with a protocol called '*WebRTCIsolationInfo' and use it to send >> information about the isolation status of each track, thereby also providing >> a working example for the rule 'all data channels that have protocols >> starting with "*" are for browser internal usage'..... > I assume that you are talking PPID here. Given that it's off limits > for JavaScript currently, then it does provide an opportunity for this > communication. The problem there is that you need to spin up data > channels, even if the application has no need of them. That's a > fairly high cost. I was actually thinking "protocol" as in the string that goes into the datachannel setup packets. PPIDs would work too for separating browser-to-brower from app-to-app, but I wasn't thinking of them. Yes, data channels do cost something to set up. But we're already paying the DTLS tax in order to set up the keying, so it's "just" another request/response. How many extra round trips does the SCTP setup add? (Would need the response in order to make sure the respondent gave the promise to obey isolation, I think.) (and to Matthew: At least we wouldn't have *yet* another congestion context to manage, which would be the case with a separate TCP connection. There are always tradeoffs.) From nobody Mon Apr 7 10:23:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0101A07BE for ; Mon, 7 Apr 2014 10:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 yAnw1MYmPke1 for ; Mon, 7 Apr 2014 10:23:12 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id B25D11A0794 for ; Mon, 7 Apr 2014 10:23:11 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id q5so5478474wiv.7 for ; Mon, 07 Apr 2014 10:23:05 -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:content-type; bh=BRVPZc9kbn+D9RHLUWFK6aFaumNgePxaRY+qNM/G8+s=; b=pBeuwpvjQbFm4gRrt//P7QI+BrmOzEDqjui+MsJUMLmIMAwUuhpgRtgwdU7VjvsOGV I2g+N5VNHgTBWPXUk5ugOr3hC0z1+MBh37g5zaqU+7oz8LDYRim+9rq+G+6zd6MS9QzV XCJZq1Sl0FFiDRc1+VDz3Wx69YLRNpfbi2zTMcUEYUQ+XIL1DFUeWGeLhqVbg8MSGQsr r+p4YumdZ4HH+MBQMovKKdGO7gRVInXIqtaZ6016ojKB14LluFsqO54vwl1R8LWyNjvi zrlb4Ts4HmfZq0JRQm0zMMaiU+MHZ4Wp1rKxS4RtAFIEZrSF19SzlhsH2DYIfmb9kV9f ZO+w== MIME-Version: 1.0 X-Received: by 10.180.188.134 with SMTP id ga6mr2467378wic.58.1396891385614; Mon, 07 Apr 2014 10:23:05 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Mon, 7 Apr 2014 10:23:05 -0700 (PDT) In-Reply-To: <5342DE6F.6040306@alvestrand.no> References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> <5342DE6F.6040306@alvestrand.no> Date: Mon, 7 Apr 2014 10:23:05 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fI6RufzZslb9H1oQTTJWRNqvosI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:23:19 -0000 On 7 April 2014 10:20, Harald Alvestrand wrote: > I was actually thinking "protocol" as in the string that goes into the > datachannel setup packets. PPIDs would work too for separating > browser-to-brower from app-to-app, but I wasn't thinking of them. That would require carving out a space to use right now. That impinges to much on application autonomy for my liking. > Yes, data channels do cost something to set up. But we're already paying the > DTLS tax in order to set up the keying, so it's "just" another > request/response. How many extra round trips does the SCTP setup add? 2. > (and to Matthew: At least we wouldn't have *yet* another congestion context to > manage, which would be the case with a separate TCP connection. There are > always tradeoffs.) I'm certain that Matthew wasn't talking about TCP. From nobody Mon Apr 7 10:28:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93981A040D for ; Mon, 7 Apr 2014 10:28:14 -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 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 cBO76JGjM7Zr for ; Mon, 7 Apr 2014 10:28:10 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2DE1A0203 for ; Mon, 7 Apr 2014 10:28:09 -0700 (PDT) Received: from BY2PR03CA036.namprd03.prod.outlook.com (10.242.234.157) by BY2PR03MB553.namprd03.prod.outlook.com (10.141.141.155) with Microsoft SMTP Server (TLS) id 15.0.913.9; Mon, 7 Apr 2014 17:27:56 +0000 Received: from BN1BFFO11FD040.protection.gbl (2a01:111:f400:7c10::1:163) by BY2PR03CA036.outlook.office365.com (2a01:111:e400:2c2c::29) with Microsoft SMTP Server (TLS) id 15.0.908.10 via Frontend Transport; Mon, 7 Apr 2014 17:27:56 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD040.mail.protection.outlook.com (10.58.144.103) with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Mon, 7 Apr 2014 17:27:56 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.193) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.3.181.7; Mon, 7 Apr 2014 17:27:15 +0000 Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.124]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0174.002; Mon, 7 Apr 2014 17:27:15 +0000 From: "Matthew Kaufman (SKYPE)" To: Harald Alvestrand , Martin Thomson Thread-Topic: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) Thread-Index: AQHPUjfRb53lyS9CtEOLJeBSW/E7VJsGYYMAgAAFe4CAAADocA== Date: Mon, 7 Apr 2014 17:27:14 +0000 Message-ID: References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> <5342DE6F.6040306@alvestrand.no> In-Reply-To: <5342DE6F.6040306@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(189002)(199002)(65816001)(80022001)(66066001)(74366001)(74706001)(74662001)(16796002)(74502001)(63696002)(47446002)(59766001)(77982001)(74876001)(31966008)(79102001)(20776003)(50466002)(55846006)(47776003)(6806004)(19580395003)(19580405001)(83322001)(44976005)(85306002)(90146001)(56816005)(2656002)(87266001)(87936001)(69226001)(97736001)(97186001)(97336001)(76796001)(76786001)(77096001)(84676001)(81686001)(81816001)(92726001)(93136001)(83072002)(85852003)(86362001)(80976001)(93516002)(92566001)(54316002)(94946001)(56776001)(94316002)(76482001)(33656001)(98676001)(49866001)(81342001)(47976001)(47736001)(54356001)(50986001)(4396001)(53806001)(81542001)(46102001)(97756001)(95416001)(95666003)(2009001)(99396002)(23726002)(46406003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB553; H:mail.microsoft.com; FPR:1C94FA1E.9C26C789.3CF3B1C7.64E462A0.2016E; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0174BD4BDA Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wK32lBzd2s5OTjzDjeL9poq7Zo4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:28:15 -0000 From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > Alvestrand >... > (and to Matthew: At least we wouldn't have *yet* another congestion > context to manage, which would be the case with a separate TCP connection= . > There are always tradeoffs.) If it was me (and at one time, it was) I would use a protocol that allows f= or multiplexing and prioritization of media and data channels over the same= secure session with shared congestion state. Over such a protocol, opening= another data stream for this purpose could be done immediately without eve= n a round trip. RFC 7016 documents such an approach. Matthew Kaufman From nobody Mon Apr 7 10:38:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB7D1A07F7 for ; Mon, 7 Apr 2014 10:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 riI_5zhY7JqC for ; Mon, 7 Apr 2014 10:38:35 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 3243B1A07EF for ; Mon, 7 Apr 2014 10:38:20 -0700 (PDT) Received: from [192.168.1.200] (p508F3041.dip0.t-ipconnect.de [80.143.48.65]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 84B401C1047EC; Mon, 7 Apr 2014 19:38:12 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: Date: Mon, 7 Apr 2014 19:38:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7E595777-F510-48A0-87FA-0941621D8B26@lurchi.franken.de> References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> <5342DE6F.6040306@alvestrand.no> To: Martin Thomson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TyJTJF8C_dxtZFtKzcr-K3VqEA4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:38:42 -0000 On 07 Apr 2014, at 19:23, Martin Thomson = wrote: > On 7 April 2014 10:20, Harald Alvestrand wrote: >> I was actually thinking "protocol" as in the string that goes into = the >> datachannel setup packets. PPIDs would work too for separating >> browser-to-brower from app-to-app, but I wasn't thinking of them. >=20 > That would require carving out a space to use right now. That > impinges to much on application autonomy for my liking. >=20 >> Yes, data channels do cost something to set up. But we're already = paying the >> DTLS tax in order to set up the keying, so it's "just" another >> request/response. How many extra round trips does the SCTP setup add? >=20 > 2. Right now: Correct. But one could optimise the initial handshake... Best regards Michael >=20 >> (and to Matthew: At least we wouldn't have *yet* another congestion = context to >> manage, which would be the case with a separate TCP connection. There = are >> always tradeoffs.) >=20 > I'm certain that Matthew wasn't talking about TCP. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Apr 7 11:01:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0F01A082F for ; Mon, 7 Apr 2014 11:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 GguWhoY8c3Fz for ; Mon, 7 Apr 2014 11:01:17 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2AA1A081E for ; Mon, 7 Apr 2014 11:01:10 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so5591296wiv.7 for ; Mon, 07 Apr 2014 11:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=84/Qm7KfjasCa8AdFjhvDWfd2DHHXVPlhL8VJ/T+YnE=; b=Ph8vfk/uPHlK5jMsJMaHYb/EzNHfttBV2IWSLnCEgbrldVae2EAss/Jj2ockezsqpH xl9S2Nq6cOrt8jacsPzCYUo8rEQ1klKrAY1Sc6vuwQqMITXG5TgkxwykQhtGv99zkXY4 3i6jiE/+5IG4bCrTAiLnwEzDv2UlMIwooVvIDrCkgTTF9Zuf/RREUF1l0uVuoIaMlxx8 87WxulrTo7whMoGy+XiC46d/t6Qfv+F1ptNAXt26GH9OLBMr90vVnO0ii38cpzs3cojE HMc+tv1rUpupkWT6AYn8WwZmiFW4LqJJiAhLcOIB1Wdfb3JDp+fD8YI3HUrYKC4UN6bc XVuA== X-Received: by 10.194.174.42 with SMTP id bp10mr43635038wjc.57.1396893664494; Mon, 07 Apr 2014 11:01:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.102.130 with HTTP; Mon, 7 Apr 2014 11:00:43 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Mon, 7 Apr 2014 11:00:43 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e01493cb4a94dd404f677a65f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cB39fVFe85-emEumLFMDMLHyqvo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 18:01:23 -0000 --089e01493cb4a94dd404f677a65f Content-Type: text/plain; charset=ISO-8859-1 Martin said: "With the TLS handshake, you either get a marked session, or you don't get a session at all. That's a big advantage with this approach. And it costs far fewer bytes." [BA] Agreed. To be clear, the "marked session" we are talking about is the DTLS session. All DTLS/SRTP sessions subsequently occurring within that DTLS marked session inherit the "isolation" property, correct? The implication here is that not only do media sharing the same DTLS session (e.g. audio and video multiplexed on the same port) share the "isolation" property, but even if audio and video are not multiplexed, if the same DTLS session is used by subsequent DTLS/SRTP sessions, then the "isolation" property is also shared. >From RFC 5764, Section 3: RTP and RTCP traffic MAY be multiplexed on a single UDP port [RFC5761 ]. In this case, both RTP and RTCP packets may be sent over the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions needed. This improves the cryptographic performance of DTLS, but may cause problems when RTCP and RTP are subject to different network treatment (e.g., for bandwidth reservation or scheduling reasons). Between a single pair of participants, there may be multiple media sessions. There MUST be a separate DTLS-SRTP session for each distinct pair of source and destination ports used by a media session (though the sessions can share a single DTLS session and hence amortize the initial public key handshake!). On Thu, Apr 3, 2014 at 8:25 PM, Martin Thomson wrote: > Perhaps some more context is necessary. > > (D)TLS provides us good protection against network attackers. The > problem is that this protection ends at the browser, and our security > story doesn't. Media streams in the browser are an extension of those > that traverse the network, and we need something of a gentlemen's > agreement between browsers to be reached. That agreement says that > your browser and mine will agree between themselves to protect media > from the application that is running in their sandbox: all that nasty > JavaScript that came from a site (or sites) that we might not want to > include in our conversation. > > On 3 April 2014 19:49, Watson Ladd wrote: > > The MITM can kill any TLS connection containing the extension. My > > understanding is that signalling data is immutable, hence the need to > > ask the browser to generate it. > > Signaling is totally mutable, which is a big problem. Once an > application gets it, there's a lot that can be changed between peers. > > >> However once the desire for isolation is communicated E2E (either via > ACP or > >> ALPN tokens), there is nothing in the SRTP traffic (keyed by DTLS/SRTP) > that > >> indicates that the traffic is to be isolated. > > > > I don't see why the isolation status cannot be included as an > > extension to SRTP. You aren't asking TLS to make extensions for video > > resolution and codec after all. > > That's a good question, and it's an option I should have added to the > list. The problem there is that nothing in RTP is reliable, and this > signal needs to be reliable. Combine that with the fact that the > extent of an RTP session is essentially unknowable, and you end up > having to put an RTP header extension on every packet. RTP header > extensions have other drawback as well, though I suspect most of those > aren't applicable in this context. > > With the TLS handshake, you either get a marked session, or you don't > get a session at all. That's a big advantage with this approach. And > it costs far fewer bytes. > --089e01493cb4a94dd404f677a65f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Martin said:=A0

"With the TLS handshake, you eith= er get a marked session, or you don't
get a session at all. =A0That's = a big advantage with this approach. =A0And
it costs f= ar fewer bytes."

[BA] Agreed. =A0To be= clear, the "marked session" we are talking about is the DTLS ses= sion. =A0All DTLS/SRTP sessions subsequently occurring within that DTLS mar= ked session inherit the "isolation" property, correct?=A0

The implication here is that not only do media sharing = the same DTLS session (e.g. audio and video multiplexed on the same port) s= hare the "isolation" property, but even if audio and video are no= t multiplexed, if the same DTLS session is used by subsequent DTLS/SRTP ses= sions, then the "isolation" property is also shared.=A0

From RFC 5764, Section 3:=A0

<= pre class=3D"" style=3D"font-size:1em;margin-top:0px;margin-bottom:0px;colo= r:rgb(0,0,0)"> RTP and RTCP traffic MAY be multiplexed on a single UDP po= rt [RFC5761]. In = this case, both RTP and RTCP packets may be sent over the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions needed. This improves the cryptographic performance of DTLS, but may cause problems when RTCP and RTP are subject to different network treatment (e.g., for bandwidth reservation or scheduling reasons). Between a single pair of participants, there may be multiple media sessions. There MUST be a separate DTLS-SRTP session for each distinct pair of source and destination ports used by a media session (though the sessions can share a single DTLS session and hence amortize the initial public key handshake!).

<= div>




On Thu, Apr 3, 2014 at 8:25 PM, Martin= Thomson <martin.thomson@gmail.com> wrote:
Perhaps some more context is necessary.

(D)TLS provides us good protection against network attackers. =A0The
problem is that this protection ends at the browser, and our security
story doesn't. =A0Media streams in the browser are an extension of thos= e
that traverse the network, and we need something of a gentlemen's
agreement between browsers to be reached. =A0That agreement says that
your browser and mine will agree between themselves to protect media
from the application that is running in their sandbox: all that nasty
JavaScript that came from a site (or sites) that we might not want to
include in our conversation.

On 3 April 2014 19:49, Watson Ladd <watsonbladd@gmail.com> wrote:
> The MITM can kill any TLS connection containing the extension. My
> understanding is that signalling data is immutable, hence the need to<= br> > ask the browser to generate it.

Signaling is totally mutable, which is a big problem. =A0Once an
application gets it, there's a lot that can be changed between peers.

>> However once the desire for isolation is communicated E2E (either = via ACP or
>> ALPN tokens), there is nothing in the SRTP traffic (keyed by DTLS/= SRTP) that
>> indicates that the traffic is to be isolated.
>
> I don't see why the isolation status cannot be included as an
> extension to SRTP. You aren't asking TLS to make extensions for vi= deo
> resolution and codec after all.

That's a good question, and it's an option I should have adde= d to the
list. =A0The problem there is that nothing in RTP is reliable, and this
signal needs to be reliable. =A0Combine that with the fact that the
extent of an RTP session is essentially unknowable, and you end up
having to put an RTP header extension on every packet. =A0RTP header
extensions have other drawback as well, though I suspect most of those
aren't applicable in this context.

With the TLS handshake, you either get a marked session, or you don't get a session at all. =A0That's a big advantage with this approach. =A0= And
it costs far fewer bytes.

--089e01493cb4a94dd404f677a65f-- From nobody Mon Apr 7 11:08:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7E91A01AE for ; Mon, 7 Apr 2014 11:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 WrE_EyigNkV9 for ; Mon, 7 Apr 2014 11:08:35 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 80B331A0267 for ; Mon, 7 Apr 2014 11:08:33 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so6606661wib.3 for ; Mon, 07 Apr 2014 11:08:27 -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:content-type; bh=/B5UWfpArl37ZBrT9iV2i/IIAyNZoZi/0vUWpUgoEiw=; b=u+vkO0AK7MHWN5jPpYopb7qQpAT+ZEgF9baf5RZgwqGd/Y62ihWE3D2GPm0a0ospu/ D8Un7y1HmO42qkKlKxWJwNr31LWHr+oK6zsI2p0ziuguPIItjhbFYxQUZe3gCvOSzzno ffJPCWG7sr6NZz6gJY+l534CaalPc0Qyp+8H3l4o3gA7vdxIa5p3UWhSWDybr5VwI5wW t0qTEsC2boYsZleFdH2V5kEjbqBiCar+gvIhCm8oEDXe1Nu9Z4FEy2YyqJKqI7yz3Q4f Q7mCFSRmo6fCE7i85TDjsXpF6TvTPT0HviSlSjH5tMA9AzVMc9tWXG1CmgLSfkJZ2N1D tekw== MIME-Version: 1.0 X-Received: by 10.180.185.197 with SMTP id fe5mr26998720wic.56.1396894107443; Mon, 07 Apr 2014 11:08:27 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Mon, 7 Apr 2014 11:08:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Apr 2014 11:08:27 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ylnnuvDot6dEUzYQ5bP5jv8NGvE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 18:08:41 -0000 On 7 April 2014 11:00, Bernard Aboba wrote: > The implication here is that not only do media sharing the same DTLS session > (e.g. audio and video multiplexed on the same port) share the "isolation" > property, but even if audio and video are not multiplexed, if the same DTLS > session is used by subsequent DTLS/SRTP sessions, then the "isolation" > property is also shared. The usual behaviour is to use the same 5-tuple for sending SRTP as the one used for the DTLS handshake. However, if the extracted keys from the DTLS session is used to key different SRTP flows on other 5-tuples, then I suppose that the conditions attached to the DTLS session would have to apply to those separate flows too. That means isolation, authentication, and whatever else we bind in. I'm not sure that I'd do that, given the risks of things like SSRC reuse, but maybe I'm misunderstanding the question. From nobody Mon Apr 7 11:20:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A271A04AF for ; Mon, 7 Apr 2014 11:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 pvI2mUaqKlyu for ; Mon, 7 Apr 2014 11:20:14 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id ECFB01A0847 for ; Mon, 7 Apr 2014 11:20:10 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id ur14so3968410igb.8 for ; Mon, 07 Apr 2014 11:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UBB6WqZCP/PNkeHlH3uw4vFtr+2xPx0J8ti3dihMfCo=; b=vcGXGftjYZ0bABGU8dy+AwqHCv//fUGVF8hhEaqfc6r65+YIADeIA22PSSXwcMWi9l JNyEm3dR9j0luVRWXdr1OpxYjLEhg7Xu+UZO5uA8H2hl/RD5jsf8GDAGyGQl0UhYKRBY nC9MzlU4h9L+rf5QUO2+atb/oVfewbisBIAJSuT5uLgrHhgBfXKFWGRLmpvNJeMVKUbH aBaR0qlWlDlskRDVjRFQZodzchOBfGpB3NTLycDN3jpln5OgBnYUx6RZN6wqRvsa/+24 Rd3L7yvOkf2RTXa+P1MhlUHfzdKDhEjoinAx7qwvjCX7Qc5w1Q14zmag+W3FF6Re+PpD HDbw== MIME-Version: 1.0 X-Received: by 10.42.113.137 with SMTP id c9mr2043971icq.90.1396894805289; Mon, 07 Apr 2014 11:20:05 -0700 (PDT) Received: by 10.42.200.204 with HTTP; Mon, 7 Apr 2014 11:20:05 -0700 (PDT) Date: Mon, 7 Apr 2014 11:20:05 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a1130c446a8703a04f677eab4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CjJkxxpe06kILY3sabsTnQNldv4 Subject: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 18:20:21 -0000 --001a1130c446a8703a04f677eab4 Content-Type: text/plain; charset=ISO-8859-1 Howdy, The chairs recently asked for a review draft-ietf-rtcweb-stun-consent-freshness; Oleg was kind enough to do one. Below is the review. regards, Ted On Fri, Apr 4, 2014 at 12:40 AM, Oleg Moskalenko wrote: Hi Ted I went through the document and I have two things to comment: 1) This document defines a "voluntary" pattern of the browser behavior. Nothing stops the determined attacker from taking the WebRTC code and creating a malicious client application that ignores all proposed connectivity checks. May be it is worth mentioning in the "Security Considerations" section. 2) I have a feeling that the document is written with somewhat optimistic idea about the modern IP network qualities. The proposed timeouts are probably too small. I am hearing from our TURN server users that in modern Wi Fi public networks that's common to observe a freeze the IP traffic for several seconds. After that "freeze" the connectivity is restored. The users do not want the connection to be broken during that time - they want the video screen frozen, temporary. I had to make adjustments to the TURN server in our recent versions so that it does not disconnects the sessions too quickly under those conditions (when TCP is used). I have a feeling that you may have the same complains that the browser stops transmission in public Wi Fi networks too quickly. I'd suggest to review the wording of the proposal (like re-transmission after 500 ms and 15 secs timeout) to make it more tolerant for the bad IP networks (which are surprisingly are rather common). Overall, I think that this proposal is very useful. Best regards, Oleg --001a1130c446a8703a04f677eab4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Howdy,

The chairs recently asked for a review draft-ietf-rtcweb-s= tun-consent-freshness; Oleg was kind enough to do one.=A0 Below is the revi= ew.

regards,

Ted


On Fri, Apr 4, 2014 at 12:40 AM, Oleg Moskal= enko <mom040267@gmail.com> wrote:
Hi Ted

I went through the document an= d I have two things to comment:

1) This document defines a "voluntary" pattern of the b= rowser=20 behavior. Nothing stops the determined attacker from taking the WebRTC=20 code and creating a malicious client application that ignores all=20 proposed connectivity checks. May be it is worth mentioning in the=20 "Security Considerations" section.

2) I have a feeling that the document is written with somewhat optimistic idea about the modern IP network qualities. The proposed=20 timeouts are probably too small. I am hearing from our TURN server users that in modern Wi Fi public networks that's common to observe a freeze= =20 the IP traffic for several seconds. After that "freeze" the conne= ctivity is restored. The users do not want the connection to be broken during=20 that time - they want the video screen frozen, temporary. I had to make=20 adjustments to the TURN server in our recent versions so that it does=20 not disconnects the sessions too quickly under those conditions (when=20 TCP is used). I have a feeling that you may have the same complains that the browser stops transmission in public Wi Fi networks too quickly.=20 I'd suggest to review the wording of the proposal (like re-transmission= =20 after 500 ms and 15 secs timeout) to make it more tolerant for the bad=20 IP networks (which are surprisingly are rather common).

Overall, I think that this proposal is very useful.

= Best regards,
Oleg
--001a1130c446a8703a04f677eab4-- From nobody Mon Apr 7 12:21:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FB81A07DE for ; Mon, 7 Apr 2014 12:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 cjkorgx4IbT3 for ; Mon, 7 Apr 2014 12:21:38 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id A24A31A04B9 for ; Mon, 7 Apr 2014 12:21:38 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta01.westchester.pa.mail.comcast.net with comcast id n0Hs1n0050QuhwU517MYJN; Mon, 07 Apr 2014 19:21:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id n7MY1n00N3ZTu2S3N7MYwu; Mon, 07 Apr 2014 19:21:32 +0000 Message-ID: <5342FABC.4080200@alum.mit.edu> Date: Mon, 07 Apr 2014 15:21:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> <5342DE6F.6040306@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396898492; bh=RKRHH5tSQaJw+zyuzOAOygU/PvMcsM51TOTDHZkEEKI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LgNoAWSJWR1+bng3/9AcRPGkURfWBKgW19kLlNM8zItPSXBRaJXoboup71E/qi6S+ biICAuROKA5UYdyZIBeiykSasae0cYDPfhRLNF63zKhc/Fb7uyUOWEgkfGtO9hiFvh 0rNG5Ujsil0akc8TOwFvZme1lxcXSRtUzuDHdn5Oo3Ga0rjizbGvz7JbBrk1UKs2Fi QRJui/4yvn6E0EB5agw2rE5V1abQzQgad+rVL/Up2bOdug7Z4qr2Ni573jpGXIMaV1 47IFYTBlaRjYyneqY8JadvQrmoC0c30h2ox7sbsa6HWqFUZSeAM1jXY1xTh+3KQQZb IOz/BbySfMk+A== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XtbOdDLIGszycNumFQKgx932YIU Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 19:21:43 -0000 On 4/7/14 1:27 PM, Matthew Kaufman (SKYPE) wrote: > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >> Alvestrand >> ... >> (and to Matthew: At least we wouldn't have *yet* another congestion >> context to manage, which would be the case with a separate TCP connection. >> There are always tradeoffs.) > > If it was me (and at one time, it was) I would use a protocol that allows for multiplexing and prioritization of media and data channels over the same secure session with shared congestion state. Over such a protocol, opening another data stream for this purpose could be done immediately without even a round trip. > > RFC 7016 documents such an approach. I see that the title starts with "Adobe's". Sigh. If you want to entertain something other than existing solutions for media, why not simply run the RTP media streams over SCTP along with the data channels? Thanks, Paul From nobody Mon Apr 7 12:28:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73B41A0237 for ; Mon, 7 Apr 2014 12:28:17 -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, SPF_HELO_PASS=-0.001] autolearn=ham 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 ynJ2pHMl7HHW for ; Mon, 7 Apr 2014 12:28:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE4D1A079D for ; Mon, 7 Apr 2014 12:27:58 -0700 (PDT) Received: from BY2PR03CA034.namprd03.prod.outlook.com (10.242.234.155) by BY2PR03MB363.namprd03.prod.outlook.com (10.242.237.16) with Microsoft SMTP Server (TLS) id 15.0.913.9; Mon, 7 Apr 2014 19:27:51 +0000 Received: from BN1AFFO11FD017.protection.gbl (2a01:111:f400:7c10::192) by BY2PR03CA034.outlook.office365.com (2a01:111:e400:2c2c::27) with Microsoft SMTP Server (TLS) id 15.0.908.10 via Frontend Transport; Mon, 7 Apr 2014 19:27:51 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD017.mail.protection.outlook.com (10.58.52.77) with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Mon, 7 Apr 2014 19:27:48 +0000 Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.124]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0181.007; Mon, 7 Apr 2014 19:27:12 +0000 From: "Matthew Kaufman (SKYPE)" To: Paul Kyzivat , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) Thread-Index: AQHPUjfRb53lyS9CtEOLJeBSW/E7VJsGYYMAgAAFe4CAAADocIAAINQAgAABNqA= Date: Mon, 7 Apr 2014 19:27:11 +0000 Message-ID: References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> <5342DE6F.6040306@alvestrand.no> <5342FABC.4080200@alum.mit.edu> In-Reply-To: <5342FABC.4080200@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; ?= =?us-ascii?Q?SFS:(10009001)(6009001)(438001)(479174003)(51704005)(1346400?= =?us-ascii?Q?3)(377454003)(24454002)(189002)(199002)(46102001)(85306002)(?= =?us-ascii?Q?53806001)(79102001)(54356001)(93516002)(33656001)(84676001)(?= =?us-ascii?Q?59766001)(77982001)(54316002)(99396002)(56776001)(97336001)(?= =?us-ascii?Q?94946001)(92566001)(95666003)(44976005)(2656002)(97186001)(9?= =?us-ascii?Q?8676001)(66066001)(4396001)(2009001)(76482001)(94316002)(319?= =?us-ascii?Q?66008)(49866001)(47976001)(92726001)(95416001)(46406003)(809?= =?us-ascii?Q?76001)(86362001)(81542001)(47736001)(81342001)(97756001)(658?= =?us-ascii?Q?16001)(87266001)(80022001)(97736001)(76786001)(74706001)(818?= =?us-ascii?Q?16001)(23726002)(6806004)(69226001)(74366001)(2171001)(20776?= =?us-ascii?Q?003)(56816005)(19580405001)(77096001)(74662001)(74876001)(50?= =?us-ascii?Q?986001)(74502001)(81686001)(87936001)(47446002)(93136001)(90?= =?us-ascii?Q?146001)(76796001)(83072002)(63696002)(50466002)(83322001)(55?= =?us-ascii?Q?846006)(19580395003)(47776003)(85852003);DIR:OUT;SFP:1101;SC?= =?us-ascii?Q?L:1;SRVR:BY2PR03MB363;H:mail.microsoft.com;FPR:FC97F016.A7FA?= =?us-ascii?Q?C789.3CD0314B.C4E4D271.2029B;MLV:sfv;PTR:InfoDomainNonexiste?= =?us-ascii?Q?nt;MX:1;A:1;LANG:en;?= X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0174BD4BDA Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JlqQZ549bNsaEtYN_eGMAgGJLKI Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 19:28:18 -0000 -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, April 7, 2014 12:22 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help wi= th > media isolation) >=20 > On 4/7/14 1:27 PM, Matthew Kaufman (SKYPE) wrote: > > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > >> Alvestrand > >> ... > >> (and to Matthew: At least we wouldn't have *yet* another congestion > >> context to manage, which would be the case with a separate TCP > connection. > >> There are always tradeoffs.) > > > > If it was me (and at one time, it was) I would use a protocol that allo= ws for > multiplexing and prioritization of media and data channels over the same > secure session with shared congestion state. Over such a protocol, openin= g > another data stream for this purpose could be done immediately without > even a round trip. > > > > RFC 7016 documents such an approach. >=20 > I see that the title starts with "Adobe's". Sigh. Yes, but there's little stopping many of these ideas from becoming the basi= s for an IETF-developed transport protocol that actually meets the needs we= have here. =20 > If you want to entertain something other than existing solutions for medi= a, > why not simply run the RTP media streams over SCTP along with the data > channels? Except for some critical shortcomings of SCTP (which are being fixed), this= isn't actually a terrible idea. Matthew Kaufman From nobody Mon Apr 7 12:32:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6D21A0256 for ; Mon, 7 Apr 2014 12:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 16WDmPpQkVRv for ; Mon, 7 Apr 2014 12:32:15 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 023771A081F for ; Mon, 7 Apr 2014 12:32:14 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so7443052wgh.32 for ; Mon, 07 Apr 2014 12:32:08 -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:content-type; bh=E8m5p5Bj2IM4HncK3xdNvBbn3YxsRThFs6hOmjJTd3s=; b=MQ70m8wf8GSN6kqt+3gEmIfuFl8sCaoLanY81rxJC0ttxHwiFn8QMF5l7HovLOBbAV N+NOnOI9Ghoe7eWDxo0AH9+QH2O/9TSOkwhvsU7Sry+3gBfSJk4vxyoZxytNThOnRbmC EWSd/JrcktB8US8XZeNG1RYlS/Q/lU18v+oioejs5DHTGeKbfxG+jKGPJ51MjXpRbZ2F /Oy6vIimsXFVLu86QGBg2681G1gw6yAzRDxCHEO+KM9cwNz1cApyD4YOsZ2VZR1Huh6P UZYMf+QbeuDdw6sZPHHxjGlikTOrB7RHqEIS3Qu1TvnYAi607sQXaBuEKGVRdgjF2JM9 sobg== MIME-Version: 1.0 X-Received: by 10.180.149.143 with SMTP id ua15mr138431wib.36.1396899128627; Mon, 07 Apr 2014 12:32:08 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Mon, 7 Apr 2014 12:32:08 -0700 (PDT) In-Reply-To: References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> <5342DE6F.6040306@alvestrand.no> <5342FABC.4080200@alum.mit.edu> Date: Mon, 7 Apr 2014 14:32:08 -0500 Message-ID: From: Mary Barnes To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=001a11c38e7059564204f678ec9c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/o_27XX08fe0DfDKnoInElXwA7Fc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 19:32:20 -0000 --001a11c38e7059564204f678ec9c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 7, 2014 at 2:27 PM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Monday, April 7, 2014 12:22 PM > > To: rtcweb@ietf.org > > Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help > with > > media isolation) > > > > On 4/7/14 1:27 PM, Matthew Kaufman (SKYPE) wrote: > > > > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > > >> Alvestrand > > >> ... > > >> (and to Matthew: At least we wouldn't have *yet* another congestion > > >> context to manage, which would be the case with a separate TCP > > connection. > > >> There are always tradeoffs.) > > > > > > If it was me (and at one time, it was) I would use a protocol that > allows for > > multiplexing and prioritization of media and data channels over the same > > secure session with shared congestion state. Over such a protocol, > opening > > another data stream for this purpose could be done immediately without > > even a round trip. > > > > > > RFC 7016 documents such an approach. > > > > I see that the title starts with "Adobe's". Sigh. > > Yes, but there's little stopping many of these ideas from becoming the > basis for an IETF-developed transport protocol that actually meets the > needs we have here. > [MB] Except, maybe, IPR: https://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-thornburgh-adobe-rtmfp [/MB] > > If you want to entertain something other than existing solutions for > media, > > why not simply run the RTP media streams over SCTP along with the data > > channels? > > Except for some critical shortcomings of SCTP (which are being fixed), > this isn't actually a terrible idea. > > Matthew Kaufman > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c38e7059564204f678ec9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Apr 7, 2014 at 2:27 PM, Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote:
-----Original Message----- > From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Monday, April 7, 2014 12:22 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help= with
> media isolation)
>
> On 4/7/14 1:27 PM, Matthew Kaufman (SKYPE) wrote:
> >
> > From: rtcweb [mailto:r= tcweb-bounces@ietf.org] On Behalf Of Harald
> >> Alvestrand
> >> ...
> >> (and to Matthew: At least we wouldn't have *yet* another = congestion
> >> context to manage, which would be the case with a separate TC= P
> connection.
> >> There are always tradeoffs.)
> >
> > If it was me (and at one time, it was) I would use a protocol tha= t allows for
> multiplexing and prioritization of media and data channels over the sa= me
> secure session with shared congestion state. Over such a protocol, ope= ning
> another data stream for this purpose could be done immediately without=
> even a round trip.
> >
> > RFC 7016 documents such an approach.
>
> I see that the title starts with "Adobe's". Sigh.

Yes, but there's little stopping many of these ideas from becomin= g the basis for an IETF-developed transport protocol that actually meets th= e needs we have here.

[MB] Except, mayb= e, IPR:=A0
[/MB]
> If you want to entertain something other than existing solutions for m= edia,
> why not simply run the RTP media streams over SCTP along with the data=
> channels?

Except for some critical shortcomings of SCTP (which are being fixed)= , this isn't actually a terrible idea.

Matthew Kaufman

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a11c38e7059564204f678ec9c-- From nobody Mon Apr 7 12:40:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D621A082B for ; Mon, 7 Apr 2014 12:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 caPs4dQJGUv9 for ; Mon, 7 Apr 2014 12:40:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7B07F1A07F4 for ; Mon, 7 Apr 2014 12:40:13 -0700 (PDT) Received: from BY2PR03CA046.namprd03.prod.outlook.com (10.141.249.19) by BY2PR03MB025.namprd03.prod.outlook.com (10.255.240.39) with Microsoft SMTP Server (TLS) id 15.0.913.9; Mon, 7 Apr 2014 19:40:03 +0000 Received: from BY2FFO11FD057.protection.gbl (2a01:111:f400:7c0c::193) by BY2PR03CA046.outlook.office365.com (2a01:111:e400:2c5d::19) with Microsoft SMTP Server (TLS) id 15.0.913.9 via Frontend Transport; Mon, 7 Apr 2014 19:40:04 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD057.mail.protection.outlook.com (10.1.15.185) with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Mon, 7 Apr 2014 19:40:01 +0000 Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.124]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0174.002; Mon, 7 Apr 2014 19:39:23 +0000 From: "Matthew Kaufman (SKYPE)" To: Mary Barnes Thread-Topic: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) Thread-Index: AQHPUjfRb53lyS9CtEOLJeBSW/E7VJsGYYMAgAAFe4CAAADocIAAINQAgAABNqCAAAHBAIAAAI7g Date: Mon, 7 Apr 2014 19:39:22 +0000 Message-ID: References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> <5342DE6F.6040306@alvestrand.no> <5342FABC.4080200@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(199002)(377454003)(189002)(51704005)(50986001)(49866001)(20776003)(98676001)(95666003)(54316002)(99396002)(94316002)(84676001)(23756003)(33656001)(81542001)(79102001)(92726001)(93136001)(97186001)(6806004)(86362001)(90146001)(85306002)(63696002)(76796001)(87936001)(47776003)(2009001)(97336001)(44976005)(94946001)(97736001)(77096001)(54356001)(87266001)(77982001)(55846006)(83322001)(81686001)(19580395003)(80976001)(65816001)(56816005)(19580405001)(31966008)(74662001)(74502001)(74366001)(74706001)(81816001)(92566001)(47446002)(80022001)(66066001)(50466002)(74876001)(53806001)(15975445006)(81342001)(47976001)(47736001)(69226001)(93516002)(4396001)(76786001)(56776001)(46102001)(85852003)(2656002)(76482001)(59766001)(95416001)(83072002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB025; H:mail.microsoft.com; FPR:4C96F2F5.A5FAD7E5.3DD03D53.4CF69869.202A3; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0174BD4BDA Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cu6rlXVytkJOpRFfplJRpK-OmSQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 19:40:18 -0000 From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, April 7, 2014 12:22 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help wi= th > media isolation) > > RFC 7016 documents such an approach. > > I see that the title starts with "Adobe's". Sigh. Yes, but there's little stopping many of these ideas from becoming the basi= s for an IETF-developed transport protocol that actually meets the needs we= have here. [MB] Except, maybe, IPR:=A0 =A0https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Dd= raft-thornburgh-adobe-rtmfp [/MB] Conveniently, RTMFP was preceded by an open-source project which had no pat= ents filed. so to the extent the "ideas" are present there (and many of the= m are), that's easily worked around, if one needed a starting place. But my point wasn't to start discussing the merits of the specific approach= described in that particular RFC... rather to note that the cobbled-togeth= er collection of choices that have been made, specifically gluing SCTP on t= o the side of RTCWEB as a way of transporting data, is highly suboptimal an= d that other solutions do exist. In fact, simply allowing the data we need to be sent unsolicited as another= SRTP stream would be an improvement over doing 2 round trips of SCTP setup= for the problem space we are discussing in this thread. Matthew Kaufman From nobody Mon Apr 7 13:57:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F081A080D for ; Mon, 7 Apr 2014 13:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 0daunx2HwqkP for ; Mon, 7 Apr 2014 13:57:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9F11A081F for ; Mon, 7 Apr 2014 13:57:03 -0700 (PDT) Received: from BY2PR02MB364.namprd02.prod.outlook.com (10.141.140.152) by BY2PR02MB364.namprd02.prod.outlook.com (10.141.140.152) with Microsoft SMTP Server (TLS) id 15.0.913.9; Mon, 7 Apr 2014 20:56:55 +0000 Received: from BY2PR02MB364.namprd02.prod.outlook.com ([10.141.140.152]) by BY2PR02MB364.namprd02.prod.outlook.com ([10.141.140.152]) with mapi id 15.00.0913.002; Mon, 7 Apr 2014 20:56:55 +0000 From: Michael Thornburgh To: Mary Barnes , "Matthew Kaufman (SKYPE)" Thread-Topic: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) Thread-Index: AQHPUjfoFsMB+NfjFkSckgH26QDjTZsGYYIAgAAFfICAAAHNAIAAH+8AgAABlICAAAFiAIAAD+cQ Date: Mon, 7 Apr 2014 20:56:55 +0000 Message-ID: References: <533F191D.8050109@alum.mit.edu> <53425BAF.4070105@alvestrand.no> <5342DE6F.6040306@alvestrand.no> <5342FABC.4080200@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.150.19.4] x-forefront-prvs: 0174BD4BDA x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(479174003)(199002)(24454002)(189002)(13464003)(377454003)(51704005)(87936001)(19580395003)(47976001)(76786001)(50986001)(76796001)(92566001)(15975445006)(47446002)(2656002)(74502001)(63696002)(77982001)(83072002)(74316001)(49866001)(81686001)(47736001)(93136001)(76576001)(4396001)(85852003)(90146001)(19580405001)(59766001)(99396002)(56816005)(83322001)(74876001)(87266001)(74706001)(20776003)(69226001)(46102001)(56776001)(54316002)(81816001)(53806001)(66066001)(86362001)(80022001)(79102001)(81342001)(65816001)(94316002)(76482001)(80976001)(54356001)(74662001)(98676001)(74366001)(85306002)(93516002)(97336001)(33646001)(95666003)(81542001)(94946001)(31966008)(95416001)(97186001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR02MB364; H:BY2PR02MB364.namprd02.prod.outlook.com; FPR:FC97F096.A7F24789.3CD3B14B.C6E6D251.20372; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-IAePZGM7eJCKkeI4Rcywblz6cY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 20:57:08 -0000 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: Monday, April 07, 2014 12:32 PM >=20 > On Mon, Apr 7, 2014 at 2:27 PM, Matthew Kaufman (SKYPE) wrote: >=20 > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyziva= t > > Sent: Monday, April 7, 2014 12:22 PM > > To: rtcweb@ietf.org > > Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help= with > > media isolation) > > > > On 4/7/14 1:27 PM, Matthew Kaufman (SKYPE) wrote: > > > > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > > >> Alvestrand > > >> ... > > >> (and to Matthew: At least we wouldn't have *yet* another congestion > > >> context to manage, which would be the case with a separate TCP > > connection. > > >> There are always tradeoffs.) > > > > > > If it was me (and at one time, it was) I would use a protocol that a= llows for > > multiplexing and prioritization of media and data channels over the sa= me > > secure session with shared congestion state. Over such a protocol, ope= ning > > another data stream for this purpose could be done immediately without > > even a round trip. > > > > > > RFC 7016 documents such an approach. > > > > I see that the title starts with "Adobe's". Sigh. >=20 > Yes, but there's little stopping many of these ideas from becoming the b= asis for an IETF- > developed transport protocol that actually meets the needs we have here. >=20 > [MB] Except, maybe, IPR: > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Dd= raft-thornburgh-adobe-rtmfp > [/MB] we would love for RTMFP to become the basis for an IETF-developed standard = transport protocol. and as far as using RTMFP as-is, note section VI of th= e (most recent) above-referenced IPR disclosure: "Royalty-Free, Reasonable = and Non-Discriminatory License to All Implementers." we think it's pretty = good already and published it (among other reasons) in the hopes that other= s would find new uses for it. > > If you want to entertain something other than existing solutions for m= edia, > > why not simply run the RTP media streams over SCTP along with the data > > channels? >=20 > Except for some critical shortcomings of SCTP (which are being fixed), t= his isn't actually a > terrible idea. except for the critical shortcomings of SCTP (for real-time communications)= that aren't being fixed. > Matthew Kaufman -michael thornburgh From nobody Tue Apr 8 04:42:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB111A0302 for ; Tue, 8 Apr 2014 04:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 OxazuVeR4aJl for ; Tue, 8 Apr 2014 04:42:33 -0700 (PDT) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id B7C331A0213 for ; Tue, 8 Apr 2014 04:42:32 -0700 (PDT) X-AuditID: c1b4fb31-b7f688e000003e64-d8-5343e0a1a09c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id C1.B8.15972.1A0E3435; Tue, 8 Apr 2014 13:42:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Tue, 8 Apr 2014 13:42:25 +0200 From: Christer Holmberg To: Martin Thomson , Paul Kyzivat Thread-Topic: [rtcweb] Asking TLS for help with media isolation Thread-Index: AQHPT5ra0JdQdaTn60axBjXPZp1dP5sBy/CAgAACawCAAv9WAIABb3EAgAFiuSA= Date: Tue, 8 Apr 2014 11:42:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> References: <533F191D.8050109@alum.mit.edu> <53419ED4.8020102@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvje6iB87BBmcn81hcO/OP0WLFhgOs Fmv/tbM7MHv8ff+ByWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgypjw8hpLwXbmimXfXrM3 MF5n6mLk5JAQMJH4v3MVI4QtJnHh3no2EFtI4CSjxLWbvF2MXED2YkaJ9nUzgRIcHGwCFhLd /7RBakQEQiXaLu4D62UWUJe4s/gcO4gtLGAnsfDhBnaIGnuJhkVPoGw/ickrjrKA2CwCKhJf bn5mBbF5BXwlXpw8zAyxaxGTxLm3K8CKOAUCJb4v+wdWxAh03PdTa5gglolL3HoyH+oBAYkl e84zQ9iiEi8fQ9RLCChK7DzbzgxRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0 zELSMgtJywJGllWMksWpxUm56UaGernpuSV6qUWZycXF+Xl6xambGIGxdXDLb8MdjBOv2R9i lOZgURLnZZjeGSQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcfWmx4HM709NP1poUf14qYjg ax7WVb3zdc8+frBv4eK3MjtO7lST8jlsJcQSdFTcxWyqyNqv3Icn//62vNXejbn3RlmS5gvG LftU/6qfTY3880/jquwOnsyiLae700L8Ahf/llC3jZ1/dsVrL+FpnG/Uj7o2a+W2p2of2BK1 /d/VwKDYmyJOLUosxRmJhlrMRcWJAD+hz1x7AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6cMqWSlC94yxy7P7arjpAb6sJ3E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 11:42:37 -0000 Hi, >> But ISTM there would need to be a different set of limitations for=20 >> non-browsers. For instance, to not echo the stream back to the source.=20 >> And not to store the stream in a place that the sender can retrieve. > >Yes. At the most abstract level, the requirements are the same. >Don't pass the media on to someone else. How would that work with an intermediary mixer, transcoder, etc? Regards, Christer From nobody Tue Apr 8 08:05:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C401A03DF for ; Tue, 8 Apr 2014 08:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 YGhAkJ56s0_w for ; Tue, 8 Apr 2014 08:04:55 -0700 (PDT) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D5FA81A03BA for ; Tue, 8 Apr 2014 08:04:54 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id d17so807225eek.4 for ; Tue, 08 Apr 2014 08:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=ptKgY4+P+5j3pNrhEht3iGMz+dOsVXQJnxRME3kSaLE=; b=m3BvFvHdCFoKTfoL3H0fx9sJeiNAts0xuWDlzdBA0Clp9D8XAh8VS0twQAr6Amiyuf /Od4HlI+FJsWiOui4KQUFJnCufNCENuPk1MrNXtbCwSTf6VhApPKx5ql6MzXoNDRGrFM 3FwzdHvI9KMjmMLeoGxNOmv51gmB0taAFewC7xVc9r8DV4M4xTboKrny8u/ZfFs3nxcs WfhLkh+2BPFk9nC79Vpcu2iJh5kzGBfkt3Oeyr2yVcs4OORedXQ2wbJasvf1WGoEOCUX 1Q9eX0GVp/vTvcUKsnbybcPwKT5c5FR0emLd1TB2Dopz4dIgRl+iDAJZ5gF8Ps8Ktn1S l2Nw== X-Received: by 10.15.10.135 with SMTP id g7mr3358228eet.72.1396969494330; Tue, 08 Apr 2014 08:04:54 -0700 (PDT) Received: from RoniE (bzq-79-183-174-212.red.bezeqint.net. [79.183.174.212]) by mx.google.com with ESMTPSA id u46sm5162990eel.1.2014.04.08.08.04.52 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Apr 2014 08:04:53 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Harald Alvestrand'" , References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no> <534288C2.6010906@ericsson.com> In-Reply-To: <534288C2.6010906@ericsson.com> Date: Tue, 8 Apr 2014 18:04:50 +0300 Message-ID: <010301cf533b$e504d9f0$af0e8dd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKAdRtyny0O/9Ki8/9GVI+Yi+W4VAKvzAr7AQtGn5yZh7O9sA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/h1qVglzhqlXPjDGXxUDVAqmuroU Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 15:04:59 -0000 Hi, Inline Roni > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: 07 April, 2014 2:15 PM > To: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Draft proposal for updating Multiparty = topologies in draft- > ietf-rtcweb-rtp-usage >=20 > On 2014-04-07 10:12, Harald Alvestrand wrote: > > Thanks for the update! > > > > It does seem reasonably clear now - clear enough that I found one > > point that I violently disagree with (if I'm interpreting it > > correctly). See below. > > > > I don't have any negative comments on the rest of the section. > > > > On 04/04/2014 11:24 AM, Magnus Westerlund wrote: > >> WG, > >> (As Author) > >> > >> Colin and I have been working on resolving terminology usage and in > >> general giving the draft a polish over before the WG last call. One > >> section that has gotten quite some attention from us is the below = one. > >> The changes are significantly from an editorial stand point. = However, > >> the intended content has not been intended to be changed, although > >> clarified and better motivated. So please review it, we intended to > >> include this in the upcoming draft update. Feedback appreciated. > >> > >> 5.1. Conferencing Extensions and Topologies > >> > >> RTP is a protocol that inherently supports group communication. > >> Groups can be implemented by having each endpoint sending its = RTP > >> packet streams to an RTP middlebox that redistributes the = traffic, by > >> using a mesh of unicast RTP packet streams between endpoints, = or by > >> using an IP multicast group to distribute the RTP packet = streams. > >> These topologies can be implemented in a number of ways as discussed > >> in [I-D.ietf-avtcore-rtp-topologies-update]. > >> > >> While the use of IP multicast groups is popular in IPTV = systems, the > >> topologies based on RTP middleboxes are dominant in interactive video > >> conferencing environments. Topologies based on a mesh of = unicast > >> transport-layer flows to create a common RTP session have not = seen > >> widespread deployment. Accordingly, WebRTC implementations are = not > >> expected to support topologies based on IP multicast groups. WebRTC > >> implementations are also not expected to support mesh-based > >> topologies, such as a point-to-multipoint mesh configured as a single > >> RTP session (Topo-Mesh in the terminology of > >> [I-D.ietf-avtcore-rtp-topologies-update]). However, a = point-to- > >> multipoint mesh constructed using several RTP sessions, in the WebRTC > >> context using independent RTCPeerConnections can be expected to = be > >> utilised by WebRTC applications. > >> > >> WebRTC implementations of RTP endpoints implemented according = to > this > >> memo are expected to support all the topologies described in > >> [I-D.ietf-avtcore-rtp-topologies-update] where the RTP = endpoints send > >> and receive unicast RTP packet streams to some peer device, provided > >> that peer can participate in performing congestion control on = the RTP > >> packet streams. The peer device could be another RTP endpoint, = or it > >> could be an RTP middlebox that redistributes the RTP packet = streams > >> to other RTP endpoints. This limitation means that some of the = RTP > >> middlebox-based topologies are not suitable for use in the = WebRTC > >> environment. Specifically: > >> > >> o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be = used, > >> since they make the use of RTCP for congestion control and quality > >> of service reports problematic (see Section 3.6.2 of > >> [I-D.ietf-avtcore-rtp-topologies-update]). > >> > >> o Content modifying MCUs with RTCP termination (Topo-RTCP- > >> terminating-MCU) SHOULD NOT be used since they break RTP = loop > >> detection, and prevent receivers from identifying active = senders > >> (see section 3.8 of = [I-D.ietf-avtcore-rtp-topologies-update]). > > > > In my (strong) opinion: This recommendation is wrong. > > > > All central conferencing units that use individual RTP sessions with > > clients fall into this category. This includes, I believe, every > > single multiuser video conferencing system based on WebRTC in > > existence (and there are many of them). >=20 > Do they? The point of this topology is that it terminates the source > identification and hides when it is performing any type of mixing or switching > operation. You can perform this with a back to back RTP session style without > breaking this property. Just by correctly linking information between = the > sessions. Which means that the individual RTP session is from the identification > part inseparable from an SFM or classic RTP mixer. Only the SSRC level loop > detection gets impacted. >=20 > I do understand that people have implemented it this way. = Implementation are > not necessarily equivalent to recommended practice. >=20 [Roni Even] In this topology the source identification is done by the application layer and not the RTP layer (using for example conference = event package or just the UI). So I think that "MAY" is strong enough and not "SHOULD NOT". I agree with Harald that it is widely used. > > > > I believe the recommendation should be: > > > > * Content modifying MCUs with RTCP termination > > (Topo-RTCP-terminating-MCU) MAY be used. Note that in this scenario, > > RTP loop detection and identification of active senders is the > > resposibility of the application; since the clients are isolated = from > > each other at the RTP layer, RTP cannot assist with these functions. > > >=20 > If this topology was without issues, then one would simply remove the bullet, > and let it fall under the general clause. However, it clearly needs = that warning. > Which results in this topology being both positively and negatively treated in > regards to the other "you may encounter this topology". >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Apr 8 08:13:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC34D1A043B for ; Tue, 8 Apr 2014 08:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 eCpUUfrtQe2m for ; Tue, 8 Apr 2014 08:13:23 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 57B551A0175 for ; Tue, 8 Apr 2014 08:13:23 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id b57so799552eek.40 for ; Tue, 08 Apr 2014 08:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=mUr/1glo59c1UpB8eSGiGf5wXZUZWR/k7Zs62U2YcK0=; b=U5w4VpFKFjlwCZc3ztLsSASrkJJf6tNo/TSn7zXiWtnojaGcAn6ilkz6sPr2NdIaxw QQY7NBDM+vhJ4SbRUYJSxKZ77FJBIa604zSTVn5kVCPBD/s2ZGfkU3QZuawUp/3XdntL xqPFMASROlUKoRYel/eXOTCMY0CNxhcYo9FwFFPCc+NxJI+NHpsvNtdDSPT33wOCC6Ce TxL5K8xgiCG/p1Fhb3yNW53MMfIX4tfAgPVpWcBQ+/75ktHGQyvB5E/MWDAdUbu5icAg hKWGe4FpDs9ascvuleRYbWwxwBRBUYTawAggrsOwITFn21SXJH9MvOj+SGC5BPnPYf2b aebA== X-Received: by 10.15.24.201 with SMTP id j49mr1368136eeu.99.1396970002748; Tue, 08 Apr 2014 08:13:22 -0700 (PDT) Received: from RoniE (bzq-79-183-174-212.red.bezeqint.net. [79.183.174.212]) by mx.google.com with ESMTPSA id e42sm5157747eev.32.2014.04.08.08.13.20 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Apr 2014 08:13:21 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , References: <533E7A50.5040909@ericsson.com> In-Reply-To: <533E7A50.5040909@ericsson.com> Date: Tue, 8 Apr 2014 18:13:19 +0300 Message-ID: <010501cf533d$143546a0$3c9fd3e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKAdRtyny0O/9Ki8/9GVI+Yi+W4VJmljo+g Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jZ5BXbBTTvuIxT2MgUqmV510iNs Cc: 'Colin Perkins' Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 15:13:28 -0000 Hi, Comment on video switching in-line Roni > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: 04 April, 2014 12:25 PM > To: rtcweb@ietf.org > Cc: Colin Perkins > Subject: [rtcweb] Draft proposal for updating Multiparty topologies in draft- > ietf-rtcweb-rtp-usage >=20 > WG, > (As Author) >=20 > Colin and I have been working on resolving terminology usage and in general > giving the draft a polish over before the WG last call. One section = that has > gotten quite some attention from us is the below one. > The changes are significantly from an editorial stand point. However, = the > intended content has not been intended to be changed, although = clarified and > better motivated. So please review it, we intended to include this in = the > upcoming draft update. Feedback appreciated. >=20 > 5.1. Conferencing Extensions and Topologies >=20 > RTP is a protocol that inherently supports group communication. > Groups can be implemented by having each endpoint sending its RTP > packet streams to an RTP middlebox that redistributes the traffic, = by > using a mesh of unicast RTP packet streams between endpoints, or by > using an IP multicast group to distribute the RTP packet streams. > These topologies can be implemented in a number of ways as = discussed > in [I-D.ietf-avtcore-rtp-topologies-update]. >=20 > While the use of IP multicast groups is popular in IPTV systems, = the > topologies based on RTP middleboxes are dominant in interactive = video > conferencing environments. Topologies based on a mesh of unicast > transport-layer flows to create a common RTP session have not seen > widespread deployment. Accordingly, WebRTC implementations are not > expected to support topologies based on IP multicast groups. = WebRTC > implementations are also not expected to support mesh-based > topologies, such as a point-to-multipoint mesh configured as a = single > RTP session (Topo-Mesh in the terminology of > [I-D.ietf-avtcore-rtp-topologies-update]). However, a point-to- > multipoint mesh constructed using several RTP sessions, in the = WebRTC > context using independent RTCPeerConnections can be expected to be > utilised by WebRTC applications. >=20 > WebRTC implementations of RTP endpoints implemented according to = this > memo are expected to support all the topologies described in > [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints = send > and receive unicast RTP packet streams to some peer device, = provided > that peer can participate in performing congestion control on the = RTP > packet streams. The peer device could be another RTP endpoint, or = it > could be an RTP middlebox that redistributes the RTP packet streams > to other RTP endpoints. This limitation means that some of the RTP > middlebox-based topologies are not suitable for use in the WebRTC > environment. Specifically: >=20 > o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, > since they make the use of RTCP for congestion control and = quality > of service reports problematic (see Section 3.6.2 of > [I-D.ietf-avtcore-rtp-topologies-update]). [Roni Even] I think that SHOULD NOT is too strong here better use MAY be used, this is a simple common mode of centralized video conferencing = being used. If you are talking about the RTP layer the MCU gets all the RTCP reports. The problem of loop detection may occur when cascading MCUs and = the avtcore topology should point it out. I do not see it as a major problem since the video switching is managed by the application layer who should prevent such situations. >=20 > o Content modifying MCUs with RTCP termination (Topo-RTCP- > terminating-MCU) SHOULD NOT be used since they break RTP loop > detection, and prevent receivers from identifying active senders > (see section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]). >=20 > o The Relay-Transport Translator (Topo-PtM-Trn-Translator) = topology > SHOULD NOT be used because its safe use requires a point to > multipoint congestion control algorithm or RTP circuit breaker, > which has not yet been standardised. >=20 > The RTP extensions described in Section 5.1.1 to Section 5.1.6 are > designed to be used with centralised conferencing, where an RTP > middlebox (e.g., a conference bridge) receives a participant's RTP > packet streams and distributes them to the other participants. = These > extensions are not necessary for interoperability; an RTP end-point > that does not implement these extensions will work correctly, but > might offer poor performance. Support for the listed extensions = will > greatly improve the quality of experience and, to provide a > reasonable baseline quality, some of these extensions are mandatory > to be supported by WebRTC end-points. >=20 > The RTCP conferencing extensions are defined in Extended RTP = Profile > for Real-time Transport Control Protocol (RTCP)-Based Feedback = (RTP/ > AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio- > Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully > usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124]. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Apr 8 09:33:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA151A050E for ; Tue, 8 Apr 2014 09:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Qy4w44_VGOsA for ; Tue, 8 Apr 2014 09:33:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DFFE61A04BC for ; Tue, 8 Apr 2014 09:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=582; q=dns/txt; s=iport; t=1396974815; x=1398184415; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/Cux0EMVcZkvRASGNY2YFL8DEpfNRvXfMNNmZRlhtx8=; b=Bw/3Mm/ax8efCOFjKy6Lb71NsONZCeRRIFaDUn3bfPtLKCcMftIZ89Tr AzUg/RIJVWDd5mDNgtVDvPt+WAB1zyO3G4HQ9J5KURFMpxwPntdedWd50 F2iq+W+XJU9sKvmjg4n0w9kEf0ULuOMwa/YNtjKRcpbLmmUzU0DJlFEo5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANgjRFOrRDoJ/2dsb2JhbABZgwbFPIEgFnSCJQEBAQMBOi4RBQsLRlcGE4d0B8obF445MweDJIEUAQOJW48ChlKLboNQHQ X-IronPort-AV: E=Sophos;i="4.97,819,1389744000"; d="scan'208";a="316131118" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-5.cisco.com with ESMTP; 08 Apr 2014 16:33:34 +0000 Received: from [10.21.70.224] ([10.21.70.224]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s38GXXGV030176; Tue, 8 Apr 2014 16:33:34 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> Date: Tue, 8 Apr 2014 09:33:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <533F191D.8050109@alum.mit.edu> <53419ED4.8020102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uC4gUlaRlnlhoXO-9tbqQqXjTvQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:33:39 -0000 On Apr 8, 2014, at 4:42 AM, Christer Holmberg = wrote: > Hi, >=20 >>> But ISTM there would need to be a different set of limitations for=20= >>> non-browsers. For instance, to not echo the stream back to the = source.=20 >>> And not to store the stream in a place that the sender can retrieve. >>=20 >> Yes. At the most abstract level, the requirements are the same. >> Don't pass the media on to someone else. >=20 > How would that work with an intermediary mixer, transcoder, etc? Or voicemail or an audio conference. -d From nobody Tue Apr 8 09:51:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DF91A04B6 for ; Tue, 8 Apr 2014 09:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 kTrEI6XqYcaK for ; Tue, 8 Apr 2014 09:51:30 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 977C51A050E for ; Tue, 8 Apr 2014 09:51:16 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so1207401wes.24 for ; Tue, 08 Apr 2014 09:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=I6wLJbbbEs7eZKu4xJz/Qx7h+QWswcQD79L78wHFRWw=; b=i1TcsRtwu3n8FShk7Fh83qWL6q/cwwi+7K8k7EELE8hIvkbShqbHnLl+LTONd9Zyz+ StFaYTuIGo/QHcrevdQk7lgXIfoQDmBkao3Jr1/qpVtaoq6WwE9CDkx/komWfixZmy2+ 4kJBVq89NRheZd9W8zEk5KTxN8B5Z0iXyroOFVGCFqEiRR+0N09QCSlyGhhv4XTQIgzG HHsEEGJ/LFWI8psrXO4rgLHICsdsbh7xpIeJjpSys9YoXbUgAQ/yHqkGa0LD17OCfc5D 0dOv55wJ+6J/gswO3toirSeaf/6ITf2GbL32TsCv8Gw4kVB26bhGXhXcoMulsyiIJdIr 7Qww== X-Received: by 10.194.188.68 with SMTP id fy4mr4898164wjc.30.1396975875881; Tue, 08 Apr 2014 09:51:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.102.130 with HTTP; Tue, 8 Apr 2014 09:50:55 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> References: <533F191D.8050109@alum.mit.edu> <53419ED4.8020102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Tue, 8 Apr 2014 09:50:55 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bb03f9ad780cf04f68aca01 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/irtigKLBS5ocvD_JyAb53j2QXmQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:51:36 -0000 --047d7bb03f9ad780cf04f68aca01 Content-Type: text/plain; charset=ISO-8859-1 Christer said: "How would that work with an intermediary mixer, transcoder, etc." [BA] I'm not sure that the concept of "isolation" makes sense for those intermediaries (or to voicemail or an audio/video conference, for that matter). While in a point-to-point call it might be useful, in a conference the whole point is to have audio/video sent to multiple parties, and recording is commonplace. The problem is that from a protocol point of view the cases are not easily distinguishable -- and so if the browser insists on "isolation" then one wonders what will happen if the conference bridge/video MCU/voicemail system refuses to negotiate it. Refusing to send media would not be a desirable outcome. On Tue, Apr 8, 2014 at 4:42 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> But ISTM there would need to be a different set of limitations for > >> non-browsers. For instance, to not echo the stream back to the source. > >> And not to store the stream in a place that the sender can retrieve. > > > >Yes. At the most abstract level, the requirements are the same. > >Don't pass the media on to someone else. > > How would that work with an intermediary mixer, transcoder, etc? > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bb03f9ad780cf04f68aca01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Christer said:

"How wo= uld that work with an intermediary mixer, transcoder, etc."
=
[BA] I'm not sure that the concept of "isolation&qu= ot; makes sense for those intermediaries (or to voicemail or an audio/video= conference, for that matter).=A0=A0 While in a point-to-point call it migh= t be useful, in a conference the whole point is to have audio/video sent to= multiple parties, and recording is commonplace.=A0 The problem is that fro= m a protocol point of view the cases are not=A0easily distinguishable -- an= d so if the browser insists on "isolation" then one wonders what = will happen if the conference bridge/video MCU/voicemail system refuses to = negotiate it.=A0=A0 Refusing to send media would not be a desirable outcome= .


On Tue,= Apr 8, 2014 at 4:42 AM, Christer Holmberg <christer.holmberg= @ericsson.com> wrote:
Hi,

>> But ISTM there would need to be a different set of limitations for=
>> non-browsers. For instance, to not echo the stream back to the sou= rce.
>> And not to store the stream in a place that the sender can retriev= e.
>
>Yes. =A0At the most abstract level, the requirements are the same.
>Don't pass the media on to someone else.

How would that work with an intermediary mixer, transcoder, etc?

Regards,

Christer

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bb03f9ad780cf04f68aca01-- From nobody Tue Apr 8 11:24:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBB61A067F for ; Tue, 8 Apr 2014 11:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 6jM4gAGlYGBg for ; Tue, 8 Apr 2014 11:24:04 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD851A0680 for ; Tue, 8 Apr 2014 11:24:04 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so7586047wib.5 for ; Tue, 08 Apr 2014 11:24:03 -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:content-type; bh=w/HhHSc7/RKayGtZn1MNfwooPO1N+gkKFzmxp6pQtNM=; b=YPxmM6ox0TArA1sHZF3J4oA+tTgPDWOviqP00yqSWEot3D4eFJmLgCLIMmh6PXQyKF /fVgXtQaV3z7Q5UjE6TClxKtF3+5I+VrsqI8U1uj1amXyHWQ1I9qptkJDCH/kne/QVxJ 1dchHNnxaUBOw4GKD9WmAFjbSUSsWOiDkvNS4SXVbQ2WrDrvrJ+QCBXjxVMMLxBi68mj IPPmQHu3f93PBDFjuwlXOjFkS4DXda0Ffob5+oVKZfGTL0Ob8uctMBTljYXUNMxcEof0 /nPZHnx052PJ0QSPYKZdahZcheK6nHdgKbm5WxKklcHVNfkBNsTG715eKEvf/HXLi2cz ffcA== MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr5862992wiw.56.1396981443422; Tue, 08 Apr 2014 11:24:03 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Tue, 8 Apr 2014 11:24:03 -0700 (PDT) In-Reply-To: References: <533F191D.8050109@alum.mit.edu> <53419ED4.8020102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> Date: Tue, 8 Apr 2014 11:24:03 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YbVVq3kBA3Qt_wURt81ZKoltdlU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:24:09 -0000 On 8 April 2014 09:50, Bernard Aboba wrote: > [BA] I'm not sure that the concept of "isolation" makes sense for those > intermediaries (or to voicemail or an audio/video conference, for that > matter). While in a point-to-point call it might be useful, in a > conference the whole point is to have audio/video sent to multiple parties, > and recording is commonplace. The problem is that from a protocol point of > view the cases are not easily distinguishable -- and so if the browser > insists on "isolation" then one wonders what will happen if the conference > bridge/video MCU/voicemail system refuses to negotiate it. Refusing to > send media would not be a desirable outcome. I think that for this, it's perfectly reasonable to use identity, but not stream isolation. With isolation, if the peer does not agree to comply, then the session fails to complete. The authenticated party here is an MCU (or bridge, or voicemail, etc...). Rather than sending to "anindividual@example.org", media is sent to "mcu@example.com". Is it reasonable for that MCU to forward media to other, unspecified entities? Clearly it can, but should it? (Not having thought it through completely, a voicemail box could conceivably work. I think that I'd want to use a different identity for it though.) From nobody Tue Apr 8 12:41:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7211A1A0701 for ; Tue, 8 Apr 2014 12:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 pyk8VUHmM8Nw for ; Tue, 8 Apr 2014 12:41:17 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3291A06FF for ; Tue, 8 Apr 2014 12:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1762; q=dns/txt; s=iport; t=1396986077; x=1398195677; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PUv5/7C0ehct4Q/nRoykA35LKroVvEqSVVNab1xdCYE=; b=ckZMM9IzE4zZo5nFNxt5VqVFnzUjKwYKFcujUfHQM58+kItaWAI+NoIJ XQp/DCHmrh3ZutFsfgB41OvqSbaoVS5+U8eKo/qu1BqHGJp2dmerhTagm hhItxRr3GUapqVK2EqpPkdznYIASFpcLJoWP10fxo+F/feV5AKAnszWJl E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAG1QRFOrRDoJ/2dsb2JhbABQCYMGO8UQgSIWdIIlAQEBAwE6LhEFCwsYLiE2BhOHaAMJBw7EBA2GQxeMU4E+KDMHgySBFASJW40UgW6BNIs9hU+DUB0 X-IronPort-AV: E=Sophos;i="4.97,819,1389744000"; d="scan'208";a="107525770" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 08 Apr 2014 19:41:17 +0000 Received: from sjc-vpn1-1033.cisco.com (sjc-vpn1-1033.cisco.com [10.21.100.9]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s38JfGhD022550; Tue, 8 Apr 2014 19:41:16 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: Date: Tue, 8 Apr 2014 12:41:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <70894E4B-CAFF-460D-BD11-B8BD6C7F41FB@cisco.com> References: <533F191D.8050109@alum.mit.edu> <53419ED4.8020102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> To: Martin Thomson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/T0_tYqena6ZpY6TofusMusioV4c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:41:22 -0000 On Apr 8, 2014, at 11:24 AM, Martin Thomson = wrote: > On 8 April 2014 09:50, Bernard Aboba wrote: >> [BA] I'm not sure that the concept of "isolation" makes sense for = those >> intermediaries (or to voicemail or an audio/video conference, for = that >> matter). While in a point-to-point call it might be useful, in a >> conference the whole point is to have audio/video sent to multiple = parties, >> and recording is commonplace. The problem is that from a protocol = point of >> view the cases are not easily distinguishable -- and so if the = browser >> insists on "isolation" then one wonders what will happen if the = conference >> bridge/video MCU/voicemail system refuses to negotiate it. Refusing = to >> send media would not be a desirable outcome. >=20 > I think that for this, it's perfectly reasonable to use identity, but > not stream isolation. With isolation, if the peer does not agree to > comply, then the session fails to complete. >=20 > The authenticated party here is an MCU (or bridge, or voicemail, > etc...). Rather than sending to "anindividual@example.org", media is > sent to "mcu@example.com". Is it reasonable for that MCU to forward > media to other, unspecified entities? Clearly it can, but should it? >=20 > (Not having thought it through completely, a voicemail box could > conceivably work. I think that I'd want to use a different identity > for it though.) For voicemail, there was a proposal in 2009 for doing what amounted to = object security, http://tools.ietf.org/html/draft-naslund-srtp-saf. = That document's last update was in 2011 but I don't know if it evolved = into a product or died out or what. -d From nobody Wed Apr 9 03:03:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF841A0204; Wed, 9 Apr 2014 03:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Bfm5Zm3nWvpj; Wed, 9 Apr 2014 03:02:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2E1A01E4; Wed, 9 Apr 2014 03:02:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> Date: Wed, 09 Apr 2014 03:02:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_kTJJrZC2W8Bj4GjYq4q7t4X7fQ Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 10:03:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : WebRTC Data Channels Authors : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-channel-08.txt Pages : 15 Date : 2014-04-09 Abstract: The Real-Time Communication in WEB-browsers working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-(S)RTP media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing WEB-browsers to exchange generic data from peer to peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-channel-08 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 Wed Apr 9 03:03:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7D41A0209; Wed, 9 Apr 2014 03:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 6ZwvPRC6US5r; Wed, 9 Apr 2014 03:03:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B3C1A0204; Wed, 9 Apr 2014 03:03:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140409100313.9526.70264.idtracker@ietfa.amsl.com> Date: Wed, 09 Apr 2014 03:03:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ox1uMZE9bBRMdkRbWeV-YNtkJxw Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 10:03:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : WebRTC Data Channel Establishment Protocol Authors : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-protocol-04.txt Pages : 12 Date : 2014-04-09 Abstract: The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to support for direct interactive rich communication using audio, video, and data between two peers' web- browsers. This document specifies a simple protocol for establishing symmetric data channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-protocol-04 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 Wed Apr 9 04:00:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB1D1A01EA for ; Wed, 9 Apr 2014 04:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 WKjBpevsnwK1 for ; Wed, 9 Apr 2014 04:00:52 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8321A01D1 for ; Wed, 9 Apr 2014 04:00:51 -0700 (PDT) Received: from [130.209.247.112] (port=64867 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WXqFJ-0008Dq-ST for rtcweb@ietf.org; Wed, 09 Apr 2014 12:00:50 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Colin Perkins In-Reply-To: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> Date: Wed, 9 Apr 2014 12:00:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1874) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/REgXw1MDM1RmCB73iGIlMdgK1BE Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:00:56 -0000 On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : WebRTC Data Channels > Authors : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-channel-08.txt > Pages : 15 > Date : 2014-04-09 >=20 > Abstract: > The Real-Time Communication in WEB-browsers working group is charged > to provide protocol support for direct interactive rich = communication > using audio, video, and data between two peers' web-browsers. This > document specifies the non-(S)RTP media data transport aspects of = the > WebRTC framework. It provides an architectural overview of how the > Stream Control Transmission Protocol (SCTP) is used in the WebRTC > context as a generic transport service allowing WEB-browsers to > exchange generic data from peer to peer. This talks about =93(S)RTP=94 throughout, but the rtp-usage draft = requires that SRTP be used for WebRTC, and disallows plain RTP. I think = this draft could be simplified by changing =93(S)RTP=94 to =93SRTP=94 = throughout. --=20 Colin Perkins http://csperkins.org/ From nobody Wed Apr 9 04:23:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51661A021D for ; Wed, 9 Apr 2014 04:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 fgdR2i2ue6_f for ; Wed, 9 Apr 2014 04:23:03 -0700 (PDT) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9061D1A00AF for ; Wed, 9 Apr 2014 04:23:02 -0700 (PDT) X-AuditID: c1b4fb31-b7f688e000003e64-69-53452d95019f Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 10.6A.15972.59D25435; Wed, 9 Apr 2014 13:23:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 13:23:00 +0200 From: Christer Holmberg To: Colin Perkins , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt Thread-Index: AQHPU9r8wvMWA0Q1K0mIC9kJW7dm+ZsI/KmAgAAnGWA= Date: Wed, 9 Apr 2014 11:22:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2B7AAB@ESESSMB209.ericsson.se> References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvje5UXddggw3H+CyWvzzBaLH2Xzu7 A5PHtPv32TyWLPnJFMAUxWWTkpqTWZZapG+XwJWx/+A2xoIGwYpvq06zNzBO4u1i5OSQEDCR mN38gxnCFpO4cG89WxcjF4eQwElGieu3prJAOIsZJZq2XADKcHCwCVhIdP/TBmkQEfCSePzg IlhYWMBdoudfLETYQ2LGp+WsELaVxJzLk1lAbBYBFYm5x3aA2bwCvhLPNx0H2yskUC7RdOcP I8gYTgFHiVWvakDCjEDnfD+1hgnEZhYQl7j1ZD4TxJkCEkv2nIc6WVTi5eN/rBC2ksSPDZdY IOp1JBbs/sQGYWtLLFv4mhliraDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilGyOLU4KTfd yFAvNz23RC+1KDO5uDg/T684dRMjMFYObvltuINx4jX7Q4zSHCxK4rwM0zuDhATSE0tSs1NT C1KL4otKc1KLDzEycXBKNTDmxPIZLPh43UpYz36btbL+7Qc9livlHj/8oTu1afeh1/r+Cpus zzIrSUfpLE9bvzxKIeKk9cFVJ/eW/ubQeB2yLt5i9/4tXFM/91Tt5rpwxOaRv1vVipS4SpX9 FeFnw6udc0SC1ll1JNVOWBInuK/eIcOl7Oaq6XYzun/z9l1qa1D9+Wqzzz8lluKMREMt5qLi RADJOg4ZYwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/a3tcSWU17VXRHX55_d2igv4rLmM Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:23:06 -0000 Hi, The WebRTC Data Channel will be used also for non-WebRTC applications (it i= s e.g. base for the CLUE Data Channel), where the must-use-SRTP rule does n= ot necessarily apply. Having said that, I DO think that the draft text need to be more generic. W= ebRTC can be described as a use-case, but it shall be clear that the mechan= ism can also be used in other environments. Regards. Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Colin Perkins Sent: 9. huhtikuuta 2014 14:01 To: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Real-Time Communication in WEB-browsers = Working Group of the IETF. >=20 > Title : WebRTC Data Channels > Authors : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-channel-08.txt > Pages : 15 > Date : 2014-04-09 >=20 > Abstract: > The Real-Time Communication in WEB-browsers working group is charged > to provide protocol support for direct interactive rich communication > using audio, video, and data between two peers' web-browsers. This > document specifies the non-(S)RTP media data transport aspects of the > WebRTC framework. It provides an architectural overview of how the > Stream Control Transmission Protocol (SCTP) is used in the WebRTC > context as a generic transport service allowing WEB-browsers to > exchange generic data from peer to peer. This talks about "(S)RTP" throughout, but the rtp-usage draft requires that= SRTP be used for WebRTC, and disallows plain RTP. I think this draft could= be simplified by changing "(S)RTP" to "SRTP" throughout. --=20 Colin Perkins http://csperkins.org/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Apr 9 04:42:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DAC1A0249 for ; Wed, 9 Apr 2014 04:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 oe5pSZ3b92yq for ; Wed, 9 Apr 2014 04:41:53 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5631A0242 for ; Wed, 9 Apr 2014 04:41:46 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so2331286wes.29 for ; Wed, 09 Apr 2014 04:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W2Sf/iEwX4/wAkXlaQh5FDaDMD8cHvHSzP+m8T/q2vc=; b=Ciz6fSSIkCO6+7oQcNg7lpWklgCdlwLER/LBBCqXgLjOU5p0ECw07/FQKvXSrJymrp f8phPEzdJu9PLMv7IW22q+H4BzvCeV4YCZZs+KhNVMSwA1CzI2OctBbM2JIqP51HYArk BAhYXEAUMg9OX/2ZRKbQJBdw+ucDVPdBbYQCDHmD5P2pr7Cnhm18GbWzfJIbHObmLRBp CUfc9G/zmqPlnJKD75466FKUMAZav/3y/n7cux9Pe9T26U038+7CjQ+1lqSniL7uePsA Y27i4nqEtCqoZpSkI6B3zeQRXgskDeV2WEHXEw5vFuOfJUgEi70AgWmo7CNwx4LulLfT deRw== X-Received: by 10.180.20.176 with SMTP id o16mr36962492wie.7.1397043705046; Wed, 09 Apr 2014 04:41:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.91.212 with HTTP; Wed, 9 Apr 2014 04:41:25 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2B7AAB@ESESSMB209.ericsson.se> References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2B7AAB@ESESSMB209.ericsson.se> From: Barry Dingle Date: Wed, 9 Apr 2014 21:41:25 +1000 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec53f35f5c66cf704f69a9563 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MJZSQ-1wg4vh4cplPyGHonTMW7Q Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:41:58 -0000 --bcaec53f35f5c66cf704f69a9563 Content-Type: text/plain; charset=UTF-8 Hi, If "WebRTC Data Channel" is to be used for other use-cases than just WebRTC, then the Title needs to change. But what do we call it? Cheers, Barry Dingle Australia On Wed, Apr 9, 2014 at 9:22 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > The WebRTC Data Channel will be used also for non-WebRTC applications (it > is e.g. base for the CLUE Data Channel), where the must-use-SRTP rule does > not necessarily apply. > > Having said that, I DO think that the draft text need to be more generic. > WebRTC can be described as a use-case, but it shall be clear that the > mechanism can also be used in other environments. > > Regards. > > Christer > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Colin Perkins > Sent: 9. huhtikuuta 2014 14:01 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt > > On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Real-Time Communication in WEB-browsers > Working Group of the IETF. > > > > Title : WebRTC Data Channels > > Authors : Randell Jesup > > Salvatore Loreto > > Michael Tuexen > > Filename : draft-ietf-rtcweb-data-channel-08.txt > > Pages : 15 > > Date : 2014-04-09 > > > > Abstract: > > The Real-Time Communication in WEB-browsers working group is charged > > to provide protocol support for direct interactive rich communication > > using audio, video, and data between two peers' web-browsers. This > > document specifies the non-(S)RTP media data transport aspects of the > > WebRTC framework. It provides an architectural overview of how the > > Stream Control Transmission Protocol (SCTP) is used in the WebRTC > > context as a generic transport service allowing WEB-browsers to > > exchange generic data from peer to peer. > > This talks about "(S)RTP" throughout, but the rtp-usage draft requires > that SRTP be used for WebRTC, and disallows plain RTP. I think this draft > could be simplified by changing "(S)RTP" to "SRTP" throughout. > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec53f35f5c66cf704f69a9563 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

If "WebRTC Data Channel" i= s to be used for other use-cases than just WebRTC, then the Title needs to = change.=C2=A0 But what do we call it?

Cheers,
Barry Dingle
Australia


On Wed, Apr 9, 2014 at 9:22 PM, Christer= Holmberg <christer.holmberg@ericsson.com> wrot= e:
Hi,

The WebRTC Data Channel will be used also for non-WebRTC applications (it i= s e.g. base for the CLUE Data Channel), where the must-use-SRTP rule does n= ot necessarily apply.

Having said that, I DO think that the draft text need to be more generic. W= ebRTC can be described as a use-case, but it shall be clear that the mechan= ism can also be used in other environments.

Regards.

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of Colin Perkins
Sent: 9. huhtikuuta 2014 14:01
To: rtcweb@ietf.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt

On 9 Apr 2014, at 11:02, Intern= et-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = WebRTC Data Channels
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Rande= ll Jesup
> =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=A0Salvatore Loreto
> =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=A0Michael Tuexen
> =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-= rtcweb-data-channel-08.txt
> =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 15
> =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2= 014-04-09
>
> Abstract:
> =C2=A0 The Real-Time Communication in WEB-browsers working group is ch= arged
> =C2=A0 to provide protocol support for direct interactive rich communi= cation
> =C2=A0 using audio, video, and data between two peers' web-browser= s. =C2=A0This
> =C2=A0 document specifies the non-(S)RTP media data transport aspects = of the
> =C2=A0 WebRTC framework. =C2=A0It provides an architectural overview o= f how the
> =C2=A0 Stream Control Transmission Protocol (SCTP) is used in the WebR= TC
> =C2=A0 context as a generic transport service allowing WEB-browsers to=
> =C2=A0 exchange generic data from peer to peer.

This talks about "(S)RTP" throughout, but the rtp-usage draft req= uires that SRTP be used for WebRTC, and disallows plain RTP. I think this d= raft could be simplified by changing "(S)RTP" to "SRTP"= throughout.

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



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec53f35f5c66cf704f69a9563-- From nobody Wed Apr 9 04:46:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3150A1A0249 for ; Wed, 9 Apr 2014 04:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 fnsvLrEk8dNK for ; Wed, 9 Apr 2014 04:46:26 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BF1C71A00E6 for ; Wed, 9 Apr 2014 04:46:24 -0700 (PDT) X-AuditID: c1b4fb25-b7f3b8e0000006f1-7e-5345330fa4ea Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4D.12.01777.F0335435; Wed, 9 Apr 2014 13:46:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 13:46:23 +0200 From: Christer Holmberg To: Barry Dingle Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt Thread-Index: AQHPU9r8wvMWA0Q1K0mIC9kJW7dm+ZsI/KmAgAAnGWD//+RHgIAAIoLA Date: Wed, 9 Apr 2014 11:46:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2B7B0E@ESESSMB209.ericsson.se> References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2B7AAB@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+JvjS6/sWuwwbdtahaP79taLH95gtFi 7b92dgdmj2n377N57Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZJ5v9CubIViyYOImxgXGP TBcjJ4eEgInE+VfbWSFsMYkL99azgdhCAocZJfYfzu9i5AKyFzNKrOw9ydzFyMHBJmAh0f1P G6RGREBVYt/syUwgNrOAl8TznTsYQUqEBdwlev7FQpR4SMz4tJwVwnaTuNzVyQ5iswioSFxe t48dpJxXwFfi9zUjiE1NTBL/Xu8Fi3MKBEo8n+4CUs4IdNn3U2ugNolL3HoynwniYgGJJXvO M0PYohIvH/+D+kRJ4seGSywgY5gFNCXW79KHaFWUmNL9EOwCXgFBiZMzn7BMYBSbhWTqLISO WUg6ZiHpWMDIsoqRPTcxMye93GgTIzBSDm75rbqD8c45kUOM0hwsSuK8H946BwkJpCeWpGan phakFsUXleakFh9iZOLglGpg9Lzkn1es0qWWNGs7a2KqsrO6v/ak+3JfD9yTdO3l6njgyRKX /yJgSW7Nxzq1jb0zTmat8liVdlpV/gUve0/2fLGeZbIZ0VynF2/rSZX/cHCmYvTTqkUHnfja +qXl1ILqV2369cfOZ8KnhMALyzIPsDmwpkfy5k91aVdO4vokY3ron4Z37D4lluKMREMt5qLi RAA7IuhlYgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4nlL9P-1r6VgNNoLT7CH4p5EeU8 Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 11:46:28 -0000 SGksDQoNCj5JZiAiV2ViUlRDIERhdGEgQ2hhbm5lbCIgaXMgdG8gYmUgdXNlZCBmb3Igb3RoZXIg dXNlLWNhc2VzIHRoYW4ganVzdCBXZWJSVEMsIHRoZW4gdGhlIFRpdGxlIG5lZWRzIHRvIGNoYW5n ZS7CoCBCdXQgd2hhdCBkbyB3ZSBjYWxsIGl0PyANCg0KSSB0aGluayB3ZSBoYWQgdGhpcyBkaXNj dXNzaW9uIGFscmVhZHkgZWFybGllciwgYW5kIHBlb3BsZSBzdWdnZXN0ZWQgZGlmZmVyZW50IG5l dyBuYW1lcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCk9uIFdlZCwgQXByIDksIDIw MTQgYXQgOToyMiBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4gd3JvdGU6DQpIaSwNCg0KVGhlIFdlYlJUQyBEYXRhIENoYW5uZWwgd2lsbCBiZSB1 c2VkIGFsc28gZm9yIG5vbi1XZWJSVEMgYXBwbGljYXRpb25zIChpdCBpcyBlLmcuIGJhc2UgZm9y IHRoZSBDTFVFIERhdGEgQ2hhbm5lbCksIHdoZXJlIHRoZSBtdXN0LXVzZS1TUlRQIHJ1bGUgZG9l cyBub3QgbmVjZXNzYXJpbHkgYXBwbHkuDQoNCkhhdmluZyBzYWlkIHRoYXQsIEkgRE8gdGhpbmsg dGhhdCB0aGUgZHJhZnQgdGV4dCBuZWVkIHRvIGJlIG1vcmUgZ2VuZXJpYy4gV2ViUlRDIGNhbiBi ZSBkZXNjcmliZWQgYXMgYSB1c2UtY2FzZSwgYnV0IGl0IHNoYWxsIGJlIGNsZWFyIHRoYXQgdGhl IG1lY2hhbmlzbSBjYW4gYWxzbyBiZSB1c2VkIGluIG90aGVyIGVudmlyb25tZW50cy4NCg0KUmVn YXJkcy4NCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0 Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ29saW4g UGVya2lucw0KU2VudDogOS4gaHVodGlrdXV0YSAyMDE0IDE0OjAxDQpUbzogcnRjd2ViQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydGN3ZWIt ZGF0YS1jaGFubmVsLTA4LnR4dA0KDQpPbiA5IEFwciAyMDE0LCBhdCAxMTowMiwgSW50ZXJuZXQt RHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFJlYWwtVGltZSBDb21tdW5pY2F0aW9uIGluIFdF Qi1icm93c2VycyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPg0KPiDCoCDCoCDCoCDCoFRp dGxlIMKgIMKgIMKgIMKgIMKgIDogV2ViUlRDIERhdGEgQ2hhbm5lbHMNCj4gwqAgwqAgwqAgwqBB dXRob3JzIMKgIMKgIMKgIMKgIDogUmFuZGVsbCBKZXN1cA0KPiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoFNhbHZhdG9yZSBMb3JldG8NCj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBNaWNoYWVsIFR1ZXhlbg0KPiDCoCDCoCDCoCBGaWxlbmFtZSDC oCDCoCDCoCDCoDogZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsLTA4LnR4dA0KPiDCoCDC oCDCoCBQYWdlcyDCoCDCoCDCoCDCoCDCoCA6IDE1DQo+IMKgIMKgIMKgIERhdGUgwqAgwqAgwqAg wqAgwqAgwqA6IDIwMTQtMDQtMDkNCj4NCj4gQWJzdHJhY3Q6DQo+IMKgIFRoZSBSZWFsLVRpbWUg Q29tbXVuaWNhdGlvbiBpbiBXRUItYnJvd3NlcnMgd29ya2luZyBncm91cCBpcyBjaGFyZ2VkDQo+ IMKgIHRvIHByb3ZpZGUgcHJvdG9jb2wgc3VwcG9ydCBmb3IgZGlyZWN0IGludGVyYWN0aXZlIHJp Y2ggY29tbXVuaWNhdGlvbg0KPiDCoCB1c2luZyBhdWRpbywgdmlkZW8sIGFuZCBkYXRhIGJldHdl ZW4gdHdvIHBlZXJzJyB3ZWItYnJvd3NlcnMuIMKgVGhpcw0KPiDCoCBkb2N1bWVudCBzcGVjaWZp ZXMgdGhlIG5vbi0oUylSVFAgbWVkaWEgZGF0YSB0cmFuc3BvcnQgYXNwZWN0cyBvZiB0aGUNCj4g wqAgV2ViUlRDIGZyYW1ld29yay4gwqBJdCBwcm92aWRlcyBhbiBhcmNoaXRlY3R1cmFsIG92ZXJ2 aWV3IG9mIGhvdyB0aGUNCj4gwqAgU3RyZWFtIENvbnRyb2wgVHJhbnNtaXNzaW9uIFByb3RvY29s IChTQ1RQKSBpcyB1c2VkIGluIHRoZSBXZWJSVEMNCj4gwqAgY29udGV4dCBhcyBhIGdlbmVyaWMg dHJhbnNwb3J0IHNlcnZpY2UgYWxsb3dpbmcgV0VCLWJyb3dzZXJzIHRvDQo+IMKgIGV4Y2hhbmdl IGdlbmVyaWMgZGF0YSBmcm9tIHBlZXIgdG8gcGVlci4NCg0KVGhpcyB0YWxrcyBhYm91dCAiKFMp UlRQIiB0aHJvdWdob3V0LCBidXQgdGhlIHJ0cC11c2FnZSBkcmFmdCByZXF1aXJlcyB0aGF0IFNS VFAgYmUgdXNlZCBmb3IgV2ViUlRDLCBhbmQgZGlzYWxsb3dzIHBsYWluIFJUUC4gSSB0aGluayB0 aGlzIGRyYWZ0IGNvdWxkIGJlIHNpbXBsaWZpZWQgYnkgY2hhbmdpbmcgIihTKVJUUCIgdG8gIlNS VFAiIHRocm91Z2hvdXQuDQoNCi0tDQpDb2xpbiBQZXJraW5zDQpodHRwOi8vY3NwZXJraW5zLm9y Zy8NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== From nobody Wed Apr 9 05:18:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0556F1A0284 for ; Wed, 9 Apr 2014 05:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=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 ZfjckPL35r15 for ; Wed, 9 Apr 2014 05:17:59 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 52F731A0280 for ; Wed, 9 Apr 2014 05:17:59 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so2406803wes.34 for ; Wed, 09 Apr 2014 05:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type; bh=a9U11x7fHiGlrMr3evXLhuEER3YRylU+RkL11dxxkPc=; b=VLZmGYWJVU9jzahaxypyi9bF5uvsvG/iIWKdxkg6ADAx8wt68oB4dZ0sv+7nKHyuzU utQQFn8qqCURy7LSvfWE/gvw4ys8/rvkoC0lFCC/YVonuZDWGv7RR9d9/TaOXhqONUV5 T/1qZZQcp6SvMCzdzyU6T++1k4SyFdVHLYfCXQURbSf7cN/+MWNy1M/IGLsvaVtrv8HA 7LzKqaaBJq3R+FImbKmWVVrRMGyh3yVT4WZ2PxxFKSK4Zn6aXq4c4L6jQbg7nbM933cO tC88X6m6ZhlHhyvNfv7w9f+yF37PzLK1K+4A5mKPmrF/FQynzhJ4gJO2ZNDcr9izgFMF BEGg== X-Received: by 10.180.94.8 with SMTP id cy8mr10764621wib.29.1397045878046; Wed, 09 Apr 2014 05:17:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.91.212 with HTTP; Wed, 9 Apr 2014 05:17:37 -0700 (PDT) In-Reply-To: <20140409100313.9526.70264.idtracker@ietfa.amsl.com> References: <20140409100313.9526.70264.idtracker@ietfa.amsl.com> From: Barry Dingle Date: Wed, 9 Apr 2014 22:17:37 +1000 Message-ID: Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d0434c0ca4bca1104f69b17aa Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Afw5Bv__qBiM33kB_LWAPI-mOxY Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 12:18:01 -0000 --f46d0434c0ca4bca1104f69b17aa Content-Type: text/plain; charset=UTF-8 Hi, The first sentence of the Abstract in the WebRTC Data Channel Establishment Protocol incorrectly refers to the "WebRTC working group. (The wording in the second line also needs editing.) I suggest copying the first sentence of the Abstract from WebRTC Data Channels (-08 version) so it reads - The Real-Time Communication in WEB-browsers working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. Cheers, /Barry Dingle Australia On Wed, Apr 9, 2014 at 8:03 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > Working Group of the IETF. > > Title : WebRTC Data Channel Establishment Protocol > Authors : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-protocol-04.txt > Pages : 12 > Date : 2014-04-09 > > Abstract: > The Web Real-Time Communication (WebRTC) working group is charged to > provide protocols to support for direct interactive rich > communication using audio, video, and data between two peers' web- > browsers. This document specifies a simple protocol for establishing > symmetric data channels between the peers. It uses a two way > handshake and allows sending of user data without waiting for the > handshake to complete. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-protocol-04 > > > 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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d0434c0ca4bca1104f69b17aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The first sentence of the Abstract in the = WebRTC Data Channel Establishment Protocol incorrectly refers to the "= WebRTC working group. (The wording in the second line also needs editing.)<= br>
I suggest copying the first sentence of the Abstract from WebRTC = Data Channels (-08 version) so it reads - 

The Real-Time Commun=
ication in WEB-browsers working group is charged
   to provide protocol support for direct interactive rich communication
   using audio, video, and data between two peers' web-browsers.
<= br>

Cheer= s,
/Barry Dingle
Australia


On Wed, Apr 9, 2014 at 8:03 PM, <internet-drafts@ietf.org><= /span> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : WebR= TC Data Channel Establishment Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Randell J= esup
=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 Salvatore Loreto
=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 Michael Tuexen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-rtcweb-data-protocol-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 12 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-04-09

Abstract:
=C2=A0 =C2=A0The Web Real-Time Communication (WebRTC) working group is char= ged to
=C2=A0 =C2=A0provide protocols to support for direct interactive rich
=C2=A0 =C2=A0communication using audio, video, and data between two peers&#= 39; web-
=C2=A0 =C2=A0browsers. =C2=A0This document specifies a simple protocol for = establishing
=C2=A0 =C2=A0symmetric data channels between the peers. =C2=A0It uses a two= way
=C2=A0 =C2=A0handshake and allows sending of user data without waiting for = the
=C2=A0 =C2=A0handshake to complete.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-dat= a-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol= -04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcw= eb-data-protocol-04


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--f46d0434c0ca4bca1104f69b17aa-- From nobody Wed Apr 9 07:12:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A179B1A0323 for ; Wed, 9 Apr 2014 07:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 n-aOlYqc5MAo for ; Wed, 9 Apr 2014 07:12:22 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 520C91A0318 for ; Wed, 9 Apr 2014 07:12:19 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta10.westchester.pa.mail.comcast.net with comcast id noHC1n0040xGWP85AqCK9Y; Wed, 09 Apr 2014 14:12:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id nqCJ1n0193ZTu2S3YqCJlJ; Wed, 09 Apr 2014 14:12:19 +0000 Message-ID: <53455542.2030105@alum.mit.edu> Date: Wed, 09 Apr 2014 10:12:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2B7AAB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2B7B0E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2B7B0E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397052739; bh=0wYWpNHsKTqV51D4z3aW3y4JFZ/7JF9L0i27jQFmZj8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=B37o/y+U1wY0DQZTeVicbrc1Lb/Rgfcomq+BgF1jXJN9DHNQ6ZkDbxeqHAR7ktH+t on/4fZAi1X5wKh+WPL17g3LluXy5Pa+bxj6hcYX/NDG068EXhtm0IzLs1MH1Pq9xKg Hm+URjp67rsggJHGgqrPmedlJ3wFaKpQjf8BeW9IR5jFK7q4kmIPUYykZPTkeTgDUH U9Bn4FsKFqXTs4rDdna3i9/i6vBwRw9Pf/4xYxjhgX5B681eeC4rkArGF0AAyB5a9+ cqn5TUe9+nNr3vthC5YQSVmSNS4yAwOAId/GTtrsO1FWwJJENLxCECZCWNNF4prUkP sPgYuKb3tGp+A== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OEqBbIA0iO5DgNzTR6qsAKR7OXU Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:12:26 -0000 SCTP Data Channel, or simply Data Channel. On 4/9/14 7:46 AM, Christer Holmberg wrote: > Hi, > >> If "WebRTC Data Channel" is to be used for other use-cases than just WebRTC, then the Title needs to change. But what do we call it? > > I think we had this discussion already earlier, and people suggested different new names. > > Regards, > > Christer > > > > On Wed, Apr 9, 2014 at 9:22 PM, Christer Holmberg wrote: > Hi, > > The WebRTC Data Channel will be used also for non-WebRTC applications (it is e.g. base for the CLUE Data Channel), where the must-use-SRTP rule does not necessarily apply. > > Having said that, I DO think that the draft text need to be more generic. WebRTC can be described as a use-case, but it shall be clear that the mechanism can also be used in other environments. > > Regards. > > Christer > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Colin Perkins > Sent: 9. huhtikuuta 2014 14:01 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt > > On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. >> >> Title : WebRTC Data Channels >> Authors : Randell Jesup >> Salvatore Loreto >> Michael Tuexen >> Filename : draft-ietf-rtcweb-data-channel-08.txt >> Pages : 15 >> Date : 2014-04-09 >> >> Abstract: >> The Real-Time Communication in WEB-browsers working group is charged >> to provide protocol support for direct interactive rich communication >> using audio, video, and data between two peers' web-browsers. This >> document specifies the non-(S)RTP media data transport aspects of the >> WebRTC framework. It provides an architectural overview of how the >> Stream Control Transmission Protocol (SCTP) is used in the WebRTC >> context as a generic transport service allowing WEB-browsers to >> exchange generic data from peer to peer. > > This talks about "(S)RTP" throughout, but the rtp-usage draft requires that SRTP be used for WebRTC, and disallows plain RTP. I think this draft could be simplified by changing "(S)RTP" to "SRTP" throughout. > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Wed Apr 9 07:20:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56F91A0336 for ; Wed, 9 Apr 2014 07:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=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 XGRSHPy-3qaL for ; Wed, 9 Apr 2014 07:20:14 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1A25C1A032F for ; Wed, 9 Apr 2014 07:20:13 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so9590920wib.1 for ; Wed, 09 Apr 2014 07:20: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:from:date:message-id:subject:cc :content-type; bh=sKFCqCdCNIQBgYBAZ8NzGhCDhp8Yv9yMt5rgztx4cgo=; b=Y/kJIooosWyk+wLlBe5SbzW4OrLY+7evqOupx1OWyVfNnTFAQLqGO66k4gavohDXb9 leiJiZICsYm+I5X2huQ5JEuoVsAZH9DoYUZu4rCw/sWK+SnF35X0S4rJhlhYhxna0mhD zfVpro6b1fysoEoerUYiiSOKI11vjZY/KK6p4ex+nemvdr+X38auhW6TNtZ/jEcjvROE h3804f7NoE68igS/FkPHeQWXZdBZjOUQMGGSNFCrSOx3n0cPkd4M7dM0qF6lL9uW6C8H LoOs3rvycFEA5tWlQfpTkOVg8tnWPyIrUeIJrn0hEHXey5S0RrwE8Zlnmqi8WQL7m0WQ DocA== X-Received: by 10.194.189.80 with SMTP id gg16mr1990015wjc.84.1397053212793; Wed, 09 Apr 2014 07:20:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.91.212 with HTTP; Wed, 9 Apr 2014 07:19:52 -0700 (PDT) In-Reply-To: <20140409100313.9526.70264.idtracker@ietfa.amsl.com> References: <20140409100313.9526.70264.idtracker@ietfa.amsl.com> From: Barry Dingle Date: Thu, 10 Apr 2014 00:19:52 +1000 Message-ID: Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb03f9c7b20a104f69ccca7 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jHR9lQ1kct7JcEezUCAhJH-loms Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:20:15 -0000 --047d7bb03f9c7b20a104f69ccca7 Content-Type: text/plain; charset=UTF-8 Data Channel Establishment Protocol *Editorials* - Section 4 - 2nd paragraph - Change "The set of consistent properties includes " to the following "The set of consistent properties includes : " Section 4 - 3rd para (after the 6 dot points), 2nd sentence reads as follows - "The side wanting to open a data channel selects an SCTP stream identifier for which the corresponding incoming and outgoing SCTP stream is unused and sends a DATA_CHANNEL_OPEN message on this outgoing SCTP stream. " This is confusing. I suggest it be simplified to - "The side wanting to open a data channel selects an unused SCTP stream identifier and sends a DATA_CHANNEL_OPEN message on this outgoing SCTP stream. " Cheers, /Barry Dingle Australia On Wed, Apr 9, 2014 at 8:03 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > Working Group of the IETF. > > Title : WebRTC Data Channel Establishment Protocol > Authors : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-protocol-04.txt > Pages : 12 > Date : 2014-04-09 > > Abstract: > The Web Real-Time Communication (WebRTC) working group is charged to > provide protocols to support for direct interactive rich > communication using audio, video, and data between two peers' web- > browsers. This document specifies a simple protocol for establishing > symmetric data channels between the peers. It uses a two way > handshake and allows sending of user data without waiting for the > handshake to complete. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-protocol-04 > > > 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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bb03f9c7b20a104f69ccca7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Data Channel Establishment Protocol Edit= orials -

Section 4 - 2nd paragraph -

C= hange=C2=A0 
"The set of consistent properties incl=
udes "   to the following 



"The set of consistent properties includes : "
=

Section 4 - 3rd para (after the 6 dot points), 2nd sentence = reads as follows -=C2=A0 
"The side wanting t=
o open a data channel selects an SCTP stream identifier for which the
   corresponding incoming and outgoing SCTP stream is unused and sends a
   DATA_CHANNEL_OPEN message on this outgoing SCTP stream. "
This= is confusing. I suggest it be simplified to - 
"Th=
e side wanting to open a data channel selects an unused SCTP stream identifier   and sends a
   DATA_CHANNEL_OPEN message on this outgoing SCTP stream. "

Cheers,
/= Barry Dingle
Australia


On Wed, Apr 9, 2014 at 8:03 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : WebR= TC Data Channel Establishment Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Randell J= esup
=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 Salvatore Loreto
=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 Michael Tuexen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-rtcweb-data-protocol-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 12 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-04-09

Abstract:
=C2=A0 =C2=A0The Web Real-Time Communication (WebRTC) working group is char= ged to
=C2=A0 =C2=A0provide protocols to support for direct interactive rich
=C2=A0 =C2=A0communication using audio, video, and data between two peers&#= 39; web-
=C2=A0 =C2=A0browsers. =C2=A0This document specifies a simple protocol for = establishing
=C2=A0 =C2=A0symmetric data channels between the peers. =C2=A0It uses a two= way
=C2=A0 =C2=A0handshake and allows sending of user data without waiting for = the
=C2=A0 =C2=A0handshake to complete.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-dat= a-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol= -04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcw= eb-data-protocol-04


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bb03f9c7b20a104f69ccca7-- From nobody Wed Apr 9 07:20:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BF21A0380 for ; Wed, 9 Apr 2014 07:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] autolearn=ham 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 1c1ZOBKAn1kZ for ; Wed, 9 Apr 2014 07:20:44 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 1614F1A032F for ; Wed, 9 Apr 2014 07:20:43 -0700 (PDT) Received: from [192.168.1.103] (p508F0BDC.dip0.t-ipconnect.de [80.143.11.220]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 83C801C1047E4; Wed, 9 Apr 2014 16:20:41 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: Date: Wed, 9 Apr 2014 16:20:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> To: Colin Perkins X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DcLAm3ymvZgLTHHLUn08s0e6Rzc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:20:48 -0000 On 09 Apr 2014, at 13:00, Colin Perkins wrote: > On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >>=20 >> Title : WebRTC Data Channels >> Authors : Randell Jesup >> Salvatore Loreto >> Michael Tuexen >> Filename : draft-ietf-rtcweb-data-channel-08.txt >> Pages : 15 >> Date : 2014-04-09 >>=20 >> Abstract: >> The Real-Time Communication in WEB-browsers working group is charged >> to provide protocol support for direct interactive rich = communication >> using audio, video, and data between two peers' web-browsers. This >> document specifies the non-(S)RTP media data transport aspects of = the >> WebRTC framework. It provides an architectural overview of how the >> Stream Control Transmission Protocol (SCTP) is used in the WebRTC >> context as a generic transport service allowing WEB-browsers to >> exchange generic data from peer to peer. >=20 > This talks about =93(S)RTP=94 throughout, but the rtp-usage draft = requires that SRTP be used for WebRTC, and disallows plain RTP. I think = this draft could be simplified by changing =93(S)RTP=94 to =93SRTP=94 = throughout. Hi Colin, The (S)RTP notion goes back to a comment from Magnus. If I remember it = correctly he considers SRTP a profile of RTP. Since I don't wanted to just use RTP, I ended up = with (S)RTP based on a discussion with Magnus. However, I'm fine with changing it to SRTP... Magnus: Any comment? Best regards Michael >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Wed Apr 9 07:25:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EB31A032F for ; Wed, 9 Apr 2014 07:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 r218O6rFdVFf for ; Wed, 9 Apr 2014 07:25:18 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id EB90D1A0327 for ; Wed, 9 Apr 2014 07:25:17 -0700 (PDT) Received: from [130.209.247.112] (port=50025 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WXtRA-0001ao-Nw; Wed, 09 Apr 2014 15:25:16 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Colin Perkins In-Reply-To: Date: Wed, 9 Apr 2014 15:25:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <02F2BCF4-70B5-47A4-ACE6-C0CCCAB11A50@csperkins.org> References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> To: Michael Tuexen X-Mailer: Apple Mail (2.1874) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3HHw7LwCZms8QQkv1Howz-E__lY Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:25:19 -0000 On 9 Apr 2014, at 15:20, Michael Tuexen = wrote: > On 09 Apr 2014, at 13:00, Colin Perkins wrote: >> On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >>>=20 >>> Title : WebRTC Data Channels >>> Authors : Randell Jesup >>> Salvatore Loreto >>> Michael Tuexen >>> Filename : draft-ietf-rtcweb-data-channel-08.txt >>> Pages : 15 >>> Date : 2014-04-09 >>>=20 >>> Abstract: >>> The Real-Time Communication in WEB-browsers working group is charged >>> to provide protocol support for direct interactive rich = communication >>> using audio, video, and data between two peers' web-browsers. This >>> document specifies the non-(S)RTP media data transport aspects of = the >>> WebRTC framework. It provides an architectural overview of how the >>> Stream Control Transmission Protocol (SCTP) is used in the WebRTC >>> context as a generic transport service allowing WEB-browsers to >>> exchange generic data from peer to peer. >>=20 >> This talks about =93(S)RTP=94 throughout, but the rtp-usage draft = requires that SRTP be used for WebRTC, and disallows plain RTP. I think = this draft could be simplified by changing =93(S)RTP=94 to =93SRTP=94 = throughout. > Hi Colin, >=20 > The (S)RTP notion goes back to a comment from Magnus. If I remember it = correctly he considers SRTP a profile of RTP. Since I don=92t wanted to = just use RTP, I ended up with (S)RTP based on a discussion with Magnus. >=20 > However, I=92m fine with changing it to SRTP... SRTP is an RTP profile. My comment was that if this is for WebRTC only, = then only SRTP can be used, and not plain RTP. Using =93(S)RTP=94 = rather than =93SRTP=94 in this draft suggests that the secure profile is = optional, which isn=92t the case in WebRTC. If this is for more general = use than WebRTC, then =93(S)RTP=94 is fine. Colin > Magnus: Any comment? >=20 > Best regards > Michael >=20 >>=20 >> --=20 >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 --=20 Colin Perkins http://csperkins.org/ From nobody Wed Apr 9 07:28:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847AE1A032F for ; Wed, 9 Apr 2014 07:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] autolearn=ham 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 ot60hbbdgPNM for ; Wed, 9 Apr 2014 07:28:24 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 151651A032E for ; Wed, 9 Apr 2014 07:28:24 -0700 (PDT) Received: from [192.168.1.103] (p508F0BDC.dip0.t-ipconnect.de [80.143.11.220]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 97C9B1C10464D; Wed, 9 Apr 2014 16:28:22 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: Date: Wed, 9 Apr 2014 16:28:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140409100313.9526.70264.idtracker@ietfa.amsl.com> To: Barry Dingle X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eGFlvriXNL9moq4pDan1b5uuxC8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:28:25 -0000 On 09 Apr 2014, at 14:17, Barry Dingle wrote: > Hi, >=20 > The first sentence of the Abstract in the WebRTC Data Channel = Establishment Protocol incorrectly refers to the "WebRTC working group. = (The wording in the second line also needs editing.) >=20 > I suggest copying the first sentence of the Abstract from WebRTC Data = Channels (-08 version) so it reads -=20 >=20 > The Real-Time Communication in WEB-browsers working group is charged > to provide protocol support for direct interactive rich = communication > using audio, video, and data between two peers' web-browsers. OK. Will be in the next revision. Best regards Michael >=20 >=20 >=20 > Cheers, > /Barry Dingle > Australia >=20 >=20 > On Wed, Apr 9, 2014 at 8:03 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : WebRTC Data Channel Establishment Protocol > Authors : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-protocol-04.txt > Pages : 12 > Date : 2014-04-09 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) working group is charged = to > provide protocols to support for direct interactive rich > communication using audio, video, and data between two peers' web- > browsers. This document specifies a simple protocol for = establishing > symmetric data channels between the peers. It uses a two way > handshake and allows sending of user data without waiting for the > handshake to complete. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-protocol-04 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Apr 9 07:32:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6EE1A034A for ; Wed, 9 Apr 2014 07:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] autolearn=ham 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 yVnzT-4mQSpD for ; Wed, 9 Apr 2014 07:32:28 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAA81A0382 for ; Wed, 9 Apr 2014 07:32:28 -0700 (PDT) Received: from [192.168.1.103] (p508F0BDC.dip0.t-ipconnect.de [80.143.11.220]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5B6801C10464D; Wed, 9 Apr 2014 16:32:27 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: Date: Wed, 9 Apr 2014 16:32:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140409100313.9526.70264.idtracker@ietfa.amsl.com> To: Barry Dingle X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DkH1O5Thk8yEaNHFSSeFLa8Xwvk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:32:30 -0000 On 09 Apr 2014, at 16:19, Barry Dingle wrote: > Data Channel Establishment Protocol Editorials -=20 >=20 > Section 4 - 2nd paragraph -=20 >=20 > Change =20 > "The set of consistent properties includes " to the following=20 >=20 >=20 >=20 >=20 > "The set of consistent properties includes : " =20 Done. >=20 > Section 4 - 3rd para (after the 6 dot points), 2nd sentence reads as = follows - =20 > "The side wanting to open a data channel selects an SCTP stream = identifier for which the > corresponding incoming and outgoing SCTP stream is unused and sends = a > DATA_CHANNEL_OPEN message on this outgoing SCTP stream. " >=20 > This is confusing. I suggest it be simplified to -=20 > "The side wanting to open a data channel selects an unused > SCTP stream identifier and sends a > DATA_CHANNEL_OPEN message on this outgoing SCTP stream. " But it is the pair of streams which are unused, not the stream = identifier. Is The side wanting to open a data channel selects an SCTP stream = identifier for which the corresponding incoming and outgoing SCTP streams are unused and sends a DATA_CHANNEL_OPEN message on the outgoing SCTP stream. better? Best regards Michael >=20 >=20 > Cheers, > /Barry Dingle > Australia >=20 >=20 > On Wed, Apr 9, 2014 at 8:03 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : WebRTC Data Channel Establishment Protocol > Authors : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-protocol-04.txt > Pages : 12 > Date : 2014-04-09 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) working group is charged = to > provide protocols to support for direct interactive rich > communication using audio, video, and data between two peers' web- > browsers. This document specifies a simple protocol for = establishing > symmetric data channels between the peers. It uses a two way > handshake and allows sending of user data without waiting for the > handshake to complete. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-protocol-04 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Apr 9 07:33:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8581A033B for ; Wed, 9 Apr 2014 07:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] autolearn=ham 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 Ww9-E_Y1nJi7 for ; Wed, 9 Apr 2014 07:33:52 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id D68C11A0384 for ; Wed, 9 Apr 2014 07:33:51 -0700 (PDT) Received: from [192.168.1.103] (p508F0BDC.dip0.t-ipconnect.de [80.143.11.220]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B0CB41C10464D; Wed, 9 Apr 2014 16:33:50 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <02F2BCF4-70B5-47A4-ACE6-C0CCCAB11A50@csperkins.org> Date: Wed, 9 Apr 2014 16:33:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9889BAD9-D9A7-42F2-A0DC-632C26696345@lurchi.franken.de> References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <02F2BCF4-70B5-47A4-ACE6-C0CCCAB11A50@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jObL7-Z8KHG1TxaAYR5Y5ZWx3Hg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:33:56 -0000 On 09 Apr 2014, at 16:25, Colin Perkins wrote: > On 9 Apr 2014, at 15:20, Michael Tuexen = wrote: >> On 09 Apr 2014, at 13:00, Colin Perkins wrote: >>> On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >>>>=20 >>>> Title : WebRTC Data Channels >>>> Authors : Randell Jesup >>>> Salvatore Loreto >>>> Michael Tuexen >>>> Filename : draft-ietf-rtcweb-data-channel-08.txt >>>> Pages : 15 >>>> Date : 2014-04-09 >>>>=20 >>>> Abstract: >>>> The Real-Time Communication in WEB-browsers working group is = charged >>>> to provide protocol support for direct interactive rich = communication >>>> using audio, video, and data between two peers' web-browsers. This >>>> document specifies the non-(S)RTP media data transport aspects of = the >>>> WebRTC framework. It provides an architectural overview of how the >>>> Stream Control Transmission Protocol (SCTP) is used in the WebRTC >>>> context as a generic transport service allowing WEB-browsers to >>>> exchange generic data from peer to peer. >>>=20 >>> This talks about =93(S)RTP=94 throughout, but the rtp-usage draft = requires that SRTP be used for WebRTC, and disallows plain RTP. I think = this draft could be simplified by changing =93(S)RTP=94 to =93SRTP=94 = throughout. >> Hi Colin, >>=20 >> The (S)RTP notion goes back to a comment from Magnus. If I remember = it correctly he considers SRTP a profile of RTP. Since I don=92t wanted = to just use RTP, I ended up with (S)RTP based on a discussion with = Magnus. >>=20 >> However, I=92m fine with changing it to SRTP... >=20 > SRTP is an RTP profile. My comment was that if this is for WebRTC = only, then only SRTP can be used, and not plain RTP. Using =93(S)RTP=94 = rather than =93SRTP=94 in this draft suggests that the secure profile is = optional, which isn=92t the case in WebRTC. If this is for more general = use than WebRTC, then =93(S)RTP=94 is fine. It is clear that in WebRTC only SRTP is used... Best regards Michael >=20 > Colin >=20 >=20 >=20 >> Magnus: Any comment? >>=20 >> Best regards >> Michael >>=20 >>>=20 >>> --=20 >>> Colin Perkins >>> http://csperkins.org/ >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 >=20 From nobody Wed Apr 9 07:39:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6A91A0159 for ; Wed, 9 Apr 2014 07:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 0BuscfkmWrFh for ; Wed, 9 Apr 2014 07:39:49 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 3632B1A005A for ; Wed, 9 Apr 2014 07:39:49 -0700 (PDT) Received: from [130.209.247.112] (port=50160 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WXtfC-0004SI-Ig; Wed, 09 Apr 2014 15:39:48 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Colin Perkins In-Reply-To: <9889BAD9-D9A7-42F2-A0DC-632C26696345@lurchi.franken.de> Date: Wed, 9 Apr 2014 15:39:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73C21E05-E36C-4899-98A4-9D762B75FCE4@csperkins.org> References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <02F2BCF4-70B5-47A4-ACE6-C0CCCAB11A50@csperkins.org> <9889BAD9-D9A7-42F2-A0DC-632C26696345@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.1874) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RZKn6G4Ziuu0Btnk9dS0iX7I3II Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:39:54 -0000 On 9 Apr 2014, at 15:33, Michael Tuexen = wrote: > On 09 Apr 2014, at 16:25, Colin Perkins wrote: >> On 9 Apr 2014, at 15:20, Michael Tuexen = wrote: >>> On 09 Apr 2014, at 13:00, Colin Perkins wrote: >>>> On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>> This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >>>>>=20 >>>>> Title : WebRTC Data Channels >>>>> Authors : Randell Jesup >>>>> Salvatore Loreto >>>>> Michael Tuexen >>>>> Filename : draft-ietf-rtcweb-data-channel-08.txt >>>>> Pages : 15 >>>>> Date : 2014-04-09 >>>>>=20 >>>>> Abstract: >>>>> The Real-Time Communication in WEB-browsers working group is = charged >>>>> to provide protocol support for direct interactive rich = communication >>>>> using audio, video, and data between two peers' web-browsers. = This >>>>> document specifies the non-(S)RTP media data transport aspects of = the >>>>> WebRTC framework. It provides an architectural overview of how = the >>>>> Stream Control Transmission Protocol (SCTP) is used in the WebRTC >>>>> context as a generic transport service allowing WEB-browsers to >>>>> exchange generic data from peer to peer. >>>>=20 >>>> This talks about =93(S)RTP=94 throughout, but the rtp-usage draft = requires that SRTP be used for WebRTC, and disallows plain RTP. I think = this draft could be simplified by changing =93(S)RTP=94 to =93SRTP=94 = throughout. >>> Hi Colin, >>>=20 >>> The (S)RTP notion goes back to a comment from Magnus. If I remember = it correctly he considers SRTP a profile of RTP. Since I don=92t wanted = to just use RTP, I ended up with (S)RTP based on a discussion with = Magnus. >>>=20 >>> However, I=92m fine with changing it to SRTP... >>=20 >> SRTP is an RTP profile. My comment was that if this is for WebRTC = only, then only SRTP can be used, and not plain RTP. Using =93(S)RTP=94 = rather than =93SRTP=94 in this draft suggests that the secure profile is = optional, which isn=92t the case in WebRTC. If this is for more general = use than WebRTC, then =93(S)RTP=94 is fine. > It is clear that in WebRTC only SRTP is used... I don=92t believe your draft is clear on that, due to the use of = =93(S)RTP=94 terminology. That=92s why I commented. --=20 Colin Perkins http://csperkins.org/ From nobody Wed Apr 9 07:47:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71ED1A030F for ; Wed, 9 Apr 2014 07:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] autolearn=ham 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 wamJ2gbiKxdk for ; Wed, 9 Apr 2014 07:47:09 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 640DC1A0299 for ; Wed, 9 Apr 2014 07:47:09 -0700 (PDT) Received: from [192.168.1.103] (p508F0BDC.dip0.t-ipconnect.de [80.143.11.220]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 817ED1C10464D; Wed, 9 Apr 2014 16:47:07 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <73C21E05-E36C-4899-98A4-9D762B75FCE4@csperkins.org> Date: Wed, 9 Apr 2014 16:47:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C2B5FD8-D9A8-4889-8483-046B4ACC75EC@lurchi.franken.de> References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <02F2BCF4-70B5-47A4-ACE6-C0CCCAB11A50@csperkins.org> <9889BAD9-D9A7-42F2-A0DC-632C26696345@lurchi.franken.de> <73C21E05-E36C-4899-98A4-9D762B75FCE4@csperkins.org> To: Colin Perkins , Magnus Westerlund X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4vrtfJ0BiVzdM9P5FITTC41-dto Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:47:21 -0000 On 09 Apr 2014, at 16:39, Colin Perkins wrote: > On 9 Apr 2014, at 15:33, Michael Tuexen = wrote: >> On 09 Apr 2014, at 16:25, Colin Perkins wrote: >>> On 9 Apr 2014, at 15:20, Michael Tuexen = wrote: >>>> On 09 Apr 2014, at 13:00, Colin Perkins wrote: >>>>> On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>> This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >>>>>>=20 >>>>>> Title : WebRTC Data Channels >>>>>> Authors : Randell Jesup >>>>>> Salvatore Loreto >>>>>> Michael Tuexen >>>>>> Filename : draft-ietf-rtcweb-data-channel-08.txt >>>>>> Pages : 15 >>>>>> Date : 2014-04-09 >>>>>>=20 >>>>>> Abstract: >>>>>> The Real-Time Communication in WEB-browsers working group is = charged >>>>>> to provide protocol support for direct interactive rich = communication >>>>>> using audio, video, and data between two peers' web-browsers. = This >>>>>> document specifies the non-(S)RTP media data transport aspects of = the >>>>>> WebRTC framework. It provides an architectural overview of how = the >>>>>> Stream Control Transmission Protocol (SCTP) is used in the WebRTC >>>>>> context as a generic transport service allowing WEB-browsers to >>>>>> exchange generic data from peer to peer. >>>>>=20 >>>>> This talks about =93(S)RTP=94 throughout, but the rtp-usage draft = requires that SRTP be used for WebRTC, and disallows plain RTP. I think = this draft could be simplified by changing =93(S)RTP=94 to =93SRTP=94 = throughout. >>>> Hi Colin, >>>>=20 >>>> The (S)RTP notion goes back to a comment from Magnus. If I remember = it correctly he considers SRTP a profile of RTP. Since I don=92t wanted = to just use RTP, I ended up with (S)RTP based on a discussion with = Magnus. >>>>=20 >>>> However, I=92m fine with changing it to SRTP... >>>=20 >>> SRTP is an RTP profile. My comment was that if this is for WebRTC = only, then only SRTP can be used, and not plain RTP. Using =93(S)RTP=94 = rather than =93SRTP=94 in this draft suggests that the secure profile is = optional, which isn=92t the case in WebRTC. If this is for more general = use than WebRTC, then =93(S)RTP=94 is fine. >> It is clear that in WebRTC only SRTP is used... >=20 > I don=92t believe your draft is clear on that, due to the use of = =93(S)RTP=94 terminology. That=92s why I commented. I'm happy to change it to SRTP... Let's see what Magnus thinks... Best regards Michael >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 >=20 From nobody Wed Apr 9 08:02:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F0E1A030F for ; Wed, 9 Apr 2014 08:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 4FplBGlv3IJ9 for ; Wed, 9 Apr 2014 08:02:02 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1D71A02C5 for ; Wed, 9 Apr 2014 08:01:54 -0700 (PDT) X-AuditID: c1b4fb32-b7fe98e0000034f3-30-534560e13733 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id CD.DF.13555.1E065435; Wed, 9 Apr 2014 17:01:53 +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.174.1; Wed, 9 Apr 2014 17:01:05 +0200 Message-ID: <534560B1.2050900@ericsson.com> Date: Wed, 9 Apr 2014 17:01:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Tuexen , Colin Perkins References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <02F2BCF4-70B5-47A4-ACE6-C0CCCAB11A50@csperkins.org> <9889BAD9-D9A7-42F2-A0DC-632C26696345@lurchi.franken.de> <73C21E05-E36C-4899-98A4-9D762B75FCE4@csperkins.org> <6C2B5FD8-D9A8-4889-8483-046B4ACC75EC@lurchi.franken.de> In-Reply-To: <6C2B5FD8-D9A8-4889-8483-046B4ACC75EC@lurchi.franken.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvje7DBNdgg4uLzSyWvzzBaHGxaQmj xdp/7ewOzB7T7t9n81iy5CeTx4aWHUwBzFFcNimpOZllqUX6dglcGVO+P2Qv2ClV8fjuYbYG xkbRLkZODgkBE4n9c66wQdhiEhfurQeyuTiEBE4ySkztnsoO4SxjlFh18hEzSBWvgLbEs/cX 2EFsFgEViR8tb1hBbDYBC4mbPxrBJokKBEssnbOYBaJeUOLkzCdANgeHiECUxNwbWSBhZgFR iVcPp4CNFBZwlzj6fDnUri5miQsND8Dmcwq4Srw+tIUNpFdCQFyipzEIotdA4siiOawQtrxE 89bZYHOEgE5raOpgncAoNAvJ5llIWmYhaVnAyLyKUbI4tbg4N93IQC83PbdEL7UoM7m4OD9P rzh1EyMwxA9u+W20g/HkHvtDjNIcLErivNdZa4KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MLaW/9ghWXhddYJpkNbH748dN9x0Yv6TxvfmplDzTiZW0TkFL6+yFJYqzlv5/93544s8OwNe tYYf/TJ1fVlx373ak6/8Zp9VduQXcV/w55efpfjiO3qPvNJXHXtSy3Iy22zGUXXT2YeP3zuu En9dTntBhdAXhlfnD0zc6+PdzGAlrHVzM6N6gooSS3FGoqEWc1FxIgCUnz6NPwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cyIrOM_2tsCFm88z-vaILii2tVI Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:02:06 -0000 On 2014-04-09 16:47, Michael Tuexen wrote: > > On 09 Apr 2014, at 16:39, Colin Perkins wrote: > >> On 9 Apr 2014, at 15:33, Michael Tuexen wrote: >>> On 09 Apr 2014, at 16:25, Colin Perkins wrote: >>>> On 9 Apr 2014, at 15:20, Michael Tuexen wrote: >>>>> On 09 Apr 2014, at 13:00, Colin Perkins wrote: >>>>>> On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>>> This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. >>>>>>> >>>>>>> Title : WebRTC Data Channels >>>>>>> Authors : Randell Jesup >>>>>>> Salvatore Loreto >>>>>>> Michael Tuexen >>>>>>> Filename : draft-ietf-rtcweb-data-channel-08.txt >>>>>>> Pages : 15 >>>>>>> Date : 2014-04-09 >>>>>>> >>>>>>> Abstract: >>>>>>> The Real-Time Communication in WEB-browsers working group is charged >>>>>>> to provide protocol support for direct interactive rich communication >>>>>>> using audio, video, and data between two peers' web-browsers. This >>>>>>> document specifies the non-(S)RTP media data transport aspects of the >>>>>>> WebRTC framework. It provides an architectural overview of how the >>>>>>> Stream Control Transmission Protocol (SCTP) is used in the WebRTC >>>>>>> context as a generic transport service allowing WEB-browsers to >>>>>>> exchange generic data from peer to peer. >>>>>> >>>>>> This talks about “(S)RTP” throughout, but the rtp-usage draft requires that SRTP be used for WebRTC, and disallows plain RTP. I think this draft could be simplified by changing “(S)RTP” to “SRTP” throughout. >>>>> Hi Colin, >>>>> >>>>> The (S)RTP notion goes back to a comment from Magnus. If I remember it correctly he considers SRTP a profile of RTP. Since I don’t wanted to just use RTP, I ended up with (S)RTP based on a discussion with Magnus. >>>>> >>>>> However, I’m fine with changing it to SRTP... >>>> >>>> SRTP is an RTP profile. My comment was that if this is for WebRTC only, then only SRTP can be used, and not plain RTP. Using “(S)RTP” rather than “SRTP” in this draft suggests that the secure profile is optional, which isn’t the case in WebRTC. If this is for more general use than WebRTC, then “(S)RTP” is fine. >>> It is clear that in WebRTC only SRTP is used... >> >> I don’t believe your draft is clear on that, due to the use of “(S)RTP” terminology. That’s why I commented. > I'm happy to change it to SRTP... Let's see what Magnus thinks... I am fine with that! /Magnus > > Best regards > Michael >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> >> >> > > > -- 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 9 08:10:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6DE1A02C6 for ; Wed, 9 Apr 2014 08:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] autolearn=ham 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 x6PiJKduruUH for ; Wed, 9 Apr 2014 08:10:34 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5BE1A0298 for ; Wed, 9 Apr 2014 08:10:34 -0700 (PDT) Received: from [192.168.1.103] (p508F0BDC.dip0.t-ipconnect.de [80.143.11.220]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 260211C1047FB; Wed, 9 Apr 2014 17:10:32 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <534560B1.2050900@ericsson.com> Date: Wed, 9 Apr 2014 17:10:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A39482B-5DF0-492E-8CCB-D2E507000816@lurchi.franken.de> References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <02F2BCF4-70B5-47A4-ACE6-C0CCCAB11A50@csperkins.org> <9889BAD9-D9A7-42F2-A0DC-632C26696345@lurchi.franken.de> <73C21E05-E36C-4899-98A4-9D762B75FCE4@csperkins.org> <6C2B5FD8-D9A8-4889-8483-046B4ACC75EC@lurchi.franken.de> <534560B1.2050900@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NYdLwL22oPEfj8fq9LtMkj1oIXI Cc: rtcweb@ietf.org, Colin Perkins Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:10:40 -0000 On 09 Apr 2014, at 17:01, Magnus Westerlund = wrote: > On 2014-04-09 16:47, Michael Tuexen wrote: >>=20 >> On 09 Apr 2014, at 16:39, Colin Perkins wrote: >>=20 >>> On 9 Apr 2014, at 15:33, Michael Tuexen = wrote: >>>> On 09 Apr 2014, at 16:25, Colin Perkins wrote: >>>>> On 9 Apr 2014, at 15:20, Michael Tuexen = wrote: >>>>>> On 09 Apr 2014, at 13:00, Colin Perkins = wrote: >>>>>>> On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >>>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>> This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >>>>>>>>=20 >>>>>>>> Title : WebRTC Data Channels >>>>>>>> Authors : Randell Jesup >>>>>>>> Salvatore Loreto >>>>>>>> Michael Tuexen >>>>>>>> Filename : draft-ietf-rtcweb-data-channel-08.txt >>>>>>>> Pages : 15 >>>>>>>> Date : 2014-04-09 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> The Real-Time Communication in WEB-browsers working group is = charged >>>>>>>> to provide protocol support for direct interactive rich = communication >>>>>>>> using audio, video, and data between two peers' web-browsers. = This >>>>>>>> document specifies the non-(S)RTP media data transport aspects = of the >>>>>>>> WebRTC framework. It provides an architectural overview of how = the >>>>>>>> Stream Control Transmission Protocol (SCTP) is used in the = WebRTC >>>>>>>> context as a generic transport service allowing WEB-browsers to >>>>>>>> exchange generic data from peer to peer. >>>>>>>=20 >>>>>>> This talks about =93(S)RTP=94 throughout, but the rtp-usage = draft requires that SRTP be used for WebRTC, and disallows plain RTP. I = think this draft could be simplified by changing =93(S)RTP=94 to =93SRTP=94= throughout. >>>>>> Hi Colin, >>>>>>=20 >>>>>> The (S)RTP notion goes back to a comment from Magnus. If I = remember it correctly he considers SRTP a profile of RTP. Since I don=92t = wanted to just use RTP, I ended up with (S)RTP based on a discussion = with Magnus. >>>>>>=20 >>>>>> However, I=92m fine with changing it to SRTP... >>>>>=20 >>>>> SRTP is an RTP profile. My comment was that if this is for WebRTC = only, then only SRTP can be used, and not plain RTP. Using =93(S)RTP=94 = rather than =93SRTP=94 in this draft suggests that the secure profile is = optional, which isn=92t the case in WebRTC. If this is for more general = use than WebRTC, then =93(S)RTP=94 is fine. >>>> It is clear that in WebRTC only SRTP is used... >>>=20 >>> I don=92t believe your draft is clear on that, due to the use of = =93(S)RTP=94 terminology. That=92s why I commented. >> I'm happy to change it to SRTP... Let's see what Magnus thinks... >=20 > I am fine with that! OK. Next revision used SRTP. Best regards Michael >=20 > /Magnus >=20 >>=20 >> Best regards >> Michael >>>=20 >>> --=20 >>> Colin Perkins >>> http://csperkins.org/ >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 From nobody Wed Apr 9 11:09:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C147B1A0303 for ; Wed, 9 Apr 2014 11:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 3tPwpRLlL1KK for ; Wed, 9 Apr 2014 11:09:25 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2F49A1A03FD for ; Wed, 9 Apr 2014 11:09:21 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so2842239wgg.6 for ; Wed, 09 Apr 2014 11:09:20 -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 :content-type; bh=TnYfqNC+T9PXIkuCu1fbnAFfq7jd4fq+nsamdNO2Sws=; b=tw0uL74oCD0JJBSgV5pwDPDt0I1zTHrUfFdiewNJNbBdir6K12Pfyo6HuKwuN56tge xTEG7yjDmF8ngmMjsUX5oSfC/aR8OLdKA4mOAdEZ0Mrfj/241JgZRVok6LguSE6cJ0JI vLZ8XhnLsKIMs2eAYvWn3lawi6C5+v0UWmLX3TM/4YChjI+08yrs8CYssiEinqvpMy10 oCycI+3kecaFmqZybbhKk+3NwrKgZR6OlhR7Rzro31KJ9mKW63Tm49nuOHE7e1dOpvo4 EQQ9DCYqV9y1My1WzlQH5qdMYVcQxnFBcDQQ3CFduvJH+bRd5Wok7ObBk73662ywssq0 IAkw== MIME-Version: 1.0 X-Received: by 10.194.192.132 with SMTP id hg4mr11078536wjc.28.1397066960049; Wed, 09 Apr 2014 11:09:20 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 11:09:20 -0700 (PDT) In-Reply-To: <20140409180350.13315.51677.idtracker@ietfa.amsl.com> References: <20140409180350.13315.51677.idtracker@ietfa.amsl.com> Date: Wed, 9 Apr 2014 11:09:20 -0700 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8hF64wtCHxjCdHEH14o_wFKpmnk Subject: [rtcweb] Fwd: New Version Notification for draft-thomson-rtcweb-alpn-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 18:09:26 -0000 The intent of this draft is to address the isolation issue. Unlike a TLS extension, this doesn't require that the TLS WG provide an official blessing. Though I'll note that this is the advice that at least two participants in that working group suggested for addressing this problem. In short: negotiate "webrtc" if you are doing the usual, insecure thing; negotiate "c-webrtc" if you would like media confidentiality. >> A new version of I-D, draft-thomson-rtcweb-alpn-00.txt has been successfully submitted by Martin Thomson and posted to the IETF repository. Name: draft-thomson-rtcweb-alpn Revision: 00 Title: Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC) Document date: 2014-04-09 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-thomson-rtcweb-alpn-00.txt Status: https://datatracker.ietf.org/doc/draft-thomson-rtcweb-alpn/ Htmlized: http://tools.ietf.org/html/draft-thomson-rtcweb-alpn-00 Abstract: Application Layer Protocol Negotiation (ALPN) labels are defined for use in identifying Web Real-Time Communications (WebRTC) usages of Datagram Transport Layer Security (DTLS). Labels are provided for identifying a session that uses a combination of WebRTC compatible media and data, and for identifying a session requiring confidentiality protection. From nobody Wed Apr 9 11:38:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763AE1A042E for ; Wed, 9 Apr 2014 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 p0P4Qa5en7SZ for ; Wed, 9 Apr 2014 11:37:58 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C59311A0432 for ; Wed, 9 Apr 2014 11:37:57 -0700 (PDT) X-AuditID: c1b4fb38-b7f518e000000889-6e-53459384ed14 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id BB.A4.02185.48395435; Wed, 9 Apr 2014 20:37:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 20:37:55 +0200 From: Christer Holmberg To: Michael Tuexen , Magnus Westerlund Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt Thread-Index: AQHPU9r8wvMWA0Q1K0mIC9kJW7dm+ZsI/KmAgAA33gCAAAFBgIAAAmyAgAABogCAAAIUAIAAA+iAgAACo4CAAGvhgA== Date: Wed, 9 Apr 2014 18:37:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2BA437@ESESSMB209.ericsson.se> References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <02F2BCF4-70B5-47A4-ACE6-C0CCCAB11A50@csperkins.org> <9889BAD9-D9A7-42F2-A0DC-632C26696345@lurchi.franken.de> <73C21E05-E36C-4899-98A4-9D762B75FCE4@csperkins.org> <6C2B5FD8-D9A8-4889-8483-046B4ACC75EC@lurchi.franken.de> <534560B1.2050900@ericsson.com> <2A39482B-5DF0-492E-8CCB-D2E507000816@lurchi.franken.de> In-Reply-To: <2A39482B-5DF0-492E-8CCB-D2E507000816@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW7LZNdgg6+tkhbLX55gtLjYtITR Yu2/dnYHZo9p9++zeSxZ8pPJY0PLDqYA5igum5TUnMyy1CJ9uwSujJdn/ArmKlXcfZHZwHhY uouRk0NCwETix+EuZghbTOLCvfVsXYxcHEICRxkldr78wAThLGaUaGtYztrFyMHBJmAh0f1P G6RBRCBb4sjhlywgNrOAl8TDb2fYQEqEBdwlev7FQpR4SMz4BNIJYmdJnFizG6ycRUBF4uzj N+wgNq+Ar8T1Q+ugVn1mltj/7iYjSIJTwFVi1f3ZYMcxAh33/dQaJohd4hK3nsxngjhaQGLJ nvNQD4hKvHz8jxXCVpJYdPszVL2exI2pU9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMXIUpxYn5aYbGWxiBEbNwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2MgTsNFG5VWD6Ozp0od2Jqgv1OkcQ9bH8NbOt+cIsVbSg8cdY1 /rP26+xaTpdFf1MiFrSnXbC2sn6eblzpWDhFYXuwNUvxRr4tj4/MOdGmVcMxaZrF2e3MObfL LYKfJ1gxGk4oa+Q++szh1Yy4/XEaTyzf3liePfH7vJlvpnnwC6umdT/qj7BUYinOSDTUYi4q TgQAE6ofXmgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/znilnsAGunMBhlHIdjKSrGHBQGM Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 18:38:02 -0000 Hi, If you want to describe the WebRTC usage, I'm fine using SRTP. But, again, as there are other usages of the data channel than WebRTC, the = generic text should not talk about only SRTP. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Michael Tuexen Sent: 09 April 2014 18:11 To: Magnus Westerlund Cc: rtcweb@ietf.org; Colin Perkins Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt On 09 Apr 2014, at 17:01, Magnus Westerlund wrote: > On 2014-04-09 16:47, Michael Tuexen wrote: >>=20 >> On 09 Apr 2014, at 16:39, Colin Perkins wrote: >>=20 >>> On 9 Apr 2014, at 15:33, Michael Tuexen wrote: >>>> On 09 Apr 2014, at 16:25, Colin Perkins wrote: >>>>> On 9 Apr 2014, at 15:20, Michael Tuexen wrote: >>>>>> On 09 Apr 2014, at 13:00, Colin Perkins wrote: >>>>>>> On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts= directories. >>>>>>>> This draft is a work item of the Real-Time Communication in WEB-br= owsers Working Group of the IETF. >>>>>>>>=20 >>>>>>>> Title : WebRTC Data Channels >>>>>>>> Authors : Randell Jesup >>>>>>>> Salvatore Loreto >>>>>>>> Michael Tuexen >>>>>>>> Filename : draft-ietf-rtcweb-data-channel-08.txt >>>>>>>> Pages : 15 >>>>>>>> Date : 2014-04-09 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> The Real-Time Communication in WEB-browsers working group is=20 >>>>>>>> charged to provide protocol support for direct interactive rich=20 >>>>>>>> communication using audio, video, and data between two peers'=20 >>>>>>>> web-browsers. This document specifies the non-(S)RTP media=20 >>>>>>>> data transport aspects of the WebRTC framework. It provides an=20 >>>>>>>> architectural overview of how the Stream Control Transmission=20 >>>>>>>> Protocol (SCTP) is used in the WebRTC context as a generic=20 >>>>>>>> transport service allowing WEB-browsers to exchange generic data f= rom peer to peer. >>>>>>>=20 >>>>>>> This talks about "(S)RTP" throughout, but the rtp-usage draft requi= res that SRTP be used for WebRTC, and disallows plain RTP. I think this dra= ft could be simplified by changing "(S)RTP" to "SRTP" throughout. >>>>>> Hi Colin, >>>>>>=20 >>>>>> The (S)RTP notion goes back to a comment from Magnus. If I remember = it correctly he considers SRTP a profile of RTP. Since I don't wanted to ju= st use RTP, I ended up with (S)RTP based on a discussion with Magnus. >>>>>>=20 >>>>>> However, I'm fine with changing it to SRTP... >>>>>=20 >>>>> SRTP is an RTP profile. My comment was that if this is for WebRTC onl= y, then only SRTP can be used, and not plain RTP. Using "(S)RTP" rather th= an "SRTP" in this draft suggests that the secure profile is optional, which= isn't the case in WebRTC. If this is for more general use than WebRTC, the= n "(S)RTP" is fine. >>>> It is clear that in WebRTC only SRTP is used... >>>=20 >>> I don't believe your draft is clear on that, due to the use of "(S)RTP"= terminology. That's why I commented. >> I'm happy to change it to SRTP... Let's see what Magnus thinks... >=20 > I am fine with that! OK. Next revision used SRTP. Best regards Michael >=20 > /Magnus >=20 >>=20 >> Best regards >> Michael >>>=20 >>> -- >>> Colin Perkins >>> http://csperkins.org/ >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Apr 9 12:13:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675111A0205 for ; Wed, 9 Apr 2014 12:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 2xAlvVsit2DK for ; Wed, 9 Apr 2014 12:13:00 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 579191A02F5 for ; Wed, 9 Apr 2014 12:13:00 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta04.westchester.pa.mail.comcast.net with comcast id ntqN1n0050vyq2s54vCzCm; Wed, 09 Apr 2014 19:12:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id nvCz1n00M3ZTu2S3RvCz6N; Wed, 09 Apr 2014 19:12:59 +0000 Message-ID: <53459BBB.1080505@alum.mit.edu> Date: Wed, 09 Apr 2014 15:12:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140409180350.13315.51677.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397070779; bh=DtgiS47sOBc5PY+ZyXvTLoawA8+UU57JTVFeI/v5PcE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gbyHBIWEbBT7u+roWLQSXMcwVzVeSW970K96zoJRtiPP0Twjt67jynF/eysND8aXw 2w6r2uo9sx/zb0YZWO7rjbRAQ/tD3NqNMmFcURFMMKoCrxuKnSr7tHoiYj6PnF3hwG GvnzpANprh3K5q0AqAEwJP21NR4Rwccv09oFUE3iXUw1WSXAqMBQ/koqgH6NxlZXaK VNR1txcMmg2KGBXAYSRX5122mxkI3Enx7kN49fnCktLsKs/R08Hwwf98QZoGuOa0ca l6R+w4dv2kSH70xeGWV5i0i4ySa/WFvBUfjMvkO9xUMxngqbXB/UUSnhWYfgKG2try z2GaBNlbTqC0Q== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iM85ieNfeqyuksMZqutQACfa9OU Subject: Re: [rtcweb] Fwd: New Version Notification for draft-thomson-rtcweb-alpn-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:13:01 -0000 If you propose to use ALPN for this, then "webrtc" and "c-webrtc" must be Application Level Protocols - presumably *different* protocols. But what is the *protocol*? I don't see that mentioned in the draft at all. IIUC it must be the multiplexing of STUN, SRTP, and SCTP over DTLS. (Maybe not STUN - maybe that is *below* or *beside* DTLS.) I see how it could make sense to use ALPN to verify that this is the intended use of the DTLS session. But that isn't even mentioned in the draft. And, from a protocol perspective, what is the difference between webrtc and c-webrtc? AFAICT this is just two different usages of the same "protocol", not two different protocols. Thanks, Paul On 4/9/14 2:09 PM, Martin Thomson wrote: > The intent of this draft is to address the isolation issue. > > Unlike a TLS extension, this doesn't require that the TLS WG provide > an official blessing. Though I'll note that this is the advice that > at least two participants in that working group suggested for > addressing this problem. > > In short: negotiate "webrtc" if you are doing the usual, insecure > thing; negotiate "c-webrtc" if you would like media confidentiality. > >>> > A new version of I-D, draft-thomson-rtcweb-alpn-00.txt > has been successfully submitted by Martin Thomson and posted to the > IETF repository. > > Name: draft-thomson-rtcweb-alpn > Revision: 00 > Title: Application Layer Protocol Negotiation for Web > Real-Time Communications (WebRTC) > Document date: 2014-04-09 > Group: Individual Submission > Pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-thomson-rtcweb-alpn-00.txt > Status: https://datatracker.ietf.org/doc/draft-thomson-rtcweb-alpn/ > Htmlized: http://tools.ietf.org/html/draft-thomson-rtcweb-alpn-00 > > > Abstract: > Application Layer Protocol Negotiation (ALPN) labels are defined for > use in identifying Web Real-Time Communications (WebRTC) usages of > Datagram Transport Layer Security (DTLS). Labels are provided for > identifying a session that uses a combination of WebRTC compatible > media and data, and for identifying a session requiring > confidentiality protection. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Wed Apr 9 12:52:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D671A043B for ; Wed, 9 Apr 2014 12:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 k0ZhQ8VdDqUX for ; Wed, 9 Apr 2014 12:52:43 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB621A03E6 for ; Wed, 9 Apr 2014 12:52:43 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so10062862wib.5 for ; Wed, 09 Apr 2014 12:52:42 -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:content-type; bh=cZrYAiph2nbcxfNc4O0W9F3A/lzq9kpimYXkcI7jU2o=; b=M+XYdYI0xUWCC4r5sdPETGcier51UBVenkjMLLWwR+iF6BiCG3OFbhR4yAqc/wBWAf RHC1MxEs1hyYWw253AmMvXKXxO+jkQcZmJpX+tFZmrZ1eyPl1ba92SAtunELKDYsEqXZ WtbDqHk6u6Tft2PgjxFszFLb3z8j8f4vpBKY8VaEE9tTB27inY6zkEZfgQ3Pvf6Vtpdo Ngwxcdtgy4REkzz/qC1M7nybgMu+6AeSEhp/FmNxgTlCp8v8rGDDNSjmhiEPPPC4ig31 +Tnow919Kd9auZ3/W/5s9p8ic5Fv8gc8urESYgMyJNNDIOTbgo66+yTDZyAjPthfTeGu d9Mw== MIME-Version: 1.0 X-Received: by 10.180.89.211 with SMTP id bq19mr38714126wib.58.1397073162439; Wed, 09 Apr 2014 12:52:42 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 12:52:42 -0700 (PDT) In-Reply-To: <53459BBB.1080505@alum.mit.edu> References: <20140409180350.13315.51677.idtracker@ietfa.amsl.com> <53459BBB.1080505@alum.mit.edu> Date: Wed, 9 Apr 2014 12:52:42 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4i-8QAigTYooBHX8Kn4Xf2jGrU8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-thomson-rtcweb-alpn-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:52:45 -0000 On 9 April 2014 12:12, Paul Kyzivat wrote: > But what is the *protocol*? I don't see that mentioned in the draft at all. There are two. Those two are described (perhaps not explicitly enough) in the list in Section 2. > IIUC it must be the multiplexing of STUN, SRTP, and SCTP over DTLS. (Maybe > not STUN - maybe that is *below* or *beside* DTLS.) I see how it could make > sense to use ALPN to verify that this is the intended use of the DTLS > session. But that isn't even mentioned in the draft. Yeah, STUN isn't inside DTLS, so it doesn't make a lot of sense to "negotiate" its use. > And, from a protocol perspective, what is the difference between webrtc and > c-webrtc? AFAICT this is just two different usages of the same "protocol", > not two different protocols. Yep. But that's what a protocol is. From nobody Wed Apr 9 13:56:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E81A0089 for ; Wed, 9 Apr 2014 13:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 AlfXd3HdgzAE for ; Wed, 9 Apr 2014 13:56:13 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id C05171A023F for ; Wed, 9 Apr 2014 13:56:12 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id nsEp1n0041c6gX858wwCAz; Wed, 09 Apr 2014 20:56:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id nwwB1n00v3ZTu2S3jwwB0b; Wed, 09 Apr 2014 20:56:12 +0000 Message-ID: <5345B3EB.4050108@alum.mit.edu> Date: Wed, 09 Apr 2014 16:56:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Martin Thomson References: <20140409180350.13315.51677.idtracker@ietfa.amsl.com> <53459BBB.1080505@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397076972; bh=jG0LDdqj3rZl/7oP0uHcPOjn91o0o4KbiA+KdTbHutw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UIvpnnh/ljTdXYdGsO0gaoKrrzbwojQ/iNoPou8r8Nsa0NqlkdSH9Bl9ROzypmekl UTi492bGROkL+ZXgvPzTUrBUVsFvgqZRwkVmw5pw2p945VNy3jM+imnNA0CQ+l8Bvf OsQfVzm3pNVrp7M1otNgK23KJlk8Dv4GjBwRbJcgL0AN/H54d7YOyOnVjik+HE0+gM 5AfHlzgDyPpngu9RAGgu7zlMgN5aB/aOZlGicsDE39PIpQ/Ovl49owFvx1BnqD0NDS p3XW3+kpuhr0LiMGvCKETHNT45gxSjDBBxJziAj53UXg97JF6BfwFtGDRYFWjY7BPh bYnfeX+W1A4gg== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VthYbEChmExChtWgKDno5T5tDaE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-thomson-rtcweb-alpn-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:56:14 -0000 On 4/9/14 3:52 PM, Martin Thomson wrote: > On 9 April 2014 12:12, Paul Kyzivat wrote: >> But what is the *protocol*? I don't see that mentioned in the draft at all. > > There are two. Those two are described (perhaps not explicitly > enough) in the list in Section 2. Not explicitly enough, IMO. >> IIUC it must be the multiplexing of STUN, SRTP, and SCTP over DTLS. (Maybe >> not STUN - maybe that is *below* or *beside* DTLS.) I see how it could make >> sense to use ALPN to verify that this is the intended use of the DTLS >> session. But that isn't even mentioned in the draft. > > Yeah, STUN isn't inside DTLS, so it doesn't make a lot of sense to > "negotiate" its use. > >> And, from a protocol perspective, what is the difference between webrtc and >> c-webrtc? AFAICT this is just two different usages of the same "protocol", >> not two different protocols. > > Yep. But that's what a protocol is. Not in my book. I expect two different protocols to look different on the wire. You seem to be saying that SMTP used to talk to ietf mailing lists is a different protocol from SMTP used to talk to my lawyer, because I expect my lawyer to keep the communications confidential. Thanks, Paul From nobody Wed Apr 9 14:26:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CD21A031C for ; Wed, 9 Apr 2014 14:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 4TYMrBsPqpXl for ; Wed, 9 Apr 2014 14:25:55 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 262DD1A02C6 for ; Wed, 9 Apr 2014 14:25:54 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so3038167wes.37 for ; Wed, 09 Apr 2014 14:25:54 -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:content-type; bh=7yKHYJLu27gfOaUxs7LLVVFMbOq9IGbozgl37uLMsmA=; b=cPvWmCX6cm3yJZMSpEcU+Epbxr6tSRy8t++HGcuTtDDc5IFw5Hx3Z3YMqQwL6jlbYY y4DSsgLIrNuoA1ZUlBksoqugGbUPlBZYfxY2uE0a65yfxud8BofODM7Jfv9+HaFfVG48 77+0IYSN8wTUX3gF4GLHNJUVzyI8JpCeo0aAGV2yr3H6OL4VOchisveSeS1DmFwvzyoj ZfbBgsZV6sTirfxPP+K7sdCvMpaTKQ330KelWKxWpMMBFerFxFr7AfktCFBHEyEpF7Xa 0SKPQa7C+v547DytZzAyuk052DaDazAgkQ41MTbDD6o0kcqkUyz4r3zWPneG6lJCyK97 iPLg== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr39431763wiw.50.1397078754038; Wed, 09 Apr 2014 14:25:54 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 14:25:53 -0700 (PDT) In-Reply-To: <5345B3EB.4050108@alum.mit.edu> References: <20140409180350.13315.51677.idtracker@ietfa.amsl.com> <53459BBB.1080505@alum.mit.edu> <5345B3EB.4050108@alum.mit.edu> Date: Wed, 9 Apr 2014 14:25:53 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xagEoiUV7tk3adr2ZP6clmLKUuA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-thomson-rtcweb-alpn-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 21:25:57 -0000 On 9 April 2014 13:56, Paul Kyzivat wrote: > I expect two different protocols to look different on the wire. > > You seem to be saying that SMTP used to talk to ietf mailing lists is a > different protocol from SMTP used to talk to my lawyer, because I expect my > lawyer to keep the communications confidential. They are different on the wire. They use different identifiers. That's hair splitting, but there's a real difference between the two usages. And I think that it's important enough to do this. Do you perhaps have an alternative, or is it just that this lack of solidity is giving you heartburn? Because I can appreciate that. From nobody Wed Apr 9 14:41:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F1D1A0321 for ; Wed, 9 Apr 2014 14:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 h3MgduWuWJNn for ; Wed, 9 Apr 2014 14:41:26 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1F31A031C for ; Wed, 9 Apr 2014 14:41:26 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id lj1so3042592pab.34 for ; Wed, 09 Apr 2014 14:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:from:mime-version:subject :message-id:date:cc:to; bh=klpwXKJ8l/KqMYbwI7nBRQOrotvKD7IpvEWHnQ5fnOA=; b=ZJvoQgEvitio0J+bCL+cPeVpsEaXuvzu0vEk7iBHhy7vsnWVYkdPlSJ5P9qTGUOVWm Ugj01+z2uhlDoUhrzI7EJ1rHAJuognO4Pc8aKslsNXQgMTYcok7QTIjZvWgKFgXxnxRH lg4szULEAs9pH/HLdTVOGbKl939cFtk120xqm7yPMerjA9YS2IeSCpefWNXfBeGCar1+ RRKnfLc58gouqffypd/xdFNXVZw6SCr8jZsKVUrW9TVNwDVYeynvoO0LVhGVgy8Q7QPe FV7PElEnsofUNX3i8JRx2Des/9jXFulLY0pvtX8IzrSZnmQrMJXKc+E18OBBHXUV/Reu uRvA== X-Received: by 10.69.26.103 with SMTP id ix7mr14931332pbd.41.1397079684614; Wed, 09 Apr 2014 14:41:24 -0700 (PDT) Received: from [10.81.46.135] ([131.107.147.124]) by mx.google.com with ESMTPSA id xr9sm10422405pab.5.2014.04.09.14.41.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 14:41:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Mime-Version: 1.0 (1.0) Message-Id: <2A1B1960-3951-43B7-971F-00BE68FBB40D@gmail.com> Date: Wed, 9 Apr 2014 14:11:49 -0700 To: Martin Thomson X-Mailer: iPad Mail (11D167) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/92hZ1imYLUGiBDI2a5t9mwKrvyY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-thomson-rtcweb-alpn-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 21:41:27 -0000 FWIW, I think the ALPN approach is an improvement, improving the likelihood o= f deployment.=20 From nobody Wed Apr 9 20:58:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A611A03F4 for ; Wed, 9 Apr 2014 20:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham 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 5pjurAd4WtT2 for ; Wed, 9 Apr 2014 20:58:29 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4A41A03E2 for ; Wed, 9 Apr 2014 20:58:28 -0700 (PDT) Received: from ppp118-209-252-214.lns20.mel6.internode.on.net ([118.209.252.214]:57180 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WY685-0001qD-5G for rtcweb@ietf.org; Thu, 10 Apr 2014 13:58:21 +1000 Message-ID: <534616DC.7090800@nteczone.com> Date: Thu, 10 Apr 2014 13:58:20 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cLO2LR-4IjpNNTLAOZxFEVcIXnw Subject: [rtcweb] JSEP/WebRTC API Datachannel question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 03:58:33 -0000 Hello, I've looked into the JSEP draft and WebRTC API (as well as the datachannel and DCEP drafts) to get a better understanding of how and when the SDP for the DTLS/SCTP Web-RTCDataChannel will be generated and what will trigger the DCEP protocol. Unfortunately I find myself more confused after the process . I was trying to find some text regarding what happens in terms of SDP and DCEP when an endpoint uses multiple datachannels per peerConnection. e.g. pc = new RTCPeerConnection(configuration); channel = pc.createDataChannel("chat"); channel = pc.createDataChannel("clue"); Now based on the WebRTC API (http://dev.w3.org/2011/webrtc/editor/webrtc.html#peer-to-peer-data-api), I understand that a createOffer() is used to generate the required SDP for the data channel. This is also mentioned in Clause 5.2.1 "initial offers" draft-ietf-rtcweb-jsep-06 indicates: /"Lastly, if a data channel has been created, a m= section MUST be generated for data..."/ The WebRTC API cl.5.1.2 "createDataChannel" step 9 says /"Create channel's associated underlying data transport and configure it according to the relevant properties of channel."/ Now unfortunately it doesn't really say want this amounts to. Create could be "a new SCTP association" or it could be "using DCEP to do a DATA_CHANNEL_OPEN" or both. If I look at the RTCPeerConnection Interface for addStream I see that it indicates that a negotiationneeded event (WebRTC API cl.4.3.2.3 step 5) is fired. This is a trigger for the createOffer(). The example 10.1 WebRTC API shows this behavior. 10.3 also shows this behavior for createDataChannel but the Peer-to-Peer Data API doesn't indicate that the negotiationneeded event is triggered when establishing a data channel. I looked at the RTCDataChannel closure procedure to see if this would shed any more light but simply says that the underlying data transport may be torn down. The JSEP draft isn't any help here either as it doesn't talk about RTCDataChannel closure at all. So its not clear to me from the drafts/API whether: 1. each createDataChannel results in an offer with new m-line "webrtc-datachannel", 2. the first createDataChannel results in an SDP offer with m-line "webrtc-datachannel" and subsequent createDataChannels result in DCEP DATA_CHANNEL_OPENs on the existing webrtc-datachannel. 3. a mix of the above an endpoint can indicate multiple m-lines "webrtc-datachannel" and have multiple DCEP DATA_CHANNEL_OPENs per m-line. Its clear from draft-ietf-rtcweb-data-channel-07 that "Multiple simultaneous data channels MUST be supported in the peer connection" but that doesn't clarify the above. Is there any specification text that clarifies this? Regards, Christian From nobody Thu Apr 10 01:52:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05BD1A0049 for ; Thu, 10 Apr 2014 01:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 x9DtqGANRE_C for ; Thu, 10 Apr 2014 01:52:31 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3851A0169 for ; Thu, 10 Apr 2014 01:52:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 11C767C5197 for ; Thu, 10 Apr 2014 10:52:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFT19JM53rgM for ; Thu, 10 Apr 2014 10:52:29 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 386EF7C5191 for ; Thu, 10 Apr 2014 10:52:29 +0200 (CEST) Message-ID: <53465BCC.9030807@alvestrand.no> Date: Thu, 10 Apr 2014 10:52:28 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140409180350.13315.51677.idtracker@ietfa.amsl.com> <53459BBB.1080505@alum.mit.edu> <5345B3EB.4050108@alum.mit.edu> In-Reply-To: <5345B3EB.4050108@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7XjEa4KBgXAHmbkId-w1HLv4AuY Subject: Re: [rtcweb] Fwd: New Version Notification for draft-thomson-rtcweb-alpn-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 08:52:34 -0000 On 04/09/2014 10:56 PM, Paul Kyzivat wrote: > On 4/9/14 3:52 PM, Martin Thomson wrote: >> On 9 April 2014 12:12, Paul Kyzivat wrote: >>> But what is the *protocol*? I don't see that mentioned in the draft >>> at all. >> >> There are two. Those two are described (perhaps not explicitly >> enough) in the list in Section 2. > > Not explicitly enough, IMO. > >>> IIUC it must be the multiplexing of STUN, SRTP, and SCTP over DTLS. >>> (Maybe >>> not STUN - maybe that is *below* or *beside* DTLS.) I see how it >>> could make >>> sense to use ALPN to verify that this is the intended use of the DTLS >>> session. But that isn't even mentioned in the draft. >> >> Yeah, STUN isn't inside DTLS, so it doesn't make a lot of sense to >> "negotiate" its use. >> >>> And, from a protocol perspective, what is the difference between >>> webrtc and >>> c-webrtc? AFAICT this is just two different usages of the same >>> "protocol", >>> not two different protocols. >> >> Yep. But that's what a protocol is. > > Not in my book. I expect two different protocols to look different on > the wire. > > You seem to be saying that SMTP used to talk to ietf mailing lists is > a different protocol from SMTP used to talk to my lawyer, because I > expect my lawyer to keep the communications confidential. (not to be taken as a comment on the proposal, because I haven't read/understood it yet) an adequate parallel would be SMTP (used for MTA-to-MTA relay on port 25) and SUBMIT (used for message submission on port 587). They are identical on the wire (apart from an extension in the EHLO response), but have different purposes, and are therefore called different protocols. From nobody Thu Apr 10 01:56:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6EB1A016F for ; Thu, 10 Apr 2014 01:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 p96TveK8GYMJ for ; Thu, 10 Apr 2014 01:56:05 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 622511A0049 for ; Thu, 10 Apr 2014 01:56:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 15F177C5197 for ; Thu, 10 Apr 2014 10:56:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ag08uYmlTBo for ; Thu, 10 Apr 2014 10:56:03 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5748C7C5191 for ; Thu, 10 Apr 2014 10:56:03 +0200 (CEST) Message-ID: <53465CA2.4010607@alvestrand.no> Date: Thu, 10 Apr 2014 10:56:02 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <533F191D.8050109@alum.mit.edu> <53419ED4.8020102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RL9UBzwlM9AlwX8QRLuos4Kzab8 Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 08:56:06 -0000 On 04/08/2014 08:24 PM, Martin Thomson wrote: > On 8 April 2014 09:50, Bernard Aboba wrote: >> [BA] I'm not sure that the concept of "isolation" makes sense for those >> intermediaries (or to voicemail or an audio/video conference, for that >> matter). While in a point-to-point call it might be useful, in a >> conference the whole point is to have audio/video sent to multiple parties, >> and recording is commonplace. The problem is that from a protocol point of >> view the cases are not easily distinguishable -- and so if the browser >> insists on "isolation" then one wonders what will happen if the conference >> bridge/video MCU/voicemail system refuses to negotiate it. Refusing to >> send media would not be a desirable outcome. > I think that for this, it's perfectly reasonable to use identity, but > not stream isolation. With isolation, if the peer does not agree to > comply, then the session fails to complete. Actually I'd say it's "if the peer does not *agree to* comply". The protocol has no defense against liars, but that's a common issue. > > The authenticated party here is an MCU (or bridge, or voicemail, > etc...). Rather than sending to "anindividual@example.org", media is > sent to "mcu@example.com". Is it reasonable for that MCU to forward > media to other, unspecified entities? Clearly it can, but should it? > > (Not having thought it through completely, a voicemail box could > conceivably work. I think that I'd want to use a different identity > for it though.) I can see an use for a recording spec that said "you can record this, but only if you do it in such a way that it's only accessible to the stated identity". Would be weird to try to enforce that.... but I agree; MCU and isolation have a hard time mixing. Let's just not. From nobody Thu Apr 10 04:51:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5A01A0233 for ; Thu, 10 Apr 2014 04:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.877 X-Spam-Level: X-Spam-Status: No, score=0.877 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] autolearn=ham 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 Z0pAuEYOsxbf for ; Thu, 10 Apr 2014 04:50:59 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 4F48C1A0212 for ; Thu, 10 Apr 2014 04:50:58 -0700 (PDT) Received: from [192.168.1.103] (p508F23E9.dip0.t-ipconnect.de [80.143.35.233]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B90D91C0E9788; Thu, 10 Apr 2014 13:50:54 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <53160FBB.4070401@ericsson.com> Date: Thu, 10 Apr 2014 13:50:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1904CA30-1112-44D4-8C6F-F15F1EF1BF9B@lurchi.franken.de> References: <530B740E.4090707@ericsson.com> <53160FBB.4070401@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jo_GsjQc1D6Lm-H7UDZ_IuG-LMs Cc: draft-ietf-rtcweb-data-protocol@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 11:51:04 -0000 On 04 Mar 2014, at 17:39, Magnus Westerlund = wrote: > On 2014-02-25 17:07, Michael Tuexen wrote: >>=20 >> On Feb 24, 2014, at 5:32 PM, Magnus Westerlund = wrote: >>=20 >>> Hi, >>> (as individual) >> Hi Magnus, >>=20 >> thank you very much for the detailed review. Please see my comments = in-line. >>=20 >> Best regards >> Michael >>>=20 >>> I have reviewed the WebRTC Data Channel Establishment protocol >>> (draft-ietf-rtcweb-data-protocol-03) and have some comments: >>>=20 >>> 1. Section 4: >>> Shouldn't this section discuss the priority field? >> I added in the list of consistent properties: >>=20 >> the priority of the data Channel. >>=20 >> and in the text below that enumeration: >>=20 >> ?????? >=20 > Yes, text for this needs to be figured out. We don't define at this place what priority is. The only point is that = both sides use the same priority. >=20 >>>=20 >>> 2. Section 4: >>>=20 >>> The method >>> used to determine which side uses odd or even is based on the >>> underlying DTLS connection role when used in WebRTC, with the side >>> acting as the DTLS client using even stream identifiers. >>>=20 >>> Isn't this unnecessary using the vague word of WebRTC instead of = simply >>> pointing to the DTLS roles of the established data channel? >=20 >> The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and = therefore >> you can refer to the DTLS role. However, you could use DCEP/SCTP/IP >> or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS. >> In that case DTLS is not used and you can not refer to the DTLS role. >> That is why the restriction is used. >=20 > Ok, if that concern then you still should be able to write a normative > specification under the condition that it is SCTP over DTLS. If not = how > do you determine that? Are suggesting just to hand way or point to a > higher signaling layer. So what about using: when using , the = method used to determine which side uses odd or even is based on the underlying DTLS connection role: the side acting as the DTLS client MUST use Streams = with even SCTP stream identifiers, the side acting as the DTLS server MUST use = Streams with odd SCTP stream identifiers. >>>=20 >>> 3. Section 5.1: >>> DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel = provides >>> a partial reliable in-order bi-directional Communication >>> channel. User messages might not be transmitted or >>> retransmitted after a specified life-time given in milli- >>> seconds in the Reliability Parameter. This life-time starts >>> when providing the user message to the Javascript engine. >>>=20 >>> I think the use of "Javascript engine" in the last sentence is = unclear. >>> Can we provide a implementation neutral definition, like "This = life-time >>> starts when requesting transmission of the user message."? >=20 >> This comment was already made on the list and I changed the text to >>=20 >> This life-time starts when providing the user message to the protocol = stack. >>=20 >> OK? >=20 > Yes. >=20 >>>=20 >>> 4. Section 5.1: >>> Label: Variable Length (sequence of characters) >>> The name of the channel. This may be an empty string. >>>=20 >>> Protocol: Variable Length (sequence of characters) >>> The protocol for the channel. If this is an empty string the >>> protocol us unspecified. If it is an non-empty string, it >>> specifies an IANA-registered protocol (see Section 8.4). >>>=20 >>> Both of these fields are strings, shouldn't a particular encoding be >>> specified here? Like UTF-8. Secondly, what values are allowed, the = full >>> set of Unicode? >=20 >> You are right. Any need for restrictions? We only need to be able to >> transform it to a DomString. >> So I changed it to: >>=20 >> >> >> The name of the channel as a UTF-8 encoded string. >> This may be an empty string. >>=20 >> >> >> The protocol for the channel as a UTF-8 encoded string. >> If this is an empty string the protocol us unspecified. >> If it is an non-empty string, it specifies an IANA-registered = protocol >> (see ). >=20 > I guess this is slightly overtaken by event. It have to be aligned = with > what the websocket sub-protocol identifier. The text now reads: The sub-protocol for the channel as a UTF-8 encoded string. If this is an empty string the protocol is unspecified. If it is a non-empty string, it specifies an protocol registered in the 'WebSocket Subprotocol Name Registry' created in . >=20 >>>=20 >>> 5. Section 6: >>> All Data Channel Establishment Protocol messages MUST be sent >>> requesting ordered delivery and using reliable transmission. >>>=20 >>> I wonder of the use of requesting ordered delivery and using = reliable >>> transmission, from an SCTP stream perspective, wouldn't using in = both >>> places be appropriate? Or is how object which has been requested to = be >>> transmitted unordered interact in SCTP with the ordered ones? >=20 >> I'm sorry, I don't understand what you are asking... >=20 > Sorry, it really is a language issue. The above sentence first states > "sent 'requesting' ordered" and later "and 'using' reliable". >=20 > This inconsistency is what I reacted to. I see. Changed to: All Data Channel Establishment Protocol messages MUST be sent using ordered delivery and reliable transmission. >=20 >>=20 >>> 6. Section 7: >>>=20 >>> I think this section can be beefed up a bit. First make clear that = the >>> Data Channel's required usage of DTLS ensures that the message = integrity >>> and possible source authentication as well as confidentiality. Then >>> going over any security risks with a malicous peer using this = protocol. >>> Can a malicous side screw up the peer using this protocol? What are = the >>> implications? >=20 >> Just to double check: Aren't the referenced documents the ones which >> discuss all security stuff in one place? >=20 > The security document do discuss system level important aspects. But, > from my perspective, details that are very specific to this protocol > should be discussed in this document. >=20 > I think this is highly relevant in this document as there are others > that are interested in using it. OK. Any concrete suggestions what should be covered? >=20 >>>=20 >>> 7. Section 8.2: >>>=20 >>> This registry reserves 0xff without any motivation, please add one. >> I added: >>=20 >> The value 0xff has been reserved for future extensibility. >>=20 >=20 > Ok >=20 >>>=20 >>> 8. Section 8.3: >>> If I define a channel behavior that allows mixed ordered and = unordered, >>> how would I register this? >=20 >> You can't. For SCTP properties like ordered/unordered delivery are >> on a per message base. In RTCWeb it was decided to make per channel >> base. So you can't have a data channel supporting a mixtures of >> ordered and unordered messages. >=20 > Ok, fine. >=20 >>>=20 >>> 9. Section 8.4: >>>=20 >>> I have a suggestion for this registries name, instead of "Protocol >>> Registry" I propose "DCEP Protocol Identification Registry" >=20 >> The problem I have with this definition is the following: >> Your name suggests that the use of this entity is restricted to >> DCEP. But isn't the protocol a property of a data channel, no matter >> whether negotiated by used DCEP or not? >=20 > As we now are going to point at the websocket one this is a mote = point. >=20 >>>=20 >>> 10. Section 8.4: >>>=20 >>> There is missing any specification of what type of strings I may >>> register. Also, no length limitation, although the protocol allows = at >>> maximum of 255 octets of encoded characters. >=20 >> I don't understand the limitation to 255 octets. The length field >> is 16 bit, so you can have up to 65535 octets. Therefore I changed: >> A name for the protocol; >> to >> A name for the protocol which length is smaller than 65536 when = using >> an UTF-8 encoding; >=20 > Overtaken by events, limitations will be the ones of the Websocket > registry. >=20 >>>=20 >>> 11. This comments concerns the relation to the Data Channel >>> specification. So my interpretation is that the WebRTC Data channel >>> draft has become both the base for this specification as well as the = one >>> that specifies that the DCEP shall be implemented and supported. For >>> WebRTC I don't think this matters much, but if someone likes to = re-use >>> the basic Data Channel specification, this structure makes it more >>> difficult and have no need for the bi-directional negotiated = parameter >>> settings that the DCEP provides. In that case one have to sub-set = the >=20 >> I think the data channel draft discusses the data channels = independent >> how they are opened. This covers data parameters, user data = transmission >> and closing of data channels. The data channel protocol draft = discusses >> an in-band protocol for setting up data channels. >=20 > I think this was discussed today. And make it clear that DCEP > requirement shouldn't be from the Data Channel spec. >=20 >>> data channel specification. I wonder if it would be better to move = some >>> normative statements around, so that the chain of implementation >>> requirement goes draft-ietf-rtcweb-transports -> >>> draft-ietf-rtcweb-data-protocol -> draft-ietf-rtcweb-data-channel = thus >>> providing a cleaner and more modular build up of the protocols. >> I think you can implement draft-ietf-rtcweb-data-channel without >> draft-ietf-rtcweb-data-protocol, but not vice versa. >>=20 >> So you don't like the statement: >>=20 >> A simple protocol for internal negotiation is specified in >> [I-D.ietf-rtcweb-data-protocol] and MUST be supported. >>=20 >> from draft-ietf-rtcweb-data-channel. What would you suggest? >=20 > I think the high level requirement on DCEP might be in = -rtcweb-transports. It now reads: A simple protocol for in-band negotiation is specified in = [I-D.ietf-rtcweb-data-protocol]. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 From nobody Thu Apr 10 04:55:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2711A022D for ; Thu, 10 Apr 2014 04:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 3_Tr9qxujlVR for ; Thu, 10 Apr 2014 04:55:26 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB3A1A0212 for ; Thu, 10 Apr 2014 04:55:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4D42F7C32B4 for ; Thu, 10 Apr 2014 13:55:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djGJke2pQF-K for ; Thu, 10 Apr 2014 13:55:24 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 466A47C064F for ; Thu, 10 Apr 2014 13:55:24 +0200 (CEST) Message-ID: <534686AA.9040304@alvestrand.no> Date: Thu, 10 Apr 2014 13:55:22 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <02F2BCF4-70B5-47A4-ACE6-C0CCCAB11A50@csperkins.org> <9889BAD9-D9A7-42F2-A0DC-632C26696345@lurchi.franken.de> <73C21E05-E36C-4899-98A4-9D762B75FCE4@csperkins.org> In-Reply-To: <73C21E05-E36C-4899-98A4-9D762B75FCE4@csperkins.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/N7Cxl9UBC25Ln96RQqnbZvYcjDg Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 11:55:31 -0000 On 04/09/2014 04:39 PM, Colin Perkins wrote: > On 9 Apr 2014, at 15:33, Michael Tuexen wrote: >> On 09 Apr 2014, at 16:25, Colin Perkins wrote: >>> On 9 Apr 2014, at 15:20, Michael Tuexen wrote: >>>> On 09 Apr 2014, at 13:00, Colin Perkins wrote: >>>>> On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>> This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. >>>>>> >>>>>> Title : WebRTC Data Channels >>>>>> Authors : Randell Jesup >>>>>> Salvatore Loreto >>>>>> Michael Tuexen >>>>>> Filename : draft-ietf-rtcweb-data-channel-08.txt >>>>>> Pages : 15 >>>>>> Date : 2014-04-09 >>>>>> >>>>>> Abstract: >>>>>> The Real-Time Communication in WEB-browsers working group is charged >>>>>> to provide protocol support for direct interactive rich communication >>>>>> using audio, video, and data between two peers' web-browsers. This >>>>>> document specifies the non-(S)RTP media data transport aspects of the >>>>>> WebRTC framework. It provides an architectural overview of how the >>>>>> Stream Control Transmission Protocol (SCTP) is used in the WebRTC >>>>>> context as a generic transport service allowing WEB-browsers to >>>>>> exchange generic data from peer to peer. >>>>> This talks about “(S)RTP” throughout, but the rtp-usage draft requires that SRTP be used for WebRTC, and disallows plain RTP. I think this draft could be simplified by changing “(S)RTP” to “SRTP” throughout. >>>> Hi Colin, >>>> >>>> The (S)RTP notion goes back to a comment from Magnus. If I remember it correctly he considers SRTP a profile of RTP. Since I don’t wanted to just use RTP, I ended up with (S)RTP based on a discussion with Magnus. >>>> >>>> However, I’m fine with changing it to SRTP... >>> SRTP is an RTP profile. My comment was that if this is for WebRTC only, then only SRTP can be used, and not plain RTP. Using “(S)RTP” rather than “SRTP” in this draft suggests that the secure profile is optional, which isn’t the case in WebRTC. If this is for more general use than WebRTC, then “(S)RTP” is fine. >> It is clear that in WebRTC only SRTP is used... > I don’t believe your draft is clear on that, due to the use of “(S)RTP” terminology. That’s why I commented. > Enforcing the SRTP-only rule for WebRTC is not the business of this draft, so it's not a normative statement in any way, shape or form. If it's possible to use these channels outside of WebRTC, and some of these places claim to be able to use pure RTP with appropriate security, then making use of "SRTP" only in this draft is confusing. I see arguments both ways, and want to leave it at editors' discretion. From nobody Thu Apr 10 04:58:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7691A067A for ; Thu, 10 Apr 2014 04:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 2yNA-i7ks5ZQ for ; Thu, 10 Apr 2014 04:57:53 -0700 (PDT) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id B61DF1A0235 for ; Thu, 10 Apr 2014 04:57:52 -0700 (PDT) X-AuditID: c1b4fb31-b7f688e000003e64-1f-5346873e901d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 50.FB.15972.E3786435; Thu, 10 Apr 2014 13:57:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Thu, 10 Apr 2014 13:57:51 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt Thread-Index: AQHPU9r8wvMWA0Q1K0mIC9kJW7dm+ZsI/KmAgAA33gCAAAFBgIAAAmyAgAABogCAAWRtAIAAIfwQ Date: Thu, 10 Apr 2014 11:57:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2BCB6A@ESESSMB209.ericsson.se> References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <02F2BCF4-70B5-47A4-ACE6-C0CCCAB11A50@csperkins.org> <9889BAD9-D9A7-42F2-A0DC-632C26696345@lurchi.franken.de> <73C21E05-E36C-4899-98A4-9D762B75FCE4@csperkins.org> <534686AA.9040304@alvestrand.no> In-Reply-To: <534686AA.9040304@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvja59u1uwwfvzXBbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKWXzrLXLBMpmLNmkb2BsbDYl2MnBwSAiYS HX8mMEHYYhIX7q1nA7GFBE4ySnR3JncxcgHZSxglPky9y9LFyMHBJmAh0f1PG6RGRCBYovf5 e0aQsLCAu0TPv1iIsIfEjE/LWSHsKImT97+BjWQRUJWYffkfO0g5r4CvxM+9BRDT/zFJ/Pm7 DKyGU0BX4s7zc2DnMAKd8/3UGjCbWUBc4taT+VBnCkgs2XOeGcIWlXj5+B8rhK0o0f60gRGi Xkdiwe5PbBC2tsSyha/B6nkFBCVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjJLFqcVJuelG hnq56bkleqlFmcnFxfl5esWpmxiBsXJwy2/DHYwTr9kfYpTmYFES52WY3hkkJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgXFJzFWp0Ifz2Z0dzty+fWVCi3alcOXph1Vu9q7RN5a/jo1e9tJT 9MY3tyxh8Q0e0tOePinLvOydlp0p/i047HbtFm/Pv92ZBxIYJKY9EWrJLFz3pVgyt/Emh+HM 36Lbn7r9iTExCTY6JsX8zTLNK5vlqHbRtbVLZ/ctSNyztvN92f4z26+KliqxFGckGmoxFxUn AgCOdsMRYwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LcabLiewmsKDEkIuQwqlW6A05B4 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 11:57:57 -0000 Hi, In BUNDLE we use "RTP-based media" terminology, eventhough BUNDLE will be u= sed in WebRTC environments where SRTP is mandated. Why can't we use the same here? Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: 10. huhtikuuta 2014 14:55 To: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt On 04/09/2014 04:39 PM, Colin Perkins wrote: > On 9 Apr 2014, at 15:33, Michael Tuexen wrote: >> On 09 Apr 2014, at 16:25, Colin Perkins wrote: >>> On 9 Apr 2014, at 15:20, Michael Tuexen wrote: >>>> On 09 Apr 2014, at 13:00, Colin Perkins wrote: >>>>> On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. >>>>>> This draft is a work item of the Real-Time Communication in WEB-brow= sers Working Group of the IETF. >>>>>> >>>>>> Title : WebRTC Data Channels >>>>>> Authors : Randell Jesup >>>>>> Salvatore Loreto >>>>>> Michael Tuexen >>>>>> Filename : draft-ietf-rtcweb-data-channel-08.txt >>>>>> Pages : 15 >>>>>> Date : 2014-04-09 >>>>>> >>>>>> Abstract: >>>>>> The Real-Time Communication in WEB-browsers working group is=20 >>>>>> charged to provide protocol support for direct interactive rich=20 >>>>>> communication using audio, video, and data between two peers'=20 >>>>>> web-browsers. This document specifies the non-(S)RTP media data=20 >>>>>> transport aspects of the WebRTC framework. It provides an=20 >>>>>> architectural overview of how the Stream Control Transmission=20 >>>>>> Protocol (SCTP) is used in the WebRTC context as a generic=20 >>>>>> transport service allowing WEB-browsers to exchange generic data fro= m peer to peer. >>>>> This talks about "(S)RTP" throughout, but the rtp-usage draft require= s that SRTP be used for WebRTC, and disallows plain RTP. I think this draft= could be simplified by changing "(S)RTP" to "SRTP" throughout. >>>> Hi Colin, >>>> >>>> The (S)RTP notion goes back to a comment from Magnus. If I remember it= correctly he considers SRTP a profile of RTP. Since I don't wanted to just= use RTP, I ended up with (S)RTP based on a discussion with Magnus. >>>> >>>> However, I'm fine with changing it to SRTP... >>> SRTP is an RTP profile. My comment was that if this is for WebRTC only,= then only SRTP can be used, and not plain RTP. Using "(S)RTP" rather than= "SRTP" in this draft suggests that the secure profile is optional, which i= sn't the case in WebRTC. If this is for more general use than WebRTC, then = "(S)RTP" is fine. >> It is clear that in WebRTC only SRTP is used... > I don't believe your draft is clear on that, due to the use of "(S)RTP" t= erminology. That's why I commented. > Enforcing the SRTP-only rule for WebRTC is not the business of this draft, = so it's not a normative statement in any way, shape or form. If it's possible to use these channels outside of WebRTC, and some of these= places claim to be able to use pure RTP with appropriate security, then ma= king use of "SRTP" only in this draft is confusing. I see arguments both ways, and want to leave it at editors' discretion. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Apr 10 06:14:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19481A01C1 for ; Thu, 10 Apr 2014 06:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 EOoOjB3DFp_b for ; Thu, 10 Apr 2014 06:14:03 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id B67441A012D for ; Thu, 10 Apr 2014 06:13:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8C9FE7C51BC for ; Thu, 10 Apr 2014 15:13:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeCV9uo8LbZ5 for ; Thu, 10 Apr 2014 15:13:42 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id C3A4E7C51BB for ; Thu, 10 Apr 2014 15:13:42 +0200 (CEST) Message-ID: <53469905.1080302@alvestrand.no> Date: Thu, 10 Apr 2014 15:13:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5339A120.3040909@alvestrand.no> In-Reply-To: <5339A120.3040909@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nh6v14uTmSVxuDCNI8y7reVwy90 Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 13:14:07 -0000 Just checking... since there's been no comment to the main body of the text here (it's all been on the SCTP aspect), is it OK to include the text in my next version of the -transport draft? (I'm not responding to Karl's comments - it's at a completely different level of complexity.) Harald On 03/31/2014 07:08 PM, Harald Alvestrand wrote: > I see that I have promised to sugggest language for -transport- about > prioritization. > Here's an attempt. References and so on to be filled in later. > > Comments welcome - this is a first stab! > > -------------------------------------------- > The RTCWEB prioritization model is that the application tells the RTCWEB > implementation about the priority of media and data flows through an API. > > The priority associated with a media or data flow is classified as > "normal", "below normal", "high" or "very high". There are only four > priority levels at the API. > > The RTCWEB implementation is responsible for mapping these to protocol > mechanics at the protocol interfaces, and to behave appropriately when > choosing what packets to send when. > > [draft-dhesikan] specifies the mapping of the four levels of priority, > combined with the media type, to DSCP markings. This marking SHOULD be > done; the implementation MAY turn off use of DSCP markings if it detects > symptoms of unexpected behaviour like priority inversion or blocking of > packets with certain DSCP markings. The detection of these conditions is > implementation dependent. (Question: Does there need to be an API knob > to turn off DSCP markings?) > > When an RTCWEB implementation has packets to send on multiple streams > that are congestion-controlled under the same congestion controller, the > RTCWEB implementation SHOULD serve the streams in a weighted round-robin > fashion, with each level of priority being given twice the transmission > capacity of the level below; thus, when congestion occurs, a "very high" > priority flow will have the ability to send 8 times as much data as a > "below normal" flow if both have data to send. This prioritization is > independent of the media type, but will lead to packet loss due to full > send buffers occuring first on the highest volume flows at any given > priority level. The details of which packet to send first are > implementation defined. > > -- TODO: Specify a relative priority scheme that makes sense with SCTP, > with an appropriate reference. [draft-ietf-tsvwg-sctp-prpolicies] > specifies a priority policy, but it's about discarding packets, not > deciding which packets to send first, and it also makes it impossible to > specify time-bounded retransmission. -- > From nobody Thu Apr 10 07:47:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA4D1A017D for ; Thu, 10 Apr 2014 07:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 4D3PqhFpWvFn for ; Thu, 10 Apr 2014 07:47:44 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id B5A631A0145 for ; Thu, 10 Apr 2014 07:47:43 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta13.westchester.pa.mail.comcast.net with comcast id oC1d1n0031swQuc5DEniM9; Thu, 10 Apr 2014 14:47:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id oEni1n00E3ZTu2S3bEniFg; Thu, 10 Apr 2014 14:47:42 +0000 Message-ID: <5346AF0E.20500@alum.mit.edu> Date: Thu, 10 Apr 2014 10:47:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Martin Thomson References: <20140409180350.13315.51677.idtracker@ietfa.amsl.com> <53459BBB.1080505@alum.mit.edu> <5345B3EB.4050108@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397141262; bh=JtyfIw+4ApYPOf4ae/Elh+g2IfzXwgMyY/B3sJCs6xs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=H6NUk9+PIS8q09pCwnBuRqn02kqWVetqNrbxgjU2sRu3SF+5CbWrTw42OsdIGdPWh M/jDjhjSXKkwdTBFc+ZCyHfqS5XsvTSNHr2BItWqZwjZxpAdjqZWb6JTmvr43Z2OcO J6bWGlUXE7El790sik7oDpumSsuf7uRk+PvYpTg8V1yvE3tvzZzwIm1U5njLwduBTw yAq3peVpatHB1ZntCXYEpqZnVPdZejC7ui6c0ztGuwOID2Hz1bDYi1EEyhw7ALnQeT H3/trnoBHGPTi8Cd1xmcXFz8u91K7BtAN+vJysZ3hCQDfFvOfO+ZZ8jjHJbrRwGpBq DHVL2PdYbmvOQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/j_mIE638wz2Hj5A-DYcXLqvEUNg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-thomson-rtcweb-alpn-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 14:47:44 -0000 On 4/9/14 5:25 PM, Martin Thomson wrote: > On 9 April 2014 13:56, Paul Kyzivat wrote: >> I expect two different protocols to look different on the wire. >> >> You seem to be saying that SMTP used to talk to ietf mailing lists is a >> different protocol from SMTP used to talk to my lawyer, because I expect my >> lawyer to keep the communications confidential. > > They are different on the wire. They use different identifiers. > > That's hair splitting, but there's a real difference between the two > usages. And I think that it's important enough to do this. > > Do you perhaps have an alternative, or is it just that this lack of > solidity is giving you heartburn? Because I can appreciate that. Heartburn. It seems like a hack - tunneling - just looking for *something* that can be used to convey one more bit of data. I don't have another suggestion. I only half understand the problem. But to the extent that I do, it seems ill-defined. AFAIK it only really has meaning in the context of a browser. Once you start signaling it, it gets fuzzier. If you *knew* both ends were controlled by a browser following these conventions then it would be a bit clearer. But when that ceases to be true I can make no sense of what it all means. And as best I understand, the isolation is intended to be per-media-stream, so solutions that are at a different level seem problematic. Thanks, Paul From nobody Thu Apr 10 07:51:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C961A0073 for ; Thu, 10 Apr 2014 07:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 acIjww83B_zj for ; Thu, 10 Apr 2014 07:51:50 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 551391A01AD for ; Thu, 10 Apr 2014 07:51:44 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta13.westchester.pa.mail.comcast.net with comcast id oCH11n0020bG4ec5DErjFB; Thu, 10 Apr 2014 14:51:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id oErj1n0083ZTu2S3PErjNt; Thu, 10 Apr 2014 14:51:43 +0000 Message-ID: <5346AFFF.4070803@alum.mit.edu> Date: Thu, 10 Apr 2014 10:51:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <533F191D.8050109@alum.mit.edu> <53419ED4.8020102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> <53465CA2.4010607@alvestrand.no> In-Reply-To: <53465CA2.4010607@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397141503; bh=pn4laG8rI9ZpAqM4Ut1DRmk3642OFaIFzWlegxX7iaA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Qoh+mZ5w33O1gJaNZFtrmHfxVxxx4IxbKG8ZMaWXRy6l6VgtLgZMoJrVmRZ2qwLBE yZXqT8WbP7xroO/1mEWMJVas2veug91HoHYDs8rrVh4SdTdhkrFJ6tHkSWkJ9l1+e3 4VqbYudY8TW0HdRcnxh1W5+q0iju8H0NQkD9G5Q/o/Aawp8AyBqzjkuAqLcyD8a4NC 3aWBxSBkGpTe8ftmgofXTQqzsrIn7Ue2JGuYnbrtCDu9dJizcS55WrrLXCi6mx+WYQ tRvq7O9AITQLhg6ZOLXQ4mWFgY4uwWEJF3MxZAZBDHC8AZAoBaiYkRMQFlrEK5hDcd IknPHPh9tkAkA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XlVHCyNkUjVRTusqM6lZNZjQmac Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 14:51:51 -0000 On 4/10/14 4:56 AM, Harald Alvestrand wrote: > On 04/08/2014 08:24 PM, Martin Thomson wrote: >> On 8 April 2014 09:50, Bernard Aboba wrote: >>> [BA] I'm not sure that the concept of "isolation" makes sense for those >>> intermediaries (or to voicemail or an audio/video conference, for that >>> matter). While in a point-to-point call it might be useful, in a >>> conference the whole point is to have audio/video sent to multiple >>> parties, >>> and recording is commonplace. The problem is that from a protocol >>> point of >>> view the cases are not easily distinguishable -- and so if the browser >>> insists on "isolation" then one wonders what will happen if the >>> conference >>> bridge/video MCU/voicemail system refuses to negotiate it. Refusing to >>> send media would not be a desirable outcome. >> I think that for this, it's perfectly reasonable to use identity, but >> not stream isolation. With isolation, if the peer does not agree to >> comply, then the session fails to complete. > Actually I'd say it's "if the peer does not *agree to* comply". > The protocol has no defense against liars, but that's a common issue. >> >> The authenticated party here is an MCU (or bridge, or voicemail, >> etc...). Rather than sending to "anindividual@example.org", media is >> sent to "mcu@example.com". Is it reasonable for that MCU to forward >> media to other, unspecified entities? Clearly it can, but should it? >> >> (Not having thought it through completely, a voicemail box could >> conceivably work. I think that I'd want to use a different identity >> for it though.) > > I can see an use for a recording spec that said "you can record this, > but only if you do it in such a way that it's only accessible to the > stated identity". > > Would be weird to try to enforce that.... but I agree; MCU and isolation > have a hard time mixing. > Let's just not. So what does this mean for screen sharing with a conference? Thanks, Paul From nobody Thu Apr 10 08:02:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2848A1A0159 for ; Thu, 10 Apr 2014 08:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 X34fNKDCRVtb for ; Thu, 10 Apr 2014 08:02:52 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBAF1A0320 for ; Thu, 10 Apr 2014 08:02:39 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta09.westchester.pa.mail.comcast.net with comcast id oCeo1n0070xGWP859F2e4j; Thu, 10 Apr 2014 15:02:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id oF2e1n00G3ZTu2S3YF2eNX; Thu, 10 Apr 2014 15:02:38 +0000 Message-ID: <5346B28E.60408@alum.mit.edu> Date: Thu, 10 Apr 2014 11:02:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> In-Reply-To: <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397142158; bh=29lzw3dEegqqhpazSj5SD5O0PhUyk2LAxPqwvbgDo2E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s0vQ+i3tGVKJPUettikm1T6p2uxrkhh8ZtmNiZJ+HVRxsinJQ3a+sMm+nKaXTCNBh RcGM27BRKdAkzDCdIxPXaee3xNMnwHBfnhlU9RJTwhlzMEPm8ugs3SRlN2FJIsXgcv pONniSIPIMFP897skLtKv0o/PaUaMZDltD8myIzteMNZteXB1Js4gKYu55UqNWV1bl KqS8q/WXTH+ijpmm1KxrbhKDGSRi1lXsJrcB5ZAJ1gusn52EWv8KWGBvRfr8X6rXo2 cRsHOKi4Qrrg97pKHb+2R5iJblFJK9oR9hV5ma1/HhQEmBHK0ittXOpzDVhVA9DwjQ aJJOQT04eyjDA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PHv2_WIUG1lnRU927Yx63AgMWwg Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 15:02:53 -0000 On 4/3/14 12:30 PM, Karl Stahl wrote: > (B) Each rtcweb file transfer MUST use its own data channel (if > combined they risk being regulated randomly/unfairly by SCTP itself > and all files will have just have one single TCP-like flow at the > network congestion point when sharing the available bandwidth with > everyone else's flows at that congestion point - That would be > "negative priority" compared to what we are used to in a browser.). I presume you mean each *concurrent* file transfer must use its own channel. Right? Reusing the same channel to transfer a series of files should be fine. Thanks, Paul From nobody Thu Apr 10 08:34:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE221A01DC for ; Thu, 10 Apr 2014 08:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1] autolearn=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 L7XW-zye5-bA for ; Thu, 10 Apr 2014 08:34:29 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id B35911A0073 for ; Thu, 10 Apr 2014 08:34:27 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404101734244210; Thu, 10 Apr 2014 17:34:24 +0200 From: "Karl Stahl" To: "'Paul Kyzivat'" , References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> <5346B28E.60408@alum.mit.edu> In-Reply-To: <5346B28E.60408@alum.mit.edu> Date: Thu, 10 Apr 2014 17:34:32 +0200 Message-ID: <00aa01cf54d2$5eb1a700$1c14f500$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9UzfajHns3jfI1RYG+yRhxnFwVhQAA8xhw Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0B4KyYkVk6UYzzJv4zZA1QLupjs Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 15:34:31 -0000 -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Paul Kyzivat Skickat: den 10 april 2014 17:03 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Some language on "prioritization" On 4/3/14 12:30 PM, Karl Stahl wrote: > (B) Each rtcweb file transfer MUST use its own data channel (if=20 > combined they risk being regulated randomly/unfairly by SCTP itself=20 > and all files will have just have one single TCP-like flow at the=20 > network congestion point when sharing the available bandwidth with=20 > everyone else's flows at that congestion point - That would be=20 > "negative priority" compared to what we are used to in a browser.). I presume you mean each *concurrent* file transfer must use its own = channel. Right? Reusing the same channel to transfer a series of files should be fine. Thanks, Paul Yes, That is right. /Karl _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Apr 10 12:32:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6629A1A042D for ; Thu, 10 Apr 2014 12:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 dRhaWnia_CNx for ; Thu, 10 Apr 2014 12:32:11 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F41AF1A0545 for ; Thu, 10 Apr 2014 12:31:50 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so4456576wgh.29 for ; Thu, 10 Apr 2014 12:31:49 -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:content-type; bh=ZAamq0VfOcOzEmk11frUVK0rUVuJSNUyDqheYmSAagw=; b=unL8CqZs4qy3qTCEaqUWdOrunSuyuKA3sEM6h0TFuf5OgdXwIE882GhaCvJgu35rsZ R+jrKC7y+rHcwRgHJ9OIpBwVnnLKVlLUAdeN+w7P+itcmzyn/xO/hvsJg8GM9M48Rxol YEkk4mufNBdqzn68CnW8GiUCfL2tawk4/YIeiO6lXznPMuX9eJuAUbZ4sUs5+5Kgwn3Z 6uy30V7Xf2SQDiPizOwCFDNI2FBLb/1ZJ/syDODGRjTKOAqPtLa/LNKdk62eny49sKSN w6dK+8z7XQXtwk6k/85+wT4HXKO3PlMWWPlp6OHh0+6p6l5HpiJevo6q+8vj3u5VfaHl 9nRQ== MIME-Version: 1.0 X-Received: by 10.180.92.196 with SMTP id co4mr16677245wib.50.1397158309444; Thu, 10 Apr 2014 12:31:49 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Thu, 10 Apr 2014 12:31:49 -0700 (PDT) In-Reply-To: <53465CA2.4010607@alvestrand.no> References: <533F191D.8050109@alum.mit.edu> <53419ED4.8020102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> <53465CA2.4010607@alvestrand.no> Date: Thu, 10 Apr 2014 12:31:49 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UFzg3P9s38WWB_KKfZHanJ67wfw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 19:32:16 -0000 On 10 April 2014 01:56, Harald Alvestrand wrote: >> I think that for this, it's perfectly reasonable to use identity, but >> not stream isolation. With isolation, if the peer does not agree to >> comply, then the session fails to complete. > > Actually I'd say it's "if the peer does not *agree to* comply". > The protocol has no defense against liars, but that's a common issue. That's precisely what I said, sans emphasis :) From nobody Thu Apr 10 12:33:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3961A0423 for ; Thu, 10 Apr 2014 12:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 rC7rkwtOHZuH for ; Thu, 10 Apr 2014 12:33:47 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 288271A03FC for ; Thu, 10 Apr 2014 12:33:46 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so5590235wiv.12 for ; Thu, 10 Apr 2014 12:33:45 -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:content-type; bh=bsqS+qILPZe2oNG6mFIS+47UXzrPKFvOXvIh3FnSYEE=; b=z4VdM+uYzLjiJC2iJhK1fgzmzVcEH4yWZZVCsDCVzpMba3EjC2yqawUQSMC2iuWHR3 hesPOE70CLcox3967zMCDPoV+RxaxYT7QhVLcEMgLNHPTcPjuTvhEpX06hA9jO0Q4xVX DeTmsUZPTgZDnt0rVArvvKhegSP8y8HYy8iMhc0MQ8e6kT6tK+wk/GpKoLeZHiUWbc94 Ys3JNwAUol0IUJGtUT5KaH0rtyOK7jh52su+94cgbz2Y7FFuzxrJ08P4ruApGsNVwZiW nEIstkFHBwEIbFWmUscrzZpPMEpGaNN93cmQf9tlr7F1uEG3ssJWkSoJ6VEzYyokg0Sh ZlYg== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr44252801wiw.50.1397158425711; Thu, 10 Apr 2014 12:33:45 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Thu, 10 Apr 2014 12:33:45 -0700 (PDT) In-Reply-To: <5346AFFF.4070803@alum.mit.edu> References: <533F191D.8050109@alum.mit.edu> <53419ED4.8020102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> <53465CA2.4010607@alvestrand.no> <5346AFFF.4070803@alum.mit.edu> Date: Thu, 10 Apr 2014 12:33:45 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KYWCHo_vj5TPRYZv3zqQlQX1cyE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 19:33:48 -0000 On 10 April 2014 07:51, Paul Kyzivat wrote: > So what does this mean for screen sharing with a conference? It means the same thing, if the stream is isolated, it will not be possible to share with a conference MCU. (You can go full mesh to retain good isolation, but that requires multiple differently isolated streams, and it's likely to annoy the user with gUM prompts.) From nobody Thu Apr 10 14:30:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1981A0214 for ; Thu, 10 Apr 2014 14:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 pzi_nL8Z0x8T for ; Thu, 10 Apr 2014 14:30:08 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC891A0073 for ; Thu, 10 Apr 2014 14:30:08 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id oH9h1n0031ap0As53MW7Cn; Thu, 10 Apr 2014 21:30:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id oMW61n00x3ZTu2S3iMW7vV; Thu, 10 Apr 2014 21:30:07 +0000 Message-ID: <53470D5D.5040806@alum.mit.edu> Date: Thu, 10 Apr 2014 17:30:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Martin Thomson References: <533F191D.8050109@alum.mit.edu> <53419ED4.8020102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2B26CB@ESESSMB209.ericsson.se> <53465CA2.4010607@alvestrand.no> <5346AFFF.4070803@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397165407; bh=61aslY8VEmxJcLBDTYOsfQNgYzl02CyIJUB4IWdtegc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aTDVtYehg2lVlHNyQ+ijlww3+/SubYPN1sf72tydN466wP9SiAR8PgpKqwCE5ELZO Uomaqa0Ior0zxHDAm/VaaEmBR+et9esCeOiTCHhpjHwYxHB/95TGZ1u4/nhsj6LBVN f7OGExQBqR8JVGnimlU6Dph1jZ41PVg7hubv8YQ4U2IOOVYI01F0w1N1I/j1QylU5c oykUsoYhxaNSrXEOHd4a8n3jLufZfM3HXfKzZs2cIX43JXvjWgaWdULRaOsP3gZM4l DrtU7qUoAVowsZG5GeMEKah9HtjN+yfHO4f7+OisAmUh5/0Aigi/uaFbD/8eHKCQOA qGuUkfqjzdu1A== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Sj2OT5dELVnS9xnSZ9cBrWLDxLA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Asking TLS for help with media isolation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 21:30:09 -0000 On 4/10/14 3:33 PM, Martin Thomson wrote: > On 10 April 2014 07:51, Paul Kyzivat wrote: >> So what does this mean for screen sharing with a conference? > > It means the same thing, if the stream is isolated, it will not be > possible to share with a conference MCU. > > (You can go full mesh to retain good isolation, but that requires > multiple differently isolated streams, and it's likely to annoy the > user with gUM prompts.) Well, apparently it will be at the discretion of the conference focus. Since it presumably doesn't have a browser, it will only be governed by its own policies and whatever normative statements are made about the behavior of servers in this case. There will be a business motivation to allow such sharing if a rationale can be made that it is allowed. So that puts a premium on clear normative statements. Thanks, Paul From nobody Thu Apr 10 20:38:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082A21A001A; Thu, 10 Apr 2014 20:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 PKiEMZL7TMnE; Thu, 10 Apr 2014 20:38:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 844C81A007B; Thu, 10 Apr 2014 20:37:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> Date: Thu, 10 Apr 2014 20:37:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7Eyr7y2WXbW58KJKUvegSAFA0QA Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 03:38:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : STUN Usage for Consent Freshness Authors : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Martin Thomson Filename : draft-ietf-rtcweb-stun-consent-freshness-02.txt Pages : 8 Date : 2014-04-10 Abstract: To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new STUN usage. This same mechanism can also determine connection loss ("liveness") with a remote peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-02 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 Thu Apr 10 22:00:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0361A0280 for ; Thu, 10 Apr 2014 22:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 HhL8bV2Z-d_d for ; Thu, 10 Apr 2014 22:00:43 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id EB7171A02CB for ; Thu, 10 Apr 2014 22:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2527; q=dns/txt; s=iport; t=1397192442; x=1398402042; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=tnNjXzUk8h+XiJSdndAtQlq/arDcJ2w3rredc02weXA=; b=k71Cg2+sjxNBibSZrvuRj2ojQSdVhYAmcHVnfNjV4PzMRQkEJQmn7/iR Ov7294z8zkWvm9wA8gzG5PVZgMZIcnY7kQdmErhl+o/mJjDPrh9aXVROk psdAWwURj9FdlOabNq53wmIewhbwVwHk960BfM0k6ztBJPQYH/f9Aj8fT 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAGAJh2R1OtJA2F/2dsb2JhbABZgwY7UQa9BoZkUYEfFnSCJQEBAQQBAQE3NBcEAgEIEQMBAh8QJwsdCAIEEwkSh2EIBcxzF445OgaEMgSYXoE1kQ2DMIIr X-IronPort-AV: E=Sophos;i="4.97,839,1389744000"; d="scan'208";a="34844595" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP; 11 Apr 2014 05:00:39 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s3B50dQj026994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 11 Apr 2014 05:00:40 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.219]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 00:00:39 -0500 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt Thread-Index: AQHPVUL7+UONYsMxGEKmYPcY6nIEHw== Date: Fri, 11 Apr 2014 05:00:39 +0000 Message-ID: References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> In-Reply-To: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [72.163.212.123] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/M_tKpRx5xrzmubK2XlxJDnEhkJI Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 05:00:47 -0000 Summary of changes in this revision Addressed the comments received from the WG. Removed the timers definition from solution overview and made the text more generic. Incorporated text from draft-thomson-rtcweb-consent. Most of the text of solution overview is re-written however the idea is still kept intact Comments are welcome. There is still some dangling reference (text) to SRTP/DTLS mechanism for consent which we will modify in the next revision Regards, Authors -----Original Message----- From: "internet-drafts@ietf.org" Date: Friday, 11 April 2014 9:07 am To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Real-Time Communication in WEB-browsers >Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-02.txt > Pages : 8 > Date : 2014-04-10 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new STUN usage. > This same mechanism can also determine connection loss ("liveness") > with a remote peer. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshnes= s- >02 > > >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/ > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Apr 10 23:52:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCF41A00D1 for ; Thu, 10 Apr 2014 23:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 8Y7o_Q9cmdO0 for ; Thu, 10 Apr 2014 23:52:11 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A69711A00C2 for ; Thu, 10 Apr 2014 23:52:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7f328e0000012ab-28-53479118ff84 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C0.00.04779.81197435; Fri, 11 Apr 2014 08:52:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Fri, 11 Apr 2014 08:52:08 +0200 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt Thread-Index: AQHPVTeOIZagSP6uQkS1AgMrcrQE2JsLugCAgABAKVA= Date: Fri, 11 Apr 2014 06:52:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvja7ERPdgg9t7bCyWd+1gtFj7r53d gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mro2X2BraBHsuJ0zxKmBsb3wl2MnBwSAiYS q58cZoawxSQu3FvP1sXIxSEkcJhR4sHUI0wQzhJGiX1n/jJ2MXJwsAlYSHT/0wZpEBEIk5h+ YgELiC0sECwx49c+Voh4iMSeaWuZIWwricbj71hAWlkEVCWuLvQBCfMK+Eo0LN3LBBIWEkiT +H7QESTMKaAvcez6P3YQmxHonO+n1jCB2MwC4hK3nsxngjhTQGLJnvNQJ4tKvHz8jxXCVpS4 On05VL2OxILdn9ggbG2JZQtfM0OsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMbLnJmbm pJcbbmIExsHBLb91dzCeOidyiFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxS DYwBL28cM1KerrfdYMKW70GL5zXY3Xvb/GCGlc+pyDVzNjM8MHv7YdZuDpFkntZ42wmd85la jjqZJCZEyeuff1fyYfuuY4dcuneZHgqesZplzg/p7xUc/hdjHW0+drp+35/SOqH5jrLluo21 qsvWpy/WPC114cSrl6wyL/3mrJi7SLunpfS/ZtNVJZbijERDLeai4kQA/nJL9FECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2oV2rs_jvRTldrjmcI14M94pEH4 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 06:52:12 -0000 Hi, I think it would be good to have some text about usage of consent freshness= when one entity is ICE lite. And, I think it would be good to make it more clear that the usage of conse= nt is always negotiated per direction. Thanks! Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R (rmo= hanr) Sent: 11. huhtikuuta 2014 8:01 To: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-= 02.txt Summary of changes in this revision Addressed the comments received from the WG. Removed the timers definition from solution overview and made the text more= generic. Incorporated text from draft-thomson-rtcweb-consent. Most of the text of solution overview is re-written however the idea is sti= ll kept intact Comments are welcome. There is still some dangling reference (text) to SRTP/DTLS mechanism for co= nsent which we will modify in the next revision Regards, Authors -----Original Message----- From: "internet-drafts@ietf.org" Date: Friday, 11 April 2014 9:07 am To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Real-Time Communication in=20 >WEB-browsers Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-02.txt > Pages : 8 > Date : 2014-04-10 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new STUN usage. > This same mechanism can also determine connection loss ("liveness") > with a remote peer. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshne >ss/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshne >ss- >02 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Apr 10 23:54:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF91A00D1 for ; Thu, 10 Apr 2014 23:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 kfAKhD78ZDFy for ; Thu, 10 Apr 2014 23:54:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 843171A00C2 for ; Thu, 10 Apr 2014 23:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3664; q=dns/txt; s=iport; t=1397199242; x=1398408842; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hSSpWuS+ggmB7GqnXI7qLZhACAY2pfMSr2GyZ1tbOp4=; b=T1oushK4QgDzlMd+xSHDGZ3mGzulFXaxjwbPFo9vbsP5w+NVsf7sQS6S Zh+82zAGnuQzjroroZyJ/5VPI2orWZCTUoabOsm5+R1xx4DY62UT9CLcG L4HmtXy5MBze1Tb3eKkziFeeDpxPEy+ly0Hud6F5vugMpn+OcqFmzx+m2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAGAGuQR1OtJV2Y/2dsb2JhbABZgwY7UQa9B4ZkUYEbFnSCJQEBAQQBAQE3NBcEAgEIEQMBAQEfCQcnCxQJCAIEARIJEodhCAXMQReOcwaEMgSYXoE1kQ2DMIIr X-IronPort-AV: E=Sophos;i="4.97,840,1389744000"; d="scan'208";a="316694683" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 11 Apr 2014 06:54:01 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3B6s1QI015490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 06:54:01 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.219]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 01:54:01 -0500 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt Thread-Index: AQHPVVLR5i0VrYNx/UKwfcbJsOvEaQ== Date: Fri, 11 Apr 2014 06:54:00 +0000 Message-ID: References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [173.39.64.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <643FD12664AA2B4EB0A0CF52CA0C0472@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/s0X7U5SniPlEF53XcTQ0puDodhw Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 06:54:07 -0000 Sure. We will add text for these two in the next revision. Thanks, Ram -----Original Message----- From: Christer Holmberg Date: Friday, 11 April 2014 12:22 pm To: Ram Mohan Ravindranath , "rtcweb@ietf.org" Subject: RE: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt >Hi, > >I think it would be good to have some text about usage of consent >freshness when one entity is ICE lite. > >And, I think it would be good to make it more clear that the usage of >consent is always negotiated per direction. > >Thanks! > >Regards, > >Christer > > >-----Original Message----- >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R >(rmohanr) >Sent: 11. huhtikuuta 2014 8:01 >To: rtcweb@ietf.org >Subject: Re: [rtcweb] I-D Action: >draft-ietf-rtcweb-stun-consent-freshness-02.txt > >Summary of changes in this revision > >Addressed the comments received from the WG. >Removed the timers definition from solution overview and made the text >more generic. >Incorporated text from draft-thomson-rtcweb-consent. >Most of the text of solution overview is re-written however the idea is >still kept intact > > >Comments are welcome. > >There is still some dangling reference (text) to SRTP/DTLS mechanism for >consent which we will modify in the next revision > > >Regards, >Authors > >-----Original Message----- >From: "internet-drafts@ietf.org" >Date: Friday, 11 April 2014 9:07 am >To: "i-d-announce@ietf.org" >Cc: "rtcweb@ietf.org" >Subject: [rtcweb] I-D Action: >draft-ietf-rtcweb-stun-consent-freshness-02.txt > >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Real-Time Communication in >>WEB-browsers Working Group of the IETF. >> >> Title : STUN Usage for Consent Freshness >> Authors : Muthu Arul Mozhi Perumal >> Dan Wing >> Ram Mohan Ravindranath >> Tirumaleswar Reddy >> Martin Thomson >> Filename : draft-ietf-rtcweb-stun-consent-freshness-02.txt >> Pages : 8 >> Date : 2014-04-10 >> >>Abstract: >> To prevent sending excessive traffic to an endpoint, periodic consent >> needs to be obtained from that remote endpoint. >> >> This document describes a consent mechanism using a new STUN usage. >> This same mechanism can also determine connection loss ("liveness") >> with a remote peer. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshne >>ss/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-02 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshne >>ss- >>02 >> >> >>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/ >> >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf.org >>https://www.ietf.org/mailman/listinfo/rtcweb > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Apr 10 23:58:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A0A1A00EF for ; Thu, 10 Apr 2014 23:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] autolearn=ham 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 FxThB88nzvDU for ; Thu, 10 Apr 2014 23:58:17 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 654FC1A00D1 for ; Thu, 10 Apr 2014 23:58:17 -0700 (PDT) Received: from [192.168.1.103] (p54818011.dip0.t-ipconnect.de [84.129.128.17]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 809FA1C104301; Fri, 11 Apr 2014 08:58:14 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <534686AA.9040304@alvestrand.no> Date: Fri, 11 Apr 2014 08:58:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140409100258.9712.74771.idtracker@ietfa.amsl.com> <02F2BCF4-70B5-47A4-ACE6-C0CCCAB11A50@csperkins.org> <9889BAD9-D9A7-42F2-A0DC-632C26696345@lurchi.franken.de> <73C21E05-E36C-4899-98A4-9D762B75FCE4@csperkins.org> <534686AA.9040304@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8qo7LqFxPwqQxY1ZD6Q5jJgyIQ4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 06:58:21 -0000 On 10 Apr 2014, at 13:55, Harald Alvestrand = wrote: > On 04/09/2014 04:39 PM, Colin Perkins wrote: >> On 9 Apr 2014, at 15:33, Michael Tuexen = wrote: >>> On 09 Apr 2014, at 16:25, Colin Perkins wrote: >>>> On 9 Apr 2014, at 15:20, Michael Tuexen = wrote: >>>>> On 09 Apr 2014, at 13:00, Colin Perkins wrote: >>>>>> On 9 Apr 2014, at 11:02, Internet-Drafts@ietf.org wrote: >>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>> This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >>>>>>>=20 >>>>>>> Title : WebRTC Data Channels >>>>>>> Authors : Randell Jesup >>>>>>> Salvatore Loreto >>>>>>> Michael Tuexen >>>>>>> Filename : draft-ietf-rtcweb-data-channel-08.txt >>>>>>> Pages : 15 >>>>>>> Date : 2014-04-09 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> The Real-Time Communication in WEB-browsers working group is = charged >>>>>>> to provide protocol support for direct interactive rich = communication >>>>>>> using audio, video, and data between two peers' web-browsers. = This >>>>>>> document specifies the non-(S)RTP media data transport aspects = of the >>>>>>> WebRTC framework. It provides an architectural overview of how = the >>>>>>> Stream Control Transmission Protocol (SCTP) is used in the = WebRTC >>>>>>> context as a generic transport service allowing WEB-browsers to >>>>>>> exchange generic data from peer to peer. >>>>>> This talks about =93(S)RTP=94 throughout, but the rtp-usage draft = requires that SRTP be used for WebRTC, and disallows plain RTP. I think = this draft could be simplified by changing =93(S)RTP=94 to =93SRTP=94 = throughout. >>>>> Hi Colin, >>>>>=20 >>>>> The (S)RTP notion goes back to a comment from Magnus. If I = remember it correctly he considers SRTP a profile of RTP. Since I don=92t = wanted to just use RTP, I ended up with (S)RTP based on a discussion = with Magnus. >>>>>=20 >>>>> However, I=92m fine with changing it to SRTP... >>>> SRTP is an RTP profile. My comment was that if this is for WebRTC = only, then only SRTP can be used, and not plain RTP. Using =93(S)RTP=94 = rather than =93SRTP=94 in this draft suggests that the secure profile is = optional, which isn=92t the case in WebRTC. If this is for more general = use than WebRTC, then =93(S)RTP=94 is fine. >>> It is clear that in WebRTC only SRTP is used... >> I don=92t believe your draft is clear on that, due to the use of = =93(S)RTP=94 terminology. That=92s why I commented. >>=20 > Enforcing the SRTP-only rule for WebRTC is not the business of this = draft, so it's not a normative statement in any way, shape or form. >=20 > If it's possible to use these channels outside of WebRTC, and some of = these places claim to be able to use pure RTP with appropriate security, = then making use of "SRTP" only in this draft is confusing. >=20 > I see arguments both ways, and want to leave it at editors' = discretion. At least I don't have a strong position. So will edit the document as it = is decided by the WG... (the current version in git uses SRTP, but I'm willing to = change that back) Maybe my co-editors do have a strong position? Best regards Michael >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Fri Apr 11 00:01:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9101A040F for ; Fri, 11 Apr 2014 00:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] autolearn=ham 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 U6PhSGB-dJZ6 for ; Fri, 11 Apr 2014 00:01:46 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id CD7A61A00D1 for ; Fri, 11 Apr 2014 00:01:45 -0700 (PDT) Received: from [192.168.1.103] (p54818011.dip0.t-ipconnect.de [84.129.128.17]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9932A1C104301; Fri, 11 Apr 2014 09:01:43 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <53469905.1080302@alvestrand.no> Date: Fri, 11 Apr 2014 09:01:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <939ACBC6-B086-4F80-987F-082A202AF5D9@lurchi.franken.de> References: <5339A120.3040909@alvestrand.no> <53469905.1080302@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CQ_RGsOFj5myMFd6hQ2_4LWx6O4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 07:01:47 -0000 On 10 Apr 2014, at 15:13, Harald Alvestrand = wrote: > Just checking... since there's been no comment to the main body of the = text here (it's all been on the SCTP aspect), is it OK to include the = text in my next version of the -transport draft? >=20 > (I'm not responding to Karl's comments - it's at a completely = different level of complexity.) >=20 > Harald >=20 > On 03/31/2014 07:08 PM, Harald Alvestrand wrote: >> I see that I have promised to sugggest language for -transport- about >> prioritization. >> Here's an attempt. References and so on to be filled in later. >>=20 >> Comments welcome - this is a first stab! >>=20 >> -------------------------------------------- >> The RTCWEB prioritization model is that the application tells the = RTCWEB >> implementation about the priority of media and data flows through an = API. >>=20 >> The priority associated with a media or data flow is classified as >> "normal", "below normal", "high" or "very high". There are only four >> priority levels at the API. >>=20 >> The RTCWEB implementation is responsible for mapping these to = protocol >> mechanics at the protocol interfaces, and to behave appropriately = when >> choosing what packets to send when. >>=20 >> [draft-dhesikan] specifies the mapping of the four levels of = priority, >> combined with the media type, to DSCP markings. This marking SHOULD = be >> done; the implementation MAY turn off use of DSCP markings if it = detects >> symptoms of unexpected behaviour like priority inversion or blocking = of >> packets with certain DSCP markings. The detection of these conditions = is >> implementation dependent. (Question: Does there need to be an API = knob >> to turn off DSCP markings?) >>=20 >> When an RTCWEB implementation has packets to send on multiple streams >> that are congestion-controlled under the same congestion controller, = the >> RTCWEB implementation SHOULD serve the streams in a weighted = round-robin >> fashion, with each level of priority being given twice the = transmission >> capacity of the level below; thus, when congestion occurs, a "very = high" >> priority flow will have the ability to send 8 times as much data as a >> "below normal" flow if both have data to send. This prioritization is >> independent of the media type, but will lead to packet loss due to = full >> send buffers occuring first on the highest volume flows at any given >> priority level. The details of which packet to send first are >> implementation defined. The text reads good to me. >>=20 >> -- TODO: Specify a relative priority scheme that makes sense with = SCTP, >> with an appropriate reference. [draft-ietf-tsvwg-sctp-prpolicies] >> specifies a priority policy, but it's about discarding packets, not >> deciding which packets to send first, and it also makes it impossible = to >> specify time-bounded retransmission. -- No sure about this TODO. The priorities in = draft-ietf-tsvwg-sctp-prpolicies are not related to the kind of priorities you describe above. Your above = apply also to reliable channels. Best regards Michael >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Fri Apr 11 00:23:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B141A0121 for ; Fri, 11 Apr 2014 00:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 FjGOP6x33BPT for ; Fri, 11 Apr 2014 00:23:29 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDD71A0106 for ; Fri, 11 Apr 2014 00:23:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EE2AC7C51F0; Fri, 11 Apr 2014 09:23:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIhUfpFPM-Cz; Fri, 11 Apr 2014 09:23:27 +0200 (CEST) Received: from [172.28.209.191] (unknown [74.125.57.33]) by mork.alvestrand.no (Postfix) with ESMTPSA id BCD8C7C51EF; Fri, 11 Apr 2014 09:23:26 +0200 (CEST) Message-ID: <5347986D.5030307@alvestrand.no> Date: Fri, 11 Apr 2014 09:23:25 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Tuexen References: <5339A120.3040909@alvestrand.no> <53469905.1080302@alvestrand.no> <939ACBC6-B086-4F80-987F-082A202AF5D9@lurchi.franken.de> In-Reply-To: <939ACBC6-B086-4F80-987F-082A202AF5D9@lurchi.franken.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/niThNpBaQWB4KgAYTh32FETm6a0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 07:23:34 -0000 On 04/11/2014 09:01 AM, Michael Tuexen wrote: > On 10 Apr 2014, at 15:13, Harald Alvestrand wrote: > >> Just checking... since there's been no comment to the main body of the text here (it's all been on the SCTP aspect), is it OK to include the text in my next version of the -transport draft? >> >> (I'm not responding to Karl's comments - it's at a completely different level of complexity.) >> >> Harald >> >> On 03/31/2014 07:08 PM, Harald Alvestrand wrote: >>> I see that I have promised to sugggest language for -transport- about >>> prioritization. >>> Here's an attempt. References and so on to be filled in later. >>> >>> Comments welcome - this is a first stab! >>> >>> -------------------------------------------- >>> The RTCWEB prioritization model is that the application tells the RTCWEB >>> implementation about the priority of media and data flows through an API. >>> >>> The priority associated with a media or data flow is classified as >>> "normal", "below normal", "high" or "very high". There are only four >>> priority levels at the API. >>> >>> The RTCWEB implementation is responsible for mapping these to protocol >>> mechanics at the protocol interfaces, and to behave appropriately when >>> choosing what packets to send when. >>> >>> [draft-dhesikan] specifies the mapping of the four levels of priority, >>> combined with the media type, to DSCP markings. This marking SHOULD be >>> done; the implementation MAY turn off use of DSCP markings if it detects >>> symptoms of unexpected behaviour like priority inversion or blocking of >>> packets with certain DSCP markings. The detection of these conditions is >>> implementation dependent. (Question: Does there need to be an API knob >>> to turn off DSCP markings?) >>> >>> When an RTCWEB implementation has packets to send on multiple streams >>> that are congestion-controlled under the same congestion controller, the >>> RTCWEB implementation SHOULD serve the streams in a weighted round-robin >>> fashion, with each level of priority being given twice the transmission >>> capacity of the level below; thus, when congestion occurs, a "very high" >>> priority flow will have the ability to send 8 times as much data as a >>> "below normal" flow if both have data to send. This prioritization is >>> independent of the media type, but will lead to packet loss due to full >>> send buffers occuring first on the highest volume flows at any given >>> priority level. The details of which packet to send first are >>> implementation defined. > The text reads good to me. >>> -- TODO: Specify a relative priority scheme that makes sense with SCTP, >>> with an appropriate reference. [draft-ietf-tsvwg-sctp-prpolicies] >>> specifies a priority policy, but it's about discarding packets, not >>> deciding which packets to send first, and it also makes it impossible to >>> specify time-bounded retransmission. -- > No sure about this TODO. The priorities in draft-ietf-tsvwg-sctp-prpolicies are > not related to the kind of priorities you describe above. Your above apply > also to reliable channels. We've already settled that none of the current policies in -ndata do what the WG wants (weighted round robin), so I think it's correct to leave this as a TODO, and punt this to TSVWG. > > Best regards > Michael >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> -- Surveillance is pervasive. Go Dark. From nobody Fri Apr 11 03:16:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717011A05C3 for ; Fri, 11 Apr 2014 03:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.373 X-Spam-Level: X-Spam-Status: No, score=-8.373 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 WNpfcN9ai8Nq for ; Fri, 11 Apr 2014 03:16:02 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id BF30D1A0573 for ; Fri, 11 Apr 2014 03:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2563; q=dns/txt; s=iport; t=1397211361; x=1398420961; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=e4lQEKBwcco2cm19yPZV5KlDsr9wOMHNYs+YmmS0OUQ=; b=AoY1/v/afUXIwU7tDzsfvqlpto9JtKzMylwQwU2JehSpjzeUdCEuCtfx Xr2p51EKXwptUK4Eitpc97DMlQfuw7qVAZ1nPjO91KyT/ZZ30QXNdBdHU N7YDpSx25XKIjPDYYptPA2spUsLAuD8TOzE5DbG75FPQBdnTk5+eQR6Wo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADzAR1OtJV2d/2dsb2JhbABZgwaBEsREgRsWdIIlAQEBBDpPAgEIEQMBAh8QIREdCAIEARIbh00DEcUlDYZjF4xTgiCEOASWcoFujHOFT4MxgWkkHg X-IronPort-AV: E=Sophos;i="4.97,841,1389744000"; d="scan'208";a="34905880" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 11 Apr 2014 10:16:00 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3BAG19w016028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 10:16:01 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.219]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 05:16:00 -0500 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" , Oleg Moskalenko Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPU9ox18KS0rN1tEWX369fwer6hpsM5mAA Date: Fri, 11 Apr 2014 10:16:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [173.39.64.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <2B665FCD3E45FF40BA4640005BE9EEB3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/piqUhLENhV19P6psy5OwsfBn8Ws Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 10:16:07 -0000 Hi Ted, Thanks for forwarding the feedback from Oleg. Please see inline for answers > > >From: Ted Hardie >Date: Monday, 7 April 2014 11:50 pm >To: "rtcweb@ietf.org" , Oleg Moskalenko > >Subject: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness > > >Howdy, > > >The chairs recently asked for a review >draft-ietf-rtcweb-stun-consent-freshness; Oleg was kind enough to do one. >Below is the review. > >regards, > >Ted > > > >On Fri, Apr 4, 2014 at 12:40 AM, Oleg Moskalenko >wrote: >Hi Ted > > >I went through the document and I have two things to comment: > > >1) This document defines a "voluntary" pattern of the browser behavior. >Nothing stops the determined attacker from taking the WebRTC code and >creating a malicious client application that ignores all proposed >connectivity checks. May be it is worth mentioning > in the "Security Considerations" section. Agree. A malicious browser that does not conform to this spec can do any thing. I am not sure if we really any text to be added for that in the draft. > > >2) I have a feeling that the document is written with somewhat optimistic >idea about the modern IP network qualities. The proposed timeouts are >probably too small. I am hearing from our TURN server users that in modern >Wi Fi public networks that's common to > observe a freeze the IP traffic for several seconds. After that "freeze" >the connectivity is restored. The users do not want the connection to be >broken during that time - they want the video screen frozen, temporary. I >had to make adjustments to the TURN > server in our recent versions so that it does not disconnects the >sessions too quickly under those conditions (when TCP is used). I have a >feeling that you may have the same complains that the browser stops >transmission in public Wi Fi networks too quickly. > I'd suggest to review the wording of the proposal (like re-transmission >after 500 ms and 15 secs timeout) to make it more tolerant for the bad IP >networks (which are surprisingly are rather common). Agree. We had revised a lot of text in the solution description section of the draft (draft-ietf-rtcweb-stun-consent-freshness-02). The text now is very generic and does not assume any specific timer values. Please review the latest text and let us know if that looks ok. Regards, Ram > > >Overall, I think that this proposal is very useful. > > >Best regards, >Oleg > From nobody Fri Apr 11 03:49:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31E81A01CE for ; Fri, 11 Apr 2014 03:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1] autolearn=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 SnbZVdTR3Vof for ; Fri, 11 Apr 2014 03:49:43 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id 403E71A00FB for ; Fri, 11 Apr 2014 03:49:42 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404111249387034; Fri, 11 Apr 2014 12:49:38 +0200 From: "Karl Stahl" To: "'Harald Alvestrand'" , References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> Date: Fri, 11 Apr 2014 12:49:44 +0200 Message-ID: <014201cf5573$c02ae3b0$4080ab10$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPVTeOIZagSP6uQkS1AgMrcrQE2JsLugCAgABAKVCAAECrQA== Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IUAfPkwERTGkC1WQW6p9J_xeZvk Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 10:49:46 -0000 Harald, Just remembered regarding ICE Lite in your transport document; I think = your statement regarding ICE, not ICE Lite therein, should be clarified so it = is understood that browsers must (also) operate against ICE Lite devices (typical for a gateway). (That is the way it already works in Chrome - buggy in Firefox though) =20 /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Christer Holmberg Skickat: den 11 april 2014 08:52 Till: Ram Mohan R (rmohanr); rtcweb@ietf.org =C4mne: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt Hi, I think it would be good to have some text about usage of consent = freshness when one entity is ICE lite. And, I think it would be good to make it more clear that the usage of consent is always negotiated per direction. Thanks! Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: 11. huhtikuuta 2014 8:01 To: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt Summary of changes in this revision Addressed the comments received from the WG. Removed the timers definition from solution overview and made the text = more generic. Incorporated text from draft-thomson-rtcweb-consent. Most of the text of solution overview is re-written however the idea is still kept intact Comments are welcome. There is still some dangling reference (text) to SRTP/DTLS mechanism for consent which we will modify in the next revision Regards, Authors -----Original Message----- From: "internet-drafts@ietf.org" Date: Friday, 11 April 2014 9:07 am To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Real-Time Communication in=20 >WEB-browsers Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-02.txt > Pages : 8 > Date : 2014-04-10 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic = consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new STUN usage. > This same mechanism can also determine connection loss ("liveness") > with a remote peer. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshne >ss/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshn= e >ss- >02 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Apr 11 03:55:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AA31A0649 for ; Fri, 11 Apr 2014 03:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 UcjDQa0BHm-9 for ; Fri, 11 Apr 2014 03:54:58 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 726CA1A0642 for ; Fri, 11 Apr 2014 03:54:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 35F787C51FA; Fri, 11 Apr 2014 12:54:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE5l1t2dsoUn; Fri, 11 Apr 2014 12:54:55 +0200 (CEST) Received: from [172.28.209.191] (unknown [74.125.57.33]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0804D7C51F7; Fri, 11 Apr 2014 12:54:54 +0200 (CEST) Message-ID: <5347C9FD.7000609@alvestrand.no> Date: Fri, 11 Apr 2014 12:54:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Karl Stahl , rtcweb@ietf.org References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> <014201cf5573$c02ae3b0$4080ab10$@stahl@intertex.se> In-Reply-To: <014201cf5573$c02ae3b0$4080ab10$@stahl@intertex.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HnIjUuKCKcV6Y9BHbE1jYkh1B24 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 10:55:02 -0000 On 04/11/2014 12:49 PM, Karl Stahl wrote: > Harald, > > Just remembered regarding ICE Lite in your transport document; I think your > statement regarding ICE, not ICE Lite therein, should be clarified so it is > understood that browsers must (also) operate against ICE Lite devices > (typical for a gateway). Huh? As far as I understand ICE-Lite, any full ICE implementation will interoperate with an ICE-Lite implementation without any special handling. Thus, any ICE implementation that doesn't do so has a bug. I don't want to put in the document a statement that says "MUST implement ICE and MUST NOT have bugs that prevent interoperability with ICE-Lite". That's just not helpful. > > (That is the way it already works in Chrome - buggy in Firefox though) > > /Karl > > -----Ursprungligt meddelande----- > Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Christer Holmberg > Skickat: den 11 april 2014 08:52 > Till: Ram Mohan R (rmohanr); rtcweb@ietf.org > Ämne: Re: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-02.txt > > Hi, > > I think it would be good to have some text about usage of consent freshness > when one entity is ICE lite. > > And, I think it would be good to make it more clear that the usage of > consent is always negotiated per direction. > > Thanks! > > Regards, > > Christer > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: 11. huhtikuuta 2014 8:01 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-02.txt > > Summary of changes in this revision > > Addressed the comments received from the WG. > Removed the timers definition from solution overview and made the text more > generic. > Incorporated text from draft-thomson-rtcweb-consent. > Most of the text of solution overview is re-written however the idea is > still kept intact > > > Comments are welcome. > > There is still some dangling reference (text) to SRTP/DTLS mechanism for > consent which we will modify in the next revision > > > Regards, > Authors > > -----Original Message----- > From: "internet-drafts@ietf.org" > Date: Friday, 11 April 2014 9:07 am > To: "i-d-announce@ietf.org" > Cc: "rtcweb@ietf.org" > Subject: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-02.txt > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Real-Time Communication in >> WEB-browsers Working Group of the IETF. >> >> Title : STUN Usage for Consent Freshness >> Authors : Muthu Arul Mozhi Perumal >> Dan Wing >> Ram Mohan Ravindranath >> Tirumaleswar Reddy >> Martin Thomson >> Filename : draft-ietf-rtcweb-stun-consent-freshness-02.txt >> Pages : 8 >> Date : 2014-04-10 >> >> Abstract: >> To prevent sending excessive traffic to an endpoint, periodic consent >> needs to be obtained from that remote endpoint. >> >> This document describes a consent mechanism using a new STUN usage. >> This same mechanism can also determine connection loss ("liveness") >> with a remote peer. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshne >> ss/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshne >> ss- >> 02 >> >> >> 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/ >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Surveillance is pervasive. Go Dark. From nobody Fri Apr 11 10:42:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EE61A072A for ; Fri, 11 Apr 2014 10:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 FS1nsPkbfxKJ for ; Fri, 11 Apr 2014 10:42:48 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0978F1A0706 for ; Fri, 11 Apr 2014 10:42:47 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id eb12so6559386oac.16 for ; Fri, 11 Apr 2014 10:42:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=WwJtCkiOqQmbzSI8i6ztdG2YCJP1Rio8ZwmY4sfH+hw=; b=E95N9Z/M1oBFtOIgZ7Cau7Wt0Smc/mjafA/7FoXWg3D3x216xx2Wm1EaBfLCHGDVQe ItM5jvEOVygQNG809vI8Z+nNQU8oMb4h6Tkp0fOLmZDZkDP9y0w38MaXtIdEN7QHETYw 3f5uiAWTeKvM80KfjLvH8wSRzBye3I+is1aEZZNf89A4yOo1D3jkCQ15hThqh2ruFVbx eRjRgX4EC6XFzcAqRzowNTELQQbsNDT76R+wGjaYOxwXriMa0lUqpfeQyJ6zz3hxekqX VA++2lAnV/a5JT3WN39PFTMWfw84oQQ/NqgL9IZwSwj6vQlk54LR/es0aaT3DR/puNOz 6ffQ== X-Gm-Message-State: ALoCoQlc5JxhzJiK5WvcDEL1LCZCFDdTdQY+Raf940hTBWNg6yD8bVVZHCL5jqEgpZ7zqwZjOFNt MIME-Version: 1.0 X-Received: by 10.60.141.70 with SMTP id rm6mr20618400oeb.27.1397238166451; Fri, 11 Apr 2014 10:42:46 -0700 (PDT) Received: by 10.60.136.231 with HTTP; Fri, 11 Apr 2014 10:42:46 -0700 (PDT) Date: Fri, 11 Apr 2014 13:42:46 -0400 Message-ID: From: Richard Barnes To: draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org, "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7b33c8fa9409f804f6c7dc68 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jKeh3y1FJ5UzqrzWRDU14XqEnHk Subject: [rtcweb] AD review of draft-ietf-rtcweb-use-cases-and-requirements-14 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:42:49 -0000 --047d7b33c8fa9409f804f6c7dc68 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document in preparation for IETF LC. Overall, it looks good to me; I have requested LC. Thanks, --Richard --047d7b33c8fa9409f804f6c7dc68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document in preparation for IETF= LC. =A0Overall, it looks good to me; I have requested LC. =A0
Thanks,
--Richard

--047d7b33c8fa9409f804f6c7dc68-- From nobody Fri Apr 11 10:52:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39041A0736 for ; Fri, 11 Apr 2014 10:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 mo16xfUqsTVA for ; Fri, 11 Apr 2014 10:52:03 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 35B861A073E for ; Fri, 11 Apr 2014 10:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4669; q=dns/txt; s=iport; t=1397238722; x=1398448322; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dmWDVol1r+qTBuZUs65n1EDx43VeSgV3eCcWiw4fHCg=; b=m3HJ2fCrhcCxACQN0u6x1MRO5cAZon7lFJqXiySDmKb6E5q2MXXriGo5 /FCmc2zBtBLIsirq3tP4JX2OmZW6qrF1+Kfm5yJn6PA74c1wWcX0KDFNh spKKxWGUg0OVNDU/gb3iUhjN/VCxOsd2iH6EVC6gUShP9GNo3g2+k9633 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFABUrSFOtJA2L/2dsb2JhbABZgwY7UQa9HYZkUYEeFnSCJQEBAQQBAQE3NBcEAgEIEQMBAQEfCQcnCxQJCAIEARIJEodhCAXLfxeOGwEBHDUFBoQyBJhggTWRDYMxgXI5 X-IronPort-AV: E=Sophos;i="4.97,843,1389744000"; d="scan'208";a="317142839" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 11 Apr 2014 17:52:01 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3BHq1t1024523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 17:52:01 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.219]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 12:52:01 -0500 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt Thread-Index: AQHPVa68NGhvZFhC3EOKQCShwM72RQ== Date: Fri, 11 Apr 2014 17:52:00 +0000 Message-ID: References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.34.193] Content-Type: text/plain; charset="us-ascii" Content-ID: <73DC8948D93BE847937A0103983BCA10@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/urULR4imjyDLmXVPaaXWwEA4wO8 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:52:06 -0000 Found this mail thread in the archives where this issue was discussed but we have not reached to any conclusion - https://www.ietf.org/mail-archive/web/rtcweb/current/msg04887.html With ICE-lite mode since the ICE-lite endpoint does not typically generate any binding requests, it may not generate STUN consent as well. This would means a malicious application (running on a ICE-lite endpoint) can use it for sending unwanted traffic. Should we mandate an ICE-lite implementation to generate a STUN consent request to its peer before it can send media ? Regards, Ram -----Original Message----- From: Ram Mohan Ravindranath Date: Friday, 11 April 2014 12:23 pm To: Christer Holmberg , "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt >Sure. We will add text for these two in the next revision. > >Thanks, >Ram > >-----Original Message----- >From: Christer Holmberg >Date: Friday, 11 April 2014 12:22 pm >To: Ram Mohan Ravindranath , "rtcweb@ietf.org" > >Subject: RE: [rtcweb] I-D Action: >draft-ietf-rtcweb-stun-consent-freshness-02.txt > >>Hi, >> >>I think it would be good to have some text about usage of consent >>freshness when one entity is ICE lite. >> >>And, I think it would be good to make it more clear that the usage of >>consent is always negotiated per direction. >> >>Thanks! >> >>Regards, >> >>Christer >> >> >>-----Original Message----- >>From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R >>(rmohanr) >>Sent: 11. huhtikuuta 2014 8:01 >>To: rtcweb@ietf.org >>Subject: Re: [rtcweb] I-D Action: >>draft-ietf-rtcweb-stun-consent-freshness-02.txt >> >>Summary of changes in this revision >> >>Addressed the comments received from the WG. >>Removed the timers definition from solution overview and made the text >>more generic. >>Incorporated text from draft-thomson-rtcweb-consent. >>Most of the text of solution overview is re-written however the idea is >>still kept intact >> >> >>Comments are welcome. >> >>There is still some dangling reference (text) to SRTP/DTLS mechanism for >>consent which we will modify in the next revision >> >> >>Regards, >>Authors >> >>-----Original Message----- >>From: "internet-drafts@ietf.org" >>Date: Friday, 11 April 2014 9:07 am >>To: "i-d-announce@ietf.org" >>Cc: "rtcweb@ietf.org" >>Subject: [rtcweb] I-D Action: >>draft-ietf-rtcweb-stun-consent-freshness-02.txt >> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> This draft is a work item of the Real-Time Communication in >>>WEB-browsers Working Group of the IETF. >>> >>> Title : STUN Usage for Consent Freshness >>> Authors : Muthu Arul Mozhi Perumal >>> Dan Wing >>> Ram Mohan Ravindranath >>> Tirumaleswar Reddy >>> Martin Thomson >>> Filename : draft-ietf-rtcweb-stun-consent-freshness-02.txt >>> Pages : 8 >>> Date : 2014-04-10 >>> >>>Abstract: >>> To prevent sending excessive traffic to an endpoint, periodic consent >>> needs to be obtained from that remote endpoint. >>> >>> This document describes a consent mechanism using a new STUN usage. >>> This same mechanism can also determine connection loss ("liveness") >>> with a remote peer. >>> >>> >>>The IETF datatracker status page for this draft is: >>>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshne >>>ss/ >>> >>>There's also a htmlized version available at: >>>http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-02 >>> >>>A diff from the previous version is available at: >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshn= e >>>ss- >>>02 >>> >>> >>>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/ >>> >>>_______________________________________________ >>>rtcweb mailing list >>>rtcweb@ietf.org >>>https://www.ietf.org/mailman/listinfo/rtcweb >> >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf.org >>https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Fri Apr 11 11:23:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FEB1A033B for ; Fri, 11 Apr 2014 11:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 SmWPlHHqi5Ij for ; Fri, 11 Apr 2014 11:23:23 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EFAF81A02D1 for ; Fri, 11 Apr 2014 11:23:22 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so1477947wib.5 for ; Fri, 11 Apr 2014 11:23:21 -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:content-type; bh=rI/UE5KM82QHebDYXztqp4zfYe1JauLGPwwpiBtJFlk=; b=CBNtQ2VntBtLAU+Sfk2w2BEZVzGbBVsoTrCaKcGDcLh/jR8rTvFWgu2GPJvpjenHds anIY/XFmjmSpGadGTcfMV+73Kivyf9VmJz5f1+3CbL4clmUjC4V2sO24RIOHB9xe/g6k e9+L6K4LQzyjuNLgBiXF04Rn2C5K7hxTxFEwIkI2LGGcGi5kYAtwPhmEI+LxuU+efbFE 0982gQYrxXM7YN9AeRY+bzHNPuOZl3kKDj2LCEzuZ946ZoUuLSkQ9l2lEHaXovpjjVA5 rd2boajDLK4LLvWd16pkdFv+HA65pPjYONMss1TUXL0N4e5PFC+Ii3JebrZT60ZOMnSx PQaw== MIME-Version: 1.0 X-Received: by 10.180.82.133 with SMTP id i5mr2279373wiy.50.1397240601175; Fri, 11 Apr 2014 11:23:21 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Fri, 11 Apr 2014 11:23:21 -0700 (PDT) In-Reply-To: References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> Date: Fri, 11 Apr 2014 11:23:21 -0700 Message-ID: From: Martin Thomson To: "Ram Mohan R (rmohanr)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Lnt9JfjgJ5byv4ixh2JX-i-wruE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:23:24 -0000 On 11 April 2014 10:52, Ram Mohan R (rmohanr) wrote: > With ICE-lite mode since the ICE-lite endpoint does not typically generate > any binding requests, it may not generate STUN consent as well. Wat? Consent is generated by responding to connectivity checks. An ICE-lite endpoint has to do that. From nobody Fri Apr 11 13:13:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849F91A033B; Fri, 11 Apr 2014 13:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 IkTzKPQzD159; Fri, 11 Apr 2014 13:13:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2680B1A0734; Fri, 11 Apr 2014 13:13:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140411201321.28167.9325.idtracker@ietfa.amsl.com> Date: Fri, 11 Apr 2014 13:13:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Rpy_AFQYZstsFfj3kHlkJeNgxTk Cc: rtcweb@ietf.org Subject: [rtcweb] Last Call: (Web Real-Time Communication Use-cases and Requirements) to Informational RFC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:13:40 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'Web Real-Time Communication Use-cases and Requirements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes web based real-time communication use-cases. Requirements on the browser functionality are derived from the use- cases. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 11 13:38:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EB41A022E for ; Fri, 11 Apr 2014 13:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 t4FOeVPcbqL7 for ; Fri, 11 Apr 2014 13:38:02 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id CE4DC1A02EA for ; Fri, 11 Apr 2014 13:37:58 -0700 (PDT) X-AuditID: c1b4fb3a-f79226d0000010eb-fb-534852a4a0bd Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 30.40.04331.4A258435; Fri, 11 Apr 2014 22:37:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Fri, 11 Apr 2014 22:37:55 +0200 From: Christer Holmberg To: Martin Thomson , "Ram Mohan R (rmohanr)" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt Thread-Index: AQHPVTeOIZagSP6uQkS1AgMrcrQE2JsLugCAgABAKVD//9+CAIAAt9gAgAAIw4CAAEbFcA== Date: Fri, 11 Apr 2014 20:37:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2BF6E5@ESESSMB209.ericsson.se> References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje6SII9gg83HJC2unfnHaLG8awej xdp/7ewOzB5Tfm9k9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mi4fv8FesIil4sLMrywN jFNYuhg5OSQETCR+P37GDGGLSVy4t56ti5GLQ0jgKKPE2bMTwRJCAksYJRofyHUxcnCwCVhI dP/TBgmLCMRIXJ6+nxHEZhZQl7iz+Bw7iC0sECwx49c+VoiaEIk909YyQ9hhEovWzGIDsVkE VCU+PLsLdgOvgK/Ew3dLWCD27mSSuNG6AyzBKRAosfAZhM0IdNz3U2uYIJaJS9x6Mp8J4mgB iSV7zkM9ICrx8vE/VghbSWLt4e0sIDczC2hKrN+lD9GqKDGl+yE7xF5BiZMzn7BMYBSbhWTq LISOWUg6ZiHpWMDIsopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMJ4ObvlttYPx4HPHQ4wC HIxKPLzHFrkHC7EmlhVX5h5ilOZgURLnnQQSEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwGhq KLdgD+vdxP5yzz1LDwj/ZH4otXTfQ/55ZjP3f788ZTvnjthYfvelDFccTNy3vvi+t4ntvJ9p n35hb5WJ4y75oxYT3l5kFn6waKGFa9PjsnpR6bijhgxJz4LVbnFeMfkqeX1tgUvDg+ZnMzbs 3uMamlO1Inb95XqL6jvPZGf3Tis7tbdc/JsSS3FGoqEWc1FxIgDKZDyciAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fny5D7NKnsyC-zLj2zgyDqNoLt4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:38:03 -0000 SGksDQoNCj4+IFdpdGggSUNFLWxpdGUgbW9kZSBzaW5jZSB0aGUgSUNFLWxpdGUgZW5kcG9pbnQg ZG9lcyBub3QgdHlwaWNhbGx5IA0KPj4gZ2VuZXJhdGUgYW55IGJpbmRpbmcgcmVxdWVzdHMsIGl0 IG1heSBub3QgZ2VuZXJhdGUgU1RVTiBjb25zZW50IGFzIHdlbGwuDQo+DQo+V2F0Pw0KPg0KPkNv bnNlbnQgaXMgZ2VuZXJhdGVkIGJ5IHJlc3BvbmRpbmcgdG8gY29ubmVjdGl2aXR5IGNoZWNrcy4g IEFuIElDRS1saXRlIGVuZHBvaW50IGhhcyB0byBkbyB0aGF0Lg0KDQpTdXJlLCBidXQgSSBndWVz cyB3aGF0IGlzIG1lYW50IGlzIHRoYXQgdGhlIElDRS1saXRlIGVuZHBvaW50IGRvZXMgbm90IGdl bmVyYXRlIFNUVU4gY29uc2VudCBSRVFVRVNUUy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From nobody Fri Apr 11 16:06:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6941B1A02B6 for ; Fri, 11 Apr 2014 16:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 Oiba6PTNOVHb for ; Fri, 11 Apr 2014 16:06:17 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id 719771A0228 for ; Fri, 11 Apr 2014 16:06:15 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404120106127951; Sat, 12 Apr 2014 01:06:12 +0200 From: "Karl Stahl" To: "'Harald Alvestrand'" , References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> <014201cf5573$c02ae3b0$4080ab10$@stahl@intertex.se> <5347C9FD.7000609@alvestrand.no> In-Reply-To: <5347C9FD.7000609@alvestrand.no> Date: Sat, 12 Apr 2014 01:06:18 +0200 Message-ID: <021801cf55da$a5f01580$f1d04080$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9VdHoYaFJtUvwnTNO8fPmBSduRXQAZLD2g Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YlYyiB3kib8w-Tk7gfySFJoRh9E Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 23:06:19 -0000 -----Ursprungligt meddelande----- Fr=E5n: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Skickat: den 11 april 2014 12:55 Till: Karl Stahl; rtcweb@ietf.org =C4mne: Re: SV: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt On 04/11/2014 12:49 PM, Karl Stahl wrote: > Harald, > > Just remembered regarding ICE Lite in your transport document; I think = > your statement regarding ICE, not ICE Lite therein, should be=20 > clarified so it is understood that browsers must (also) operate=20 > against ICE Lite devices (typical for a gateway). Huh? As far as I understand ICE-Lite, any full ICE implementation will interoperate with an ICE-Lite implementation without any special = handling. Thus, any ICE implementation that doesn't do so has a bug. --- Agree, that is correct. I don't want to put in the document a statement that says "MUST = implement ICE and MUST NOT have bugs that prevent interoperability with ICE-Lite". That's just not helpful. --- I am sure you can express it in a way that WOULD be helpful :) (I = myself had to ask our developers to get that understanding, so, just a point to make it clearer and avoid doubts - we are not all experts on the details = of all specs.)=20 /Karl > > (That is the way it already works in Chrome - buggy in Firefox though) > =20 > /Karl > > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Christer = Holmberg > Skickat: den 11 april 2014 08:52 > Till: Ram Mohan R (rmohanr); rtcweb@ietf.org > =C4mne: Re: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-02.txt > > Hi, > > I think it would be good to have some text about usage of consent=20 > freshness when one entity is ICE lite. > > And, I think it would be good to make it more clear that the usage of=20 > consent is always negotiated per direction. > > Thanks! > > Regards, > > Christer > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: 11. huhtikuuta 2014 8:01 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-02.txt > > Summary of changes in this revision > > Addressed the comments received from the WG. > Removed the timers definition from solution overview and made the text = > more generic. > Incorporated text from draft-thomson-rtcweb-consent. > Most of the text of solution overview is re-written however the idea=20 > is still kept intact > > > Comments are welcome. > > There is still some dangling reference (text) to SRTP/DTLS mechanism=20 > for consent which we will modify in the next revision > > > Regards, > Authors > > -----Original Message----- > From: "internet-drafts@ietf.org" > Date: Friday, 11 April 2014 9:07 am > To: "i-d-announce@ietf.org" > Cc: "rtcweb@ietf.org" > Subject: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-02.txt > >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> This draft is a work item of the Real-Time Communication in=20 >> WEB-browsers Working Group of the IETF. >> >> Title : STUN Usage for Consent Freshness >> Authors : Muthu Arul Mozhi Perumal >> Dan Wing >> Ram Mohan Ravindranath >> Tirumaleswar Reddy >> Martin Thomson >> Filename : draft-ietf-rtcweb-stun-consent-freshness-02.txt >> Pages : 8 >> Date : 2014-04-10 >> >> Abstract: >> To prevent sending excessive traffic to an endpoint, periodic = consent >> needs to be obtained from that remote endpoint. >> >> This document describes a consent mechanism using a new STUN usage. >> This same mechanism can also determine connection loss ("liveness") >> with a remote peer. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-fresh >> ne >> ss/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-0 >> 2 >> >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-fresh >> ne >> ss- >> 02 >> >> >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Surveillance is pervasive. Go Dark. From nobody Fri Apr 11 22:59:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ACD1A0222 for ; Fri, 11 Apr 2014 22:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 7e814KwSt62j for ; Fri, 11 Apr 2014 22:59:18 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6A01A0079 for ; Fri, 11 Apr 2014 22:59:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DEFF97C50EE; Sat, 12 Apr 2014 07:59:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICh2b2nMXWar; Sat, 12 Apr 2014 07:59:12 +0200 (CEST) Received: from [10.208.103.239] (host-95-195-135-239.mobileonline.telia.com [95.195.135.239]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5B3D97C0D40; Sat, 12 Apr 2014 07:59:12 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2BF6E5@ESESSMB209.ericsson.se> References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2BF6E5@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----D1RHT21879OWJI9N0U0WG6CHXQ7O7B" Content-Transfer-Encoding: 8bit From: Harald Alvestrand Date: Sat, 12 Apr 2014 07:59:09 +0200 To: Christer Holmberg , Martin Thomson , "Ram Mohan R (rmohanr)" Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/y_SufRkKpHgNTZgZhLd3PWtfJkU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 05:59:22 -0000 ------D1RHT21879OWJI9N0U0WG6CHXQ7O7B Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Seems we have another reason why running a browser on ice-lite is a bad idea. Good that we do not allow that. On 11. april 2014 22:37:55 CEST, Christer Holmberg wrote: >Hi, > >>> With ICE-lite mode since the ICE-lite endpoint does not typically >>> generate any binding requests, it may not generate STUN consent as >well. >> >>Wat? >> >>Consent is generated by responding to connectivity checks. An >ICE-lite endpoint has to do that. > >Sure, but I guess what is meant is that the ICE-lite endpoint does not >generate STUN consent REQUESTS. > >Regards, > >Christer >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------D1RHT21879OWJI9N0U0WG6CHXQ7O7B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Seems we have another reason why running a browser on ice-lite is a bad idea. Good that we do not allow that.

On 11. april 2014 22:37:55 CEST, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

 With ICE-lite mode since the ICE-lite endpoint does not typically 
 generate any binding requests, it may not generate STUN consent as well.

Wat?

Consent is generated by responding to connectivity checks.  An ICE-lite endpoint has to do that.

Sure, but I guess what is meant is that the ICE-lite endpoint does not generate STUN consent REQUESTS.

Regards,

Christer

rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------D1RHT21879OWJI9N0U0WG6CHXQ7O7B-- From nobody Sat Apr 12 01:26:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA6A1A015A for ; Sat, 12 Apr 2014 01:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 iDnCpCwIq10x for ; Sat, 12 Apr 2014 01:26:31 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id A109B1A00BF for ; Sat, 12 Apr 2014 01:26:30 -0700 (PDT) X-AuditID: c1b4fb3a-f79226d0000010eb-78-5348f8b35ae2 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3E.52.04331.3B8F8435; Sat, 12 Apr 2014 10:26:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Sat, 12 Apr 2014 10:26:27 +0200 From: Christer Holmberg To: Harald Alvestrand , Martin Thomson , "Ram Mohan R (rmohanr)" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt Thread-Index: AQHPVTeOIZagSP6uQkS1AgMrcrQE2JsLugCAgABAKVD//9+CAIAAt9gAgAAIw4CAAEbFcIAAe6KAgABKBnA= Date: Sat, 12 Apr 2014 08:26:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2BFE90@ESESSMB209.ericsson.se> References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2BF6E5@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2BFE90ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM+Jvje6WHx7BBs/W8Foc6+tis7h25h+j xfKuHYwWa/+1szuweFyZcIXVY8rvjaweO2fdZfdYsuQnUwBLFJdNSmpOZllqkb5dAlfG8SN1 BYdCKw52TGNvYJwS3MXIySEhYCKxa/oSRghbTOLCvfVsILaQwFFGid+vhLoYuYDsJYwSn3qO s3YxcnCwCVhIdP/TBomLCLQxSrz8u4AdpIFZQF3izuJzYLawQLDEjF/7WEFsEYEQiT3T1jJD 2EkSWw/+BouzCKhKPN71FczmFfCVONR3kR1i2Q5miT3HIQZxCrhKTJp/HqyIEei676fWMEEs E5e49WQ+E8TVAhJL9pxnhrBFJV4+/scKYStJLLr9Gao+X2LHn8tsEMsEJU7OfMIygVF0FpJR s5CUzUJSNgvoZ2YBTYn1u/QhShQlpnQ/ZIewNSRa58xlRxZfwMi+ilG0OLW4ODfdyEgvtSgz ubg4P08vL7VkEyMwKg9u+W21g/Hgc8dDjAIcjEo8vMcWuQcLsSaWFVfmHmKU5mBREuedBBIS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOH/Bu0uzawr1Fv7cXT991Yw0PYWo/1wSZ/fYLE1k F4wzj3EI2qbqqP/oprSyUWXHre+ryieWa6SUHM1xOr2pRfEVk0yp0eOXrBJsOevTJH9xJtpq HT3+LFLCa3P4udtzEt3CVj20UtVPXn/pygbdnEOvn1+qi923ZsFR3668mSfOyUvuX8YtqsRS nJFoqMVcVJwIABA4QtKrAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1b9U0rhML37Q0Cw5rAsSAnRZoO8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 08:26:33 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2BFE90ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkl04oCZcyBub3QgYWJvdXQgcnVubmluZyBhIGJyb3dzZXIgb24gaWNlLWxpdGUg4oCT IGl0IGlzIGFib3V0IGEgYnJvd3NlciBiZWluZyBwcmVwYXJlZCB0byBydW4gd2l0aCBhIHJlbW90 ZSBlbmRwb2ludCB0aGF0IGlzIHJ1bm5pbmcgaWNlLWxpdGUgKGUuZy4gYSBnYXRld2F5KS4gQ2Vy dGFpbiBicm93c2VyIGltcGxlbWVudGF0aW9ucyBoYXZlIGhhZCBzb21lIHByb2JsZW1zIHdpdGgg dGhhdCwgYWZhaWvigKYNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogSGFyYWxkIEFs dmVzdHJhbmQgW21haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ub10NClNlbnQ6IDEyIEFwcmlsIDIw MTQgMDg6NTkNClRvOiBDaHJpc3RlciBIb2xtYmVyZzsgTWFydGluIFRob21zb247IFJhbSBNb2hh biBSIChybW9oYW5yKQ0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMDIu dHh0DQoNClNlZW1zIHdlIGhhdmUgYW5vdGhlciByZWFzb24gd2h5IHJ1bm5pbmcgYSBicm93c2Vy IG9uIGljZS1saXRlIGlzIGEgYmFkIGlkZWEuIEdvb2QgdGhhdCB3ZSBkbyBub3QgYWxsb3cgdGhh dC4NCk9uIDExLiBhcHJpbCAyMDE0IDIyOjM3OjU1IENFU1QsIENocmlzdGVyIEhvbG1iZXJnIDxj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KIFdpdGggSUNFLWxpdGUgbW9kZSBzaW5jZSB0 aGUgSUNFLWxpdGUgZW5kcG9pbnQgZG9lcyBub3QgdHlwaWNhbGx5DQogZ2VuZXJhdGUgYW55IGJp bmRpbmcgcmVxdWVzdHMsIGl0IG1heSBub3QgZ2VuZXJhdGUgU1RVTiBjb25zZW50IGFzIHdlbGwu DQoNCldhdD8NCg0KQ29uc2VudCBpcyBnZW5lcmF0ZWQgYnkgcmVzcG9uZGluZyB0byBjb25uZWN0 aXZpdHkgY2hlY2tzLiAgQW4gSUNFLWxpdGUgZW5kcG9pbnQgaGFzIHRvIGRvIHRoYXQuDQoNClN1 cmUsIGJ1dCBJIGd1ZXNzIHdoYXQgaXMgbWVhbnQgaXMgdGhhdCB0aGUgSUNFLWxpdGUgZW5kcG9p bnQgZG9lcyBub3QgZ2VuZXJhdGUgU1RVTiBjb25zZW50IFJFUVVFU1RTLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpydGN3ZWIg bWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCi0tDQpTZW50IGZy b20gbXkgQW5kcm9pZCBkZXZpY2Ugd2l0aCBLLTkgTWFpbC4gUGxlYXNlIGV4Y3VzZSBteSBicmV2 aXR5Lg0K --_000_7594FB04B1934943A5C02806D1A2204B1D2BFE90ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SXTigJlzIG5vdCBhYm91dCBy dW5uaW5nIGEgYnJvd3NlciBvbiBpY2UtbGl0ZSDigJMgaXQgaXMgYWJvdXQgYSBicm93c2VyIGJl aW5nIHByZXBhcmVkIHRvIHJ1biB3aXRoIGEgcmVtb3RlIGVuZHBvaW50IHRoYXQgaXMgcnVubmlu Zw0KIGljZS1saXRlIChlLmcuIGEgZ2F0ZXdheSkuIENlcnRhaW4gYnJvd3NlciBpbXBsZW1lbnRh dGlvbnMgaGF2ZSBoYWQgc29tZSBwcm9ibGVtcyB3aXRoIHRoYXQsIGFmYWlr4oCmPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gSGFyYWxkIEFsdmVzdHJhbmQgW21haWx0bzpoYXJhbGRAYWx2ZXN0cmFu ZC5ub10NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMiBBcHJpbCAyMDE0IDA4OjU5PGJyPg0KPGI+VG86 PC9iPiBDaHJpc3RlciBIb2xtYmVyZzsgTWFydGluIFRob21zb247IFJhbSBNb2hhbiBSIChybW9o YW5yKTxicj4NCjxiPkNjOjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbcnRjd2ViXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQt ZnJlc2huZXNzLTAyLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U2VlbXMgd2UgaGF2ZSBhbm90aGVy IHJlYXNvbiB3aHkgcnVubmluZyBhIGJyb3dzZXIgb24gaWNlLWxpdGUgaXMgYSBiYWQgaWRlYS4g R29vZCB0aGF0IHdlIGRvIG5vdCBhbGxvdyB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDExLiBhcHJpbCAyMDE0IDIyOjM3OjU1IENFU1QsIENocmlz dGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+SGksPG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjNzI5RkNGIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjYuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQUQ3RkE4 IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjYuMHB0Ij4NCjxwcmU+IFdpdGggSUNFLWxpdGUgbW9k ZSBzaW5jZSB0aGUgSUNFLWxpdGUgZW5kcG9pbnQgZG9lcyBub3QgdHlwaWNhbGx5IDxicj4mbmJz cDtnZW5lcmF0ZSBhbnkgYmluZGluZyByZXF1ZXN0cywgaXQgbWF5IG5vdCBnZW5lcmF0ZSBTVFVO IGNvbnNlbnQgYXMgd2VsbC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48 YnI+V2F0Pzxicj48YnI+Q29uc2VudCBpcyBnZW5lcmF0ZWQgYnkgcmVzcG9uZGluZyB0byBjb25u ZWN0aXZpdHkgY2hlY2tzLiZuYnNwOyBBbiBJQ0UtbGl0ZSBlbmRwb2ludCBoYXMgdG8gZG8gdGhh dC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48YnI+U3VyZSwgYnV0IEkg Z3Vlc3Mgd2hhdCBpcyBtZWFudCBpcyB0aGF0IHRoZSBJQ0UtbGl0ZSBlbmRwb2ludCBkb2VzIG5v dCBnZW5lcmF0ZSBTVFVOIGNvbnNlbnQgUkVRVUVTVFMuPGJyPjxicj5SZWdhcmRzLDxicj48YnI+ Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIi PjxociBzaXplPSIzIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+PC9wcmU+DQo8cHJlPjxi cj5ydGN3ZWIgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci PnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0tIDxicj4NClNlbnQgZnJvbSBteSBBbmRyb2lkIGRl dmljZSB3aXRoIEstOSBNYWlsLiBQbGVhc2UgZXhjdXNlIG15IGJyZXZpdHkuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D2BFE90ESESSMB209erics_-- From nobody Sat Apr 12 02:57:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F801A02D3 for ; Sat, 12 Apr 2014 02:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 OQPAwIH2jNb9 for ; Sat, 12 Apr 2014 02:57:09 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id 071DD1A0179 for ; Sat, 12 Apr 2014 02:57:06 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404121157033593; Sat, 12 Apr 2014 11:57:03 +0200 From: "Karl Stahl" To: "'Christer Holmberg'" , "'Harald Alvestrand'" , "'Martin Thomson'" , "'Ram Mohan R \(rmohanr\)'" References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2BF6E5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2BFE90@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2BFE90@ESESSMB209.ericsson.se> Date: Sat, 12 Apr 2014 11:57:10 +0200 Message-ID: <024c01cf5635$92835650$b78a02f0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_024D_01CF5646.560C2650" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPVTeOIZagSP6uQkS1AgMrcrQE2JsLugCAgABAKVD//9+CAIAAt9gAgAAIw4CAAEbFcIAAe6KAgABKBnCAABKvUA== Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PDrQ8LlwEF9sUzgyQpAJvqzJVhk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE-Lite, Was: I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 09:57:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_024D_01CF5646.560C2650 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To avoid confusion=E2=80=A6 =20 Gateways are not mentioned in draft-ietf-rtcweb-transports-03 =20 Under 3.5. Middle box related functions=20 It too simply says: ICE [RFC5245] MUST be supported. The implementation MUST be a full ICE implementation, not ICE-Lite. =20 It needs to be said that gateways, i.e. devices having a media port on a = public IP address =E2=80=93 never behind a NAT/firewall =E2=80=93 SHOULD = implement ICE-Lite. (which browsers implementing full ICE correctly are = compatible with =E2=80=93 and has to be =E2=80=93 which we all have the = same understanding of, I believe) =20 =20 /Karl =20 =20 Fr=C3=A5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Christer = Holmberg Skickat: den 12 april 2014 10:26 Till: Harald Alvestrand; Martin Thomson; Ram Mohan R (rmohanr) Kopia: rtcweb@ietf.org =C3=84mne: Re: [rtcweb] I-D Action: = draft-ietf-rtcweb-stun-consent-freshness-02.txt =20 Hi, =20 It=E2=80=99s not about running a browser on ice-lite =E2=80=93 it is = about a browser being prepared to run with a remote endpoint that is = running ice-lite (e.g. a gateway). Certain browser implementations have = had some problems with that, afaik=E2=80=A6 =20 Regards, =20 Christer =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: 12 April 2014 08:59 To: Christer Holmberg; Martin Thomson; Ram Mohan R (rmohanr) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: = draft-ietf-rtcweb-stun-consent-freshness-02.txt =20 Seems we have another reason why running a browser on ice-lite is a bad = idea. Good that we do not allow that. On 11. april 2014 22:37:55 CEST, Christer Holmberg = wrote: Hi, With ICE-lite mode since the ICE-lite endpoint does not typically=20 generate any binding requests, it may not generate STUN consent as = well. Wat? Consent is generated by responding to connectivity checks. An ICE-lite = endpoint has to do that. Sure, but I guess what is meant is that the ICE-lite endpoint does not = generate STUN consent REQUESTS. Regards, Christer _____ =20 rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --=20 Sent from my Android device with K-9 Mail. Please excuse my brevity. ------=_NextPart_000_024D_01CF5646.560C2650 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

To= avoid confusion=E2=80=A6

 

Ga= teways are not mentioned in = draft-ietf-rtcweb-transports-03

 

Un= der 3.5.=C2=A0 Middle box related functions

It= too simply says:

ICE [RFC5245] MUST be = supported.=C2=A0 The implementation MUST be a = full

=C2=A0=C2=A0 ICE implementation, not = ICE-Lite.

 

It= needs to be said that gateways, i.e. devices having a media port on a = public IP address =E2=80=93 never behind a NAT/firewall =E2=80=93 SHOULD = implement ICE-Lite. (which browsers implementing full ICE correctly are = compatible with =E2=80=93 and has to be =E2=80=93 which we all have the = same understanding of, I believe)

 

 

/K= arl

 

 

Fr=C3=A5n: rtcweb = [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Christer = Holmberg
Skickat: den 12 april 2014 10:26
Till: = Harald Alvestrand; Martin Thomson; Ram Mohan R = (rmohanr)
Kopia: rtcweb@ietf.org
=C3=84mne: Re: = [rtcweb] I-D Action: = draft-ietf-rtcweb-stun-consent-freshness-02.txt

 

Hi,

 

It=E2=80=99s not about running a browser on ice-lite =E2=80=93 it is = about a browser being prepared to run with a remote endpoint that is = running ice-lite (e.g. a gateway). Certain browser implementations have = had some problems with that, afaik=E2=80=A6

 

Regards,

 

Christer

 

From: Harald = Alvestrand [mailto:harald@alvestrand.no] =
Sent: 12 April 2014 08:59
To: Christer Holmberg; = Martin Thomson; Ram Mohan R (rmohanr)
Cc: rtcweb@ietf.org
Subject: = Re: [rtcweb] I-D Action: = draft-ietf-rtcweb-stun-consent-freshness-02.txt

 

Seems we have another = reason why running a browser on ice-lite is a bad idea. Good that we do = not allow that.

On 11. april 2014 22:37:55 CEST, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:

Hi,
 With ICE-lite mode since the ICE-lite =
endpoint does not typically 
 generate any binding requests, it =
may not generate STUN consent as =
well.

Wat?

Consent is generated by responding to =
connectivity checks.  An ICE-lite endpoint has to do =
that.

Sure, but I guess what is meant is that the ICE-lite =
endpoint does not generate STUN consent =
REQUESTS.

Regards,

Christer

rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or=
g/mailman/listinfo/rtcweb
<= p class=3DMsoNormal>
--
Sent from my Android = device with K-9 Mail. Please excuse my = brevity.

------=_NextPart_000_024D_01CF5646.560C2650-- From nobody Sat Apr 12 05:55:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5FF1A0118 for ; Sat, 12 Apr 2014 05:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 TMbESjU27ZNL for ; Sat, 12 Apr 2014 05:55:40 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1B91A010E for ; Sat, 12 Apr 2014 05:55:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 977DB7C5150; Sat, 12 Apr 2014 14:55:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9EA5Ftzk3LG; Sat, 12 Apr 2014 14:55:36 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:8c75:c2ff:d7f9:c60e] (unknown [IPv6:2001:470:de0a:27:8c75:c2ff:d7f9:c60e]) by mork.alvestrand.no (Postfix) with ESMTPSA id CB5637C054B; Sat, 12 Apr 2014 14:55:35 +0200 (CEST) Message-ID: <534937C6.5030403@alvestrand.no> Date: Sat, 12 Apr 2014 14:55:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Karl Stahl , 'Christer Holmberg' , 'Martin Thomson' , "'Ram Mohan R (rmohanr)'" References: <20140411033753.19230.46577.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D2BD7C3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2BF6E5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2BFE90@ESESSMB209.ericsson.se> <024c01cf5635$92835650$b78a02f0$@stahl@intertex.se> In-Reply-To: <024c01cf5635$92835650$b78a02f0$@stahl@intertex.se> Content-Type: multipart/alternative; boundary="------------030906040408020800070200" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gnKGLl5ugsPG5254dz_6dNZ66PQ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE-Lite, Was: I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 12:55:44 -0000 This is a multi-part message in MIME format. --------------030906040408020800070200 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 04/12/2014 11:57 AM, Karl Stahl wrote: > > To avoid confusion… > > Gateways are not mentionedin draft-ietf-rtcweb-transports-03 > > Under 3.5. Middle box related functions > > It too simply says: > > ICE [RFC5245] MUST be supported. The implementation MUST be a full > > ICE implementation, not ICE-Lite. > > It needs to be said that gateways, i.e. devices having a media port on > a public IP address – never behind a NAT/firewall – SHOULD implement > ICE-Lite. (which browsers implementing full ICE correctly are > compatible with – and has to be – which we all have the same > understanding of, I believe) > I think we've been over this ground before. At the moment, the RTCWEB protocol suite documentation deals with requirements for browsers, not requirements for gateways. If someone wishes to start a requirements-for-gateways documents, I think they should be free to do that - but I hope we can finish this document set before that. > /Karl > > *Från:*rtcweb [mailto:rtcweb-bounces@ietf.org] *För *Christer Holmberg > *Skickat:* den 12 april 2014 10:26 > *Till:* Harald Alvestrand; Martin Thomson; Ram Mohan R (rmohanr) > *Kopia:* rtcweb@ietf.org > *Ämne:* Re: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-02.txt > > Hi, > > It’s not about running a browser on ice-lite – it is about a browser > being prepared to run with a remote endpoint that is running ice-lite > (e.g. a gateway). Certain browser implementations have had some > problems with that, afaik… > > Regards, > > Christer > > *From:*Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* 12 April 2014 08:59 > *To:* Christer Holmberg; Martin Thomson; Ram Mohan R (rmohanr) > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-02.txt > > Seems we have another reason why running a browser on ice-lite is a > bad idea. Good that we do not allow that. > > On 11. april 2014 22:37:55 CEST, Christer Holmberg > > wrote: > > Hi, > > With ICE-lite mode since the ICE-lite endpoint does not typically > generate any binding requests, it may not generate STUN consent as well. > > > Wat? > > Consent is generated by responding to connectivity checks. An ICE-lite endpoint has to do that. > > > Sure, but I guess what is meant is that the ICE-lite endpoint does not generate STUN consent REQUESTS. > > Regards, > > Christer > > ------------------------------------------------------------------------ > > > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > --------------030906040408020800070200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 04/12/2014 11:57 AM, Karl Stahl wrote:

To avoid confusion…

 

Gateways are not mentioned in draft-ietf-rtcweb-transports-03

 

Under 3.5.  Middle box related functions

It too simply says:

ICE [RFC5245] MUST be supported.  The implementation MUST be a full

   ICE implementation, not ICE-Lite.

 

It needs to be said that gateways, i.e. devices having a media port on a public IP address – never behind a NAT/firewall – SHOULD implement ICE-Lite. (which browsers implementing full ICE correctly are compatible with – and has to be – which we all have the same understanding of, I believe)


I think we've been over this ground before.

At the moment, the RTCWEB protocol suite documentation deals with requirements for browsers, not requirements for gateways.

If someone wishes to start a requirements-for-gateways documents, I think they should be free to do that - but I hope we can finish this document set before that.


 

 

/Karl

 

 

Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Christer Holmberg
Skickat: den 12 april 2014 10:26
Till: Harald Alvestrand; Martin Thomson; Ram Mohan R (rmohanr)
Kopia: rtcweb@ietf.org
Ämne: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt

 

Hi,

 

It’s not about running a browser on ice-lite – it is about a browser being prepared to run with a remote endpoint that is running ice-lite (e.g. a gateway). Certain browser implementations have had some problems with that, afaik…

 

Regards,

 

Christer

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: 12 April 2014 08:59
To: Christer Holmberg; Martin Thomson; Ram Mohan R (rmohanr)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt

 

Seems we have another reason why running a browser on ice-lite is a bad idea. Good that we do not allow that.

On 11. april 2014 22:37:55 CEST, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,
 With ICE-lite mode since the ICE-lite endpoint does not typically 
 generate any binding requests, it may not generate STUN consent as well.

Wat?

Consent is generated by responding to connectivity checks.  An ICE-lite endpoint has to do that.

Sure, but I guess what is meant is that the ICE-lite endpoint does not generate STUN consent REQUESTS.

Regards,

Christer

rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


--------------030906040408020800070200-- From nobody Mon Apr 14 22:14:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBFF1A033B for ; Mon, 14 Apr 2014 22:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham 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 AfysmITOJtaZ for ; Mon, 14 Apr 2014 22:14:05 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEA81A031A for ; Mon, 14 Apr 2014 22:14:04 -0700 (PDT) Received: from ppp118-209-199-135.lns20.mel6.internode.on.net ([118.209.199.135]:57736 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WZvh0-0004KR-QX for rtcweb@ietf.org; Tue, 15 Apr 2014 15:13:58 +1000 Message-ID: <534CC016.3020901@nteczone.com> Date: Tue, 15 Apr 2014 15:13:58 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <534616DC.7090800@nteczone.com> In-Reply-To: <534616DC.7090800@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/chf5rSfcBqvHEx-ogCmzTy-Mlkk Subject: Re: [rtcweb] JSEP/WebRTC API Datachannel question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 05:14:07 -0000 I'll take a punt that people were thinking about 2 below when data channel was added. In order to clarify that I propose to add the following text to the JSEP draft to clarify this. http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1 Replace: "Lastly, if a data channel has been created, a m= section MUST be generated for data. The field MUST be set to "application" and the field MUST be set to "DTLS/SCTP", as specified in [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1." With: / "Lastly, if createDataChannel has been called a m= section MUST be generated for data. In the case of multiple createDataChannel calls only one m= section is generated. The field MUST be set to "application" and the field MUST be set to "DTLS/SCTP", as specified in [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1."/ New text in http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.2: (above last paragraph) / "If createDataChannel has been called and a m= section has not previously been generated, a m= section MUST be generated for data. In the case of multiple createDataChannel calls only one m= section is generated. The field MUST be set to "application" and the field MUST be set to "DTLS/SCTP", as specified in [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.// // //If all data channels have been closed, the m= section related to the data channels MUST be marked as recvonly by changing the value of the [RFC3264] directional attribute to "a=recvonly".//"/ It would also be good to add some text regarding the relationship between a createDataChannel and DCEP DATA_CHANNEL_OPEN I'm not sure if the JSEP draft is the place? Also the W3C draft could be updated to indicate the interaction of a createDataChannel with the negotiationneeded event in section 5.2 something along the lines of: /7. For the first creation of a RTCDataChannel object fire a negotiationneeded event at connection./ Regards, Christian On 10/04/2014 1:58 PM, Christian Groves wrote: > Hello, > > I've looked into the JSEP draft and WebRTC API (as well as the > datachannel and DCEP drafts) to get a better understanding of how and > when the SDP for the DTLS/SCTP Web-RTCDataChannel will be generated > and what will trigger the DCEP protocol. Unfortunately I find myself > more confused after the process . > > I was trying to find some text regarding what happens in terms of SDP > and DCEP when an endpoint uses multiple datachannels per > peerConnection. e.g. > > pc = new RTCPeerConnection(configuration); > channel = pc.createDataChannel("chat"); > channel = pc.createDataChannel("clue"); > > Now based on the WebRTC API > (http://dev.w3.org/2011/webrtc/editor/webrtc.html#peer-to-peer-data-api), > I understand that a createOffer() is used to generate the required SDP > for the data channel. This is also mentioned in Clause 5.2.1 "initial > offers" draft-ietf-rtcweb-jsep-06 indicates: /"Lastly, if a data > channel has been created, a m= section MUST be generated for data..."/ > > The WebRTC API cl.5.1.2 "createDataChannel" step 9 says /"Create > channel's associated underlying data transport and configure it > according to the relevant properties of channel."/ Now unfortunately > it doesn't really say want this amounts to. Create could be "a new > SCTP association" or it could be "using DCEP to do a > DATA_CHANNEL_OPEN" or both. > > If I look at the RTCPeerConnection Interface for addStream I see that > it indicates that a negotiationneeded event (WebRTC API cl.4.3.2.3 > step 5) is fired. This is a trigger for the createOffer(). The example > 10.1 WebRTC API shows this behavior. 10.3 also shows this behavior for > createDataChannel but the Peer-to-Peer Data API doesn't indicate that > the negotiationneeded event is triggered when establishing a data > channel. > > I looked at the RTCDataChannel closure procedure to see if this would > shed any more light but simply says that the underlying data transport > may be torn down. The JSEP draft isn't any help here either as it > doesn't talk about RTCDataChannel closure at all. > > So its not clear to me from the drafts/API whether: > 1. each createDataChannel results in an offer with new m-line > "webrtc-datachannel", > 2. the first createDataChannel results in an SDP offer with m-line > "webrtc-datachannel" and subsequent createDataChannels result in DCEP > DATA_CHANNEL_OPENs on the existing webrtc-datachannel. > 3. a mix of the above an endpoint can indicate multiple m-lines > "webrtc-datachannel" and have multiple DCEP DATA_CHANNEL_OPENs per > m-line. > > Its clear from draft-ietf-rtcweb-data-channel-07 that "Multiple > simultaneous data channels MUST be supported in the peer connection" > but that doesn't clarify the above. > > Is there any specification text that clarifies this? > > Regards, Christian > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Apr 15 05:11:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2C91A03E8 for ; Tue, 15 Apr 2014 05:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 FrPYE6E-ErVh for ; Tue, 15 Apr 2014 05:10:53 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DF09E1A03E0 for ; Tue, 15 Apr 2014 05:10:46 -0700 (PDT) X-AuditID: c1b4fb30-f791c6d000005f7c-0e-534d21c336de Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 58.3C.24444.3C12D435; Tue, 15 Apr 2014 14:10:43 +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.174.1; Tue, 15 Apr 2014 14:10:42 +0200 Message-ID: <534D21C2.20300@ericsson.com> Date: Tue, 15 Apr 2014 14:10:42 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Martin Thomson , Colin Perkins References: <533E76AC.7030003@ericsson.com> <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org> <534284B7.7010103@ericsson.com> In-Reply-To: <534284B7.7010103@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM+Jvje5hRd9gg+8nxC2WvzzBaHHtzD9G i7X/2tkdmD2m3b/P5rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZRw+PpGl4LZFxbyTa5ga GLfpdDFyckgImEhMOvCfHcIWk7hwbz1bFyMXh5DAUUaJ/wsXQTnLGSWuH93IBFLFK6ApsWTz WkYQm0VAVeL22wawbjYBC4mbPxrZQGxRgWCJpXMWs0DUC0qcnPkEyObgEBEIkujvKwYJMwuo S9xZfA6sVVjAR+LW5X+sELu6mCTm754O1sspoCPR8eEzG0ivhIC4RE9jEESvpkTr9t/sELa8 RPPW2cwgtpCAtkRDUwfrBEahWUg2z0LSMgtJywJG5lWMosWpxUm56UZGeqlFmcnFxfl5enmp JZsYgaF9cMtvgx2ML587HmIU4GBU4uHVPeceLMSaWFZcmXuIUZqDRUmc99tZoJBAemJJanZq akFqUXxRaU5q8SFGJg5OqQZGHW2WumVbDq/lzlVMiQ/bnh754/gWg3PypW7bKnLmlnKGNV5K qL1wIlto24ZFr34ILdCdlLBjwr5du9on/nj7RK5vzSGDxWqVXYZv1vlW1TuevfrllfyqGwff b1hnZtHzMfaKJ9/HPWuOpesckrSc98n50fodTwvseORDCv5bdxosL2w97anrrsRSnJFoqMVc VJwIAD9OfBZOAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lnjcO4Vf7bKJqn19edBu2YizH-s Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 12:10:59 -0000 Hi Martin and WG, Colin has helped clarify the text. Thus, I wanted to provide an updated version of the text to see if this resolves your concerns properly. Section 4.1 (Part) o Support for multiple synchronisation contexts. Participants that send multiple simultaneous RTP packet streams SHOULD do so as part of a single synchronisation context, using a single RTCP CNAME for all streams and allowing receivers to play the streams out in a synchronised manner. For compatibility with potential future versions of this specification, or for interoperability with non- WebRTC devices through a gateway, receivers MUST support multiple synchronisation contexts, indicated by the use of multiple RTCP CNAMEs in an RTP session. This specification requires the usage of a single CNAME when sending RTP Packet Streams in some circumstances, see Section 4.9. 4.9. Generation of the RTCP Canonical Name (CNAME) The RTCP Canonical Name (CNAME) provides a persistent transport-level identifier for an RTP end-point. While the Synchronisation Source (SSRC) identifier for an RTP end-point can change if a collision is detected, or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged for the duration of a RTCPeerConnection [W3C.WD-webrtc-20130910], so that RTP end-points can be uniquely identified and associated with their RTP packet streams within a set of related RTP sessions. Each RTP end-point MUST have at least one RTCP CNAME, and that RTCP CNAME MUST be unique within the RTCPeerConnection. RTCP CNAMEs identify a particular synchronisation context, i.e., all SSRCs associated with a single RTCP CNAME share a common reference clock. If an end-point has SSRCs that are associated with several unsynchronised reference clocks, and hence different synchronisation contexts, it will need to use multiple RTCP CNAMEs, one for each synchronisation context. Taking the discussion in Section 11 into account, a WebRTC end-point MUST NOT use more than one RTCP CNAME in the RTP sessions belonging to single RTCPeerConnection (that is, an RTCPeerConnection forms a synchronisation context). RTP middleboxes MAY generate RTP packet streams associated with more than one RTCP CNAME, to allow them to avoid having to resynchronize media from multiple different end- points part of a multi-party RTP session. The RTP specification [RFC3550] includes guidelines for choosing a unique RTP CNAME, but these are not sufficient in the presence of NAT devices. In addition, long-term persistent identifiers can be problematic from a privacy viewpoint (Section 13). Accordingly, a WebRTC endpoint MUST generate a new, unique, short-term persistent RTCP CNAME for each RTCPeerConnection, following [RFC7022]. An WebRTC end-point MUST support reception of any CNAME that matches the syntax limitations specified by the RTP specification [RFC3550] and cannot assume that any CNAME will be chosen according to the form suggested above. Section 11 (Part) The same MediaStreamTrack can also be included in multiple MediaStreams, thus multiple sets of MediaStreams can implicitly need to use the same synchronisation base. To ensure that this works in all cases, and don't forces a end-point to change synchronisation base and CNAME in the middle of a ongoing delivery of any packet streams, which would cause media disruption; all MediaStreamTracks and their associated SSRCs originating from the same end-point needs to be sent using the same CNAME within one RTCPeerConnection. This is motivating the strong recommendation in Section 4.9 to only use a single CNAME. Note: It is important that the same CNAME is not used in different communication session contexts or origins, as that could enable tracking of a user and its device usage of different services. See Section 4.4.1 of Security Considerations for WebRTC [I-D.ietf-rtcweb-security] for further discussion. The requirement on using the same CNAME for all SSRCs that originates from the same end-point, does not require middleboxes that forwards traffic from multiple end-points to only use a single CNAME. The above will currently force a WebRTC end-point that receives an MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing on any RTCPeerConnection to perform resynchronisation of the stream. This, as the sending party needs to change the CNAME, which implies that it has to use a locally available system clock as timebase for the synchronisation. Thus, the relative relation between the timebase of the incoming stream and the system sending out needs to defined. This relation also needs monitoring for clock drift and likely adjustments of the synchronisation. The sending entity is also responsible for congestion control for its the sent streams. In cases of packet loss the loss of incoming data also needs to be handled. This leads to the observation that the method that is least likely to cause issues or interruptions in the outgoing source packet stream is a model of full decoding, including repair etc followed by encoding of the media again into the outgoing packet stream. Optimisations of this method is clearly possible and implementation specific. A WebRTC end-point MUST support receiving multiple MediaStreamTracks, where each of different MediaStreamTracks (and their sets of associated packet streams) uses different CNAMEs. However, MediaStreamTracks that are received with different CNAMEs have no defined synchronisation. Note: The motivation for supporting reception of multiple CNAMEs are to allow for forward compatibility with any future changes that enables more efficient stream handling when end-points relay/ forward streams. It also ensures that end-points can interoperate with certain types of multi-stream middleboxes or end-points that are not WebRTC. Section 13 (Part) RTCP packets convey a Canonical Name (CNAME) identifier that is used to associate RTP packet streams that need to be synchronised across related RTP sessions. Inappropriate choice of CNAME values can be a privacy concern, since long-term persistent CNAME identifiers can be used to track users across multiple WebRTC calls. Section 4.9 of this memo provides guidelines for generation of untraceable CNAME values that alleviate this risk. -- 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 15 05:22:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F221A069F for ; Tue, 15 Apr 2014 05:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.054 X-Spam-Level: X-Spam-Status: No, score=0.054 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 gvxTXcTb9xwc for ; Tue, 15 Apr 2014 05:22:16 -0700 (PDT) Received: from sesbmg23.ericsson.net (unknown [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2741A069B for ; Tue, 15 Apr 2014 05:22:15 -0700 (PDT) X-AuditID: c1b4fb25-f798a6d000005ede-e3-534d24738dbc Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 37.2B.24286.3742D435; Tue, 15 Apr 2014 14:22:12 +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.174.1; Tue, 15 Apr 2014 14:22:11 +0200 Message-ID: <534D2473.7020007@ericsson.com> Date: Tue, 15 Apr 2014 14:22:11 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Roni Even , References: <533E7A50.5040909@ericsson.com> <010501cf533d$143546a0$3c9fd3e0$@gmail.com> In-Reply-To: <010501cf533d$143546a0$3c9fd3e0$@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+JvjW6Jim+wwd5mVovlL08wWvxtZ7ZY +6+d3YHZY9r9+2weO2fdZfdYsuQnUwBzFJdNSmpOZllqkb5dAlfGl13tbAUnpCtudp9kaWB8 LNrFyMkhIWAi0XvmLSOELSZx4d56ti5GLg4hgaOMEicWvWeFcJYzSmy7d5cFpIpXQFti6a5n zCA2i4CqxO7nnWBxNgELiZs/GtlAbFGBYImlcxZD1QtKnJz5BMwWEbCUmPVnCxOIzSygLvFs 9n6wOcICGRLTmjaD9QoJhEusbvgPFucEmrnk0DX2LkYOoOvEJXoagyBa9SSmXG1hhLDlJZq3 zmaGaNWWaGjqYJ3AKDQLyeZZSFpmIWlZwMi8ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMw sA9u+a26g/HyG8dDjAIcjEo8vFq3fYKFWBPLiitzDzFKc7AoifN+uQUUEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwFiVmn43Xzcp0fTPB9bEvT+SA5JCUnM/Hn+4vv0869vdery/dKp3v77v skBjuu4bjgN6LtdqVQvml+cePPd36bd7ahG90RdfBNfeaJJkCdub9z9AeNayPdsVmqOuxTTP i2I9YVaU4N64bCX/9kqt6/9dsx++yfPd+cry9fqVf5Jae6f+Kgms4FBiKc5INNRiLipOBACw +ePBTQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VOrUjxufX24h-Zna8ADyPCEsuYM Cc: 'Colin Perkins' Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 12:22:20 -0000 On 2014-04-08 17:13, Roni Even wrote: > Hi, > Comment on video switching in-line >> >> o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, >> since they make the use of RTCP for congestion control and quality >> of service reports problematic (see Section 3.6.2 of >> [I-D.ietf-avtcore-rtp-topologies-update]). > [Roni Even] I think that SHOULD NOT is too strong here better use MAY be > used, this is a simple common mode of centralized video conferencing being > used. If you are talking about the RTP layer the MCU gets all the RTCP > reports. The problem of loop detection may occur when cascading MCUs and the > avtcore topology should point it out. I do not see it as a major problem > since the video switching is managed by the application layer who should > prevent such situations. > Roni, I think you need to go read the definition of the topology in the draft. As defined in the topologies update draft, that behaviour is not acceptable towards an WebRTC end-point that uses RTCP for congestion control. I quote the most important parts (Section 3.8) from -01: "A video switching MCU forwards to a participant a single media stream, selected from the available streams. The criteria for selection are often based on voice activity in the audio-visual conference, but other conference management mechanisms (like presentation mode or explicit floor control) are known to exist as well. The video switching MCU may also perform media translation to modify the content in bit-rate, encoding, or resolution. However, it still may indicate the original sender of the content through the SSRC. In this case, the values of the CC and CSRC fields are retained. If not terminating RTP, the RTCP Sender Reports are forwarded for the currently selected sender. All RTCP Receiver Reports are freely forwarded between the participants. In addition, the MCU may also originate RTCP control traffic in order to control the session and/or report on status from its viewpoint. The video switching MCU has most of the attributes of a Translator. However, its stream selection is a mixing behavior. This behavior has some RTP and RTCP issues associated with it. The suppression of all but one media stream results in most participants seeing only a subset of the sent media streams at any given time, often a single stream per conference. Therefore, RTCP Receiver Reports only report on these streams. Consequently, the media senders that are not currently forwarded receive a view of the session that indicates their media streams disappear somewhere en route. This makes the use of RTCP for congestion control, or any type of quality reporting, very problematic." I think the behaviour you are interested in falls under the RTP mixer behaviour either the Mixing (Section 3.6.1) or the Switching (Section 3.6.2) where RTCP is properly handled. 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 15 08:14:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96EA1A0476 for ; Tue, 15 Apr 2014 08:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 umR9VgE29KOy for ; Tue, 15 Apr 2014 08:14:17 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0861A03E5 for ; Tue, 15 Apr 2014 08:14:16 -0700 (PDT) X-AuditID: c1b4fb30-f791c6d000005f7c-ae-534d4cc49d8a Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.07.24444.4CC4D435; Tue, 15 Apr 2014 17:14:13 +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.174.1; Tue, 15 Apr 2014 17:14:12 +0200 Message-ID: <534D4CC4.9040107@ericsson.com> Date: Tue, 15 Apr 2014 17:14:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Harald Alvestrand , References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no> <534288C2.6010906@ericsson.com> <5342ABBB.9050300@alvestrand.no> In-Reply-To: <5342ABBB.9050300@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvje5RH99ggynHeSyO9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGWcv72duWCpccXzj11sDYzTNLsYOTkkBEwk piyaxgZhi0lcuLceyObiEBI4yigxec8OVghnOaPEo4l/WEGqeAW0Jc4c/scEYrMIqEo0nf7D CGKzCVhI3PzRCDZJVCBYYumcxSwQ9YISJ2c+AbNFBOwlLs55CWYLC2RITGvaDLWtl1Hi6MXD YAs4BXQl2m69Ze5i5AA6SVyipzEIJMwsoCcx5WoLI4QtL9G8dTYziC0EdE9DUwfrBEbBWUjW zULSMgtJywJG5lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgQF7cMtvgx2ML587HmIU4GBU 4uHVPeceLMSaWFZcmXuIUZqDRUmc99tZoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGqaxc mS+C+3/3e36yPqAuWjorwvL4CqMMF3V1vcIJ+V2sixez+hYLr3pg/Hn3xqs9sb7bpyzV+jZp s/rjjl7vki6pn3NElZ6sDp1ybJ6wvib7I5GDbszbzr8/wjLXzTHvr23oPL9go4kv1savrH18 5M7ttbfey6/tzfZWMFx3tYxZ586527l6SizFGYmGWsxFxYkAr/iItDkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PxQusli99ldZ-Nlk0OVR4o7WQGk Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 15:14:21 -0000 Hi, I have considered these comments and are okay with modifying the recommendation. I have modified the proposed text from Harald somewhat. My proposal is the following: WebRTC implementations of RTP endpoints implemented according to this memo are expected to support all the topologies described in [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send and receive unicast RTP packet streams to and from some peer device, provided that peer can participate in performing congestion control on the RTP packet streams. The peer device could be another RTP endpoint, or it could be an RTP middlebox that redistributes the RTP packet streams to other RTP endpoints. This limitation means that some of the RTP middlebox-based topologies are not suitable for use in the WebRTC environment. Specifically: o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, since they make the use of RTCP for congestion control and quality of service reports problematic (see Section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]). o The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology SHOULD NOT be used because its safe use requires a point to multipoint congestion control algorithm or RTP circuit breaker, which has not yet been standardised. The following topology may be used, however it has considerations worth noting: o Content modifying MCUs with RTCP termination (Topo-RTCP- terminating-MCU) MAY be used. Note that in this RTP Topology, RTP loop detection and identification of active senders is the responsibility of the WebRTC application; since the clients are isolated from each other at the RTP layer, RTP cannot assist with these functions (see section 3.9 of [I-D.ietf-avtcore-rtp-topologies-update]). Please provide feedback on this text! Please see further response to questions and comments inline below. On 2014-04-07 15:44, Harald Alvestrand wrote: > On 04/07/2014 01:15 PM, Magnus Westerlund wrote: >> On 2014-04-07 10:12, Harald Alvestrand wrote: >>> In my (strong) opinion: This recommendation is wrong. >>> >>> All central conferencing units that use individual RTP sessions with >>> clients fall into this category. This includes, I believe, every single >>> multiuser video conferencing system based on WebRTC in existence (and >>> there are many of them). >> Do they? The point of this topology is that it terminates the source >> identification and hides when it is performing any type of mixing or >> switching operation. You can perform this with a back to back RTP >> session style without breaking this property. Just by correctly linking >> information between the sessions. > > Is there a definition for "correctly linking information"? > In particular, are you thinking of mappings that preserve SSRC? > Because that's not the ones I'm thinking of. The correctly linking information is mostly a question of preserving CNAMEs across the middlebox to ensure that an end-point can determine synchronization contexts, and origin if CSRC are used. As we add additional meta data about streams they may also needs to preserved depending on scope. Here it becomes a question of how one deals with APPID and MSID. Preserving SSRC is a choice, if one does it then loop detection works, if one doesn't preserve it it doesn't. Preserving it avoids having to remap any information that have global scope across the legs. It becomes a choice on what complexities one needs to handle, common uniqueness requirements versus remapping I think is the major trade-off. > >> Which means that the individual RTP >> session is from the identification part inseparable from an SFM or >> classic RTP mixer. Only the SSRC level loop detection gets impacted. >> >> I do understand that people have implemented it this way. Implementation >> are not necessarily equivalent to recommended practice. > > But when there's one common practice, and no recommended practice, that > might be a gentle hint that there's a reason why people are doing it - > indeed, it might be worth making it a recommended practice. You are welcome to propose changes regarding this to the topologies-update document in AVTCORE WG. >> >>> I believe the recommendation should be: >>> >>> * Content modifying MCUs with RTCP termination >>> (Topo-RTCP-terminating-MCU) MAY be used. Note that in this scenario, RTP >>> loop detection and identification of active senders is the resposibility >>> of the application; since the clients are isolated from each other at >>> the RTP layer, RTP cannot assist with these functions. >>> >> If this topology was without issues, then one would simply remove the >> bullet, and let it fall under the general clause. However, it clearly >> needs that warning. Which results in this topology being both positively >> and negatively treated in regards to the other "you may encounter this >> topology". > > It might need that warning - I'm not sure it's a real issue; loop > detection is only an issue when you have potential loops, and in a > single-mixer architecture, that potential is minimal (each endpoint > knows perfectly well the difference between what it's sourcing and what > it's receiving). Identification of active senders can be an > application-layer thing. Yes, I agree that in a basic conference application with only a single server instance this is unlikely to form a loop. If one starts doing more complex things, including multi-server conferences or PeerConnection Meshes things become more complex. The later we anyway have removed the RTP loop detection due to the CNAME being unique on PeerConnection level, but I do think that is the right trade-off from privacy point of view. > > Anyway, I stand by my statement: SHOULD NOT is the wrong thing to say. I do accept this, and are willing to change the recommendation. 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 15 08:55:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA06F1A03A5 for ; Tue, 15 Apr 2014 08:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 Pn_iaN17VWeG for ; Tue, 15 Apr 2014 08:55:30 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0CF1A0489 for ; Tue, 15 Apr 2014 08:55:29 -0700 (PDT) X-AuditID: c1b4fb3a-f79f36d0000039bf-6e-534d566d5580 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B9.7D.14783.D665D435; Tue, 15 Apr 2014 17:55:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.174.1; Tue, 15 Apr 2014 17:55:23 +0200 Message-ID: <534D566B.3040905@ericsson.com> Date: Tue, 15 Apr 2014 17:55:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Tuexen References: <530B740E.4090707@ericsson.com> <53160FBB.4070401@ericsson.com> <1904CA30-1112-44D4-8C6F-F15F1EF1BF9B@lurchi.franken.de> In-Reply-To: <1904CA30-1112-44D4-8C6F-F15F1EF1BF9B@lurchi.franken.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+JvjW5emG+wwaXXzBarD+9ls7jYtITR Yu2/dnYHZo8lS34yeWxo2cHk8eXyZ7YA5igum5TUnMyy1CJ9uwSujK1/G5kKtrlX7O/cw9bA +NKyi5GTQ0LARGJy9wcmCFtM4sK99WxdjFwcQgJHGSU+tW1lhnCWM0o8XP6cFaSKV0Bb4uqO JjYQm0VAVeLYs+ksIDabgIXEzR+NYHFRgWCJpXMWs0DUC0qcnPkEzBYRMJU4uHwemM0sEC3R cfMmM4gtLOAtsWxFK9TmvYwS/VcPgRVxCrhKLLo3Beg8DqDzxCV6GoMgevUkplxtYYSw5SWa t84GmyMEdFtDUwfrBEahWUhWz0LSMgtJywJG5lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsY gcF9cMtvqx2MB587HmIU4GBU4uE9tsg9WIg1say4MvcQozQHi5I47ySQkEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBkaGvB/yX1awrJLoKUmo2XVBNY3bJbgrpO9bk+CxxujQbZeWHtr5Rayx Y0fqB+GS96znN282uWJ7jn3i44ayJ2884t9WSl3KmPe9ZWe+6a/eKK7jWz6e3vQpa2Hr12tv sjvz89btjreRKhSY2H+nsrOFWfhUZ5ae4QdNlut7tjdzekqre3snTlNiKc5INNRiLipOBACf zwAjTwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KcvzufuIeNnbXCnova0PGrDA16A Cc: draft-ietf-rtcweb-data-protocol@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 15:55:36 -0000 Hi, Please see inline for replies. On 2014-04-10 13:50, Michael Tuexen wrote: > On 04 Mar 2014, at 17:39, Magnus Westerlund wrote: > >> On 2014-02-25 17:07, Michael Tuexen wrote: >>> >>> On Feb 24, 2014, at 5:32 PM, Magnus Westerlund wrote: >>>> 1. Section 4: >>>> Shouldn't this section discuss the priority field? >>> I added in the list of consistent properties: >>> >>> the priority of the data Channel. >>> >>> and in the text below that enumeration: >>> >>> ?????? >> >> Yes, text for this needs to be figured out. > We don't define at this place what priority is. The only point is that both > sides use the same priority. Okay, I agree, the Priority is a property of the established Data Channel, and the values and implication of these needs to be defined in the Data Channel draft and not here. >> >>>> >>>> 2. Section 4: >>>> >>>> The method >>>> used to determine which side uses odd or even is based on the >>>> underlying DTLS connection role when used in WebRTC, with the side >>>> acting as the DTLS client using even stream identifiers. >>>> >>>> Isn't this unnecessary using the vague word of WebRTC instead of simply >>>> pointing to the DTLS roles of the established data channel? >> >>> The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and therefore >>> you can refer to the DTLS role. However, you could use DCEP/SCTP/IP >>> or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS. >>> In that case DTLS is not used and you can not refer to the DTLS role. >>> That is why the restriction is used. >> >> Ok, if that concern then you still should be able to write a normative >> specification under the condition that it is SCTP over DTLS. If not how >> do you determine that? Are suggesting just to hand way or point to a >> higher signaling layer. > So what about using: > > when using , the method used to > determine which side uses odd or even is based on the underlying DTLS > connection role: the side acting as the DTLS client MUST use Streams with even > SCTP stream identifiers, the side acting as the DTLS server MUST use Streams > with odd SCTP stream identifiers. I think that is fine for when using over DTLS. And to my understanding this do require DTLS? If not we need alternative text. >>>> >>>> 4. Section 5.1: >>>> Label: Variable Length (sequence of characters) >>>> The name of the channel. This may be an empty string. >>>> >>>> Protocol: Variable Length (sequence of characters) >>>> The protocol for the channel. If this is an empty string the >>>> protocol us unspecified. If it is an non-empty string, it >>>> specifies an IANA-registered protocol (see Section 8.4). >>>> >>>> Both of these fields are strings, shouldn't a particular encoding be >>>> specified here? Like UTF-8. Secondly, what values are allowed, the full >>>> set of Unicode? >> >>> You are right. Any need for restrictions? We only need to be able to >>> transform it to a DomString. >>> So I changed it to: >>> >>> >>> >>> The name of the channel as a UTF-8 encoded string. >>> This may be an empty string. >>> >>> >>> >>> The protocol for the channel as a UTF-8 encoded string. >>> If this is an empty string the protocol us unspecified. >>> If it is an non-empty string, it specifies an IANA-registered protocol >>> (see ). >> >> I guess this is slightly overtaken by event. It have to be aligned with >> what the websocket sub-protocol identifier. > The text now reads: > > > The sub-protocol for the channel as a UTF-8 encoded string. > If this is an empty string the protocol is unspecified. > If it is a non-empty string, it specifies an protocol registered in the > 'WebSocket Subprotocol Name Registry' created in > . Ok. >> >>>> >>>> 5. Section 6: >>>> All Data Channel Establishment Protocol messages MUST be sent >>>> requesting ordered delivery and using reliable transmission. >>>> >>>> I wonder of the use of requesting ordered delivery and using reliable >>>> transmission, from an SCTP stream perspective, wouldn't using in both >>>> places be appropriate? Or is how object which has been requested to be >>>> transmitted unordered interact in SCTP with the ordered ones? >> >>> I'm sorry, I don't understand what you are asking... >> >> Sorry, it really is a language issue. The above sentence first states >> "sent 'requesting' ordered" and later "and 'using' reliable". >> >> This inconsistency is what I reacted to. > I see. Changed to: > All Data Channel Establishment Protocol messages MUST be sent using > ordered delivery and reliable transmission. Ok >> >>> >>>> 6. Section 7: >>>> >>>> I think this section can be beefed up a bit. First make clear that the >>>> Data Channel's required usage of DTLS ensures that the message integrity >>>> and possible source authentication as well as confidentiality. Then >>>> going over any security risks with a malicous peer using this protocol. >>>> Can a malicous side screw up the peer using this protocol? What are the >>>> implications? >> >>> Just to double check: Aren't the referenced documents the ones which >>> discuss all security stuff in one place? >> >> The security document do discuss system level important aspects. But, >> from my perspective, details that are very specific to this protocol >> should be discussed in this document. >> >> I think this is highly relevant in this document as there are others >> that are interested in using it. > OK. Any concrete suggestions what should be covered? I can at least think of potentially relevant issues: - Exhaustion attacks by opening all 64k Data channels - Attempting to overflow buffers by including 64k of Strings in Label and Protocol fields in the OPEN message. - Attempt to get undocumented behaviour by sending Reliability Parameters that aren't defined. Or use out of range Priorities or message types. But that I guess is most of the things I can think of to attempt to break the protocol. Then it is the question of requiring DTLS to ensure it is safe from Privacy, Confidentiality, Integrity and possibly source authentication concerns. >>>> >>>> 11. This comments concerns the relation to the Data Channel >>>> specification. So my interpretation is that the WebRTC Data channel >>>> draft has become both the base for this specification as well as the one >>>> that specifies that the DCEP shall be implemented and supported. For >>>> WebRTC I don't think this matters much, but if someone likes to re-use >>>> the basic Data Channel specification, this structure makes it more >>>> difficult and have no need for the bi-directional negotiated parameter >>>> settings that the DCEP provides. In that case one have to sub-set the >> >>> I think the data channel draft discusses the data channels independent >>> how they are opened. This covers data parameters, user data transmission >>> and closing of data channels. The data channel protocol draft discusses >>> an in-band protocol for setting up data channels. >> >> I think this was discussed today. And make it clear that DCEP >> requirement shouldn't be from the Data Channel spec. >> >>>> data channel specification. I wonder if it would be better to move some >>>> normative statements around, so that the chain of implementation >>>> requirement goes draft-ietf-rtcweb-transports -> >>>> draft-ietf-rtcweb-data-protocol -> draft-ietf-rtcweb-data-channel thus >>>> providing a cleaner and more modular build up of the protocols. >>> I think you can implement draft-ietf-rtcweb-data-channel without >>> draft-ietf-rtcweb-data-protocol, but not vice versa. >>> >>> So you don't like the statement: >>> >>> A simple protocol for internal negotiation is specified in >>> [I-D.ietf-rtcweb-data-protocol] and MUST be supported. >>> >>> from draft-ietf-rtcweb-data-channel. What would you suggest? >> >> I think the high level requirement on DCEP might be in -rtcweb-transports. > It now reads: > A simple protocol for in-band negotiation is specified in [I-D.ietf-rtcweb-data-protocol]. Ok 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 15 10:33:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EC81A01E7 for ; Tue, 15 Apr 2014 10:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 w2yLAMWmFL-V for ; Tue, 15 Apr 2014 10:33:07 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0CC1A02E3 for ; Tue, 15 Apr 2014 10:33:07 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so9631265wes.6 for ; Tue, 15 Apr 2014 10:33:04 -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:content-type; bh=JkbclcbV3Od+bSrsUdjs0UhquxvWL7+NpgBQBlGtHM8=; b=lZ9fdWb+GC0QZPF9+yPMs7qi8Ktd/zM7eY1uuALZih7MVODlOIIBflgGEY8znurWk9 VYG2Hh+aLcKrx56C7p/21wrJ6xrNN6Q6dwVplfDgfiM1hdE1TUtx+yVJblkEYeaN/QMi e+8VQpX60LSZmkTR8iPv0Mr33QT8qn76mifZcw3HKd8mhGX/kL7FCfCHhXII+g6GHr5j 4H0Eka/R3vQKqbdbrzFH7+qTJsdWar4MMsjV/Lea4MzBWGKnrVyTPEj39YbMn7RsB/kW AkuL+fvNvTztgDHNQrDGbrbcgLJQy0lLreBKvv295orqxWF5quU7glK0DUvWF4KAHLtA 4y/g== MIME-Version: 1.0 X-Received: by 10.180.13.180 with SMTP id i20mr15392357wic.56.1397583184048; Tue, 15 Apr 2014 10:33:04 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Tue, 15 Apr 2014 10:33:04 -0700 (PDT) In-Reply-To: <534D21C2.20300@ericsson.com> References: <533E76AC.7030003@ericsson.com> <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org> <534284B7.7010103@ericsson.com> <534D21C2.20300@ericsson.com> Date: Tue, 15 Apr 2014 10:33:04 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mAP0aT7_vNlf0VFIIId8U4TQ_nU Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 17:33:12 -0000 The text looks fine, with one comment. On 15 April 2014 05:10, Magnus Westerlund wrote: > Note: It is important that the same CNAME is not used in different > communication session contexts or origins, as that could enable > tracking of a user and its device usage of different services. > See Section 4.4.1 of Security Considerations for WebRTC > [I-D.ietf-rtcweb-security] for further discussion. I'd rather not have this hidden in a "Note", and I'd prefer if it were more concrete. I think that we need to say something like: A different CNAME MUST be used for different RTCPeerConnection instances. Having two communication sessions with the same CNAME could enable tracking of a user or device across different services (see Section 4.4.1 of [security] for details). A web application MAY override the CNAME that is selected using the process in [RFC7022] to allow for synchronization of disjoint sessions; [[this doesn't result in a tracking issue, since the creation of matching CNAMEs depends on existing tracking]]. From nobody Tue Apr 15 14:57:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6841A074F for ; Tue, 15 Apr 2014 14:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 vgM35NJo8W2u for ; Tue, 15 Apr 2014 14:57:16 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id D13F91A07A0 for ; Tue, 15 Apr 2014 14:57:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 568D57C52BD; Tue, 15 Apr 2014 23:57:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPdPWASh4X+l; Tue, 15 Apr 2014 23:57:11 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:58bb:20e7:5cb8:4b63] (unknown [IPv6:2001:470:de0a:27:58bb:20e7:5cb8:4b63]) by mork.alvestrand.no (Postfix) with ESMTPSA id EF5CD7C52A6; Tue, 15 Apr 2014 23:57:10 +0200 (CEST) Message-ID: <534DAB36.3070105@alvestrand.no> Date: Tue, 15 Apr 2014 23:57:10 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Magnus Westerlund , rtcweb@ietf.org References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no> <534288C2.6010906@ericsson.com> <5342ABBB.9050300@alvestrand.no> <534D4CC4.9040107@ericsson.com> In-Reply-To: <534D4CC4.9040107@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5EkpaoIzI80Y6tGwfTkxpVzlpYo Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 21:57:24 -0000 On 04/15/2014 05:14 PM, Magnus Westerlund wrote: > Hi, > > I have considered these comments and are okay with modifying the > recommendation. I have modified the proposed text from Harald somewhat. > My proposal is the following: > > > WebRTC implementations of RTP endpoints implemented according to this > memo are expected to support all the topologies described in > [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send > and receive unicast RTP packet streams to and from some peer device, > provided that peer can participate in performing congestion control > on the RTP packet streams. The peer device could be another RTP > endpoint, or it could be an RTP middlebox that redistributes the RTP > packet streams to other RTP endpoints. This limitation means that > some of the RTP middlebox-based topologies are not suitable for use > in the WebRTC environment. Specifically: > > o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, > since they make the use of RTCP for congestion control and quality > of service reports problematic (see Section 3.8 of > [I-D.ietf-avtcore-rtp-topologies-update]). > > o The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology > SHOULD NOT be used because its safe use requires a point to > multipoint congestion control algorithm or RTP circuit breaker, > which has not yet been standardised. Grammar warning: The above can be parsed as either (multipoint congestion control algorithm) or (RTP circuit breaker) or multipoint ((congestion control algorithm) or (RTP circuit breaker)) Only the second parse will be a true statement once -circuit-breaker (a normative dependency) is published. Perhaps this needs rephrasing? > > The following topology may be used, however it has considerations > worth noting: > > o Content modifying MCUs with RTCP termination (Topo-RTCP- > terminating-MCU) MAY be used. Note that in this RTP Topology, RTP > loop detection and identification of active senders is the > responsibility of the WebRTC application; since the clients are > isolated from each other at the RTP layer, RTP cannot assist with > these functions (see section 3.9 of > [I-D.ietf-avtcore-rtp-topologies-update]). > > > Please provide feedback on this text! This text looks reasonable to me. > > Please see further response to questions and comments inline below. > > > On 2014-04-07 15:44, Harald Alvestrand wrote: >> On 04/07/2014 01:15 PM, Magnus Westerlund wrote: >>> On 2014-04-07 10:12, Harald Alvestrand wrote: >>>> In my (strong) opinion: This recommendation is wrong. >>>> >>>> All central conferencing units that use individual RTP sessions with >>>> clients fall into this category. This includes, I believe, every single >>>> multiuser video conferencing system based on WebRTC in existence (and >>>> there are many of them). >>> Do they? The point of this topology is that it terminates the source >>> identification and hides when it is performing any type of mixing or >>> switching operation. You can perform this with a back to back RTP >>> session style without breaking this property. Just by correctly linking >>> information between the sessions. >> Is there a definition for "correctly linking information"? >> In particular, are you thinking of mappings that preserve SSRC? >> Because that's not the ones I'm thinking of. > The correctly linking information is mostly a question of preserving > CNAMEs across the middlebox to ensure that an end-point can determine > synchronization contexts, and origin if CSRC are used. As we add > additional meta data about streams they may also needs to preserved > depending on scope. Here it becomes a question of how one deals with > APPID and MSID. > > Preserving SSRC is a choice, if one does it then loop detection works, > if one doesn't preserve it it doesn't. Preserving it avoids having to > remap any information that have global scope across the legs. > > It becomes a choice on what complexities one needs to handle, common > uniqueness requirements versus remapping I think is the major trade-off. > >>> Which means that the individual RTP >>> session is from the identification part inseparable from an SFM or >>> classic RTP mixer. Only the SSRC level loop detection gets impacted. >>> >>> I do understand that people have implemented it this way. Implementation >>> are not necessarily equivalent to recommended practice. >> But when there's one common practice, and no recommended practice, that >> might be a gentle hint that there's a reason why people are doing it - >> indeed, it might be worth making it a recommended practice. > You are welcome to propose changes regarding this to the > topologies-update document in AVTCORE WG. > >>>> I believe the recommendation should be: >>>> >>>> * Content modifying MCUs with RTCP termination >>>> (Topo-RTCP-terminating-MCU) MAY be used. Note that in this scenario, RTP >>>> loop detection and identification of active senders is the resposibility >>>> of the application; since the clients are isolated from each other at >>>> the RTP layer, RTP cannot assist with these functions. >>>> >>> If this topology was without issues, then one would simply remove the >>> bullet, and let it fall under the general clause. However, it clearly >>> needs that warning. Which results in this topology being both positively >>> and negatively treated in regards to the other "you may encounter this >>> topology". >> It might need that warning - I'm not sure it's a real issue; loop >> detection is only an issue when you have potential loops, and in a >> single-mixer architecture, that potential is minimal (each endpoint >> knows perfectly well the difference between what it's sourcing and what >> it's receiving). Identification of active senders can be an >> application-layer thing. > Yes, I agree that in a basic conference application with only a single > server instance this is unlikely to form a loop. If one starts doing > more complex things, including multi-server conferences or > PeerConnection Meshes things become more complex. The later we anyway > have removed the RTP loop detection due to the CNAME being unique on > PeerConnection level, but I do think that is the right trade-off from > privacy point of view. > >> Anyway, I stand by my statement: SHOULD NOT is the wrong thing to say. > I do accept this, and are willing to change the recommendation. > > 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 16 05:26:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A89D1A0146 for ; Wed, 16 Apr 2014 05:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 FTZWayxo4vj7 for ; Wed, 16 Apr 2014 05:26:25 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id EED7C1A0145 for ; Wed, 16 Apr 2014 05:26:24 -0700 (PDT) X-AuditID: c1b4fb3a-f79f36d0000039bf-1a-534e76ecaac9 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FB.80.14783.CE67E435; Wed, 16 Apr 2014 14:26:21 +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.174.1; Wed, 16 Apr 2014 14:26:20 +0200 Message-ID: <534E76EC.8060208@ericsson.com> Date: Wed, 16 Apr 2014 14:26:20 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Harald Alvestrand , References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no> <534288C2.6010906@ericsson.com> <5342ABBB.9050300@alvestrand.no> <534D4CC4.9040107@ericsson.com> <534DAB36.3070105@alvestrand.no> In-Reply-To: <534DAB36.3070105@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvje7bMr9gg5u7GC2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGXc33mZveCdUMW9OS+YGhg/8nUxcnJICJhI LDnUxQ5hi0lcuLeerYuRi0NI4CijxM9nJ1ggnOWMEsvn3mcEqeIV0JY4vGcJWAeLgKrEop57 bCA2m4CFxM0fjWC2qECwxNI5i1kg6gUlTs58AmaLCNhLXJzzEswWFsiQmNa0GWrbOUaJDS1n WEESnAK6EocOfAUq4gA6SVyipzEIJMwsoCcx5WoLI4QtL9G8dTYziC0EdE9DUwfrBEbBWUjW zULSMgtJywJG5lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgQF7cMtvqx2MB587HmIU4GBU 4uFlU/MLFmJNLCuuzD3EKM3BoiTOO2mRe7CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRs6o H+cvcl1Om5206ZtDol2/zLtLq/mjvv1vDbj+2oP3/fnM0xsZX3bJGH2aO59z3oqUJ2V7pTac DedJecuZ9OGosP1jn79VvIy/f4ktt4jienbJlfPRO1uTmfbXVU7Od3nqsFk6z2KJC9t1zU9G 77KWLn55+EWI+oudWrv71Ximbnj1fuW8lZuVWIozEg21mIuKEwFzXMMnOQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UVknz1o4KEQxNBlDv3abp3U1dg0 Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 12:26:30 -0000 On 2014-04-15 23:57, Harald Alvestrand wrote: > On 04/15/2014 05:14 PM, Magnus Westerlund wrote: >> Hi, >> >> I have considered these comments and are okay with modifying the >> recommendation. I have modified the proposed text from Harald somewhat. >> My proposal is the following: >> >> >> WebRTC implementations of RTP endpoints implemented according to this >> memo are expected to support all the topologies described in >> [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send >> and receive unicast RTP packet streams to and from some peer device, >> provided that peer can participate in performing congestion control >> on the RTP packet streams. The peer device could be another RTP >> endpoint, or it could be an RTP middlebox that redistributes the RTP >> packet streams to other RTP endpoints. This limitation means that >> some of the RTP middlebox-based topologies are not suitable for use >> in the WebRTC environment. Specifically: >> >> o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, >> since they make the use of RTCP for congestion control and quality >> of service reports problematic (see Section 3.8 of >> [I-D.ietf-avtcore-rtp-topologies-update]). >> >> o The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology >> SHOULD NOT be used because its safe use requires a point to >> multipoint congestion control algorithm or RTP circuit breaker, >> which has not yet been standardised. > > Grammar warning: The above can be parsed as either > > (multipoint congestion control algorithm) or (RTP circuit breaker) > > or > > multipoint ((congestion control algorithm) or (RTP circuit breaker)) > It is the later that was intended. Because the topology requires congestion control for multi endpoint. Will reword. Thanks 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 16 05:54:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DC81A0159 for ; Wed, 16 Apr 2014 05:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.346 X-Spam-Level: X-Spam-Status: No, score=-1.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 OMbNrL-QFUst for ; Wed, 16 Apr 2014 05:54:33 -0700 (PDT) Received: from sessmg23.ericsson.net (unknown [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0741A0156 for ; Wed, 16 Apr 2014 05:54:32 -0700 (PDT) X-AuditID: c1b4fb2d-f79fa6d000007cbe-d8-534e7d84c9db Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5B.3C.31934.48D7E435; Wed, 16 Apr 2014 14:54:28 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.174.1; Wed, 16 Apr 2014 14:54:27 +0200 Message-ID: <534E7D83.3010608@ericsson.com> Date: Wed, 16 Apr 2014 14:54:27 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Martin Thomson References: <533E76AC.7030003@ericsson.com> <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org> <534284B7.7010103@ericsson.com> <534D21C2.20300@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+JvjW5LrV+wwamV0hbLX55gtLh25h+j xdp/7ewOzB7T7t9n89g56y67x5IlP5kCmKO4bFJSczLLUov07RK4Ms42fmQr2G9acXtDE1MD 42StLkYODgkBE4mJUyu6GDmBTDGJC/fWs3UxcnEICRxllDh18BEzhLOcUWJjcwcLSAOvgLbE qp0eIA0sAqoSF1pXsoHYbAIWEjd/NILZogLBEkvnLGYBsXkFBCVOznwCZosI6EosOvuAHcRm FvCSeL5zByOILSzgI3Hr8j9WiF1vmSQetJ4CK+IUCJQ4vH4JE8Sh4hI9jUEQvZoSrdt/Q82R l2jeOpsZxBYCOq2hqYN1AqPQLCSrZyFpmYWkZQEj8ypG0eLU4uLcdCNjvdSizOTi4vw8vbzU kk2MwMA+uOW37g7G1a8dDzEKcDAq8fCyqfkFC7EmlhVX5h5ilOZgURLnbbvrHSwkkJ5Ykpqd mlqQWhRfVJqTWnyIkYmDU6qBMcv9hdFx7tw/obbzt95dnn3o0JkfUzg1/gRbx1ltn7C/8Pla +zfflxzz6JWaZh2XKR66W/lTiueNnZWzZ2ax7RPwrLqfdaq/55FzJquwi8fFtFMWjJt+PTLM TAkxmJV14YnBlQ/MGSHTffKU66T9Bb7py30RshQUkWKo/f3hSOTCwvNmpy6uUWIpzkg01GIu Kk4EALv3FE1NAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sdQUUEjRzhtWISRxuIabyU9o69I Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 12:54:37 -0000 On 2014-04-15 19:33, Martin Thomson wrote: > The text looks fine, with one comment. > > On 15 April 2014 05:10, Magnus Westerlund > wrote: >> Note: It is important that the same CNAME is not used in different >> communication session contexts or origins, as that could enable >> tracking of a user and its device usage of different services. >> See Section 4.4.1 of Security Considerations for WebRTC >> [I-D.ietf-rtcweb-security] for further discussion. > > I'd rather not have this hidden in a "Note", and I'd prefer if it were > more concrete. I think that we need to say something like: > > A different CNAME MUST be used for different RTCPeerConnection > instances. Having two communication sessions with the same CNAME > could enable tracking of a user or device across different services > (see Section 4.4.1 of [security] for details). A web application MAY > override the CNAME that is selected using the process in [RFC7022] to > allow for synchronization of disjoint sessions; [[this doesn't result > in a tracking issue, since the creation of matching CNAMEs depends on > existing tracking]]. > > The first part is already said in Section 4.9 text: The RTP specification [RFC3550] includes guidelines for choosing a unique RTP CNAME, but these are not sufficient in the presence of NAT devices. In addition, long-term persistent identifiers can be problematic from a privacy viewpoint (Section 13). Accordingly, a WebRTC endpoint MUST generate a new, unique, short-term persistent RTCP CNAME for each RTCPeerConnection, following [RFC7022]. Thus, I don't want in two places to use Normative RFC 2119 text for the same purpose. For the second half, I have to ask what the scope of this overriding is intended to be. Is it that within the same origin, a web application creating multiple PeerConnections can request them to use the same (by browser) selected random CNAME value? Or is it that the web application can set the CNAME to be used at PeerConnection creation time. The first I am fine with, as it appear to have very little downsides, and can really help application that tries to do advanced things where multiple PCs are used across multiple endpoints and middleboxes. Thus, I would propose to modify your proposal to result in a change in Section 4.9: Old: The RTP specification [RFC3550] includes guidelines for choosing a unique RTP CNAME, but these are not sufficient in the presence of NAT devices. In addition, long-term persistent identifiers can be problematic from a privacy viewpoint (Section 13). Accordingly, a WebRTC endpoint MUST generate a new, unique, short-term persistent RTCP CNAME for each RTCPeerConnection, following [RFC7022]. NEW: The RTP specification [RFC3550] includes guidelines for choosing a unique RTP CNAME, but these are not sufficient in the presence of NAT devices. In addition, long-term persistent identifiers can be problematic from a privacy viewpoint (Section 13). Accordingly, a WebRTC endpoint MUST generate a new, unique, short-term persistent RTCP CNAME for each RTCPeerConnection, following [RFC7022], with a single exception; if explicitly requested at creation an RTCPeerConnection MAY use the same CNAME as as an existing RTCPeerConnection within their common same-origin context. Section 11: OLD: The same MediaStreamTrack can also be included in multiple MediaStreams, thus multiple sets of MediaStreams can implicitly need to use the same synchronisation base. To ensure that this works in all cases, and don't forces a end-point to change synchronisation base and CNAME in the middle of a ongoing delivery of any packet streams, which would cause media disruption; all MediaStreamTracks and their associated SSRCs originating from the same end-point needs to be sent using the same CNAME within one RTCPeerConnection. This is motivating the strong recommendation in Section 4.9 to only use a single CNAME. Note: It is important that the same CNAME is not used in different communication session contexts or origins, as that could enable tracking of a user and its device usage of different services. See Section 4.4.1 of Security Considerations for WebRTC [I-D.ietf-rtcweb-security] for further discussion. The requirement on using the same CNAME for all SSRCs that originates from the same end-point, does not require middleboxes that forwards traffic from multiple end-points to only use a single CNAME. NEW: The same MediaStreamTrack can also be included in multiple MediaStreams, thus multiple sets of MediaStreams can implicitly need to use the same synchronisation base. To ensure that this works in all cases, and don't forces a end-point to change synchronisation base and CNAME in the middle of a ongoing delivery of any packet streams, which would cause media disruption; all MediaStreamTracks and their associated SSRCs originating from the same end-point needs to be sent using the same CNAME within one RTCPeerConnection. This is motivating the strong recommendation in Section 4.9 to only use a single CNAME. The requirement on using the same CNAME for all SSRCs that originates from the same end-point, does not require middleboxes that forwards traffic from multiple end-points to only use a single CNAME. Different CNAMEs are normally required to be used for different RTCPeerConnection instances, as specified in Section 4.9. Having two communication sessions with the same CNAME could enable tracking of a user or device across different services (see Section 4.4.1 of [I-D.ietf-rtcweb-security] for details). A web application can request that the CNAMEs used in different RTCPeerConnection within a same-orign context to be the same, this allow for synchronization of the endpoint's RTP packet streams across the different RTCPeerConnections. Note: this doesn't result in a tracking issue, since the creation of matching CNAMEs depends on existing tracking. Is this better/acceptable? 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 16 07:04:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B579E1A01BF for ; Wed, 16 Apr 2014 07:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 ywj-7s4RmZyx for ; Wed, 16 Apr 2014 07:04:37 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C57D1A01B5 for ; Wed, 16 Apr 2014 07:04:37 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id eb12so12490067oac.18 for ; Wed, 16 Apr 2014 07:04:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=YEH75XITba2BknWknEu10ByME+PPZJMVof/poLr3nTY=; b=CgW1kYxJBbn3SZG+PRfMD1PH8ATkbPtLt34OmfD+JKNAbj16XeqZNHPlk2mN9dU7X2 uuLrdpTO8pG6yiiinXjfzUDz1WtLlR2TcyjGGnInJW9Ll182hW7Qx0xU83LFeCakWavz vFFxO20cldmPi+2xjRVN201/109FzmlZesPmQqYLJvdtvc8Lv7qOnkfT+b6x8VOKKKl0 Nvr5sqBe0hJcOFV3tTn+/7m52qKnuwBOA/gPP095r53jjOfg2iGe4LpVMIs3Ib6Ebk1u LknZcOnAqGE4/vGDlJHmozOZCyXvTfho6Q/HfEdy6rNAT72foYP6pNoOTO6TRZnFmQvY tzzA== X-Gm-Message-State: ALoCoQlb6yBPQDAjtbTew+3qtExfoOB8gut90bGm970swotcdgb06078LetVTjIlDPofutOU1hOT MIME-Version: 1.0 X-Received: by 10.60.173.147 with SMTP id bk19mr6797408oec.27.1397657073973; Wed, 16 Apr 2014 07:04:33 -0700 (PDT) Received: by 10.60.136.231 with HTTP; Wed, 16 Apr 2014 07:04:33 -0700 (PDT) Date: Wed, 16 Apr 2014 10:04:33 -0400 Message-ID: From: Richard Barnes To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e01184bae698ea304f72965db Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dlvf-SXJFNmtNScxJ1-KCeqvsNk Subject: [rtcweb] Change of co-chair X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:04:39 -0000 --089e01184bae698ea304f72965db Content-Type: text/plain; charset=ISO-8859-1 Dear RTCWEB, We're having a minor change of management in this WG. Magnus is stepping down in preparation for his upcoming parental leave. Sean Turner has kindly agreed to take his place. For those of you who don't know Sean, he was recently SEC AD, he chaired the S/MIME working group before that, and he's currently providing security expertise in the STIR working group. Many thanks to Magnus for his leadership in this working group! --Richard --089e01184bae698ea304f72965db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear RTCWEB,

We're having a minor c= hange of management in this WG. =A0Magnus is stepping down in preparation f= or his upcoming parental leave. =A0Sean Turner has kindly agreed to take hi= s place. =A0For those of you who don't know Sean, he was recently SEC A= D, he chaired the S/MIME working group before that, and he's currently = providing security expertise in the STIR working group.

Many thanks to Magnus for his leadership in this workin= g group!

--Richard

--089e01184bae698ea304f72965db-- From nobody Wed Apr 16 07:17:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207EC1A01AD for ; Wed, 16 Apr 2014 07:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 RST89kpr8_bl for ; Wed, 16 Apr 2014 07:17:28 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id BCEEF1A01AA for ; Wed, 16 Apr 2014 07:17:28 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id uy17so1071634igb.3 for ; Wed, 16 Apr 2014 07:17:25 -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:content-type; bh=D4ntNzMVf6zozgRe/Xx37Sag/hSodRaeZuqEaJ3Z41s=; b=NZdDtK17eoq59jXd2v2d6fZDF3y6Xm921YmKX08+dZLGFecu1RABhsev+0FyjUQaYc aBt/i4125AtrSuB68fRu0pWS8TckgGX0Mf/UD1dhhkjfPueNzhN/J+oXNWq/ua6PTGJ/ u2cw2AaG5CjkxUrjQ6TETdxgdCFb9e5k0/3A570+Mmm4CupxKCGTkJ7HJUpzhjiiDM+E vZY91jDxWd7tcz9I+4ZtogIzs+CdSLa+fmL+yjgqP74LD1A9WLtrgmH7CDW4iSz0GONx fUiXVzfeHI+X7I4EMBHRFvJHK0Bt5+m+YWk21BBEy1qWjFAoRYDE+KmGQfJECaRDKbhQ DvfQ== MIME-Version: 1.0 X-Received: by 10.42.249.8 with SMTP id mi8mr4336700icb.4.1397657845533; Wed, 16 Apr 2014 07:17:25 -0700 (PDT) Received: by 10.42.200.204 with HTTP; Wed, 16 Apr 2014 07:17:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Apr 2014 07:17:25 -0700 Message-ID: From: Ted Hardie To: Richard Barnes Content-Type: multipart/alternative; boundary=20cf300e5069668fd204f7299355 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rP2qjB9LeUeWsZ_5flaTRN2lkLQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Change of co-chair X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:17:30 -0000 --20cf300e5069668fd204f7299355 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 16, 2014 at 7:04 AM, Richard Barnes wrote: > Dear RTCWEB, > > We're having a minor change of management in this WG. Magnus is stepping > down in preparation for his upcoming parental leave. Sean Turner has > kindly agreed to take his place. For those of you who don't know Sean, h= e > was recently SEC AD, he chaired the S/MIME working group before that, and > he's currently providing security expertise in the STIR working group. > > Many thanks to Magnus for his leadership in this working group! > > =E2=80=8BI'd like to add my thanks to Magnus; as a chair, contributor (and = host for meetings), he's been a tremendous and positive influence on the development of WebRTC. Sean, welcome, you have big boots to fill! Ted > --Richard > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf300e5069668fd204f7299355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 16, 2014 at 7:04 AM= , Richard Barnes <rlb@ipv.sx> wrote:
=
Dear RTCWEB,

We're having a minor c= hange of management in this WG. =C2=A0Magnus is stepping down in preparatio= n for his upcoming parental leave. =C2=A0Sean Turner has kindly agreed to t= ake his place. =C2=A0For those of you who don't know Sean, he was recen= tly SEC AD, he chaired the S/MIME working group before that, and he's c= urrently providing security expertise in the STIR working group.

Many thanks to Magnus for his leadership in this workin= g group!


=E2=80=8BI'd like to add my thanks to Magnus; as a chair, contributor (= and host for meetings), he's been a tremendous and positive influence o= n the development of WebRTC.

Sean, welcome, you have big boots to fill!

Ted



= =C2=A0
--Richard


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--20cf300e5069668fd204f7299355-- From nobody Wed Apr 16 08:07:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5091A01EA for ; Wed, 16 Apr 2014 08:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 9HVGA3b3dr_l for ; Wed, 16 Apr 2014 08:07:25 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65DDB1A01E4 for ; Wed, 16 Apr 2014 08:06:37 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so10962401wgh.15 for ; Wed, 16 Apr 2014 08:06:33 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type; bh=Q1VwQvgJ37v8MNGgwXQ+n19beaDOCnAtn4a5+GKqPmg=; b=l3ta9i7fuDi/DKnLTxmSO61dq7Klom/alaBYmvAybpzSww8+5GrSQBYbnaRBFxHNQH 5Sl2NHHc5s3FebsZ3WsAYH5zd0qSuJg0pnqoSo3LRUXjAAhwdJgz+39EiSiB/g4WLYo7 u4Bm7WZz1sfPOVXG+nS8LgxNLijtX9/CRLK/QDZO7lzi68Tot0BreknxEy7ElXpz5Dwi cJ+TH0Wsv5qZkHvAclb2u7yxc/iwfOZ3RZ2p0ODdHvMRGlUIPmRsK+j29Pd/RlI8DfyZ BiTmAuLfISOq1Hvj81uIRN4yYDsWio/fHVAqQ1zz49qKYA6LKXoaL7zNx7o30NyFQIjm P3YQ== X-Gm-Message-State: ALoCoQnj1n4PWkq9yfAZfaixF9ZcpQwHtcIo89QcyI/FTZ+KeyBPey86gMmlVbtenOjDx1h4He5U X-Received: by 10.194.192.132 with SMTP id hg4mr7514904wjc.28.1397660793707; Wed, 16 Apr 2014 08:06:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 16 Apr 2014 08:05:53 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Wed, 16 Apr 2014 08:05:53 -0700 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=047d7b87389620368d04f72a4321 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ltbSCA6ETQ6lu69fTibtpFpGzZQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Change of co-chair X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:07:30 -0000 --047d7b87389620368d04f72a4321 Content-Type: text/plain; charset=ISO-8859-1 Yes, thanks to Magnus! Welcome to Sean. -Ekr On Wed, Apr 16, 2014 at 7:17 AM, Ted Hardie wrote: > On Wed, Apr 16, 2014 at 7:04 AM, Richard Barnes wrote: > >> Dear RTCWEB, >> >> We're having a minor change of management in this WG. Magnus is stepping >> down in preparation for his upcoming parental leave. Sean Turner has >> kindly agreed to take his place. For those of you who don't know Sean, he >> was recently SEC AD, he chaired the S/MIME working group before that, and >> he's currently providing security expertise in the STIR working group. >> >> Many thanks to Magnus for his leadership in this working group! >> >> > I'd like to add my thanks to Magnus; as a chair, contributor (and host for > meetings), he's been a tremendous and positive influence on the development > of WebRTC. > > Sean, welcome, you have big boots to fill! > > Ted > > > > > >> --Richard >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b87389620368d04f72a4321 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, thanks to Magnus! Welcome to Sean.

-Ekr



On Wed, Apr 16, 2014 at 7:17 AM, Ted Hardie <ted.ietf@= gmail.com> wrote:
=
On Wed, Apr 16, 2014 at 7:04 AM, Richard Barnes <rlb@ipv.s= x> wrote:
Dear RTCWEB,

We're having a minor c= hange of management in this WG. =A0Magnus is stepping down in preparation f= or his upcoming parental leave. =A0Sean Turner has kindly agreed to take hi= s place. =A0For those of you who don't know Sean, he was recently SEC A= D, he chaired the S/MIME working group before that, and he's currently = providing security expertise in the STIR working group.

Many thanks to Magnus for his leadership in this workin= g group!


I'd like to add my thanks to Magnus; as a chair, contributor (and host = for meetings), he's been a tremendous and positive influence on the dev= elopment of WebRTC.

Sean, welcome, you have big boots to fill!

Ted



= =A0
--Richard


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b87389620368d04f72a4321-- From nobody Wed Apr 16 14:09:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A381A02CE for ; Wed, 16 Apr 2014 14:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 HgDjbupxTmUg for ; Wed, 16 Apr 2014 14:09:36 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.56.144.3]) by ietfa.amsl.com (Postfix) with ESMTP id 481D91A037D for ; Wed, 16 Apr 2014 14:08:22 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id EE155E095FD72; Wed, 16 Apr 2014 16:08:18 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 6E7C0E095E537 for ; Wed, 16 Apr 2014 16:08:12 -0500 (CDT) Received: from [96.231.225.192] (port=49623 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WaX3z-0005Ui-8K; Wed, 16 Apr 2014 16:08:11 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sean Turner In-Reply-To: Date: Wed, 16 Apr 2014 17:08:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla , Ted Hardie X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WaX3z-0005Ui-8K X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [96.231.225.192]:49623 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/biqetI_EQLJpL-H_uvv11fRkGUw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Change of co-chair X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 21:09:41 -0000 Thanks. I=92ll try my best! Obviously, going to take a wee-bit of time = to get up to speed. spt On Apr 16, 2014, at 11:05, Eric Rescorla wrote: > Yes, thanks to Magnus! Welcome to Sean. >=20 > -Ekr >=20 >=20 >=20 > On Wed, Apr 16, 2014 at 7:17 AM, Ted Hardie = wrote: > On Wed, Apr 16, 2014 at 7:04 AM, Richard Barnes wrote: > Dear RTCWEB, >=20 > We're having a minor change of management in this WG. Magnus is = stepping down in preparation for his upcoming parental leave. Sean = Turner has kindly agreed to take his place. For those of you who don't = know Sean, he was recently SEC AD, he chaired the S/MIME working group = before that, and he's currently providing security expertise in the STIR = working group. >=20 > Many thanks to Magnus for his leadership in this working group! >=20 >=20 > I'd like to add my thanks to Magnus; as a chair, contributor (and host = for meetings), he's been a tremendous and positive influence on the = development of WebRTC.=20 >=20 > Sean, welcome, you have big boots to fill! >=20 > Ted >=20 >=20 >=20 > =20 > --Richard >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Apr 16 15:41:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18821A03C9 for ; Wed, 16 Apr 2014 15:31:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 E7qvzqI7rcsS for ; Wed, 16 Apr 2014 15:31:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id B827B1A0365 for ; Wed, 16 Apr 2014 15:31:42 -0700 (PDT) Received: from BY2PR03MB427.namprd03.prod.outlook.com (10.141.141.146) by BY2PR03MB425.namprd03.prod.outlook.com (10.141.141.139) with Microsoft SMTP Server (TLS) id 15.0.918.8; Wed, 16 Apr 2014 22:31:38 +0000 Received: from BY2PR03MB427.namprd03.prod.outlook.com ([10.141.141.146]) by BY2PR03MB427.namprd03.prod.outlook.com ([10.141.141.146]) with mapi id 15.00.0918.000; Wed, 16 Apr 2014 22:31:38 +0000 From: Andrei Popov To: "rtcweb@ietf.org" Thread-Topic: draft-ietf-rtcweb-security-arch-09: DTLS 1.2 only? Thread-Index: Ac9Zw5ansFOV9k7GQvai4TDmd4zOig== Date: Wed, 16 Apr 2014 22:31:37 +0000 Message-ID: <99c75200c5e742b5946ec8e0a850e13d@BY2PR03MB427.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(86362001)(81542001)(54356999)(16236675002)(46102001)(50986999)(99286001)(77096999)(99396002)(76482001)(92566001)(74662001)(2656002)(76576001)(87936001)(81342001)(80022001)(15202345003)(86612001)(15975445006)(74502001)(79102001)(4396001)(77982001)(19300405004)(20776003)(31966008)(74316001)(19580395003)(83322001)(85852003)(83072002)(80976001)(33646001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB425; H:BY2PR03MB427.namprd03.prod.outlook.com; FPR:79FAE8DF.D3DA4CA.2D71954E.DC8C7C38.200DF; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_99c75200c5e742b5946ec8e0a850e13dBY2PR03MB427namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/P7aMW5knftGAZZTLujo-nV_JcF0 X-Mailman-Approved-At: Wed, 16 Apr 2014 15:41:45 -0700 Subject: [rtcweb] draft-ietf-rtcweb-security-arch-09: DTLS 1.2 only? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 22:31:45 -0000 --_000_99c75200c5e742b5946ec8e0a850e13dBY2PR03MB427namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-rtcweb-security-arch-09. says: " [[OPEN ISSUE: Are these the right cipher suites?]] All implementations MUST implement the following two cipher suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ..." These are (D)TLS 1.2 cipher suites; I think this requirement would exclude = DTLS 1.0 implementations. For easier/broader adoption, would it make sense = to allow DTLS 1.0? Cheers, Andrei --_000_99c75200c5e742b5946ec8e0a850e13dBY2PR03MB427namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-ietf-rtcweb-security-arch-09. says:=

 

“ [[OPEN ISSUE:  Are these the right ciph= er suites?]]  All

   implementations MUST implement the foll= owing two cipher suites:

   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and=

   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 &= #8230;”

 

These are (D)TLS 1.2 cipher suites; I think this req= uirement would exclude DTLS 1.0 implementations. For easier/broader adoptio= n, would it make sense to allow DTLS 1.0?

 

Cheers,

 

Andrei

--_000_99c75200c5e742b5946ec8e0a850e13dBY2PR03MB427namprd03pro_-- From nobody Wed Apr 16 16:27:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006061A0412 for ; Wed, 16 Apr 2014 16:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 LdANVKO2Rkol for ; Wed, 16 Apr 2014 16:27:06 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE301A040F for ; Wed, 16 Apr 2014 16:27:06 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so11430699wgg.1 for ; Wed, 16 Apr 2014 16:27:02 -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:content-type; bh=TWJ2I47KpVjGOjzuCC1yV1DJ8D1HywXuuguf00CPoac=; b=uMIT0dCLJyPZ043SdXvHyKxjoGB3qIEBwR0P9kv8UjSo2aXbRkvyE9BaD7hSGJH7QG XHYXeqM59BNwySYx9dgAw55J4iBr9Bl+MeKt1xbHhfEU2yMz0pkYFvM5uYMP8Bw7ETGo d6VEoxL8NjUcHgs0LBf8psXk0d1XICT3jKj+71vlbUS9EyKAw1U1q/W2eA7R1rKpzDXK XiNbJf/b7AkghbdeGEVkSshldJjNQzhw3TyYEfPp03Ealgro3WNjQRBZYcW2h4Pmoh8i aVZoeqp3sIo/t+EO2TMfelVf6sOOHWe8u5I9Up6UUyr7aDseAFqgbh+jCfULQ252fowX 94LQ== MIME-Version: 1.0 X-Received: by 10.180.82.133 with SMTP id i5mr21490588wiy.50.1397690822386; Wed, 16 Apr 2014 16:27:02 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 16 Apr 2014 16:27:02 -0700 (PDT) In-Reply-To: <534E7D83.3010608@ericsson.com> References: <533E76AC.7030003@ericsson.com> <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org> <534284B7.7010103@ericsson.com> <534D21C2.20300@ericsson.com> <534E7D83.3010608@ericsson.com> Date: Wed, 16 Apr 2014 16:27:02 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3_QGyYao8brfm6gXTw6sVZFtlE0 Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 23:27:11 -0000 On 16 April 2014 05:54, Magnus Westerlund wrote: > Is this better/acceptable? Better, but I don't think that the proposed solution is sufficient for some use cases. There is no downside to enabling correlation of sessions when the signaling entity is able to force correlation. Let the app set CNAME. From nobody Thu Apr 17 03:50:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A5A1A004D for ; Thu, 17 Apr 2014 03:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.346 X-Spam-Level: X-Spam-Status: No, score=-1.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 A4AyArPw3urg for ; Thu, 17 Apr 2014 03:50:21 -0700 (PDT) Received: from sessmg23.ericsson.net (unknown [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9893A1A0090 for ; Thu, 17 Apr 2014 03:50:20 -0700 (PDT) X-AuditID: c1b4fb2d-f79fa6d000007cbe-d7-534fb1e8a828 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C7.0D.31934.8E1BF435; Thu, 17 Apr 2014 12:50:16 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.174.1; Thu, 17 Apr 2014 12:50:15 +0200 Message-ID: <534FB1E7.4050300@ericsson.com> Date: Thu, 17 Apr 2014 12:50:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Martin Thomson References: <533E76AC.7030003@ericsson.com> <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org> <534284B7.7010103@ericsson.com> <534D21C2.20300@ericsson.com> <534E7D83.3010608@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvje6Ljf7BBqd+y1osf3mC0eLamX+M Fmv/tbM7MHtMu3+fzWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyjjz9xVzQRt3RefSKYwN jE2cXYycHBICJhITp/SxQ9hiEhfurWfrYuTiEBI4yigx6/4ZVghnOaNE/89dzCBVvALaEnP+ 7QfrYBFQlfi24jeYzSZgIXHzRyMbiC0qECyxdM5iFoh6QYmTM5+A2SICuhKLzj4Aq2cW8JJ4 vnMHI4gtLOAjcevyP6hll5gl2qYvAiviFAiUWLd4IZDNAXSeuERPYxBEr6ZE6/bfUHPkJZq3 zga7TQjotoamDtYJjEKzkKyehaRlFpKWBYzMqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjEC g/vglt+6OxhXv3Y8xCjAwajEw8um5hcsxJpYVlyZe4hRmoNFSZy37a53sJBAemJJanZqakFq UXxRaU5q8SFGJg5OqQZGob82fh8+vJhk2JV36r/bscW7mK6er+XQ/P3HQ3/OpgW/UryM0x3C Nyfddj1UvuqrqPUnhqTPt8wXt5jqK7c8YFB/trxx27akBtkZ7lcfuu3xvWAa6rGFkdWy+1PY 3u0q1z5xJz97a7Zg9cfvTc1uxSf/qJ9Zf7dScafKo7eX2vJnb1FtEPWQVWIpzkg01GIuKk4E AKflANxPAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wjqtOaAPeKIoVaMdzXe2dQCC8js Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 10:50:25 -0000 On 2014-04-17 01:27, Martin Thomson wrote: > On 16 April 2014 05:54, Magnus Westerlund > wrote: >> Is this better/acceptable? > > Better, but I don't think that the proposed solution is sufficient for > some use cases. There is no downside to enabling correlation of > sessions when the signaling entity is able to force correlation. Let > the app set CNAME. > Sure from privacy point of view, but there are a potential to really screw up RTP/RTCP by setting the same CNAME in multiple endpoints part of the same communication session. That is why I wrote like I wrote. Even using the same CNAME between different instances of the media framework, which I assume is the likely result of establishing PeerConnection in different tabs/windows in a browser instance could get into issues using the same CNAME, due to them really not being based on a common context. 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 Thu Apr 17 09:16:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46C31A0180 for ; Thu, 17 Apr 2014 09:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 BwOtcTTn0d6C for ; Thu, 17 Apr 2014 09:16:07 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 73A731A016F for ; Thu, 17 Apr 2014 09:16:06 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id w62so654247wes.14 for ; Thu, 17 Apr 2014 09:16:02 -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:content-type; bh=j2gd52WSWgATy2Gp2BFUg95yPwHry/XwUKz9WYVKr44=; b=l0yzKPBBuj8p3FraJkczh69n/nqvB6jUYmOZ2fc3fwKY39SoeM2VFW30BuRAgJXyJ3 RcooanLidQgrRrwujUq3FF6f04HAzNAB2N9tg9tIgOH1UGSaY724bXMjcHJSZi430dwE kJPh8FHe+s/rpxEof1xYnf3Kx15JVCFA5zJU99RgDoO/CQCb38EcoRMfqyccx/9yr85E 37NckU4PMSJ67kqwonXgPmyP3Sf5SZJ6S80yDehpkUrS/6ope05EqMhtzusJv+I5E0TB S3RUPhlEVTz4P0wpOxRfyNWKTgd+LBWNpwZg78Aq3W95YmuMsVWPPIqh9/p6XX37cSUG iD4w== MIME-Version: 1.0 X-Received: by 10.194.171.167 with SMTP id av7mr12702107wjc.32.1397751362435; Thu, 17 Apr 2014 09:16:02 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Thu, 17 Apr 2014 09:16:02 -0700 (PDT) In-Reply-To: <534FB1E7.4050300@ericsson.com> References: <533E76AC.7030003@ericsson.com> <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org> <534284B7.7010103@ericsson.com> <534D21C2.20300@ericsson.com> <534E7D83.3010608@ericsson.com> <534FB1E7.4050300@ericsson.com> Date: Thu, 17 Apr 2014 09:16:02 -0700 Message-ID: From: Martin Thomson To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sz7Pp170sZ67obktNqnqwT5bCCw Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:16:11 -0000 On 17 April 2014 03:50, Magnus Westerlund wrote: > On 2014-04-17 01:27, Martin Thomson wrote: >> On 16 April 2014 05:54, Magnus Westerlund >> wrote: >>> Is this better/acceptable? >> >> Better, but I don't think that the proposed solution is sufficient for >> some use cases. There is no downside to enabling correlation of >> sessions when the signaling entity is able to force correlation. Let >> the app set CNAME. >> > > Sure from privacy point of view, but there are a potential to really > screw up RTP/RTCP by setting the same CNAME in multiple endpoints part > of the same communication session. That is why I wrote like I wrote. > Even using the same CNAME between different instances of the media > framework, which I assume is the likely result of establishing > PeerConnection in different tabs/windows in a browser instance could get > into issues using the same CNAME, due to them really not being based on > a common context. Sure, WFM. From nobody Fri Apr 18 07:53:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2590F1A0303 for ; Fri, 18 Apr 2014 07:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 jgkMOvkUDEYt for ; Fri, 18 Apr 2014 07:53:13 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0474F1A01AF for ; Fri, 18 Apr 2014 07:53:12 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id B02A8A0124 for ; Fri, 18 Apr 2014 14:53:08 +0000 (UTC) X-hush-tls-connected: 1 Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS for ; Fri, 18 Apr 2014 14:53:08 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 46CB4A039F; Fri, 18 Apr 2014 14:53:08 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 18 Apr 2014 10:53:08 -0400 To: rtcweb@ietf.org From: srivastava_samir@hush.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20140418145308.46CB4A039F@smtp.hushmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9F04a3WNNI2Zsfz3R4D2y7k064g Subject: [rtcweb] Question on draft-ietf-rtcweb-use-cases-and-requirements-14 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 14:53:14 -0000 Hi, I am new to rtcweb so pl excuse my lack of knowledge. 1) Refer F33 The browser must be able to initiate and accept a media session where the data needed for establishment can be carried in SIP. In other places in other documents it is stated that browser is given freedom to do signaling it likes. Then this requirement will be met with signaling gateway. And there is no work in progress for that. Whether IETF mandates for browser to understand SIP or not? 2) It will be better if 1-800-Go-Fedex (Fedex call) is referred as IVR call and Fedex should be taken out as SKYPE was taken out. Thanks Samir From nobody Sat Apr 19 12:24:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9636D1A007F for ; Sat, 19 Apr 2014 12:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 mM6HkcHtKxTg for ; Sat, 19 Apr 2014 12:24:09 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D55C71A0078 for ; Sat, 19 Apr 2014 12:24:08 -0700 (PDT) X-AuditID: c1b4fb25-f798a6d000005ede-47-5352cd539d31 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.0E.24286.35DC2535; Sat, 19 Apr 2014 21:24:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Sat, 19 Apr 2014 21:24:03 +0200 From: Christer Holmberg To: "srivastava_samir@hush.com" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Question on draft-ietf-rtcweb-use-cases-and-requirements-14 Thread-Index: AQHPWxXtCGStWlqQ+EKzKQuSkPMxS5sZUneg Date: Sat, 19 Apr 2014 19:24:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2D16CE@ESESSMB209.ericsson.se> References: <20140418145308.46CB4A039F@smtp.hushmail.com> In-Reply-To: <20140418145308.46CB4A039F@smtp.hushmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW7w2aBggxsf9CzW/mtnt3hwrJXN gclj2fl9zB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4dXcDY8E1toqbu/pZGhibWbsYOTkkBEwk fu44zwRhi0lcuLeerYuRi0NI4CijxIb+S4wQzhJGiQtTprJ3MXJwsAlYSHT/0wZpEBFIknj5 YTUbiC0sECwx599iVoh4iETj8rfsELaRROu1+4wgNouAqsS/hcfB4rwCvhKfXr1mAbGFBCwl vn/4ARbnFLCSuPzsKlicEeig76fWgB3HLCAucevJfKhDBSSW7DnPDGGLSrx8/A/qGSWJtYe3 s0DU60gs2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFqcVJu upGxXmpRZnJxcX6eXl5qySZGYJwc3PJbdQfj5TeOhxgFOBiVeHjZ1PyChVgTy4orcw8xSnOw KInzfrnlEywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsW9j0TTZ599/HZFyYa8LXL537on5 97+YVx5eJtH325b92Lv9Su9+Sl2O9L2d/6Fc/K9gTaDPtZ93lgvP/NifeoN1ZeLWZ84ml3Lb 7Q0bDr7eaR/Lsq+Qed65Gys3T1y9Zr3/D667tU0SgrNcP/395fPs8sHwOa9brwaXNFcphT76 Xffuj3L7ga9KLMUZiYZazEXFiQDQEAkxdAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KDbnFKvntFUfxx6Xsy_SBcnSFmA Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-use-cases-and-requirements-14 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 19:24:10 -0000 Hi, =20 >1) Refer=20 > F33 The browser must be able to initiate and > accept a media session where the data needed > for establishment can be carried in SIP. > > In other places in other documents it is stated that browser is given f= reedom to do signaling it=20 > likes. Then this requirement will be met with signaling gateway. And ther= e is no work in progress=20 > for that. Whether IETF mandates for browser to understand SIP or not? Not. IETF does mandate the browser to understand SDP, though (as part of JSEP). >2) It will be better if 1-800-Go-Fedex (Fedex call) is referred as IVR cal= l and Fedex should be taken >out as SKYPE was taken out. Which version did you look at? Skype has been removed from the latest versi= on (-14). Fedex is still there, though. Regards, Christer From nobody Sun Apr 20 08:39:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BEF1A000A for ; Sun, 20 Apr 2014 08:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 WOmbG8Lz7b71 for ; Sun, 20 Apr 2014 08:38:57 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id D6C7A1A0008 for ; Sun, 20 Apr 2014 08:38:56 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id c41so3046053eek.36 for ; Sun, 20 Apr 2014 08:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=SiIU7XoDdXrRIpYTLysUY2oN+S4e1RrZJZc69I5QKKM=; b=nqGtvdwjSSOq2XChreDWithlz3FkVReLgdiacBRpnr4ocC9e2ExFV+bmuA/V2nH56N 1d9w7y2rl5A9Mfdv2xaeId7WjHMt0q8IaQf/wFE21mXn7eHmdOSpwRWM8OGG2CO6brHB bZHf4C98y8Qe09ujGGJV+w1gBTqK570A9/OfeuaWGqCY7Rk6T6ghCsh1qs2tHgL1upJL hKl9d7ChyRVjuJwo1kmlQPsGwPHacRyvN95gQAXJwRC0nfIIqT64OQt8YKQy4Fpm533P 9V6BHEsXVdD+2Qs8tmYidlXHhXbJRLNh4Ssn/d4416140f+EkLmKj/tv+fLrXX4PYU/k vNeQ== X-Received: by 10.14.206.137 with SMTP id l9mr39691222eeo.40.1398008331695; Sun, 20 Apr 2014 08:38:51 -0700 (PDT) Received: from RoniE ([109.67.104.144]) by mx.google.com with ESMTPSA id x45sm95512772eef.15.2014.04.20.08.38.49 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 20 Apr 2014 08:38:50 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Harald Alvestrand'" , References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no> <534288C2.6010906@ericsson.com> <5342ABBB.9050300@alvestrand.no> <534D4CC4.9040107@ericsson.com> In-Reply-To: <534D4CC4.9040107@ericsson.com> Date: Sun, 20 Apr 2014 18:38:46 +0300 Message-ID: <021801cf5cae$9fe25970$dfa70c50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKAdRtyny0O/9Ki8/9GVI+Yi+W4VAKvzAr7AQtGn5wBZ5knWQIJh4ZSmX8PMXA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cz9Q77wgDrkvWvJKCWm-r_CSE1o Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 15:39:01 -0000 Hi Magnus, I am OK with the text. Do you think that for Multiparty we should state that a mixed conference (WebRTC and non WebRTC participants) is possible and should also support these rules. =20 Roni=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: 15 April, 2014 6:14 PM > To: Harald Alvestrand; rtcweb@ietf.org > Subject: Re: [rtcweb] Draft proposal for updating Multiparty = topologies in draft- > ietf-rtcweb-rtp-usage >=20 > Hi, >=20 > I have considered these comments and are okay with modifying the > recommendation. I have modified the proposed text from Harald = somewhat. > My proposal is the following: >=20 >=20 > WebRTC implementations of RTP endpoints implemented according to = this > memo are expected to support all the topologies described in > [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints = send > and receive unicast RTP packet streams to and from some peer = device, > provided that peer can participate in performing congestion control > on the RTP packet streams. The peer device could be another RTP > endpoint, or it could be an RTP middlebox that redistributes the = RTP > packet streams to other RTP endpoints. This limitation means that > some of the RTP middlebox-based topologies are not suitable for use > in the WebRTC environment. Specifically: >=20 > o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, > since they make the use of RTCP for congestion control and = quality > of service reports problematic (see Section 3.8 of > [I-D.ietf-avtcore-rtp-topologies-update]). >=20 > o The Relay-Transport Translator (Topo-PtM-Trn-Translator) = topology > SHOULD NOT be used because its safe use requires a point to > multipoint congestion control algorithm or RTP circuit breaker, > which has not yet been standardised. >=20 > The following topology may be used, however it has considerations > worth noting: >=20 > o Content modifying MCUs with RTCP termination (Topo-RTCP- > terminating-MCU) MAY be used. Note that in this RTP Topology, = RTP > loop detection and identification of active senders is the > responsibility of the WebRTC application; since the clients are > isolated from each other at the RTP layer, RTP cannot assist = with > these functions (see section 3.9 of > [I-D.ietf-avtcore-rtp-topologies-update]). >=20 >=20 > Please provide feedback on this text! >=20 > Please see further response to questions and comments inline below. >=20 >=20 > On 2014-04-07 15:44, Harald Alvestrand wrote: > > On 04/07/2014 01:15 PM, Magnus Westerlund wrote: > >> On 2014-04-07 10:12, Harald Alvestrand wrote: >=20 > >>> In my (strong) opinion: This recommendation is wrong. > >>> > >>> All central conferencing units that use individual RTP sessions = with > >>> clients fall into this category. This includes, I believe, every > >>> single multiuser video conferencing system based on WebRTC in > >>> existence (and there are many of them). > >> Do they? The point of this topology is that it terminates the = source > >> identification and hides when it is performing any type of mixing = or > >> switching operation. You can perform this with a back to back RTP > >> session style without breaking this property. Just by correctly > >> linking information between the sessions. > > > > Is there a definition for "correctly linking information"? > > In particular, are you thinking of mappings that preserve SSRC? > > Because that's not the ones I'm thinking of. >=20 > The correctly linking information is mostly a question of preserving CNAMEs > across the middlebox to ensure that an end-point can determine > synchronization contexts, and origin if CSRC are used. As we add additional > meta data about streams they may also needs to preserved depending on > scope. Here it becomes a question of how one deals with APPID and = MSID. >=20 > Preserving SSRC is a choice, if one does it then loop detection works, = if one > doesn't preserve it it doesn't. Preserving it avoids having to remap = any > information that have global scope across the legs. >=20 > It becomes a choice on what complexities one needs to handle, common > uniqueness requirements versus remapping I think is the major = trade-off. >=20 > > > >> Which means that the individual RTP session is from the > >> identification part inseparable from an SFM or classic RTP mixer. > >> Only the SSRC level loop detection gets impacted. > >> > >> I do understand that people have implemented it this way. > >> Implementation are not necessarily equivalent to recommended = practice. > > > > But when there's one common practice, and no recommended practice, > > that might be a gentle hint that there's a reason why people are = doing > > it - indeed, it might be worth making it a recommended practice. >=20 > You are welcome to propose changes regarding this to the = topologies-update > document in AVTCORE WG. >=20 > >> > >>> I believe the recommendation should be: > >>> > >>> * Content modifying MCUs with RTCP termination > >>> (Topo-RTCP-terminating-MCU) MAY be used. Note that in this = scenario, > >>> RTP loop detection and identification of active senders is the > >>> resposibility of the application; since the clients are isolated > >>> from each other at the RTP layer, RTP cannot assist with these functions. > >>> > >> If this topology was without issues, then one would simply remove = the > >> bullet, and let it fall under the general clause. However, it = clearly > >> needs that warning. Which results in this topology being both > >> positively and negatively treated in regards to the other "you may > >> encounter this topology". > > > > It might need that warning - I'm not sure it's a real issue; loop > > detection is only an issue when you have potential loops, and in a > > single-mixer architecture, that potential is minimal (each endpoint > > knows perfectly well the difference between what it's sourcing and > > what it's receiving). Identification of active senders can be an > > application-layer thing. >=20 > Yes, I agree that in a basic conference application with only a single server > instance this is unlikely to form a loop. If one starts doing more = complex things, > including multi-server conferences or PeerConnection Meshes things = become > more complex. The later we anyway have removed the RTP loop detection = due > to the CNAME being unique on PeerConnection level, but I do think that = is the > right trade-off from privacy point of view. >=20 > > > > Anyway, I stand by my statement: SHOULD NOT is the wrong thing to = say. >=20 > I do accept this, and are willing to change the recommendation. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Apr 21 05:13:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3DB1A0207 for ; Mon, 21 Apr 2014 05:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 VV2HaohwLTwR for ; Mon, 21 Apr 2014 05:13:23 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id 91DE21A0209 for ; Mon, 21 Apr 2014 05:13:20 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404211413130034; Mon, 21 Apr 2014 14:13:13 +0200 From: "Karl Stahl" To: "'Simon Perreault'" , "'Pal Martinsen \(palmarti\)'" , "'Harald Alvestrand'" , "'Magnus Westerlund'" References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> In-Reply-To: Date: Mon, 21 Apr 2014 14:13:12 +0200 Message-ID: <020501cf5d5b$117e9830$347bc890$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPTQQB2UV1VISa20ivIvWZybl59Jr7de0AgAABWoCAAAFxAIAAAHRfgAHi2oCAHmncUIAAO+RA Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/s2P3wXAU_72FRxroOUl6MwrqpBU Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 12:13:27 -0000 1) AVOIDING SELF DESTRUCTING PRIORITAZATION FROM FILE TRANSFER IN DATA CHANNEL Simon, I saw you are an author of TURN-TCP RFC6062. Doesn't that RFC allow a=20 webrtc file transfer channel (separate from the rtcweb data channel)=20 to be created, using TLS file transfer P2P? ICE/STUN/TURN would set=20 it up, NOT BUNDLED with chunk data and RTP media. Freeing the current rtcweb data channel from file transfer would remedy=20 the self destruction of prioritization/QoS for data chunks and RTP media = as explained in (A), (B) and (C) below. I also think it would be much better for a web programmer to have a=20 separate p2p file transfer channel (that is not and cannot be = prioritized)=20 than pouring files into the data channel. 2) MARKING PRIORITY DATA AND MEDIA FOR NETWORK LEVEL PRIORITIZATION/QoS P=E5l, Harald, Magnus, Collins, Tiru, Dan, We have previously discussed how to convey traffic info (bandwidth=20 requirement, and traffic type/prio) from the browser/application to=20 the network layer to prioritize or take other QoS measure by some=20 network element. I have been pushing for inserting such traffic info into every RTP=20 media packet in the RTP header extension, see [1] below. After looking how to mark data channel priority data chunks similarly,=20 I suggested [2] below, i.e. a new DTLS ContentType for the rtcweb=20 data channel, where the content would be the unencrypted traffic=20 info (preferable the same as in the RTP header extension) followed by=20 the SCTP data.=20 Are there other ways? - Maybe more similar, consistent and/or better? We need the traffic info (contrary to e.g. DSCP bits) to be unchanged=20 end-to-end and available in both STUN and TURN flows for network=20 elements to see and act upon (e.g. to set DSCP bits or reserve=20 bandwidth or otherwise regulate) for various network types. The=20 traffic info must also be possible for network elements to find. No way b!) Since webrtc now mandates DTLS-SRTP for media, cannot=20 that DTLS also hold the traffic info, just as for the data chunks=20 - instead of putting the traffic info into the RTP header extension?=20 NO, here the DTLS is only in the key exchange packets - not in every=20 packet so that would NOT work, unfortunately. A way c?) Why not send data chunks in SRTP (instead of SCTP) and=20 reuse the RTP header extension for the traffic info for the network=20 layer. (File transfer is done in 1) above - not here!) What other things from SCTP do we actually want? (Not everything=20 from that complex protocol for carrying telephony signaling can be=20 of interest for webrtc.)=20 - Priority (local): The browser could have a prioritizing mechanism=20 including both media and data chunks before putting it in the UDP=20 socket (simpler than SCTP). - Reliable data: A small transaction layer with retransmission of=20 reliable data chunks could be implemented by the browser (simpler=20 than SCTP). So with this way c, SCTP would go away totally and only the RTP=20 header extension would be used for traffic info to the network layer. Are there more ways? We need this traffic info to allow WebRTC with=20 acceptable QoS over all network types (especially mobile Internet/OTT=20 LTE and Cable Networks that are of reservation type). Below are also a few comments to other feedback. =20 /Karl On 10 Apr 2014, at 17:35, Paul Kyzivat [pkyzivat@alum.mit.edu] wrote: I presume you mean each *concurrent* file transfer must use its own = channel. Right? Reusing the same channel to transfer a series of files should be fine. Thanks, Paul [Karl] Yes, That is right. /Karl On 10 Apr 2014, at 15:14, Harald Alvestrand [harald@alvestrand.no] = wrote: Just checking... since there's been no comment to the main body of the = text here (it's all been on the SCTP aspect), is it OK to include the text in = my next version of the -transport draft? (I'm not responding to Karl's comments - it's at a completely different level of complexity.) [Karl] Yes, it is but needs to be addressed. I think file transfer=20 just be taken out of the data channel, and a file transfer channel=20 (on a separate flow, as suggested above) be defined for Web=20 programmers to use. That would remedy (A), (B) and (C) below (p2p=20 file transfer not destroying priority for data chunks and media).=20 The file transfer channel would not/cannot be prioritized.=20 On 03 Apr 2014, at 21:12, Michael Tuexen [Michael.Tuexen@lurchi.franken.de]wrote: >Is there an > overall design/thought somewhere that I missed/am unaware of?) The basis idea is to use a stream scheduler to handle streams different. Some data channels can get a higher bandwidth than others. Since the priority stuff is still in flux in W3C, it hasn't been nailed down in = the SCTP spec. I guess, the place will be in http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00 This document is not finalized yet. > [Karl] There are severe limitations for doing prioritization in a=20 protocol (SCTP or other) executed in the endpoints. In most cases=20 there are no packets in the endpoint to put first among queued up=20 traffic, because the queue is somewhere else between the endpoints.=20 Just consider the most common case where the endpoints are connected=20 with a fast Ethernet. The data has then already left the endpoint and=20 is queued up at some congestion point in the network where the SCTP=20 protocol cannot rearrange the queue. First when that unreachable=20 queue is full, there is something in the endpoint to act upon... -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Karl Stahl Skickat: den 3 april 2014 18:30 Till: 'Matthew Kaufman (SKYPE)'; 'Harald Alvestrand'; 'Magnus = Westerlund' Kopia: rtcweb@ietf.org =C4mne: Re: [rtcweb] Some language on "prioritization" The questions raised here don't have simple "local or endpoint=20 answers". There are overall and basic things to be made clear first.=20 Combining P2P file transfer over the rtcweb data channels with=20 prioritized traffic chunks, brings further complications to the=20 prioritization/QoS issue. This cannot be handled/done by endpoint=20 or applications without considering the transport network (The=20 congestion to handle by prioritization is in the network - NOT in=20 the endpoints)!=20 There are below (A), (B) and (C) - to get us back to normal -=20 then there is (D) to improve - to allow the network level to=20 give us the prioritization required for WebRTC critical traffic=20 (real-time and data chunks). Without (D) - an interface to=20 network QoS equipment - the network does not even know what to=20 prioritize. I am afraid that this will be considered "back to the drawing board"=20 rather than "some language" but I cannot see the way forward if not=20 considered.=20 Has the SCTP data channel been constructed with hopes of=20 prioritization/quality functionality that simply are not there=20 (cannot be there)? (I have browsed the (complex) SCTP spec and=20 some rtcweb drafts to get an understanding of the=20 prioritization/QoS thoughts and means in this rtcweb context=20 and the intended usage. Is there an overall design/thought=20 somewhere that I missed/am unaware of?) File transfer - getting a larger amount of data through between=20 endpoints as quickly as possible - CANNOT be prioritized over=20 IP networks! For file transfer we normally use TCP, meaning we=20 fill the pipe, until THE ENDPOINTS see packet drop and regulate=20 down their traffic flow. File transfer over IP networks works=20 this way and cannot be improved upon ("Internet would stop" if=20 we prioritized such traffic! The available bandwidth at congestion=20 points are shared between everyone's TCP-flows hitting such=20 congestion points in the network.) File transfer's nature is=20 to have "infinite bandwidth demand" - the mechanism to handle=20 this is to allow file transfer to "take the rest of the bandwidth"=20 after prioritized media and chunks have taken their needed share.=20 The improvement to make - prioritization of media traffic and=20 data chunks - is to allow level 3 QoS methods - not only relying=20 on the level 4 TCP backing off process. Without level 3 QoS=20 (diffserve/DSCP, reservation or separate pipes) media and data=20 chunks packets are also lost in the level 4 TCP backing off=20 process (=3Dtoday's situation over best effort Internet). That is=20 where the prioritization/QoS measures that we need for rtcweb=20 have to be. SCTP in itself (instead of TLS/TCP) does not/cannot/will not=20 improve things. It can destroy though if wrongly/badly=20 implemented or used! >From the SCTP RFC4960: 7. Congestion Control ...adequate resources will be allocated to SCTP traffic=20 to ensure prompt delivery of time-critical data ... unlikely,=20 during normal operations, that transmissions encounter severe=20 congestion conditions. =20 However, SCTP must operate under adverse operational conditions, which can develop upon partial network failures=20 or unexpected traffic surges. In such situations, SCTP must=20 follow correct congestion control steps to recover from=20 congestion quickly in order to get data delivered as soon as=20 possible. =20 ... SCTP congestion control is always applied to the entire=20 association, and not to individual streams. Doing file transfer with the data channel will use SCTP in the=20 "adverse operational conditions, which can develop upon partial=20 network failures or unexpected traffic surges"-mode! Has that been=20 considered when constructing the data channel? Hope so... Assuming SCTP is implemented correctly and as good as TCP for=20 file transfer (even though file transfer =3D filling the pipe=20 mode is an "adverse condition..." for SCTP). Then we must specify: (A) Rtcweb file transfer MUST NOT use the same data channel as=20 data chunks expected to have prioritized delivery (otherwise,=20 as per above, SCTP will regulate the "the entire association"=20 to share the available bandwidth at the congestion point -=20 self-destroying the expected prioritized delivery of data chunks=20 in the same channel). (B) Each rtcweb file transfer MUST use its own data channel (if=20 combined they risk being regulated randomly/unfairly by SCTP=20 itself and all files will have just have one single TCP-like=20 flow at the network congestion point when sharing the available=20 bandwidth with everyone else's flows at that congestion point=20 - That would be "negative priority" compared to what we are used=20 to in a browser.). FURTHER, to allow the underlying network the ability to handle=20 the real-time and data chunks as least as good as "before rtcweb"=20 (Unfortunately this will make NAT-firewall less good - not sending=20 everything P2P in a single bundle/flow - I don't like it either...=20 Sorry...): (C) File transfer using the data channel MUST NOT be bundled=20 with media and data chunk traffic in the same flow - file=20 transfer must use a separate socket creating another flow/5-tuple=20 over the network.=20 (In reservation type of networks (e.g. mobile OTT, cable), file=20 transfer - having no bandwidth limitation - would otherwise=20 overflow the reserved bandwidth for media and chunck traffic -=20 destroying prioritized delivery of media and chunck traffic=20 over that flow.) Such file transfer data channels MUST NOT be=20 prioritized by the underlying network (applies to all IP network=20 types, network prioritization of file transfer will STOP traffic=20 between endpoints - Endpoint's TCP-like regulation has to function!). Several file=20 transfers could share such a separate flow (without specifying in=20 SDP I guess) but the underlying network must be able to separate=20 such flows (not to be prioritized) from media and chunk flows.=20 In the API, such file transfer data channel could be mapped to=20 the "below normal" classification (but would it not be better=20 with a "file transfer channel" API instead?). (And notice that=20 without (D) below, the network is not informed how to separate a=20 file transfer data channel flow from a prioritized data channel=20 flow.) Having (A), (B) and (C) in place we are BACK TO THE CURRENT=20 Internet prioritization/QoS level - before the rtcweb p2p data=20 channel file transfer was introduced... Now remains the prioritization improvement required for quality=20 hungry rtcweb! Both for the real-time media and the data chuncks. (D) The underlying transport network needs to be informed about=20 the traffic requirements.=20 - In RTP media this traffic info could be inserted by the rtcweb=20 browser in the RTP header extension [1] depending on codec usage=20 etc. The API classification could be mapped to the=20 "Prioritize X(2 bits)" suggested in [1] below. - for the data channel, the traffic info could be inserted as=20 suggested in previous email ([2] below)=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973.html =20 Note that the required bandwidth (only known by the=20 browser/application) has to be passed to reservation types of=20 network. Requested prioritization from the API or DSCP bits are=20 not sufficient. The browser knows the bandwidth requirements for=20 codecs, but for data chunks, the application has the knowledge.=20 In lack of a bandwidth parameter in the data channel API, a simple=20 convention - e.g. reserve 200 kbps for data chunks could serve as=20 a compromise (or 4 bandwidths mapped to the API prioritize=20 classifications...). A modified API with the bandwidth requirement=20 spelled out would of course be better for the chuck data channel.=20 For a file transfer data channel - prioritization classification=20 does not even apply. =20 Having prioritization over the network cleared, the application=20 should use that transport properly - having media and data chunks=20 transported with prioritization (as produced/inserted), NOT queuing=20 them up, rearranged by protocols or applications and NOT involving=20 file transfer (that has to be unprioritized).=20 Using DSCP bits if available through the OS in some situations does=20 not help either, as already pointed out in the transport document.=20 For (D) above, DSCP bits could in a few situations function locally,=20 but not end-to-end, so of no use generally.=20 =20 /Karl [1] Traffic type information to encode (recreating the=20 idea/intention of the RTP payload type (PT) header that is not=20 available for the network level anymore, by instead having the=20 browser filling the RTP header extension with relevant traffic=20 info that all IP network types can use.), as suggested already=20 October 22. Two parameters to encode=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html=20 A) The maximum bandwidth requirement: Two bytes could contain=20 everything from some bps for real-time text to Gbps for future 3D=20 supersize telepresence on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest=20 bit set to 1, we could allocate a bit each for quality type e.g:=20 Best Effort, Audio, Video, Supplemental Video, Gaming, Data,=20 Delay Insensitive (e.g. video streaming), Minimum Delay,=20 Reliable Delivery, Prioritize X(2 bits), Variation Y(2 bits),=20 that could be combined as required to describe the stream. And with the highest bit set to 0, there could instead be a number=20 for special usage that does not fit the general description of=20 the individual bits. Without this information, how could e.g. a reservation type=20 network (e.g. mobile OTT and cable) reserve the bandwidth=20 required for incoming rtcweb media or data chunks from a diffserve=20 network (carrying no bandwidth requirement)?=20 =20 [2] A new DTLS ContentType (e.g. 24 instead of current 23) for the=20 rtcweb data channel, where the content would be the unencrypted=20 traffic info (preferable the same as in the RTP header extension)=20 followed by the SCTP data as it is today (where it today comes=20 directly in the DTLS as the only content).: TODAY: Content Type: 23 (1 byte) content type 23 means =93application data=94 DTLS version: 0xfeff (2 byte) Epoch: 0001 (2 byte) Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 byte Encrypted application data: ...... =3D the SCTP =20 SUGGESTION WITH ADDED TRAFFIC INFO FOR LOWER LEVELS:=20 Content Type: 24 (1 byte) content type 24 meaning =93application data = preceded by traffic info=94 DTLS version: 0xfeff (2 byte) Epoch: 0001 (2 byte) Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 byte: length of the encrypted application data = after the new header extension TRAFFIC INFO, Same as suggested for the RTP Header extension:=20 Encrypted application data: ...... ...... =3D the SCTP unchanged -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Matthew Kaufman = (SKYPE) Skickat: den 31 mars 2014 19:50 Till: Harald Alvestrand Kopia: rtcweb@ietf.org =C4mne: Re: [rtcweb] Some language on "prioritization" And if SCTP and RTP have packets to send, which goes first, why, and = under what circumstances? Matthew Kaufman (Sent from my iPhone) > On Mar 31, 2014, at 10:48 AM, "Harald Alvestrand" = wrote: >=20 >> On 03/31/2014 07:42 PM, Michael Tuexen wrote: >>> On 31 Mar 2014, at 19:38, Martin Thomson wrote: >>>=20 >>>> On 31 March 2014 10:08, Harald Alvestrand = wrote: >>>> -- TODO: Specify a relative priority scheme that makes sense with=20 >>>> SCTP, with an appropriate reference.=20 >>>> [draft-ietf-tsvwg-sctp-prpolicies] >>>> specifies a priority policy, but it's about discarding packets, not = >>>> deciding which packets to send first, and it also makes it=20 >>>> impossible to specify time-bounded retransmission. -- >>>=20 >>> Why would SCTP need special treatment? I can understand if there=20 >>> are particular time-sensitive control messages that need to be given = >>> higher priority, but this is all time-sensitive. >> A single transport connection (in this case an SCTP association) can=20 >> only use a single DSCP. So it would be OK to use the same priority=20 >> for all data channels, but things get complicated when when some data = >> channels would have different priorities requiring different DSCP markings. >=20 > The SCTP protocol machine will, at some given moment in time, have=20 > packets in its send buffers that belong to multiple data channels.=20 > Only one of them can go on the wire first. >=20 > Which packet does it choose to send first, and why? >=20 > That's the question I'm looking for an answer to. >=20 > If the answer has an RFC number, chapter and section, I'd be very = happy. > If it doesn't - perhaps we have to invent one. > Or say that it's "implementation dependent". >=20 From nobody Mon Apr 21 07:45:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228481A0228 for ; Mon, 21 Apr 2014 07:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 XMq2TPBtL3YX for ; Mon, 21 Apr 2014 07:45:22 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id C7B3E1A021F for ; Mon, 21 Apr 2014 07:45:21 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta15.westchester.pa.mail.comcast.net with comcast id scWb1n0011c6gX85FelGdf; Mon, 21 Apr 2014 14:45:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id selG1n0063ZTu2S3jelGcL; Mon, 21 Apr 2014 14:45:16 +0000 Message-ID: <53552EFC.3000502@alum.mit.edu> Date: Mon, 21 Apr 2014 10:45:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> <020501cf5d5b$117e9830$347bc890$@stahl@intertex.se> In-Reply-To: <020501cf5d5b$117e9830$347bc890$@stahl@intertex.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398091516; bh=xzao469DI12ModKiHqyaKItgqyhX723HP6x2end9xHw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YQRLV6zwCCztS9hpRDbSvy+5NKblCv10lils5O8ckc1NIcOwHz0JdszvmhidTR+0z KNvllIawdH2pDMNjiqyqR6PNSR6l0D0gmLpwDTVDQCaF4AvBk5XkDl/DnWUOWvX+av ep2ooQBinPMyc7IpAGGQsGrKVpwlw9UjbX1Vwv/dZMYc3BZzrd6adeqxSfnp2NMTtG hkBoFtzatK7dybxbCcjGYqSXmSi4cMAYGQw0EPM1wCnDPjSHkOcnDDpygvIhDo5m0+ knarMJVtRpRvrwiThp8Ydp7JdhXQDEHtA0UiDt+Dpjy5WxkBypmsa/WRRKSRCWyO9K SLWhIbq/Ekchg== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EEpDfB1d3Vk4TBbZZYVHdLvhPbg Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 14:45:26 -0000 It bothers me to see file transfer singled out for special treatment. File transfer is one (common) example of a potentially high volume stream that has low requirements on latency. There are certainly other use cases with similar characteristics that are not file transfers. If it isn't feasible to manage data channels with differing priority needs within the same SCTP association, then why not simply make provision for multiple SCTP associations, with a priority for each? Thanks, Paul On 4/21/14 8:13 AM, Karl Stahl wrote: > 1) AVOIDING SELF DESTRUCTING PRIORITAZATION FROM FILE TRANSFER IN DATA > CHANNEL > > Simon, > > I saw you are an author of TURN-TCP RFC6062. Doesn't that RFC allow a > webrtc file transfer channel (separate from the rtcweb data channel) > to be created, using TLS file transfer P2P? ICE/STUN/TURN would set > it up, NOT BUNDLED with chunk data and RTP media. > > Freeing the current rtcweb data channel from file transfer would remedy > the self destruction of prioritization/QoS for data chunks and RTP media > as explained in (A), (B) and (C) below. > > I also think it would be much better for a web programmer to have a > separate p2p file transfer channel (that is not and cannot be prioritized) > than pouring files into the data channel. > > > 2) MARKING PRIORITY DATA AND MEDIA FOR NETWORK LEVEL PRIORITIZATION/QoS > > Pål, Harald, Magnus, Collins, Tiru, Dan, > > We have previously discussed how to convey traffic info (bandwidth > requirement, and traffic type/prio) from the browser/application to > the network layer to prioritize or take other QoS measure by some > network element. > > I have been pushing for inserting such traffic info into every RTP > media packet in the RTP header extension, see [1] below. > > After looking how to mark data channel priority data chunks similarly, > I suggested [2] below, i.e. a new DTLS ContentType for the rtcweb > data channel, where the content would be the unencrypted traffic > info (preferable the same as in the RTP header extension) followed by > the SCTP data. > > Are there other ways? - Maybe more similar, consistent and/or better? > > We need the traffic info (contrary to e.g. DSCP bits) to be unchanged > end-to-end and available in both STUN and TURN flows for network > elements to see and act upon (e.g. to set DSCP bits or reserve > bandwidth or otherwise regulate) for various network types. The > traffic info must also be possible for network elements to find. > > No way b!) Since webrtc now mandates DTLS-SRTP for media, cannot > that DTLS also hold the traffic info, just as for the data chunks > - instead of putting the traffic info into the RTP header extension? > NO, here the DTLS is only in the key exchange packets - not in every > packet so that would NOT work, unfortunately. > > A way c?) Why not send data chunks in SRTP (instead of SCTP) and > reuse the RTP header extension for the traffic info for the network > layer. (File transfer is done in 1) above - not here!) > > What other things from SCTP do we actually want? (Not everything > from that complex protocol for carrying telephony signaling can be > of interest for webrtc.) > > - Priority (local): The browser could have a prioritizing mechanism > including both media and data chunks before putting it in the UDP > socket (simpler than SCTP). > > - Reliable data: A small transaction layer with retransmission of > reliable data chunks could be implemented by the browser (simpler > than SCTP). > > So with this way c, SCTP would go away totally and only the RTP > header extension would be used for traffic info to the network layer. > > > Are there more ways? We need this traffic info to allow WebRTC with > acceptable QoS over all network types (especially mobile Internet/OTT > LTE and Cable Networks that are of reservation type). > > > Below are also a few comments to other feedback. > > /Karl > > > On 10 Apr 2014, at 17:35, Paul Kyzivat [pkyzivat@alum.mit.edu] wrote: > I presume you mean each *concurrent* file transfer must use its own channel. > Right? Reusing the same channel to transfer a series of files should be > fine. > > Thanks, > Paul > [Karl] Yes, That is right. /Karl > > On 10 Apr 2014, at 15:14, Harald Alvestrand [harald@alvestrand.no] wrote: > Just checking... since there's been no comment to the main body of the text > here (it's all been on the SCTP aspect), is it OK to include the text in my > next version of the -transport draft? > > (I'm not responding to Karl's comments - it's at a completely different > level of complexity.) > > [Karl] Yes, it is but needs to be addressed. I think file transfer > just be taken out of the data channel, and a file transfer channel > (on a separate flow, as suggested above) be defined for Web > programmers to use. That would remedy (A), (B) and (C) below (p2p > file transfer not destroying priority for data chunks and media). > The file transfer channel would not/cannot be prioritized. > > On 03 Apr 2014, at 21:12, Michael Tuexen > [Michael.Tuexen@lurchi.franken.de]wrote: >> Is there an >> overall design/thought somewhere that I missed/am unaware of?) > The basis idea is to use a stream scheduler to handle streams different. > Some data channels can get a higher bandwidth than others. Since the > priority stuff is still in flux in W3C, it hasn't been nailed down in the > SCTP spec. I guess, the place will be in > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00 > This document is not finalized yet. >> > [Karl] There are severe limitations for doing prioritization in a > protocol (SCTP or other) executed in the endpoints. In most cases > there are no packets in the endpoint to put first among queued up > traffic, because the queue is somewhere else between the endpoints. > Just consider the most common case where the endpoints are connected > with a fast Ethernet. The data has then already left the endpoint and > is queued up at some congestion point in the network where the SCTP > protocol cannot rearrange the queue. First when that unreachable > queue is full, there is something in the endpoint to act upon... > > > -----Ursprungligt meddelande----- > Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Karl Stahl > Skickat: den 3 april 2014 18:30 > Till: 'Matthew Kaufman (SKYPE)'; 'Harald Alvestrand'; 'Magnus Westerlund' > Kopia: rtcweb@ietf.org > Ämne: Re: [rtcweb] Some language on "prioritization" > > The questions raised here don't have simple "local or endpoint > answers". There are overall and basic things to be made clear first. > Combining P2P file transfer over the rtcweb data channels with > prioritized traffic chunks, brings further complications to the > prioritization/QoS issue. This cannot be handled/done by endpoint > or applications without considering the transport network (The > congestion to handle by prioritization is in the network - NOT in > the endpoints)! > > There are below (A), (B) and (C) - to get us back to normal - > then there is (D) to improve - to allow the network level to > give us the prioritization required for WebRTC critical traffic > (real-time and data chunks). Without (D) - an interface to > network QoS equipment - the network does not even know what to > prioritize. > > I am afraid that this will be considered "back to the drawing board" > rather than "some language" but I cannot see the way forward if not > considered. > > Has the SCTP data channel been constructed with hopes of > prioritization/quality functionality that simply are not there > (cannot be there)? (I have browsed the (complex) SCTP spec and > some rtcweb drafts to get an understanding of the > prioritization/QoS thoughts and means in this rtcweb context > and the intended usage. Is there an overall design/thought > somewhere that I missed/am unaware of?) > > File transfer - getting a larger amount of data through between > endpoints as quickly as possible - CANNOT be prioritized over > IP networks! For file transfer we normally use TCP, meaning we > fill the pipe, until THE ENDPOINTS see packet drop and regulate > down their traffic flow. File transfer over IP networks works > this way and cannot be improved upon ("Internet would stop" if > we prioritized such traffic! The available bandwidth at congestion > points are shared between everyone's TCP-flows hitting such > congestion points in the network.) File transfer's nature is > to have "infinite bandwidth demand" - the mechanism to handle > this is to allow file transfer to "take the rest of the bandwidth" > after prioritized media and chunks have taken their needed share. > > The improvement to make - prioritization of media traffic and > data chunks - is to allow level 3 QoS methods - not only relying > on the level 4 TCP backing off process. Without level 3 QoS > (diffserve/DSCP, reservation or separate pipes) media and data > chunks packets are also lost in the level 4 TCP backing off > process (=today's situation over best effort Internet). That is > where the prioritization/QoS measures that we need for rtcweb > have to be. > > SCTP in itself (instead of TLS/TCP) does not/cannot/will not > improve things. It can destroy though if wrongly/badly > implemented or used! > >>From the SCTP RFC4960: 7. Congestion Control > ...adequate resources will be allocated to SCTP traffic > to ensure prompt delivery of time-critical data ... unlikely, > during normal operations, that transmissions encounter severe > congestion conditions. > > However, SCTP must operate under adverse operational > conditions, which can develop upon partial network failures > or unexpected traffic surges. In such situations, SCTP must > follow correct congestion control steps to recover from > congestion quickly in order to get data delivered as soon as > possible. > > ... SCTP congestion control is always applied to the entire > association, and not to individual streams. > > Doing file transfer with the data channel will use SCTP in the > "adverse operational conditions, which can develop upon partial > network failures or unexpected traffic surges"-mode! Has that been > considered when constructing the data channel? Hope so... > > Assuming SCTP is implemented correctly and as good as TCP for > file transfer (even though file transfer = filling the pipe > mode is an "adverse condition..." for SCTP). Then we must specify: > > > (A) Rtcweb file transfer MUST NOT use the same data channel as > data chunks expected to have prioritized delivery (otherwise, > as per above, SCTP will regulate the "the entire association" > to share the available bandwidth at the congestion point - > self-destroying the expected prioritized delivery of data chunks > in the same channel). > > (B) Each rtcweb file transfer MUST use its own data channel (if > combined they risk being regulated randomly/unfairly by SCTP > itself and all files will have just have one single TCP-like > flow at the network congestion point when sharing the available > bandwidth with everyone else's flows at that congestion point > - That would be "negative priority" compared to what we are used > to in a browser.). > > FURTHER, to allow the underlying network the ability to handle > the real-time and data chunks as least as good as "before rtcweb" > (Unfortunately this will make NAT-firewall less good - not sending > everything P2P in a single bundle/flow - I don't like it either... > Sorry...): > > (C) File transfer using the data channel MUST NOT be bundled > with media and data chunk traffic in the same flow - file > transfer must use a separate socket creating another flow/5-tuple > over the network. > (In reservation type of networks (e.g. mobile OTT, cable), file > transfer - having no bandwidth limitation - would otherwise > overflow the reserved bandwidth for media and chunck traffic - > destroying prioritized delivery of media and chunck traffic > over that flow.) Such file transfer data channels MUST NOT be > prioritized by the underlying network (applies to all IP network > types, network prioritization of file transfer will STOP traffic > between endpoints > - Endpoint's TCP-like regulation has to function!). Several file > transfers could share such a separate flow (without specifying in > SDP I guess) but the underlying network must be able to separate > such flows (not to be prioritized) from media and chunk flows. > > In the API, such file transfer data channel could be mapped to > the "below normal" classification (but would it not be better > with a "file transfer channel" API instead?). (And notice that > without (D) below, the network is not informed how to separate a > file transfer data channel flow from a prioritized data channel > flow.) > > > Having (A), (B) and (C) in place we are BACK TO THE CURRENT > Internet prioritization/QoS level - before the rtcweb p2p data > channel file transfer was introduced... > > Now remains the prioritization improvement required for quality > > hungry rtcweb! Both for the real-time media and the data chuncks. > > > (D) The underlying transport network needs to be informed about > the traffic requirements. > > - In RTP media this traffic info could be inserted by the rtcweb > browser in the RTP header extension [1] depending on codec usage > etc. The API classification could be mapped to the > "Prioritize X(2 bits)" suggested in [1] below. > > - for the data channel, the traffic info could be inserted as > suggested in previous email ([2] below) > http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973.html > > Note that the required bandwidth (only known by the > browser/application) has to be passed to reservation types of > network. Requested prioritization from the API or DSCP bits are > not sufficient. The browser knows the bandwidth requirements for > codecs, but for data chunks, the application has the knowledge. > In lack of a bandwidth parameter in the data channel API, a simple > convention - e.g. reserve 200 kbps for data chunks could serve as > a compromise (or 4 bandwidths mapped to the API prioritize > classifications...). A modified API with the bandwidth requirement > spelled out would of course be better for the chuck data channel. > For a file transfer data channel - prioritization classification > does not even apply. > > > Having prioritization over the network cleared, the application > should use that transport properly - having media and data chunks > transported with prioritization (as produced/inserted), NOT queuing > them up, rearranged by protocols or applications and NOT involving > file transfer (that has to be unprioritized). > > Using DSCP bits if available through the OS in some situations does > not help either, as already pointed out in the transport document. > For (D) above, DSCP bits could in a few situations function locally, > but not end-to-end, so of no use generally. > > /Karl > > > [1] Traffic type information to encode (recreating the > idea/intention of the RTP payload type (PT) header that is not > available for the network level anymore, by instead having the > browser filling the RTP header extension with relevant traffic > info that all IP network types can use.), as suggested already > October 22. Two parameters to encode > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html > > A) The maximum bandwidth requirement: Two bytes could contain > everything from some bps for real-time text to Gbps for future 3D > supersize telepresence on a logarithmic scale. > > B) The quality characteristics for the stream, with the highest > bit set to 1, we could allocate a bit each for quality type e.g: > Best Effort, Audio, Video, Supplemental Video, Gaming, Data, > Delay Insensitive (e.g. video streaming), Minimum Delay, > Reliable Delivery, Prioritize X(2 bits), Variation Y(2 bits), > that could be combined as required to describe the stream. > > And with the highest bit set to 0, there could instead be a number > for special usage that does not fit the general description of > the individual bits. > > Without this information, how could e.g. a reservation type > network (e.g. mobile OTT and cable) reserve the bandwidth > required for incoming rtcweb media or data chunks from a diffserve > network (carrying no bandwidth requirement)? > > > [2] A new DTLS ContentType (e.g. 24 instead of current 23) for the > rtcweb data channel, where the content would be the unencrypted > traffic info (preferable the same as in the RTP header extension) > followed by the SCTP data as it is today (where it today comes > directly in the DTLS as the only content).: > > TODAY: > Content Type: 23 (1 byte) content type 23 means “application data” > DTLS version: 0xfeff (2 byte) > Epoch: 0001 (2 byte) > Sequence number (e.g. 00 00 00 00 00 01) 6 byte > Length (e.g. 01 c0) 2 byte > Encrypted application data: ...... = the SCTP > > SUGGESTION WITH ADDED TRAFFIC INFO FOR LOWER LEVELS: > Content Type: 24 (1 byte) content type 24 meaning “application data preceded > by traffic info” > DTLS version: 0xfeff (2 byte) > Epoch: 0001 (2 byte) > Sequence number (e.g. 00 00 00 00 00 01) 6 byte > Length (e.g. 01 c0) 2 byte: length of the encrypted application data after > the new header extension > TRAFFIC INFO, Same as suggested for the RTP Header extension: > Encrypted application data: ...... ...... = the SCTP unchanged > > > -----Ursprungligt meddelande----- > Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Matthew Kaufman (SKYPE) > Skickat: den 31 mars 2014 19:50 > Till: Harald Alvestrand > Kopia: rtcweb@ietf.org > Ämne: Re: [rtcweb] Some language on "prioritization" > > And if SCTP and RTP have packets to send, which goes first, why, and under > what circumstances? > > Matthew Kaufman > > (Sent from my iPhone) > >> On Mar 31, 2014, at 10:48 AM, "Harald Alvestrand" > wrote: >> >>> On 03/31/2014 07:42 PM, Michael Tuexen wrote: >>>> On 31 Mar 2014, at 19:38, Martin Thomson > wrote: >>>> >>>>> On 31 March 2014 10:08, Harald Alvestrand wrote: >>>>> -- TODO: Specify a relative priority scheme that makes sense with >>>>> SCTP, with an appropriate reference. >>>>> [draft-ietf-tsvwg-sctp-prpolicies] >>>>> specifies a priority policy, but it's about discarding packets, not >>>>> deciding which packets to send first, and it also makes it >>>>> impossible to specify time-bounded retransmission. -- >>>> >>>> Why would SCTP need special treatment? I can understand if there >>>> are particular time-sensitive control messages that need to be given >>>> higher priority, but this is all time-sensitive. >>> A single transport connection (in this case an SCTP association) can >>> only use a single DSCP. So it would be OK to use the same priority >>> for all data channels, but things get complicated when when some data >>> channels would have different priorities requiring different DSCP > markings. >> >> The SCTP protocol machine will, at some given moment in time, have >> packets in its send buffers that belong to multiple data channels. >> Only one of them can go on the wire first. >> >> Which packet does it choose to send first, and why? >> >> That's the question I'm looking for an answer to. >> >> If the answer has an RFC number, chapter and section, I'd be very happy. >> If it doesn't - perhaps we have to invent one. >> Or say that it's "implementation dependent". >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Apr 21 15:39:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6E91A02DC for ; Mon, 21 Apr 2014 15:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 2lgFZar594X5 for ; Mon, 21 Apr 2014 15:39:05 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id 59E881A02B8 for ; Mon, 21 Apr 2014 15:39:02 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404220038562401; Tue, 22 Apr 2014 00:38:56 +0200 From: "Karl Stahl" To: "'Paul Kyzivat'" , References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> <020501cf5d5b$117e9830$347bc890$@stahl@intertex.se> <53552EFC.3000502@alum.mit.edu> In-Reply-To: <53552EFC.3000502@alum.mit.edu> Date: Tue, 22 Apr 2014 00:38:55 +0200 Message-ID: <024901cf5db2$7ac4bf70$704e3e50$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9dcFfux+vXXYJBS/aNqutIDDOSBAAOdP6A Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2etd1mJGwBXuOAOWbRMNraY6iiM Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 22:39:09 -0000 Inline comments/explanations below. /Karl -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Paul Kyzivat Skickat: den 21 april 2014 16:45 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Some language on "prioritization" It bothers me to see file transfer singled out for special treatment. File transfer is one (common) example of a potentially high volume = stream that has low requirements on latency. There are certainly other use = cases with similar characteristics that are not file transfers. --- When I say "file transfer" I mean ALL traffic of the character = "transfer this high amount of data as fast as possible", which usually is done by = TCP, allowing all "bandwidth left for me at the congestion point" to be used = (by the TCP endpoints regulating their flow to share the available bandwidth = at the congestion point). That cannot be transferred better or with higher priority, due to its "maximum bandwidth for minimum time" nature. = Congestion always occur - it is the way the available bandwidth is shared (best). = That is what we use TCP for. --- "Stream" I would reserve for traffic ticking along with time, NOT filling the pipe. That could be real-time data and be prioritized or reserved bandwidth for.=20 --- If you know your bandwidth at the congestion point (which you don't = - TCP tries it out) you could convert a file transfer into a stream by spreading it out over time, NOT filling the pipe. But then it would just take longer time to get the file transferred. File transfer = cannot/should not be prioritized. =20 --- These traffic types are different and need to be so. If it isn't feasible to manage data channels with differing priority = needs within the same SCTP association, then why not simply make provision for multiple SCTP associations, with a priority for each? --- Yes multiple SCTP associations are possible as said in (B) below = when file transfer is involved. However, for the sharing of bandwidth at congestion in the network, such SCTP associations should NOT be bundled = over the same flow/5-tuple as the real-time traffic (=3DC below). You then = need to set up another ICE connection - That is where I now suggested to do it = with TLS instead (which already is perfect for file transfer) instead of SCTP (which could be used if working equally well, although much more = complex). Neither can/should prioritize file transfer though. =20 Thanks, Paul On 4/21/14 8:13 AM, Karl Stahl wrote: > 1) AVOIDING SELF DESTRUCTING PRIORITAZATION FROM FILE TRANSFER IN DATA = > CHANNEL > > Simon, > > I saw you are an author of TURN-TCP RFC6062. Doesn't that RFC allow a=20 > webrtc file transfer channel (separate from the rtcweb data channel)=20 > to be created, using TLS file transfer P2P? ICE/STUN/TURN would set it = > up, NOT BUNDLED with chunk data and RTP media. > > Freeing the current rtcweb data channel from file transfer would=20 > remedy the self destruction of prioritization/QoS for data chunks and=20 > RTP media as explained in (A), (B) and (C) below. > > I also think it would be much better for a web programmer to have a=20 > separate p2p file transfer channel (that is not and cannot be=20 > prioritized) than pouring files into the data channel. > > > 2) MARKING PRIORITY DATA AND MEDIA FOR NETWORK LEVEL=20 > PRIORITIZATION/QoS > > P=E5l, Harald, Magnus, Collins, Tiru, Dan, > > We have previously discussed how to convey traffic info (bandwidth=20 > requirement, and traffic type/prio) from the browser/application to=20 > the network layer to prioritize or take other QoS measure by some=20 > network element. > > I have been pushing for inserting such traffic info into every RTP=20 > media packet in the RTP header extension, see [1] below. > > After looking how to mark data channel priority data chunks similarly, = > I suggested [2] below, i.e. a new DTLS ContentType for the rtcweb data = > channel, where the content would be the unencrypted traffic info=20 > (preferable the same as in the RTP header extension) followed by the=20 > SCTP data. > > Are there other ways? - Maybe more similar, consistent and/or better? > > We need the traffic info (contrary to e.g. DSCP bits) to be unchanged=20 > end-to-end and available in both STUN and TURN flows for network=20 > elements to see and act upon (e.g. to set DSCP bits or reserve=20 > bandwidth or otherwise regulate) for various network types. The=20 > traffic info must also be possible for network elements to find. > > No way b!) Since webrtc now mandates DTLS-SRTP for media, cannot that=20 > DTLS also hold the traffic info, just as for the data chunks > - instead of putting the traffic info into the RTP header extension? > NO, here the DTLS is only in the key exchange packets - not in every=20 > packet so that would NOT work, unfortunately. > > A way c?) Why not send data chunks in SRTP (instead of SCTP) and reuse = > the RTP header extension for the traffic info for the network layer.=20 > (File transfer is done in 1) above - not here!) > > What other things from SCTP do we actually want? (Not everything from=20 > that complex protocol for carrying telephony signaling can be of=20 > interest for webrtc.) > > - Priority (local): The browser could have a prioritizing mechanism=20 > including both media and data chunks before putting it in the UDP=20 > socket (simpler than SCTP). > > - Reliable data: A small transaction layer with retransmission of=20 > reliable data chunks could be implemented by the browser (simpler than = > SCTP). > > So with this way c, SCTP would go away totally and only the RTP header = > extension would be used for traffic info to the network layer. > > > Are there more ways? We need this traffic info to allow WebRTC with=20 > acceptable QoS over all network types (especially mobile Internet/OTT=20 > LTE and Cable Networks that are of reservation type). > > > Below are also a few comments to other feedback. > > /Karl > > > On 10 Apr 2014, at 17:35, Paul Kyzivat [pkyzivat@alum.mit.edu] wrote: > I presume you mean each *concurrent* file transfer must use its own channel. > Right? Reusing the same channel to transfer a series of files should=20 > be fine. > > Thanks, > Paul > [Karl] Yes, That is right. /Karl > > On 10 Apr 2014, at 15:14, Harald Alvestrand [harald@alvestrand.no] = wrote: > Just checking... since there's been no comment to the main body of the = > text here (it's all been on the SCTP aspect), is it OK to include the=20 > text in my next version of the -transport draft? > > (I'm not responding to Karl's comments - it's at a completely=20 > different level of complexity.) > > [Karl] Yes, it is but needs to be addressed. I think file transfer=20 > just be taken out of the data channel, and a file transfer channel (on = > a separate flow, as suggested above) be defined for Web programmers to = > use. That would remedy (A), (B) and (C) below (p2p file transfer not=20 > destroying priority for data chunks and media). > The file transfer channel would not/cannot be prioritized. > > On 03 Apr 2014, at 21:12, Michael Tuexen > [Michael.Tuexen@lurchi.franken.de]wrote: >> Is there an >> overall design/thought somewhere that I missed/am unaware of?) > The basis idea is to use a stream scheduler to handle streams = different. > Some data channels can get a higher bandwidth than others. Since the=20 > priority stuff is still in flux in W3C, it hasn't been nailed down in=20 > the SCTP spec. I guess, the place will be in > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00 > This document is not finalized yet. >> > [Karl] There are severe limitations for doing prioritization in a=20 > protocol (SCTP or other) executed in the endpoints. In most cases=20 > there are no packets in the endpoint to put first among queued up=20 > traffic, because the queue is somewhere else between the endpoints. > Just consider the most common case where the endpoints are connected=20 > with a fast Ethernet. The data has then already left the endpoint and=20 > is queued up at some congestion point in the network where the SCTP=20 > protocol cannot rearrange the queue. First when that unreachable queue = > is full, there is something in the endpoint to act upon... > > > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Karl Stahl > Skickat: den 3 april 2014 18:30 > Till: 'Matthew Kaufman (SKYPE)'; 'Harald Alvestrand'; 'Magnus = Westerlund' > Kopia: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Some language on "prioritization" > > The questions raised here don't have simple "local or endpoint=20 > answers". There are overall and basic things to be made clear first. > Combining P2P file transfer over the rtcweb data channels with=20 > prioritized traffic chunks, brings further complications to the=20 > prioritization/QoS issue. This cannot be handled/done by endpoint or=20 > applications without considering the transport network (The congestion = > to handle by prioritization is in the network - NOT in the endpoints)! > > There are below (A), (B) and (C) - to get us back to normal - then=20 > there is (D) to improve - to allow the network level to give us the=20 > prioritization required for WebRTC critical traffic (real-time and=20 > data chunks). Without (D) - an interface to network QoS equipment -=20 > the network does not even know what to prioritize. > > I am afraid that this will be considered "back to the drawing board" > rather than "some language" but I cannot see the way forward if not=20 > considered. > > Has the SCTP data channel been constructed with hopes of=20 > prioritization/quality functionality that simply are not there (cannot = > be there)? (I have browsed the (complex) SCTP spec and some rtcweb=20 > drafts to get an understanding of the prioritization/QoS thoughts and=20 > means in this rtcweb context and the intended usage. Is there an=20 > overall design/thought somewhere that I missed/am unaware of?) > > File transfer - getting a larger amount of data through between=20 > endpoints as quickly as possible - CANNOT be prioritized over IP=20 > networks! For file transfer we normally use TCP, meaning we fill the=20 > pipe, until THE ENDPOINTS see packet drop and regulate down their=20 > traffic flow. File transfer over IP networks works this way and cannot = > be improved upon ("Internet would stop" if we prioritized such=20 > traffic! The available bandwidth at congestion points are shared=20 > between everyone's TCP-flows hitting such congestion points in the=20 > network.) File transfer's nature is to have "infinite bandwidth=20 > demand" - the mechanism to handle this is to allow file transfer to=20 > "take the rest of the bandwidth" > after prioritized media and chunks have taken their needed share. > > The improvement to make - prioritization of media traffic and data=20 > chunks - is to allow level 3 QoS methods - not only relying on the=20 > level 4 TCP backing off process. Without level 3 QoS (diffserve/DSCP,=20 > reservation or separate pipes) media and data chunks packets are also=20 > lost in the level 4 TCP backing off process (=3Dtoday's situation over = > best effort Internet). That is where the prioritization/QoS measures=20 > that we need for rtcweb have to be. > > SCTP in itself (instead of TLS/TCP) does not/cannot/will not improve=20 > things. It can destroy though if wrongly/badly implemented or used! > >>From the SCTP RFC4960: 7. Congestion Control > ...adequate resources will be allocated to SCTP traffic > to ensure prompt delivery of time-critical data ... unlikely, > during normal operations, that transmissions encounter severe > congestion conditions. > > However, SCTP must operate under adverse operational > conditions, which can develop upon partial network failures > or unexpected traffic surges. In such situations, SCTP must > follow correct congestion control steps to recover from > congestion quickly in order to get data delivered as soon as > possible. > > ... SCTP congestion control is always applied to the entire > association, and not to individual streams. > > Doing file transfer with the data channel will use SCTP in the=20 > "adverse operational conditions, which can develop upon partial=20 > network failures or unexpected traffic surges"-mode! Has that been=20 > considered when constructing the data channel? Hope so... > > Assuming SCTP is implemented correctly and as good as TCP for file=20 > transfer (even though file transfer =3D filling the pipe mode is an=20 > "adverse condition..." for SCTP). Then we must specify: > > > (A) Rtcweb file transfer MUST NOT use the same data channel as data=20 > chunks expected to have prioritized delivery (otherwise, as per above, = > SCTP will regulate the "the entire association" > to share the available bandwidth at the congestion point -=20 > self-destroying the expected prioritized delivery of data chunks in=20 > the same channel). > > (B) Each rtcweb file transfer MUST use its own data channel (if=20 > combined they risk being regulated randomly/unfairly by SCTP itself=20 > and all files will have just have one single TCP-like flow at the=20 > network congestion point when sharing the available bandwidth with=20 > everyone else's flows at that congestion point > - That would be "negative priority" compared to what we are used to in = > a browser.). > > FURTHER, to allow the underlying network the ability to handle the=20 > real-time and data chunks as least as good as "before rtcweb" > (Unfortunately this will make NAT-firewall less good - not sending=20 > everything P2P in a single bundle/flow - I don't like it either... > Sorry...): > > (C) File transfer using the data channel MUST NOT be bundled with=20 > media and data chunk traffic in the same flow - file transfer must use = > a separate socket creating another flow/5-tuple over the network. > (In reservation type of networks (e.g. mobile OTT, cable), file=20 > transfer - having no bandwidth limitation - would otherwise overflow=20 > the reserved bandwidth for media and chunck traffic - destroying=20 > prioritized delivery of media and chunck traffic over that flow.) Such = > file transfer data channels MUST NOT be prioritized by the underlying=20 > network (applies to all IP network types, network prioritization of=20 > file transfer will STOP traffic between endpoints > - Endpoint's TCP-like regulation has to function!). Several file=20 > transfers could share such a separate flow (without specifying in SDP=20 > I guess) but the underlying network must be able to separate such=20 > flows (not to be prioritized) from media and chunk flows. > > In the API, such file transfer data channel could be mapped to the=20 > "below normal" classification (but would it not be better with a "file = > transfer channel" API instead?). (And notice that without (D) below,=20 > the network is not informed how to separate a file transfer data=20 > channel flow from a prioritized data channel > flow.) > > > Having (A), (B) and (C) in place we are BACK TO THE CURRENT Internet=20 > prioritization/QoS level - before the rtcweb p2p data channel file=20 > transfer was introduced... > > Now remains the prioritization improvement required for quality > > hungry rtcweb! Both for the real-time media and the data chuncks. > > > (D) The underlying transport network needs to be informed about the=20 > traffic requirements. > > - In RTP media this traffic info could be inserted by the rtcweb=20 > browser in the RTP header extension [1] depending on codec usage etc.=20 > The API classification could be mapped to the "Prioritize X(2 bits)"=20 > suggested in [1] below. > > - for the data channel, the traffic info could be inserted as=20 > suggested in previous email ([2] below)=20 > http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973.html > > Note that the required bandwidth (only known by the > browser/application) has to be passed to reservation types of network. = > Requested prioritization from the API or DSCP bits are not sufficient. = > The browser knows the bandwidth requirements for codecs, but for data=20 > chunks, the application has the knowledge. > In lack of a bandwidth parameter in the data channel API, a simple=20 > convention - e.g. reserve 200 kbps for data chunks could serve as a=20 > compromise (or 4 bandwidths mapped to the API prioritize=20 > classifications...). A modified API with the bandwidth requirement=20 > spelled out would of course be better for the chuck data channel. > For a file transfer data channel - prioritization classification does=20 > not even apply. > > > Having prioritization over the network cleared, the application should = > use that transport properly - having media and data chunks transported = > with prioritization (as produced/inserted), NOT queuing them up,=20 > rearranged by protocols or applications and NOT involving file=20 > transfer (that has to be unprioritized). > > Using DSCP bits if available through the OS in some situations does=20 > not help either, as already pointed out in the transport document. > For (D) above, DSCP bits could in a few situations function locally,=20 > but not end-to-end, so of no use generally. > > /Karl > > > [1] Traffic type information to encode (recreating the idea/intention=20 > of the RTP payload type (PT) header that is not available for the=20 > network level anymore, by instead having the browser filling the RTP=20 > header extension with relevant traffic info that all IP network types=20 > can use.), as suggested already October 22. Two parameters to encode=20 > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html > > A) The maximum bandwidth requirement: Two bytes could contain=20 > everything from some bps for real-time text to Gbps for future 3D=20 > supersize telepresence on a logarithmic scale. > > B) The quality characteristics for the stream, with the highest bit=20 > set to 1, we could allocate a bit each for quality type e.g: > Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay=20 > Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery,=20 > Prioritize X(2 bits), Variation Y(2 bits), that could be combined as=20 > required to describe the stream. > > And with the highest bit set to 0, there could instead be a number for = > special usage that does not fit the general description of the=20 > individual bits. > > Without this information, how could e.g. a reservation type network=20 > (e.g. mobile OTT and cable) reserve the bandwidth required for=20 > incoming rtcweb media or data chunks from a diffserve network=20 > (carrying no bandwidth requirement)? > > > [2] A new DTLS ContentType (e.g. 24 instead of current 23) for the=20 > rtcweb data channel, where the content would be the unencrypted=20 > traffic info (preferable the same as in the RTP header extension)=20 > followed by the SCTP data as it is today (where it today comes=20 > directly in the DTLS as the only content).: > > TODAY: > Content Type: 23 (1 byte) content type 23 means =93application data=94 > DTLS version: 0xfeff (2 byte) > Epoch: 0001 (2 byte) > Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2=20 > byte Encrypted application data: ...... =3D the SCTP > > SUGGESTION WITH ADDED TRAFFIC INFO FOR LOWER LEVELS: > Content Type: 24 (1 byte) content type 24 meaning =93application data=20 > preceded by traffic info=94 > DTLS version: 0xfeff (2 byte) > Epoch: 0001 (2 byte) > Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2=20 > byte: length of the encrypted application data after the new header=20 > extension TRAFFIC INFO, Same as suggested for the RTP Header=20 > extension: > Encrypted application data: ...... ...... =3D the SCTP unchanged > > > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Matthew Kaufman=20 > (SKYPE) > Skickat: den 31 mars 2014 19:50 > Till: Harald Alvestrand > Kopia: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Some language on "prioritization" > > And if SCTP and RTP have packets to send, which goes first, why, and=20 > under what circumstances? > > Matthew Kaufman > > (Sent from my iPhone) > >> On Mar 31, 2014, at 10:48 AM, "Harald Alvestrand"=20 >> > wrote: >> >>> On 03/31/2014 07:42 PM, Michael Tuexen wrote: >>>> On 31 Mar 2014, at 19:38, Martin Thomson > wrote: >>>> >>>>> On 31 March 2014 10:08, Harald Alvestrand wrote: >>>>> -- TODO: Specify a relative priority scheme that makes sense with=20 >>>>> SCTP, with an appropriate reference. >>>>> [draft-ietf-tsvwg-sctp-prpolicies] >>>>> specifies a priority policy, but it's about discarding packets,=20 >>>>> not deciding which packets to send first, and it also makes it=20 >>>>> impossible to specify time-bounded retransmission. -- >>>> >>>> Why would SCTP need special treatment? I can understand if there=20 >>>> are particular time-sensitive control messages that need to be=20 >>>> given higher priority, but this is all time-sensitive. >>> A single transport connection (in this case an SCTP association) can = >>> only use a single DSCP. So it would be OK to use the same priority=20 >>> for all data channels, but things get complicated when when some=20 >>> data channels would have different priorities requiring different=20 >>> DSCP > markings. >> >> The SCTP protocol machine will, at some given moment in time, have=20 >> packets in its send buffers that belong to multiple data channels. >> Only one of them can go on the wire first. >> >> Which packet does it choose to send first, and why? >> >> That's the question I'm looking for an answer to. >> >> If the answer has an RFC number, chapter and section, I'd be very = happy. >> If it doesn't - perhaps we have to invent one. >> Or say that it's "implementation dependent". >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Apr 22 06:46:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CF71A041A for ; Tue, 22 Apr 2014 06:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham 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 0Dm_dlTBRZ7A for ; Tue, 22 Apr 2014 06:46:36 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D99A11A0430 for ; Tue, 22 Apr 2014 06:46:30 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:349d:fe5f:bc57:89]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4185B40221; Tue, 22 Apr 2014 09:46:25 -0400 (EDT) Message-ID: <535672B0.5030900@viagenie.ca> Date: Tue, 22 Apr 2014 09:46:24 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Karl Stahl , "'Pal Martinsen (palmarti)'" , 'Harald Alvestrand' , 'Magnus Westerlund' References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> <020501cf5d5b$117e9830$347bc890$@stahl@intertex.se> In-Reply-To: <020501cf5d5b$117e9830$347bc890$@stahl@intertex.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/s2GQQ43XbZnmvin4gShZs85gYfY Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 13:46:41 -0000 Le 2014-04-21 08:13, Karl Stahl a écrit : > 1) AVOIDING SELF DESTRUCTING PRIORITAZATION FROM FILE TRANSFER IN DATA > CHANNEL > > Simon, > > I saw you are an author of TURN-TCP RFC6062. Doesn't that RFC allow a > webrtc file transfer channel (separate from the rtcweb data channel) > to be created, using TLS file transfer P2P? ICE/STUN/TURN would set > it up, NOT BUNDLED with chunk data and RTP media. RFC6062 knows nothing about WebRTC or TLS inside the peer connection payload. So it doesn't explicitly "allow" what you suggest. But I guess it doesn't prevent it either. It doesn't care. > Freeing the current rtcweb data channel from file transfer would remedy > the self destruction of prioritization/QoS for data chunks and RTP media > as explained in (A), (B) and (C) below. > > I also think it would be much better for a web programmer to have a > separate p2p file transfer channel (that is not and cannot be prioritized) > than pouring files into the data channel. Why do you think using a separate channel would eliminate the issue of prioritization? We would end up with multiple channels contending for the same bandwidth. You have just moved the problem one level up. And made things needlessly more complex, IMHO. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Apr 22 11:36:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287281A0226 for ; Tue, 22 Apr 2014 11:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 kh1a5wrdR223 for ; Tue, 22 Apr 2014 11:36:48 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D30621A022B for ; Tue, 22 Apr 2014 11:36:47 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id t5DE1n0030xGWP8536ciXe; Tue, 22 Apr 2014 18:36:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id t6ch1n00c3ZTu2S3Y6chem; Tue, 22 Apr 2014 18:36:42 +0000 Message-ID: <5356B6B9.3050505@alum.mit.edu> Date: Tue, 22 Apr 2014 14:36:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Karl Stahl , rtcweb@ietf.org References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> <020501cf5d5b$117e9830$347bc890$@stahl@intertex.se> <53552EFC.3000502@alum.mit.edu> <024901cf5db2$7ac4bf70$704e3e50$@stahl@intertex.se> In-Reply-To: <024901cf5db2$7ac4bf70$704e3e50$@stahl@intertex.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398191802; bh=cmM2VKX6xR50PK9m/9iIgL/npzHihcddq4WDEHj/VpE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sQ6SYIiWIphXLoJIbETyKCc1NVnZkeaEtnsP/HFx0JlFCxRrdBOAqMk+1X60AlAdX 9ctnKZo2B3DNq8WXwHuHoTWM5mV6wEvQn3nn/ywAFfeDxhsuouQdLJdfsN2kD9uKwC lwG5K0d3IYQ52HbBSZwr3i85LaFnhVcoKSICB6tiGfEPZzzKjm8ld+K59Z3yK620ie owVFBwhTkwGIQQ6veKy+ROcYrPzyhDhAJRkxznxj2qp3liK4UhPxel+ty2CrS96k6g 3oGV8VFWwwU4TpvL+Z5WyLOIOFb0aQ0txrizAlpYNiRAxb7tz5ioBG0NK94IBGFVdW idR8hIGpoSGpQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7OERjmEiVjmoIckeEEjPwV8LoeU Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 18:36:52 -0000 On 4/21/14 6:38 PM, Karl Stahl wrote: > Inline comments/explanations below. /Karl > > -----Ursprungligt meddelande----- > Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Paul Kyzivat > Skickat: den 21 april 2014 16:45 > Till: rtcweb@ietf.org > Ämne: Re: [rtcweb] Some language on "prioritization" > > It bothers me to see file transfer singled out for special treatment. > > File transfer is one (common) example of a potentially high volume stream > that has low requirements on latency. There are certainly other use cases > with similar characteristics that are not file transfers. > > > --- When I say "file transfer" I mean ALL traffic of the character "transfer > this high amount of data as fast as possible", OK. So you are really talking about a usage with a particular traffic class. > which usually is done by TCP, > allowing all "bandwidth left for me at the congestion point" to be used (by > the TCP endpoints regulating their flow to share the available bandwidth at > the congestion point). That cannot be transferred better or with higher > priority, due to its "maximum bandwidth for minimum time" nature. Congestion > always occur - it is the way the available bandwidth is shared (best). That > is what we use TCP for. > > --- "Stream" I would reserve for traffic ticking along with time, NOT > filling the pipe. That could be real-time data and be prioritized or > reserved bandwidth for. > > --- If you know your bandwidth at the congestion point (which you don't - > TCP tries it out) you could convert a file transfer into a stream by > spreading it out over time, NOT filling the pipe. But then it would just > take longer time to get the file transferred. File transfer cannot/should > not be prioritized. > > --- These traffic types are different and need to be so. > > If it isn't feasible to manage data channels with differing priority needs > within the same SCTP association, then why not simply make provision for > multiple SCTP associations, with a priority for each? > > --- Yes multiple SCTP associations are possible as said in (B) below when > file transfer is involved. However, for the sharing of bandwidth at > congestion in the network, such SCTP associations should NOT be bundled over > the same flow/5-tuple as the real-time traffic (=C below). You then need to > set up another ICE connection - That is where I now suggested to do it with > TLS instead (which already is perfect for file transfer) instead of SCTP > (which could be used if working equally well, although much more complex). > Neither can/should prioritize file transfer though. ISTM that avoiding setting up another 5-tuple, with the trouble of ICE, etc. is one of the goals. The data channels give you a cheap and easy way to set up these things. IIUC there is already a desire/intent to mark the different streams within a bundle as different priorities/traffic classes. (I thought that is what DART is about.) Isn't that good enough to achieve the same end as running the data over a different 5-tuple? Apparently there is a problem with doing that at the data channel level. But I wouldn't think it would be a problem for multiple SCTP associations in the same bundle. (Different SCTP port numbers.) That would allow you to have one association for "file transfers" and one for more interactive data. Thanks, Paul > Thanks, > Paul > > On 4/21/14 8:13 AM, Karl Stahl wrote: >> 1) AVOIDING SELF DESTRUCTING PRIORITAZATION FROM FILE TRANSFER IN DATA >> CHANNEL >> >> Simon, >> >> I saw you are an author of TURN-TCP RFC6062. Doesn't that RFC allow a >> webrtc file transfer channel (separate from the rtcweb data channel) >> to be created, using TLS file transfer P2P? ICE/STUN/TURN would set it >> up, NOT BUNDLED with chunk data and RTP media. >> >> Freeing the current rtcweb data channel from file transfer would >> remedy the self destruction of prioritization/QoS for data chunks and >> RTP media as explained in (A), (B) and (C) below. >> >> I also think it would be much better for a web programmer to have a >> separate p2p file transfer channel (that is not and cannot be >> prioritized) than pouring files into the data channel. >> >> >> 2) MARKING PRIORITY DATA AND MEDIA FOR NETWORK LEVEL >> PRIORITIZATION/QoS >> >> Pål, Harald, Magnus, Collins, Tiru, Dan, >> >> We have previously discussed how to convey traffic info (bandwidth >> requirement, and traffic type/prio) from the browser/application to >> the network layer to prioritize or take other QoS measure by some >> network element. >> >> I have been pushing for inserting such traffic info into every RTP >> media packet in the RTP header extension, see [1] below. >> >> After looking how to mark data channel priority data chunks similarly, >> I suggested [2] below, i.e. a new DTLS ContentType for the rtcweb data >> channel, where the content would be the unencrypted traffic info >> (preferable the same as in the RTP header extension) followed by the >> SCTP data. >> >> Are there other ways? - Maybe more similar, consistent and/or better? >> >> We need the traffic info (contrary to e.g. DSCP bits) to be unchanged >> end-to-end and available in both STUN and TURN flows for network >> elements to see and act upon (e.g. to set DSCP bits or reserve >> bandwidth or otherwise regulate) for various network types. The >> traffic info must also be possible for network elements to find. >> >> No way b!) Since webrtc now mandates DTLS-SRTP for media, cannot that >> DTLS also hold the traffic info, just as for the data chunks >> - instead of putting the traffic info into the RTP header extension? >> NO, here the DTLS is only in the key exchange packets - not in every >> packet so that would NOT work, unfortunately. >> >> A way c?) Why not send data chunks in SRTP (instead of SCTP) and reuse >> the RTP header extension for the traffic info for the network layer. >> (File transfer is done in 1) above - not here!) >> >> What other things from SCTP do we actually want? (Not everything from >> that complex protocol for carrying telephony signaling can be of >> interest for webrtc.) >> >> - Priority (local): The browser could have a prioritizing mechanism >> including both media and data chunks before putting it in the UDP >> socket (simpler than SCTP). >> >> - Reliable data: A small transaction layer with retransmission of >> reliable data chunks could be implemented by the browser (simpler than >> SCTP). >> >> So with this way c, SCTP would go away totally and only the RTP header >> extension would be used for traffic info to the network layer. >> >> >> Are there more ways? We need this traffic info to allow WebRTC with >> acceptable QoS over all network types (especially mobile Internet/OTT >> LTE and Cable Networks that are of reservation type). >> >> >> Below are also a few comments to other feedback. >> >> /Karl >> >> >> On 10 Apr 2014, at 17:35, Paul Kyzivat [pkyzivat@alum.mit.edu] wrote: >> I presume you mean each *concurrent* file transfer must use its own > channel. >> Right? Reusing the same channel to transfer a series of files should >> be fine. >> >> Thanks, >> Paul >> [Karl] Yes, That is right. /Karl >> >> On 10 Apr 2014, at 15:14, Harald Alvestrand [harald@alvestrand.no] wrote: >> Just checking... since there's been no comment to the main body of the >> text here (it's all been on the SCTP aspect), is it OK to include the >> text in my next version of the -transport draft? >> >> (I'm not responding to Karl's comments - it's at a completely >> different level of complexity.) >> >> [Karl] Yes, it is but needs to be addressed. I think file transfer >> just be taken out of the data channel, and a file transfer channel (on >> a separate flow, as suggested above) be defined for Web programmers to >> use. That would remedy (A), (B) and (C) below (p2p file transfer not >> destroying priority for data chunks and media). >> The file transfer channel would not/cannot be prioritized. >> >> On 03 Apr 2014, at 21:12, Michael Tuexen >> [Michael.Tuexen@lurchi.franken.de]wrote: >>> Is there an >>> overall design/thought somewhere that I missed/am unaware of?) >> The basis idea is to use a stream scheduler to handle streams different. >> Some data channels can get a higher bandwidth than others. Since the >> priority stuff is still in flux in W3C, it hasn't been nailed down in >> the SCTP spec. I guess, the place will be in >> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00 >> This document is not finalized yet. >>> >> [Karl] There are severe limitations for doing prioritization in a >> protocol (SCTP or other) executed in the endpoints. In most cases >> there are no packets in the endpoint to put first among queued up >> traffic, because the queue is somewhere else between the endpoints. >> Just consider the most common case where the endpoints are connected >> with a fast Ethernet. The data has then already left the endpoint and >> is queued up at some congestion point in the network where the SCTP >> protocol cannot rearrange the queue. First when that unreachable queue >> is full, there is something in the endpoint to act upon... >> >> >> -----Ursprungligt meddelande----- >> Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Karl Stahl >> Skickat: den 3 april 2014 18:30 >> Till: 'Matthew Kaufman (SKYPE)'; 'Harald Alvestrand'; 'Magnus Westerlund' >> Kopia: rtcweb@ietf.org >> Ämne: Re: [rtcweb] Some language on "prioritization" >> >> The questions raised here don't have simple "local or endpoint >> answers". There are overall and basic things to be made clear first. >> Combining P2P file transfer over the rtcweb data channels with >> prioritized traffic chunks, brings further complications to the >> prioritization/QoS issue. This cannot be handled/done by endpoint or >> applications without considering the transport network (The congestion >> to handle by prioritization is in the network - NOT in the endpoints)! >> >> There are below (A), (B) and (C) - to get us back to normal - then >> there is (D) to improve - to allow the network level to give us the >> prioritization required for WebRTC critical traffic (real-time and >> data chunks). Without (D) - an interface to network QoS equipment - >> the network does not even know what to prioritize. >> >> I am afraid that this will be considered "back to the drawing board" >> rather than "some language" but I cannot see the way forward if not >> considered. >> >> Has the SCTP data channel been constructed with hopes of >> prioritization/quality functionality that simply are not there (cannot >> be there)? (I have browsed the (complex) SCTP spec and some rtcweb >> drafts to get an understanding of the prioritization/QoS thoughts and >> means in this rtcweb context and the intended usage. Is there an >> overall design/thought somewhere that I missed/am unaware of?) >> >> File transfer - getting a larger amount of data through between >> endpoints as quickly as possible - CANNOT be prioritized over IP >> networks! For file transfer we normally use TCP, meaning we fill the >> pipe, until THE ENDPOINTS see packet drop and regulate down their >> traffic flow. File transfer over IP networks works this way and cannot >> be improved upon ("Internet would stop" if we prioritized such >> traffic! The available bandwidth at congestion points are shared >> between everyone's TCP-flows hitting such congestion points in the >> network.) File transfer's nature is to have "infinite bandwidth >> demand" - the mechanism to handle this is to allow file transfer to >> "take the rest of the bandwidth" >> after prioritized media and chunks have taken their needed share. >> >> The improvement to make - prioritization of media traffic and data >> chunks - is to allow level 3 QoS methods - not only relying on the >> level 4 TCP backing off process. Without level 3 QoS (diffserve/DSCP, >> reservation or separate pipes) media and data chunks packets are also >> lost in the level 4 TCP backing off process (=today's situation over >> best effort Internet). That is where the prioritization/QoS measures >> that we need for rtcweb have to be. >> >> SCTP in itself (instead of TLS/TCP) does not/cannot/will not improve >> things. It can destroy though if wrongly/badly implemented or used! >> >> >From the SCTP RFC4960: 7. Congestion Control >> ...adequate resources will be allocated to SCTP traffic >> to ensure prompt delivery of time-critical data ... unlikely, >> during normal operations, that transmissions encounter severe >> congestion conditions. >> >> However, SCTP must operate under adverse operational >> conditions, which can develop upon partial network failures >> or unexpected traffic surges. In such situations, SCTP must >> follow correct congestion control steps to recover from >> congestion quickly in order to get data delivered as soon as >> possible. >> >> ... SCTP congestion control is always applied to the entire >> association, and not to individual streams. >> >> Doing file transfer with the data channel will use SCTP in the >> "adverse operational conditions, which can develop upon partial >> network failures or unexpected traffic surges"-mode! Has that been >> considered when constructing the data channel? Hope so... >> >> Assuming SCTP is implemented correctly and as good as TCP for file >> transfer (even though file transfer = filling the pipe mode is an >> "adverse condition..." for SCTP). Then we must specify: >> >> >> (A) Rtcweb file transfer MUST NOT use the same data channel as data >> chunks expected to have prioritized delivery (otherwise, as per above, >> SCTP will regulate the "the entire association" >> to share the available bandwidth at the congestion point - >> self-destroying the expected prioritized delivery of data chunks in >> the same channel). >> >> (B) Each rtcweb file transfer MUST use its own data channel (if >> combined they risk being regulated randomly/unfairly by SCTP itself >> and all files will have just have one single TCP-like flow at the >> network congestion point when sharing the available bandwidth with >> everyone else's flows at that congestion point >> - That would be "negative priority" compared to what we are used to in >> a browser.). >> >> FURTHER, to allow the underlying network the ability to handle the >> real-time and data chunks as least as good as "before rtcweb" >> (Unfortunately this will make NAT-firewall less good - not sending >> everything P2P in a single bundle/flow - I don't like it either... >> Sorry...): >> >> (C) File transfer using the data channel MUST NOT be bundled with >> media and data chunk traffic in the same flow - file transfer must use >> a separate socket creating another flow/5-tuple over the network. >> (In reservation type of networks (e.g. mobile OTT, cable), file >> transfer - having no bandwidth limitation - would otherwise overflow >> the reserved bandwidth for media and chunck traffic - destroying >> prioritized delivery of media and chunck traffic over that flow.) Such >> file transfer data channels MUST NOT be prioritized by the underlying >> network (applies to all IP network types, network prioritization of >> file transfer will STOP traffic between endpoints >> - Endpoint's TCP-like regulation has to function!). Several file >> transfers could share such a separate flow (without specifying in SDP >> I guess) but the underlying network must be able to separate such >> flows (not to be prioritized) from media and chunk flows. >> >> In the API, such file transfer data channel could be mapped to the >> "below normal" classification (but would it not be better with a "file >> transfer channel" API instead?). (And notice that without (D) below, >> the network is not informed how to separate a file transfer data >> channel flow from a prioritized data channel >> flow.) >> >> >> Having (A), (B) and (C) in place we are BACK TO THE CURRENT Internet >> prioritization/QoS level - before the rtcweb p2p data channel file >> transfer was introduced... >> >> Now remains the prioritization improvement required for quality >> >> hungry rtcweb! Both for the real-time media and the data chuncks. >> >> >> (D) The underlying transport network needs to be informed about the >> traffic requirements. >> >> - In RTP media this traffic info could be inserted by the rtcweb >> browser in the RTP header extension [1] depending on codec usage etc. >> The API classification could be mapped to the "Prioritize X(2 bits)" >> suggested in [1] below. >> >> - for the data channel, the traffic info could be inserted as >> suggested in previous email ([2] below) >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973.html >> >> Note that the required bandwidth (only known by the >> browser/application) has to be passed to reservation types of network. >> Requested prioritization from the API or DSCP bits are not sufficient. >> The browser knows the bandwidth requirements for codecs, but for data >> chunks, the application has the knowledge. >> In lack of a bandwidth parameter in the data channel API, a simple >> convention - e.g. reserve 200 kbps for data chunks could serve as a >> compromise (or 4 bandwidths mapped to the API prioritize >> classifications...). A modified API with the bandwidth requirement >> spelled out would of course be better for the chuck data channel. >> For a file transfer data channel - prioritization classification does >> not even apply. >> >> >> Having prioritization over the network cleared, the application should >> use that transport properly - having media and data chunks transported >> with prioritization (as produced/inserted), NOT queuing them up, >> rearranged by protocols or applications and NOT involving file >> transfer (that has to be unprioritized). >> >> Using DSCP bits if available through the OS in some situations does >> not help either, as already pointed out in the transport document. >> For (D) above, DSCP bits could in a few situations function locally, >> but not end-to-end, so of no use generally. >> >> /Karl >> >> >> [1] Traffic type information to encode (recreating the idea/intention >> of the RTP payload type (PT) header that is not available for the >> network level anymore, by instead having the browser filling the RTP >> header extension with relevant traffic info that all IP network types >> can use.), as suggested already October 22. Two parameters to encode >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html >> >> A) The maximum bandwidth requirement: Two bytes could contain >> everything from some bps for real-time text to Gbps for future 3D >> supersize telepresence on a logarithmic scale. >> >> B) The quality characteristics for the stream, with the highest bit >> set to 1, we could allocate a bit each for quality type e.g: >> Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay >> Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, >> Prioritize X(2 bits), Variation Y(2 bits), that could be combined as >> required to describe the stream. >> >> And with the highest bit set to 0, there could instead be a number for >> special usage that does not fit the general description of the >> individual bits. >> >> Without this information, how could e.g. a reservation type network >> (e.g. mobile OTT and cable) reserve the bandwidth required for >> incoming rtcweb media or data chunks from a diffserve network >> (carrying no bandwidth requirement)? >> >> >> [2] A new DTLS ContentType (e.g. 24 instead of current 23) for the >> rtcweb data channel, where the content would be the unencrypted >> traffic info (preferable the same as in the RTP header extension) >> followed by the SCTP data as it is today (where it today comes >> directly in the DTLS as the only content).: >> >> TODAY: >> Content Type: 23 (1 byte) content type 23 means “application data” >> DTLS version: 0xfeff (2 byte) >> Epoch: 0001 (2 byte) >> Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 >> byte Encrypted application data: ...... = the SCTP >> >> SUGGESTION WITH ADDED TRAFFIC INFO FOR LOWER LEVELS: >> Content Type: 24 (1 byte) content type 24 meaning “application data >> preceded by traffic info” >> DTLS version: 0xfeff (2 byte) >> Epoch: 0001 (2 byte) >> Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 >> byte: length of the encrypted application data after the new header >> extension TRAFFIC INFO, Same as suggested for the RTP Header >> extension: >> Encrypted application data: ...... ...... = the SCTP unchanged >> >> >> -----Ursprungligt meddelande----- >> Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Matthew Kaufman >> (SKYPE) >> Skickat: den 31 mars 2014 19:50 >> Till: Harald Alvestrand >> Kopia: rtcweb@ietf.org >> Ämne: Re: [rtcweb] Some language on "prioritization" >> >> And if SCTP and RTP have packets to send, which goes first, why, and >> under what circumstances? >> >> Matthew Kaufman >> >> (Sent from my iPhone) >> >>> On Mar 31, 2014, at 10:48 AM, "Harald Alvestrand" >>> >> wrote: >>> >>>> On 03/31/2014 07:42 PM, Michael Tuexen wrote: >>>>> On 31 Mar 2014, at 19:38, Martin Thomson >> wrote: >>>>> >>>>>> On 31 March 2014 10:08, Harald Alvestrand > wrote: >>>>>> -- TODO: Specify a relative priority scheme that makes sense with >>>>>> SCTP, with an appropriate reference. >>>>>> [draft-ietf-tsvwg-sctp-prpolicies] >>>>>> specifies a priority policy, but it's about discarding packets, >>>>>> not deciding which packets to send first, and it also makes it >>>>>> impossible to specify time-bounded retransmission. -- >>>>> >>>>> Why would SCTP need special treatment? I can understand if there >>>>> are particular time-sensitive control messages that need to be >>>>> given higher priority, but this is all time-sensitive. >>>> A single transport connection (in this case an SCTP association) can >>>> only use a single DSCP. So it would be OK to use the same priority >>>> for all data channels, but things get complicated when when some >>>> data channels would have different priorities requiring different >>>> DSCP >> markings. >>> >>> The SCTP protocol machine will, at some given moment in time, have >>> packets in its send buffers that belong to multiple data channels. >>> Only one of them can go on the wire first. >>> >>> Which packet does it choose to send first, and why? >>> >>> That's the question I'm looking for an answer to. >>> >>> If the answer has an RFC number, chapter and section, I'd be very happy. >>> If it doesn't - perhaps we have to invent one. >>> Or say that it's "implementation dependent". >>> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From nobody Tue Apr 22 22:10:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F401A005A for ; Tue, 22 Apr 2014 22:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 pCrjHUD0wmPg for ; Tue, 22 Apr 2014 22:10:37 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id A3F771A0073 for ; Tue, 22 Apr 2014 22:10:34 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404230710256065; Wed, 23 Apr 2014 07:10:25 +0200 From: "Karl Stahl" To: "'Simon Perreault'" , "'Pal Martinsen \(palmarti\)'" , "'Harald Alvestrand'" , "'Magnus Westerlund'" References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> <020501cf5d5b$117e9830$347bc890$@stahl@intertex.se> <535672B0.5030900@viagenie.ca> In-Reply-To: <535672B0.5030900@viagenie.ca> Date: Wed, 23 Apr 2014 07:10:29 +0200 Message-ID: <000601cf5eb2$58454cc0$08cfe640$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9eMUH0j1tyOdxNRxukpTolB4vGoAAe5vxw Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/D6skBFW7uFsZJDLqUdAj_WzrEJs Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 05:10:42 -0000 -----Ursprungligt meddelande----- Fr=E5n: Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Skickat: den 22 april 2014 15:46 Till: Karl Stahl; 'Pal Martinsen (palmarti)'; 'Harald Alvestrand'; = 'Magnus Westerlund' Kopia: rtcweb@ietf.org =C4mne: Re: SV: [rtcweb] Some language on "prioritization" Le 2014-04-21 08:13, Karl Stahl a =E9crit : > 1) AVOIDING SELF DESTRUCTING PRIORITAZATION FROM FILE TRANSFER IN DATA = > CHANNEL >=20 > Simon, >=20 > I saw you are an author of TURN-TCP RFC6062. Doesn't that RFC allow a=20 > webrtc file transfer channel (separate from the rtcweb data channel)=20 > to be created, using TLS file transfer P2P? ICE/STUN/TURN would set it = > up, NOT BUNDLED with chunk data and RTP media. RFC6062 knows nothing about WebRTC or TLS inside the peer connection payload. So it doesn't explicitly "allow" what you suggest. But I guess = it doesn't prevent it either. It doesn't care. [Karl] OK (just realized TURN was not limited to setting up UDP with TURN-TCP RFC6062 now available), so meant "allow" in the sense: Fine, we = can use TLS for file-transfer, rather than new/complex UDP with DTLS with = SCTP.=20 > Freeing the current rtcweb data channel from file transfer would=20 > remedy the self destruction of prioritization/QoS for data chunks and=20 > RTP media as explained in (A), (B) and (C) below. >=20 > I also think it would be much better for a web programmer to have a=20 > separate p2p file transfer channel (that is not and cannot be=20 > prioritized) than pouring files into the data channel. Why do you think using a separate channel would eliminate the issue of prioritization? We would end up with multiple channels contending for = the same bandwidth. You have just moved the problem one level up. And made things needlessly more complex, IMHO. [Karl] The (A) and (B) and (C) at the bottom in the email you answered DESTROYS the QoS/Prioritization we are used over the Internet (By SCTP = data channel mixing real-time stream data with filling the pipe (congesting creating) file transfer data in the same bundle/flow/5-tuple). SCTP's own prioritization mechanism can only act on what is in the endpoint's buffers - SCTP cannot help/remedy congestion happening IN THE NETWORK where its data transfer has caused congestion when competing = with other parties file transfer TCP flows, and there filled a network buffer with the mixture of our own file transfer AND REAL-TIME data.=20 Yes, pouring a file into current data channel will even cause QoS damage = to our own bundled Video/Voice that SCTP's prio-mechanism cannot fix, = because it cannot rearrange what is queued up in a Network buffer. First after getting back to having file transfer separated out of the = bundle in another flow/5-tuple can we start thinking about improving prioritization/QoS for real-time data. [Karl] I wrote this sometime before, regarding how QoS over the internet works in general - may be useful for understanding For better understanding of these QoS/QoE problems, and methods for improving (not specifically discussing the policies of sharing real-time traffic space), I would like to explain: Over an IP pipe only used for real-traffic (no TCP data traffic), it is sufficient that the pipe is wide enough for good QoS. That is often used = and implemented by separating IP pipes at a lower level using e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can enforce real-traffic into such pipes and QoS is achieved. Let=92s call = this Level 2 QoS (Network level) Over an IP pipe shared between quality requiring real-time traffic and = less demanding data or streaming (usually TCP) traffic, we have the sharing between these two traffic classes to consider. The main method (and the mechanism making today=92s real-time QoE as good as it often is) is that = TCP endpoints back-off and share their bandwidth usage. Real-time traffic = using UDP transport do not back-off, the endpoints using UDP occupy the = bandwidth needed. When an IP pipe gets filled, it is all endpoint=92s TCP = bandwidth usage that is back-off and shared between them, leaving room for the UDP traffic. This is mechanism we experience everyday over the Internet, = using our =93Surf IP pipes=94. Let=92s call this Level 4 QoS (Transport level) However, this Level 4 QoS is based on that at congestion times (which = happen every time we click =96 setting up a TCP flow and transferring some = amount of data as quick as possible) the router handling the most narrow part of = the pipe (the congestion point) drop packets. It is this packet dropping = that (i) signals to TCP endpoints to reduce their bandwidth (via TCP=92s = error correction/retransmission mechanism) and (ii) destroys the QoE of = real-time traffic. (Both TCP and UDP packets are dropped in this process that is triggered by flow intensive TCP traffic.) We need (i) but don=92t want (ii) and to improve on this we can e.g. use diffserve, DSCP bits in IP packets to instruct routers to always forward = the real-time traffic before any unmarked TCP traffic (which usually fills = most of the pipe). Then QoS is then achieved for real-time traffic. This is = Level 3 QoS (IP level). The method used is =93traffic shaping=94: backing off = data traffic, leaving real-time traffic free passage without packet loss. Here, in TRAM we want to go beyond Level 4 QoS (already available and working as good as it can on the Internet), to give quality demanding = WebRTC real-time traffic better QoE by: a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using auto-discovered TURN servers)=20 or b. Forcing real-time traffic into IP-pipes having Level 3 QoS (using auto-discovered TURN servers). Here we must have traffic shaping = mechanisms working, and with correct and sufficient information to do the job. This = is why we in TRAM discuss DISCUSS/MALICE, draft-thomson-tram-turn-bandwidth-00.txt attributes and recreating the payload type (PT) idea/intent in RTP packets (by now conveying bandwidth = and traffic type in the RTP extension header http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html. How these QoS/QoE things are done and used in practice is also illustrated/exemplified in this email discussion: http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html=20 Prioritization of individual real-time packets (e.g. using diffserve = DSCP bits) have today little impact on the QoE, UNLESS a pipe full with only real-time traffic (which is unusual), because in today=92s IP pipes with = high bandwidth, packets are not stored for later delivery, but rather dropped = by routers implementing diffserve (after only a short time period =3D small buffer size). The only good remedy is higher bandwidth, that can handle = ALL real-time traffic.=20 Prioritization of real-time packets (any diffserve DSCP bits marking) = =93makes QoS perfect=94, when there are best effort (=3Dno DSCP bits set) TCP = (=3Dnon real-time) traffic going over the IP pipe that can be pushed off. = Routers implementing diffserve do that. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Apr 22 22:19:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57471A0063 for ; Tue, 22 Apr 2014 22:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 BuOapmr0uKFv for ; Tue, 22 Apr 2014 22:19:27 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2E1A0062 for ; Tue, 22 Apr 2014 22:19:26 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404230719187241; Wed, 23 Apr 2014 07:19:18 +0200 From: "Karl Stahl" To: "'Paul Kyzivat'" , References: <5339A120.3040909@alvestrand.no> , <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> <020501cf5d5b$117e9830$347bc890$@stahl@intertex.se> <53552EFC.3000502@alum.mit.edu> <024901cf5db2$7ac4bf70$704e3e50$@stahl@intertex.se> <5356B6B9.3050505@alum.mit.edu> In-Reply-To: <5356B6B9.3050505@alum.mit.edu> Date: Wed, 23 Apr 2014 07:19:22 +0200 Message-ID: <000701cf5eb3$960aa270$c21fe750$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9eWc6zSxlXSPjiRUCXG6dEzUJp/gAWJqqg Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OGaZSZ_g5H3QO-8pSJTfhLHpms0 Subject: Re: [rtcweb] Some language on "prioritization" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 05:19:32 -0000 -----Ursprungligt meddelande----- Fr=E5n: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Skickat: den 22 april 2014 20:37 Till: Karl Stahl; rtcweb@ietf.org =C4mne: Re: SV: [rtcweb] Some language on "prioritization" On 4/21/14 6:38 PM, Karl Stahl wrote: > Inline comments/explanations below. /Karl > > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Paul Kyzivat > Skickat: den 21 april 2014 16:45 > Till: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Some language on "prioritization" > > It bothers me to see file transfer singled out for special treatment. > > File transfer is one (common) example of a potentially high volume=20 > stream that has low requirements on latency. There are certainly other = > use cases with similar characteristics that are not file transfers. > > > --- When I say "file transfer" I mean ALL traffic of the character=20 > "transfer this high amount of data as fast as possible", OK. So you are really talking about a usage with a particular traffic = class. [Karl] Yes > which usually is done by TCP, > allowing all "bandwidth left for me at the congestion point" to be=20 > used (by the TCP endpoints regulating their flow to share the=20 > available bandwidth at the congestion point). That cannot be=20 > transferred better or with higher priority, due to its "maximum=20 > bandwidth for minimum time" nature. Congestion always occur - it is=20 > the way the available bandwidth is shared (best). That is what we use = TCP for. > > --- "Stream" I would reserve for traffic ticking along with time, NOT=20 > filling the pipe. That could be real-time data and be prioritized or=20 > reserved bandwidth for. > > --- If you know your bandwidth at the congestion point (which you=20 > don't - TCP tries it out) you could convert a file transfer into a=20 > stream by spreading it out over time, NOT filling the pipe. But then=20 > it would just take longer time to get the file transferred. File=20 > transfer cannot/should not be prioritized. > > --- These traffic types are different and need to be so. > > If it isn't feasible to manage data channels with differing priority=20 > needs within the same SCTP association, then why not simply make=20 > provision for multiple SCTP associations, with a priority for each? > > --- Yes multiple SCTP associations are possible as said in (B) below=20 > when file transfer is involved. However, for the sharing of bandwidth=20 > at congestion in the network, such SCTP associations should NOT be=20 > bundled over the same flow/5-tuple as the real-time traffic (=3DC=20 > below). You then need to set up another ICE connection - That is where = > I now suggested to do it with TLS instead (which already is perfect=20 > for file transfer) instead of SCTP (which could be used if working = equally well, although much more complex). > Neither can/should prioritize file transfer though. ISTM that avoiding setting up another 5-tuple, with the trouble of ICE, = etc. is one of the goals.=20 [Karl] Yes, that goal will unfortunately have to be sacrificed=20 The data channels give you a cheap and easy way to set up these things. IIUC there is already a desire/intent to mark the different streams = within a bundle as different priorities/traffic classes. (I thought that is what = DART is about.)=20 [Karl] For whom to act upon? At the network level? Do you have a = pointer? Isn't that good enough to achieve the same end as running the data over = a different 5-tuple? [Karl] Nope, I don't think reservation type of networks could do that = even with very complex network equipment doing reservations (which I believe = is per flow).=20 Apparently there is a problem with doing that at the data channel level. = But I wouldn't think it would be a problem for multiple SCTP = associations in the same bundle. (Different SCTP port numbers.) That would allow you to = have one association for "file transfers" and one for more interactive data. [Karl] Still one flow/5-tuple for one bundle - I also wish there was a = way around that Thanks, Paul > Thanks, > Paul > > On 4/21/14 8:13 AM, Karl Stahl wrote: >> 1) AVOIDING SELF DESTRUCTING PRIORITAZATION FROM FILE TRANSFER IN=20 >> DATA CHANNEL >> >> Simon, >> >> I saw you are an author of TURN-TCP RFC6062. Doesn't that RFC allow a = >> webrtc file transfer channel (separate from the rtcweb data channel)=20 >> to be created, using TLS file transfer P2P? ICE/STUN/TURN would set=20 >> it up, NOT BUNDLED with chunk data and RTP media. >> >> Freeing the current rtcweb data channel from file transfer would=20 >> remedy the self destruction of prioritization/QoS for data chunks and = >> RTP media as explained in (A), (B) and (C) below. >> >> I also think it would be much better for a web programmer to have a=20 >> separate p2p file transfer channel (that is not and cannot be >> prioritized) than pouring files into the data channel. >> >> >> 2) MARKING PRIORITY DATA AND MEDIA FOR NETWORK LEVEL=20 >> PRIORITIZATION/QoS >> >> P=E5l, Harald, Magnus, Collins, Tiru, Dan, >> >> We have previously discussed how to convey traffic info (bandwidth=20 >> requirement, and traffic type/prio) from the browser/application to=20 >> the network layer to prioritize or take other QoS measure by some=20 >> network element. >> >> I have been pushing for inserting such traffic info into every RTP=20 >> media packet in the RTP header extension, see [1] below. >> >> After looking how to mark data channel priority data chunks=20 >> similarly, I suggested [2] below, i.e. a new DTLS ContentType for the = >> rtcweb data channel, where the content would be the unencrypted=20 >> traffic info (preferable the same as in the RTP header extension)=20 >> followed by the SCTP data. >> >> Are there other ways? - Maybe more similar, consistent and/or better? >> >> We need the traffic info (contrary to e.g. DSCP bits) to be unchanged = >> end-to-end and available in both STUN and TURN flows for network=20 >> elements to see and act upon (e.g. to set DSCP bits or reserve=20 >> bandwidth or otherwise regulate) for various network types. The=20 >> traffic info must also be possible for network elements to find. >> >> No way b!) Since webrtc now mandates DTLS-SRTP for media, cannot that = >> DTLS also hold the traffic info, just as for the data chunks >> - instead of putting the traffic info into the RTP header extension? >> NO, here the DTLS is only in the key exchange packets - not in every=20 >> packet so that would NOT work, unfortunately. >> >> A way c?) Why not send data chunks in SRTP (instead of SCTP) and=20 >> reuse the RTP header extension for the traffic info for the network layer. >> (File transfer is done in 1) above - not here!) >> >> What other things from SCTP do we actually want? (Not everything from = >> that complex protocol for carrying telephony signaling can be of=20 >> interest for webrtc.) >> >> - Priority (local): The browser could have a prioritizing mechanism=20 >> including both media and data chunks before putting it in the UDP=20 >> socket (simpler than SCTP). >> >> - Reliable data: A small transaction layer with retransmission of=20 >> reliable data chunks could be implemented by the browser (simpler=20 >> than SCTP). >> >> So with this way c, SCTP would go away totally and only the RTP=20 >> header extension would be used for traffic info to the network layer. >> >> >> Are there more ways? We need this traffic info to allow WebRTC with=20 >> acceptable QoS over all network types (especially mobile Internet/OTT = >> LTE and Cable Networks that are of reservation type). >> >> >> Below are also a few comments to other feedback. >> >> /Karl >> >> >> On 10 Apr 2014, at 17:35, Paul Kyzivat [pkyzivat@alum.mit.edu] wrote: >> I presume you mean each *concurrent* file transfer must use its own > channel. >> Right? Reusing the same channel to transfer a series of files should=20 >> be fine. >> >> Thanks, >> Paul >> [Karl] Yes, That is right. /Karl >> >> On 10 Apr 2014, at 15:14, Harald Alvestrand [harald@alvestrand.no] = wrote: >> Just checking... since there's been no comment to the main body of=20 >> the text here (it's all been on the SCTP aspect), is it OK to include = >> the text in my next version of the -transport draft? >> >> (I'm not responding to Karl's comments - it's at a completely=20 >> different level of complexity.) >> >> [Karl] Yes, it is but needs to be addressed. I think file transfer=20 >> just be taken out of the data channel, and a file transfer channel=20 >> (on a separate flow, as suggested above) be defined for Web=20 >> programmers to use. That would remedy (A), (B) and (C) below (p2p=20 >> file transfer not destroying priority for data chunks and media). >> The file transfer channel would not/cannot be prioritized. >> >> On 03 Apr 2014, at 21:12, Michael Tuexen >> [Michael.Tuexen@lurchi.franken.de]wrote: >>> Is there an >>> overall design/thought somewhere that I missed/am unaware of?) >> The basis idea is to use a stream scheduler to handle streams = different. >> Some data channels can get a higher bandwidth than others. Since the=20 >> priority stuff is still in flux in W3C, it hasn't been nailed down in = >> the SCTP spec. I guess, the place will be in >> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00 >> This document is not finalized yet. >>> >> [Karl] There are severe limitations for doing prioritization in a=20 >> protocol (SCTP or other) executed in the endpoints. In most cases=20 >> there are no packets in the endpoint to put first among queued up=20 >> traffic, because the queue is somewhere else between the endpoints. >> Just consider the most common case where the endpoints are connected=20 >> with a fast Ethernet. The data has then already left the endpoint and = >> is queued up at some congestion point in the network where the SCTP=20 >> protocol cannot rearrange the queue. First when that unreachable=20 >> queue is full, there is something in the endpoint to act upon... >> >> >> -----Ursprungligt meddelande----- >> Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Karl Stahl >> Skickat: den 3 april 2014 18:30 >> Till: 'Matthew Kaufman (SKYPE)'; 'Harald Alvestrand'; 'Magnus = Westerlund' >> Kopia: rtcweb@ietf.org >> =C4mne: Re: [rtcweb] Some language on "prioritization" >> >> The questions raised here don't have simple "local or endpoint=20 >> answers". There are overall and basic things to be made clear first. >> Combining P2P file transfer over the rtcweb data channels with=20 >> prioritized traffic chunks, brings further complications to the=20 >> prioritization/QoS issue. This cannot be handled/done by endpoint or=20 >> applications without considering the transport network (The=20 >> congestion to handle by prioritization is in the network - NOT in the endpoints)! >> >> There are below (A), (B) and (C) - to get us back to normal - then=20 >> there is (D) to improve - to allow the network level to give us the=20 >> prioritization required for WebRTC critical traffic (real-time and=20 >> data chunks). Without (D) - an interface to network QoS equipment -=20 >> the network does not even know what to prioritize. >> >> I am afraid that this will be considered "back to the drawing board" >> rather than "some language" but I cannot see the way forward if not=20 >> considered. >> >> Has the SCTP data channel been constructed with hopes of=20 >> prioritization/quality functionality that simply are not there=20 >> (cannot be there)? (I have browsed the (complex) SCTP spec and some=20 >> rtcweb drafts to get an understanding of the prioritization/QoS=20 >> thoughts and means in this rtcweb context and the intended usage. Is=20 >> there an overall design/thought somewhere that I missed/am unaware=20 >> of?) >> >> File transfer - getting a larger amount of data through between=20 >> endpoints as quickly as possible - CANNOT be prioritized over IP=20 >> networks! For file transfer we normally use TCP, meaning we fill the=20 >> pipe, until THE ENDPOINTS see packet drop and regulate down their=20 >> traffic flow. File transfer over IP networks works this way and=20 >> cannot be improved upon ("Internet would stop" if we prioritized such = >> traffic! The available bandwidth at congestion points are shared=20 >> between everyone's TCP-flows hitting such congestion points in the >> network.) File transfer's nature is to have "infinite bandwidth=20 >> demand" - the mechanism to handle this is to allow file transfer to=20 >> "take the rest of the bandwidth" >> after prioritized media and chunks have taken their needed share. >> >> The improvement to make - prioritization of media traffic and data=20 >> chunks - is to allow level 3 QoS methods - not only relying on the=20 >> level 4 TCP backing off process. Without level 3 QoS (diffserve/DSCP, = >> reservation or separate pipes) media and data chunks packets are also = >> lost in the level 4 TCP backing off process (=3Dtoday's situation = over=20 >> best effort Internet). That is where the prioritization/QoS measures=20 >> that we need for rtcweb have to be. >> >> SCTP in itself (instead of TLS/TCP) does not/cannot/will not improve=20 >> things. It can destroy though if wrongly/badly implemented or used! >> >> >From the SCTP RFC4960: 7. Congestion Control >> ...adequate resources will be allocated to SCTP traffic >> to ensure prompt delivery of time-critical data ... unlikely, >> during normal operations, that transmissions encounter severe >> congestion conditions. >> >> However, SCTP must operate under adverse operational >> conditions, which can develop upon partial network failures >> or unexpected traffic surges. In such situations, SCTP must >> follow correct congestion control steps to recover from >> congestion quickly in order to get data delivered as soon as >> possible. >> >> ... SCTP congestion control is always applied to the entire >> association, and not to individual streams. >> >> Doing file transfer with the data channel will use SCTP in the=20 >> "adverse operational conditions, which can develop upon partial=20 >> network failures or unexpected traffic surges"-mode! Has that been=20 >> considered when constructing the data channel? Hope so... >> >> Assuming SCTP is implemented correctly and as good as TCP for file=20 >> transfer (even though file transfer =3D filling the pipe mode is an=20 >> "adverse condition..." for SCTP). Then we must specify: >> >> >> (A) Rtcweb file transfer MUST NOT use the same data channel as data=20 >> chunks expected to have prioritized delivery (otherwise, as per=20 >> above, SCTP will regulate the "the entire association" >> to share the available bandwidth at the congestion point -=20 >> self-destroying the expected prioritized delivery of data chunks in=20 >> the same channel). >> >> (B) Each rtcweb file transfer MUST use its own data channel (if=20 >> combined they risk being regulated randomly/unfairly by SCTP itself=20 >> and all files will have just have one single TCP-like flow at the=20 >> network congestion point when sharing the available bandwidth with=20 >> everyone else's flows at that congestion point >> - That would be "negative priority" compared to what we are used to=20 >> in a browser.). >> >> FURTHER, to allow the underlying network the ability to handle the=20 >> real-time and data chunks as least as good as "before rtcweb" >> (Unfortunately this will make NAT-firewall less good - not sending=20 >> everything P2P in a single bundle/flow - I don't like it either... >> Sorry...): >> >> (C) File transfer using the data channel MUST NOT be bundled with=20 >> media and data chunk traffic in the same flow - file transfer must=20 >> use a separate socket creating another flow/5-tuple over the network. >> (In reservation type of networks (e.g. mobile OTT, cable), file=20 >> transfer - having no bandwidth limitation - would otherwise overflow=20 >> the reserved bandwidth for media and chunck traffic - destroying=20 >> prioritized delivery of media and chunck traffic over that flow.)=20 >> Such file transfer data channels MUST NOT be prioritized by the=20 >> underlying network (applies to all IP network types, network=20 >> prioritization of file transfer will STOP traffic between endpoints >> - Endpoint's TCP-like regulation has to function!). Several file=20 >> transfers could share such a separate flow (without specifying in SDP = >> I guess) but the underlying network must be able to separate such=20 >> flows (not to be prioritized) from media and chunk flows. >> >> In the API, such file transfer data channel could be mapped to the=20 >> "below normal" classification (but would it not be better with a=20 >> "file transfer channel" API instead?). (And notice that without (D)=20 >> below, the network is not informed how to separate a file transfer=20 >> data channel flow from a prioritized data channel >> flow.) >> >> >> Having (A), (B) and (C) in place we are BACK TO THE CURRENT Internet=20 >> prioritization/QoS level - before the rtcweb p2p data channel file=20 >> transfer was introduced... >> >> Now remains the prioritization improvement required for quality >> >> hungry rtcweb! Both for the real-time media and the data chuncks. >> >> >> (D) The underlying transport network needs to be informed about the=20 >> traffic requirements. >> >> - In RTP media this traffic info could be inserted by the rtcweb=20 >> browser in the RTP header extension [1] depending on codec usage etc. >> The API classification could be mapped to the "Prioritize X(2 bits)" >> suggested in [1] below. >> >> - for the data channel, the traffic info could be inserted as=20 >> suggested in previous email ([2] below)=20 >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973.html >> >> Note that the required bandwidth (only known by the >> browser/application) has to be passed to reservation types of = network. >> Requested prioritization from the API or DSCP bits are not = sufficient. >> The browser knows the bandwidth requirements for codecs, but for data = >> chunks, the application has the knowledge. >> In lack of a bandwidth parameter in the data channel API, a simple=20 >> convention - e.g. reserve 200 kbps for data chunks could serve as a=20 >> compromise (or 4 bandwidths mapped to the API prioritize=20 >> classifications...). A modified API with the bandwidth requirement=20 >> spelled out would of course be better for the chuck data channel. >> For a file transfer data channel - prioritization classification does = >> not even apply. >> >> >> Having prioritization over the network cleared, the application=20 >> should use that transport properly - having media and data chunks=20 >> transported with prioritization (as produced/inserted), NOT queuing=20 >> them up, rearranged by protocols or applications and NOT involving=20 >> file transfer (that has to be unprioritized). >> >> Using DSCP bits if available through the OS in some situations does=20 >> not help either, as already pointed out in the transport document. >> For (D) above, DSCP bits could in a few situations function locally,=20 >> but not end-to-end, so of no use generally. >> >> /Karl >> >> >> [1] Traffic type information to encode (recreating the idea/intention = >> of the RTP payload type (PT) header that is not available for the=20 >> network level anymore, by instead having the browser filling the RTP=20 >> header extension with relevant traffic info that all IP network types = >> can use.), as suggested already October 22. Two parameters to encode=20 >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html >> >> A) The maximum bandwidth requirement: Two bytes could contain=20 >> everything from some bps for real-time text to Gbps for future 3D=20 >> supersize telepresence on a logarithmic scale. >> >> B) The quality characteristics for the stream, with the highest bit=20 >> set to 1, we could allocate a bit each for quality type e.g: >> Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay=20 >> Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = >> Prioritize X(2 bits), Variation Y(2 bits), that could be combined as=20 >> required to describe the stream. >> >> And with the highest bit set to 0, there could instead be a number=20 >> for special usage that does not fit the general description of the=20 >> individual bits. >> >> Without this information, how could e.g. a reservation type network=20 >> (e.g. mobile OTT and cable) reserve the bandwidth required for=20 >> incoming rtcweb media or data chunks from a diffserve network=20 >> (carrying no bandwidth requirement)? >> >> >> [2] A new DTLS ContentType (e.g. 24 instead of current 23) for the=20 >> rtcweb data channel, where the content would be the unencrypted=20 >> traffic info (preferable the same as in the RTP header extension)=20 >> followed by the SCTP data as it is today (where it today comes=20 >> directly in the DTLS as the only content).: >> >> TODAY: >> Content Type: 23 (1 byte) content type 23 means =93application = data=94 >> DTLS version: 0xfeff (2 byte) >> Epoch: 0001 (2 byte) >> Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 = >> byte Encrypted application data: ...... =3D the SCTP >> >> SUGGESTION WITH ADDED TRAFFIC INFO FOR LOWER LEVELS: >> Content Type: 24 (1 byte) content type 24 meaning =93application data = >> preceded by traffic info=94 >> DTLS version: 0xfeff (2 byte) >> Epoch: 0001 (2 byte) >> Sequence number (e.g. 00 00 00 00 00 01) 6 byte Length (e.g. 01 c0) 2 >> byte: length of the encrypted application data after the new header=20 >> extension TRAFFIC INFO, Same as suggested for the RTP Header >> extension: >> Encrypted application data: ...... ...... =3D the SCTP unchanged >> >> >> -----Ursprungligt meddelande----- >> Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Matthew Kaufman >> (SKYPE) >> Skickat: den 31 mars 2014 19:50 >> Till: Harald Alvestrand >> Kopia: rtcweb@ietf.org >> =C4mne: Re: [rtcweb] Some language on "prioritization" >> >> And if SCTP and RTP have packets to send, which goes first, why, and=20 >> under what circumstances? >> >> Matthew Kaufman >> >> (Sent from my iPhone) >> >>> On Mar 31, 2014, at 10:48 AM, "Harald Alvestrand" >>> >> wrote: >>> >>>> On 03/31/2014 07:42 PM, Michael Tuexen wrote: >>>>> On 31 Mar 2014, at 19:38, Martin Thomson=20 >>>>> >> wrote: >>>>> >>>>>> On 31 March 2014 10:08, Harald Alvestrand > wrote: >>>>>> -- TODO: Specify a relative priority scheme that makes sense with = >>>>>> SCTP, with an appropriate reference. >>>>>> [draft-ietf-tsvwg-sctp-prpolicies] >>>>>> specifies a priority policy, but it's about discarding packets,=20 >>>>>> not deciding which packets to send first, and it also makes it=20 >>>>>> impossible to specify time-bounded retransmission. -- >>>>> >>>>> Why would SCTP need special treatment? I can understand if there=20 >>>>> are particular time-sensitive control messages that need to be=20 >>>>> given higher priority, but this is all time-sensitive. >>>> A single transport connection (in this case an SCTP association)=20 >>>> can only use a single DSCP. So it would be OK to use the same=20 >>>> priority for all data channels, but things get complicated when=20 >>>> when some data channels would have different priorities requiring=20 >>>> different DSCP >> markings. >>> >>> The SCTP protocol machine will, at some given moment in time, have=20 >>> packets in its send buffers that belong to multiple data channels. >>> Only one of them can go on the wire first. >>> >>> Which packet does it choose to send first, and why? >>> >>> That's the question I'm looking for an answer to. >>> >>> If the answer has an RFC number, chapter and section, I'd be very = happy. >>> If it doesn't - perhaps we have to invent one. >>> Or say that it's "implementation dependent". >>> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From nobody Wed Apr 23 05:31:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3681A0345 for ; Wed, 23 Apr 2014 05:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 wermhLwKHAv0 for ; Wed, 23 Apr 2014 05:31:04 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE401A01C3 for ; Wed, 23 Apr 2014 05:31:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3A8317C536F for ; Wed, 23 Apr 2014 14:30:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvQJVLBIm6K5 for ; Wed, 23 Apr 2014 14:30:57 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 593167C0427 for ; Wed, 23 Apr 2014 14:30:57 +0200 (CEST) Message-ID: <5357B281.1030900@alvestrand.no> Date: Wed, 23 Apr 2014 14:30:57 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sUuhWS8U2INHB7TO1DfUkyuZLn4 Subject: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 12:31:07 -0000 I quote Karl's piece below, because I want other's opinion of whether it's a realistic picture. My impression is that it is not - in particular that: - Lots of interactive traffic goes over the Internet today without layer 2 separation - All UDP endpoints that use the open Internet have some form of backoff on congestion - using delay, packet drop or (most likely) both to detect congestion I'm writing the transport document based on those assumptions - that we should specify something that will work as well as it can over an Internet that does not care, and try to allow for better things to come along later. Am I wrong to write it like this? Harald ------------------------------------ [Karl] I wrote this sometime before, regarding how QoS over the internet works in general - may be useful for understanding For better understanding of these QoS/QoE problems, and methods for improving (not specifically discussing the policies of sharing real-time traffic space), I would like to explain: Over an IP pipe only used for real-traffic (no TCP data traffic), it is sufficient that the pipe is wide enough for good QoS. That is often used and implemented by separating IP pipes at a lower level using e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can enforce real-traffic into such pipes and QoS is achieved. Let’s call this Level 2 QoS (Network level) Over an IP pipe shared between quality requiring real-time traffic and less demanding data or streaming (usually TCP) traffic, we have the sharing between these two traffic classes to consider. The main method (and the mechanism making today’s real-time QoE as good as it often is) is that TCP endpoints back-off and share their bandwidth usage. Real-time traffic using UDP transport do not back-off, the endpoints using UDP occupy the bandwidth needed. When an IP pipe gets filled, it is all endpoint’s TCP bandwidth usage that is back-off and shared between them, leaving room for the UDP traffic. This is mechanism we experience everyday over the Internet, using our “Surf IP pipes”. Let’s call this Level 4 QoS (Transport level) However, this Level 4 QoS is based on that at congestion times (which happen every time we click – setting up a TCP flow and transferring some amount of data as quick as possible) the router handling the most narrow part of the pipe (the congestion point) drop packets. It is this packet dropping that (i) signals to TCP endpoints to reduce their bandwidth (via TCP’s error correction/retransmission mechanism) and (ii) destroys the QoE of real-time traffic. (Both TCP and UDP packets are dropped in this process that is triggered by flow intensive TCP traffic.) We need (i) but don’t want (ii) and to improve on this we can e.g. use diffserve, DSCP bits in IP packets to instruct routers to always forward the real-time traffic before any unmarked TCP traffic (which usually fills most of the pipe). Then QoS is then achieved for real-time traffic. This is Level 3 QoS (IP level). The method used is “traffic shaping”: backing off data traffic, leaving real-time traffic free passage without packet loss. From nobody Wed Apr 23 06:27:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674891A03A7; Wed, 23 Apr 2014 06:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 gNY-WRXkrsRW; Wed, 23 Apr 2014 06:27:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1111A0362; Wed, 23 Apr 2014 06:27:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423132741.9210.61684.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 06:27:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qyzKSbrmOWUMaHTE6Ls8r01LZUk Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 13:27:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP Authors : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-13.txt Pages : 45 Date : 2014-04-23 Abstract: The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-13 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 Wed Apr 23 06:33:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EC61A03A9 for ; Wed, 23 Apr 2014 06:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 ooufphHCeXFx for ; Wed, 23 Apr 2014 06:32:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 16A571A0362 for ; Wed, 23 Apr 2014 06:32:57 -0700 (PDT) X-AuditID: c1b4fb25-f798a6d000005ede-78-5357c1037366 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AA.42.24286.301C7535; Wed, 23 Apr 2014 15:32:51 +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.174.1; Wed, 23 Apr 2014 15:32:51 +0200 Message-ID: <5357C102.2060606@ericsson.com> Date: Wed, 23 Apr 2014 15:32:50 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20140423132741.9210.61684.idtracker@ietfa.amsl.com> In-Reply-To: <20140423132741.9210.61684.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvjS7zwfBgg/UrdS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuPyE8wFTeIVr3ccY2tgnCjUxcjJISFgInFucy87hC0mceHe erYuRi4OIYGjjBL9566xQzjLGSVuNV8Dq+IV0JaY+u0CmM0ioCrx6MQxMJtNwELi5o9GNhBb VCBYYumcxSwQ9YISJ2c+AbNFBNQlLj+E6BUWsJbomvwJzBYScJBYdfQqM4jNKeAo8bb1EFCc A+gicYmexiCQMLOAnsSUqy2MELa8RPPW2cwQrdoSDU0drBMYBWch2TYLScssJC0LGJlXMYoW pxYn5aYbGeulFmUmFxfn5+nlpZZsYgSG5sEtv1V3MF5+43iIUYCDUYmHl03NL1iINbGsuDL3 EKM0B4uSOO+XWz7BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgZeLcub5BNjeNl/K38/eaC xcrLZOvjXWTWRz1mZjgz6e65niUVZvP0OUIUeQvFY2UCbdomxnsWPVZ0Vtnz6mOJX/zlB9He 2o/f3M1fmbPpnGaa3gmmGqX7nmYfBI2jstT5HROrLqxXz/Q34+z1nlZcut92r1SdWM2bi0xT Lq/cz6xm+shERomlOCPRUIu5qDgRAPM/w4AuAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TSDwJTB8JLCucbG1n_a1xRvQcu8 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 13:33:00 -0000 WG, We authors have been doing some editing on this version to take care of the last known issues. This includes the text that has been discussed on the list lately. It also contains an expanded example about RTCP bandwidth (see Section 7.2). Further we have reviewed the terminology usage in the document, and applied the AVTEXT grouping taxonomy. So, we authors now believe this to be ready for WG last call. Cheers Magnus On 2014-04-23 15:27, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP > Authors : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-13.txt > Pages : 45 > Date : 2014-04-23 > > Abstract: > The Web Real-Time Communication (WebRTC) framework provides support > for direct interactive rich communication using audio, video, text, > collaboration, games, etc. between two peers' web-browsers. This > memo describes the media transport aspects of the WebRTC framework. > It specifies how the Real-time Transport Protocol (RTP) is used in > the WebRTC context, and gives requirements for which RTP features, > profiles, and extensions need to be supported. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-13 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-13 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- 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 23 08:03:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABADC1A03DB for ; Wed, 23 Apr 2014 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 pnxlEwrAMvzs for ; Wed, 23 Apr 2014 08:03:03 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id C28191A0104 for ; Wed, 23 Apr 2014 08:03:02 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so969177wgh.4 for ; Wed, 23 Apr 2014 08:02:56 -0700 (PDT) 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:content-type; bh=QIF3/7O9tnYyn5ZJJYV8WvanOSQhVjBecWj5ZxJZ8jY=; b=C5aoQ5dra1NN46SY0M13wcYR12wvABmwq0sE4PJ9XXXxsUZQBxfSmSXtft++ZaWsaB m1ORnbQ2vhXYy8EmZW0KYbrCYuSlW1oUP5gIhkIKJ3Q3qhQlTjCBj0tcN/st7mf3F4w/ xxoPN/0wR7QuFnWb+G4mw0/KBPlCy+ykFQFct8b/BpJahlCI6JnBX48JYeRKbO4Hb9/j fEB656rRY/2jZkrnOxkQ6qDhx069lH8tXFSirAlqUetsjMAHfWpZ4LOocXCtoljsIogh 45vARlMARAb0StBIPo/KezJld7nfSrGmdjM8I05KbPSgq3ZEddwF++wttbrk2aF+3Wd6 dDSw== X-Gm-Message-State: ALoCoQkwVLuJom3fBjl3it5UDXcozxxCw6K8MOGO8cSbI2EJc9Dfm2jf5gkInNr7aO49DYqLMXZD X-Received: by 10.180.91.161 with SMTP id cf1mr2310909wib.1.1398265376366; Wed, 23 Apr 2014 08:02:56 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx.google.com with ESMTPSA id h10sm4752317wix.2.2014.04.23.08.02.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 08:02:55 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so5070048wiv.1 for ; Wed, 23 Apr 2014 08:02:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.205.197 with SMTP id li5mr2162829wic.19.1398265374790; Wed, 23 Apr 2014 08:02:54 -0700 (PDT) Received: by 10.216.181.136 with HTTP; Wed, 23 Apr 2014 08:02:54 -0700 (PDT) Received: by 10.216.181.136 with HTTP; Wed, 23 Apr 2014 08:02:54 -0700 (PDT) In-Reply-To: <5357B281.1030900@alvestrand.no> References: <5357B281.1030900@alvestrand.no> Date: Wed, 23 Apr 2014 11:02:54 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11c38cc2f75ddf04f7b70699 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RKuFV5WHfs1vVpPWRaTGm13R-m0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 15:03:13 -0000 --001a11c38cc2f75ddf04f7b70699 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would say that some video end points have congestion back off. Almost all audio end points have none. Based on this, most UDP endpoints do not deal well with congestion. Ideally this should change to support better bandwidth management. Futhermore, reliably transmitting real time media over public internet would also require changes to biffer management algorithms in routers, which will, in turn, affect congestion handling strategies in the end points. On Apr 23, 2014 8:31 AM, "Harald Alvestrand" wrote: > > I quote Karl's piece below, because I want other's opinion of whether it's a realistic picture. > > My impression is that it is not - in particular that: > > - Lots of interactive traffic goes over the Internet today without layer 2 separation > - All UDP endpoints that use the open Internet have some form of backoff on congestion - using delay, packet drop or (most likely) both to detect congestion > > I'm writing the transport document based on those assumptions - that we should specify something that will work as well as it can over an Internet that does not care, and try to allow for better things to come along later. > > Am I wrong to write it like this? > > Harald > > > > ------------------------------------ > [Karl] I wrote this sometime before, regarding how QoS over the internet > works in general - may be useful for understanding > > For better understanding of these QoS/QoE problems, and methods for > improving (not specifically discussing the policies of sharing real-time > traffic space), I would like to explain: > > Over an IP pipe only used for real-traffic (no TCP data traffic), it is > sufficient that the pipe is wide enough for good QoS. That is often used and > implemented by separating IP pipes at a lower level using e.g. Ethernet > VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can > enforce real-traffic into such pipes and QoS is achieved. Let=E2=80=99s c= all this > Level 2 QoS (Network level) > > Over an IP pipe shared between quality requiring real-time traffic and less > demanding data or streaming (usually TCP) traffic, we have the sharing > between these two traffic classes to consider. The main method (and the > mechanism making today=E2=80=99s real-time QoE as good as it often is) is= that TCP > endpoints back-off and share their bandwidth usage. Real-time traffic using > UDP transport do not back-off, the endpoints using UDP occupy the bandwidth > needed. When an IP pipe gets filled, it is all endpoint=E2=80=99s TCP ban= dwidth > usage that is back-off and shared between them, leaving room for the UDP > traffic. This is mechanism we experience everyday over the Internet, usin= g > our =E2=80=9CSurf IP pipes=E2=80=9D. Let=E2=80=99s call this Level 4 QoS = (Transport level) > > However, this Level 4 QoS is based on that at congestion times (which happen > every time we click =E2=80=93 setting up a TCP flow and transferring some= amount of > data as quick as possible) the router handling the most narrow part of th= e > pipe (the congestion point) drop packets. It is this packet dropping that > (i) signals to TCP endpoints to reduce their bandwidth (via TCP=E2=80=99s= error > correction/retransmission mechanism) and (ii) destroys the QoE of real-time > traffic. (Both TCP and UDP packets are dropped in this process that is > triggered by flow intensive TCP traffic.) > > We need (i) but don=E2=80=99t want (ii) and to improve on this we can e.g= . use > diffserve, DSCP bits in IP packets to instruct routers to always forward the > real-time traffic before any unmarked TCP traffic (which usually fills most > of the pipe). Then QoS is then achieved for real-time traffic. This is Level > 3 QoS (IP level). The method used is =E2=80=9Ctraffic shaping=E2=80=9D: b= acking off data > traffic, leaving real-time traffic free passage without packet loss. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --001a11c38cc2f75ddf04f7b70699 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would say that some video end points have congestion back = off.=C2=A0 Almost all audio end points have none. Based on this, most UDP e= ndpoints do not deal well with congestion. Ideally this should change to su= pport better bandwidth management. Futhermore, reliably transmitting real t= ime media over public internet would also require changes to biffer managem= ent algorithms in routers, which will, in turn, affect congestion handling = strategies in the end points.

On Apr 23, 2014 8:31 AM, "Harald Alvestrand" <<= a href=3D"mailto:harald@alvestrand.no">harald@alvestrand.no> wrote:<= br> >
> I quote Karl's piece below, because I want other's opinion of = whether it's a realistic picture.
>
> My impression is that it is not - in particular that:
>
> - Lots of interactive traffic goes over the Internet today without lay= er 2 separation
> - All UDP endpoints that use the open Internet have some form of backo= ff on congestion - using delay, packet drop or (most likely) both to detect= congestion
>
> I'm writing the transport document based on those assumptions - th= at we should specify something that will work as well as it can over an Int= ernet that does not care, and try to allow for better things to come along = later.
>
> Am I wrong to write it like this?
>
> Harald
>
>
>
> ------------------------------------
> [Karl] I wrote this sometime before, regarding how QoS over the intern= et
> works in general - may be useful for understanding
>
> For better understanding of these QoS/QoE problems, and methods for > improving (not specifically discussing the policies of sharing real-ti= me
> traffic space), I would like to explain:
>
> Over an IP pipe only used for real-traffic (no TCP data traffic), it i= s
> sufficient that the pipe is wide enough for good QoS. That is often us= ed and
> implemented by separating IP pipes at a lower level using e.g. Etherne= t
> VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can<= br> > enforce real-traffic into such pipes and QoS is achieved. Let=E2=80=99= s call this
> Level 2 QoS (Network level)
>
> Over an IP pipe shared between quality requiring real-time traffic and= less
> demanding data or streaming (usually TCP) traffic, we have the sharing=
> between these two traffic classes to consider. The main method (and th= e
> mechanism making today=E2=80=99s real-time QoE as good as it often is)= is that TCP
> endpoints back-off and share their bandwidth usage. Real-time traffic = using
> UDP transport do not back-off, the endpoints using UDP occupy the band= width
> needed. When an IP pipe gets filled, it is all endpoint=E2=80=99s TCP = bandwidth
> usage that is back-off and shared between them, leaving room for the U= DP
> traffic. This is mechanism we experience everyday over the Internet, u= sing
> our =E2=80=9CSurf IP pipes=E2=80=9D. Let=E2=80=99s call this Level 4 Q= oS (Transport level)
>
> However, this Level 4 QoS is based on that at congestion times (which = happen
> every time we click =E2=80=93 setting up a TCP flow and transferring s= ome amount of
> data as quick as possible) the router handling the most narrow part of= the
> pipe (the congestion point) drop packets. It is this packet dropping t= hat
> (i) signals to TCP endpoints to reduce their bandwidth (via TCP=E2=80= =99s error
> correction/retransmission mechanism) and (ii) destroys the QoE of real= -time
> traffic. (Both TCP and UDP packets are dropped in this process that is=
> triggered by flow intensive TCP traffic.)
>
> We need (i) but don=E2=80=99t want (ii) and to improve on this we can = e.g. use
> diffserve, DSCP bits in IP packets to instruct routers to always forwa= rd the
> real-time traffic before any unmarked TCP traffic (which usually fills= most
> of the pipe). Then QoS is then achieved for real-time traffic. This is= Level
> 3 QoS (IP level). The method used is =E2=80=9Ctraffic shaping=E2=80=9D= : backing off data
> traffic, leaving real-time traffic free passage without packet loss. >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--001a11c38cc2f75ddf04f7b70699-- From nobody Wed Apr 23 08:19:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984D41A03E1 for ; Wed, 23 Apr 2014 08:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 WN_ru3lonQNU for ; Wed, 23 Apr 2014 08:18:55 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4B01A0389 for ; Wed, 23 Apr 2014 08:18:55 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q58so1015781wes.12 for ; Wed, 23 Apr 2014 08:18:48 -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:content-type:content-transfer-encoding; bh=FlCCAMlIgVYv5yg+ZxGO+mTP0S1AsJHefaCYPV4koBw=; b=VcICUcoOCRs8mvRMRKysDBYB568CaWqyJIvH8yz41fjlyEmqKMJvnoAu1IxLKA4df+ EhgfzDxEHBGAAsf+Fk0QSSL6sQqkL+6XOmMLNZmuTvkledRIwOhchmfqw0+HawWlHfRB dazH6YcjV5CUg6ioiJ3UAPGH5fLR/2tc3YnTSDISVnbiGMExTxndjETzXcuShRTykpqC abhz5S07lDFwLtdNfMIh0yCQAIl9MpkpgZgWdLuTdu6Gsa3i5JvOWPgS2vT3hglk3cO2 0ByYaMoYJZg59ATzq/IFTAuLHgtHP21tuNb8/z2pJuAzwNVezogrb/l6BW2MbxQlOcnh S4Bg== MIME-Version: 1.0 X-Received: by 10.180.76.166 with SMTP id l6mr2269727wiw.17.1398266328883; Wed, 23 Apr 2014 08:18:48 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Wed, 23 Apr 2014 08:18:48 -0700 (PDT) In-Reply-To: <5357B281.1030900@alvestrand.no> References: <5357B281.1030900@alvestrand.no> Date: Wed, 23 Apr 2014 08:18:48 -0700 Message-ID: From: Dave Taht To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5RJWlfAj9xHx8x1ZVFbYKYtNu1g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 15:19:03 -0000 On Wed, Apr 23, 2014 at 5:30 AM, Harald Alvestrand w= rote: > I quote Karl's piece below, because I want other's opinion of whether it'= s a > realistic picture. > > My impression is that it is not - in particular that: > > - Lots of interactive traffic goes over the Internet today without layer = 2 > separation > - All UDP endpoints that use the open Internet have some form of backoff = on > congestion - using delay, packet drop or (most likely) both to detect > congestion I'm not sure if we have a shared definition of "congestion". Mine is network delays exceeding that of what human factors research notes as "perceptible" with about 20ms as the outer bound. http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-t= raditional-aqm-is-not-enough/ Kathie/Van something like a sustained delay > 1.1 * RTT =3D bad queue Bittorrent folk put it at > 100ms Others use even bigger numbers. > I'm writing the transport document based on those assumptions - that we > should specify something that will work as well as it can over an Interne= t > that does not care, and try to allow for better things to come along late= r. > > Am I wrong to write it like this? > > Harald > > > > ------------------------------------ > [Karl] I wrote this sometime before, regarding how QoS over the internet > works in general - may be useful for understanding > > For better understanding of these QoS/QoE problems, and methods for > improving (not specifically discussing the policies of sharing real-time > traffic space), I would like to explain: > > Over an IP pipe only used for real-traffic (no TCP data traffic), it is > sufficient that the pipe is wide enough for good QoS. That is often used = and > implemented by separating IP pipes at a lower level using e.g. Ethernet > VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can > enforce real-traffic into such pipes and QoS is achieved. Let=E2=80=99s c= all this > Level 2 QoS (Network level) > > Over an IP pipe shared between quality requiring real-time traffic and le= ss > demanding data or streaming (usually TCP) traffic, we have the sharing > between these two traffic classes to consider. The main method (and the > mechanism making today=E2=80=99s real-time QoE as good as it often is) is= that TCP > endpoints back-off and share their bandwidth usage. Real-time traffic usi= ng > UDP transport do not back-off, the endpoints using UDP occupy the bandwid= th > needed. When an IP pipe gets filled, it is all endpoint=E2=80=99s TCP ban= dwidth > usage that is back-off and shared between them, leaving room for the UDP > traffic. This is mechanism we experience everyday over the Internet, usin= g > our =E2=80=9CSurf IP pipes=E2=80=9D. Let=E2=80=99s call this Level 4 QoS = (Transport level) > > However, this Level 4 QoS is based on that at congestion times (which hap= pen > every time we click =E2=80=93 setting up a TCP flow and transferring some= amount of > data as quick as possible) the router handling the most narrow part of th= e > pipe (the congestion point) drop packets. It is this packet dropping that > (i) signals to TCP endpoints to reduce their bandwidth (via TCP=E2=80=99s= error > correction/retransmission mechanism) and (ii) destroys the QoE of real-ti= me > traffic. (Both TCP and UDP packets are dropped in this process that is > triggered by flow intensive TCP traffic.) Um, er, the situation today is one of dramatic overbuffering on everything, triggering packet drop too infrequently, which messes with QoE far worse for much interactive traffic (notably games and VOIP) than drop does. "once you have bad latency you're stuck with it" - http://rescomp.stanford.edu/~cheshire/rants/Latency.html > > We need (i) but don=E2=80=99t want (ii) and to improve on this we can e.g= . use > diffserve, DSCP bits in IP packets to instruct routers to always forward = the > real-time traffic before any unmarked TCP traffic (which usually fills mo= st > of the pipe). Then QoS is then achieved for real-time traffic. This is Le= vel > 3 QoS (IP level). The method used is =E2=80=9Ctraffic shaping=E2=80=9D: b= acking off data > traffic, leaving real-time traffic free passage without packet loss. Well, there are several techniques involved in traffic shaping, and in the end you have to use most of them comprehensively to get good QoE. http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Wed Apr 23 08:47:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2252A1A00CB for ; Wed, 23 Apr 2014 08:47:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 sJOjCRR_2PPf for ; Wed, 23 Apr 2014 08:47:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id CDFFD1A0016 for ; Wed, 23 Apr 2014 08:47:02 -0700 (PDT) Received: from BN1PR07MB357.namprd07.prod.outlook.com (10.141.60.143) by BN1PR07MB359.namprd07.prod.outlook.com (10.141.60.145) with Microsoft SMTP Server (TLS) id 15.0.921.12; Wed, 23 Apr 2014 15:46:55 +0000 Received: from BN1PR07MB357.namprd07.prod.outlook.com ([169.254.6.14]) by BN1PR07MB357.namprd07.prod.outlook.com ([169.254.6.168]) with mapi id 15.00.0918.000; Wed, 23 Apr 2014 15:46:55 +0000 From: Stephan Wenger To: Roman Shpount , Harald Alvestrand Thread-Topic: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? Thread-Index: AQHPXu/o3Bhv29E500+Tvc/+kjdzjJsfTFUA//+W7QA= Date: Wed, 23 Apr 2014 15:46:54 +0000 Message-ID: References: <5357B281.1030900@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(24454002)(51704005)(377454003)(189002)(199002)(86362001)(92566001)(83072002)(92726001)(80976001)(2656002)(76482001)(16236675002)(15975445006)(77982001)(87936001)(85852003)(36756003)(99286001)(31966008)(20776003)(74662001)(79102001)(66066001)(19580395003)(80022001)(19580405001)(74502001)(83322001)(54356999)(76176999)(81342001)(99396002)(46102001)(50986999)(81542001)(4396001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR07MB359; H:BN1PR07MB357.namprd07.prod.outlook.com; FPR:E634D1FC.ABEA53C3.3BD69163.12F4AB60.205F3; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (: stewe.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_CF7D2A6D464A8stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XuqX1BQmP1wsp51eBn7ntZlTTkQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 15:47:09 -0000 --_000_CF7D2A6D464A8stewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please see inline. Stephan From: Roman Shpount > Date: Wednesday, April 23, 2014 at 8:02 To: Harald Alvestrand > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] Pictures of congestion control on the Internet - whic= h is more realistic? I would say that some video end points have congestion back off. Concur. In fact, I would replace "some" with "very few", and I think the s= tatement would still be correct. At least when it comes to the hardware ba= sed solutions, and your typical SIP client. The proprietary soft-clients (= Skype, hangouts, etc.) may be a better in that regard, especially the moder= n ones that use scalability (like ours, brag brag). (One can, of course, a= rgue that at any given moment there are more sessions active using modern s= oft-clients than the combined lifetime sales of all traditional hardware vi= deo conference vendors-and that's why we haven't had a meltdown yet. I att= ribute the lack of a meltdown to other reasons, though.) Almost all audio end points have none. Concur as well. And, I believe the number of bits spent on interactive aud= io over the open Internet is still considerably higher than those for inter= active video. In both cases, the typical reaction of an endpoint is to expose the user to= crappy quality, until the user hangs up. Sometimes, slightly smarter impl= ementations hang up themselves if the packet loss rate becomes excessive.I = would suggest not to paint a rosier picture in the draft than what is warra= nted based on real-world observations. Based on this, most UDP endpoints do not deal well with congestion. Ideally= this should change to support better bandwidth management. Futhermore, rel= iably transmitting real time media over public internet would also require = changes to biffer management algorithms in routers, which will, in turn, af= fect congestion handling strategies in the end points. On Apr 23, 2014 8:31 AM, "Harald Alvestrand" > wrote: > > I quote Karl's piece below, because I want other's opinion of whether it'= s a realistic picture. > > My impression is that it is not - in particular that: > > - Lots of interactive traffic goes over the Internet today without layer = 2 separation > - All UDP endpoints that use the open Internet have some form of backoff = on congestion - using delay, packet drop or (most likely) both to detect co= ngestion > > I'm writing the transport document based on those assumptions - that we s= hould specify something that will work as well as it can over an Internet t= hat does not care, and try to allow for better things to come along later. > > Am I wrong to write it like this? > > Harald > > > > ------------------------------------ > [Karl] I wrote this sometime before, regarding how QoS over the internet > works in general - may be useful for understanding > > For better understanding of these QoS/QoE problems, and methods for > improving (not specifically discussing the policies of sharing real-time > traffic space), I would like to explain: > > Over an IP pipe only used for real-traffic (no TCP data traffic), it is > sufficient that the pipe is wide enough for good QoS. That is often used = and > implemented by separating IP pipes at a lower level using e.g. Ethernet > VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can > enforce real-traffic into such pipes and QoS is achieved. Let's call this > Level 2 QoS (Network level) > > Over an IP pipe shared between quality requiring real-time traffic and le= ss > demanding data or streaming (usually TCP) traffic, we have the sharing > between these two traffic classes to consider. The main method (and the > mechanism making today's real-time QoE as good as it often is) is that TC= P > endpoints back-off and share their bandwidth usage. Real-time traffic usi= ng > UDP transport do not back-off, the endpoints using UDP occupy the bandwid= th > needed. When an IP pipe gets filled, it is all endpoint's TCP bandwidth > usage that is back-off and shared between them, leaving room for the UDP > traffic. This is mechanism we experience everyday over the Internet, usin= g > our "Surf IP pipes". Let's call this Level 4 QoS (Transport level) > > However, this Level 4 QoS is based on that at congestion times (which hap= pen > every time we click - setting up a TCP flow and transferring some amount = of > data as quick as possible) the router handling the most narrow part of th= e > pipe (the congestion point) drop packets. It is this packet dropping that > (i) signals to TCP endpoints to reduce their bandwidth (via TCP's error > correction/retransmission mechanism) and (ii) destroys the QoE of real-ti= me > traffic. (Both TCP and UDP packets are dropped in this process that is > triggered by flow intensive TCP traffic.) > > We need (i) but don't want (ii) and to improve on this we can e.g. use > diffserve, DSCP bits in IP packets to instruct routers to always forward = the > real-time traffic before any unmarked TCP traffic (which usually fills mo= st > of the pipe). Then QoS is then achieved for real-time traffic. This is Le= vel > 3 QoS (IP level). The method used is "traffic shaping": backing off data > traffic, leaving real-time traffic free passage without packet loss. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --_000_CF7D2A6D464A8stewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <74C110D3DDA1724594D2D3EF03C81A31@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,
Please see inline.
Stephan

From: Roman Shpount <roman@telurix.com>
Date: Wednesday, April 23, 2014 at = 8:02
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: Re: [rtcweb] Pictures of c= ongestion control on the Internet - which is more realistic?

I would say that some video end points have congestion back = off. 

Concur.  In fact, I would replace “some” with “= very few”, and I think the statement would still be correct.  At= least when it comes to the hardware based solutions, and your typical SIP = client.  The proprietary soft-clients (Skype, hangouts, etc.) may be a better in that regard, especially the modern ones that use scalabilit= y (like ours, brag brag).  (One can, of course, argue that at any give= n moment there are more sessions active using modern soft-clients than the = combined lifetime sales of all traditional hardware video conference vendors—and that’s why we haven̵= 7;t had a meltdown yet.  I attribute the lack of a meltdown to other r= easons, though.) 

Almost all audio end points have none.

Concur as well.  And, I believe the number of bits spent on inter= active audio over the open Internet is still considerably higher than those= for interactive video.

In both cases, the typical reaction of an endpoint is to expose the us= er to crappy quality, until the user hangs up.  Sometimes, slightly sm= arter implementations hang up themselves if the packet loss rate becomes ex= cessive.I would suggest not to paint a rosier picture in the draft than what is warranted based on real-world o= bservations.  

Based on this, most UDP endpoints do not deal well with cong= estion. Ideally this should change to support better bandwidth management. = Futhermore, reliably transmitting real time media over public internet woul= d also require changes to biffer management algorithms in routers, which will, in turn, affect congestion handling str= ategies in the end points.

On Apr 23, 2014 8:31 AM, "Harald Alvestrand" <<= a href=3D"mailto:harald@alvestrand.no">harald@alvestrand.no> wrote:<= br> >
> I quote Karl's piece below, because I want other's opinion of whether = it's a realistic picture.
>
> My impression is that it is not - in particular that:
>
> - Lots of interactive traffic goes over the Internet today without lay= er 2 separation
> - All UDP endpoints that use the open Internet have some form of backo= ff on congestion - using delay, packet drop or (most likely) both to detect= congestion
>
> I'm writing the transport document based on those assumptions - that w= e should specify something that will work as well as it can over an Interne= t that does not care, and try to allow for better things to come along late= r.
>
> Am I wrong to write it like this?
>
> Harald
>
>
>
> ------------------------------------
> [Karl] I wrote this sometime before, regarding how QoS over the intern= et
> works in general - may be useful for understanding
>
> For better understanding of these QoS/QoE problems, and methods for > improving (not specifically discussing the policies of sharing real-ti= me
> traffic space), I would like to explain:
>
> Over an IP pipe only used for real-traffic (no TCP data traffic), it i= s
> sufficient that the pipe is wide enough for good QoS. That is often us= ed and
> implemented by separating IP pipes at a lower level using e.g. Etherne= t
> VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can<= br> > enforce real-traffic into such pipes and QoS is achieved. Let’s = call this
> Level 2 QoS (Network level)
>
> Over an IP pipe shared between quality requiring real-time traffic and= less
> demanding data or streaming (usually TCP) traffic, we have the sharing=
> between these two traffic classes to consider. The main method (and th= e
> mechanism making today’s real-time QoE as good as it often is) i= s that TCP
> endpoints back-off and share their bandwidth usage. Real-time traffic = using
> UDP transport do not back-off, the endpoints using UDP occupy the band= width
> needed. When an IP pipe gets filled, it is all endpoint’s TCP ba= ndwidth
> usage that is back-off and shared between them, leaving room for the U= DP
> traffic. This is mechanism we experience everyday over the Internet, u= sing
> our “Surf IP pipes”. Let’s call this Level 4 QoS (Tr= ansport level)
>
> However, this Level 4 QoS is based on that at congestion times (which = happen
> every time we click – setting up a TCP flow and transferring som= e amount of
> data as quick as possible) the router handling the most narrow part of= the
> pipe (the congestion point) drop packets. It is this packet dropping t= hat
> (i) signals to TCP endpoints to reduce their bandwidth (via TCP’= s error
> correction/retransmission mechanism) and (ii) destroys the QoE of real= -time
> traffic. (Both TCP and UDP packets are dropped in this process that is=
> triggered by flow intensive TCP traffic.)
>
> We need (i) but don’t want (ii) and to improve on this we can e.= g. use
> diffserve, DSCP bits in IP packets to instruct routers to always forwa= rd the
> real-time traffic before any unmarked TCP traffic (which usually fills= most
> of the pipe). Then QoS is then achieved for real-time traffic. This is= Level
> 3 QoS (IP level). The method used is “traffic shaping”: ba= cking off data
> traffic, leaving real-time traffic free passage without packet loss. >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

 --_000_CF7D2A6D464A8stewesteweorg_-- From nobody Wed Apr 23 09:25:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE861A037F for ; Wed, 23 Apr 2014 09:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 5kH8h9vEUuwc for ; Wed, 23 Apr 2014 09:25:36 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id DBB111A02A8 for ; Wed, 23 Apr 2014 09:25:35 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so1103258wes.9 for ; Wed, 23 Apr 2014 09:25:29 -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:content-type; bh=dCGfkrmBX59mumr23fwBW2GuBRrGut2fAZioT9KoeaI=; b=DX/Ck6wIOsEEz/PvgRf9W5PJeCIN2VXx88qpfpUHl2XiBHK13nilZMt4dJAZ1nLHPb 2812JCdLVeeFqUnsgRyzJcEFJmULYFWhhzSc/zJ+RHemk4dKmMOxd5gZxumwviMvrKB9 Cb6Mc+3hXB++De5tO+kcjEQ7aSt1oamxtbS/VhN70gDswZt2nuSSFSqQhBUN22wd1lyy l949KzIBUpEx/dmnBIAkwjIsGU8Ue8FxZ8M2W/u+jNi2b1suY//Z1un0RfxwOqVBuDAc Wg7GD0tAmKsCQ9qIi6Mm0HPqF9KcRGOqskvBl65gQJHQA25bgglLAlFElzkZutpoCx+5 iowA== MIME-Version: 1.0 X-Received: by 10.194.77.148 with SMTP id s20mr7153820wjw.31.1398270329683; Wed, 23 Apr 2014 09:25:29 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 23 Apr 2014 09:25:29 -0700 (PDT) In-Reply-To: <5357B281.1030900@alvestrand.no> References: <5357B281.1030900@alvestrand.no> Date: Wed, 23 Apr 2014 09:25:29 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TQN4by7znUZm3xqd6mP2DRZPnok Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:25:37 -0000 On 23 April 2014 05:30, Harald Alvestrand wrote: > - All UDP endpoints that use the open Internet have some form of backoff on > congestion - using delay, packet drop or (most likely) both to detect > congestion There's some evidence that this is true, but we wouldn't have RMCAT if it weren't for the fact that there was pretty wide consensus that it's not good enough. Maybe the vendors of those soft video clients Stephan mentions are confident that they have the answer, I don't know. From nobody Wed Apr 23 09:37:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F601A0348 for ; Wed, 23 Apr 2014 09:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 OK76keK_v_RV for ; Wed, 23 Apr 2014 09:37:25 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 11C051A0221 for ; Wed, 23 Apr 2014 09:37:25 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 332AEC94BD; Wed, 23 Apr 2014 12:37:17 -0400 (EDT) Date: Wed, 23 Apr 2014 12:37:17 -0400 From: John Leslie To: Dave Taht Message-ID: <20140423163717.GG86778@verdi> References: <5357B281.1030900@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Un36hfo-IM76hbLe7hM0RXw1_gk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:37:27 -0000 Dave Taht wrote: > > I'm not sure if we have a shared definition of "congestion". Mine is > network delays exceeding that of what human factors research notes > as "perceptible" with about 20ms as the outer bound. I, OTOH, am quite sure we don't have a shared definition of congestion. My preferred definition is rate-of-arrival exceeding rate-of-forwarding. But, of course, you don't have to agree with mine -- "shared" merely implies _some_ overlap of the sets of definitions we use... Dave's, I fear, isn't terribly useful. There is a base latency (in the absence of any traffic) which exceeds 20 milliseconds for many paths of interest. To tell truth, though, most users probably only notice the total delay, not the components of it; so I think Dave's metric is useful -- it's just not helpful as a measure of "congestion". I'd like to follow up a bit on Dave's metric, regardless. There's a lot of talk about "buffer-bloat" where I believe we all agree the situation would be better with less buffering. But can we talk about the other end of that spectrum? Surely there is some minimal amount of buffering, for any particular traffic, which is needed in order to maintain a reasonable flow rate. Most likely, that minimal buffering varies with factors such as RTT. Do we even have a shared concept of what those factors are? I'd like to see a thread on what is needed as a minimum buffering for various kinds of traffic. I suspect that minimum can be fairly small except for TCP transport of "large" files... > http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/ Excellent as food for thought... -- John Leslie From nobody Wed Apr 23 10:16:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233AD1A0389 for ; Wed, 23 Apr 2014 10:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 sDa4e5Sk-A0z for ; Wed, 23 Apr 2014 10:16:41 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC231A021F for ; Wed, 23 Apr 2014 10:16:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 27E0F7C53A2; Wed, 23 Apr 2014 19:16:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTUGucaog+g4; Wed, 23 Apr 2014 19:16:33 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0ACD87C5397; Wed, 23 Apr 2014 19:16:33 +0200 (CEST) Message-ID: <5357F56F.8080606@alvestrand.no> Date: Wed, 23 Apr 2014 19:16:31 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John Leslie , Dave Taht References: <5357B281.1030900@alvestrand.no> <20140423163717.GG86778@verdi> In-Reply-To: <20140423163717.GG86778@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Qh5cINDSXXKvVxBpy2uLpeB_I-k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 17:16:45 -0000 Would that be a good discussion to have on the rmcat list? I hear they're close to finishing their requirements and test methodology documents..... On 04/23/2014 06:37 PM, John Leslie wrote: > Dave Taht wrote: >> I'm not sure if we have a shared definition of "congestion". Mine is >> network delays exceeding that of what human factors research notes >> as "perceptible" with about 20ms as the outer bound. > I, OTOH, am quite sure we don't have a shared definition of congestion. > > My preferred definition is rate-of-arrival exceeding rate-of-forwarding. > > But, of course, you don't have to agree with mine -- "shared" merely > implies _some_ overlap of the sets of definitions we use... > > Dave's, I fear, isn't terribly useful. There is a base latency (in the > absence of any traffic) which exceeds 20 milliseconds for many paths > of interest. > > To tell truth, though, most users probably only notice the total delay, > not the components of it; so I think Dave's metric is useful -- it's just > not helpful as a measure of "congestion". > > I'd like to follow up a bit on Dave's metric, regardless. > > There's a lot of talk about "buffer-bloat" where I believe we all > agree the situation would be better with less buffering. > > But can we talk about the other end of that spectrum? > > Surely there is some minimal amount of buffering, for any particular > traffic, which is needed in order to maintain a reasonable flow rate. > Most likely, that minimal buffering varies with factors such as RTT. Do > we even have a shared concept of what those factors are? > > I'd like to see a thread on what is needed as a minimum buffering > for various kinds of traffic. I suspect that minimum can be fairly small > except for TCP transport of "large" files... > >> http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/ > Excellent as food for thought... > > -- > John Leslie From nobody Wed Apr 23 14:37:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B41C1A06C4 for ; Wed, 23 Apr 2014 14:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 ej4ih-Oz0HVi for ; Wed, 23 Apr 2014 14:37:03 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id B6C221A0686 for ; Wed, 23 Apr 2014 14:37:01 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404232336539104; Wed, 23 Apr 2014 23:36:53 +0200 From: "Karl Stahl" To: "'Harald Alvestrand'" , References: <5357B281.1030900@alvestrand.no> In-Reply-To: <5357B281.1030900@alvestrand.no> Date: Wed, 23 Apr 2014 23:36:57 +0200 Message-ID: <011601cf5f3c$26fe7300$74fb5900$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9e7+k45pdCiAbkRSSC4/xnQQ6WlgAQACLw Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PQvltAAQr74xTQGjlQeeGEB2a_0 Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 21:37:05 -0000 -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Harald Alvestrand Skickat: den 23 april 2014 14:31 Till: rtcweb@ietf.org =C4mne: [rtcweb] Pictures of congestion control on the Internet - which = is more realistic? I quote Karl's piece below, because I want other's opinion of whether = it's a realistic picture. My impression is that it is not - in particular that: - Lots of interactive traffic goes over the Internet today without layer = 2 separation [Karl] I am NOT for more level 2 separation (was describing it though) - = we are on the level 3 Internet! We can do equally well with level 3 QoS (diffserve and reservation, but for that we need the traffic info in = each packet, unchanged end-to-end, so network elements can act upon it.) [Karl] Today we mostly only have level 4 QoS over the Internet. We need level 3 QoS for WebRTC.=20 - All UDP endpoints that use the open Internet have some form of backoff = on congestion - using delay, packet drop or (most likely) both to detect congestion [Karl] Unfortunately that is not very effective. With level 4 QoS, UDP backing off means that TCP flows take that bandwidth instead (today's Internet traffic is very TCP-flow intensive), and the congestion is back again. (Had we level 3 QoS, and starting to fill the whole pipe with priority data, then priority data backing off would be effective. = Otherwise, the improvement is small, if any.)=20 I'm writing the transport document based on those assumptions - that we should specify something that will work as well as it can over an = Internet that does not care, and try to allow for better things to come along = later. [Karl] Two things to address for achieving that: 1. Doing file transfer in the data channel bundled with real-time = traffic in the same flow/5-tuple, destroys the level 4 QoS we already have over the Internet. Getting file transfer out of the bundle restores that. SCTP's = prio mechanism cannot restore that when the congestion is in the network = (only when in the endpoints)=20 2). To "try to allow for better things to come along" we need the = traffic info (bandwidth requirement and traffic type) in every priority packet, readable at the network level, unchanged end-to-end. Then network = elements can be programmed to act upon that traffic info to give us level 3 QoS. (When routing, the priority packets are simply put first in the out = queue, i.e. never dropped, but TCP file transfer flows will have packets = discarded and be backed off. Reservation type of networks will have to do some calculations also.) It is easy to put in that traffic info now - very difficult to do it later. Am I wrong to write it like this? Harald ------------------------------------ [Karl] I wrote this sometime before, regarding how QoS over the internet works in general - may be useful for understanding For better understanding of these QoS/QoE problems, and methods for improving (not specifically discussing the policies of sharing real-time traffic space), I would like to explain: Over an IP pipe only used for real-traffic (no TCP data traffic), it is sufficient that the pipe is wide enough for good QoS. That is often used = and implemented by separating IP pipes at a lower level using e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can enforce real-traffic into such pipes and QoS is achieved. Let=92s call = this Level 2 QoS (Network level) Over an IP pipe shared between quality requiring real-time traffic and = less demanding data or streaming (usually TCP) traffic, we have the sharing between these two traffic classes to consider. The main method (and the mechanism making today=92s real-time QoE as good as it often is) is that = TCP endpoints back-off and share their bandwidth usage. Real-time traffic = using UDP transport do not back-off, the endpoints using UDP occupy the = bandwidth needed. When an IP pipe gets filled, it is all endpoint=92s TCP = bandwidth usage that is back-off and shared between them, leaving room for the UDP traffic. This is mechanism we experience everyday over the Internet, = using our =93Surf IP pipes=94. Let=92s call this Level 4 QoS (Transport level) However, this Level 4 QoS is based on that at congestion times (which = happen every time we click =96 setting up a TCP flow and transferring some = amount of data as quick as possible) the router handling the most narrow part of = the pipe (the congestion point) drop packets. It is this packet dropping = that (i) signals to TCP endpoints to reduce their bandwidth (via TCP=92s = error correction/retransmission mechanism) and (ii) destroys the QoE of = real-time traffic. (Both TCP and UDP packets are dropped in this process that is triggered by flow intensive TCP traffic.) We need (i) but don=92t want (ii) and to improve on this we can e.g. use diffserve, DSCP bits in IP packets to instruct routers to always forward = the real-time traffic before any unmarked TCP traffic (which usually fills = most of the pipe). Then QoS is then achieved for real-time traffic. This is = Level 3 QoS (IP level). The method used is =93traffic shaping=94: backing off = data traffic, leaving real-time traffic free passage without packet loss. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Apr 23 14:37:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803831A06C8 for ; Wed, 23 Apr 2014 14:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 9mr3MrxI1m4R for ; Wed, 23 Apr 2014 14:37:43 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id BB1E71A069F for ; Wed, 23 Apr 2014 14:37:42 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404232337349137; Wed, 23 Apr 2014 23:37:34 +0200 From: "Karl Stahl" To: "'Stephan Wenger'" , "'Roman Shpount'" , "'Harald Alvestrand'" References: <5357B281.1030900@alvestrand.no> In-Reply-To: Date: Wed, 23 Apr 2014 23:37:38 +0200 Message-ID: <011701cf5f3c$3fafb530$bf0f1f90$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0118_01CF5F4D.03388530" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPXu/o3Bhv29E500+Tvc/+kjdzjJsfTFUA//+W7QCAAM7+cA== Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/73lajIvDeTCl0yxy3QYSKaMRrxo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 21:37:48 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0118_01CF5F4D.03388530 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think real-time media backing-off is rarely used, because it is seldom efficient. As long as we rely on level 4 QoS, the freed bandwidth is = simply taken by flow intensive TCP file transfer traffic and congestion is back again. > Futhermore, reliably transmitting real time media over public internet would also require changes to biffer management algorithms in routers=85 --- Yes, need to be done in the routers =96 endpoints cannot simply do = it alone. And routers need to know what to prioritize or reserve for: We need the traffic info (bandwidth requirement and traffic type) in each RTP or = data channel priority packet, readable by the network and unchanged = end-to-end over the Internet [1] [2]. =20 /Karl =20 [1] Traffic type information to encode (recreating the=20 idea/intention of the RTP payload type (PT) byte that is not=20 available for the network layer anymore, by instead having the=20 browser filling the RTP header extension with relevant traffic=20 info that all IP network types can use.).Two parameters to encode=20 (Bandwidth and traffic type) http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html=20 this draft should be filled for use with WebRTC:=20 http://tools.ietf.org/html/draft-carlberg-avtext-classifier-01 =20 [2] For the WebRTC data channel, the traffic info could be inserted as=20 suggested (in the same format as in the RTP header extension):=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973.html =20 =20 =20 Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Stephan Wenger Skickat: den 23 april 2014 17:47 Till: Roman Shpount; Harald Alvestrand Kopia: rtcweb@ietf.org =C4mne: Re: [rtcweb] Pictures of congestion control on the Internet - = which is more realistic? =20 Hi, Please see inline. Stephan =20 From: Roman Shpount Date: Wednesday, April 23, 2014 at 8:02 To: Harald Alvestrand Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Pictures of congestion control on the Internet - = which is more realistic? =20 I would say that some video end points have congestion back off. =20 Concur. In fact, I would replace =93some=94 with =93very few=94, and I = think the statement would still be correct. At least when it comes to the = hardware based solutions, and your typical SIP client. The proprietary = soft-clients (Skype, hangouts, etc.) may be a better in that regard, especially the modern ones that use scalability (like ours, brag brag). (One can, of course, argue that at any given moment there are more sessions active = using modern soft-clients than the combined lifetime sales of all traditional hardware video conference vendors=97and that=92s why we haven=92t had a = meltdown yet. I attribute the lack of a meltdown to other reasons, though.)=20 Almost all audio end points have none.=20 Concur as well. And, I believe the number of bits spent on interactive audio over the open Internet is still considerably higher than those for interactive video. =20 In both cases, the typical reaction of an endpoint is to expose the user = to crappy quality, until the user hangs up. Sometimes, slightly smarter implementations hang up themselves if the packet loss rate becomes excessive.I would suggest not to paint a rosier picture in the draft = than what is warranted based on real-world observations. =20 Based on this, most UDP endpoints do not deal well with congestion. = Ideally this should change to support better bandwidth management. Futhermore, reliably transmitting real time media over public internet would also require changes to biffer management algorithms in routers, which will, = in turn, affect congestion handling strategies in the end points. On Apr 23, 2014 8:31 AM, "Harald Alvestrand" = wrote: > > I quote Karl's piece below, because I want other's opinion of whether = it's a realistic picture. > > My impression is that it is not - in particular that: > > - Lots of interactive traffic goes over the Internet today without = layer 2 separation > - All UDP endpoints that use the open Internet have some form of = backoff on congestion - using delay, packet drop or (most likely) both to detect congestion > > I'm writing the transport document based on those assumptions - that = we should specify something that will work as well as it can over an = Internet that does not care, and try to allow for better things to come along = later. > > Am I wrong to write it like this? > > Harald > > > > ------------------------------------ > [Karl] I wrote this sometime before, regarding how QoS over the = internet > works in general - may be useful for understanding > > For better understanding of these QoS/QoE problems, and methods for > improving (not specifically discussing the policies of sharing = real-time > traffic space), I would like to explain: > > Over an IP pipe only used for real-traffic (no TCP data traffic), it = is > sufficient that the pipe is wide enough for good QoS. That is often = used and > implemented by separating IP pipes at a lower level using e.g. = Ethernet > VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can > enforce real-traffic into such pipes and QoS is achieved. Let=92s call = this > Level 2 QoS (Network level) > > Over an IP pipe shared between quality requiring real-time traffic and less > demanding data or streaming (usually TCP) traffic, we have the sharing > between these two traffic classes to consider. The main method (and = the > mechanism making today=92s real-time QoE as good as it often is) is = that TCP > endpoints back-off and share their bandwidth usage. Real-time traffic using > UDP transport do not back-off, the endpoints using UDP occupy the bandwidth > needed. When an IP pipe gets filled, it is all endpoint=92s TCP = bandwidth > usage that is back-off and shared between them, leaving room for the = UDP > traffic. This is mechanism we experience everyday over the Internet, = using > our =93Surf IP pipes=94. Let=92s call this Level 4 QoS (Transport = level) > > However, this Level 4 QoS is based on that at congestion times (which happen > every time we click =96 setting up a TCP flow and transferring some = amount of > data as quick as possible) the router handling the most narrow part of = the > pipe (the congestion point) drop packets. It is this packet dropping = that > (i) signals to TCP endpoints to reduce their bandwidth (via TCP=92s = error > correction/retransmission mechanism) and (ii) destroys the QoE of real-time > traffic. (Both TCP and UDP packets are dropped in this process that is > triggered by flow intensive TCP traffic.) > > We need (i) but don=92t want (ii) and to improve on this we can e.g. = use > diffserve, DSCP bits in IP packets to instruct routers to always = forward the > real-time traffic before any unmarked TCP traffic (which usually fills most > of the pipe). Then QoS is then achieved for real-time traffic. This is Level > 3 QoS (IP level). The method used is =93traffic shaping=94: backing = off data > traffic, leaving real-time traffic free passage without packet loss. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_000_0118_01CF5F4D.03388530 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I = think real-time media backing-off is rarely used, because it is seldom = efficient. As long as we rely on level 4 QoS, the freed bandwidth is = simply taken by flow intensive TCP file transfer traffic and congestion = is back again.

> = Futhermore, reliably transmitting real time media over public internet = would also require changes to biffer management algorithms in = routers…

--- Yes, need = to be done in the routers – endpoints cannot simply do it = alone.

And routers = need to know what to prioritize or reserve for: We need the traffic info = (bandwidth requirement and traffic type) in each RTP or data channel = priority packet, readable by the network and unchanged end-to-end over = the Internet [1] [2].

 

/Karl=

 

[1] Traffic type information to = encode (recreating the

idea/intention of the RTP = payload type (PT) byte that is not

available for the network layer = anymore, by instead having the

browser filling the RTP header = extension with relevant traffic

info that all IP network types = can use.).Two parameters to encode

(Bandwidth and traffic = type)

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129= .html

this draft should be filled for = use with WebRTC:

h= ttp://tools.ietf.org/html/draft-carlberg-avtext-classifier-01

 

[2] For the WebRTC data channel, the traffic info could be = inserted as

suggested (in the same format as in the RTP header = extension):

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11973= .html 

 

 

Fr=E5n: rtcweb = [mailto:rtcweb-bounces@ietf.org] F=F6r Stephan = Wenger
Skickat: den 23 april 2014 17:47
Till: Roman = Shpount; Harald Alvestrand
Kopia: = rtcweb@ietf.org
=C4mne: Re: [rtcweb] Pictures of congestion = control on the Internet - which is more = realistic?

 

Hi,

Please see inline.

Stephan

 

From: Roman Shpount <roman@telurix.com>
Date: = Wednesday, April 23, 2014 at 8:02
To: Harald Alvestrand = <harald@alvestrand.no>
C= c: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: = Re: [rtcweb] Pictures of congestion control on the Internet - which = is more realistic?

 

I would say that some video end points have congestion back off.  =

Concur.  In fact, I would replace “some” with = “very few”, and I think the statement would still be = correct.  At least when it comes to the hardware based solutions, = and your typical SIP client.  The proprietary soft-clients (Skype, = hangouts, etc.) may be a better in that regard, especially the modern = ones that use scalability (like ours, brag brag).  (One can, of = course, argue that at any given moment there are more sessions active = using modern soft-clients than the combined lifetime sales of all = traditional hardware video conference vendors—and that’s why = we haven’t had a meltdown yet.  I attribute the lack of a = meltdown to other reasons, = though.) 

Almost all audio end points have none. =

Concur as well.  And, I believe the number of bits spent on = interactive audio over the open Internet is still considerably higher = than those for interactive video.

 

In both cases, the typical reaction of an endpoint is to expose the = user to crappy quality, until the user hangs up.  Sometimes, = slightly smarter implementations hang up themselves if the packet loss = rate becomes excessive.I would suggest not to paint a rosier picture in = the draft than what is warranted based on real-world observations. =  

Based on this, most UDP endpoints do not deal well with congestion. = Ideally this should change to support better bandwidth management. = Futhermore, reliably transmitting real time media over public internet = would also require changes to biffer management algorithms in routers, = which will, in turn, affect congestion handling strategies in the end = points.

On Apr 23, 2014 8:31 AM, "Harald Alvestrand" <harald@alvestrand.no> = wrote:
>
> I quote Karl's piece below, because I want = other's opinion of whether it's a realistic picture.
>
> My = impression is that it is not - in particular that:
>
> - = Lots of interactive traffic goes over the Internet today without layer 2 = separation
> - All UDP endpoints that use the open Internet have = some form of backoff on congestion - using delay, packet drop or (most = likely) both to detect congestion
>
> I'm writing the = transport document based on those assumptions - that we should specify = something that will work as well as it can over an Internet that does = not care, and try to allow for better things to come along = later.
>
> Am I wrong to write it like this?
>
> = Harald
>
>
>
> = ------------------------------------
> [Karl] I wrote this = sometime before, regarding how QoS over the internet
> works in = general - may be useful for understanding
>
> For better = understanding of these QoS/QoE problems, and methods for
> = improving (not specifically discussing the policies of sharing = real-time
> traffic space), I would like to = explain:
>
> Over an IP pipe only used for real-traffic (no = TCP data traffic), it is
> sufficient that the pipe is wide enough = for good QoS. That is often used and
> implemented by separating = IP pipes at a lower level using e.g. Ethernet
> VLAN, MPLS, = Ethernet over ATM (std for ADSL modems). TURN servers can
> = enforce real-traffic into such pipes and QoS is achieved. Let’s = call this
> Level 2 QoS (Network level)
>
> Over an IP = pipe shared between quality requiring real-time traffic and less
> = demanding data or streaming (usually TCP) traffic, we have the = sharing
> between these two traffic classes to consider. The main = method (and the
> mechanism making today’s real-time QoE as = good as it often is) is that TCP
> endpoints back-off and share = their bandwidth usage. Real-time traffic using
> UDP transport do = not back-off, the endpoints using UDP occupy the bandwidth
> = needed. When an IP pipe gets filled, it is all endpoint’s TCP = bandwidth
> usage that is back-off and shared between them, = leaving room for the UDP
> traffic. This is mechanism we = experience everyday over the Internet, using
> our “Surf IP = pipes”. Let’s call this Level 4 QoS (Transport = level)
>
> However, this Level 4 QoS is based on that at = congestion times (which happen
> every time we click – = setting up a TCP flow and transferring some amount of
> data as = quick as possible) the router handling the most narrow part of = the
> pipe (the congestion point) drop packets. It is this packet = dropping that
> (i) signals to TCP endpoints to reduce their = bandwidth (via TCP’s error
> correction/retransmission = mechanism) and (ii) destroys the QoE of real-time
> traffic. (Both = TCP and UDP packets are dropped in this process that is
> = triggered by flow intensive TCP traffic.)
>
> We need (i) = but don’t want (ii) and to improve on this we can e.g. use
> = diffserve, DSCP bits in IP packets to instruct routers to always forward = the
> real-time traffic before any unmarked TCP traffic (which = usually fills most
> of the pipe). Then QoS is then achieved for = real-time traffic. This is Level
> 3 QoS (IP level). The method = used is “traffic shaping”: backing off data
> traffic, = leaving real-time traffic free passage without packet = loss.
>
> = _______________________________________________
> rtcweb mailing = list
> rtcweb@ietf.org
> https://www.ietf.or= g/mailman/listinfo/rtcweb

------=_NextPart_000_0118_01CF5F4D.03388530-- From nobody Thu Apr 24 02:56:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E3E1A07FC for ; Thu, 24 Apr 2014 02:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 KQ19_iAlwqzg for ; Thu, 24 Apr 2014 02:56:44 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C9C0A1A07F9 for ; Thu, 24 Apr 2014 02:56:43 -0700 (PDT) X-AuditID: c1b4fb25-f798a6d000005ede-dd-5358dfd596ad Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2B.98.24286.5DFD8535; Thu, 24 Apr 2014 11:56:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Thu, 24 Apr 2014 11:56:36 +0200 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? Thread-Index: AQHPXu/madRJFOb1bEmdMyYxHp0vgw== Date: Thu, 24 Apr 2014 09:56:36 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CFD9001@ESESSMB209.ericsson.se> References: <5357B281.1030900@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje7V+xHBBhNeiVkc6+tis1j7r53d gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4uOIJe8EupYrpHzayNTDOluli5OSQEDCR WPFvHguELSZx4d56ti5GLg4hgaOMEi+/fmCFcJYwSmye/Agow8HBJhAs0fTXDaRBBMjsff6e EcQWFkiU+Nzwlx0iniTx7cZBNghbT6Lx41Uwm0VAVeLv/51g9bwCvhIfru4HqxcS0JGYtHUe K4jNCHTE91NrmEBsZgFxiVtP5jNBHCcgsWTPeWYIW1Ti5eN/rBC2okT70wZGiHoDiffn5jND 2NoSyxa+ZobYJShxcuYTlgmMIrOQjJ2FpGUWkpZZSFoWMLKsYhQtTi1Oyk03MtZLLcpMLi7O z9PLSy3ZxAiMh4NbfqvuYLz8xvEQowAHoxIPL5uaX7AQa2JZcWXuIUZpDhYlcd4vt3yChQTS E0tSs1NTC1KL4otKc1KLDzEycXBKNTDyNi+6Zz5Z5YrkT5f8tJv5Ycuqe2+vjLhjy7XUWqGR +33fl5RGl7oe4wV105UefX3oplNxYOEel8rAPOPczCvfQt0ilk+eMvOciArf3KWtV/ZW6NeZ 7H+5UczadoOg9s0FHBrVF/YVcoqIZMs32t2S/af9ooR54vIJoe0O89O3Hl+c8rN+4VUlluKM REMt5qLiRAB0+uhCaAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lwS3ucGQ2Z07XBkeDqqxuDHenec Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 09:56:46 -0000 On 2014-04-23 14:31, Harald Alvestrand wrote:=0A= > I quote Karl's piece below, because I want other's opinion of whether=0A= > it's a realistic picture.=0A= >=0A= > My impression is that it is not - in particular that:=0A= >=0A= > - Lots of interactive traffic goes over the Internet today without=0A= > layer 2 separation - All UDP endpoints that use the open Internet=0A= > have some form of backoff on congestion - using delay, packet drop or=0A= > (most likely) both to detect congestion=0A= >=0A= > I'm writing the transport document based on those assumptions - that=0A= > we should specify something that will work as well as it can over an=0A= > Internet that does not care, and try to allow for better things to=0A= > come along later.=0A= >=0A= > Am I wrong to write it like this?=0A= =0A= My impression (I have no facts, so I can be completely wrong; it would =0A= be nice if someone could show figures) is that most UDP traffic on the =0A= internet comes from modern (SW implementations) audiovisual =0A= communication, from torrent traffic and from other special transport =0A= built on top of UDP (quic is one example, but there are other used by =0A= e.g. games). I think all of them back off, so I think you are right.=0A= =0A= There is some older stuff that do not back off, but does it really =0A= generate enough traffic to be relevant?=0A= =0A= >=0A= > Harald=0A= >=0A= >=0A= >=0A= > ------------------------------------ [Karl] I wrote this sometime=0A= > before, regarding how QoS over the internet works in general - may be=0A= > useful for understanding=0A= >=0A= > For better understanding of these QoS/QoE problems, and methods for=0A= > improving (not specifically discussing the policies of sharing=0A= > real-time traffic space), I would like to explain:=0A= >=0A= > Over an IP pipe only used for real-traffic (no TCP data traffic), it=0A= > is sufficient that the pipe is wide enough for good QoS. That is=0A= > often used and implemented by separating IP pipes at a lower level=0A= > using e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std for ADSL=0A= > modems). TURN servers can enforce real-traffic into such pipes and=0A= > QoS is achieved. Let=92s call this Level 2 QoS (Network level)=0A= >=0A= > Over an IP pipe shared between quality requiring real-time traffic=0A= > and less demanding data or streaming (usually TCP) traffic, we have=0A= > the sharing between these two traffic classes to consider. The main=0A= > method (and the mechanism making today=92s real-time QoE as good as it=0A= > often is) is that TCP endpoints back-off and share their bandwidth=0A= > usage. Real-time traffic using UDP transport do not back-off, the=0A= > endpoints using UDP occupy the bandwidth needed. When an IP pipe gets=0A= > filled, it is all endpoint=92s TCP bandwidth usage that is back-off and= =0A= > shared between them, leaving room for the UDP traffic. This is=0A= > mechanism we experience everyday over the Internet, using our =93Surf=0A= > IP pipes=94. Let=92s call this Level 4 QoS (Transport level)=0A= >=0A= > However, this Level 4 QoS is based on that at congestion times (which=0A= > happen every time we click =96 setting up a TCP flow and transferring=0A= > some amount of data as quick as possible) the router handling the=0A= > most narrow part of the pipe (the congestion point) drop packets. It=0A= > is this packet dropping that (i) signals to TCP endpoints to reduce=0A= > their bandwidth (via TCP=92s error correction/retransmission mechanism)= =0A= > and (ii) destroys the QoE of real-time traffic. (Both TCP and UDP=0A= > packets are dropped in this process that is triggered by flow=0A= > intensive TCP traffic.)=0A= >=0A= > We need (i) but don=92t want (ii) and to improve on this we can e.g.=0A= > use diffserve, DSCP bits in IP packets to instruct routers to always=0A= > forward the real-time traffic before any unmarked TCP traffic (which=0A= > usually fills most of the pipe). Then QoS is then achieved for=0A= > real-time traffic. This is Level 3 QoS (IP level). The method used is=0A= > =93traffic shaping=94: backing off data traffic, leaving real-time=0A= > traffic free passage without packet loss.=0A= >=0A= > _______________________________________________ rtcweb mailing list=0A= > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From nobody Thu Apr 24 04:04:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659181A0176 for ; Thu, 24 Apr 2014 04:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 L3XwkURIIsTr for ; Thu, 24 Apr 2014 04:04:38 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id C36461A017B for ; Thu, 24 Apr 2014 04:04:37 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WdHSA-0003h1-0z; Thu, 24 Apr 2014 13:04:30 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WdHS9-0006c0-JW; Thu, 24 Apr 2014 13:04:29 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <20140423163717.GG86778@verdi> Date: Thu, 24 Apr 2014 13:04:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E4B3960-4AA1-4F20-A46F-913E143AA18A@ifi.uio.no> References: <5357B281.1030900@alvestrand.no> <20140423163717.GG86778@verdi> To: John Leslie X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 15662 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 09113F87B410D80791460587E0DC905AE27BDC42 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 5082 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gTfbznJdlCYiPsB0tk3275Yhv2c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:04:41 -0000 On 23. apr. 2014, at 18:37, John Leslie wrote: > Dave Taht wrote: >>=20 >> I'm not sure if we have a shared definition of "congestion". Mine is >> network delays exceeding that of what human factors research notes >> as "perceptible" with about 20ms as the outer bound. >=20 > I, OTOH, am quite sure we don't have a shared definition of = congestion. >=20 > My preferred definition is rate-of-arrival exceeding = rate-of-forwarding. FWIW, there's RFC 6077, which discusses definitions of congestion and = congestion control in its introduction. It says: " Congestion can be defined as a state or condition that occurs when network resources are overloaded, resulting in impairments for network users as objectively measured by the probability of loss and/or delay. The overload results in the reduction of utility in networks that support both spatial and temporal multiplexing, but no reservation" which is based on a presentation by Keshav in 2007, which, in turn, is = based on the long and boring discussion about this definition that = happened when ICCRG was born. Been there, done that, let's not repeat = please. Buuuuuut this seems off topic for the context here anyway... if you = really want to discuss this definition, I suggest to take it to ICCRG. = There, we will tell you to read the mailing list archives :-) Cheers, Michael From nobody Thu Apr 24 04:24:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BF21A0192 for ; Thu, 24 Apr 2014 04:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.1 X-Spam-Level: ** X-Spam-Status: No, score=2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 OeCNnC32FBB4 for ; Thu, 24 Apr 2014 04:24:21 -0700 (PDT) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id B7CC31A0188 for ; Thu, 24 Apr 2014 04:24:19 -0700 (PDT) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201404241324101457; Thu, 24 Apr 2014 13:24:10 +0200 From: "Karl Stahl" To: =?iso-8859-1?Q?'Stefan_H=E5kansson_LK'?= , "'Harald Alvestrand'" , References: <5357B281.1030900@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B1CFD9001@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1CFD9001@ESESSMB209.ericsson.se> Date: Thu, 24 Apr 2014 13:24:13 +0200 Message-ID: <017a01cf5faf$b8e16b10$2aa44130$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPXu/madRJFOb1bEmdMyYxHp0vg5sgjy4A Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dAgJl4Q2415fM1efUUHXJsdiPs0 Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:24:23 -0000 -----Ursprungligt meddelande----- Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Stefan H=E5kansson = LK Skickat: den 24 april 2014 11:57 Till: Harald Alvestrand; rtcweb@ietf.org =C4mne: Re: [rtcweb] Pictures of congestion control on the Internet - = which is more realistic? On 2014-04-23 14:31, Harald Alvestrand wrote: > I quote Karl's piece below, because I want other's opinion of whether=20 > it's a realistic picture. > > My impression is that it is not - in particular that: > > - Lots of interactive traffic goes over the Internet today without=20 > layer 2 separation - All UDP endpoints that use the open Internet have = > some form of backoff on congestion - using delay, packet drop or (most = > likely) both to detect congestion > > I'm writing the transport document based on those assumptions - that=20 > we should specify something that will work as well as it can over an=20 > Internet that does not care, and try to allow for better things to=20 > come along later. > > Am I wrong to write it like this? My impression (I have no facts, so I can be completely wrong; it would = be nice if someone could show figures) is that most UDP traffic on the = internet comes from modern (SW implementations) audiovisual communication, from torrent traffic and from other special transport built on top of UDP = (quic is one example, but there are other used by e.g. games). I think all of = them back off, so I think you are right. There is some older stuff that do not back off, but does it really = generate enough traffic to be relevant? [Karl] If file transfer type of traffic (that wants max bandwidth during shortest time) run over UDP (like e.g. torrent) their endpoints need to back-off when seeing congestion - just like TCP has built-in. That is = also one of the mechanisms build into SCTP (to "operate under adverse = operational conditions" Quoting SCTP RFC4960: 7. Congestion Control). To add level 3 QoS to the level 4 QoS we already had for WebRTC = real-time traffic (NOT file transfer traffic type), the network need to see the traffic info in those packets and assure that those are prioritized = instead of dropped at congestion in routers when fighting with file transfer = traffic about the available bandwidth.=20 If I remember correctly bit-torrent has also a setting of max bandwidth usage (maybe that is why torrent don't just use TCP's "take all you get" = ), so if you have a 2 Mbps pipe, you can e.g. have bit-torrent only use 0.5 Mbps (no hurry to get your movie...) and leave 1.5 Mbps at least not = harmed by the bit-torrent's bandwidth hunger. Unfortunately WebRTC real-time traffic cannot tell all other file = transfer going on to restrict their bandwidth hunger. Instead we need to ask the routers to prioritize the WebRTC real-time traffic (which then needs to = be marked for network elements to see). And WebRTC should not insert file transfer type of traffic in its real-time flow, nor mark such traffic = for prioritization. > > Harald > > > > ------------------------------------ [Karl] I wrote this sometime=20 > before, regarding how QoS over the internet works in general - may be=20 > useful for understanding > > For better understanding of these QoS/QoE problems, and methods for=20 > improving (not specifically discussing the policies of sharing=20 > real-time traffic space), I would like to explain: > > Over an IP pipe only used for real-traffic (no TCP data traffic), it=20 > is sufficient that the pipe is wide enough for good QoS. That is often = > used and implemented by separating IP pipes at a lower level using=20 > e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std for ADSL modems).=20 > TURN servers can enforce real-traffic into such pipes and QoS is=20 > achieved. Let=92s call this Level 2 QoS (Network level) > > Over an IP pipe shared between quality requiring real-time traffic and = > less demanding data or streaming (usually TCP) traffic, we have the=20 > sharing between these two traffic classes to consider. The main method = > (and the mechanism making today=92s real-time QoE as good as it often=20 > is) is that TCP endpoints back-off and share their bandwidth usage.=20 > Real-time traffic using UDP transport do not back-off, the endpoints=20 > using UDP occupy the bandwidth needed. When an IP pipe gets filled, it = > is all endpoint=92s TCP bandwidth usage that is back-off and shared=20 > between them, leaving room for the UDP traffic. This is mechanism we=20 > experience everyday over the Internet, using our =93Surf IP pipes=94.=20 > Let=92s call this Level 4 QoS (Transport level) > > However, this Level 4 QoS is based on that at congestion times (which=20 > happen every time we click =96 setting up a TCP flow and transferring=20 > some amount of data as quick as possible) the router handling the most = > narrow part of the pipe (the congestion point) drop packets. It is=20 > this packet dropping that (i) signals to TCP endpoints to reduce their = > bandwidth (via TCP=92s error correction/retransmission mechanism) and=20 > (ii) destroys the QoE of real-time traffic. (Both TCP and UDP packets=20 > are dropped in this process that is triggered by flow intensive TCP=20 > traffic.) > > We need (i) but don=92t want (ii) and to improve on this we can e.g. > use diffserve, DSCP bits in IP packets to instruct routers to always=20 > forward the real-time traffic before any unmarked TCP traffic (which=20 > usually fills most of the pipe). Then QoS is then achieved for=20 > real-time traffic. This is Level 3 QoS (IP level). The method used is=20 > =93traffic shaping=94: backing off data traffic, leaving real-time = traffic=20 > free passage without packet loss. > > _______________________________________________ rtcweb mailing list=20 > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Apr 24 05:27:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EE71A01DA for ; Thu, 24 Apr 2014 05:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 PuFkCH-FA6XS for ; Thu, 24 Apr 2014 05:27:18 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id AC33C1A01B3 for ; Thu, 24 Apr 2014 05:27:10 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WdIk3-0007SC-4u; Thu, 24 Apr 2014 14:27:03 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WdIk2-0001cu-MC; Thu, 24 Apr 2014 14:27:03 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: <017a01cf5faf$b8e16b10$2aa44130$@stahl@intertex.se> Date: Thu, 24 Apr 2014 14:27:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5357B281.1030900@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B1CFD9001@ESESSMB209.ericsson.se> <017a01cf5faf$b8e16b10$2aa44130$@stahl@intertex.se> To: Karl Stahl X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 9 sum msgs/h 4 total rcpts 15669 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1E04AF53EB590499D8DB9C78CA41E4CEF68796EB X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 5086 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/efAGyQTHKoQj7lNd1E4QyXCLGJc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 12:27:21 -0000 On 24. apr. 2014, at 13:24, Karl Stahl wrote: >=20 >=20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Stefan H=E5kansson= LK > Skickat: den 24 april 2014 11:57 > Till: Harald Alvestrand; rtcweb@ietf.org > =C4mne: Re: [rtcweb] Pictures of congestion control on the Internet - = which is > more realistic? >=20 > On 2014-04-23 14:31, Harald Alvestrand wrote: >> I quote Karl's piece below, because I want other's opinion of whether=20= >> it's a realistic picture. >>=20 >> My impression is that it is not - in particular that: >>=20 >> - Lots of interactive traffic goes over the Internet today without=20 >> layer 2 separation - All UDP endpoints that use the open Internet = have=20 >> some form of backoff on congestion - using delay, packet drop or = (most=20 >> likely) both to detect congestion >>=20 >> I'm writing the transport document based on those assumptions - that=20= >> we should specify something that will work as well as it can over an=20= >> Internet that does not care, and try to allow for better things to=20 >> come along later. >>=20 >> Am I wrong to write it like this? >=20 > My impression (I have no facts, so I can be completely wrong; it would = be > nice if someone could show figures) is that most UDP traffic on the = internet > comes from modern (SW implementations) audiovisual communication, from > torrent traffic and from other special transport built on top of UDP = (quic > is one example, but there are other used by e.g. games). I think all = of them > back off, so I think you are right. >=20 > There is some older stuff that do not back off, but does it really = generate > enough traffic to be relevant? >=20 > [Karl] If file transfer type of traffic (that wants max bandwidth = during > shortest time) run over UDP (like e.g. torrent) their endpoints need = to > back-off when seeing congestion - just like TCP has built-in. That is = also > one of the mechanisms build into SCTP (to "operate under adverse = operational > conditions" Quoting SCTP RFC4960: 7. Congestion Control). >=20 > To add level 3 QoS to the level 4 QoS we already had for WebRTC = real-time > traffic (NOT file transfer traffic type), the network need to see the > traffic info in those packets and assure that those are prioritized = instead > of dropped at congestion in routers when fighting with file transfer = traffic > about the available bandwidth.=20 >=20 > If I remember correctly bit-torrent has also a setting of max = bandwidth > usage (maybe that is why torrent don't just use TCP's "take all you = get" ), > so if you have a 2 Mbps pipe, you can e.g. have bit-torrent only use = 0.5 > Mbps (no hurry to get your movie...) and leave 1.5 Mbps at least not = harmed > by the bit-torrent's bandwidth hunger. Just as a data point, at least the official bit-torrent client uses a = variant of LEDBAT ( RFC 6817 ) called uTP AFAIK, which is a mechanism = that can better saturate a link than TCP in the absence of TCP, but is = designed to back off fast to avoid getting in the way (by detecting = growing queuing delay) when TCP is present. Cheers, Michael From nobody Thu Apr 24 08:13:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6F21A0397 for ; Thu, 24 Apr 2014 08:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 hhb1ehTsQNE8 for ; Thu, 24 Apr 2014 08:13:28 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 676F81A0393 for ; Thu, 24 Apr 2014 08:13:28 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id h18so1156374igc.4 for ; Thu, 24 Apr 2014 08:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5Cc3fjnTgIYmvqjCkLqe37fB4kl59JqMoowjivQKmkU=; b=LSpnjO5eLyDduIdzR5CDASRsTB0DWo//7dSh05tpBpwLSgpsVwc9FYCHB6cO3tDQtO U6Znh++tZLEOskLbnn+KMZ9/6G4g1rYYLZij9ILV9EoTcPxeu6JRc7wqmatusHJUlrHc 5XhyTXhgJdSlAqT9R/49pu0OSj1qzIjM/LSc5P/LPieAGXit5jhgBLW8svjHLT6FPek4 TD7tmMpVZSXYrrR50jdN9NGlNPDQokzslD6D9OpjeosqU6NM+M+mZFVxcyTon8DwnPXJ lcrrXAp7QOOTp0J+YJ8oFWJgte3GtjsvkojXrxQaUvVnPTuYKOmtsegdyu8f/9/Dpeop Qysw== MIME-Version: 1.0 X-Received: by 10.43.163.200 with SMTP id mp8mr2482091icc.18.1398352402254; Thu, 24 Apr 2014 08:13:22 -0700 (PDT) Received: by 10.42.200.204 with HTTP; Thu, 24 Apr 2014 08:13:22 -0700 (PDT) Date: Thu, 24 Apr 2014 08:13:22 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a11c30cc8350f8e04f7cb4ad9 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rnnz84tM1IewikLGIqYXlCoCH-g Subject: [rtcweb] Working Group Last Call for draft-ietf-rtcweb-rtp-usage-13 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:13:29 -0000 --001a11c30cc8350f8e04f7cb4ad9 Content-Type: text/plain; charset=UTF-8 This begins a working group last call on draft-ietf-rtcweb-rtp-usage-13; please review the document and provide comments to the list by May 9, 2014. thanks, Ted, Cullen, Sean --001a11c30cc8350f8e04f7cb4ad9 Content-Type: text/html; charset=UTF-8
This begins a working group last call on draft-ietf-rtcweb-rtp-usage-13; please review the document and provide comments to the list by May 9, 2014.

thanks,

Ted, Cullen, Sean
--001a11c30cc8350f8e04f7cb4ad9-- From nobody Thu Apr 24 08:40:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F6F1A028B for ; Thu, 24 Apr 2014 08:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 TsBrpo9dZxEM for ; Thu, 24 Apr 2014 08:40:26 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 334E71A0275 for ; Thu, 24 Apr 2014 08:40:26 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id to1so2556873ieb.34 for ; Thu, 24 Apr 2014 08:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=08aI1faDTfRVslzyhWFh5KyQf91aSf/pwx9mkerMfzk=; b=iCaB1hlMSkjFMcgJ9m5cW8MDzxpJVBRhVZU6mZIrP04btkUn8boJZ22dEMX24AfXTH fp5V2HL8Sj8mXfkEqz5GaQpdO7pQxfe62ZqGj5subktk0qY08ih+c3X9joY0jF8rTM3f p2uLXFNkYVKF1fD9uTaVgn+plpJNmAr1w+Gqv91Gd7bReJlxW5IIMbUYn+glOHo8xFdo 1YB7oII7Vsxp5HuZSGl7If9tX3FbeM3aC7HZNYCaNm+q5g3zod1C+52bxH/7PrhKSU3/ rZ10+1StnOoinKvRYLtAyzj+RDs5ryFWGQL6iROu1/lkamcWj0YKyZpsXkU+zNyeN2Uc j4iQ== MIME-Version: 1.0 X-Received: by 10.42.86.196 with SMTP id v4mr2534400icl.62.1398354019994; Thu, 24 Apr 2014 08:40:19 -0700 (PDT) Received: by 10.42.200.204 with HTTP; Thu, 24 Apr 2014 08:40:19 -0700 (PDT) Date: Thu, 24 Apr 2014 08:40:19 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Sean Turner , Cullen Jennings Content-Type: multipart/alternative; boundary=20cf30223a23a1d0ea04f7cbaa1d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0aGx1lTF3eE9j9kkLOWoxaq0Dw8 Subject: [rtcweb] Sketch of agenda for upcoming RTCWEB Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:40:32 -0000 --20cf30223a23a1d0ea04f7cbaa1d Content-Type: text/plain; charset=UTF-8 Howdy, Below is a rough sketch of the agenda for the upcoming RTCWEB Inteirm (essentially, we have the morning sessions for the three days May 19, May 20, May 21 2014). If you have not filled in your participation in the doodle poll, please do so at: http://doodle.com/qewq4xvszbc6d4sn. Comments on the agenda timing, on other work, or mechanics welcome, thanks, Ted, Sean, Cullen Interim Meeting RTCWEB May 2014 Day 1 RTP + Media (2h) draft-ietf-rtcweb-rtp-usage-13 draft-ietf-rtcweb-audio-05 draft-ietf-rtcweb-transports-03 JSEP (2h) draft-ietf-rtcweb-jsep-06 Day 2 Data Channel (4h) draft-ietf-rtcweb-data-channel-08 draft-ietf-rtcweb-data-protocol-04 Day 3 Security ( 2h ) draft-ietf-rtcweb-security-06 draft-ietf-rtcweb-security-arch-09 ALPN ( 15m ) draft-thomson-rtcweb-alpn-00 Consent Freshness ( 30m) draft-ietf-rtcweb-stun-consent-freshness-02 Matters arising from webrtc meetings ( remaining time) --20cf30223a23a1d0ea04f7cbaa1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Below is a rough sketch of the agenda for the upcoming RTC= WEB Inteirm (essentially, we have the morning sessions for the three days M= ay 19, May 20, May 21 2014).=C2=A0 If you have not filled in your participa= tion in the doodle poll, please do so at:=C2=A0 http://doodle.com/qewq4xvszbc6d4sn.

= Comments on the agenda timing, on other work, or mechanics welcome,

= thanks,

Ted, Sean, Cullen

Interim Meeting RTCWEB May 2= 014

=


Day 1<= /p>

RTP + Media =C2=A0(2h)

= draft-ietf-rtcweb-rtp-usage-13

= draft-ietf-rtcweb-audio-05

= draft-ietf-rtcweb-transports-03


JSEP (2h)

= draft-ietf-rtcweb-jsep-06


Day 2


Data Channel (4h)=

= draft-ietf-rtcweb-data-channel-08

= draft-ietf-rtcweb-data-protocol-04



Day 3


Security ( 2h )

= draft-ietf-rtcweb-security-06

= draft-ietf-rtcweb-security-arch-09


ALPN ( 15m )

= draft-thomson-rtcweb-alpn-00


Consent Freshness ( 30m= )

draft-ietf-rtcweb-stun-consent-freshness-02


Matters arising from we= brtc meetings ( remaining time)



--20cf30223a23a1d0ea04f7cbaa1d-- From nobody Thu Apr 24 12:08:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9FC1A03C2 for ; Thu, 24 Apr 2014 12:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 YgKNi1gcGatV for ; Thu, 24 Apr 2014 12:08:50 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2C81A03D9 for ; Thu, 24 Apr 2014 12:08:47 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so1489860wes.0 for ; Thu, 24 Apr 2014 12:08:40 -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:content-type:content-transfer-encoding; bh=+VdCM0NCSVnsc+6t9IGDXnYw6dgkqmgqwjbAJP35rMI=; b=g6w7C6PFP2gcr0vD+GTAxkWiAQeSvSBe6wpkBqU03axFIS5nylX6y959WoKGiocVGZ OKGjZ+14Vd4MiJC59/bvNd0EsD4+2ZWw8vsV5hygLpgQt3VI/wLlIMpyEX9UBErOKdB0 qj0dtAwaQjgBAL9XZL+iMO0XRodMgXvkKF1nBqeJxj/TojSNcIzxjUMqfm63XVYw/Jyf 3wikzIFTsfhUm41dcQF59raCWmQArN0e0Jaorr3kF40+Alyau4TWpYG3bvTdiu0FDkzq SXLFmCY40WVYt9/h3x2/v+t8UIjiAWoZbuF9TdcCRLEZ3+yNI0bOuv/W2ioIWGjScuHf Sj8Q== MIME-Version: 1.0 X-Received: by 10.180.14.233 with SMTP id s9mr240892wic.53.1398366520825; Thu, 24 Apr 2014 12:08:40 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Thu, 24 Apr 2014 12:08:40 -0700 (PDT) In-Reply-To: <20140423163717.GG86778@verdi> References: <5357B281.1030900@alvestrand.no> <20140423163717.GG86778@verdi> Date: Thu, 24 Apr 2014 12:08:40 -0700 Message-ID: From: Dave Taht To: John Leslie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PpRC07WOwe3g9bbF0A8-L0CSakI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 19:08:52 -0000 On Wed, Apr 23, 2014 at 9:37 AM, John Leslie wrote: > Dave Taht wrote: >> >> I'm not sure if we have a shared definition of "congestion". Mine is >> network delays exceeding that of what human factors research notes >> as "perceptible" with about 20ms as the outer bound. > I, OTOH, am quite sure we don't have a shared definition of congestion= . > > My preferred definition is rate-of-arrival exceeding rate-of-forwardin= g. That's not bad. But I would call that instantaneous congestion: exit -------- 1 2 3 4 5 6 7 8 -------- arrival at a slightly higher rate when two packets arrive so that they must be queued or dropped. Without clearing the delay caused by packet 4, we induce a 1 packet delay, and without clearing = the delay caused by packet 7, we are now at two packets of delay. And so on. When you got to defining congestion, the "rate" term you used is actually a measurement over something else, usually an interval. Where I mentioned X*1.1*RTT was trying to get to where there was a definition of interval tha= t made sense. > But, of course, you don't have to agree with mine -- "shared" merely > implies _some_ overlap of the sets of definitions we use... I should probably have said "induced network delays", although I have to ad= mit that ANY delay - whether it be physical RTT, switching overhead, or encoding overhead, or congestion, bothers me. I've spent a lot of time working on RT systems (see ardour.org) where 2.7ms delay was too much delay, and others with much tighter constrai= nts. So me saying it above was not a definition of congestion but my subconscious making a twitchy reflexive swing at delay inducing techniques in general. > Dave's, I fear, isn't terribly useful. There is a base latency (in the > absence of any traffic) which exceeds 20 milliseconds for many paths > of interest. Well, in the presence of some traffic, it's quite possible to get zero dela= y, for special traffic that can be slipped in when the grant arrives. Cablelabs did this with their SFQ sim, and it's possible with any request/grant architecture. http://www.igvita.com/2014/04/21/uplink-scheduling-in-4G-networks/ As for baseline physical RTTs, well, in major cities, data centers are with= in 2ms of nearly everyone. I'd like to see a multi-industry-wide effort to remove excessive latency from enodeBs, and wifi APs, and from future layer 2 standards. Stuart Cheshire and I did a preso at ietf last time showing a 170ms latency on data delivery on a 10Mbit/1ms path, first chopping it down to <10ms with codel, then to 0 with codel + ecn. http://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf It would be nice if every last mile technology could be as good as ethernet= , circa 1980. > > To tell truth, though, most users probably only notice the total delay= , and jitter. > not the components of it; so I think Dave's metric is useful -- it's just > not helpful as a measure of "congestion". Well, I suggested several possible metrics. > > I'd like to follow up a bit on Dave's metric, regardless. > > There's a lot of talk about "buffer-bloat" where I believe we all > agree the situation would be better with less buffering. > But can we talk about the other end of that spectrum? > > Surely there is some minimal amount of buffering, for any particular > traffic, which is needed in order to maintain a reasonable flow rate. > Most likely, that minimal buffering varies with factors such as RTT. Do > we even have a shared concept of what those factors are? > > I'd like to see a thread on what is needed as a minimum buffering > for various kinds of traffic. I suspect that minimum can be fairly small > except for TCP transport of "large" files... >> http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuin= g-traditional-aqm-is-not-enough/ > > Excellent as food for thought... > > -- > John Leslie --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Fri Apr 25 01:47:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790141A0291; Fri, 25 Apr 2014 01:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 mpnbEgbSb1vc; Fri, 25 Apr 2014 01:47:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B151A00D1; Fri, 25 Apr 2014 01:47:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> Date: Fri, 25 Apr 2014 01:47:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Qu2_Wb-kEx-ZD8PvM48LYsrxQ1Y Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 08:47:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Transports for RTCWEB Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-04.txt Pages : 13 Date : 2014-04-25 Abstract: This document describes the data transport protocols used by RTCWEB, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-transports-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-04 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 Fri Apr 25 01:50:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A521A033C for ; Fri, 25 Apr 2014 01:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 wNYuloPlcFKB for ; Fri, 25 Apr 2014 01:50:51 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 73AE91A020C for ; Fri, 25 Apr 2014 01:50:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5D0317C5428 for ; Fri, 25 Apr 2014 10:50:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS7UCzDoibpb for ; Fri, 25 Apr 2014 10:50:43 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 588537C541E for ; Fri, 25 Apr 2014 10:50:43 +0200 (CEST) Message-ID: <535A21E3.7070008@alvestrand.no> Date: Fri, 25 Apr 2014 10:50:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> In-Reply-To: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UXbg39j53okKg-R6grqnpIuV9-8 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 08:50:56 -0000 For easy access, here's the changelog section: A.4. Changes from -03 to -04 o Added a section on prioritization, moved the DSCP section into it, and added a section on local prioritization, giving a specific algorithm for interpreting "priority" in local prioritization. o ICE-TCP candidates was changed from MAY to MUST, in recognition of the sense of the room at the London IETF. There are also some attempts at language improvements, of course, but those should be the main changes. On 04/25/2014 10:47 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : Transports for RTCWEB > Author : Harald Alvestrand > Filename : draft-ietf-rtcweb-transports-04.txt > Pages : 13 > Date : 2014-04-25 > > Abstract: > This document describes the data transport protocols used by RTCWEB, > including the protocols used for interaction with intermediate boxes > such as firewalls, relays and NAT boxes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-transports-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-04 > > > 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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From kiran.guduru@samsung.com Fri Apr 25 03:21:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B4E1A0167 for ; Fri, 25 Apr 2014 03:21:42 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, STOCK_IMG_CTYPE=0.001] autolearn=ham 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 yPMTZftVbSHQ for ; Fri, 25 Apr 2014 03:21:40 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by ietfa.amsl.com (Postfix) with ESMTP id C71621A016F for ; Fri, 25 Apr 2014 03:21:37 -0700 (PDT) Received: from epcpsbgr3.samsung.com (u143.gpu120.samsung.co.kr [203.254.230.143]) by mailout2.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N4L00HFN0RU6T40@mailout2.samsung.com> for rtcweb@ietf.org; Fri, 25 Apr 2014 19:21:30 +0900 (KST) Received: from epcpsbgx1.samsung.com ( [172.20.52.126]) by epcpsbgr3.samsung.com (EPCPMTA) with SMTP id E8.16.11120.A273A535; Fri, 25 Apr 2014 19:21:30 +0900 (KST) X-AuditID: cbfee68f-b7eff6d000002b70-bd-535a372affa8 Received: from epmailer02 ( [203.254.219.142]) by epcpsbgx1.samsung.com (EPCPMTA) with SMTP id 9F.4D.32015.A273A535; Fri, 25 Apr 2014 19:21:30 +0900 (KST) Message-id: Date: Fri, 25 Apr 2014 10:21:30 +0000 (GMT) From: Kiran Kumar Guduru To: jmvalin@jmvalin.ca, cary.bran@plantronics.com, rtcweb@ietf.org MIME-version: 1.0 X-MTR: 20140425101845626@kiran.guduru Msgkey: 20140425101845626@kiran.guduru X-EPLocale: en_US.windows-1252 X-Priority: 3 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-EPTrCode: X-EPTrName: X-MLAttribute: X-RootMTR: 20140425101845626@kiran.guduru X-ParentMTR: X-ArchiveUser: X-CPGSPASS: N MIME-version: 1.0 Content-type: multipart/related; boundary="=_NamoWEC-kp6oaeupb6" X-Generator: Namo ActiveSquare 7 7.0.0.45 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsWyRsSkTlfLPCrY4N90Hou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcat7BnvBlxWMFTdfN7A1MC5fwtjFyMkhJKAusWH1PTYQW0LA ROLokUNMELaYxIV764HiXEA1SxklrjzbzQ5T9H9JFwtEYg6jxOGbu8Em8QpYSHxY+ZUZxGYR UJW4dmoK2FQ2oIZfJ9YA1XBwCAuYSrw+oAUSFhEIlVi78CobxBFKEmuv3mSFGCMocXLmExaI XaoSF042MUHE1SQ2tp9nhIjLSSyZehnqUF6JGe1PWWDi076uYYawpSXOz9rACPPM4u+PoeL8 Esdu72ACOQek98n9YJgxuzd/gYaDgMTUMwehWrUkFlyYCjWeT2LNwrcsMGN2nVrODNN7f8tc JlTnc3AwCzhJTL8mDFGiKfFoUSs41CQEDnBIvH63lm0Co9IsJC2obLh2kDCzgKHEl3mPGSFs RYkp3Q/ZIWw7ibeb17NjiqtK3G/fwraAkWMVo2hqQXJBcVJ6kbFecWJucWleul5yfu4mRmDq Of3vWf8OxrsHrA8xVgEjbSKzlGhyPjB15ZXEGxqbGVmYmpgaG5lbmlFFWEmc9/7DpCAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjEGukwt7yp3dJ55q8fCoTDD3mXCT5U7M9AdsLB9yhC1L /hycLXE6NSSI6eCRUpnFNsVbbgdNKDERPPjMY/kcDa+/4VHtc9alP+WIXpe6+tbM78Uu36O3 rmJaEBz7oXN54EOf4r/zow/eTnBJ/h13QKDddYHT32AZD0F14YzHq7vXPZBbeuT2BCWW4oxE Qy3mouJEAIZv4qFqAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMJsWRmVeSWpSXmKPExsVy+t/tPl0t86hgg5ltjBZr/7WzOzB6LFny kymAMSrNJiM1MSW1SCE1Lzk/JTMv3VbJOzjeOd7UzMBQ19DSwlxJIS8xN9VWycUnQNctMwdo qpJCWWJOKVAoILG4WEnfzqYov7QkVSEjv7jEVina0NxIz8hAz9RIz9A01srQwMDIFKgmIS3j VvcM9oIvKxgrbr5uYGtgXL6EsYuRk0NIQF1iw+p7bCC2hICJxP8lXSwQtpjEhXvrgeJcQDVz GCUO39wN1sAioCpx7dQUsAY2oIZfJ9YAxTk4hAVMJV4f0AIJiwiESqxdeJUNYr6SxNqrN1lB bF4BQYmTM59AzVeVuHCyiQkiriaxsf08I0RcTmLJ1MtMEDavxIz2pyww8Wlf1zBD2NIS52dt YIS5c/H3x1Bxfoljt3cwgZwD0vvkfjDMmN2bv0C9KCAx9cxBqFYtiQUXpkKN55NYs/AtC8yY XaeWM8P03t8ylwnV+RwczAJOEtOvCUOUaEo8WtTKMoFRZhaSKlQ2XAdImFnAUOLLvMeMELai xJTuh+wQtp3E283r2THFVSXut29hW8DIsYpRNLUguaA4Kb3CUK84Mbe4NC9dLzk/dxMjOJ09 W7iD8ct560OMAhyMSjy8E2Qjg4VYE8uKK3MPMaoAzXm0YfUFRimWvPy8VCURXlmTqGAh3pTE yqrUovz4otKc1OJDjBMZgVE8kVlKNDkfmITzSuINjU3MTY1NLQwMzc3NaCmsJM5792ZSkJBA emJJanZqakFqEcxRTBycUg2MC2xnJ4hx6XTkqJh/vxYtVmngpHbNK0n9c3XwfD2Xi4ciWnud dGujPGdV1Apa+VvzCrZPZp501/z99T0z0jcLPl89VyyV9fnrpi97ZNcfL1iR+f/ZwwPHWf0r uWun3XXdVNrEGtFpvjxESzvb8Nq1IPetM1jWsx9mdWGcaqSX5Jmpy1Bv+UqJpTgj0VCLuag4 EQD8heBH5gMAAA== DLP-Filter: Pass X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/awybah3uG7LhtiJgp89ltVsmBzE Subject: [rtcweb] Query Regarding Mandatory audio codecs draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kiran.guduru@samsung.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 10:26:35 -0000 --=_NamoWEC-kp6oaeupb6 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: base64 PEhUTUw+PEhFQUQ+PFRJVExFPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L1RJ VExFPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiIgaHR0 cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8U1RZTEUgaWQ9bXlzaW5nbGVfc3R5bGUgdHlwZT10ZXh0 L2Nzcz5QIHsNCglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1B UkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0NClREIHsNCglNQVJHSU4tVE9QOiA1 cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1T SVpFOiA5cHQNCn0NCkxJIHsNCglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwg YXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0NCkJPRFkgew0KCUxJ TkUtSEVJR0hUOiAxLjQ7IE1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsg Rk9OVC1TSVpFOiA5cHQNCn0NCjwvU1RZTEU+DQoNCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRl bnQ9QWN0aXZlU3F1YXJlPjwvSEVBRD4NCjxCT0RZPg0KPERJVj4NCjxESVY+SGksPEJSPjwvRElW PkkgaGF2ZSBhIHF1ZXJ5IHJlZ2FyZGluZyBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGF1ZGlvIGNv ZGVjcy48QlI+PEJSPkluIGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLCBpdCBoYXMgYmVlbiBzcGVj aWZpZWQgdGhhdCA8QlI+PEJSPiJGb3IgYWxsIGNhc2VzIHdoZXJlIHRoZSBjbGllbnQgaXMgYWJs ZSB0byBwcm9jZXNzIGF1ZGlvIGF0IGEgc2FtcGxpbmcgcmF0ZSBoaWdoZXIgdGhhbiA4IGtIeiwg aXQgaXMgUkVDT01NRU5ERUQgdGhhdCBPcHVzIGJlIG9mZmVyZWQgYmVmb3JlIFBDTUEvUENNVS4i PEJSPjxCUj48L0RJVj4NCjxQPklzIHRoYXQgbWVhbnMgc3BlYyBpcyByZWNvbW1lbmRpbmcgRy43 MTEgKFBDTUEvUENNVSkgZm9yIHNhbXBsaW5nIHJhdGUgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIDgg a0h6PzwvUD4NCjxQPiZuYnNwOzwvUD48IS0tU1A6a2lyYW4uZ3VkdXJ1LS0+PCEtLWtpcmFuLmd1 ZHVydTpFUC0tPg0KPFA+Jm5ic3A7PC9QPg0KPFRBQkxFIGlkPWNvbmZpZGVudGlhbHNpZ25pbWc+ DQo8VEJPRFk+DQo8VFI+DQo8VEQgTkFNT19MT0NLPg0KPFA+PElNRyBib3JkZXI9MCBzcmM9ImNp ZDowR0FOMDVXNVk1VzdAbmFtby5jby5rciIgd2lkdGg9NTIwPjwvUD48L1REPjwvVFI+PC9UQk9E WT48L1RBQkxFPjwvQk9EWT48L0hUTUw+PGltZyBzcmM9J2h0dHA6Ly9leHQuc2Ftc3VuZy5uZXQv bWFpbGNoZWNrL1NlZW5UaW1lQ2hlY2tlcj9kbz0zNzlhNjEwNWFkNTlkNzYxM2E3NTJmZjYyZTc2 Mjk1ZDIzMmY4Y2RhNTk5NzBiOWY1MmNjYWFhNWU3OGQ3OTE3YTU4NmE4Yzk5ZGZiZmJhYjBlZGJl NjgzYzg1M2ZlNzFkYjlmZGRkZGEzM2U4MmNiZTRhMzkxNDI0ZTYyZmNmNmNmODc4ZjlhMjZjZTE1 YTAnIGJvcmRlcj0wIHdpZHRoPTAgaGVpZ2h0PTAgc3R5bGU9J2Rpc3BsYXk6bm9uZSc+ --=_NamoWEC-kp6oaeupb6 Content-Type: image/gif; name="201404251551985_LLKJ9INH.gif" Content-Transfer-Encoding: base64 Content-ID: <0GAN05W5Y5W7@namo.co.kr> R0lGODlhCAKQAMQAAEdHR4yMjLm5uQICAtt0dCoqKumiotTU1PLExMpMTG9vb9RiYvfZ2fvt7eSO juvr68k6Ov/+/jMzM////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C1hN UCBEYXRhWE1QPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtj OWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUg WE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAgICAgICAi PiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5 bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXBNTT0iaHR0 cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtbG5zOnhtcD0iaHR0cDovL25zLmFk b2JlLmNvbS94YXAvMS4wLyIgeG1wTU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjc5QkEy RTkxMTJFMUUxMTFCRjA5ODE0RDA4NTQ0MEQyIiB4bXBNTTpEb2N1bWVudElEPSJ4bXAuZGlkOjk0 NUI4NzE1RTEyQzExRTFBNzY0RUYwRkU5MUQ4MTBGIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAuaWlk Ojk0NUI4NzE0RTEyQzExRTFBNzY0RUYwRkU5MUQ4MTBGIiB4bXA6Q3JlYXRvclRvb2w9IkFkb2Jl IFBob3Rvc2hvcCBDUzUgV2luZG93cyI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5j ZUlEPSJ4bXAuaWlkOjdBQkEyRTkxMTJFMUUxMTFCRjA5ODE0RDA4NTQ0MEQyIiBzdFJlZjpkb2N1 bWVudElEPSJ4bXAuZGlkOjc5QkEyRTkxMTJFMUUxMTFCRjA5ODE0RDA4NTQ0MEQyIi8+IDwvcmRm OkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8P3hwYWNrZXQgZW5kPSJyIj8+ Af/+/fz7+vn49/b19PPy8fDv7u3s6+rp6Ofm5eTj4uHg397d3Nva2djX1tXU09LR0M/OzczLysnI x8bFxMPCwcC/vr28u7q5uLe2tbSzsrGwr66trKuqqainpqWko6KhoJ+enZybmpmYl5aVlJOSkZCP jo2Mi4qJiIeGhYSDgoGAf359fHt6eXh3dnV0c3JxcG9ubWxramloZ2ZlZGNiYWBfXl1cW1pZWFdW VVRTUlFQT05NTEtKSUhHRkVEQ0JBQD8+PTw7Ojk4NzY1NDMyMTAvLi0sKyopKCcmJSQjIiEgHx4d HBsaGRgXFhUUExIREA8ODQwLCgkIBwYFBAMCAQAAIfkEAAAAAAAsAAAAAAgCkAAABf/gI45kaZ5o qq5s675wLM90bd94ru987/+5iXBILBqPyKRyyWw6n9CodEqtWq/YrHbL7Xq/VhF4TC6bz+i0es1u u7Hit3xOr9vv+Lw+/Nj7/4CBgoOEdnGFiImKi4yNeodDEkSSSZRKkpYSmpNFmp6WS5mfkUKfmxOg R6mkrKWnpa6eraimla+ioKu1sJWhRrqRo7y7qLGblKmZs6qdwsW/r8+0ub7Tt1TOzLq7uJydrbmm 0eJTsuDj1UaQvMPO26eY7MrL0sayyd/19JOr7NLzzwAC3Dev3z5wwajZoycumr536Ibl+5dwFD55 vyoiQ4hRYseJB6GRMsiKpD6K/pj/pTxpLVvGXgm9qesDEtjKjcVworyJRGFJc/1I6hzJEaVAfi45 YiLHUuPHozxBBjQn06dLYlTrXdxZVCdWpUVlnmOKM57KjQ1vNgzH1J5Jr2RbwuuKZJ3ZaVVfon3a LOksagrjigzGCarRsVAKEo350uNOXA7lovPpz2pKw38nDpQnzDBUzBqzBvS2VxtCtnkrbxmaE2nP sZGFQFKsWe89xiudWP6oOgrtx3wli45VMqzY0cG5NsGMjKpZ1qC19r0GzWrElj+dqxS72+JrpNE9 r1269vvuf9ejy6b5sD1DiSaxHSZd0/c31NmpX/HK0KZn4+l4FBl/0LlzX0jHwfQd/3D21QdWa9Pd xiB4m1H2RHkMCnQMgOs1GFVpwoWW1F3xiTjgeAouuB2GFG5IHIL0JUeMW37JQaItJZbTVVrVzWhN jHelk1WOPbrDY4ovOibecB22KJV/sLwlxW9uBbjdJVZKpWVmSDYmI4cHtVVlhAaJOR82M9o04ZVs Pgmfblh6mVuCdNa54H9zzmabnD9CGCKM7Vmo3HJ8bokgi15uxsSJ1mnX5UmKCqqmcUGK2CZkRjr6 56P9LWbonEUOeSSil456HV4H6flpU4XBSGSijb36XpwqFpqionGWGJ+UfEaa4KSgglrpr7MqmON4 5B3Zqq3BEnvocihCSmutQ9jlI/+zmilLaq1ibqsloiyGqyyt3o7DK6dzmmmmXD1d2+stsXU7bqzz ehGUqetuuqm3odTral3sOSLwwAQXbPDBRKyD8MIMN+zww2YoDPHEFFdsscUSX6zxxhx3PEjGHocs 8sgkl3GIYF+lNpWmGR077YVMrsqadOiqrAQEOEMwBM4759zzzTpPkLPPQgfNBM9CIF200kof0fTP SQwtNRFSPw3F0FCj2mx13Llrp9YsuYwusPoyO+wEGc9MXm08ieopcRKm7OyiLP+odlWnVolrEUhX nXTQfQMu+N+EF1340UYHXnjgWBtO9dROGx0535I/XnXllJM7Lp52xpYcYXQ2V3f/iwPC2vXb1QaM nJrJYCh3We4N6mu2gjnW26T8RWUzEoo7zjjRvQc/eBNMD+935o4vbbkRVlMOedQ6F+83zzye+3m+ tqt8kaDIfUo27myDmLDqN2J32YO4wb7V7JBu3lv2gR1oDICsj/u78Isbr//hQN+/P/LNQ9zlrMCz pzVuaZgL1voA1Qx+xOocDgxbboQyL3CFL0pHsMt0+sK27qXGO9pbiO64xBvogOeDnxsh8YiWvAP6 L3+NC6DzhofArEHNf89zwuUOyLzoSQ5/SWJV+wITrSnljVoeZKCs8mEgu2WQPWmZ2UOaWDv1ddAv QzJdZeoWv/PlbogSImACb/g//zESTobJO1zzZLhDFl5th/krnIbO8zIyiC6KZ1GF58IUrSDR5mwg a0dnuGDFEEqQTA6p0XG6uCgwGaWIWQAiAnM4uZ6hsZIthKMU2oi4HhYvhYPql7oguZ882gpZXfJj cfw0vizN7S9pepMhW2c9bC2DkWNaUwefMEAb+q6MmHyjL5tGzDHyz3I8DCbvjHmnWQnlXzUroV44 OMUlvgxP4kvd1441qkQpg5Z4ueNcakZLEIbmfYi5ZbhWiLxJxhBy0jteGn05Q3gaMHGabKca8wk9 T8ozi6sqob+2NhDXcWNMd2skOj14jX6oCom9KlbLCIUkVKISorYj29cc+bh23v8TaPTsaA9BKtJl hlSZn1whJ+eJRnFeKx7lu5AvYCpRbCXUlXVEXZNohKnhgMtrG1VgGcR2zpzSK1+9/FtSMbnSAK7U nW4cqVLlWc9iLvWNVw3oAwUJVCF+ZqBexdFLwbqrJ5bsrGhNq1qlEMi1uvWtcN1YW+NK17ralWBz vate98pXP+S1r4ANrGDT8FewJWucTtnanapoS60aVnekaur0mBnJqJLUn5FbIz/PSNmfXXIJH+1n FD5rUkvy0IU07B/w8ElJ03rWnq49JlTRqLTZkPWQbpLW/FTY00QeY3RbXVlXUxFaq1kVtVed7O9m K72pTrKG7BwgG31YQNZS1Z//lEwpMp9H2n0Ok5m94yUw5/nLY15Xn6Jto9EUBpeDBuUsQJnmKkkz ugVq9TNH9VFxMadd2YY0nuX1ruGqW0zolva45H1tdTP32dBmzbip9W9pM8lg6UZYgKtF7y+TqTg4 ktbBtVVdEv1YvYnmZ5DzxSBsrtIfdSmlm6DVJIQXLNKnlpTD+CTjgN1IYPD6cIYJ5iyNX4vh7OYY gPzd7IN/eF4kZ3XJprVsgAss4SrTU7vsfV9BF4m+FA9FPcZCE/cQGbNgohbJOtysdjtM1Sef1M3M rdyQ2cnUJFuZziz9MTJPGuOSinfN1AWwedV74/UGzHVhocz2IKupRcMMe3qw//B2+3vZdwp6sgZe blVhO+cKD9nGm0au4I7bWpWOWr001rRKNTwFAqM5wKPN8E6/NRl+tQvSQuQq9so5SnJcFFGoFm2R kwldHDu3vD0mY3crHOQdd/rOf76wn+Oc5PD2GdmE7mSwtyBJrNIwbaUMVZvGvSVdraaxrPpwZ6Wa 2VMze8ecLbZ1l8ndwU23hpo1db3jLexN2pvJ+4Z1q9dN7+NJNo6hPvKQwU1mxX4PkbHD6SvFOqJQ 7RHClT1woDcMcNY6F8Hs5je88zy1fE9b43vuN7RBnufYCnzVJ59wlQVN3v2mHG1Q7KN8s3RYoG7F lb+mKM+FyeqpohrOxyb2m/+lrHQHE7nZIw+2ui9rdIMTnN1Ol+qyRw7tQatcw1lvZ2ENmi9cW6lc 5ahgBS1Okhk32QvLpq0xnfp2kV/77ngPeZqRbkO+41CzHmduu0ttZbcT/nCFHaziF8/4KiS+8ZCP vORbOfnKW/7y2sS85je/+Mdz/vOgH5lt4xtNogKKREf8la9NBHHcFpXX6lSkLhvVuaacDaDUIqVj Gz62OqF+zC3GdS1hIjdyM9Bkh9453oDL9h6peEm1px+3BhM6ik/ckFxizjd3O6yvMl9Yyx/urcbv 3mnh3vhErK/0s8eZ7xM2+UxckfGvX0j88qYmLvL9blPs+l1qVISoUj7YpGL/xcE6uBFKBOggGLUU V/JMMQEYkvElr1Emc2OAulYR8oduyEch7BdK3LQu9Yc+exNTaGcdUdJT6bJI4idNv2F/lZJNupQT noMrwBc24aCA8sMVZ7MjMUODFRhcUhSEBEEHWcZ/96dY0WdOABUeotB/2Bd9E7R/RtRoq4RNYTQ/ 95J++gE6XLhQu6dFKHSC+Yd7TNhA3BFciTViiLU7SEgGJ7N6uJWFMmUeCRhmbchTeVMWpGQhpfMF +NAND6JKdahQX7gsugVGbRFTQ6gaXxRGezNTt/SDeNiBNLhHZ/BX7xWFouQ+o9FbjahHZgcn0AJW oDhQthZWAkIzrMR61URm/9rBPtbkJ0t0I5/Yfr5VRIqoinRBiGyYa5cIfzGSPtSUBYVEh0eIRLPo JEDnc/JBTlWog75IiTlFJR24L0b4J7QogQioiQz1LbsYjEkCTnMwetxwUAglVHQzF554gFn4UhJ3 iNH4fz/HiqhoC4vxh6XYGXCYezl4fOC4ir2gGIC4RTUILM/xPU2EjebILkmkBg/1LLliVJB4h07Y Mg7Ij0p0SuUmkdGoU4PYkRCpUBf1jkRCgcMnM6KIUbuEjsT3BuQoe2WVjl0VfjCZj85xg81XVPSo jA14a1iBLzN5kqd4kvM3hyq5TRxZjySZkkP5jmjgeaEXlVJZMVA5lVZ5lf8HU5VYuZVcqQha2ZVg GZZ+JWJiWZZmSQhfeZZquZa/yJZu+ZaGQJZwOZd06YZyWZd4CXkRsJd82Zd++ZeAGZiCGZhKkJZ5 eZhvNZiKuZiMCZiFeZeIGZl91ZiUWZmEmQSHcAACsJmb+QAHAJlJ8JkC45mhCZpOIJql+QSomTAH oASaaZpDsJoO2ZpMQJrVQpt2IAB6IJtWoJtr0JcIMJgNwACWuZcM0AB/OZyOiZnsoQAAUAADAAAA cAAA4JtRUJ0CEwABkATYaQQKcJ3WeQTd2QTjOQTaGZoFMJ1McADbWZ5pcJ5MIAAAQATyiQcD8Abs KZ7h6Z1PcJ9m8J1D0Jf/CTCYCEAAjOkAfkkAwemXBbqcAFME9SkE7ukEE0ox/vkEFToEGaqfRgCf RxChTHCeG0oGHqoEIDoBJ0oHF8oGJdqfLmoGK0qZDbqYA7qYM+qXjwmh8ymhCjAABdCaDwAA0Rkw QToAA9CePVoAfVCkAPAAArCdKLqdAQCdUCoEB+CcR9qjOzqlR4o2QvqjE9CjXRqmRvqdB0ClAJqk uDkB5ymmVRqmB3ClQvqdWsqmVDoBcjoAABoA0VkAusmlUMqnz2mdRQqmTNoH2AmobKqdvhkA1gmd dOqjrRkAPeqbZ1oAAQAAauqlQ0oECsCnhiqkXfqpPioA0KmbZ6qnVuqj/wDwpkXapQ8AqfMZq3o6 n5paAHYKq1/amm4qBJtKpmDqqWW6qHdKpj1KBNp5qkIKpWKqAEFqpTtqpXd6qGEKqnFaAJj6qtup AHGKpQDqq9F5pQUQqapqrP75q9LaqYpqp34apj36AIpap0LQlwbqAAaQAAtAnA2wAAngAPVKnAyA oAbArwjqAAlAAAG7AA7gAMQ5sAfbADfalzlKn9EqnWxKpxjrqWZ6n8/5AAqQsR97pr4aAA8wANeK mwJgsgdwpLH6mSr7o5l6sWfqpLiaqSLwo58apPM5pfCKq+YZADNrqkRQnSnrsnE6AAJQsidbtEqr tCmbtC+7tEhrnjsLsv/fWZ1Ke6bsqZ07arJUy55KOqVs2qTVErIWS6numrYaurPz+bF4yrG2Grbz ma2tOgF+WrJv6rYrW606y7cWi7QiELUxS6lBW7Nha7g9i6xN2rI8u7c2e6zmGbYqe58227JgirZD 4Kcr67EZe7ZNGrJ6y7GbabJKG5tIm7J9ULkw+7mUe7hD254kG7VKK7aaGrgnu7LWKaARQAAGagD1 agANwLu7G5wNmgDBmQAMwADGiwAJ0ADBiwANgLy7awARy5cTOwQgip316bUl20opOwF1271eu7ft OgDwmqZVGqH+WZ2Y+6kxKwKm2ge0Kb9+ar4oaqu+GayLOrN4OrSbuaP/2Em56Buh7Augftq+2mnA 1vm+fTC+oovA2lmyNEux4Ju/W1sEIqqb2wukK6q9s9oH35uo2ymfInu/Jfyp3nuf9huzKzyf/gnB Hxy//dudP0rDa0q/Twqlovu2yDrCXSsbeOqnbtuu0ioEUNuae+vBi4pzKCq6BBye9wmiOIydSWzB Grqdk4q+mNuef4q+ExCjfDmgChoBxYucvju8ZGyg0kucETCgMzrGAGuv1buX12vEFavBLmykRkoE qSqkFSwEKjwE9/mpIsunepy+P1zBhmykJPucJGusQPql9WvH4KvHUysEbaqna0q0AKyblGvJjtrJ 8Mm+oDzKhOrIDSzI/4pcyrCLwtiLvxKawxjMxff7xZbsv7Xcxzt8nvKZsnpcnVv6prr8xZTsn9uL yaAcpNkKyZWsx/Jpyafsowesw39MzD9by8RcqJqrpCt6ohe6w/V5nsPMybFMBFG8o9rcy4DczEZq nWdat4t8pCWaqKBszfMaxmhcvHvZoGPcoAM7xm2cxns5xga7AAtAvQb6l3WMzX98zFZKBES8w+K7 pFE8rt8Jn2uqvrGM0TgnrmjDnubrthVsv/XZnWsqzvBqv7H8xMTM0U9syhxtyqnj0fbbvewLpZMq pT2a0bBst7Lcww3twrGJy/UZ0X/My8C8HhFaokZtzEJdyy+M0x2tAP+46pl8GqSWWs1rKtI3vc7d uaJIvc5crZsWTcEoKsFoA847u52Y6tX/W86qHKFj/dVazcf3674PDZ+0zNH2PAG6289qvM8GCtgR cJy+awAB/cYI4LtmjNAOalZmHdTgO8I+C8ipy7EXbatSuqPY2poyXLeUbM1Eq6STjcJ4y9nqjLsf 27fvq7/aGbM+raFv/ccVjaihHMsii7uf7ai4irtDYNocu9kVvNvnWbKVTckx67hvusRKXLdCK9tQ fdlH7cNfnMXVbbdvusLBHaaazd3WvNvADdsHPKurizb6S8VIC58CzKZgTd3EjN66WalFYL4SDM+w HM7bqd3D3cnmjM3/8I22fDq25o2bd0vCpN2qIiu02nvg+W3Efo3PhE0AiO2v0xsBvssAC4Cc9prY Ca2gBoCg++rYCs2cOgrd9bmyQhqeVD2u5vuc0InE0em1lfzb2HrcGv3HK97bfUqyNT6fKfucrUqr zmnez/mtixqr2Bqt+13O2OqxNe7f8V3jUY6tvirlpuvIbyukrYmdOb7Ek13iSD61LcqnmYrHWX7J 5VyfK/6uIlzLU6rl7NrWNM7intmn83mp6WnPXY7i2drjRD6uf27kP56er73OSO7H16zRg+7cK4rJ 2LqxcK7EZL7mLT7b5YmtEbroPJ6e9xmrRY6sOx6mTy7qU9udXW63/9z84HspxsRroBhu0AbKvLxb rwtAAPkaAQat2NFr6ws7xxGw0E0gAGtqpcOetNVi7EigmVCg7LIh7NiLm8zOpqkbrc6OBNVem8Ye 7R8aMNqO7Alz7U4qYtouBPr7ocNeBHFq7eduBOm+nt7e7uh+w/Ke7IR67deOohl97uNuBPu5BNqO ufF+7HeZ7vCO7dy+nwh/7uEem+F57wwv8NvJmMrJl8kLnAsaARCLnH6Z8YoJ7BAzpXza7w4jp4g5 pSLvMfCKCA+g8cXZ8i7/8g7KqE8A8zRf833ZAMBr8zrv8iGzmZK58sV5nJUp9DtPmUQPnBjPxi5/ 9EPP8i3PAAjA9P9Mr5gT75dHX/UMqvQ1j/Udn5pUwJt5cPLxCQaoapqyCfa3KQVin/aYicSwWQS2 uQRAz5cIupgA3Zh3X/R2f/H4bACI/fJ+3/KB7/Kynvd5L5gI6ut37+sOcNA2n/gJzZhHkJ8jugQt qgWOWptGfgSN/qJeQLnLzaHQbe1K7gSdz++lX+KVXwTfmaJ14fQ1qpiHL/t8r/cuP/i3//eWifvF yft8OfuAGfuACfwJWvsvL/yNeQQZrAer7/rzTQWnnwXRL/pw/aGpnwXO/8pTcM5NMPcRYLC9i69/ f6+3TgAFTZz2iq/6SgAPi8bnX9jsv7DBu5fzT/EEO9CNT/H+mgD/iA0CjLM4DkM0UWQSkWFEzJI4 qpEQZjzXcbIQYKrdjxEJ4lKMX3AYQSwWsAYhubotGDKp7kZYIFwzmKhac+BEEWoiASOEVWoHllFn o1boshvdcrWh+KnhpdAVDU08AAwAPAgUFAQAKAwUHCgyOk4oVDoeAAhwPgQEcFqanl5OsE6UFgyI BlQKHMAquFoe2A7gTvCaMuJWrp5WtrqmAiRHplYeq2LOxrbyrgIENLJia08MJE9ASmYODAQTP0yE 5o63CiwvlgcImE6Gp24zt3s+LitgHsD14Ja/XQqEbeu1rJUnSAjZ4VOUQk4CBDK0JGhw0cCCIy0M 1CDwsUUJPUcQ/xhAwVEPlRZZXPRQIaWBlAgVJz5x0yAjgoxUENDZYdMFjJlBdjboGcZoUYtunNRM afNN0yVCZCLo2aBkSZEuBLGwmEWpDARIezLYiTEryRoyTg5B0MJrSioGtp4J6SBpAox3s1w8YmAJ W5NdRybqxEnBg06gls1aLJnSIgECzD34VsrWowKuHEFClu1A6EnpJA0MsEg1amwTCtQaQOqS6dKO oLEqxUpzgUeab//u7MozsnH2eq32xti1ZlOwLzfGZUtdb8WhbO2S7c6f9FjLGHGKyNv350UK3qkT hd76d8sDDmQ+YBr3r1iX4cvGfkA7qwc4h4KkAh0BugCXXAa20P+XDyc1EUEWGT3RloNxCBXhUE5A IaABB54kVYAJEJVhhASCIaJcb13hRAoNSAUiUSgGJUdHT6i1IBwWvtBhD2AQSAeHN4J4YAMp9ASX CgfeiGQYCi6BoAou3miEXUMdyCSISf4RgTcANZdeOMu8p8g365QySSiQzdPbL+qkUowrvtBmSmhf pjfnO5yF0w+brFyyzn6ipdKlN17+6dpr8kWkiCLHYYJemI4mM12eD6Rz2Z6DhhJZeNspUuk3nwIA iiitCDqmKI+gt46j6dgTCnrprZMZMoO+mqkvCuDjnxMg3tCGGzkOgaWTLg4Fx40nuXjgRcRaaCGz zb7w41Jw8br/oa84AAtHT74aa8NVgACRoLccAtvsk0NcGcaBOcKRLUrXbvgHkBbKgEO6cc2lbr4X FqvvuXChEQUMQYp7rrAqDLobOKqCWU45Xr6DqyT1mPIMJow4PCo46en2aqruOXwmMqk67N2o37Si 26Aqm6owxuXQk2g2BQAAJiuQ0tncq6zwAt46mNJTMj7o9fwNbAWchzKpG7d8c3s5O13nQmeePOs3 tQbtcK7/VSsHUTY4KSyEOzEYBxgQckhCTE/MWKUT0Marwo1SQFgth0OSWNgaSf1RbmBuh9j3VRya Nfa9676BkhDtCmGEtFS6FMe9R+6rpE0rHv4HlCjlkSPBl6+R/3ki2smqG8MJr+lnI5eRacoD8vU5 KiYpKxNzOMR9/CqlHuv588VV064wy14CzfPGPK+Cs/I2l8I7bC6faqrKs0f9/KAHYQMAcUsP76dl Ty8v9TbvRG81nRynQr1Eu+6QQhBvZSis/DBI1W4LTZbQkoAVva1gE8+ixUEMeBxHetA1BYFkCXxZ khE+lIKaHGlGXnGR5x74LZ/0pQn18xe7xOIDsbgvbtRyVgpuYCQLyS8MGqyc5uSGkhrQZGAopB8L E+Eae5hOPd+Rk2d+Fgl1aKdMC4GNPTKTjtx45k8su1gwRBGmyMgmPugpomwikw3R4MJSw7Pib8RE iojMqWbeqP+YKcyxqS5F8T1BHBMuWlULNRkqZ6zizTx6Yb4ttvE8O/zMng4iPo4Bx3xYw1McdTWE KGwlCjMaAf9SSC97GQEONBHYGnjwhyK9rSeI5FcEo1CDx1nlXDnyAgJ/AAZAVKGBpvyWIkdwoVGu 0gkcIYEPUumkDiYyCmEYQRSaNTcwkMSTGaSQ5Sy3BFsebHM7+UJJdHk/SDoJYfthhDTMcbppUuNn 4FEAcXQTCZplIhK+QGIzNhaAb6aDm0Gj5nCQVp/liFMRNIMFMqYJnuENRHvfWEQ8VdaKb3LTG9pT UyMikY4undOd3ETaewYapnUsdHt0WmglsqMaMyKjVPKkJnr/WCdGW0SiPVgzhtL4BJupiSKiyDCk CpKiBArR6G0yVZFZZGoRG5Swb2sbwgBnSrme+jSoLa2pHWRihDXUtKVHzeR/ZKqRmWphCC4VKlOd ANSZTlUOS6UqVpPKVaTiJKtgFWp/BHDEX6ivFY8466za6g711WJWzUsrzzSWJ0WYtRrUI83N4OrW R7h1ZLOKa2DvuhvAHtaus9qFXgfrVr4GlrGFnaxa87pS9b2OsvOoz6zW+ljFsvSrohUtR24QBo7A VLQcGm1QaeKAL7A2trKdLW1ra1vZUja3ut2tP3fr298CN7glRV1wi2vc4+r2MpMYZ3FDe1vZRutI qRVtUZ8r/4cXNNW62t0ud7tLVeSCd7CKDS95y5syuZo3veqlrO2QSym1Ui+zn20rfArb3vXKVxF0 naxlLMNW8+Y3vfWta38tO9kAuzVm/wUvqiyjXgTnFrG6fVtUvfvVtHz1qaLVMIUdt93pChXEo30q hqmaFg4LFcVcbcBZd7azkXUDGT9ra83OydzwNgYcWVzIbhtRszCZd8frJR4n9Fmz/Q6Wx2495yzU dNzN3szHBj3wjQMr5N+eE8nyQcbbaGnhoBb1WFQtF1dXK0sZavdZPt0QJ2VrubftVFtZwmoNyLzi FvP4xcHzrT3kOd7jvni4PU5ZlZEr6PTOOGq71bPVZocr5P/OeGdxTLCSC3to3dY4sL21Kmy/vObE edfMQ7Czp98m5tqKmn02nfOqZ8tiTkXtFeYAqWowVjGDuJNP1IvrOc0YEEZMYxm/xigxMAGLMnki IOTYBDc2sbSoUcIzvVaNLxbxi1v84iB2TLZ0sM2mRrDVGgZ5SDa0p9hXBQRp8TDjQBSybLbyp77x 2EQ88vgcbCd0djszXUCL/Roz+rvepwhVt+34bWf/09rIm3U5WXFmB8ThEGMRAkpGvTiijGENVXiK DkSwhZQEzAj16kEOpDAYkXilEJWkwZyXAIQ3EAEFbHjJyOXmhVm67wqIYMOvonCC/b1E4luVqiVX oIUZCCL/DSMowQCj8BQ1GH0MOao5H3b6akXT6Zyvk41jFFMo97xXYZ2NBXbusx/WkAYzVezNOYeD qP18TzKKMeOklQZFs8YnPquITGvqiJ/sxL3vY7wUn2QRivfEp+zUGNlCoBMdzuJqEdyRDEOwQT3F YJ4xRFRT322hGqwzRxZslzZtRr+YgcQm8LUuYzDAiAsnw2Y/0aEeVOxA8pE0STAWF+UCNAKikjQJ S3g5wUdqwBSbmAW7WXmtYc5wF68csnAybEIQPGT85w/sLyGZPmKAn4WZ8Kr3K6ELqzWkP2NRhTBa +UlPBjMWeaEkCzmaiRTQUiOp4plTW3Sdp/74bCyyAq68/wrKuApx4IoPkQaa0AqYcEnC9JaUhQnK aAquPJrl4Y7IeMnVhEo32czxrAkpYKCtFF6SKdp7WUoQMaCYyJW/hYmsaEct6IakfIw7SBlxEOCo XMIMHsoLYoIGSspx5EZEPNqjyeAXcZmMVJILWQgYIMXuAYgQgMiQ5MQtgZpciEiLeIuMGIGCkA2E SAUSpsiVkMFX7A2KAM6NeI6TSGGRzMuxZMHB9E9OMcgYQo4LiYiPwB/ioAhIPA7+wVrWBQo4FI3/ HZZaGWEyDOD4vEopvIx9KKAGos6nBGFG9dezZYPWoEdvXEbIjJQGekwH9tYl1gzWqEyinQ+6wQJ4 oIyjlP/MX81dK5ZUx5TM09zMc1DPDSrid5SMpWTUl3yiA0ZESLnTi23akeAAMnEQHcwZsHTNUNRL FVAhghBOwQALBF0LiCRLlpCLDMlAE1DBTGxLIFwIGk6fvzzjvUyOsfiLTGXjSXQjFPqS3kRLHn6E CFkh/KnIWUkKIAqPcwSiq1TajM3CBM7DQtzgIk6C7PAjJJKOJHqgoElg+ohJ2+mOnmSgL14gMFZD 8oRge5niL75G1axiB65JLXKK0vRgX3XMQrxXpFVawvhQ3PlOwsSVJ2ZkRG5kf0FinhSjYCxfFT5T jGThE57LKfULjgCliVAjDaELT13Iam2jM0bIXmjECNz/TQpszteIjjWOkBtaobmompI4Tg7U4Ulw CB7aYT0qZR+2FLzNzg0Fom6sESHeTjqgHmcMRAKKnauECW3AQw4+Ip3cECiKR1utIhwFg6E8kR6N zwJuyZ7gpEmqQ0eGBtyR4PnMpWv4kWvMyW6MSmRwZg+JAjYs0ZsQGaNJoLBBYp/JxjowR84wkUYG ID6sQxohin5NQFMi4cFUwX8ESJEwI+iY0Ap9jdhEEpq9gAIFCwzEDwwwH7oYQU2ACBPKRVB0YQPV QFamodiUEDqSYfD5C4o1AfPBwSm5jbTY31h0xE4Uhucc5+PEwdUhkfZswv5xgji1ZtzNCjcBWwCK k0Ue/yRAUco8dQeuOMdJ1Qc7RabY9aJ//lAuzM45cRRKvQaCJhRBTeI/iROCeklEnVvjLQRF5UdB qSYj2NVloFOCUgNISVsqSGiYqBPWPdtAwIIo7IfmaU+3PWgkTFGKLqibWFE/mYNu2MCcZcTBfCFP HWMz/p4w8QXKAUJKcJAiYaW39EobOEUVhMEWAIEsKZIMeYEUHFNUAIGCaGc5WggvoUEiFckkNRIH fQuX5kuYFgUw2WEryUQUwMESDIgYINLjuIh8lhWSLRahLhZh1RV7hcqJ7pXGeFZZLRhwQdZnRSpe 6eOftRWiJlilRhZmpZWmvtVgNSqlhuqijWo4nKqlVv8DpuaWZKFVK8SWUEqViGmVVW1VhVEYrTrV TSkVVA3dWCHVUg1QdlHXVvHqkfxqS33LGvxqVomVVcGUV11VDNCqEAjqkCEXo2HrtnJrt3rrt3or VY0AsZZauZrrbd3FucoWi7QluDZXorhrvMrrvNKru45Zsqprvurrvn6ZFFpXifFrmf2qrloVsQ7r dgFsvhKsTRXsV6XWwiosa0EsT5HrhVVswtJWwmLYw6qWTOHmLxiYcbHqtw6YbgWYc9UWqQWsTI3A VbCZmvnUqbVUGjxXmE3sbLEZO8YWs6jsqC1J/6zsTMGsTL0sa8msUMXZdLHZ0ULXt6Qh+2wFVakZ nWT/RqiA16WBa28p6kpVbNB216nNC6qVH231LHcxrWwNbcz+rNc+19luV9o6wY247WipLMymGtC+ DZ1oq3DVa3G9WGjVgcZZgdBV3BO8AFVYgRfoAE/xgNy40lDeD9IpQeNaVeMGLrjwqRXUnBOYwAtk nBmsACKAREVIHBTwz8xtiMDoQMhhHAQNgR9MLg3YHA5gbr28RD1SUui+ROiiwZkJhhXYQBHQgBV8 RBvsVOCqXOnOwC5hgemqUBYiQR78AewSgfwVQQsk7+UKSFpUwe4Gr+wOwtJ1QRHUQRD8ARXErRc4 bkewbkpQkuegAckdAfgiAu9OLclUG0sKm7ctxAPy/8O16QKUbZa/ERrZeZs4OIMuJIOz/cO82SVB cC3j2gH75sURUHDuVV/2CYYCKQVU/MXAeFVwUl9RYJ8Hx5BdTAQKP0UTHF+wxF9SdARH2IFKxLD0 zoX4SQj+hAVHsEgM9x4mFSkVXF8MTcUGH0VUiAsPAycKZEhd9O7urfBVqDBVDEVf0ISwyh8Fm4RX fAGLzMUNe/ErafD/fIUQOwgNqXDzeQQZurD17UpaAEZFrN+eZjEKlyd27spe/E/y0bAYwLBW6jGY yh8T1/BW3C9kuMnevR5rlFGG7kbrvUY9YAOcwI5wpMwmCN5zVBFotCgRekbmTYaSsRSBDIzIiWFR Fv8OiyDnC+wIhZhhwTjhKYtc22TJK5/QCL0ILcet4pwLkgiB/C3OaTEn9hJJ18BBjPAIPLpwsOoy BYGalGChCP/yCWwpz67yLotxFYucLPVAKduIMKMQOAPO025nGCTFGqzBBmnzN4Ol/ezNG8dAL8Mf KcPFMRsfTCnIGf4yLxNlPouLLxtVlBzy+QTg61nGTTqyRtqlaVzNJ7cJ9XTMBcrgpcTJFOFCC34K q4gyTpAZsUwOryijVlppMOML5bRZcH5cTnBLSYczNjtzONJuG8PjmzGOEuaIsiCdMX9lhyizEpq0 s0DvaSFdEsPjxmHpsVhzNi+zMwMIEMBURzclObb/9E0vZTZPTvCGywh5dDS50Dem66g5tTy7EJnJ rVjknm6eYRzUdD+b9OcYdUUgtcd2lJJhx07izANO4syIEW3gQiNqjCxyopL5dSnISm3CooyOshAM DOYYCYjwKf2sct7ERTO/DUpP5VVOtkmD7drOY0v9x1q7tdnws1QfiFHqtFcG5zIPkFJmsyT5M1Ee ZTzHNRQPpRIytWN7scsqNuiQDWnvC1VbdRbeywD9zb5gI2PD4UkMiQjMiBzkdlmuNajNTUmEZcGg Njw+7Xnui2xLjlwvg54hTRYh9EMGIXZMVIzOZPBUJO/MpOlkw0FVA01uNOOyje7VT539wQwIt7dw /zD/QKfuPctvTqe/INDa+A+oLbVw47FMi7VUNIm7fE2VdGdxcs6CpLYN1Fl2HmdrZ4UEEbUoYW9G BIgJ0fbXJLhWyoAhXAX8dARx+jZcAPeBB/eIQ5yHdyVTJvcxTwGxpHgYxiOL1/Mu+Te6OCdyPpOJ HxAVf45UIMWIR+FS6W2l0cJuxOZDFSYiEsdHPSgVnVVpQhGlvAeX64aEbgMP9dF8v+7y1pL/KNJR fSE5048pRaspValVLSkqnRIpGSud37JVMrWe73JwCsmXmviLq2lf3ICUTlJU9HQl2ZIm9V42W+UX kEBHMKnGeZKj63eJk5mf7/cIfMFWMVI1I2OE///2MK+Anl5zFJZpdHoS+57NmkfSOrrQmH4LqL+E MynhqKf6VwIxulB6nS86ZIvSwABBpDs2DXwjLdHEF3wOwsz1YNldii5U3U0iQNmg/sbTnpXbE8UT P7lTDGIUNtnoN6F5XIRVUmkLTsiqTFWX98qBrp7zrKZ7dk2rTSXrs6oWvvoUrsaAsfI7vfOUrt7U sYaYsc6WwWcSiHmVvrOWv/uUWHnVEyyVw0e8wj8BhVi8Vx0rgezKvOP7ik0XUBm8iGkWc03qq+ZW yGaqoT6qyvcVZb08hKFsUJ3auKYYyzU32/J8z/v8zwN9bKGWzvr8ZJ3TyPbtttb8mvlmwCvrVwf/ fdRL/dRTvb5mxUwtq9fyF9InPbaG3WWBfde7g29B2GSVrLxyPX7NTsr/laHimNv3B9xn68cCV9mX fdoXlqvSfdeXfWD1fWDh/W5l1tnLvNx3FltdmYx2PdYiQ+JjWuCrF+Ovl5CxTmE5/nrt7WViq6AA l9Ym9P+tVKGpVRtFhOfXa+aPvgfmluQDlw7uJ6UF19c7ptgbGu3/FuunVyzCay+ifnj1vuIPmenn lumb/qGh/hTtvu0n10vOK+obP/PL/Fk1BM3YkbL12o0lVLkbXLMlVDpw/5T1b+uBmzqQgy/0GnAQ 3LuFhwIzxLgZXMocW7aFdyW8DralW5U1m9gR/3AlVD8IFAPwTIEYTOp0KMCgqOeQKmN7FEWQTkI/ sQEEhVfMhFpNHq/CYfkiBQMD51LkYmFVAEVhRUxKJ2PoqKSgFogDgbb6BJiAbyuAKj1U70p9MZUD ozKgYmOVZPi0ghIAkMQTNECjxCSINNnyEiDE4kLD2VJ4kCkYGthjI8gIuEWGV7Iil1bF5ja7JuJW KfWAJftEdcY5kyIw1POjpLzyAMvSJjDwJG080WatuCR9MrHDlELTG8MXXjAOLgOeQh6k0CvwIO2q J1CtEHNPJteoNBR9EC9bwBwHopXoUsLbDoPOVsD4Zg3JA26Nmjnhc2egFRX/AsYTQJCesQf39P9w ASJSnjSN2fhtagcTwD5ZAZjI8UYOHhgaBNNoUZIvn0wyBSbedMOPEKRFSOVM4rMmHp2ok3CiOzHx y4kDWLmtOPGjKJE5OR6MXXHv3UeC//TUdNK2XEE5ZOqtpHZUj1GLXJ1AsmptHR1CQx0Z1Uf0cFB8 NQvDG3AwAD2Wxky6WrasmRJC1epWk5fNxBHJX0w45YIUXd05EVkTcm2tBEgWLNh9fmJyiA+6qDvr lnEkjW83OYB3Xibv8+puT0rkMAZIdCEgw19OiVjt7+OGnOkeCw6En2Z58VZ/LtGo+O7WYEoL/5LP YXPCqdc3T8p6xf3TZN2j9K+ecr/BJceA2WT/14NSpDm3mWxcgdfZa/7QJWE93lnYGwABluDcGgiq h19+g6wGSTW6lejUfLGZtppz7Fgn3FHxNITZEtyt59k+RbjxFXV0KUeiaieqBslrRbJXSBU7YMdf RLodlyNqX0kiSQDD4WgMlJtxdNoLVMLTxBo58BFMlWBcuNSRCIrGz5bVUTmJCkx4Yw2c5vGXJZxN cpkONhsNYueQ6wUzlIJKEMofD50thaOiejoJJ4ZeSsLjoAmyZoMCob3W5xwRZjhilKJOCGUlOmCo 6I+JDhbkeoJ+ZudrJtqi5FVwWrlPGrzVKOeNw1UDUCPh9WBlaUAKWiFsyh4pK1dSqOkUh/Th/wjq cvk9ceVZWe665XrT0hbfENh2sVRo1YHHJGt6+OQmmj2E1kwLX3AahxtAbtsrkjj6dE9pDunXamVW KMcoQd6ms6iPCNM13nLjOqzEmhFBEixk//rw4HSfilrhrxfi6wNJR0zoqbGrbvlqgfUBSZusKlcE W7n2wUAHr5r963FZ16lQ3FjysNNqskXGQSQ6ut3xUi/omJgCP0/uSrK1RER2JTaudAbQZjVcReEB utETlcCRnYlaWb1MY6kKItDYXdlFXTadNpeN9fRlWcjzEqccrTSwJbEU80XKZxUq4uAny7OkfN2A A0wMSslxdnaQ/ymxgm2uEYsbd5hNYKhRd//8xUcexxbQ19Dsw/hlRrKacsAFAm73yzEojd3bd/hm caU13qz2Gh/LUsSfQeSChA4lCC1kfV780dqROeigjSP5nCqHHi/US+2oui//RdUnGF/1IMEff4X0 PozwxwmO1KCDvzjqtrw73fieX5tKUC8l932gD8gI19T9vCIg4Xr6CoM5YCGP/b1Acyu7iQ68MLGp PHBeffpe4mTQvqYVQSXlM8cz3BG8I/CMZpfiQS90sKsAFuKBZqFQtZKFQg/9rngxiIYjMkLC4r1t dShroOuesUAtoLAuYzJHDIynv0W5kFc2ooROalQPzMyGZ7pjYo1GYUUWVMoszuAiM56YRSbzFsSK Y1TGFAdhFilmo4xUdAYbxbhFMKKlZkuQo5zeKKczYsxmoSkIjZSBRZ65L2KhgWIh1SjGQ7Kgj3bc IxU5ckg8mjGSupNkGMHwx2UEUot9qGQVL3lJswjkkF7Mo3M+ya4s8g6UrGylK18Jy1geShl6k6Ut leGFTN5yl7yCDi9/CcxgCnOYxCxmLkOpy2Iqc5nBpCMzsyiZZwaTK9KspjWvic1nRhOZ2eymN78J znCKc5zkLGc2V2nOdKpznexspzvfCU8bNWOe9KynPe+Jz3zqc5/87Kc//wnQgAp0oAQtqEEPitCE KnShDG2oQx+K0BAAADs= --=_NamoWEC-kp6oaeupb6-- From nobody Fri Apr 25 03:31:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90961A0148 for ; Fri, 25 Apr 2014 03:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 IU8wusilgc3M for ; Fri, 25 Apr 2014 03:31:02 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 96FA51A0139 for ; Fri, 25 Apr 2014 03:31:02 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable167.97-201-24.mc.videotron.ca [24.201.97.167]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 4CCD8F22BE; Fri, 25 Apr 2014 03:30:55 -0700 (PDT) Message-ID: <535A395E.7020103@mozilla.com> Date: Fri, 25 Apr 2014 06:30:54 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: kiran.guduru@samsung.com, cary.bran@plantronics.com, rtcweb@ietf.org References: <2F.4D.32015.9273A535@epcpsbgx1.samsung.com> In-Reply-To: <2F.4D.32015.9273A535@epcpsbgx1.samsung.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VdhsoGfoRBeFwhdMVq3bTHdzmwM Subject: Re: [rtcweb] Query Regarding Mandatory audio codecs draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 10:31:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/04/14 06:21 AM, Kiran Kumar Guduru wrote: > Is that means spec is recommending G.711 (PCMA/PCMU) for sampling > rate less than or equal to 8 kHz? No. Opus is still a good idea for 8 kHz, but it's not 2119 RECOMMENDED since there are valid (mostly complexity-related) reasons to use G.711 despite the higher bit-rate. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWjlaAAoJEJ6/8sItn9q95OkH/R6aJUdypTfLSz3YUjFUv8Ql m7ISOCpfp/UE7SvdFBLLXjyqZmqiIPdwcia23AThhJpUcZLtrHHx+sJ5Osei05Qb BqjnIdiAnXLSbbhtuCiGcUgDPtFHTAPiLAOgvYvTe5O+PxnUVtANkDck/DJKdmKs JACGfMH7/8YB8S0hjQLB7oMtOQo92vS9nlswRrjNawVkquwM2fiR/fGie3DM6zeH vBHBTo/B2ZpSHg5SnhHFZoCKPzAEHe1ieMFzI0IMiC5DvMWkUNzdgN+WuRUXrSw2 13E9CKeHNT9F0IIaw2D7R0X0OSu/A1cuXC+nmMVJP5mwWTN0J/SnmVfpyYcVfY8= =rcxU -----END PGP SIGNATURE----- From nobody Fri Apr 25 03:38:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C22F1A038D for ; Fri, 25 Apr 2014 03:38:34 -0700 (PDT) X-Quarantine-ID: <5Ah5kPIlorvH> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -4.05 X-Spam-Level: X-Spam-Status: No, score=-4.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, STOCK_IMG_CTYPE=0.001] autolearn=ham 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 5Ah5kPIlorvH for ; Fri, 25 Apr 2014 03:38:31 -0700 (PDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by ietfa.amsl.com (Postfix) with ESMTP id 511201A0148 for ; Fri, 25 Apr 2014 03:38:31 -0700 (PDT) Received: from epcpsbgr2.samsung.com (u142.gpu120.samsung.co.kr [203.254.230.142]) by mailout3.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N4L00LP11K01810@mailout3.samsung.com> for rtcweb@ietf.org; Fri, 25 Apr 2014 19:38:24 +0900 (KST) Received: from epcpsbgx3.samsung.com ( [172.20.52.126]) by epcpsbgr2.samsung.com (EPCPMTA) with SMTP id DF.65.14563.F1B3A535; Fri, 25 Apr 2014 19:38:24 +0900 (KST) X-AuditID: cbfee68e-b7fd86d0000038e3-0f-535a3b1f4c9a Received: from epmailer02 ( [203.254.219.142]) by epcpsbgx3.samsung.com (EPCPMTA) with SMTP id EB.8C.11443.F1B3A535; Fri, 25 Apr 2014 19:38:23 +0900 (KST) Message-id: Date: Fri, 25 Apr 2014 10:38:23 +0000 (GMT) From: Kiran Kumar Guduru To: Jean-Marc Valin , "cary.bran@plantronics.com" , "rtcweb@ietf.org" MIME-version: 1.0 X-MTR: 20140425103508607@kiran.guduru Msgkey: 20140425103508607@kiran.guduru X-EPLocale: en_US.windows-1252 X-Priority: 3 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-EPTrCode: X-EPTrName: X-MLAttribute: X-RootMTR: 20140425103508607@kiran.guduru X-ParentMTR: X-ArchiveUser: X-CPGSPASS: N MIME-version: 1.0 Content-type: multipart/related; boundary="=_NamoWEC-g993dl39iq" X-Generator: Namo ActiveSquare 7 7.0.0.45 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFKsWRmVeSWpSXmKPExsWyRsSkTlfBOirY4OpZZou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMbfrBmPBhy2MFTMbPjA3MP5ez9jFyMkhJKAusWH1PTYQW0LA ROL9lHOsELaYxIV764HiXEA1SxklXv3tZYUp2vz3ExNEYg6jxJVX54ESHBy8AhYSM0+4gtSw CKhKvHn2CWwBG1D9rxNrwGxhAVuJu7fnsoP0igj0Mkq865nHCnGFksTaqzfBbF4BQYmTM5+w QCxTlZj4pYsZIq4m0XPqFBNEXE5iydTLUDavxIz2pyww8Wlf1zBD2NIS52dtYIT5ZvH3x1Bx foljt3cwgdwM0vvkfjDMmN2bv0ADQkBi6pmDUK1aEv8v/WaHsPkk1ix8ywIzZtep5cwwvfe3 zGVCdz6zgJPE772/oGZqSjxa1MoC8ruEwB4OibMTP7JPYFSahaQHnQ3TD2EbSnyZ95gRwlaU mNL9kB3CtpNo/t7PhimuKnHlyDXmBYwcqxhFUwuSC4qT0ouM9IoTc4tL89L1kvNzNzECE9Dp f8/6djDePGB9iLEKGHETmaVEk/OBCSyvJN7Q2MzIwtTE1NjI3NKMKsJK4ryLHiYFCQmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamCM3Za5rDl0zd3EmlU8z9ndXD3dllq/b4o6n6Dd0Wzy9d3z M3aWr5S/fb38uEvcTm+SIu+GiJ64pCSbHOPF91JSMuWP/AlmqY5q8738tUblAe/FEqWLLRvN lx1Y/LXq1b1tDGysuv6re/vzz298sqShxD9xcv6uHO2cH+w7PK7OyD7PIjzt9hQlluKMREMt 5qLiRAAVh27BbQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOJsWRmVeSWpSXmKPExsVy+t/tPl1566hgg0/3DCzW/mtnd2D0WLLk J1MAY1SaTUZqYkpqkUJqXnJ+SmZeuq2Sd3C8c7ypmYGhrqGlhbmSQl5ibqqtkotPgK5bZg7Q VCWFssScUqBQQGJxsZK+nU1RfmlJqkJGfnGJrVK0obmRnpGBnqmRnqFprJWhgYGRKVBNQlrG 3K4bjAUftjBWzGz4wNzA+Hs9YxcjJ4eQgLrEhtX32EBsCQETic1/PzFB2GISF+6tB4pzAdXM YZS48uo8K0iCRUBV4s2zT2DNbEANv06sAbOFBWwl7t6eyw7SICLQyyjxrmceK8QGJYm1V2+C 2bwCghInZz5hgdigKjHxSxczRFxNoufUKajNchJLpl6GsnklZrQ/ZYGJT/u6hhnClpY4P2sD I8yli78/horzSxy7vQOolwOs98n9YJgxuzd/gXpSQGLqmYNQrVoS/y/9Zoew+STWLHzLAjNm 16nlzDC997fMZUJ3PrOAk8Tvvb+gZmpKPFrUyjKBUWYWkjJ0NkwLhG0o8WXeY0YIW1FiSvdD dgjbTqL5ez8bpriqxJUj15gXMHKsYhRNLUguKE5KrzDWK07MLS7NS9dLzs/dxAhOa88W72D8 f976EKMAB6MSD+8E2chgIdbEsuLK3EOMKkBzHm1YfYFRiiUvPy9VSYRX1iQqWIg3JbGyKrUo P76oNCe1+BDjREZgNE9klhJNzgcm47ySeENjE3NTY1MLA0NzczNaCiuJ88bfSgoSEkhPLEnN Tk0tSC2COYqJg1OqgXHaWfeFzx4un/R7flywTIx49MOjPmtVODqdr9es3f516RyFhxeMrRZP qvsl3Jlb7jO5NNdyyYkT35dYNMwtl0qdbT4jqite9x/XsRUc5Xu/1/3ZdWxeiavIlujgrpPl a+b+F+yTL3ywvEt4qsqkom/c9fYrb3UK+v6+fWAq+ywXsedmvz98OHhFiaU4I9FQi7moOBEA NoYWj+oDAAA= DLP-Filter: Pass X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1V5Tkr3CeesMbKmnekdmEFgCz5U Subject: Re: [rtcweb] Query Regarding Mandatory audio codecs draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kiran.guduru@samsung.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 10:38:34 -0000 --=_NamoWEC-g993dl39iq Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: base64 PEhUTUw+PEhFQUQ+PFRJVExFPlNhbXN1bmcgRW50ZXJwcmlzZSBQb3J0YWwgbXlTaW5nbGU8L1RJ VExFPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiIgaHR0 cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8U1RZTEUgaWQ9bXlzaW5nbGVfc3R5bGUgdHlwZT10ZXh0 L2Nzcz5QIHsNCglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1B UkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0NClREIHsNCglNQVJHSU4tVE9QOiA1 cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1T SVpFOiA5cHQNCn0NCkxJIHsNCglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwg YXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0NCkJPRFkgew0KCUxJ TkUtSEVJR0hUOiAxLjQ7IE1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsg Rk9OVC1TSVpFOiA5cHQNCn0NCjwvU1RZTEU+DQoNCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRl bnQ9QWN0aXZlU3F1YXJlPjwvSEVBRD4NCjxCT0RZPg0KPFA+RGVhciBKZWFuLU1hcmMsPC9QPg0K PFA+UGxlYXNlIGNvcnJlY3QgbWUgaWYgbXkgdW5kZXJzdGFuZGluZyBpcyB3cm9uZy48L1A+DQo8 UD5TcGVjIHByZWZlcnMgRy43MTEgYXQgOCBrSHogc2FtcGxpbmcgcmF0ZSBhbmQgUkVDT01NRU5E UyBPcHVzIGFib3ZlIDgga0h6IHNhbXBsaW5nIHJhdGUuPC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+ SXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0PzwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPiZuYnNw OzwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPi0tLS0tLS0gPEI+T3JpZ2luYWwgTWVzc2FnZTwvQj4g LS0tLS0tLTwvUD4NCjxQPjxCPlNlbmRlcjwvQj4gOiBKZWFuLU1hcmMgVmFsaW4mbHQ7am12YWxp bkBtb3ppbGxhLmNvbSZndDs8L1A+DQo8UD48Qj5EYXRlPC9CPiA6IEFwciAyNSwgMjAxNCAxOToz MCAoR01UKzA5OjAwKTwvUD4NCjxQPjxCPlRpdGxlPC9CPiA6IFJlOiBRdWVyeSBSZWdhcmRpbmcg TWFuZGF0b3J5IGF1ZGlvIGNvZGVjcyBkcmFmdDwvUD4NCjxQPiZuYnNwOzwvUD4tLS0tLUJFR0lO IFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tPEJSPkhhc2g6IFNIQTE8QlI+PEJSPjxCUj48QlI+T24g MjUvMDQvMTQgMDY6MjEgQU0sIEtpcmFuIEt1bWFyIEd1ZHVydSB3cm90ZTo8QlI+Jmd0OyBJcyB0 aGF0IG1lYW5zIHNwZWMgaXMgcmVjb21tZW5kaW5nIEcuNzExIChQQ01BL1BDTVUpIGZvciBzYW1w bGluZzxCUj4mZ3Q7IHJhdGUgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIDgga0h6PzxCUj48QlI+Tm8u IE9wdXMgaXMgc3RpbGwgYSBnb29kIGlkZWEgZm9yIDgga0h6LCBidXQgaXQncyBub3QgMjExOSBS RUNPTU1FTkRFRDxCUj5zaW5jZSB0aGVyZSBhcmUgdmFsaWQgKG1vc3RseSBjb21wbGV4aXR5LXJl bGF0ZWQpIHJlYXNvbnMgdG8gdXNlIEcuNzExPEJSPmRlc3BpdGUgdGhlIGhpZ2hlciBiaXQtcmF0 ZS48QlI+PEJSPkplYW4tTWFyYzxCUj4tLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLTxCUj5W ZXJzaW9uOiBHbnVQRyB2MTxCUj5Db21tZW50OiBVc2luZyBHbnVQRyB3aXRoIFRodW5kZXJiaXJk IC0gaHR0cDovL3d3dy5lbmlnbWFpbC5uZXQvPEJSPjxCUj5pUUVjQkFFQkFnQUdCUUpUV2psYUFB b0pFSjYvOHNJdG45cTk1T2tIL1I2YUpVZHlwVGZMU3ozWVVqRlV2OFFsPEJSPm03SVNPQ3BmcC9V RTdTdmRGQkxMWGp5cVptcWlJUGR3Y2lhMjNBVGhoSnBVY1pMdHJISHgrc0o1T3NlaTA1UWI8QlI+ QnFqbklkaUFuWExTYmJodHVDaUdjVWdEUHRGSFRBUGlMQU9ndll2VGU1TytQeG5VVnRBTmtEY2sv REpLZG1LczxCUj5KQUNHZk1INy84WUI4UzBoalFMQjdvTXRPUW85MnZTOW5sc3dScmpOYXdWa3F1 d00yZmlSL2ZHaWUzRE02emVIPEJSPnZCSEJUby9CMlpwU0hnNVNuaEhGWm9DS1B6QUVIZTFpZU1G ekkwSU1pQzVEdk1Xa1VOemRnTitXdVJVWHJTdzI8QlI+MTNFOUNLZUhOVDlGMElJYXcyRDdSMFgw T1N1L0ExY3VYQytubU1WSlA1bXdXVE4wSi9Tbm1WZnB5WWNWZlk4PTxCUj49cmN4VTxCUj4tLS0t LUVORCBQR1AgU0lHTkFUVVJFLS0tLS08QlI+DQo8UD4mbmJzcDs8L1A+DQo8UD4mbmJzcDs8L1A+ PCEtLVNQOmtpcmFuLmd1ZHVydS0tPjwhLS1raXJhbi5ndWR1cnU6RVAtLT4NCjxQPiZuYnNwOzwv UD4NCjxUQUJMRSBpZD1jb25maWRlbnRpYWxzaWduaW1nPg0KPFRCT0RZPg0KPFRSPg0KPFREIE5B TU9fTE9DSz4NCjxQPjxJTUcgYm9yZGVyPTAgc3JjPSJjaWQ6QkVJMFhUNE5aNUpFQG5hbW8uY28u a3IiIHdpZHRoPTUyMD48L1A+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0JPRFk+PC9IVE1M PjxpbWcgc3JjPSdodHRwOi8vZXh0LnNhbXN1bmcubmV0L21haWxjaGVjay9TZWVuVGltZUNoZWNr ZXI/ZG89Mzc5YTYxMDVhZDU5ZDc2MTU5NDlmYzdkOTAyOTQyYjZjNmI3MDBmYjFmNTEwYTJhNTJj Y2FhYTVlNzhkNzkxN2E1ODZhOGM5OWRmYmZiYWIwZWRiZTY4M2M4NTNmZTcxZGI5ZmRkZGRhMzNl ODJjYmU0YTM5MTQyNGU2MmZjZjZjZjg3OGY5YTI2Y2UxNWEwJyBib3JkZXI9MCB3aWR0aD0wIGhl aWdodD0wIHN0eWxlPSdkaXNwbGF5Om5vbmUnPg== --=_NamoWEC-g993dl39iq Content-Type: image/gif; name="201404251608216_QKNMBDIF.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhCAKQAMQAAEdHR4yMjLm5uQICAtt0dCoqKumiotTU1PLExMpMTG9vb9RiYvfZ2fvt7eSO juvr68k6Ov/+/jMzM////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C1hN UCBEYXRhWE1QPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtj OWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUg WE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAgICAgICAi PiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5 bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXBNTT0iaHR0 cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtbG5zOnhtcD0iaHR0cDovL25zLmFk b2JlLmNvbS94YXAvMS4wLyIgeG1wTU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjc5QkEy RTkxMTJFMUUxMTFCRjA5ODE0RDA4NTQ0MEQyIiB4bXBNTTpEb2N1bWVudElEPSJ4bXAuZGlkOjk0 NUI4NzE1RTEyQzExRTFBNzY0RUYwRkU5MUQ4MTBGIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAuaWlk Ojk0NUI4NzE0RTEyQzExRTFBNzY0RUYwRkU5MUQ4MTBGIiB4bXA6Q3JlYXRvclRvb2w9IkFkb2Jl IFBob3Rvc2hvcCBDUzUgV2luZG93cyI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5j ZUlEPSJ4bXAuaWlkOjdBQkEyRTkxMTJFMUUxMTFCRjA5ODE0RDA4NTQ0MEQyIiBzdFJlZjpkb2N1 bWVudElEPSJ4bXAuZGlkOjc5QkEyRTkxMTJFMUUxMTFCRjA5ODE0RDA4NTQ0MEQyIi8+IDwvcmRm OkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8P3hwYWNrZXQgZW5kPSJyIj8+ Af/+/fz7+vn49/b19PPy8fDv7u3s6+rp6Ofm5eTj4uHg397d3Nva2djX1tXU09LR0M/OzczLysnI x8bFxMPCwcC/vr28u7q5uLe2tbSzsrGwr66trKuqqainpqWko6KhoJ+enZybmpmYl5aVlJOSkZCP jo2Mi4qJiIeGhYSDgoGAf359fHt6eXh3dnV0c3JxcG9ubWxramloZ2ZlZGNiYWBfXl1cW1pZWFdW VVRTUlFQT05NTEtKSUhHRkVEQ0JBQD8+PTw7Ojk4NzY1NDMyMTAvLi0sKyopKCcmJSQjIiEgHx4d HBsaGRgXFhUUExIREA8ODQwLCgkIBwYFBAMCAQAAIfkEAAAAAAAsAAAAAAgCkAAABf/gI45kaZ5o qq5s675wLM90bd94ru987/+5iXBILBqPyKRyyWw6n9CodEqtWq/YrHbL7Xq/VhF4TC6bz+i0es1u u7Hit3xOr9vv+Lw+/Nj7/4CBgoOEdnGFiImKi4yNeodDEkSSSZRKkpYSmpNFmp6WS5mfkUKfmxOg R6mkrKWnpa6eraimla+ioKu1sJWhRrqRo7y7qLGblKmZs6qdwsW/r8+0ub7Tt1TOzLq7uJydrbmm 0eJTsuDj1UaQvMPO26eY7MrL0sayyd/19JOr7NLzzwAC3Dev3z5wwajZoycumr536Ibl+5dwFD55 vyoiQ4hRYseJB6GRMsiKpD6K/pj/pTxpLVvGXgm9qesDEtjKjcVworyJRGFJc/1I6hzJEaVAfi45 YiLHUuPHozxBBjQn06dLYlTrXdxZVCdWpUVlnmOKM57KjQ1vNgzH1J5Jr2RbwuuKZJ3ZaVVfon3a LOksagrjigzGCarRsVAKEo350uNOXA7lovPpz2pKw38nDpQnzDBUzBqzBvS2VxtCtnkrbxmaE2nP sZGFQFKsWe89xiudWP6oOgrtx3wli45VMqzY0cG5NsGMjKpZ1qC19r0GzWrElj+dqxS72+JrpNE9 r1269vvuf9ejy6b5sD1DiSaxHSZd0/c31NmpX/HK0KZn4+l4FBl/0LlzX0jHwfQd/3D21QdWa9Pd xiB4m1H2RHkMCnQMgOs1GFVpwoWW1F3xiTjgeAouuB2GFG5IHIL0JUeMW37JQaItJZbTVVrVzWhN jHelk1WOPbrDY4ovOibecB22KJV/sLwlxW9uBbjdJVZKpWVmSDYmI4cHtVVlhAaJOR82M9o04ZVs Pgmfblh6mVuCdNa54H9zzmabnD9CGCKM7Vmo3HJ8bokgi15uxsSJ1mnX5UmKCqqmcUGK2CZkRjr6 56P9LWbonEUOeSSil456HV4H6flpU4XBSGSijb36XpwqFpqionGWGJ+UfEaa4KSgglrpr7MqmON4 5B3Zqq3BEnvocihCSmutQ9jlI/+zmilLaq1ibqsloiyGqyyt3o7DK6dzmmmmXD1d2+stsXU7bqzz ehGUqetuuqm3odTral3sOSLwwAQXbPDBRKyD8MIMN+zww2YoDPHEFFdsscUSX6zxxhx3PEjGHocs 8sgkl3GIYF+lNpWmGR077YVMrsqadOiqrAQEOEMwBM4759zzzTpPkLPPQgfNBM9CIF200kof0fTP SQwtNRFSPw3F0FCj2mx13Llrp9YsuYwusPoyO+wEGc9MXm08ieopcRKm7OyiLP+odlWnVolrEUhX nXTQfQMu+N+EF1340UYHXnjgWBtO9dROGx0535I/XnXllJM7Lp52xpYcYXQ2V3f/iwPC2vXb1QaM nJrJYCh3We4N6mu2gjnW26T8RWUzEoo7zjjRvQc/eBNMD+935o4vbbkRVlMOedQ6F+83zzye+3m+ tqt8kaDIfUo27myDmLDqN2J32YO4wb7V7JBu3lv2gR1oDICsj/u78Isbr//hQN+/P/LNQ9zlrMCz pzVuaZgL1voA1Qx+xOocDgxbboQyL3CFL0pHsMt0+sK27qXGO9pbiO64xBvogOeDnxsh8YiWvAP6 L3+NC6DzhofArEHNf89zwuUOyLzoSQ5/SWJV+wITrSnljVoeZKCs8mEgu2WQPWmZ2UOaWDv1ddAv QzJdZeoWv/PlbogSImACb/g//zESTobJO1zzZLhDFl5th/krnIbO8zIyiC6KZ1GF58IUrSDR5mwg a0dnuGDFEEqQTA6p0XG6uCgwGaWIWQAiAnM4uZ6hsZIthKMU2oi4HhYvhYPql7oguZ882gpZXfJj cfw0vizN7S9pepMhW2c9bC2DkWNaUwefMEAb+q6MmHyjL5tGzDHyz3I8DCbvjHmnWQnlXzUroV44 OMUlvgxP4kvd1441qkQpg5Z4ueNcakZLEIbmfYi5ZbhWiLxJxhBy0jteGn05Q3gaMHGabKca8wk9 T8ozi6sqob+2NhDXcWNMd2skOj14jX6oCom9KlbLCIUkVKISorYj29cc+bh23v8TaPTsaA9BKtJl hlSZn1whJ+eJRnFeKx7lu5AvYCpRbCXUlXVEXZNohKnhgMtrG1VgGcR2zpzSK1+9/FtSMbnSAK7U nW4cqVLlWc9iLvWNVw3oAwUJVCF+ZqBexdFLwbqrJ5bsrGhNq1qlEMi1uvWtcN1YW+NK17ralWBz vate98pXP+S1r4ANrGDT8FewJWucTtnanapoS60aVnekaur0mBnJqJLUn5FbIz/PSNmfXXIJH+1n FD5rUkvy0IU07B/w8ElJ03rWnq49JlTRqLTZkPWQbpLW/FTY00QeY3RbXVlXUxFaq1kVtVed7O9m K72pTrKG7BwgG31YQNZS1Z//lEwpMp9H2n0Ok5m94yUw5/nLY15Xn6Jto9EUBpeDBuUsQJnmKkkz ugVq9TNH9VFxMadd2YY0nuX1ruGqW0zolva45H1tdTP32dBmzbip9W9pM8lg6UZYgKtF7y+TqTg4 ktbBtVVdEv1YvYnmZ5DzxSBsrtIfdSmlm6DVJIQXLNKnlpTD+CTjgN1IYPD6cIYJ5iyNX4vh7OYY gPzd7IN/eF4kZ3XJprVsgAss4SrTU7vsfV9BF4m+FA9FPcZCE/cQGbNgohbJOtysdjtM1Sef1M3M rdyQ2cnUJFuZziz9MTJPGuOSinfN1AWwedV74/UGzHVhocz2IKupRcMMe3qw//B2+3vZdwp6sgZe blVhO+cKD9nGm0au4I7bWpWOWr001rRKNTwFAqM5wKPN8E6/NRl+tQvSQuQq9so5SnJcFFGoFm2R kwldHDu3vD0mY3crHOQdd/rOf76wn+Oc5PD2GdmE7mSwtyBJrNIwbaUMVZvGvSVdraaxrPpwZ6Wa 2VMze8ecLbZ1l8ndwU23hpo1db3jLexN2pvJ+4Z1q9dN7+NJNo6hPvKQwU1mxX4PkbHD6SvFOqJQ 7RHClT1woDcMcNY6F8Hs5je88zy1fE9b43vuN7RBnufYCnzVJ59wlQVN3v2mHG1Q7KN8s3RYoG7F lb+mKM+FyeqpohrOxyb2m/+lrHQHE7nZIw+2ui9rdIMTnN1Ol+qyRw7tQatcw1lvZ2ENmi9cW6lc 5ahgBS1Okhk32QvLpq0xnfp2kV/77ngPeZqRbkO+41CzHmduu0ttZbcT/nCFHaziF8/4KiS+8ZCP vORbOfnKW/7y2sS85je/+Mdz/vOgH5lt4xtNogKKREf8la9NBHHcFpXX6lSkLhvVuaacDaDUIqVj Gz62OqF+zC3GdS1hIjdyM9Bkh9453oDL9h6peEm1px+3BhM6ik/ckFxizjd3O6yvMl9Yyx/urcbv 3mnh3vhErK/0s8eZ7xM2+UxckfGvX0j88qYmLvL9blPs+l1qVISoUj7YpGL/xcE6uBFKBOggGLUU V/JMMQEYkvElr1Emc2OAulYR8oduyEch7BdK3LQu9Yc+exNTaGcdUdJT6bJI4idNv2F/lZJNupQT noMrwBc24aCA8sMVZ7MjMUODFRhcUhSEBEEHWcZ/96dY0WdOABUeotB/2Bd9E7R/RtRoq4RNYTQ/ 95J++gE6XLhQu6dFKHSC+Yd7TNhA3BFciTViiLU7SEgGJ7N6uJWFMmUeCRhmbchTeVMWpGQhpfMF +NAND6JKdahQX7gsugVGbRFTQ6gaXxRGezNTt/SDeNiBNLhHZ/BX7xWFouQ+o9FbjahHZgcn0AJW oDhQthZWAkIzrMR61URm/9rBPtbkJ0t0I5/Yfr5VRIqoinRBiGyYa5cIfzGSPtSUBYVEh0eIRLPo JEDnc/JBTlWog75IiTlFJR24L0b4J7QogQioiQz1LbsYjEkCTnMwetxwUAglVHQzF554gFn4UhJ3 iNH4fz/HiqhoC4vxh6XYGXCYezl4fOC4ir2gGIC4RTUILM/xPU2EjebILkmkBg/1LLliVJB4h07Y Mg7Ij0p0SuUmkdGoU4PYkRCpUBf1jkRCgcMnM6KIUbuEjsT3BuQoe2WVjl0VfjCZj85xg81XVPSo jA14a1iBLzN5kqd4kvM3hyq5TRxZjySZkkP5jmjgeaEXlVJZMVA5lVZ5lf8HU5VYuZVcqQha2ZVg GZZ+JWJiWZZmSQhfeZZquZa/yJZu+ZaGQJZwOZd06YZyWZd4CXkRsJd82Zd++ZeAGZiCGZhKkJZ5 eZhvNZiKuZiMCZiFeZeIGZl91ZiUWZmEmQSHcAACsJmb+QAHAJlJ8JkC45mhCZpOIJql+QSomTAH oASaaZpDsJoO2ZpMQJrVQpt2IAB6IJtWoJtr0JcIMJgNwACWuZcM0AB/OZyOiZnsoQAAUAADAAAA cAAA4JtRUJ0CEwABkATYaQQKcJ3WeQTd2QTjOQTaGZoFMJ1McADbWZ5pcJ5MIAAAQATyiQcD8Abs KZ7h6Z1PcJ9m8J1D0Jf/CTCYCEAAjOkAfkkAwemXBbqcAFME9SkE7ukEE0ox/vkEFToEGaqfRgCf RxChTHCeG0oGHqoEIDoBJ0oHF8oGJdqfLmoGK0qZDbqYA7qYM+qXjwmh8ymhCjAABdCaDwAA0Rkw QToAA9CePVoAfVCkAPAAArCdKLqdAQCdUCoEB+CcR9qjOzqlR4o2QvqjE9CjXRqmRvqdB0ClAJqk uDkB5ymmVRqmB3ClQvqdWsqmVDoBcjoAABoA0VkAusmlUMqnz2mdRQqmTNoH2AmobKqdvhkA1gmd dOqjrRkAPeqbZ1oAAQAAauqlQ0oECsCnhiqkXfqpPioA0KmbZ6qnVuqj/wDwpkXapQ8AqfMZq3o6 n5paAHYKq1/amm4qBJtKpmDqqWW6qHdKpj1KBNp5qkIKpWKqAEFqpTtqpXd6qGEKqnFaAJj6qtup AHGKpQDqq9F5pQUQqapqrP75q9LaqYpqp34apj36AIpap0LQlwbqAAaQAAtAnA2wAAngAPVKnAyA oAbArwjqAAlAAAG7AA7gAMQ5sAfbADfalzlKn9EqnWxKpxjrqWZ6n8/5AAqQsR97pr4aAA8wANeK mwJgsgdwpLH6mSr7o5l6sWfqpLiaqSLwo58apPM5pfCKq+YZADNrqkRQnSnrsnE6AAJQsidbtEqr tCmbtC+7tEhrnjsLsv/fWZ1Ke6bsqZ07arJUy55KOqVs2qTVErIWS6numrYaurPz+bF4yrG2Grbz ma2tOgF+WrJv6rYrW606y7cWi7QiELUxS6lBW7Nha7g9i6xN2rI8u7c2e6zmGbYqe58227JgirZD 4Kcr67EZe7ZNGrJ6y7GbabJKG5tIm7J9ULkw+7mUe7hD254kG7VKK7aaGrgnu7LWKaARQAAGagD1 agANwLu7G5wNmgDBmQAMwADGiwAJ0ADBiwANgLy7awARy5cTOwQgip316bUl20opOwF1271eu7ft OgDwmqZVGqH+WZ2Y+6kxKwKm2ge0Kb9+ar4oaqu+GayLOrN4OrSbuaP/2Em56Buh7Augftq+2mnA 1vm+fTC+oovA2lmyNEux4Ju/W1sEIqqb2wukK6q9s9oH35uo2ymfInu/Jfyp3nuf9huzKzyf/gnB Hxy//dudP0rDa0q/Twqlovu2yDrCXSsbeOqnbtuu0ioEUNuae+vBi4pzKCq6BBye9wmiOIydSWzB Grqdk4q+mNuef4q+ExCjfDmgChoBxYucvju8ZGyg0kucETCgMzrGAGuv1buX12vEFavBLmykRkoE qSqkFSwEKjwE9/mpIsunepy+P1zBhmykJPucJGusQPql9WvH4KvHUysEbaqna0q0AKyblGvJjtrJ 8Mm+oDzKhOrIDSzI/4pcyrCLwtiLvxKawxjMxff7xZbsv7Xcxzt8nvKZsnpcnVv6prr8xZTsn9uL yaAcpNkKyZWsx/Jpyafsowesw39MzD9by8RcqJqrpCt6ohe6w/V5nsPMybFMBFG8o9rcy4DczEZq nWdat4t8pCWaqKBszfMaxmhcvHvZoGPcoAM7xm2cxns5xga7AAtAvQb6l3WMzX98zFZKBES8w+K7 pFE8rt8Jn2uqvrGM0TgnrmjDnubrthVsv/XZnWsqzvBqv7H8xMTM0U9syhxtyqnj0fbbvewLpZMq pT2a0bBst7Lcww3twrGJy/UZ0X/My8C8HhFaokZtzEJdyy+M0x2tAP+46pl8GqSWWs1rKtI3vc7d uaJIvc5crZsWTcEoKsFoA847u52Y6tX/W86qHKFj/dVazcf3674PDZ+0zNH2PAG6289qvM8GCtgR cJy+awAB/cYI4LtmjNAOalZmHdTgO8I+C8ipy7EXbatSuqPY2poyXLeUbM1Eq6STjcJ4y9nqjLsf 27fvq7/aGbM+raFv/ccVjaihHMsii7uf7ai4irtDYNocu9kVvNvnWbKVTckx67hvusRKXLdCK9tQ fdlH7cNfnMXVbbdvusLBHaaazd3WvNvADdsHPKurizb6S8VIC58CzKZgTd3EjN66WalFYL4SDM+w HM7bqd3D3cnmjM3/8I22fDq25o2bd0vCpN2qIiu02nvg+W3Efo3PhE0AiO2v0xsBvssAC4Cc9prY Ca2gBoCg++rYCs2cOgrd9bmyQhqeVD2u5vuc0InE0em1lfzb2HrcGv3HK97bfUqyNT6fKfucrUqr zmnez/mtixqr2Bqt+13O2OqxNe7f8V3jUY6tvirlpuvIbyukrYmdOb7Ek13iSD61LcqnmYrHWX7J 5VyfK/6uIlzLU6rl7NrWNM7intmn83mp6WnPXY7i2drjRD6uf27kP56er73OSO7H16zRg+7cK4rJ 2LqxcK7EZL7mLT7b5YmtEbroPJ6e9xmrRY6sOx6mTy7qU9udXW63/9z84HspxsRroBhu0AbKvLxb rwtAAPkaAQat2NFr6ws7xxGw0E0gAGtqpcOetNVi7EigmVCg7LIh7NiLm8zOpqkbrc6OBNVem8Ye 7R8aMNqO7Alz7U4qYtouBPr7ocNeBHFq7eduBOm+nt7e7uh+w/Ke7IR67deOohl97uNuBPu5BNqO ufF+7HeZ7vCO7dy+nwh/7uEem+F57wwv8NvJmMrJl8kLnAsaARCLnH6Z8YoJ7BAzpXza7w4jp4g5 pSLvMfCKCA+g8cXZ8i7/8g7KqE8A8zRf833ZAMBr8zrv8iGzmZK58sV5nJUp9DtPmUQPnBjPxi5/ 9EPP8i3PAAjA9P9Mr5gT75dHX/UMqvQ1j/Udn5pUwJt5cPLxCQaoapqyCfa3KQVin/aYicSwWQS2 uQRAz5cIupgA3Zh3X/R2f/H4bACI/fJ+3/KB7/Kynvd5L5gI6ut37+sOcNA2n/gJzZhHkJ8jugQt qgWOWptGfgSN/qJeQLnLzaHQbe1K7gSdz++lX+KVXwTfmaJ14fQ1qpiHL/t8r/cuP/i3//eWifvF yft8OfuAGfuACfwJWvsvL/yNeQQZrAer7/rzTQWnnwXRL/pw/aGpnwXO/8pTcM5NMPcRYLC9i69/ f6+3TgAFTZz2iq/6SgAPi8bnX9jsv7DBu5fzT/EEO9CNT/H+mgD/iA0CjLM4DkM0UWQSkWFEzJI4 qpEQZjzXcbIQYKrdjxEJ4lKMX3AYQSwWsAYhubotGDKp7kZYIFwzmKhac+BEEWoiASOEVWoHllFn o1boshvdcrWh+KnhpdAVDU08AAwAPAgUFAQAKAwUHCgyOk4oVDoeAAhwPgQEcFqanl5OsE6UFgyI BlQKHMAquFoe2A7gTvCaMuJWrp5WtrqmAiRHplYeq2LOxrbyrgIENLJia08MJE9ASmYODAQTP0yE 5o63CiwvlgcImE6Gp24zt3s+LitgHsD14Ja/XQqEbeu1rJUnSAjZ4VOUQk4CBDK0JGhw0cCCIy0M 1CDwsUUJPUcQ/xhAwVEPlRZZXPRQIaWBlAgVJz5x0yAjgoxUENDZYdMFjJlBdjboGcZoUYtunNRM afNN0yVCZCLo2aBkSZEuBLGwmEWpDARIezLYiTEryRoyTg5B0MJrSioGtp4J6SBpAox3s1w8YmAJ W5NdRybqxEnBg06gls1aLJnSIgECzD34VsrWowKuHEFClu1A6EnpJA0MsEg1amwTCtQaQOqS6dKO oLEqxUpzgUeab//u7MozsnH2eq32xti1ZlOwLzfGZUtdb8WhbO2S7c6f9FjLGHGKyNv350UK3qkT hd76d8sDDmQ+YBr3r1iX4cvGfkA7qwc4h4KkAh0BugCXXAa20P+XDyc1EUEWGT3RloNxCBXhUE5A IaABB54kVYAJEJVhhASCIaJcb13hRAoNSAUiUSgGJUdHT6i1IBwWvtBhD2AQSAeHN4J4YAMp9ASX CgfeiGQYCi6BoAou3miEXUMdyCSISf4RgTcANZdeOMu8p8g365QySSiQzdPbL+qkUowrvtBmSmhf pjfnO5yF0w+brFyyzn6ipdKlN17+6dpr8kWkiCLHYYJemI4mM12eD6Rz2Z6DhhJZeNspUuk3nwIA iiitCDqmKI+gt46j6dgTCnrprZMZMoO+mqkvCuDjnxMg3tCGGzkOgaWTLg4Fx40nuXjgRcRaaCGz zb7w41Jw8br/oa84AAtHT74aa8NVgACRoLccAtvsk0NcGcaBOcKRLUrXbvgHkBbKgEO6cc2lbr4X FqvvuXChEQUMQYp7rrAqDLobOKqCWU45Xr6DqyT1mPIMJow4PCo46en2aqruOXwmMqk67N2o37Si 26Aqm6owxuXQk2g2BQAAJiuQ0tncq6zwAt46mNJTMj7o9fwNbAWchzKpG7d8c3s5O13nQmeePOs3 tQbtcK7/VSsHUTY4KSyEOzEYBxgQckhCTE/MWKUT0Marwo1SQFgth0OSWNgaSf1RbmBuh9j3VRya Nfa9676BkhDtCmGEtFS6FMe9R+6rpE0rHv4HlCjlkSPBl6+R/3ki2smqG8MJr+lnI5eRacoD8vU5 KiYpKxNzOMR9/CqlHuv588VV064wy14CzfPGPK+Cs/I2l8I7bC6faqrKs0f9/KAHYQMAcUsP76dl Ty8v9TbvRG81nRynQr1Eu+6QQhBvZSis/DBI1W4LTZbQkoAVva1gE8+ixUEMeBxHetA1BYFkCXxZ khE+lIKaHGlGXnGR5x74LZ/0pQn18xe7xOIDsbgvbtRyVgpuYCQLyS8MGqyc5uSGkhrQZGAopB8L E+Eae5hOPd+Rk2d+Fgl1aKdMC4GNPTKTjtx45k8su1gwRBGmyMgmPugpomwikw3R4MJSw7Pib8RE iojMqWbeqP+YKcyxqS5F8T1BHBMuWlULNRkqZ6zizTx6Yb4ttvE8O/zMng4iPo4Bx3xYw1McdTWE KGwlCjMaAf9SSC97GQEONBHYGnjwhyK9rSeI5FcEo1CDx1nlXDnyAgJ/AAZAVKGBpvyWIkdwoVGu 0gkcIYEPUumkDiYyCmEYQRSaNTcwkMSTGaSQ5Sy3BFsebHM7+UJJdHk/SDoJYfthhDTMcbppUuNn 4FEAcXQTCZplIhK+QGIzNhaAb6aDm0Gj5nCQVp/liFMRNIMFMqYJnuENRHvfWEQ8VdaKb3LTG9pT UyMikY4undOd3ETaewYapnUsdHt0WmglsqMaMyKjVPKkJnr/WCdGW0SiPVgzhtL4BJupiSKiyDCk CpKiBArR6G0yVZFZZGoRG5Swb2sbwgBnSrme+jSoLa2pHWRihDXUtKVHzeR/ZKqRmWphCC4VKlOd ANSZTlUOS6UqVpPKVaTiJKtgFWp/BHDEX6ivFY8466za6g711WJWzUsrzzSWJ0WYtRrUI83N4OrW R7h1ZLOKa2DvuhvAHtaus9qFXgfrVr4GlrGFnaxa87pS9b2OsvOoz6zW+ljFsvSrohUtR24QBo7A VLQcGm1QaeKAL7A2trKdLW1ra1vZUja3ut2tP3fr298CN7glRV1wi2vc4+r2MpMYZ3FDe1vZRutI qRVtUZ8r/4cXNNW62t0ud7tLVeSCd7CKDS95y5syuZo3veqlrO2QSym1Ui+zn20rfArb3vXKVxF0 naxlLMNW8+Y3vfWta38tO9kAuzVm/wUvqiyjXgTnFrG6fVtUvfvVtHz1qaLVMIUdt93pChXEo30q hqmaFg4LFcVcbcBZd7azkXUDGT9ra83OydzwNgYcWVzIbhtRszCZd8frJR4n9Fmz/Q6Wx2495yzU dNzN3szHBj3wjQMr5N+eE8nyQcbbaGnhoBb1WFQtF1dXK0sZavdZPt0QJ2VrubftVFtZwmoNyLzi FvP4xcHzrT3kOd7jvni4PU5ZlZEr6PTOOGq71bPVZocr5P/OeGdxTLCSC3to3dY4sL21Kmy/vObE edfMQ7Czp98m5tqKmn02nfOqZ8tiTkXtFeYAqWowVjGDuJNP1IvrOc0YEEZMYxm/xigxMAGLMnki IOTYBDc2sbSoUcIzvVaNLxbxi1v84iB2TLZ0sM2mRrDVGgZ5SDa0p9hXBQRp8TDjQBSybLbyp77x 2EQ88vgcbCd0djszXUCL/Roz+rvepwhVt+34bWf/09rIm3U5WXFmB8ThEGMRAkpGvTiijGENVXiK DkSwhZQEzAj16kEOpDAYkXilEJWkwZyXAIQ3EAEFbHjJyOXmhVm67wqIYMOvonCC/b1E4luVqiVX oIUZCCL/DSMowQCj8BQ1GH0MOao5H3b6akXT6Zyvk41jFFMo97xXYZ2NBXbusx/WkAYzVezNOYeD qP18TzKKMeOklQZFs8YnPquITGvqiJ/sxL3vY7wUn2QRivfEp+zUGNlCoBMdzuJqEdyRDEOwQT3F YJ4xRFRT322hGqwzRxZslzZtRr+YgcQm8LUuYzDAiAsnw2Y/0aEeVOxA8pE0STAWF+UCNAKikjQJ S3g5wUdqwBSbmAW7WXmtYc5wF68csnAybEIQPGT85w/sLyGZPmKAn4WZ8Kr3K6ELqzWkP2NRhTBa +UlPBjMWeaEkCzmaiRTQUiOp4plTW3Sdp/74bCyyAq68/wrKuApx4IoPkQaa0AqYcEnC9JaUhQnK aAquPJrl4Y7IeMnVhEo32czxrAkpYKCtFF6SKdp7WUoQMaCYyJW/hYmsaEct6IakfIw7SBlxEOCo XMIMHsoLYoIGSspx5EZEPNqjyeAXcZmMVJILWQgYIMXuAYgQgMiQ5MQtgZpciEiLeIuMGIGCkA2E SAUSpsiVkMFX7A2KAM6NeI6TSGGRzMuxZMHB9E9OMcgYQo4LiYiPwB/ioAhIPA7+wVrWBQo4FI3/ HZZaGWEyDOD4vEopvIx9KKAGos6nBGFG9dezZYPWoEdvXEbIjJQGekwH9tYl1gzWqEyinQ+6wQJ4 oIyjlP/MX81dK5ZUx5TM09zMc1DPDSrid5SMpWTUl3yiA0ZESLnTi23akeAAMnEQHcwZsHTNUNRL FVAhghBOwQALBF0LiCRLlpCLDMlAE1DBTGxLIFwIGk6fvzzjvUyOsfiLTGXjSXQjFPqS3kRLHn6E CFkh/KnIWUkKIAqPcwSiq1TajM3CBM7DQtzgIk6C7PAjJJKOJHqgoElg+ohJ2+mOnmSgL14gMFZD 8oRge5niL75G1axiB65JLXKK0vRgX3XMQrxXpFVawvhQ3PlOwsSVJ2ZkRG5kf0FinhSjYCxfFT5T jGThE57LKfULjgCliVAjDaELT13Iam2jM0bIXmjECNz/TQpszteIjjWOkBtaobmompI4Tg7U4Ulw CB7aYT0qZR+2FLzNzg0Fom6sESHeTjqgHmcMRAKKnauECW3AQw4+Ip3cECiKR1utIhwFg6E8kR6N zwJuyZ7gpEmqQ0eGBtyR4PnMpWv4kWvMyW6MSmRwZg+JAjYs0ZsQGaNJoLBBYp/JxjowR84wkUYG ID6sQxohin5NQFMi4cFUwX8ESJEwI+iY0Ap9jdhEEpq9gAIFCwzEDwwwH7oYQU2ACBPKRVB0YQPV QFamodiUEDqSYfD5C4o1AfPBwSm5jbTY31h0xE4Uhucc5+PEwdUhkfZswv5xgji1ZtzNCjcBWwCK k0Ue/yRAUco8dQeuOMdJ1Qc7RabY9aJ//lAuzM45cRRKvQaCJhRBTeI/iROCeklEnVvjLQRF5UdB qSYj2NVloFOCUgNISVsqSGiYqBPWPdtAwIIo7IfmaU+3PWgkTFGKLqibWFE/mYNu2MCcZcTBfCFP HWMz/p4w8QXKAUJKcJAiYaW39EobOEUVhMEWAIEsKZIMeYEUHFNUAIGCaGc5WggvoUEiFckkNRIH fQuX5kuYFgUw2WEryUQUwMESDIgYINLjuIh8lhWSLRahLhZh1RV7hcqJ7pXGeFZZLRhwQdZnRSpe 6eOftRWiJlilRhZmpZWmvtVgNSqlhuqijWo4nKqlVv8DpuaWZKFVK8SWUEqViGmVVW1VhVEYrTrV TSkVVA3dWCHVUg1QdlHXVvHqkfxqS33LGvxqVomVVcGUV11VDNCqEAjqkCEXo2HrtnJrt3rrt3or VY0AsZZauZrrbd3FucoWi7QluDZXorhrvMrrvNKru45Zsqprvurrvn6ZFFpXifFrmf2qrloVsQ7r dgFsvhKsTRXsV6XWwiosa0EsT5HrhVVswtJWwmLYw6qWTOHmLxiYcbHqtw6YbgWYc9UWqQWsTI3A VbCZmvnUqbVUGjxXmE3sbLEZO8YWs6jsqC1J/6zsTMGsTL0sa8msUMXZdLHZ0ULXt6Qh+2wFVakZ nWT/RqiA16WBa28p6kpVbNB216nNC6qVH231LHcxrWwNbcz+rNc+19luV9o6wY247WipLMymGtC+ DZ1oq3DVa3G9WGjVgcZZgdBV3BO8AFVYgRfoAE/xgNy40lDeD9IpQeNaVeMGLrjwqRXUnBOYwAtk nBmsACKAREVIHBTwz8xtiMDoQMhhHAQNgR9MLg3YHA5gbr28RD1SUui+ROiiwZkJhhXYQBHQgBV8 RBvsVOCqXOnOwC5hgemqUBYiQR78AewSgfwVQQsk7+UKSFpUwe4Gr+wOwtJ1QRHUQRD8ARXErRc4 bkewbkpQkuegAckdAfgiAu9OLclUG0sKm7ctxAPy/8O16QKUbZa/ERrZeZs4OIMuJIOz/cO82SVB cC3j2gH75sURUHDuVV/2CYYCKQVU/MXAeFVwUl9RYJ8Hx5BdTAQKP0UTHF+wxF9SdARH2IFKxLD0 zoX4SQj+hAVHsEgM9x4mFSkVXF8MTcUGH0VUiAsPAycKZEhd9O7urfBVqDBVDEVf0ISwyh8Fm4RX fAGLzMUNe/ErafD/fIUQOwgNqXDzeQQZurD17UpaAEZFrN+eZjEKlyd27spe/E/y0bAYwLBW6jGY yh8T1/BW3C9kuMnevR5rlFGG7kbrvUY9YAOcwI5wpMwmCN5zVBFotCgRekbmTYaSsRSBDIzIiWFR Fv8OiyDnC+wIhZhhwTjhKYtc22TJK5/QCL0ILcet4pwLkgiB/C3OaTEn9hJJ18BBjPAIPLpwsOoy BYGalGChCP/yCWwpz67yLotxFYucLPVAKduIMKMQOAPO025nGCTFGqzBBmnzN4Ol/ezNG8dAL8Mf KcPFMRsfTCnIGf4yLxNlPouLLxtVlBzy+QTg61nGTTqyRtqlaVzNJ7cJ9XTMBcrgpcTJFOFCC34K q4gyTpAZsUwOryijVlppMOML5bRZcH5cTnBLSYczNjtzONJuG8PjmzGOEuaIsiCdMX9lhyizEpq0 s0DvaSFdEsPjxmHpsVhzNi+zMwMIEMBURzclObb/9E0vZTZPTvCGywh5dDS50Dem66g5tTy7EJnJ rVjknm6eYRzUdD+b9OcYdUUgtcd2lJJhx07izANO4syIEW3gQiNqjCxyopL5dSnISm3CooyOshAM DOYYCYjwKf2sct7ERTO/DUpP5VVOtkmD7drOY0v9x1q7tdnws1QfiFHqtFcG5zIPkFJmsyT5M1Ee ZTzHNRQPpRIytWN7scsqNuiQDWnvC1VbdRbeywD9zb5gI2PD4UkMiQjMiBzkdlmuNajNTUmEZcGg Njw+7Xnui2xLjlwvg54hTRYh9EMGIXZMVIzOZPBUJO/MpOlkw0FVA01uNOOyje7VT539wQwIt7dw /zD/QKfuPctvTqe/INDa+A+oLbVw47FMi7VUNIm7fE2VdGdxcs6CpLYN1Fl2HmdrZ4UEEbUoYW9G BIgJ0fbXJLhWyoAhXAX8dARx+jZcAPeBB/eIQ5yHdyVTJvcxTwGxpHgYxiOL1/Mu+Te6OCdyPpOJ HxAVf45UIMWIR+FS6W2l0cJuxOZDFSYiEsdHPSgVnVVpQhGlvAeX64aEbgMP9dF8v+7y1pL/KNJR fSE5048pRaspValVLSkqnRIpGSud37JVMrWe73JwCsmXmviLq2lf3ICUTlJU9HQl2ZIm9V42W+UX kEBHMKnGeZKj63eJk5mf7/cIfMFWMVI1I2OE///2MK+Anl5zFJZpdHoS+57NmkfSOrrQmH4LqL+E MynhqKf6VwIxulB6nS86ZIvSwABBpDs2DXwjLdHEF3wOwsz1YNldii5U3U0iQNmg/sbTnpXbE8UT P7lTDGIUNtnoN6F5XIRVUmkLTsiqTFWX98qBrp7zrKZ7dk2rTSXrs6oWvvoUrsaAsfI7vfOUrt7U sYaYsc6WwWcSiHmVvrOWv/uUWHnVEyyVw0e8wj8BhVi8Vx0rgezKvOP7ik0XUBm8iGkWc03qq+ZW yGaqoT6qyvcVZb08hKFsUJ3auKYYyzU32/J8z/v8zwN9bKGWzvr8ZJ3TyPbtttb8mvlmwCvrVwf/ fdRL/dRTvb5mxUwtq9fyF9InPbaG3WWBfde7g29B2GSVrLxyPX7NTsr/laHimNv3B9xn68cCV9mX fdoXlqvSfdeXfWD1fWDh/W5l1tnLvNx3FltdmYx2PdYiQ+JjWuCrF+Ovl5CxTmE5/nrt7WViq6AA l9Ym9P+tVKGpVRtFhOfXa+aPvgfmluQDlw7uJ6UF19c7ptgbGu3/FuunVyzCay+ifnj1vuIPmenn lumb/qGh/hTtvu0n10vOK+obP/PL/Fk1BM3YkbL12o0lVLkbXLMlVDpw/5T1b+uBmzqQgy/0GnAQ 3LuFhwIzxLgZXMocW7aFdyW8DralW5U1m9gR/3AlVD8IFAPwTIEYTOp0KMCgqOeQKmN7FEWQTkI/ sQEEhVfMhFpNHq/CYfkiBQMD51LkYmFVAEVhRUxKJ2PoqKSgFogDgbb6BJiAbyuAKj1U70p9MZUD ozKgYmOVZPi0ghIAkMQTNECjxCSINNnyEiDE4kLD2VJ4kCkYGthjI8gIuEWGV7Iil1bF5ja7JuJW KfWAJftEdcY5kyIw1POjpLzyAMvSJjDwJG080WatuCR9MrHDlELTG8MXXjAOLgOeQh6k0CvwIO2q J1CtEHNPJteoNBR9EC9bwBwHopXoUsLbDoPOVsD4Zg3JA26Nmjnhc2egFRX/AsYTQJCesQf39P9w ASJSnjSN2fhtagcTwD5ZAZjI8UYOHhgaBNNoUZIvn0wyBSbedMOPEKRFSOVM4rMmHp2ok3CiOzHx y4kDWLmtOPGjKJE5OR6MXXHv3UeC//TUdNK2XEE5ZOqtpHZUj1GLXJ1AsmptHR1CQx0Z1Uf0cFB8 NQvDG3AwAD2Wxky6WrasmRJC1epWk5fNxBHJX0w45YIUXd05EVkTcm2tBEgWLNh9fmJyiA+6qDvr lnEkjW83OYB3Xibv8+puT0rkMAZIdCEgw19OiVjt7+OGnOkeCw6En2Z58VZ/LtGo+O7WYEoL/5LP YXPCqdc3T8p6xf3TZN2j9K+ecr/BJceA2WT/14NSpDm3mWxcgdfZa/7QJWE93lnYGwABluDcGgiq h19+g6wGSTW6lejUfLGZtppz7Fgn3FHxNITZEtyt59k+RbjxFXV0KUeiaieqBslrRbJXSBU7YMdf RLodlyNqX0kiSQDD4WgMlJtxdNoLVMLTxBo58BFMlWBcuNSRCIrGz5bVUTmJCkx4Yw2c5vGXJZxN cpkONhsNYueQ6wUzlIJKEMofD50thaOiejoJJ4ZeSsLjoAmyZoMCob3W5xwRZjhilKJOCGUlOmCo 6I+JDhbkeoJ+ZudrJtqi5FVwWrlPGrzVKOeNw1UDUCPh9WBlaUAKWiFsyh4pK1dSqOkUh/Th/wjq cvk9ceVZWe665XrT0hbfENh2sVRo1YHHJGt6+OQmmj2E1kwLX3AahxtAbtsrkjj6dE9pDunXamVW KMcoQd6ms6iPCNM13nLjOqzEmhFBEixk//rw4HSfilrhrxfi6wNJR0zoqbGrbvlqgfUBSZusKlcE W7n2wUAHr5r963FZ16lQ3FjysNNqskXGQSQ6ut3xUi/omJgCP0/uSrK1RER2JTaudAbQZjVcReEB utETlcCRnYlaWb1MY6kKItDYXdlFXTadNpeN9fRlWcjzEqccrTSwJbEU80XKZxUq4uAny7OkfN2A A0wMSslxdnaQ/ymxgm2uEYsbd5hNYKhRd//8xUcexxbQ19Dsw/hlRrKacsAFAm73yzEojd3bd/hm caU13qz2Gh/LUsSfQeSChA4lCC1kfV780dqROeigjSP5nCqHHi/US+2oui//RdUnGF/1IMEff4X0 PozwxwmO1KCDvzjqtrw73fieX5tKUC8l932gD8gI19T9vCIg4Xr6CoM5YCGP/b1Acyu7iQ68MLGp PHBeffpe4mTQvqYVQSXlM8cz3BG8I/CMZpfiQS90sKsAFuKBZqFQtZKFQg/9rngxiIYjMkLC4r1t dShroOuesUAtoLAuYzJHDIynv0W5kFc2ooROalQPzMyGZ7pjYo1GYUUWVMoszuAiM56YRSbzFsSK Y1TGFAdhFilmo4xUdAYbxbhFMKKlZkuQo5zeKKczYsxmoSkIjZSBRZ65L2KhgWIh1SjGQ7Kgj3bc IxU5ckg8mjGSupNkGMHwx2UEUot9qGQVL3lJswjkkF7Mo3M+ya4s8g6UrGylK18Jy1geShl6k6Ut leGFTN5yl7yCDi9/CcxgCnOYxCxmLkOpy2Iqc5nBpCMzsyiZZwaTK9KspjWvic1nRhOZ2eymN78J znCKc5zkLGc2V2nOdKpznexspzvfCU8bNWOe9KynPe+Jz3zqc5/87Kc//wnQgAp0oAQtqEEPitCE KnShDG2oQx+K0BAAADs= --=_NamoWEC-g993dl39iq-- From nobody Fri Apr 25 03:46:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D701A0175 for ; Fri, 25 Apr 2014 03:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 VrEEsylHNCRY for ; Fri, 25 Apr 2014 03:46:47 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 948EE1A0164 for ; Fri, 25 Apr 2014 03:46:47 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable167.97-201-24.mc.videotron.ca [24.201.97.167]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id BC193F2AFE; Fri, 25 Apr 2014 03:46:40 -0700 (PDT) Message-ID: <535A3D0F.4090409@mozilla.com> Date: Fri, 25 Apr 2014 06:46:39 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: kiran.guduru@samsung.com, "cary.bran@plantronics.com" , "rtcweb@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fqde1EZ4YkL2Og2N8RNuJ1BElV0 Subject: Re: [rtcweb] Query Regarding Mandatory audio codecs draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 10:46:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/04/14 06:38 AM, Kiran Kumar Guduru wrote: > Spec prefers G.711 at 8 kHz sampling rate and RECOMMENDS Opus above > 8 kHz sampling rate. > > Is my understanding correct? No. The spec does not prefer anything and does not make any recommendation at 8 kHz. Just like the statement "if it rains, bring an umbrella" does not say anything about the case where it doesn't rain. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWj0PAAoJEJ6/8sItn9q9aoQH+wW2Zf/FbLdTLTGt1dfSfsqD nsTWzOPsdQAf8d5FHJmw4LFbIHtI3fMxJIDqOGMyWNqZ98POZ8EAZTD+nqUYt0pz j0I0vMLFdSsf9Wt61B6Dm6vMZBnjhpVeH2UsvANIVLR5dX2qFS5NPFpOZtTyZx69 BoKweWcenRvwn5WZPAQvk5qXH59eVUaegcDstvLUEwZ+S247cseiF5sDUSCx5dlP KBaujXn0OAAGIPS86yibrahVrEDVG4O8JSpdEOzVPDmQP19Eh9NTzc+CjREMKSIE 1zuMRrI90JSPjFnC4n3/PPOkUSFZTUeltgh7M+f/8heg+p6pMtaLVGWpaGzjY1E= =huAZ -----END PGP SIGNATURE----- From nobody Fri Apr 25 04:54:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D8C1A047E for ; Fri, 25 Apr 2014 04:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 mv0qUBh8OFFL for ; Fri, 25 Apr 2014 04:54:30 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 003951A0435 for ; Fri, 25 Apr 2014 04:54:29 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so825261wgg.24 for ; Fri, 25 Apr 2014 04:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=qXf7DeFRJ6yXkvUUPTgDeVgx/VOim17GRf88ZQA2dP8=; b=j1W+w1AOlSG1FsuztXGZX6gt0tvRG2zWJ45hquz6nP+Zwhp6agv3EpLe/6P0LL373W BhpLGsxU2o6viilh0o8+EpFTMX3IKYH6xk49lpQYX9gzGa7rMeDmnWCnlYq9TIOJl07T Lc49v88tFs0+KHT1YBo1cC24CDncS4ueGdLcTu5tYQO8y2+hmhgQ9y7wGqWuMTzaqh11 KSdIAtUdnvAFz00T2RPA8R+nua88Z6xrCX1T2tVD0btCbvvVl8Gyt6Umzq0zFKAwr+WU gPp+qzgg0Wjuz66YLzBn7r7KIfhlDjju1PIMYHkRyIzK3Y6JzWYhtnefm6sPmFOCu6Aq p6Nw== X-Received: by 10.180.97.41 with SMTP id dx9mr3444924wib.28.1398426862908; Fri, 25 Apr 2014 04:54:22 -0700 (PDT) Received: from [192.168.1.33] (61.Red-88-9-161.dynamicIP.rima-tde.net. [88.9.161.61]) by mx.google.com with ESMTPSA id cv4sm10832667wjc.34.2014.04.25.04.54.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Apr 2014 04:54:21 -0700 (PDT) Message-ID: <535A4CEF.7040904@gmail.com> Date: Fri, 25 Apr 2014 13:54:23 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5357B281.1030900@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070304070203000802070708" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KJIbNpoEM-yM_m5iHZo5VXrXh9w Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 11:54:31 -0000 This is a multi-part message in MIME format. --------------070304070203000802070708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 23/04/2014 17:46, Stephan Wenger escribió: > In both cases, the typical reaction of an endpoint is to expose the > user to crappy quality, until the user hangs up. Sometimes, slightly > smarter implementations hang up themselves if the packet loss rate > becomes excessive.I would suggest not to paint a rosier picture in the > draft than what is warranted based on real-world observations. > > Based on this, most UDP endpoints do not deal well with > congestion. Ideally this should change to support better bandwidth > management. Futhermore, reliably transmitting real time media over > public internet would also require changes to biffer management > algorithms in routers, which will, in turn, affect congestion > handling strategies in the end points. > +1, but also from my real life experience, the most problems I am having with quality are related to bad Wifi coverage or cheap/crappy XDSL routers/cable modems. Almost 100% of problems with quality I had found were solved just by plugging the ethernet cable. Best regards Sergio --------------070304070203000802070708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
El 23/04/2014 17:46, Stephan Wenger escribió:
In both cases, the typical reaction of an endpoint is to expose the user to crappy quality, until the user hangs up.  Sometimes, slightly smarter implementations hang up themselves if the packet loss rate becomes excessive.I would suggest not to paint a rosier picture in the draft than what is warranted based on real-world observations.  

Based on this, most UDP endpoints do not deal well with congestion. Ideally this should change to support better bandwidth management. Futhermore, reliably transmitting real time media over public internet would also require changes to biffer management algorithms in routers, which will, in turn, affect congestion handling strategies in the end points.


+1, but also from my real life experience, the most problems I am having with quality are related to bad Wifi coverage or cheap/crappy XDSL routers/cable modems. Almost 100% of problems with quality I had found were solved just by plugging the ethernet cable. 

Best regards
Sergio
--------------070304070203000802070708-- From nobody Fri Apr 25 05:04:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0231A048C for ; Fri, 25 Apr 2014 05:04:37 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 XiA8VaAQ71FT for ; Fri, 25 Apr 2014 05:04:35 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD911A047E for ; Fri, 25 Apr 2014 05:04:34 -0700 (PDT) X-AuditID: c1b4fb25-f798a6d000005ede-3e-535a4f4bc512 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A5.93.24286.B4F4A535; Fri, 25 Apr 2014 14:04:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Fri, 25 Apr 2014 14:04:27 +0200 From: Christer Holmberg To: Ted Hardie , "rtcweb@ietf.org" , "Sean Turner" , Cullen Jennings Thread-Topic: [rtcweb] Sketch of agenda for upcoming RTCWEB Interim Thread-Index: AQHPX9OHSF3f4MzEWEGb9oJsXWIVu5siPKbg Date: Fri, 25 Apr 2014 12:04:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2DC366@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2DC366ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3RtfbPyrY4NN8PYuOyWwWa/+1s1s0 zrWz2HFuAosDi8eU3xtZPXbOusvucWfOB1aPJUt+MgWwRHHZpKTmZJalFunbJXBlzNt9kaWg bwVjxZmfMQ2MFxYzdjFyckgImEi83vyXGcIWk7hwbz1bFyMXh5DAUUaJHdvus0I4Sxglvn/4 zN7FyMHBJmAh0f1PGyQuIjCBUeLKt/Vg3cICThLzfy1lBakREXCWWHXXHSQsImAk8fbWKrBl LAKqEi/XbWUDsXkFfCUOXG9mAbGFBAIkms8eBotzCgRKNDWtAxvJCHTQ91NrmEBsZgFxiVtP 5jNBHCogsWTPeaijRSVePv4HtlZCQEli2tY0iPJ8icd75zBDrBKUODnzCcsERpFZSCbNQlI2 C0nZLKBJzAKaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFSbrqRsV5qUWZycXF+ nl5easkmRmDkHdzyW3UH4+U3jocYBTgYlXh4i79EBguxJpYVV+YeYpTmYFES5/1yyydYSCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6Pju08CTcVnLmjdW/P3zdrkd5cLOvJ/7r164dKp5CPV LT0z9s4/Kjntc8CZSYsEqxum5hTfSOeL+ixUxPqoXNXoVtZTt00e7KE3/c7+fO/vvW9F+UbT S47+P53VcovlJEyEXZonHlMum9SspSX1N3ZFlf7JP7vz8udWpb5dc6x41x2di1Kt68qVWIoz Eg21mIuKEwGvuu/ZnQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xS1gem-_RbBxTOklQjopu9TXLXw Subject: Re: [rtcweb] Sketch of agenda for upcoming RTCWEB Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 12:04:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2DC366ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk9uZSBjb21tZW50Og0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBoYXZl IG1vcmUgdGltZSBmb3IgSlNFUC4NCg0KSSBoYXZlbuKAmXQgYmVlbiBjbG9zZWx5IGludm9sdmVk IGluIHRoZSDigJxSVFAgKyBtZWRpYeKAnSByZWxhdGVkIHdvcmssIGJ1dCBhcmUgdGhlcmUgbWFq b3IgaXNzdWVzIHRoYXQgcmVxdWlyZXMgMiBob3VycyBmYWNlLXRvLWZhY2UgdGltZT8NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUZWQgSGFyZGllDQpTZW50OiAyNC4gaHVodGlrdXV0YSAy MDE0IDE4OjQwDQpUbzogcnRjd2ViQGlldGYub3JnOyBTZWFuIFR1cm5lcjsgQ3VsbGVuIEplbm5p bmdzDQpTdWJqZWN0OiBbcnRjd2ViXSBTa2V0Y2ggb2YgYWdlbmRhIGZvciB1cGNvbWluZyBSVENX RUIgSW50ZXJpbQ0KDQpIb3dkeSwNCkJlbG93IGlzIGEgcm91Z2ggc2tldGNoIG9mIHRoZSBhZ2Vu ZGEgZm9yIHRoZSB1cGNvbWluZyBSVENXRUIgSW50ZWlybSAoZXNzZW50aWFsbHksIHdlIGhhdmUg dGhlIG1vcm5pbmcgc2Vzc2lvbnMgZm9yIHRoZSB0aHJlZSBkYXlzIE1heSAxOSwgTWF5IDIwLCBN YXkgMjEgMjAxNCkuICBJZiB5b3UgaGF2ZSBub3QgZmlsbGVkIGluIHlvdXIgcGFydGljaXBhdGlv biBpbiB0aGUgZG9vZGxlIHBvbGwsIHBsZWFzZSBkbyBzbyBhdDogIGh0dHA6Ly9kb29kbGUuY29t L3Fld3E0eHZzemJjNmQ0c24uDQpDb21tZW50cyBvbiB0aGUgYWdlbmRhIHRpbWluZywgb24gb3Ro ZXIgd29yaywgb3IgbWVjaGFuaWNzIHdlbGNvbWUsDQoNCnRoYW5rcywNCg0KVGVkLCBTZWFuLCBD dWxsZW4NCg0KDQoNCkludGVyaW0gTWVldGluZyBSVENXRUIgTWF5IDIwMTQNCg0KDQoNCg0KRGF5 IDENCg0KDQpSVFAgKyBNZWRpYSAgKDJoKQ0KDQpkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2Ut MTM8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAt dXNhZ2UvPg0KDQpkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby0wNTxodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLz4NCg0KZHJhZnQtaWV0Zi1ydGN3 ZWItdHJhbnNwb3J0cy0wMzxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtcnRjd2ViLXRyYW5zcG9ydHMvPg0KDQoNCkpTRVAgKDJoKQ0KDQpkcmFmdC1pZXRmLXJ0Y3dl Yi1qc2VwLTA2PGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3 ZWItanNlcC8+DQoNCg0KRGF5IDINCg0KDQpEYXRhIENoYW5uZWwgKDRoKQ0KDQpkcmFmdC1pZXRm LXJ0Y3dlYi1kYXRhLWNoYW5uZWwtMDg8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXJ0Y3dlYi1kYXRhLWNoYW5uZWwvPg0KDQpkcmFmdC1pZXRmLXJ0Y3dlYi1kYXRh LXByb3RvY29sLTA0PGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1y dGN3ZWItZGF0YS1wcm90b2NvbC8+DQoNCg0KRGF5IDMNCg0KDQpTZWN1cml0eSAoIDJoICkNCg0K ZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktMDY8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS8+DQoNCmRyYWZ0LWlldGYtcnRjd2ViLXNl Y3VyaXR5LWFyY2gtMDk8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LXJ0Y3dlYi1zZWN1cml0eS1hcmNoLz4NCg0KDQpBTFBOICggMTVtICkNCg0KZHJhZnQtdGhvbXNv bi1ydGN3ZWItYWxwbi0wMDxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRo b21zb24tcnRjd2ViLWFscG4vPg0KDQoNCkNvbnNlbnQgRnJlc2huZXNzICggMzBtKQ0KDQpkcmFm dC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTAyPGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy8+ DQoNCg0KTWF0dGVycyBhcmlzaW5nIGZyb20gd2VicnRjIG1lZXRpbmdzICggcmVtYWluaW5nIHRp bWUpDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D2DC366ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Okdlb3JnaWE7DQoJcGFub3NlLTE6MiA0IDUgMiA1IDQg NSAyIDMgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uZSBjb21tZW50OjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBtb3JlIHRpbWUgZm9yIEpTRVAuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JIGhhdmVu4oCZdCBiZWVuIGNsb3NlbHkgaW52b2x2ZWQgaW4gdGhlIOKAnFJUUCAm IzQzOyBtZWRpYeKAnSByZWxhdGVkIHdvcmssIGJ1dCBhcmUgdGhlcmUgbWFqb3IgaXNzdWVzIHRo YXQgcmVxdWlyZXMgMiBob3VycyBmYWNlLXRvLWZhY2UgdGltZT88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlRlZCBIYXJkaWU8YnI+DQo8Yj5TZW50OjwvYj4gMjQuIGh1aHRpa3V1dGEgMjAx NCAxODo0MDxicj4NCjxiPlRvOjwvYj4gcnRjd2ViQGlldGYub3JnOyBTZWFuIFR1cm5lcjsgQ3Vs bGVuIEplbm5pbmdzPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtydGN3ZWJdIFNrZXRjaCBvZiBhZ2Vu ZGEgZm9yIHVwY29taW5nIFJUQ1dFQiBJbnRlcmltPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhv d2R5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0dlb3JnaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJlbG93IGlzIGEgcm91 Z2ggc2tldGNoIG9mIHRoZSBhZ2VuZGEgZm9yIHRoZSB1cGNvbWluZyBSVENXRUIgSW50ZWlybSAo ZXNzZW50aWFsbHksIHdlIGhhdmUgdGhlIG1vcm5pbmcgc2Vzc2lvbnMgZm9yIHRoZSB0aHJlZSBk YXlzIE1heSAxOSwgTWF5IDIwLCBNYXkgMjEgMjAxNCkuJm5ic3A7DQogSWYgeW91IGhhdmUgbm90 IGZpbGxlZCBpbiB5b3VyIHBhcnRpY2lwYXRpb24gaW4gdGhlIGRvb2RsZSBwb2xsLCBwbGVhc2Ug ZG8gc28gYXQ6Jm5ic3A7DQo8YSBocmVmPSJodHRwOi8vZG9vZGxlLmNvbS9xZXdxNHh2c3piYzZk NHNuIj5odHRwOi8vZG9vZGxlLmNvbS9xZXdxNHh2c3piYzZkNHNuPC9hPi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Q29t bWVudHMgb24gdGhlIGFnZW5kYSB0aW1pbmcsIG9uIG90aGVyIHdvcmssIG9yIG1lY2hhbmljcyB3 ZWxjb21lLDxicj4NCjxicj4NCnRoYW5rcyw8YnI+DQo8YnI+DQpUZWQsIFNlYW4sIEN1bGxlbjxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+SW50ZXJpbSBNZWV0aW5nIFJUQ1dFQiBNYXkgMjAxNDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+RGF5IDE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0dlb3JnaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHZW9y Z2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJUUCAmIzQzOyBNZWRpYSAmbmJzcDsoMmgpPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHZW9y Z2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzExNTVDQztiYWNrZ3JvdW5kOndoaXRlIj5kcmFmdC1pZXRmLXJ0 Y3dlYi1ydHAtdXNhZ2UtMTM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8vIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxMTU1Q0M7YmFja2dyb3VuZDojRURGNUZG Ij5kcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby0wNTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dl Yi10cmFuc3BvcnRzLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTE1NUNDO2Jh Y2tncm91bmQ6d2hpdGUiPmRyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDM8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkpTRVAg KDJoKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1qc2VwLyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMTE1NUNDO2JhY2tncm91bmQ6d2hpdGUiPmRyYWZ0LWlldGYt cnRjd2ViLWpzZXAtMDY8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkRheSAyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtHZW9yZ2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EYXRhIENoYW5uZWwgKDRoKTwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1kYXRhLWNoYW5uZWwvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxMTU1Q0M7YmFja2dyb3VuZDp3aGl0ZSI+ZHJhZnQtaWV0Zi1ydGN3 ZWItZGF0YS1jaGFubmVsLTA4PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YSBocmVmPSJo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLWRhdGEtcHJv dG9jb2wvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxMTU1Q0M7YmFja2dyb3Vu ZDojRURGNUZGIj5kcmFmdC1pZXRmLXJ0Y3dlYi1kYXRhLXByb3RvY29sLTA0PC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkRheSAzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtHZW9yZ2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TZWN1cml0eSAoIDJoICk8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHkvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxMTU1Q0M7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC1pZXRmLXJ0Y3dl Yi1zZWN1cml0eS0wNjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNo LyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTE1NUNDO2JhY2tncm91bmQ6d2hp dGUiPmRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMDk8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFMUE4gKCAxNW0gKTwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2Vv cmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC10aG9tc29uLXJ0Y3dlYi1hbHBuLyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMTE1NUNDO2JhY2tncm91bmQ6d2hpdGUiPmRyYWZ0LXRob21zb24t cnRjd2ViLWFscG4tMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 MTIuMHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5Db25zZW50IEZyZXNobmVzcyAoIDMwbSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGNtIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YSBo cmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXN0 dW4tY29uc2VudC1mcmVzaG5lc3MvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx MTU1Q0M7YmFja2dyb3VuZDojRURGNUZGIj5kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQt ZnJlc2huZXNzLTAyPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEy LjBwdDttYXJnaW4tbGVmdDowY20iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+TWF0dGVycyBhcmlzaW5nIGZyb20gd2VicnRjIG1lZXRpbmdzICggcmVtYWluaW5nIHRp bWUpDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0dlb3JnaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_7594FB04B1934943A5C02806D1A2204B1D2DC366ESESSMB209erics_-- From nobody Fri Apr 25 05:53:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FA01A04A3 for ; Fri, 25 Apr 2014 05:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham 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 IMUBmXeENuZi for ; Fri, 25 Apr 2014 05:53:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6946B1A048D for ; Fri, 25 Apr 2014 05:53:39 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:15b:212f:d481:de2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ECC6F40397 for ; Fri, 25 Apr 2014 08:53:32 -0400 (EDT) Message-ID: <535A5ACC.9070700@viagenie.ca> Date: Fri, 25 Apr 2014 08:53:32 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> In-Reply-To: <535A21E3.7070008@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SpLS0PVMwUgayx3xPwK0sSXL12g Subject: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 12:53:41 -0000 Le 2014-04-25 04:50, Harald Alvestrand a écrit : > A.4. Changes from -03 to -04 > > o Added a section on prioritization, moved the DSCP section into it, > and added a section on local prioritization, giving a specific > algorithm for interpreting "priority" in local prioritization. Harald, The new text looks good. A comment about this part: > When an RTCWEB implementation has packets to send on multiple streams > that are congestion-controlled under the same congestion controller, > the RTCWEB implementation SHOULD serve the streams in a weighted > round-robin fashion, with each stream at each level of priority being > given approximately twice the transmission capacity (measured in > payload bytes) of the level below. This looks like a QoS algorithm that might get quickly obsoleted by better ones. We don't want to prevent innovation in this matter by prescribing an obsolete QoS algorithm. Suggestion: leave it up to implementations to interpret priority levels however they want. Reword the current text so that it becomes an *example* of what an implementation might do. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Apr 25 06:21:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AABC1A04AE for ; Fri, 25 Apr 2014 06:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 ue8EJUQVb8yD for ; Fri, 25 Apr 2014 06:21:29 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id A9C2C1A04B6 for ; Fri, 25 Apr 2014 06:21:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BA09D7C54D8 for ; Fri, 25 Apr 2014 15:21:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMXTTp7-jCTs for ; Fri, 25 Apr 2014 15:21:22 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 05DA27C54D5 for ; Fri, 25 Apr 2014 15:21:22 +0200 (CEST) Message-ID: <535A6151.1060501@alvestrand.no> Date: Fri, 25 Apr 2014 15:21:21 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> In-Reply-To: <535A5ACC.9070700@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/W_XoJDoW2B4PEzneXol8mh6ZxIo Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 13:21:33 -0000 On 04/25/2014 02:53 PM, Simon Perreault wrote: > Le 2014-04-25 04:50, Harald Alvestrand a écrit : >> A.4. Changes from -03 to -04 >> >> o Added a section on prioritization, moved the DSCP section into it, >> and added a section on local prioritization, giving a specific >> algorithm for interpreting "priority" in local prioritization. > Harald, > > The new text looks good. A comment about this part: > >> When an RTCWEB implementation has packets to send on multiple streams >> that are congestion-controlled under the same congestion controller, >> the RTCWEB implementation SHOULD serve the streams in a weighted >> round-robin fashion, with each stream at each level of priority being >> given approximately twice the transmission capacity (measured in >> payload bytes) of the level below. > This looks like a QoS algorithm that might get quickly obsoleted by > better ones. We don't want to prevent innovation in this matter by > prescribing an obsolete QoS algorithm. > > Suggestion: leave it up to implementations to interpret priority levels > however they want. Reword the current text so that it becomes an > *example* of what an implementation might do. The problem with doing that is that it leads to completely inconsistent behaviour. The reason I wrote it this way is because the bandwidth estimation problem breaks down into two parts: - Telling if it's a good idea to send a packet (congestion control) - Deciding which packet to send (prioritization) Congestion control is an active area of research and innovation. I said very little about it. Prioritization is a different matter. What I was trying to encapsulate was: - Higher priority means more packets get sent - "More" has a numeric value, so behaviour is predictable (that's where the x2 figure came from) - Small packet flows get more packets than large-packet flows (counting bytes not packets) - Lower priority flows can't be starved completely This text captures that. I'd like to continue to capture that. From nobody Fri Apr 25 06:53:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEE61A01E9 for ; Fri, 25 Apr 2014 06:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham 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 E85Or2Vj_c3s for ; Fri, 25 Apr 2014 06:53:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD8D1A01DF for ; Fri, 25 Apr 2014 06:53:44 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:15b:212f:d481:de2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9BA7E46E76 for ; Fri, 25 Apr 2014 09:53:37 -0400 (EDT) Message-ID: <535A68E1.9090901@viagenie.ca> Date: Fri, 25 Apr 2014 09:53:37 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> In-Reply-To: <535A6151.1060501@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/m52emCYRbVaJhN0kJZKqz9yD1EA Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 13:53:46 -0000 Le 2014-04-25 09:21, Harald Alvestrand a écrit : >> Suggestion: leave it up to implementations to interpret priority levels >> however they want. Reword the current text so that it becomes an >> *example* of what an implementation might do. > > The problem with doing that is that it leads to completely inconsistent > behaviour. Understood. But is that something we should care about? I mean, if it does not lead to application developers doing "if (chrome) ... else if (firefox) ..." then behaviour inconsistency is of no consequence. I can't imagine a situation where that would happen if we leave it open. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Apr 25 07:20:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BB71A01B3 for ; Fri, 25 Apr 2014 07:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 8bzZmYWtiAix for ; Fri, 25 Apr 2014 07:20:02 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 95F591A022E for ; Fri, 25 Apr 2014 07:20:01 -0700 (PDT) X-AuditID: c1b4fb2d-f79b16d00000734d-fd-535a6f0914c4 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4C.BF.29517.90F6A535; Fri, 25 Apr 2014 16:19:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.174.1; Fri, 25 Apr 2014 16:19:53 +0200 Message-ID: <535A6F08.3030203@ericsson.com> Date: Fri, 25 Apr 2014 16:19:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> In-Reply-To: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+JvjS5nflSwwdc/1hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48mBRSwF54wr/l3tZW9gbNDsYuTkkBAwkXiy6DAzhC0mceHe ejYQW0jgKKPEpYfyXYxcQPZyRolzM7ezgiR4BbQlTpzfDdbAIqAqcfL2OkYQm03AQuLmj0aw ZlGBYImlcxazQNQLSpyc+QTMFhEQlXj9eBrYHGEBe4kr92+wQCxzkFg2/zfYHE4BR4kjOxcy dTFyAB0kLtHTGAQSZhbQk5hytYURwpaXaN46mxmiVVuioamDdQKj4Cwk22YhaZmFpGUBI/Mq RtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMDAPLjlt+4OxtWvHQ8xCnAwKvHwFn+JDBZiTSwr rsw9xCjNwaIkztt21ztYSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6MLf9qcqD2H5jx/Y3bo XJ5cawNbp8brM8cz+eOkywtfvW32miN8glNvyiXpFypCt3ftkWZrSwhLC6s4GaI1P0f/mTPT 87T7P1dM2XywhfPy7JBqVxl3fq9zZ1n27K7KXn3M8quIwbz9u/ndnY6k899zOdpy84ir81Hb 62zMH42qayesZL+iEK3EUpyRaKjFXFScCADyRo0uLQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/t-ch3V0t4n1Gk2CSzYSkiBU2FYg Subject: [rtcweb] Review Comments on draft-ietf-rtcweb-transports-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:20:06 -0000 Harald and WG, I am catching up on the changes and improvements in the two latest versions. I have tried to do a complete review through and match with my previous comments. First of all, I think the two revisions have improved a number of things. 1. Section 3.1: Platforms that do not give access to these interfaces will not be able to support a conforming RTCWEB implementation. I am very split over this statement. We do want platforms to support per packet DSCP markings, while at the same time we know we might not be able to set DSCP at all for a transport flow (5-tuple). Thus, I wonder if calling the implementations non-conformant due to the underlying platform is a bit though. 2. Section 3.1: This specification does not assume that the implementation will have access to ICMP or raw IP. But, to my understanding we have things that could benefit from getting the information from ICMP, e.g. the SCTP MTU discovery mechanism. Thus, I wonder if this statement should be changed to: This specification does not assume that the implementation will have access to ICMP or raw IP, however access to ICMP information can benefit the WebRTC implementation and its performance. 3. Section 3.4: TURN TCP candidates [RFC6062] MAY be supported. However, such candidates are not seen as providing any significant benefit. First, use of TURN TCP would only be relevant in cases which both peers are required to use TCP to establish a PeerConnection. Secondly, that use case is anyway supported by both sides establishing UDP relay candidates using TURN over TCP to connect to the relay server. Thirdly, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking. I think these two paragraphs should be moved to after the following paragraph: ICE-TCP candidates [RFC6544] MUST be supported; this may allow applications to communicate to peers with public IP addresses across UDP-blocking firewalls without using a TURN server. >From a discussion of WebRTC RTP or DTLS packets over TCP, it makes better sense to first discuss the ICE TCP candidates, then discuss why TCP candidates from TURN makes less so. 4. Section 3.4: If TCP connections are used, RTP framing according to [RFC4571] MUST be used, both for the RTP packets and for the DTLS packets used to carry data channels. I think this paragraph forgets the encapsulation of the STUN messages that ICE emits for initial path verification and nomination, as well as for keep-alive and consent freshness. 5. section 3.4: NOTE IN DRAFT: This may be added. I don't understand this note. 6. Section 3.5: The setup protocol for RTCWEB data channels is described in [I-D.jesup-rtcweb-data-protocol]. First of all, this pointer is the individual version rather than WG draft. Secondly, I think the DCEP shall be mandated to be supported by an WebRTC implementation in this specification, and thus become a normative reference also. 7. Section 4: The RTCWEB prioritization model is that the application tells the RTCWEB implementation about the priority of media and data flows through an API. As we have discussed before in regards to DART as well as draft-ietf-tsvwg-rtcweb-qos has needs for clear definitions what is meant with media and data flows here. But, reading this section it is clear that the document itself has need for clear definitions. A data flow appear to be the one of the SCTP streams that forms a single data channel, as this is the level where we assign data priority. A WebRTC media flows is a more complex beast. It is one or more RTP packet streams (draft-ietf-avtext-grouping-taxonomy), i.e. the RTP packets associated with an SSRC. However, due to FEC and RTP retransmission as well as scalable codecs, there could be multiple SSRCs that carries data associated and possibly necessary to be able to perform media decoding. Thus, I think we are talking about the RTP packet streams that are the result of a single MediaStreamTrack within one RTCPeerConnection. I would also note that Section 4.1 uses Media Stream instead of media flow. There are need for alignment here. 8. Section 4.1: I think this section is a good start. It clearly needs some more input. Especially about the notes made. In addition to the first three configurations, I think the one where one has different transport flows per priority level for the media flows appears to be one most likely to require mandating implementation support. Yes this means that I also would like to mandate implementation support for the one transport flow per media type configuration. 9. Section 4.1: A receiving implementation MUST be able to receive media and data in all these configurations. It is very unclear what "all" in the above sentence includes. 10. Section 4.2: First of all I do wonder if this is the right solution. I haven't yet spent enough time on the issue to know if the proposal is useful and good enough, or if we need something else. I do encourage people to consider this. However, considering Simon Perrault's comment, I do want to state that I share Harald's view that this prioritization behavior needs to be consistent over the implementations. 11. Section 4.2: This prioritization is independent of the media type, but will lead to packet loss due to full send buffers occuring first on the highest volume flows at any given priority level. I think I have two questions here. First, I appears that you assume that you have an API model where the framework will try to send and fail rather than creating the data based on allowance or with the knowledge that you can send a particular data amount. I think creating sender side buffer overflow is a poor regulation model. Secondly, I would not that this issue has a higher probability of effecting the flow with most data first. 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 Fri Apr 25 08:02:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BED1A04CD for ; Fri, 25 Apr 2014 08:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 clNO9iML7qfi for ; Fri, 25 Apr 2014 08:02:34 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id AC7DE1A01DA for ; Fri, 25 Apr 2014 08:02:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 66AC57C54D1 for ; Fri, 25 Apr 2014 17:02:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H94k1nq3Wb1N for ; Fri, 25 Apr 2014 17:02:25 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id C373D7C54CB for ; Fri, 25 Apr 2014 17:02:25 +0200 (CEST) Message-ID: <535A78FF.20700@alvestrand.no> Date: Fri, 25 Apr 2014 17:02:23 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> <535A68E1.9090901@viagenie.ca> In-Reply-To: <535A68E1.9090901@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jhzl59zPWyFNEVoH3NNt90C3Ewg Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:02:37 -0000 On 04/25/2014 03:53 PM, Simon Perreault wrote: > Le 2014-04-25 09:21, Harald Alvestrand a écrit : >>> Suggestion: leave it up to implementations to interpret priority levels >>> however they want. Reword the current text so that it becomes an >>> *example* of what an implementation might do. >> The problem with doing that is that it leads to completely inconsistent >> behaviour. > Understood. But is that something we should care about? I mean, if it > does not lead to application developers doing "if (chrome) ... else if > (firefox) ..." then behaviour inconsistency is of no consequence. I > can't imagine a situation where that would happen if we leave it open. I can imagine that happening. Consider a scenario where complete starvation is considered a Really Bad Thing. if (firefox) { // higher priority channels will completely starve out lower priority ones. Don't. priority = normal } else if (chrome) { // lower priority channels will get some packets through. That's OK. priority = high } else { // I have no idea what will happen, let's play it safe. priority = normal } > > Simon From nobody Fri Apr 25 08:17:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2C91A050E for ; Fri, 25 Apr 2014 08:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham 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 hNs5mOi8i7Sa for ; Fri, 25 Apr 2014 08:17:16 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 87BBA1A0573 for ; Fri, 25 Apr 2014 08:17:14 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:15b:212f:d481:de2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 045504034D for ; Fri, 25 Apr 2014 11:17:07 -0400 (EDT) Message-ID: <535A7C73.6050701@viagenie.ca> Date: Fri, 25 Apr 2014 11:17:07 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> <535A68E1.9090901@viagenie.ca> <535A78FF.20700@alvestrand.no> In-Reply-To: <535A78FF.20700@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H-_NJ72VBbpSv0IeCI-t1Aq6U24 Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:17:22 -0000 Le 2014-04-25 11:02, Harald Alvestrand a écrit : > On 04/25/2014 03:53 PM, Simon Perreault wrote: >> Le 2014-04-25 09:21, Harald Alvestrand a écrit : >>>> Suggestion: leave it up to implementations to interpret priority levels >>>> however they want. Reword the current text so that it becomes an >>>> *example* of what an implementation might do. >>> The problem with doing that is that it leads to completely inconsistent >>> behaviour. >> Understood. But is that something we should care about? I mean, if it >> does not lead to application developers doing "if (chrome) ... else if >> (firefox) ..." then behaviour inconsistency is of no consequence. I >> can't imagine a situation where that would happen if we leave it open. > > I can imagine that happening. Consider a scenario where complete > starvation is considered a Really Bad Thing. > > if (firefox) { > // higher priority channels will completely starve out lower priority > ones. Don't. > priority = normal > } else if (chrome) { > // lower priority channels will get some packets through. That's OK. > priority = high > } else { > // I have no idea what will happen, let's play it safe. > priority = normal > } Ok, then how about "MUST NOT do starvation"? I'll shut up now. I see your point. If nobody else feels this issue is important, feel free to ignore my comment. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Apr 25 10:01:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1CF1A065A for ; Fri, 25 Apr 2014 10:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 E52IR5YmqO3K for ; Fri, 25 Apr 2014 10:00:47 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7D71A0660 for ; Fri, 25 Apr 2014 10:00:38 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id k48so3908942wev.11 for ; Fri, 25 Apr 2014 10:00:31 -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:content-type; bh=p/KBJwYGxnX+px2+KtppB0Lrfx0ok2jr4jsJOBH6hwI=; b=hAX7M8yOmim1MW+yWmpCv7JAAJWhw5uXxa00d7iHf2mO+9yH4hZWDDFScEPCy+ulol T0ttSlpAkVgcT5DLw9cxg7nZ3ThZUamOn2Pn0yLmIWFapJPKjKY6b6Mgv+Y0qnWU/OCO EZ6XBnADGYrVGdRHZ453/856ZZNUUDNQ3wUBKlRc6n/jDgvLmuB7ELY7XqsQPsg5iPbg 3MjiaNU+RMUZxW38KnnC6oBGhCokay08t9vdC4moLshsPvp4D5XL26OVg+Y4DP431V3c uQ1LZnQXEuYm0Nz4XLfl6WG8f7VOWqs2xVZozDMiCk5fkf08Xi/X4ibdVjSjsz5BToBh Qc2w== MIME-Version: 1.0 X-Received: by 10.180.188.134 with SMTP id ga6mr4509072wic.58.1398445231343; Fri, 25 Apr 2014 10:00:31 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Fri, 25 Apr 2014 10:00:31 -0700 (PDT) In-Reply-To: <535A7C73.6050701@viagenie.ca> References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> <535A68E1.9090901@viagenie.ca> <535A78FF.20700@alvestrand.no> <535A7C73.6050701@viagenie.ca> Date: Fri, 25 Apr 2014 10:00:31 -0700 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3W-yAoZZLwyPS_KFuUfO24rRcYw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 17:00:54 -0000 On 25 April 2014 08:17, Simon Perreault wrote: > I'll shut up now. I see your point. If nobody else feels this issue is > important, feel free to ignore my comment. Honestly, I was originally inclined to agree with you, but the SHOULD leaves plenty of wiggle room for those who think they know better. I think that providing motivation in the document - something like "This ensures that lower priority streams receive fewer resources, but cannot be completely blocked by those at higher priority." - would help to ensure that people who think they know better - and don't - can't screw things up too much. From nobody Fri Apr 25 10:04:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1AE1A05D1 for ; Fri, 25 Apr 2014 10:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 N3liYYOIlogY for ; Fri, 25 Apr 2014 10:04:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) by ietfa.amsl.com (Postfix) with ESMTP id 63E4F1A0679 for ; Fri, 25 Apr 2014 10:03:59 -0700 (PDT) Received: from CH1PR03CA005.namprd03.prod.outlook.com (10.255.156.150) by BY2PR03MB505.namprd03.prod.outlook.com (10.141.143.12) with Microsoft SMTP Server (TLS) id 15.0.921.12; Fri, 25 Apr 2014 17:03:50 +0000 Received: from BL2FFO11FD006.protection.gbl (10.255.156.132) by CH1PR03CA005.outlook.office365.com (10.255.156.150) with Microsoft SMTP Server (TLS) id 15.0.929.12 via Frontend Transport; Fri, 25 Apr 2014 17:03:50 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Fri, 25 Apr 2014 17:03:49 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.193) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.3.181.7; Fri, 25 Apr 2014 17:03:09 +0000 Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.224]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0174.002; Fri, 25 Apr 2014 17:03:09 +0000 From: "Matthew Kaufman (SKYPE)" To: Martin Thomson , Simon Perreault Thread-Topic: [rtcweb] Prioritization Thread-Index: AQHPYIVjkPq1Tfael0+4dMESGUjujZsiUXSAgAAJBICAABM2gIAABB6AgAAc5ICAAABOkA== Date: Fri, 25 Apr 2014 17:03:09 +0000 Message-ID: References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> <535A68E1.9090901@viagenie.ca> <535A78FF.20700@alvestrand.no> <535A7C73.6050701@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(52044002)(377454003)(51444003)(13464003)(24454002)(51704005)(189002)(199002)(44976005)(46102001)(15975445006)(87936001)(2656002)(83322001)(80022001)(84676001)(97736001)(6806004)(54356999)(76482001)(97756001)(19580405001)(19580395003)(4396001)(99396002)(55846006)(50466002)(85852003)(92566001)(46406003)(79102001)(92726001)(16796002)(85806002)(81342001)(77982001)(33656001)(50986999)(76176999)(80976001)(2009001)(47776003)(23726002)(81542001)(31966008)(74662001)(74502001)(20776003)(86362001)(66066001)(83072002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB505; H:mail.microsoft.com; FPR:1C8EE575.113454C1.79EB7727.CAE4F1EB.20252; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0192E812EC Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7hZpuChrlKKmIKnjNCf1iy14hXo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 17:04:11 -0000 If a "lower priority" packet is dispatched before a "higher priority" packe= t in order to "prevent starvation", then what does "higher priority" mean? Streams that are deliberately set to take resources from other streams shou= ld behave that way. Otherwise the knob shouldn't be labeled the way it is. Matthew Kaufman > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin > Thomson > Sent: Friday, April 25, 2014 10:01 AM > To: Simon Perreault > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Prioritization >=20 > On 25 April 2014 08:17, Simon Perreault > wrote: > > I'll shut up now. I see your point. If nobody else feels this issue is > > important, feel free to ignore my comment. >=20 > Honestly, I was originally inclined to agree with you, but the SHOULD lea= ves > plenty of wiggle room for those who think they know better. >=20 > I think that providing motivation in the document - something like "This > ensures that lower priority streams receive fewer resources, but cannot b= e > completely blocked by those at higher priority." - would help to ensure t= hat > people who think they know better - and don't - can't screw things up too > much. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Apr 25 10:07:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4731A0664 for ; Fri, 25 Apr 2014 10:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 DkV2ByYpQj7t for ; Fri, 25 Apr 2014 10:07:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id 977151A0676 for ; Fri, 25 Apr 2014 10:07:09 -0700 (PDT) Received: from BY2PR03MB027.namprd03.prod.outlook.com (10.255.240.41) by BY2PR03MB556.namprd03.prod.outlook.com (10.141.142.145) with Microsoft SMTP Server (TLS) id 15.0.929.12; Fri, 25 Apr 2014 17:07:01 +0000 Received: from BY2PR03CA068.namprd03.prod.outlook.com (10.141.249.41) by BY2PR03MB027.namprd03.prod.outlook.com (10.255.240.41) with Microsoft SMTP Server (TLS) id 15.0.934.12; Fri, 25 Apr 2014 17:07:00 +0000 Received: from BY2FFO11FD042.protection.gbl (2a01:111:f400:7c0c::168) by BY2PR03CA068.outlook.office365.com (2a01:111:e400:2c5d::41) with Microsoft SMTP Server (TLS) id 15.0.929.12 via Frontend Transport; Fri, 25 Apr 2014 17:07:00 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD042.mail.protection.outlook.com (10.1.14.227) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Fri, 25 Apr 2014 17:06:59 +0000 Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.224]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0181.007; Fri, 25 Apr 2014 17:06:21 +0000 From: "Matthew Kaufman (SKYPE)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Prioritization Thread-Index: AQHPYIVjkPq1Tfael0+4dMESGUjujZsiUXSAgAA+R9A= Date: Fri, 25 Apr 2014 17:06:21 +0000 Message-ID: References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> In-Reply-To: <535A6151.1060501@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(51704005)(199002)(189002)(83072002)(85852003)(86362001)(74502001)(33656001)(74662001)(31966008)(99396002)(2009001)(81342001)(97736001)(97756001)(92566001)(92726001)(4396001)(46102001)(77982001)(55846006)(76482001)(84676001)(80022001)(85806002)(66066001)(83322001)(6806004)(2656002)(87936001)(44976005)(80976001)(23726002)(79102001)(50466002)(46406003)(81542001)(20776003)(76176999)(47776003)(50986999)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB027; H:mail.microsoft.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0192E812EC Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=matthew.kaufman@skype.net; X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-1a79AaNSC81jAVYucuq0nzcOqM Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 17:07:13 -0000 Harald Alvestrand: > Prioritization is a different matter. >=20 > What I was trying to encapsulate was: >=20 > - Higher priority means more packets get sent > - "More" has a numeric value, so behaviour is predictable (that's where t= he > x2 figure came from) > - Small packet flows get more packets than large-packet flows (counting > bytes not packets) > - Lower priority flows can't be starved completely >=20 > This text captures that. I'd like to continue to capture that. The above is simply wrong, so the text shouldn't capture it at all. If I say that audio is more important than video, and I try to send 100kbps= of audio and 3 Mbps of video over a 101kbps channel, how much audio should= I drop at send time to let video through? Matthew Kaufman From nobody Fri Apr 25 11:31:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAA91A06A9 for ; Fri, 25 Apr 2014 11:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham 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 3q3oI8Z0vfuA for ; Fri, 25 Apr 2014 11:31:08 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id C46221A069E for ; Fri, 25 Apr 2014 11:31:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 03F4F7C54C0; Fri, 25 Apr 2014 20:31:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Azv6FlcKG19R; Fri, 25 Apr 2014 20:31:00 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 546197C54B3; Fri, 25 Apr 2014 20:31:00 +0200 (CEST) Message-ID: <535AA9E2.4080208@alvestrand.no> Date: Fri, 25 Apr 2014 20:30:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Matthew Kaufman (SKYPE)" , "rtcweb@ietf.org" References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AVz8R8o2f6kmAgjqdUnNjgOrjq0 Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 18:31:10 -0000 On 04/25/2014 07:06 PM, Matthew Kaufman (SKYPE) wrote: > Harald Alvestrand: >> Prioritization is a different matter. >> >> What I was trying to encapsulate was: >> >> - Higher priority means more packets get sent >> - "More" has a numeric value, so behaviour is predictable (that's where the >> x2 figure came from) >> - Small packet flows get more packets than large-packet flows (counting >> bytes not packets) >> - Lower priority flows can't be starved completely >> >> This text captures that. I'd like to continue to capture that. > The above is simply wrong, so the text shouldn't capture it at all. > > If I say that audio is more important than video, and I try to send 100kbps of audio and 3 Mbps of video over a 101kbps channel, how much audio should I drop at send time to let video through? > > Matthew Kaufman Is either stream adaptive? If I send high quality OPUS (100 Kbits/sec) and VP8 in HD (3 Mbits/sec), the suggested result would likely be OPUS scaled down to ~60 Kbits/sec and VP8 scaled down to ~30 Kbits/sec. The latter is probably useful for recognizing that there was an intention to send a picture. This MAY be a fine result, depending on the application's requirements. From nobody Fri Apr 25 13:28:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888A11A06BB for ; Fri, 25 Apr 2014 13:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 091ZcOaO7deW for ; Fri, 25 Apr 2014 13:28:23 -0700 (PDT) Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB7D1A06B9 for ; Fri, 25 Apr 2014 13:28:23 -0700 (PDT) Received: from BLU0-SMTP94 ([65.55.116.74]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Apr 2014 13:28:16 -0700 X-TMN: [bUDFRJJRqGCEFmB6mOABF3gyTJOEwjsz] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.38.66]) by BLU0-SMTP94.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Apr 2014 13:28:16 -0700 From: Paul Coverdale To: "'Jean-Marc Valin'" , , , References: <2F.4D.32015.9273A535@epcpsbgx1.samsung.com> <535A395E.7020103@mozilla.com> In-Reply-To: <535A395E.7020103@mozilla.com> Date: Fri, 25 Apr 2014 16:28:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9gcXNbbdvSCXapT8Kl/4+BTGpcDgAUmjng Content-Language: en-us X-OriginalArrivalTime: 25 Apr 2014 20:28:16.0270 (UTC) FILETIME=[E370A2E0:01CF60C4] Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9cz38lA47ShQ3gJJroz0OlVWCv8 Subject: Re: [rtcweb] Query Regarding Mandatory audio codecs draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 20:28:25 -0000 >>On 25/04/14 06:21 AM, Kiran Kumar Guduru wrote: >> Is that means spec is recommending G.711 (PCMA/PCMU) for sampling rate >> less than or equal to 8 kHz? > >No. Opus is still a good idea for 8 kHz, but it's not 2119 RECOMMENDED >since there are valid (mostly complexity-related) reasons to use G.711 >despite the higher bit-rate. > > Jean-Marc Opus isn't a good idea for 8 KHz if you are trying to inter-operate with another end-point using G.711. ...Paul From nobody Sun Apr 27 21:40:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559EA1A070F for ; Sun, 27 Apr 2014 21:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 qKA0jOLc5hqV for ; Sun, 27 Apr 2014 21:40:09 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id E41591A070B for ; Sun, 27 Apr 2014 21:40:08 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id q108so6321262qgd.21 for ; Sun, 27 Apr 2014 21:40:08 -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 :content-type; bh=wX5Ed2dAJlsyqta+ntpk7W0tSgMpHbBfvhbb7zRwjXU=; b=hZtMmSnaq9BJyWZ882OAntWJyJRZL9YQUtxO84wWw0l0jlkdUCYd7HD+0OPI4Ju2n2 JHXcqhwqJE/v7fwP6zN1KN6ut6408ZBAbNVKLB3o5dYGg4kgOD+lLNdsDgiGU0kW5QmF 5muS7XlbW2xZd6e8GenUHltF/MdhaJn8wwmPzJyGZ1YpCjBkDneAabhu3xxPLW6oNZJe z2u5M6blAOQZS2P2KpP8LveYXVZGK1CasWdbZVt6jFcyi1BG4xqsoQcxYYj2ZJsVPTnu SLaruQYubANWyTQjTgGrQmmSsa9FGiWHhPEAIkUt65JjB9TIm2adulrQfcuTZfUOY5+M 5JdQ== MIME-Version: 1.0 X-Received: by 10.140.82.229 with SMTP id h92mr26287745qgd.51.1398660008283; Sun, 27 Apr 2014 21:40:08 -0700 (PDT) Received: by 10.140.30.98 with HTTP; Sun, 27 Apr 2014 21:40:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Apr 2014 10:10:08 +0530 Message-ID: From: Steev James To: rtcweb@ietf.org, coverdale@sympatico.ca, jmvalin@mozilla.com, "kiran.guduru@samsung.com" , cary.bran@plantronics.com Content-Type: multipart/alternative; boundary=001a11c12366f4922a04f812e8fa Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-dmkQWv8czh2Spcjq_SAIO1ipzk Subject: Re: [rtcweb] rtcweb Digest, Vol 38, Issue 51 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 04:40:10 -0000 --001a11c12366f4922a04f812e8fa Content-Type: text/plain; charset=UTF-8 Paul, What do you say, if another end point is using both G.711 and Opus at 8kHz and why ? Steev. >> Is that means spec is recommending G.711 (PCMA/PCMU) for sampling rate > >> less than or equal to 8 kHz? > > > >No. Opus is still a good idea for 8 kHz, but it's not 2119 RECOMMENDED > >since there are valid (mostly complexity-related) reasons to use G.711 > >despite the higher bit-rate. > > > > Jean-Marc > > Opus isn't a good idea for 8 KHz if you are trying to inter-operate with > another end-point using G.711. > > ...Paul > > > --001a11c12366f4922a04f812e8fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,
What do you say, if another end p= oint is using both G.711 and Opus at 8kHz and why ?

Steev.
=



>> Is that means spec is recommending G.711 (PCMA/PCMU) for sampling = rate
>> less than or equal to 8 kHz?
>
>No. Opus is still a good idea for 8 kHz, but it's not 2119 RECOMMEN= DED
>since there are valid (mostly complexity-related) reasons to use G.711<= br> >despite the higher bit-rate.
>
> =C2=A0 =C2=A0 =C2=A0 Jean-Marc

Opus isn't a good idea for 8 KHz if you are trying to inter-operate wit= h
another end-point using G.711.

...Paul



--001a11c12366f4922a04f812e8fa-- From nobody Sun Apr 27 22:53:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB441A071D for ; Sun, 27 Apr 2014 22:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.929 X-Spam-Level: X-Spam-Status: No, score=-3.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 OLJnY7TXpafH for ; Sun, 27 Apr 2014 22:53:45 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 94DCA1A070F for ; Sun, 27 Apr 2014 22:53:45 -0700 (PDT) Received: from panoramix.jmvalin.ca (unknown [50.94.78.179]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 76F96F2456; Sun, 27 Apr 2014 22:53:44 -0700 (PDT) Message-ID: <535DECE8.5020406@mozilla.com> Date: Mon, 28 Apr 2014 01:53:44 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Steev James , rtcweb@ietf.org, coverdale@sympatico.ca, "kiran.guduru@samsung.com" , cary.bran@plantronics.com References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QexFCipIoaH5YH_GL06LfwxzxzE Subject: Re: [rtcweb] rtcweb Digest, Vol 38, Issue 51 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 05:53:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So, if the other endpoint only supports G.711 (legacy), then it doesn't matter which codec you offer first. The the other endpoint supports both Opus and G.711, but only at 8 kHz, then it comes down to which of complexity or bandwidth is more important. On a corporate LAN you'd likely want to use G.711 while for chatting from your home, you'd usually want Opus. This is why the draft makes has no SHOULD when it comes to narrowband. Jean-Marc On 28/04/14 12:40 AM, Steev James wrote: > Paul, What do you say, if another end point is using both G.711 and > Opus at 8kHz and why ? > > Steev. > > > >>> Is that means spec is recommending G.711 (PCMA/PCMU) for >>> sampling > rate >>> less than or equal to 8 kHz? >> >> No. Opus is still a good idea for 8 kHz, but it's not 2119 >> RECOMMENDED since there are valid (mostly complexity-related) >> reasons to use G.711 despite the higher bit-rate. >> >> Jean-Marc > > Opus isn't a good idea for 8 KHz if you are trying to inter-operate > with another end-point using G.711. > > ...Paul > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTXezkAAoJEJ6/8sItn9q9DfEIAKy6ZPCE7o/dyBFhpt5tGpds XRDUiR++S89H4blgJOsR5nzzmkGwN+onN4cwBfz4Tbvi0Q7Q/UyzdlBePekC4gwL wrQL2/fwxfTnB0T6yfn2rrCd+i7jVWf2xJz0xJIY2qYAxYVg469PzeGMHTJK1+1x S1BDRZHZp4X/nSShthdthHvkfHrVPq5pDzexCfBc2h56+9Z3K1COdQlVZD/UJwQy twp8p6755LzucV4KdvN5NM5w9rjySBTAaUElU0WkyMPfRppowAkFhJunoJCTeIW9 8Stsm5yrAeasQhe9mlubceIYsTyjGfKkoO1RVkQUB2YwzctqyMnK14ZYJQbg8Us= =Ys9g -----END PGP SIGNATURE----- From nobody Mon Apr 28 02:26:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D511A06FA for ; Mon, 28 Apr 2014 02:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 x89k_hqEmxBr for ; Mon, 28 Apr 2014 02:25:56 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 965E91A010C for ; Mon, 28 Apr 2014 02:25:56 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id hw13so530807qab.5 for ; Mon, 28 Apr 2014 02:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=wl5GlT8DMXwer4HaOIjAjSZfczBtjO2DP8duyXtTzPo=; b=lKGACqhXK9Q4t3X+CfKnUEzs17n2ZnqpQeV4Mn9eWet1+ZQnm0GT5wGSoHWIdczj6o 7Tm4lcgXh+swnHStO47HpTvwVOk9tYy/Viq5TkDJXdwjOFaD/QhZLuWtn6GTEt1Nzs3v iQa0lRUcNCREAsgkUTZtwkYpreH9MJF8SUdC3IdyQ5xpqLpL5a70oXpFPqkugxEteIFU bh/UXdzLduGQOswVKa+UVINa2oK/8g/qg81H5VdM4CaZQblJBor8XASODv+dhcAsToDc 07Vti13eAcjJ310lw4sum99V0j30SOMmOT8IHMwCpwBQGQhZ6MxwEiNOel8jmLKEcNwd e+pA== MIME-Version: 1.0 X-Received: by 10.224.56.5 with SMTP id w5mr31072045qag.60.1398677155889; Mon, 28 Apr 2014 02:25:55 -0700 (PDT) Received: by 10.140.30.98 with HTTP; Mon, 28 Apr 2014 02:25:55 -0700 (PDT) Date: Mon, 28 Apr 2014 14:55:55 +0530 Message-ID: From: Steev James To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=001a11c300a608470404f816e729 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MRqMHFAdvUFksFMqvPJ176JH09w Cc: "kiran.guduru@samsung.com" , rtcweb@ietf.org, cary.bran@plantronics.com Subject: Re: [rtcweb] Query Regarding Mandatory audio codecs draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 09:25:59 -0000 --001a11c300a608470404f816e729 Content-Type: text/plain; charset=UTF-8 Means you say that G.711 uses less bandwidth than Opus at the expense of complexity. Am I right ? On Mon, Apr 28, 2014 at 11:23 AM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So, if the other endpoint only supports G.711 (legacy), then it > doesn't matter which codec you offer first. The the other endpoint > supports both Opus and G.711, but only at 8 kHz, then it comes down to > which of complexity or bandwidth is more important. On a corporate LAN > you'd likely want to use G.711 while for chatting from your home, > you'd usually want Opus. This is why the draft makes has no SHOULD > when it comes to narrowband. > > Jean-Marc > > On 28/04/14 12:40 AM, Steev James wrote: > > Paul, What do you say, if another end point is using both G.711 and > > Opus at 8kHz and why ? > > > > Steev. > > > > > > > >>> Is that means spec is recommending G.711 (PCMA/PCMU) for > >>> sampling > > rate > >>> less than or equal to 8 kHz? > >> > >> No. Opus is still a good idea for 8 kHz, but it's not 2119 > >> RECOMMENDED since there are valid (mostly complexity-related) > >> reasons to use G.711 despite the higher bit-rate. > >> > >> Jean-Marc > > > > Opus isn't a good idea for 8 KHz if you are trying to inter-operate > > with another end-point using G.711. > > > > ...Paul > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTXezkAAoJEJ6/8sItn9q9DfEIAKy6ZPCE7o/dyBFhpt5tGpds > XRDUiR++S89H4blgJOsR5nzzmkGwN+onN4cwBfz4Tbvi0Q7Q/UyzdlBePekC4gwL > wrQL2/fwxfTnB0T6yfn2rrCd+i7jVWf2xJz0xJIY2qYAxYVg469PzeGMHTJK1+1x > S1BDRZHZp4X/nSShthdthHvkfHrVPq5pDzexCfBc2h56+9Z3K1COdQlVZD/UJwQy > twp8p6755LzucV4KdvN5NM5w9rjySBTAaUElU0WkyMPfRppowAkFhJunoJCTeIW9 > 8Stsm5yrAeasQhe9mlubceIYsTyjGfKkoO1RVkQUB2YwzctqyMnK14ZYJQbg8Us= > =Ys9g > -----END PGP SIGNATURE----- > --001a11c300a608470404f816e729 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Means you say that G.711 uses less bandwidth than Opu= s at the expense of complexity.

Am I right ?


On Mon, Apr 28, 2= 014 at 11:23 AM, Jean-Marc Valin <jmvalin@mozilla.com> wro= te:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So, if the other endpoint only supports G.711 (legacy), then it
doesn't matter which codec you offer first. The the other endpoint
supports both Opus and G.711, but only at 8 kHz, then it comes down to
which of complexity or bandwidth is more important. On a corporate LAN
you'd likely want to use G.711 while for chatting from your home,
you'd usually want Opus. This is why the draft makes has no SHOULD
when it comes to narrowband.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc

On 28/04/14 12:40 AM, Steev James wrote:
> Paul, What do you say, if another end point is using both G.711 and > Opus at 8kHz and why ?
>
> Steev.
>
>
>
>>> Is that means spec is recommending G.711 (PCMA/PCMU) for
>>> sampling
> rate
>>> less than or equal to 8 kHz?
>>
>> No. Opus is still a good idea for 8 kHz, but it's not 2119
>> RECOMMENDED since there are valid (mostly complexity-related)
>> reasons to use G.711 despite the higher bit-rate.
>>
>> Jean-Marc
>
> Opus isn't a good idea for 8 KHz if you are trying to inter-operat= e
> with another end-point using G.711.
>
> ...Paul
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTXezkAAoJEJ6/8sItn9q9DfEIAKy6ZPCE7o/dyBFhpt5tGpds
XRDUiR++S89H4blgJOsR5nzzmkGwN+onN4cwBfz4Tbvi0Q7Q/UyzdlBePekC4gwL
wrQL2/fwxfTnB0T6yfn2rrCd+i7jVWf2xJz0xJIY2qYAxYVg469PzeGMHTJK1+1x
S1BDRZHZp4X/nSShthdthHvkfHrVPq5pDzexCfBc2h56+9Z3K1COdQlVZD/UJwQy
twp8p6755LzucV4KdvN5NM5w9rjySBTAaUElU0WkyMPfRppowAkFhJunoJCTeIW9
8Stsm5yrAeasQhe9mlubceIYsTyjGfKkoO1RVkQUB2YwzctqyMnK14ZYJQbg8Us=3D
=3DYs9g
-----END PGP SIGNATURE-----

--001a11c300a608470404f816e729-- From nobody Mon Apr 28 05:14:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B51B1A09EF for ; Mon, 28 Apr 2014 05:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 XGEgqzNQxtE2 for ; Mon, 28 Apr 2014 05:14:26 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 38C2C1A09EA for ; Mon, 28 Apr 2014 05:14:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0BA7F7C5318 for ; Mon, 28 Apr 2014 14:14:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kqSZ6tCw4Zd for ; Mon, 28 Apr 2014 14:14:22 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6562C7C51B4 for ; Mon, 28 Apr 2014 14:14:22 +0200 (CEST) Message-ID: <535E461E.8080803@alvestrand.no> Date: Mon, 28 Apr 2014 14:14:22 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wQfRfengf4-Vogf0Vh1l422hBHU Subject: Re: [rtcweb] Query Regarding Mandatory audio codecs draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:14:29 -0000 On 04/28/2014 11:25 AM, Steev James wrote: > Means you say that G.711 uses less bandwidth than Opus at the expense > of complexity. G.711 gives very low audio quality. The larger complexity of Opus means that it is able to give a much better quality at the same bandwidth. Personal opinion: The only time I'd be wanting to use G.711 if Opus is available is when I'm on a severely underpowered mobile phone. That platform is likely also so weak that I couldn't even imagine using video on it (video is order-of-magnitude more complex to encode/decode than Opus). From nobody Mon Apr 28 05:51:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3021A09EF for ; Mon, 28 Apr 2014 05:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 3UrvSi4STyM7 for ; Mon, 28 Apr 2014 05:51:16 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 510FC1A09F1 for ; Mon, 28 Apr 2014 05:51:16 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ib6so1604876vcb.19 for ; Mon, 28 Apr 2014 05:51:15 -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:content-type; bh=EaxR0ZtqcxrgaxUrbuuVwCw/9q0H8FLUrc2itxOcUbw=; b=kQttizkhqq6IcKntpNNSVN4hwvRN1tqFcOUBqd+Vvuz8MDzAk64qkarh7MgAiVfKqv GwRtpjMssMsF/B16AhaK4Hot7e6Zga6/AK99d8qRlWiRFgOkq+oNDrggY+IoalP0KwNJ cNvQiKtX23JzQXjxktTMTF5mugj3yp7YebekmfskFTHYS2Ua60Z63V8nd/VeXciU2gjM c0UlAgZD1BwdMGsDa3zW+ehte4LsK9F8186UFmQrWKcsdh6Y/8tV3O637h7cOSxSkIe7 kdqd7vYG15xzb/+7LwyST8UdDqOyL60Qg3I6QWDJd6SymaCW1tqLU+wrwiQRrKMUAlkl 0EPQ== MIME-Version: 1.0 X-Received: by 10.221.34.7 with SMTP id sq7mr23651600vcb.5.1398689475462; Mon, 28 Apr 2014 05:51:15 -0700 (PDT) Received: by 10.221.40.135 with HTTP; Mon, 28 Apr 2014 05:51:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Apr 2014 08:51:15 -0400 Message-ID: From: Stephen Botzko To: Steev James Content-Type: multipart/alternative; boundary=001a1136526a560c5f04f819c5f0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PUkg4y2gK45nsHlhEMryyxaA32g Cc: "rtcweb@ietf.org" , "kiran.guduru@samsung.com" , cary.bran@plantronics.com Subject: Re: [rtcweb] Query Regarding Mandatory audio codecs draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:51:20 -0000 --001a1136526a560c5f04f819c5f0 Content-Type: text/plain; charset=UTF-8 No. G.711 uses more network bandwidth than OPUS, but OPUS is more complex. The main benefit of using G.711 is that it can avoid the use of transcoding in some scenarios. My view is that the approach in the current text is correct - there is no need to specify a SHOULD on which codec is offered first. Stephen On Mon, Apr 28, 2014 at 5:25 AM, Steev James wrote: > Means you say that G.711 uses less bandwidth than Opus at the expense of > complexity. > > Am I right ? > > > On Mon, Apr 28, 2014 at 11:23 AM, Jean-Marc Valin wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> So, if the other endpoint only supports G.711 (legacy), then it >> doesn't matter which codec you offer first. The the other endpoint >> supports both Opus and G.711, but only at 8 kHz, then it comes down to >> which of complexity or bandwidth is more important. On a corporate LAN >> you'd likely want to use G.711 while for chatting from your home, >> you'd usually want Opus. This is why the draft makes has no SHOULD >> when it comes to narrowband. >> >> Jean-Marc >> >> On 28/04/14 12:40 AM, Steev James wrote: >> > Paul, What do you say, if another end point is using both G.711 and >> > Opus at 8kHz and why ? >> > >> > Steev. >> >> > >> > >> > >> >>> Is that means spec is recommending G.711 (PCMA/PCMU) for >> >>> sampling >> > rate >> >>> less than or equal to 8 kHz? >> >> >> >> No. Opus is still a good idea for 8 kHz, but it's not 2119 >> >> RECOMMENDED since there are valid (mostly complexity-related) >> >> reasons to use G.711 despite the higher bit-rate. >> >> >> >> Jean-Marc >> > >> > Opus isn't a good idea for 8 KHz if you are trying to inter-operate >> > with another end-point using G.711. >> > >> > ...Paul >> > >> > >> > >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQEcBAEBAgAGBQJTXezkAAoJEJ6/8sItn9q9DfEIAKy6ZPCE7o/dyBFhpt5tGpds >> XRDUiR++S89H4blgJOsR5nzzmkGwN+onN4cwBfz4Tbvi0Q7Q/UyzdlBePekC4gwL >> wrQL2/fwxfTnB0T6yfn2rrCd+i7jVWf2xJz0xJIY2qYAxYVg469PzeGMHTJK1+1x >> S1BDRZHZp4X/nSShthdthHvkfHrVPq5pDzexCfBc2h56+9Z3K1COdQlVZD/UJwQy >> twp8p6755LzucV4KdvN5NM5w9rjySBTAaUElU0WkyMPfRppowAkFhJunoJCTeIW9 >> 8Stsm5yrAeasQhe9mlubceIYsTyjGfKkoO1RVkQUB2YwzctqyMnK14ZYJQbg8Us= >> =Ys9g >> -----END PGP SIGNATURE----- >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1136526a560c5f04f819c5f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No. =C2=A0G.711 uses more network bandwidth than OPUS, but= OPUS is more complex.

The main benefit of using G.711 i= s that it can avoid the use of transcoding in some scenarios.
=
My view is that the approach in the current text is correct - th= ere is no need to specify a SHOULD on which codec is offered first.

Stephen


On Mon, Apr 28, 2014 at 5:25 AM, Steev James= <steev.a.james@gmail.com> wrote:
Means you say that G.711 uses less bandwidth than Opu= s at the expense of complexity.

Am I right ?


O= n Mon, Apr 28, 2014 at 11:23 AM, Jean-Marc Valin <jmvalin@mozilla.com> wrote:
-----BEGIN PGP SIGNED = MESSAGE-----
Hash: SHA1

So, if the other endpoint only supports G.711 (legacy), then it
doesn't matter which codec you offer first. The the other endpoint
supports both Opus and G.711, but only at 8 kHz, then it comes down to
which of complexity or bandwidth is more important. On a corporate LAN
you'd likely want to use G.711 while for chatting from your home,
you'd usually want Opus. This is why the draft makes has no SHOULD
when it comes to narrowband.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc

On 28/04/14 12:40 AM, Steev James wrote:
> Paul, What do you say, if another end point is using both G.711 and > Opus at 8kHz and why ?
>
> Steev.

>
>
>
>>> Is that means spec is recommending G.711 (PCMA/PCMU) for
>>> sampling
> rate
>>> less than or equal to 8 kHz?
>>
>> No. Opus is still a good idea for 8 kHz, but it's not 2119
>> RECOMMENDED since there are valid (mostly complexity-related)
>> reasons to use G.711 despite the higher bit-rate.
>>
>> Jean-Marc
>
> Opus isn't a good idea for 8 KHz if you are trying to inter-operat= e
> with another end-point using G.711.
>
> ...Paul
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTXezkAAoJEJ6/8sItn9q9DfEIAKy6ZPCE7o/dyBFhpt5tGpds
XRDUiR++S89H4blgJOsR5nzzmkGwN+onN4cwBfz4Tbvi0Q7Q/UyzdlBePekC4gwL
wrQL2/fwxfTnB0T6yfn2rrCd+i7jVWf2xJz0xJIY2qYAxYVg469PzeGMHTJK1+1x
S1BDRZHZp4X/nSShthdthHvkfHrVPq5pDzexCfBc2h56+9Z3K1COdQlVZD/UJwQy
twp8p6755LzucV4KdvN5NM5w9rjySBTAaUElU0WkyMPfRppowAkFhJunoJCTeIW9
8Stsm5yrAeasQhe9mlubceIYsTyjGfKkoO1RVkQUB2YwzctqyMnK14ZYJQbg8Us=3D
=3DYs9g
-----END PGP SIGNATURE-----


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--001a1136526a560c5f04f819c5f0-- From nobody Mon Apr 28 06:46:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32341A0A18 for ; Mon, 28 Apr 2014 06:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 OziNz_O0X33q for ; Mon, 28 Apr 2014 06:46:23 -0700 (PDT) Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0811A0795 for ; Mon, 28 Apr 2014 06:46:22 -0700 (PDT) Received: from BLU0-SMTP21 ([65.55.116.72]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Apr 2014 06:46:22 -0700 X-TMN: [rh2I5YYc7OREYYkDcPV/fAA5FUwHug1H] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.38.66]) by BLU0-SMTP21.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Apr 2014 06:46:21 -0700 From: Paul Coverdale To: "'Steev James'" , "'Jean-Marc Valin'" References: In-Reply-To: Date: Mon, 28 Apr 2014 09:46:18 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01CF62C6.B4F95700" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9iw9uhCCquOqr/QPOOwKLn2TaMvAAIef9A Content-Language: en-us X-OriginalArrivalTime: 28 Apr 2014 13:46:21.0698 (UTC) FILETIME=[3D463620:01CF62E8] Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZlelgDivhHbNy0g5s120l-cVmws Cc: kiran.guduru@samsung.com, rtcweb@ietf.org, cary.bran@plantronics.com Subject: Re: [rtcweb] Query Regarding Mandatory audio codecs draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 13:46:25 -0000 ------=_NextPart_000_0044_01CF62C6.B4F95700 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we=E2=80=99re mixing up sampling frequency and bit-rate here. =20 By definition, G.711 uses a sampling frequency of 8 KHz and encodes each = sample with an 8-bit logarithmically companded, encoding law (A or Mu), = resulting in an output bit-rate of 64 kbit/s.=20 =20 Opus can operate with a number of different sampling frequencies = (depending on the desired audio bandwidth) and output bit-rates, = including 64 kbit/s. =20 The point I was trying to make is that, even if both codecs provide the = same numerical bit-rate, they are not compatible between end-points. If = a legacy end-point can only support G.711, it=E2=80=99s no good sending = it anything else but G.711. =20 ...Paul =20 From: Steev James [mailto:steev.a.james@gmail.com]=20 Sent: Monday, April 28, 2014 5:26 AM To: Jean-Marc Valin Cc: rtcweb@ietf.org; coverdale@sympatico.ca; kiran.guduru@samsung.com; = cary.bran@plantronics.com Subject: Re:Query Regarding Mandatory audio codecs draft =20 Means you say that G.711 uses less bandwidth than Opus at the expense of = complexity. Am I right ? =20 On Mon, Apr 28, 2014 at 11:23 AM, Jean-Marc Valin = wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So, if the other endpoint only supports G.711 (legacy), then it doesn't matter which codec you offer first. The the other endpoint supports both Opus and G.711, but only at 8 kHz, then it comes down to which of complexity or bandwidth is more important. On a corporate LAN you'd likely want to use G.711 while for chatting from your home, you'd usually want Opus. This is why the draft makes has no SHOULD when it comes to narrowband. Jean-Marc On 28/04/14 12:40 AM, Steev James wrote: > Paul, What do you say, if another end point is using both G.711 and > Opus at 8kHz and why ? > > Steev. > > > >>> Is that means spec is recommending G.711 (PCMA/PCMU) for >>> sampling > rate >>> less than or equal to 8 kHz? >> >> No. Opus is still a good idea for 8 kHz, but it's not 2119 >> RECOMMENDED since there are valid (mostly complexity-related) >> reasons to use G.711 despite the higher bit-rate. >> >> Jean-Marc > > Opus isn't a good idea for 8 KHz if you are trying to inter-operate > with another end-point using G.711. > > ...Paul > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTXezkAAoJEJ6/8sItn9q9DfEIAKy6ZPCE7o/dyBFhpt5tGpds XRDUiR++S89H4blgJOsR5nzzmkGwN+onN4cwBfz4Tbvi0Q7Q/UyzdlBePekC4gwL wrQL2/fwxfTnB0T6yfn2rrCd+i7jVWf2xJz0xJIY2qYAxYVg469PzeGMHTJK1+1x S1BDRZHZp4X/nSShthdthHvkfHrVPq5pDzexCfBc2h56+9Z3K1COdQlVZD/UJwQy twp8p6755LzucV4KdvN5NM5w9rjySBTAaUElU0WkyMPfRppowAkFhJunoJCTeIW9 8Stsm5yrAeasQhe9mlubceIYsTyjGfKkoO1RVkQUB2YwzctqyMnK14ZYJQbg8Us=3D =3DYs9g -----END PGP SIGNATURE----- =20 ------=_NextPart_000_0044_01CF62C6.B4F95700 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I think we=E2=80=99re mixing up sampling frequency and bit-rate = here.

 

By definition, G.711 uses a sampling frequency of 8 KHz and encodes = each sample with an 8-bit logarithmically companded, encoding law (A or = Mu), resulting in an output bit-rate of 64 kbit/s. =

 

Opus can operate with a number of different sampling frequencies = (depending on the desired audio bandwidth) and output bit-rates, = including 64 kbit/s.

 

The point I was trying to make is that, even if both codecs provide = the same numerical bit-rate, they are not compatible between end-points. = If a legacy end-point can only support G.711, it=E2=80=99s no good = sending it anything else but G.711.

 

...Paul

 

From:= = Steev James [mailto:steev.a.james@gmail.com]
Sent: Monday, = April 28, 2014 5:26 AM
To: Jean-Marc Valin
Cc: = rtcweb@ietf.org; coverdale@sympatico.ca; kiran.guduru@samsung.com; = cary.bran@plantronics.com
Subject: Re:Query Regarding = Mandatory audio codecs draft

 

Means you say that G.711 uses less = bandwidth than Opus at the expense of complexity.

Am I right ?

 

On Mon, Apr 28, 2014 at 11:23 AM, Jean-Marc Valin = <jmvalin@mozilla.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1

So, if the other endpoint only supports G.711 (legacy), then = it
doesn't matter which codec you offer first. The the other = endpoint
supports both Opus and G.711, but only at 8 kHz, then it = comes down to
which of complexity or bandwidth is more important. On = a corporate LAN
you'd likely want to use G.711 while for chatting = from your home,
you'd usually want Opus. This is why the draft makes = has no SHOULD
when it comes to narrowband.

    =     Jean-Marc


On 28/04/14 12:40 AM, Steev James wrote:
> = Paul, What do you say, if another end point is using both G.711 = and
> Opus at 8kHz and why ?
>
> = Steev.
>
>
>
>>> Is that means spec is = recommending G.711 (PCMA/PCMU) for
>>> sampling
> = rate
>>> less than or equal to 8 = kHz?
>>
>> No. Opus is still a good idea for 8 kHz, = but it's not 2119
>> RECOMMENDED since there are valid (mostly = complexity-related)
>> reasons to use G.711 despite the higher = bit-rate.
>>
>> Jean-Marc
>
> Opus isn't a = good idea for 8 KHz if you are trying to inter-operate
> with = another end-point using G.711.
>
> = ...Paul
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG = v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTXez= kAAoJEJ6/8sItn9q9DfEIAKy6ZPCE7o/dyBFhpt5tGpds
XRDUiR++S89H4blgJOsR5nzz= mkGwN+onN4cwBfz4Tbvi0Q7Q/UyzdlBePekC4gwL
wrQL2/fwxfTnB0T6yfn2rrCd+i7jV= Wf2xJz0xJIY2qYAxYVg469PzeGMHTJK1+1x
S1BDRZHZp4X/nSShthdthHvkfHrVPq5pDz= exCfBc2h56+9Z3K1COdQlVZD/UJwQy
twp8p6755LzucV4KdvN5NM5w9rjySBTAaUElU0W= kyMPfRppowAkFhJunoJCTeIW9
8Stsm5yrAeasQhe9mlubceIYsTyjGfKkoO1RVkQUB2Yw= zctqyMnK14ZYJQbg8Us=3D
=3DYs9g
-----END PGP = SIGNATURE-----

 

------=_NextPart_000_0044_01CF62C6.B4F95700-- From nobody Mon Apr 28 08:16:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8AF1A6EFE for ; Mon, 28 Apr 2014 08:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 h1MdcFPjb8tz for ; Mon, 28 Apr 2014 08:16:48 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A53AD1A6F05 for ; Mon, 28 Apr 2014 08:16:48 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id c1so4869338igq.10 for ; Mon, 28 Apr 2014 08:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=P4H1743t7YXrzNeEscbbOFjRwCr78ptODP8SP+jDsCo=; b=wPORPMwiIctVBAqYrdH9KMlCL+I3FNlQrDSHbsGc2B56Z6fLThbPAiav8pzVJo9SYI 0UqxG6t11MqaYvbdb5mt78u8mdytyQ/l6W+AfvsTlgdawNeigd/UzGbzCcGhA0NIbmL1 T1sZvQRgXhVNWLt9BdwUqhbaIeWdHWvpj3JIJH2obeBWz+pVQG5V6wZ1xmTb4kKMSPaM soeaUS1jyRDMgTqmj+gAquCL9QU0wO28PTNsp5CZFQT/7Y4hS2yHLmUrJt1UYJ83U38e kXVZoZRgGRxKV33izAa8cR3m+4pE6rbwSyLBWv0GjCUYLmjqZeaBNTWALcm/8dCOBdID Rk1A== MIME-Version: 1.0 X-Received: by 10.50.79.134 with SMTP id j6mr24062130igx.6.1398698207721; Mon, 28 Apr 2014 08:16:47 -0700 (PDT) Received: by 10.42.200.204 with HTTP; Mon, 28 Apr 2014 08:16:47 -0700 (PDT) Date: Mon, 28 Apr 2014 08:16:47 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e0112c3b0d1d4c204f81bcd31 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pXtC99PK0etyPB7YQOxapKn7flY Subject: [rtcweb] Document mechanics for JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 15:16:50 -0000 --089e0112c3b0d1d4c204f81bcd31 Content-Type: text/plain; charset=UTF-8 Howdy, In order to increase the velocity of our work, the chairs would like to make some changes to how we approach the document editing for JSEP. First, we have asked Eric Rescorla to act as an editor of the document. Cullen and Justin will, of course, continue to be listed as authors, but the day-to-day editorial work will be done by ekr. Second, we would like to work using github as the repository of the working copy, with pull requests for specific text changes there. The repository is at: https://github.com/rtcweb-wg/jsep Note that issues can be raised there, but that non-editorial issues must then be submitted to the mailing list, and substantive discussion of those issues should remain on the mailing list. This approach has worked well in the HTTP and TLS working groups, and we hope it can help us deliver in a timely way. Let us know if there are questions or concerns, thanks, Ted and Sean (Cullen recused) --089e0112c3b0d1d4c204f81bcd31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How= dy,

In order to increase the velocity of our work, the chairs would like to=20 make some changes to how we approach the document editing for JSEP.=C2=A0= =20 First, we have asked Eric Rescorla to act as an editor of the document.=C2= =A0 Cullen and Justin will, of course, continue to be listed as authors,=20 but the day-to-day editorial work will be done by ekr.=C2=A0 Second, we wou= ld like to work using github as the repository of the working copy, with=20 pull requests for specific text changes there.=C2=A0 The repository is at:<= br>
https:/= /github.com/rtcweb-wg/jsep

Note that issues can be raised there, but that non-editorial issues must=20 then be submitted to the mailing list, and=C2=A0 substantive discussion of= =20 those issues should remain on the mailing list.=C2=A0

= This approach has worked well in the HTTP and TLS working groups, and we ho= pe it can help us deliver in a timely way.

Let us know if there are questions or concerns,

thanks,

Ted a= nd Sean (Cullen recused)
--089e0112c3b0d1d4c204f81bcd31-- From nobody Mon Apr 28 08:19:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEC11A6EFE for ; Mon, 28 Apr 2014 08:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 BdvqfdQCvuOr for ; Mon, 28 Apr 2014 08:19:43 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 286AD1A08C5 for ; Mon, 28 Apr 2014 08:19:43 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id tp5so3387505ieb.27 for ; Mon, 28 Apr 2014 08:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ARitMOJ0ivB0yk80x7n8dMCUphx3jUZqh3BUC5Dw4Uk=; b=VJluX51/3HZtxSeRJLkvyVjAjSaRqN5IE3CTASYDDM8g3pac/T0Sk+Mn/VEigCdt2f FmUZCxZ9YXj5VvtjZtiZ2ShnIXTgupYRcPKuzKxpL1+fNnptXDNIZs2q90B9kmZr9+MV uT52Xzo7rIU4pQPY9CfrYahXCvfMMb4KbYMeA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ARitMOJ0ivB0yk80x7n8dMCUphx3jUZqh3BUC5Dw4Uk=; b=C6WY5xutAzX3NVImSYJrgIANAMiJdH/DEt+uT/CBVgeUhViFyWZlt66sbr/kenPMLy 9Ff2A0i/zvu2H5y/uIlucgzQAOWC/jbIfiaanqMX5NawZogpqlWunTjfTjmmd3H5lYvC pJmFnwRM7pDa1uTeJ3H4dPMKDJDKo+hN4zyUnTW/3GtXNbNF4EWUjUONqmCuPJ2FFsjk uh3lSyeuD9SF7n6Jv8ZxP9dQNUcRortQotge1JJqvVMCGFWPMvNJTXvahin7xWPvdC1+ XcE7TS58NVyfXhMZkhsu+AKa7WEUWkeZjuPKiTEAdWtcXTrRFcR/y1+uBhb4MYoKqNKF GOYg== X-Gm-Message-State: ALoCoQnly2q4UxkeLAMvhVf9b+PoMrvLpv0fBkYPSc8i5Az2RN+dPFLNCHl3cNIoouuBJvmUW/MP X-Received: by 10.50.238.229 with SMTP id vn5mr25015614igc.45.1398698382348; Mon, 28 Apr 2014 08:19:42 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.129]) by mx.google.com with ESMTPSA id k8sm26582595ige.0.2014.04.28.08.19.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 08:19:41 -0700 (PDT) Message-ID: <535E7197.3040905@getjive.com> Date: Mon, 28 Apr 2014 09:19:51 -0600 From: Jessie Morris User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <535E461E.8080803@alvestrand.no> In-Reply-To: <535E461E.8080803@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/c5UQ3FlvnVD4r8yIUpfdVgoopJQ Subject: Re: [rtcweb] Query Regarding Mandatory audio codecs draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 15:19:45 -0000 The only situation that it would make sense to use G.711 and video is on a weak platform that happens to have hardware decoding capabilities for H.264 or VP8 or whatever the video codec is. I don't think there are a lot of these currently, but it is possible. On 2014-04-28, 06:14, Harald Alvestrand wrote: > On 04/28/2014 11:25 AM, Steev James wrote: >> Means you say that G.711 uses less bandwidth than Opus at the expense >> of complexity. > > G.711 gives very low audio quality. The larger complexity of Opus > means that it is able to give a much better quality at the same > bandwidth. > > Personal opinion: The only time I'd be wanting to use G.711 if Opus is > available is when I'm on a severely underpowered mobile phone. That > platform is likely also so weak that I couldn't even imagine using > video on it (video is order-of-magnitude more complex to encode/decode > than Opus). > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Jessie A. Morris Jive Communications, Inc. jmorris@getjive.com From nobody Mon Apr 28 09:19:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BC61A6F25 for ; Mon, 28 Apr 2014 09:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 hqhudTykhylL for ; Mon, 28 Apr 2014 09:19:20 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8731A6F41 for ; Mon, 28 Apr 2014 09:19:14 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id b13so572426wgh.19 for ; Mon, 28 Apr 2014 09:19: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:content-type; bh=9k+IJMKzH3HMci81o+6mRUeb7cvokQRVwMstGEMtWag=; b=Uj1bkhq3bj9bFZOhDvbNAAn6VyKZQdC9mS+8VI7D7ZNDCFi2lUMz6zvRo5i1pgaTOV f7V4JMtm2dDMCqdXJ3SAkU2ucgT1lsVr0kHHsmVRcyRn4jq5AS2QvMhOuKhDy0A7ITLN Iaru1QzSbHSvUPBtwzVNI424HhTP/bMt6kM8JMGz6+bl3tmREzLIMeSsjVCVJaocvKbN LForCsZmsEmHHapuN0q1k45027Bc8g1r4CuKji9lSBKiFvapwAZet0sUvqZIHpTS/aoL zWbhWD1oILYU/b0RA0tFFXixFKe4T8+Ar3+EXreWVu0Nvuu3WmbzDXsLSZvxAyBoT/Mr UpoA== MIME-Version: 1.0 X-Received: by 10.194.81.164 with SMTP id b4mr20163259wjy.2.1398701953226; Mon, 28 Apr 2014 09:19:13 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Mon, 28 Apr 2014 09:19:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Apr 2014 09:19:13 -0700 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/j4pfo3ClQ7K4vb0MaSKzWNc4rv8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Document mechanics for JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 16:19:21 -0000 On 28 April 2014 08:16, Ted Hardie wrote: > The repository is at: > > https://github.com/rtcweb-wg/jsep Good. From nobody Mon Apr 28 11:23:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D2B1A6FB5 for ; Mon, 28 Apr 2014 11:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 75jJDs9qY0te for ; Mon, 28 Apr 2014 11:23:25 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 13BB51A6FB2 for ; Mon, 28 Apr 2014 11:23:24 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id im17so8823745vcb.0 for ; Mon, 28 Apr 2014 11:23:24 -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:content-type; bh=DsZ3USRSOTrTfD+7kkkcPnnJ3SqDHWr1QVwLnSo6p+Q=; b=njMIz3jwHLpvSERKuDCX8FztnB9H5RLl0B2S5BXSyzKkJ97EfECNcI1+IRwADZX5o2 OAp4QMOa9aunznwTDrXu2ewSSVY73tyXFMuEfbdT015SSwHR12ewJ5cG+xSWgw6UxnA2 3SaH0vG4rlghimdxjP7JATy9Oikbx4/pbxRmCwlMPDQa8nw0WGuEj+MyRtlA9qhOf79f wmcE7+4GsuWVCXHIt0q5uYjUCIu3uTrjpVN1nyVzjCyX5tU1bAzeQMk/DWJrXBsbWVZQ YgnlsuSeCh6M28Bx6MFLfLQ2tOW22fWzM/hTcdjjZ2yD4BIsbbj7ZP7qo0HwxVu1bMrJ F29w== MIME-Version: 1.0 X-Received: by 10.221.34.7 with SMTP id sq7mr24904344vcb.5.1398709404173; Mon, 28 Apr 2014 11:23:24 -0700 (PDT) Received: by 10.221.40.135 with HTTP; Mon, 28 Apr 2014 11:23:24 -0700 (PDT) In-Reply-To: <535E7197.3040905@getjive.com> References: <535E461E.8080803@alvestrand.no> <535E7197.3040905@getjive.com> Date: Mon, 28 Apr 2014 14:23:24 -0400 Message-ID: From: Stephen Botzko To: Jessie Morris Content-Type: multipart/alternative; boundary=001a1136526a2e0a2604f81e69b7 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TcnCC7TISOd_43HZBoEpSu9o1ec Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Query Regarding Mandatory audio codecs draft X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:23:27 -0000 --001a1136526a2e0a2604f81e69b7 Content-Type: text/plain; charset=UTF-8 The mandatory codec question for audio is long settled, and personally I am thinking we really don't want to reopen that discussion. The original poster was wanting to know if G.711 was preferred over OPUS for narrow band. The answer given was "no". Is there really a need to discuss this more? Stephen On Mon, Apr 28, 2014 at 11:19 AM, Jessie Morris wrote: > The only situation that it would make sense to use G.711 and video is on a > weak platform that happens to have hardware decoding capabilities for H.264 > or VP8 or whatever the video codec is. I don't think there are a lot of > these currently, but it is possible. > > > On 2014-04-28, 06:14, Harald Alvestrand wrote: > >> On 04/28/2014 11:25 AM, Steev James wrote: >> >>> Means you say that G.711 uses less bandwidth than Opus at the expense of >>> complexity. >>> >> >> G.711 gives very low audio quality. The larger complexity of Opus means >> that it is able to give a much better quality at the same bandwidth. >> >> Personal opinion: The only time I'd be wanting to use G.711 if Opus is >> available is when I'm on a severely underpowered mobile phone. That >> platform is likely also so weak that I couldn't even imagine using video on >> it (video is order-of-magnitude more complex to encode/decode than Opus). >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > -- > Jessie A. Morris > Jive Communications, Inc. > jmorris@getjive.com > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1136526a2e0a2604f81e69b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The mandatory codec question for audio is long settle= d, and personally I am thinking we really don't want to reopen that dis= cussion. =C2=A0

The original poster was wantin= g to know if G.711 was preferred over OPUS for narrow band. =C2=A0The answe= r given was "no". =C2=A0Is there really a need to discuss this mo= re?

Stephen =C2=A0


=
On Mon, Apr 28, 2014 at 11:19 AM, Jessie Morris = <jmorris@getjive.com> wrote:
The only situation that it would make sense = to use G.711 and video is on a weak platform that happens to have hardware = decoding capabilities for H.264 or VP8 or whatever the video codec is. I do= n't think there are a lot of these currently, but it is possible.


On 2014-04-28, 06:14, Harald Alvestrand wrote:
On 04/28/2014 11:25 AM, Steev James wrote:
Means you say that G.711 uses less bandwidth than Opus at the expense of co= mplexity.

G.711 gives very low audio quality. The larger complexity of Opus means tha= t it is able to give a much better quality at the same bandwidth.

Personal opinion: The only time I'd be wanting to use G.711 if Opus is = available is when I'm on a severely underpowered mobile phone. That pla= tform is likely also so weak that I couldn't even imagine using video o= n it (video is order-of-magnitude more complex to encode/decode than Opus).=

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
--
Jessie A. Morris
Jive Communications, Inc.
jmorris@getjive.co= m


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--001a1136526a2e0a2604f81e69b7-- From nobody Mon Apr 28 11:42:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C9C1A6FB5 for ; Mon, 28 Apr 2014 11:42:08 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 WdC84KIH2m-K for ; Mon, 28 Apr 2014 11:42:06 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 412DB1A6FB7 for ; Mon, 28 Apr 2014 11:42:06 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-f6-535ea0fcbf8e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 59.35.04199.CF0AE535; Mon, 28 Apr 2014 20:42:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Mon, 28 Apr 2014 20:42:04 +0200 From: Christer Holmberg To: Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Document mechanics for JSEP Thread-Index: AQHPYvTjwPvcFVrKX0WRf0CsM7KfqpsnXQFw Date: Mon, 28 Apr 2014 18:42:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2E2AEF@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2E2AEFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvje7fBXHBBu87mSzW/mtnt2ica+fA 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZWz9dpy14IJ3xYrm9WwNjEc8uxg5OSQETCSa nnewQNhiEhfurWfrYuTiEBI4yijRtPgTI4SzhFHi18dtQFUcHGwCFhLd/7RBGkQEPCQ2/f3N CmILCxhKdG3qZgIpEREwkri7zgnGPPTUEaSCRUBV4vKaDlaQMK+Ar8SrdlGQsJBAgMTzBVvY QGxOgUCJKx8ugg1kBLrm+6k1TCA2s4C4xK0n85kgrhSQWLLnPDOELSrx8vE/VghbSWLF9kuM EPX5Ej0rb4F9xSsgKHFy5hOWCYwis5CMmoWkbBaSsllA1zELaEqs36UPUaIoMaX7ITuErSHR OmcuO7L4Akb2VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiB0XRwy2+DHYwvnzseYhTgYFTi 4S3+EhksxJpYVlyZe4hRmoNFSZz321n3YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MPXxX esIT/zx5N032TlLW0+9H/PiC+FMFv6mUqy5rfXowZX/t0nwJXh25FWfkdi8KECpbdT/x3H7B S1NPnrpn8/1xzplDMg67Oqtr9+y60y6/nUc3tN1XfG5l4CInibt26tvE7/id2PVvTtaDJNv1 dTPEhR6bP7f11EucLSBocGx3v/jtjA8RSizFGYmGWsxFxYkAuBbuH4cCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SBBqERLr-nhsYxPMe4mnOAE8IwM Subject: Re: [rtcweb] Document mechanics for JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:42:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2E2AEFESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZW7igJl0IHVzZWQgdGhlIGdpdGh1YiBhcHByb2FjaCBmb3IgZHJhZnRzIGJl Zm9yZSwgYnV0IEkgYW0gZmluZSB0byBnaXZlIGl0IGEgdHJ5IDopDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgVGVkIEhhcmRpZQ0KU2VudDogMjggQXByaWwgMjAxNCAxODoxNw0KVG86IHJ0 Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogW3J0Y3dlYl0gRG9jdW1lbnQgbWVjaGFuaWNzIGZvciBK U0VQDQoNCkhvd2R5LA0KSW4gb3JkZXIgdG8gaW5jcmVhc2UgdGhlIHZlbG9jaXR5IG9mIG91ciB3 b3JrLCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gbWFrZSBzb21lIGNoYW5nZXMgdG8gaG93IHdl IGFwcHJvYWNoIHRoZSBkb2N1bWVudCBlZGl0aW5nIGZvciBKU0VQLiAgRmlyc3QsIHdlIGhhdmUg YXNrZWQgRXJpYyBSZXNjb3JsYSB0byBhY3QgYXMgYW4gZWRpdG9yIG9mIHRoZSBkb2N1bWVudC4g IEN1bGxlbiBhbmQgSnVzdGluIHdpbGwsIG9mIGNvdXJzZSwgY29udGludWUgdG8gYmUgbGlzdGVk IGFzIGF1dGhvcnMsIGJ1dCB0aGUgZGF5LXRvLWRheSBlZGl0b3JpYWwgd29yayB3aWxsIGJlIGRv bmUgYnkgZWtyLiAgU2Vjb25kLCB3ZSB3b3VsZCBsaWtlIHRvIHdvcmsgdXNpbmcgZ2l0aHViIGFz IHRoZSByZXBvc2l0b3J5IG9mIHRoZSB3b3JraW5nIGNvcHksIHdpdGggcHVsbCByZXF1ZXN0cyBm b3Igc3BlY2lmaWMgdGV4dCBjaGFuZ2VzIHRoZXJlLiAgVGhlIHJlcG9zaXRvcnkgaXMgYXQ6DQoN Cmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNlcA0KTm90ZSB0aGF0IGlzc3VlcyBjYW4g YmUgcmFpc2VkIHRoZXJlLCBidXQgdGhhdCBub24tZWRpdG9yaWFsIGlzc3VlcyBtdXN0IHRoZW4g YmUgc3VibWl0dGVkIHRvIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCAgc3Vic3RhbnRpdmUgZGlzY3Vz c2lvbiBvZiB0aG9zZSBpc3N1ZXMgc2hvdWxkIHJlbWFpbiBvbiB0aGUgbWFpbGluZyBsaXN0Lg0K VGhpcyBhcHByb2FjaCBoYXMgd29ya2VkIHdlbGwgaW4gdGhlIEhUVFAgYW5kIFRMUyB3b3JraW5n IGdyb3VwcywgYW5kIHdlIGhvcGUgaXQgY2FuIGhlbHAgdXMgZGVsaXZlciBpbiBhIHRpbWVseSB3 YXkuDQpMZXQgdXMga25vdyBpZiB0aGVyZSBhcmUgcXVlc3Rpb25zIG9yIGNvbmNlcm5zLA0KDQp0 aGFua3MsDQoNClRlZCBhbmQgU2VhbiAoQ3VsbGVuIHJlY3VzZWQpDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D2E2AEFESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1 IDIgNSA0IDUgMiAzIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgaGF2ZW7igJl0IHVzZWQgdGhlIGdpdGh1YiBhcHByb2Fj aCBmb3IgZHJhZnRzIGJlZm9yZSwgYnV0IEkgYW0gZmluZSB0byBnaXZlIGl0IGEgdHJ5IDopPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0 bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGVkIEhhcmRp ZTxicj4NCjxiPlNlbnQ6PC9iPiAyOCBBcHJpbCAyMDE0IDE4OjE3PGJyPg0KPGI+VG86PC9iPiBy dGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3J0Y3dlYl0gRG9jdW1lbnQgbWVj aGFuaWNzIGZvciBKU0VQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Ib3dkeSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtHZW9yZ2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JbiBvcmRlciB0byBpbmNyZWFzZSB0 aGUgdmVsb2NpdHkgb2Ygb3VyIHdvcmssIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBtYWtlIHNv bWUgY2hhbmdlcyB0byBob3cgd2UgYXBwcm9hY2ggdGhlIGRvY3VtZW50IGVkaXRpbmcgZm9yIEpT RVAuJm5ic3A7IEZpcnN0LCB3ZSBoYXZlIGFza2VkIEVyaWMNCiBSZXNjb3JsYSB0byBhY3QgYXMg YW4gZWRpdG9yIG9mIHRoZSBkb2N1bWVudC4mbmJzcDsgQ3VsbGVuIGFuZCBKdXN0aW4gd2lsbCwg b2YgY291cnNlLCBjb250aW51ZSB0byBiZSBsaXN0ZWQgYXMgYXV0aG9ycywgYnV0IHRoZSBkYXkt dG8tZGF5IGVkaXRvcmlhbCB3b3JrIHdpbGwgYmUgZG9uZSBieSBla3IuJm5ic3A7IFNlY29uZCwg d2Ugd291bGQgbGlrZSB0byB3b3JrIHVzaW5nIGdpdGh1YiBhcyB0aGUgcmVwb3NpdG9yeSBvZiB0 aGUgd29ya2luZyBjb3B5LCB3aXRoDQogcHVsbCByZXF1ZXN0cyBmb3Igc3BlY2lmaWMgdGV4dCBj aGFuZ2VzIHRoZXJlLiZuYnNwOyBUaGUgcmVwb3NpdG9yeSBpcyBhdDo8YnI+DQo8YnI+DQo8YSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXA8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Tm90ZSB0aGF0IGlzc3VlcyBjYW4gYmUgcmFpc2VkIHRoZXJlLCBi dXQgdGhhdCBub24tZWRpdG9yaWFsIGlzc3VlcyBtdXN0IHRoZW4gYmUgc3VibWl0dGVkIHRvIHRo ZSBtYWlsaW5nIGxpc3QsIGFuZCZuYnNwOyBzdWJzdGFudGl2ZSBkaXNjdXNzaW9uIG9mIHRob3Nl IGlzc3VlcyBzaG91bGQNCiByZW1haW4gb24gdGhlIG1haWxpbmcgbGlzdC4mbmJzcDsgPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhpcyBhcHByb2FjaCBoYXMgd29ya2Vk IHdlbGwgaW4gdGhlIEhUVFAgYW5kIFRMUyB3b3JraW5nIGdyb3VwcywgYW5kIHdlIGhvcGUgaXQg Y2FuIGhlbHAgdXMgZGVsaXZlciBpbiBhIHRpbWVseSB3YXkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+TGV0IHVzIGtub3cgaWYgdGhl cmUgYXJlIHF1ZXN0aW9ucyBvciBjb25jZXJucyw8YnI+DQo8YnI+DQp0aGFua3MsPGJyPg0KPGJy Pg0KVGVkIGFuZCBTZWFuIChDdWxsZW4gcmVjdXNlZCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D2E2AEFESESSMB209erics_-- From nobody Wed Apr 30 14:09:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533BD1A063B for ; Wed, 30 Apr 2014 14:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 dYdbHw4-9wvg for ; Wed, 30 Apr 2014 14:09:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 172161A0852 for ; Wed, 30 Apr 2014 14:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1180; q=dns/txt; s=iport; t=1398892160; x=1400101760; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aGLQdhEq1Wv3wBlhQebhgdcmgb3unS3jH7MjhAMHqp4=; b=FhcoJsyM1mrmU+cBlmGCyY1hebXdRDVdzfcGsVINTJfU9cLAr3nbHdyQ Kx+kIGOweFX0ZCcJxlAB87XmzDdjGDvtH2E3P3E3zd7D1tid1B6l1Ppcx aREpxFpWbNolNS4JhfghhPAh8noIcVu1IApsZVaiRtlYNogvuTNZsjvjs s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAAZmYVOtJA2K/2dsb2JhbABZgwaBJsRMgSEWdIIlAQEBAwE6PwULAgEINhAyJQIEDgWIOQjKBReJMIRuMweDJIEVAQOVM4N0kmuDMYIr X-IronPort-AV: E=Sophos;i="4.97,960,1389744000"; d="scan'208";a="321359069" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP; 30 Apr 2014 21:09:20 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3UL9KeY009425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 21:09:20 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 16:09:20 -0500 From: "Cullen Jennings (fluffy)" To: Matthew Kaufman Thread-Topic: [rtcweb] Prioritization Thread-Index: AQHPZLhzZTpDzprP00KkioeC3psNOg== Date: Wed, 30 Apr 2014 21:09:19 +0000 Message-ID: References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> <535A68E1.9090901@viagenie.ca> <535A78FF.20700@alvestrand.no> <535A7C73.6050701@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <74ED26A38D00354280E5CDF819BAAE50@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3J3qVzZFqPJ_NmhFDRKYrwbPXJM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:09:24 -0000 On Apr 25, 2014, at 11:03 AM, Matthew Kaufman (SKYPE) wrote: > If a "lower priority" packet is dispatched before a "higher priority" pac= ket in order to "prevent starvation", then what does "higher priority" mean= ? I think the labels reflect what "might" happen on average and not for any p= articular packet. I say "might" because in some deployments it possible the= values will have no effect at all and it is possible to construct bizarre = environments where you could get the opposite of the desired behavior in so= me cases. None of that bothers me as the label still seem like the closest = to helping developers request the desired treatment. With all things qos li= ke, the best we can for is desired outcome and not what will necessarily ha= ppen on internet.=20 priority might be better called "desired priority" and the values of "very = low, low, med, high" might better be called "broccoli, apple, orange, cherr= y" - they are really just some labels that describe how the packets *might*= be queued by systems they pass through. I think the fruit labels would be= more confusing to web programmers.=20 From nobody Wed Apr 30 14:22:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB5B1A0997 for ; Wed, 30 Apr 2014 14:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 NEJGQI1ajOib for ; Wed, 30 Apr 2014 14:21:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 30EA81A08B5 for ; Wed, 30 Apr 2014 14:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=750; q=dns/txt; s=iport; t=1398892898; x=1400102498; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SUJBm4u8Da7sbd0Gu4k6+FgaMbnd1+2FzzZwqkYzRLo=; b=bW6G0Ex7GfdG10FT+8CukO74z/9lhsS+Hp9NMfgbSI+ILvIozi5saK9t SKehi6m6Mi+evR2NylPdjcq6dpfZRTeq7CxjNwA/OBhA3mnO65HXFS1KE CkPp+ar+65UnNtRx/szk3B62Xa1fnkqFI0fSTupukk0eVzp8RObB0ynEG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAB5oYVOtJA2M/2dsb2JhbABZgwaBJsRMgSEWdIIlAQEBAwF5BQsCAQhGMiUCBA4FiDkIygcXjh4zB4MkgRUBA5knkmuBcoE/gis X-IronPort-AV: E=Sophos;i="4.97,960,1389744000"; d="scan'208";a="321519635" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 30 Apr 2014 21:21:36 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s3ULLafP017199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 21:21:36 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 16:21:36 -0500 From: "Cullen Jennings (fluffy)" To: Roman Shpount Thread-Topic: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? Thread-Index: AQHPZLoqT0r3kE244UWS8vLGoCPh4w== Date: Wed, 30 Apr 2014 21:21:35 +0000 Message-ID: <4A607E3C-B0A3-450E-863C-8E71C8EFC191@cisco.com> References: <5357B281.1030900@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: <414962C124AE794B93DB3106F74A9497@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XqBW8XsK3ahBEaEH3nds0et_Hlk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:21:45 -0000 On Apr 23, 2014, at 9:02 AM, Roman Shpount wrote: > I would say that some video end points have congestion back off. Almost = all audio end points have none. Based on this, most UDP endpoints do not de= al well with congestion. Well =85 I sort of agree with you and Wenger and sort of don=92t. They have= an upper layer congestion control. Basically when the congestion gets bad,= the humans on both ends hang up the call and go call each other on their c= ell phones.=20 But the bottom line of all this is we all wish we had better congestion con= trol for interactive voice and video and RMCAT is working on that and it is= hard and going to take awhile to figure out and probably longer to deploy.= =20 From nobody Wed Apr 30 14:23:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2073D1A09A8 for ; Wed, 30 Apr 2014 14:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 P00o7PY8tTm4 for ; Wed, 30 Apr 2014 14:23:32 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 81FE41A09AB for ; Wed, 30 Apr 2014 14:23:28 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id x48so2227219wes.7 for ; Wed, 30 Apr 2014 14:23:26 -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:content-type; bh=AaiequWR38zeV6ZPlyesBEiaQuiSehKJxtZZEA2L+Ng=; b=1FEdtzTgKbMG8NfqSZ3H0NR3XVojysn28DZW67/4stilEyUBRhPtYehJb7B+Y6+CTK r+jBP7hW0edO0yo1cvusz+GzHd85BempWZp4oqI1ZnCtWCpDFBtFSS0gDGJW7uXty/X6 zR3jPR83Rv+CGXiOZlNd4PXwzr14Hbe9bRqJLUKuc+7Je2vzEZZKkZWQNSkR4mvZ2BIT GbfYmRAqVEkKjYZxAoMVTg/ZcvMJW81Dq9bitUoQR0net0pVtJylHPZkOMEHCXzq1W01 c7J91rwyhLC599usW8/iIrKU6Mxmpm+PBaJaWHdW/+yr6gN+eUhPjsICWuQc68Y55AxJ F6Kw== MIME-Version: 1.0 X-Received: by 10.180.82.133 with SMTP id i5mr5508324wiy.50.1398893006484; Wed, 30 Apr 2014 14:23:26 -0700 (PDT) Received: by 10.227.77.10 with HTTP; Wed, 30 Apr 2014 14:23:26 -0700 (PDT) In-Reply-To: References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> <535A68E1.9090901@viagenie.ca> <535A78FF.20700@alvestrand.no> <535A7C73.6050701@viagenie.ca> Date: Wed, 30 Apr 2014 14:23:26 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HMa96-BxXHdZIf44jx0j9VzcaX8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:23:36 -0000 On 30 April 2014 14:09, Cullen Jennings (fluffy) wrote: > On Apr 25, 2014, at 11:03 AM, Matthew Kaufman (SKYPE) wrote: > >> If a "lower priority" packet is dispatched before a "higher priority" packet in order to "prevent starvation", then what does "higher priority" mean? > > I think the labels reflect what "might" happen on average and not for any particular packet. I think that Matthew was referring to the part where the browser is involved. That is, the bit where, when presented with the option to send just one packet from buckets A through D, how does it choose from those buckets. The implication was that if A is more important than B, then if A wants to send, it gets to send. Period. The "prevents starvation" view of the world says that work is shared between A-D, with increasingly large proportions of the available capacity given to higher priority streams. The problem with both these models is that they are crap in various ways. In one, you get cases where lower priority stuff never happens, even if that isn't what you wanted; in another, lower priority stuff can get resources, and that wasn't what you wanted. The DSCP markings and how they might interact with this are just an additional layer of uncertainty, primarily. From nobody Wed Apr 30 14:37:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FB01A0953 for ; Wed, 30 Apr 2014 14:37:21 -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, SPF_HELO_PASS=-0.001] autolearn=ham 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 J8QybBum3W4V for ; Wed, 30 Apr 2014 14:37:15 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 748E61A079F for ; Wed, 30 Apr 2014 14:37:14 -0700 (PDT) Received: from BLUPR03CA037.namprd03.prod.outlook.com (10.141.30.30) by BL2PR03MB163.namprd03.prod.outlook.com (10.255.230.147) with Microsoft SMTP Server (TLS) id 15.0.934.12; Wed, 30 Apr 2014 21:37:12 +0000 Received: from BY2FFO11FD041.protection.gbl (2a01:111:f400:7c0c::158) by BLUPR03CA037.outlook.office365.com (2a01:111:e400:879::30) with Microsoft SMTP Server (TLS) id 15.0.921.12 via Frontend Transport; Wed, 30 Apr 2014 21:37:12 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD041.mail.protection.outlook.com (10.1.14.226) with Microsoft SMTP Server (TLS) id 15.0.929.8 via Frontend Transport; Wed, 30 Apr 2014 21:37:11 +0000 Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.224]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0174.002; Wed, 30 Apr 2014 21:36:33 +0000 From: "Matthew Kaufman (SKYPE)" To: Martin Thomson , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Prioritization Thread-Index: AQHPYIVjkPq1Tfael0+4dMESGUjujZsiUXSAgAAJBICAABM2gIAABB6AgAAc5ICAAABOkIAIIN6AgAAD8QCAAAOVQA== Date: Wed, 30 Apr 2014 21:36:32 +0000 Message-ID: References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> <535A68E1.9090901@viagenie.ca> <535A78FF.20700@alvestrand.no> <535A7C73.6050701@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(189002)(199002)(377454003)(24454002)(51704005)(81542001)(20776003)(47776003)(76482001)(31966008)(74662001)(74502001)(79102001)(4396001)(50986999)(54356999)(76176999)(2009001)(55846006)(77982001)(99396002)(46102001)(33656001)(23676002)(6806004)(80976001)(50466002)(83322001)(19580405001)(19580395003)(44976005)(80022001)(85806002)(66066001)(86362001)(83072002)(92726001)(81342001)(92566001)(87936001)(2656002)(85852003)(84676001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB163; H:mail.microsoft.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0197AFBD92 Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=matthew.kaufman@skype.net; X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/x4brlSDrCxhgZRHHuqleSYZ4qdA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:37:21 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcnRpbiBUaG9tc29uIFtt YWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmls IDMwLCAyMDE0IDI6MjMgUE0NCj4gVG86IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KQ0KPiBDYzog TWF0dGhldyBLYXVmbWFuIChTS1lQRSk7IFNpbW9uIFBlcnJlYXVsdDsgcnRjd2ViQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBQcmlvcml0aXphdGlvbg0KPiANCj4gT24gMzAgQXBy aWwgMjAxNCAxNDowOSwgQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpIDxmbHVmZnlAY2lzY28uY29t PiB3cm90ZToNCj4gPiBPbiBBcHIgMjUsIDIwMTQsIGF0IDExOjAzIEFNLCBNYXR0aGV3IEthdWZt YW4gKFNLWVBFKQ0KPiA8bWF0dGhldy5rYXVmbWFuQHNreXBlLm5ldD4gd3JvdGU6DQo+ID4NCj4g Pj4gSWYgYSAibG93ZXIgcHJpb3JpdHkiIHBhY2tldCBpcyBkaXNwYXRjaGVkIGJlZm9yZSBhICJo aWdoZXIgcHJpb3JpdHkiIHBhY2tldA0KPiBpbiBvcmRlciB0byAicHJldmVudCBzdGFydmF0aW9u IiwgdGhlbiB3aGF0IGRvZXMgImhpZ2hlciBwcmlvcml0eSIgbWVhbj8NCj4gPg0KPiA+IEkgdGhp bmsgdGhlIGxhYmVscyByZWZsZWN0IHdoYXQgIm1pZ2h0IiBoYXBwZW4gb24gYXZlcmFnZSBhbmQg bm90IGZvciBhbnkNCj4gcGFydGljdWxhciBwYWNrZXQuDQo+IA0KPiBJIHRoaW5rIHRoYXQgTWF0 dGhldyB3YXMgcmVmZXJyaW5nIHRvIHRoZSBwYXJ0IHdoZXJlIHRoZSBicm93c2VyIGlzIGludm9s dmVkLg0KPiBUaGF0IGlzLCB0aGUgYml0IHdoZXJlLCB3aGVuIHByZXNlbnRlZCB3aXRoIHRoZSBv cHRpb24gdG8gc2VuZCBqdXN0IG9uZQ0KPiBwYWNrZXQgZnJvbSBidWNrZXRzIEEgdGhyb3VnaCBE LCBob3cgZG9lcyBpdCBjaG9vc2UgZnJvbSB0aG9zZSBidWNrZXRzLg0KPiANCj4gVGhlIGltcGxp Y2F0aW9uIHdhcyB0aGF0IGlmIEEgaXMgbW9yZSBpbXBvcnRhbnQgdGhhbiBCLCB0aGVuIGlmIEEg d2FudHMgdG8NCj4gc2VuZCwgaXQgZ2V0cyB0byBzZW5kLiAgUGVyaW9kLiAgVGhlICJwcmV2ZW50 cyBzdGFydmF0aW9uIg0KPiB2aWV3IG9mIHRoZSB3b3JsZCBzYXlzIHRoYXQgd29yayBpcyBzaGFy ZWQgYmV0d2VlbiBBLUQsIHdpdGggaW5jcmVhc2luZ2x5DQo+IGxhcmdlIHByb3BvcnRpb25zIG9m IHRoZSBhdmFpbGFibGUgY2FwYWNpdHkgZ2l2ZW4gdG8gaGlnaGVyIHByaW9yaXR5IHN0cmVhbXMu DQo+IFRoZSBwcm9ibGVtIHdpdGggYm90aCB0aGVzZSBtb2RlbHMgaXMgdGhhdCB0aGV5IGFyZSBj cmFwIGluIHZhcmlvdXMgd2F5cy4gIEluDQo+IG9uZSwgeW91IGdldCBjYXNlcyB3aGVyZSBsb3dl ciBwcmlvcml0eSBzdHVmZiBuZXZlciBoYXBwZW5zLCBldmVuIGlmIHRoYXQNCj4gaXNuJ3Qgd2hh dCB5b3Ugd2FudGVkOyBpbiBhbm90aGVyLCBsb3dlciBwcmlvcml0eSBzdHVmZiBjYW4gZ2V0IHJl c291cmNlcywgYW5kDQo+IHRoYXQgd2Fzbid0IHdoYXQgeW91IHdhbnRlZC4NCj4gDQo+IFRoZSBE U0NQIG1hcmtpbmdzIGFuZCBob3cgdGhleSBtaWdodCBpbnRlcmFjdCB3aXRoIHRoaXMgYXJlIGp1 c3QgYW4NCj4gYWRkaXRpb25hbCBsYXllciBvZiB1bmNlcnRhaW50eSwgcHJpbWFyaWx5Lg0KDQpB Y2N1cmF0ZSBzdW1tYXJ5IG9mIG15IHBvc2l0aW9uLg0KDQpNYXR0aGV3IEthdWZtYW4NCg== From nobody Wed Apr 30 14:46:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CFD1A09A5 for ; Wed, 30 Apr 2014 14:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 R5dV4ujbnR2X for ; Wed, 30 Apr 2014 14:46:03 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 55ED51A0852 for ; Wed, 30 Apr 2014 14:46:03 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so2955598wiv.6 for ; Wed, 30 Apr 2014 14:46:01 -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:content-type:content-transfer-encoding; bh=jIcAbEYtPL8sYkKXKwrCJK4OErQjmnLPC/m6bTwWcTM=; b=UtOIkCKDMJi3iDu/zEK828YT0AIKMW1wJvpp5LCSdRFElOtOOUu+/sMuc6YQLzJyDw hmIm/oIeQBheOWC6goWj9Dm8+Z6X15bmBCQekREBYJ8HULuIr7cqkrx60YWZ9aK2LobJ 7pb+PqjafWqms8b14Uom3eA7lAqo23ySGK9Tlmmhn6YJJL0ESIv/F997sPTL0wSW1BnS /MJycYoXAcs1LpiS1d6QKZojKuToDRn4Myr6YbFpy4RA2tr3/Cw/FOKgjfSsM1mn37g5 tZDyEU82IwLCzkfRvJlD4/QMCIgmICLEssh/rs8nmfzE/TCAkEY3Rl0ojfgmgrurwq0u 1bDw== MIME-Version: 1.0 X-Received: by 10.180.14.233 with SMTP id s9mr5481874wic.53.1398894361265; Wed, 30 Apr 2014 14:46:01 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Wed, 30 Apr 2014 14:46:01 -0700 (PDT) In-Reply-To: References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> <535A68E1.9090901@viagenie.ca> <535A78FF.20700@alvestrand.no> <535A7C73.6050701@viagenie.ca> Date: Wed, 30 Apr 2014 14:46:01 -0700 Message-ID: From: Dave Taht To: "Matthew Kaufman (SKYPE)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5OPF2dNVVjp3TO8qfgigY52964E Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:46:07 -0000 On Wed, Apr 30, 2014 at 2:36 PM, Matthew Kaufman (SKYPE) wrote: > >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Wednesday, April 30, 2014 2:23 PM >> To: Cullen Jennings (fluffy) >> Cc: Matthew Kaufman (SKYPE); Simon Perreault; rtcweb@ietf.org >> Subject: Re: [rtcweb] Prioritization >> >> On 30 April 2014 14:09, Cullen Jennings (fluffy) wrot= e: >> > On Apr 25, 2014, at 11:03 AM, Matthew Kaufman (SKYPE) >> wrote: >> > >> >> If a "lower priority" packet is dispatched before a "higher priority"= packet >> in order to "prevent starvation", then what does "higher priority" mean? >> > >> > I think the labels reflect what "might" happen on average and not for = any >> particular packet. >> >> I think that Matthew was referring to the part where the browser is invo= lved. >> That is, the bit where, when presented with the option to send just one >> packet from buckets A through D, how does it choose from those buckets. >> >> The implication was that if A is more important than B, then if A wants = to >> send, it gets to send. Period. The "prevents starvation" >> view of the world says that work is shared between A-D, with increasingl= y >> large proportions of the available capacity given to higher priority str= eams. >> The problem with both these models is that they are crap in various ways= . In >> one, you get cases where lower priority stuff never happens, even if tha= t >> isn't what you wanted; in another, lower priority stuff can get resource= s, and >> that wasn't what you wanted. It is extremely rare that you want a starvation queue. Two examples are holding a port open through a natted device, and your typical keepalives. If you want to support near-starvation queues, you could specify an outer bound for the maximum time a lower priority queue can be starved. otherwise a system of weights seems more appropo. >> The DSCP markings and how they might interact with this are just an >> additional layer of uncertainty, primarily. > > Accurate summary of my position. > > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Wed Apr 30 14:56:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4B41A09A5 for ; Wed, 30 Apr 2014 14:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 Y5YvXFctAf93 for ; Wed, 30 Apr 2014 14:56:42 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 90E5B1A09A3 for ; Wed, 30 Apr 2014 14:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1251; q=dns/txt; s=iport; t=1398895001; x=1400104601; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zoxVLl1rMSBd+SLdDqR2hh66p+afOzfJKNMuzdJ8RNY=; b=VtV+LR2W/8OmBPn/q2l10nEKigvYBu3EhWn8rAvTddpvavmo938jeSh7 9P3Xi+sHaga3JzhPJST9fNtdrK+cK4qeI6A0WGglwWuKn+ntc7doZQh3f s2PgkKIz2IQxLRprrdRODuV1/r90NxjvRkbPBDtId2SkSY3mSAvdOwR+V 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAAlxYVOtJV2a/2dsb2JhbABZgwaBJsRLgSEWdIIlAQEBAwFoEQULAgEIRjIlAgQOBYg5CMoDF44eMweDJIEVAQOJS49ckmuBcoE/gis X-IronPort-AV: E=Sophos;i="4.97,960,1389744000"; d="scan'208";a="40114943" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 30 Apr 2014 21:56:40 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3ULueqU028112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 21:56:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 16:56:40 -0500 From: "Cullen Jennings (fluffy)" To: Magnus Westerlund Thread-Topic: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage Thread-Index: AQHPZL8Q59672nYevkqhkexdZdxtQw== Date: Wed, 30 Apr 2014 21:56:40 +0000 Message-ID: References: <533E7A50.5040909@ericsson.com> <53425DDE.2030005@alvestrand.no> <534288C2.6010906@ericsson.com> <5342ABBB.9050300@alvestrand.no> <534D4CC4.9040107@ericsson.com> In-Reply-To: <534D4CC4.9040107@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8D4F8014527EA641B40C141A9116B5BB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/r7GUt8H4FMqR-5lrNjVAzSyr-pI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Draft proposal for updating Multiparty topologies in draft-ietf-rtcweb-rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:56:43 -0000 On Apr 15, 2014, at 9:14 AM, Magnus Westerlund wrote: > This limitation means that > some of the RTP middlebox-based topologies are not suitable for use > in the WebRTC environment. Specifically: >=20 > o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, > since they make the use of RTCP for congestion control and quality > of service reports problematic (see Section 3.8 of > [I-D.ietf-avtcore-rtp-topologies-update]). I think this is deserving of some WG discussion as people may not be up to = speed of what this is allowing or not allowing. My understanding was severa= l companies at the last WebRTC Expo conference were demonstrating system th= at used this type of MCU.=20 If SRTP were more flexible and there was a way to a mixer work without givi= ng it the keys to the decrypt the media, I think people would be keener on = mixers but right it seems like the pro / cons invovle a trade off between s= ignificant security functionally loss and possible loss of some RTCP data w= hich many systems totally ignore. Anyway, not taking any opinion other tha= n this seems like a significant enough change to have some discussion on it= .=20 From nobody Wed Apr 30 16:01:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3CF1A0955 for ; Wed, 30 Apr 2014 16:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 l0jfV6v4hZ1i for ; Wed, 30 Apr 2014 16:01:29 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCBC1A04E8 for ; Wed, 30 Apr 2014 16:01:29 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id z60so1952373qgd.15 for ; Wed, 30 Apr 2014 16:01:27 -0700 (PDT) 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:content-type; bh=lj3p35FjNf6WxI0ZG8WG8QHyGPXStLVTM3px8fs68Ns=; b=BpPwrysY2lt77nEaZzseRihNJRXQoLeFaygmJIZpKjBwKBWxvYV/jGmrErajYGOdhE I4LvxxZttQ97hNuayRD0L3kezODHn0vc40kjHjxGpCZCxEdsKfDNCxYKIEJFN+JD7KUB /gSNWNiN9EADW+nDPngtfZAp5OMxZoY2h92sUZJetfuLavPlXjFpOn7bUvSIUdlsAlfP UaRO/jD/UxSf6mH7tjvYAEqIfk1/dfs/cc8axusx1knm9jrcyf7CI+dHVoKC9JM3NfJ/ iJXHzozJMDKeXY1qjwOdz+D29sIxuvXmfiNuBTGeq+Hq+/5hNHdJpQZZpR0t6/OpGESt a1Fw== X-Gm-Message-State: ALoCoQlRgamxS1AnsQ+OR8sqVI7SiWFgaSdXNmyIHiXT4WVcA5Am4l7/0eB6yx8fDAM8TD/k76oB X-Received: by 10.229.179.65 with SMTP id bp1mr9475330qcb.11.1398898887242; Wed, 30 Apr 2014 16:01:27 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by mx.google.com with ESMTPSA id g7sm48651399qaf.14.2014.04.30.16.01.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 16:01:25 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id j107so2661694qga.0 for ; Wed, 30 Apr 2014 16:01:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.229.220.197 with SMTP id hz5mr6104584qcb.9.1398898884703; Wed, 30 Apr 2014 16:01:24 -0700 (PDT) Received: by 10.96.210.68 with HTTP; Wed, 30 Apr 2014 16:01:24 -0700 (PDT) In-Reply-To: <4A607E3C-B0A3-450E-863C-8E71C8EFC191@cisco.com> References: <5357B281.1030900@alvestrand.no> <4A607E3C-B0A3-450E-863C-8E71C8EFC191@cisco.com> Date: Wed, 30 Apr 2014 19:01:24 -0400 Message-ID: From: Roman Shpount To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=001a11346f6a197c9004f84a87b0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wqg_pRsq_SXv8ZP5hQr3J5vXsg8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which is more realistic? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 23:01:33 -0000 --001a11346f6a197c9004f84a87b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 30, 2014 at 5:21 PM, Cullen Jennings (fluffy) wrote: > > On Apr 23, 2014, at 9:02 AM, Roman Shpount wrote: > > > I would say that some video end points have congestion back off. Almos= t > all audio end points have none. Based on this, most UDP endpoints do not > deal well with congestion. > > Well =E2=80=A6 I sort of agree with you and Wenger and sort of don=E2=80= =99t. They have an > upper layer congestion control. Basically when the congestion gets bad, t= he > humans on both ends hang up the call and go call each other on their cell > phones. I know we are deep in the discussion but originally I was addressing the following point: On 2014-04-23 14:31, Harald Alvestrand wrote: > All UDP endpoints that use the open Internet have some form of backoff on congestion - using delay, packet drop or > (most likely) both to detect congestion >From my experience this is not true for almost all voice end points and it is not true for majority of video end points. So, Harald's assumption does not hold. I think based on this assumption Harald was trying to decide if QOS support needs to be exposed in WebRTC. My second point was that if congestion is introduced by something other then the real time media client (such as loading a large document over HTTP from public internet or using a separate screen sharing program which uses TCP to upload the screen on a slide change), there is little that can be done by the real time media end point to deal with this congestion except implement a good packet loss recovery policy. Better handling of such congestion will require either changes to router queuing policies (using PIE or Codel queuing policies at the point of congestion can help a lot) or better yet implementing QOS. Such router policy changes are outside of this groups charter, but exposing QOS support to WebRTC is definitely something that should be discussed. _____________ Roman Shpount --001a11346f6a197c9004f84a87b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 30, 2014 at 5:21 PM, Cullen Jennings (fluffy) <= ;fluffy@cisco.com= > wrote:

On Apr 23, 2014, at 9:02 AM, Roman Shpount <roman@telurix.com> wrote:

> I would say that some video end points have congestion back off. =C2= =A0Almost all audio end points have none. Based on this, most UDP endpoints= do not deal well with congestion.

Well =E2=80=A6 I sort of agree with you and Wenger and sort of don=E2=80=99= t. They have an upper layer congestion control. Basically when the congesti= on gets bad, the humans on both ends hang up the call and go call each othe= r on their cell phones.

I know we are deep in the discussion but originally I was ad= dressing the following point:

On 20= 14-04-23 14:31, Harald Alvestrand wrote:
> =C2=A0All UDP endpoints th= at use the open Internet have some form of backoff on congestion - using de= lay, packet drop or
> (most likely) both to detect congestion

From my ex= perience this is not true for almost all voice end points and it is not tru= e for majority of video end points. So, Harald's assumption does not ho= ld.

I think based on this assumption Harald was trying to d= ecide if QOS support needs to be exposed in WebRTC. My second point was tha= t if congestion is introduced by something other then the real time media c= lient (such as loading a large document over HTTP from public internet or u= sing a separate screen sharing program which uses TCP to upload the screen = on a slide change), there is little that can be done by the real time media= end point to deal with this congestion except implement a good packet loss= recovery policy. Better handling of such congestion will require either ch= anges to router queuing policies (using PIE or Codel queuing policies at th= e point of congestion can help a lot) or better yet implementing QOS. Such = router policy changes are outside of this groups charter, but exposing QOS = support to WebRTC is definitely something that should be discussed.
_____________
Roman Shpount

--001a11346f6a197c9004f84a87b0-- From nobody Wed Apr 30 21:01:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1EE1A09A2 for ; Wed, 30 Apr 2014 21:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 YxeliA9QgDux for ; Wed, 30 Apr 2014 21:01:39 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 818131A09A0 for ; Wed, 30 Apr 2014 21:01:39 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 227c1635.2b5f90c0d940.6835642.00-2431.19130198.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 01 May 2014 04:01:38 +0000 (UTC) X-MXL-Hash: 5361c7222ae76daa-162b3da7c521c5fe0cd21d21ef5f0abc8c0049c6 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 5e6c1635.0.6834729.00-2320.19127564.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 01 May 2014 04:00:38 +0000 (UTC) X-MXL-Hash: 5361c6e62c4f2f44-ad675e0c1f951dee6d3af22c98d81f93dbe4fa2f Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id s4140bl6031261; Wed, 30 Apr 2014 21:00:37 -0700 Received: from flpi488.ffdc.sbc.com (flpi488.ffdc.sbc.com [130.4.162.182]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id s4140XL0031224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2014 21:00:33 -0700 Received: from CAFRFD1MSGHUB9F.ITServices.sbc.com (CAFRFD1MSGHUB9F.itservices.sbc.com [135.161.21.166]) by flpi488.ffdc.sbc.com (RSA Interceptor); Thu, 1 May 2014 04:00:25 GMT Received: from CAFRFD1MSGUSRIA.ITServices.sbc.com ([169.254.1.196]) by CAFRFD1MSGHUB9F.ITServices.sbc.com ([135.161.21.166]) with mapi id 14.03.0174.001; Wed, 30 Apr 2014 21:00:25 -0700 From: "DRUTA, DAN" To: "Cullen Jennings (fluffy)" , Matthew Kaufman Thread-Topic: [rtcweb] Prioritization Thread-Index: AQHPYIVkbrnol5gVYEePM17Zq0EsRJsixs2AgAAJA4CAABM3gIAABB6AgAAc5ICAAAC8gIAIIG+A///1ZcA= Date: Thu, 1 May 2014 04:00:24 +0000 Message-ID: <4AA3A95D6033ED488F8AE4E45F47448743A2DF4A@CAFRFD1MSGUSRIA.ITServices.sbc.com> References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> <535A68E1.9090901@viagenie.ca> <535A78FF.20700@alvestrand.no> <535A7C73.6050701@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=QZ3RSLnv c=1 sm=1 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=sQVNTnci9XEA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=vR12nkMaAAAA:8 a=Io4Au8LPJgGXhrALu88A:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=lZB815dzVvQA:10 a=qi9FgK3vWkoA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/r2JUcUPco4fVv5aUlLOlVAk_NdQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Prioritization X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 04:01:46 -0000 We discussed this a while back and to a certain extent is a split problem b= etween the API and the protocol. If we look from developer's point of view, they are the ones that know with= in their app what's more important. For a game data channel might be more important than video where for a cust= omer service app audio might be more important than video (could be the opp= osite if it's a furniture store and showing how to assemble a piece of furn= iture is far more important). The point is that it starts with the API and hopefully we will get somethin= g that will give the browser a hint on the track priority. This indication should be used for two purposes: 1. Plug in a common congestion control between media and data within the b= rowser implementation, try to honor this application demand and potentially= balance it with other web applications competing for resources and even ot= her applications on the same device. 2. Allow the browser to mark the traffic accordingly so with additional ne= twork support it can be prioritized where possible e2e. It might require an= out of band negotiation between the application and the network in order t= o request and honor the fulfilment of this kind of prioritization where pos= sible. The relative priority within an app is critical and I'm sure no app develop= er would mark all of their tracks as high knowing that it would not do any = good. Ideally we would have an algorithm implemented consistently across the boar= d within browsers so developers would know what to expect but the algorithm= must take input from the app as a factor into its decision. Dan -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings = (fluffy) Sent: Wednesday, April 30, 2014 2:09 PM To: Matthew Kaufman Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Prioritization On Apr 25, 2014, at 11:03 AM, Matthew Kaufman (SKYPE) wrote: > If a "lower priority" packet is dispatched before a "higher priority" pac= ket in order to "prevent starvation", then what does "higher priority" mean= ? I think the labels reflect what "might" happen on average and not for any p= articular packet. I say "might" because in some deployments it possible the= values will have no effect at all and it is possible to construct bizarre = environments where you could get the opposite of the desired behavior in so= me cases. None of that bothers me as the label still seem like the closest = to helping developers request the desired treatment. With all things qos li= ke, the best we can for is desired outcome and not what will necessarily ha= ppen on internet.=20 priority might be better called "desired priority" and the values of "very = low, low, med, high" might better be called "broccoli, apple, orange, cherr= y" - they are really just some labels that describe how the packets *might*= be queued by systems they pass through. I think the fruit labels would be= more confusing to web programmers.=20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb