From nobody Mon Jun 6 01:06:05 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E9B12B055; Mon, 6 Jun 2016 01:06:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160606080601.20802.14972.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 01:06:01 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 08:06:01 -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 of the IETF. Title : Transports for WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-13.txt Pages : 17 Date : 2016-06-06 Abstract: This document describes the data transport protocols used by WebRTC, 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: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-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 Mon Jun 6 01:38:03 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147E312B069 for ; Mon, 6 Jun 2016 01:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ06sER9v8bn for ; Mon, 6 Jun 2016 01:38:01 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3F012B009 for ; Mon, 6 Jun 2016 01:38:00 -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 1b9q2p-0004AY-5j for rtcweb@ietf.org; Mon, 06 Jun 2016 10:37:59 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b9q2o-0006eg-Go; Mon, 06 Jun 2016 10:37:59 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <20160606080601.20802.14972.idtracker@ietfa.amsl.com> Date: Mon, 6 Jun 2016 10:37:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160606080601.20802.14972.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 6 sum rcpts/h 12 sum msgs/h 6 total rcpts 42635 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.646, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FFCE56125A737AF243B9FC7644F5F277A35132BD X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 1 bait 0 mail/h: 6 total 10234 max/h 17 blacklist 0 greylist 1 ratelimit 0 Archived-At: Cc: Safiqul Islam Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 08:38:03 -0000 .... and my suggestions below are still not addressed. Cheers, Michael > Begin forwarded message: >=20 > From: Michael Welzl > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-12.txt > Date: 23 Mar 2016 09:40:44 CET > To: Harald Alvestrand > Cc: rtcweb@ietf.org > Resent-From: >=20 >=20 >> On 22 Mar 2016, at 16:14, Harald Alvestrand = wrote: >>=20 >> Thank you - yes, it was lost. >>=20 >> I've filed this suggestion as >> https://github.com/rtcweb-wg/rtcweb-transport/issues/16 >=20 > Thanks! >=20 >=20 >> My queries are of course: >>=20 >> - Is the reference to [coupled] normative or informative? >=20 > Seeing that you made I-D.ietf-tsvwg-rtcweb-qos a normative reference, = I'd say this one should be normative too. For streams that are known to = share a bottleneck (e.g. between the same hosts and multiplexed), this = *always* works, not only when routers on your path happen to support it. >=20 >=20 >> - What is the expected timeline for emission of [coupled]? >=20 > I think we're quite close to the finish line. (I'll follow up with a = private email) >=20 >=20 >> I see that RFC 7657 got published with [coupled] as an informative >> reference. >> The "e.g." in your first suggestion might be loose enough to warrant = an >> informative reference. >=20 > Well, I find it strange for I-D.ietf-tsvwg-rtcweb-qos to be normative = and [coupled] to be informative. >=20 > Cheers, > Michael >=20 >=20 >=20 >>=20 >> Den 22. mars 2016 15:45, skrev Michael Welzl: >>> Hi, >>>=20 >>> On 26 February, I sent an email to rtcweb in which I made some = suggestions to this document. I see that these have not been = incorporated, and my email has also never been answered (except that = I-D.ietf-dart-dscp-rtp was replaced by RFC 7657, but that may not have = been due to my email). I can understand that: probably my prior email = just drowned in the WebRTC Audio Codec related thread. However I do = think that these comments would be good to address, so I'm copying in = the email again below. >>>=20 >>> Cheers, >>> Michael >>>=20 >>> ---- >>>=20 >>> Hi, >>>=20 >>> Overall, I like this document a lot - it makes for a very good read! >>>=20 >>> - but I think it would make sense for section 4.1 to explicitly = point to draft-ietf-rmcat-coupled-cc (the next version of which is going = to explain how weights much be set to adhere to the priority levels that = are described in this section; it's easy, we just didn't have this text = in there yet). >>>=20 >>>=20 >>> To be concrete, I suggest the following two changes: >>>=20 >>> *** >>> When an WebRTC implementation has packets to send on multiple = streams >>> that are congestion-controlled under the same congestion controller, >>> the WebRTC implementation SHOULD cause data to be emitted in such a >>> way that each stream at each level of priority is being given >>> approximately twice the transmission capacity (measured in payload >>> bytes) of the level below. >>> *** >>>=20 >>> should be: >>>=20 >>> *** >>> When a WebRTC implementation has packets to send on multiple streams >>> that are congestion-controlled under the same congestion controller >>> or multiple coupled congestion controllers (e.g. using the mechanism = in >>> [draft-ietf-rmcat-coupled-cc]), >>> the WebRTC implementation SHOULD cause data to be emitted in such a >>> way that each stream at each level of priority is being given >>> approximately twice the transmission capacity (measured in payload >>> bytes) of the level below. >>> *** >>>=20 >>> (note a fixed nit in there: the second word is "a" instead of "an") >>>=20 >>>=20 >>> and, perhaps even more importantly, a small change in section 4.2: >>>=20 >>> *** >>> More advice on the use of DSCP code points with RTP is given in >>> [I-D.ietf-dart-dscp-rtp]. >>> *** >>>=20 >>> should be: >>>=20 >>> *** >>> More advice on the use of DSCP code points with RTP as well as = coupled >>> congestion control is given in [I-D.ietf-dart-dscp-rtp]. >>> *** >>>=20 >>> and in fact I-D.ietf-dart-dscp-rtp should now be RFC 7657. >>>=20 >>>=20 >>> Cheers, >>> Michael >>>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 7 01:40:04 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2994112D0B9 for ; Tue, 7 Jun 2016 01:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTFk4Wq9JIDq for ; Tue, 7 Jun 2016 01:40:00 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D32312D09C for ; Tue, 7 Jun 2016 01:39:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 103787C84FD; Tue, 7 Jun 2016 10:39: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 RFUIoSYJ_nDV; Tue, 7 Jun 2016 10:39:56 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:544:2421:6aac:9b1e] (unknown [IPv6:2001:470:de0a:1:544:2421:6aac:9b1e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 541787C84D6; Tue, 7 Jun 2016 10:39:56 +0200 (CEST) To: Michael Welzl , rtcweb@ietf.org References: <20160606080601.20802.14972.idtracker@ietfa.amsl.com> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <5756885A.1020108@alvestrand.no> Date: Tue, 7 Jun 2016 10:39:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Safiqul Islam Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jun 2016 08:40:03 -0000 Den 06. juni 2016 10:37, skrev Michael Welzl: > .... and my suggestions below are still not addressed. The issue is addressed, but not as you suggested - after taking advice from the chairs, I did not reference "coupled" directly, instead choosing to reference RFC 7657 and mentioning that it contained advice on congestion control. I also changed one occurence of "the same congestion controller" to "the same congstion control regime", so that this document was neutral about whether there was one or multiple congestion controllers. Details at https://github.com/rtcweb-wg/rtcweb-transport/issues/16 I have to spin a new version anyway, since the TSVWG and RTCWEB chairs requested a comment on interactive vs non-interactive video: https://github.com/rtcweb-wg/rtcweb-transport/issues/19 but unless I get more advice on this one, I'll leave it as-is. > > Cheers, > Michael > > >> Begin forwarded message: >> >> From: Michael Welzl >> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-12.txt >> Date: 23 Mar 2016 09:40:44 CET >> To: Harald Alvestrand >> Cc: rtcweb@ietf.org >> Resent-From: >> >> >>> On 22 Mar 2016, at 16:14, Harald Alvestrand wrote: >>> >>> Thank you - yes, it was lost. >>> >>> I've filed this suggestion as >>> https://github.com/rtcweb-wg/rtcweb-transport/issues/16 >> >> Thanks! >> >> >>> My queries are of course: >>> >>> - Is the reference to [coupled] normative or informative? >> >> Seeing that you made I-D.ietf-tsvwg-rtcweb-qos a normative reference, I'd say this one should be normative too. For streams that are known to share a bottleneck (e.g. between the same hosts and multiplexed), this *always* works, not only when routers on your path happen to support it. >> >> >>> - What is the expected timeline for emission of [coupled]? >> >> I think we're quite close to the finish line. (I'll follow up with a private email) >> >> >>> I see that RFC 7657 got published with [coupled] as an informative >>> reference. >>> The "e.g." in your first suggestion might be loose enough to warrant an >>> informative reference. >> >> Well, I find it strange for I-D.ietf-tsvwg-rtcweb-qos to be normative and [coupled] to be informative. >> >> Cheers, >> Michael >> >> >> >>> >>> Den 22. mars 2016 15:45, skrev Michael Welzl: >>>> Hi, >>>> >>>> On 26 February, I sent an email to rtcweb in which I made some suggestions to this document. I see that these have not been incorporated, and my email has also never been answered (except that I-D.ietf-dart-dscp-rtp was replaced by RFC 7657, but that may not have been due to my email). I can understand that: probably my prior email just drowned in the WebRTC Audio Codec related thread. However I do think that these comments would be good to address, so I'm copying in the email again below. >>>> >>>> Cheers, >>>> Michael >>>> >>>> ---- >>>> >>>> Hi, >>>> >>>> Overall, I like this document a lot - it makes for a very good read! >>>> >>>> - but I think it would make sense for section 4.1 to explicitly point to draft-ietf-rmcat-coupled-cc (the next version of which is going to explain how weights much be set to adhere to the priority levels that are described in this section; it's easy, we just didn't have this text in there yet). >>>> >>>> >>>> To be concrete, I suggest the following two changes: >>>> >>>> *** >>>> When an WebRTC implementation has packets to send on multiple streams >>>> that are congestion-controlled under the same congestion controller, >>>> the WebRTC implementation SHOULD cause data to be emitted in such a >>>> way that each stream at each level of priority is being given >>>> approximately twice the transmission capacity (measured in payload >>>> bytes) of the level below. >>>> *** >>>> >>>> should be: >>>> >>>> *** >>>> When a WebRTC implementation has packets to send on multiple streams >>>> that are congestion-controlled under the same congestion controller >>>> or multiple coupled congestion controllers (e.g. using the mechanism in >>>> [draft-ietf-rmcat-coupled-cc]), >>>> the WebRTC implementation SHOULD cause data to be emitted in such a >>>> way that each stream at each level of priority is being given >>>> approximately twice the transmission capacity (measured in payload >>>> bytes) of the level below. >>>> *** >>>> >>>> (note a fixed nit in there: the second word is "a" instead of "an") >>>> >>>> >>>> and, perhaps even more importantly, a small change in section 4.2: >>>> >>>> *** >>>> More advice on the use of DSCP code points with RTP is given in >>>> [I-D.ietf-dart-dscp-rtp]. >>>> *** >>>> >>>> should be: >>>> >>>> *** >>>> More advice on the use of DSCP code points with RTP as well as coupled >>>> congestion control is given in [I-D.ietf-dart-dscp-rtp]. >>>> *** >>>> >>>> and in fact I-D.ietf-dart-dscp-rtp should now be RFC 7657. >>>> >>>> >>>> Cheers, >>>> Michael >>>> >> >> _______________________________________________ >> 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 Jun 7 02:13:09 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6B712D1C8 for ; Tue, 7 Jun 2016 02:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDhLEChLCEOq for ; Tue, 7 Jun 2016 02:13:05 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9321012D531 for ; Tue, 7 Jun 2016 02:13:05 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bAD4J-0001LH-Mz; Tue, 07 Jun 2016 11:13:03 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bAD4I-00011M-Vw; Tue, 07 Jun 2016 11:13:03 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <5756885A.1020108@alvestrand.no> Date: Tue, 7 Jun 2016 11:13:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38D052B1-A0BE-4581-93EF-02C1C520E6AF@ifi.uio.no> References: <20160606080601.20802.14972.idtracker@ietfa.amsl.com> <5756885A.1020108@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 9 sum msgs/h 5 total rcpts 42717 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.646, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6AF85346CEA5A562AA9E32B0FC2036DAE62DBC85 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 1 bait 0 mail/h: 2 total 10271 max/h 17 blacklist 0 greylist 1 ratelimit 0 Archived-At: Cc: rtcweb@ietf.org, Safiqul Islam Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jun 2016 09:13:08 -0000 Sorry! Sure enough, I only searched for "coupled" to see if this was = addressed :) My bad. I agree with how you did this, it's fine. Thanks! Cheers, Michael > On 07 Jun 2016, at 10:39, Harald Alvestrand = wrote: >=20 > Den 06. juni 2016 10:37, skrev Michael Welzl: >> .... and my suggestions below are still not addressed. >=20 > The issue is addressed, but not as you suggested - after taking advice > from the chairs, I did not reference "coupled" directly, instead > choosing to reference RFC 7657 and mentioning that it contained advice > on congestion control. >=20 > I also changed one occurence of "the same congestion controller" to = "the > same congstion control regime", so that this document was neutral = about > whether there was one or multiple congestion controllers. >=20 > Details at https://github.com/rtcweb-wg/rtcweb-transport/issues/16 >=20 > I have to spin a new version anyway, since the TSVWG and RTCWEB chairs > requested a comment on interactive vs non-interactive video: >=20 > https://github.com/rtcweb-wg/rtcweb-transport/issues/19 >=20 > but unless I get more advice on this one, I'll leave it as-is. >=20 >=20 >>=20 >> Cheers, >> Michael >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: Michael Welzl >>> Subject: Re: [rtcweb] I-D Action: = draft-ietf-rtcweb-transports-12.txt >>> Date: 23 Mar 2016 09:40:44 CET >>> To: Harald Alvestrand >>> Cc: rtcweb@ietf.org >>> Resent-From: >>>=20 >>>=20 >>>> On 22 Mar 2016, at 16:14, Harald Alvestrand = wrote: >>>>=20 >>>> Thank you - yes, it was lost. >>>>=20 >>>> I've filed this suggestion as >>>> https://github.com/rtcweb-wg/rtcweb-transport/issues/16 >>>=20 >>> Thanks! >>>=20 >>>=20 >>>> My queries are of course: >>>>=20 >>>> - Is the reference to [coupled] normative or informative? >>>=20 >>> Seeing that you made I-D.ietf-tsvwg-rtcweb-qos a normative = reference, I'd say this one should be normative too. For streams that = are known to share a bottleneck (e.g. between the same hosts and = multiplexed), this *always* works, not only when routers on your path = happen to support it. >>>=20 >>>=20 >>>> - What is the expected timeline for emission of [coupled]? >>>=20 >>> I think we're quite close to the finish line. (I'll follow up with a = private email) >>>=20 >>>=20 >>>> I see that RFC 7657 got published with [coupled] as an informative >>>> reference. >>>> The "e.g." in your first suggestion might be loose enough to = warrant an >>>> informative reference. >>>=20 >>> Well, I find it strange for I-D.ietf-tsvwg-rtcweb-qos to be = normative and [coupled] to be informative. >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Den 22. mars 2016 15:45, skrev Michael Welzl: >>>>> Hi, >>>>>=20 >>>>> On 26 February, I sent an email to rtcweb in which I made some = suggestions to this document. I see that these have not been = incorporated, and my email has also never been answered (except that = I-D.ietf-dart-dscp-rtp was replaced by RFC 7657, but that may not have = been due to my email). I can understand that: probably my prior email = just drowned in the WebRTC Audio Codec related thread. However I do = think that these comments would be good to address, so I'm copying in = the email again below. >>>>>=20 >>>>> Cheers, >>>>> Michael >>>>>=20 >>>>> ---- >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Overall, I like this document a lot - it makes for a very good = read! >>>>>=20 >>>>> - but I think it would make sense for section 4.1 to explicitly = point to draft-ietf-rmcat-coupled-cc (the next version of which is going = to explain how weights much be set to adhere to the priority levels that = are described in this section; it's easy, we just didn't have this text = in there yet). >>>>>=20 >>>>>=20 >>>>> To be concrete, I suggest the following two changes: >>>>>=20 >>>>> *** >>>>> When an WebRTC implementation has packets to send on multiple = streams >>>>> that are congestion-controlled under the same congestion = controller, >>>>> the WebRTC implementation SHOULD cause data to be emitted in such = a >>>>> way that each stream at each level of priority is being given >>>>> approximately twice the transmission capacity (measured in payload >>>>> bytes) of the level below. >>>>> *** >>>>>=20 >>>>> should be: >>>>>=20 >>>>> *** >>>>> When a WebRTC implementation has packets to send on multiple = streams >>>>> that are congestion-controlled under the same congestion = controller >>>>> or multiple coupled congestion controllers (e.g. using the = mechanism in >>>>> [draft-ietf-rmcat-coupled-cc]), >>>>> the WebRTC implementation SHOULD cause data to be emitted in such = a >>>>> way that each stream at each level of priority is being given >>>>> approximately twice the transmission capacity (measured in payload >>>>> bytes) of the level below. >>>>> *** >>>>>=20 >>>>> (note a fixed nit in there: the second word is "a" instead of = "an") >>>>>=20 >>>>>=20 >>>>> and, perhaps even more importantly, a small change in section 4.2: >>>>>=20 >>>>> *** >>>>> More advice on the use of DSCP code points with RTP is given in >>>>> [I-D.ietf-dart-dscp-rtp]. >>>>> *** >>>>>=20 >>>>> should be: >>>>>=20 >>>>> *** >>>>> More advice on the use of DSCP code points with RTP as well as = coupled >>>>> congestion control is given in [I-D.ietf-dart-dscp-rtp]. >>>>> *** >>>>>=20 >>>>> and in fact I-D.ietf-dart-dscp-rtp should now be RFC 7657. >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>> Michael >>>>>=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 >>=20 From nobody Tue Jun 7 06:09:58 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7397E12D61B; Tue, 7 Jun 2016 06:09:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607130956.13768.21750.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 06:09:56 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-14.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jun 2016 13:09:56 -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 of the IETF. Title : Transports for WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-14.txt Pages : 17 Date : 2016-06-07 Abstract: This document describes the data transport protocols used by WebRTC, 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: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-14 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 Jun 8 16:27:47 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE8D12D7D5; Wed, 8 Jun 2016 16:27:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160608232743.20003.43843.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2016 16:27:43 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-12.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 23: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 of the IETF. Title : WebRTC Security Architecture Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-12.txt Pages : 43 Date : 2016-06-08 Abstract: The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC"). This document defines the security architecture for WebRTC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-arch-12 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 Jun 8 23:53:41 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13BC12D125 for ; Wed, 8 Jun 2016 23:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAQRI_u5w8PC for ; Wed, 8 Jun 2016 23:53:39 -0700 (PDT) Received: from relay.mailchannels.net (nov-007-i611.relay.mailchannels.net [46.232.183.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875EB12B043 for ; Wed, 8 Jun 2016 23:53:36 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id AB9F9A0040 for ; Thu, 9 Jun 2016 06:53:31 +0000 (UTC) Received: from rcentral501.webserversystems.com (ip-10-213-0-221.us-west-2.compute.internal [10.213.0.221]) by relay.mailchannels.net (Postfix) with ESMTPA id CDB06A0183 for ; Thu, 9 Jun 2016 06:53:30 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from rcentral501.webserversystems.com (rcentral501.webserversystems.com [10.25.19.46]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.6.14); Thu, 09 Jun 2016 06:53:31 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1465455211013:3098467555 X-MC-Ingress-Time: 1465455211012 Received: from pool-71-162-135-19.phlapa.fios.verizon.net ([71.162.135.19]:56759 helo=[192.168.1.12]) by rcentral501.webserversystems.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bAtqT-00023K-P8 for rtcweb@ietf.org; Thu, 09 Jun 2016 02:53:37 -0400 References: <57457874.1010708@alvestrand.no> To: rtcweb@ietf.org From: Randell Jesup Message-ID: Date: Thu, 9 Jun 2016 02:52:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <57457874.1010708@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: Subject: Re: [rtcweb] Security architecture: Making ECDSA mandatory X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 06:53:41 -0000 On 5/25/2016 6:03 AM, Harald Alvestrand wrote: > In my search for status on ECDSA (we're in the process of switching > the Chrome default), I came across this in the current draft: > > All implementations MUST implement DTLS 1.0, with the cipher suite > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection > profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD > implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > cipher suite. Implementations SHOULD favor cipher suites which > support PFS over non-PFS cipher suites and GCM over CBC cipher > suites. [[OPEN ISSUE: Should we require ECDSA? Waiting for WG > Consensus.]] > > I also found Martin's PR. It's 11 months old, still open. > > Can we merge this now? PLEASE :-) Is there any objection at all? If not, let's do it ASAP. > > > On 06/13/2015 12:06 AM, Martin Thomson wrote: >> I've openedhttps://github.com/rtcweb-wg/security-arch/pull/33 -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much spam From nobody Wed Jun 8 23:59:58 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C550E12D12B for ; Wed, 8 Jun 2016 23:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM875hOGeJtP for ; Wed, 8 Jun 2016 23:59:55 -0700 (PDT) Received: from relay.mailchannels.net (baboon.maple.relay.mailchannels.net [23.83.214.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF1C12D125 for ; Wed, 8 Jun 2016 23:59:55 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 24A9412046F for ; Thu, 9 Jun 2016 06:59:49 +0000 (UTC) Received: from rcentral501.webserversystems.com (ip-10-213-0-221.us-west-2.compute.internal [10.213.0.221]) by relay.mailchannels.net (Postfix) with ESMTPA id 4C3021205CD for ; Thu, 9 Jun 2016 06:59:48 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from rcentral501.webserversystems.com (rcentral501.webserversystems.com [10.25.19.46]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.6.14); Thu, 09 Jun 2016 06:59:48 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1465455588504:2558196524 X-MC-Ingress-Time: 1465455588503 Received: from pool-71-162-135-19.phlapa.fios.verizon.net ([71.162.135.19]:56830 helo=[192.168.1.12]) by rcentral501.webserversystems.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bAtwZ-0006Bv-6p for rtcweb@ietf.org; Thu, 09 Jun 2016 02:59:55 -0400 References: <571DE213.8080306@goodadvice.pages.de> <9F33F40F6F2CD847824537F3C4E37DDF260FFABF@MCHP04MSX.global-ad.net> <4CD65A98-7FFE-4E24-A258-E022509E0A32@iii.ca> To: rtcweb@ietf.org From: Randell Jesup Message-ID: Date: Thu, 9 Jun 2016 02:58:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <4CD65A98-7FFE-4E24-A258-E022509E0A32@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed X-AuthUser: randell@jesup.org Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] which bandwidth modifiers need to be supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 06:59:57 -0000 On 5/23/2016 11:42 AM, Cullen Jennings wrote: > I=E2=80=99m not sure there is a requirement for a WebRTC endpoint to ge= nerate them but if there is, agree that we should say TIAS is preferred. Agreed TIAS should be preferred (though are we actually talking generate=20 or accept? - the messages below seem to slightly be in conflict.) =20 Firefox Nightly just landed support for receiving b=3DTIAS, but not b=3DA= S=20 (at least so far). >> On May 11, 2016, at 8:55 AM, Hutton, Andrew = wrote: >> >> I was also looking at this again my assumption is that TIAS is what a = WebRTC endpoint should generate TIAS as Philipp stated this is hinted at = in the W3C spec but probably also should be specified in JSEP and an exam= ple in https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-01#section-5.2.2= would also be useful. >> >> For parsing then both TIAS and AS needs to be supported this is specif= ied in https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-14#section-5.8. >> >> >>> -----Original Message----- >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Philipp >>> Hancke >>> Sent: 25 April 2016 10:24 >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] which bandwidth modifiers need to be supported? >>> >>> which bandwidth modifiers for b=3D lines does a client need to suppor= t? >>> >>> Chrome currently supports b=3DAS, however the implementation is close= r to >>> TIAS semantically. Firefox does not implement either currently. --=20 Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much sp= am From nobody Thu Jun 9 08:08:15 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824EB12D63C for ; Thu, 9 Jun 2016 08:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4kN1-Bbi_NE for ; Thu, 9 Jun 2016 08:08:11 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ECF812D5CD for ; Thu, 9 Jun 2016 08:08:11 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id c2so14281899pfa.2 for ; Thu, 09 Jun 2016 08:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mu9WEqHW+q3FidDCRrqmeGUypOz8PnK91wvvb81we7w=; b=lDo5yThLQX3KM6D1Icyp3s3ufn2jxHueSvVGYYgOAx8vl8ylaOYV9yM630zVf4vQk4 vccQ5YDXaHCdU4FCkmq8rAKDLWsS0QKsWT9U3cW767QOiqA74NKupN+JKV3c8To2gPV0 gLqTGuRu0gkrZY++pBAYtc/woifP4u/4/WDs7Nb6+wPvMHaN4TR/QiIYA5HLBN/xDYRf DePJRNmsed+OZPYVNqKZ3Y08V0XMCSDpv6gHw794R1byOTsviOO0zr0wyNeTSm+caf2U E6LcLMN+MmQnGrpjJlFAwq3BFu0r/mtHl21DxIcQ/wuTndNkMDhRoSg5TtP4WFasWSRM c+dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mu9WEqHW+q3FidDCRrqmeGUypOz8PnK91wvvb81we7w=; b=nGAfDYL/e1btddk2bsdgzKANWOv13RwOvkhGW5x0Qx0zLMN0Eef+VO2oNRNNxrIOCY L61kNwwxiad+vUg2VA8DOgj3D33S6Z5qTvLn83Z9RGaK+ArUgz0yUVtPSQ0F5nhM76+9 n87kHC4K9KTbsstOAS0B029v4iq7VpqiBDxDlP7tuH9zcd0/dnLYfJma5+7MZ0cQrgtR 7OFUG6Lh+xPjinzcFVwzkAzO/SKQoXcSZKVpmee0TS6ka9USvO751PXg/3pByoL7DI8q xfKtkiW2C/tkmZpgL0fMheGOQcpQbLONVYMSJFg4Sd9NcVrCxwu9AqkU118s5hlgmLBc uFRQ== X-Gm-Message-State: ALyK8tKosueA5W+A+V82sMMjchjE5Ynmf8KOznHJ9vjiHsPBjs5rPJTOoTMn0QRAnIfHHw== X-Received: by 10.98.99.132 with SMTP id x126mr5188779pfb.48.1465484891018; Thu, 09 Jun 2016 08:08:11 -0700 (PDT) Received: from [10.0.1.6] (c-24-19-245-25.hsd1.wa.comcast.net. [24.19.245.25]) by smtp.gmail.com with ESMTPSA id d8sm10786192pfg.72.2016.06.09.08.08.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2016 08:08:09 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-8EB685EF-1B75-480D-97CC-9900253EFBEA Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13F69) In-Reply-To: <57457874.1010708@alvestrand.no> Date: Thu, 9 Jun 2016 08:08:09 -0700 Content-Transfer-Encoding: 7bit Message-Id: <3A4427FF-A0F1-4B1A-B30C-7FE4319515A2@gmail.com> References: <57457874.1010708@alvestrand.no> To: Harald Alvestrand Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Security architecture: Making ECDSA mandatory X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 15:08:14 -0000 --Apple-Mail-8EB685EF-1B75-480D-97CC-9900253EFBEA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable It should be merged.=20 > On May 25, 2016, at 03:03, Harald Alvestrand wrote:= >=20 > In my search for status on ECDSA (we're in the process of switching the Ch= rome default), I came across this in the current draft: >=20 > All implementations MUST implement DTLS 1.0, with the cipher suite > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection > profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD > implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > cipher suite. Implementations SHOULD favor cipher suites which > support PFS over non-PFS cipher suites and GCM over CBC cipher > suites. [[OPEN ISSUE: Should we require ECDSA? Waiting for WG > Consensus.]] >=20 > I also found Martin's PR. It's 11 months old, still open. >=20 > Can we merge this now? >=20 >=20 >> On 06/13/2015 12:06 AM, Martin Thomson wrote: >> I've opened https://github.com/rtcweb-wg/security-arch/pull/33 >>=20 >> This changes the MTI cipher suites to ECDSA and does a little cleanup >> on the corresponding API requirements to more closely match what has >> just landed in the W3C specification. >>=20 >> We discussed ECDSA and the only concerns raised were with >> compatibility. I've done some testing with other implementations with >> no issues, and ECDSA seems to be well supported on all those >> hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for helping >> out with checks there and to NIST for creating certification pressure >> with FIPS-2). >>=20 >> I have an implementation that switches Firefox to ECDSA with P-256 by >> default. It's much, much faster. http://bench.cr.yp.to/ claims that >> it's 150 times faster on mobile devices for keygen. >>=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 --Apple-Mail-8EB685EF-1B75-480D-97CC-9900253EFBEA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
It should be merged. 

On May 25, 2016, at 03:03, Harald Alvestrand <harald@alvestrand.no> wrote:

In my search for status on ECDSA (we're in the process of switching the Chrome default), I came across this in the current draft:

   All implementations MUST implement DTLS 1.0, with the cipher suite
   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection
   profile SRTP_AES128_CM_HMAC_SHA1_80.  Implementations SHOULD
   implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   cipher suite.  Implementations SHOULD favor cipher suites which
   support PFS over non-PFS cipher suites and GCM over CBC cipher
   suites.  [[OPEN ISSUE: Should we require ECDSA?  Waiting for WG
   Consensus.]]
I also found Martin's PR. It's 11 months old, still open.

Can we merge this now?


On 06/13/2015 12:06 AM, Martin Thomson wrote:
I've opened https://github.com/rtcweb-wg/security-arch/pull/33

This changes the MTI cipher suites to ECDSA and does a little cleanup
on the corresponding API requirements to more closely match what has
just landed in the W3C specification.

We discussed ECDSA and the only concerns raised were with
compatibility.  I've done some testing with other implementations with
no issues, and ECDSA seems to be well supported on all those
hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for helping
out with checks there and to NIST for creating certification pressure
with FIPS-2).

I have an implementation that switches Firefox to ECDSA with P-256 by
default.  It's much, much faster.  http://bench.cr.yp.to/ claims that
it's 150 times faster on mobile devices for keygen.

_______________________________________________
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
--Apple-Mail-8EB685EF-1B75-480D-97CC-9900253EFBEA-- From nobody Thu Jun 9 10:29:30 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D954412D8DA for ; Thu, 9 Jun 2016 10:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yls9o3TSxRvX for ; Thu, 9 Jun 2016 10:29:27 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4803512D789 for ; Thu, 9 Jun 2016 10:29:27 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id i187so24509829qkd.3 for ; Thu, 09 Jun 2016 10:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=L9LntyoSB7DGDY1vgm/6B0mMb4hXPKP5tBxo2byfmXA=; b=RuTCKC2DCaiykNH9Gm5iDX8Z2y3+SQHKn3tAk++EmGGMtU/L6DuFRgXLClcj9u5kly W2pc0ZyqdrGHMamKvN6GzbYgViLYE3bFpCuNcJxGRwV+yA8C2gPjEafxt132ikY9C0e+ cak0sQ6t1Bip8GqnPXnylyhPHgTVTa6AY47UQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=L9LntyoSB7DGDY1vgm/6B0mMb4hXPKP5tBxo2byfmXA=; b=MHdgdAK11DHI4W6d3jGRlsQPyVLaQ/2+4nStkV1a9spLKQP0tN2szfmONSmyZgk1Ge 0PtRl2H38FQRj0nNQn0+0hTaYqpnadAyvCUtn0YZ3mJErUgj4bxLy/GNiKB/TRWM0yLI DiIdTGk5iwjDzAKh4WpWfn44KtXTSRRbkGJc86NQqsnv7BVWvdIUSIogbpRdzh9520Mw eltD6ogqDLrItjSygZ9aqhPHhzmWF6H9xUXLlt/waiscYXaDcvou1RT2BeT2nwyzFZMB pD3lfjVm4crvHMU81vFEazS/++gRzYgZf1M2Lxo50G4thFS+nr+ZST31uTDpDIs8SxPs 0/tw== X-Gm-Message-State: ALyK8tIyWGl5WZU8zFWiC1HWD7YByL2eht+NdvL2NacM3H/W+3XO7TSdTl5sp3uADwwpWQ== X-Received: by 10.55.144.68 with SMTP id s65mr10984153qkd.209.1465493366323; Thu, 09 Jun 2016 10:29:26 -0700 (PDT) Received: from [5.5.33.201] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id h132sm1918666qhh.32.2016.06.09.10.29.25 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jun 2016 10:29:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <3A4427FF-A0F1-4B1A-B30C-7FE4319515A2@gmail.com> Date: Thu, 9 Jun 2016 12:29:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3B7A187E-D85C-4EB7-A4A8-221E1FD5E059@sn3rd.com> References: <57457874.1010708@alvestrand.no> <3A4427FF-A0F1-4B1A-B30C-7FE4319515A2@gmail.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] Security architecture: Making ECDSA mandatory X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 17:29:29 -0000 I believe it=E2=80=99s in the newly posted -12 version: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch spt > On Jun 09, 2016, at 10:08, Bernard Aboba = wrote: >=20 > It should be merged.=20 >=20 > On May 25, 2016, at 03:03, Harald Alvestrand = wrote: >=20 >> In my search for status on ECDSA (we're in the process of switching = the Chrome default), I came across this in the current draft: >>=20 >> All implementations MUST implement DTLS 1.0, with the cipher suite >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection >> profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD >> implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >> cipher suite. Implementations SHOULD favor cipher suites which >> support PFS over non-PFS cipher suites and GCM over CBC cipher >> suites. [[OPEN ISSUE: Should we require ECDSA? Waiting for WG >> Consensus.]] >>=20 >>=20 >> I also found Martin's PR. It's 11 months old, still open. >>=20 >> Can we merge this now? >>=20 >>=20 >> On 06/13/2015 12:06 AM, Martin Thomson wrote: >>> I've opened https://github.com/rtcweb-wg/security-arch/pull/33 >>>=20 >>>=20 >>> This changes the MTI cipher suites to ECDSA and does a little = cleanup >>> on the corresponding API requirements to more closely match what has >>> just landed in the W3C specification. >>>=20 >>> We discussed ECDSA and the only concerns raised were with >>> compatibility. I've done some testing with other implementations = with >>> no issues, and ECDSA seems to be well supported on all those >>> hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for = helping >>> out with checks there and to NIST for creating certification = pressure >>> with FIPS-2). >>>=20 >>> I have an implementation that switches Firefox to ECDSA with P-256 = by >>> default. It's much, much faster. =20 >>> http://bench.cr.yp.to/ >>> claims that >>> it's 150 times faster on mobile devices for keygen. >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>>=20 >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=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 Jun 9 10:38:00 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6C812D6AE for ; Thu, 9 Jun 2016 10:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mjcwguPPg1V for ; Thu, 9 Jun 2016 10:37:56 -0700 (PDT) Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB4012D188 for ; Thu, 9 Jun 2016 10:37:55 -0700 (PDT) Received: from smtp16.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CEF2818317F for ; Thu, 9 Jun 2016 13:35:26 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp16.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 72DE018317C for ; Thu, 9 Jun 2016 13:35:26 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Thu, 09 Jun 2016 13:35:26 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Thu, 9 Jun 2016 11:35:30 -0600 To: RTCWeb IETF Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] WGLC of draft-ietf-rtcweb-transports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 17:37:58 -0000 This is the working group last call for draft-ietf-rtcweb-transports-14 Please send any comments to this list by June 22, 2016. Thanks, Cullen, Ted, and Sean From nobody Sun Jun 12 02:19:27 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C787412D1B1 for ; Sun, 12 Jun 2016 02:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ombGZE5Wp_en for ; Sun, 12 Jun 2016 02:19:24 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FAC412D10B for ; Sun, 12 Jun 2016 02:19:24 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id z186so84904086ywd.2 for ; Sun, 12 Jun 2016 02:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=K3k2ZUTI3HQCt4UT0jIFy+jwbaU3JvJx+DZQnzbND34=; b=LwonjjLEBYjUI0KU0tZQcwFAr2re/ifvAXFp5dt0QcONN8KdFa8pYeMnRvosamQSkB 3mNDu9f8PjzlIBy7vNQOP9z+/cVYIGMmuu5FAcYMylKrtMf+tNhg94XhcQC+qCz5i3ad eRLJ/Rm60mYC45qr4Dt55nZwAL9EDomWNZvJMB3ZNb2qj9sitFPQydUsZ8AeSdLaV7+9 8QVmiqPwQGZ+bdV7B5r+if5FiIJrHOhn6EimH9rTFfu4q/kqRHFZ8vAGFZroOi72z8gz d1u9G6eF53FvVkpOqHkbzfExGUAJHbJsJlNSlj6/WnRB3sgG0Oa8gI9Bp/OKZfEsJSwk lceQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=K3k2ZUTI3HQCt4UT0jIFy+jwbaU3JvJx+DZQnzbND34=; b=F9kYYtaSpfSNvS72GGFD0j2l/OkM1AWQn0TPbIz6I1/bFsOk9N8cbSz9zwEWYWxNNt vTCfxHXcL1O3ujiPH1auPDA1k1rRkCV/LaXWtdYxmOGjes3ENG7jVJmQe2kGRxxms/8/ 6cJybp85Ahx5shuq1YSaZFJ3JshUIsFvg3iG7Ad5Kz+8P9ae8MD8OpD7aLSHPHSvU7Oy 6AHlz0svaGZ1ihVHsW9jF6glouIuStXf29JbJEYqlh8jK9RWSbNgI7IwfWJz+RtMZb+s VZyhO5ZLns3GoxF8mVr5ok+xL0cmU/erqQ9jMKOBD+SNUPex2CsmVUa01ti4Dq3aZ93T PnFA== X-Gm-Message-State: ALyK8tJfF5x8FxwKXuZmGoj0mHCJ/Lvj8+eyOlN1rY3zS9UZg7XpMyfkXyvSITA/T05JtoGVDBLq/kSMdC+85g== X-Received: by 10.129.27.9 with SMTP id b9mr5359692ywb.173.1465723163871; Sun, 12 Jun 2016 02:19:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.240.194 with HTTP; Sun, 12 Jun 2016 02:19:04 -0700 (PDT) In-Reply-To: <3B7A187E-D85C-4EB7-A4A8-221E1FD5E059@sn3rd.com> References: <57457874.1010708@alvestrand.no> <3A4427FF-A0F1-4B1A-B30C-7FE4319515A2@gmail.com> <3B7A187E-D85C-4EB7-A4A8-221E1FD5E059@sn3rd.com> From: Michael Davey Date: Sun, 12 Jun 2016 10:19:04 +0100 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a1142a41a85913b0535114481 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Security architecture: Making ECDSA mandatory X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: md84419@gmail.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: Sun, 12 Jun 2016 09:19:27 -0000 --001a1142a41a85913b0535114481 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25 May 2016 at 16:10, Michael Davey wrote: > > I would recommend referencing IETF BCP 195. The comments about ECDHE in that document (and of course the wider issues with weak DH key exchange) may also be noteworthy. There is still no mention of BCP 195 in the -12 document. The recommendations of BCP 195 with regards to ECDHE aren't reflected in the -12 document. --=20 Michael On 9 June 2016 at 18:29, Sean Turner wrote: > I believe it=E2=80=99s in the newly posted -12 version: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch > > spt > > > On Jun 09, 2016, at 10:08, Bernard Aboba > wrote: > > > > It should be merged. > > > > On May 25, 2016, at 03:03, Harald Alvestrand > wrote: > > > >> In my search for status on ECDSA (we're in the process of switching th= e > Chrome default), I came across this in the current draft: > >> > >> All implementations MUST implement DTLS 1.0, with the cipher suite > >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection > >> profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD > >> implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > >> cipher suite. Implementations SHOULD favor cipher suites which > >> support PFS over non-PFS cipher suites and GCM over CBC cipher > >> suites. [[OPEN ISSUE: Should we require ECDSA? Waiting for WG > >> Consensus.]] > >> > >> > >> I also found Martin's PR. It's 11 months old, still open. > >> > >> Can we merge this now? > >> > >> > >> On 06/13/2015 12:06 AM, Martin Thomson wrote: > >>> I've opened https://github.com/rtcweb-wg/security-arch/pull/33 > >>> > >>> > >>> This changes the MTI cipher suites to ECDSA and does a little cleanup > >>> on the corresponding API requirements to more closely match what has > >>> just landed in the W3C specification. > >>> > >>> We discussed ECDSA and the only concerns raised were with > >>> compatibility. I've done some testing with other implementations wit= h > >>> no issues, and ECDSA seems to be well supported on all those > >>> hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for helping > >>> out with checks there and to NIST for creating certification pressure > >>> with FIPS-2). > >>> > >>> I have an implementation that switches Firefox to ECDSA with P-256 by > >>> default. It's much, much faster. > >>> http://bench.cr.yp.to/ > >>> claims that > >>> it's 150 times faster on mobile devices for keygen. > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1142a41a85913b0535114481 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 25 May 2016 at 16:10, Michael Davey=C2= =A0<md84419@gmail.com>=C2=A0wrote:
>=C2=A0I= would recommend referencing IETF BCP 195.=C2=A0 The comments about ECDHE i= n that document (and of course the wider issues with weak DH key exchange) = may also be noteworthy.

There is still no mention o= f BCP 195 in the -12 document.=C2=A0 The recommendations of BCP 195 with re= gards to ECDHE aren't reflected in the -12 document.
<= span style=3D"font-size:12.8px">
--=C2=A0
Mich= ael


On 9 June 2016 = at 18:29, Sean Turner <sean@sn3rd.com> wrote:
I believe it=E2=80=99s in the newly posted -12 version: https://datatracker.ietf.org/doc/dra= ft-ietf-rtcweb-security-arch

spt

> On Jun 09, 2016, at 10:08, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>
> It should be merged.
>
> On May 25, 2016, at 03:03, Harald Alvestrand <harald@alvestrand.no> wrote:
>
>> In my search for status on ECDSA (we're in the process of swit= ching the Chrome default), I came across this in the current draft:
>>
>>=C2=A0 =C2=A0 All implementations MUST implement DTLS 1.0, with the= cipher suite
>>=C2=A0 =C2=A0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP = protection
>>=C2=A0 =C2=A0 profile SRTP_AES128_CM_HMAC_SHA1_80.=C2=A0 Implementa= tions SHOULD
>>=C2=A0 =C2=A0 implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_12= 8_GCM_SHA256
>>=C2=A0 =C2=A0 cipher suite.=C2=A0 Implementations SHOULD favor ciph= er suites which
>>=C2=A0 =C2=A0 support PFS over non-PFS cipher suites and GCM over C= BC cipher
>>=C2=A0 =C2=A0 suites.=C2=A0 [[OPEN ISSUE: Should we require ECDSA?= =C2=A0 Waiting for WG
>>=C2=A0 =C2=A0 Consensus.]]
>>
>>
>> I also found Martin's PR. It's 11 months old, still open.<= br> >>
>> Can we merge this now?
>>
>>
>> On 06/13/2015 12:06 AM, Martin Thomson wrote:
>>> I've opened https://github.com/rt= cweb-wg/security-arch/pull/33
>>>
>>>
>>> This changes the MTI cipher suites to ECDSA and does a little = cleanup
>>> on the corresponding API requirements to more closely match wh= at has
>>> just landed in the W3C specification.
>>>
>>> We discussed ECDSA and the only concerns raised were with
>>> compatibility.=C2=A0 I've done some testing with other imp= lementations with
>>> no issues, and ECDSA seems to be well supported on all those >>> hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for = helping
>>> out with checks there and to NIST for creating certification p= ressure
>>> with FIPS-2).
>>>
>>> I have an implementation that switches Firefox to ECDSA with P= -256 by
>>> default.=C2=A0 It's much, much faster.
>>> http://bench.cr.yp.to/
>>>=C2=A0 claims that
>>> it's 150 times faster on mobile devices for keygen.
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>>
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtc= web
>>
>> _______________________________________________
>> 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

--001a1142a41a85913b0535114481-- From nobody Sun Jun 12 04:53:59 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024F912D647 for ; Sun, 12 Jun 2016 04:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxQenpka1HkU for ; Sun, 12 Jun 2016 04:53:56 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31F012D190 for ; Sun, 12 Jun 2016 04:53:55 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id v137so2462628ywa.3 for ; Sun, 12 Jun 2016 04:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vSljsB6NVXQ6TDLASdun2WXeLwPLd9rFP5mJWYBflko=; b=X7NnadJ1aMcAlL6Y1oVisdiiW0QEz97h1im3K9Az4tYRzxyhqrGp2ALV16JdnA2dtm 8GaFU3ud3HPqj53m2wMaTrlmyTHpVPPcCiCx1mEgE2ueTyxq8X7JXIzjbK5tIC6HPWl9 1sW8pI6YQ1DNhU6uT4RslnK8NwypAYz8KURIbMLOHN+xfqbW4jyE2eQm8zL8hRQzg7ki ukhN4ot4nXLhTEqpQc9sggbRgtqGmV1g3nVmNq8Or33VS9/ZdAMaOLW1UVPqxfFok6ms c/m1qNKoXLqgdvEJ53Oq9hpCy0Vv9QVAVcq3P7iVETSBv3LzmfDpItWoHA8MxZhcIl+E b6kw== 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; bh=vSljsB6NVXQ6TDLASdun2WXeLwPLd9rFP5mJWYBflko=; b=IY5i8dALy+TgKTa/9vtf6oHzG3eLIjgfyePeWtnRSXPL28h1I0uGqipbHuMdHW2/wq PSwfqMzlL1Q+eo4W9U84aABB9EllkhRsKNUUJ2EvGdATgkK031tfD/Teden8nAYUkkKB kH1CiqDonDQkNgaxzNAL/rX8pK6Hnn9aroA6wrpyTsNb8b972q/mYzkbVgXaRVXmV/80 fBFNRKsRLzvtfs6r8YayGAUOEhgcFUXDlA0G5w09GU65bpG/Qv2jgdJMYY5Yi3ZnxlcD rIDTMam8b4JrzXH4KtOfzk1VpyzSNQUyzmwzwtqNAP9G4fXGY6nDDBkXkuQjDYKb0tRm bGfA== X-Gm-Message-State: ALyK8tKBRcUsWhNWUuOHZKFKIEoF4fq8ndPypOhRUhP6YKZ4Unl/ubx6dqYDNzJhVauTMG834wIfmYH4TVzuLw== X-Received: by 10.129.4.8 with SMTP id 8mr6047576ywe.44.1465732435058; Sun, 12 Jun 2016 04:53:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.213.206 with HTTP; Sun, 12 Jun 2016 04:53:15 -0700 (PDT) In-Reply-To: References: <57457874.1010708@alvestrand.no> <3A4427FF-A0F1-4B1A-B30C-7FE4319515A2@gmail.com> <3B7A187E-D85C-4EB7-A4A8-221E1FD5E059@sn3rd.com> From: Eric Rescorla Date: Sun, 12 Jun 2016 04:53:15 -0700 Message-ID: To: md84419@gmail.com Content-Type: multipart/alternative; boundary=001a113f575c20e6d10535136d31 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security architecture: Making ECDSA mandatory X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jun 2016 11:53:58 -0000 --001a113f575c20e6d10535136d31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If there's something in particular you'd like to see, a pull request would be a great way to indicate that. -Ekr On Sun, Jun 12, 2016 at 2:19 AM, Michael Davey wrote: > > On 25 May 2016 at 16:10, Michael Davey wrote: > >> > I would recommend referencing IETF BCP 195. The comments about ECDHE > in that document (and of course the wider issues with weak DH key exchang= e) > may also be noteworthy. > > There is still no mention of BCP 195 in the -12 document. The > recommendations of BCP 195 with regards to ECDHE aren't reflected in the > -12 document. > > -- > Michael > > > On 9 June 2016 at 18:29, Sean Turner wrote: > >> I believe it=E2=80=99s in the newly posted -12 version: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch >> >> spt >> >> > On Jun 09, 2016, at 10:08, Bernard Aboba >> wrote: >> > >> > It should be merged. >> > >> > On May 25, 2016, at 03:03, Harald Alvestrand >> wrote: >> > >> >> In my search for status on ECDSA (we're in the process of switching >> the Chrome default), I came across this in the current draft: >> >> >> >> All implementations MUST implement DTLS 1.0, with the cipher suite >> >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection >> >> profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD >> >> implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >> >> cipher suite. Implementations SHOULD favor cipher suites which >> >> support PFS over non-PFS cipher suites and GCM over CBC cipher >> >> suites. [[OPEN ISSUE: Should we require ECDSA? Waiting for WG >> >> Consensus.]] >> >> >> >> >> >> I also found Martin's PR. It's 11 months old, still open. >> >> >> >> Can we merge this now? >> >> >> >> >> >> On 06/13/2015 12:06 AM, Martin Thomson wrote: >> >>> I've opened https://github.com/rtcweb-wg/security-arch/pull/33 >> >>> >> >>> >> >>> This changes the MTI cipher suites to ECDSA and does a little cleanu= p >> >>> on the corresponding API requirements to more closely match what has >> >>> just landed in the W3C specification. >> >>> >> >>> We discussed ECDSA and the only concerns raised were with >> >>> compatibility. I've done some testing with other implementations wi= th >> >>> no issues, and ECDSA seems to be well supported on all those >> >>> hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for helpin= g >> >>> out with checks there and to NIST for creating certification pressur= e >> >>> with FIPS-2). >> >>> >> >>> I have an implementation that switches Firefox to ECDSA with P-256 b= y >> >>> default. It's much, much faster. >> >>> http://bench.cr.yp.to/ >> >>> claims that >> >>> it's 150 times faster on mobile devices for keygen. >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> _______________________________________________ >> 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 > > --001a113f575c20e6d10535136d31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If there's something in particular you'd like to s= ee, a pull request would be a great way to indicate that.

-Ekr


On Sun, Jun 12, 2016 at 2:19 AM, Michael Davey <md84419= @gmail.com> wrote:

On 25 May 2016 at 16:10, Michael D= avey=C2=A0<md84419@gmail.com>=C2=A0wrote:
>=C2=A0I would recommend referencing IETF BCP 195.=C2=A0 The comments about = ECDHE in that document (and of course the wider issues with weak DH key exc= hange) may also be noteworthy.
=
There is stil= l no mention of BCP 195 in the -12 document.=C2=A0 The recommendations of B= CP 195 with regards to ECDHE aren't reflected in the -12 document.

--= =C2=A0
Michael


On 9 June 2016 at 18:29, Sean Turner <sean@sn3rd.com= > wrote:
I believe it=E2=80= =99s in the newly posted -12 version:
https://datatracker.ietf.org/doc/dra= ft-ietf-rtcweb-security-arch

spt

> On Jun 09, 2016, at 10:08, Bernard Aboba <bernard.aboba@gmail.com> wrote:<= br> >
> It should be merged.
>
> On May 25, 2016, at 03:03, Harald Alvestrand <harald@alvestrand.no> wrote: >
>> In my search for status on ECDSA (we're in the process of swit= ching the Chrome default), I came across this in the current draft:
>>
>>=C2=A0 =C2=A0 All implementations MUST implement DTLS 1.0, with the= cipher suite
>>=C2=A0 =C2=A0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP = protection
>>=C2=A0 =C2=A0 profile SRTP_AES128_CM_HMAC_SHA1_80.=C2=A0 Implementa= tions SHOULD
>>=C2=A0 =C2=A0 implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_12= 8_GCM_SHA256
>>=C2=A0 =C2=A0 cipher suite.=C2=A0 Implementations SHOULD favor ciph= er suites which
>>=C2=A0 =C2=A0 support PFS over non-PFS cipher suites and GCM over C= BC cipher
>>=C2=A0 =C2=A0 suites.=C2=A0 [[OPEN ISSUE: Should we require ECDSA?= =C2=A0 Waiting for WG
>>=C2=A0 =C2=A0 Consensus.]]
>>
>>
>> I also found Martin's PR. It's 11 months old, still open.<= br> >>
>> Can we merge this now?
>>
>>
>> On 06/13/2015 12:06 AM, Martin Thomson wrote:
>>> I've opened https://github.com/rt= cweb-wg/security-arch/pull/33
>>>
>>>
>>> This changes the MTI cipher suites to ECDSA and does a little = cleanup
>>> on the corresponding API requirements to more closely match wh= at has
>>> just landed in the W3C specification.
>>>
>>> We discussed ECDSA and the only concerns raised were with
>>> compatibility.=C2=A0 I've done some testing with other imp= lementations with
>>> no issues, and ECDSA seems to be well supported on all those >>> hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for = helping
>>> out with checks there and to NIST for creating certification p= ressure
>>> with FIPS-2).
>>>
>>> I have an implementation that switches Firefox to ECDSA with P= -256 by
>>> default.=C2=A0 It's much, much faster.
>>> http://bench.cr.yp.to/
>>>=C2=A0 claims that
>>> it's 150 times faster on mobile devices for keygen.
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>>
>>> rtcweb@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/rtc= web
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> 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


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


--001a113f575c20e6d10535136d31-- From nobody Tue Jun 14 01:14:49 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F0212B032; Tue, 14 Jun 2016 01:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b9ZZ3WToUGD; Tue, 14 Jun 2016 01:14:46 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F829127078; Tue, 14 Jun 2016 01:14:45 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-2e-575fbcf355e1 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AC.CA.12926.3FCBF575; Tue, 14 Jun 2016 10:14:43 +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.294.0; Tue, 14 Jun 2016 10:14:43 +0200 To: IETF AVTCore WG From: Magnus Westerlund Message-ID: Date: Tue, 14 Jun 2016 10:14:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM2K7ve7nPfHhBi9O21i87FnJbjG/8zS7 xdp/7ewWx97cZXNg8Viy5CeTx6ydT1gCmKK4bFJSczLLUov07RK4Mh4/2sdWcJW7Yu7DJ6wN jDc5uxg5OSQETCRO7F7CCGGLSVy4t56ti5GLQ0jgCKPEq0VvmCCc5YwSZz82sYNUiQgoSeyY tI0ZxGYWSJQ4uP8SG4jNJmAhcfNHI5gtLOAj8fXLXBYQm1fAXuJk/2WwOIuAqsSpQ01gtqhA jETj7cPsEDWCEidnPgGq5wCaaS/xYGsZxHh5ieats8FWCQloSzQ0dbBOYOSfhaRjFkLHLCQd CxiZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIEBuTBLb9VdzBefuN4iFGAg1GJh/eBTny4 EGtiWXFl7iFGCQ5mJRHepJ1AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NT C1KLYLJMHJxSDYyG8mkr72zPXXVooxrPzU+3tDaHeyR/rK8Rlmw8ck8rfIqi3gzGvoeK/Dw9 MXPKrz19su/yii+pf6VD53IXm5Q1fTk2ve/1F8lp/jdrExacqdVez/GVYd2ZJaxV9vwMK/Yr 1KUdEWWcs/LwdysTzqoDPs/+sF1btuD8ttIc2euXLu2fzdsT5vFViaU4I9FQi7moOBEAbjui kkQCAAA= Archived-At: Cc: Ben Campbell , "rtcweb@ietf.org" , tsvwg Subject: [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jun 2016 08:14:48 -0000 AVT, RTCWEB and TSVWG This announces an additional one week WG last call (in AVT) on the changes done to "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions" that is intended for Proposed Standard. The last call concludes on the 21st of June. So this last call is deemed necessary due to normative changes in the behaviour as result of the conclusions of how to resolve the Discuss regarding reaction to ECN markings. If there are no issues in this additional WG last call, the draft will be approved for publication as it has already passed IESG review. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-16 Cheers Magnus Westerlund AVTCORE WG chair ---------------------------------------------------------------------- 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 Jun 14 06:21:06 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07CA12D662; Tue, 14 Jun 2016 06:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEpuZ837quLs; Tue, 14 Jun 2016 06:20:57 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CDCE12D149; Tue, 14 Jun 2016 06:20:57 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5EDKrkG030742 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Jun 2016 09:20:54 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u5EDKrkG030742 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1465910454; bh=DuhFDGqjhQ/8VD5WyBYNAgylz7w=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=g9qea73KSBhwHDxUlFzQ2yVnnJk4bno4rfc66HNlR3VlZPT6ZvmHTgNNFgM83E7MI i32lfa4BiAbgNLKT1oLLb10DLS/saYtl2nPyJ1qHJy7D3kBwPvM7P/xJCxtH4b1Orn AnEjqjwKsJA5K470EueUlsQeZiuYi0SA9F6FLUtU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u5EDKrkG030742 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 14 Jun 2016 09:20:02 -0400 Received: from MXHUB314.corp.emc.com (MXHUB314.corp.emc.com [10.146.3.92]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5EDKdJE021165 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 14 Jun 2016 09:20:40 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB314.corp.emc.com ([10.146.3.92]) with mapi id 14.03.0266.001; Tue, 14 Jun 2016 09:20:39 -0400 From: "Black, David" To: Magnus Westerlund , IETF AVTCore WG Thread-Topic: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRxhTZlEGL7AwWFU+285hNj7xak5/o7+uw Date: Tue, 14 Jun 2016 13:20:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.54] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , tsvwg Subject: Re: [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jun 2016 13:21:00 -0000 In the new ECN text in Section 7, I see: Given the above issues, implementations MAY ignore ECN-CE marks when=09 determining if the congestion circuit breaker triggers, since=09 excessive persistent congestion will eventually lead to packet loss=09 that will trigger the circuit breaker. Doing this will protect the=09 network from congestion collapse, but might result in sub-optimal=09 user experience for competing flows that share the bottleneck queue,=09 since that queue will be driven to overflow, inducing high latency. If this is a concern, the only current guidance is for=09 implementations to treat ECN-CE marked packets as equivalent to lost=09 packets, whilst being aware that this might trigger the circuit=09 breaker prematurely in future, depending on how AQM and ECN=09 deployment evolves. Developers that implement a circuit breaker=09 based on ECN-CE marks will need to track future developments in AQM=09 standards and deployed ECN marking behaviour, and ensure their=09 implementations are updated to match. I think "MAY" is inappropriate here - this text reads like a "SHOULD NOT" requirement with an explanation of what happens when something else is done. Proposed rewrite: Given the above issues, implementations SHOULD NOT ignore ECN-CE marks when determining whether to trigger the congestion circuit breaker, even= =09 though excessive persistent congestion will eventually lead to packet lo= ss=09 that triggers the circuit breaker. Relying on packet loss protects the= =09 network from congestion collapse, but might result in sub-optimal=09 user experience for competing flows that share the bottleneck queue,=09 since that queue will be driven to overflow, inducing higher latency. Current implementation guidance is for implementations to treat ECN-CE marked packets as equivalent to lost=09 packets, whilst being aware that this might trigger the circuit=09 breaker prematurely in the future, depending on how AQM and ECN=09 deployment evolves. Developers that implement a circuit breaker=09 based on ECN-CE marks will need to track future developments in AQM=09 standards and deployed ECN marking behaviour, and ensure their=09 implementations are updated to match. The original "MAY" language invites implementers to completely ignore ECN-CE marks, which I think is very bad advice. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Magnus Westerlun= d > Sent: Tuesday, June 14, 2016 4:15 AM > To: IETF AVTCore WG > Cc: rtcweb@ietf.org; tsvwg > Subject: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-= breakers- > 16 >=20 > AVT, RTCWEB and TSVWG >=20 > This announces an additional one week WG last call (in AVT) on the > changes done to "Multimedia Congestion Control: Circuit Breakers for > Unicast RTP Sessions" that is intended for Proposed Standard. The last > call concludes on the 21st of June. >=20 > So this last call is deemed necessary due to normative changes in the > behaviour as result of the conclusions of how to resolve the Discuss > regarding reaction to ECN markings. >=20 > If there are no issues in this additional WG last call, the draft will > be approved for publication as it has already passed IESG review. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-circuit-breake= rs-16 >=20 > Cheers >=20 > Magnus Westerlund > AVTCORE WG chair >=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 > ---------------------------------------------------------------------- From nobody Tue Jun 14 06:44:16 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AED128E18; Tue, 14 Jun 2016 06:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH0nhxd6spt6; Tue, 14 Jun 2016 06:44:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5776A12D5C2; Tue, 14 Jun 2016 06:44:06 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-bd-57600a247218 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FD.B5.12926.42A00675; Tue, 14 Jun 2016 15:44:04 +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.294.0; Tue, 14 Jun 2016 15:43:48 +0200 To: "Black, David" , IETF AVTCore WG References: From: Magnus Westerlund Message-ID: Date: Tue, 14 Jun 2016 15:43:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7ja4KV0K4wfVv2hYve1ayW2w9vJbd Yu2/dnaLY2/usjmweBw5MpvFY8mSn0wBTFFcNimpOZllqUX6dglcGf29H5kKnqhV/O45wtrA eE+ui5GTQ0LARKJx8xdGCFtM4sK99WxdjFwcQgJHGCVufNvPBpIQEljOKLG4vQTEFhaIkli9 8wFYXETAQ6JpywNGiIZmRolZ8ycwgSSYBewlrvxaww5iswlYSNz80QjWwAsUv3n7O5jNIqAq 0TRvAliNqECMROPtw+wQNYISJ2c+YQGxOQX8JPb+O87axcgBNvPB1jKI8fISzVtnM0Pcpi3R 0NTBOoFRcBaS7lkIHbOQdCxgZF7FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERjAB7f8Vt3B ePmN4yFGAQ5GJR7eBzrx4UKsiWXFlbmHGCU4mJVEeNvYE8KFeFMSK6tSi/Lji0pzUosPMUpz sCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MIo/FjxuYtZ/ZMkX06tFwp2JjjFMu22zwr5u Yv21d32BwZPF+o/M/u/ap6T2q+zQx4NsnVM8AqfxVZZ3hzC8P992O2vu8RwztyNSjNeTnFf/ /nxHIuaN84/e0lvL17FtEWnb8vPufpbbbv5zRG2f9Wry9LQ0NGk9mPO9jDlN4uXKqHl3dF4G uCixFGckGmoxFxUnAgBjR6ISXAIAAA== Archived-At: Cc: "rtcweb@ietf.org" , tsvwg Subject: Re: [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jun 2016 13:44:10 -0000 Hi, Please see below. Den 2016-06-14 kl. 15:20, skrev Black, David: > In the new ECN text in Section 7, I see: > > Given the above issues, implementations MAY ignore ECN-CE marks when > determining if the congestion circuit breaker triggers, since > excessive persistent congestion will eventually lead to packet loss > that will trigger the circuit breaker. Doing this will protect the > network from congestion collapse, but might result in sub-optimal > user experience for competing flows that share the bottleneck queue, > since that queue will be driven to overflow, inducing high latency. > If this is a concern, the only current guidance is for > implementations to treat ECN-CE marked packets as equivalent to lost > packets, whilst being aware that this might trigger the circuit > breaker prematurely in future, depending on how AQM and ECN > deployment evolves. Developers that implement a circuit breaker > based on ECN-CE marks will need to track future developments in AQM > standards and deployed ECN marking behaviour, and ensure their > implementations are updated to match. > > I think "MAY" is inappropriate here - this text reads like a "SHOULD NOT" > requirement with an explanation of what happens when something else > is done. Proposed rewrite: > > Given the above issues, implementations SHOULD NOT ignore ECN-CE marks > when determining whether to trigger the congestion circuit breaker, even > though excessive persistent congestion will eventually lead to packet loss > that triggers the circuit breaker. Relying on packet loss protects the > network from congestion collapse, but might result in sub-optimal > user experience for competing flows that share the bottleneck queue, > since that queue will be driven to overflow, inducing higher latency. > > Current implementation guidance is for > implementations to treat ECN-CE marked packets as equivalent to lost > packets, whilst being aware that this might trigger the circuit > breaker prematurely in the future, depending on how AQM and ECN > deployment evolves. Developers that implement a circuit breaker > based on ECN-CE marks will need to track future developments in AQM > standards and deployed ECN marking behaviour, and ensure their > implementations are updated to match. > > The original "MAY" language invites implementers to completely ignore > ECN-CE marks, which I think is very bad advice. So in the discussion between Mirja, the authors and me in attempting to resolve the discuss we ended up in MAY for a reason. We on the call agreed after a lengthy discussion that treating a ECN-CE mark the same way as a loss, is not appropriate. This despite that current in force specification indicate that would be the answer. However, as indicated in the updated text, there are a number of ongoing work that indicates that is not the expected actual marking behavior. This resulted in another issue, there are no specified marking behavior that we define an appropriate response based on. When such a behavior is defined one can update circuit breaker with a well defined response to ECN-CE marks. So due to the lack of defined behavior we didn't see a possibility for using SHOULD NOT, as we can't point to what should be implemented. Thus we chose to propose MAY as it then is open to the implementation if they can find a well working response or completely ignore this. So far I lack evidence for any significant deployment of ECN for RTP, unfortunately. This lessens the impact of this choice. Secondly, ignoring the ECN-CE marks for a circuit breaker we believe will have a limited impact. If the implementation only have circuit breaker, i.e. no full fledged congestion controller and uses ECN, they can in worst case drive the buffer into the overload regime where it starts dropping packets. So if the flow does cause persistent congestion it will drive the AQM into packet drops and thus triggering of the circuit breaker. Yes, it will be unfair and push away responsive flows. But, that will happen also without ECN, is not something that the circuit breaker can protect against. I hope this makes it clearer why we arrived at MAY and don't see the possibility to use SHOULD strength wording regarding ECN-CE marks. Cheers Magnus Westerlund AVTCORE Chair. ---------------------------------------------------------------------- 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 Jun 14 06:59:40 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B883D12D759; Tue, 14 Jun 2016 06:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEEbiEgX6_FW; Tue, 14 Jun 2016 06:59:33 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0E44712D74D; Tue, 14 Jun 2016 06:59:33 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9BA06C9418; Tue, 14 Jun 2016 09:59:27 -0400 (EDT) Date: Tue, 14 Jun 2016 09:59:27 -0400 From: John Leslie To: "Black, David" Message-ID: <20160614135927.GE39331@verdi> References: 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: Cc: "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jun 2016 13:59:35 -0000 Black, David wrote: > > In the new ECN text in Section 7, I see: > > Given the above issues, implementations MAY ignore ECN-CE marks when > determining if the congestion circuit breaker triggers, since > excessive persistent congestion will eventually lead to packet loss >... > I think "MAY" is inappropriate here - this text reads like a "SHOULD NOT" > requirement with an explanation of what happens when something else > is done. I'm very sympathetic to your issue: there are implementations of ECN out there which _will_not_ drop an ECN-capable packet before the sending queue has overflowed. But at the same time, we're headed into changes where ECN-CE marking will become more frequent than packet-drop. We must find a way to avoid ECN-CE triggering the congestion circuit breaker when the forwarding node has not reached a level of congestion which could trigger packet loss. I'd prefer language (perhaps in an RFC-3168-bis) stating that packet drop MUST me used, at least occasionally, on packets which would be ECN-CE marked, when the overall congestion at that node reaches the drop level for non-ECN-capable packets. (The forwarding node is the only node with sufficient information to see the issue.) (I recommend folks interested in circuit-breaker pay attention to the L4S BoF being scheduled for Berlin.) -- John Leslie From nobody Tue Jun 14 07:20:54 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB34212D7AA; Tue, 14 Jun 2016 07:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxabOGro3I76; Tue, 14 Jun 2016 07:20:50 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29A412D79B; Tue, 14 Jun 2016 07:20:49 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5EEKhhX017803 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Jun 2016 10:20:46 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5EEKhhX017803 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1465914047; bh=2SjV7jVI0zuMzxIA0xsaInXWGgU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=pJINkQkeIn1Exy+Bruh1n5uWbp7YA/NXNHj4kRkxF2PuzdaKEAo/3j1kGA+Qe2pdB f9Yg70GYJvrfgxEFjBQzTqgIVcCk2F4O2ryEjO36iyt8MFMymESTNNdXlpwIgE71fg oqYjz9W16gFiQ9V3GfFuB1dBFAqw9nPM5NxnMrT8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5EEKhhX017803 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 14 Jun 2016 10:19:42 -0400 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5EEKK00015973 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 14 Jun 2016 10:20:20 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0266.001; Tue, 14 Jun 2016 10:20:20 -0400 From: "Black, David" To: Magnus Westerlund , IETF AVTCore WG Thread-Topic: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRxkLUYr+6QxUe90uOYiuDzdk+1J/pASmA Date: Tue, 14 Jun 2016 14:20:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.54] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , tsvwg Subject: Re: [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jun 2016 14:20:53 -0000 > This resulted in another issue, there are no specified marking behavior > that we define an appropriate response based on. When such a behavior is > defined one can update circuit breaker with a well defined response to > ECN-CE marks. So due to the lack of defined behavior we didn't see a > possibility for using SHOULD NOT, as we can't point to what should be > implemented. Thus we chose to propose MAY as it then is open to the > implementation if they can find a well working response or completely > ignore this. My problem is that the new "MAY" sentence is unqualified: > > Given the above issues, implementations MAY ignore ECN-CE marks when > > determining if the congestion circuit breaker triggers, That invites implementers to ignore ECN-CE marks without giving this topic = the level of consideration anticipated in this discussion and elsewhere in Sect= ion 7. If "SHOULD NOT" language is unworkable, please propose alternate text that qualifies applicability of the "MAY" - e.g., only after careful considerati= on of everything that we're now discussing and the rest of the text in Section 7. I proposed "SHOULD NOT" because it appear that the original RFC 2119 defini= tion of that term is a good fit to this situation: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Thanks, --David > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, June 14, 2016 9:44 AM > To: Black, David; IETF AVTCore WG > Cc: rtcweb@ietf.org; tsvwg > Subject: Re: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circ= uit- > breakers-16 >=20 > Hi, >=20 > Please see below. >=20 > Den 2016-06-14 kl. 15:20, skrev Black, David: > > In the new ECN text in Section 7, I see: > > > > Given the above issues, implementations MAY ignore ECN-CE marks when > > determining if the congestion circuit breaker triggers, since > > excessive persistent congestion will eventually lead to packet loss > > that will trigger the circuit breaker. Doing this will protect the > > network from congestion collapse, but might result in sub-optimal > > user experience for competing flows that share the bottleneck queue, > > since that queue will be driven to overflow, inducing high latency. > > If this is a concern, the only current guidance is for > > implementations to treat ECN-CE marked packets as equivalent to lost > > packets, whilst being aware that this might trigger the circuit > > breaker prematurely in future, depending on how AQM and ECN > > deployment evolves. Developers that implement a circuit breaker > > based on ECN-CE marks will need to track future developments in AQM > > standards and deployed ECN marking behaviour, and ensure their > > implementations are updated to match. > > > > I think "MAY" is inappropriate here - this text reads like a "SHOULD NO= T" > > requirement with an explanation of what happens when something else > > is done. Proposed rewrite: > > > > Given the above issues, implementations SHOULD NOT ignore ECN-CE mar= ks > > when determining whether to trigger the congestion circuit breaker, > even > > though excessive persistent congestion will eventually lead to packe= t loss > > that triggers the circuit breaker. Relying on packet loss protects= the > > network from congestion collapse, but might result in sub-optimal > > user experience for competing flows that share the bottleneck queue, > > since that queue will be driven to overflow, inducing higher latency= . > > > > Current implementation guidance is for > > implementations to treat ECN-CE marked packets as equivalent to lost > > packets, whilst being aware that this might trigger the circuit > > breaker prematurely in the future, depending on how AQM and ECN > > deployment evolves. Developers that implement a circuit breaker > > based on ECN-CE marks will need to track future developments in AQM > > standards and deployed ECN marking behaviour, and ensure their > > implementations are updated to match. > > > > The original "MAY" language invites implementers to completely ignore > > ECN-CE marks, which I think is very bad advice. >=20 > So in the discussion between Mirja, the authors and me in attempting to > resolve the discuss we ended up in MAY for a reason. We on the call > agreed after a lengthy discussion that treating a ECN-CE mark the same > way as a loss, is not appropriate. This despite that current in force > specification indicate that would be the answer. However, as indicated > in the updated text, there are a number of ongoing work that indicates > that is not the expected actual marking behavior. >=20 > This resulted in another issue, there are no specified marking behavior > that we define an appropriate response based on. When such a behavior is > defined one can update circuit breaker with a well defined response to > ECN-CE marks. So due to the lack of defined behavior we didn't see a > possibility for using SHOULD NOT, as we can't point to what should be > implemented. Thus we chose to propose MAY as it then is open to the > implementation if they can find a well working response or completely > ignore this. >=20 > So far I lack evidence for any significant deployment of ECN for RTP, > unfortunately. This lessens the impact of this choice. >=20 > Secondly, ignoring the ECN-CE marks for a circuit breaker we believe > will have a limited impact. If the implementation only have circuit > breaker, i.e. no full fledged congestion controller and uses ECN, they > can in worst case drive the buffer into the overload regime where it > starts dropping packets. So if the flow does cause persistent congestion > it will drive the AQM into packet drops and thus triggering of the > circuit breaker. Yes, it will be unfair and push away responsive flows. > But, that will happen also without ECN, is not something that the > circuit breaker can protect against. >=20 > I hope this makes it clearer why we arrived at MAY and don't see the > possibility to use SHOULD strength wording regarding ECN-CE marks. >=20 > Cheers >=20 > Magnus Westerlund > AVTCORE Chair. >=20 >=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 > ---------------------------------------------------------------------- From nobody Wed Jun 15 08:04:44 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D2212D836; Wed, 15 Jun 2016 08:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE5F-AD8UTlS; Wed, 15 Jun 2016 08:04:39 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73BD112D849; Wed, 15 Jun 2016 08:04:39 -0700 (PDT) Received: from [130.209.247.112] (port=50083 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bDCMs-0001RF-Mx; Wed, 15 Jun 2016 16:04:36 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Wed, 15 Jun 2016 16:04:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Black, David" X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 15:04:41 -0000 > On 14 Jun 2016, at 15:20, Black, David wrote: >=20 >> This resulted in another issue, there are no specified marking = behavior >> that we define an appropriate response based on. When such a behavior = is >> defined one can update circuit breaker with a well defined response = to >> ECN-CE marks. So due to the lack of defined behavior we didn't see a >> possibility for using SHOULD NOT, as we can't point to what should be >> implemented. Thus we chose to propose MAY as it then is open to the >> implementation if they can find a well working response or completely >> ignore this. >=20 > My problem is that the new "MAY" sentence is unqualified: >=20 >>> Given the above issues, implementations MAY ignore ECN-CE marks = when >>> determining if the congestion circuit breaker triggers, >=20 > That invites implementers to ignore ECN-CE marks without giving this = topic the > level of consideration anticipated in this discussion and elsewhere in = Section 7. > If "SHOULD NOT" language is unworkable, please propose alternate text = that > qualifies applicability of the "MAY" - e.g., only after careful = consideration of > everything that we're now discussing and the rest of the text in = Section 7. >=20 > I proposed "SHOULD NOT" because it appear that the original RFC 2119 = definition > of that term is a good fit to this situation: >=20 > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. The issue with saying =E2=80=9Cimplementations SHOULD NOT ignore ECN-CE = marks=E2=80=9D, is that it implies that they should respond to those = marks. However, the outcome of the long discussion we had with Mirja was = that there=E2=80=99s no consensus on what=E2=80=99s the correct = response, and concern that implementations picking the wrong choice will = hinder the deployment of ECN.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Wed Jun 15 09:06:55 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F26612D920; Wed, 15 Jun 2016 09:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRG71oQhs4JM; Wed, 15 Jun 2016 09:06:51 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE10212D8FB; Wed, 15 Jun 2016 09:06:51 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5FG6bUo024433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jun 2016 12:06:41 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5FG6bUo024433 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466006802; bh=fBUUGjcyrMM7KuZukJy/BBJlINk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=SFkE0GjYhxGm2dPoHUuw74LqajFwiNlASgGHEiY+rKdQ2ROFzrNLx4tH7geCDRJXC rSvFTpd3/hZkskkyrZFLUBG+t0obcZ68gfefy0hX0UWCULYnL6ESeontST0vCPbp6R j6CL2s+GhcqENTXUUOeww+fDrvfu5TdVXOLhMSy4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5FG6bUo024433 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 15 Jun 2016 12:05:43 -0400 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5FG6KY7024501 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 15 Jun 2016 12:06:21 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Wed, 15 Jun 2016 12:06:20 -0400 From: "Black, David" To: Colin Perkins Thread-Topic: [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRxkLUYr+6QxUe90uOYiuDzdk+1J/pASmAgAHjzYD//80dQA== Date: Wed, 15 Jun 2016 16:06:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 16:06:53 -0000 PiBUaGUgaXNzdWUgd2l0aCBzYXlpbmcg4oCcaW1wbGVtZW50YXRpb25zIFNIT1VMRCBOT1QgaWdu b3JlIEVDTi1DRSBtYXJrc+KAnSwgaXMNCj4gdGhhdCBpdCBpbXBsaWVzIHRoYXQgdGhleSBzaG91 bGQgcmVzcG9uZCB0byB0aG9zZSBtYXJrcy4gSG93ZXZlciwgdGhlIG91dGNvbWUNCj4gb2YgdGhl IGxvbmcgZGlzY3Vzc2lvbiB3ZSBoYWQgd2l0aCBNaXJqYSB3YXMgdGhhdCB0aGVyZeKAmXMgbm8g Y29uc2Vuc3VzIG9uIHdoYXTigJlzDQo+IHRoZSBjb3JyZWN0IHJlc3BvbnNlLCBhbmQgY29uY2Vy biB0aGF0IGltcGxlbWVudGF0aW9ucyBwaWNraW5nIHRoZSB3cm9uZw0KPiBjaG9pY2Ugd2lsbCBo aW5kZXIgdGhlIGRlcGxveW1lbnQgb2YgRUNOLg0KDQpVbmRlcnN0b29kLCBhbmQgSSdtIG5vdCBh c2tpbmcgZm9yIHRoYXQuICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBwcm92aWRpbmcgaW1w bGVtZW50ZXJzDQp3aXRoIHRvbyBtdWNoIGxhdGl0dWRlIHRvIGlnbm9yZSBFQ04tQ0UgbWFya3Mg KGUuZy4sIGJlY2F1c2UgYW4gaW1wbGVtZW50ZXIgZG9lc24ndA0Kd2FudCB0byB0aGluayBhYm91 dCB0aGlzIHByb2JsZW0gc3BhY2UgaW4gdGhlIGZpcnN0IHBsYWNlKS4NCg0KQ291bGQgc29tZW9u ZSBwcm9wb3NlIGluaXRpYWwgdGV4dCB0byBxdWFsaWZpZXMgdGhlIGN1cnJlbnQgIk1BWSBpZ25v cmUiIHN0YXRlbWVudD8NCg0KSSdtIGxvb2tpbmcgZm9yIHNvbWUgc29ydCBvZiBhcHBsaWNhYmls aXR5IGFuZCBwcmVyZXF1aXNpdGUgdGV4dCB0aGF0IGRlc2NyaWJlcyB0aGUNCnNpdHVhdGlvbnMg YW5kIGRlc2lnbiBhc3BlY3RzIHRoYXQgb3VnaHQgdG8gYmUgY29uc2lkZXJlZCBiZWZvcmUgYW4g aW1wbGVtZW50YXRpb24NCmRlY2lkZXMgdG8gaWdub3JlIEVDTi1DRSBtYXJrcy4gIA0KDQpUaGFu a3MsIC0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDb2xp biBQZXJraW5zIFttYWlsdG86Y3NwQGNzcGVya2lucy5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwg SnVuZSAxNSwgMjAxNiAxMTowNCBBTQ0KPiBUbzogQmxhY2ssIERhdmlkDQo+IENjOiBNYWdudXMg V2VzdGVybHVuZDsgSUVURiBBVlRDb3JlIFdHOyBydGN3ZWJAaWV0Zi5vcmc7IHRzdndnDQo+IFN1 YmplY3Q6IFJlOiBbQVZUQ09SRV0gW3RzdndnXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczogZHJh ZnQtaWV0Zi1hdnRjb3JlLXJ0cC0NCj4gY2lyY3VpdC1icmVha2Vycy0xNg0KPiANCj4gPiBPbiAx NCBKdW4gMjAxNiwgYXQgMTU6MjAsIEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT4g d3JvdGU6DQo+ID4NCj4gPj4gVGhpcyByZXN1bHRlZCBpbiBhbm90aGVyIGlzc3VlLCB0aGVyZSBh cmUgbm8gc3BlY2lmaWVkIG1hcmtpbmcgYmVoYXZpb3INCj4gPj4gdGhhdCB3ZSBkZWZpbmUgYW4g YXBwcm9wcmlhdGUgcmVzcG9uc2UgYmFzZWQgb24uIFdoZW4gc3VjaCBhIGJlaGF2aW9yIGlzDQo+ ID4+IGRlZmluZWQgb25lIGNhbiB1cGRhdGUgY2lyY3VpdCBicmVha2VyIHdpdGggYSB3ZWxsIGRl ZmluZWQgcmVzcG9uc2UgdG8NCj4gPj4gRUNOLUNFIG1hcmtzLiBTbyBkdWUgdG8gdGhlIGxhY2sg b2YgZGVmaW5lZCBiZWhhdmlvciB3ZSBkaWRuJ3Qgc2VlIGENCj4gPj4gcG9zc2liaWxpdHkgZm9y IHVzaW5nIFNIT1VMRCBOT1QsIGFzIHdlIGNhbid0IHBvaW50IHRvIHdoYXQgc2hvdWxkIGJlDQo+ ID4+IGltcGxlbWVudGVkLiBUaHVzIHdlIGNob3NlIHRvIHByb3Bvc2UgTUFZIGFzIGl0IHRoZW4g aXMgb3BlbiB0byB0aGUNCj4gPj4gaW1wbGVtZW50YXRpb24gaWYgdGhleSBjYW4gZmluZCBhIHdl bGwgd29ya2luZyByZXNwb25zZSBvciBjb21wbGV0ZWx5DQo+ID4+IGlnbm9yZSB0aGlzLg0KPiA+ DQo+ID4gTXkgcHJvYmxlbSBpcyB0aGF0IHRoZSBuZXcgIk1BWSIgc2VudGVuY2UgaXMgdW5xdWFs aWZpZWQ6DQo+ID4NCj4gPj4+ICAgR2l2ZW4gdGhlIGFib3ZlIGlzc3VlcywgaW1wbGVtZW50YXRp b25zIE1BWSBpZ25vcmUgRUNOLUNFIG1hcmtzIHdoZW4NCj4gPj4+ICAgZGV0ZXJtaW5pbmcgaWYg dGhlIGNvbmdlc3Rpb24gY2lyY3VpdCBicmVha2VyIHRyaWdnZXJzLA0KPiA+DQo+ID4gVGhhdCBp bnZpdGVzIGltcGxlbWVudGVycyB0byBpZ25vcmUgRUNOLUNFIG1hcmtzIHdpdGhvdXQgZ2l2aW5n IHRoaXMgdG9waWMgdGhlDQo+ID4gbGV2ZWwgb2YgY29uc2lkZXJhdGlvbiBhbnRpY2lwYXRlZCBp biB0aGlzIGRpc2N1c3Npb24gYW5kIGVsc2V3aGVyZSBpbiBTZWN0aW9uIDcuDQo+ID4gSWYgIlNI T1VMRCBOT1QiIGxhbmd1YWdlIGlzIHVud29ya2FibGUsIHBsZWFzZSBwcm9wb3NlIGFsdGVybmF0 ZSB0ZXh0IHRoYXQNCj4gPiBxdWFsaWZpZXMgYXBwbGljYWJpbGl0eSBvZiB0aGUgIk1BWSIgLSBl LmcuLCBvbmx5IGFmdGVyIGNhcmVmdWwgY29uc2lkZXJhdGlvbiBvZg0KPiA+IGV2ZXJ5dGhpbmcg dGhhdCB3ZSdyZSBub3cgZGlzY3Vzc2luZyBhbmQgdGhlIHJlc3Qgb2YgdGhlIHRleHQgaW4gU2Vj dGlvbiA3Lg0KPiA+DQo+ID4gSSBwcm9wb3NlZCAiU0hPVUxEIE5PVCIgYmVjYXVzZSBpdCBhcHBl YXIgdGhhdCB0aGUgb3JpZ2luYWwgUkZDIDIxMTkNCj4gZGVmaW5pdGlvbg0KPiA+IG9mIHRoYXQg dGVybSBpcyBhIGdvb2QgZml0IHRvIHRoaXMgc2l0dWF0aW9uOg0KPiA+DQo+ID4gNC4gU0hPVUxE IE5PVCAgIFRoaXMgcGhyYXNlLCBvciB0aGUgcGhyYXNlICJOT1QgUkVDT01NRU5ERUQiIG1lYW4g dGhhdA0KPiA+ICAgdGhlcmUgbWF5IGV4aXN0IHZhbGlkIHJlYXNvbnMgaW4gcGFydGljdWxhciBj aXJjdW1zdGFuY2VzIHdoZW4gdGhlDQo+ID4gICBwYXJ0aWN1bGFyIGJlaGF2aW9yIGlzIGFjY2Vw dGFibGUgb3IgZXZlbiB1c2VmdWwsIGJ1dCB0aGUgZnVsbA0KPiA+ICAgaW1wbGljYXRpb25zIHNo b3VsZCBiZSB1bmRlcnN0b29kIGFuZCB0aGUgY2FzZSBjYXJlZnVsbHkgd2VpZ2hlZA0KPiA+ICAg YmVmb3JlIGltcGxlbWVudGluZyBhbnkgYmVoYXZpb3IgZGVzY3JpYmVkIHdpdGggdGhpcyBsYWJl bC4NCj4gDQo+IFRoZSBpc3N1ZSB3aXRoIHNheWluZyDigJxpbXBsZW1lbnRhdGlvbnMgU0hPVUxE IE5PVCBpZ25vcmUgRUNOLUNFIG1hcmtz4oCdLCBpcw0KPiB0aGF0IGl0IGltcGxpZXMgdGhhdCB0 aGV5IHNob3VsZCByZXNwb25kIHRvIHRob3NlIG1hcmtzLiBIb3dldmVyLCB0aGUgb3V0Y29tZQ0K PiBvZiB0aGUgbG9uZyBkaXNjdXNzaW9uIHdlIGhhZCB3aXRoIE1pcmphIHdhcyB0aGF0IHRoZXJl 4oCZcyBubyBjb25zZW5zdXMgb24gd2hhdOKAmXMNCj4gdGhlIGNvcnJlY3QgcmVzcG9uc2UsIGFu ZCBjb25jZXJuIHRoYXQgaW1wbGVtZW50YXRpb25zIHBpY2tpbmcgdGhlIHdyb25nDQo+IGNob2lj ZSB3aWxsIGhpbmRlciB0aGUgZGVwbG95bWVudCBvZiBFQ04uDQo+IA0KPiANCj4gDQo+IC0tDQo+ IENvbGluIFBlcmtpbnMNCj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiANCj4gDQo+IA0KDQo= From nobody Thu Jun 16 05:45:08 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96CA12D5A4 for ; Thu, 16 Jun 2016 05:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELk_zCfhLfYf for ; Thu, 16 Jun 2016 05:45:06 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADF412D594 for ; Thu, 16 Jun 2016 05:45:06 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id j2so71334653vkg.2 for ; Thu, 16 Jun 2016 05:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=pXmZGlrC3VPpzjrIG/AQUxjdqXB+rgGOJNTAtB6P17Y=; b=FZnqZlkQ/ZkTDSwLOeFjubzMNv6gzJEnLgmsMRQCDVlb71DRoznkbcCgN+GNr84ko0 a8Bp/GtOyr7j7DStGF9ouOZPvhZyRVDiX0fvdFHoor7p+XzshvJxRgohnp5f+ewVMwrD OjtrAYlB7bvTzb9nzih+H6p89raNeFwZG2WJ3VtUHcAFBkG6bEY/AXu73Ld2vjniFNJH ywJzTJhBy2SnVome8TCAbioOEuxBYtpF6cDe5NRiykoDrs2xVu0MVzwzBzG9npMNBsIC pwngxAmEuke8KU/akwrYCPdCOX42GIekZr+54lx6wmUKHrvHF+AkfJOeJ1/Xy1TEzwkM E7gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pXmZGlrC3VPpzjrIG/AQUxjdqXB+rgGOJNTAtB6P17Y=; b=ic0ODFgGweJJTDbNMAPlWBML6/AM1Md97N2MlPsXkX6dGW2GyzOfyKsHP3DsGF0/5G qBprcT/hhU+fLQYpCM7qovW17WgPaEBf1q3/ZsLeYOFSWTRBVc4D/OjCXZd8owktDuab uDNfGu9cLPdTqBicdWpIE9Ngw8OO9Tbdz3EGVZ9f49ETXkjW1D1tMFxTBzL/CcanYDr6 Tw+VxT1jUSjko0ASzmbPK8ZCgmr9OYF8/TonxaUFUxszVSFmvdjUUu6rdH9hU7Cfl5YU hYtrLsSRMXfTNy0o7iItN4gWpCqtzBcnbuHMUbfygA0bqHfoPQn4onv/Lte1qizlAdZz LJng== X-Gm-Message-State: ALyK8tLrCZj3cmmQ3tiFsNc+Sg7Snnj57jQ3vcYJNlIAv8Afi21BoHJYzZOLHET/e/neq78BYS50SV+4MOeSPg== X-Received: by 10.31.7.78 with SMTP id 75mr573484vkh.74.1466081105685; Thu, 16 Jun 2016 05:45:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.198 with HTTP; Thu, 16 Jun 2016 05:44:46 -0700 (PDT) From: Bernard Aboba Date: Thu, 16 Jun 2016 08:44:46 -0400 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1143d2dc8447250535649b5c Archived-At: Subject: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jun 2016 12:45:08 -0000 --001a1143d2dc8447250535649b5c Content-Type: text/plain; charset=UTF-8 JSEP Section 5.2.1 talks about the initial offer and simulcasting in an RtpSender. However Section 5.3.1 (Initial Answers) does not describe simulcast in an RtpReceiver. Also, Section 5.9 (Applying an Answer) only talks about sending of simulcast streams, not receiving. Are we to conclude that JSEP only supports sending of simulcast, but that an RtpReceiver should only expect to receive a single RTP stream? --001a1143d2dc8447250535649b5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
JSEP Section 5.2.1 talks about the initial offer and simul= casting in an RtpSender. However Section 5.3.1 (Initial Answers) does not d= escribe simulcast in an RtpReceiver.=C2=A0 Also, Section 5.9 (Applying an = =C2=A0Answer) only talks about sending of simulcast streams, not receiving.= =C2=A0

Are we to conclude that JSEP only supports sendin= g of simulcast, but that an =C2=A0RtpReceiver should only expect to receive= a single RTP stream?=C2=A0
--001a1143d2dc8447250535649b5c-- From nobody Thu Jun 16 06:04:49 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24DD12D5F2 for ; Thu, 16 Jun 2016 06:04:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-7Yu-ZYOJut for ; Thu, 16 Jun 2016 06:04:46 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B67D12D5D7 for ; Thu, 16 Jun 2016 06:04:45 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id v137so41936460ywa.3 for ; Thu, 16 Jun 2016 06:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3QiUrLMwEkTxz9qRwaRkjYgu2QdQfoBzu21bxmfpMrE=; b=aN+EOw4GLH0d1FCpOvCGW61v4gAWWGIV0dZ2B/WSGRPYLxX67fP1cKSGVq7O5DCYpi yH5Wjav/+6BVonFPZUXZa07m4nTSCneMxmyfRwW1CGjeDP6nGn2uTOHE++cHkYkibjIo MZ+BKFle5epNei/q+At7cwUdknyxJBXImSQvgP8m207SDF/mXRQQMnV44u91xA5KGU0J DKFH88fIgBBSEnTPalE9BLTHyUNQtWtZfI3D7Lm3p9txJaYSXsaBVaaX+Gnk/EZC7hcs vJ2GUiG80ibhICZ4B9LgZQ6tR+/rJrVBSLs73/O8ThC7UZ6SsWoPy7ZfXA7aJ8Q5Doq7 iYVw== 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; bh=3QiUrLMwEkTxz9qRwaRkjYgu2QdQfoBzu21bxmfpMrE=; b=Shzp6lwviWQWfFWgKRUEB493noyil7Ni68c+u/AjY8+Btyam+JzruCJeZ33UEcraxw uisBbAf2Q4O0oJs3OVxmUQwVqm2bECtHbx48mAAL6pQFml3N7UaKBMC7U8Gdgw7xcX3Z CPwLIINecBIy59gmQfCALRgTtCTc8PFKV+GOGCtdK7my6XmYYouvL+rWU96EOCHIAM9O v48FP20UTgjyWSnAHnVD3R3kbwKjkYIcIH6jL4n5hQogJBtMKmJ2oTpDolsmotfPu5Tb PSFLVtNRPGpDYMd0E/D7H9VyspDUwiPULVhgt7R+4taStzrT6vShHqRsbr5W8isOZUxh r2cg== X-Gm-Message-State: ALyK8tLkjTALld+YPfoBfD5skLAbTSnFDABt0qiIdLDwkbqmZ4GDn8htbUem2eG8TuKemw== X-Received: by 10.13.203.68 with SMTP id n65mr650573ywd.262.1466082284397; Thu, 16 Jun 2016 06:04:44 -0700 (PDT) Received: from mail-yw0-f170.google.com (mail-yw0-f170.google.com. [209.85.161.170]) by smtp.gmail.com with ESMTPSA id i62sm5139875ywe.44.2016.06.16.06.04.43 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2016 06:04:44 -0700 (PDT) Received: by mail-yw0-f170.google.com with SMTP id v137so41936141ywa.3 for ; Thu, 16 Jun 2016 06:04:43 -0700 (PDT) X-Received: by 10.37.50.140 with SMTP id y134mr2323694yby.113.1466082283735; Thu, 16 Jun 2016 06:04:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.35.205 with HTTP; Thu, 16 Jun 2016 06:04:24 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Thu, 16 Jun 2016 06:04:24 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jun 2016 13:04:48 -0000 Are there specs that would actually allow JSEP to operate with simulcast in reception? Do we have anything that says how SSRCs should be sort-of ignored in the presence of an incoming RID and tells us what to do with sequence numbers in such scenarios? On Thu, Jun 16, 2016 at 5:44 AM, Bernard Aboba wrote: > JSEP Section 5.2.1 talks about the initial offer and simulcasting in an > RtpSender. However Section 5.3.1 (Initial Answers) does not describe > simulcast in an RtpReceiver. Also, Section 5.9 (Applying an Answer) only > talks about sending of simulcast streams, not receiving. > > Are we to conclude that JSEP only supports sending of simulcast, but that an > RtpReceiver should only expect to receive a single RTP stream? > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- https://jitsi.org From nobody Thu Jun 16 12:39:54 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D5512DBE5 for ; Thu, 16 Jun 2016 12:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LGLtKlsE0EU for ; Thu, 16 Jun 2016 12:39:51 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A38412DBE1 for ; Thu, 16 Jun 2016 12:39:51 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id c73so64144588qkg.2 for ; Thu, 16 Jun 2016 12:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/RMhBmKwq+bI8jskL6GBUf2TiYTRnNE0NOayXsFnyWY=; b=Iin3YZgHHK+wLrcZrguti1IFALkhjDOZ/y8fh7qasXnMuMYp54ePzDvI25xMI26P00 J71ZtlPitoWbeeGzcODTWcZHCU5F77FEIlKtk5Ypy9wa6FSt2sN3U+/1ZVdIWpQxCXIR 0BVUaM9UOg0RVrSnB894vsfzl7rtqvTrWMLa8bgYN05OpQiKqTsc3qfSp64guMEcVMrY +6d8cRN6QhgM7ZTi5HRG6XRliy2DNCwzvWrXiKGedH7fMN48SKEePspuqst2ze5RFJ9e 72igVHd5wX0fku+Ghehcsy8e20IqMGJgzaCGxkhaXk6enbTqaCIwvCHK1JCnGPzDksM3 q2oQ== 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; bh=/RMhBmKwq+bI8jskL6GBUf2TiYTRnNE0NOayXsFnyWY=; b=ddAgD2hhW4l35sOujfG2SaUBMLjnMHsLWH2MXe5lJjvPNtXjqKT5Ubw+FOrTEKGrj8 0sIhrZsuc5K46xi26qohYyQ72nP3LaXc+pExjbUpVaMhzAbk3E1M4d8PVFjAgy6BmoJh lRGWtf7tnVZaVnlmtNwMBxnNM3OkVOhOSdeOC6YtAp2CRb+hYpVJGSYvZ4gb8RxoGFjq O8lhZbOd1JaFIgutwaJY4FtTA2yZ32/dkLzFsFYcUbCD/VZ0RftF0RQ682EXkUcE4V3B cR21+ZIRIyqjTcct7wb0G91JsI4k25+i2L8AhVkVyLvXHdmqHQ/PFPfadaw0MHUzPVer O40Q== X-Gm-Message-State: ALyK8tKkWP3MIuYHzk2eeNEOgsHE5OC+YvfpTNVxkU6W4rHqZ91ruShBw1CbJG15Yr6pVjU/bu/7L4SIkD6Vv7yB X-Received: by 10.200.40.49 with SMTP id 46mr7020656qtq.79.1466105990366; Thu, 16 Jun 2016 12:39:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.189.195 with HTTP; Thu, 16 Jun 2016 12:39:10 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Thu, 16 Jun 2016 12:39:10 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a1140e406c29baa05356a66a3 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jun 2016 19:39:53 -0000 --001a1140e406c29baa05356a66a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 16, 2016 at 5:44 AM, Bernard Aboba wrote: > JSEP Section 5.2.1 talks about the initial offer and simulcasting in an > RtpSender. However Section 5.3.1 (Initial Answers) does not describe > simulcast in an RtpReceiver. Also, Section 5.9 (Applying an Answer) onl= y > talks about sending of simulcast streams, not receiving. > > Are we to conclude that JSEP only supports sending of simulcast, but that > an RtpReceiver should only expect to receive a single RTP stream? > > =E2=80=8BYes. The working group(s) decided that receiving simulcast was ou= t of scope for WebRTC 1.0.=E2=80=8B > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1140e406c29baa05356a66a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 16, 2016 at 5:44 AM, Bernard Aboba <bernard= .aboba@gmail.com> wrote:
JSEP Section 5.2.1 talks about the initial offer and simulca= sting in an RtpSender. However Section 5.3.1 (Initial Answers) does not des= cribe simulcast in an RtpReceiver.=C2=A0 Also, Section 5.9 (Applying an =C2= =A0Answer) only talks about sending of simulcast streams, not receiving.=C2= =A0

Are we to conclude that JSEP only supports sending o= f simulcast, but that an =C2=A0RtpReceiver should only expect to receive a = single RTP stream?=C2=A0


=E2=80=8BYes.=C2=A0 The working gro= up(s) decided that receiving simulcast was out of scope for WebRTC 1.0.=E2= =80=8B

=C2=A0
_____= __________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb


--001a1140e406c29baa05356a66a3-- From nobody Thu Jun 16 12:42:27 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154FC12DC0D for ; Thu, 16 Jun 2016 12:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhRsR7ADq2F1 for ; Thu, 16 Jun 2016 12:42:25 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4877B12DC13 for ; Thu, 16 Jun 2016 12:42:25 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id s186so64419814qkc.1 for ; Thu, 16 Jun 2016 12:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q7pcKp8h2uQhY+aayQN/M1zEcDFY4TxFwHynseRYc1I=; b=UhoC40MA7SCPZ6mHs+wSGiv9LfO2QTzFbMuUcOOeUh0Nd+YRvnSLa6ffQgrAvKJBNH z6P291nU0w96yL0eM3w/vSkfZ52IHskbflJ9GPweYtHf0fKMLa63KzYdz+w3d9LyT7ib Y6n1N8C3/D/DDc9P7aztmi/gh16ny4xrledrykIIpco9VyzsbLj/3/6KygsD2YHoS+HP SXgCryxpmg4TWfhbEFqdd1+TvW9HfWAHaJ5n464vH0JWOXHt/CTJLFgdO9qHV64MVf+0 YKu1/T41+VtHxxnwdcYTqe21QBd5eCn3Qb3MiibKNr/ALf5Klw7tXmKUv86POnMfG3os eIKg== 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; bh=Q7pcKp8h2uQhY+aayQN/M1zEcDFY4TxFwHynseRYc1I=; b=JzqHk8hWb2rYVVGViYRRPjlej3sK91KlUlTTItI1rUwRp6fvQUxSGm6fdST/xkAURS a5gYsgMPrJ/o7XOb5Ta6xrlDa0rN3mgT/ZurhymGOnp8nBFd3mqmb20VerNKzN7IPrNz OeNTZOrx2tW6XwmNlAkudrM1zntM9xD0SjZ7wAc1XsbCVJeg8REpC/+Q7tZkIed5BOQV c6qYE9KSxD35nA72VNhBLQLxijm+QZPVtE18rtFt8tOfdeP/uZYV+wYS4HNVkv1N3cbb HcsI+wj5Tu4VawVO2qIASPGSA3Yk6weGLLKMmI3t8H0WpQbMms1Fdh4tRwTGZagkmFuY UjWQ== X-Gm-Message-State: ALyK8tJjbAzaSERc44+b6ppTu3TOuM3WTEfD4zDiy2xRzHzySsomrGhLRDssnLCAOVAD5aBDdVSPhs6UprkFFWR6 X-Received: by 10.55.73.209 with SMTP id w200mr7318894qka.77.1466106144404; Thu, 16 Jun 2016 12:42:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.189.195 with HTTP; Thu, 16 Jun 2016 12:41:45 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Thu, 16 Jun 2016 12:41:45 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a114a6cf6f1090f05356a6fd7 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jun 2016 19:42:27 -0000 --001a114a6cf6f1090f05356a6fd7 Content-Type: text/plain; charset=UTF-8 ORTC allows it, so perhaps WebRTC NV will, but through direct method calls, which has nothing to do with JSEP. On Thu, Jun 16, 2016 at 6:04 AM, Emil Ivov wrote: > Are there specs that would actually allow JSEP to operate with > simulcast in reception? Do we have anything that says how SSRCs should > be sort-of ignored in the presence of an incoming RID and tells us > what to do with sequence numbers in such scenarios? > > On Thu, Jun 16, 2016 at 5:44 AM, Bernard Aboba > wrote: > > JSEP Section 5.2.1 talks about the initial offer and simulcasting in an > > RtpSender. However Section 5.3.1 (Initial Answers) does not describe > > simulcast in an RtpReceiver. Also, Section 5.9 (Applying an Answer) > only > > talks about sending of simulcast streams, not receiving. > > > > Are we to conclude that JSEP only supports sending of simulcast, but > that an > > RtpReceiver should only expect to receive a single RTP stream? > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > https://jitsi.org > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114a6cf6f1090f05356a6fd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ORTC allows it, so perhaps WebRTC NV will, but through = direct method calls, which has nothing to do with JSEP.


On Thu, Jun 16= , 2016 at 6:04 AM, Emil Ivov <emcho@jitsi.org> wrote:
Are there specs that would actually allow JSEP to= operate with
simulcast in reception? Do we have anything that says how SSRCs should
be sort-of ignored in the presence of an incoming RID and tells us
what to do with sequence numbers in such scenarios?

On Thu, Jun 16, 2016 at 5:44 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> JSEP Section 5.2.1 talks about the initial offer and simulcasting in a= n
> RtpSender. However Section 5.3.1 (Initial Answers) does not describe > simulcast in an RtpReceiver.=C2=A0 Also, Section 5.9 (Applying an=C2= =A0 Answer) only
> talks about sending of simulcast streams, not receiving.
>
> Are we to conclude that JSEP only supports sending of simulcast, but t= hat an
> RtpReceiver should only expect to receive a single RTP stream?
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >



--
https://= jitsi.org

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

--001a114a6cf6f1090f05356a6fd7-- From nobody Thu Jun 16 15:25:55 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E5612DB45; Thu, 16 Jun 2016 15:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_vB2Jp_0XzS; Thu, 16 Jun 2016 15:25:52 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 60D2012D11E; Thu, 16 Jun 2016 15:25:52 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 31E1BC9416; Thu, 16 Jun 2016 18:25:48 -0400 (EDT) Date: Thu, 16 Jun 2016 18:25:48 -0400 From: John Leslie To: "Black, David" Message-ID: <20160616222548.GB77166@verdi> References: 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: Cc: tsvwg , "rtcweb@ietf.org" , Colin Perkins , IETF AVTCore WG Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jun 2016 22:25:54 -0000 Black, David wrote: > > ... I view the current text as providing implementers with too much > latitude to ignore ECN-CE marks (e.g., because an implementer doesn't > want to think about this problem space in the first place). Understand, we have at least two proposals to make ECN-CE more frequent than packet drop would be for non-ECN packets: possibly substantially more frequent. Unless both are killed off, ECN-CE will show up frequently enough that closing the flow on ECN-CE would kill too many connections. If you want circuit-breaking on such connections, there are two ways: 1. convince the forwarding nodes to drop packets if their queue exceeds design capacity; or 2. require the sender to send enough not-ECN-capable packets so that our receiver will see enough packet-drops when a circuit-breaker should activate. (I prefer the first option; but I wouldn't object to the second.) There really isn't any way for our circuit-breaker to know _how_much_ more frequent the ECN-CE marks may be. :^( We _will_ be sorry if we allot the same frequency of CE packets as packet-drops to trigger the circuit-breaker. > Could someone propose initial text to qualifies the current "MAY ignore" > statement? Essentially, for the second option, you might propose text to the effect of: ] ] If too many ECN-CE packets are received, the sender SHOULD send some ] not-ECN-capable packets to determine whether enough packets along the ] path are being dropped to justify activating our circuit-breaker. I'm not enthusiastic about adding that; but it would resolve the issue. BTW, I'm 100% convinced that either of the proposals being considered in TSVWG could bring _substantial_ benefit to RTCWEB traffic. -- John Leslie From nobody Fri Jun 17 03:14:27 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB3912B037; Fri, 17 Jun 2016 03:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RZxOCMKxb0S; Fri, 17 Jun 2016 03:14:23 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4CD12B03F; Fri, 17 Jun 2016 03:14:23 -0700 (PDT) Received: from [130.209.247.112] (port=57386 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bDqn4-0003o3-Ox; Fri, 17 Jun 2016 11:14:20 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <20160616222548.GB77166@verdi> Date: Fri, 17 Jun 2016 11:14:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> References: <20160616222548.GB77166@verdi> To: John Leslie , "Black, David" X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 10:14:25 -0000 > On 16 Jun 2016, at 23:25, John Leslie wrote: >=20 > Black, David wrote: >>=20 >> ... I view the current text as providing implementers with too much >> latitude to ignore ECN-CE marks (e.g., because an implementer doesn't >> want to think about this problem space in the first place). I agree, but the argument is that doing so is less harmful than = deploying a circuit breaker that triggers too often when ECN is used.=20 I=E2=80=99m not sure I believe this argument, though, since it seems = that any new AQM that applies ECN marks much more often than at present = will have to consider backwards compatibility, to work with deployed TCP = (e.g., draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a = signal to use the new marking, while existing implementations set = ECT(0)). These compatibility mechanisms would seem to prevent the issues = with the circuit breaker too. > Understand, we have at least two proposals to make ECN-CE more = frequent > than packet drop would be for non-ECN packets: possibly substantially > more frequent. Unless both are killed off, ECN-CE will show up = frequently > enough that closing the flow on ECN-CE would kill too many = connections. >=20 > If you want circuit-breaking on such connections, there are two = ways: > 1. convince the forwarding nodes to drop packets if their queue = exceeds > design capacity; or > 2. require the sender to send enough not-ECN-capable packets so that = our > receiver will see enough packet-drops when a circuit-breaker should > activate. >=20 > (I prefer the first option; but I wouldn't object to the second.) >=20 > There really isn't any way for our circuit-breaker to know = _how_much_ > more frequent the ECN-CE marks may be. :^( This is a problem, both for the circuit breaker, and for the algorithms = being defined in RMCAT. We do need some understanding what the expected = marking rates are likely to be, so congestion control and circuit = breakers can be defined.=20 > We _will_ be sorry if we > allot the same frequency of CE packets as packet-drops to trigger the > circuit-breaker. >=20 >> Could someone propose initial text to qualifies the current "MAY = ignore" >> statement? >=20 > Essentially, for the second option, you might propose text to the > effect of: > ]=20 > ] If too many ECN-CE packets are received, the sender SHOULD send some > ] not-ECN-capable packets to determine whether enough packets along = the > ] path are being dropped to justify activating our circuit-breaker. >=20 > I=E2=80=99m not enthusiastic about adding that; but it would resolve = the issue. I=E2=80=99m not convinced this would work. The circuit breaker is = looking at long term trends, and in order to have enough not-ECT packets = to determine if it should trigger, you=E2=80=99d essentially have to run = without ECN for some seconds.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Fri Jun 17 07:04:15 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A9212D5CE; Fri, 17 Jun 2016 07:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFHsbW5608CS; Fri, 17 Jun 2016 07:04:10 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B82A12D660; Fri, 17 Jun 2016 07:04:09 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5HE3wXt025920 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Jun 2016 10:04:01 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5HE3wXt025920 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466172241; bh=1MdxT5kVQ5qEdUCAEs7ZwD4cBRI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=hA7wI5bFZq/YTELrEnIlkKgAt7v3xLCpCE/hVRLFTDWJonXKGB1n5859Hxlbln8uT r2jRBzS5UTrL5HzEOjk+DQECJATSxWtnNmQVztpQKXtw9wQVElPQfmLdu1PDndKL60 EUyVdw8nwzIMo37PtYOZHR3t/TAb0NZV1nFN3tBg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5HE3wXt025920 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd55.lss.emc.com (RSA Interceptor); Fri, 17 Jun 2016 10:03:29 -0400 Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5HE3nPx006854 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 17 Jun 2016 10:03:49 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0266.001; Fri, 17 Jun 2016 10:03:48 -0400 From: "Black, David" To: Colin Perkins , John Leslie Thread-Topic: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRyB4QG1826TWG60eO2TVJ3aRsKp/ttMoA///yYCA= Date: Fri, 17 Jun 2016 14:03:48 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> In-Reply-To: <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 14:04:12 -0000 Q29saW4sDQoNCj4gPj4gLi4uICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBwcm92aWRpbmcg aW1wbGVtZW50ZXJzIHdpdGggdG9vIG11Y2gNCj4gPj4gbGF0aXR1ZGUgdG8gaWdub3JlIEVDTi1D RSBtYXJrcyAoZS5nLiwgYmVjYXVzZSBhbiBpbXBsZW1lbnRlciBkb2Vzbid0DQo+ID4+IHdhbnQg dG8gdGhpbmsgYWJvdXQgdGhpcyBwcm9ibGVtIHNwYWNlIGluIHRoZSBmaXJzdCBwbGFjZSkuDQo+ IA0KPiBJIGFncmVlLCBidXQgdGhlIGFyZ3VtZW50IGlzIHRoYXQgZG9pbmcgc28gaXMgbGVzcyBo YXJtZnVsIHRoYW4gZGVwbG95aW5nIGEgY2lyY3VpdA0KPiBicmVha2VyIHRoYXQgdHJpZ2dlcnMg dG9vIG9mdGVuIHdoZW4gRUNOIGlzIHVzZWQuDQo+IA0KPiBJ4oCZbSBub3Qgc3VyZSBJIGJlbGll dmUgdGhpcyBhcmd1bWVudCwgdGhvdWdoLCBzaW5jZSBpdCBzZWVtcyB0aGF0IGFueSBuZXcgQVFN DQo+IHRoYXQgYXBwbGllcyBFQ04gbWFya3MgbXVjaCBtb3JlIG9mdGVuIHRoYW4gYXQgcHJlc2Vu dCB3aWxsIGhhdmUgdG8gY29uc2lkZXINCj4gYmFja3dhcmRzIGNvbXBhdGliaWxpdHksIHRvIHdv cmsgd2l0aCBkZXBsb3llZCBUQ1AgKGUuZy4sIGRyYWZ0LWJyaXNjb2UtdHN2d2ctDQo+IGFxbS10 Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVzZXMgRUNUKDEpIGFzIGEgc2lnbmFsIHRvIHVzZSB0aGUg bmV3IG1hcmtpbmcsDQo+IHdoaWxlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDAp KS4gVGhlc2UgY29tcGF0aWJpbGl0eSBtZWNoYW5pc21zDQo+IHdvdWxkIHNlZW0gdG8gcHJldmVu dCB0aGUgaXNzdWVzIHdpdGggdGhlIGNpcmN1aXQgYnJlYWtlciB0b28uDQoNClRoYXQgcm91Z2hs eSBtYXRjaGVzIG15IGxpbmUgb2YgdGhpbmtpbmcsIGFuZCBJJ2xsIG9ic2VydmUgdGhhdCB0aGUg b3JpZ2luYWwgRENUQ1ANCnByb3RvY29sIGRlc2lnbiB0aGF0IHVzZWQgbW9yZSBhZ2dyZXNzaXZl IEVDTi1DRSBtYXJraW5nIHdhcyBvbmx5IHNhZmUgZm9yDQpDb250cm9sbGVkIEVudmlyb25tZW50 IGRlcGxveW1lbnRzLiAgIFNlZSB0aGUgVFNWV0cgcmZjNTQwNWJpcyBkcmFmdCBmb3IgdGhlDQpk ZWZpbml0aW9uIG9mIENvbnRyb2xsZWQgRW52aXJvbm1lbnQsIGFuZCBpZ25vcmUgdGhlIGZhY3Qg dGhhdCB0aGUgcmZjNTQwNWJpcw0KZHJhZnQgaXMgYSBVRFAgZHJhZnQgLSB0aGlzIGRlZmluaXRp b24gaXMgbW9yZSBicm9hZGx5IGFwcGxpY2FibGUuDQoNCkdvaW5nIGJhY2sgb3ZlciBTZWN0aW9u IDcgaW4gdGhpcyBhdnRjb3JlIGRyYWZ0LCBteSB2aWV3cyBhcmU6DQoNCltBXSBOb25lIG9mIHRo ZXNlIGRyYWZ0cyBqdXN0aWZ5IGEgIk1BWSBpZ25vcmUiIHJlc3BvbnNlIHRvIEVDTi1DRSBtYXJr czoNCgktIGRyYWZ0LWtoYWRlbWktdGNwbS1hbHRlcm5hdGl2ZWJhY2tvZmYtZWNuDQoJLSBkcmFm dC1pZXRmLXJtY2F0LW5hZGENCgktIGRyYWZ0LWlldGYtcm1jYXQtc2NyZWFtLWNjDQoNCltCXSBJ biBsaW5lIHdpdGggQ29saW4ncyBjb21tZW50IG9uIHRoZSBMNFMgZHJhZnQsIEkgdGhpbmsgaXQn cyBpbmN1bWJlbnQgb24NCnRoZSBhdXRob3JzIG9mIGRyYWZ0LWJyaXNjb2UtYXFtLWR1YWxxLWNv dXBsZWQgdG8gZmlndXJlIG91dCBob3cgdGhhdCB3aWxsDQpjb2V4aXN0IChvciBhdm9pZCkgZGVw bG95ZWQgVENQLCBhbmQgdGhpcyBhdnRjb3JlIGRyYWZ0IG91Z2h0IG5vdCB0byBiZQ0KdHJ5aW5n IHRvIHByZWp1ZGdlIHdoYXQgd2lsbCBiZSBkb25lIHRoZXJlLg0KDQpTbywgSSBkb24ndCB0aGlu ayB0aGUgY3VycmVudCB0ZXh0IGluIFNlY3Rpb24gNyBoYXMganVzdGlmaWVkIHRoZSB1bmZldHRl cmVkDQoiaW1wbGVtZW50YXRpb25zIE1BWSBpZ25vcmUgRUNOLUNFIG1hcmtzIiB0ZXh0LCBhcyBp Z25vcmluZyB0aG9zZSBtYXJrcw0KaXMgbm90IGNvbnNpc3RlbnQgd2l0aCBhbnkgb2YgdGhlIGZv dXIgY2l0ZWQgZHJhZnRzLg0KDQpJbiBtb3JlIGRldGFpbCwgSSB0aGluayBtYWtpbmcgY2hhbmdl cyB0byBub3JtYXRpdmUgcmVxdWlyZW1lbnRzIGhlcmUgYmFzZWQNCm9uIFtCXSBpcyBwcmVtYXR1 cmUsIGFuZCBJIHdvdWxkIGhvcGUgdGhhdCB0aGUgcm1jYXQgV0cgY291bGQgYmUgZW5jb3VyYWdl ZA0KdG8gY29uc2lkZXIgdGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIgaW4gaXRzIGNvbmdlc3Rpb24g Y29udHJvbCBkcmFmdHMsIGFzIHRob3NlIENDDQptZWNoYW5pc21zIGFyZSByZWxhdGVkIHRvIHRo ZSBjaXJjdWl0IGJyZWFrZXIgbWVjaGFuaXNtLCBoZW5jZSBsaWtlbHkNCnRvIGJlIGluIHJlbGF0 ZWQgYXJlYXMgb2YgYW4gUlRQIGltcGxlbWVudGF0aW9uLg0KDQpUaGF0IGxlYXZlcyBkcmFmdC1r aGFkZW1pLXRjcG0tYWx0ZXJuYXRpdmViYWNrb2ZmLWVjbiwgd2hpY2ggVFNWV0cNCndpbGwgYmUg bG9va2luZyBhdCBpbiBCZXJsaW4uICBJZiBhIG5vcm1hdGl2ZSBzdGF0ZW1lbnQgYWJvdXQgRUNO LUNFIHJlYWN0aW9uDQppcyBnb2luZyB0byByZXN0IG9uIHRoYXQgZHJhZnQsIHRoZW4gdGhlIHJl ZmVyZW5jZSB0byB0aGF0IGRyYWZ0IHNob3VsZCBiZQ0Kbm9ybWF0aXZlLiAgU29tZXRoaW5nIGFi b3V0IGRvaW5nIHRoYXQgc3RyaWtlcyBtZSBhcyBwcmVtYXR1cmUgLi4uDQoNCkkgcmVhbGl6ZSB0 aGF0IHdlJ3JlIHRyeWluZyB0byBwcmVkaWN0IGFuZCBhY2NvbW1vZGF0ZSB0aGUgZnV0dXJlLCB3 aGljaA0KaXMgYW4gaW1wcmVjaXNlIHVuZGVydGFraW5nIGF0IGJlc3QuICAgQXMgYW4gYWx0ZXJu YXRpdmUgdG8gdGhlIGN1cnJlbnQgdGV4dCwNCndvdWxkIGl0IGJlIHJlYXNvbmFibGUgdG8gc2F5 ICh3aXRob3V0IGFueSBSRkMgMjExOSBrZXl3b3JkcykgdGhhdCB0aGUNCmJlc3QgY3VycmVudCBn dWlkYW5jZSBpcyBzdGlsbCB0byB0cmVhdCBFQ04tQ0UgbWFya3MgYXMgaW5kaWNhdGluZyBkcm9w cywNCndpdGggYSB3YXJuaW5nIHRoYXQgdGhlcmUgaXMgYSBnb29kIHBvc3NpYmlsaXR5IG9mIHRo aXMgY2hhbmdpbmcgaW4gdGhlDQpuZWFyIGZ1dHVyZSBkdWUgdG8gYWxsIG9mIHRoZSB3b3JrIGlu IHByb2dyZXNzIGNpdGVkIGluIFNlY3Rpb24gNz8NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ29saW4gUGVya2lucyBbbWFpbHRvOmNz cEBjc3BlcmtpbnMub3JnXQ0KPiBTZW50OiBGcmlkYXksIEp1bmUgMTcsIDIwMTYgNjoxNCBBTQ0K PiBUbzogSm9obiBMZXNsaWU7IEJsYWNrLCBEYXZpZA0KPiBDYzogcnRjd2ViQGlldGYub3JnOyBJ RVRGIEFWVENvcmUgV0c7IHRzdndnDQo+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBbQVZUQ09SRV0g W3RzdndnXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczogZHJhZnQtaWV0Zi0NCj4gYXZ0Y29yZS1y dHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiANCj4gDQo+ID4gT24gMTYgSnVuIDIwMTYsIGF0IDIz OjI1LCBKb2huIExlc2xpZSA8am9obkBqbGMubmV0PiB3cm90ZToNCj4gPg0KPiA+IEJsYWNrLCBE YXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT4gd3JvdGU6DQo+ID4+DQo+ID4+IC4uLiAgSSB2aWV3 IHRoZSBjdXJyZW50IHRleHQgYXMgcHJvdmlkaW5nIGltcGxlbWVudGVycyB3aXRoIHRvbyBtdWNo DQo+ID4+IGxhdGl0dWRlIHRvIGlnbm9yZSBFQ04tQ0UgbWFya3MgKGUuZy4sIGJlY2F1c2UgYW4g aW1wbGVtZW50ZXIgZG9lc24ndA0KPiA+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJvYmxl bSBzcGFjZSBpbiB0aGUgZmlyc3QgcGxhY2UpLg0KPiANCj4gSSBhZ3JlZSwgYnV0IHRoZSBhcmd1 bWVudCBpcyB0aGF0IGRvaW5nIHNvIGlzIGxlc3MgaGFybWZ1bCB0aGFuIGRlcGxveWluZyBhIGNp cmN1aXQNCj4gYnJlYWtlciB0aGF0IHRyaWdnZXJzIHRvbyBvZnRlbiB3aGVuIEVDTiBpcyB1c2Vk Lg0KPiANCj4gSeKAmW0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMgYXJndW1lbnQsIHRob3VnaCwg c2luY2UgaXQgc2VlbXMgdGhhdCBhbnkgbmV3IEFRTQ0KPiB0aGF0IGFwcGxpZXMgRUNOIG1hcmtz IG11Y2ggbW9yZSBvZnRlbiB0aGFuIGF0IHByZXNlbnQgd2lsbCBoYXZlIHRvIGNvbnNpZGVyDQo+ IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCB0byB3b3JrIHdpdGggZGVwbG95ZWQgVENQIChlLmcu LCBkcmFmdC1icmlzY29lLXRzdndnLQ0KPiBhcW0tdGNwbS1ybWNhdC1sNHMtcHJvYmxlbSB1c2Vz IEVDVCgxKSBhcyBhIHNpZ25hbCB0byB1c2UgdGhlIG5ldyBtYXJraW5nLA0KPiB3aGlsZSBleGlz dGluZyBpbXBsZW1lbnRhdGlvbnMgc2V0IEVDVCgwKSkuIFRoZXNlIGNvbXBhdGliaWxpdHkgbWVj aGFuaXNtcw0KPiB3b3VsZCBzZWVtIHRvIHByZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJj dWl0IGJyZWFrZXIgdG9vLg0KPiANCj4gPiAgIFVuZGVyc3RhbmQsIHdlIGhhdmUgYXQgbGVhc3Qg dHdvIHByb3Bvc2FscyB0byBtYWtlIEVDTi1DRSBtb3JlIGZyZXF1ZW50DQo+ID4gdGhhbiBwYWNr ZXQgZHJvcCB3b3VsZCBiZSBmb3Igbm9uLUVDTiBwYWNrZXRzOiBwb3NzaWJseSBzdWJzdGFudGlh bGx5DQo+ID4gbW9yZSBmcmVxdWVudC4gVW5sZXNzIGJvdGggYXJlIGtpbGxlZCBvZmYsIEVDTi1D RSB3aWxsIHNob3cgdXAgZnJlcXVlbnRseQ0KPiA+IGVub3VnaCB0aGF0IGNsb3NpbmcgdGhlIGZs b3cgb24gRUNOLUNFIHdvdWxkIGtpbGwgdG9vIG1hbnkgY29ubmVjdGlvbnMuDQo+ID4NCj4gPiAg IElmIHlvdSB3YW50IGNpcmN1aXQtYnJlYWtpbmcgb24gc3VjaCBjb25uZWN0aW9ucywgdGhlcmUg YXJlIHR3byB3YXlzOg0KPiA+IDEuIGNvbnZpbmNlIHRoZSBmb3J3YXJkaW5nIG5vZGVzIHRvIGRy b3AgcGFja2V0cyBpZiB0aGVpciBxdWV1ZSBleGNlZWRzDQo+ID4gICBkZXNpZ24gY2FwYWNpdHk7 IG9yDQo+ID4gMi4gcmVxdWlyZSB0aGUgc2VuZGVyIHRvIHNlbmQgZW5vdWdoIG5vdC1FQ04tY2Fw YWJsZSBwYWNrZXRzIHNvIHRoYXQgb3VyDQo+ID4gICByZWNlaXZlciB3aWxsIHNlZSBlbm91Z2gg cGFja2V0LWRyb3BzIHdoZW4gYSBjaXJjdWl0LWJyZWFrZXIgc2hvdWxkDQo+ID4gICBhY3RpdmF0 ZS4NCj4gPg0KPiA+ICAgKEkgcHJlZmVyIHRoZSBmaXJzdCBvcHRpb247IGJ1dCBJIHdvdWxkbid0 IG9iamVjdCB0byB0aGUgc2Vjb25kLikNCj4gPg0KPiA+ICAgVGhlcmUgcmVhbGx5IGlzbid0IGFu eSB3YXkgZm9yIG91ciBjaXJjdWl0LWJyZWFrZXIgdG8ga25vdyBfaG93X211Y2hfDQo+ID4gbW9y ZSBmcmVxdWVudCB0aGUgRUNOLUNFIG1hcmtzIG1heSBiZS4gOl4oDQo+IA0KPiBUaGlzIGlzIGEg cHJvYmxlbSwgYm90aCBmb3IgdGhlIGNpcmN1aXQgYnJlYWtlciwgYW5kIGZvciB0aGUgYWxnb3Jp dGhtcyBiZWluZw0KPiBkZWZpbmVkIGluIFJNQ0FULiBXZSBkbyBuZWVkIHNvbWUgdW5kZXJzdGFu ZGluZyB3aGF0IHRoZSBleHBlY3RlZCBtYXJraW5nDQo+IHJhdGVzIGFyZSBsaWtlbHkgdG8gYmUs IHNvIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgY2lyY3VpdCBicmVha2VycyBjYW4gYmUgZGVmaW5l ZC4NCj4gDQo+ID4gV2UgX3dpbGxfIGJlIHNvcnJ5IGlmIHdlDQo+ID4gYWxsb3QgdGhlIHNhbWUg ZnJlcXVlbmN5IG9mIENFIHBhY2tldHMgYXMgcGFja2V0LWRyb3BzIHRvIHRyaWdnZXIgdGhlDQo+ ID4gY2lyY3VpdC1icmVha2VyLg0KPiA+DQo+ID4+IENvdWxkIHNvbWVvbmUgcHJvcG9zZSBpbml0 aWFsIHRleHQgdG8gcXVhbGlmaWVzIHRoZSBjdXJyZW50ICJNQVkgaWdub3JlIg0KPiA+PiBzdGF0 ZW1lbnQ/DQo+ID4NCj4gPiAgIEVzc2VudGlhbGx5LCBmb3IgdGhlIHNlY29uZCBvcHRpb24sIHlv dSBtaWdodCBwcm9wb3NlIHRleHQgdG8gdGhlDQo+ID4gZWZmZWN0IG9mOg0KPiA+IF0NCj4gPiBd IElmIHRvbyBtYW55IEVDTi1DRSBwYWNrZXRzIGFyZSByZWNlaXZlZCwgdGhlIHNlbmRlciBTSE9V TEQgc2VuZCBzb21lDQo+ID4gXSBub3QtRUNOLWNhcGFibGUgcGFja2V0cyB0byBkZXRlcm1pbmUg d2hldGhlciBlbm91Z2ggcGFja2V0cyBhbG9uZyB0aGUNCj4gPiBdIHBhdGggYXJlIGJlaW5nIGRy b3BwZWQgdG8ganVzdGlmeSBhY3RpdmF0aW5nIG91ciBjaXJjdWl0LWJyZWFrZXIuDQo+ID4NCj4g PiAgIEnigJltIG5vdCBlbnRodXNpYXN0aWMgYWJvdXQgYWRkaW5nIHRoYXQ7IGJ1dCBpdCB3b3Vs ZCByZXNvbHZlIHRoZSBpc3N1ZS4NCj4gDQo+IEnigJltIG5vdCBjb252aW5jZWQgdGhpcyB3b3Vs ZCB3b3JrLiBUaGUgY2lyY3VpdCBicmVha2VyIGlzIGxvb2tpbmcgYXQgbG9uZyB0ZXJtDQo+IHRy ZW5kcywgYW5kIGluIG9yZGVyIHRvIGhhdmUgZW5vdWdoIG5vdC1FQ1QgcGFja2V0cyB0byBkZXRl cm1pbmUgaWYgaXQgc2hvdWxkDQo+IHRyaWdnZXIsIHlvdeKAmWQgZXNzZW50aWFsbHkgaGF2ZSB0 byBydW4gd2l0aG91dCBFQ04gZm9yIHNvbWUgc2Vjb25kcy4NCj4gDQo+IC0tDQo+IENvbGluIFBl cmtpbnMNCj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiANCj4gDQo+IA0KDQo= From nobody Fri Jun 17 08:02:47 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF8112D6A1; Fri, 17 Jun 2016 08:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOLuHtqOyGy4; Fri, 17 Jun 2016 08:02:39 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC4112D686; Fri, 17 Jun 2016 08:02:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E0759D9305; Fri, 17 Jun 2016 17:02:37 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FHFcyi7WHAnM; Fri, 17 Jun 2016 17:02:37 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8C04FD9304; Fri, 17 Jun 2016 17:02:37 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 17 Jun 2016 17:02:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> To: "Black, David" , Magnus Westerlund , Colin Perkins X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 15:02:42 -0000 +1 to not use normative language here. However, please note that having a high level of ECN-CE marks (without = any losses) means that all packets were received correctly. This = situation can even occurs without high delays (depending on the AQM = used), which would just mean the services works perfectly. Therefore for = me CE marks are a perfect input signal for a congestion control loop = (where the AQM tell the sender to take action - whatever that means). = But I=E2=80=99m less concerned than David about eventually ignoring it = for circuit breaker. In addition one point on something Magnus wrote earlier: "If the implementation only have circuit breaker, i.e. no full fledged = congestion controller and uses ECN, they can in worst case drive the = buffer into the overload regime where it starts dropping packets. =E2=80=9E= I=E2=80=99m not sure about this case. ECN is an input signal for = congestion control. If you don=E2=80=99t use congestion control but only = a circuit breaker, you should probably not enable ECN. At least it not = clear to me why you would enable it, and it's definitely not conform to = the ECN spec. Probably we should say something about this in the = draft...? Mirja > Am 17.06.2016 um 16:03 schrieb Black, David : >=20 > Colin, >=20 >>>> ... I view the current text as providing implementers with too = much >>>> latitude to ignore ECN-CE marks (e.g., because an implementer = doesn't >>>> want to think about this problem space in the first place). >>=20 >> I agree, but the argument is that doing so is less harmful than = deploying a circuit >> breaker that triggers too often when ECN is used. >>=20 >> I=E2=80=99m not sure I believe this argument, though, since it seems = that any new AQM >> that applies ECN marks much more often than at present will have to = consider >> backwards compatibility, to work with deployed TCP (e.g., = draft-briscoe-tsvwg- >> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new = marking, >> while existing implementations set ECT(0)). These compatibility = mechanisms >> would seem to prevent the issues with the circuit breaker too. >=20 > That roughly matches my line of thinking, and I'll observe that the = original DCTCP > protocol design that used more aggressive ECN-CE marking was only safe = for > Controlled Environment deployments. See the TSVWG rfc5405bis draft = for the > definition of Controlled Environment, and ignore the fact that the = rfc5405bis > draft is a UDP draft - this definition is more broadly applicable. >=20 > Going back over Section 7 in this avtcore draft, my views are: >=20 > [A] None of these drafts justify a "MAY ignore" response to ECN-CE = marks: > - draft-khademi-tcpm-alternativebackoff-ecn > - draft-ietf-rmcat-nada > - draft-ietf-rmcat-scream-cc >=20 > [B] In line with Colin's comment on the L4S draft, I think it's = incumbent on > the authors of draft-briscoe-aqm-dualq-coupled to figure out how that = will > coexist (or avoid) deployed TCP, and this avtcore draft ought not to = be > trying to prejudge what will be done there. >=20 > So, I don't think the current text in Section 7 has justified the = unfettered > "implementations MAY ignore ECN-CE marks" text, as ignoring those = marks > is not consistent with any of the four cited drafts. >=20 > In more detail, I think making changes to normative requirements here = based > on [B] is premature, and I would hope that the rmcat WG could be = encouraged > to consider the RTP circuit breaker in its congestion control drafts, = as those CC > mechanisms are related to the circuit breaker mechanism, hence likely > to be in related areas of an RTP implementation. >=20 > That leaves draft-khademi-tcpm-alternativebackoff-ecn, which TSVWG > will be looking at in Berlin. If a normative statement about ECN-CE = reaction > is going to rest on that draft, then the reference to that draft = should be > normative. Something about doing that strikes me as premature ... >=20 > I realize that we're trying to predict and accommodate the future, = which > is an imprecise undertaking at best. As an alternative to the = current text, > would it be reasonable to say (without any RFC 2119 keywords) that the > best current guidance is still to treat ECN-CE marks as indicating = drops, > with a warning that there is a good possibility of this changing in = the > near future due to all of the work in progress cited in Section 7? >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Friday, June 17, 2016 6:14 AM >> To: John Leslie; Black, David >> Cc: rtcweb@ietf.org; IETF AVTCore WG; tsvwg >> Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: = draft-ietf- >> avtcore-rtp-circuit-breakers-16 >>=20 >>=20 >>> On 16 Jun 2016, at 23:25, John Leslie wrote: >>>=20 >>> Black, David wrote: >>>>=20 >>>> ... I view the current text as providing implementers with too = much >>>> latitude to ignore ECN-CE marks (e.g., because an implementer = doesn't >>>> want to think about this problem space in the first place). >>=20 >> I agree, but the argument is that doing so is less harmful than = deploying a circuit >> breaker that triggers too often when ECN is used. >>=20 >> I=E2=80=99m not sure I believe this argument, though, since it seems = that any new AQM >> that applies ECN marks much more often than at present will have to = consider >> backwards compatibility, to work with deployed TCP (e.g., = draft-briscoe-tsvwg- >> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new = marking, >> while existing implementations set ECT(0)). These compatibility = mechanisms >> would seem to prevent the issues with the circuit breaker too. >>=20 >>> Understand, we have at least two proposals to make ECN-CE more = frequent >>> than packet drop would be for non-ECN packets: possibly = substantially >>> more frequent. Unless both are killed off, ECN-CE will show up = frequently >>> enough that closing the flow on ECN-CE would kill too many = connections. >>>=20 >>> If you want circuit-breaking on such connections, there are two = ways: >>> 1. convince the forwarding nodes to drop packets if their queue = exceeds >>> design capacity; or >>> 2. require the sender to send enough not-ECN-capable packets so that = our >>> receiver will see enough packet-drops when a circuit-breaker should >>> activate. >>>=20 >>> (I prefer the first option; but I wouldn't object to the second.) >>>=20 >>> There really isn't any way for our circuit-breaker to know = _how_much_ >>> more frequent the ECN-CE marks may be. :^( >>=20 >> This is a problem, both for the circuit breaker, and for the = algorithms being >> defined in RMCAT. We do need some understanding what the expected = marking >> rates are likely to be, so congestion control and circuit breakers = can be defined. >>=20 >>> We _will_ be sorry if we >>> allot the same frequency of CE packets as packet-drops to trigger = the >>> circuit-breaker. >>>=20 >>>> Could someone propose initial text to qualifies the current "MAY = ignore" >>>> statement? >>>=20 >>> Essentially, for the second option, you might propose text to the >>> effect of: >>> ] >>> ] If too many ECN-CE packets are received, the sender SHOULD send = some >>> ] not-ECN-capable packets to determine whether enough packets along = the >>> ] path are being dropped to justify activating our circuit-breaker. >>>=20 >>> I=E2=80=99m not enthusiastic about adding that; but it would = resolve the issue. >>=20 >> I=E2=80=99m not convinced this would work. The circuit breaker is = looking at long term >> trends, and in order to have enough not-ECT packets to determine if = it should >> trigger, you=E2=80=99d essentially have to run without ECN for some = seconds. >>=20 >> -- >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jun 17 23:22:44 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7735C12D177; Fri, 17 Jun 2016 23:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIkQy38WV_Lk; Fri, 17 Jun 2016 23:22:39 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0CA12B049; Fri, 17 Jun 2016 23:22:39 -0700 (PDT) Received: from [192.168.2.19] (host-2-102-74-50.as13285.net [2.102.74.50]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 928291B001B5; Sat, 18 Jun 2016 07:22:36 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Sat, 18 Jun 2016 07:22:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= Archived-At: Cc: tsvwg , "Black, David" , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jun 2016 06:22:42 -0000 I think we SHOULD NOT recommend to use ECN marks as inputs to a CB. See belo= w: > On 17 Jun 2016, at 16:02, Mirja K=C3=BChlewind wrote: >=20 > +1 to not use normative language here. >=20 > However, please note that having a high level of ECN-CE marks (without any= losses) means that all packets were received correctly. This situation can e= ven occurs without high delays (depending on the AQM used), which would just= mean the services works perfectly. Therefore for me CE marks are a perfect i= nput signal for a congestion control loop (where the AQM tell the sender to t= ake action - whatever that means). We may in future figure out ways to do this to detect significant failure us= ing a rate adaptive transport and ECN e.g. Observing 100% CE marks or somet= hing, for an RTP flow that is trying to send well below its peak rate decide= d by CC -- but I think this is speculating at an algorithm and adding detail= s here is not a good idea. Especially as AQM continues to evolve. > But I=E2=80=99m less concerned than David about eventually ignoring it for= circuit breaker. >=20 Agree. Loss is the measurement that a CB MUST respond to. > In addition one point on something Magnus wrote earlier: > "If the implementation only have circuit breaker, i.e. no full fledged con= gestion controller and uses ECN, they can in worst case drive the buffer int= o the overload regime where it starts dropping packets. =E2=80=9E >=20 > I=E2=80=99m not sure about this case. ECN is an input signal for congestio= n control. If you don=E2=80=99t use congestion control but only a circuit br= eaker, you should probably not enable ECN. At least it not clear to me why y= ou would enable it, and it's definitely not conform to the ECN spec. Probabl= y we should say something about this in the draft...? >=20 Agree, enabling ECN without a responsive CC is going to lead to trouble. > Mirja >=20 Gorry >> Am 17.06.2016 um 16:03 schrieb Black, David : >>=20 >> Colin, >>=20 >>>>> ... I view the current text as providing implementers with too much >>>>> latitude to ignore ECN-CE marks (e.g., because an implementer doesn't >>>>> want to think about this problem space in the first place). >>>=20 >>> I agree, but the argument is that doing so is less harmful than deployin= g a circuit >>> breaker that triggers too often when ECN is used. >>>=20 >>> I=E2=80=99m not sure I believe this argument, though, since it seems tha= t any new AQM >>> that applies ECN marks much more often than at present will have to cons= ider >>> backwards compatibility, to work with deployed TCP (e.g., draft-briscoe-= tsvwg- >>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new markin= g, >>> while existing implementations set ECT(0)). These compatibility mechanis= ms >>> would seem to prevent the issues with the circuit breaker too. >>=20 >> That roughly matches my line of thinking, and I'll observe that the origi= nal DCTCP >> protocol design that used more aggressive ECN-CE marking was only safe fo= r >> Controlled Environment deployments. See the TSVWG rfc5405bis draft for t= he >> definition of Controlled Environment, and ignore the fact that the rfc540= 5bis >> draft is a UDP draft - this definition is more broadly applicable. >>=20 >> Going back over Section 7 in this avtcore draft, my views are: >>=20 >> [A] None of these drafts justify a "MAY ignore" response to ECN-CE marks:= >> - draft-khademi-tcpm-alternativebackoff-ecn >> - draft-ietf-rmcat-nada >> - draft-ietf-rmcat-scream-cc >>=20 >> [B] In line with Colin's comment on the L4S draft, I think it's incumbent= on >> the authors of draft-briscoe-aqm-dualq-coupled to figure out how that wil= l >> coexist (or avoid) deployed TCP, and this avtcore draft ought not to be >> trying to prejudge what will be done there. >>=20 >> So, I don't think the current text in Section 7 has justified the unfette= red >> "implementations MAY ignore ECN-CE marks" text, as ignoring those marks >> is not consistent with any of the four cited drafts. >>=20 >> In more detail, I think making changes to normative requirements here bas= ed >> on [B] is premature, and I would hope that the rmcat WG could be encourag= ed >> to consider the RTP circuit breaker in its congestion control drafts, as t= hose CC >> mechanisms are related to the circuit breaker mechanism, hence likely >> to be in related areas of an RTP implementation. >>=20 >> That leaves draft-khademi-tcpm-alternativebackoff-ecn, which TSVWG >> will be looking at in Berlin. If a normative statement about ECN-CE reac= tion >> is going to rest on that draft, then the reference to that draft should b= e >> normative. Something about doing that strikes me as premature ... >>=20 >> I realize that we're trying to predict and accommodate the future, which >> is an imprecise undertaking at best. As an alternative to the current t= ext, >> would it be reasonable to say (without any RFC 2119 keywords) that the >> best current guidance is still to treat ECN-CE marks as indicating drops,= >> with a warning that there is a good possibility of this changing in the >> near future due to all of the work in progress cited in Section 7? >>=20 >> Thanks, --David >>=20 >>> -----Original Message----- >>> From: Colin Perkins [mailto:csp@csperkins.org] >>> Sent: Friday, June 17, 2016 6:14 AM >>> To: John Leslie; Black, David >>> Cc: rtcweb@ietf.org; IETF AVTCore WG; tsvwg >>> Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-i= etf- >>> avtcore-rtp-circuit-breakers-16 >>>=20 >>>=20 >>>> On 16 Jun 2016, at 23:25, John Leslie wrote: >>>>=20 >>>> Black, David wrote: >>>>>=20 >>>>> ... I view the current text as providing implementers with too much >>>>> latitude to ignore ECN-CE marks (e.g., because an implementer doesn't >>>>> want to think about this problem space in the first place). >>>=20 >>> I agree, but the argument is that doing so is less harmful than deployin= g a circuit >>> breaker that triggers too often when ECN is used. >>>=20 >>> I=E2=80=99m not sure I believe this argument, though, since it seems tha= t any new AQM >>> that applies ECN marks much more often than at present will have to cons= ider >>> backwards compatibility, to work with deployed TCP (e.g., draft-briscoe-= tsvwg- >>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new markin= g, >>> while existing implementations set ECT(0)). These compatibility mechanis= ms >>> would seem to prevent the issues with the circuit breaker too. >>>=20 >>>> Understand, we have at least two proposals to make ECN-CE more frequent= >>>> than packet drop would be for non-ECN packets: possibly substantially >>>> more frequent. Unless both are killed off, ECN-CE will show up frequent= ly >>>> enough that closing the flow on ECN-CE would kill too many connections.= >>>>=20 >>>> If you want circuit-breaking on such connections, there are two ways: >>>> 1. convince the forwarding nodes to drop packets if their queue exceeds= >>>> design capacity; or >>>> 2. require the sender to send enough not-ECN-capable packets so that ou= r >>>> receiver will see enough packet-drops when a circuit-breaker should >>>> activate. >>>>=20 >>>> (I prefer the first option; but I wouldn't object to the second.) >>>>=20 >>>> There really isn't any way for our circuit-breaker to know _how_much_ >>>> more frequent the ECN-CE marks may be. :^( >>>=20 >>> This is a problem, both for the circuit breaker, and for the algorithms b= eing >>> defined in RMCAT. We do need some understanding what the expected markin= g >>> rates are likely to be, so congestion control and circuit breakers can b= e defined. >>>=20 >>>> We _will_ be sorry if we >>>> allot the same frequency of CE packets as packet-drops to trigger the >>>> circuit-breaker. >>>>=20 >>>>> Could someone propose initial text to qualifies the current "MAY ignor= e" >>>>> statement? >>>>=20 >>>> Essentially, for the second option, you might propose text to the >>>> effect of: >>>> ] >>>> ] If too many ECN-CE packets are received, the sender SHOULD send some >>>> ] not-ECN-capable packets to determine whether enough packets along the= >>>> ] path are being dropped to justify activating our circuit-breaker. >>>>=20 >>>> I=E2=80=99m not enthusiastic about adding that; but it would resolve th= e issue. >>>=20 >>> I=E2=80=99m not convinced this would work. The circuit breaker is lookin= g at long term >>> trends, and in order to have enough not-ECT packets to determine if it s= hould >>> trigger, you=E2=80=99d essentially have to run without ECN for some seco= nds. >>>=20 >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Jun 19 11:42:13 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD0C12D6A7 for ; Sun, 19 Jun 2016 11:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8OioP1MMznm for ; Sun, 19 Jun 2016 11:42:10 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BA612D697 for ; Sun, 19 Jun 2016 11:42:10 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id a66so51037695wme.0 for ; Sun, 19 Jun 2016 11:42: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:from:date:message-id:subject:to :cc; bh=TJBa97S4ElYuvXUWS8DO/+rwnvZN2FSSJeiSxIfmMP8=; b=mk7mQBQZ4zuThBegZkS9OztKt2JsQ1t2V0MbwqmfvX7PQGgm2srlRP2KdQbIQu4coa 0CNWak3zhbFnftauw0Lr+5IVkxOEqnWY4KxmRfjLnO8G41eGWRgQDwFg5UHHsolSPKeU ydgkiM93WoWkAPKN5TZu2tOY/iCL3gX5MTbRT2scoGkSPtmCIzjksaSK7j8KN1psLxhJ oFNeiuSAYBAgWasHBAOsc8QGKpnS6xkYogGl/1Cj1tY4lM/hYOmztMl907m7gp4ijdyB iGUhDngWMAMAbDVGTWhgVlC9B4Yy5BACxR+os2f/eCk9iqIzmdr2QddUTYUkKj5l/00H 9eBQ== 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; bh=TJBa97S4ElYuvXUWS8DO/+rwnvZN2FSSJeiSxIfmMP8=; b=iVQPqfd0JJCFN1g1WlA9J1AvDqm0A9Rb9TgmB06s7J9qCpSJs0cektN5fXu0K1pBP3 htdYs2d1VnpfKwMTnTvWAAboRl0do2I6JWPy/bR1fCRrE8Qh0lgPaNgh6jYPe/3WENHc kvZz6K8Hn52o4R6GAfSHWedWiChnx4q56yUmts17Fm1oKDJdbapEDeID6AzfiEaD5K+c K0M4r19d0NH0S+G74DbH7ovCxvWAvqBqRICgzJ06hSnezJfKVXv9nZL9vzZUk2D/+3tL Pxl0KBroS/QkhQe2pmCYjNtrI477dVjqfLwfAAOK1RTWiEbHtxbeLee5/7si8V1Jf2th JEGw== X-Gm-Message-State: ALyK8tK2RRDP03dm3gnxnbjgvhSJ0tnvSGEk9dm/cjm08Oa1rPijqEOt0m1/E8rtpSe0ALMaDyZPbbDzXgT+aQ== X-Received: by 10.194.82.36 with SMTP id f4mr11252811wjy.104.1466361728599; Sun, 19 Jun 2016 11:42:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.30.103 with HTTP; Sun, 19 Jun 2016 11:42:07 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Date: Sun, 19 Jun 2016 20:42:07 +0200 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=047d7beba114f20d710535a5f139 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jun 2016 18:42:12 -0000 --047d7beba114f20d710535a5f139 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello everybody, from my point of view if the spec talks about sending simulcast, it should talk about receiving simulcast. Probably, for browsers it makes no sense in most of use cases, but the API could be implemented (for example) by Media Servers, and here having the notion of receiving simulcast is quite useful for developers. Best regards!! 2016-06-16 21:41 GMT+02:00 Peter Thatcher : > ORTC allows it, so perhaps WebRTC NV will, but through direct method > calls, which has nothing to do with JSEP. > > > On Thu, Jun 16, 2016 at 6:04 AM, Emil Ivov wrote: > >> Are there specs that would actually allow JSEP to operate with >> simulcast in reception? Do we have anything that says how SSRCs should >> be sort-of ignored in the presence of an incoming RID and tells us >> what to do with sequence numbers in such scenarios? >> >> On Thu, Jun 16, 2016 at 5:44 AM, Bernard Aboba >> wrote: >> > JSEP Section 5.2.1 talks about the initial offer and simulcasting in a= n >> > RtpSender. However Section 5.3.1 (Initial Answers) does not describe >> > simulcast in an RtpReceiver. Also, Section 5.9 (Applying an Answer) >> only >> > talks about sending of simulcast streams, not receiving. >> > >> > Are we to conclude that JSEP only supports sending of simulcast, but >> that an >> > RtpReceiver should only expect to receive a single RTP stream? >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> > >> >> >> >> -- >> https://jitsi.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 > > --=20 Miguel Par=C3=ADs D=C3=ADaz ------------------------------------------------------------------------ Computer/Software engineer. Researcher and architect in http://www.kurento.org http://twitter.com/mparisdiaz ------------------------------------------------------------------------ --047d7beba114f20d710535a5f139 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everybody,
from my point of = view if the spec talks about sending simulcast, it should talk about receiv= ing simulcast.

Probably, for browsers it makes no sense in mos= t of use cases, but the API could be implemented (for example) by Media Ser= vers, and here having the notion of receiving simulcast is quite useful for= developers.

Best regards!!

2016-06-16 21:41 GMT+02:00 Peter Thatcher = <pthatcher@google.com>:
ORTC allows it, so perhaps WebRTC NV will, but through= direct method calls, which has nothing to do with JSEP.


On Thu, Jun 16, 2016 at 6:04 AM, Emil Ivov <= emcho@jitsi.org>= ; wrote:
Are there specs that woul= d actually allow JSEP to operate with
simulcast in reception? Do we have anything that says how SSRCs should
be sort-of ignored in the presence of an incoming RID and tells us
what to do with sequence numbers in such scenarios?

On Thu, Jun 16, 2016 at 5:44 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:=
> JSEP Section 5.2.1 talks about the initial offer and simulcasting in a= n
> RtpSender. However Section 5.3.1 (Initial Answers) does not describe > simulcast in an RtpReceiver.=C2=A0 Also, Section 5.9 (Applying an=C2= =A0 Answer) only
> talks about sending of simulcast streams, not receiving.
>
> Are we to conclude that JSEP only supports sending of simulcast, but t= hat an
> RtpReceiver should only expect to receive a single RTP stream?
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >



--
https://= jitsi.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




--
Miguel Par= =C3=ADs D=C3=ADaz
------------------------------------------------------= ------------------
Computer/Software engineer.
Researcher and archite= ct in http://www.kuren= to.org
h= ttp://twitter.com/mparisdiaz
---------------------------------------= ---------------------------------
--047d7beba114f20d710535a5f139-- From nobody Mon Jun 20 03:11:52 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9697712D13D for ; Mon, 20 Jun 2016 03:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUBtiSHcZhNe for ; Mon, 20 Jun 2016 03:11:50 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C19512D0F1 for ; Mon, 20 Jun 2016 03:11:50 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id EEF4923F042C; Mon, 20 Jun 2016 12:11:47 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0279.002; Mon, 20 Jun 2016 12:11:47 +0200 From: "Hutton, Andrew" To: Cullen Jennings , RTCWeb IETF Thread-Topic: WGLC comment on draft-ietf-rtcweb-transports - return. Thread-Index: AQHRytwmYEeUypUvHka/duhQgJpE6A== Date: Mon, 20 Jun 2016 10:11:46 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF26147002@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports - return. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 10:11:51 -0000 https://tools.ietf.org/html/draft-ietf-rtcweb-transports-14#section-3.4 sta= tes "WebRTC browsers MUST support configuration of STUN and TURN servers, b= oth from browser configuration and from an application".=20 The return draft (draft-ietf-rtcweb-return) explains how to deal with the s= ituation when both are available and actually this also covers the case whe= n a TURN server is auto-discovered as well as being provided by the applica= tion. So should the text be expanded to say that "configuration" also incl= uded auto-discovery and include a reference to -rtcweb-return? Sorry for the last minute comment I have read this so many times before. Regards Andy > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen > Jennings > Sent: 09 June 2016 18:36 > To: RTCWeb IETF > Subject: [rtcweb] WGLC of draft-ietf-rtcweb-transports >=20 > This is the working group last call for draft-ietf-rtcweb-transports-14 >=20 > Please send any comments to this list by June 22, 2016. >=20 > Thanks, > Cullen, Ted, and Sean >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jun 20 06:17:47 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E17E12D0D3; Mon, 20 Jun 2016 06:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVpEIjUgQmoo; Mon, 20 Jun 2016 06:17:38 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A8112D0ED; Mon, 20 Jun 2016 06:17:38 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5KDHLPr009084 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jun 2016 09:17:22 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u5KDHLPr009084 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466428644; bh=8Xp72uWLcZCT5fKoLzmAn5etgCA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=IwebxAOwqWUN0i5iMpV1G4HvJE6ix0dvZs91TYYHFcsCptOKg+YWjG4rEsdLCfdmo 2Eh6I0zmNSHGew8ya6SvfdumclyauRbSF5h1jPVwuWF+3EUe6EUVKp+/kmb4cZVnA5 Q1Su3kznDMvmlfGbb3+BZi6Yh1vtCAbDhGZ76+eo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u5KDHLPr009084 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd55.lss.emc.com (RSA Interceptor); Mon, 20 Jun 2016 09:16:36 -0400 Received: from MXHUB312.corp.emc.com (MXHUB312.corp.emc.com [10.146.3.90]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5KDGxoQ000644 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 20 Jun 2016 09:16:59 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB312.corp.emc.com ([10.146.3.90]) with mapi id 14.03.0266.001; Mon, 20 Jun 2016 09:16:59 -0400 From: "Black, David" To: "Gorry (erg)" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRySnSO2oWwmhohkOlLHzEpySa4p/yV2bA Date: Mon, 20 Jun 2016 13:16:58 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> In-Reply-To: <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.105] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: tsvwg , "rtcweb@ietf.org" , Colin Perkins , IETF AVTCore WG Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 13:17:42 -0000 PiA+IEJ1dCBJ4oCZbSBsZXNzIGNvbmNlcm5lZCB0aGFuIERhdmlkIGFib3V0IGV2ZW50dWFsbHkg aWdub3JpbmcgaXQgZm9yIGNpcmN1aXQNCj4gYnJlYWtlci4NCj4gPg0KPiBBZ3JlZS4gTG9zcyBp cyB0aGUgbWVhc3VyZW1lbnQgdGhhdCBhIENCIE1VU1QgcmVzcG9uZCB0by4NCg0KTXVtYmxlLiAg IEkgd291bGQgYmUgb2sgd2l0aCBhIGNsZWFyIGRpc2NvdXJhZ2VtZW50IGZvciB1c2Ugb2YgRUNO LUNFIG1hcmtzLCBhY2NvbXBhbmllZCBieSB0aGUgc29ydCBvZiBkZXNpZ24gcmF0aW9uYWxlIGhl cmUsIG9yIGV2ZW4gYmV0dGVyLCBhIGNsZWFyIHN0YXRlbWVudCB0aGF0IGxvc3QgcGFja2V0cyBm b3IgdGhlIHB1cnBvc2Ugb2YgdGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIgaGF2ZSB0byBiZSBhY3R1 YWxseSBsb3N0IHdpdGhvdXQgZ2V0dGluZyBpbnRvIHdoZXRoZXIgb3Igbm90IEVDTi1DRSBtYXJr cyBhcmUgaW52b2x2ZWQgLWkuZS4sIHRoZSBSVFAgY2lyY3VpdCBicmVha2VyIGlzIHNwZWNpZmll ZCBhZ2FpbnN0IGFjdHVhbCBkcm9wcyBhcyBhIG5ldHdvcmsgcHJvdGVjdGlvbiBiYWNrc3RvcC4N Cg0KQSByZWxhdGVkIGNvbmNlcm4gaXMgdGhhdCBFQ04gbWFya3MgbWF5IG92ZXJzdGF0ZSBlcXVp dmFsZW50IGxvc3MgYmVoYXZpb3IgLSBhIHNpbXBsaXN0aWMgcXVldWUgbWFuYWdlbWVudCBkaXNj aXBsaW5lIHRoYXQgbWFya3MgZXZlcnkgcGFja2V0IHdoZW4gdGhlIHF1ZXVlIGlzIG92ZXIgYSB0 aHJlc2hvbGQgKE5COiB0aGlzIGNsYXNzIG9mIG1hcmtpbmcgYmVoYXZpb3IgaXMgTk9UIFJFQ09N TUVOREVEIC0gYSByZWFsIEFRTSBTSE9VTEQgYmUgdXNlZCkgY291bGQgeWllbGQgYSBydW4gb2Yg RUNOLUNFIG1hcmtzIHRoYXQgd291bGQgbm90IGNhdXNlIGEgY29ycmVzcG9uZGluZyB3aXRoIGEg cnVuIG9mIHBhY2tldCBkcm9wcy4gICBUaGlzIGlzIGFtb25nIHRoZSByZWFzb25zIHRoYXQgVENQ IHJlYWN0cyB0byBFQ04tQ0UgbWFya3Mgb25seSBvbmNlIHBlciBSVFQsIGFuZCBtaWdodCBiZSBh IHJlYXNvbiB0byB0cmVhdCBtdWx0aXBsZSBFQ04tQ0UgbWFya3MgaW4gYW4gUlRUIGludGVydmFs IGFzIG5vdCByZXByZXNlbnRpbmcgZHJvcHMgb2YgYWxsIHBhY2tldHMgZm9yIHRoZSBSVFAgY2ly Y3VpdCBicmVha2VyJ3MgVENQLWVxdWl2YWxlbnQgdGhyb3VnaHB1dCBjYWxjdWxhdGlvbi4NCg0K VGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog R29ycnkgKGVyZykgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51a10NCj4gU2VudDogU2F0dXJk YXksIEp1bmUgMTgsIDIwMTYgMjoyMyBBTQ0KPiBUbzogTWlyamEgS8O8aGxld2luZA0KPiBDYzog QmxhY2ssIERhdmlkOyBNYWdudXMgV2VzdGVybHVuZDsgQ29saW4gUGVya2luczsgcnRjd2ViQGll dGYub3JnOyBJRVRGDQo+IEFWVENvcmUgV0c7IHRzdndnDQo+IFN1YmplY3Q6IFJlOiBbdHN2d2dd IFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczogZHJhZnQtaWV0Zi0N Cj4gYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiANCj4gSSB0aGluayB3ZSBTSE9V TEQgTk9UIHJlY29tbWVuZCB0byB1c2UgRUNOIG1hcmtzIGFzIGlucHV0cyB0byBhIENCLiBTZWUN Cj4gYmVsb3c6DQo+IA0KPiA+IE9uIDE3IEp1biAyMDE2LCBhdCAxNjowMiwgTWlyamEgS8O8aGxl d2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4NCj4gd3JvdGU6DQo+ID4NCj4g PiArMSB0byBub3QgdXNlIG5vcm1hdGl2ZSBsYW5ndWFnZSBoZXJlLg0KPiA+DQo+ID4gSG93ZXZl ciwgcGxlYXNlIG5vdGUgdGhhdCBoYXZpbmcgYSBoaWdoIGxldmVsIG9mIEVDTi1DRSBtYXJrcyAo d2l0aG91dCBhbnkNCj4gbG9zc2VzKSBtZWFucyB0aGF0IGFsbCBwYWNrZXRzIHdlcmUgcmVjZWl2 ZWQgY29ycmVjdGx5LiBUaGlzIHNpdHVhdGlvbiBjYW4gZXZlbg0KPiBvY2N1cnMgd2l0aG91dCBo aWdoIGRlbGF5cyAoZGVwZW5kaW5nIG9uIHRoZSBBUU0gdXNlZCksIHdoaWNoIHdvdWxkIGp1c3QN Cj4gbWVhbiB0aGUgc2VydmljZXMgd29ya3MgcGVyZmVjdGx5LiBUaGVyZWZvcmUgZm9yIG1lIENF IG1hcmtzIGFyZSBhIHBlcmZlY3QgaW5wdXQNCj4gc2lnbmFsIGZvciBhIGNvbmdlc3Rpb24gY29u dHJvbCBsb29wICh3aGVyZSB0aGUgQVFNIHRlbGwgdGhlIHNlbmRlciB0byB0YWtlIGFjdGlvbg0K PiAtIHdoYXRldmVyIHRoYXQgbWVhbnMpLg0KPiANCj4gV2UgbWF5IGluIGZ1dHVyZSBmaWd1cmUg b3V0IHdheXMgdG8gZG8gdGhpcyB0byBkZXRlY3Qgc2lnbmlmaWNhbnQgZmFpbHVyZSB1c2luZyBh DQo+IHJhdGUgYWRhcHRpdmUgdHJhbnNwb3J0IGFuZCBFQ04gZS5nLiAgT2JzZXJ2aW5nIDEwMCUg Q0UgbWFya3Mgb3Igc29tZXRoaW5nLCBmb3INCj4gYW4gUlRQIGZsb3cgdGhhdCBpcyB0cnlpbmcg dG8gc2VuZCB3ZWxsIGJlbG93IGl0cyBwZWFrIHJhdGUgZGVjaWRlZCBieSBDQyAtLSBidXQgSQ0K PiB0aGluayB0aGlzIGlzIHNwZWN1bGF0aW5nIGF0IGFuIGFsZ29yaXRobSBhbmQgYWRkaW5nIGRl dGFpbHMgaGVyZSBpcyBub3QgYSBnb29kIGlkZWEuDQo+IEVzcGVjaWFsbHkgYXMgQVFNIGNvbnRp bnVlcyB0byBldm9sdmUuDQo+IA0KPiA+IEJ1dCBJ4oCZbSBsZXNzIGNvbmNlcm5lZCB0aGFuIERh dmlkIGFib3V0IGV2ZW50dWFsbHkgaWdub3JpbmcgaXQgZm9yIGNpcmN1aXQNCj4gYnJlYWtlci4N Cj4gPg0KPiBBZ3JlZS4gTG9zcyBpcyB0aGUgbWVhc3VyZW1lbnQgdGhhdCBhIENCIE1VU1QgcmVz cG9uZCB0by4NCj4gDQo+ID4gSW4gYWRkaXRpb24gb25lIHBvaW50IG9uIHNvbWV0aGluZyBNYWdu dXMgd3JvdGUgZWFybGllcjoNCj4gPiAiSWYgdGhlIGltcGxlbWVudGF0aW9uIG9ubHkgaGF2ZSBj aXJjdWl0IGJyZWFrZXIsIGkuZS4gbm8gZnVsbCBmbGVkZ2VkIGNvbmdlc3Rpb24NCj4gY29udHJv bGxlciBhbmQgdXNlcyBFQ04sIHRoZXkgY2FuIGluIHdvcnN0IGNhc2UgZHJpdmUgdGhlIGJ1ZmZl ciBpbnRvIHRoZSBvdmVybG9hZA0KPiByZWdpbWUgd2hlcmUgaXQgc3RhcnRzIGRyb3BwaW5nIHBh Y2tldHMuIOKAng0KPiA+DQo+ID4gSeKAmW0gbm90IHN1cmUgYWJvdXQgdGhpcyBjYXNlLiBFQ04g aXMgYW4gaW5wdXQgc2lnbmFsIGZvciBjb25nZXN0aW9uIGNvbnRyb2wuIElmIHlvdQ0KPiBkb27i gJl0IHVzZSBjb25nZXN0aW9uIGNvbnRyb2wgYnV0IG9ubHkgYSBjaXJjdWl0IGJyZWFrZXIsIHlv dSBzaG91bGQgcHJvYmFibHkgbm90DQo+IGVuYWJsZSBFQ04uIEF0IGxlYXN0IGl0IG5vdCBjbGVh ciB0byBtZSB3aHkgeW91IHdvdWxkIGVuYWJsZSBpdCwgYW5kIGl0J3MgZGVmaW5pdGVseQ0KPiBu b3QgY29uZm9ybSB0byB0aGUgRUNOIHNwZWMuIFByb2JhYmx5IHdlIHNob3VsZCBzYXkgc29tZXRo aW5nIGFib3V0IHRoaXMgaW4gdGhlDQo+IGRyYWZ0Li4uPw0KPiA+DQo+IEFncmVlLCBlbmFibGlu ZyBFQ04gd2l0aG91dCBhIHJlc3BvbnNpdmUgQ0MgaXMgZ29pbmcgdG8gbGVhZCB0byB0cm91Ymxl Lg0KPiANCj4gPiBNaXJqYQ0KPiA+DQo+IEdvcnJ5DQo+IA0KPiA+PiBBbSAxNy4wNi4yMDE2IHVt IDE2OjAzIHNjaHJpZWIgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPjoNCj4gPj4N Cj4gPj4gQ29saW4sDQo+ID4+DQo+ID4+Pj4+IC4uLiAgSSB2aWV3IHRoZSBjdXJyZW50IHRleHQg YXMgcHJvdmlkaW5nIGltcGxlbWVudGVycyB3aXRoIHRvbyBtdWNoDQo+ID4+Pj4+IGxhdGl0dWRl IHRvIGlnbm9yZSBFQ04tQ0UgbWFya3MgKGUuZy4sIGJlY2F1c2UgYW4gaW1wbGVtZW50ZXIgZG9l c24ndA0KPiA+Pj4+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJvYmxlbSBzcGFjZSBpbiB0 aGUgZmlyc3QgcGxhY2UpLg0KPiA+Pj4NCj4gPj4+IEkgYWdyZWUsIGJ1dCB0aGUgYXJndW1lbnQg aXMgdGhhdCBkb2luZyBzbyBpcyBsZXNzIGhhcm1mdWwgdGhhbiBkZXBsb3lpbmcgYQ0KPiBjaXJj dWl0DQo+ID4+PiBicmVha2VyIHRoYXQgdHJpZ2dlcnMgdG9vIG9mdGVuIHdoZW4gRUNOIGlzIHVz ZWQuDQo+ID4+Pg0KPiA+Pj4gSeKAmW0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMgYXJndW1lbnQs IHRob3VnaCwgc2luY2UgaXQgc2VlbXMgdGhhdCBhbnkgbmV3DQo+IEFRTQ0KPiA+Pj4gdGhhdCBh cHBsaWVzIEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhhbiBhdCBwcmVzZW50IHdpbGwgaGF2 ZSB0bw0KPiBjb25zaWRlcg0KPiA+Pj4gYmFja3dhcmRzIGNvbXBhdGliaWxpdHksIHRvIHdvcmsg d2l0aCBkZXBsb3llZCBUQ1AgKGUuZy4sIGRyYWZ0LWJyaXNjb2UtDQo+IHRzdndnLQ0KPiA+Pj4g YXFtLXRjcG0tcm1jYXQtbDRzLXByb2JsZW0gdXNlcyBFQ1QoMSkgYXMgYSBzaWduYWwgdG8gdXNl IHRoZSBuZXcgbWFya2luZywNCj4gPj4+IHdoaWxlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBz ZXQgRUNUKDApKS4gVGhlc2UgY29tcGF0aWJpbGl0eSBtZWNoYW5pc21zDQo+ID4+PiB3b3VsZCBz ZWVtIHRvIHByZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJjdWl0IGJyZWFrZXIgdG9vLg0K PiA+Pg0KPiA+PiBUaGF0IHJvdWdobHkgbWF0Y2hlcyBteSBsaW5lIG9mIHRoaW5raW5nLCBhbmQg SSdsbCBvYnNlcnZlIHRoYXQgdGhlIG9yaWdpbmFsDQo+IERDVENQDQo+ID4+IHByb3RvY29sIGRl c2lnbiB0aGF0IHVzZWQgbW9yZSBhZ2dyZXNzaXZlIEVDTi1DRSBtYXJraW5nIHdhcyBvbmx5IHNh ZmUgZm9yDQo+ID4+IENvbnRyb2xsZWQgRW52aXJvbm1lbnQgZGVwbG95bWVudHMuICAgU2VlIHRo ZSBUU1ZXRyByZmM1NDA1YmlzIGRyYWZ0IGZvcg0KPiB0aGUNCj4gPj4gZGVmaW5pdGlvbiBvZiBD b250cm9sbGVkIEVudmlyb25tZW50LCBhbmQgaWdub3JlIHRoZSBmYWN0IHRoYXQgdGhlIHJmYzU0 MDViaXMNCj4gPj4gZHJhZnQgaXMgYSBVRFAgZHJhZnQgLSB0aGlzIGRlZmluaXRpb24gaXMgbW9y ZSBicm9hZGx5IGFwcGxpY2FibGUuDQo+ID4+DQo+ID4+IEdvaW5nIGJhY2sgb3ZlciBTZWN0aW9u IDcgaW4gdGhpcyBhdnRjb3JlIGRyYWZ0LCBteSB2aWV3cyBhcmU6DQo+ID4+DQo+ID4+IFtBXSBO b25lIG9mIHRoZXNlIGRyYWZ0cyBqdXN0aWZ5IGEgIk1BWSBpZ25vcmUiIHJlc3BvbnNlIHRvIEVD Ti1DRSBtYXJrczoNCj4gPj4gICAgLSBkcmFmdC1raGFkZW1pLXRjcG0tYWx0ZXJuYXRpdmViYWNr b2ZmLWVjbg0KPiA+PiAgICAtIGRyYWZ0LWlldGYtcm1jYXQtbmFkYQ0KPiA+PiAgICAtIGRyYWZ0 LWlldGYtcm1jYXQtc2NyZWFtLWNjDQo+ID4+DQo+ID4+IFtCXSBJbiBsaW5lIHdpdGggQ29saW4n cyBjb21tZW50IG9uIHRoZSBMNFMgZHJhZnQsIEkgdGhpbmsgaXQncyBpbmN1bWJlbnQgb24NCj4g Pj4gdGhlIGF1dGhvcnMgb2YgZHJhZnQtYnJpc2NvZS1hcW0tZHVhbHEtY291cGxlZCB0byBmaWd1 cmUgb3V0IGhvdyB0aGF0IHdpbGwNCj4gPj4gY29leGlzdCAob3IgYXZvaWQpIGRlcGxveWVkIFRD UCwgYW5kIHRoaXMgYXZ0Y29yZSBkcmFmdCBvdWdodCBub3QgdG8gYmUNCj4gPj4gdHJ5aW5nIHRv IHByZWp1ZGdlIHdoYXQgd2lsbCBiZSBkb25lIHRoZXJlLg0KPiA+Pg0KPiA+PiBTbywgSSBkb24n dCB0aGluayB0aGUgY3VycmVudCB0ZXh0IGluIFNlY3Rpb24gNyBoYXMganVzdGlmaWVkIHRoZSB1 bmZldHRlcmVkDQo+ID4+ICJpbXBsZW1lbnRhdGlvbnMgTUFZIGlnbm9yZSBFQ04tQ0UgbWFya3Mi IHRleHQsIGFzIGlnbm9yaW5nIHRob3NlIG1hcmtzDQo+ID4+IGlzIG5vdCBjb25zaXN0ZW50IHdp dGggYW55IG9mIHRoZSBmb3VyIGNpdGVkIGRyYWZ0cy4NCj4gPj4NCj4gPj4gSW4gbW9yZSBkZXRh aWwsIEkgdGhpbmsgbWFraW5nIGNoYW5nZXMgdG8gbm9ybWF0aXZlIHJlcXVpcmVtZW50cyBoZXJl IGJhc2VkDQo+ID4+IG9uIFtCXSBpcyBwcmVtYXR1cmUsIGFuZCBJIHdvdWxkIGhvcGUgdGhhdCB0 aGUgcm1jYXQgV0cgY291bGQgYmUNCj4gZW5jb3VyYWdlZA0KPiA+PiB0byBjb25zaWRlciB0aGUg UlRQIGNpcmN1aXQgYnJlYWtlciBpbiBpdHMgY29uZ2VzdGlvbiBjb250cm9sIGRyYWZ0cywgYXMg dGhvc2UgQ0MNCj4gPj4gbWVjaGFuaXNtcyBhcmUgcmVsYXRlZCB0byB0aGUgY2lyY3VpdCBicmVh a2VyIG1lY2hhbmlzbSwgaGVuY2UgbGlrZWx5DQo+ID4+IHRvIGJlIGluIHJlbGF0ZWQgYXJlYXMg b2YgYW4gUlRQIGltcGxlbWVudGF0aW9uLg0KPiA+Pg0KPiA+PiBUaGF0IGxlYXZlcyBkcmFmdC1r aGFkZW1pLXRjcG0tYWx0ZXJuYXRpdmViYWNrb2ZmLWVjbiwgd2hpY2ggVFNWV0cNCj4gPj4gd2ls bCBiZSBsb29raW5nIGF0IGluIEJlcmxpbi4gIElmIGEgbm9ybWF0aXZlIHN0YXRlbWVudCBhYm91 dCBFQ04tQ0UgcmVhY3Rpb24NCj4gPj4gaXMgZ29pbmcgdG8gcmVzdCBvbiB0aGF0IGRyYWZ0LCB0 aGVuIHRoZSByZWZlcmVuY2UgdG8gdGhhdCBkcmFmdCBzaG91bGQgYmUNCj4gPj4gbm9ybWF0aXZl LiAgU29tZXRoaW5nIGFib3V0IGRvaW5nIHRoYXQgc3RyaWtlcyBtZSBhcyBwcmVtYXR1cmUgLi4u DQo+ID4+DQo+ID4+IEkgcmVhbGl6ZSB0aGF0IHdlJ3JlIHRyeWluZyB0byBwcmVkaWN0IGFuZCBh Y2NvbW1vZGF0ZSB0aGUgZnV0dXJlLCB3aGljaA0KPiA+PiBpcyBhbiBpbXByZWNpc2UgdW5kZXJ0 YWtpbmcgYXQgYmVzdC4gICBBcyBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgY3VycmVudCB0ZXh0LA0K PiA+PiB3b3VsZCBpdCBiZSByZWFzb25hYmxlIHRvIHNheSAod2l0aG91dCBhbnkgUkZDIDIxMTkg a2V5d29yZHMpIHRoYXQgdGhlDQo+ID4+IGJlc3QgY3VycmVudCBndWlkYW5jZSBpcyBzdGlsbCB0 byB0cmVhdCBFQ04tQ0UgbWFya3MgYXMgaW5kaWNhdGluZyBkcm9wcywNCj4gPj4gd2l0aCBhIHdh cm5pbmcgdGhhdCB0aGVyZSBpcyBhIGdvb2QgcG9zc2liaWxpdHkgb2YgdGhpcyBjaGFuZ2luZyBp biB0aGUNCj4gPj4gbmVhciBmdXR1cmUgZHVlIHRvIGFsbCBvZiB0aGUgd29yayBpbiBwcm9ncmVz cyBjaXRlZCBpbiBTZWN0aW9uIDc/DQo+ID4+DQo+ID4+IFRoYW5rcywgLS1EYXZpZA0KPiA+Pg0K PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IENvbGluIFBlcmtp bnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10NCj4gPj4+IFNlbnQ6IEZyaWRheSwgSnVuZSAx NywgMjAxNiA2OjE0IEFNDQo+ID4+PiBUbzogSm9obiBMZXNsaWU7IEJsYWNrLCBEYXZpZA0KPiA+ Pj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZzsgSUVURiBBVlRDb3JlIFdHOyB0c3Z3Zw0KPiA+Pj4gU3Vi amVjdDogUmU6IFtydGN3ZWJdIFtBVlRDT1JFXSBbdHN2d2ddIFdHIExhc3QgQ2FsbCBvbiBjaGFu Z2VzOiBkcmFmdC1pZXRmLQ0KPiA+Pj4gYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0K PiA+Pj4NCj4gPj4+DQo+ID4+Pj4gT24gMTYgSnVuIDIwMTYsIGF0IDIzOjI1LCBKb2huIExlc2xp ZSA8am9obkBqbGMubmV0PiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+IEJsYWNrLCBEYXZpZCA8ZGF2 aWQuYmxhY2tAZW1jLmNvbT4gd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+IC4uLiAgSSB2aWV3IHRo ZSBjdXJyZW50IHRleHQgYXMgcHJvdmlkaW5nIGltcGxlbWVudGVycyB3aXRoIHRvbyBtdWNoDQo+ ID4+Pj4+IGxhdGl0dWRlIHRvIGlnbm9yZSBFQ04tQ0UgbWFya3MgKGUuZy4sIGJlY2F1c2UgYW4g aW1wbGVtZW50ZXIgZG9lc24ndA0KPiA+Pj4+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJv YmxlbSBzcGFjZSBpbiB0aGUgZmlyc3QgcGxhY2UpLg0KPiA+Pj4NCj4gPj4+IEkgYWdyZWUsIGJ1 dCB0aGUgYXJndW1lbnQgaXMgdGhhdCBkb2luZyBzbyBpcyBsZXNzIGhhcm1mdWwgdGhhbiBkZXBs b3lpbmcgYQ0KPiBjaXJjdWl0DQo+ID4+PiBicmVha2VyIHRoYXQgdHJpZ2dlcnMgdG9vIG9mdGVu IHdoZW4gRUNOIGlzIHVzZWQuDQo+ID4+Pg0KPiA+Pj4gSeKAmW0gbm90IHN1cmUgSSBiZWxpZXZl IHRoaXMgYXJndW1lbnQsIHRob3VnaCwgc2luY2UgaXQgc2VlbXMgdGhhdCBhbnkgbmV3DQo+IEFR TQ0KPiA+Pj4gdGhhdCBhcHBsaWVzIEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhhbiBhdCBw cmVzZW50IHdpbGwgaGF2ZSB0bw0KPiBjb25zaWRlcg0KPiA+Pj4gYmFja3dhcmRzIGNvbXBhdGli aWxpdHksIHRvIHdvcmsgd2l0aCBkZXBsb3llZCBUQ1AgKGUuZy4sIGRyYWZ0LWJyaXNjb2UtDQo+ IHRzdndnLQ0KPiA+Pj4gYXFtLXRjcG0tcm1jYXQtbDRzLXByb2JsZW0gdXNlcyBFQ1QoMSkgYXMg YSBzaWduYWwgdG8gdXNlIHRoZSBuZXcgbWFya2luZywNCj4gPj4+IHdoaWxlIGV4aXN0aW5nIGlt cGxlbWVudGF0aW9ucyBzZXQgRUNUKDApKS4gVGhlc2UgY29tcGF0aWJpbGl0eSBtZWNoYW5pc21z DQo+ID4+PiB3b3VsZCBzZWVtIHRvIHByZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJjdWl0 IGJyZWFrZXIgdG9vLg0KPiA+Pj4NCj4gPj4+PiBVbmRlcnN0YW5kLCB3ZSBoYXZlIGF0IGxlYXN0 IHR3byBwcm9wb3NhbHMgdG8gbWFrZSBFQ04tQ0UgbW9yZQ0KPiBmcmVxdWVudA0KPiA+Pj4+IHRo YW4gcGFja2V0IGRyb3Agd291bGQgYmUgZm9yIG5vbi1FQ04gcGFja2V0czogcG9zc2libHkgc3Vi c3RhbnRpYWxseQ0KPiA+Pj4+IG1vcmUgZnJlcXVlbnQuIFVubGVzcyBib3RoIGFyZSBraWxsZWQg b2ZmLCBFQ04tQ0Ugd2lsbCBzaG93IHVwIGZyZXF1ZW50bHkNCj4gPj4+PiBlbm91Z2ggdGhhdCBj bG9zaW5nIHRoZSBmbG93IG9uIEVDTi1DRSB3b3VsZCBraWxsIHRvbyBtYW55IGNvbm5lY3Rpb25z Lg0KPiA+Pj4+DQo+ID4+Pj4gSWYgeW91IHdhbnQgY2lyY3VpdC1icmVha2luZyBvbiBzdWNoIGNv bm5lY3Rpb25zLCB0aGVyZSBhcmUgdHdvIHdheXM6DQo+ID4+Pj4gMS4gY29udmluY2UgdGhlIGZv cndhcmRpbmcgbm9kZXMgdG8gZHJvcCBwYWNrZXRzIGlmIHRoZWlyIHF1ZXVlIGV4Y2VlZHMNCj4g Pj4+PiBkZXNpZ24gY2FwYWNpdHk7IG9yDQo+ID4+Pj4gMi4gcmVxdWlyZSB0aGUgc2VuZGVyIHRv IHNlbmQgZW5vdWdoIG5vdC1FQ04tY2FwYWJsZSBwYWNrZXRzIHNvIHRoYXQgb3VyDQo+ID4+Pj4g cmVjZWl2ZXIgd2lsbCBzZWUgZW5vdWdoIHBhY2tldC1kcm9wcyB3aGVuIGEgY2lyY3VpdC1icmVh a2VyIHNob3VsZA0KPiA+Pj4+IGFjdGl2YXRlLg0KPiA+Pj4+DQo+ID4+Pj4gKEkgcHJlZmVyIHRo ZSBmaXJzdCBvcHRpb247IGJ1dCBJIHdvdWxkbid0IG9iamVjdCB0byB0aGUgc2Vjb25kLikNCj4g Pj4+Pg0KPiA+Pj4+IFRoZXJlIHJlYWxseSBpc24ndCBhbnkgd2F5IGZvciBvdXIgY2lyY3VpdC1i cmVha2VyIHRvIGtub3cgX2hvd19tdWNoXw0KPiA+Pj4+IG1vcmUgZnJlcXVlbnQgdGhlIEVDTi1D RSBtYXJrcyBtYXkgYmUuIDpeKA0KPiA+Pj4NCj4gPj4+IFRoaXMgaXMgYSBwcm9ibGVtLCBib3Ro IGZvciB0aGUgY2lyY3VpdCBicmVha2VyLCBhbmQgZm9yIHRoZSBhbGdvcml0aG1zIGJlaW5nDQo+ ID4+PiBkZWZpbmVkIGluIFJNQ0FULiBXZSBkbyBuZWVkIHNvbWUgdW5kZXJzdGFuZGluZyB3aGF0 IHRoZSBleHBlY3RlZA0KPiBtYXJraW5nDQo+ID4+PiByYXRlcyBhcmUgbGlrZWx5IHRvIGJlLCBz byBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIGNpcmN1aXQgYnJlYWtlcnMgY2FuIGJlDQo+IGRlZmlu ZWQuDQo+ID4+Pg0KPiA+Pj4+IFdlIF93aWxsXyBiZSBzb3JyeSBpZiB3ZQ0KPiA+Pj4+IGFsbG90 IHRoZSBzYW1lIGZyZXF1ZW5jeSBvZiBDRSBwYWNrZXRzIGFzIHBhY2tldC1kcm9wcyB0byB0cmln Z2VyIHRoZQ0KPiA+Pj4+IGNpcmN1aXQtYnJlYWtlci4NCj4gPj4+Pg0KPiA+Pj4+PiBDb3VsZCBz b21lb25lIHByb3Bvc2UgaW5pdGlhbCB0ZXh0IHRvIHF1YWxpZmllcyB0aGUgY3VycmVudCAiTUFZ IGlnbm9yZSINCj4gPj4+Pj4gc3RhdGVtZW50Pw0KPiA+Pj4+DQo+ID4+Pj4gRXNzZW50aWFsbHks IGZvciB0aGUgc2Vjb25kIG9wdGlvbiwgeW91IG1pZ2h0IHByb3Bvc2UgdGV4dCB0byB0aGUNCj4g Pj4+PiBlZmZlY3Qgb2Y6DQo+ID4+Pj4gXQ0KPiA+Pj4+IF0gSWYgdG9vIG1hbnkgRUNOLUNFIHBh Y2tldHMgYXJlIHJlY2VpdmVkLCB0aGUgc2VuZGVyIFNIT1VMRCBzZW5kIHNvbWUNCj4gPj4+PiBd IG5vdC1FQ04tY2FwYWJsZSBwYWNrZXRzIHRvIGRldGVybWluZSB3aGV0aGVyIGVub3VnaCBwYWNr ZXRzIGFsb25nIHRoZQ0KPiA+Pj4+IF0gcGF0aCBhcmUgYmVpbmcgZHJvcHBlZCB0byBqdXN0aWZ5 IGFjdGl2YXRpbmcgb3VyIGNpcmN1aXQtYnJlYWtlci4NCj4gPj4+Pg0KPiA+Pj4+IEnigJltIG5v dCBlbnRodXNpYXN0aWMgYWJvdXQgYWRkaW5nIHRoYXQ7IGJ1dCBpdCB3b3VsZCByZXNvbHZlIHRo ZSBpc3N1ZS4NCj4gPj4+DQo+ID4+PiBJ4oCZbSBub3QgY29udmluY2VkIHRoaXMgd291bGQgd29y ay4gVGhlIGNpcmN1aXQgYnJlYWtlciBpcyBsb29raW5nIGF0IGxvbmcgdGVybQ0KPiA+Pj4gdHJl bmRzLCBhbmQgaW4gb3JkZXIgdG8gaGF2ZSBlbm91Z2ggbm90LUVDVCBwYWNrZXRzIHRvIGRldGVy bWluZSBpZiBpdA0KPiBzaG91bGQNCj4gPj4+IHRyaWdnZXIsIHlvdeKAmWQgZXNzZW50aWFsbHkg aGF2ZSB0byBydW4gd2l0aG91dCBFQ04gZm9yIHNvbWUgc2Vjb25kcy4NCj4gPj4+DQo+ID4+PiAt LQ0KPiA+Pj4gQ29saW4gUGVya2lucw0KPiA+Pj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiA+ Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4+IHJ0Y3dlYkBpZXRmLm9yZw0KPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= From nobody Mon Jun 20 09:35:55 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D116512D650; Mon, 20 Jun 2016 09:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEuh64FlejmJ; Mon, 20 Jun 2016 09:35:46 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431A012D77E; Mon, 20 Jun 2016 09:35:46 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bF2An-0000AQ-N2; Mon, 20 Jun 2016 18:35:41 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.104]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bF2Am-0002lH-MC; Mon, 20 Jun 2016 18:35:41 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Mon, 20 Jun 2016 18:35:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> To: "Black, David" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 15 msgs/h 5 sum rcpts/h 15 sum msgs/h 5 total rcpts 43389 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D44EF8E5A0B4DDC7002F5832F45A733540B00FCB X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 1352 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: " Fairhurst" , tsvwg , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 16:35:50 -0000 > On 20. jun. 2016, at 15.16, Black, David wrote: >=20 >>> But I=E2=80=99m less concerned than David about eventually ignoring = it for circuit >> breaker. >>>=20 >> Agree. Loss is the measurement that a CB MUST respond to. >=20 > Mumble. I would be ok with a clear discouragement for use of ECN-CE = marks, accompanied by the sort of design rationale here, or even better, = a clear statement that lost packets for the purpose of the RTP circuit = breaker have to be actually lost without getting into whether or not = ECN-CE marks are involved -i.e., the RTP circuit breaker is specified = against actual drops as a network protection backstop. >=20 > A related concern is that ECN marks may overstate equivalent loss = behavior - a simplistic queue management discipline that marks every = packet when the queue is over a threshold (NB: this class of marking = behavior is NOT RECOMMENDED - a real AQM SHOULD be used) could yield a = run of ECN-CE marks that would not cause a corresponding with a run of = packet drops. This is among the reasons that TCP reacts to ECN-CE = marks only once per RTT, and might be a reason to treat multiple ECN-CE = marks in an RTT interval as not representing drops of all packets for = the RTP circuit breaker's TCP-equivalent throughput calculation. I=E2=80=99m not sure we need such complicated logic to find a case where = ECN marks are different from packet drops: Basically, they simply aren=E2=80=99t - even =E2=80=9Creal=E2=80=9D AQMs = marking isn=E2=80=99t exactly the same as a packet drop: the marks = themselves inform you that an AQM did its job, and with modern AQMs like = CoDel / PIE etc., you=E2=80=99re probably getting this from a shallow = queue. Chances are that this is less than a BDP worth of queuing, which = is our justification for recommending a different back-off behavior in = draft-khademi-tsvwg-ecn-response-00 and = draft-khademi-tcpm-alternativebackoff-ecn-00 So the point is not that AQMs would treat ECN marking and dropping = differently - it=E2=80=99s that ECN indicates an AQM, and hence probably = a shallow queue. With a drop, you just don=E2=80=99t know. Back to the CB, I think an AQM marking at a shallow queue (like e.g. = CoDel) is indeed quite different from a =E2=80=9Cbroken connection=E2=80=9D= . Cheers, Michael >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: Gorry (erg) [mailto:gorry@erg.abdn.ac.uk] >> Sent: Saturday, June 18, 2016 2:23 AM >> To: Mirja K=C3=BChlewind >> Cc: Black, David; Magnus Westerlund; Colin Perkins; rtcweb@ietf.org; = IETF >> AVTCore WG; tsvwg >> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: = draft-ietf- >> avtcore-rtp-circuit-breakers-16 >>=20 >> I think we SHOULD NOT recommend to use ECN marks as inputs to a CB. = See >> below: >>=20 >>> On 17 Jun 2016, at 16:02, Mirja K=C3=BChlewind = >> wrote: >>>=20 >>> +1 to not use normative language here. >>>=20 >>> However, please note that having a high level of ECN-CE marks = (without any >> losses) means that all packets were received correctly. This = situation can even >> occurs without high delays (depending on the AQM used), which would = just >> mean the services works perfectly. Therefore for me CE marks are a = perfect input >> signal for a congestion control loop (where the AQM tell the sender = to take action >> - whatever that means). >>=20 >> We may in future figure out ways to do this to detect significant = failure using a >> rate adaptive transport and ECN e.g. Observing 100% CE marks or = something, for >> an RTP flow that is trying to send well below its peak rate decided = by CC -- but I >> think this is speculating at an algorithm and adding details here is = not a good idea. >> Especially as AQM continues to evolve. >>=20 >>> But I=E2=80=99m less concerned than David about eventually ignoring = it for circuit >> breaker. >>>=20 >> Agree. Loss is the measurement that a CB MUST respond to. >>=20 >>> In addition one point on something Magnus wrote earlier: >>> "If the implementation only have circuit breaker, i.e. no full = fledged congestion >> controller and uses ECN, they can in worst case drive the buffer into = the overload >> regime where it starts dropping packets. =E2=80=9E >>>=20 >>> I=E2=80=99m not sure about this case. ECN is an input signal for = congestion control. If you >> don=E2=80=99t use congestion control but only a circuit breaker, you = should probably not >> enable ECN. At least it not clear to me why you would enable it, and = it's definitely >> not conform to the ECN spec. Probably we should say something about = this in the >> draft...? >>>=20 >> Agree, enabling ECN without a responsive CC is going to lead to = trouble. >>=20 >>> Mirja >>>=20 >> Gorry >>=20 >>>> Am 17.06.2016 um 16:03 schrieb Black, David : >>>>=20 >>>> Colin, >>>>=20 >>>>>>> ... I view the current text as providing implementers with too = much >>>>>>> latitude to ignore ECN-CE marks (e.g., because an implementer = doesn't >>>>>>> want to think about this problem space in the first place). >>>>>=20 >>>>> I agree, but the argument is that doing so is less harmful than = deploying a >> circuit >>>>> breaker that triggers too often when ECN is used. >>>>>=20 >>>>> I=E2=80=99m not sure I believe this argument, though, since it = seems that any new >> AQM >>>>> that applies ECN marks much more often than at present will have = to >> consider >>>>> backwards compatibility, to work with deployed TCP (e.g., = draft-briscoe- >> tsvwg- >>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new = marking, >>>>> while existing implementations set ECT(0)). These compatibility = mechanisms >>>>> would seem to prevent the issues with the circuit breaker too. >>>>=20 >>>> That roughly matches my line of thinking, and I'll observe that the = original >> DCTCP >>>> protocol design that used more aggressive ECN-CE marking was only = safe for >>>> Controlled Environment deployments. See the TSVWG rfc5405bis = draft for >> the >>>> definition of Controlled Environment, and ignore the fact that the = rfc5405bis >>>> draft is a UDP draft - this definition is more broadly applicable. >>>>=20 >>>> Going back over Section 7 in this avtcore draft, my views are: >>>>=20 >>>> [A] None of these drafts justify a "MAY ignore" response to ECN-CE = marks: >>>> - draft-khademi-tcpm-alternativebackoff-ecn >>>> - draft-ietf-rmcat-nada >>>> - draft-ietf-rmcat-scream-cc >>>>=20 >>>> [B] In line with Colin's comment on the L4S draft, I think it's = incumbent on >>>> the authors of draft-briscoe-aqm-dualq-coupled to figure out how = that will >>>> coexist (or avoid) deployed TCP, and this avtcore draft ought not = to be >>>> trying to prejudge what will be done there. >>>>=20 >>>> So, I don't think the current text in Section 7 has justified the = unfettered >>>> "implementations MAY ignore ECN-CE marks" text, as ignoring those = marks >>>> is not consistent with any of the four cited drafts. >>>>=20 >>>> In more detail, I think making changes to normative requirements = here based >>>> on [B] is premature, and I would hope that the rmcat WG could be >> encouraged >>>> to consider the RTP circuit breaker in its congestion control = drafts, as those CC >>>> mechanisms are related to the circuit breaker mechanism, hence = likely >>>> to be in related areas of an RTP implementation. >>>>=20 >>>> That leaves draft-khademi-tcpm-alternativebackoff-ecn, which TSVWG >>>> will be looking at in Berlin. If a normative statement about = ECN-CE reaction >>>> is going to rest on that draft, then the reference to that draft = should be >>>> normative. Something about doing that strikes me as premature ... >>>>=20 >>>> I realize that we're trying to predict and accommodate the future, = which >>>> is an imprecise undertaking at best. As an alternative to the = current text, >>>> would it be reasonable to say (without any RFC 2119 keywords) that = the >>>> best current guidance is still to treat ECN-CE marks as indicating = drops, >>>> with a warning that there is a good possibility of this changing in = the >>>> near future due to all of the work in progress cited in Section 7? >>>>=20 >>>> Thanks, --David >>>>=20 >>>>> -----Original Message----- >>>>> From: Colin Perkins [mailto:csp@csperkins.org] >>>>> Sent: Friday, June 17, 2016 6:14 AM >>>>> To: John Leslie; Black, David >>>>> Cc: rtcweb@ietf.org; IETF AVTCore WG; tsvwg >>>>> Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: = draft-ietf- >>>>> avtcore-rtp-circuit-breakers-16 >>>>>=20 >>>>>=20 >>>>>> On 16 Jun 2016, at 23:25, John Leslie wrote: >>>>>>=20 >>>>>> Black, David wrote: >>>>>>>=20 >>>>>>> ... I view the current text as providing implementers with too = much >>>>>>> latitude to ignore ECN-CE marks (e.g., because an implementer = doesn't >>>>>>> want to think about this problem space in the first place). >>>>>=20 >>>>> I agree, but the argument is that doing so is less harmful than = deploying a >> circuit >>>>> breaker that triggers too often when ECN is used. >>>>>=20 >>>>> I=E2=80=99m not sure I believe this argument, though, since it = seems that any new >> AQM >>>>> that applies ECN marks much more often than at present will have = to >> consider >>>>> backwards compatibility, to work with deployed TCP (e.g., = draft-briscoe- >> tsvwg- >>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new = marking, >>>>> while existing implementations set ECT(0)). These compatibility = mechanisms >>>>> would seem to prevent the issues with the circuit breaker too. >>>>>=20 >>>>>> Understand, we have at least two proposals to make ECN-CE more >> frequent >>>>>> than packet drop would be for non-ECN packets: possibly = substantially >>>>>> more frequent. Unless both are killed off, ECN-CE will show up = frequently >>>>>> enough that closing the flow on ECN-CE would kill too many = connections. >>>>>>=20 >>>>>> If you want circuit-breaking on such connections, there are two = ways: >>>>>> 1. convince the forwarding nodes to drop packets if their queue = exceeds >>>>>> design capacity; or >>>>>> 2. require the sender to send enough not-ECN-capable packets so = that our >>>>>> receiver will see enough packet-drops when a circuit-breaker = should >>>>>> activate. >>>>>>=20 >>>>>> (I prefer the first option; but I wouldn't object to the second.) >>>>>>=20 >>>>>> There really isn't any way for our circuit-breaker to know = _how_much_ >>>>>> more frequent the ECN-CE marks may be. :^( >>>>>=20 >>>>> This is a problem, both for the circuit breaker, and for the = algorithms being >>>>> defined in RMCAT. We do need some understanding what the expected >> marking >>>>> rates are likely to be, so congestion control and circuit breakers = can be >> defined. >>>>>=20 >>>>>> We _will_ be sorry if we >>>>>> allot the same frequency of CE packets as packet-drops to trigger = the >>>>>> circuit-breaker. >>>>>>=20 >>>>>>> Could someone propose initial text to qualifies the current "MAY = ignore" >>>>>>> statement? >>>>>>=20 >>>>>> Essentially, for the second option, you might propose text to the >>>>>> effect of: >>>>>> ] >>>>>> ] If too many ECN-CE packets are received, the sender SHOULD send = some >>>>>> ] not-ECN-capable packets to determine whether enough packets = along the >>>>>> ] path are being dropped to justify activating our = circuit-breaker. >>>>>>=20 >>>>>> I=E2=80=99m not enthusiastic about adding that; but it would = resolve the issue. >>>>>=20 >>>>> I=E2=80=99m not convinced this would work. The circuit breaker is = looking at long term >>>>> trends, and in order to have enough not-ECT packets to determine = if it >> should >>>>> trigger, you=E2=80=99d essentially have to run without ECN for = some seconds. >>>>>=20 >>>>> -- >>>>> Colin Perkins >>>>> https://csperkins.org/ >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Jun 20 10:44:40 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C686E12D8BA for ; Mon, 20 Jun 2016 10:44:38 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXOlMadfyOjH for ; Mon, 20 Jun 2016 10:44:36 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8ED512D7FC for ; Mon, 20 Jun 2016 10:44:36 -0700 (PDT) Received: by mail-ob0-x229.google.com with SMTP id xn17so401087obc.0 for ; Mon, 20 Jun 2016 10:44:36 -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; bh=su6csTu+1Cjbi9Gtlsj8Cf2g2Jh612dnKHv7uawZFas=; b=osdfmO6YSFccnfu3IBoxixjz6Wkgfjw6asrAsrRjpUPAE3qSSnVm46JYdU4eRPBTrb gncXiSP8Ejn1RyiEgXhbai0FcuzKb3VWcAIOfcAyUalA4KXvpe2BHz+Wq1Jrg94Rdhdr mukuINQmbR29Mq5mH0NGWrT5W2Nw1Vo3Q0D8tvjOtf9ZM+lLjtpZi91qru1/qbI9WTqX iDwJPhug6XZv6ws+j67M84wRqO8Y7ZAL4IoMDCMBweV8nLQYJPOU4zcDtXViBfD/n5Mt qlqL/xxb8YN227bM47dC9/bV2Y7fHpwhhbStx7ur/MZeE3PDtdoeJDLacQGfgAXuUPy6 z33A== 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; bh=su6csTu+1Cjbi9Gtlsj8Cf2g2Jh612dnKHv7uawZFas=; b=Srj2PvscsYZ7qqTDKR+nAvDEXwpOqNt0+kh3NWxWeW7v5H5O4TlB3VCgbTW+F8Zqug 80JdfsZz5Q99rer4DMa1m7pWka0OyD7Kz8IxG97BJCE5ZMsl1WCRaegkSl6kBrzg5nyL UU2oTa7mcWMa7LPiqo7E2z762kMEdOu91qSEUL+xL0vHHTQ/6Px3CXR1iQVSTu2vCNes ekNrM1976CZ2NrHVrzi+HfchjJFsMMpMYPZsSi4OWOmrVXpJG/voHMxgF1kMxKNPSQf9 YXu2kZLauC1F3XFKaHhtqOcqiV8ZeUTLrtP01TNJ+4gECd+Abi8YspgVrGBRpUAVq++T yFLw== X-Gm-Message-State: ALyK8tKQAlfWkvHt+1TTGcKKKGI/JAi0rEZw/8rNKwT5BG4G7ryNbWxE4vLsqVo8ny4LZ3+kRBzZI7UX5oERtA== X-Received: by 10.157.61.73 with SMTP id a67mr11831261otc.48.1466444675466; Mon, 20 Jun 2016 10:44:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Mon, 20 Jun 2016 10:44:16 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF26147002@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF26147002@MCHP04MSX.global-ad.net> From: Ted Hardie Date: Mon, 20 Jun 2016 10:44:16 -0700 Message-ID: To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=001a11c14282f6cd8c0535b94180 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports - return. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 17:44:39 -0000 --001a11c14282f6cd8c0535b94180 Content-Type: text/plain; charset=UTF-8 Hi Andrew, Thanks for re-reading the draft for last call. If the following: "WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application." were modified to "WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application. If a WebRTC browser implements RETURN [draft-ietf-rtcweb-return] to permit the use of TURN proxies, it should resolve conflicts among discovered or configured proxies as set out in section 6.2 of [draft-ietf-rtcweb-return]." would that resolve the issue for you? regards, Ted On Mon, Jun 20, 2016 at 3:11 AM, Hutton, Andrew wrote: > https://tools.ietf.org/html/draft-ietf-rtcweb-transports-14#section-3.4 > states "WebRTC browsers MUST support configuration of STUN and TURN > servers, both from browser configuration and from an application". > > The return draft (draft-ietf-rtcweb-return) explains how to deal with the > situation when both are available and actually this also covers the case > when a TURN server is auto-discovered as well as being provided by the > application. So should the text be expanded to say that "configuration" > also included auto-discovery and include a reference to -rtcweb-return? > > Sorry for the last minute comment I have read this so many times before. > > Regards > Andy > > > > > > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen > > Jennings > > Sent: 09 June 2016 18:36 > > To: RTCWeb IETF > > Subject: [rtcweb] WGLC of draft-ietf-rtcweb-transports > > > > This is the working group last call for draft-ietf-rtcweb-transports-14 > > > > Please send any comments to this list by June 22, 2016. > > > > Thanks, > > Cullen, Ted, and Sean > > > > > > > > > > _______________________________________________ > > 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 > --001a11c14282f6cd8c0535b94180 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andrew,

Thanks for re-= reading the draft for last call.

If the following: "WebRT= C browsers MUST support configuration of STUN and TURN servers, both from b= rowser configuration and from an application."=C2=A0 were modified to = "WebRTC browsers MUST support configuration of STUN and TURN servers, = both from browser configuration and from an application.=C2=A0 If a WebRTC = browser implements RETURN [draft-ietf-rtcweb-return] to permit the use of T= URN proxies, it should resolve conflicts among discovered or configured pro= xies as set out in section 6.2 of [draft-ietf-rtcweb-return]." would t= hat resolve the issue for you?

regards,

Ted=C2=A0=

On Mon, Jun 20, = 2016 at 3:11 AM, Hutton, Andrew <andrew.hutton@unify.com> wrote:
https://tools.ietf.org/html/draft-ietf-r= tcweb-transports-14#section-3.4 states "WebRTC browsers MUST suppo= rt configuration of STUN and TURN servers, both from browser configuration = and from an application".

The return draft (draft-ietf-rtcweb-return) explains how to deal with the s= ituation when both are available and actually this also covers the case whe= n a TURN server is auto-discovered as well as being provided by the applica= tion.=C2=A0 So should the text be expanded to say that "configuration&= quot; also included auto-discovery and include a reference to -rtcweb-retur= n?

Sorry for the last minute comment I have read this so many times before.
Regards
Andy





> -----Original Message-----
> From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Cullen
> Jennings
> Sent: 09 June 2016 18:36
> To: RTCWeb IETF
> Subject: [rtcweb] WGLC of draft-ietf-rtcweb-transports
>
> This is the working group last call for draft-ietf-rtcweb-transports-1= 4
>
> Please send any comments to this list by June 22, 2016.
>
> Thanks,
> Cullen, Ted, and Sean
>
>
>
>
> _______________________________________________
> 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

--001a11c14282f6cd8c0535b94180-- From nobody Mon Jun 20 13:19:45 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A07E12D9E9 for ; Mon, 20 Jun 2016 13:19:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y4xx8B2rYZR for ; Mon, 20 Jun 2016 13:19:43 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EA412D9E7 for ; Mon, 20 Jun 2016 13:19:43 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id v77so28471081ywg.0 for ; Mon, 20 Jun 2016 13:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LZd3gGYkcFYUW+Wd/11XBgGSxx7aLhZsmwkD/h2K3AE=; b=QaNh9kgr4FIjglZcPpLi1WK/wmLE2T0QKKR0KmlfJKZHBNrFuyLrOLPLgyUWmY5ZtA sNripr7EOpnV8TGMglCemWB0mGRn41Ma9TPWNJIy/32txkHA6qq0YcHAMN1Z6sS0bAMs 5c1rYOt0fZRpgv6oYxYGDr7eKlpHca805INDQPrJu0sX8VVieoXPc3FODnMA9i6TJW3+ Mk98ZzRBqPvr6nK+eC8exnAMMUwrAkn98DGWFFDi5uAgdVVpVF6DEI/1LulgHKpbAYOh ejZFuLsapVHEbvBSvEeipQ6eqV3SGImrq3DHWPXal6BCZdIXTQriHrypcpJ1Gy7mqpCz Hfqg== 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-transfer-encoding; bh=LZd3gGYkcFYUW+Wd/11XBgGSxx7aLhZsmwkD/h2K3AE=; b=Nl1YERipNu09yB3+hIOiPK1PrQg2g9nj4mGUqZZygQmb0Fz8hpPzPKxMh7MyPsH8L0 lr1t4UnS/XgOtpJvTXZCtBDubrhaxd4fyShcVyDte2Q4TE7BIAQ6n2A4ub+lgCFLYM9q 8rrCP4lI/wPa3LjZL65hvvCtzii3YPCBHWksDSQ18ghtJf5TJlAfVjwepytbxN6owvn9 na5sw2alF/yZ/AIO/gTH/1fem8OvL+X+zSVyjoW6XjxnleEfnpOFy9XJ+isf++wKjW2W ZuXRfixW9e26GFYTMYdngtFkvcKP5pIffZa7T4ai2oo2q4DSYi3LHOcDL12r3XIS8JZc 6iWQ== X-Gm-Message-State: ALyK8tLMwuZIx3tnHF3oZg0+cWwqAoEMg7db+AKd92hdJID2S6nfnaLOyQK3rvsdxETzp+iCuxC05pl6MyQiKA== X-Received: by 10.37.212.207 with SMTP id m198mr9705366ybf.20.1466453982381; Mon, 20 Jun 2016 13:19:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.7.199 with HTTP; Mon, 20 Jun 2016 13:19:22 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 Jun 2016 22:19:22 +0200 Message-ID: To: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 20:19:44 -0000 2016-06-19 20:42 GMT+02:00 Miguel Par=C3=ADs D=C3=ADaz : > Probably, for browsers it makes no sense in most of use cases, but the AP= I > could be implemented (for example) by Media Servers, and here having the > notion of receiving simulcast is quite useful for developers. A WebRTC server must just choose a single encoding (up to the server logic), signal it to the receiver and just route such an encoding to the receiver. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 21 00:46:48 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F48D12D7F2 for ; Tue, 21 Jun 2016 00:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=urjc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4oREKgXTqz7 for ; Tue, 21 Jun 2016 00:46:44 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0691.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::691]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416C012D54B for ; Tue, 21 Jun 2016 00:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=urjc.onmicrosoft.com; s=selector1-urjc-es; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jKVd1O3QlgkgZqhOSbsvTZKZEAgbJl8n/tWFxOovHRU=; b=LTL/ashiz/824RIBZa/QlRV22EBIzTZWJjeuOL2Z0YOun0rk6ZikvRdekSxgtxla2aJCFe112nKWOCSfXtcGXZhYHa5EDIhtFi9pavpk640dk06dgTXAkcxl5TiOpws+ZKYP/Xyx3EiW0g6Gl44HC2jG4X2wlkN85TT7ZPbl7BA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=luis.lopez@urjc.es; Received: from [193.147.51.18] (193.147.51.18) by AM4PR0201MB2082.eurprd02.prod.outlook.com (10.165.38.147) with Microsoft SMTP Server (TLS) id 15.1.517.8; Tue, 21 Jun 2016 07:46:22 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Luis_L=C3=B3pez_Fern=C3=A1ndez?= In-Reply-To: Date: Tue, 21 Jun 2016 09:46:20 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.147.51.18] X-ClientProxiedBy: AM3PR04CA0030.eurprd04.prod.outlook.com (10.242.16.30) To AM4PR0201MB2082.eurprd02.prod.outlook.com (10.165.38.147) X-MS-Office365-Filtering-Correlation-Id: b0bc576e-7a36-462e-c0e5-08d399a8241f X-Microsoft-Exchange-Diagnostics: 1; AM4PR0201MB2082; 2:IgL75C6C7KfnS9HOQEn7Jw/UrzyMsI/1lN0AiZqsFed6VH3eUa3fSSE2BbPBoV6ZHqxUFYGM8B/l7gpZUssxxMjhOi1k43IrdBhVTLV0yppa1f7018U8nWWfpEqtlWLlOIXnCdKzHzbs6XhaOxhXsEq5+pOi+nRG9GwfEUIoQZX+lSgs/nHpkIa8WD5nN2oK; 3:ImujR0xxt6wCwnPV6G92Szpb8lT6XlVf1GzuieRg9zdGswBU1jbilZyQk+JChUa7V/7uhMGv7+gybgqQuRiOC5iOA1EaX9kwgL34qTYVG0R6ecK8bSnhMHiKLCpeaoED X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR0201MB2082; X-Microsoft-Exchange-Diagnostics: 1; AM4PR0201MB2082; 25:JzH9Z/Ht4+7WuxAp7q/uM/IE72wixa0f9ceJhOaYDmssa3G2midTybbbj04xqCH/N3usbEDqj+rIvD+lU5W1qt4ORZe0f/MFV7RGakDpHL1ZsWXKHOVvkx6P9qp7qsXdNBL8Fa6he0Unv13ba1dVo++ahJAbV0gUCiP8TIuQ1EYnQ7Wv94XpqqFtVSy5PD/vL4t7gqUSY0kEvvb9UCwBzH7z0cbp+MPgXROZUJWW+LlLDOd3FFDQI/ecUu0xENtnBhJW2oNHFJ9i0O6LSupKuTdyWCqFcijHe53n0f5BSf5hdnLD4o3G6U0z3Xd3+dhXn1G47HrPa+oU5MLVVVzV0Ubo8fsR+bHr6KODZIGsk4EjJYKXAoZ405SchkmkdKSRzoRptB1LtxWkt5/11hYIAZGuzA6sb0TBcJ85sG1rr8ZooIwNo+gn1Jza0VO2LGMMX6O0ljiLvBW2gvC0B9r5ZyaHHrpBV8WBiFSV//fVAokHGPA3CDAxaU6655jSwtpLRaQhy5XhRZlntKMGR6Jxd7PukGyd1pQ1dZjE6AYJpchpDgnyd3xIeKflPQrf5ogDPEmCRwI3sCCij+J9KDNGtDZgDEl2fTxErQtwHxhhLRAhjZ2wuHFqw/jP0NM65T+xVlMYNCMsDgJpRr4c8njWHIdsSiDsLH7kVcoYg0AgHY1Utl54yGEocvPV8oKMJNc/40+slDt9dceLcBfPv6vXhboTkEMaMskjylpmOZpyI7VRwTG+dpy7bKJ6S64Vfqhi5P++OFNmLcPW3bff/55BqA+u52Nj5+UtUCTP3j7dK5FiO4RFdqG9Nw0Z5PeYblUT X-Microsoft-Exchange-Diagnostics: 1; AM4PR0201MB2082; 20:+5VQpH90bX1YxT2zIBH6LA9YfvaZeA1aPlPUNhWVvkuEHTHN0xsefzfAy2ufRbwzY91v0/Q4nLJxjmgMv7PMe254h4utP94v3EIGVzyUW3YK7qE+D4x5wEQsKRBj8OIr0XTvX0wp3gPbGUnHTyUbPtTjEBIq2oJ+IIHTPoBY1sDnkiU806IXhGAXqlaQiw+f3eqnqOO9pEBueugoJCPFNAr3HxI5j2lTYiJyRukaorOsR6xL4jtqxD8WKRLQHwYBs3ByMz1ZiKWRMzQu4kCVbWu2/Sk/VeH/st1ZoyQcnRD2RmxiUJ83SXiWPLUNCHuyq7XJaod45xs1hDSQtlUoCIafYqdOFsE4N4lJoIioHPxo8XfG6tL8UFtB05UF0qUmaga6osntYc846SjEI0kVzLyzpMTHhzD2+WWhWYgz3t0c6ZQiwfcsrUgMqcjiHdu/ePxesuneVWaQY8zqYeHB7h8zQPfZaeVtsP4N4FCnA8DRFWrLU6wXsBcZCAD7EbFG; 4:Vcy+cukz0IofBvIOPCYcdrCGuchqtSUOQ9p5df86bFhGGmLGhdTdKTBMyzzmUI6/XoWo1xJ2uv45oTqG6xNc+4SU8H9mDETBJm63o3X1PXKH/elqeNK7kVRpvs53co33WLeR4ySDq0Rj2VQLd0cTOWehibK6akHz//ADDOB1ZkwGRr0uIi1A56+5TcgaR5xIRP/ruxI4nRJ6qqHdSkoMxYi541RkwjievgH17DoRNtVJQRbp385qwxpxBCTM+URtujcPLfLhtbnv7QsDYz7DcZMohvNNZDE/ZRolPVxrS1hVgmruM+6JTvWuxUA52NvhiBqBNHC8qi+U85OtU9dVs1lIm9S4lLGT4FwurcWWK8Ljydsj1L6Jn3sgeDUIztu89VTRMv+ATpGM+r8cSP0keUXVnnNDE7x/iwKmQz29h3s= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM4PR0201MB2082; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0201MB2082; X-Forefront-PRVS: 098076C36C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(377424004)(189002)(199003)(76176999)(50986999)(7846002)(105586002)(19580395003)(81166006)(74482002)(97736004)(23676002)(19580405001)(57306001)(50466002)(110136002)(8676002)(4326007)(77096005)(81156014)(101416001)(8746002)(47776003)(15975445007)(2950100001)(106356001)(2906002)(3846002)(6116002)(86362001)(42186005)(33656002)(50226002)(36756003)(66066001)(82746002)(83716003)(92566002)(68736007)(93886004)(7736002)(189998001)(586003)(3940600001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0201MB2082; H:[193.147.51.18]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; Received-SPF: None (protection.outlook.com: urjc.es does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjAyMDFNQjIwODI7MjM6ZjdNVUVWc1pVVG9UeHlzejFjd1FOV1RM?= =?utf-8?B?MzJKMTBFcWgxOURQQisycmdxUnc0T1JLU2ZhaS94bWxjTVQ3a294d0lkbURp?= =?utf-8?B?LzN3WnROTktaVE4rM0lybWpnb3ZEaHh5Qlo3REJ6WStpdFdtbHIydWNpNUtM?= =?utf-8?B?WERvOUg4MlpLaVVzMkhqazJKU0J2bFBudG9yTDI1aUJiczJZMHZBbHQ4VEJn?= =?utf-8?B?N2JJRUlnSW1xYkw1M3FUVEpMazRjblAwcHJyRUsvclBpYUUvVnFaVlBvdkdI?= =?utf-8?B?emtCTjhMcEhONlFmQVhlcDNiTDN6dGJlTFYvTEZnOGE1emEzbDFGeWRLYVZF?= =?utf-8?B?RVhYbVU2K0YycW9xaHk0RXNTSFJjNENBNmxJSWh2enNGc2lXSURlU044UVJV?= =?utf-8?B?cHdQTkc5WGxsMkZ5bkRLMkFOSWRDeDJHNk43eSsyRm8xaGIweStDTjQraDlX?= =?utf-8?B?V3R6TVFaSk1jOW9oT0ZVRjRKTkV5S096UFJ3YU15dUd2OUFMYTk3bG5scXJ0?= =?utf-8?B?eWdVQUxrSEZjbFpKdDZqNTAxY3RERXdrTWtZMGZrUFd1UlFORTl6Q1JnZEkv?= =?utf-8?B?N3B4UC9kZHRtRXluUk5ZaTc4Vm1PdlhwNjdlY0lNMUZxUjlUT1hIOEZ2dk4y?= =?utf-8?B?SWtiWGhHRDBqV0xRckJlWG5nTTg2NzJxLytaMXhsKzdFV3BMVUxCcTladUU3?= =?utf-8?B?VDF4SUpRL09KT0N0UnZQNko2NHQrdU5TQnZuNXBTMnFsTXlTYVNsZnFtbVA3?= =?utf-8?B?WVBlWEl2aDJWSWRVUEdkT2dvdHVzbStIZ3lxQWZueTZrTWpLdHExWGtUeGJE?= =?utf-8?B?dTdWb2dTUTBvSUV0VEhDODNJVVZJL1JJRzZjZFFCRGh0M3oyUS91QmFKQTlk?= =?utf-8?B?Rnh4amVNRGRkTm85UktLQlZjNmV1NW8ydEd3VUhtWmNaZGM3cDNCNGlUR2I3?= =?utf-8?B?eVFtM2ZFbkUxUytSeU9NeWkvV3JNV0JtZDlqTm8rVmFNRDhBMDV0NDdxRHZo?= =?utf-8?B?dlI1ckRCNHRMVnlITklEVFlDR05OWmVUaXRMZGt1VFlsZU45eldmVklOZGw5?= =?utf-8?B?Z1lYUURvNjVFcDVTOWhXaGgyTG1VYmZrcTB1NnViWERsWjlHMHNOVjNCUG52?= =?utf-8?B?RDZEanl1Q0p0QWVhOGU2Z1d3SE1vekQxRUhPUzVzaGs5VlY1YXNjNSt6ZGFz?= =?utf-8?B?ZzZ0eDYxVGE1K3RtdWpKVGx1SHJGTDVBbzJKZHRuQUYvVHg2RVRocWV1ZjVH?= =?utf-8?B?dDNpVUI2Q1pzVzJnNUd1aVpYWlZVVzM2TnU1SVF4d0gxUkZ1UGVhY0NWeHVJ?= =?utf-8?B?Y1lMd1I2UjFTeDhBd1Fwc1YxdHRqSDR6cHRhMTFwamF5djA1NDlqeHNhbzJL?= =?utf-8?B?M1JoZlY3NUlYOXI2cVZCQzZEcldpWm5aYU5aQjRDM3Fsa3JoWENuYXMvQnNQ?= =?utf-8?B?WXBqMUlLZDVLK3VPZ2k0L2xnTjVoWGR4dEhQbWpCQUd4YWp0WmdaMi9IZlRM?= =?utf-8?B?RWNaTlVqWWRuRFgyZTZvWFlIU3VLRTlmOGtHNk1NU3dJWHdaVDR1enRCMkgy?= =?utf-8?B?NDdDai9vMlFrRFIrd1NDZ1RQYkUvUi8vbUo5OVRNbWtEamM0TXV6WkNhNmYr?= =?utf-8?Q?H+XvzEbfIXFnfAh9VCIeMk?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR0201MB2082; 6:MST5HAkm3OA4Eu2onhEL0tKTC3SetY47HkIiD4t3UNlRyT6Bs6yS4TLHNuKg1Bsg5onsTxxsmZJHi4iEcrevGLn7pv3QnAI6JOcSNJdfJdZx1PX0MTiiYg28QUf2OCRoGu8QLFwGXbycMMCM2wf0nc3pcR9GPyYpcjDfw5axjS75V2baQ6qrk8qrh2zVqALIW+tQyxK4I/4r7IXywcdlmU3bTjCLSlXY0Q/axfSCaF8wyTkQ5VIU4vzZn8u6QUtNkRf7eJDhEPBIhwkiUfAgzZkka1wE/MKG+heyHOcBYh0=; 5:NPF91mXiFLkPr0cx2yTlogM4p4YUKLW5kRcG2cbzylrEp4GdVE0rCr477Q7vj/8G5g/xu3NyusXLNvZejQJsbzfv0X5QLilJED59TjKQqfEhxQRZsYrx3mMlDmZOqVhrMGCCz43yVB3lQZyJqhHCqg==; 24:43mCcw8hdrN4g61IpEGtPsezjFpJdGQEiCVs7AvZApzZWz1r6hSi+zD8JtvN6snp2hUFLZllQDHCPubcRuV4mHLiDnJ89PxartKO8ARnJpU=; 7:weqAx06YtoY750kR+pRlCpya1ds1SH4vrWhYYlGSByr5WH+Jz50917aUy5jBMTnM0xqL70Dq2a0PPA41ZPwo9jqVkPTsM1ihdQkW+UnnJFWxL5JvRxIN1PWzR+p8+vjF0VjRoUaVOoiMVugBrv4ELgjiVdd3yDdITXW291KGjnMjMKQXZH5o29+ssNQF2MCCnt8JrycYBKT5EiyyapHdMw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: urjc.es X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2016 07:46:22.6085 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0201MB2082 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 07:46:47 -0000 > El 20 jun 2016, a las 22:19, I=C3=B1aki Baz Castillo = escribi=C3=B3: >=20 > 2016-06-19 20:42 GMT+02:00 Miguel Par=C3=ADs D=C3=ADaz = : >> Probably, for browsers it makes no sense in most of use cases, but = the API >> could be implemented (for example) by Media Servers, and here having = the >> notion of receiving simulcast is quite useful for developers. >=20 > A WebRTC server must just choose a single encoding (up to the server > logic), signal it to the receiver and just route such an encoding to > the receiver. You are assuming that the WebRTC server can only mediate between two = clients. But a WebRTC server can also be mediating between a client and = another WebRTC server when I need very large scalability. For example, = if I want to create very large distribution trees (broadcasting) using = WebRTC, I need servers to communicate to other servers so that such = servers exchange all the simulcast encodings. Only the end servers (i.e. = the servers on the leaves of the tree that are serving to the final = clients) can route to the client the appropriate encoding adapted to the = client available bandwidth. >=20 >=20 > --=20 > I=C3=B1aki Baz Castillo > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 21 00:53:20 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F7812D169 for ; Tue, 21 Jun 2016 00:53:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwQSCFL20hk9 for ; Tue, 21 Jun 2016 00:53:17 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A4D12D924 for ; Tue, 21 Jun 2016 00:53:16 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id b72so6961676ywa.3 for ; Tue, 21 Jun 2016 00:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6qQaRPKMRWi7iuj7eiTqBKM3wFy3YhmzMhSpmvBfX0o=; b=GNT+NvhRiAK6aubnHemzstC5tgzXlP+1PD0CgChjcQh7mQuGbd3cPhI9wvLv/x27jd b/8d6XH8QNkyl7sfoKkmAW4blMCMoUT585r/QmG6go0yT5BSvv0z8xIV5aDOmUPGCmxP 4eUeKvYTmmvIU0CL2hpNDuUoATcEmEtVF+8KsKt0TrQZTZ8r5zgqCpmhIV1z/9slptNd /LuHXm9TEOflXW9EIX05yd0D8y8RTC8TgZ/tchFx80b/myDd67y2PSFZ8tc+pFejMnTU hwqXclnYpScDa0wf3ngKXdfVEEhXZGEv2ApwGW7xu/KKLmJ+UqvLJgcGimFAhRc09AUR cYCw== 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-transfer-encoding; bh=6qQaRPKMRWi7iuj7eiTqBKM3wFy3YhmzMhSpmvBfX0o=; b=hUXdHGZkCqAAN+dEgD7IuWcRHscLCnpv9VKiTpuczVMfQnr4Jq7LRtz2AIjVzuRQxi vgX/bHxbQPiUN5ycYk9e/aPXaXIlBRr1kxSrTbeuV5ASmPdEh6huPbxy7mi0sfdNx9eW agktQBSbWTzGNi/PKXxPt85VelAUUHtP64M2pA+vU/1qc370VN+izh4JkXz4YG53DY7b FYQREq+klb/bE34JyS43EkvwcR5Qf3htubjfXhSXEiAftrY1lTm6cQ6dNtcpqiDmKZtN B7e/YTa03RM9get7o4u8GAq69KwikAn5tZSaRvfJckLH5ELE9snWgpqTQhOe5vZItOCM sJ1w== X-Gm-Message-State: ALyK8tIDgg2LoC6UHJakWuVQMsPknz6GtjRPQkEQTfYHV35irMurmMLR2MHCeXvdJk7JYAJ+m31/Use4EkxhHg== X-Received: by 10.129.137.129 with SMTP id z123mr10703849ywf.101.1466495596161; Tue, 21 Jun 2016 00:53:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.7.199 with HTTP; Tue, 21 Jun 2016 00:52:56 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 21 Jun 2016 09:52:56 +0200 Message-ID: To: =?UTF-8?Q?Luis_L=C3=B3pez_Fern=C3=A1ndez?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 07:53:19 -0000 2016-06-21 9:46 GMT+02:00 Luis L=C3=B3pez Fern=C3=A1ndez : >> A WebRTC server must just choose a single encoding (up to the server >> logic), signal it to the receiver and just route such an encoding to >> the receiver. > You are assuming that the WebRTC server can only mediate between two clie= nts. Not at all. What I say above also applies to SFUs. >But a WebRTC server can also be mediating between a client and another Web= RTC server when I need very large scalability. For example, if I want to cr= eate very large distribution trees (broadcasting) using WebRTC, I need serv= ers to communicate to other servers so that such servers exchange all the s= imulcast encodings. Only the end servers (i.e. the servers on the leaves of= the tree that are serving to the final clients) can route to the client th= e appropriate encoding adapted to the client available bandwidth. Easy: let the first server route all the encodings to the end-server, and let the end-server decide which want to route to the receiver peer. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 21 01:02:03 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D7A12D93A for ; Tue, 21 Jun 2016 01:02: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=urjc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8se_JaeWX1PM for ; Tue, 21 Jun 2016 01:02:00 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::627]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FA612D945 for ; Tue, 21 Jun 2016 01:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=urjc.onmicrosoft.com; s=selector1-urjc-es; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nHFLxv2ZrAMP/L5m/1jXZl3lZbl5BMDPgSNULYj3UKY=; b=Xczh0AaJWepSbwnG2ISGH/xZriqadm2OneNOyfNxDNqXGqW5NeTCxRC17fX1O80L89NKqR616iRC6g96Vfp9u2H4ad1YZk+5xxGHZFjLjE0NcBINIdyEc8bsB1Tw5viTC3grf9REkEAQOmgu16fCQeyYPG5NlPPUWjOCPNv+cyg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=luis.lopez@urjc.es; Received: from [193.147.51.18] (193.147.51.18) by AM4PR0201MB2083.eurprd02.prod.outlook.com (10.165.38.148) with Microsoft SMTP Server (TLS) id 15.1.517.8; Tue, 21 Jun 2016 08:01:43 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_CE93B7E6-6C6F-4DCA-9B65-1299E18DC4C7" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Luis_L=C3=B3pez_Fern=C3=A1ndez?= In-Reply-To: Date: Tue, 21 Jun 2016 10:01:38 +0200 Message-ID: <26647A6B-F7F8-4999-AAC9-C7DCB87F7487@urjc.es> References: To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.147.51.18] X-ClientProxiedBy: HE1PR0201CA0005.eurprd02.prod.outlook.com (10.165.229.15) To AM4PR0201MB2083.eurprd02.prod.outlook.com (10.165.38.148) X-MS-Office365-Filtering-Correlation-Id: 746283d6-0be0-4515-85b4-08d399aa493e X-Microsoft-Exchange-Diagnostics: 1; AM4PR0201MB2083; 2:+Vn47E/wNsJDtctYlR1M+VK5sT0J9ol25Ll/oNThqGWhswycICvzBC+LLuM2tKmzFgi9EIxTgp0Kii9nsDnJcc/M+GNsgk4p2NV5yN2LjrDOntIhvMO5FdcQcEGS4W2P3WZ/CvHuERQkZzH441JVLtKmxEKl9TiGyVsA12QLRY32LYdm9nhQsIxZ498j7Snz; 3:JN7UCtm/QBVyMsfBGRoxRuAB2F/qj5ZJnaalQ3GmDxei98RHmhsxc1eF6taQdxXX9B79uTJj5+pyPXBeGp5SZb0qwbVWqY+/CSXfm/4KOMJLy8ENE8bCcU5wGgeJYZEo; 25:eReVN0g7+mjHWG4eV8E/tp6/KOLplvYFrw3/hZdfxPeTc/UE/RIsUN0DOblg0CC+HcoTKTs7myY0h9azUYM9ftSIA6M6lAWgKRxwqRqN/9a5dhKoLDBurB0dxSWoHsY9cNtbbVYyU2O6W8cH0tRZ2S/1Y5D7+Ofj2Len4higOzxejbCpJ+67OahKZBpys/5HSB/tildu4pn+5LIkCEeWyb94zTkhM0h8AdJoBZY1HBDBUY7ULwzpmJOsPrEDWoiJ1yawbEUDxX1NuBZz5Djni/1WAkjVLiyNwz2SP1QNxVxx6JWExxouor8j+XNxUeGFZ8gsssPArHgEUlD7tQBbyrNshC16ImeODZaSQ9XrID4chmOqwGoLJPKeg50nudbEkoXo4SCUhvjaDo3QE1TUWDCtM1G0dVPwr4DAtZoGA8w= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR0201MB2083; X-Microsoft-Exchange-Diagnostics: 1; AM4PR0201MB2083; 20:WWBZzq4j3UbivVZq8nbeHEhlz3MnuZC4Y25SihvHCJutgKNFr9OaoKyFctFe1d40WXF5Qd6RXs4MAPWE1vu21NCud5ZAqblwj9z1t9n3piStbKpRk/8G6JIep8XGBea1kDzpOCUmO7522tkmftHBjjzKnN+R4osymTCWYA/MlzeJRdLx0tAw5NwJEutt2AG986uMrB/2BwpHO6JJcm1/VVN/NEfej5FbieuhUCxClnsfPkU3ZpkmsUAXMpphvbS9XcMv4d6v4Dd71YNg9rNx/T9lWq9B77wqgLKtJsOR/Xg5EhFkYA3KKsXeyJ48rXq0f5bC318VTKiS+0/vhIGzByYiLB5kJ0l2e+xpburFt0+I0232Jsbi/ANuQmoUkP7domUeYdk9igtmB2o78oNuw4OEsS7NBVh8iEJ34g3R+oJHmuMUNOCPWurvjpDNjJxzKg5yLTrmn+3nxrHoRPaUUTHkrB6170v7h0KE8I2RHZ/DKgFqo+iw7klElWfK6p1h; 4:nWnv+lBvFMRes7H4qp5kwq0zpfB+8bH5WPq5T9IaaOmjR2FnKiZoBw6ic+UlyykyO0N14zwCh/yeOn+Y31n7E+i0zeq6WG73O4gVUiblC+b4FRH7zDxD6bE7n7oE0RmDJyiA4hDIXTVTgdEvM4grHU47+0TlWFiEvMLpSOuCHpDqJeDpbWzos0qiGrP4Vsk5VnxgvdoAPGlEdOruiomcexbgy1ih6ZaBB9bQANXa0IVt8r7kSflqeZrA8aRwH2bCy1SGAMxicQMx4DoIW9hYYC+nmEgjVeqdmaOqH0b3ZtwhO58R3VlbRrBvpMlZ2kdb1WFbbthaKb/5E6Y5+5S+/kWdSlOIs/Rzqj1FUZLGcu8HFHwsaXk7ApSHdNzb2F418QkuosEcrs9odR8ORe0KpW5dHWUFhLBLmSjL2lPUDK0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM4PR0201MB2083; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0201MB2083; X-Forefront-PRVS: 098076C36C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(199003)(189002)(33656002)(50226002)(36756003)(66066001)(86362001)(6116002)(3846002)(42186005)(93886004)(68736007)(7736002)(189998001)(586003)(82746002)(92566002)(84326002)(83716003)(2906002)(74482002)(81166006)(57306001)(97736004)(7846002)(69556001)(105586002)(76176999)(50986999)(106356001)(2950100001)(260700001)(8676002)(110136002)(512954002)(4326007)(77096005)(101416001)(81156014)(3940600001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0201MB2083; H:[193.147.51.18]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; Received-SPF: None (protection.outlook.com: urjc.es does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM4PR0201MB2083; 23:jScHVBmg56vRW//spnUkvU8/rhU3kT7l5qm2Wp/?= =?us-ascii?Q?XTLDOMX8bMdr2gKL4s15DPkHwv9wcLFDXYA5bYZLe45aSVtDhvhdlE3uOJm0?= =?us-ascii?Q?9Y6RwoK/f4TSJo2Byfcgitp1bMzAiAbwVlzDsQAw+hjRw02pLGZLZhH8fH3M?= =?us-ascii?Q?OVG2PVEP+gWhxackh64ARO6EnEwmDZi7/OnDD8YhBrXa0UddTAiIcScnE4Sj?= =?us-ascii?Q?SUxSBxOyTuGXe1eNx8uvaiiLKswtkmGjUz/gxKcZ54hhTvWL7W2YKZeH+vpB?= =?us-ascii?Q?K6lUKzHQqzmj0OrogO0REHoIkfhDcf//QcqnR/Nrtv9dWywhDaMKyuBfxwb4?= =?us-ascii?Q?QnOveGAxHL+xh96ef26sWb1E988Rpw62fojZqX50gvp8qPLqQ5CqgAU58YuF?= =?us-ascii?Q?LCxD8Os5Lv39avfI5tCI4TSWz5D1NNgmxjR1yOdOSRecoxc4wAqm+wTKycdM?= =?us-ascii?Q?GZGik4QAkSKTPmtXn2vZNmmkxvhAMhQLXuvUHmiFh0I1Drmut9zIHH5AShhh?= =?us-ascii?Q?vf4IsHj9EIwbTAM6/HZpCih6KEFLbl96ftAlJC/anqOn3thcG8GmYGfiKad4?= =?us-ascii?Q?3Y3KHpA/OVO3qK8ZXzE0rJHacysDn6vDgTQsrb9NcpkYm6g5znPsn1K74D3R?= =?us-ascii?Q?3WAWUo+3DQEznEI/kAcx2ISLDGOerm0CzI1RTRO5/pkousJdYrL9ne+6yuAX?= =?us-ascii?Q?iA8UvG8XKRyjnObtWcHrAK/ERG/zF554PIDnkLN3tk+TYhWe1aVcvyvVOJBQ?= =?us-ascii?Q?6bNr+HAuDtmpboL1VqgLriSHG9o9+tnAVlukfeGcj3QQlQUt5JrmN4DQwpf/?= =?us-ascii?Q?WuMDKbogrv0XYr4tTOCecp9TGhC5pyw5+KM6Z3EoYYCmeYfTreI3ShAtkPKD?= =?us-ascii?Q?sphauTrQw0P3Mzof1cYfVcqZ7tfvYo8owI3KBZXjPRP1N7H7aT1K1/z3V4oh?= =?us-ascii?Q?oT1ixvHeABph0TKAIagNEBU8hY4/0vVV5WXTQW53jUPNWxYDiLctjMamWYp1?= =?us-ascii?Q?e4zEGhRq5b7lfUCZ193U0Mo8vENuGPp51soEQyZe9sKtz3w2V29vJtQzahZG?= =?us-ascii?Q?3q+ISqoXl49XukbvIk8Bo1ZxB0qbd4Q3BlITTsxqoAEvtM57vWCQTjG3MjjN?= =?us-ascii?Q?Qkp9K9fw/C4I=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR0201MB2083; 6:5b0jTotlhvVg+8b6WFw+jzy+sPXrZrvyHuV8A1NbWGIWCXfGyqCwgyqwyz+BwmZcAlTV71GykuSl/G8Z5szmgKshflS4kttireJyZvCp1L5fFxaieIWKKMSkclo9R8TYa9unmQYhJGJfI6Zs9OgfH0OuWpOBIqlMwZn9imcshLj8vTyKUrqKZAeDLCxXb0UgYYl9ua0noyfN+AKSUh+WDP3achCySjcHltFNCL+RQieK9L3N/3acQqj1Ytas99V2rjYwTt/PAHHVenZKKvVc2n2C68uPdHP1vepHP5+GSWA=; 5:NEULxDyZ+iuoRGBEFeJX6fYbhh3eNm9VBiAjQPIYUAlI/pfoLUvLR24HvZSynmZa4rLyvDaN2Y1apOpfdtaGsEMo0sVsdPMZ8giZU376tKNBqQWEbXHQ0Rpc54MyENMXc2RGNzrmgHaWLAEgJhV1UQ==; 24:+vjlHewr2PBG5qenQh+Dih5p2cX73TJtu8FkLTaYBrr3j3hsXqfDFK0slBrlVVAEBQueZ6oSvizD8ta2VVZkvgICSl7D5y93fsJBvjwidJk=; 7:lvW5CNV3HRtr4yKMyTTYNS8kMuJWlMBRXj/YinnwCB9xmx0YlB0BxQ/eR5t8PcZdDc0JCDU0En6Yp4vQ82uIp5rCuNC7kY71B4VmY5Fx7hwSIVYgFm1JFlPvHfzzlaaq1FtaVr2NlU1zuZdY0d/F1kThDgoNw04uVp+f8j7Y8SNZNHibmx39nq7sQRH4UsgRFqd4dtDwidl+ZiJpeXtLLg== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: urjc.es X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2016 08:01:43.6151 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0201MB2083 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 08:02:03 -0000 --Apple-Mail=_CE93B7E6-6C6F-4DCA-9B65-1299E18DC4C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" > Easy: let the first server route all the encodings to the end-server, > and let the end-server decide which want to route to the receiver > peer. Yes, and this supports that it might make sense on the spec to talk = about receiving simulcast, and not only sending simulcast (as the = original mail on this thread was asking for), as it makes sense (as you = recognize) to receive simulcast on some server-side scenarios.= --Apple-Mail=_CE93B7E6-6C6F-4DCA-9B65-1299E18DC4C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Easy: let the first server route all the = encodings to the end-server,
and let the end-server decide which want = to route to the receiver
peer.

Yes, and this supports that it might make = sense on the spec to talk about receiving simulcast, and not only = sending simulcast (as the original mail on this thread was asking for), = as it makes sense (as you recognize) to receive simulcast on some = server-side scenarios.
= --Apple-Mail=_CE93B7E6-6C6F-4DCA-9B65-1299E18DC4C7-- From nobody Tue Jun 21 01:05:32 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5D812D0A1 for ; Tue, 21 Jun 2016 01:05:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUU7thIx6Zng for ; Tue, 21 Jun 2016 01:05:29 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6592312D87B for ; Tue, 21 Jun 2016 01:05:29 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id i12so7132370ywa.1 for ; Tue, 21 Jun 2016 01:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1Ofa0VVxuA7GDZLpHi8nGf6upCCxqF7I6IAEr/Bij58=; b=dfvrV26Sj7TS8zDme90bU11jvo7P3ClCZbVxgxch/voWctXWviJ4wwXzwhxEsGbulZ Bq1mNywSwr/vefvkON6v2xIHNw426U8DIHI7f3HXlAF/a1S2zgYpX90fb8kT0ccMlZC1 /jf+o89ZOoTgOy+GtaF9YeiBcmkNcCo7y7f998E0bzGhi7hZnk7X9kAdVNHE3d9Oq01Z Pgdoe86GxUDSiBlyt/U9ewgJQZKkReNg7LNksmNWjQ9NTBqZEi7NAnz/Ck0ORFDOkAKe LK2x4RyTU4FIcqjkJdGTDDtQAQczRfz05YHJcwdxfdkyvlxUrU8fHuEdXQKHkojzOuTC brGQ== 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-transfer-encoding; bh=1Ofa0VVxuA7GDZLpHi8nGf6upCCxqF7I6IAEr/Bij58=; b=ZyqVCPtObCEaO+9hA7xGcFAXKsLw1c6SR/r/1uA1jldmDIzecI48A+6UzbkYjZknE/ x9w1IgAE8cSNKWZZMNthyy52cOuOdXH4OZpzx1L0NYxkki8jBPMfiLXcXfhMfd20yA/0 OeaNv7nx9tSIbCwfb92XAnL0wvHzOT9gcNijqHqNZ06yuJl9XTkq7U+eGVYoQ0cmJo09 sOqL+VxDJbdwcDPJjHUWTiLqEoP7KcGK5Y5URAimvpBlB0Q4RNJTj4hsqZzasDP5JctH l6Jsx+3zUdgopaREXWZhxObrlMxgEoa5QvUiVPp162bGDztdIZ1TOxI6D6t1jT6H89PN eZwA== X-Gm-Message-State: ALyK8tKvdnshgNh+g8inIIwWBcbJg5ijTGZPTNjaSkegSRxaDB3Rfc00ju29ghRwRe4xvv43aDGmePtsJBjIIw== X-Received: by 10.37.223.66 with SMTP id w63mr10867724ybg.172.1466496328678; Tue, 21 Jun 2016 01:05:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.7.199 with HTTP; Tue, 21 Jun 2016 01:05:09 -0700 (PDT) In-Reply-To: <26647A6B-F7F8-4999-AAC9-C7DCB87F7487@urjc.es> References: <26647A6B-F7F8-4999-AAC9-C7DCB87F7487@urjc.es> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 21 Jun 2016 10:05:09 +0200 Message-ID: To: =?UTF-8?Q?Luis_L=C3=B3pez_Fern=C3=A1ndez?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 08:05:30 -0000 2016-06-21 10:01 GMT+02:00 Luis L=C3=B3pez Fern=C3=A1ndez : > Yes, and this supports that it might make sense on the spec to talk about > receiving simulcast, and not only sending simulcast (as the original mail= on > this thread was asking for), as it makes sense (as you recognize) to rece= ive > simulcast on some server-side scenarios. I agree that a spec describing that would be useful. However, JSEP is about WebRTC endpoints implementing the spec API: > This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 21 01:29:38 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494CF12D18B for ; Tue, 21 Jun 2016 01:29:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=urjc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6btei-j7Fgk for ; Tue, 21 Jun 2016 01:29:35 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0623.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::623]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFABD12D1B3 for ; Tue, 21 Jun 2016 01:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=urjc.onmicrosoft.com; s=selector1-urjc-es; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5puKwdCkoVP9bEmUp0ovLjiJOSZmLxFYYStLJNWnzL0=; b=T3oCsRw/yy2YftTLWd3DfNwHn97rpkFx7XndSUsTI3Wfg7LnBBDa3LyhFyau1uQwxCEg62W+3s+9FEv3PwhnwxlW9hLLOLsu4KJr/CPhi63toR6yZcYMLx3HoNwFUv0/bMbZ5f3zt0r/o1JhfTW4KiKsvJmJbfb3fFvi4h7esB0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=luis.lopez@urjc.es; Received: from [193.147.51.18] (193.147.51.18) by VI1PR0201MB2094.eurprd02.prod.outlook.com (10.169.131.19) with Microsoft SMTP Server (TLS) id 15.1.511.8; Tue, 21 Jun 2016 08:29:11 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_9E4E9554-F623-4FC8-9B38-05524D94E6DD" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Luis_L=C3=B3pez_Fern=C3=A1ndez?= In-Reply-To: Date: Tue, 21 Jun 2016 10:29:06 +0200 Message-ID: <3545E396-A1F8-47C4-9E6D-2967D97471E9@urjc.es> References: <26647A6B-F7F8-4999-AAC9-C7DCB87F7487@urjc.es> To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.3124) X-Originating-IP: [193.147.51.18] X-ClientProxiedBy: DB4PR03CA0001.eurprd03.prod.outlook.com (10.160.39.139) To VI1PR0201MB2094.eurprd02.prod.outlook.com (10.169.131.19) X-MS-Office365-Filtering-Correlation-Id: 366d3cca-69b6-4d0e-539f-08d399ae1f93 X-Microsoft-Exchange-Diagnostics: 1; VI1PR0201MB2094; 2:p7FAXre2wbxR6YvBNNnaNFwDu6FiexwDwdp4T3L47i8vTo9xPaOiSYMtacwDoOhwiibMv4HXEcCUs2EC/2+swcx1OVxo53ZIsQRCcXpy1g29O4NVbbXHZQAMzlfIHXHw0MEe7A+tTNYuajlNuQncKqPgpvjCKta2mH9Z0XFcdHLswOElbM7+sgRWF5Lr96w4; 3:9a7U9XYfgVsLdqET//fBQKWbqytck6rcpKfRbQO0GRdRdkETrdwkZ05Amb6oUjt0wuZYUd7tKtjwXo7lz5ijUbBgpd+XmMsRPEsyCvPRd6y3vmmiXrbDmCtpQqve1sqR X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0201MB2094; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0201MB2094; 25:ImUExvzQiUGGF7kj9T11OoclGDd4N/Aq95k8sks1SLl9q3LaH3N1smlu+I69MBMYGvM4wC3bYL48/NjJvxYdGeikZ/7T1yIlBl2JMJ5kLCQKKgGl/g53bXZjdWFjKtBfKqD0W3t+038zxyDIGshwMsi/gEm+K2/7oiN0hyPH+GYkMeW7HrlKQPjISJDAznhxwbNDr06zS6sAZUPVzJD1ynwkUIp7492lw394XHSD2Wk0zeKJxvyHeMzPfpF1yDX5p//tF9kPg+K5Ii3ESFU5LMqMfS8OOuXciZKcSYWhhS+Ub10lgnk5MsNwA4/gHga8dtO8YbI/w6F8tHNNZqfWZTNapEOY34TKVDHZcZNKijmfxmejs1KaNUU6JFd/nOHRwaaNA4IDs/zRGAqSkYowtWNoPtyj7eKf7a+yVy9ByXyCwBZB4bZQv2tgZBz9vh4iPKgScZyQ30bnXXvpZu0Dx/L8xu9TzseUD3JhssSXhN6ahu1x3MH+Y3LRRs90SNAX04fs2Qgl62cPiDhxWVYrs8cv5vrhzp+2wwHWb4Q0MvBuyNjJV3yXH9NB7emzJx5zqsEHDOvKuLNYZhnPrrDXXzg87Nxk4ZhSYTkfdCDnGht8CUbHhBG2lp145J2d+HOr3JwExRMCm7U0DrqFrd4qlEc138plPchdEu+xX8IjlN3ZnzVEB0xQzxD/u+BMn+1GYpiT2HGr+rJyUQGSlaWePtTNm0Phjx4BNA2NhcaZNcaIIbjHx3PbmA+jSSW6AC+jwuxLMJY4A3yL9XDafGO1LqU1xyHYE9zQRJInj9yWg71iWHHRtC/vnbZZ6TqM7EKQHLDvW658Dl3ZubJZn2WCaw== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0201MB2094; 20:FdgubcqzfYicfx1tnRLy0ylMbhJpig7N4LnYr+R19wluL/HwNMjMapmBzlShbTdeFnO7PQGCBDjYop1OLvBYaR+pY0oRhFKCZAyPV7FY19Ysi5c5umA+wLM7hkKZwUq7oo4UHv01oatT+m5uW8Rq8Y2XfsEIMpwGrUpOzqf6E2ABsuoA6NQnkNmuFw+dGTGo5JsUD2igw8VnwZg4geIZ/90ONFy8alPRmz0RmyTAa2QPSTeNTMZLjYwmqcZU5Dui0TKYbkLl+qBv4kfQq/qsaEItJUOTWxyqdg6wYoUAm8wwBIYZRM0vJtJumraxSs8pfIJcCn80TTFV414NdAbuvBYcY+IiH0WDKPOoYzAdsHgpiYsepqy5son2YJ+Dy/m/yZZjPee7LjsXPdcW6XIIxTnuOuvICGFN9XGzU4XbzZlFPTHMOWSaGLHeHmYpNgYpy7BgBQK7PEiI7NS8QlkoAChN93D8Zd5NyhfPlUn5PoQE46Ul8rtct9zJJO7JiPwr; 4:DwaUD1T0hkJXUvFgiN7GGoi3IWNAGUFmrUQnY04OMQJxyP1f6OYUf2IkswiVdmsM9CobDtZqF2XUhxJW5a5FFSDZPz6xGFONYwVRwHevGjrzJQ3oib8Llh11cmPq7qO+PuVbIUcV5Y0S1iixeirUsuGRORI2fXzMimC8Kiqq4aveQDUuutuzK9iSlPuHK/J5rIPAdroHtBAx27MkFLxNlC7yA7QfBv49jB4OJRcKySnVJhxVaFGvPqCxrQ9GVCKom3uSVnGodM4p334OkrvufmfX0NC3NZjhtJDVz513C7K6qVjS/a2uJjiAeB+cAc8dTrWF/LNmFkhLCcCgNUzKSuo3lw0LW+HIdrgp8fOIgsuE2md+moSI7ayy/L4dYCTIWLi1oVvMOQzzjvLKOQbUuZojwmcEzBItwReqJH9x/64= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR0201MB2094; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0201MB2094; X-Forefront-PRVS: 098076C36C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(189002)(199003)(50986999)(101416001)(76176999)(81156014)(81166006)(7736002)(7846002)(8676002)(42186005)(2906002)(4326007)(93886004)(92566002)(57306001)(6116002)(3846002)(110136002)(69556001)(586003)(50226002)(36756003)(33656002)(68736007)(106356001)(66066001)(105586002)(83716003)(2950100001)(77096005)(97736004)(84326002)(189998001)(74482002)(82746002)(86362001)(512874002)(3940600001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0201MB2094; H:[193.147.51.18]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: urjc.es does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR0201MB2094; 23:ufy36MlOFUJfxWUI8xugazx6at0xtxMwpoYdath?= =?us-ascii?Q?zLFa/z+967Ztkd/PFpebAjFz95sQj+WTTbJMFl3kg0OlmW9YG2zxv+X5e8jw?= =?us-ascii?Q?WWDHRJHYKpo7LB5cV0cO35f8hsZywALWefVbS+6D9jcNT1HZPrQecKOAOW9C?= =?us-ascii?Q?pfa6PY6v45AfFE1AKJyK3tWzZTiiGNAwyrS+2xjeB6DKBQkA2m0cKr+0YQm1?= =?us-ascii?Q?HPYNdSntB6z5QznQ5V3gAZ9ZJb4hPaza68LhW8JCvDvnxGlZnC7FWa9GMm4g?= =?us-ascii?Q?kyOkiBzuZVwtpccmdgZaW3zjd2tzs5036ToABZpSyJqOGnkOPEE8N6v0YBz5?= =?us-ascii?Q?qJxZ0xzMSpRarOUbV3flhC3gMVyyVs+OCk0z3qSwsWdeN3vDnRo6awOzCNmX?= =?us-ascii?Q?u/9uOP2QZEC6OYYLCekvKnmbBgRhruNa+uRto2dfqgJzXty8EiUuGm8b68s5?= =?us-ascii?Q?hkXXuSeKjMN0GoxEs5eYM/hBdOowY0fV5ZjUQzEm+gwCXuNPg1dKAN6YUdSd?= =?us-ascii?Q?LxY7cjfMcB5epLjEpG07o85f6fdUnWfoxwFDMbnB/vy3evTFg2+l27R5ODUJ?= =?us-ascii?Q?KhbHUd6Hr+4oVZUQh+10rqR3n6BOYXU0Dy9uqwe8UZPpHlCGbWdpUr2zyg3K?= =?us-ascii?Q?AyfM7rNJUbyXOUojeojoFGQqXt5Ek2D4fMX9WRN9qWzRGxpfDMWlcKHJXI8F?= =?us-ascii?Q?s+DE3Rxz0Sygs4QKiakT8he/ctQbcee4bsCiEZ8pj6rC135/nwMl96HG8yW9?= =?us-ascii?Q?gS4jyKAK5vnWrYfTAYCsa8+AxFcYf0nJTL7iRhXN6EHLWFiMIOPgBgUPzBuz?= =?us-ascii?Q?rg31pBqxoYDgvbWOzeokhI5mXZ7f8sdXfbHajVaDpYFtbQ4eh5/l5Sv7VSrz?= =?us-ascii?Q?a2Z0/HqQU1C6zEZWNwXZVd4TJF/ghLjXFASopd33/NCu18HCzVNXLH8Y7aea?= =?us-ascii?Q?xEtR9cYMJQqzu/jgKipQf+jZv83EhaoMHg/u0sUZS9PJ4w6QC//IibAM/Yz3?= =?us-ascii?Q?nh+JiTwFHl/hYziGhEZhif9h5QsJU58zzOS1liYIQ9Vojd7NL+BXRcR9q8Rb?= =?us-ascii?Q?g5rDS91VAzg8Um14iaPi+wsb+bPgri30KTmxfI1HzsGWX29L3Cg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0201MB2094; 5:jp11je1Wx7lymP/L+CSgJE4vFZchxrMMhpOEAJh52zZQcqbOCCRDuadFv6GyFiar3gGyJ6p3Q405FgBCZqT/viAOdtdo87tZap4lturmzGxXGfr6qLf5Th+NPr5+iUK6YPLzDDgF6FwO2guoSfPfWA==; 24:zIQX2XsNeCWjIE2YCEbdWCflmmW/ki9lVztn/xXZjYpqR+5IJkVG6KN9DEkdMCxOD6nWhPBqMJE1JBO4B9+L+RR+Pe7kEoLgCYqdbtMG8yA=; 7:32UnsPgYI1vTmpuU8vsCd0wK9r/A7TAcMBXT61uEa36xzX2PmdfB12ZFwrTPrG0ViceAIGG7r3R2HeDyPMuU+Dr5aRa1MmXbmRIVUCC9HiDxSAhEpPQiEshlRyLtsRHsHMG+UVz6oppaiMSk/UEWaG9IZKr4qag2PKoSiIJHPnlL+Rg4w1oZnXWOK6t3hZ5Il7i4eAuln7Zt+0yk9xzJLA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: urjc.es X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2016 08:29:11.7167 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0201MB2094 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 08:29:37 -0000 --Apple-Mail=_9E4E9554-F623-4FC8-9B38-05524D94E6DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > I agree that a spec describing that would be useful. However, JSEP is > about WebRTC endpoints implementing the spec API: Nothing avoids a WebRTC server to implement a WebRTC endpoint complying = with spec API. In fact, at Kurento we have a full implementation of such = endpoint with the complete API as it is specified. This is why we have = discovered that receiving simulcast (which is a feature we need and = others might need) is not covered by the spec and it might be covered = (if there are no other reasons avoiding it) for completeness. It is true = that the spec introduction assumes a browser-to-browser scenario, but = IMO this is a somehow =E2=80=9Cartificial=E2=80=9D restriction that = could be avoided if there is the appropriate consensus. Perhaps, = fragmenting too much the specs is not always the best option. This is = basically the point of this thread and this is why we wanted to gather = opinions on this topic. --Apple-Mail=_9E4E9554-F623-4FC8-9B38-05524D94E6DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
I agree that a spec describing that would = be useful. However, JSEP is
about WebRTC endpoints implementing the = spec API:

Nothing = avoids a WebRTC server to implement a WebRTC endpoint complying with = spec API. In fact, at Kurento we have a full implementation of such = endpoint with the complete API as it is specified. This is why we have = discovered that receiving simulcast (which is a feature we need and = others might need) is not covered by the spec and it might be covered = (if there are no other reasons avoiding it) for completeness. It is true = that the spec introduction assumes a browser-to-browser scenario, but = IMO this is a somehow =E2=80=9Cartificial=E2=80=9D restriction that = could be avoided if there is the appropriate consensus. Perhaps, = fragmenting too much the specs is not always the best option. This is = basically the point of this thread and this is why we wanted to gather = opinions on this topic.


= --Apple-Mail=_9E4E9554-F623-4FC8-9B38-05524D94E6DD-- From nobody Tue Jun 21 01:36:05 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2285A12D0E6 for ; Tue, 21 Jun 2016 01:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRZ2NTGNEK3A for ; Tue, 21 Jun 2016 01:36:02 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC6512B02E for ; Tue, 21 Jun 2016 01:36:01 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 4C57A23F0420; Tue, 21 Jun 2016 10:36:00 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Tue, 21 Jun 2016 10:35:59 +0200 From: "Hutton, Andrew" To: Ted Hardie Thread-Topic: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports - return. Thread-Index: AQHRytwmYEeUypUvHka/duhQgJpE6J/yf3sAgAEO4XA= Date: Tue, 21 Jun 2016 08:35:58 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF261485CC@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF26147002@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF261485CCMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports - return. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 08:36:04 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF261485CCMCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVkIC8gQWxsLA0KDQpUaGFua3MgZm9yIHN1Z2dlc3Rpbmcgc29tZSB0ZXh0IGJ1dCB5b3Vy IHRleHQgaXMgSSBiZWxpZXZlIG5vdCBjb3JyZWN0IGluIHRoYXQgc2VjdGlvbiA2LjIgb2YgZHJh ZnQtaWV0Zi1ydGN3ZWItcmV0dXJuIG9ubHkgY292ZXJzIHRoZSBjb25mbGljdCBiZXR3ZWVuIGF1 dG8tZGlzY292ZXJlZCBhbmQgY29uZmlndXJlZCBUVVJOIHNlcnZlcnMgbm90IHRoZSBjb25mbGlj dCBiZXR3ZWVuIGNvbmZpZ3VyZWQvYXV0by1kaXNjb3ZlcmVkIGFuZCBhcHBsaWNhdGlvbiBwcm92 aWRlZCBUVVJOIHNlcnZlcnMuIEkgdGhlcmVmb3JlIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyB0ZXh0 Og0K4oCcV2ViUlRDIGJyb3dzZXJzIE1VU1Qgc3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIFNUVU4g YW5kIFRVUk4gc2VydmVycywgYm90aCBmcm9tIGJyb3dzZXIgY29uZmlndXJhdGlvbiBhbmQgZnJv bSBhbiBhcHBsaWNhdGlvbi4gV2ViUlRDIGJyb3dzZXJzIE1BWSBhbHNvIGRpc2NvdmVyIFRVUk4g c2VydmVycyB1c2luZyBUVVJOIEF1dG8tRGlzY292ZXJ5IFtkcmFmdC1pZXRmLXRyYW0tdHVybi1z ZXJ2ZXItZGlzY292ZXJ5XS4gVG8gcmVzb2x2ZSBjb25mbGljdHMgYmV0d2VlbiBUVVJOIHNlcnZl cnMgcHJvdmlkZWQgYnkgY29uZmlndXJhdGlvbiwgYXV0by1kaXNjb3ZlcnksIGFuZCB0aGUgYXBw bGljYXRpb24gV2ViUlRDIGJyb3dzZXJzIE1BWSBpbXBsZW1lbnQgdGhlIHByb2NlZHVyZXMgc3Bl Y2lmaWVkIGluIFJlY3Vyc2l2ZWx5IEVuY2Fwc3VsYXRlZCBUVVJOIChSRVRVUk4pIFtkcmFmdC1p ZXRmLXJ0Y3dlYi1yZXR1cm5d4oCdLg0KUGVyc29uYWxseSBJIHRoaW5rIGl0IHdvdWxkIGJlIGJl dHRlciB0byBtYWtlIFJFVFVSTiBhIOKAnE1VU1TigJ0gbGV2ZWwgcmVxdWlyZW1lbnQgYXMgZ2V0 dGluZyBjb25zaXN0ZW5jeSBpbiB0aGUgYnJvd3NlciBpbXBsZW1lbnRhdGlvbnMgaGVyZSBpcyBJ IHRoaW5rIGltcG9ydGFudCBidXQgSSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBtaWdodCBiZSB0b28g bXVjaCBmb3IgbWFueSBwZW9wbGUgYW5kIHRoZXJlIGFyZSBubyBpbXBsZW1lbnRhdGlvbnMgb3V0 IHRoZXJlIGF0IHRoZSBtb21lbnQuDQoNClJlZ2FyZHMNCkFuZHkNCg0KDQoNCg0KRnJvbTogVGVk IEhhcmRpZSBbbWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IDIwIEp1bmUgMjAxNiAx ODo0NA0KVG86IEh1dHRvbiwgQW5kcmV3DQpDYzogQ3VsbGVuIEplbm5pbmdzOyBSVENXZWIgSUVU Rg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdHTEMgY29tbWVudCBvbiBkcmFmdC1pZXRmLXJ0Y3dl Yi10cmFuc3BvcnRzIC0gcmV0dXJuLg0KDQpIaSBBbmRyZXcsDQpUaGFua3MgZm9yIHJlLXJlYWRp bmcgdGhlIGRyYWZ0IGZvciBsYXN0IGNhbGwuDQpJZiB0aGUgZm9sbG93aW5nOiAiV2ViUlRDIGJy b3dzZXJzIE1VU1Qgc3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIFNUVU4gYW5kIFRVUk4gc2VydmVy cywgYm90aCBmcm9tIGJyb3dzZXIgY29uZmlndXJhdGlvbiBhbmQgZnJvbSBhbiBhcHBsaWNhdGlv bi4iICB3ZXJlIG1vZGlmaWVkIHRvICJXZWJSVEMgYnJvd3NlcnMgTVVTVCBzdXBwb3J0IGNvbmZp Z3VyYXRpb24gb2YgU1RVTiBhbmQgVFVSTiBzZXJ2ZXJzLCBib3RoIGZyb20gYnJvd3NlciBjb25m aWd1cmF0aW9uIGFuZCBmcm9tIGFuIGFwcGxpY2F0aW9uLiAgSWYgYSBXZWJSVEMgYnJvd3NlciBp bXBsZW1lbnRzIFJFVFVSTiBbZHJhZnQtaWV0Zi1ydGN3ZWItcmV0dXJuXSB0byBwZXJtaXQgdGhl IHVzZSBvZiBUVVJOIHByb3hpZXMsIGl0IHNob3VsZCByZXNvbHZlIGNvbmZsaWN0cyBhbW9uZyBk aXNjb3ZlcmVkIG9yIGNvbmZpZ3VyZWQgcHJveGllcyBhcyBzZXQgb3V0IGluIHNlY3Rpb24gNi4y IG9mIFtkcmFmdC1pZXRmLXJ0Y3dlYi1yZXR1cm5dLiIgd291bGQgdGhhdCByZXNvbHZlIHRoZSBp c3N1ZSBmb3IgeW91Pw0KcmVnYXJkcywNClRlZA0KDQpPbiBNb24sIEp1biAyMCwgMjAxNiBhdCAz OjExIEFNLCBIdXR0b24sIEFuZHJldyA8YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb208bWFpbHRvOmFu ZHJldy5odXR0b25AdW5pZnkuY29tPj4gd3JvdGU6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy0xNCNzZWN0aW9uLTMuNCBzdGF0ZXMgIldl YlJUQyBicm93c2VycyBNVVNUIHN1cHBvcnQgY29uZmlndXJhdGlvbiBvZiBTVFVOIGFuZCBUVVJO IHNlcnZlcnMsIGJvdGggZnJvbSBicm93c2VyIGNvbmZpZ3VyYXRpb24gYW5kIGZyb20gYW4gYXBw bGljYXRpb24iLg0KDQpUaGUgcmV0dXJuIGRyYWZ0IChkcmFmdC1pZXRmLXJ0Y3dlYi1yZXR1cm4p IGV4cGxhaW5zIGhvdyB0byBkZWFsIHdpdGggdGhlIHNpdHVhdGlvbiB3aGVuIGJvdGggYXJlIGF2 YWlsYWJsZSBhbmQgYWN0dWFsbHkgdGhpcyBhbHNvIGNvdmVycyB0aGUgY2FzZSB3aGVuIGEgVFVS TiBzZXJ2ZXIgaXMgYXV0by1kaXNjb3ZlcmVkIGFzIHdlbGwgYXMgYmVpbmcgcHJvdmlkZWQgYnkg dGhlIGFwcGxpY2F0aW9uLiAgU28gc2hvdWxkIHRoZSB0ZXh0IGJlIGV4cGFuZGVkIHRvIHNheSB0 aGF0ICJjb25maWd1cmF0aW9uIiBhbHNvIGluY2x1ZGVkIGF1dG8tZGlzY292ZXJ5IGFuZCBpbmNs dWRlIGEgcmVmZXJlbmNlIHRvIC1ydGN3ZWItcmV0dXJuPw0KDQpTb3JyeSBmb3IgdGhlIGxhc3Qg bWludXRlIGNvbW1lbnQgSSBoYXZlIHJlYWQgdGhpcyBzbyBtYW55IHRpbWVzIGJlZm9yZS4NCg0K UmVnYXJkcw0KQW5keQ0KDQoNCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dl Yi1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEN1bGxlbg0KPiBKZW5uaW5ncw0KPiBT ZW50OiAwOSBKdW5lIDIwMTYgMTg6MzYNCj4gVG86IFJUQ1dlYiBJRVRGDQo+IFN1YmplY3Q6IFty dGN3ZWJdIFdHTEMgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cw0KPg0KPiBUaGlzIGlz IHRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNw b3J0cy0xNA0KPg0KPiBQbGVhc2Ugc2VuZCBhbnkgY29tbWVudHMgdG8gdGhpcyBsaXN0IGJ5IEp1 bmUgMjIsIDIwMTYuDQo+DQo+IFRoYW5rcywNCj4gQ3VsbGVuLCBUZWQsIGFuZCBTZWFuDQo+DQo+ DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJA aWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3 ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF261485CCMCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmgxDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1s aW5rOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjI0LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhlYWRpbmcxQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSGVhZGluZyAxIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHls ZS1saW5rOiJIZWFkaW5nIDEiOw0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBUZWQgLyBBbGwsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyBmb3Igc3VnZ2VzdGluZyBzb21lIHRleHQgYnV0IHlvdXIgdGV4dCBpcyBJIGJl bGlldmUgbm90IGNvcnJlY3QgaW4gdGhhdCBzZWN0aW9uIDYuMiBvZiBkcmFmdC1pZXRmLXJ0Y3dl Yi1yZXR1cm4gb25seSBjb3ZlcnMgdGhlIGNvbmZsaWN0IGJldHdlZW4gYXV0by1kaXNjb3ZlcmVk IGFuZCBjb25maWd1cmVkIFRVUk4gc2VydmVycyBub3QgdGhlIGNvbmZsaWN0IGJldHdlZW4gY29u ZmlndXJlZC9hdXRvLWRpc2NvdmVyZWQNCiBhbmQgYXBwbGljYXRpb24gcHJvdmlkZWQgVFVSTiBz ZXJ2ZXJzLiBJIHRoZXJlZm9yZSBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgdGV4dDo8bzpwPjwvbzpw PjwvcD4NCjxoMSBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtd2VpZ2h0Om5vcm1hbCI+4oCcV2ViUlRDIGJyb3dzZXJzIE1V U1Qgc3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIFNUVU4gYW5kIFRVUk4gc2VydmVycywgYm90aCBm cm9tIGJyb3dzZXIgY29uZmlndXJhdGlvbiBhbmQgZnJvbSBhbiBhcHBsaWNhdGlvbi4mbmJzcDtX ZWJSVEMgYnJvd3NlcnMgTUFZIGFsc28gZGlzY292ZXIgVFVSTiBzZXJ2ZXJzDQogdXNpbmcgVFVS TiBBdXRvLURpc2NvdmVyeSBbZHJhZnQtaWV0Zi10cmFtLXR1cm4tc2VydmVyLWRpc2NvdmVyeV0u IFRvIHJlc29sdmUgY29uZmxpY3RzIGJldHdlZW4gVFVSTiBzZXJ2ZXJzIHByb3ZpZGVkIGJ5IGNv bmZpZ3VyYXRpb24sIGF1dG8tZGlzY292ZXJ5LCBhbmQgdGhlIGFwcGxpY2F0aW9uIFdlYlJUQyBi cm93c2VycyBNQVkgaW1wbGVtZW50IHRoZSBwcm9jZWR1cmVzIHNwZWNpZmllZCBpbiBSZWN1cnNp dmVseSBFbmNhcHN1bGF0ZWQgVFVSTg0KIChSRVRVUk4pIFtkcmFmdC1pZXRmLXJ0Y3dlYi1yZXR1 cm5d4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvaDE+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJz b25hbGx5IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIG1ha2UgUkVUVVJOIGEg4oCcTVVT VOKAnSBsZXZlbCByZXF1aXJlbWVudCBhcyBnZXR0aW5nIGNvbnNpc3RlbmN5IGluIHRoZSBicm93 c2VyIGltcGxlbWVudGF0aW9ucyBoZXJlIGlzIEkgdGhpbmsgaW1wb3J0YW50IGJ1dCBJIHVuZGVy c3RhbmQgdGhhdCB0aGlzIG1pZ2h0IGJlIHRvbyBtdWNoIGZvciBtYW55IHBlb3BsZSBhbmQgdGhl cmUgYXJlIG5vDQogaW1wbGVtZW50YXRpb25zIG91dCB0aGVyZSBhdCB0aGUgbW9tZW50LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVkIEhhcmRp ZSBbbWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyMCBKdW5l IDIwMTYgMTg6NDQ8YnI+DQo8Yj5Ubzo8L2I+IEh1dHRvbiwgQW5kcmV3PGJyPg0KPGI+Q2M6PC9i PiBDdWxsZW4gSmVubmluZ3M7IFJUQ1dlYiBJRVRGPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb cnRjd2ViXSBXR0xDIGNvbW1lbnQgb24gZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cyAtIHJl dHVybi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+SGkgQW5kcmV3LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYW5rcyBmb3IgcmUtcmVhZGluZyB0aGUg ZHJhZnQgZm9yIGxhc3QgY2FsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JZiB0aGUgZm9sbG93aW5nOiAm cXVvdDtXZWJSVEMgYnJvd3NlcnMgTVVTVCBzdXBwb3J0IGNvbmZpZ3VyYXRpb24gb2YgU1RVTiBh bmQgVFVSTiBzZXJ2ZXJzLCBib3RoIGZyb20gYnJvd3NlciBjb25maWd1cmF0aW9uIGFuZCBmcm9t IGFuIGFwcGxpY2F0aW9uLiZxdW90OyZuYnNwOyB3ZXJlIG1vZGlmaWVkIHRvICZxdW90O1dlYlJU QyBicm93c2VycyBNVVNUIHN1cHBvcnQgY29uZmlndXJhdGlvbg0KIG9mIFNUVU4gYW5kIFRVUk4g c2VydmVycywgYm90aCBmcm9tIGJyb3dzZXIgY29uZmlndXJhdGlvbiBhbmQgZnJvbSBhbiBhcHBs aWNhdGlvbi4mbmJzcDsgSWYgYSBXZWJSVEMgYnJvd3NlciBpbXBsZW1lbnRzIFJFVFVSTiBbZHJh ZnQtaWV0Zi1ydGN3ZWItcmV0dXJuXSB0byBwZXJtaXQgdGhlIHVzZSBvZiBUVVJOIHByb3hpZXMs IGl0IHNob3VsZCByZXNvbHZlIGNvbmZsaWN0cyBhbW9uZyBkaXNjb3ZlcmVkIG9yIGNvbmZpZ3Vy ZWQgcHJveGllcyBhcyBzZXQNCiBvdXQgaW4gc2VjdGlvbiA2LjIgb2YgW2RyYWZ0LWlldGYtcnRj d2ViLXJldHVybl0uJnF1b3Q7IHdvdWxkIHRoYXQgcmVzb2x2ZSB0aGUgaXNzdWUgZm9yIHlvdT88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5yZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UZWQmbmJzcDsgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gTW9uLCBKdW4gMjAsIDIwMTYgYXQgMzoxMSBBTSwgSHV0dG9uLCBBbmRyZXcgJmx0 OzxhIGhyZWY9Im1haWx0bzphbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmFuZHJldy5odXR0b25AdW5pZnkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy0xNCNzZWN0aW9uLTMuNCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3Bv cnRzLTE0I3NlY3Rpb24tMy40PC9hPiBzdGF0ZXMgJnF1b3Q7V2ViUlRDIGJyb3dzZXJzIE1VU1Qg c3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIFNUVU4gYW5kDQogVFVSTiBzZXJ2ZXJzLCBib3RoIGZy b20gYnJvd3NlciBjb25maWd1cmF0aW9uIGFuZCBmcm9tIGFuIGFwcGxpY2F0aW9uJnF1b3Q7Ljxi cj4NCjxicj4NClRoZSByZXR1cm4gZHJhZnQgKGRyYWZ0LWlldGYtcnRjd2ViLXJldHVybikgZXhw bGFpbnMgaG93IHRvIGRlYWwgd2l0aCB0aGUgc2l0dWF0aW9uIHdoZW4gYm90aCBhcmUgYXZhaWxh YmxlIGFuZCBhY3R1YWxseSB0aGlzIGFsc28gY292ZXJzIHRoZSBjYXNlIHdoZW4gYSBUVVJOIHNl cnZlciBpcyBhdXRvLWRpc2NvdmVyZWQgYXMgd2VsbCBhcyBiZWluZyBwcm92aWRlZCBieSB0aGUg YXBwbGljYXRpb24uJm5ic3A7IFNvIHNob3VsZCB0aGUgdGV4dCBiZSBleHBhbmRlZA0KIHRvIHNh eSB0aGF0ICZxdW90O2NvbmZpZ3VyYXRpb24mcXVvdDsgYWxzbyBpbmNsdWRlZCBhdXRvLWRpc2Nv dmVyeSBhbmQgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byAtcnRjd2ViLXJldHVybj88YnI+DQo8YnI+ DQpTb3JyeSBmb3IgdGhlIGxhc3QgbWludXRlIGNvbW1lbnQgSSBoYXZlIHJlYWQgdGhpcyBzbyBt YW55IHRpbWVzIGJlZm9yZS48YnI+DQo8YnI+DQpSZWdhcmRzPGJyPg0KQW5keTxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQomZ3Q7IEZyb206IHJ0Y3dlYiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZyI+cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Yg Q3VsbGVuPGJyPg0KJmd0OyBKZW5uaW5nczxicj4NCiZndDsgU2VudDogMDkgSnVuZSAyMDE2IDE4 OjM2PGJyPg0KJmd0OyBUbzogUlRDV2ViIElFVEY8YnI+DQomZ3Q7IFN1YmplY3Q6IFtydGN3ZWJd IFdHTEMgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0czxicj4NCiZndDs8YnI+DQomZ3Q7 IFRoaXMgaXMgdGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXJ0Y3dl Yi10cmFuc3BvcnRzLTE0PGJyPg0KJmd0Ozxicj4NCiZndDsgUGxlYXNlIHNlbmQgYW55IGNvbW1l bnRzIHRvIHRoaXMgbGlzdCBieSBKdW5lIDIyLCAyMDE2Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRo YW5rcyw8YnI+DQomZ3Q7IEN1bGxlbiwgVGVkLCBhbmQgU2Vhbjxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_9F33F40F6F2CD847824537F3C4E37DDF261485CCMCHP04MSXglobal_-- From nobody Tue Jun 21 01:41:08 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1768C12B00C for ; Tue, 21 Jun 2016 01:41:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYaiZt8NrkFB for ; Tue, 21 Jun 2016 01:41:05 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0608E12D80A for ; Tue, 21 Jun 2016 01:40:57 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id b72so7790852ywa.3 for ; Tue, 21 Jun 2016 01:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zit5w0nhrKLgdw7l7Y5Bd6uha4HWAr8x7Ppc3zqIb9U=; b=B1k2cguBY/xmQ7Br6mVhewWyfddSgQZZOftWUiDHZ7SHII+j3rReQABL7JmhO+yH+A K/86nFrnwTLl1Yg1EywfWdSlwpqYfKfnaxhyTAyp5Ia/jRJYPaavk8HV4w83nsDwmN3k 9Qka+v0/9O0/pvzLGQ/rmh6Yg4ViXEYtubRmMHyd7CNkgYKR7TyGvP7rhhCd9Ek5SttZ boRca7OVzrWBrOw+poHCINJVWRqEmNQsI3SEvCnZwjVsyD9q6YDDCU7BwZ9bMoIZ2CfZ jcDfwDjL+rcVC9IavF19uvRxc8WiILgZeP9p0duXDkayL1f9NpJxWtZnIVX6NmFRs1Yy TTwg== 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-transfer-encoding; bh=zit5w0nhrKLgdw7l7Y5Bd6uha4HWAr8x7Ppc3zqIb9U=; b=PCjRUpepS6tZgDQK5ihJ2jDBRLfNXNbEwPLsa5i5mNIIWto+ijJBQDW5Wo4C/GY3el E896uuD7ZAd0GhpoWlb0KbezYEnwuj9uz+IIMP42mlB1MdfKvmjBU5OrvuSa54o5aEP7 hxsYw+FZE+bLy43EjkDowoAEe3ICQhMGYsJM8otXsXyBgv4x2nIJsIYloLKQmJUagrR/ mNFj3OrLvY0unOYLZMRDkq2bGJJ4+qDfq6DJw971LmVStSSP9Ax5hHOhHvrhKE8RoEiH DEAg/93rGWZhID9n9RJawbRduiKXRNNGvkvt7RekDbefw4IXymo7LHprs+kSjGHTPLmj MzCA== X-Gm-Message-State: ALyK8tIHAmRhQJn8uQWaNOP33nyNSRBLew3EP1oxsJQZ9JEnkGMFS03C9Flw3JXa/E1/8FkXDxGoNciL5BVpzw== X-Received: by 10.37.51.134 with SMTP id z128mr11057192ybz.178.1466498456224; Tue, 21 Jun 2016 01:40:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.7.199 with HTTP; Tue, 21 Jun 2016 01:40:36 -0700 (PDT) In-Reply-To: <3545E396-A1F8-47C4-9E6D-2967D97471E9@urjc.es> References: <26647A6B-F7F8-4999-AAC9-C7DCB87F7487@urjc.es> <3545E396-A1F8-47C4-9E6D-2967D97471E9@urjc.es> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 21 Jun 2016 10:40:36 +0200 Message-ID: To: =?UTF-8?Q?Luis_L=C3=B3pez_Fern=C3=A1ndez?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 08:41:07 -0000 2016-06-21 10:29 GMT+02:00 Luis L=C3=B3pez Fern=C3=A1ndez : > Nothing avoids a WebRTC server to implement a WebRTC endpoint complying w= ith > spec API. In fact, at Kurento we have a full implementation of such endpo= int > with the complete API as it is specified. This is why we have discovered > that receiving simulcast (which is a feature we need and others might nee= d) > is not covered by the spec and it might be covered (if there are no other > reasons avoiding it) for completeness. It is true that the spec introduct= ion > assumes a browser-to-browser scenario, but IMO this is a somehow > =E2=80=9Cartificial=E2=80=9D restriction that could be avoided if there i= s the appropriate > consensus. Perhaps, fragmenting too much the specs is not always the best > option. This is basically the point of this thread and this is why we wan= ted > to gather opinions on this topic. Again, I agree with you. However, I think that receiving simulcast is not present in the spec because it's hard to define it in concrete terms. Basically a server may do whatever it wants and it's so hard to document a concrete set of features. It comes to my mind a similar scenario regarding SIP and B2BUA servers. There is no one RFC defining what a B2BUA is or what it must be, nor how it must behave. Coming back to the original topic, the spec cannot easily define receiving simulcast (in browsers) because it "breaks" the current API: a RtpReceiver is supposed to have a single associated MediaStreamTrack. However, if multiple encoding are received at the same time, it's hard to figure out how to deal with that without generating multiple MediaStreamTracks (which would break the spec). --=20 I=C3=B1aki Baz Castillo From nobody Tue Jun 21 03:57:50 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8622812B029 for ; Tue, 21 Jun 2016 03:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnCosfO8N3uP for ; Tue, 21 Jun 2016 03:57:47 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD50C12B01B for ; Tue, 21 Jun 2016 03:57:46 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-ca-57691da82912 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4E.2D.12926.8AD19675; Tue, 21 Jun 2016 12:57:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.241]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0294.000; Tue, 21 Jun 2016 12:57:44 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Bernard Aboba , "rtcweb@ietf.org" Thread-Topic: [rtcweb] JSEP: simulcast reception not supported? Thread-Index: AQHRx8zt7SNfqO19PUuW0pPEj2PW6g== Date: Tue, 21 Jun 2016 10:57:43 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B375E3C27@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2J7uO4K2cxwgx9bLS027PvPbLH2Xzu7 A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx6v4ZtoJL7BWdPStYGxg3snUxcnJICJhI PL+5kRXCFpO4cG89UJyLQ0jgCKPEhJ9NLBDOEkaJn62tTCBVbAKBElv3LQDrFhEIkmjrWsgI YgsL2EksePmBCSJuL3Hq1S2oGj2J1h0HgTZwcLAIqEpM/iMBEuYV8JWYc/EFWKuQQIDEzBtH 2EFsRqAjvp9aAzaGWUBc4taT+UwQxwlILNlznhnCFpV4+fgf1NFKEo1LnrBC1OtJ3Jg6hQ3C 1pZYtvA1M8QuQYmTM5+wTGAUmYVk7CwkLbOQtMxC0rKAkWUVo2hxanFSbrqRsV5qUWZycXF+ nl5easkmRmA8HNzyW3UH4+U3jocYBTgYlXh4FfQzwoVYE8uKK3MPMUpwMCuJ8MpJZYYL8aYk VlalFuXHF5XmpBYfYpTmYFES5/V/qRguJJCeWJKanZpakFoEk2Xi4JRqYLS2fZb36FdojM28 rZ8qI94LpSsd/jZL9MfSXft1JRiXHT6fG69UdXaOn+e1w0/vCKurv7oRt235/9M8+uyTTwZH fTsnlWfa9y/xXv+1lR2F0efm9cg/5mZLEl40c7JGm5HWA9OEr9lnXlYsUEiOnLHjmG/5RB8Z 9UlypZWcCz2zP0qJbEj9dliJpTgj0VCLuag4EQDIOnkdgwIAAA== Archived-At: Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 10:57:49 -0000 On 16/06/16 14:45, Bernard Aboba wrote:=0A= > JSEP Section 5.2.1 talks about the initial offer and simulcasting in an= =0A= > RtpSender. However Section 5.3.1 (Initial Answers) does not describe=0A= > simulcast in an RtpReceiver. Also, Section 5.9 (Applying an Answer)=0A= > only talks about sending of simulcast streams, not receiving.=0A= >=0A= > Are we to conclude that JSEP only supports sending of simulcast, but=0A= > that an RtpReceiver should only expect to receive a single RTP stream?= =0A= =0A= FWIW,=0A= =0A= simulcast was discussed a bit at TPAC last fall, and there it was =0A= proposed to leave simulcast reception out of scope for WebRTC 1.0 (and =0A= no one expressed a different opinion). See minutes [1] and slides [2] =0A= (simulcast reception was discussed last).=0A= =0A= =0A= [1] https://www.w3.org/2015/10/28-webrtc-minutes#item07=0A= [2] =0A= https://www.w3.org/2011/04/webrtc/wiki/images/e/e3/Simulcast_at_TPAC_2015.p= df=0A= From nobody Tue Jun 21 07:24:12 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AED12B04B for ; Tue, 21 Jun 2016 07:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lyUC__cJMwd for ; Tue, 21 Jun 2016 07:24:09 -0700 (PDT) Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFBA12B046 for ; Tue, 21 Jun 2016 07:24:08 -0700 (PDT) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 254003804C6; Tue, 21 Jun 2016 10:24:03 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 3849138042C; Tue, 21 Jun 2016 10:24:02 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 21 Jun 2016 10:24:03 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF261485CC@MCHP04MSX.global-ad.net> Date: Tue, 21 Jun 2016 08:24:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F33F40F6F2CD847824537F3C4E37DDF26147002@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF261485CC@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports - return. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 14:24:11 -0000 I don't think we had consensus on MUST do RETURN. It is very clear that = browser are not forbidden from doing RETURN so saying MAY implement some = RFC does not seem very controversial as long as it does not extend the = list of normative dependencies.=20 > On Jun 21, 2016, at 2:35 AM, Hutton, Andrew = wrote: >=20 > Hi Ted / All, > =20 > Thanks for suggesting some text but your text is I believe not correct = in that section 6.2 of draft-ietf-rtcweb-return only covers the conflict = between auto-discovered and configured TURN servers not the conflict = between configured/auto-discovered and application provided TURN = servers. I therefore suggest the following text: > =E2=80=9CWebRTC browsers MUST support configuration of STUN and TURN = servers, both from browser configuration and from an application. WebRTC = browsers MAY also discover TURN servers using TURN Auto-Discovery = [draft-ietf-tram-turn-server-discovery]. To resolve conflicts between = TURN servers provided by configuration, auto-discovery, and the = application WebRTC browsers MAY implement the procedures specified in = Recursively Encapsulated TURN (RETURN) [draft-ietf-rtcweb-return]=E2=80=9D= . >=20 > Personally I think it would be better to make RETURN a =E2=80=9CMUST=E2=80= =9D level requirement as getting consistency in the browser = implementations here is I think important but I understand that this = might be too much for many people and there are no implementations out = there at the moment. > =20 > Regards > Andy > =20 > =20 > =20 > =20 > From: Ted Hardie [mailto:ted.ietf@gmail.com]=20 > Sent: 20 June 2016 18:44 > To: Hutton, Andrew > Cc: Cullen Jennings; RTCWeb IETF > Subject: Re: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports - = return. > =20 > Hi Andrew, >=20 > Thanks for re-reading the draft for last call. >=20 > If the following: "WebRTC browsers MUST support configuration of STUN = and TURN servers, both from browser configuration and from an = application." were modified to "WebRTC browsers MUST support = configuration of STUN and TURN servers, both from browser configuration = and from an application. If a WebRTC browser implements RETURN = [draft-ietf-rtcweb-return] to permit the use of TURN proxies, it should = resolve conflicts among discovered or configured proxies as set out in = section 6.2 of [draft-ietf-rtcweb-return]." would that resolve the issue = for you? >=20 > regards, >=20 > Ted =20 > =20 > On Mon, Jun 20, 2016 at 3:11 AM, Hutton, Andrew = wrote: > = https://tools.ietf.org/html/draft-ietf-rtcweb-transports-14#section-3.4 = states "WebRTC browsers MUST support configuration of STUN and TURN = servers, both from browser configuration and from an application". >=20 > The return draft (draft-ietf-rtcweb-return) explains how to deal with = the situation when both are available and actually this also covers the = case when a TURN server is auto-discovered as well as being provided by = the application. So should the text be expanded to say that = "configuration" also included auto-discovery and include a reference to = -rtcweb-return? >=20 > Sorry for the last minute comment I have read this so many times = before. >=20 > Regards > Andy >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen > > Jennings > > Sent: 09 June 2016 18:36 > > To: RTCWeb IETF > > Subject: [rtcweb] WGLC of draft-ietf-rtcweb-transports > > > > This is the working group last call for = draft-ietf-rtcweb-transports-14 > > > > Please send any comments to this list by June 22, 2016. > > > > Thanks, > > Cullen, Ted, and Sean > > > > > > > > > > _______________________________________________ > > 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 Tue Jun 21 22:49:00 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBB612D58E for ; Tue, 21 Jun 2016 22:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pswVESQFuByD for ; Tue, 21 Jun 2016 22:48:55 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA3E12D181 for ; Tue, 21 Jun 2016 22:48:55 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id v77so33868010ywg.0 for ; Tue, 21 Jun 2016 22:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cQkoG2dbyd96U5pL9fqinYVbspQtj1QVImVD6xIO9jM=; b=pQ2q0TXmAYo2DYbkh29ZFIDezVugJpVGmZRzNoPaXE4RN/3JNW3y5pQh/SPt6BcUrn 9YABHaVTSjJBa9OYSEvPaXmBILCVm1/j2/ZzJWZQnA4mN0MhdeOFHOCJQa/YokQ/4BZu +QApFxEvfpP90wMDbCzcdOV7b6bFWEjeO+dXUvFSrORqZJvIIB5YTCkVNxvTqz7Vm9nV qS85G+YmdqaOO+US7zHQkWVGbfGVsDX0HSBUFhwme3GmTWCsxiB3TomrBjVVlgTtHRJv 1V1a0JPdE5I/tCPkq+dxAoVWYqsMjd0zm7dyvS9VN1eLRZ35JkuEUYWSS77Il4UJxfs7 ZxOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=cQkoG2dbyd96U5pL9fqinYVbspQtj1QVImVD6xIO9jM=; b=fr/vq93KUEwqZSS7XMtDifQCTXwtxhl1qrz5P/ZVcEBi1h1zyzDGxQOfzv1y453KV0 t0OAY4jALubbDuQeb/V3lETCcinwZdKsvPvKEHDGOLXj3rwBTd8g57Uguf7bFTiBsy1P 5PsILlTkZbdCAle/DGPb09FnTh+LGhZeoQYPql7VgtIvaQJotLc5+AKfZPW/9Arvsb8Q Fg89rxsiaMyG5nj2whPBvbO0jXdSz5uXpyH/S4gFErietX4zciyKguqvGkcTNDFf/4+3 Uq0n68VijnNhuvJlATqZnMl8921C4ppc7bY6gsec8sK4t6z6Zr6HcGEwy0N5x7hzH1Ld FKgw== X-Gm-Message-State: ALyK8tLKynoGKODuE4dzoaZXu4AJ9s3lq+IkeGmK9s/jw/zKxNwB9tl3RfJ3c0gNdYCod05KmIqJufJMGgEGWQ== X-Received: by 10.129.84.193 with SMTP id i184mr13905899ywb.285.1466574534871; Tue, 21 Jun 2016 22:48:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.240.194 with HTTP; Tue, 21 Jun 2016 22:48:35 -0700 (PDT) In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF26147002@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF261485CC@MCHP04MSX.global-ad.net> From: Michael Davey Date: Wed, 22 Jun 2016 06:48:35 +0100 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a114d9a5030114e0535d77ee0 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports - return. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: md84419@gmail.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, 22 Jun 2016 05:48:58 -0000 --001a114d9a5030114e0535d77ee0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Could we pick the middle ground and make it an "are RECOMMENDED to"? --=20 Michael On 21 June 2016 at 15:24, Cullen Jennings wrote: > > I don't think we had consensus on MUST do RETURN. It is very clear that > browser are not forbidden from doing RETURN so saying MAY implement some > RFC does not seem very controversial as long as it does not extend the li= st > of normative dependencies. > > > > On Jun 21, 2016, at 2:35 AM, Hutton, Andrew > wrote: > > > > Hi Ted / All, > > > > Thanks for suggesting some text but your text is I believe not correct > in that section 6.2 of draft-ietf-rtcweb-return only covers the conflict > between auto-discovered and configured TURN servers not the conflict > between configured/auto-discovered and application provided TURN servers.= I > therefore suggest the following text: > > =E2=80=9CWebRTC browsers MUST support configuration of STUN and TURN se= rvers, > both from browser configuration and from an application. WebRTC browsers > MAY also discover TURN servers using TURN Auto-Discovery > [draft-ietf-tram-turn-server-discovery]. To resolve conflicts between TUR= N > servers provided by configuration, auto-discovery, and the application > WebRTC browsers MAY implement the procedures specified in Recursively > Encapsulated TURN (RETURN) [draft-ietf-rtcweb-return]=E2=80=9D. > > > > Personally I think it would be better to make RETURN a =E2=80=9CMUST=E2= =80=9D level > requirement as getting consistency in the browser implementations here is= I > think important but I understand that this might be too much for many > people and there are no implementations out there at the moment. > > > > Regards > > Andy > > > > > > > > > > From: Ted Hardie [mailto:ted.ietf@gmail.com] > > Sent: 20 June 2016 18:44 > > To: Hutton, Andrew > > Cc: Cullen Jennings; RTCWeb IETF > > Subject: Re: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports - > return. > > > > Hi Andrew, > > > > Thanks for re-reading the draft for last call. > > > > If the following: "WebRTC browsers MUST support configuration of STUN > and TURN servers, both from browser configuration and from an > application." were modified to "WebRTC browsers MUST support configurati= on > of STUN and TURN servers, both from browser configuration and from an > application. If a WebRTC browser implements RETURN > [draft-ietf-rtcweb-return] to permit the use of TURN proxies, it should > resolve conflicts among discovered or configured proxies as set out in > section 6.2 of [draft-ietf-rtcweb-return]." would that resolve the issue > for you? > > > > regards, > > > > Ted > > > > On Mon, Jun 20, 2016 at 3:11 AM, Hutton, Andrew > wrote: > > https://tools.ietf.org/html/draft-ietf-rtcweb-transports-14#section-3.4 > states "WebRTC browsers MUST support configuration of STUN and TURN > servers, both from browser configuration and from an application". > > > > The return draft (draft-ietf-rtcweb-return) explains how to deal with > the situation when both are available and actually this also covers the > case when a TURN server is auto-discovered as well as being provided by t= he > application. So should the text be expanded to say that "configuration" > also included auto-discovery and include a reference to -rtcweb-return? > > > > Sorry for the last minute comment I have read this so many times before= . > > > > Regards > > Andy > > > > > > > > > > > > > -----Original Message----- > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen > > > Jennings > > > Sent: 09 June 2016 18:36 > > > To: RTCWeb IETF > > > Subject: [rtcweb] WGLC of draft-ietf-rtcweb-transports > > > > > > This is the working group last call for draft-ietf-rtcweb-transports-= 14 > > > > > > Please send any comments to this list by June 22, 2016. > > > > > > Thanks, > > > Cullen, Ted, and Sean > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > --001a114d9a5030114e0535d77ee0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Could we pick the middle ground and make it an "are R= ECOMMENDED to"?

--=C2=A0
Michael


On 21 June 2016 at 15:24, Cullen Jennings <fluffy@iii.ca> wrote= :

I don't think we had consensus on MUST do RETURN. It is very clear that= browser are not forbidden from doing RETURN so saying MAY implement some R= FC does not seem very controversial as long as it does not extend the list = of normative dependencies.


> On Jun 21, 2016, at 2:35 AM, Hutton, Andrew <andrew.hutton@unify.com> wrote:
>
> Hi Ted / All,
>
> Thanks for suggesting some text but your text is I believe not correct= in that section 6.2 of draft-ietf-rtcweb-return only covers the conflict b= etween auto-discovered and configured TURN servers not the conflict between= configured/auto-discovered and application provided TURN servers. I theref= ore suggest the following text:
> =E2=80=9CWebRTC browsers MUST support configuration of STUN and TURN s= ervers, both from browser configuration and from an application. WebRTC bro= wsers MAY also discover TURN servers using TURN Auto-Discovery [draft-ietf-= tram-turn-server-discovery]. To resolve conflicts between TURN servers prov= ided by configuration, auto-discovery, and the application WebRTC browsers = MAY implement the procedures specified in Recursively Encapsulated TURN (RE= TURN) [draft-ietf-rtcweb-return]=E2=80=9D.
>
> Personally I think it would be better to make RETURN a =E2=80=9CMUST= =E2=80=9D level requirement as getting consistency in the browser implement= ations here is I think important but I understand that this might be too mu= ch for many people and there are no implementations out there at the moment= .
>
> Regards
> Andy
>
>
>
>
> From: Ted Hardie [mailto:ted.iet= f@gmail.com]
> Sent: 20 June 2016 18:44
> To: Hutton, Andrew
> Cc: Cullen Jennings; RTCWeb IETF
> Subject: Re: [rtcweb] WGLC comment on draft-ietf-rtcweb-transports - r= eturn.
>
> Hi Andrew,
>
> Thanks for re-reading the draft for last call.
>
> If the following: "WebRTC browsers MUST support configuration of = STUN and TURN servers, both from browser configuration and from an applicat= ion."=C2=A0 were modified to "WebRTC browsers MUST support config= uration of STUN and TURN servers, both from browser configuration and from = an application.=C2=A0 If a WebRTC browser implements RETURN [draft-ietf-rtc= web-return] to permit the use of TURN proxies, it should resolve conflicts = among discovered or configured proxies as set out in section 6.2 of [draft-= ietf-rtcweb-return]." would that resolve the issue for you?
>
> regards,
>
> Ted
>
> On Mon, Jun 20, 2016 at 3:11 AM, Hutton, Andrew <andrew.hutton@unify.com> wrote:
> https://tools.ietf.org/h= tml/draft-ietf-rtcweb-transports-14#section-3.4 states "WebRTC bro= wsers MUST support configuration of STUN and TURN servers, both from browse= r configuration and from an application".
>
> The return draft (draft-ietf-rtcweb-return) explains how to deal with = the situation when both are available and actually this also covers the cas= e when a TURN server is auto-discovered as well as being provided by the ap= plication.=C2=A0 So should the text be expanded to say that "configura= tion" also included auto-discovery and include a reference to -rtcweb-= return?
>
> Sorry for the last minute comment I have read this so many times befor= e.
>
> Regards
> Andy
>
>
>
>
>
> > -----Original Message-----
> > From: rtcweb [mailto:r= tcweb-bounces@ietf.org] On Behalf Of Cullen
> > Jennings
> > Sent: 09 June 2016 18:36
> > To: RTCWeb IETF
> > Subject: [rtcweb] WGLC of draft-ietf-rtcweb-transports
> >
> > This is the working group last call for draft-ietf-rtcweb-transpo= rts-14
> >
> > Please send any comments to this list by June 22, 2016.
> >
> > Thanks,
> > Cullen, Ted, and Sean
> >
> >
> >
> >
> > _______________________________________________
> > 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

--001a114d9a5030114e0535d77ee0-- From nobody Wed Jun 22 11:45:33 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FA712D7B7 for ; Wed, 22 Jun 2016 11:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_cOo0RghTRJ for ; Wed, 22 Jun 2016 11:45:30 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460F612D826 for ; Wed, 22 Jun 2016 11:45:29 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 90BE31EB84E9; Wed, 22 Jun 2016 20:45:27 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0279.002; Wed, 22 Jun 2016 20:45:27 +0200 From: "Hutton, Andrew" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Bernard Aboba , "rtcweb@ietf.org" Thread-Topic: [rtcweb] JSEP: simulcast reception not supported? Thread-Index: AQHRx8zt7SNfqO19PUuW0pPEj2PW6p/12/TA Date: Wed, 22 Jun 2016 18:45:26 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF2614A9B9@MCHP04MSX.global-ad.net> References: <1447FA0C20ED5147A1AA0EF02890A64B375E3C27@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B375E3C27@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 18:45:31 -0000 On: 21 June 2016 11:58 Stefan H=E5kansson LK Wrote: >=20 > FWIW, >=20 > simulcast was discussed a bit at TPAC last fall, and there it was > proposed to leave simulcast reception out of scope for WebRTC 1.0 (and > no one expressed a different opinion). See minutes [1] and slides [2] > (simulcast reception was discussed last). >=20 >=20 Yes that was the decision and if I remember correctly we talked very vaguel= y about simulcast reception being possibly something for WebRTC NV which I = guess it could still be. From nobody Wed Jun 22 18:07:05 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C99012DE79 for ; Wed, 22 Jun 2016 18:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSvAgDniXDum for ; Wed, 22 Jun 2016 18:07:02 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F45512D83D for ; Wed, 22 Jun 2016 18:07:02 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id j2so85495007vkg.2 for ; Wed, 22 Jun 2016 18:07: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:from:date:message-id:subject:to :cc; bh=tMmu3A8WAaNHTjnrc3mUyIW6EXtlReQUgCFwlCt3+gw=; b=HeGT0/f3xFNLLpvlYXOpjViipURaJl77hx++HYDdPf+G5msHMB7l1bTiJq9yXUCpqD 1zSPXcr5BcyC22sML3Fb0Hw8ygkO2qkVefqmLlCvrH15dizx++eWyJ55lH1NbNEbUqEi XQRE6LjF/3UQ6f19jVqizC8fslt3OgysEOkJ88XLjqLMBRl06Zpteltmy2jizVeIc6fs nGR6cejkBZwFoEd99oMJ0FEm/Oyz0+U8wxZGfr+4n6qw7gODgRN9TOXi19wfJZwfg6wR OSVdpvHG/Ovye3A1HLU3iaM0P+Jh52tvPG+3JBNQp0/nYIga5ycyZNCcBXn7+P9ejqkb /55w== 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; bh=tMmu3A8WAaNHTjnrc3mUyIW6EXtlReQUgCFwlCt3+gw=; b=GNMZ0acBmj9/qIuH0VbrzUX/F2tqHyxZ4lwFbba9OUfjlgysBOkpOyp8mNFS5PJOr1 BwJ3hm+hJ7+8rK/aGinIz1FBPzKRcql1M7U4NJuiAbcFCk1zRz5DnB3lF6iHrFMtVZzk 48CGS/MVGtG0ins0VdlAjNID3reL6lj2roTMIlQFSjg6H3mN3p8Mt+5JcHGVx7iD0DIp cIdzGVx82kNOtWhTHqD2Aeg0H+mBsbO5TXVgVjBrwEZWWpw5GRXRPzIni4ySpzEojEwC 90bu4FkTlevgSnli7PbgpFZ3COtRn1/yJQEeeSIxGbomZZ6lBN3tU3TI/haydNDRTVq5 WVdw== X-Gm-Message-State: ALyK8tILnDJCBMuVboEVVnGgR63QLkDJlEBMEHhRcp2k3PIIr23xZy5HPUnkviFDCrk7OVoICfmbO45aCqSqEA== X-Received: by 10.176.7.7 with SMTP id h7mr13748635uah.9.1466644021096; Wed, 22 Jun 2016 18:07:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.198 with HTTP; Wed, 22 Jun 2016 18:06:41 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B375E3C27@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B375E3C27@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Wed, 22 Jun 2016 18:06:41 -0700 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=94eb2c1229d8e3bf5b0535e7abc7 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: simulcast reception not supported? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jun 2016 01:07:04 -0000 --94eb2c1229d8e3bf5b0535e7abc7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stefan said: "it was proposed to leave simulcast reception out of scope for WebRTC 1.0" [BA] That is my recollection as well. However, currently in the WebRTC 1.0 API spec in Section 5.1 addTransceiver() it says: 'When setRemoteDescription is called with a corresponding remote description that is able to receive multiple RTP encodings as defined in [JSEP], the RTCRtpSender may send multiple RTP encodings and the parameters retrieved via the transceiver=E2=80=99s sender.getParameters() will reflect= the encodings negotiated.' So there is an expectation that JSEP will describe "a corresponding remote description that is able to receive multiple RTP encodings". Currently, that is not something one will find in JSEP, but rather in draft-ietf-mmusic-rid, perhaps because such a remote description would most likely be created by an SFU rather than a browser. Is it possible to add such material to JSEP that can be referenced in WebRTC 1.0 API without confusing the issue of whether a WebRTC 1.0 browser would emit an Answer indicating the ability to receive multiple RTP encodings? On Tue, Jun 21, 2016 at 3:57 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 16/06/16 14:45, Bernard Aboba wrote: > > JSEP Section 5.2.1 talks about the initial offer and simulcasting in an > > RtpSender. However Section 5.3.1 (Initial Answers) does not describe > > simulcast in an RtpReceiver. Also, Section 5.9 (Applying an Answer) > > only talks about sending of simulcast streams, not receiving. > > > > Are we to conclude that JSEP only supports sending of simulcast, but > > that an RtpReceiver should only expect to receive a single RTP stream? > > FWIW, > > simulcast was discussed a bit at TPAC last fall, and there it was > proposed to leave simulcast reception out of scope for WebRTC 1.0 (and > no one expressed a different opinion). See minutes [1] and slides [2] > (simulcast reception was discussed last). > > > [1] https://www.w3.org/2015/10/28-webrtc-minutes#item07 > [2] > > https://www.w3.org/2011/04/webrtc/wiki/images/e/e3/Simulcast_at_TPAC_2015= .pdf > --94eb2c1229d8e3bf5b0535e7abc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stefan said:=C2=A0

"it was propose= d to leave simulcast reception out of scope for WebRTC 1.0"
=
[BA] That is my recollection as well.=C2=A0 However, current= ly in the WebRTC 1.0 API spec in Section 5.1 addTransceiver() it says:=C2= =A0

'When setRemoteDescription is called with a corresponding re= mote description that is able to receive multiple RTP encodings as defined = in [JSEP], the RTCRtpSender may send multiple RTP encodings and the paramet= ers retrieved via the transceiver=E2=80=99s sender.getParameters() will ref= lect the encodings negotiated.'

So there is an expectation that JSEP will describe &qu= ot;a corresponding remote description that is able to receive multiple RTP = encodings".=C2=A0 Currently, that is not something one will find in JS= EP, but rather in=C2=A0draft-ietf-mmusic-rid, perhaps because such a remote= description would most likely be created by an SFU rather than a browser.= =C2=A0

Is it po= ssible to add such material to JSEP that can be referenced in WebRTC 1.0 AP= I without confusing the issue of whether a WebRTC 1.0 browser would emit an= Answer indicating the ability to receive multiple RTP encodings?=C2=A0

=

On Tu= e, Jun 21, 2016 at 3:57 AM, Stefan H=C3=A5kansson LK <= stefa= n.lk.hakansson@ericsson.com> wrote:
On 16/06/16 14:45, Bernard= Aboba wrote:
> JSEP Section 5.2.1 talks about the initial offer and simulcasting in a= n
> RtpSender. However Section 5.3.1 (Initial Answers) does not describe > simulcast in an RtpReceiver.=C2=A0 Also, Section 5.9 (Applying an=C2= =A0 Answer)
> only talks about sending of simulcast streams, not receiving.
>
> Are we to conclude that JSEP only supports sending of simulcast, but > that an=C2=A0 RtpReceiver should only expect to receive a single RTP s= tream?

FWIW,

simulcast was discussed a bit at TPAC last fall, and there it was
proposed to leave simulcast reception out of scope for WebRTC 1.0 (and
no one expressed a different opinion). See minutes [1] and slides [2]
(simulcast reception was discussed last).


[1] https://www.w3.org/2015/10/28-webrtc-minutes#= item07
[2]
https://www.w3.org/2011= /04/webrtc/wiki/images/e/e3/Simulcast_at_TPAC_2015.pdf

--94eb2c1229d8e3bf5b0535e7abc7-- From nobody Fri Jun 24 09:05:28 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4AA12DCE0; Fri, 24 Jun 2016 09:00:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160052.10933.84665.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:52 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] rtcweb - Requested sessions have been scheduled for IETF 96 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jun 2016 16:00:56 -0000 Dear Ted Hardie, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rtcweb Session 1 (2:00:00) Thursday, Afternoon Session I 1400-1600 Room Name: Potsdam II size: 175 --------------------------------------------- rtcweb Session 2 (1:00:00) Friday, Afternoon Session I 1220-1320 Room Name: Potsdam I size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Applications and Real-Time Area Session Requester: Ted Hardie Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: tls rmcat aqm avtcore avtext clue dispatch httpbis stir acme mmusic payload sipcore perc Second Priority: dprive tcpinc straw tsvwg tsvarea ace uta netvc capport Third Priority: insipid irtfopen ianaplan dane opsawg Special Requests: There are two possible BoFs that we need to add as First priority conflicts: SPUD and QUIC (if approved). thanks, Ted --------------------------------------------------------- From nobody Mon Jun 27 06:46:28 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9381E12D1B7; Mon, 27 Jun 2016 06:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytMGopx8Qd3T; Mon, 27 Jun 2016 06:46:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FE112D1AD; Mon, 27 Jun 2016 06:46:13 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-25-57712e24f2d3 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.08.27088.42E21775; Mon, 27 Jun 2016 15:46:12 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.294.0; Mon, 27 Jun 2016 15:46:09 +0200 To: IETF AVTCore WG References: From: Magnus Westerlund Message-ID: Date: Mon, 27 Jun 2016 15:46:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM2K7pa6KXmG4wY8LkhYve1ayW8zvPM1u 8eL6R2aLtf/a2S2OvbnL5sDqsWTJTyaPlo8LWT1m7XzCEsAcxWWTkpqTWZZapG+XwJWx7spP poItIhXLbx5nbGC8L9DFyMEhIWAi8eSabRcjJ5ApJnHh3no2EFtI4AijRMNh4S5GLiB7OaPE 61V7mEASwgLREqeO/WIGsUUElCR2TNrGDNFgL3Flxz1GkAZmgU5GibaDe8AmsQlYSNz80Qhm 8wIV9X89DtbAIqAq8W/ebEYQW1QgRqLx9mF2iBpBiZMzn7CA2JwCDhJXH/YwghzKDNT7YGsZ SJhZQF6ieetsqL3aEg1NHawTGAVnIemehdAxC0nHAkbmVYyixanFSbnpRkZ6qUWZycXF+Xl6 eaklmxiBIX1wy2+DHYwvnzseYhTgYFTi4U0IKAgXYk0sK67MPcQowcGsJMJrrlsYLsSbklhZ lVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNTqoGx6MybwwuOOqZkHZ1o uubcyqtvnutHlz3e8DXn5OOEkPKN61Od2QK499Qdv5VVpBAvcWnNneKzTsvq0mreTni1bU2O ncrV/dtfaB2T0Hi25PyMvvUr9J3/l5q/3G166drL3Yr2nD52Py63MhkYrt3xcWFP/b/uz26y +XU/3uaLWcg5ORv0Zm55rcRSnJFoqMVcVJwIABPbM/9lAgAA Archived-At: Cc: Ben Campbell , "rtcweb@ietf.org" , tsvwg , Mirja Kuehlewind Subject: Re: [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 13:46:17 -0000 AVT, RTCWEB, TSVWG and ADS. I have to conclude that there is not consensus on the proposed text. It does appear that this subject do require additional discussion and most likely drafting of new text. Please continue to provide input into the matter. I would like to conclude this subject no later than by the end of the Berlin meeting. Cheers Magnus Den 2016-06-14 kl. 10:14, skrev Magnus Westerlund: > AVT, RTCWEB and TSVWG > > This announces an additional one week WG last call (in AVT) on the > changes done to "Multimedia Congestion Control: Circuit Breakers for > Unicast RTP Sessions" that is intended for Proposed Standard. The last > call concludes on the 21st of June. > > So this last call is deemed necessary due to normative changes in the > behaviour as result of the conclusions of how to resolve the Discuss > regarding reaction to ECN markings. > > If there are no issues in this additional WG last call, the draft will > be approved for publication as it has already passed IESG review. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-16 > > > Cheers > > Magnus Westerlund > AVTCORE WG chair > > ---------------------------------------------------------------------- > 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 > -- 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 Jun 27 07:42:39 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A5612D1C8; Mon, 27 Jun 2016 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3KGxu1zAOHk; Mon, 27 Jun 2016 07:42:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A327512D65E; Mon, 27 Jun 2016 07:40:17 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5REeBsi052206 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 27 Jun 2016 09:40:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Magnus Westerlund" Date: Mon, 27 Jun 2016 09:40:17 -0500 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Mirja Kuehlewind , "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 14:42:38 -0000 Thanks, Magnus! On 27 Jun 2016, at 8:46, Magnus Westerlund wrote: > AVT, RTCWEB, TSVWG and ADS. > > I have to conclude that there is not consensus on the proposed text. > It does appear that this subject do require additional discussion and > most likely drafting of new text. > > Please continue to provide input into the matter. I would like to > conclude this subject no later than by the end of the Berlin meeting. > > Cheers > > Magnus > > Den 2016-06-14 kl. 10:14, skrev Magnus Westerlund: >> AVT, RTCWEB and TSVWG >> >> This announces an additional one week WG last call (in AVT) on the >> changes done to "Multimedia Congestion Control: Circuit Breakers for >> Unicast RTP Sessions" that is intended for Proposed Standard. The >> last >> call concludes on the 21st of June. >> >> So this last call is deemed necessary due to normative changes in the >> behaviour as result of the conclusions of how to resolve the Discuss >> regarding reaction to ECN markings. >> >> If there are no issues in this additional WG last call, the draft >> will >> be approved for publication as it has already passed IESG review. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-16 >> >> >> Cheers >> >> Magnus Westerlund >> AVTCORE WG chair >> >> ---------------------------------------------------------------------- >> 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 >> > > > -- > > 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 Jun 27 08:04:40 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D939E12D69E; Mon, 27 Jun 2016 08:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpIQgnt2hTHk; Mon, 27 Jun 2016 08:04:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FBF12D66B; Mon, 27 Jun 2016 07:56:04 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D205CEF8A2240; Mon, 27 Jun 2016 14:55:58 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5REtTAX001691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Jun 2016 14:56:01 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5RErb3a017606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jun 2016 16:55:20 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 27 Jun 2016 16:53:13 +0200 From: "De Schepper, Koen (Nokia - BE)" To: Michael Welzl , "Black, David" Thread-Topic: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRyB4Xv7l4815Xu02SCqscZNZxsp/tUDQAgABAKwCAABBvgIABAQmAgAOYcQCAADeCAIAK/Ekg Date: Mon, 27 Jun 2016 14:53:12 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> In-Reply-To: <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: " Fairhurst" , tsvwg , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 15:04:34 -0000 QXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhpcyBkcmFmdCBpcyByZWxhdGVkIHRvIGNpcmN1aXQg YnJlYWtlcnMgaW4gZW5kLXN5c3RlbXMsIHJpZ2h0Pw0KSXQgaXMgdGhlIGVuZCBzeXN0ZW0gdGhh dCBkZXRlcm1pbmVzIHRoZSB1c2Ugb2YgRUNOIChjdXJyZW50bHkgbWFya2luZyBub24tZWN0IGZv ciBkcm9wIGFuZCBlY3QoMCkgZm9yIENsYXNzaWMgRUNOKS4gDQpJbiBMNFMgd2UgZG9uJ3QgcGxh biB0byBjaGFuZ2UgdGhlIGJlaGF2aW9yIG9mIENsYXNzaWMgRUNOLCBhbmQgQUJFJ3MgYmVoYXZp b3Igc2hvdWxkIGJlIGNsb3NlIHRvIG5vbi1BQkUgRUNOLiBTbyBJIGd1ZXNzIHRoZXJlIGlzIG5v IHByb2JsZW0gb2YgZGVzY3JpYmluZyB0aGUgYmVoYXZpb3Igb2YgaG93IGEgQ2xhc3NpYyBFQ04g YmFzZWQgc2VuZGVyIHdvdWxkIHJlc3BvbmQgdG9kYXkuIA0KDQpBcyB3ZSBvbmx5IHdhbnQgdG8g c2lnbmlmaWNhbnRseSBjaGFuZ2UgdGhlIG5ldHdvcmsgYmVoYXZpb3Igb2YgZWN0KDEpIG1hcmtp bmcsIGNhbiB3ZSBzb2x2ZSB0aGlzIGlzc3VlIGJ5IHJlY29tbWVuZGluZyAob3IgZXZlbiByZXF1 aXJpbmcpIHNlbmRlcnMgdG8gbWFyayBvbmx5IGVjdCgwKSBhbmQgZGVzY3JpYmluZyB0aGUgY2xh c3NpYyBFQ04gY2lyY3VpdCBicmVha2VyPyBXaGVuIEw0UyBnZXRzIGRlZmluZWQsIGFsc28gYW4g TDRTIGJhc2VkIGNpcmN1aXQgYnJlYWtlciBleHRlbnNpb24gY2FuIGJlIGRlZmluZWQgZm9yIHNl bmRlcnMgdGhhdCB3YW50IHRvIHVzZSB0aGUgTDRTIHNlcnZpY2UgKHdoZW4gc2VuZGVycyBzZW5k IGVjdCgxKSBwYWNrZXRzKS4NCg0KUmVnYXJkcywNCktvZW4uDQoNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsIFdlbHpsDQo+IFNlbnQ6IG1hYW5kYWcgMjAganVuaSAy MDE2IDE4OjM2DQo+IFRvOiBCbGFjaywgRGF2aWQNCj4gQ2M6IDxnb3JyeUBlcmcuYWJkbi5hYy51 az4gRmFpcmh1cnN0OyBNYWdudXMgV2VzdGVybHVuZDsgdHN2d2c7IElFVEYNCj4gQVZUQ29yZSBX RzsgcnRjd2ViQGlldGYub3JnOyBDb2xpbiBQZXJraW5zDQo+IFN1YmplY3Q6IFJlOiBbdHN2d2dd IFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczogZHJhZnQtDQo+IGll dGYtYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiANCj4gDQo+ID4gT24gMjAuIGp1 bi4gMjAxNiwgYXQgMTUuMTYsIEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT4gd3Jv dGU6DQo+ID4NCj4gPj4+IEJ1dCBJ4oCZbSBsZXNzIGNvbmNlcm5lZCB0aGFuIERhdmlkIGFib3V0 IGV2ZW50dWFsbHkgaWdub3JpbmcgaXQgZm9yDQo+IGNpcmN1aXQNCj4gPj4gYnJlYWtlci4NCj4g Pj4+DQo+ID4+IEFncmVlLiBMb3NzIGlzIHRoZSBtZWFzdXJlbWVudCB0aGF0IGEgQ0IgTVVTVCBy ZXNwb25kIHRvLg0KPiA+DQo+ID4gTXVtYmxlLiAgIEkgd291bGQgYmUgb2sgd2l0aCBhIGNsZWFy IGRpc2NvdXJhZ2VtZW50IGZvciB1c2Ugb2YgRUNOLUNFDQo+IG1hcmtzLCBhY2NvbXBhbmllZCBi eSB0aGUgc29ydCBvZiBkZXNpZ24gcmF0aW9uYWxlIGhlcmUsIG9yIGV2ZW4gYmV0dGVyLA0KPiBh IGNsZWFyIHN0YXRlbWVudCB0aGF0IGxvc3QgcGFja2V0cyBmb3IgdGhlIHB1cnBvc2Ugb2YgdGhl IFJUUCBjaXJjdWl0DQo+IGJyZWFrZXIgaGF2ZSB0byBiZSBhY3R1YWxseSBsb3N0IHdpdGhvdXQg Z2V0dGluZyBpbnRvIHdoZXRoZXIgb3Igbm90DQo+IEVDTi1DRSBtYXJrcyBhcmUgaW52b2x2ZWQg LWkuZS4sIHRoZSBSVFAgY2lyY3VpdCBicmVha2VyIGlzIHNwZWNpZmllZA0KPiBhZ2FpbnN0IGFj dHVhbCBkcm9wcyBhcyBhIG5ldHdvcmsgcHJvdGVjdGlvbiBiYWNrc3RvcC4NCj4gPg0KPiA+IEEg cmVsYXRlZCBjb25jZXJuIGlzIHRoYXQgRUNOIG1hcmtzIG1heSBvdmVyc3RhdGUgZXF1aXZhbGVu dCBsb3NzDQo+IGJlaGF2aW9yIC0gYSBzaW1wbGlzdGljIHF1ZXVlIG1hbmFnZW1lbnQgZGlzY2lw bGluZSB0aGF0IG1hcmtzIGV2ZXJ5DQo+IHBhY2tldCB3aGVuIHRoZSBxdWV1ZSBpcyBvdmVyIGEg dGhyZXNob2xkIChOQjogdGhpcyBjbGFzcyBvZiBtYXJraW5nDQo+IGJlaGF2aW9yIGlzIE5PVCBS RUNPTU1FTkRFRCAtIGEgcmVhbCBBUU0gU0hPVUxEIGJlIHVzZWQpIGNvdWxkIHlpZWxkIGENCj4g cnVuIG9mIEVDTi1DRSBtYXJrcyB0aGF0IHdvdWxkIG5vdCBjYXVzZSBhIGNvcnJlc3BvbmRpbmcg d2l0aCBhIHJ1biBvZg0KPiBwYWNrZXQgZHJvcHMuICAgVGhpcyBpcyBhbW9uZyB0aGUgcmVhc29u cyB0aGF0IFRDUCByZWFjdHMgdG8gRUNOLUNFDQo+IG1hcmtzIG9ubHkgb25jZSBwZXIgUlRULCBh bmQgbWlnaHQgYmUgYSByZWFzb24gdG8gdHJlYXQgbXVsdGlwbGUgRUNOLUNFDQo+IG1hcmtzIGlu IGFuIFJUVCBpbnRlcnZhbCBhcyBub3QgcmVwcmVzZW50aW5nIGRyb3BzIG9mIGFsbCBwYWNrZXRz IGZvcg0KPiB0aGUgUlRQIGNpcmN1aXQgYnJlYWtlcidzIFRDUC1lcXVpdmFsZW50IHRocm91Z2hw dXQgY2FsY3VsYXRpb24uDQo+IA0KPiBJ4oCZbSBub3Qgc3VyZSB3ZSBuZWVkIHN1Y2ggY29tcGxp Y2F0ZWQgbG9naWMgdG8gZmluZCBhIGNhc2Ugd2hlcmUgRUNODQo+IG1hcmtzIGFyZSBkaWZmZXJl bnQgZnJvbSBwYWNrZXQgZHJvcHM6DQo+IA0KPiBCYXNpY2FsbHksIHRoZXkgc2ltcGx5IGFyZW7i gJl0IC0gZXZlbiDigJxyZWFs4oCdIEFRTXMgbWFya2luZyBpc27igJl0IGV4YWN0bHkNCj4gdGhl IHNhbWUgYXMgYSBwYWNrZXQgZHJvcDogdGhlIG1hcmtzIHRoZW1zZWx2ZXMgaW5mb3JtIHlvdSB0 aGF0IGFuIEFRTQ0KPiBkaWQgaXRzIGpvYiwgYW5kIHdpdGggbW9kZXJuIEFRTXMgbGlrZSBDb0Rl bCAvIFBJRSBldGMuLCB5b3XigJlyZSBwcm9iYWJseQ0KPiBnZXR0aW5nIHRoaXMgZnJvbSBhIHNo YWxsb3cgcXVldWUuIENoYW5jZXMgYXJlIHRoYXQgdGhpcyBpcyBsZXNzIHRoYW4gYQ0KPiBCRFAg d29ydGggb2YgcXVldWluZywgd2hpY2ggaXMgb3VyIGp1c3RpZmljYXRpb24gZm9yIHJlY29tbWVu ZGluZyBhDQo+IGRpZmZlcmVudCBiYWNrLW9mZiBiZWhhdmlvciBpbiBkcmFmdC1raGFkZW1pLXRz dndnLWVjbi1yZXNwb25zZS0wMCBhbmQNCj4gZHJhZnQta2hhZGVtaS10Y3BtLWFsdGVybmF0aXZl YmFja29mZi1lY24tMDANCj4gDQo+IFNvIHRoZSBwb2ludCBpcyBub3QgdGhhdCBBUU1zIHdvdWxk IHRyZWF0IEVDTiBtYXJraW5nIGFuZCBkcm9wcGluZw0KPiBkaWZmZXJlbnRseSAtIGl04oCZcyB0 aGF0IEVDTiBpbmRpY2F0ZXMgYW4gQVFNLCBhbmQgaGVuY2UgcHJvYmFibHkgYQ0KPiBzaGFsbG93 IHF1ZXVlLiBXaXRoIGEgZHJvcCwgeW91IGp1c3QgZG9u4oCZdCBrbm93Lg0KPiANCj4gQmFjayB0 byB0aGUgQ0IsIEkgdGhpbmsgYW4gQVFNIG1hcmtpbmcgYXQgYSBzaGFsbG93IHF1ZXVlIChsaWtl IGUuZy4NCj4gQ29EZWwpIGlzIGluZGVlZCBxdWl0ZSBkaWZmZXJlbnQgZnJvbSBhIOKAnGJyb2tl biBjb25uZWN0aW9u4oCdLg0KPiANCj4gQ2hlZXJzLA0KPiBNaWNoYWVsDQo+IA0KPiANCj4gPg0K PiA+IFRoYW5rcywgLS1EYXZpZA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IEdvcnJ5IChlcmcpIFttYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWtdDQo+ ID4+IFNlbnQ6IFNhdHVyZGF5LCBKdW5lIDE4LCAyMDE2IDI6MjMgQU0NCj4gPj4gVG86IE1pcmph IEvDvGhsZXdpbmQNCj4gPj4gQ2M6IEJsYWNrLCBEYXZpZDsgTWFnbnVzIFdlc3Rlcmx1bmQ7IENv bGluIFBlcmtpbnM7IHJ0Y3dlYkBpZXRmLm9yZzsNCj4gSUVURg0KPiA+PiBBVlRDb3JlIFdHOyB0 c3Z3Zw0KPiA+PiBTdWJqZWN0OiBSZTogW3RzdndnXSBbcnRjd2ViXSBbQVZUQ09SRV0gV0cgTGFz dCBDYWxsIG9uIGNoYW5nZXM6DQo+IGRyYWZ0LWlldGYtDQo+ID4+IGF2dGNvcmUtcnRwLWNpcmN1 aXQtYnJlYWtlcnMtMTYNCj4gPj4NCj4gPj4gSSB0aGluayB3ZSBTSE9VTEQgTk9UIHJlY29tbWVu ZCB0byB1c2UgRUNOIG1hcmtzIGFzIGlucHV0cyB0byBhIENCLg0KPiBTZWUNCj4gPj4gYmVsb3c6 DQo+ID4+DQo+ID4+PiBPbiAxNyBKdW4gMjAxNiwgYXQgMTY6MDIsIE1pcmphIEvDvGhsZXdpbmQN Cj4gPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+DQo+ID4+IHdyb3RlOg0KPiA+Pj4N Cj4gPj4+ICsxIHRvIG5vdCB1c2Ugbm9ybWF0aXZlIGxhbmd1YWdlIGhlcmUuDQo+ID4+Pg0KPiA+ Pj4gSG93ZXZlciwgcGxlYXNlIG5vdGUgdGhhdCBoYXZpbmcgYSBoaWdoIGxldmVsIG9mIEVDTi1D RSBtYXJrcw0KPiAod2l0aG91dCBhbnkNCj4gPj4gbG9zc2VzKSBtZWFucyB0aGF0IGFsbCBwYWNr ZXRzIHdlcmUgcmVjZWl2ZWQgY29ycmVjdGx5LiBUaGlzDQo+IHNpdHVhdGlvbiBjYW4gZXZlbg0K PiA+PiBvY2N1cnMgd2l0aG91dCBoaWdoIGRlbGF5cyAoZGVwZW5kaW5nIG9uIHRoZSBBUU0gdXNl ZCksIHdoaWNoIHdvdWxkDQo+IGp1c3QNCj4gPj4gbWVhbiB0aGUgc2VydmljZXMgd29ya3MgcGVy ZmVjdGx5LiBUaGVyZWZvcmUgZm9yIG1lIENFIG1hcmtzIGFyZSBhDQo+IHBlcmZlY3QgaW5wdXQN Cj4gPj4gc2lnbmFsIGZvciBhIGNvbmdlc3Rpb24gY29udHJvbCBsb29wICh3aGVyZSB0aGUgQVFN IHRlbGwgdGhlIHNlbmRlcg0KPiB0byB0YWtlIGFjdGlvbg0KPiA+PiAtIHdoYXRldmVyIHRoYXQg bWVhbnMpLg0KPiA+Pg0KPiA+PiBXZSBtYXkgaW4gZnV0dXJlIGZpZ3VyZSBvdXQgd2F5cyB0byBk byB0aGlzIHRvIGRldGVjdCBzaWduaWZpY2FudA0KPiBmYWlsdXJlIHVzaW5nIGENCj4gPj4gcmF0 ZSBhZGFwdGl2ZSB0cmFuc3BvcnQgYW5kIEVDTiBlLmcuICBPYnNlcnZpbmcgMTAwJSBDRSBtYXJr cyBvcg0KPiBzb21ldGhpbmcsIGZvcg0KPiA+PiBhbiBSVFAgZmxvdyB0aGF0IGlzIHRyeWluZyB0 byBzZW5kIHdlbGwgYmVsb3cgaXRzIHBlYWsgcmF0ZSBkZWNpZGVkDQo+IGJ5IENDIC0tIGJ1dCBJ DQo+ID4+IHRoaW5rIHRoaXMgaXMgc3BlY3VsYXRpbmcgYXQgYW4gYWxnb3JpdGhtIGFuZCBhZGRp bmcgZGV0YWlscyBoZXJlIGlzDQo+IG5vdCBhIGdvb2QgaWRlYS4NCj4gPj4gRXNwZWNpYWxseSBh cyBBUU0gY29udGludWVzIHRvIGV2b2x2ZS4NCj4gPj4NCj4gPj4+IEJ1dCBJ4oCZbSBsZXNzIGNv bmNlcm5lZCB0aGFuIERhdmlkIGFib3V0IGV2ZW50dWFsbHkgaWdub3JpbmcgaXQgZm9yDQo+IGNp cmN1aXQNCj4gPj4gYnJlYWtlci4NCj4gPj4+DQo+ID4+IEFncmVlLiBMb3NzIGlzIHRoZSBtZWFz dXJlbWVudCB0aGF0IGEgQ0IgTVVTVCByZXNwb25kIHRvLg0KPiA+Pg0KPiA+Pj4gSW4gYWRkaXRp b24gb25lIHBvaW50IG9uIHNvbWV0aGluZyBNYWdudXMgd3JvdGUgZWFybGllcjoNCj4gPj4+ICJJ ZiB0aGUgaW1wbGVtZW50YXRpb24gb25seSBoYXZlIGNpcmN1aXQgYnJlYWtlciwgaS5lLiBubyBm dWxsDQo+IGZsZWRnZWQgY29uZ2VzdGlvbg0KPiA+PiBjb250cm9sbGVyIGFuZCB1c2VzIEVDTiwg dGhleSBjYW4gaW4gd29yc3QgY2FzZSBkcml2ZSB0aGUgYnVmZmVyIGludG8NCj4gdGhlIG92ZXJs b2FkDQo+ID4+IHJlZ2ltZSB3aGVyZSBpdCBzdGFydHMgZHJvcHBpbmcgcGFja2V0cy4g4oCeDQo+ ID4+Pg0KPiA+Pj4gSeKAmW0gbm90IHN1cmUgYWJvdXQgdGhpcyBjYXNlLiBFQ04gaXMgYW4gaW5w dXQgc2lnbmFsIGZvciBjb25nZXN0aW9uDQo+IGNvbnRyb2wuIElmIHlvdQ0KPiA+PiBkb27igJl0 IHVzZSBjb25nZXN0aW9uIGNvbnRyb2wgYnV0IG9ubHkgYSBjaXJjdWl0IGJyZWFrZXIsIHlvdSBz aG91bGQNCj4gcHJvYmFibHkgbm90DQo+ID4+IGVuYWJsZSBFQ04uIEF0IGxlYXN0IGl0IG5vdCBj bGVhciB0byBtZSB3aHkgeW91IHdvdWxkIGVuYWJsZSBpdCwgYW5kDQo+IGl0J3MgZGVmaW5pdGVs eQ0KPiA+PiBub3QgY29uZm9ybSB0byB0aGUgRUNOIHNwZWMuIFByb2JhYmx5IHdlIHNob3VsZCBz YXkgc29tZXRoaW5nIGFib3V0DQo+IHRoaXMgaW4gdGhlDQo+ID4+IGRyYWZ0Li4uPw0KPiA+Pj4N Cj4gPj4gQWdyZWUsIGVuYWJsaW5nIEVDTiB3aXRob3V0IGEgcmVzcG9uc2l2ZSBDQyBpcyBnb2lu ZyB0byBsZWFkIHRvDQo+IHRyb3VibGUuDQo+ID4+DQo+ID4+PiBNaXJqYQ0KPiA+Pj4NCj4gPj4g R29ycnkNCj4gPj4NCj4gPj4+PiBBbSAxNy4wNi4yMDE2IHVtIDE2OjAzIHNjaHJpZWIgQmxhY2ss IERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPjoNCj4gPj4+Pg0KPiA+Pj4+IENvbGluLA0KPiA+ Pj4+DQo+ID4+Pj4+Pj4gLi4uICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBwcm92aWRpbmcg aW1wbGVtZW50ZXJzIHdpdGggdG9vDQo+IG11Y2gNCj4gPj4+Pj4+PiBsYXRpdHVkZSB0byBpZ25v cmUgRUNOLUNFIG1hcmtzIChlLmcuLCBiZWNhdXNlIGFuIGltcGxlbWVudGVyDQo+IGRvZXNuJ3QN Cj4gPj4+Pj4+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJvYmxlbSBzcGFjZSBpbiB0aGUg Zmlyc3QgcGxhY2UpLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIGFncmVlLCBidXQgdGhlIGFyZ3VtZW50 IGlzIHRoYXQgZG9pbmcgc28gaXMgbGVzcyBoYXJtZnVsIHRoYW4NCj4gZGVwbG95aW5nIGENCj4g Pj4gY2lyY3VpdA0KPiA+Pj4+PiBicmVha2VyIHRoYXQgdHJpZ2dlcnMgdG9vIG9mdGVuIHdoZW4g RUNOIGlzIHVzZWQuDQo+ID4+Pj4+DQo+ID4+Pj4+IEnigJltIG5vdCBzdXJlIEkgYmVsaWV2ZSB0 aGlzIGFyZ3VtZW50LCB0aG91Z2gsIHNpbmNlIGl0IHNlZW1zIHRoYXQNCj4gYW55IG5ldw0KPiA+ PiBBUU0NCj4gPj4+Pj4gdGhhdCBhcHBsaWVzIEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhh biBhdCBwcmVzZW50IHdpbGwgaGF2ZQ0KPiB0bw0KPiA+PiBjb25zaWRlcg0KPiA+Pj4+PiBiYWNr d2FyZHMgY29tcGF0aWJpbGl0eSwgdG8gd29yayB3aXRoIGRlcGxveWVkIFRDUCAoZS5nLiwgZHJh ZnQtDQo+IGJyaXNjb2UtDQo+ID4+IHRzdndnLQ0KPiA+Pj4+PiBhcW0tdGNwbS1ybWNhdC1sNHMt cHJvYmxlbSB1c2VzIEVDVCgxKSBhcyBhIHNpZ25hbCB0byB1c2UgdGhlIG5ldw0KPiBtYXJraW5n LA0KPiA+Pj4+PiB3aGlsZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgc2V0IEVDVCgwKSkuIFRo ZXNlIGNvbXBhdGliaWxpdHkNCj4gbWVjaGFuaXNtcw0KPiA+Pj4+PiB3b3VsZCBzZWVtIHRvIHBy ZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJjdWl0IGJyZWFrZXIgdG9vLg0KPiA+Pj4+DQo+ ID4+Pj4gVGhhdCByb3VnaGx5IG1hdGNoZXMgbXkgbGluZSBvZiB0aGlua2luZywgYW5kIEknbGwg b2JzZXJ2ZSB0aGF0IHRoZQ0KPiBvcmlnaW5hbA0KPiA+PiBEQ1RDUA0KPiA+Pj4+IHByb3RvY29s IGRlc2lnbiB0aGF0IHVzZWQgbW9yZSBhZ2dyZXNzaXZlIEVDTi1DRSBtYXJraW5nIHdhcyBvbmx5 DQo+IHNhZmUgZm9yDQo+ID4+Pj4gQ29udHJvbGxlZCBFbnZpcm9ubWVudCBkZXBsb3ltZW50cy4g ICBTZWUgdGhlIFRTVldHIHJmYzU0MDViaXMNCj4gZHJhZnQgZm9yDQo+ID4+IHRoZQ0KPiA+Pj4+ IGRlZmluaXRpb24gb2YgQ29udHJvbGxlZCBFbnZpcm9ubWVudCwgYW5kIGlnbm9yZSB0aGUgZmFj dCB0aGF0IHRoZQ0KPiByZmM1NDA1YmlzDQo+ID4+Pj4gZHJhZnQgaXMgYSBVRFAgZHJhZnQgLSB0 aGlzIGRlZmluaXRpb24gaXMgbW9yZSBicm9hZGx5IGFwcGxpY2FibGUuDQo+ID4+Pj4NCj4gPj4+ PiBHb2luZyBiYWNrIG92ZXIgU2VjdGlvbiA3IGluIHRoaXMgYXZ0Y29yZSBkcmFmdCwgbXkgdmll d3MgYXJlOg0KPiA+Pj4+DQo+ID4+Pj4gW0FdIE5vbmUgb2YgdGhlc2UgZHJhZnRzIGp1c3RpZnkg YSAiTUFZIGlnbm9yZSIgcmVzcG9uc2UgdG8gRUNOLUNFDQo+IG1hcmtzOg0KPiA+Pj4+ICAgLSBk cmFmdC1raGFkZW1pLXRjcG0tYWx0ZXJuYXRpdmViYWNrb2ZmLWVjbg0KPiA+Pj4+ICAgLSBkcmFm dC1pZXRmLXJtY2F0LW5hZGENCj4gPj4+PiAgIC0gZHJhZnQtaWV0Zi1ybWNhdC1zY3JlYW0tY2MN Cj4gPj4+Pg0KPiA+Pj4+IFtCXSBJbiBsaW5lIHdpdGggQ29saW4ncyBjb21tZW50IG9uIHRoZSBM NFMgZHJhZnQsIEkgdGhpbmsgaXQncw0KPiBpbmN1bWJlbnQgb24NCj4gPj4+PiB0aGUgYXV0aG9y cyBvZiBkcmFmdC1icmlzY29lLWFxbS1kdWFscS1jb3VwbGVkIHRvIGZpZ3VyZSBvdXQgaG93DQo+ IHRoYXQgd2lsbA0KPiA+Pj4+IGNvZXhpc3QgKG9yIGF2b2lkKSBkZXBsb3llZCBUQ1AsIGFuZCB0 aGlzIGF2dGNvcmUgZHJhZnQgb3VnaHQgbm90DQo+IHRvIGJlDQo+ID4+Pj4gdHJ5aW5nIHRvIHBy ZWp1ZGdlIHdoYXQgd2lsbCBiZSBkb25lIHRoZXJlLg0KPiA+Pj4+DQo+ID4+Pj4gU28sIEkgZG9u J3QgdGhpbmsgdGhlIGN1cnJlbnQgdGV4dCBpbiBTZWN0aW9uIDcgaGFzIGp1c3RpZmllZCB0aGUN Cj4gdW5mZXR0ZXJlZA0KPiA+Pj4+ICJpbXBsZW1lbnRhdGlvbnMgTUFZIGlnbm9yZSBFQ04tQ0Ug bWFya3MiIHRleHQsIGFzIGlnbm9yaW5nIHRob3NlDQo+IG1hcmtzDQo+ID4+Pj4gaXMgbm90IGNv bnNpc3RlbnQgd2l0aCBhbnkgb2YgdGhlIGZvdXIgY2l0ZWQgZHJhZnRzLg0KPiA+Pj4+DQo+ID4+ Pj4gSW4gbW9yZSBkZXRhaWwsIEkgdGhpbmsgbWFraW5nIGNoYW5nZXMgdG8gbm9ybWF0aXZlIHJl cXVpcmVtZW50cw0KPiBoZXJlIGJhc2VkDQo+ID4+Pj4gb24gW0JdIGlzIHByZW1hdHVyZSwgYW5k IEkgd291bGQgaG9wZSB0aGF0IHRoZSBybWNhdCBXRyBjb3VsZCBiZQ0KPiA+PiBlbmNvdXJhZ2Vk DQo+ID4+Pj4gdG8gY29uc2lkZXIgdGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIgaW4gaXRzIGNvbmdl c3Rpb24gY29udHJvbA0KPiBkcmFmdHMsIGFzIHRob3NlIENDDQo+ID4+Pj4gbWVjaGFuaXNtcyBh cmUgcmVsYXRlZCB0byB0aGUgY2lyY3VpdCBicmVha2VyIG1lY2hhbmlzbSwgaGVuY2UNCj4gbGlr ZWx5DQo+ID4+Pj4gdG8gYmUgaW4gcmVsYXRlZCBhcmVhcyBvZiBhbiBSVFAgaW1wbGVtZW50YXRp b24uDQo+ID4+Pj4NCj4gPj4+PiBUaGF0IGxlYXZlcyBkcmFmdC1raGFkZW1pLXRjcG0tYWx0ZXJu YXRpdmViYWNrb2ZmLWVjbiwgd2hpY2ggVFNWV0cNCj4gPj4+PiB3aWxsIGJlIGxvb2tpbmcgYXQg aW4gQmVybGluLiAgSWYgYSBub3JtYXRpdmUgc3RhdGVtZW50IGFib3V0IEVDTi0NCj4gQ0UgcmVh Y3Rpb24NCj4gPj4+PiBpcyBnb2luZyB0byByZXN0IG9uIHRoYXQgZHJhZnQsIHRoZW4gdGhlIHJl ZmVyZW5jZSB0byB0aGF0IGRyYWZ0DQo+IHNob3VsZCBiZQ0KPiA+Pj4+IG5vcm1hdGl2ZS4gIFNv bWV0aGluZyBhYm91dCBkb2luZyB0aGF0IHN0cmlrZXMgbWUgYXMgcHJlbWF0dXJlIC4uLg0KPiA+ Pj4+DQo+ID4+Pj4gSSByZWFsaXplIHRoYXQgd2UncmUgdHJ5aW5nIHRvIHByZWRpY3QgYW5kIGFj Y29tbW9kYXRlIHRoZSBmdXR1cmUsDQo+IHdoaWNoDQo+ID4+Pj4gaXMgYW4gaW1wcmVjaXNlIHVu ZGVydGFraW5nIGF0IGJlc3QuICAgQXMgYW4gYWx0ZXJuYXRpdmUgdG8gdGhlDQo+IGN1cnJlbnQg dGV4dCwNCj4gPj4+PiB3b3VsZCBpdCBiZSByZWFzb25hYmxlIHRvIHNheSAod2l0aG91dCBhbnkg UkZDIDIxMTkga2V5d29yZHMpIHRoYXQNCj4gdGhlDQo+ID4+Pj4gYmVzdCBjdXJyZW50IGd1aWRh bmNlIGlzIHN0aWxsIHRvIHRyZWF0IEVDTi1DRSBtYXJrcyBhcyBpbmRpY2F0aW5nDQo+IGRyb3Bz LA0KPiA+Pj4+IHdpdGggYSB3YXJuaW5nIHRoYXQgdGhlcmUgaXMgYSBnb29kIHBvc3NpYmlsaXR5 IG9mIHRoaXMgY2hhbmdpbmcgaW4NCj4gdGhlDQo+ID4+Pj4gbmVhciBmdXR1cmUgZHVlIHRvIGFs bCBvZiB0aGUgd29yayBpbiBwcm9ncmVzcyBjaXRlZCBpbiBTZWN0aW9uIDc/DQo+ID4+Pj4NCj4g Pj4+PiBUaGFua3MsIC0tRGF2aWQNCj4gPj4+Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+Pj4+PiBGcm9tOiBDb2xpbiBQZXJraW5zIFttYWlsdG86Y3NwQGNzcGVya2lu cy5vcmddDQo+ID4+Pj4+IFNlbnQ6IEZyaWRheSwgSnVuZSAxNywgMjAxNiA2OjE0IEFNDQo+ID4+ Pj4+IFRvOiBKb2huIExlc2xpZTsgQmxhY2ssIERhdmlkDQo+ID4+Pj4+IENjOiBydGN3ZWJAaWV0 Zi5vcmc7IElFVEYgQVZUQ29yZSBXRzsgdHN2d2cNCj4gPj4+Pj4gU3ViamVjdDogUmU6IFtydGN3 ZWJdIFtBVlRDT1JFXSBbdHN2d2ddIFdHIExhc3QgQ2FsbCBvbiBjaGFuZ2VzOg0KPiBkcmFmdC1p ZXRmLQ0KPiA+Pj4+PiBhdnRjb3JlLXJ0cC1jaXJjdWl0LWJyZWFrZXJzLTE2DQo+ID4+Pj4+DQo+ ID4+Pj4+DQo+ID4+Pj4+PiBPbiAxNiBKdW4gMjAxNiwgYXQgMjM6MjUsIEpvaG4gTGVzbGllIDxq b2huQGpsYy5uZXQ+IHdyb3RlOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEJsYWNrLCBEYXZpZCA8ZGF2 aWQuYmxhY2tAZW1jLmNvbT4gd3JvdGU6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAuLi4gIEkgdmll dyB0aGUgY3VycmVudCB0ZXh0IGFzIHByb3ZpZGluZyBpbXBsZW1lbnRlcnMgd2l0aCB0b28NCj4g bXVjaA0KPiA+Pj4+Pj4+IGxhdGl0dWRlIHRvIGlnbm9yZSBFQ04tQ0UgbWFya3MgKGUuZy4sIGJl Y2F1c2UgYW4gaW1wbGVtZW50ZXINCj4gZG9lc24ndA0KPiA+Pj4+Pj4+IHdhbnQgdG8gdGhpbmsg YWJvdXQgdGhpcyBwcm9ibGVtIHNwYWNlIGluIHRoZSBmaXJzdCBwbGFjZSkuDQo+ID4+Pj4+DQo+ ID4+Pj4+IEkgYWdyZWUsIGJ1dCB0aGUgYXJndW1lbnQgaXMgdGhhdCBkb2luZyBzbyBpcyBsZXNz IGhhcm1mdWwgdGhhbg0KPiBkZXBsb3lpbmcgYQ0KPiA+PiBjaXJjdWl0DQo+ID4+Pj4+IGJyZWFr ZXIgdGhhdCB0cmlnZ2VycyB0b28gb2Z0ZW4gd2hlbiBFQ04gaXMgdXNlZC4NCj4gPj4+Pj4NCj4g Pj4+Pj4gSeKAmW0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMgYXJndW1lbnQsIHRob3VnaCwgc2lu Y2UgaXQgc2VlbXMgdGhhdA0KPiBhbnkgbmV3DQo+ID4+IEFRTQ0KPiA+Pj4+PiB0aGF0IGFwcGxp ZXMgRUNOIG1hcmtzIG11Y2ggbW9yZSBvZnRlbiB0aGFuIGF0IHByZXNlbnQgd2lsbCBoYXZlDQo+ IHRvDQo+ID4+IGNvbnNpZGVyDQo+ID4+Pj4+IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCB0byB3 b3JrIHdpdGggZGVwbG95ZWQgVENQIChlLmcuLCBkcmFmdC0NCj4gYnJpc2NvZS0NCj4gPj4gdHN2 d2ctDQo+ID4+Pj4+IGFxbS10Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVzZXMgRUNUKDEpIGFzIGEg c2lnbmFsIHRvIHVzZSB0aGUgbmV3DQo+IG1hcmtpbmcsDQo+ID4+Pj4+IHdoaWxlIGV4aXN0aW5n IGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDApKS4gVGhlc2UgY29tcGF0aWJpbGl0eQ0KPiBtZWNo YW5pc21zDQo+ID4+Pj4+IHdvdWxkIHNlZW0gdG8gcHJldmVudCB0aGUgaXNzdWVzIHdpdGggdGhl IGNpcmN1aXQgYnJlYWtlciB0b28uDQo+ID4+Pj4+DQo+ID4+Pj4+PiBVbmRlcnN0YW5kLCB3ZSBo YXZlIGF0IGxlYXN0IHR3byBwcm9wb3NhbHMgdG8gbWFrZSBFQ04tQ0UgbW9yZQ0KPiA+PiBmcmVx dWVudA0KPiA+Pj4+Pj4gdGhhbiBwYWNrZXQgZHJvcCB3b3VsZCBiZSBmb3Igbm9uLUVDTiBwYWNr ZXRzOiBwb3NzaWJseQ0KPiBzdWJzdGFudGlhbGx5DQo+ID4+Pj4+PiBtb3JlIGZyZXF1ZW50LiBV bmxlc3MgYm90aCBhcmUga2lsbGVkIG9mZiwgRUNOLUNFIHdpbGwgc2hvdyB1cA0KPiBmcmVxdWVu dGx5DQo+ID4+Pj4+PiBlbm91Z2ggdGhhdCBjbG9zaW5nIHRoZSBmbG93IG9uIEVDTi1DRSB3b3Vs ZCBraWxsIHRvbyBtYW55DQo+IGNvbm5lY3Rpb25zLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IElmIHlv dSB3YW50IGNpcmN1aXQtYnJlYWtpbmcgb24gc3VjaCBjb25uZWN0aW9ucywgdGhlcmUgYXJlIHR3 bw0KPiB3YXlzOg0KPiA+Pj4+Pj4gMS4gY29udmluY2UgdGhlIGZvcndhcmRpbmcgbm9kZXMgdG8g ZHJvcCBwYWNrZXRzIGlmIHRoZWlyIHF1ZXVlDQo+IGV4Y2VlZHMNCj4gPj4+Pj4+IGRlc2lnbiBj YXBhY2l0eTsgb3INCj4gPj4+Pj4+IDIuIHJlcXVpcmUgdGhlIHNlbmRlciB0byBzZW5kIGVub3Vn aCBub3QtRUNOLWNhcGFibGUgcGFja2V0cyBzbw0KPiB0aGF0IG91cg0KPiA+Pj4+Pj4gcmVjZWl2 ZXIgd2lsbCBzZWUgZW5vdWdoIHBhY2tldC1kcm9wcyB3aGVuIGEgY2lyY3VpdC1icmVha2VyDQo+ IHNob3VsZA0KPiA+Pj4+Pj4gYWN0aXZhdGUuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKEkgcHJlZmVy IHRoZSBmaXJzdCBvcHRpb247IGJ1dCBJIHdvdWxkbid0IG9iamVjdCB0byB0aGUgc2Vjb25kLikN Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGVyZSByZWFsbHkgaXNuJ3QgYW55IHdheSBmb3Igb3VyIGNp cmN1aXQtYnJlYWtlciB0byBrbm93DQo+IF9ob3dfbXVjaF8NCj4gPj4+Pj4+IG1vcmUgZnJlcXVl bnQgdGhlIEVDTi1DRSBtYXJrcyBtYXkgYmUuIDpeKA0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGlzIGlz IGEgcHJvYmxlbSwgYm90aCBmb3IgdGhlIGNpcmN1aXQgYnJlYWtlciwgYW5kIGZvciB0aGUNCj4g YWxnb3JpdGhtcyBiZWluZw0KPiA+Pj4+PiBkZWZpbmVkIGluIFJNQ0FULiBXZSBkbyBuZWVkIHNv bWUgdW5kZXJzdGFuZGluZyB3aGF0IHRoZSBleHBlY3RlZA0KPiA+PiBtYXJraW5nDQo+ID4+Pj4+ IHJhdGVzIGFyZSBsaWtlbHkgdG8gYmUsIHNvIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgY2lyY3Vp dCBicmVha2Vycw0KPiBjYW4gYmUNCj4gPj4gZGVmaW5lZC4NCj4gPj4+Pj4NCj4gPj4+Pj4+IFdl IF93aWxsXyBiZSBzb3JyeSBpZiB3ZQ0KPiA+Pj4+Pj4gYWxsb3QgdGhlIHNhbWUgZnJlcXVlbmN5 IG9mIENFIHBhY2tldHMgYXMgcGFja2V0LWRyb3BzIHRvIHRyaWdnZXINCj4gdGhlDQo+ID4+Pj4+ PiBjaXJjdWl0LWJyZWFrZXIuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+IENvdWxkIHNvbWVvbmUgcHJv cG9zZSBpbml0aWFsIHRleHQgdG8gcXVhbGlmaWVzIHRoZSBjdXJyZW50ICJNQVkNCj4gaWdub3Jl Ig0KPiA+Pj4+Pj4+IHN0YXRlbWVudD8NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBFc3NlbnRpYWxseSwg Zm9yIHRoZSBzZWNvbmQgb3B0aW9uLCB5b3UgbWlnaHQgcHJvcG9zZSB0ZXh0IHRvIHRoZQ0KPiA+ Pj4+Pj4gZWZmZWN0IG9mOg0KPiA+Pj4+Pj4gXQ0KPiA+Pj4+Pj4gXSBJZiB0b28gbWFueSBFQ04t Q0UgcGFja2V0cyBhcmUgcmVjZWl2ZWQsIHRoZSBzZW5kZXIgU0hPVUxEIHNlbmQNCj4gc29tZQ0K PiA+Pj4+Pj4gXSBub3QtRUNOLWNhcGFibGUgcGFja2V0cyB0byBkZXRlcm1pbmUgd2hldGhlciBl bm91Z2ggcGFja2V0cw0KPiBhbG9uZyB0aGUNCj4gPj4+Pj4+IF0gcGF0aCBhcmUgYmVpbmcgZHJv cHBlZCB0byBqdXN0aWZ5IGFjdGl2YXRpbmcgb3VyIGNpcmN1aXQtDQo+IGJyZWFrZXIuDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gSeKAmW0gbm90IGVudGh1c2lhc3RpYyBhYm91dCBhZGRpbmcgdGhhdDsg YnV0IGl0IHdvdWxkIHJlc29sdmUgdGhlDQo+IGlzc3VlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJ4oCZ bSBub3QgY29udmluY2VkIHRoaXMgd291bGQgd29yay4gVGhlIGNpcmN1aXQgYnJlYWtlciBpcyBs b29raW5nDQo+IGF0IGxvbmcgdGVybQ0KPiA+Pj4+PiB0cmVuZHMsIGFuZCBpbiBvcmRlciB0byBo YXZlIGVub3VnaCBub3QtRUNUIHBhY2tldHMgdG8gZGV0ZXJtaW5lDQo+IGlmIGl0DQo+ID4+IHNo b3VsZA0KPiA+Pj4+PiB0cmlnZ2VyLCB5b3XigJlkIGVzc2VudGlhbGx5IGhhdmUgdG8gcnVuIHdp dGhvdXQgRUNOIGZvciBzb21lDQo+IHNlY29uZHMuDQo+ID4+Pj4+DQo+ID4+Pj4+IC0tDQo+ID4+ Pj4+IENvbGluIFBlcmtpbnMNCj4gPj4+Pj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiA+Pj4+ DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4+Pj4gcnRjd2ViQGlldGYub3JnDQo+ID4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4gPg0KDQo= From nobody Mon Jun 27 08:41:48 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191CE12D5B5; Mon, 27 Jun 2016 08:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFNKh2IxLZfS; Mon, 27 Jun 2016 08:41:35 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 4324912D868; Mon, 27 Jun 2016 08:38:18 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 778361B00277; Mon, 27 Jun 2016 16:38:06 +0100 (BST) Received: from 148.122.56.254 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 27 Jun 2016 16:38:16 +0100 Message-ID: <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> In-Reply-To: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> Date: Mon, 27 Jun 2016 16:38:16 +0100 From: gorry@erg.abdn.ac.uk To: "De Schepper, Koen (Nokia - BE)" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: gorry@erg.abdn.ac.uk, tsvwg , "Black, David" , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 15:41:39 -0000 I think thinking of L4S is maybe off at a tangent. The question really is about the interpretation of loss and CE-mark as equivalent. I argued that each ECN-CE mark should not be counted as equivalent to a lost segment - in this context we should use ECN to drive a CC algorithm and we should be cautious to avoid requiring its use within a Circuit Breaker - optional use, if you understand how to interpret a reaction to many CE-marks as excessive congestion, are permitted. Gorry > As far as I understand, this draft is related to circuit breakers in > end-systems, right? > > It is the end system that determines the use of ECN (currently marking > non-ect for drop and ect(0) for Classic ECN). > > In L4S we don't plan to change the behavior of Classic ECN, and ABE's > behavior should be close to non-ABE ECN. So I guess there is no problem of > describing the behavior of how a Classic ECN based sender would respond > today. > > As we only want to significantly change the network behavior of ect(1) > marking, can we solve this issue by recommending (or even requiring) > senders to mark only ect(0) and describing the classic ECN circuit > breaker? When L4S gets defined, also an L4S based circuit breaker > extension can be defined for senders that want to use the L4S service > (when senders send ect(1) packets). > > Regards, > Koen. > > >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael Welzl >> Sent: maandag 20 juni 2016 18:36 >> To: Black, David >> Cc: Fairhurst; Magnus Westerlund; tsvwg; IETF >> AVTCore WG; rtcweb@ietf.org; Colin Perkins >> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft- >> ietf-avtcore-rtp-circuit-breakers-16 >> >> >> > On 20. jun. 2016, at 15.16, Black, David wrote: >> > >> >>> But I’m less concerned than David about eventually ignoring it >> for >> circuit >> >> breaker. >> >>> >> >> Agree. Loss is the measurement that a CB MUST respond to. >> > >> > Mumble. I would be ok with a clear discouragement for use of ECN-CE >> marks, accompanied by the sort of design rationale here, or even >> better, >> a clear statement that lost packets for the purpose of the RTP circuit >> breaker have to be actually lost without getting into whether or not >> ECN-CE marks are involved -i.e., the RTP circuit breaker is specified >> against actual drops as a network protection backstop. >> > >> > A related concern is that ECN marks may overstate equivalent loss >> behavior - a simplistic queue management discipline that marks every >> packet when the queue is over a threshold (NB: this class of marking >> behavior is NOT RECOMMENDED - a real AQM SHOULD be used) could yield a >> run of ECN-CE marks that would not cause a corresponding with a run of >> packet drops. This is among the reasons that TCP reacts to ECN-CE >> marks only once per RTT, and might be a reason to treat multiple ECN-CE >> marks in an RTT interval as not representing drops of all packets for >> the RTP circuit breaker's TCP-equivalent throughput calculation. >> >> I’m not sure we need such complicated logic to find a case where ECN >> marks are different from packet drops: >> >> Basically, they simply aren’t - even “real†AQMs marking isn’t >> exactly >> the same as a packet drop: the marks themselves inform you that an AQM >> did its job, and with modern AQMs like CoDel / PIE etc., you’re >> probably >> getting this from a shallow queue. Chances are that this is less than a >> BDP worth of queuing, which is our justification for recommending a >> different back-off behavior in draft-khademi-tsvwg-ecn-response-00 and >> draft-khademi-tcpm-alternativebackoff-ecn-00 >> >> So the point is not that AQMs would treat ECN marking and dropping >> differently - it’s that ECN indicates an AQM, and hence probably a >> shallow queue. With a drop, you just don’t know. >> >> Back to the CB, I think an AQM marking at a shallow queue (like e.g. >> CoDel) is indeed quite different from a “broken connectionâ€. >> >> Cheers, >> Michael >> >> >> > >> > Thanks, --David >> > >> >> -----Original Message----- >> >> From: Gorry (erg) [mailto:gorry@erg.abdn.ac.uk] >> >> Sent: Saturday, June 18, 2016 2:23 AM >> >> To: Mirja Kühlewind >> >> Cc: Black, David; Magnus Westerlund; Colin Perkins; rtcweb@ietf.org; >> IETF >> >> AVTCore WG; tsvwg >> >> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: >> draft-ietf- >> >> avtcore-rtp-circuit-breakers-16 >> >> >> >> I think we SHOULD NOT recommend to use ECN marks as inputs to a CB. >> See >> >> below: >> >> >> >>> On 17 Jun 2016, at 16:02, Mirja Kühlewind >> >> >> wrote: >> >>> >> >>> +1 to not use normative language here. >> >>> >> >>> However, please note that having a high level of ECN-CE marks >> (without any >> >> losses) means that all packets were received correctly. This >> situation can even >> >> occurs without high delays (depending on the AQM used), which would >> just >> >> mean the services works perfectly. Therefore for me CE marks are a >> perfect input >> >> signal for a congestion control loop (where the AQM tell the sender >> to take action >> >> - whatever that means). >> >> >> >> We may in future figure out ways to do this to detect significant >> failure using a >> >> rate adaptive transport and ECN e.g. Observing 100% CE marks or >> something, for >> >> an RTP flow that is trying to send well below its peak rate decided >> by CC -- but I >> >> think this is speculating at an algorithm and adding details here is >> not a good idea. >> >> Especially as AQM continues to evolve. >> >> >> >>> But I’m less concerned than David about eventually ignoring it >> for >> circuit >> >> breaker. >> >>> >> >> Agree. Loss is the measurement that a CB MUST respond to. >> >> >> >>> In addition one point on something Magnus wrote earlier: >> >>> "If the implementation only have circuit breaker, i.e. no full >> fledged congestion >> >> controller and uses ECN, they can in worst case drive the buffer >> into >> the overload >> >> regime where it starts dropping packets. „ >> >>> >> >>> I’m not sure about this case. ECN is an input signal for >> congestion >> control. If you >> >> don’t use congestion control but only a circuit breaker, you >> should >> probably not >> >> enable ECN. At least it not clear to me why you would enable it, and >> it's definitely >> >> not conform to the ECN spec. Probably we should say something about >> this in the >> >> draft...? >> >>> >> >> Agree, enabling ECN without a responsive CC is going to lead to >> trouble. >> >> >> >>> Mirja >> >>> >> >> Gorry >> >> >> >>>> Am 17.06.2016 um 16:03 schrieb Black, David : >> >>>> >> >>>> Colin, >> >>>> >> >>>>>>> ... I view the current text as providing implementers with too >> much >> >>>>>>> latitude to ignore ECN-CE marks (e.g., because an implementer >> doesn't >> >>>>>>> want to think about this problem space in the first place). >> >>>>> >> >>>>> I agree, but the argument is that doing so is less harmful than >> deploying a >> >> circuit >> >>>>> breaker that triggers too often when ECN is used. >> >>>>> >> >>>>> I’m not sure I believe this argument, though, since it seems >> that >> any new >> >> AQM >> >>>>> that applies ECN marks much more often than at present will have >> to >> >> consider >> >>>>> backwards compatibility, to work with deployed TCP (e.g., draft- >> briscoe- >> >> tsvwg- >> >>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new >> marking, >> >>>>> while existing implementations set ECT(0)). These compatibility >> mechanisms >> >>>>> would seem to prevent the issues with the circuit breaker too. >> >>>> >> >>>> That roughly matches my line of thinking, and I'll observe that >> the >> original >> >> DCTCP >> >>>> protocol design that used more aggressive ECN-CE marking was only >> safe for >> >>>> Controlled Environment deployments. See the TSVWG rfc5405bis >> draft for >> >> the >> >>>> definition of Controlled Environment, and ignore the fact that the >> rfc5405bis >> >>>> draft is a UDP draft - this definition is more broadly applicable. >> >>>> >> >>>> Going back over Section 7 in this avtcore draft, my views are: >> >>>> >> >>>> [A] None of these drafts justify a "MAY ignore" response to ECN-CE >> marks: >> >>>> - draft-khademi-tcpm-alternativebackoff-ecn >> >>>> - draft-ietf-rmcat-nada >> >>>> - draft-ietf-rmcat-scream-cc >> >>>> >> >>>> [B] In line with Colin's comment on the L4S draft, I think it's >> incumbent on >> >>>> the authors of draft-briscoe-aqm-dualq-coupled to figure out how >> that will >> >>>> coexist (or avoid) deployed TCP, and this avtcore draft ought not >> to be >> >>>> trying to prejudge what will be done there. >> >>>> >> >>>> So, I don't think the current text in Section 7 has justified the >> unfettered >> >>>> "implementations MAY ignore ECN-CE marks" text, as ignoring those >> marks >> >>>> is not consistent with any of the four cited drafts. >> >>>> >> >>>> In more detail, I think making changes to normative requirements >> here based >> >>>> on [B] is premature, and I would hope that the rmcat WG could be >> >> encouraged >> >>>> to consider the RTP circuit breaker in its congestion control >> drafts, as those CC >> >>>> mechanisms are related to the circuit breaker mechanism, hence >> likely >> >>>> to be in related areas of an RTP implementation. >> >>>> >> >>>> That leaves draft-khademi-tcpm-alternativebackoff-ecn, which TSVWG >> >>>> will be looking at in Berlin. If a normative statement about ECN- >> CE reaction >> >>>> is going to rest on that draft, then the reference to that draft >> should be >> >>>> normative. Something about doing that strikes me as premature ... >> >>>> >> >>>> I realize that we're trying to predict and accommodate the future, >> which >> >>>> is an imprecise undertaking at best. As an alternative to the >> current text, >> >>>> would it be reasonable to say (without any RFC 2119 keywords) that >> the >> >>>> best current guidance is still to treat ECN-CE marks as indicating >> drops, >> >>>> with a warning that there is a good possibility of this changing >> in >> the >> >>>> near future due to all of the work in progress cited in Section 7? >> >>>> >> >>>> Thanks, --David >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Colin Perkins [mailto:csp@csperkins.org] >> >>>>> Sent: Friday, June 17, 2016 6:14 AM >> >>>>> To: John Leslie; Black, David >> >>>>> Cc: rtcweb@ietf.org; IETF AVTCore WG; tsvwg >> >>>>> Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: >> draft-ietf- >> >>>>> avtcore-rtp-circuit-breakers-16 >> >>>>> >> >>>>> >> >>>>>> On 16 Jun 2016, at 23:25, John Leslie wrote: >> >>>>>> >> >>>>>> Black, David wrote: >> >>>>>>> >> >>>>>>> ... I view the current text as providing implementers with too >> much >> >>>>>>> latitude to ignore ECN-CE marks (e.g., because an implementer >> doesn't >> >>>>>>> want to think about this problem space in the first place). >> >>>>> >> >>>>> I agree, but the argument is that doing so is less harmful than >> deploying a >> >> circuit >> >>>>> breaker that triggers too often when ECN is used. >> >>>>> >> >>>>> I’m not sure I believe this argument, though, since it seems >> that >> any new >> >> AQM >> >>>>> that applies ECN marks much more often than at present will have >> to >> >> consider >> >>>>> backwards compatibility, to work with deployed TCP (e.g., draft- >> briscoe- >> >> tsvwg- >> >>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the new >> marking, >> >>>>> while existing implementations set ECT(0)). These compatibility >> mechanisms >> >>>>> would seem to prevent the issues with the circuit breaker too. >> >>>>> >> >>>>>> Understand, we have at least two proposals to make ECN-CE more >> >> frequent >> >>>>>> than packet drop would be for non-ECN packets: possibly >> substantially >> >>>>>> more frequent. Unless both are killed off, ECN-CE will show up >> frequently >> >>>>>> enough that closing the flow on ECN-CE would kill too many >> connections. >> >>>>>> >> >>>>>> If you want circuit-breaking on such connections, there are two >> ways: >> >>>>>> 1. convince the forwarding nodes to drop packets if their queue >> exceeds >> >>>>>> design capacity; or >> >>>>>> 2. require the sender to send enough not-ECN-capable packets so >> that our >> >>>>>> receiver will see enough packet-drops when a circuit-breaker >> should >> >>>>>> activate. >> >>>>>> >> >>>>>> (I prefer the first option; but I wouldn't object to the >> second.) >> >>>>>> >> >>>>>> There really isn't any way for our circuit-breaker to know >> _how_much_ >> >>>>>> more frequent the ECN-CE marks may be. :^( >> >>>>> >> >>>>> This is a problem, both for the circuit breaker, and for the >> algorithms being >> >>>>> defined in RMCAT. We do need some understanding what the expected >> >> marking >> >>>>> rates are likely to be, so congestion control and circuit >> breakers >> can be >> >> defined. >> >>>>> >> >>>>>> We _will_ be sorry if we >> >>>>>> allot the same frequency of CE packets as packet-drops to >> trigger >> the >> >>>>>> circuit-breaker. >> >>>>>> >> >>>>>>> Could someone propose initial text to qualifies the current >> "MAY >> ignore" >> >>>>>>> statement? >> >>>>>> >> >>>>>> Essentially, for the second option, you might propose text to >> the >> >>>>>> effect of: >> >>>>>> ] >> >>>>>> ] If too many ECN-CE packets are received, the sender SHOULD >> send >> some >> >>>>>> ] not-ECN-capable packets to determine whether enough packets >> along the >> >>>>>> ] path are being dropped to justify activating our circuit- >> breaker. >> >>>>>> >> >>>>>> I’m not enthusiastic about adding that; but it would resolve >> the >> issue. >> >>>>> >> >>>>> I’m not convinced this would work. The circuit breaker is >> looking >> at long term >> >>>>> trends, and in order to have enough not-ECT packets to determine >> if it >> >> should >> >>>>> trigger, you’d essentially have to run without ECN for some >> seconds. >> >>>>> >> >>>>> -- >> >>>>> Colin Perkins >> >>>>> https://csperkins.org/ >> >>>> >> >>>> _______________________________________________ >> >>>> rtcweb mailing list >> >>>> rtcweb@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > From nobody Mon Jun 27 12:13:01 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A1512D7F8; Mon, 27 Jun 2016 12:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unfi0uI2xgCz; Mon, 27 Jun 2016 12:12:55 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC35A12D7D1; Mon, 27 Jun 2016 12:12:54 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B03A0F90A1507; Mon, 27 Jun 2016 19:12:48 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5RJCpTx026670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Jun 2016 19:12:52 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5RJCpZH011789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jun 2016 21:12:51 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 27 Jun 2016 21:12:51 +0200 From: "De Schepper, Koen (Nokia - BE)" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRyB4Xv7l4815Xu02SCqscZNZxsp/tUDQAgABAKwCAABBvgIABAQmAgAOYcQCAADeCAIAK/Ekg///0AQCAAFzOEA== Date: Mon, 27 Jun 2016 19:12:50 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> In-Reply-To: <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: tsvwg , "Black, David" , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 19:12:59 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGdvcnJ5QGVyZy5hYmRuLmFj LnVrIFttYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWtdDQo+IFNlbnQ6IG1hYW5kYWcgMjcganVu aSAyMDE2IDE3OjM4DQo+IFRvOiBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRSkNCj4gQ2M6 IE1pY2hhZWwgV2Vsemw7IEJsYWNrLCBEYXZpZDsgZ29ycnlAZXJnLmFiZG4uYWMudWs7IE1hZ251 cw0KPiBXZXN0ZXJsdW5kOyB0c3Z3ZzsgSUVURiBBVlRDb3JlIFdHOyBydGN3ZWJAaWV0Zi5vcmc7 IENvbGluIFBlcmtpbnMNCj4gU3ViamVjdDogUmU6IFt0c3Z3Z10gW3J0Y3dlYl0gW0FWVENPUkVd IFdHIExhc3QgQ2FsbCBvbiBjaGFuZ2VzOiBkcmFmdC0NCj4gaWV0Zi1hdnRjb3JlLXJ0cC1jaXJj dWl0LWJyZWFrZXJzLTE2DQo+IA0KPiBJIHRoaW5rIHRoaW5raW5nIG9mIEw0UyBpcyBtYXliZSBv ZmYgYXQgYSB0YW5nZW50LiBUaGUgcXVlc3Rpb24gcmVhbGx5DQo+IGlzDQo+IGFib3V0IHRoZSBp bnRlcnByZXRhdGlvbiBvZiBsb3NzIGFuZCBDRS1tYXJrIGFzIGVxdWl2YWxlbnQuIEkgYXJndWVk DQo+IHRoYXQNCj4gZWFjaCBFQ04tQ0UgbWFyayBzaG91bGQgbm90IGJlIGNvdW50ZWQgYXMgZXF1 aXZhbGVudCB0byBhIGxvc3Qgc2VnbWVudCAtDQoNCldoeSBub3Q/IEFzIGxvbmcgYXMgYW4gQVFN IGlzIG1hcmtpbmcgYXQgdGhlIHNhbWUgcmF0ZSBhcyBkcm9wcGluZywgYSANCjEwMCUgbWFya2lu ZyBtZWFucyB0aGF0IG5vbi1lY24gZmxvd3MgYXJlIGJlaW5nIGRyb3BwZWQgYXQgYSAxMDAlLCBu b3Q/DQoNCktvZW4uDQoNCg0KPiBpbiB0aGlzIGNvbnRleHQgd2Ugc2hvdWxkIHVzZSBFQ04gdG8g ZHJpdmUgYSBDQyBhbGdvcml0aG0gYW5kIHdlIHNob3VsZA0KPiBiZQ0KPiBjYXV0aW91cyB0byBh dm9pZCByZXF1aXJpbmcgaXRzIHVzZSB3aXRoaW4gYSBDaXJjdWl0IEJyZWFrZXIgLSBvcHRpb25h bA0KPiB1c2UsIGlmIHlvdSB1bmRlcnN0YW5kIGhvdyB0byBpbnRlcnByZXQgYSByZWFjdGlvbiB0 byBtYW55IENFLW1hcmtzIGFzDQo+IGV4Y2Vzc2l2ZSBjb25nZXN0aW9uLCBhcmUgcGVybWl0dGVk Lg0KPiANCj4gR29ycnkNCj4gDQo+ID4gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhpcyBkcmFm dCBpcyByZWxhdGVkIHRvIGNpcmN1aXQgYnJlYWtlcnMgaW4NCj4gPiBlbmQtc3lzdGVtcywgcmln aHQ/DQo+ID4NCj4gPiBJdCBpcyB0aGUgZW5kIHN5c3RlbSB0aGF0IGRldGVybWluZXMgdGhlIHVz ZSBvZiBFQ04gKGN1cnJlbnRseSBtYXJraW5nDQo+ID4gbm9uLWVjdCBmb3IgZHJvcCBhbmQgZWN0 KDApIGZvciBDbGFzc2ljIEVDTikuDQo+ID4NCj4gPiBJbiBMNFMgd2UgZG9uJ3QgcGxhbiB0byBj aGFuZ2UgdGhlIGJlaGF2aW9yIG9mIENsYXNzaWMgRUNOLCBhbmQgQUJFJ3MNCj4gPiBiZWhhdmlv ciBzaG91bGQgYmUgY2xvc2UgdG8gbm9uLUFCRSBFQ04uIFNvIEkgZ3Vlc3MgdGhlcmUgaXMgbm8N Cj4gcHJvYmxlbSBvZg0KPiA+IGRlc2NyaWJpbmcgdGhlIGJlaGF2aW9yIG9mIGhvdyBhIENsYXNz aWMgRUNOIGJhc2VkIHNlbmRlciB3b3VsZA0KPiByZXNwb25kDQo+ID4gdG9kYXkuDQo+ID4NCj4g PiBBcyB3ZSBvbmx5IHdhbnQgdG8gc2lnbmlmaWNhbnRseSBjaGFuZ2UgdGhlIG5ldHdvcmsgYmVo YXZpb3Igb2YgZWN0KDEpDQo+ID4gbWFya2luZywgY2FuIHdlIHNvbHZlIHRoaXMgaXNzdWUgYnkg cmVjb21tZW5kaW5nIChvciBldmVuIHJlcXVpcmluZykNCj4gPiBzZW5kZXJzIHRvIG1hcmsgb25s eSBlY3QoMCkgYW5kIGRlc2NyaWJpbmcgdGhlIGNsYXNzaWMgRUNOIGNpcmN1aXQNCj4gPiBicmVh a2VyPyBXaGVuIEw0UyBnZXRzIGRlZmluZWQsIGFsc28gYW4gTDRTIGJhc2VkIGNpcmN1aXQgYnJl YWtlcg0KPiA+IGV4dGVuc2lvbiBjYW4gYmUgZGVmaW5lZCBmb3Igc2VuZGVycyB0aGF0IHdhbnQg dG8gdXNlIHRoZSBMNFMgc2VydmljZQ0KPiA+ICh3aGVuIHNlbmRlcnMgc2VuZCBlY3QoMSkgcGFj a2V0cykuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IEtvZW4uDQo+ID4NCj4gPg0KPiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsDQo+IFdlbHpsDQo+ID4+IFNlbnQ6 IG1hYW5kYWcgMjAganVuaSAyMDE2IDE4OjM2DQo+ID4+IFRvOiBCbGFjaywgRGF2aWQNCj4gPj4g Q2M6IDxnb3JyeUBlcmcuYWJkbi5hYy51az4gRmFpcmh1cnN0OyBNYWdudXMgV2VzdGVybHVuZDsg dHN2d2c7IElFVEYNCj4gPj4gQVZUQ29yZSBXRzsgcnRjd2ViQGlldGYub3JnOyBDb2xpbiBQZXJr aW5zDQo+ID4+IFN1YmplY3Q6IFJlOiBbdHN2d2ddIFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0 IENhbGwgb24gY2hhbmdlczoNCj4gZHJhZnQtDQo+ID4+IGlldGYtYXZ0Y29yZS1ydHAtY2lyY3Vp dC1icmVha2Vycy0xNg0KPiA+Pg0KPiA+Pg0KPiA+PiA+IE9uIDIwLiBqdW4uIDIwMTYsIGF0IDE1 LjE2LCBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb20+DQo+IHdyb3RlOg0KPiA+PiA+ DQo+ID4+ID4+PiBCdXQgScOi4oKs4oSibSBsZXNzIGNvbmNlcm5lZCB0aGFuIERhdmlkIGFib3V0 IGV2ZW50dWFsbHkgaWdub3JpbmcgaXQNCj4gPj4gZm9yDQo+ID4+IGNpcmN1aXQNCj4gPj4gPj4g YnJlYWtlci4NCj4gPj4gPj4+DQo+ID4+ID4+IEFncmVlLiBMb3NzIGlzIHRoZSBtZWFzdXJlbWVu dCB0aGF0IGEgQ0IgTVVTVCByZXNwb25kIHRvLg0KPiA+PiA+DQo+ID4+ID4gTXVtYmxlLiAgIEkg d291bGQgYmUgb2sgd2l0aCBhIGNsZWFyIGRpc2NvdXJhZ2VtZW50IGZvciB1c2Ugb2YgRUNOLQ0K PiBDRQ0KPiA+PiBtYXJrcywgYWNjb21wYW5pZWQgYnkgdGhlIHNvcnQgb2YgZGVzaWduIHJhdGlv bmFsZSBoZXJlLCBvciBldmVuDQo+ID4+IGJldHRlciwNCj4gPj4gYSBjbGVhciBzdGF0ZW1lbnQg dGhhdCBsb3N0IHBhY2tldHMgZm9yIHRoZSBwdXJwb3NlIG9mIHRoZSBSVFANCj4gY2lyY3VpdA0K PiA+PiBicmVha2VyIGhhdmUgdG8gYmUgYWN0dWFsbHkgbG9zdCB3aXRob3V0IGdldHRpbmcgaW50 byB3aGV0aGVyIG9yIG5vdA0KPiA+PiBFQ04tQ0UgbWFya3MgYXJlIGludm9sdmVkIC1pLmUuLCB0 aGUgUlRQIGNpcmN1aXQgYnJlYWtlciBpcyBzcGVjaWZpZWQNCj4gPj4gYWdhaW5zdCBhY3R1YWwg ZHJvcHMgYXMgYSBuZXR3b3JrIHByb3RlY3Rpb24gYmFja3N0b3AuDQo+ID4+ID4NCj4gPj4gPiBB IHJlbGF0ZWQgY29uY2VybiBpcyB0aGF0IEVDTiBtYXJrcyBtYXkgb3ZlcnN0YXRlIGVxdWl2YWxl bnQgbG9zcw0KPiA+PiBiZWhhdmlvciAtIGEgc2ltcGxpc3RpYyBxdWV1ZSBtYW5hZ2VtZW50IGRp c2NpcGxpbmUgdGhhdCBtYXJrcyBldmVyeQ0KPiA+PiBwYWNrZXQgd2hlbiB0aGUgcXVldWUgaXMg b3ZlciBhIHRocmVzaG9sZCAoTkI6IHRoaXMgY2xhc3Mgb2YgbWFya2luZw0KPiA+PiBiZWhhdmlv ciBpcyBOT1QgUkVDT01NRU5ERUQgLSBhIHJlYWwgQVFNIFNIT1VMRCBiZSB1c2VkKSBjb3VsZCB5 aWVsZA0KPiBhDQo+ID4+IHJ1biBvZiBFQ04tQ0UgbWFya3MgdGhhdCB3b3VsZCBub3QgY2F1c2Ug YSBjb3JyZXNwb25kaW5nIHdpdGggYSBydW4NCj4gb2YNCj4gPj4gcGFja2V0IGRyb3BzLiAgIFRo aXMgaXMgYW1vbmcgdGhlIHJlYXNvbnMgdGhhdCBUQ1AgcmVhY3RzIHRvIEVDTi1DRQ0KPiA+PiBt YXJrcyBvbmx5IG9uY2UgcGVyIFJUVCwgYW5kIG1pZ2h0IGJlIGEgcmVhc29uIHRvIHRyZWF0IG11 bHRpcGxlIEVDTi0NCj4gQ0UNCj4gPj4gbWFya3MgaW4gYW4gUlRUIGludGVydmFsIGFzIG5vdCBy ZXByZXNlbnRpbmcgZHJvcHMgb2YgYWxsIHBhY2tldHMgZm9yDQo+ID4+IHRoZSBSVFAgY2lyY3Vp dCBicmVha2VyJ3MgVENQLWVxdWl2YWxlbnQgdGhyb3VnaHB1dCBjYWxjdWxhdGlvbi4NCj4gPj4N Cj4gPj4gScOi4oKs4oSibSBub3Qgc3VyZSB3ZSBuZWVkIHN1Y2ggY29tcGxpY2F0ZWQgbG9naWMg dG8gZmluZCBhIGNhc2Ugd2hlcmUNCj4gRUNODQo+ID4+IG1hcmtzIGFyZSBkaWZmZXJlbnQgZnJv bSBwYWNrZXQgZHJvcHM6DQo+ID4+DQo+ID4+IEJhc2ljYWxseSwgdGhleSBzaW1wbHkgYXJlbsOi 4oKs4oSidCAtIGV2ZW4gw6LigqzFk3JlYWzDouKCrMKdIEFRTXMgbWFya2luZw0KPiBpc27DouKC rOKEonQNCj4gPj4gZXhhY3RseQ0KPiA+PiB0aGUgc2FtZSBhcyBhIHBhY2tldCBkcm9wOiB0aGUg bWFya3MgdGhlbXNlbHZlcyBpbmZvcm0geW91IHRoYXQgYW4NCj4gQVFNDQo+ID4+IGRpZCBpdHMg am9iLCBhbmQgd2l0aCBtb2Rlcm4gQVFNcyBsaWtlIENvRGVsIC8gUElFIGV0Yy4sIHlvdcOi4oKs 4oSicmUNCj4gPj4gcHJvYmFibHkNCj4gPj4gZ2V0dGluZyB0aGlzIGZyb20gYSBzaGFsbG93IHF1 ZXVlLiBDaGFuY2VzIGFyZSB0aGF0IHRoaXMgaXMgbGVzcyB0aGFuDQo+IGENCj4gPj4gQkRQIHdv cnRoIG9mIHF1ZXVpbmcsIHdoaWNoIGlzIG91ciBqdXN0aWZpY2F0aW9uIGZvciByZWNvbW1lbmRp bmcgYQ0KPiA+PiBkaWZmZXJlbnQgYmFjay1vZmYgYmVoYXZpb3IgaW4gZHJhZnQta2hhZGVtaS10 c3Z3Zy1lY24tcmVzcG9uc2UtMDANCj4gYW5kDQo+ID4+IGRyYWZ0LWtoYWRlbWktdGNwbS1hbHRl cm5hdGl2ZWJhY2tvZmYtZWNuLTAwDQo+ID4+DQo+ID4+IFNvIHRoZSBwb2ludCBpcyBub3QgdGhh dCBBUU1zIHdvdWxkIHRyZWF0IEVDTiBtYXJraW5nIGFuZCBkcm9wcGluZw0KPiA+PiBkaWZmZXJl bnRseSAtIGl0w6LigqzihKJzIHRoYXQgRUNOIGluZGljYXRlcyBhbiBBUU0sIGFuZCBoZW5jZSBw cm9iYWJseSBhDQo+ID4+IHNoYWxsb3cgcXVldWUuIFdpdGggYSBkcm9wLCB5b3UganVzdCBkb27D ouKCrOKEonQga25vdy4NCj4gPj4NCj4gPj4gQmFjayB0byB0aGUgQ0IsIEkgdGhpbmsgYW4gQVFN IG1hcmtpbmcgYXQgYSBzaGFsbG93IHF1ZXVlIChsaWtlIGUuZy4NCj4gPj4gQ29EZWwpIGlzIGlu ZGVlZCBxdWl0ZSBkaWZmZXJlbnQgZnJvbSBhIMOi4oKsxZNicm9rZW4gY29ubmVjdGlvbsOi4oKs wp0uDQo+ID4+DQo+ID4+IENoZWVycywNCj4gPj4gTWljaGFlbA0KPiA+Pg0KPiA+Pg0KPiA+PiA+ DQo+ID4+ID4gVGhhbmtzLCAtLURhdmlkDQo+ID4+ID4NCj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPj4gPj4gRnJvbTogR29ycnkgKGVyZykgW21haWx0bzpnb3JyeUBlcmcu YWJkbi5hYy51a10NCj4gPj4gPj4gU2VudDogU2F0dXJkYXksIEp1bmUgMTgsIDIwMTYgMjoyMyBB TQ0KPiA+PiA+PiBUbzogTWlyamEgS8ODwrxobGV3aW5kDQo+ID4+ID4+IENjOiBCbGFjaywgRGF2 aWQ7IE1hZ251cyBXZXN0ZXJsdW5kOyBDb2xpbiBQZXJraW5zOw0KPiBydGN3ZWJAaWV0Zi5vcmc7 DQo+ID4+IElFVEYNCj4gPj4gPj4gQVZUQ29yZSBXRzsgdHN2d2cNCj4gPj4gPj4gU3ViamVjdDog UmU6IFt0c3Z3Z10gW3J0Y3dlYl0gW0FWVENPUkVdIFdHIExhc3QgQ2FsbCBvbiBjaGFuZ2VzOg0K PiA+PiBkcmFmdC1pZXRmLQ0KPiA+PiA+PiBhdnRjb3JlLXJ0cC1jaXJjdWl0LWJyZWFrZXJzLTE2 DQo+ID4+ID4+DQo+ID4+ID4+IEkgdGhpbmsgd2UgU0hPVUxEIE5PVCByZWNvbW1lbmQgdG8gdXNl IEVDTiBtYXJrcyBhcyBpbnB1dHMgdG8gYQ0KPiBDQi4NCj4gPj4gU2VlDQo+ID4+ID4+IGJlbG93 Og0KPiA+PiA+Pg0KPiA+PiA+Pj4gT24gMTcgSnVuIDIwMTYsIGF0IDE2OjAyLCBNaXJqYSBLw4PC vGhsZXdpbmQNCj4gPj4gPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+DQo+ID4+ID4+ IHdyb3RlOg0KPiA+PiA+Pj4NCj4gPj4gPj4+ICsxIHRvIG5vdCB1c2Ugbm9ybWF0aXZlIGxhbmd1 YWdlIGhlcmUuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gSG93ZXZlciwgcGxlYXNlIG5vdGUgdGhhdCBo YXZpbmcgYSBoaWdoIGxldmVsIG9mIEVDTi1DRSBtYXJrcw0KPiA+PiAod2l0aG91dCBhbnkNCj4g Pj4gPj4gbG9zc2VzKSBtZWFucyB0aGF0IGFsbCBwYWNrZXRzIHdlcmUgcmVjZWl2ZWQgY29ycmVj dGx5LiBUaGlzDQo+ID4+IHNpdHVhdGlvbiBjYW4gZXZlbg0KPiA+PiA+PiBvY2N1cnMgd2l0aG91 dCBoaWdoIGRlbGF5cyAoZGVwZW5kaW5nIG9uIHRoZSBBUU0gdXNlZCksIHdoaWNoDQo+IHdvdWxk DQo+ID4+IGp1c3QNCj4gPj4gPj4gbWVhbiB0aGUgc2VydmljZXMgd29ya3MgcGVyZmVjdGx5LiBU aGVyZWZvcmUgZm9yIG1lIENFIG1hcmtzIGFyZSBhDQo+ID4+IHBlcmZlY3QgaW5wdXQNCj4gPj4g Pj4gc2lnbmFsIGZvciBhIGNvbmdlc3Rpb24gY29udHJvbCBsb29wICh3aGVyZSB0aGUgQVFNIHRl bGwgdGhlDQo+IHNlbmRlcg0KPiA+PiB0byB0YWtlIGFjdGlvbg0KPiA+PiA+PiAtIHdoYXRldmVy IHRoYXQgbWVhbnMpLg0KPiA+PiA+Pg0KPiA+PiA+PiBXZSBtYXkgaW4gZnV0dXJlIGZpZ3VyZSBv dXQgd2F5cyB0byBkbyB0aGlzIHRvIGRldGVjdCBzaWduaWZpY2FudA0KPiA+PiBmYWlsdXJlIHVz aW5nIGENCj4gPj4gPj4gcmF0ZSBhZGFwdGl2ZSB0cmFuc3BvcnQgYW5kIEVDTiBlLmcuICBPYnNl cnZpbmcgMTAwJSBDRSBtYXJrcyBvcg0KPiA+PiBzb21ldGhpbmcsIGZvcg0KPiA+PiA+PiBhbiBS VFAgZmxvdyB0aGF0IGlzIHRyeWluZyB0byBzZW5kIHdlbGwgYmVsb3cgaXRzIHBlYWsgcmF0ZQ0K PiBkZWNpZGVkDQo+ID4+IGJ5IENDIC0tIGJ1dCBJDQo+ID4+ID4+IHRoaW5rIHRoaXMgaXMgc3Bl Y3VsYXRpbmcgYXQgYW4gYWxnb3JpdGhtIGFuZCBhZGRpbmcgZGV0YWlscyBoZXJlDQo+IGlzDQo+ ID4+IG5vdCBhIGdvb2QgaWRlYS4NCj4gPj4gPj4gRXNwZWNpYWxseSBhcyBBUU0gY29udGludWVz IHRvIGV2b2x2ZS4NCj4gPj4gPj4NCj4gPj4gPj4+IEJ1dCBJw6LigqzihKJtIGxlc3MgY29uY2Vy bmVkIHRoYW4gRGF2aWQgYWJvdXQgZXZlbnR1YWxseSBpZ25vcmluZyBpdA0KPiA+PiBmb3INCj4g Pj4gY2lyY3VpdA0KPiA+PiA+PiBicmVha2VyLg0KPiA+PiA+Pj4NCj4gPj4gPj4gQWdyZWUuIExv c3MgaXMgdGhlIG1lYXN1cmVtZW50IHRoYXQgYSBDQiBNVVNUIHJlc3BvbmQgdG8uDQo+ID4+ID4+ DQo+ID4+ID4+PiBJbiBhZGRpdGlvbiBvbmUgcG9pbnQgb24gc29tZXRoaW5nIE1hZ251cyB3cm90 ZSBlYXJsaWVyOg0KPiA+PiA+Pj4gIklmIHRoZSBpbXBsZW1lbnRhdGlvbiBvbmx5IGhhdmUgY2ly Y3VpdCBicmVha2VyLCBpLmUuIG5vIGZ1bGwNCj4gPj4gZmxlZGdlZCBjb25nZXN0aW9uDQo+ID4+ ID4+IGNvbnRyb2xsZXIgYW5kIHVzZXMgRUNOLCB0aGV5IGNhbiBpbiB3b3JzdCBjYXNlIGRyaXZl IHRoZSBidWZmZXINCj4gPj4gaW50bw0KPiA+PiB0aGUgb3ZlcmxvYWQNCj4gPj4gPj4gcmVnaW1l IHdoZXJlIGl0IHN0YXJ0cyBkcm9wcGluZyBwYWNrZXRzLiDDouKCrMW+DQo+ID4+ID4+Pg0KPiA+ PiA+Pj4gScOi4oKs4oSibSBub3Qgc3VyZSBhYm91dCB0aGlzIGNhc2UuIEVDTiBpcyBhbiBpbnB1 dCBzaWduYWwgZm9yDQo+ID4+IGNvbmdlc3Rpb24NCj4gPj4gY29udHJvbC4gSWYgeW91DQo+ID4+ ID4+IGRvbsOi4oKs4oSidCB1c2UgY29uZ2VzdGlvbiBjb250cm9sIGJ1dCBvbmx5IGEgY2lyY3Vp dCBicmVha2VyLCB5b3UNCj4gPj4gc2hvdWxkDQo+ID4+IHByb2JhYmx5IG5vdA0KPiA+PiA+PiBl bmFibGUgRUNOLiBBdCBsZWFzdCBpdCBub3QgY2xlYXIgdG8gbWUgd2h5IHlvdSB3b3VsZCBlbmFi bGUgaXQsDQo+IGFuZA0KPiA+PiBpdCdzIGRlZmluaXRlbHkNCj4gPj4gPj4gbm90IGNvbmZvcm0g dG8gdGhlIEVDTiBzcGVjLiBQcm9iYWJseSB3ZSBzaG91bGQgc2F5IHNvbWV0aGluZw0KPiBhYm91 dA0KPiA+PiB0aGlzIGluIHRoZQ0KPiA+PiA+PiBkcmFmdC4uLj8NCj4gPj4gPj4+DQo+ID4+ID4+ IEFncmVlLCBlbmFibGluZyBFQ04gd2l0aG91dCBhIHJlc3BvbnNpdmUgQ0MgaXMgZ29pbmcgdG8g bGVhZCB0bw0KPiA+PiB0cm91YmxlLg0KPiA+PiA+Pg0KPiA+PiA+Pj4gTWlyamENCj4gPj4gPj4+ DQo+ID4+ID4+IEdvcnJ5DQo+ID4+ID4+DQo+ID4+ID4+Pj4gQW0gMTcuMDYuMjAxNiB1bSAxNjow MyBzY2hyaWViIEJsYWNrLCBEYXZpZA0KPiA8ZGF2aWQuYmxhY2tAZW1jLmNvbT46DQo+ID4+ID4+ Pj4NCj4gPj4gPj4+PiBDb2xpbiwNCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+Pj4+IC4uLiAgSSB2aWV3 IHRoZSBjdXJyZW50IHRleHQgYXMgcHJvdmlkaW5nIGltcGxlbWVudGVycyB3aXRoDQo+IHRvbw0K PiA+PiBtdWNoDQo+ID4+ID4+Pj4+Pj4gbGF0aXR1ZGUgdG8gaWdub3JlIEVDTi1DRSBtYXJrcyAo ZS5nLiwgYmVjYXVzZSBhbiBpbXBsZW1lbnRlcg0KPiA+PiBkb2Vzbid0DQo+ID4+ID4+Pj4+Pj4g d2FudCB0byB0aGluayBhYm91dCB0aGlzIHByb2JsZW0gc3BhY2UgaW4gdGhlIGZpcnN0IHBsYWNl KS4NCj4gPj4gPj4+Pj4NCj4gPj4gPj4+Pj4gSSBhZ3JlZSwgYnV0IHRoZSBhcmd1bWVudCBpcyB0 aGF0IGRvaW5nIHNvIGlzIGxlc3MgaGFybWZ1bCB0aGFuDQo+ID4+IGRlcGxveWluZyBhDQo+ID4+ ID4+IGNpcmN1aXQNCj4gPj4gPj4+Pj4gYnJlYWtlciB0aGF0IHRyaWdnZXJzIHRvbyBvZnRlbiB3 aGVuIEVDTiBpcyB1c2VkLg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+PiBJw6LigqzihKJtIG5vdCBz dXJlIEkgYmVsaWV2ZSB0aGlzIGFyZ3VtZW50LCB0aG91Z2gsIHNpbmNlIGl0IHNlZW1zDQo+ID4+ IHRoYXQNCj4gPj4gYW55IG5ldw0KPiA+PiA+PiBBUU0NCj4gPj4gPj4+Pj4gdGhhdCBhcHBsaWVz IEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhhbiBhdCBwcmVzZW50IHdpbGwNCj4gaGF2ZQ0K PiA+PiB0bw0KPiA+PiA+PiBjb25zaWRlcg0KPiA+PiA+Pj4+PiBiYWNrd2FyZHMgY29tcGF0aWJp bGl0eSwgdG8gd29yayB3aXRoIGRlcGxveWVkIFRDUCAoZS5nLiwNCj4gZHJhZnQtDQo+ID4+IGJy aXNjb2UtDQo+ID4+ID4+IHRzdndnLQ0KPiA+PiA+Pj4+PiBhcW0tdGNwbS1ybWNhdC1sNHMtcHJv YmxlbSB1c2VzIEVDVCgxKSBhcyBhIHNpZ25hbCB0byB1c2UgdGhlDQo+IG5ldw0KPiA+PiBtYXJr aW5nLA0KPiA+PiA+Pj4+PiB3aGlsZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgc2V0IEVDVCgw KSkuIFRoZXNlIGNvbXBhdGliaWxpdHkNCj4gPj4gbWVjaGFuaXNtcw0KPiA+PiA+Pj4+PiB3b3Vs ZCBzZWVtIHRvIHByZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJjdWl0IGJyZWFrZXIgdG9v Lg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gVGhhdCByb3VnaGx5IG1hdGNoZXMgbXkgbGluZSBvZiB0 aGlua2luZywgYW5kIEknbGwgb2JzZXJ2ZSB0aGF0DQo+ID4+IHRoZQ0KPiA+PiBvcmlnaW5hbA0K PiA+PiA+PiBEQ1RDUA0KPiA+PiA+Pj4+IHByb3RvY29sIGRlc2lnbiB0aGF0IHVzZWQgbW9yZSBh Z2dyZXNzaXZlIEVDTi1DRSBtYXJraW5nIHdhcw0KPiBvbmx5DQo+ID4+IHNhZmUgZm9yDQo+ID4+ ID4+Pj4gQ29udHJvbGxlZCBFbnZpcm9ubWVudCBkZXBsb3ltZW50cy4gICBTZWUgdGhlIFRTVldH IHJmYzU0MDViaXMNCj4gPj4gZHJhZnQgZm9yDQo+ID4+ID4+IHRoZQ0KPiA+PiA+Pj4+IGRlZmlu aXRpb24gb2YgQ29udHJvbGxlZCBFbnZpcm9ubWVudCwgYW5kIGlnbm9yZSB0aGUgZmFjdCB0aGF0 DQo+IHRoZQ0KPiA+PiByZmM1NDA1YmlzDQo+ID4+ID4+Pj4gZHJhZnQgaXMgYSBVRFAgZHJhZnQg LSB0aGlzIGRlZmluaXRpb24gaXMgbW9yZSBicm9hZGx5DQo+IGFwcGxpY2FibGUuDQo+ID4+ID4+ Pj4NCj4gPj4gPj4+PiBHb2luZyBiYWNrIG92ZXIgU2VjdGlvbiA3IGluIHRoaXMgYXZ0Y29yZSBk cmFmdCwgbXkgdmlld3MgYXJlOg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gW0FdIE5vbmUgb2YgdGhl c2UgZHJhZnRzIGp1c3RpZnkgYSAiTUFZIGlnbm9yZSIgcmVzcG9uc2UgdG8gRUNOLQ0KPiBDRQ0K PiA+PiBtYXJrczoNCj4gPj4gPj4+PiAgIC0gZHJhZnQta2hhZGVtaS10Y3BtLWFsdGVybmF0aXZl YmFja29mZi1lY24NCj4gPj4gPj4+PiAgIC0gZHJhZnQtaWV0Zi1ybWNhdC1uYWRhDQo+ID4+ID4+ Pj4gICAtIGRyYWZ0LWlldGYtcm1jYXQtc2NyZWFtLWNjDQo+ID4+ID4+Pj4NCj4gPj4gPj4+PiBb Ql0gSW4gbGluZSB3aXRoIENvbGluJ3MgY29tbWVudCBvbiB0aGUgTDRTIGRyYWZ0LCBJIHRoaW5r IGl0J3MNCj4gPj4gaW5jdW1iZW50IG9uDQo+ID4+ID4+Pj4gdGhlIGF1dGhvcnMgb2YgZHJhZnQt YnJpc2NvZS1hcW0tZHVhbHEtY291cGxlZCB0byBmaWd1cmUgb3V0IGhvdw0KPiA+PiB0aGF0IHdp bGwNCj4gPj4gPj4+PiBjb2V4aXN0IChvciBhdm9pZCkgZGVwbG95ZWQgVENQLCBhbmQgdGhpcyBh dnRjb3JlIGRyYWZ0IG91Z2h0DQo+IG5vdA0KPiA+PiB0byBiZQ0KPiA+PiA+Pj4+IHRyeWluZyB0 byBwcmVqdWRnZSB3aGF0IHdpbGwgYmUgZG9uZSB0aGVyZS4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+ IFNvLCBJIGRvbid0IHRoaW5rIHRoZSBjdXJyZW50IHRleHQgaW4gU2VjdGlvbiA3IGhhcyBqdXN0 aWZpZWQNCj4gdGhlDQo+ID4+IHVuZmV0dGVyZWQNCj4gPj4gPj4+PiAiaW1wbGVtZW50YXRpb25z IE1BWSBpZ25vcmUgRUNOLUNFIG1hcmtzIiB0ZXh0LCBhcyBpZ25vcmluZw0KPiB0aG9zZQ0KPiA+ PiBtYXJrcw0KPiA+PiA+Pj4+IGlzIG5vdCBjb25zaXN0ZW50IHdpdGggYW55IG9mIHRoZSBmb3Vy IGNpdGVkIGRyYWZ0cy4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+IEluIG1vcmUgZGV0YWlsLCBJIHRo aW5rIG1ha2luZyBjaGFuZ2VzIHRvIG5vcm1hdGl2ZSByZXF1aXJlbWVudHMNCj4gPj4gaGVyZSBi YXNlZA0KPiA+PiA+Pj4+IG9uIFtCXSBpcyBwcmVtYXR1cmUsIGFuZCBJIHdvdWxkIGhvcGUgdGhh dCB0aGUgcm1jYXQgV0cgY291bGQgYmUNCj4gPj4gPj4gZW5jb3VyYWdlZA0KPiA+PiA+Pj4+IHRv IGNvbnNpZGVyIHRoZSBSVFAgY2lyY3VpdCBicmVha2VyIGluIGl0cyBjb25nZXN0aW9uIGNvbnRy b2wNCj4gPj4gZHJhZnRzLCBhcyB0aG9zZSBDQw0KPiA+PiA+Pj4+IG1lY2hhbmlzbXMgYXJlIHJl bGF0ZWQgdG8gdGhlIGNpcmN1aXQgYnJlYWtlciBtZWNoYW5pc20sIGhlbmNlDQo+ID4+IGxpa2Vs eQ0KPiA+PiA+Pj4+IHRvIGJlIGluIHJlbGF0ZWQgYXJlYXMgb2YgYW4gUlRQIGltcGxlbWVudGF0 aW9uLg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gVGhhdCBsZWF2ZXMgZHJhZnQta2hhZGVtaS10Y3Bt LWFsdGVybmF0aXZlYmFja29mZi1lY24sIHdoaWNoDQo+IFRTVldHDQo+ID4+ID4+Pj4gd2lsbCBi ZSBsb29raW5nIGF0IGluIEJlcmxpbi4gIElmIGEgbm9ybWF0aXZlIHN0YXRlbWVudCBhYm91dA0K PiBFQ04tDQo+ID4+IENFIHJlYWN0aW9uDQo+ID4+ID4+Pj4gaXMgZ29pbmcgdG8gcmVzdCBvbiB0 aGF0IGRyYWZ0LCB0aGVuIHRoZSByZWZlcmVuY2UgdG8gdGhhdCBkcmFmdA0KPiA+PiBzaG91bGQg YmUNCj4gPj4gPj4+PiBub3JtYXRpdmUuICBTb21ldGhpbmcgYWJvdXQgZG9pbmcgdGhhdCBzdHJp a2VzIG1lIGFzIHByZW1hdHVyZQ0KPiAuLi4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+IEkgcmVhbGl6 ZSB0aGF0IHdlJ3JlIHRyeWluZyB0byBwcmVkaWN0IGFuZCBhY2NvbW1vZGF0ZSB0aGUNCj4gZnV0 dXJlLA0KPiA+PiB3aGljaA0KPiA+PiA+Pj4+IGlzIGFuIGltcHJlY2lzZSB1bmRlcnRha2luZyBh dCBiZXN0LiAgIEFzIGFuIGFsdGVybmF0aXZlIHRvIHRoZQ0KPiA+PiBjdXJyZW50IHRleHQsDQo+ ID4+ID4+Pj4gd291bGQgaXQgYmUgcmVhc29uYWJsZSB0byBzYXkgKHdpdGhvdXQgYW55IFJGQyAy MTE5IGtleXdvcmRzKQ0KPiB0aGF0DQo+ID4+IHRoZQ0KPiA+PiA+Pj4+IGJlc3QgY3VycmVudCBn dWlkYW5jZSBpcyBzdGlsbCB0byB0cmVhdCBFQ04tQ0UgbWFya3MgYXMNCj4gaW5kaWNhdGluZw0K PiA+PiBkcm9wcywNCj4gPj4gPj4+PiB3aXRoIGEgd2FybmluZyB0aGF0IHRoZXJlIGlzIGEgZ29v ZCBwb3NzaWJpbGl0eSBvZiB0aGlzIGNoYW5naW5nDQo+ID4+IGluDQo+ID4+IHRoZQ0KPiA+PiA+ Pj4+IG5lYXIgZnV0dXJlIGR1ZSB0byBhbGwgb2YgdGhlIHdvcmsgaW4gcHJvZ3Jlc3MgY2l0ZWQg aW4gU2VjdGlvbg0KPiA3Pw0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gVGhhbmtzLCAtLURhdmlkDQo+ ID4+ID4+Pj4NCj4gPj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4+ Pj4gRnJvbTogQ29saW4gUGVya2lucyBbbWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnXQ0KPiA+PiA+ Pj4+PiBTZW50OiBGcmlkYXksIEp1bmUgMTcsIDIwMTYgNjoxNCBBTQ0KPiA+PiA+Pj4+PiBUbzog Sm9obiBMZXNsaWU7IEJsYWNrLCBEYXZpZA0KPiA+PiA+Pj4+PiBDYzogcnRjd2ViQGlldGYub3Jn OyBJRVRGIEFWVENvcmUgV0c7IHRzdndnDQo+ID4+ID4+Pj4+IFN1YmplY3Q6IFJlOiBbcnRjd2Vi XSBbQVZUQ09SRV0gW3RzdndnXSBXRyBMYXN0IENhbGwgb24NCj4gY2hhbmdlczoNCj4gPj4gZHJh ZnQtaWV0Zi0NCj4gPj4gPj4+Pj4gYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiA+ PiA+Pj4+Pg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+Pj4gT24gMTYgSnVuIDIwMTYsIGF0IDIzOjI1 LCBKb2huIExlc2xpZSA8am9obkBqbGMubmV0PiB3cm90ZToNCj4gPj4gPj4+Pj4+DQo+ID4+ID4+ Pj4+PiBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb20+IHdyb3RlOg0KPiA+PiA+Pj4+ Pj4+DQo+ID4+ID4+Pj4+Pj4gLi4uICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBwcm92aWRp bmcgaW1wbGVtZW50ZXJzIHdpdGgNCj4gdG9vDQo+ID4+IG11Y2gNCj4gPj4gPj4+Pj4+PiBsYXRp dHVkZSB0byBpZ25vcmUgRUNOLUNFIG1hcmtzIChlLmcuLCBiZWNhdXNlIGFuIGltcGxlbWVudGVy DQo+ID4+IGRvZXNuJ3QNCj4gPj4gPj4+Pj4+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJv YmxlbSBzcGFjZSBpbiB0aGUgZmlyc3QgcGxhY2UpLg0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+PiBJ IGFncmVlLCBidXQgdGhlIGFyZ3VtZW50IGlzIHRoYXQgZG9pbmcgc28gaXMgbGVzcyBoYXJtZnVs IHRoYW4NCj4gPj4gZGVwbG95aW5nIGENCj4gPj4gPj4gY2lyY3VpdA0KPiA+PiA+Pj4+PiBicmVh a2VyIHRoYXQgdHJpZ2dlcnMgdG9vIG9mdGVuIHdoZW4gRUNOIGlzIHVzZWQuDQo+ID4+ID4+Pj4+ DQo+ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMgYXJndW1lbnQs IHRob3VnaCwgc2luY2UgaXQgc2VlbXMNCj4gPj4gdGhhdA0KPiA+PiBhbnkgbmV3DQo+ID4+ID4+ IEFRTQ0KPiA+PiA+Pj4+PiB0aGF0IGFwcGxpZXMgRUNOIG1hcmtzIG11Y2ggbW9yZSBvZnRlbiB0 aGFuIGF0IHByZXNlbnQgd2lsbA0KPiBoYXZlDQo+ID4+IHRvDQo+ID4+ID4+IGNvbnNpZGVyDQo+ ID4+ID4+Pj4+IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCB0byB3b3JrIHdpdGggZGVwbG95ZWQg VENQIChlLmcuLA0KPiBkcmFmdC0NCj4gPj4gYnJpc2NvZS0NCj4gPj4gPj4gdHN2d2ctDQo+ID4+ ID4+Pj4+IGFxbS10Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVzZXMgRUNUKDEpIGFzIGEgc2lnbmFs IHRvIHVzZSB0aGUNCj4gbmV3DQo+ID4+IG1hcmtpbmcsDQo+ID4+ID4+Pj4+IHdoaWxlIGV4aXN0 aW5nIGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDApKS4gVGhlc2UgY29tcGF0aWJpbGl0eQ0KPiA+ PiBtZWNoYW5pc21zDQo+ID4+ID4+Pj4+IHdvdWxkIHNlZW0gdG8gcHJldmVudCB0aGUgaXNzdWVz IHdpdGggdGhlIGNpcmN1aXQgYnJlYWtlciB0b28uDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+PiBV bmRlcnN0YW5kLCB3ZSBoYXZlIGF0IGxlYXN0IHR3byBwcm9wb3NhbHMgdG8gbWFrZSBFQ04tQ0Ug bW9yZQ0KPiA+PiA+PiBmcmVxdWVudA0KPiA+PiA+Pj4+Pj4gdGhhbiBwYWNrZXQgZHJvcCB3b3Vs ZCBiZSBmb3Igbm9uLUVDTiBwYWNrZXRzOiBwb3NzaWJseQ0KPiA+PiBzdWJzdGFudGlhbGx5DQo+ ID4+ID4+Pj4+PiBtb3JlIGZyZXF1ZW50LiBVbmxlc3MgYm90aCBhcmUga2lsbGVkIG9mZiwgRUNO LUNFIHdpbGwgc2hvdyB1cA0KPiA+PiBmcmVxdWVudGx5DQo+ID4+ID4+Pj4+PiBlbm91Z2ggdGhh dCBjbG9zaW5nIHRoZSBmbG93IG9uIEVDTi1DRSB3b3VsZCBraWxsIHRvbyBtYW55DQo+ID4+IGNv bm5lY3Rpb25zLg0KPiA+PiA+Pj4+Pj4NCj4gPj4gPj4+Pj4+IElmIHlvdSB3YW50IGNpcmN1aXQt YnJlYWtpbmcgb24gc3VjaCBjb25uZWN0aW9ucywgdGhlcmUgYXJlDQo+IHR3bw0KPiA+PiB3YXlz Og0KPiA+PiA+Pj4+Pj4gMS4gY29udmluY2UgdGhlIGZvcndhcmRpbmcgbm9kZXMgdG8gZHJvcCBw YWNrZXRzIGlmIHRoZWlyDQo+IHF1ZXVlDQo+ID4+IGV4Y2VlZHMNCj4gPj4gPj4+Pj4+IGRlc2ln biBjYXBhY2l0eTsgb3INCj4gPj4gPj4+Pj4+IDIuIHJlcXVpcmUgdGhlIHNlbmRlciB0byBzZW5k IGVub3VnaCBub3QtRUNOLWNhcGFibGUgcGFja2V0cw0KPiBzbw0KPiA+PiB0aGF0IG91cg0KPiA+ PiA+Pj4+Pj4gcmVjZWl2ZXIgd2lsbCBzZWUgZW5vdWdoIHBhY2tldC1kcm9wcyB3aGVuIGEgY2ly Y3VpdC1icmVha2VyDQo+ID4+IHNob3VsZA0KPiA+PiA+Pj4+Pj4gYWN0aXZhdGUuDQo+ID4+ID4+ Pj4+Pg0KPiA+PiA+Pj4+Pj4gKEkgcHJlZmVyIHRoZSBmaXJzdCBvcHRpb247IGJ1dCBJIHdvdWxk bid0IG9iamVjdCB0byB0aGUNCj4gPj4gc2Vjb25kLikNCj4gPj4gPj4+Pj4+DQo+ID4+ID4+Pj4+ PiBUaGVyZSByZWFsbHkgaXNuJ3QgYW55IHdheSBmb3Igb3VyIGNpcmN1aXQtYnJlYWtlciB0byBr bm93DQo+ID4+IF9ob3dfbXVjaF8NCj4gPj4gPj4+Pj4+IG1vcmUgZnJlcXVlbnQgdGhlIEVDTi1D RSBtYXJrcyBtYXkgYmUuIDpeKA0KPiA+PiA+Pj4+Pg0KPiA+PiA+Pj4+PiBUaGlzIGlzIGEgcHJv YmxlbSwgYm90aCBmb3IgdGhlIGNpcmN1aXQgYnJlYWtlciwgYW5kIGZvciB0aGUNCj4gPj4gYWxn b3JpdGhtcyBiZWluZw0KPiA+PiA+Pj4+PiBkZWZpbmVkIGluIFJNQ0FULiBXZSBkbyBuZWVkIHNv bWUgdW5kZXJzdGFuZGluZyB3aGF0IHRoZQ0KPiBleHBlY3RlZA0KPiA+PiA+PiBtYXJraW5nDQo+ ID4+ID4+Pj4+IHJhdGVzIGFyZSBsaWtlbHkgdG8gYmUsIHNvIGNvbmdlc3Rpb24gY29udHJvbCBh bmQgY2lyY3VpdA0KPiA+PiBicmVha2Vycw0KPiA+PiBjYW4gYmUNCj4gPj4gPj4gZGVmaW5lZC4N Cj4gPj4gPj4+Pj4NCj4gPj4gPj4+Pj4+IFdlIF93aWxsXyBiZSBzb3JyeSBpZiB3ZQ0KPiA+PiA+ Pj4+Pj4gYWxsb3QgdGhlIHNhbWUgZnJlcXVlbmN5IG9mIENFIHBhY2tldHMgYXMgcGFja2V0LWRy b3BzIHRvDQo+ID4+IHRyaWdnZXINCj4gPj4gdGhlDQo+ID4+ID4+Pj4+PiBjaXJjdWl0LWJyZWFr ZXIuDQo+ID4+ID4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+IENvdWxkIHNvbWVvbmUgcHJvcG9zZSBpbml0 aWFsIHRleHQgdG8gcXVhbGlmaWVzIHRoZSBjdXJyZW50DQo+ID4+ICJNQVkNCj4gPj4gaWdub3Jl Ig0KPiA+PiA+Pj4+Pj4+IHN0YXRlbWVudD8NCj4gPj4gPj4+Pj4+DQo+ID4+ID4+Pj4+PiBFc3Nl bnRpYWxseSwgZm9yIHRoZSBzZWNvbmQgb3B0aW9uLCB5b3UgbWlnaHQgcHJvcG9zZSB0ZXh0IHRv DQo+ID4+IHRoZQ0KPiA+PiA+Pj4+Pj4gZWZmZWN0IG9mOg0KPiA+PiA+Pj4+Pj4gXQ0KPiA+PiA+ Pj4+Pj4gXSBJZiB0b28gbWFueSBFQ04tQ0UgcGFja2V0cyBhcmUgcmVjZWl2ZWQsIHRoZSBzZW5k ZXIgU0hPVUxEDQo+ID4+IHNlbmQNCj4gPj4gc29tZQ0KPiA+PiA+Pj4+Pj4gXSBub3QtRUNOLWNh cGFibGUgcGFja2V0cyB0byBkZXRlcm1pbmUgd2hldGhlciBlbm91Z2ggcGFja2V0cw0KPiA+PiBh bG9uZyB0aGUNCj4gPj4gPj4+Pj4+IF0gcGF0aCBhcmUgYmVpbmcgZHJvcHBlZCB0byBqdXN0aWZ5 IGFjdGl2YXRpbmcgb3VyIGNpcmN1aXQtDQo+ID4+IGJyZWFrZXIuDQo+ID4+ID4+Pj4+Pg0KPiA+ PiA+Pj4+Pj4gScOi4oKs4oSibSBub3QgZW50aHVzaWFzdGljIGFib3V0IGFkZGluZyB0aGF0OyBi dXQgaXQgd291bGQgcmVzb2x2ZQ0KPiA+PiB0aGUNCj4gPj4gaXNzdWUuDQo+ID4+ID4+Pj4+DQo+ ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IGNvbnZpbmNlZCB0aGlzIHdvdWxkIHdvcmsuIFRoZSBj aXJjdWl0IGJyZWFrZXIgaXMNCj4gPj4gbG9va2luZw0KPiA+PiBhdCBsb25nIHRlcm0NCj4gPj4g Pj4+Pj4gdHJlbmRzLCBhbmQgaW4gb3JkZXIgdG8gaGF2ZSBlbm91Z2ggbm90LUVDVCBwYWNrZXRz IHRvDQo+IGRldGVybWluZQ0KPiA+PiBpZiBpdA0KPiA+PiA+PiBzaG91bGQNCj4gPj4gPj4+Pj4g dHJpZ2dlciwgeW91w6LigqzihKJkIGVzc2VudGlhbGx5IGhhdmUgdG8gcnVuIHdpdGhvdXQgRUNO IGZvciBzb21lDQo+ID4+IHNlY29uZHMuDQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+IC0tDQo+ID4+ ID4+Pj4+IENvbGluIFBlcmtpbnMNCj4gPj4gPj4+Pj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0K PiA+PiA+Pj4+DQo+ID4+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4gPj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4+ID4+Pj4gcnRj d2ViQGlldGYub3JnDQo+ID4+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWINCj4gPj4gPg0KPiA+DQo+ID4NCg0K From nobody Mon Jun 27 13:09:54 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B1D12D898; Mon, 27 Jun 2016 13:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIQIC4cdKtfO; Mon, 27 Jun 2016 13:09:50 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E5112D899; Mon, 27 Jun 2016 13:09:50 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5RK9lA0009014 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Jun 2016 16:09:49 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5RK9lA0009014 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1467058189; bh=jCK9zCl9eu7o7TEn25IU/lxbdj4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=AA8RMNSr2VaqutfzEGOLZnvIrAoRH4x6xM6gkG31azEwcc22cClAss1+9EvgBexFG 8Gbsa7CgnhIqH/0MetTBcAWPA9CPHemm/hwODMo2wrK5c824u7UX+0FVuh63LT5viu gpLJj8vL77RFtZmsTHz8LeiGcc9muu6e9s8a6tWc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5RK9lA0009014 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd51.lss.emc.com (RSA Interceptor); Mon, 27 Jun 2016 16:08:42 -0400 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5RK9WuX013689 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 27 Jun 2016 16:09:32 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0266.001; Mon, 27 Jun 2016 16:09:31 -0400 From: "Black, David" To: "De Schepper, Koen (Nokia - BE)" Thread-Topic: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRySnSO2oWwmhohkOlLHzEpySa4p/yV2bAgAB84gCACuOzAIAADJcAgAA78wD//8FkgA== Date: Mon, 27 Jun 2016 20:09:30 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 20:09:53 -0000 PiBBcyBsb25nIGFzIGFuIEFRTSBpcyBtYXJraW5nIGF0IHRoZSBzYW1lIHJhdGUgYXMgZHJvcHBp bmcNCg0KVGhhdCdzIGFuIGludGVyZXN0aW5nIGFzc3VtcHRpb24gLSBpdCBzaG91bGQgYmUgdHJ1 ZSBmb3IgQVFNcyB2ZXR0ZWQNCmhlcmUgaW4gdGhlIHBhc3QsIGJ1dCB0aGVyZSBhcmUgZWFzeSB3 YXlzIGZvciBpdCBub3QgdG8gaG9sZCAoZS5nLiwgaWYgZHJvcHBpbmcNCm9yIG1hcmtpbmcgaXMg YmFzZWQgb24gcXVldWUgb2NjdXBhbmN5LCBpdCBpcyBwb3NzaWJsZSB0aGF0IGRyb3BwaW5nDQpy ZWR1Y2VzIHF1ZXVlIG9jY3VwYW5jeSBpbiBhIGZhc2hpb24gdGhhdCBtYXJraW5nIGRvZXMgbm90 KS4NCg0KRm9yIEVDTiAiY2xhc3NpYyIgKGkuZS4sIHNlZSBSRkMgMzE2OCkgd2hlcmUgRUNOLUNF IG1hcmtpbmdzIGFyZSB0cmVhdGVkDQphcyBkcm9wLWVxdWl2YWxlbnQsIHRoYXQgaXMgZm9yIGNv bmdlc3Rpb24gY29udHJvbCBwdXJwb3Nlcywgd2hpY2ggaXMgc2ltaWxhcg0KdG8sIChidXQgbm90 IHRoZSBzYW1lIGFzKSB0aGUgdGhyb3VnaHB1dCBlc3RpbWF0aW9uIHVzYWdlIGZvciB0aGUgUlRQ IGNpcmN1aXQNCmJyZWFrZXIuICAgIEknbGwgbm90ZSB0aGF0IEVDTiAiY2xhc3NpYyIgd2FzIGRl c2lnbmVkIGNvbmdlc3Rpb24gY29udHJvbA0KYWxnb3JpdGhtcyBmb3IgcmVhY3QgdG8gRUNOLUNF IG1hcmtzIG9uY2UgcGVyIFJUVCwgaW5kZXBlbmRlbnQgb2YgaG93DQptYW55IEVDTi1DRSBtYXJr cyBhcmUgb2JzZXJ2ZWQgaW4gYW4gUlRULg0KDQpHb3JyeSB3cm90ZToNCg0KPiA+IGluIHRoaXMg Y29udGV4dCB3ZSBzaG91bGQgdXNlIEVDTiB0byBkcml2ZSBhIENDIGFsZ29yaXRobSBhbmQgd2Ug c2hvdWxkIGJlDQo+ID4gY2F1dGlvdXMgdG8gYXZvaWQgcmVxdWlyaW5nIGl0cyB1c2Ugd2l0aGlu IGEgQ2lyY3VpdCBCcmVha2VyIC0gb3B0aW9uYWwNCj4gPiB1c2UsIGlmIHlvdSB1bmRlcnN0YW5k IGhvdyB0byBpbnRlcnByZXQgYSByZWFjdGlvbiB0byBtYW55IENFLW1hcmtzIGFzDQo+ID4gZXhj ZXNzaXZlIGNvbmdlc3Rpb24sIGFyZSBwZXJtaXR0ZWQuDQoNClNvbWV0aGluZyBsaWtlIHRoYXQg bWF5IGJlIHdvcmthYmxlLCBzdGFydGluZyB3aXRoIGEgY2xlYXIgZGlzdGluY3Rpb24gYmV0d2Vl bg0KdGhlIHVzZSBvZiBFQ04gYnkgQ0MgKHJvdXRpbmUsIGFjdGl2ZSBhdCBhbGwgdGltZXMpIGFu ZCBFQ04gYnkgYSBjaXJjdWl0DQpicmVha2VyIChtb25pdG9ycyBmb3IgZXZpZGVuY2UgdGhhdCB0 aGluZ3MgaGF2ZSBnb3R0ZW4gYmFkLCBvbmx5IGFjdGl2YXRlZA0Kd2hlbiB0aGluZ3MgZ2V0IGJh ZCkuICAgVGhpcyB3b3VsZCBiYXNlbGluZSB0aGUgUlRQIGNpcmN1aXQgYnJlYWtlciBvbiBkcm9w cw0KYW5kIGFsbG93IHVzZSBvZiBFQ04gYXMgYWRkaXRpb25hbCBldmlkZW5jZSBvZiBwcm9ibGVt cywgaW4gY29udHJhc3QgdG8NCmNvbmdlc3Rpb24gY29udHJvbCB3aGVyZSBFQ04tQ0UgaXMgZWZm ZWN0aXZlbHkgdHJlYXRlZCBhcyBkcm9wLWVxdWl2YWxlbnQuDQoNCkknbSBub3QgcXVpdGUgc3Vy ZSBob3cgdG8gc3BlY2lmeSAidXNlIG9mIEVDTiBhcyBhZGRpdGlvbmFsIGV2aWRlbmNlIiBvZg0K ImV4Y2Vzc2l2ZSBjb25nZXN0aW9uIiBhcyBkcm9wLWVxdWl2YWxlbmNlIGlzIGFib3V0IHRoZSBi ZXN0IHdlIGhhdmUNCmZvciBjdXJyZW50IGd1aWRhbmNlLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEZSBTY2hlcHBlciwgS29lbiAo Tm9raWEgLSBCRSkgW21haWx0bzprb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtDQo+IGxhYnMu Y29tXQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMjcsIDIwMTYgMzoxMyBQTQ0KPiBUbzogZ29ycnlA ZXJnLmFiZG4uYWMudWsNCj4gQ2M6IE1pY2hhZWwgV2Vsemw7IEJsYWNrLCBEYXZpZDsgTWFnbnVz IFdlc3Rlcmx1bmQ7IHRzdndnOyBJRVRGIEFWVENvcmUgV0c7DQo+IHJ0Y3dlYkBpZXRmLm9yZzsg Q29saW4gUGVya2lucw0KPiBTdWJqZWN0OiBSRTogW3RzdndnXSBbcnRjd2ViXSBbQVZUQ09SRV0g V0cgTGFzdCBDYWxsIG9uIGNoYW5nZXM6IGRyYWZ0LWlldGYtDQo+IGF2dGNvcmUtcnRwLWNpcmN1 aXQtYnJlYWtlcnMtMTYNCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gRnJvbTogZ29ycnlAZXJnLmFiZG4uYWMudWsgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51 a10NCj4gPiBTZW50OiBtYWFuZGFnIDI3IGp1bmkgMjAxNiAxNzozOA0KPiA+IFRvOiBEZSBTY2hl cHBlciwgS29lbiAoTm9raWEgLSBCRSkNCj4gPiBDYzogTWljaGFlbCBXZWx6bDsgQmxhY2ssIERh dmlkOyBnb3JyeUBlcmcuYWJkbi5hYy51azsgTWFnbnVzDQo+ID4gV2VzdGVybHVuZDsgdHN2d2c7 IElFVEYgQVZUQ29yZSBXRzsgcnRjd2ViQGlldGYub3JnOyBDb2xpbiBQZXJraW5zDQo+ID4gU3Vi amVjdDogUmU6IFt0c3Z3Z10gW3J0Y3dlYl0gW0FWVENPUkVdIFdHIExhc3QgQ2FsbCBvbiBjaGFu Z2VzOiBkcmFmdC0NCj4gPiBpZXRmLWF2dGNvcmUtcnRwLWNpcmN1aXQtYnJlYWtlcnMtMTYNCj4g Pg0KPiA+IEkgdGhpbmsgdGhpbmtpbmcgb2YgTDRTIGlzIG1heWJlIG9mZiBhdCBhIHRhbmdlbnQu IFRoZSBxdWVzdGlvbiByZWFsbHkNCj4gPiBpcw0KPiA+IGFib3V0IHRoZSBpbnRlcnByZXRhdGlv biBvZiBsb3NzIGFuZCBDRS1tYXJrIGFzIGVxdWl2YWxlbnQuIEkgYXJndWVkDQo+ID4gdGhhdA0K PiA+IGVhY2ggRUNOLUNFIG1hcmsgc2hvdWxkIG5vdCBiZSBjb3VudGVkIGFzIGVxdWl2YWxlbnQg dG8gYSBsb3N0IHNlZ21lbnQgLQ0KPiANCj4gV2h5IG5vdD8gQXMgbG9uZyBhcyBhbiBBUU0gaXMg bWFya2luZyBhdCB0aGUgc2FtZSByYXRlIGFzIGRyb3BwaW5nLCBhDQo+IDEwMCUgbWFya2luZyBt ZWFucyB0aGF0IG5vbi1lY24gZmxvd3MgYXJlIGJlaW5nIGRyb3BwZWQgYXQgYSAxMDAlLCBub3Q/ DQo+IA0KPiBLb2VuLg0KPiANCj4gDQo+ID4gaW4gdGhpcyBjb250ZXh0IHdlIHNob3VsZCB1c2Ug RUNOIHRvIGRyaXZlIGEgQ0MgYWxnb3JpdGhtIGFuZCB3ZSBzaG91bGQNCj4gPiBiZQ0KPiA+IGNh dXRpb3VzIHRvIGF2b2lkIHJlcXVpcmluZyBpdHMgdXNlIHdpdGhpbiBhIENpcmN1aXQgQnJlYWtl ciAtIG9wdGlvbmFsDQo+ID4gdXNlLCBpZiB5b3UgdW5kZXJzdGFuZCBob3cgdG8gaW50ZXJwcmV0 IGEgcmVhY3Rpb24gdG8gbWFueSBDRS1tYXJrcyBhcw0KPiA+IGV4Y2Vzc2l2ZSBjb25nZXN0aW9u LCBhcmUgcGVybWl0dGVkLg0KPiA+DQo+ID4gR29ycnkNCj4gPg0KPiA+ID4gQXMgZmFyIGFzIEkg dW5kZXJzdGFuZCwgdGhpcyBkcmFmdCBpcyByZWxhdGVkIHRvIGNpcmN1aXQgYnJlYWtlcnMgaW4N Cj4gPiA+IGVuZC1zeXN0ZW1zLCByaWdodD8NCj4gPiA+DQo+ID4gPiBJdCBpcyB0aGUgZW5kIHN5 c3RlbSB0aGF0IGRldGVybWluZXMgdGhlIHVzZSBvZiBFQ04gKGN1cnJlbnRseSBtYXJraW5nDQo+ ID4gPiBub24tZWN0IGZvciBkcm9wIGFuZCBlY3QoMCkgZm9yIENsYXNzaWMgRUNOKS4NCj4gPiA+ DQo+ID4gPiBJbiBMNFMgd2UgZG9uJ3QgcGxhbiB0byBjaGFuZ2UgdGhlIGJlaGF2aW9yIG9mIENs YXNzaWMgRUNOLCBhbmQgQUJFJ3MNCj4gPiA+IGJlaGF2aW9yIHNob3VsZCBiZSBjbG9zZSB0byBu b24tQUJFIEVDTi4gU28gSSBndWVzcyB0aGVyZSBpcyBubw0KPiA+IHByb2JsZW0gb2YNCj4gPiA+ IGRlc2NyaWJpbmcgdGhlIGJlaGF2aW9yIG9mIGhvdyBhIENsYXNzaWMgRUNOIGJhc2VkIHNlbmRl ciB3b3VsZA0KPiA+IHJlc3BvbmQNCj4gPiA+IHRvZGF5Lg0KPiA+ID4NCj4gPiA+IEFzIHdlIG9u bHkgd2FudCB0byBzaWduaWZpY2FudGx5IGNoYW5nZSB0aGUgbmV0d29yayBiZWhhdmlvciBvZiBl Y3QoMSkNCj4gPiA+IG1hcmtpbmcsIGNhbiB3ZSBzb2x2ZSB0aGlzIGlzc3VlIGJ5IHJlY29tbWVu ZGluZyAob3IgZXZlbiByZXF1aXJpbmcpDQo+ID4gPiBzZW5kZXJzIHRvIG1hcmsgb25seSBlY3Qo MCkgYW5kIGRlc2NyaWJpbmcgdGhlIGNsYXNzaWMgRUNOIGNpcmN1aXQNCj4gPiA+IGJyZWFrZXI/ IFdoZW4gTDRTIGdldHMgZGVmaW5lZCwgYWxzbyBhbiBMNFMgYmFzZWQgY2lyY3VpdCBicmVha2Vy DQo+ID4gPiBleHRlbnNpb24gY2FuIGJlIGRlZmluZWQgZm9yIHNlbmRlcnMgdGhhdCB3YW50IHRv IHVzZSB0aGUgTDRTIHNlcnZpY2UNCj4gPiA+ICh3aGVuIHNlbmRlcnMgc2VuZCBlY3QoMSkgcGFj a2V0cykuDQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IEtvZW4uDQo+ID4gPg0KPiA+ID4N Cj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IHRzdndnIFtt YWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4gPiBX ZWx6bA0KPiA+ID4+IFNlbnQ6IG1hYW5kYWcgMjAganVuaSAyMDE2IDE4OjM2DQo+ID4gPj4gVG86 IEJsYWNrLCBEYXZpZA0KPiA+ID4+IENjOiA8Z29ycnlAZXJnLmFiZG4uYWMudWs+IEZhaXJodXJz dDsgTWFnbnVzIFdlc3Rlcmx1bmQ7IHRzdndnOyBJRVRGDQo+ID4gPj4gQVZUQ29yZSBXRzsgcnRj d2ViQGlldGYub3JnOyBDb2xpbiBQZXJraW5zDQo+ID4gPj4gU3ViamVjdDogUmU6IFt0c3Z3Z10g W3J0Y3dlYl0gW0FWVENPUkVdIFdHIExhc3QgQ2FsbCBvbiBjaGFuZ2VzOg0KPiA+IGRyYWZ0LQ0K PiA+ID4+IGlldGYtYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiA+ID4+DQo+ID4g Pj4NCj4gPiA+PiA+IE9uIDIwLiBqdW4uIDIwMTYsIGF0IDE1LjE2LCBCbGFjaywgRGF2aWQgPGRh dmlkLmJsYWNrQGVtYy5jb20+DQo+ID4gd3JvdGU6DQo+ID4gPj4gPg0KPiA+ID4+ID4+PiBCdXQg ScOi4oKs4oSibSBsZXNzIGNvbmNlcm5lZCB0aGFuIERhdmlkIGFib3V0IGV2ZW50dWFsbHkgaWdu b3JpbmcgaXQNCj4gPiA+PiBmb3INCj4gPiA+PiBjaXJjdWl0DQo+ID4gPj4gPj4gYnJlYWtlci4N Cj4gPiA+PiA+Pj4NCj4gPiA+PiA+PiBBZ3JlZS4gTG9zcyBpcyB0aGUgbWVhc3VyZW1lbnQgdGhh dCBhIENCIE1VU1QgcmVzcG9uZCB0by4NCj4gPiA+PiA+DQo+ID4gPj4gPiBNdW1ibGUuICAgSSB3 b3VsZCBiZSBvayB3aXRoIGEgY2xlYXIgZGlzY291cmFnZW1lbnQgZm9yIHVzZSBvZiBFQ04tDQo+ ID4gQ0UNCj4gPiA+PiBtYXJrcywgYWNjb21wYW5pZWQgYnkgdGhlIHNvcnQgb2YgZGVzaWduIHJh dGlvbmFsZSBoZXJlLCBvciBldmVuDQo+ID4gPj4gYmV0dGVyLA0KPiA+ID4+IGEgY2xlYXIgc3Rh dGVtZW50IHRoYXQgbG9zdCBwYWNrZXRzIGZvciB0aGUgcHVycG9zZSBvZiB0aGUgUlRQDQo+ID4g Y2lyY3VpdA0KPiA+ID4+IGJyZWFrZXIgaGF2ZSB0byBiZSBhY3R1YWxseSBsb3N0IHdpdGhvdXQg Z2V0dGluZyBpbnRvIHdoZXRoZXIgb3Igbm90DQo+ID4gPj4gRUNOLUNFIG1hcmtzIGFyZSBpbnZv bHZlZCAtaS5lLiwgdGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIgaXMgc3BlY2lmaWVkDQo+ID4gPj4g YWdhaW5zdCBhY3R1YWwgZHJvcHMgYXMgYSBuZXR3b3JrIHByb3RlY3Rpb24gYmFja3N0b3AuDQo+ ID4gPj4gPg0KPiA+ID4+ID4gQSByZWxhdGVkIGNvbmNlcm4gaXMgdGhhdCBFQ04gbWFya3MgbWF5 IG92ZXJzdGF0ZSBlcXVpdmFsZW50IGxvc3MNCj4gPiA+PiBiZWhhdmlvciAtIGEgc2ltcGxpc3Rp YyBxdWV1ZSBtYW5hZ2VtZW50IGRpc2NpcGxpbmUgdGhhdCBtYXJrcyBldmVyeQ0KPiA+ID4+IHBh Y2tldCB3aGVuIHRoZSBxdWV1ZSBpcyBvdmVyIGEgdGhyZXNob2xkIChOQjogdGhpcyBjbGFzcyBv ZiBtYXJraW5nDQo+ID4gPj4gYmVoYXZpb3IgaXMgTk9UIFJFQ09NTUVOREVEIC0gYSByZWFsIEFR TSBTSE9VTEQgYmUgdXNlZCkgY291bGQgeWllbGQNCj4gPiBhDQo+ID4gPj4gcnVuIG9mIEVDTi1D RSBtYXJrcyB0aGF0IHdvdWxkIG5vdCBjYXVzZSBhIGNvcnJlc3BvbmRpbmcgd2l0aCBhIHJ1bg0K PiA+IG9mDQo+ID4gPj4gcGFja2V0IGRyb3BzLiAgIFRoaXMgaXMgYW1vbmcgdGhlIHJlYXNvbnMg dGhhdCBUQ1AgcmVhY3RzIHRvIEVDTi1DRQ0KPiA+ID4+IG1hcmtzIG9ubHkgb25jZSBwZXIgUlRU LCBhbmQgbWlnaHQgYmUgYSByZWFzb24gdG8gdHJlYXQgbXVsdGlwbGUgRUNOLQ0KPiA+IENFDQo+ ID4gPj4gbWFya3MgaW4gYW4gUlRUIGludGVydmFsIGFzIG5vdCByZXByZXNlbnRpbmcgZHJvcHMg b2YgYWxsIHBhY2tldHMgZm9yDQo+ID4gPj4gdGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIncyBUQ1At ZXF1aXZhbGVudCB0aHJvdWdocHV0IGNhbGN1bGF0aW9uLg0KPiA+ID4+DQo+ID4gPj4gScOi4oKs 4oSibSBub3Qgc3VyZSB3ZSBuZWVkIHN1Y2ggY29tcGxpY2F0ZWQgbG9naWMgdG8gZmluZCBhIGNh c2Ugd2hlcmUNCj4gPiBFQ04NCj4gPiA+PiBtYXJrcyBhcmUgZGlmZmVyZW50IGZyb20gcGFja2V0 IGRyb3BzOg0KPiA+ID4+DQo+ID4gPj4gQmFzaWNhbGx5LCB0aGV5IHNpbXBseSBhcmVuw6Ligqzi hKJ0IC0gZXZlbiDDouKCrMWTcmVhbMOi4oKswp0gQVFNcyBtYXJraW5nDQo+ID4gaXNuw6Ligqzi hKJ0DQo+ID4gPj4gZXhhY3RseQ0KPiA+ID4+IHRoZSBzYW1lIGFzIGEgcGFja2V0IGRyb3A6IHRo ZSBtYXJrcyB0aGVtc2VsdmVzIGluZm9ybSB5b3UgdGhhdCBhbg0KPiA+IEFRTQ0KPiA+ID4+IGRp ZCBpdHMgam9iLCBhbmQgd2l0aCBtb2Rlcm4gQVFNcyBsaWtlIENvRGVsIC8gUElFIGV0Yy4sIHlv dcOi4oKs4oSicmUNCj4gPiA+PiBwcm9iYWJseQ0KPiA+ID4+IGdldHRpbmcgdGhpcyBmcm9tIGEg c2hhbGxvdyBxdWV1ZS4gQ2hhbmNlcyBhcmUgdGhhdCB0aGlzIGlzIGxlc3MgdGhhbg0KPiA+IGEN Cj4gPiA+PiBCRFAgd29ydGggb2YgcXVldWluZywgd2hpY2ggaXMgb3VyIGp1c3RpZmljYXRpb24g Zm9yIHJlY29tbWVuZGluZyBhDQo+ID4gPj4gZGlmZmVyZW50IGJhY2stb2ZmIGJlaGF2aW9yIGlu IGRyYWZ0LWtoYWRlbWktdHN2d2ctZWNuLXJlc3BvbnNlLTAwDQo+ID4gYW5kDQo+ID4gPj4gZHJh ZnQta2hhZGVtaS10Y3BtLWFsdGVybmF0aXZlYmFja29mZi1lY24tMDANCj4gPiA+Pg0KPiA+ID4+ IFNvIHRoZSBwb2ludCBpcyBub3QgdGhhdCBBUU1zIHdvdWxkIHRyZWF0IEVDTiBtYXJraW5nIGFu ZCBkcm9wcGluZw0KPiA+ID4+IGRpZmZlcmVudGx5IC0gaXTDouKCrOKEonMgdGhhdCBFQ04gaW5k aWNhdGVzIGFuIEFRTSwgYW5kIGhlbmNlIHByb2JhYmx5IGENCj4gPiA+PiBzaGFsbG93IHF1ZXVl LiBXaXRoIGEgZHJvcCwgeW91IGp1c3QgZG9uw6LigqzihKJ0IGtub3cuDQo+ID4gPj4NCj4gPiA+ PiBCYWNrIHRvIHRoZSBDQiwgSSB0aGluayBhbiBBUU0gbWFya2luZyBhdCBhIHNoYWxsb3cgcXVl dWUgKGxpa2UgZS5nLg0KPiA+ID4+IENvRGVsKSBpcyBpbmRlZWQgcXVpdGUgZGlmZmVyZW50IGZy b20gYSDDouKCrMWTYnJva2VuIGNvbm5lY3Rpb27DouKCrMKdLg0KPiA+ID4+DQo+ID4gPj4gQ2hl ZXJzLA0KPiA+ID4+IE1pY2hhZWwNCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4gPg0KPiA+ID4+ID4g VGhhbmtzLCAtLURhdmlkDQo+ID4gPj4gPg0KPiA+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPj4gPj4gRnJvbTogR29ycnkgKGVyZykgW21haWx0bzpnb3JyeUBlcmcuYWJk bi5hYy51a10NCj4gPiA+PiA+PiBTZW50OiBTYXR1cmRheSwgSnVuZSAxOCwgMjAxNiAyOjIzIEFN DQo+ID4gPj4gPj4gVG86IE1pcmphIEvDg8K8aGxld2luZA0KPiA+ID4+ID4+IENjOiBCbGFjaywg RGF2aWQ7IE1hZ251cyBXZXN0ZXJsdW5kOyBDb2xpbiBQZXJraW5zOw0KPiA+IHJ0Y3dlYkBpZXRm Lm9yZzsNCj4gPiA+PiBJRVRGDQo+ID4gPj4gPj4gQVZUQ29yZSBXRzsgdHN2d2cNCj4gPiA+PiA+ PiBTdWJqZWN0OiBSZTogW3RzdndnXSBbcnRjd2ViXSBbQVZUQ09SRV0gV0cgTGFzdCBDYWxsIG9u IGNoYW5nZXM6DQo+ID4gPj4gZHJhZnQtaWV0Zi0NCj4gPiA+PiA+PiBhdnRjb3JlLXJ0cC1jaXJj dWl0LWJyZWFrZXJzLTE2DQo+ID4gPj4gPj4NCj4gPiA+PiA+PiBJIHRoaW5rIHdlIFNIT1VMRCBO T1QgcmVjb21tZW5kIHRvIHVzZSBFQ04gbWFya3MgYXMgaW5wdXRzIHRvIGENCj4gPiBDQi4NCj4g PiA+PiBTZWUNCj4gPiA+PiA+PiBiZWxvdzoNCj4gPiA+PiA+Pg0KPiA+ID4+ID4+PiBPbiAxNyBK dW4gMjAxNiwgYXQgMTY6MDIsIE1pcmphIEvDg8K8aGxld2luZA0KPiA+ID4+IDxtaXJqYS5rdWVo bGV3aW5kQHRpay5lZS5ldGh6LmNoPg0KPiA+ID4+ID4+IHdyb3RlOg0KPiA+ID4+ID4+Pg0KPiA+ ID4+ID4+PiArMSB0byBub3QgdXNlIG5vcm1hdGl2ZSBsYW5ndWFnZSBoZXJlLg0KPiA+ID4+ID4+ Pg0KPiA+ID4+ID4+PiBIb3dldmVyLCBwbGVhc2Ugbm90ZSB0aGF0IGhhdmluZyBhIGhpZ2ggbGV2 ZWwgb2YgRUNOLUNFIG1hcmtzDQo+ID4gPj4gKHdpdGhvdXQgYW55DQo+ID4gPj4gPj4gbG9zc2Vz KSBtZWFucyB0aGF0IGFsbCBwYWNrZXRzIHdlcmUgcmVjZWl2ZWQgY29ycmVjdGx5LiBUaGlzDQo+ ID4gPj4gc2l0dWF0aW9uIGNhbiBldmVuDQo+ID4gPj4gPj4gb2NjdXJzIHdpdGhvdXQgaGlnaCBk ZWxheXMgKGRlcGVuZGluZyBvbiB0aGUgQVFNIHVzZWQpLCB3aGljaA0KPiA+IHdvdWxkDQo+ID4g Pj4ganVzdA0KPiA+ID4+ID4+IG1lYW4gdGhlIHNlcnZpY2VzIHdvcmtzIHBlcmZlY3RseS4gVGhl cmVmb3JlIGZvciBtZSBDRSBtYXJrcyBhcmUgYQ0KPiA+ID4+IHBlcmZlY3QgaW5wdXQNCj4gPiA+ PiA+PiBzaWduYWwgZm9yIGEgY29uZ2VzdGlvbiBjb250cm9sIGxvb3AgKHdoZXJlIHRoZSBBUU0g dGVsbCB0aGUNCj4gPiBzZW5kZXINCj4gPiA+PiB0byB0YWtlIGFjdGlvbg0KPiA+ID4+ID4+IC0g d2hhdGV2ZXIgdGhhdCBtZWFucykuDQo+ID4gPj4gPj4NCj4gPiA+PiA+PiBXZSBtYXkgaW4gZnV0 dXJlIGZpZ3VyZSBvdXQgd2F5cyB0byBkbyB0aGlzIHRvIGRldGVjdCBzaWduaWZpY2FudA0KPiA+ ID4+IGZhaWx1cmUgdXNpbmcgYQ0KPiA+ID4+ID4+IHJhdGUgYWRhcHRpdmUgdHJhbnNwb3J0IGFu ZCBFQ04gZS5nLiAgT2JzZXJ2aW5nIDEwMCUgQ0UgbWFya3Mgb3INCj4gPiA+PiBzb21ldGhpbmcs IGZvcg0KPiA+ID4+ID4+IGFuIFJUUCBmbG93IHRoYXQgaXMgdHJ5aW5nIHRvIHNlbmQgd2VsbCBi ZWxvdyBpdHMgcGVhayByYXRlDQo+ID4gZGVjaWRlZA0KPiA+ID4+IGJ5IENDIC0tIGJ1dCBJDQo+ ID4gPj4gPj4gdGhpbmsgdGhpcyBpcyBzcGVjdWxhdGluZyBhdCBhbiBhbGdvcml0aG0gYW5kIGFk ZGluZyBkZXRhaWxzIGhlcmUNCj4gPiBpcw0KPiA+ID4+IG5vdCBhIGdvb2QgaWRlYS4NCj4gPiA+ PiA+PiBFc3BlY2lhbGx5IGFzIEFRTSBjb250aW51ZXMgdG8gZXZvbHZlLg0KPiA+ID4+ID4+DQo+ ID4gPj4gPj4+IEJ1dCBJw6LigqzihKJtIGxlc3MgY29uY2VybmVkIHRoYW4gRGF2aWQgYWJvdXQg ZXZlbnR1YWxseSBpZ25vcmluZyBpdA0KPiA+ID4+IGZvcg0KPiA+ID4+IGNpcmN1aXQNCj4gPiA+ PiA+PiBicmVha2VyLg0KPiA+ID4+ID4+Pg0KPiA+ID4+ID4+IEFncmVlLiBMb3NzIGlzIHRoZSBt ZWFzdXJlbWVudCB0aGF0IGEgQ0IgTVVTVCByZXNwb25kIHRvLg0KPiA+ID4+ID4+DQo+ID4gPj4g Pj4+IEluIGFkZGl0aW9uIG9uZSBwb2ludCBvbiBzb21ldGhpbmcgTWFnbnVzIHdyb3RlIGVhcmxp ZXI6DQo+ID4gPj4gPj4+ICJJZiB0aGUgaW1wbGVtZW50YXRpb24gb25seSBoYXZlIGNpcmN1aXQg YnJlYWtlciwgaS5lLiBubyBmdWxsDQo+ID4gPj4gZmxlZGdlZCBjb25nZXN0aW9uDQo+ID4gPj4g Pj4gY29udHJvbGxlciBhbmQgdXNlcyBFQ04sIHRoZXkgY2FuIGluIHdvcnN0IGNhc2UgZHJpdmUg dGhlIGJ1ZmZlcg0KPiA+ID4+IGludG8NCj4gPiA+PiB0aGUgb3ZlcmxvYWQNCj4gPiA+PiA+PiBy ZWdpbWUgd2hlcmUgaXQgc3RhcnRzIGRyb3BwaW5nIHBhY2tldHMuIMOi4oKsxb4NCj4gPiA+PiA+ Pj4NCj4gPiA+PiA+Pj4gScOi4oKs4oSibSBub3Qgc3VyZSBhYm91dCB0aGlzIGNhc2UuIEVDTiBp cyBhbiBpbnB1dCBzaWduYWwgZm9yDQo+ID4gPj4gY29uZ2VzdGlvbg0KPiA+ID4+IGNvbnRyb2wu IElmIHlvdQ0KPiA+ID4+ID4+IGRvbsOi4oKs4oSidCB1c2UgY29uZ2VzdGlvbiBjb250cm9sIGJ1 dCBvbmx5IGEgY2lyY3VpdCBicmVha2VyLCB5b3UNCj4gPiA+PiBzaG91bGQNCj4gPiA+PiBwcm9i YWJseSBub3QNCj4gPiA+PiA+PiBlbmFibGUgRUNOLiBBdCBsZWFzdCBpdCBub3QgY2xlYXIgdG8g bWUgd2h5IHlvdSB3b3VsZCBlbmFibGUgaXQsDQo+ID4gYW5kDQo+ID4gPj4gaXQncyBkZWZpbml0 ZWx5DQo+ID4gPj4gPj4gbm90IGNvbmZvcm0gdG8gdGhlIEVDTiBzcGVjLiBQcm9iYWJseSB3ZSBz aG91bGQgc2F5IHNvbWV0aGluZw0KPiA+IGFib3V0DQo+ID4gPj4gdGhpcyBpbiB0aGUNCj4gPiA+ PiA+PiBkcmFmdC4uLj8NCj4gPiA+PiA+Pj4NCj4gPiA+PiA+PiBBZ3JlZSwgZW5hYmxpbmcgRUNO IHdpdGhvdXQgYSByZXNwb25zaXZlIENDIGlzIGdvaW5nIHRvIGxlYWQgdG8NCj4gPiA+PiB0cm91 YmxlLg0KPiA+ID4+ID4+DQo+ID4gPj4gPj4+IE1pcmphDQo+ID4gPj4gPj4+DQo+ID4gPj4gPj4g R29ycnkNCj4gPiA+PiA+Pg0KPiA+ID4+ID4+Pj4gQW0gMTcuMDYuMjAxNiB1bSAxNjowMyBzY2hy aWViIEJsYWNrLCBEYXZpZA0KPiA+IDxkYXZpZC5ibGFja0BlbWMuY29tPjoNCj4gPiA+PiA+Pj4+ DQo+ID4gPj4gPj4+PiBDb2xpbiwNCj4gPiA+PiA+Pj4+DQo+ID4gPj4gPj4+Pj4+PiAuLi4gIEkg dmlldyB0aGUgY3VycmVudCB0ZXh0IGFzIHByb3ZpZGluZyBpbXBsZW1lbnRlcnMgd2l0aA0KPiA+ IHRvbw0KPiA+ID4+IG11Y2gNCj4gPiA+PiA+Pj4+Pj4+IGxhdGl0dWRlIHRvIGlnbm9yZSBFQ04t Q0UgbWFya3MgKGUuZy4sIGJlY2F1c2UgYW4gaW1wbGVtZW50ZXINCj4gPiA+PiBkb2Vzbid0DQo+ ID4gPj4gPj4+Pj4+PiB3YW50IHRvIHRoaW5rIGFib3V0IHRoaXMgcHJvYmxlbSBzcGFjZSBpbiB0 aGUgZmlyc3QgcGxhY2UpLg0KPiA+ID4+ID4+Pj4+DQo+ID4gPj4gPj4+Pj4gSSBhZ3JlZSwgYnV0 IHRoZSBhcmd1bWVudCBpcyB0aGF0IGRvaW5nIHNvIGlzIGxlc3MgaGFybWZ1bCB0aGFuDQo+ID4g Pj4gZGVwbG95aW5nIGENCj4gPiA+PiA+PiBjaXJjdWl0DQo+ID4gPj4gPj4+Pj4gYnJlYWtlciB0 aGF0IHRyaWdnZXJzIHRvbyBvZnRlbiB3aGVuIEVDTiBpcyB1c2VkLg0KPiA+ID4+ID4+Pj4+DQo+ ID4gPj4gPj4+Pj4gScOi4oKs4oSibSBub3Qgc3VyZSBJIGJlbGlldmUgdGhpcyBhcmd1bWVudCwg dGhvdWdoLCBzaW5jZSBpdCBzZWVtcw0KPiA+ID4+IHRoYXQNCj4gPiA+PiBhbnkgbmV3DQo+ID4g Pj4gPj4gQVFNDQo+ID4gPj4gPj4+Pj4gdGhhdCBhcHBsaWVzIEVDTiBtYXJrcyBtdWNoIG1vcmUg b2Z0ZW4gdGhhbiBhdCBwcmVzZW50IHdpbGwNCj4gPiBoYXZlDQo+ID4gPj4gdG8NCj4gPiA+PiA+ PiBjb25zaWRlcg0KPiA+ID4+ID4+Pj4+IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCB0byB3b3Jr IHdpdGggZGVwbG95ZWQgVENQIChlLmcuLA0KPiA+IGRyYWZ0LQ0KPiA+ID4+IGJyaXNjb2UtDQo+ ID4gPj4gPj4gdHN2d2ctDQo+ID4gPj4gPj4+Pj4gYXFtLXRjcG0tcm1jYXQtbDRzLXByb2JsZW0g dXNlcyBFQ1QoMSkgYXMgYSBzaWduYWwgdG8gdXNlIHRoZQ0KPiA+IG5ldw0KPiA+ID4+IG1hcmtp bmcsDQo+ID4gPj4gPj4+Pj4gd2hpbGUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHNldCBFQ1Qo MCkpLiBUaGVzZSBjb21wYXRpYmlsaXR5DQo+ID4gPj4gbWVjaGFuaXNtcw0KPiA+ID4+ID4+Pj4+ IHdvdWxkIHNlZW0gdG8gcHJldmVudCB0aGUgaXNzdWVzIHdpdGggdGhlIGNpcmN1aXQgYnJlYWtl ciB0b28uDQo+ID4gPj4gPj4+Pg0KPiA+ID4+ID4+Pj4gVGhhdCByb3VnaGx5IG1hdGNoZXMgbXkg bGluZSBvZiB0aGlua2luZywgYW5kIEknbGwgb2JzZXJ2ZSB0aGF0DQo+ID4gPj4gdGhlDQo+ID4g Pj4gb3JpZ2luYWwNCj4gPiA+PiA+PiBEQ1RDUA0KPiA+ID4+ID4+Pj4gcHJvdG9jb2wgZGVzaWdu IHRoYXQgdXNlZCBtb3JlIGFnZ3Jlc3NpdmUgRUNOLUNFIG1hcmtpbmcgd2FzDQo+ID4gb25seQ0K PiA+ID4+IHNhZmUgZm9yDQo+ID4gPj4gPj4+PiBDb250cm9sbGVkIEVudmlyb25tZW50IGRlcGxv eW1lbnRzLiAgIFNlZSB0aGUgVFNWV0cgcmZjNTQwNWJpcw0KPiA+ID4+IGRyYWZ0IGZvcg0KPiA+ ID4+ID4+IHRoZQ0KPiA+ID4+ID4+Pj4gZGVmaW5pdGlvbiBvZiBDb250cm9sbGVkIEVudmlyb25t ZW50LCBhbmQgaWdub3JlIHRoZSBmYWN0IHRoYXQNCj4gPiB0aGUNCj4gPiA+PiByZmM1NDA1Ymlz DQo+ID4gPj4gPj4+PiBkcmFmdCBpcyBhIFVEUCBkcmFmdCAtIHRoaXMgZGVmaW5pdGlvbiBpcyBt b3JlIGJyb2FkbHkNCj4gPiBhcHBsaWNhYmxlLg0KPiA+ID4+ID4+Pj4NCj4gPiA+PiA+Pj4+IEdv aW5nIGJhY2sgb3ZlciBTZWN0aW9uIDcgaW4gdGhpcyBhdnRjb3JlIGRyYWZ0LCBteSB2aWV3cyBh cmU6DQo+ID4gPj4gPj4+Pg0KPiA+ID4+ID4+Pj4gW0FdIE5vbmUgb2YgdGhlc2UgZHJhZnRzIGp1 c3RpZnkgYSAiTUFZIGlnbm9yZSIgcmVzcG9uc2UgdG8gRUNOLQ0KPiA+IENFDQo+ID4gPj4gbWFy a3M6DQo+ID4gPj4gPj4+PiAgIC0gZHJhZnQta2hhZGVtaS10Y3BtLWFsdGVybmF0aXZlYmFja29m Zi1lY24NCj4gPiA+PiA+Pj4+ICAgLSBkcmFmdC1pZXRmLXJtY2F0LW5hZGENCj4gPiA+PiA+Pj4+ ICAgLSBkcmFmdC1pZXRmLXJtY2F0LXNjcmVhbS1jYw0KPiA+ID4+ID4+Pj4NCj4gPiA+PiA+Pj4+ IFtCXSBJbiBsaW5lIHdpdGggQ29saW4ncyBjb21tZW50IG9uIHRoZSBMNFMgZHJhZnQsIEkgdGhp bmsgaXQncw0KPiA+ID4+IGluY3VtYmVudCBvbg0KPiA+ID4+ID4+Pj4gdGhlIGF1dGhvcnMgb2Yg ZHJhZnQtYnJpc2NvZS1hcW0tZHVhbHEtY291cGxlZCB0byBmaWd1cmUgb3V0IGhvdw0KPiA+ID4+ IHRoYXQgd2lsbA0KPiA+ID4+ID4+Pj4gY29leGlzdCAob3IgYXZvaWQpIGRlcGxveWVkIFRDUCwg YW5kIHRoaXMgYXZ0Y29yZSBkcmFmdCBvdWdodA0KPiA+IG5vdA0KPiA+ID4+IHRvIGJlDQo+ID4g Pj4gPj4+PiB0cnlpbmcgdG8gcHJlanVkZ2Ugd2hhdCB3aWxsIGJlIGRvbmUgdGhlcmUuDQo+ID4g Pj4gPj4+Pg0KPiA+ID4+ID4+Pj4gU28sIEkgZG9uJ3QgdGhpbmsgdGhlIGN1cnJlbnQgdGV4dCBp biBTZWN0aW9uIDcgaGFzIGp1c3RpZmllZA0KPiA+IHRoZQ0KPiA+ID4+IHVuZmV0dGVyZWQNCj4g PiA+PiA+Pj4+ICJpbXBsZW1lbnRhdGlvbnMgTUFZIGlnbm9yZSBFQ04tQ0UgbWFya3MiIHRleHQs IGFzIGlnbm9yaW5nDQo+ID4gdGhvc2UNCj4gPiA+PiBtYXJrcw0KPiA+ID4+ID4+Pj4gaXMgbm90 IGNvbnNpc3RlbnQgd2l0aCBhbnkgb2YgdGhlIGZvdXIgY2l0ZWQgZHJhZnRzLg0KPiA+ID4+ID4+ Pj4NCj4gPiA+PiA+Pj4+IEluIG1vcmUgZGV0YWlsLCBJIHRoaW5rIG1ha2luZyBjaGFuZ2VzIHRv IG5vcm1hdGl2ZSByZXF1aXJlbWVudHMNCj4gPiA+PiBoZXJlIGJhc2VkDQo+ID4gPj4gPj4+PiBv biBbQl0gaXMgcHJlbWF0dXJlLCBhbmQgSSB3b3VsZCBob3BlIHRoYXQgdGhlIHJtY2F0IFdHIGNv dWxkIGJlDQo+ID4gPj4gPj4gZW5jb3VyYWdlZA0KPiA+ID4+ID4+Pj4gdG8gY29uc2lkZXIgdGhl IFJUUCBjaXJjdWl0IGJyZWFrZXIgaW4gaXRzIGNvbmdlc3Rpb24gY29udHJvbA0KPiA+ID4+IGRy YWZ0cywgYXMgdGhvc2UgQ0MNCj4gPiA+PiA+Pj4+IG1lY2hhbmlzbXMgYXJlIHJlbGF0ZWQgdG8g dGhlIGNpcmN1aXQgYnJlYWtlciBtZWNoYW5pc20sIGhlbmNlDQo+ID4gPj4gbGlrZWx5DQo+ID4g Pj4gPj4+PiB0byBiZSBpbiByZWxhdGVkIGFyZWFzIG9mIGFuIFJUUCBpbXBsZW1lbnRhdGlvbi4N Cj4gPiA+PiA+Pj4+DQo+ID4gPj4gPj4+PiBUaGF0IGxlYXZlcyBkcmFmdC1raGFkZW1pLXRjcG0t YWx0ZXJuYXRpdmViYWNrb2ZmLWVjbiwgd2hpY2gNCj4gPiBUU1ZXRw0KPiA+ID4+ID4+Pj4gd2ls bCBiZSBsb29raW5nIGF0IGluIEJlcmxpbi4gIElmIGEgbm9ybWF0aXZlIHN0YXRlbWVudCBhYm91 dA0KPiA+IEVDTi0NCj4gPiA+PiBDRSByZWFjdGlvbg0KPiA+ID4+ID4+Pj4gaXMgZ29pbmcgdG8g cmVzdCBvbiB0aGF0IGRyYWZ0LCB0aGVuIHRoZSByZWZlcmVuY2UgdG8gdGhhdCBkcmFmdA0KPiA+ ID4+IHNob3VsZCBiZQ0KPiA+ID4+ID4+Pj4gbm9ybWF0aXZlLiAgU29tZXRoaW5nIGFib3V0IGRv aW5nIHRoYXQgc3RyaWtlcyBtZSBhcyBwcmVtYXR1cmUNCj4gPiAuLi4NCj4gPiA+PiA+Pj4+DQo+ ID4gPj4gPj4+PiBJIHJlYWxpemUgdGhhdCB3ZSdyZSB0cnlpbmcgdG8gcHJlZGljdCBhbmQgYWNj b21tb2RhdGUgdGhlDQo+ID4gZnV0dXJlLA0KPiA+ID4+IHdoaWNoDQo+ID4gPj4gPj4+PiBpcyBh biBpbXByZWNpc2UgdW5kZXJ0YWtpbmcgYXQgYmVzdC4gICBBcyBhbiBhbHRlcm5hdGl2ZSB0byB0 aGUNCj4gPiA+PiBjdXJyZW50IHRleHQsDQo+ID4gPj4gPj4+PiB3b3VsZCBpdCBiZSByZWFzb25h YmxlIHRvIHNheSAod2l0aG91dCBhbnkgUkZDIDIxMTkga2V5d29yZHMpDQo+ID4gdGhhdA0KPiA+ ID4+IHRoZQ0KPiA+ID4+ID4+Pj4gYmVzdCBjdXJyZW50IGd1aWRhbmNlIGlzIHN0aWxsIHRvIHRy ZWF0IEVDTi1DRSBtYXJrcyBhcw0KPiA+IGluZGljYXRpbmcNCj4gPiA+PiBkcm9wcywNCj4gPiA+ PiA+Pj4+IHdpdGggYSB3YXJuaW5nIHRoYXQgdGhlcmUgaXMgYSBnb29kIHBvc3NpYmlsaXR5IG9m IHRoaXMgY2hhbmdpbmcNCj4gPiA+PiBpbg0KPiA+ID4+IHRoZQ0KPiA+ID4+ID4+Pj4gbmVhciBm dXR1cmUgZHVlIHRvIGFsbCBvZiB0aGUgd29yayBpbiBwcm9ncmVzcyBjaXRlZCBpbiBTZWN0aW9u DQo+ID4gNz8NCj4gPiA+PiA+Pj4+DQo+ID4gPj4gPj4+PiBUaGFua3MsIC0tRGF2aWQNCj4gPiA+ PiA+Pj4+DQo+ID4gPj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+PiA+ Pj4+PiBGcm9tOiBDb2xpbiBQZXJraW5zIFttYWlsdG86Y3NwQGNzcGVya2lucy5vcmddDQo+ID4g Pj4gPj4+Pj4gU2VudDogRnJpZGF5LCBKdW5lIDE3LCAyMDE2IDY6MTQgQU0NCj4gPiA+PiA+Pj4+ PiBUbzogSm9obiBMZXNsaWU7IEJsYWNrLCBEYXZpZA0KPiA+ID4+ID4+Pj4+IENjOiBydGN3ZWJA aWV0Zi5vcmc7IElFVEYgQVZUQ29yZSBXRzsgdHN2d2cNCj4gPiA+PiA+Pj4+PiBTdWJqZWN0OiBS ZTogW3J0Y3dlYl0gW0FWVENPUkVdIFt0c3Z3Z10gV0cgTGFzdCBDYWxsIG9uDQo+ID4gY2hhbmdl czoNCj4gPiA+PiBkcmFmdC1pZXRmLQ0KPiA+ID4+ID4+Pj4+IGF2dGNvcmUtcnRwLWNpcmN1aXQt YnJlYWtlcnMtMTYNCj4gPiA+PiA+Pj4+Pg0KPiA+ID4+ID4+Pj4+DQo+ID4gPj4gPj4+Pj4+IE9u IDE2IEp1biAyMDE2LCBhdCAyMzoyNSwgSm9obiBMZXNsaWUgPGpvaG5AamxjLm5ldD4gd3JvdGU6 DQo+ID4gPj4gPj4+Pj4+DQo+ID4gPj4gPj4+Pj4+IEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tA ZW1jLmNvbT4gd3JvdGU6DQo+ID4gPj4gPj4+Pj4+Pg0KPiA+ID4+ID4+Pj4+Pj4gLi4uICBJIHZp ZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBwcm92aWRpbmcgaW1wbGVtZW50ZXJzIHdpdGgNCj4gPiB0 b28NCj4gPiA+PiBtdWNoDQo+ID4gPj4gPj4+Pj4+PiBsYXRpdHVkZSB0byBpZ25vcmUgRUNOLUNF IG1hcmtzIChlLmcuLCBiZWNhdXNlIGFuIGltcGxlbWVudGVyDQo+ID4gPj4gZG9lc24ndA0KPiA+ ID4+ID4+Pj4+Pj4gd2FudCB0byB0aGluayBhYm91dCB0aGlzIHByb2JsZW0gc3BhY2UgaW4gdGhl IGZpcnN0IHBsYWNlKS4NCj4gPiA+PiA+Pj4+Pg0KPiA+ID4+ID4+Pj4+IEkgYWdyZWUsIGJ1dCB0 aGUgYXJndW1lbnQgaXMgdGhhdCBkb2luZyBzbyBpcyBsZXNzIGhhcm1mdWwgdGhhbg0KPiA+ID4+ IGRlcGxveWluZyBhDQo+ID4gPj4gPj4gY2lyY3VpdA0KPiA+ID4+ID4+Pj4+IGJyZWFrZXIgdGhh dCB0cmlnZ2VycyB0b28gb2Z0ZW4gd2hlbiBFQ04gaXMgdXNlZC4NCj4gPiA+PiA+Pj4+Pg0KPiA+ ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMgYXJndW1lbnQsIHRo b3VnaCwgc2luY2UgaXQgc2VlbXMNCj4gPiA+PiB0aGF0DQo+ID4gPj4gYW55IG5ldw0KPiA+ID4+ ID4+IEFRTQ0KPiA+ID4+ID4+Pj4+IHRoYXQgYXBwbGllcyBFQ04gbWFya3MgbXVjaCBtb3JlIG9m dGVuIHRoYW4gYXQgcHJlc2VudCB3aWxsDQo+ID4gaGF2ZQ0KPiA+ID4+IHRvDQo+ID4gPj4gPj4g Y29uc2lkZXINCj4gPiA+PiA+Pj4+PiBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSwgdG8gd29yayB3 aXRoIGRlcGxveWVkIFRDUCAoZS5nLiwNCj4gPiBkcmFmdC0NCj4gPiA+PiBicmlzY29lLQ0KPiA+ ID4+ID4+IHRzdndnLQ0KPiA+ID4+ID4+Pj4+IGFxbS10Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVz ZXMgRUNUKDEpIGFzIGEgc2lnbmFsIHRvIHVzZSB0aGUNCj4gPiBuZXcNCj4gPiA+PiBtYXJraW5n LA0KPiA+ID4+ID4+Pj4+IHdoaWxlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDAp KS4gVGhlc2UgY29tcGF0aWJpbGl0eQ0KPiA+ID4+IG1lY2hhbmlzbXMNCj4gPiA+PiA+Pj4+PiB3 b3VsZCBzZWVtIHRvIHByZXZlbnQgdGhlIGlzc3VlcyB3aXRoIHRoZSBjaXJjdWl0IGJyZWFrZXIg dG9vLg0KPiA+ID4+ID4+Pj4+DQo+ID4gPj4gPj4+Pj4+IFVuZGVyc3RhbmQsIHdlIGhhdmUgYXQg bGVhc3QgdHdvIHByb3Bvc2FscyB0byBtYWtlIEVDTi1DRSBtb3JlDQo+ID4gPj4gPj4gZnJlcXVl bnQNCj4gPiA+PiA+Pj4+Pj4gdGhhbiBwYWNrZXQgZHJvcCB3b3VsZCBiZSBmb3Igbm9uLUVDTiBw YWNrZXRzOiBwb3NzaWJseQ0KPiA+ID4+IHN1YnN0YW50aWFsbHkNCj4gPiA+PiA+Pj4+Pj4gbW9y ZSBmcmVxdWVudC4gVW5sZXNzIGJvdGggYXJlIGtpbGxlZCBvZmYsIEVDTi1DRSB3aWxsIHNob3cg dXANCj4gPiA+PiBmcmVxdWVudGx5DQo+ID4gPj4gPj4+Pj4+IGVub3VnaCB0aGF0IGNsb3Npbmcg dGhlIGZsb3cgb24gRUNOLUNFIHdvdWxkIGtpbGwgdG9vIG1hbnkNCj4gPiA+PiBjb25uZWN0aW9u cy4NCj4gPiA+PiA+Pj4+Pj4NCj4gPiA+PiA+Pj4+Pj4gSWYgeW91IHdhbnQgY2lyY3VpdC1icmVh a2luZyBvbiBzdWNoIGNvbm5lY3Rpb25zLCB0aGVyZSBhcmUNCj4gPiB0d28NCj4gPiA+PiB3YXlz Og0KPiA+ID4+ID4+Pj4+PiAxLiBjb252aW5jZSB0aGUgZm9yd2FyZGluZyBub2RlcyB0byBkcm9w IHBhY2tldHMgaWYgdGhlaXINCj4gPiBxdWV1ZQ0KPiA+ID4+IGV4Y2VlZHMNCj4gPiA+PiA+Pj4+ Pj4gZGVzaWduIGNhcGFjaXR5OyBvcg0KPiA+ID4+ID4+Pj4+PiAyLiByZXF1aXJlIHRoZSBzZW5k ZXIgdG8gc2VuZCBlbm91Z2ggbm90LUVDTi1jYXBhYmxlIHBhY2tldHMNCj4gPiBzbw0KPiA+ID4+ IHRoYXQgb3VyDQo+ID4gPj4gPj4+Pj4+IHJlY2VpdmVyIHdpbGwgc2VlIGVub3VnaCBwYWNrZXQt ZHJvcHMgd2hlbiBhIGNpcmN1aXQtYnJlYWtlcg0KPiA+ID4+IHNob3VsZA0KPiA+ID4+ID4+Pj4+ PiBhY3RpdmF0ZS4NCj4gPiA+PiA+Pj4+Pj4NCj4gPiA+PiA+Pj4+Pj4gKEkgcHJlZmVyIHRoZSBm aXJzdCBvcHRpb247IGJ1dCBJIHdvdWxkbid0IG9iamVjdCB0byB0aGUNCj4gPiA+PiBzZWNvbmQu KQ0KPiA+ID4+ID4+Pj4+Pg0KPiA+ID4+ID4+Pj4+PiBUaGVyZSByZWFsbHkgaXNuJ3QgYW55IHdh eSBmb3Igb3VyIGNpcmN1aXQtYnJlYWtlciB0byBrbm93DQo+ID4gPj4gX2hvd19tdWNoXw0KPiA+ ID4+ID4+Pj4+PiBtb3JlIGZyZXF1ZW50IHRoZSBFQ04tQ0UgbWFya3MgbWF5IGJlLiA6XigNCj4g PiA+PiA+Pj4+Pg0KPiA+ID4+ID4+Pj4+IFRoaXMgaXMgYSBwcm9ibGVtLCBib3RoIGZvciB0aGUg Y2lyY3VpdCBicmVha2VyLCBhbmQgZm9yIHRoZQ0KPiA+ID4+IGFsZ29yaXRobXMgYmVpbmcNCj4g PiA+PiA+Pj4+PiBkZWZpbmVkIGluIFJNQ0FULiBXZSBkbyBuZWVkIHNvbWUgdW5kZXJzdGFuZGlu ZyB3aGF0IHRoZQ0KPiA+IGV4cGVjdGVkDQo+ID4gPj4gPj4gbWFya2luZw0KPiA+ID4+ID4+Pj4+ IHJhdGVzIGFyZSBsaWtlbHkgdG8gYmUsIHNvIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgY2lyY3Vp dA0KPiA+ID4+IGJyZWFrZXJzDQo+ID4gPj4gY2FuIGJlDQo+ID4gPj4gPj4gZGVmaW5lZC4NCj4g PiA+PiA+Pj4+Pg0KPiA+ID4+ID4+Pj4+PiBXZSBfd2lsbF8gYmUgc29ycnkgaWYgd2UNCj4gPiA+ PiA+Pj4+Pj4gYWxsb3QgdGhlIHNhbWUgZnJlcXVlbmN5IG9mIENFIHBhY2tldHMgYXMgcGFja2V0 LWRyb3BzIHRvDQo+ID4gPj4gdHJpZ2dlcg0KPiA+ID4+IHRoZQ0KPiA+ID4+ID4+Pj4+PiBjaXJj dWl0LWJyZWFrZXIuDQo+ID4gPj4gPj4+Pj4+DQo+ID4gPj4gPj4+Pj4+PiBDb3VsZCBzb21lb25l IHByb3Bvc2UgaW5pdGlhbCB0ZXh0IHRvIHF1YWxpZmllcyB0aGUgY3VycmVudA0KPiA+ID4+ICJN QVkNCj4gPiA+PiBpZ25vcmUiDQo+ID4gPj4gPj4+Pj4+PiBzdGF0ZW1lbnQ/DQo+ID4gPj4gPj4+ Pj4+DQo+ID4gPj4gPj4+Pj4+IEVzc2VudGlhbGx5LCBmb3IgdGhlIHNlY29uZCBvcHRpb24sIHlv dSBtaWdodCBwcm9wb3NlIHRleHQgdG8NCj4gPiA+PiB0aGUNCj4gPiA+PiA+Pj4+Pj4gZWZmZWN0 IG9mOg0KPiA+ID4+ID4+Pj4+PiBdDQo+ID4gPj4gPj4+Pj4+IF0gSWYgdG9vIG1hbnkgRUNOLUNF IHBhY2tldHMgYXJlIHJlY2VpdmVkLCB0aGUgc2VuZGVyIFNIT1VMRA0KPiA+ID4+IHNlbmQNCj4g PiA+PiBzb21lDQo+ID4gPj4gPj4+Pj4+IF0gbm90LUVDTi1jYXBhYmxlIHBhY2tldHMgdG8gZGV0 ZXJtaW5lIHdoZXRoZXIgZW5vdWdoIHBhY2tldHMNCj4gPiA+PiBhbG9uZyB0aGUNCj4gPiA+PiA+ Pj4+Pj4gXSBwYXRoIGFyZSBiZWluZyBkcm9wcGVkIHRvIGp1c3RpZnkgYWN0aXZhdGluZyBvdXIg Y2lyY3VpdC0NCj4gPiA+PiBicmVha2VyLg0KPiA+ID4+ID4+Pj4+Pg0KPiA+ID4+ID4+Pj4+PiBJ w6LigqzihKJtIG5vdCBlbnRodXNpYXN0aWMgYWJvdXQgYWRkaW5nIHRoYXQ7IGJ1dCBpdCB3b3Vs ZCByZXNvbHZlDQo+ID4gPj4gdGhlDQo+ID4gPj4gaXNzdWUuDQo+ID4gPj4gPj4+Pj4NCj4gPiA+ PiA+Pj4+PiBJw6LigqzihKJtIG5vdCBjb252aW5jZWQgdGhpcyB3b3VsZCB3b3JrLiBUaGUgY2ly Y3VpdCBicmVha2VyIGlzDQo+ID4gPj4gbG9va2luZw0KPiA+ID4+IGF0IGxvbmcgdGVybQ0KPiA+ ID4+ID4+Pj4+IHRyZW5kcywgYW5kIGluIG9yZGVyIHRvIGhhdmUgZW5vdWdoIG5vdC1FQ1QgcGFj a2V0cyB0bw0KPiA+IGRldGVybWluZQ0KPiA+ID4+IGlmIGl0DQo+ID4gPj4gPj4gc2hvdWxkDQo+ ID4gPj4gPj4+Pj4gdHJpZ2dlciwgeW91w6LigqzihKJkIGVzc2VudGlhbGx5IGhhdmUgdG8gcnVu IHdpdGhvdXQgRUNOIGZvciBzb21lDQo+ID4gPj4gc2Vjb25kcy4NCj4gPiA+PiA+Pj4+Pg0KPiA+ ID4+ID4+Pj4+IC0tDQo+ID4gPj4gPj4+Pj4gQ29saW4gUGVya2lucw0KPiA+ID4+ID4+Pj4+IGh0 dHBzOi8vY3NwZXJraW5zLm9yZy8NCj4gPiA+PiA+Pj4+DQo+ID4gPj4gPj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+ID4+Pj4gcnRjd2Vi IG1haWxpbmcgbGlzdA0KPiA+ID4+ID4+Pj4gcnRjd2ViQGlldGYub3JnDQo+ID4gPj4gPj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiA+ID4+ID4NCj4g PiA+DQo+ID4gPg0KDQo= From nobody Mon Jun 27 13:44:06 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D745012D8E6; Mon, 27 Jun 2016 13:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1ikFbNLwd5R; Mon, 27 Jun 2016 13:43:53 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43E212D8C9; Mon, 27 Jun 2016 13:43:51 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bHdNj-0003hj-GG; Mon, 27 Jun 2016 22:43:47 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bHdNi-0008Hm-4k; Mon, 27 Jun 2016 22:43:47 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Mon, 27 Jun 2016 22:43:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> To: "De Schepper, Koen (Nokia - BE)" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 4 sum rcpts/h 15 sum msgs/h 6 total rcpts 43711 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DC59AF59C13BC0D4F28E9F553A241CEB4D1FF3F9 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1460 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: " Fairhurst" , tsvwg , "Black, David" , IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 20:43:58 -0000 > On 27. jun. 2016, at 21.12, De Schepper, Koen (Nokia - BE) = wrote: >=20 >=20 >> -----Original Message----- >> From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] >> Sent: maandag 27 juni 2016 17:38 >> To: De Schepper, Koen (Nokia - BE) >> Cc: Michael Welzl; Black, David; gorry@erg.abdn.ac.uk; Magnus >> Westerlund; tsvwg; IETF AVTCore WG; rtcweb@ietf.org; Colin Perkins >> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: = draft- >> ietf-avtcore-rtp-circuit-breakers-16 >>=20 >> I think thinking of L4S is maybe off at a tangent. The question = really >> is >> about the interpretation of loss and CE-mark as equivalent. I argued >> that >> each ECN-CE mark should not be counted as equivalent to a lost = segment - >=20 > Why not? As long as an AQM is marking at the same rate as dropping, a=20= > 100% marking means that non-ecn flows are being dropped at a 100%, = not? Yes you can construct an AQM mechanism to act precisely like that. Do we want rules that make every other behavior =E2=80=9Cillegal=E2=80=9D = ? Should this really be how end systems should interpret all forms of = CE-marking? I think we both would agree that the answer is no: both the L4S and the = ABE work are based on the premise that a CE-mark does *NOT* necessarily = mean the same as packet loss would. So I agree with Gorry here - a circuit breaker is a bit of a special = beast. It really mustn=E2=80=99t trigger by accident. Cheers, Michael >=20 > Koen. >=20 >=20 >> in this context we should use ECN to drive a CC algorithm and we = should >> be >> cautious to avoid requiring its use within a Circuit Breaker - = optional >> use, if you understand how to interpret a reaction to many CE-marks = as >> excessive congestion, are permitted. >>=20 >> Gorry >>=20 >>> As far as I understand, this draft is related to circuit breakers in >>> end-systems, right? >>>=20 >>> It is the end system that determines the use of ECN (currently = marking >>> non-ect for drop and ect(0) for Classic ECN). >>>=20 >>> In L4S we don't plan to change the behavior of Classic ECN, and = ABE's >>> behavior should be close to non-ABE ECN. So I guess there is no >> problem of >>> describing the behavior of how a Classic ECN based sender would >> respond >>> today. >>>=20 >>> As we only want to significantly change the network behavior of = ect(1) >>> marking, can we solve this issue by recommending (or even requiring) >>> senders to mark only ect(0) and describing the classic ECN circuit >>> breaker? When L4S gets defined, also an L4S based circuit breaker >>> extension can be defined for senders that want to use the L4S = service >>> (when senders send ect(1) packets). >>>=20 >>> Regards, >>> Koen. >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael >> Welzl >>>> Sent: maandag 20 juni 2016 18:36 >>>> To: Black, David >>>> Cc: Fairhurst; Magnus Westerlund; tsvwg; = IETF >>>> AVTCore WG; rtcweb@ietf.org; Colin Perkins >>>> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: >> draft- >>>> ietf-avtcore-rtp-circuit-breakers-16 >>>>=20 >>>>=20 >>>>> On 20. jun. 2016, at 15.16, Black, David >> wrote: >>>>>=20 >>>>>>> But I=C3=A2=E2=82=AC=E2=84=A2m less concerned than David about = eventually ignoring it >>>> for >>>> circuit >>>>>> breaker. >>>>>>>=20 >>>>>> Agree. Loss is the measurement that a CB MUST respond to. >>>>>=20 >>>>> Mumble. I would be ok with a clear discouragement for use of = ECN- >> CE >>>> marks, accompanied by the sort of design rationale here, or even >>>> better, >>>> a clear statement that lost packets for the purpose of the RTP >> circuit >>>> breaker have to be actually lost without getting into whether or = not >>>> ECN-CE marks are involved -i.e., the RTP circuit breaker is = specified >>>> against actual drops as a network protection backstop. >>>>>=20 >>>>> A related concern is that ECN marks may overstate equivalent loss >>>> behavior - a simplistic queue management discipline that marks = every >>>> packet when the queue is over a threshold (NB: this class of = marking >>>> behavior is NOT RECOMMENDED - a real AQM SHOULD be used) could = yield >> a >>>> run of ECN-CE marks that would not cause a corresponding with a run >> of >>>> packet drops. This is among the reasons that TCP reacts to ECN-CE >>>> marks only once per RTT, and might be a reason to treat multiple = ECN- >> CE >>>> marks in an RTT interval as not representing drops of all packets = for >>>> the RTP circuit breaker's TCP-equivalent throughput calculation. >>>>=20 >>>> I=C3=A2=E2=82=AC=E2=84=A2m not sure we need such complicated logic = to find a case where >> ECN >>>> marks are different from packet drops: >>>>=20 >>>> Basically, they simply aren=C3=A2=E2=82=AC=E2=84=A2t - even = =C3=A2=E2=82=AC=C5=93real=C3=A2=E2=82=AC=C2=9D AQMs marking >> isn=C3=A2=E2=82=AC=E2=84=A2t >>>> exactly >>>> the same as a packet drop: the marks themselves inform you that an >> AQM >>>> did its job, and with modern AQMs like CoDel / PIE etc., = you=C3=A2=E2=82=AC=E2=84=A2re >>>> probably >>>> getting this from a shallow queue. Chances are that this is less = than >> a >>>> BDP worth of queuing, which is our justification for recommending a >>>> different back-off behavior in draft-khademi-tsvwg-ecn-response-00 >> and >>>> draft-khademi-tcpm-alternativebackoff-ecn-00 >>>>=20 >>>> So the point is not that AQMs would treat ECN marking and dropping >>>> differently - it=C3=A2=E2=82=AC=E2=84=A2s that ECN indicates an = AQM, and hence probably a >>>> shallow queue. With a drop, you just don=C3=A2=E2=82=AC=E2=84=A2t = know. >>>>=20 >>>> Back to the CB, I think an AQM marking at a shallow queue (like = e.g. >>>> CoDel) is indeed quite different from a =C3=A2=E2=82=AC=C5=93broken = connection=C3=A2=E2=82=AC=C2=9D. >>>>=20 >>>> Cheers, >>>> Michael >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks, --David >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Gorry (erg) [mailto:gorry@erg.abdn.ac.uk] >>>>>> Sent: Saturday, June 18, 2016 2:23 AM >>>>>> To: Mirja K=C3=83=C2=BChlewind >>>>>> Cc: Black, David; Magnus Westerlund; Colin Perkins; >> rtcweb@ietf.org; >>>> IETF >>>>>> AVTCore WG; tsvwg >>>>>> Subject: Re: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: >>>> draft-ietf- >>>>>> avtcore-rtp-circuit-breakers-16 >>>>>>=20 >>>>>> I think we SHOULD NOT recommend to use ECN marks as inputs to a >> CB. >>>> See >>>>>> below: >>>>>>=20 >>>>>>> On 17 Jun 2016, at 16:02, Mirja K=C3=83=C2=BChlewind >>>> >>>>>> wrote: >>>>>>>=20 >>>>>>> +1 to not use normative language here. >>>>>>>=20 >>>>>>> However, please note that having a high level of ECN-CE marks >>>> (without any >>>>>> losses) means that all packets were received correctly. This >>>> situation can even >>>>>> occurs without high delays (depending on the AQM used), which >> would >>>> just >>>>>> mean the services works perfectly. Therefore for me CE marks are = a >>>> perfect input >>>>>> signal for a congestion control loop (where the AQM tell the >> sender >>>> to take action >>>>>> - whatever that means). >>>>>>=20 >>>>>> We may in future figure out ways to do this to detect significant >>>> failure using a >>>>>> rate adaptive transport and ECN e.g. Observing 100% CE marks or >>>> something, for >>>>>> an RTP flow that is trying to send well below its peak rate >> decided >>>> by CC -- but I >>>>>> think this is speculating at an algorithm and adding details here >> is >>>> not a good idea. >>>>>> Especially as AQM continues to evolve. >>>>>>=20 >>>>>>> But I=C3=A2=E2=82=AC=E2=84=A2m less concerned than David about = eventually ignoring it >>>> for >>>> circuit >>>>>> breaker. >>>>>>>=20 >>>>>> Agree. Loss is the measurement that a CB MUST respond to. >>>>>>=20 >>>>>>> In addition one point on something Magnus wrote earlier: >>>>>>> "If the implementation only have circuit breaker, i.e. no full >>>> fledged congestion >>>>>> controller and uses ECN, they can in worst case drive the buffer >>>> into >>>> the overload >>>>>> regime where it starts dropping packets. =C3=A2=E2=82=AC=C5=BE >>>>>>>=20 >>>>>>> I=C3=A2=E2=82=AC=E2=84=A2m not sure about this case. ECN is an = input signal for >>>> congestion >>>> control. If you >>>>>> don=C3=A2=E2=82=AC=E2=84=A2t use congestion control but only a = circuit breaker, you >>>> should >>>> probably not >>>>>> enable ECN. At least it not clear to me why you would enable it, >> and >>>> it's definitely >>>>>> not conform to the ECN spec. Probably we should say something >> about >>>> this in the >>>>>> draft...? >>>>>>>=20 >>>>>> Agree, enabling ECN without a responsive CC is going to lead to >>>> trouble. >>>>>>=20 >>>>>>> Mirja >>>>>>>=20 >>>>>> Gorry >>>>>>=20 >>>>>>>> Am 17.06.2016 um 16:03 schrieb Black, David >> : >>>>>>>>=20 >>>>>>>> Colin, >>>>>>>>=20 >>>>>>>>>>> ... I view the current text as providing implementers with >> too >>>> much >>>>>>>>>>> latitude to ignore ECN-CE marks (e.g., because an = implementer >>>> doesn't >>>>>>>>>>> want to think about this problem space in the first place). >>>>>>>>>=20 >>>>>>>>> I agree, but the argument is that doing so is less harmful = than >>>> deploying a >>>>>> circuit >>>>>>>>> breaker that triggers too often when ECN is used. >>>>>>>>>=20 >>>>>>>>> I=C3=A2=E2=82=AC=E2=84=A2m not sure I believe this argument, = though, since it seems >>>> that >>>> any new >>>>>> AQM >>>>>>>>> that applies ECN marks much more often than at present will >> have >>>> to >>>>>> consider >>>>>>>>> backwards compatibility, to work with deployed TCP (e.g., >> draft- >>>> briscoe- >>>>>> tsvwg- >>>>>>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the >> new >>>> marking, >>>>>>>>> while existing implementations set ECT(0)). These = compatibility >>>> mechanisms >>>>>>>>> would seem to prevent the issues with the circuit breaker too. >>>>>>>>=20 >>>>>>>> That roughly matches my line of thinking, and I'll observe that >>>> the >>>> original >>>>>> DCTCP >>>>>>>> protocol design that used more aggressive ECN-CE marking was >> only >>>> safe for >>>>>>>> Controlled Environment deployments. See the TSVWG rfc5405bis >>>> draft for >>>>>> the >>>>>>>> definition of Controlled Environment, and ignore the fact that >> the >>>> rfc5405bis >>>>>>>> draft is a UDP draft - this definition is more broadly >> applicable. >>>>>>>>=20 >>>>>>>> Going back over Section 7 in this avtcore draft, my views are: >>>>>>>>=20 >>>>>>>> [A] None of these drafts justify a "MAY ignore" response to = ECN- >> CE >>>> marks: >>>>>>>> - draft-khademi-tcpm-alternativebackoff-ecn >>>>>>>> - draft-ietf-rmcat-nada >>>>>>>> - draft-ietf-rmcat-scream-cc >>>>>>>>=20 >>>>>>>> [B] In line with Colin's comment on the L4S draft, I think it's >>>> incumbent on >>>>>>>> the authors of draft-briscoe-aqm-dualq-coupled to figure out = how >>>> that will >>>>>>>> coexist (or avoid) deployed TCP, and this avtcore draft ought >> not >>>> to be >>>>>>>> trying to prejudge what will be done there. >>>>>>>>=20 >>>>>>>> So, I don't think the current text in Section 7 has justified >> the >>>> unfettered >>>>>>>> "implementations MAY ignore ECN-CE marks" text, as ignoring >> those >>>> marks >>>>>>>> is not consistent with any of the four cited drafts. >>>>>>>>=20 >>>>>>>> In more detail, I think making changes to normative = requirements >>>> here based >>>>>>>> on [B] is premature, and I would hope that the rmcat WG could = be >>>>>> encouraged >>>>>>>> to consider the RTP circuit breaker in its congestion control >>>> drafts, as those CC >>>>>>>> mechanisms are related to the circuit breaker mechanism, hence >>>> likely >>>>>>>> to be in related areas of an RTP implementation. >>>>>>>>=20 >>>>>>>> That leaves draft-khademi-tcpm-alternativebackoff-ecn, which >> TSVWG >>>>>>>> will be looking at in Berlin. If a normative statement about >> ECN- >>>> CE reaction >>>>>>>> is going to rest on that draft, then the reference to that = draft >>>> should be >>>>>>>> normative. Something about doing that strikes me as premature >> ... >>>>>>>>=20 >>>>>>>> I realize that we're trying to predict and accommodate the >> future, >>>> which >>>>>>>> is an imprecise undertaking at best. As an alternative to the >>>> current text, >>>>>>>> would it be reasonable to say (without any RFC 2119 keywords) >> that >>>> the >>>>>>>> best current guidance is still to treat ECN-CE marks as >> indicating >>>> drops, >>>>>>>> with a warning that there is a good possibility of this = changing >>>> in >>>> the >>>>>>>> near future due to all of the work in progress cited in Section >> 7? >>>>>>>>=20 >>>>>>>> Thanks, --David >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Colin Perkins [mailto:csp@csperkins.org] >>>>>>>>> Sent: Friday, June 17, 2016 6:14 AM >>>>>>>>> To: John Leslie; Black, David >>>>>>>>> Cc: rtcweb@ietf.org; IETF AVTCore WG; tsvwg >>>>>>>>> Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on >> changes: >>>> draft-ietf- >>>>>>>>> avtcore-rtp-circuit-breakers-16 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 16 Jun 2016, at 23:25, John Leslie wrote: >>>>>>>>>>=20 >>>>>>>>>> Black, David wrote: >>>>>>>>>>>=20 >>>>>>>>>>> ... I view the current text as providing implementers with >> too >>>> much >>>>>>>>>>> latitude to ignore ECN-CE marks (e.g., because an = implementer >>>> doesn't >>>>>>>>>>> want to think about this problem space in the first place). >>>>>>>>>=20 >>>>>>>>> I agree, but the argument is that doing so is less harmful = than >>>> deploying a >>>>>> circuit >>>>>>>>> breaker that triggers too often when ECN is used. >>>>>>>>>=20 >>>>>>>>> I=C3=A2=E2=82=AC=E2=84=A2m not sure I believe this argument, = though, since it seems >>>> that >>>> any new >>>>>> AQM >>>>>>>>> that applies ECN marks much more often than at present will >> have >>>> to >>>>>> consider >>>>>>>>> backwards compatibility, to work with deployed TCP (e.g., >> draft- >>>> briscoe- >>>>>> tsvwg- >>>>>>>>> aqm-tcpm-rmcat-l4s-problem uses ECT(1) as a signal to use the >> new >>>> marking, >>>>>>>>> while existing implementations set ECT(0)). These = compatibility >>>> mechanisms >>>>>>>>> would seem to prevent the issues with the circuit breaker too. >>>>>>>>>=20 >>>>>>>>>> Understand, we have at least two proposals to make ECN-CE = more >>>>>> frequent >>>>>>>>>> than packet drop would be for non-ECN packets: possibly >>>> substantially >>>>>>>>>> more frequent. Unless both are killed off, ECN-CE will show = up >>>> frequently >>>>>>>>>> enough that closing the flow on ECN-CE would kill too many >>>> connections. >>>>>>>>>>=20 >>>>>>>>>> If you want circuit-breaking on such connections, there are >> two >>>> ways: >>>>>>>>>> 1. convince the forwarding nodes to drop packets if their >> queue >>>> exceeds >>>>>>>>>> design capacity; or >>>>>>>>>> 2. require the sender to send enough not-ECN-capable packets >> so >>>> that our >>>>>>>>>> receiver will see enough packet-drops when a circuit-breaker >>>> should >>>>>>>>>> activate. >>>>>>>>>>=20 >>>>>>>>>> (I prefer the first option; but I wouldn't object to the >>>> second.) >>>>>>>>>>=20 >>>>>>>>>> There really isn't any way for our circuit-breaker to know >>>> _how_much_ >>>>>>>>>> more frequent the ECN-CE marks may be. :^( >>>>>>>>>=20 >>>>>>>>> This is a problem, both for the circuit breaker, and for the >>>> algorithms being >>>>>>>>> defined in RMCAT. We do need some understanding what the >> expected >>>>>> marking >>>>>>>>> rates are likely to be, so congestion control and circuit >>>> breakers >>>> can be >>>>>> defined. >>>>>>>>>=20 >>>>>>>>>> We _will_ be sorry if we >>>>>>>>>> allot the same frequency of CE packets as packet-drops to >>>> trigger >>>> the >>>>>>>>>> circuit-breaker. >>>>>>>>>>=20 >>>>>>>>>>> Could someone propose initial text to qualifies the current >>>> "MAY >>>> ignore" >>>>>>>>>>> statement? >>>>>>>>>>=20 >>>>>>>>>> Essentially, for the second option, you might propose text to >>>> the >>>>>>>>>> effect of: >>>>>>>>>> ] >>>>>>>>>> ] If too many ECN-CE packets are received, the sender SHOULD >>>> send >>>> some >>>>>>>>>> ] not-ECN-capable packets to determine whether enough packets >>>> along the >>>>>>>>>> ] path are being dropped to justify activating our circuit- >>>> breaker. >>>>>>>>>>=20 >>>>>>>>>> I=C3=A2=E2=82=AC=E2=84=A2m not enthusiastic about adding = that; but it would resolve >>>> the >>>> issue. >>>>>>>>>=20 >>>>>>>>> I=C3=A2=E2=82=AC=E2=84=A2m not convinced this would work. The = circuit breaker is >>>> looking >>>> at long term >>>>>>>>> trends, and in order to have enough not-ECT packets to >> determine >>>> if it >>>>>> should >>>>>>>>> trigger, you=C3=A2=E2=82=AC=E2=84=A2d essentially have to run = without ECN for some >>>> seconds. >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Colin Perkins >>>>>>>>> https://csperkins.org/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> rtcweb mailing list >>>>>>>> rtcweb@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>=20 >>>=20 >>>=20 >=20 From nobody Mon Jun 27 13:52:50 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54ADE12D8ED; Mon, 27 Jun 2016 13:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jlimzs4mdFc7; Mon, 27 Jun 2016 13:52:47 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBE812D906; Mon, 27 Jun 2016 13:52:45 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bHdWM-0005Li-Ji; Mon, 27 Jun 2016 22:52:42 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bHdWL-0001kS-Ua; Mon, 27 Jun 2016 22:52:42 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Mon, 27 Jun 2016 22:52:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> To: "Black, David" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 6 sum rcpts/h 21 sum msgs/h 8 total rcpts 43717 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EDE3784A2ED8A05C4E7D3F5B76F58C2CF9551B16 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 1462 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG , "De Schepper, Koen \(Nokia - BE\)" Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 20:52:49 -0000 David, > On 27. jun. 2016, at 22.09, Black, David wrote: >=20 >> As long as an AQM is marking at the same rate as dropping >=20 > That's an interesting assumption - it should be true for AQMs vetted > here in the past, but there are easy ways for it not to hold (e.g., if = dropping > or marking is based on queue occupancy, it is possible that dropping > reduces queue occupancy in a fashion that marking does not). >=20 > For ECN "classic" (i.e., see RFC 3168) where ECN-CE markings are = treated > as drop-equivalent, that is for congestion control purposes, which is = similar > to, (but not the same as) the throughput estimation usage for the RTP = circuit > breaker. I'll note that ECN "classic" was designed congestion = control > algorithms for react to ECN-CE marks once per RTT, independent of how > many ECN-CE marks are observed in an RTT. >=20 > Gorry wrote: >=20 >>> in this context we should use ECN to drive a CC algorithm and we = should be >>> cautious to avoid requiring its use within a Circuit Breaker - = optional >>> use, if you understand how to interpret a reaction to many CE-marks = as >>> excessive congestion, are permitted. >=20 > Something like that may be workable, starting with a clear distinction = between > the use of ECN by CC (routine, active at all times) and ECN by a = circuit > breaker (monitors for evidence that things have gotten bad, only = activated > when things get bad). This would baseline the RTP circuit breaker on = drops > and allow use of ECN as additional evidence of problems, in contrast = to > congestion control where ECN-CE is effectively treated as = drop-equivalent. >=20 > I'm not quite sure how to specify "use of ECN as additional evidence" = of > "excessive congestion" as drop-equivalence is about the best we have > for current guidance. I fail to parse that sentence, so maybe I=E2=80=99m getting you wrong, = but anyway I wonder: what=E2=80=99s even the point of this? Why even bother considering CE-marks as information for a circuit = breaker? CE-marks may *not* indicate *excessive* congestion - and since you say = =E2=80=9Cadditional evidence=E2=80=9D: I don=E2=80=99t think that a = combination of loss and CE-marks makes this any better? CE-marks may be = produced by a shallow queue, which can be rather =E2=80=9Cmild=E2=80=9D = congestion, at least in the light of what a circuit breaker should = consider=E2=80=A6 Cheers, Michael From nobody Mon Jun 27 15:02:35 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1499512D8B1; Mon, 27 Jun 2016 15:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c90lEi2M0KD5; Mon, 27 Jun 2016 15:02:30 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FE812D9B5; Mon, 27 Jun 2016 15:02:29 -0700 (PDT) Received: from [81.187.2.149] (port=39596 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bHebq-0004LA-92; Mon, 27 Jun 2016 23:02:26 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> Date: Mon, 27 Jun 2016 23:02:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "Black, David" , "De Schepper, Koen \(Nokia - BE\)" , "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 22:02:33 -0000 > On 27 Jun 2016, at 21:52, Michael Welzl wrote: >=20 > David, >=20 >=20 >> On 27. jun. 2016, at 22.09, Black, David wrote: >>=20 >>> As long as an AQM is marking at the same rate as dropping >>=20 >> That's an interesting assumption - it should be true for AQMs vetted >> here in the past, but there are easy ways for it not to hold (e.g., = if dropping >> or marking is based on queue occupancy, it is possible that dropping >> reduces queue occupancy in a fashion that marking does not). >>=20 >> For ECN "classic" (i.e., see RFC 3168) where ECN-CE markings are = treated >> as drop-equivalent, that is for congestion control purposes, which is = similar >> to, (but not the same as) the throughput estimation usage for the RTP = circuit >> breaker. I'll note that ECN "classic" was designed congestion = control >> algorithms for react to ECN-CE marks once per RTT, independent of how >> many ECN-CE marks are observed in an RTT. >>=20 >> Gorry wrote: >>=20 >>>> in this context we should use ECN to drive a CC algorithm and we = should be >>>> cautious to avoid requiring its use within a Circuit Breaker - = optional >>>> use, if you understand how to interpret a reaction to many CE-marks = as >>>> excessive congestion, are permitted. >>=20 >> Something like that may be workable, starting with a clear = distinction between >> the use of ECN by CC (routine, active at all times) and ECN by a = circuit >> breaker (monitors for evidence that things have gotten bad, only = activated >> when things get bad). This would baseline the RTP circuit breaker = on drops >> and allow use of ECN as additional evidence of problems, in contrast = to >> congestion control where ECN-CE is effectively treated as = drop-equivalent. >>=20 >> I'm not quite sure how to specify "use of ECN as additional evidence" = of >> "excessive congestion" as drop-equivalence is about the best we have >> for current guidance. >=20 > I fail to parse that sentence, so maybe I=E2=80=99m getting you wrong, = but anyway I wonder: what=E2=80=99s even the point of this? > Why even bother considering CE-marks as information for a circuit = breaker? Because the alternative is that we only break the circuit once the queue = has been driven into overflow, and packets have been lost. We want to = avoid that, since it causes latency, and too much latency is very bad = for the user experience.=20 > CE-marks may *not* indicate *excessive* congestion - and since you say = =E2=80=9Cadditional evidence=E2=80=9D: I don=E2=80=99t think that a = combination of loss and CE-marks makes this any better? CE-marks may be = produced by a shallow queue, which can be rather =E2=80=9Cmild=E2=80=9D = congestion, at least in the light of what a circuit breaker should = consider=E2=80=A6 Surely this is just arguing for a different threshold for a circuit = breaker triggered by ECN-CE marks (using a modern, small queue, AQM) = than for one triggered by loss (or ECN marks considered equivalent to = loss)?=20 If I understand the L4S proposal correctly, that would be treat ECN-CE = marks on ECT(0) marked flows as equivalent to loss, but treat ECN-CE = marks on ECT(1) marked flows with a (much) higher threshold.=20 Assuming, in all cases, that there=E2=80=99s a parallel congestion = control algorithm running (and RMCAT has figured out the right = congestion response for that; the proposals now treat ECN-CE and loss = very similarly). --=20 Colin Perkins https://csperkins.org/ From nobody Mon Jun 27 15:29:44 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3CA12DA1D; Mon, 27 Jun 2016 15:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srG2c0_PfgM8; Mon, 27 Jun 2016 15:29:32 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8382B12D9FB; Mon, 27 Jun 2016 15:29:32 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bHf21-0000OP-6Q; Tue, 28 Jun 2016 00:29:29 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bHf20-0005Rh-3B; Tue, 28 Jun 2016 00:29:29 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> Date: Tue, 28 Jun 2016 00:29:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 2 sum rcpts/h 21 sum msgs/h 6 total rcpts 43742 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5426A5020F93DC23462A308CEEEE1C860525310A X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1471 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "Black, David" , "De Schepper, Koen \(Nokia - BE\)" , "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 22:29:36 -0000 > On 28. jun. 2016, at 00.02, Colin Perkins wrote: >=20 >=20 >> On 27 Jun 2016, at 21:52, Michael Welzl wrote: >>=20 >> David, >>=20 >>=20 >>> On 27. jun. 2016, at 22.09, Black, David = wrote: >>>=20 >>>> As long as an AQM is marking at the same rate as dropping >>>=20 >>> That's an interesting assumption - it should be true for AQMs vetted >>> here in the past, but there are easy ways for it not to hold (e.g., = if dropping >>> or marking is based on queue occupancy, it is possible that dropping >>> reduces queue occupancy in a fashion that marking does not). >>>=20 >>> For ECN "classic" (i.e., see RFC 3168) where ECN-CE markings are = treated >>> as drop-equivalent, that is for congestion control purposes, which = is similar >>> to, (but not the same as) the throughput estimation usage for the = RTP circuit >>> breaker. I'll note that ECN "classic" was designed congestion = control >>> algorithms for react to ECN-CE marks once per RTT, independent of = how >>> many ECN-CE marks are observed in an RTT. >>>=20 >>> Gorry wrote: >>>=20 >>>>> in this context we should use ECN to drive a CC algorithm and we = should be >>>>> cautious to avoid requiring its use within a Circuit Breaker - = optional >>>>> use, if you understand how to interpret a reaction to many = CE-marks as >>>>> excessive congestion, are permitted. >>>=20 >>> Something like that may be workable, starting with a clear = distinction between >>> the use of ECN by CC (routine, active at all times) and ECN by a = circuit >>> breaker (monitors for evidence that things have gotten bad, only = activated >>> when things get bad). This would baseline the RTP circuit breaker = on drops >>> and allow use of ECN as additional evidence of problems, in contrast = to >>> congestion control where ECN-CE is effectively treated as = drop-equivalent. >>>=20 >>> I'm not quite sure how to specify "use of ECN as additional = evidence" of >>> "excessive congestion" as drop-equivalence is about the best we have >>> for current guidance. >>=20 >> I fail to parse that sentence, so maybe I=E2=80=99m getting you = wrong, but anyway I wonder: what=E2=80=99s even the point of this? >> Why even bother considering CE-marks as information for a circuit = breaker? >=20 > Because the alternative is that we only break the circuit once the = queue has been driven into overflow, and packets have been lost. We want = to avoid that, since it causes latency, and too much latency is very bad = for the user experience.=20 Well - the better way out would be for the application to react. Maybe = this is me misunderstanding the circuit breaker, but I did think it=E2=80=99= s more like a last resort=E2=80=A6 you just don=E2=80=99t want to be = trigger-happy with such a thing? >> CE-marks may *not* indicate *excessive* congestion - and since you = say =E2=80=9Cadditional evidence=E2=80=9D: I don=E2=80=99t think that a = combination of loss and CE-marks makes this any better? CE-marks may be = produced by a shallow queue, which can be rather =E2=80=9Cmild=E2=80=9D = congestion, at least in the light of what a circuit breaker should = consider=E2=80=A6 >=20 > Surely this is just arguing for a different threshold for a circuit = breaker triggered by ECN-CE marks (using a modern, small queue, AQM) = than for one triggered by loss (or ECN marks considered equivalent to = loss)?=20 If you have room for yet another code point, for the circuit breaker = only? :) Or maybe I just misunderstand you here? > If I understand the L4S proposal correctly, that would be treat ECN-CE = marks on ECT(0) marked flows as equivalent to loss, but treat ECN-CE = marks on ECT(1) marked flows with a (much) higher threshold.=20 L4S would not change anything about how ECT(0) marked flows are treated, = and would CE-mark packets carrying ECT(1) with an instantaneous queue - = i.e. a much *lower* threshold. But that=E2=80=99s not the issue - I = agree there=E2=80=99s no problem with L4S. The compatibility problem does exist with the ABE proposal, which works = off ECT(0). The ABE proposal exploits a very simple fact: that CE-marks are, by = definition, *not* the same as loss (see David Black=E2=80=99s previous = email where he says "if dropping or marking is based on queue occupancy, = it is possible that dropping reduces queue occupancy in a fashion that = marking does not=E2=80=9D). Indeed, queue dynamics play out differently = when packets are dropped or marked ( see Section 7 with Figures 13/14 = in = https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434= .pdf ) . Losses may stem from a DropTail (FIFO) queue somewhere along the path - = CE-marks are, however, very likely to only be caused by an AQM = algorithm. TCP=E2=80=99s built-in reaction to loss yields full link = utilization only when there=E2=80=99s at least a BDP worth of queuing. = This is a lot of latency - when the queue is full this doubles the RTT. = Modern AQM mechanisms strive to maintain a much smaller average queue = size, and this is where they mark packets. So: if we react to CE-marks the same way as to loss, CoDel and PIE let = us underutilize the link. Thus, it makes more sense to interpret the signal for what it is: an = indication that there was congestion, but from a queue that might be = much smaller than a BDP. > Assuming, in all cases, that there=E2=80=99s a parallel congestion = control algorithm running If you assume that there=E2=80=99s a parallel congestion control = algorithm running, I understand even less why you want to feed ECN = CE-marks into the circuit breaker. The congestion control algorithm = should already deal with them. =20 > (and RMCAT has figured out the right congestion response for that; the = proposals now treat ECN-CE and loss very similarly). I disagree that this is the =E2=80=9Cright=E2=80=9D congestion response. = It=E2=80=99s a workable one, sure. Nothing extremely terrible will = happen if congestion controllers treat ECN-CE and loss similarly - it = just yields unnecessarily poor utilization with ECN, with modern AQMs = (unless one backs off by less than TCP would in response to loss too, = which is good if there=E2=80=99s an AQM in place but may be quite bad = otherwise). Bottom line: it really does mean something different, and it seems wrong = to me to act as if that wasn=E2=80=99t the case - just because we=E2=80=99= ve always done so. Cheers, Michael From nobody Mon Jun 27 16:03:29 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD0612DA5E; Mon, 27 Jun 2016 16:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kkr2BdaOeAHY; Mon, 27 Jun 2016 16:03:21 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F7C12DA65; Mon, 27 Jun 2016 16:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3195; q=dns/txt; s=iport; t=1467068598; x=1468278198; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VAaZX0ROdLwNmX7qcO2RWkRfiRBl3ZH9DbVzO3DLVzc=; b=HQ39jH8Q2tK/fOOhZVqLnFCmA7m7/fxKzwcmXVHbsJ6+CW5mjyBY/fTj bhYZmTgRiVY/hVKsctB7A6KqLciDcR+lcN/AMlktbgd2XBGIscjaeo9fV e1TJ/szpGOoR81xaD6V7UO+XC9Rqy9/EVLDFQzN4tb7Yj8nfT/Oqcof5r c=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALBQB8sHFX/5ldJa1bgz6BUwa6J4F7h?= =?us-ascii?q?hgCgTI6EgEBAQEBAQFlJ4RNAQEEeRACAQgYLjIlAgQOBQ6IIsB2AQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEPDogfCIJOh2yCLwWZAQGDLYFsiR2PJI9+ASUCLYI7gTVui?= =?us-ascii?q?Hh/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,538,1459814400"; d="asc'?scan'208";a="290689781" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 23:03:04 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5RN34Uf012273 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 23:03:04 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 18:03:03 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 27 Jun 2016 18:03:03 -0500 From: "Fred Baker (fred)" To: John Leslie Thread-Topic: [tsvwg] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHR0MgPJk4Q/dpdG0yJgW1TNb0Iow== Date: Mon, 27 Jun 2016 23:03:03 +0000 Message-ID: References: <20160614135927.GE39331@verdi> In-Reply-To: <20160614135927.GE39331@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_CBB13F8A-4654-4CDB-8827-72DE6F3DD0E1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , IETF AVTCore WG , tsvwg Subject: Re: [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jun 2016 23:03:24 -0000 --Apple-Mail=_CBB13F8A-4654-4CDB-8827-72DE6F3DD0E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 14, 2016, at 6:59 AM, John Leslie wrote: > We must find a way to avoid ECN-CE triggering the congestion circuit > breaker when the forwarding node has not reached a level of congestion > which could trigger packet loss. I'm not sure I agree. I tend to think that ECN is relatively cheap - it asks the sender to = reduce its effective window but doesn't make him retransmit anything and = causes no delivery delay - while packet loss is relatively expensive in = that it makes the sender retransmit and introduces at least a one RTT = hiccup ( to detect and retransmit the lost packet) in the transmission = stream. Neither actually changes the rate at which anyone sends (we talk = about the signal asking the sender to slow down, but the rate = demonstrably doesn't actually change - we're asking the sender to not = pack the pipe so full). When ECN does ask someone to reduce their effective window, if they are = typically increasing it by one per RTT, ECN could very logically reduce = it by a small amount, such as two or three. If it reduced it by two, for = example, that would cause it to skip the next two transmission = opportunities (the next two received acknowledgements, which might = actually arrive in the same ack), and would be back to the same level = two RTTs later. If ECN is typically keeping the delay relatively = shallow, it is oscillating between "a little shallower" and " a little = less shallow". So it gets CE every other RTT? So what? If I'm dropping a = packet, or a couple of packets, every other RTT, we're going to see = notes on NANOG and other lists. "Your network's broken again. It's = dropping packets." I could be argued into setting the CE threshold a little lower than the = discard threshold. There are probably some mechanisms we'd do well to = explore, but... --Apple-Mail=_CBB13F8A-4654-4CDB-8827-72DE6F3DD0E1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV3Gwp0ayAOS/EQ8MAQIcWQ//RQ78ysjqgFND1AT6aIn+VwNBvFrqLoZG Qmco/8N7hN2JFKH+xLetplT6cFC266SeyxCepbuGh24J5WlUM5NlqtZlf09THS2E /k2ZRDWB5F7Z8FXAFB4TZSyUN02Iz9xr8qiMt3zB8l62F/AMeqhUE63RD9yrW4My oERvVSuqc4MoIvI5hkf7FLPTmK66tPs9bB4+R+XyI3NadhLphSfQG6MoNjk56Q3l AJg7EB2P7OY2hvf9nTqt0GYQDZCL1gmDPZmn2K2EPPuKy90ovQblr9UmNNJOoB+3 FyzZTMAghbdWCgNocB3dDHbeql2PBKDvsi9GiJDu8OxRXGgA5DFUNVFSPWQGaZky JvKN0pImScqr1ZJ+knUdUMfKd+wjIK1MdsAu9dugqQ79AEG/EhiAFezeNeGzQOqZ MN4kJXbLLKuCrKb2HTkTEIMZ1bDlNjT+EWWd9vsdciP7yBGzcAoImRbszagw7aTI VrA/b6tDlxFIv+BChR6tUwTz7Qr10vuhWtsMUPmL5Rn25Ry1/cQggJ/1YA6xQJSB u1ZMUvZAEe6MsHt2GK0CLG3lsg3ykCC3AFyYIU21ACdWBEJOuu/+VaCv9NxcpqjF dblrMlIS5xJAeZMIE+Pv3cOMhJ7fV5dnUcl2dGQh5mUYi3bnjm8/NruvCgAQUQ3x JzxkI2WVSYc= =mQAq -----END PGP SIGNATURE----- --Apple-Mail=_CBB13F8A-4654-4CDB-8827-72DE6F3DD0E1-- From nobody Mon Jun 27 17:04:15 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1EA12DAB6; Mon, 27 Jun 2016 17:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7YmQYi1tzAn; Mon, 27 Jun 2016 17:04:05 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3710412D7F8; Mon, 27 Jun 2016 17:04:05 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id ED3DBC9419; Mon, 27 Jun 2016 20:04:00 -0400 (EDT) Date: Mon, 27 Jun 2016 20:04:00 -0400 From: John Leslie To: Colin Perkins Message-ID: <20160628000400.GA1223@verdi> References: <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> User-Agent: Mutt/1.4.1i Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 00:04:07 -0000 Colin Perkins wrote: > On 27 Jun 2016, at 21:52, Michael Welzl wrote: > >> Why even bother considering CE-marks as information for a circuit breaker? > > Because the alternative is that we only break the circuit once the queue > has been driven into overflow, and packets have been lost. > We want to avoid that, since it causes latency, and too much latency is > very bad for the user experience. If you want a circuit-breaker to control latency, why aren't you measuring latency? -- John Leslie From nobody Mon Jun 27 17:10:50 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317AA12DAB7; Mon, 27 Jun 2016 17:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsFnzNQBIVOO; Mon, 27 Jun 2016 17:10:47 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F3012DAB5; Mon, 27 Jun 2016 17:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1999; q=dns/txt; s=iport; t=1467072647; x=1468282247; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nUh+eRUAkz0MKZNyoZ4kFaO+q0WnI3KbfwC+kI4poHk=; b=TVkZ3Tgo7puW1WfPQcGafjt3T+E7OU9dM/5LKdJBlpZRLvKfyTV7PkDV 9s1lXAD4pLHnGCzR3pq1VYOCS5/yDSWAziB6toITN2+CfXStJNsRCoTG0 W0EoO47OisFX+V4jUIs+TmaiWVJ1g/gsqVbFAk69sGEjB2QLTAlma8Ko1 g=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQD1v3FX/4oNJK1bgz6BUwa4G4IPg?= =?us-ascii?q?XuGGAKBMjgUAQEBAQEBAWUnhEwBAQEDAXkFCwIBCBguMiUCBA4FDogaCMEJAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDg6IHwiCTodsgi8FmQIBgy2BbIkfjySPfgEeN?= =?us-ascii?q?oI7gTVuiDF/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,538,1459814400"; d="asc'?scan'208";a="290630131" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2016 00:10:46 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u5S0AkAg003816 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jun 2016 00:10:46 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 19:10:45 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Mon, 27 Jun 2016 19:10:42 -0500 From: "Fred Baker (fred)" To: John Leslie Thread-Topic: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHR0NGCnW55W4e6ZUygJkpoCO5zfg== Date: Tue, 28 Jun 2016 00:10:42 +0000 Message-ID: References: <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <20160628000400.GA1223@verdi> In-Reply-To: <20160628000400.GA1223@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_17B46CEF-55F4-4DB9-806E-BB8961CAED68"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: IETF AVTCore WG , "rtcweb@ietf.org" , Colin Perkins , tsvwg Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 00:10:49 -0000 --Apple-Mail=_17B46CEF-55F4-4DB9-806E-BB8961CAED68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 27, 2016, at 5:04 PM, John Leslie wrote: >=20 > Colin Perkins wrote: >> On 27 Jun 2016, at 21:52, Michael Welzl wrote: >>=20 >>> Why even bother considering CE-marks as information for a circuit = breaker? >>=20 >> Because the alternative is that we only break the circuit once the = queue >> has been driven into overflow, and packets have been lost. >> We want to avoid that, since it causes latency, and too much latency = is >> very bad for the user experience. >=20 > If you want a circuit-breaker to control latency, why aren't you = measuring > latency? You mean, like CoDel? --Apple-Mail=_17B46CEF-55F4-4DB9-806E-BB8961CAED68 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV3HAgUayAOS/EQ8MAQISZA/+M9q0QehOZKM/YkHA3KqcEtDDEXf9IHyI L0qYVOk9f66FFlexKUMiQG5CXmMeLl5kERjSXDPdy3aUyjlNMEUMpn0/tHIwoUfW 6EI3RiypqxBdFDETYeYB0oOFs1j2UBxNpScWv3LhZH1JgWUsbudMaqCXYn4Yu0eK u7Rj0V9AwOCfTma3rjnSIb3lYmrvFmmsBHII+mZdmZ9+J4iWQVjelNYGXjb+Y23b F2sIofnvhIhZvlXF9YxTb1G0wktUjB9geifxW736Tp4dOl6Rt9uIe9wSWIwNk/QM eh3HwCqaE9VA2eZptyAZ47StPBu1FL0SgYEuJreHDF9JEEQnzH3hPc8LphwVyraT LokquZNze3pcsptIlp6OG1YeUPREdOIKgws3UHqc/mJwNg8iT9uqCgYdvu2eRQXO m/AUkKIgaYJ0KusKz8RJS08HaqpJFj340cINDkZ8nPYGZUGJUBPisncKADGYNsoU /m8QTTJOnnzUzRjdzfbamaCijE3f2Ua6uMXL6nSiXINA88uN41Ejllr3qVURARjF 16Fj3tpRB6J7pj1DJs6Is0/ajbm0JdaN2meeE+NsyUjIt2SbOV4nY4FB1lGoHXBL nui7Ckq04kHL7JLgN4m/CuJbkEyI6nyzCKiCL6Ye4RXI8mhXvfkndYFgjIqHmxBQ eNyzmCfEnI8= =uKDi -----END PGP SIGNATURE----- --Apple-Mail=_17B46CEF-55F4-4DB9-806E-BB8961CAED68-- From nobody Mon Jun 27 18:04:44 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0464412D7D1; Mon, 27 Jun 2016 18:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRgaliwB9gGn; Mon, 27 Jun 2016 18:04:33 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132B112D0AD; Mon, 27 Jun 2016 18:04:32 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5S14Rtp022619 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Jun 2016 21:04:27 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u5S14Rtp022619 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1467075868; bh=GP3mzO+j5XxOL31gZdB8kCQpKfo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EBNvq5m4lBjav/2/ABb1U1Mph3UR414wbwYGs9xoKYIdKz2N7hKMy5qX1t9B48tF/ XPMC8IyBaxDLYr8t3uO2nSoWtvkRO+pxxFdnliV9Gx25TBruawmEWsxncOHZp9/8EZ xAdHsnDr+zW0N+vv7PJNFFM2FamUjtaHf6sPqXsE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com u5S14Rtp022619 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 27 Jun 2016 21:03:52 -0400 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5S14C9f018610 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 27 Jun 2016 21:04:13 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Mon, 27 Jun 2016 21:04:12 -0400 From: "Black, David" To: Michael Welzl , Colin Perkins Thread-Topic: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHR0L+ZFj+KetGouEG7mSRAG7kvVJ/+KEcA///WaKA= Date: Tue, 28 Jun 2016 01:04:11 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 01:04:35 -0000 VHJ5aW5nIHRvIHNob3J0ZW4gdXAgdGhpcyB0aHJlYWQgYWdhaW4gLi4uDQoNCj4gPj4+IEknbSBu b3QgcXVpdGUgc3VyZSBob3cgdG8gc3BlY2lmeSAidXNlIG9mIEVDTiBhcyBhZGRpdGlvbmFsIGV2 aWRlbmNlIiBvZg0KPiA+Pj4gImV4Y2Vzc2l2ZSBjb25nZXN0aW9uIiBhcyBkcm9wLWVxdWl2YWxl bmNlIGlzIGFib3V0IHRoZSBiZXN0IHdlIGhhdmUNCj4gPj4+IGZvciBjdXJyZW50IGd1aWRhbmNl Lg0KPiA+Pg0KPiA+PiBJIGZhaWwgdG8gcGFyc2UgdGhhdCBzZW50ZW5jZSwgc28gbWF5YmUgSeKA mW0gZ2V0dGluZyB5b3Ugd3JvbmcsIGJ1dCBhbnl3YXkgSQ0KPiA+PiB3b25kZXI6IHdoYXTigJlz IGV2ZW4gdGhlIHBvaW50IG9mIHRoaXM/DQo+ID4+IFdoeSBldmVuIGJvdGhlciBjb25zaWRlcmlu ZyBDRS1tYXJrcyBhcyBpbmZvcm1hdGlvbiBmb3IgYSBjaXJjdWl0IGJyZWFrZXI/DQo+ID4NCj4g PiBCZWNhdXNlIHRoZSBhbHRlcm5hdGl2ZSBpcyB0aGF0IHdlIG9ubHkgYnJlYWsgdGhlIGNpcmN1 aXQgb25jZSB0aGUgcXVldWUgaGFzDQo+IGJlZW4gZHJpdmVuIGludG8gb3ZlcmZsb3csIGFuZCBw YWNrZXRzIGhhdmUgYmVlbiBsb3N0LiBXZSB3YW50IHRvIGF2b2lkIHRoYXQsDQo+IHNpbmNlIGl0 IGNhdXNlcyBsYXRlbmN5LCBhbmQgdG9vIG11Y2ggbGF0ZW5jeSBpcyB2ZXJ5IGJhZCBmb3IgdGhl IHVzZXIgZXhwZXJpZW5jZS4NCj4gDQo+IFdlbGwgLSB0aGUgYmV0dGVyIHdheSBvdXQgd291bGQg YmUgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byByZWFjdC4gTWF5YmUgdGhpcyBpcyBtZQ0KPiBtaXN1 bmRlcnN0YW5kaW5nIHRoZSBjaXJjdWl0IGJyZWFrZXIsIGJ1dCBJIGRpZCB0aGluayBpdOKAmXMg bW9yZSBsaWtlIGEgbGFzdCByZXNvcnTigKYNCj4geW91IGp1c3QgZG9u4oCZdCB3YW50IHRvIGJl IHRyaWdnZXItaGFwcHkgd2l0aCBzdWNoIGEgdGhpbmc/DQoNCldlbGwsIHRoZSBSVFAgY2lyY3Vp dCBicmVha2VyIGRyYWZ0IGlzIG5vdCB0cmlnZ2VyIGhhcHB5IC0gZm9yIGl0cyBjb25nZXN0aW9u IGNpcmN1aXQNCmJyZWFrZXIgdG8gdHJpcCwgUlRQIGhhcyB0byBiZSBzZW5kaW5nIGF0IDEweCB0 aGUgcmF0ZSB0aGF0IFRDUCB3b3VsZCBzZW5kIHVuZGVyDQp0aG9zZSBjb25kaXRpb25zLCBiYXNl ZCBvbiB0aGUgVENQIHRocm91Z2hwdXQgZXF1YXRpb24uICBTZWU6DQoNCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2dGNvcmUtcnRwLWNpcmN1aXQtYnJlYWtlcnMtMTYj c2VjdGlvbi00LjMNCg0KVGhlIGlzc3VlIGhlcmUgaXMgLSB3aGVuIGNhbGN1bGF0aW5nIHRoZSBj b21wYXJhYmxlIFRDUCB0aHJvdWdocHV0LCBob3cgYXJlIEVDTi1DRQ0KbWFya3MgdXNlZCB0byBk ZXRlcm1pbmUgdGhlIGxvc3MgcmF0ZSBpbnB1dCB0byB0aGUgVENQIHRocm91Z2hwdXQgZXF1YXRp b24/ICBEbw0KRUNOLUNFIG1hcmtlZCBwYWNrZXRzIGNvdW50IGFzIGhhdmluZyBhcnJpdmVkIG9y IGhhdmluZyBiZWVuIGRyb3BwZWQ/DQoNCldoZW4gdGhpbmdzIGFyZSByZWxhdGl2ZWx5IHN0YWJs ZSBhbmQgdGhlIEVDTi1DRSBtYXJrcyBhcmUgYmVpbmcgdXNlZCB0byBudWRnZQ0KdGhlIHNlbmRl cidzIHJhdGUgYmFzZWQgb24gd2hhdCB0aGUgbmV0d29yayBjYW4gYWJzb3JiLCB3aGV0aGVyIEVD Ti1DRSBtYXJrcw0KY291bnQgYXMgbG9zc2VzIG9yIG5vdCBpcyBwcm9iYWJseSBpbW1hdGVyaWFs IC0gdGhlIDEweCBkaXZlcmdlbmNlIGZyb20gdGhlIFRDUA0KdGhyb3VnaHB1dCBlcXVhdGlvbidz IHJhdGUgaXMgbm90IGdvaW5nIHRvIGFyaXNlLCBhbmQgdGhlIGNpcmN1aXQgYnJlYWtlciB3b24n dCB0cmlwLg0KVGhlIGNpcmN1aXQgYnJlYWtlciBpcyBvbmx5IHN1cHBvc2VkIHRvIHRyaXAgd2hl biB0aGluZ3MgYXJlIHNlcmlvdXNseSB3cm9uZy4NCg0KKDEpIElmIHRoZSBSVFAgY29uZ2VzdGlv biBjaXJjdWl0IGJyZWFrZXIgdHJpcHMgYmFzZWQgb24gRUNOLUNFIG1hcmtzIGFsb25lLA0Kc29t ZXRoaW5nIGZlZWxzIGludHVpdGl2ZWx5IHdyb25nIC0gaG93J2Qgd2UgZ2V0IHRvIFJUUCBydW5u aW5nIGF0IDEweCB0aGUNCmNvbXBhcmFibGUgVENQIHNlbmRpbmcgcmF0ZSB3aXRoIG5vIGxvc3Nl cz8gIFBlcmhhcHMgdGhlIGNpcmN1aXQgYnJlYWtlcg0Kc2hvdWxkbid0IHRyaXAgb24gRUNOLUNF IG1hcmtzIGFsb25lPw0KDQooMikgQXQgdGhlIG90aGVyIGV4dHJlbWUsIHRoZSBjb25nZXN0aW9u IGNpcmN1aXQgYnJlYWtlciBjbGVhcmx5IGhhcyB0byB0cmlwIGlmIFJUUA0KZ2V0cyB0byAxMHgg dGhlIGNvbXBhcmFibGUgVENQIHNlbmRpbmcgcmF0ZSBiYXNlZCBvbiBsb3NzZXMgYWxvbmUuICBU aGlzIGlzIHRoZQ0KYmFzZWxpbmUgZm9yIHRoZSBjaXJjdWl0IGJyZWFrZXIgdG8gcHJvdmlkZSBu ZXR3b3JrIHByb3RlY3Rpb24gYXMgaW50ZW5kZWQuDQoNClNvLCBnb2luZyBiYWNrIHRvIEdvcnJ5 J3Mgc3VnZ2VzdGlvbiB0byB1c2UgRUNOLUNFIG1hcmtzIGFzICJhZGRpdGlvbmFsIGV2aWRlbmNl LCINCmhlcmUncyBhIHN0cmF3IHByb3Bvc2FsIHRvIHNob290IGF0IC4uLiBmYWN0b3IgaW4gRUNO LUNFIG1hcmtzIGFzIGFkZGl0aW9uYWwgbG9zc2VzDQoqb25seSB3aGVuKiBsb3NzZXMgYXJlIGFs cmVhZHkgb2NjdXJyaW5nLiAgIA0KDQpGb3IgZXhhbXBsZSwgd2UgY291bGQgc3BlY2lmeSB0aGF0 IGZvciB0aGUgUlRQIGNvbmdlc3Rpb24gY2lyY3VpdCBicmVha2VyIHRvIHRyaXAsIHRoZQ0KUlRQ IHNlbmRpbmcgcmF0ZSBoYXMgdG8gYmU6DQoJLSAxMHggdGhlIGVxdWl2YWxlbnQgVENQIHNlbmRp bmcgcmF0ZSBiYXNlZCBvbiBjb3VudGluZyBFQ04tQ0UgbWFya2VkDQoJCXBhY2tldHMgYXMgbG9z dDsgQU5EDQoJLSAzeCB0aGUgZXF1aXZhbGVudCBzZW5kaW5nIHJhdGUgYmFzZWQgb24gYWN0dWFs IGRyb3BzIChpLmUuLCBjb3VudGluZw0KCQlFQ04tQ0UgbWFya2VkIHBhY2tldHMgYXMgZGVsaXZl cmVkKS4NClRoZSAiM3giIGFib3ZlIGlzIGFuIG9mZi10aGUtdG9wLW9mLW15LWhlYWQgZmFjdG9y IHRoYXQgYXR0ZW1wdHMgdG8gcm91Z2hseQ0KZXF1YWxseSB3ZWlnaHQgdGhlIGlucHV0cyAoMyBp cyBjbG9zZSB0byB0aGUgc3F1YXJlIHJvb3Qgb2YgMTApIC0gcGljayBhIGRpZmZlcmVudA0KbnVt YmVyIGlmIHRoYXQgd2VpZ2h0aW5nIGZlZWxzIHdyb25nLg0KDQpUaGlzIHdvdWxkIGZvcmNlIGRy b3BzIHRvIG9jY3VyIGFuZCB0aGVuIGNvbnNpZGVyIEVDTi1DRSBtYXJrcyBhcyBhZGRpdGlvbmFs IGV2aWRlbmNlDQp0aGF0IHNvbWV0aGluZyBpcyB3cm9uZyBpbiB0aGUgbmV0d29yay4NCg0KQW5v dGhlciBwb3NzaWJsZSByYXRpb25hbGUgZm9yIHRoaXMgbWl4aW5nIGlzIHRoYXQgaWYgZHJvcHMg c3RhcnQgb2NjdXJyaW5nLCB0aGVuIG1hbnkgb2YNCnRoZSBuZXcgYW5kIHByb3Bvc2VkIHVzZXMg b2YgRUNOIHRoYXQgdHJlYXQgRUNOLUNFIG1hcmtzIGFzIGxlc3MgdGhhbiBsb3NzLWVxdWl2YWxl bnQNCmFyZSBvdXRzaWRlIHRoZWlyIGludGVuZGVkIG9wZXJhdGluZyBlbnZlbG9wZXMvcmVnaW9u cy4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCg== From nobody Tue Jun 28 14:48:36 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8E712D537; Tue, 28 Jun 2016 14:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR5EcQJGV8RU; Tue, 28 Jun 2016 14:48:28 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B9412D1D2; Tue, 28 Jun 2016 14:48:28 -0700 (PDT) Received: from [81.187.2.149] (port=37071 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bI0ro-0005cG-G5; Tue, 28 Jun 2016 22:48:25 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <20160628000400.GA1223@verdi> Date: Tue, 28 Jun 2016 22:48:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <20160628000400.GA1223@verdi> To: John Leslie X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 21:48:31 -0000 > On 28 Jun 2016, at 01:04, John Leslie wrote: > Colin Perkins wrote: >> On 27 Jun 2016, at 21:52, Michael Welzl wrote: >>=20 >>> Why even bother considering CE-marks as information for a circuit = breaker? >>=20 >> Because the alternative is that we only break the circuit once the = queue >> has been driven into overflow, and packets have been lost. >> We want to avoid that, since it causes latency, and too much latency = is >> very bad for the user experience.=20 >=20 > If you want a circuit-breaker to control latency, why aren't you = measuring > latency? Because the RTP circuit breaker needs to work with unmodified RFC = 3550-style RTCP, which doesn=E2=80=99t return RTT samples sufficiently = often to allow that, and because we don=E2=80=99t care about the precise = latency, we just don=E2=80=99t want to fill a large queue. --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jun 28 15:03:03 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25D012D83A; Tue, 28 Jun 2016 15:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoulhWdapYVq; Tue, 28 Jun 2016 15:02:59 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3863E12D790; Tue, 28 Jun 2016 15:02:58 -0700 (PDT) Received: from [81.187.2.149] (port=47431 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bI15q-0007Ir-IC; Tue, 28 Jun 2016 23:02:55 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Tue, 28 Jun 2016 23:02:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> To: "Black, David" X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 22:03:03 -0000 > On 28 Jun 2016, at 02:04, Black, David wrote: >=20 > Trying to shorten up this thread again ... >=20 >>>>> I'm not quite sure how to specify "use of ECN as additional = evidence" of >>>>> "excessive congestion" as drop-equivalence is about the best we = have >>>>> for current guidance. >>>>=20 >>>> I fail to parse that sentence, so maybe I=E2=80=99m getting you = wrong, but anyway I >>>> wonder: what=E2=80=99s even the point of this? >>>> Why even bother considering CE-marks as information for a circuit = breaker? >>>=20 >>> Because the alternative is that we only break the circuit once the = queue has >> been driven into overflow, and packets have been lost. We want to = avoid that, >> since it causes latency, and too much latency is very bad for the = user experience. >>=20 >> Well - the better way out would be for the application to react. = Maybe this is me >> misunderstanding the circuit breaker, but I did think it=E2=80=99s = more like a last resort=E2=80=A6 >> you just don=E2=80=99t want to be trigger-happy with such a thing? >=20 > Well, the RTP circuit breaker draft is not trigger happy - for its = congestion circuit > breaker to trip, RTP has to be sending at 10x the rate that TCP would = send under > those conditions, based on the TCP throughput equation. See: >=20 > = https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16#sec= tion-4.3 >=20 > The issue here is - when calculating the comparable TCP throughput, = how are ECN-CE > marks used to determine the loss rate input to the TCP throughput = equation? Do > ECN-CE marked packets count as having arrived or having been dropped? Right - or do they count somewhere between the two. > When things are relatively stable and the ECN-CE marks are being used = to nudge > the sender's rate based on what the network can absorb, whether ECN-CE = marks > count as losses or not is probably immaterial - the 10x divergence = from the TCP > throughput equation's rate is not going to arise, and the circuit = breaker won't trip. > The circuit breaker is only supposed to trip when things are seriously = wrong. Correct. > (1) If the RTP congestion circuit breaker trips based on ECN-CE marks = alone, > something feels intuitively wrong - how'd we get to RTP running at 10x = the > comparable TCP sending rate with no losses? Perhaps the circuit = breaker > shouldn=E2=80=99t trip on ECN-CE marks alone? Shouldn=E2=80=99t the comparable rate to trigger the circuit breaker be = 10x that given to a TCP flow subject to the same ECN-CE marking rate? If = the TCP treats ECN-CE as equivalent to loss, for congestion response, = then the circuit breaker should do so to, etc. > (2) At the other extreme, the congestion circuit breaker clearly has = to trip if RTP > gets to 10x the comparable TCP sending rate based on losses alone. = This is the > baseline for the circuit breaker to provide network protection as = intended. >=20 > So, going back to Gorry's suggestion to use ECN-CE marks as = "additional evidence," > here's a straw proposal to shoot at ... factor in ECN-CE marks as = additional losses > *only when* losses are already occurring. =20 >=20 > For example, we could specify that for the RTP congestion circuit = breaker to trip, the > RTP sending rate has to be: > - 10x the equivalent TCP sending rate based on counting ECN-CE = marked > packets as lost; AND > - 3x the equivalent sending rate based on actual drops (i.e., = counting > ECN-CE marked packets as delivered). > The "3x" above is an off-the-top-of-my-head factor that attempts to = roughly > equally weight the inputs (3 is close to the square root of 10) - pick = a different > number if that weighting feels wrong. >=20 > This would force drops to occur and then consider ECN-CE marks as = additional evidence > that something is wrong in the network. >=20 > Another possible rationale for this mixing is that if drops start = occurring, then many of > the new and proposed uses of ECN that treat ECN-CE marks as less than = loss-equivalent > are outside their intended operating envelopes/regions. Clearly if the queue has been driven to overflow, so that packet loss is = occurring, then the AQM is outside its intended operating regime. I=E2=80=99= m not sure we need to push it so far, though. Is there not a regime = where the ECN-CE marking rate indicates excessive congestion, before the = queue overflows and drops packets?=20 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jun 28 23:50:18 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27C612D7F0; Tue, 28 Jun 2016 23:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDc-Wk1J3f79; Tue, 28 Jun 2016 23:50:14 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C999212B009; Tue, 28 Jun 2016 23:50:11 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 29 Jun 2016 08:50:09 +0200 X-IronPort-AV: E=Sophos;i="5.26,545,1459807200"; d="scan'208";a="909211051" Received: from he101654.emea1.cds.t-internal.com ([10.134.226.15]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2016 08:50:08 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101654.emea1.cds.t-internal.com (10.134.226.15) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 29 Jun 2016 08:50:16 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1178.000; Wed, 29 Jun 2016 08:50:08 +0200 From: To: , Thread-Topic: [tsvwg] [AVTCORE] [rtcweb] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHR0YjOJ/Ww8HzxYEqxGgZcc0m8Op//+RNA Date: Wed, 29 Jun 2016 06:50:08 +0000 Message-ID: <577acdb4599440439f92480c9875fba6@HE101653.emea1.cds.t-internal.com> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> In-Reply-To: <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.170.182] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: rtcweb@ietf.org, tsvwg@ietf.org, avt@ietf.org Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 06:50:17 -0000 Q29saW4sIERhdmlkLA0KDQpJIGRvbid0IGludGVuZCB0byBiZSBkaXN0dXJiaW5nLiBJcyB0aGVy ZSBhIHN0YW5kYXJkcyB0cmFjayBSRkMgaW5kaWNhdGluZyBob3cgYSByb3V0ZXIgc2hvdWxkIGJl IGNvbmZpZ3VyZWQgdG8gc3VwcG9ydCBFQ04gbWFya2luZyBzbyB0aGF0IHRoZXJlIGlzIGEgbmV0 d29yayBiZWhhdmlvciBieSB3aGljaCBhbiBlbmQgc3lzdGVtIGlzIGFibGUgdG8gcmVsYXRlIEVD TiBtYXJraW5nIHJhdGVzIHVuYW1iaWd1b3VzbHkgdG8gZHJvcCByYXRlcyBpbiB0aGUgbmV0d29y ayAoYXNzdW1pbmcgYm90aCB0byBiZSBjYXVzZWQgYnkgdGhlIHNhbWUgYm90dGxlbmVjayk/DQoN CkkgZG9uJ3QgbmVlZCBhbiBSRkMgbnVtYmVyLCAieWVzIiBvciAibm8iIHdpbGwgZG8uIFRoZSBS RkMgc2hvdWxkIGJlIGNsZWFyIGVub3VnaCB0byBhbGxvdyBhbnkgdGVybWluYWwgdG8gaW50ZXJw cmV0IHRoZSBFQ04gc2lnbmFscyBjb3JyZWN0bHksIG5vIG1hdHRlciB0byB3aGljaCBFQ04gc3Vw cG9ydGluZyBuZXR3b3JrIGl0IGNvbm5lY3RzLiANCg0KUmVnYXJkcywNCg0KUnVlZGlnZXINCg0K DQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IHRzdndnIFttYWlsdG86 dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQ29saW4gUGVya2lucw0KR2Vz ZW5kZXQ6IE1pdHR3b2NoLCAyOS4gSnVuaSAyMDE2IDAwOjAzDQpBbjogQmxhY2ssIERhdmlkDQpD YzogcnRjd2ViQGlldGYub3JnOyB0c3Z3ZzsgTWljaGFlbCBXZWx6bDsgSUVURiBBVlRDb3JlIFdH DQpCZXRyZWZmOiBSZTogW3RzdndnXSBbQVZUQ09SRV0gW3J0Y3dlYl0gV0cgTGFzdCBDYWxsIG9u IGNoYW5nZXM6IGRyYWZ0LWlldGYtYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KDQoN Cj4gT24gMjggSnVuIDIwMTYsIGF0IDAyOjA0LCBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVt Yy5jb20+IHdyb3RlOg0KPiANCj4gVHJ5aW5nIHRvIHNob3J0ZW4gdXAgdGhpcyB0aHJlYWQgYWdh aW4gLi4uDQo+IA0KPj4+Pj4gSSdtIG5vdCBxdWl0ZSBzdXJlIGhvdyB0byBzcGVjaWZ5ICJ1c2Ug b2YgRUNOIGFzIGFkZGl0aW9uYWwgDQo+Pj4+PiBldmlkZW5jZSIgb2YgImV4Y2Vzc2l2ZSBjb25n ZXN0aW9uIiBhcyBkcm9wLWVxdWl2YWxlbmNlIGlzIGFib3V0IA0KPj4+Pj4gdGhlIGJlc3Qgd2Ug aGF2ZSBmb3IgY3VycmVudCBndWlkYW5jZS4NCj4+Pj4gDQo+Pj4+IEkgZmFpbCB0byBwYXJzZSB0 aGF0IHNlbnRlbmNlLCBzbyBtYXliZSBJ4oCZbSBnZXR0aW5nIHlvdSB3cm9uZywgYnV0IA0KPj4+ PiBhbnl3YXkgSQ0KPj4+PiB3b25kZXI6IHdoYXTigJlzIGV2ZW4gdGhlIHBvaW50IG9mIHRoaXM/ DQo+Pj4+IFdoeSBldmVuIGJvdGhlciBjb25zaWRlcmluZyBDRS1tYXJrcyBhcyBpbmZvcm1hdGlv biBmb3IgYSBjaXJjdWl0IGJyZWFrZXI/DQo+Pj4gDQo+Pj4gQmVjYXVzZSB0aGUgYWx0ZXJuYXRp dmUgaXMgdGhhdCB3ZSBvbmx5IGJyZWFrIHRoZSBjaXJjdWl0IG9uY2UgdGhlIA0KPj4+IHF1ZXVl IGhhcw0KPj4gYmVlbiBkcml2ZW4gaW50byBvdmVyZmxvdywgYW5kIHBhY2tldHMgaGF2ZSBiZWVu IGxvc3QuIFdlIHdhbnQgdG8gDQo+PiBhdm9pZCB0aGF0LCBzaW5jZSBpdCBjYXVzZXMgbGF0ZW5j eSwgYW5kIHRvbyBtdWNoIGxhdGVuY3kgaXMgdmVyeSBiYWQgZm9yIHRoZSB1c2VyIGV4cGVyaWVu Y2UuDQo+PiANCj4+IFdlbGwgLSB0aGUgYmV0dGVyIHdheSBvdXQgd291bGQgYmUgZm9yIHRoZSBh cHBsaWNhdGlvbiB0byByZWFjdC4gDQo+PiBNYXliZSB0aGlzIGlzIG1lIG1pc3VuZGVyc3RhbmRp bmcgdGhlIGNpcmN1aXQgYnJlYWtlciwgYnV0IEkgZGlkIA0KPj4gdGhpbmsgaXTigJlzIG1vcmUg bGlrZSBhIGxhc3QgcmVzb3J04oCmIHlvdSBqdXN0IGRvbuKAmXQgd2FudCB0byBiZSB0cmlnZ2Vy LWhhcHB5IHdpdGggc3VjaCBhIHRoaW5nPw0KPiANCj4gV2VsbCwgdGhlIFJUUCBjaXJjdWl0IGJy ZWFrZXIgZHJhZnQgaXMgbm90IHRyaWdnZXIgaGFwcHkgLSBmb3IgaXRzIA0KPiBjb25nZXN0aW9u IGNpcmN1aXQgYnJlYWtlciB0byB0cmlwLCBSVFAgaGFzIHRvIGJlIHNlbmRpbmcgYXQgMTB4IHRo ZSANCj4gcmF0ZSB0aGF0IFRDUCB3b3VsZCBzZW5kIHVuZGVyIHRob3NlIGNvbmRpdGlvbnMsIGJh c2VkIG9uIHRoZSBUQ1AgdGhyb3VnaHB1dCBlcXVhdGlvbi4gIFNlZToNCj4gDQo+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2dGNvcmUtcnRwLWNpcmN1aXQtYnJlYWtl cnMtMTYNCj4gI3NlY3Rpb24tNC4zDQo+IA0KPiBUaGUgaXNzdWUgaGVyZSBpcyAtIHdoZW4gY2Fs Y3VsYXRpbmcgdGhlIGNvbXBhcmFibGUgVENQIHRocm91Z2hwdXQsIA0KPiBob3cgYXJlIEVDTi1D RSBtYXJrcyB1c2VkIHRvIGRldGVybWluZSB0aGUgbG9zcyByYXRlIGlucHV0IHRvIHRoZSBUQ1Ag DQo+IHRocm91Z2hwdXQgZXF1YXRpb24/ICBEbyBFQ04tQ0UgbWFya2VkIHBhY2tldHMgY291bnQg YXMgaGF2aW5nIGFycml2ZWQgb3IgaGF2aW5nIGJlZW4gZHJvcHBlZD8NCg0KUmlnaHQgLSBvciBk byB0aGV5IGNvdW50IHNvbWV3aGVyZSBiZXR3ZWVuIHRoZSB0d28uDQoNCj4gV2hlbiB0aGluZ3Mg YXJlIHJlbGF0aXZlbHkgc3RhYmxlIGFuZCB0aGUgRUNOLUNFIG1hcmtzIGFyZSBiZWluZyB1c2Vk IA0KPiB0byBudWRnZSB0aGUgc2VuZGVyJ3MgcmF0ZSBiYXNlZCBvbiB3aGF0IHRoZSBuZXR3b3Jr IGNhbiBhYnNvcmIsIA0KPiB3aGV0aGVyIEVDTi1DRSBtYXJrcyBjb3VudCBhcyBsb3NzZXMgb3Ig bm90IGlzIHByb2JhYmx5IGltbWF0ZXJpYWwgLSANCj4gdGhlIDEweCBkaXZlcmdlbmNlIGZyb20g dGhlIFRDUCB0aHJvdWdocHV0IGVxdWF0aW9uJ3MgcmF0ZSBpcyBub3QgZ29pbmcgdG8gYXJpc2Us IGFuZCB0aGUgY2lyY3VpdCBicmVha2VyIHdvbid0IHRyaXAuDQo+IFRoZSBjaXJjdWl0IGJyZWFr ZXIgaXMgb25seSBzdXBwb3NlZCB0byB0cmlwIHdoZW4gdGhpbmdzIGFyZSBzZXJpb3VzbHkgd3Jv bmcuDQoNCkNvcnJlY3QuDQoNCj4gKDEpIElmIHRoZSBSVFAgY29uZ2VzdGlvbiBjaXJjdWl0IGJy ZWFrZXIgdHJpcHMgYmFzZWQgb24gRUNOLUNFIG1hcmtzIA0KPiBhbG9uZSwgc29tZXRoaW5nIGZl ZWxzIGludHVpdGl2ZWx5IHdyb25nIC0gaG93J2Qgd2UgZ2V0IHRvIFJUUCBydW5uaW5nIA0KPiBh dCAxMHggdGhlIGNvbXBhcmFibGUgVENQIHNlbmRpbmcgcmF0ZSB3aXRoIG5vIGxvc3Nlcz8gIFBl cmhhcHMgdGhlIA0KPiBjaXJjdWl0IGJyZWFrZXIgc2hvdWxkbuKAmXQgdHJpcCBvbiBFQ04tQ0Ug bWFya3MgYWxvbmU/DQoNClNob3VsZG7igJl0IHRoZSBjb21wYXJhYmxlIHJhdGUgdG8gdHJpZ2dl ciB0aGUgY2lyY3VpdCBicmVha2VyIGJlIDEweCB0aGF0IGdpdmVuIHRvIGEgVENQIGZsb3cgc3Vi amVjdCB0byB0aGUgc2FtZSBFQ04tQ0UgbWFya2luZyByYXRlPyBJZiB0aGUgVENQIHRyZWF0cyBF Q04tQ0UgYXMgZXF1aXZhbGVudCB0byBsb3NzLCBmb3IgY29uZ2VzdGlvbiByZXNwb25zZSwgdGhl biB0aGUgY2lyY3VpdCBicmVha2VyIHNob3VsZCBkbyBzbyB0bywgZXRjLg0KDQo+ICgyKSBBdCB0 aGUgb3RoZXIgZXh0cmVtZSwgdGhlIGNvbmdlc3Rpb24gY2lyY3VpdCBicmVha2VyIGNsZWFybHkg aGFzIA0KPiB0byB0cmlwIGlmIFJUUCBnZXRzIHRvIDEweCB0aGUgY29tcGFyYWJsZSBUQ1Agc2Vu ZGluZyByYXRlIGJhc2VkIG9uIA0KPiBsb3NzZXMgYWxvbmUuICBUaGlzIGlzIHRoZSBiYXNlbGlu ZSBmb3IgdGhlIGNpcmN1aXQgYnJlYWtlciB0byBwcm92aWRlIG5ldHdvcmsgcHJvdGVjdGlvbiBh cyBpbnRlbmRlZC4NCj4gDQo+IFNvLCBnb2luZyBiYWNrIHRvIEdvcnJ5J3Mgc3VnZ2VzdGlvbiB0 byB1c2UgRUNOLUNFIG1hcmtzIGFzICJhZGRpdGlvbmFsIGV2aWRlbmNlLCINCj4gaGVyZSdzIGEg c3RyYXcgcHJvcG9zYWwgdG8gc2hvb3QgYXQgLi4uIGZhY3RvciBpbiBFQ04tQ0UgbWFya3MgYXMg YWRkaXRpb25hbCBsb3NzZXMNCj4gKm9ubHkgd2hlbiogbG9zc2VzIGFyZSBhbHJlYWR5IG9jY3Vy cmluZy4gICANCj4gDQo+IEZvciBleGFtcGxlLCB3ZSBjb3VsZCBzcGVjaWZ5IHRoYXQgZm9yIHRo ZSBSVFAgY29uZ2VzdGlvbiBjaXJjdWl0IA0KPiBicmVha2VyIHRvIHRyaXAsIHRoZSBSVFAgc2Vu ZGluZyByYXRlIGhhcyB0byBiZToNCj4gCS0gMTB4IHRoZSBlcXVpdmFsZW50IFRDUCBzZW5kaW5n IHJhdGUgYmFzZWQgb24gY291bnRpbmcgRUNOLUNFIG1hcmtlZA0KPiAJCXBhY2tldHMgYXMgbG9z dDsgQU5EDQo+IAktIDN4IHRoZSBlcXVpdmFsZW50IHNlbmRpbmcgcmF0ZSBiYXNlZCBvbiBhY3R1 YWwgZHJvcHMgKGkuZS4sIGNvdW50aW5nDQo+IAkJRUNOLUNFIG1hcmtlZCBwYWNrZXRzIGFzIGRl bGl2ZXJlZCkuDQo+IFRoZSAiM3giIGFib3ZlIGlzIGFuIG9mZi10aGUtdG9wLW9mLW15LWhlYWQg ZmFjdG9yIHRoYXQgYXR0ZW1wdHMgdG8gDQo+IHJvdWdobHkgZXF1YWxseSB3ZWlnaHQgdGhlIGlu cHV0cyAoMyBpcyBjbG9zZSB0byB0aGUgc3F1YXJlIHJvb3Qgb2YgDQo+IDEwKSAtIHBpY2sgYSBk aWZmZXJlbnQgbnVtYmVyIGlmIHRoYXQgd2VpZ2h0aW5nIGZlZWxzIHdyb25nLg0KPiANCj4gVGhp cyB3b3VsZCBmb3JjZSBkcm9wcyB0byBvY2N1ciBhbmQgdGhlbiBjb25zaWRlciBFQ04tQ0UgbWFy a3MgYXMgDQo+IGFkZGl0aW9uYWwgZXZpZGVuY2UgdGhhdCBzb21ldGhpbmcgaXMgd3JvbmcgaW4g dGhlIG5ldHdvcmsuDQo+IA0KPiBBbm90aGVyIHBvc3NpYmxlIHJhdGlvbmFsZSBmb3IgdGhpcyBt aXhpbmcgaXMgdGhhdCBpZiBkcm9wcyBzdGFydCANCj4gb2NjdXJyaW5nLCB0aGVuIG1hbnkgb2Yg dGhlIG5ldyBhbmQgcHJvcG9zZWQgdXNlcyBvZiBFQ04gdGhhdCB0cmVhdCANCj4gRUNOLUNFIG1h cmtzIGFzIGxlc3MgdGhhbiBsb3NzLWVxdWl2YWxlbnQgYXJlIG91dHNpZGUgdGhlaXIgaW50ZW5k ZWQgb3BlcmF0aW5nIGVudmVsb3Blcy9yZWdpb25zLg0KDQpDbGVhcmx5IGlmIHRoZSBxdWV1ZSBo YXMgYmVlbiBkcml2ZW4gdG8gb3ZlcmZsb3csIHNvIHRoYXQgcGFja2V0IGxvc3MgaXMgb2NjdXJy aW5nLCB0aGVuIHRoZSBBUU0gaXMgb3V0c2lkZSBpdHMgaW50ZW5kZWQgb3BlcmF0aW5nIHJlZ2lt ZS4gSeKAmW0gbm90IHN1cmUgd2UgbmVlZCB0byBwdXNoIGl0IHNvIGZhciwgdGhvdWdoLiBJcyB0 aGVyZSBub3QgYSByZWdpbWUgd2hlcmUgdGhlIEVDTi1DRSBtYXJraW5nIHJhdGUgaW5kaWNhdGVz IGV4Y2Vzc2l2ZSBjb25nZXN0aW9uLCBiZWZvcmUgdGhlIHF1ZXVlIG92ZXJmbG93cyBhbmQgZHJv cHMgcGFja2V0cz8gDQoNCi0tDQpDb2xpbiBQZXJraW5zDQpodHRwczovL2NzcGVya2lucy5vcmcv DQoNCg0KDQoNCg== From nobody Wed Jun 29 01:54:50 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDDF12D178; Wed, 29 Jun 2016 01:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fggf8ucP1sw6; Wed, 29 Jun 2016 01:54:40 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A0512DA5B; Wed, 29 Jun 2016 01:54:40 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bIBGV-0005qd-UY; Wed, 29 Jun 2016 10:54:35 +0200 Received: from 1x-193-157-240-251.uio.no ([193.157.240.251]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bIBGV-0007N9-7B; Wed, 29 Jun 2016 10:54:35 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> Date: Wed, 29 Jun 2016 10:54:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 3 sum rcpts/h 11 sum msgs/h 5 total rcpts 43797 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-2.138, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 987467064C5EE9518D5076116F92D0BC8280545D X-UiO-SPAM-Test: remote_host: 193.157.240.251 spam_score: -70 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 117 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 08:54:44 -0000 > On 29. jun. 2016, at 00.02, Colin Perkins wrote: >=20 >=20 >> On 28 Jun 2016, at 02:04, Black, David wrote: >>=20 >> Trying to shorten up this thread again ... >>=20 >>>>>> I'm not quite sure how to specify "use of ECN as additional = evidence" of >>>>>> "excessive congestion" as drop-equivalence is about the best we = have >>>>>> for current guidance. >>>>>=20 >>>>> I fail to parse that sentence, so maybe I=E2=80=99m getting you = wrong, but anyway I >>>>> wonder: what=E2=80=99s even the point of this? >>>>> Why even bother considering CE-marks as information for a circuit = breaker? >>>>=20 >>>> Because the alternative is that we only break the circuit once the = queue has >>> been driven into overflow, and packets have been lost. We want to = avoid that, >>> since it causes latency, and too much latency is very bad for the = user experience. >>>=20 >>> Well - the better way out would be for the application to react. = Maybe this is me >>> misunderstanding the circuit breaker, but I did think it=E2=80=99s = more like a last resort=E2=80=A6 >>> you just don=E2=80=99t want to be trigger-happy with such a thing? >>=20 >> Well, the RTP circuit breaker draft is not trigger happy - for its = congestion circuit >> breaker to trip, RTP has to be sending at 10x the rate that TCP would = send under >> those conditions, based on the TCP throughput equation. See: >>=20 >> = https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16#sec= tion-4.3 >>=20 >> The issue here is - when calculating the comparable TCP throughput, = how are ECN-CE >> marks used to determine the loss rate input to the TCP throughput = equation? Do >> ECN-CE marked packets count as having arrived or having been dropped? >=20 > Right - or do they count somewhere between the two. Let=E2=80=99s see them clearly for what they are. They mean: the path is *not* broken (they have arrived!), and a probably = an AQM mechanism, potentially using a shallow queue, marked them to = indicate congestion. I think =E2=80=9Csomewhere between the two=E2=80=9D = really doesn=E2=80=99t capture this well. >> When things are relatively stable and the ECN-CE marks are being used = to nudge >> the sender's rate based on what the network can absorb, whether = ECN-CE marks >> count as losses or not is probably immaterial - the 10x divergence = from the TCP >> throughput equation's rate is not going to arise, and the circuit = breaker won't trip. >> The circuit breaker is only supposed to trip when things are = seriously wrong. >=20 > Correct. >=20 >> (1) If the RTP congestion circuit breaker trips based on ECN-CE marks = alone, >> something feels intuitively wrong - how'd we get to RTP running at = 10x the >> comparable TCP sending rate with no losses? Perhaps the circuit = breaker >> shouldn=E2=80=99t trip on ECN-CE marks alone? >=20 > Shouldn=E2=80=99t the comparable rate to trigger the circuit breaker = be 10x that given to a TCP flow subject to the same ECN-CE marking rate? = If the TCP treats ECN-CE as equivalent to loss, for congestion response, = then the circuit breaker should do so to, etc. First, TCP shouldn=E2=80=99t (treat ECN-CE as equivalent to loss), and = so the circuit breaker shouldn=E2=80=99t. Second, I guess you=E2=80=99re talking about the equation. Well that = goes completely wrong anyway (the derivation assumes packets to be lost, = not marked; then again, you=E2=80=99re using loss, not the loss event = ratio; then again, you=E2=80=99re close to this with ECN perhaps, using = =E2=80=9Ctraditional=E2=80=9D ECN receiver behavior). >> (2) At the other extreme, the congestion circuit breaker clearly has = to trip if RTP >> gets to 10x the comparable TCP sending rate based on losses alone. = This is the >> baseline for the circuit breaker to provide network protection as = intended. >>=20 >> So, going back to Gorry's suggestion to use ECN-CE marks as = "additional evidence," >> here's a straw proposal to shoot at ... factor in ECN-CE marks as = additional losses >> *only when* losses are already occurring. =20 I think this is very reasonable. >> For example, we could specify that for the RTP congestion circuit = breaker to trip, the >> RTP sending rate has to be: >> - 10x the equivalent TCP sending rate based on counting ECN-CE = marked >> packets as lost; AND >> - 3x the equivalent sending rate based on actual drops (i.e., = counting >> ECN-CE marked packets as delivered). >> The "3x" above is an off-the-top-of-my-head factor that attempts to = roughly >> equally weight the inputs (3 is close to the square root of 10) - = pick a different >> number if that weighting feels wrong. >>=20 >> This would force drops to occur and then consider ECN-CE marks as = additional evidence >> that something is wrong in the network. >>=20 >> Another possible rationale for this mixing is that if drops start = occurring, then many of >> the new and proposed uses of ECN that treat ECN-CE marks as less than = loss-equivalent >> are outside their intended operating envelopes/regions. >=20 > Clearly if the queue has been driven to overflow, so that packet loss = is occurring, then the AQM is outside its intended operating regime. = I=E2=80=99m not sure we need to push it so far, though. Is there not a = regime where the ECN-CE marking rate indicates excessive congestion, = before the queue overflows and drops packets?=20 Shouldn=E2=80=99t a congestion control mechanism react well before that? Cheers, Michael From nobody Wed Jun 29 07:44:41 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E612D192; Wed, 29 Jun 2016 07:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD8v5AFiMknX; Wed, 29 Jun 2016 07:44:33 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A7E12B069; Wed, 29 Jun 2016 07:44:33 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5TEiPHj006676 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Jun 2016 10:44:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5TEiPHj006676 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1467211466; bh=kSkJdhAqpefg+rp93A8/ncTCzz8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=lSlZ4owL5+qyQq8sxDeCrzLKDDW5LWAVBVwHz0EvgoAEYwgN0/KSmOtrF1IdvjiCR fEgPvt0fR3/LXuKuMnhUufGVsdCV+L9AAytgIU3VW6Qaf87L/BrIiquhXwpUW6q4qB Dl/9KFDlSqsYUXByrLRDAsFobce4cE8ZLY967nns= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u5TEiPHj006676 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 29 Jun 2016 10:43:36 -0400 Received: from MXHUB308.corp.emc.com (MXHUB308.corp.emc.com [10.146.3.34]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5TEiAqD019619 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 29 Jun 2016 10:44:11 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB308.corp.emc.com ([10.146.3.34]) with mapi id 14.03.0266.001; Wed, 29 Jun 2016 10:44:10 -0400 From: "Black, David" To: Michael Welzl , Colin Perkins Thread-Topic: [AVTCORE] [rtcweb] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHR0L+ZFj+KetGouEG7mSRAG7kvVJ/+KEcA///WaKCAAbR8AIAAthgAgAAb1mA= Date: Wed, 29 Jun 2016 14:44:09 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 14:44:36 -0000 SSB3cm90ZTogDQoNCj4+IEFub3RoZXIgcG9zc2libGUgcmF0aW9uYWxlIGZvciB0aGlzIG1peGlu ZyBpcyB0aGF0IGlmIGRyb3BzIHN0YXJ0IG9jY3VycmluZywgdGhlbiBtYW55IG9mDQo+PiB0aGUg bmV3IGFuZCBwcm9wb3NlZCB1c2VzIG9mIEVDTiB0aGF0IHRyZWF0IEVDTi1DRSBtYXJrcyBhcyBs ZXNzIHRoYW4gbG9zcy1lcXVpdmFsZW50DQo+PiBhcmUgb3V0c2lkZSB0aGVpciBpbnRlbmRlZCBv cGVyYXRpbmcgZW52ZWxvcGVzL3JlZ2lvbnMuDQoNCkNvbGluIHJlc3BvbmRlZDoNCg0KPiBDbGVh cmx5IGlmIHRoZSBxdWV1ZSBoYXMgYmVlbiBkcml2ZW4gdG8gb3ZlcmZsb3csIHNvIHRoYXQgcGFj a2V0IGxvc3MgaXMNCj4gb2NjdXJyaW5nLCB0aGVuIHRoZSBBUU0gaXMgb3V0c2lkZSBpdHMgaW50 ZW5kZWQgb3BlcmF0aW5nIHJlZ2ltZS4gSeKAmW0gbm90IHN1cmUNCj4gd2UgbmVlZCB0byBwdXNo IGl0IHNvIGZhciwgdGhvdWdoLiBJcyB0aGVyZSBub3QgYSByZWdpbWUgd2hlcmUgdGhlIEVDTi1D RQ0KPiBtYXJraW5nIHJhdGUgaW5kaWNhdGVzIGV4Y2Vzc2l2ZSBjb25nZXN0aW9uLCBiZWZvcmUg dGhlIHF1ZXVlIG92ZXJmbG93cyBhbmQNCj4gZHJvcHMgcGFja2V0cz8NCg0KWWVzLCBidXQgdGhh dCBtYXkgbm90IGJlIHJlbGV2YW50IHRvIHRoaXMgZGlzY3Vzc2lvbi4gICBNeSBoeXBvdGhlc2lz IGZvciB0aGlzIGRpc2N1c3Npb24NCmlzIHRoYXQgYWN0dWFsIGRyb3BzIHdpbGwgb2NjdXIgd2Vs bCBiZWZvcmUgUlRQICBpcyBydW5uaW5nIGF0IDEweCB0aGUgVENQIGVxdWl2YWxlbnQgcmF0ZQ0K KGJhc2VkIG9uIGRyb3BzIGFuZCBFQ04tQ0UgbWFya3MpLCBhbmQgdGhhdCAxMHggZmFjdG9yIGlz IHRoZSB0cmlwIHRocmVzaG9sZCBmb3IgdGhlDQpjaXJjdWl0IGJyZWFrZXIsIHdoaWNoIGlzIHRo ZSBmb2N1cyBvZiB0aGlzIGRpc2N1c3Npb24uIA0KDQpJIHdvdWxkIHRoaW5rIHRoYXQgdGhlICJy ZWdpbWUgd2hlcmUgdGhlIEVDTi1DRSBtYXJraW5nIHJhdGUgaW5kaWNhdGVzIGV4Y2Vzc2l2ZQ0K Y29uZ2VzdGlvbiwgYmVmb3JlIHRoZSBxdWV1ZSBvdmVyZmxvd3MgYW5kIGRyb3BzIHBhY2tldHM/ IiB3b3VsZCBub3QgZXh0ZW5kIGFzDQpmYXIgYXMgUlRQIHJ1bm5pbmcgYXQgMTB4IHRoZSBUQ1Ag ZXF1aXZhbGVudCByYXRlLCB3aGljaCBpcyB3aGVyZSB0aGUgUlRQIGNpcmN1aXQNCmJyZWFrZXIg dHJpcHMuDQoNClRoaXMgaXMgYWxsIGEgdGhvdWdodCBleGVyY2lzZSAtIEknbSBoYXBweSB0byBi ZSBzaG93biB0byBiZSB3cm9uZyBiYXNlZCBvbiBhY3R1YWwNCmRhdGEgYW5kIGV4cGVyaWVuY2Ug d2l0aCAicnVubmluZyBjb2RlIiAuLi4NCg0KVG8gd2hpY2ggTWljaGFlbCByZXNwb25kZWQ6IA0K DQo+IFNob3VsZG7igJl0IGEgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSByZWFjdCB3ZWxs IGJlZm9yZSB0aGF0Pw0KDQpZZXMsIGlmIHRoZXJlIGlzIG9uZSA7LSkuICBUaGlzIGlzIFJUUCAu Li4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogTWljaGFlbCBXZWx6bCBbbWFpbHRvOm1pY2hhd2VAaWZpLnVpby5ub10NCj4gU2VudDog V2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IDQ6NTUgQU0NCj4gVG86IENvbGluIFBlcmtpbnMNCj4g Q2M6IEJsYWNrLCBEYXZpZDsgcnRjd2ViQGlldGYub3JnOyB0c3Z3ZzsgSUVURiBBVlRDb3JlIFdH DQo+IFN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gW3J0Y3dlYl0gW3RzdndnXSBXRyBMYXN0IENhbGwg b24gY2hhbmdlczogZHJhZnQtaWV0Zi0NCj4gYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0x Ng0KPiANCj4gDQo+ID4gT24gMjkuIGp1bi4gMjAxNiwgYXQgMDAuMDIsIENvbGluIFBlcmtpbnMg PGNzcEBjc3BlcmtpbnMub3JnPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4+IE9uIDI4IEp1biAyMDE2 LCBhdCAwMjowNCwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPiB3cm90ZToNCj4g Pj4NCj4gPj4gVHJ5aW5nIHRvIHNob3J0ZW4gdXAgdGhpcyB0aHJlYWQgYWdhaW4gLi4uDQo+ID4+ DQo+ID4+Pj4+PiBJJ20gbm90IHF1aXRlIHN1cmUgaG93IHRvIHNwZWNpZnkgInVzZSBvZiBFQ04g YXMgYWRkaXRpb25hbCBldmlkZW5jZSIgb2YNCj4gPj4+Pj4+ICJleGNlc3NpdmUgY29uZ2VzdGlv biIgYXMgZHJvcC1lcXVpdmFsZW5jZSBpcyBhYm91dCB0aGUgYmVzdCB3ZSBoYXZlDQo+ID4+Pj4+ PiBmb3IgY3VycmVudCBndWlkYW5jZS4NCj4gPj4+Pj4NCj4gPj4+Pj4gSSBmYWlsIHRvIHBhcnNl IHRoYXQgc2VudGVuY2UsIHNvIG1heWJlIEnigJltIGdldHRpbmcgeW91IHdyb25nLCBidXQgYW55 d2F5DQo+IEkNCj4gPj4+Pj4gd29uZGVyOiB3aGF04oCZcyBldmVuIHRoZSBwb2ludCBvZiB0aGlz Pw0KPiA+Pj4+PiBXaHkgZXZlbiBib3RoZXIgY29uc2lkZXJpbmcgQ0UtbWFya3MgYXMgaW5mb3Jt YXRpb24gZm9yIGEgY2lyY3VpdA0KPiBicmVha2VyPw0KPiA+Pj4+DQo+ID4+Pj4gQmVjYXVzZSB0 aGUgYWx0ZXJuYXRpdmUgaXMgdGhhdCB3ZSBvbmx5IGJyZWFrIHRoZSBjaXJjdWl0IG9uY2UgdGhl IHF1ZXVlIGhhcw0KPiA+Pj4gYmVlbiBkcml2ZW4gaW50byBvdmVyZmxvdywgYW5kIHBhY2tldHMg aGF2ZSBiZWVuIGxvc3QuIFdlIHdhbnQgdG8gYXZvaWQNCj4gdGhhdCwNCj4gPj4+IHNpbmNlIGl0 IGNhdXNlcyBsYXRlbmN5LCBhbmQgdG9vIG11Y2ggbGF0ZW5jeSBpcyB2ZXJ5IGJhZCBmb3IgdGhl IHVzZXINCj4gZXhwZXJpZW5jZS4NCj4gPj4+DQo+ID4+PiBXZWxsIC0gdGhlIGJldHRlciB3YXkg b3V0IHdvdWxkIGJlIGZvciB0aGUgYXBwbGljYXRpb24gdG8gcmVhY3QuIE1heWJlIHRoaXMgaXMN Cj4gbWUNCj4gPj4+IG1pc3VuZGVyc3RhbmRpbmcgdGhlIGNpcmN1aXQgYnJlYWtlciwgYnV0IEkg ZGlkIHRoaW5rIGl04oCZcyBtb3JlIGxpa2UgYSBsYXN0DQo+IHJlc29ydOKApg0KPiA+Pj4geW91 IGp1c3QgZG9u4oCZdCB3YW50IHRvIGJlIHRyaWdnZXItaGFwcHkgd2l0aCBzdWNoIGEgdGhpbmc/ DQo+ID4+DQo+ID4+IFdlbGwsIHRoZSBSVFAgY2lyY3VpdCBicmVha2VyIGRyYWZ0IGlzIG5vdCB0 cmlnZ2VyIGhhcHB5IC0gZm9yIGl0cyBjb25nZXN0aW9uDQo+IGNpcmN1aXQNCj4gPj4gYnJlYWtl ciB0byB0cmlwLCBSVFAgaGFzIHRvIGJlIHNlbmRpbmcgYXQgMTB4IHRoZSByYXRlIHRoYXQgVENQ IHdvdWxkIHNlbmQNCj4gdW5kZXINCj4gPj4gdGhvc2UgY29uZGl0aW9ucywgYmFzZWQgb24gdGhl IFRDUCB0aHJvdWdocHV0IGVxdWF0aW9uLiAgU2VlOg0KPiA+Pg0KPiA+PiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hdnRjb3JlLXJ0cC1jaXJjdWl0LWJyZWFrZXJzLTE2 I3NlY3Rpb24tDQo+IDQuMw0KPiA+Pg0KPiA+PiBUaGUgaXNzdWUgaGVyZSBpcyAtIHdoZW4gY2Fs Y3VsYXRpbmcgdGhlIGNvbXBhcmFibGUgVENQIHRocm91Z2hwdXQsIGhvdyBhcmUNCj4gRUNOLUNF DQo+ID4+IG1hcmtzIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBsb3NzIHJhdGUgaW5wdXQgdG8gdGhl IFRDUCB0aHJvdWdocHV0IGVxdWF0aW9uPw0KPiBEbw0KPiA+PiBFQ04tQ0UgbWFya2VkIHBhY2tl dHMgY291bnQgYXMgaGF2aW5nIGFycml2ZWQgb3IgaGF2aW5nIGJlZW4gZHJvcHBlZD8NCj4gPg0K PiA+IFJpZ2h0IC0gb3IgZG8gdGhleSBjb3VudCBzb21ld2hlcmUgYmV0d2VlbiB0aGUgdHdvLg0K PiANCj4gTGV04oCZcyBzZWUgdGhlbSBjbGVhcmx5IGZvciB3aGF0IHRoZXkgYXJlLg0KPiBUaGV5 IG1lYW46IHRoZSBwYXRoIGlzICpub3QqIGJyb2tlbiAodGhleSBoYXZlIGFycml2ZWQhKSwgYW5k IGEgcHJvYmFibHkgYW4NCj4gQVFNIG1lY2hhbmlzbSwgcG90ZW50aWFsbHkgdXNpbmcgYSBzaGFs bG93IHF1ZXVlLCBtYXJrZWQgdGhlbSB0byBpbmRpY2F0ZQ0KPiBjb25nZXN0aW9uLiBJIHRoaW5r IOKAnHNvbWV3aGVyZSBiZXR3ZWVuIHRoZSB0d2/igJ0gcmVhbGx5IGRvZXNu4oCZdCBjYXB0dXJl IHRoaXMNCj4gd2VsbC4NCj4gDQo+IA0KPiA+PiBXaGVuIHRoaW5ncyBhcmUgcmVsYXRpdmVseSBz dGFibGUgYW5kIHRoZSBFQ04tQ0UgbWFya3MgYXJlIGJlaW5nIHVzZWQgdG8NCj4gbnVkZ2UNCj4g Pj4gdGhlIHNlbmRlcidzIHJhdGUgYmFzZWQgb24gd2hhdCB0aGUgbmV0d29yayBjYW4gYWJzb3Ji LCB3aGV0aGVyIEVDTi1DRQ0KPiBtYXJrcw0KPiA+PiBjb3VudCBhcyBsb3NzZXMgb3Igbm90IGlz IHByb2JhYmx5IGltbWF0ZXJpYWwgLSB0aGUgMTB4IGRpdmVyZ2VuY2UgZnJvbSB0aGUNCj4gVENQ DQo+ID4+IHRocm91Z2hwdXQgZXF1YXRpb24ncyByYXRlIGlzIG5vdCBnb2luZyB0byBhcmlzZSwg YW5kIHRoZSBjaXJjdWl0IGJyZWFrZXIgd29uJ3QNCj4gdHJpcC4NCj4gPj4gVGhlIGNpcmN1aXQg YnJlYWtlciBpcyBvbmx5IHN1cHBvc2VkIHRvIHRyaXAgd2hlbiB0aGluZ3MgYXJlIHNlcmlvdXNs eSB3cm9uZy4NCj4gPg0KPiA+IENvcnJlY3QuDQo+ID4NCj4gPj4gKDEpIElmIHRoZSBSVFAgY29u Z2VzdGlvbiBjaXJjdWl0IGJyZWFrZXIgdHJpcHMgYmFzZWQgb24gRUNOLUNFIG1hcmtzIGFsb25l LA0KPiA+PiBzb21ldGhpbmcgZmVlbHMgaW50dWl0aXZlbHkgd3JvbmcgLSBob3cnZCB3ZSBnZXQg dG8gUlRQIHJ1bm5pbmcgYXQgMTB4IHRoZQ0KPiA+PiBjb21wYXJhYmxlIFRDUCBzZW5kaW5nIHJh dGUgd2l0aCBubyBsb3NzZXM/ICBQZXJoYXBzIHRoZSBjaXJjdWl0IGJyZWFrZXINCj4gPj4gc2hv dWxkbuKAmXQgdHJpcCBvbiBFQ04tQ0UgbWFya3MgYWxvbmU/DQo+ID4NCj4gPiBTaG91bGRu4oCZ dCB0aGUgY29tcGFyYWJsZSByYXRlIHRvIHRyaWdnZXIgdGhlIGNpcmN1aXQgYnJlYWtlciBiZSAx MHggdGhhdCBnaXZlbiB0bw0KPiBhIFRDUCBmbG93IHN1YmplY3QgdG8gdGhlIHNhbWUgRUNOLUNF IG1hcmtpbmcgcmF0ZT8gSWYgdGhlIFRDUCB0cmVhdHMgRUNOLUNFIGFzDQo+IGVxdWl2YWxlbnQg dG8gbG9zcywgZm9yIGNvbmdlc3Rpb24gcmVzcG9uc2UsIHRoZW4gdGhlIGNpcmN1aXQgYnJlYWtl ciBzaG91bGQgZG8gc28NCj4gdG8sIGV0Yy4NCj4gDQo+IEZpcnN0LCBUQ1Agc2hvdWxkbuKAmXQg KHRyZWF0IEVDTi1DRSBhcyBlcXVpdmFsZW50IHRvIGxvc3MpLCBhbmQgc28gdGhlIGNpcmN1aXQg YnJlYWtlcg0KPiBzaG91bGRu4oCZdC4NCj4gU2Vjb25kLCBJIGd1ZXNzIHlvdeKAmXJlIHRhbGtp bmcgYWJvdXQgdGhlIGVxdWF0aW9uLiBXZWxsIHRoYXQgZ29lcyBjb21wbGV0ZWx5DQo+IHdyb25n IGFueXdheSAodGhlIGRlcml2YXRpb24gYXNzdW1lcyBwYWNrZXRzIHRvIGJlIGxvc3QsIG5vdCBt YXJrZWQ7IHRoZW4NCj4gYWdhaW4sIHlvdeKAmXJlIHVzaW5nIGxvc3MsIG5vdCB0aGUgbG9zcyBl dmVudCByYXRpbzsgdGhlbiBhZ2FpbiwgeW914oCZcmUgY2xvc2UgdG8gdGhpcw0KPiB3aXRoIEVD TiBwZXJoYXBzLCB1c2luZyDigJx0cmFkaXRpb25hbOKAnSBFQ04gcmVjZWl2ZXIgYmVoYXZpb3Ip Lg0KPiANCj4gDQo+ID4+ICgyKSBBdCB0aGUgb3RoZXIgZXh0cmVtZSwgdGhlIGNvbmdlc3Rpb24g Y2lyY3VpdCBicmVha2VyIGNsZWFybHkgaGFzIHRvIHRyaXAgaWYNCj4gUlRQDQo+ID4+IGdldHMg dG8gMTB4IHRoZSBjb21wYXJhYmxlIFRDUCBzZW5kaW5nIHJhdGUgYmFzZWQgb24gbG9zc2VzIGFs b25lLiAgVGhpcyBpcyB0aGUNCj4gPj4gYmFzZWxpbmUgZm9yIHRoZSBjaXJjdWl0IGJyZWFrZXIg dG8gcHJvdmlkZSBuZXR3b3JrIHByb3RlY3Rpb24gYXMgaW50ZW5kZWQuDQo+ID4+DQo+ID4+IFNv LCBnb2luZyBiYWNrIHRvIEdvcnJ5J3Mgc3VnZ2VzdGlvbiB0byB1c2UgRUNOLUNFIG1hcmtzIGFz ICJhZGRpdGlvbmFsDQo+IGV2aWRlbmNlLCINCj4gPj4gaGVyZSdzIGEgc3RyYXcgcHJvcG9zYWwg dG8gc2hvb3QgYXQgLi4uIGZhY3RvciBpbiBFQ04tQ0UgbWFya3MgYXMgYWRkaXRpb25hbA0KPiBs b3NzZXMNCj4gPj4gKm9ubHkgd2hlbiogbG9zc2VzIGFyZSBhbHJlYWR5IG9jY3VycmluZy4NCj4g DQo+IEkgdGhpbmsgdGhpcyBpcyB2ZXJ5IHJlYXNvbmFibGUuDQo+IA0KPiANCj4gPj4gRm9yIGV4 YW1wbGUsIHdlIGNvdWxkIHNwZWNpZnkgdGhhdCBmb3IgdGhlIFJUUCBjb25nZXN0aW9uIGNpcmN1 aXQgYnJlYWtlciB0bw0KPiB0cmlwLCB0aGUNCj4gPj4gUlRQIHNlbmRpbmcgcmF0ZSBoYXMgdG8g YmU6DQo+ID4+IAktIDEweCB0aGUgZXF1aXZhbGVudCBUQ1Agc2VuZGluZyByYXRlIGJhc2VkIG9u IGNvdW50aW5nIEVDTi1DRSBtYXJrZWQNCj4gPj4gCQlwYWNrZXRzIGFzIGxvc3Q7IEFORA0KPiA+ PiAJLSAzeCB0aGUgZXF1aXZhbGVudCBzZW5kaW5nIHJhdGUgYmFzZWQgb24gYWN0dWFsIGRyb3Bz IChpLmUuLCBjb3VudGluZw0KPiA+PiAJCUVDTi1DRSBtYXJrZWQgcGFja2V0cyBhcyBkZWxpdmVy ZWQpLg0KPiA+PiBUaGUgIjN4IiBhYm92ZSBpcyBhbiBvZmYtdGhlLXRvcC1vZi1teS1oZWFkIGZh Y3RvciB0aGF0IGF0dGVtcHRzIHRvIHJvdWdobHkNCj4gPj4gZXF1YWxseSB3ZWlnaHQgdGhlIGlu cHV0cyAoMyBpcyBjbG9zZSB0byB0aGUgc3F1YXJlIHJvb3Qgb2YgMTApIC0gcGljayBhIGRpZmZl cmVudA0KPiA+PiBudW1iZXIgaWYgdGhhdCB3ZWlnaHRpbmcgZmVlbHMgd3JvbmcuDQo+ID4+DQo+ ID4+IFRoaXMgd291bGQgZm9yY2UgZHJvcHMgdG8gb2NjdXIgYW5kIHRoZW4gY29uc2lkZXIgRUNO LUNFIG1hcmtzIGFzIGFkZGl0aW9uYWwNCj4gZXZpZGVuY2UNCj4gPj4gdGhhdCBzb21ldGhpbmcg aXMgd3JvbmcgaW4gdGhlIG5ldHdvcmsuDQo+ID4+DQo+ID4+IEFub3RoZXIgcG9zc2libGUgcmF0 aW9uYWxlIGZvciB0aGlzIG1peGluZyBpcyB0aGF0IGlmIGRyb3BzIHN0YXJ0IG9jY3VycmluZywg dGhlbg0KPiBtYW55IG9mDQo+ID4+IHRoZSBuZXcgYW5kIHByb3Bvc2VkIHVzZXMgb2YgRUNOIHRo YXQgdHJlYXQgRUNOLUNFIG1hcmtzIGFzIGxlc3MgdGhhbiBsb3NzLQ0KPiBlcXVpdmFsZW50DQo+ ID4+IGFyZSBvdXRzaWRlIHRoZWlyIGludGVuZGVkIG9wZXJhdGluZyBlbnZlbG9wZXMvcmVnaW9u cy4NCj4gPg0KPiA+IENsZWFybHkgaWYgdGhlIHF1ZXVlIGhhcyBiZWVuIGRyaXZlbiB0byBvdmVy Zmxvdywgc28gdGhhdCBwYWNrZXQgbG9zcyBpcw0KPiBvY2N1cnJpbmcsIHRoZW4gdGhlIEFRTSBp cyBvdXRzaWRlIGl0cyBpbnRlbmRlZCBvcGVyYXRpbmcgcmVnaW1lLiBJ4oCZbSBub3Qgc3VyZQ0K PiB3ZSBuZWVkIHRvIHB1c2ggaXQgc28gZmFyLCB0aG91Z2guIElzIHRoZXJlIG5vdCBhIHJlZ2lt ZSB3aGVyZSB0aGUgRUNOLUNFDQo+IG1hcmtpbmcgcmF0ZSBpbmRpY2F0ZXMgZXhjZXNzaXZlIGNv bmdlc3Rpb24sIGJlZm9yZSB0aGUgcXVldWUgb3ZlcmZsb3dzIGFuZA0KPiBkcm9wcyBwYWNrZXRz Pw0KPiANCj4gU2hvdWxkbuKAmXQgYSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtIHJlYWN0 IHdlbGwgYmVmb3JlIHRoYXQ/DQo+IA0KPiBDaGVlcnMsDQo+IE1pY2hhZWwNCg0K From nobody Wed Jun 29 07:54:22 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B9512DC29; Wed, 29 Jun 2016 07:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5Ym9gC2J5Vs; Wed, 29 Jun 2016 07:54:18 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F7112D08F; Wed, 29 Jun 2016 07:54:16 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bIGsW-0004NH-BT; Wed, 29 Jun 2016 16:54:12 +0200 Received: from 1x-193-157-240-251.uio.no ([193.157.240.251]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bIGsV-0005HQ-Pp; Wed, 29 Jun 2016 16:54:12 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Wed, 29 Jun 2016 16:54:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> To: "Black, David" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 3 sum rcpts/h 15 sum msgs/h 7 total rcpts 43824 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-7.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-2.138, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BEC1D3752D6DF3869DF476B59BD2B275000EA244 X-UiO-SPAM-Test: remote_host: 193.157.240.251 spam_score: -70 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 131 max/h 8 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "rtcweb@ietf.org" , Colin Perkins , IETF AVTCore WG , tsvwg Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 14:54:21 -0000 > On 29. jun. 2016, at 16.44, Black, David wrote: >=20 > I wrote:=20 >=20 >>> Another possible rationale for this mixing is that if drops start = occurring, then many of >>> the new and proposed uses of ECN that treat ECN-CE marks as less = than loss-equivalent >>> are outside their intended operating envelopes/regions. >=20 > Colin responded: >=20 >> Clearly if the queue has been driven to overflow, so that packet loss = is >> occurring, then the AQM is outside its intended operating regime. = I=E2=80=99m not sure >> we need to push it so far, though. Is there not a regime where the = ECN-CE >> marking rate indicates excessive congestion, before the queue = overflows and >> drops packets? >=20 > Yes, but that may not be relevant to this discussion. My hypothesis = for this discussion > is that actual drops will occur well before RTP is running at 10x the = TCP equivalent rate > (based on drops and ECN-CE marks), and that 10x factor is the trip = threshold for the > circuit breaker, which is the focus of this discussion.=20 >=20 > I would think that the "regime where the ECN-CE marking rate indicates = excessive > congestion, before the queue overflows and drops packets?" would not = extend as > far as RTP running at 10x the TCP equivalent rate, which is where the = RTP circuit > breaker trips. Seems reasonable to me=E2=80=A6. >=20 > This is all a thought exercise - I'm happy to be shown to be wrong = based on actual > data and experience with "running code" ... >=20 > To which Michael responded:=20 >=20 >> Shouldn=E2=80=99t a congestion control mechanism react well before = that? >=20 > Yes, if there is one ;-). This is RTP =E2=80=A6 Earlier, in the same conversation, so - I assume - the same context, = Colin wrote: "Assuming, in all cases, that there=E2=80=99s a parallel congestion = control algorithm running=E2=80=9D Cheers, Michael From nobody Thu Jun 30 07:51:42 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717AD12D09B; Thu, 30 Jun 2016 07:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0CKsTE6lqQi; Thu, 30 Jun 2016 07:51:32 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CBF12B054; Thu, 30 Jun 2016 07:51:32 -0700 (PDT) Received: from [130.209.247.112] (port=64642 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bIdJQ-0004W4-9v; Thu, 30 Jun 2016 15:51:29 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Thu, 30 Jun 2016 15:51:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B94C5D0-A473-44A4-B1BF-0D927DEBDD63@csperkins.org> References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> <6E35FB6C-CA98-413C-B7AE-75402A968017@ifi.uio.no> <3FD27BBF-8E2D-4A42-86A0-C4C0692FF8C9@csperkins.org> <2E09525C-C1AD-41D1-AE22-865518FA0FBE@csperkins.org> To: Michael Welzl X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 14:51:34 -0000 > On 29 Jun 2016, at 15:54, Michael Welzl wrote: >> On 29. jun. 2016, at 16.44, Black, David wrote: >> I wrote:=20 >>=20 >>>> Another possible rationale for this mixing is that if drops start = occurring, then many of >>>> the new and proposed uses of ECN that treat ECN-CE marks as less = than loss-equivalent >>>> are outside their intended operating envelopes/regions. >>=20 >> Colin responded: >>=20 >>> Clearly if the queue has been driven to overflow, so that packet = loss is >>> occurring, then the AQM is outside its intended operating regime. = I=E2=80=99m not sure >>> we need to push it so far, though. Is there not a regime where the = ECN-CE >>> marking rate indicates excessive congestion, before the queue = overflows and >>> drops packets? >>=20 >> Yes, but that may not be relevant to this discussion. My hypothesis = for this discussion >> is that actual drops will occur well before RTP is running at 10x = the TCP equivalent rate >> (based on drops and ECN-CE marks), and that 10x factor is the trip = threshold for the >> circuit breaker, which is the focus of this discussion.=20 >>=20 >> I would think that the "regime where the ECN-CE marking rate = indicates excessive >> congestion, before the queue overflows and drops packets?" would not = extend as >> far as RTP running at 10x the TCP equivalent rate, which is where the = RTP circuit >> breaker trips. >=20 > Seems reasonable to me=E2=80=A6. Does anyone have data to let us find out either way?=20 >> This is all a thought exercise - I'm happy to be shown to be wrong = based on actual >> data and experience with "running code" ... >>=20 >> To which Michael responded:=20 >>=20 >>> Shouldn=E2=80=99t a congestion control mechanism react well before = that? >>=20 >> Yes, if there is one ;-). This is RTP =E2=80=A6 >=20 > Earlier, in the same conversation, so - I assume - the same context, = Colin wrote: > "Assuming, in all cases, that there=E2=80=99s a parallel congestion = control algorithm running=E2=80=9D If the congestion control is working, then it should adapt the rate so = the circuit breaker never triggers. Yes, there should be a parallel = congestion control, but for the circuit breaker to be relevant, that = congestion control is either not working properly, or not implemented.=20= --=20 Colin Perkins https://csperkins.org/ From nobody Thu Jun 30 09:00:12 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9449F12D508; Thu, 30 Jun 2016 09:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ2deBhBW38t; Thu, 30 Jun 2016 08:59:58 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F059112D113; Thu, 30 Jun 2016 08:59:57 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id A149A96969B67; Thu, 30 Jun 2016 15:59:51 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5UFxsAG002113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2016 15:59:54 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5UFxrch016560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jun 2016 17:59:54 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.240]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 30 Jun 2016 17:58:43 +0200 From: "De Schepper, Koen (Nokia - BE)" To: "Black, David" Thread-Topic: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 Thread-Index: AQHRyB4Xv7l4815Xu02SCqscZNZxsp/tUDQAgABAKwCAABBvgIABAQmAgAOYcQCAADeCAIAK/Ekg///0AQCAAFzOEP//7voAgAAowpA= Date: Thu, 30 Jun 2016 15:58:42 +0000 Message-ID: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 16:00:06 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJsYWNrLCBEYXZpZCBbbWFp bHRvOmRhdmlkLmJsYWNrQGVtYy5jb21dDQo+IFNlbnQ6IG1hYW5kYWcgMjcganVuaSAyMDE2IDIy OjEwDQo+IFRvOiBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRSkNCj4gQ2M6IHRzdndnOyBJ RVRGIEFWVENvcmUgV0c7IHJ0Y3dlYkBpZXRmLm9yZzsgQmxhY2ssIERhdmlkDQo+IFN1YmplY3Q6 IFJFOiBbdHN2d2ddIFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczog ZHJhZnQtDQo+IGlldGYtYXZ0Y29yZS1ydHAtY2lyY3VpdC1icmVha2Vycy0xNg0KPiANCj4gPiBB cyBsb25nIGFzIGFuIEFRTSBpcyBtYXJraW5nIGF0IHRoZSBzYW1lIHJhdGUgYXMgZHJvcHBpbmcN Cj4gDQo+IFRoYXQncyBhbiBpbnRlcmVzdGluZyBhc3N1bXB0aW9uIC0gaXQgc2hvdWxkIGJlIHRy dWUgZm9yIEFRTXMgdmV0dGVkDQo+IGhlcmUgaW4gdGhlIHBhc3QsDQoNCkFuZCBJIGhvcGUgZm9y IGVjdCgwKSB0aGUgbmV0d29yayB3aWxsIGtlZXAgZG9pbmcgdGhpcyBpbiB0aGUgZnV0dXJlLCBh dCANCmxlYXN0IG5vdCB0byBkZXZpYXRlIHRvbyBmYXIgZnJvbSB0aGlzLg0KTDRTIHByb3Bvc2Vz IHRvIHVzZSBlY3QoMSkganVzdCBiZWNhdXNlIGl0IGRldmlhdGVzIHRvbyBtdWNoLCBzbyB0aGUg bmV0d29yayANCmNhbiBkZXRlY3QgdGhlIGRpZmZlcmVudCBlbmQtc3lzdGVtIGJlaGF2aW9yIGFu ZCBjYW4gY291cGxlIGl0IGNvcnJlY3RseSB0byANCndoYXQgaXQgaXMgZG9pbmcgZm9yIGRyb3Ag YW5kIGVjdCgwKS4NCg0KDQo+IGJ1dCB0aGVyZSBhcmUgZWFzeSB3YXlzIGZvciBpdCBub3QgdG8g aG9sZCAoZS5nLiwgaWYNCj4gZHJvcHBpbmcNCj4gb3IgbWFya2luZyBpcyBiYXNlZCBvbiBxdWV1 ZSBvY2N1cGFuY3ksIGl0IGlzIHBvc3NpYmxlIHRoYXQgZHJvcHBpbmcNCj4gcmVkdWNlcyBxdWV1 ZSBvY2N1cGFuY3kgaW4gYSBmYXNoaW9uIHRoYXQgbWFya2luZyBkb2VzIG5vdCkuDQoNCkRvIHlv dSBtZWFuIHRoYXQgdGhpcyByZXN1bHRzIGluIGRpZmZlcmVudCBtYXJrIGFuZCBkcm9wIHByb2Jh YmlsaXRpZXMgDQpmb3IgY29tcGV0aW5nIEVDTiBhbmQgbm9uLUVDTiBmbG93cz8NCg0KVGhlIGlt cGFjdCBvbiB0aGUgZHJvcHBpbmcvbWFya2luZyBwcm9iYWJpbGl0eSAqdmFsdWUqIGFwcGxpZWQg YnkgYW4gQVFNIGNhbiBjaGFuZ2UgDQpkdWUgdG8gcHJlc2VuY2Ugb2YgRUNOIGZsb3dzLCBidXQg SSBkb24ndCB0aGluayB0aGlzIHJlc3VsdHMgaW4gYSBkaWZmZXJlbnQgDQpkcm9wIGNvbXBhcmVk IHRvIG1hcmsgcHJvYmFiaWxpdHkuIFVwIHRvIG5vdyBhbGwgY2xhc3NpYyBBUU1zIHNtb290aCB0 aGVpciBwIA0Kb3ZlciBzdWZmaWNpZW50IGxvbmcgdGltZSB0byByZW1vdmUgc2hvcnQgZmx1Y3R1 YXRpb25zIGluIHF1ZXVlIHNpemVzLiANCg0KRnJvbSBhbiBlbmQgc3lzdGVtIEkgdGhpbmsgZm9y IGNsYXNzaWMgRUNOIGl0IGlzIHNhZmUgdG8gYXNzdW1lIHRoYXQgaWYgeW91IA0KZGV0ZWN0IGhp Z2ggbGV2ZWxzIG9mIGRyb3AsIGl0IG1lYW5zIHRoZXJlIGlzIGEgaGlnaCBsZXZlbCBvZiANCmNv bmdlc3Rpb24gQU5EIHRoZSBuZXR3b3JrIHRha2VzIGNhcmUgb2YgaXQuIElmIHlvdSBkZXRlY3Qg YSBoaWdoIGxldmVsDQpvZiBtYXJraW5nLCBpdCBtZWFucyBsb3RzIG9mIGNvbmdlc3Rpb24gYW5k IG5vYm9keSBpcyBjdXJyZW50bHkgdGFraW5nIGNhcmUgDQpvZiBpdC4gRXZlcnlib2R5IGlzIGxv b2tpbmcgYXQgeW91IGFzIGEgc2VuZGVyIHRvIHRha2UgY2FyZSBvZiBpdC4gVGhhdCdzIHdoeQ0K SSB0aGluayB5b3Ugc2hvdWxkIG5vdCB1c2UgRUNOIGlmIHlvdSBkb24ndCB1c2UgY29uZ2VzdGlv biBjb250cm9sLg0KDQpJdCBhbHNvIG1lYW5zIHRoYXQgdGhlIGNvbXBldGluZyBkcm9wIGZsb3dz IGFyZSBoYXZpbmcgYSBoaWdoIGxldmVsIG9mIG1hdGNoaW5nDQpkcm9wLiBUaGF0J3Mgd2h5IEkg dGhpbmsgYSBjbGFzc2ljIGNpcmN1aXQgYnJlYWtlciBzaG91bGQgYWxzbyB0cmVhdCBkcm9wIGFu ZCANCmNsYXNzaWMgbWFya2luZyBzaW1pbGFyLg0KDQpJIHVuZGVyc3Rvb2QgQUJFIHRyaWVzIHRv IG1vZGlmeSB0aGUgZW5kIHN5c3RlbSBiZWhhdmlvciBzbGlnaHRseSBmb3IgRUNOLiBJZiANCnRo aXMgY2FuIGJlIGRvbmUgc2FmZWx5IHdpdGggYmVuZWZpdHMgdGhhdCBvdXR3ZWlnaHMgdGhlIGRp c2FkdmFudGFnZXMsIA0KdGhhbiB0aGF0J3Mgbm8gcHJvYmxlbSwgYnV0IEkgdGhpbmsgbm9ib2R5 IGlzIGluIGZhdm9yIHRvIG1vZGlmeSB0aGUgQVFNIA0KYmVoYXZpb3IgdG8gZWN0KDApLg0KDQpC YXNlZCBvbiBEdWFsUSBjb21wYXRpYmlsaXR5IGV4cGVyaW1lbnRzIHdpdGggY2xhc3NpYyBFQ04s IEkgYWxzbyBiZWxpZXZlIA0KdGhhdCwgaWYgd2Ugd2FudCB0byBmdXJ0aGVyIHByb21vdGUgY2xh c3NpYyBFQ04gdG9vLCB3ZSBuZWVkIHNvbWUgZXh0cmEgDQpzYWZldHkgbWVhc3VyZXMgZm9yIGNs YXNzaWMgQVFNcyB1c2luZyBFQ04gdG8gYXZvaWQgaGlnaCBDRSBtYXJraW5nIGxldmVscywgDQp3 aGVyZSBlY3QoMCkgZmxvd3Mgc3RhcnQgdG8gcHVzaCBhd2F5IHRvbyBtdWNoIHRoZSBub24tZWN0 IGZsb3dzLiBGb3IgDQppbnN0YW5jZSBQSUUgaGFzIChmb3IgZ29vZCByZWFzb25zKSBhIG1heCBv ZiAxMCUgbWFya2luZywgYW5kIHRoZW4gc3dpdGNoZXMgDQp0byBkcm9wLiBBcyBmYXIgYXMgSSBr bm93IHN1Y2ggbWVhc3VyZXMgYXJlIG5vdCBtYW5kYXRvcnkgaW4gb3RoZXIgRUNOL0FRTSANCnJl bGF0ZWQgZHJhZnRzLCBpcyBpdD8NCg0KS29lbi4NCg0KPiANCj4gRm9yIEVDTiAiY2xhc3NpYyIg KGkuZS4sIHNlZSBSRkMgMzE2OCkgd2hlcmUgRUNOLUNFIG1hcmtpbmdzIGFyZSB0cmVhdGVkDQo+ IGFzIGRyb3AtZXF1aXZhbGVudCwgdGhhdCBpcyBmb3IgY29uZ2VzdGlvbiBjb250cm9sIHB1cnBv c2VzLCB3aGljaCBpcw0KPiBzaW1pbGFyDQo+IHRvLCAoYnV0IG5vdCB0aGUgc2FtZSBhcykgdGhl IHRocm91Z2hwdXQgZXN0aW1hdGlvbiB1c2FnZSBmb3IgdGhlIFJUUA0KPiBjaXJjdWl0DQo+IGJy ZWFrZXIuICAgIEknbGwgbm90ZSB0aGF0IEVDTiAiY2xhc3NpYyIgd2FzIGRlc2lnbmVkIGNvbmdl c3Rpb24gY29udHJvbA0KPiBhbGdvcml0aG1zIGZvciByZWFjdCB0byBFQ04tQ0UgbWFya3Mgb25j ZSBwZXIgUlRULCBpbmRlcGVuZGVudCBvZiBob3cNCj4gbWFueSBFQ04tQ0UgbWFya3MgYXJlIG9i c2VydmVkIGluIGFuIFJUVC4NCj4gDQo+IEdvcnJ5IHdyb3RlOg0KPiANCj4gPiA+IGluIHRoaXMg Y29udGV4dCB3ZSBzaG91bGQgdXNlIEVDTiB0byBkcml2ZSBhIENDIGFsZ29yaXRobSBhbmQgd2UN Cj4gc2hvdWxkIGJlDQo+ID4gPiBjYXV0aW91cyB0byBhdm9pZCByZXF1aXJpbmcgaXRzIHVzZSB3 aXRoaW4gYSBDaXJjdWl0IEJyZWFrZXIgLQ0KPiBvcHRpb25hbA0KPiA+ID4gdXNlLCBpZiB5b3Ug dW5kZXJzdGFuZCBob3cgdG8gaW50ZXJwcmV0IGEgcmVhY3Rpb24gdG8gbWFueSBDRS1tYXJrcw0K PiBhcw0KPiA+ID4gZXhjZXNzaXZlIGNvbmdlc3Rpb24sIGFyZSBwZXJtaXR0ZWQuDQo+IA0KPiBT b21ldGhpbmcgbGlrZSB0aGF0IG1heSBiZSB3b3JrYWJsZSwgc3RhcnRpbmcgd2l0aCBhIGNsZWFy IGRpc3RpbmN0aW9uDQo+IGJldHdlZW4NCj4gdGhlIHVzZSBvZiBFQ04gYnkgQ0MgKHJvdXRpbmUs IGFjdGl2ZSBhdCBhbGwgdGltZXMpIGFuZCBFQ04gYnkgYSBjaXJjdWl0DQo+IGJyZWFrZXIgKG1v bml0b3JzIGZvciBldmlkZW5jZSB0aGF0IHRoaW5ncyBoYXZlIGdvdHRlbiBiYWQsIG9ubHkNCj4g YWN0aXZhdGVkDQo+IHdoZW4gdGhpbmdzIGdldCBiYWQpLiAgIFRoaXMgd291bGQgYmFzZWxpbmUg dGhlIFJUUCBjaXJjdWl0IGJyZWFrZXIgb24NCj4gZHJvcHMNCj4gYW5kIGFsbG93IHVzZSBvZiBF Q04gYXMgYWRkaXRpb25hbCBldmlkZW5jZSBvZiBwcm9ibGVtcywgaW4gY29udHJhc3QgdG8NCj4g Y29uZ2VzdGlvbiBjb250cm9sIHdoZXJlIEVDTi1DRSBpcyBlZmZlY3RpdmVseSB0cmVhdGVkIGFz IGRyb3AtDQo+IGVxdWl2YWxlbnQuDQo+IA0KPiBJJ20gbm90IHF1aXRlIHN1cmUgaG93IHRvIHNw ZWNpZnkgInVzZSBvZiBFQ04gYXMgYWRkaXRpb25hbCBldmlkZW5jZSIgb2YNCj4gImV4Y2Vzc2l2 ZSBjb25nZXN0aW9uIiBhcyBkcm9wLWVxdWl2YWxlbmNlIGlzIGFib3V0IHRoZSBiZXN0IHdlIGhh dmUNCj4gZm9yIGN1cnJlbnQgZ3VpZGFuY2UuDQo+IA0KPiBUaGFua3MsIC0tRGF2aWQNCj4gDQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBEZSBTY2hlcHBlciwgS29l biAoTm9raWEgLSBCRSkgW21haWx0bzprb2VuLmRlX3NjaGVwcGVyQG5va2lhLQ0KPiBiZWxsLQ0K PiA+IGxhYnMuY29tXQ0KPiA+IFNlbnQ6IE1vbmRheSwgSnVuZSAyNywgMjAxNiAzOjEzIFBNDQo+ ID4gVG86IGdvcnJ5QGVyZy5hYmRuLmFjLnVrDQo+ID4gQ2M6IE1pY2hhZWwgV2Vsemw7IEJsYWNr LCBEYXZpZDsgTWFnbnVzIFdlc3Rlcmx1bmQ7IHRzdndnOyBJRVRGDQo+IEFWVENvcmUgV0c7DQo+ ID4gcnRjd2ViQGlldGYub3JnOyBDb2xpbiBQZXJraW5zDQo+ID4gU3ViamVjdDogUkU6IFt0c3Z3 Z10gW3J0Y3dlYl0gW0FWVENPUkVdIFdHIExhc3QgQ2FsbCBvbiBjaGFuZ2VzOg0KPiBkcmFmdC1p ZXRmLQ0KPiA+IGF2dGNvcmUtcnRwLWNpcmN1aXQtYnJlYWtlcnMtMTYNCj4gPg0KPiA+DQo+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogZ29ycnlAZXJnLmFiZG4u YWMudWsgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51a10NCj4gPiA+IFNlbnQ6IG1hYW5kYWcg MjcganVuaSAyMDE2IDE3OjM4DQo+ID4gPiBUbzogRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0g QkUpDQo+ID4gPiBDYzogTWljaGFlbCBXZWx6bDsgQmxhY2ssIERhdmlkOyBnb3JyeUBlcmcuYWJk bi5hYy51azsgTWFnbnVzDQo+ID4gPiBXZXN0ZXJsdW5kOyB0c3Z3ZzsgSUVURiBBVlRDb3JlIFdH OyBydGN3ZWJAaWV0Zi5vcmc7IENvbGluIFBlcmtpbnMNCj4gPiA+IFN1YmplY3Q6IFJlOiBbdHN2 d2ddIFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0IENhbGwgb24gY2hhbmdlczoNCj4gZHJhZnQt DQo+ID4gPiBpZXRmLWF2dGNvcmUtcnRwLWNpcmN1aXQtYnJlYWtlcnMtMTYNCj4gPiA+DQo+ID4g PiBJIHRoaW5rIHRoaW5raW5nIG9mIEw0UyBpcyBtYXliZSBvZmYgYXQgYSB0YW5nZW50LiBUaGUg cXVlc3Rpb24NCj4gcmVhbGx5DQo+ID4gPiBpcw0KPiA+ID4gYWJvdXQgdGhlIGludGVycHJldGF0 aW9uIG9mIGxvc3MgYW5kIENFLW1hcmsgYXMgZXF1aXZhbGVudC4gSSBhcmd1ZWQNCj4gPiA+IHRo YXQNCj4gPiA+IGVhY2ggRUNOLUNFIG1hcmsgc2hvdWxkIG5vdCBiZSBjb3VudGVkIGFzIGVxdWl2 YWxlbnQgdG8gYSBsb3N0DQo+IHNlZ21lbnQgLQ0KPiA+DQo+ID4gV2h5IG5vdD8gQXMgbG9uZyBh cyBhbiBBUU0gaXMgbWFya2luZyBhdCB0aGUgc2FtZSByYXRlIGFzIGRyb3BwaW5nLCBhDQo+ID4g MTAwJSBtYXJraW5nIG1lYW5zIHRoYXQgbm9uLWVjbiBmbG93cyBhcmUgYmVpbmcgZHJvcHBlZCBh dCBhIDEwMCUsDQo+IG5vdD8NCj4gPg0KPiA+IEtvZW4uDQo+ID4NCj4gPg0KPiA+ID4gaW4gdGhp cyBjb250ZXh0IHdlIHNob3VsZCB1c2UgRUNOIHRvIGRyaXZlIGEgQ0MgYWxnb3JpdGhtIGFuZCB3 ZQ0KPiBzaG91bGQNCj4gPiA+IGJlDQo+ID4gPiBjYXV0aW91cyB0byBhdm9pZCByZXF1aXJpbmcg aXRzIHVzZSB3aXRoaW4gYSBDaXJjdWl0IEJyZWFrZXIgLQ0KPiBvcHRpb25hbA0KPiA+ID4gdXNl LCBpZiB5b3UgdW5kZXJzdGFuZCBob3cgdG8gaW50ZXJwcmV0IGEgcmVhY3Rpb24gdG8gbWFueSBD RS1tYXJrcw0KPiBhcw0KPiA+ID4gZXhjZXNzaXZlIGNvbmdlc3Rpb24sIGFyZSBwZXJtaXR0ZWQu DQo+ID4gPg0KPiA+ID4gR29ycnkNCj4gPiA+DQo+ID4gPiA+IEFzIGZhciBhcyBJIHVuZGVyc3Rh bmQsIHRoaXMgZHJhZnQgaXMgcmVsYXRlZCB0byBjaXJjdWl0IGJyZWFrZXJzDQo+IGluDQo+ID4g PiA+IGVuZC1zeXN0ZW1zLCByaWdodD8NCj4gPiA+ID4NCj4gPiA+ID4gSXQgaXMgdGhlIGVuZCBz eXN0ZW0gdGhhdCBkZXRlcm1pbmVzIHRoZSB1c2Ugb2YgRUNOIChjdXJyZW50bHkNCj4gbWFya2lu Zw0KPiA+ID4gPiBub24tZWN0IGZvciBkcm9wIGFuZCBlY3QoMCkgZm9yIENsYXNzaWMgRUNOKS4N Cj4gPiA+ID4NCj4gPiA+ID4gSW4gTDRTIHdlIGRvbid0IHBsYW4gdG8gY2hhbmdlIHRoZSBiZWhh dmlvciBvZiBDbGFzc2ljIEVDTiwgYW5kDQo+IEFCRSdzDQo+ID4gPiA+IGJlaGF2aW9yIHNob3Vs ZCBiZSBjbG9zZSB0byBub24tQUJFIEVDTi4gU28gSSBndWVzcyB0aGVyZSBpcyBubw0KPiA+ID4g cHJvYmxlbSBvZg0KPiA+ID4gPiBkZXNjcmliaW5nIHRoZSBiZWhhdmlvciBvZiBob3cgYSBDbGFz c2ljIEVDTiBiYXNlZCBzZW5kZXIgd291bGQNCj4gPiA+IHJlc3BvbmQNCj4gPiA+ID4gdG9kYXku DQo+ID4gPiA+DQo+ID4gPiA+IEFzIHdlIG9ubHkgd2FudCB0byBzaWduaWZpY2FudGx5IGNoYW5n ZSB0aGUgbmV0d29yayBiZWhhdmlvciBvZg0KPiBlY3QoMSkNCj4gPiA+ID4gbWFya2luZywgY2Fu IHdlIHNvbHZlIHRoaXMgaXNzdWUgYnkgcmVjb21tZW5kaW5nIChvciBldmVuDQo+IHJlcXVpcmlu ZykNCj4gPiA+ID4gc2VuZGVycyB0byBtYXJrIG9ubHkgZWN0KDApIGFuZCBkZXNjcmliaW5nIHRo ZSBjbGFzc2ljIEVDTiBjaXJjdWl0DQo+ID4gPiA+IGJyZWFrZXI/IFdoZW4gTDRTIGdldHMgZGVm aW5lZCwgYWxzbyBhbiBMNFMgYmFzZWQgY2lyY3VpdCBicmVha2VyDQo+ID4gPiA+IGV4dGVuc2lv biBjYW4gYmUgZGVmaW5lZCBmb3Igc2VuZGVycyB0aGF0IHdhbnQgdG8gdXNlIHRoZSBMNFMNCj4g c2VydmljZQ0KPiA+ID4gPiAod2hlbiBzZW5kZXJzIHNlbmQgZWN0KDEpIHBhY2tldHMpLg0KPiA+ ID4gPg0KPiA+ID4gPiBSZWdhcmRzLA0KPiA+ID4gPiBLb2VuLg0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+IEZyb206IHRzdndn IFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4g PiA+IFdlbHpsDQo+ID4gPiA+PiBTZW50OiBtYWFuZGFnIDIwIGp1bmkgMjAxNiAxODozNg0KPiA+ ID4gPj4gVG86IEJsYWNrLCBEYXZpZA0KPiA+ID4gPj4gQ2M6IDxnb3JyeUBlcmcuYWJkbi5hYy51 az4gRmFpcmh1cnN0OyBNYWdudXMgV2VzdGVybHVuZDsgdHN2d2c7DQo+IElFVEYNCj4gPiA+ID4+ IEFWVENvcmUgV0c7IHJ0Y3dlYkBpZXRmLm9yZzsgQ29saW4gUGVya2lucw0KPiA+ID4gPj4gU3Vi amVjdDogUmU6IFt0c3Z3Z10gW3J0Y3dlYl0gW0FWVENPUkVdIFdHIExhc3QgQ2FsbCBvbiBjaGFu Z2VzOg0KPiA+ID4gZHJhZnQtDQo+ID4gPiA+PiBpZXRmLWF2dGNvcmUtcnRwLWNpcmN1aXQtYnJl YWtlcnMtMTYNCj4gPiA+ID4+DQo+ID4gPiA+Pg0KPiA+ID4gPj4gPiBPbiAyMC4ganVuLiAyMDE2 LCBhdCAxNS4xNiwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPg0KPiA+ID4gd3Jv dGU6DQo+ID4gPiA+PiA+DQo+ID4gPiA+PiA+Pj4gQnV0IEnDouKCrOKEom0gbGVzcyBjb25jZXJu ZWQgdGhhbiBEYXZpZCBhYm91dCBldmVudHVhbGx5IGlnbm9yaW5nDQo+IGl0DQo+ID4gPiA+PiBm b3INCj4gPiA+ID4+IGNpcmN1aXQNCj4gPiA+ID4+ID4+IGJyZWFrZXIuDQo+ID4gPiA+PiA+Pj4N Cj4gPiA+ID4+ID4+IEFncmVlLiBMb3NzIGlzIHRoZSBtZWFzdXJlbWVudCB0aGF0IGEgQ0IgTVVT VCByZXNwb25kIHRvLg0KPiA+ID4gPj4gPg0KPiA+ID4gPj4gPiBNdW1ibGUuICAgSSB3b3VsZCBi ZSBvayB3aXRoIGEgY2xlYXIgZGlzY291cmFnZW1lbnQgZm9yIHVzZSBvZg0KPiBFQ04tDQo+ID4g PiBDRQ0KPiA+ID4gPj4gbWFya3MsIGFjY29tcGFuaWVkIGJ5IHRoZSBzb3J0IG9mIGRlc2lnbiBy YXRpb25hbGUgaGVyZSwgb3IgZXZlbg0KPiA+ID4gPj4gYmV0dGVyLA0KPiA+ID4gPj4gYSBjbGVh ciBzdGF0ZW1lbnQgdGhhdCBsb3N0IHBhY2tldHMgZm9yIHRoZSBwdXJwb3NlIG9mIHRoZSBSVFAN Cj4gPiA+IGNpcmN1aXQNCj4gPiA+ID4+IGJyZWFrZXIgaGF2ZSB0byBiZSBhY3R1YWxseSBsb3N0 IHdpdGhvdXQgZ2V0dGluZyBpbnRvIHdoZXRoZXIgb3INCj4gbm90DQo+ID4gPiA+PiBFQ04tQ0Ug bWFya3MgYXJlIGludm9sdmVkIC1pLmUuLCB0aGUgUlRQIGNpcmN1aXQgYnJlYWtlciBpcw0KPiBz cGVjaWZpZWQNCj4gPiA+ID4+IGFnYWluc3QgYWN0dWFsIGRyb3BzIGFzIGEgbmV0d29yayBwcm90 ZWN0aW9uIGJhY2tzdG9wLg0KPiA+ID4gPj4gPg0KPiA+ID4gPj4gPiBBIHJlbGF0ZWQgY29uY2Vy biBpcyB0aGF0IEVDTiBtYXJrcyBtYXkgb3ZlcnN0YXRlIGVxdWl2YWxlbnQNCj4gbG9zcw0KPiA+ ID4gPj4gYmVoYXZpb3IgLSBhIHNpbXBsaXN0aWMgcXVldWUgbWFuYWdlbWVudCBkaXNjaXBsaW5l IHRoYXQgbWFya3MNCj4gZXZlcnkNCj4gPiA+ID4+IHBhY2tldCB3aGVuIHRoZSBxdWV1ZSBpcyBv dmVyIGEgdGhyZXNob2xkIChOQjogdGhpcyBjbGFzcyBvZg0KPiBtYXJraW5nDQo+ID4gPiA+PiBi ZWhhdmlvciBpcyBOT1QgUkVDT01NRU5ERUQgLSBhIHJlYWwgQVFNIFNIT1VMRCBiZSB1c2VkKSBj b3VsZA0KPiB5aWVsZA0KPiA+ID4gYQ0KPiA+ID4gPj4gcnVuIG9mIEVDTi1DRSBtYXJrcyB0aGF0 IHdvdWxkIG5vdCBjYXVzZSBhIGNvcnJlc3BvbmRpbmcgd2l0aCBhDQo+IHJ1bg0KPiA+ID4gb2YN Cj4gPiA+ID4+IHBhY2tldCBkcm9wcy4gICBUaGlzIGlzIGFtb25nIHRoZSByZWFzb25zIHRoYXQg VENQIHJlYWN0cyB0byBFQ04tDQo+IENFDQo+ID4gPiA+PiBtYXJrcyBvbmx5IG9uY2UgcGVyIFJU VCwgYW5kIG1pZ2h0IGJlIGEgcmVhc29uIHRvIHRyZWF0IG11bHRpcGxlDQo+IEVDTi0NCj4gPiA+ IENFDQo+ID4gPiA+PiBtYXJrcyBpbiBhbiBSVFQgaW50ZXJ2YWwgYXMgbm90IHJlcHJlc2VudGlu ZyBkcm9wcyBvZiBhbGwgcGFja2V0cw0KPiBmb3INCj4gPiA+ID4+IHRoZSBSVFAgY2lyY3VpdCBi cmVha2VyJ3MgVENQLWVxdWl2YWxlbnQgdGhyb3VnaHB1dCBjYWxjdWxhdGlvbi4NCj4gPiA+ID4+ DQo+ID4gPiA+PiBJw6LigqzihKJtIG5vdCBzdXJlIHdlIG5lZWQgc3VjaCBjb21wbGljYXRlZCBs b2dpYyB0byBmaW5kIGEgY2FzZQ0KPiB3aGVyZQ0KPiA+ID4gRUNODQo+ID4gPiA+PiBtYXJrcyBh cmUgZGlmZmVyZW50IGZyb20gcGFja2V0IGRyb3BzOg0KPiA+ID4gPj4NCj4gPiA+ID4+IEJhc2lj YWxseSwgdGhleSBzaW1wbHkgYXJlbsOi4oKs4oSidCAtIGV2ZW4gw6LigqzFk3JlYWzDouKCrMKd IEFRTXMgbWFya2luZw0KPiA+ID4gaXNuw6LigqzihKJ0DQo+ID4gPiA+PiBleGFjdGx5DQo+ID4g PiA+PiB0aGUgc2FtZSBhcyBhIHBhY2tldCBkcm9wOiB0aGUgbWFya3MgdGhlbXNlbHZlcyBpbmZv cm0geW91IHRoYXQNCj4gYW4NCj4gPiA+IEFRTQ0KPiA+ID4gPj4gZGlkIGl0cyBqb2IsIGFuZCB3 aXRoIG1vZGVybiBBUU1zIGxpa2UgQ29EZWwgLyBQSUUgZXRjLiwgeW91w6LigqzihKJyZQ0KPiA+ ID4gPj4gcHJvYmFibHkNCj4gPiA+ID4+IGdldHRpbmcgdGhpcyBmcm9tIGEgc2hhbGxvdyBxdWV1 ZS4gQ2hhbmNlcyBhcmUgdGhhdCB0aGlzIGlzIGxlc3MNCj4gdGhhbg0KPiA+ID4gYQ0KPiA+ID4g Pj4gQkRQIHdvcnRoIG9mIHF1ZXVpbmcsIHdoaWNoIGlzIG91ciBqdXN0aWZpY2F0aW9uIGZvciBy ZWNvbW1lbmRpbmcNCj4gYQ0KPiA+ID4gPj4gZGlmZmVyZW50IGJhY2stb2ZmIGJlaGF2aW9yIGlu IGRyYWZ0LWtoYWRlbWktdHN2d2ctZWNuLXJlc3BvbnNlLQ0KPiAwMA0KPiA+ID4gYW5kDQo+ID4g PiA+PiBkcmFmdC1raGFkZW1pLXRjcG0tYWx0ZXJuYXRpdmViYWNrb2ZmLWVjbi0wMA0KPiA+ID4g Pj4NCj4gPiA+ID4+IFNvIHRoZSBwb2ludCBpcyBub3QgdGhhdCBBUU1zIHdvdWxkIHRyZWF0IEVD TiBtYXJraW5nIGFuZA0KPiBkcm9wcGluZw0KPiA+ID4gPj4gZGlmZmVyZW50bHkgLSBpdMOi4oKs 4oSicyB0aGF0IEVDTiBpbmRpY2F0ZXMgYW4gQVFNLCBhbmQgaGVuY2UNCj4gcHJvYmFibHkgYQ0K PiA+ID4gPj4gc2hhbGxvdyBxdWV1ZS4gV2l0aCBhIGRyb3AsIHlvdSBqdXN0IGRvbsOi4oKs4oSi dCBrbm93Lg0KPiA+ID4gPj4NCj4gPiA+ID4+IEJhY2sgdG8gdGhlIENCLCBJIHRoaW5rIGFuIEFR TSBtYXJraW5nIGF0IGEgc2hhbGxvdyBxdWV1ZSAobGlrZQ0KPiBlLmcuDQo+ID4gPiA+PiBDb0Rl bCkgaXMgaW5kZWVkIHF1aXRlIGRpZmZlcmVudCBmcm9tIGEgw6LigqzFk2Jyb2tlbiBjb25uZWN0 aW9uw6LigqzCnS4NCj4gPiA+ID4+DQo+ID4gPiA+PiBDaGVlcnMsDQo+ID4gPiA+PiBNaWNoYWVs DQo+ID4gPiA+Pg0KPiA+ID4gPj4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4gVGhhbmtzLCAtLURh dmlkDQo+ID4gPiA+PiA+DQo+ID4gPiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+ID4gPj4gPj4gRnJvbTogR29ycnkgKGVyZykgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51 a10NCj4gPiA+ID4+ID4+IFNlbnQ6IFNhdHVyZGF5LCBKdW5lIDE4LCAyMDE2IDI6MjMgQU0NCj4g PiA+ID4+ID4+IFRvOiBNaXJqYSBLw4PCvGhsZXdpbmQNCj4gPiA+ID4+ID4+IENjOiBCbGFjaywg RGF2aWQ7IE1hZ251cyBXZXN0ZXJsdW5kOyBDb2xpbiBQZXJraW5zOw0KPiA+ID4gcnRjd2ViQGll dGYub3JnOw0KPiA+ID4gPj4gSUVURg0KPiA+ID4gPj4gPj4gQVZUQ29yZSBXRzsgdHN2d2cNCj4g PiA+ID4+ID4+IFN1YmplY3Q6IFJlOiBbdHN2d2ddIFtydGN3ZWJdIFtBVlRDT1JFXSBXRyBMYXN0 IENhbGwgb24NCj4gY2hhbmdlczoNCj4gPiA+ID4+IGRyYWZ0LWlldGYtDQo+ID4gPiA+PiA+PiBh dnRjb3JlLXJ0cC1jaXJjdWl0LWJyZWFrZXJzLTE2DQo+ID4gPiA+PiA+Pg0KPiA+ID4gPj4gPj4g SSB0aGluayB3ZSBTSE9VTEQgTk9UIHJlY29tbWVuZCB0byB1c2UgRUNOIG1hcmtzIGFzIGlucHV0 cyB0bw0KPiBhDQo+ID4gPiBDQi4NCj4gPiA+ID4+IFNlZQ0KPiA+ID4gPj4gPj4gYmVsb3c6DQo+ ID4gPiA+PiA+Pg0KPiA+ID4gPj4gPj4+IE9uIDE3IEp1biAyMDE2LCBhdCAxNjowMiwgTWlyamEg S8ODwrxobGV3aW5kDQo+ID4gPiA+PiA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4N Cj4gPiA+ID4+ID4+IHdyb3RlOg0KPiA+ID4gPj4gPj4+DQo+ID4gPiA+PiA+Pj4gKzEgdG8gbm90 IHVzZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaGVyZS4NCj4gPiA+ID4+ID4+Pg0KPiA+ID4gPj4gPj4+ IEhvd2V2ZXIsIHBsZWFzZSBub3RlIHRoYXQgaGF2aW5nIGEgaGlnaCBsZXZlbCBvZiBFQ04tQ0Ug bWFya3MNCj4gPiA+ID4+ICh3aXRob3V0IGFueQ0KPiA+ID4gPj4gPj4gbG9zc2VzKSBtZWFucyB0 aGF0IGFsbCBwYWNrZXRzIHdlcmUgcmVjZWl2ZWQgY29ycmVjdGx5LiBUaGlzDQo+ID4gPiA+PiBz aXR1YXRpb24gY2FuIGV2ZW4NCj4gPiA+ID4+ID4+IG9jY3VycyB3aXRob3V0IGhpZ2ggZGVsYXlz IChkZXBlbmRpbmcgb24gdGhlIEFRTSB1c2VkKSwgd2hpY2gNCj4gPiA+IHdvdWxkDQo+ID4gPiA+ PiBqdXN0DQo+ID4gPiA+PiA+PiBtZWFuIHRoZSBzZXJ2aWNlcyB3b3JrcyBwZXJmZWN0bHkuIFRo ZXJlZm9yZSBmb3IgbWUgQ0UgbWFya3MNCj4gYXJlIGENCj4gPiA+ID4+IHBlcmZlY3QgaW5wdXQN Cj4gPiA+ID4+ID4+IHNpZ25hbCBmb3IgYSBjb25nZXN0aW9uIGNvbnRyb2wgbG9vcCAod2hlcmUg dGhlIEFRTSB0ZWxsIHRoZQ0KPiA+ID4gc2VuZGVyDQo+ID4gPiA+PiB0byB0YWtlIGFjdGlvbg0K PiA+ID4gPj4gPj4gLSB3aGF0ZXZlciB0aGF0IG1lYW5zKS4NCj4gPiA+ID4+ID4+DQo+ID4gPiA+ PiA+PiBXZSBtYXkgaW4gZnV0dXJlIGZpZ3VyZSBvdXQgd2F5cyB0byBkbyB0aGlzIHRvIGRldGVj dA0KPiBzaWduaWZpY2FudA0KPiA+ID4gPj4gZmFpbHVyZSB1c2luZyBhDQo+ID4gPiA+PiA+PiBy YXRlIGFkYXB0aXZlIHRyYW5zcG9ydCBhbmQgRUNOIGUuZy4gIE9ic2VydmluZyAxMDAlIENFIG1h cmtzDQo+IG9yDQo+ID4gPiA+PiBzb21ldGhpbmcsIGZvcg0KPiA+ID4gPj4gPj4gYW4gUlRQIGZs b3cgdGhhdCBpcyB0cnlpbmcgdG8gc2VuZCB3ZWxsIGJlbG93IGl0cyBwZWFrIHJhdGUNCj4gPiA+ IGRlY2lkZWQNCj4gPiA+ID4+IGJ5IENDIC0tIGJ1dCBJDQo+ID4gPiA+PiA+PiB0aGluayB0aGlz IGlzIHNwZWN1bGF0aW5nIGF0IGFuIGFsZ29yaXRobSBhbmQgYWRkaW5nIGRldGFpbHMNCj4gaGVy ZQ0KPiA+ID4gaXMNCj4gPiA+ID4+IG5vdCBhIGdvb2QgaWRlYS4NCj4gPiA+ID4+ID4+IEVzcGVj aWFsbHkgYXMgQVFNIGNvbnRpbnVlcyB0byBldm9sdmUuDQo+ID4gPiA+PiA+Pg0KPiA+ID4gPj4g Pj4+IEJ1dCBJw6LigqzihKJtIGxlc3MgY29uY2VybmVkIHRoYW4gRGF2aWQgYWJvdXQgZXZlbnR1 YWxseSBpZ25vcmluZw0KPiBpdA0KPiA+ID4gPj4gZm9yDQo+ID4gPiA+PiBjaXJjdWl0DQo+ID4g PiA+PiA+PiBicmVha2VyLg0KPiA+ID4gPj4gPj4+DQo+ID4gPiA+PiA+PiBBZ3JlZS4gTG9zcyBp cyB0aGUgbWVhc3VyZW1lbnQgdGhhdCBhIENCIE1VU1QgcmVzcG9uZCB0by4NCj4gPiA+ID4+ID4+ DQo+ID4gPiA+PiA+Pj4gSW4gYWRkaXRpb24gb25lIHBvaW50IG9uIHNvbWV0aGluZyBNYWdudXMg d3JvdGUgZWFybGllcjoNCj4gPiA+ID4+ID4+PiAiSWYgdGhlIGltcGxlbWVudGF0aW9uIG9ubHkg aGF2ZSBjaXJjdWl0IGJyZWFrZXIsIGkuZS4gbm8NCj4gZnVsbA0KPiA+ID4gPj4gZmxlZGdlZCBj b25nZXN0aW9uDQo+ID4gPiA+PiA+PiBjb250cm9sbGVyIGFuZCB1c2VzIEVDTiwgdGhleSBjYW4g aW4gd29yc3QgY2FzZSBkcml2ZSB0aGUNCj4gYnVmZmVyDQo+ID4gPiA+PiBpbnRvDQo+ID4gPiA+ PiB0aGUgb3ZlcmxvYWQNCj4gPiA+ID4+ID4+IHJlZ2ltZSB3aGVyZSBpdCBzdGFydHMgZHJvcHBp bmcgcGFja2V0cy4gw6LigqzFvg0KPiA+ID4gPj4gPj4+DQo+ID4gPiA+PiA+Pj4gScOi4oKs4oSi bSBub3Qgc3VyZSBhYm91dCB0aGlzIGNhc2UuIEVDTiBpcyBhbiBpbnB1dCBzaWduYWwgZm9yDQo+ ID4gPiA+PiBjb25nZXN0aW9uDQo+ID4gPiA+PiBjb250cm9sLiBJZiB5b3UNCj4gPiA+ID4+ID4+ IGRvbsOi4oKs4oSidCB1c2UgY29uZ2VzdGlvbiBjb250cm9sIGJ1dCBvbmx5IGEgY2lyY3VpdCBi cmVha2VyLCB5b3UNCj4gPiA+ID4+IHNob3VsZA0KPiA+ID4gPj4gcHJvYmFibHkgbm90DQo+ID4g PiA+PiA+PiBlbmFibGUgRUNOLiBBdCBsZWFzdCBpdCBub3QgY2xlYXIgdG8gbWUgd2h5IHlvdSB3 b3VsZCBlbmFibGUNCj4gaXQsDQo+ID4gPiBhbmQNCj4gPiA+ID4+IGl0J3MgZGVmaW5pdGVseQ0K PiA+ID4gPj4gPj4gbm90IGNvbmZvcm0gdG8gdGhlIEVDTiBzcGVjLiBQcm9iYWJseSB3ZSBzaG91 bGQgc2F5IHNvbWV0aGluZw0KPiA+ID4gYWJvdXQNCj4gPiA+ID4+IHRoaXMgaW4gdGhlDQo+ID4g PiA+PiA+PiBkcmFmdC4uLj8NCj4gPiA+ID4+ID4+Pg0KPiA+ID4gPj4gPj4gQWdyZWUsIGVuYWJs aW5nIEVDTiB3aXRob3V0IGEgcmVzcG9uc2l2ZSBDQyBpcyBnb2luZyB0byBsZWFkDQo+IHRvDQo+ ID4gPiA+PiB0cm91YmxlLg0KPiA+ID4gPj4gPj4NCj4gPiA+ID4+ID4+PiBNaXJqYQ0KPiA+ID4g Pj4gPj4+DQo+ID4gPiA+PiA+PiBHb3JyeQ0KPiA+ID4gPj4gPj4NCj4gPiA+ID4+ID4+Pj4gQW0g MTcuMDYuMjAxNiB1bSAxNjowMyBzY2hyaWViIEJsYWNrLCBEYXZpZA0KPiA+ID4gPGRhdmlkLmJs YWNrQGVtYy5jb20+Og0KPiA+ID4gPj4gPj4+Pg0KPiA+ID4gPj4gPj4+PiBDb2xpbiwNCj4gPiA+ ID4+ID4+Pj4NCj4gPiA+ID4+ID4+Pj4+Pj4gLi4uICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBh cyBwcm92aWRpbmcgaW1wbGVtZW50ZXJzDQo+IHdpdGgNCj4gPiA+IHRvbw0KPiA+ID4gPj4gbXVj aA0KPiA+ID4gPj4gPj4+Pj4+PiBsYXRpdHVkZSB0byBpZ25vcmUgRUNOLUNFIG1hcmtzIChlLmcu LCBiZWNhdXNlIGFuDQo+IGltcGxlbWVudGVyDQo+ID4gPiA+PiBkb2Vzbid0DQo+ID4gPiA+PiA+ Pj4+Pj4+IHdhbnQgdG8gdGhpbmsgYWJvdXQgdGhpcyBwcm9ibGVtIHNwYWNlIGluIHRoZSBmaXJz dA0KPiBwbGFjZSkuDQo+ID4gPiA+PiA+Pj4+Pg0KPiA+ID4gPj4gPj4+Pj4gSSBhZ3JlZSwgYnV0 IHRoZSBhcmd1bWVudCBpcyB0aGF0IGRvaW5nIHNvIGlzIGxlc3MgaGFybWZ1bA0KPiB0aGFuDQo+ ID4gPiA+PiBkZXBsb3lpbmcgYQ0KPiA+ID4gPj4gPj4gY2lyY3VpdA0KPiA+ID4gPj4gPj4+Pj4g YnJlYWtlciB0aGF0IHRyaWdnZXJzIHRvbyBvZnRlbiB3aGVuIEVDTiBpcyB1c2VkLg0KPiA+ID4g Pj4gPj4+Pj4NCj4gPiA+ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IHN1cmUgSSBiZWxpZXZlIHRo aXMgYXJndW1lbnQsIHRob3VnaCwgc2luY2UgaXQNCj4gc2VlbXMNCj4gPiA+ID4+IHRoYXQNCj4g PiA+ID4+IGFueSBuZXcNCj4gPiA+ID4+ID4+IEFRTQ0KPiA+ID4gPj4gPj4+Pj4gdGhhdCBhcHBs aWVzIEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhhbiBhdCBwcmVzZW50IHdpbGwNCj4gPiA+ IGhhdmUNCj4gPiA+ID4+IHRvDQo+ID4gPiA+PiA+PiBjb25zaWRlcg0KPiA+ID4gPj4gPj4+Pj4g YmFja3dhcmRzIGNvbXBhdGliaWxpdHksIHRvIHdvcmsgd2l0aCBkZXBsb3llZCBUQ1AgKGUuZy4s DQo+ID4gPiBkcmFmdC0NCj4gPiA+ID4+IGJyaXNjb2UtDQo+ID4gPiA+PiA+PiB0c3Z3Zy0NCj4g PiA+ID4+ID4+Pj4+IGFxbS10Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVzZXMgRUNUKDEpIGFzIGEg c2lnbmFsIHRvIHVzZQ0KPiB0aGUNCj4gPiA+IG5ldw0KPiA+ID4gPj4gbWFya2luZywNCj4gPiA+ ID4+ID4+Pj4+IHdoaWxlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDApKS4gVGhl c2UNCj4gY29tcGF0aWJpbGl0eQ0KPiA+ID4gPj4gbWVjaGFuaXNtcw0KPiA+ID4gPj4gPj4+Pj4g d291bGQgc2VlbSB0byBwcmV2ZW50IHRoZSBpc3N1ZXMgd2l0aCB0aGUgY2lyY3VpdCBicmVha2Vy DQo+IHRvby4NCj4gPiA+ID4+ID4+Pj4NCj4gPiA+ID4+ID4+Pj4gVGhhdCByb3VnaGx5IG1hdGNo ZXMgbXkgbGluZSBvZiB0aGlua2luZywgYW5kIEknbGwgb2JzZXJ2ZQ0KPiB0aGF0DQo+ID4gPiA+ PiB0aGUNCj4gPiA+ID4+IG9yaWdpbmFsDQo+ID4gPiA+PiA+PiBEQ1RDUA0KPiA+ID4gPj4gPj4+ PiBwcm90b2NvbCBkZXNpZ24gdGhhdCB1c2VkIG1vcmUgYWdncmVzc2l2ZSBFQ04tQ0UgbWFya2lu ZyB3YXMNCj4gPiA+IG9ubHkNCj4gPiA+ID4+IHNhZmUgZm9yDQo+ID4gPiA+PiA+Pj4+IENvbnRy b2xsZWQgRW52aXJvbm1lbnQgZGVwbG95bWVudHMuICAgU2VlIHRoZSBUU1ZXRw0KPiByZmM1NDA1 YmlzDQo+ID4gPiA+PiBkcmFmdCBmb3INCj4gPiA+ID4+ID4+IHRoZQ0KPiA+ID4gPj4gPj4+PiBk ZWZpbml0aW9uIG9mIENvbnRyb2xsZWQgRW52aXJvbm1lbnQsIGFuZCBpZ25vcmUgdGhlIGZhY3QN Cj4gdGhhdA0KPiA+ID4gdGhlDQo+ID4gPiA+PiByZmM1NDA1YmlzDQo+ID4gPiA+PiA+Pj4+IGRy YWZ0IGlzIGEgVURQIGRyYWZ0IC0gdGhpcyBkZWZpbml0aW9uIGlzIG1vcmUgYnJvYWRseQ0KPiA+ ID4gYXBwbGljYWJsZS4NCj4gPiA+ID4+ID4+Pj4NCj4gPiA+ID4+ID4+Pj4gR29pbmcgYmFjayBv dmVyIFNlY3Rpb24gNyBpbiB0aGlzIGF2dGNvcmUgZHJhZnQsIG15IHZpZXdzDQo+IGFyZToNCj4g PiA+ID4+ID4+Pj4NCj4gPiA+ID4+ID4+Pj4gW0FdIE5vbmUgb2YgdGhlc2UgZHJhZnRzIGp1c3Rp ZnkgYSAiTUFZIGlnbm9yZSIgcmVzcG9uc2UgdG8NCj4gRUNOLQ0KPiA+ID4gQ0UNCj4gPiA+ID4+ IG1hcmtzOg0KPiA+ID4gPj4gPj4+PiAgIC0gZHJhZnQta2hhZGVtaS10Y3BtLWFsdGVybmF0aXZl YmFja29mZi1lY24NCj4gPiA+ID4+ID4+Pj4gICAtIGRyYWZ0LWlldGYtcm1jYXQtbmFkYQ0KPiA+ ID4gPj4gPj4+PiAgIC0gZHJhZnQtaWV0Zi1ybWNhdC1zY3JlYW0tY2MNCj4gPiA+ID4+ID4+Pj4N Cj4gPiA+ID4+ID4+Pj4gW0JdIEluIGxpbmUgd2l0aCBDb2xpbidzIGNvbW1lbnQgb24gdGhlIEw0 UyBkcmFmdCwgSSB0aGluaw0KPiBpdCdzDQo+ID4gPiA+PiBpbmN1bWJlbnQgb24NCj4gPiA+ID4+ ID4+Pj4gdGhlIGF1dGhvcnMgb2YgZHJhZnQtYnJpc2NvZS1hcW0tZHVhbHEtY291cGxlZCB0byBm aWd1cmUgb3V0DQo+IGhvdw0KPiA+ID4gPj4gdGhhdCB3aWxsDQo+ID4gPiA+PiA+Pj4+IGNvZXhp c3QgKG9yIGF2b2lkKSBkZXBsb3llZCBUQ1AsIGFuZCB0aGlzIGF2dGNvcmUgZHJhZnQNCj4gb3Vn aHQNCj4gPiA+IG5vdA0KPiA+ID4gPj4gdG8gYmUNCj4gPiA+ID4+ID4+Pj4gdHJ5aW5nIHRvIHBy ZWp1ZGdlIHdoYXQgd2lsbCBiZSBkb25lIHRoZXJlLg0KPiA+ID4gPj4gPj4+Pg0KPiA+ID4gPj4g Pj4+PiBTbywgSSBkb24ndCB0aGluayB0aGUgY3VycmVudCB0ZXh0IGluIFNlY3Rpb24gNyBoYXMN Cj4ganVzdGlmaWVkDQo+ID4gPiB0aGUNCj4gPiA+ID4+IHVuZmV0dGVyZWQNCj4gPiA+ID4+ID4+ Pj4gImltcGxlbWVudGF0aW9ucyBNQVkgaWdub3JlIEVDTi1DRSBtYXJrcyIgdGV4dCwgYXMgaWdu b3JpbmcNCj4gPiA+IHRob3NlDQo+ID4gPiA+PiBtYXJrcw0KPiA+ID4gPj4gPj4+PiBpcyBub3Qg Y29uc2lzdGVudCB3aXRoIGFueSBvZiB0aGUgZm91ciBjaXRlZCBkcmFmdHMuDQo+ID4gPiA+PiA+ Pj4+DQo+ID4gPiA+PiA+Pj4+IEluIG1vcmUgZGV0YWlsLCBJIHRoaW5rIG1ha2luZyBjaGFuZ2Vz IHRvIG5vcm1hdGl2ZQ0KPiByZXF1aXJlbWVudHMNCj4gPiA+ID4+IGhlcmUgYmFzZWQNCj4gPiA+ ID4+ID4+Pj4gb24gW0JdIGlzIHByZW1hdHVyZSwgYW5kIEkgd291bGQgaG9wZSB0aGF0IHRoZSBy bWNhdCBXRw0KPiBjb3VsZCBiZQ0KPiA+ID4gPj4gPj4gZW5jb3VyYWdlZA0KPiA+ID4gPj4gPj4+ PiB0byBjb25zaWRlciB0aGUgUlRQIGNpcmN1aXQgYnJlYWtlciBpbiBpdHMgY29uZ2VzdGlvbg0K PiBjb250cm9sDQo+ID4gPiA+PiBkcmFmdHMsIGFzIHRob3NlIENDDQo+ID4gPiA+PiA+Pj4+IG1l Y2hhbmlzbXMgYXJlIHJlbGF0ZWQgdG8gdGhlIGNpcmN1aXQgYnJlYWtlciBtZWNoYW5pc20sDQo+ IGhlbmNlDQo+ID4gPiA+PiBsaWtlbHkNCj4gPiA+ID4+ID4+Pj4gdG8gYmUgaW4gcmVsYXRlZCBh cmVhcyBvZiBhbiBSVFAgaW1wbGVtZW50YXRpb24uDQo+ID4gPiA+PiA+Pj4+DQo+ID4gPiA+PiA+ Pj4+IFRoYXQgbGVhdmVzIGRyYWZ0LWtoYWRlbWktdGNwbS1hbHRlcm5hdGl2ZWJhY2tvZmYtZWNu LCB3aGljaA0KPiA+ID4gVFNWV0cNCj4gPiA+ID4+ID4+Pj4gd2lsbCBiZSBsb29raW5nIGF0IGlu IEJlcmxpbi4gIElmIGEgbm9ybWF0aXZlIHN0YXRlbWVudA0KPiBhYm91dA0KPiA+ID4gRUNOLQ0K PiA+ID4gPj4gQ0UgcmVhY3Rpb24NCj4gPiA+ID4+ID4+Pj4gaXMgZ29pbmcgdG8gcmVzdCBvbiB0 aGF0IGRyYWZ0LCB0aGVuIHRoZSByZWZlcmVuY2UgdG8gdGhhdA0KPiBkcmFmdA0KPiA+ID4gPj4g c2hvdWxkIGJlDQo+ID4gPiA+PiA+Pj4+IG5vcm1hdGl2ZS4gIFNvbWV0aGluZyBhYm91dCBkb2lu ZyB0aGF0IHN0cmlrZXMgbWUgYXMNCj4gcHJlbWF0dXJlDQo+ID4gPiAuLi4NCj4gPiA+ID4+ID4+ Pj4NCj4gPiA+ID4+ID4+Pj4gSSByZWFsaXplIHRoYXQgd2UncmUgdHJ5aW5nIHRvIHByZWRpY3Qg YW5kIGFjY29tbW9kYXRlIHRoZQ0KPiA+ID4gZnV0dXJlLA0KPiA+ID4gPj4gd2hpY2gNCj4gPiA+ ID4+ID4+Pj4gaXMgYW4gaW1wcmVjaXNlIHVuZGVydGFraW5nIGF0IGJlc3QuICAgQXMgYW4gYWx0 ZXJuYXRpdmUgdG8NCj4gdGhlDQo+ID4gPiA+PiBjdXJyZW50IHRleHQsDQo+ID4gPiA+PiA+Pj4+ IHdvdWxkIGl0IGJlIHJlYXNvbmFibGUgdG8gc2F5ICh3aXRob3V0IGFueSBSRkMgMjExOQ0KPiBr ZXl3b3JkcykNCj4gPiA+IHRoYXQNCj4gPiA+ID4+IHRoZQ0KPiA+ID4gPj4gPj4+PiBiZXN0IGN1 cnJlbnQgZ3VpZGFuY2UgaXMgc3RpbGwgdG8gdHJlYXQgRUNOLUNFIG1hcmtzIGFzDQo+ID4gPiBp bmRpY2F0aW5nDQo+ID4gPiA+PiBkcm9wcywNCj4gPiA+ID4+ID4+Pj4gd2l0aCBhIHdhcm5pbmcg dGhhdCB0aGVyZSBpcyBhIGdvb2QgcG9zc2liaWxpdHkgb2YgdGhpcw0KPiBjaGFuZ2luZw0KPiA+ ID4gPj4gaW4NCj4gPiA+ID4+IHRoZQ0KPiA+ID4gPj4gPj4+PiBuZWFyIGZ1dHVyZSBkdWUgdG8g YWxsIG9mIHRoZSB3b3JrIGluIHByb2dyZXNzIGNpdGVkIGluDQo+IFNlY3Rpb24NCj4gPiA+IDc/ DQo+ID4gPiA+PiA+Pj4+DQo+ID4gPiA+PiA+Pj4+IFRoYW5rcywgLS1EYXZpZA0KPiA+ID4gPj4g Pj4+Pg0KPiA+ID4gPj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+ ID4+Pj4+IEZyb206IENvbGluIFBlcmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10NCj4g PiA+ID4+ID4+Pj4+IFNlbnQ6IEZyaWRheSwgSnVuZSAxNywgMjAxNiA2OjE0IEFNDQo+ID4gPiA+ PiA+Pj4+PiBUbzogSm9obiBMZXNsaWU7IEJsYWNrLCBEYXZpZA0KPiA+ID4gPj4gPj4+Pj4gQ2M6 IHJ0Y3dlYkBpZXRmLm9yZzsgSUVURiBBVlRDb3JlIFdHOyB0c3Z3Zw0KPiA+ID4gPj4gPj4+Pj4g U3ViamVjdDogUmU6IFtydGN3ZWJdIFtBVlRDT1JFXSBbdHN2d2ddIFdHIExhc3QgQ2FsbCBvbg0K PiA+ID4gY2hhbmdlczoNCj4gPiA+ID4+IGRyYWZ0LWlldGYtDQo+ID4gPiA+PiA+Pj4+PiBhdnRj b3JlLXJ0cC1jaXJjdWl0LWJyZWFrZXJzLTE2DQo+ID4gPiA+PiA+Pj4+Pg0KPiA+ID4gPj4gPj4+ Pj4NCj4gPiA+ID4+ID4+Pj4+PiBPbiAxNiBKdW4gMjAxNiwgYXQgMjM6MjUsIEpvaG4gTGVzbGll IDxqb2huQGpsYy5uZXQ+DQo+IHdyb3RlOg0KPiA+ID4gPj4gPj4+Pj4+DQo+ID4gPiA+PiA+Pj4+ Pj4gQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPiB3cm90ZToNCj4gPiA+ID4+ID4+ Pj4+Pj4NCj4gPiA+ID4+ID4+Pj4+Pj4gLi4uICBJIHZpZXcgdGhlIGN1cnJlbnQgdGV4dCBhcyBw cm92aWRpbmcgaW1wbGVtZW50ZXJzDQo+IHdpdGgNCj4gPiA+IHRvbw0KPiA+ID4gPj4gbXVjaA0K PiA+ID4gPj4gPj4+Pj4+PiBsYXRpdHVkZSB0byBpZ25vcmUgRUNOLUNFIG1hcmtzIChlLmcuLCBi ZWNhdXNlIGFuDQo+IGltcGxlbWVudGVyDQo+ID4gPiA+PiBkb2Vzbid0DQo+ID4gPiA+PiA+Pj4+ Pj4+IHdhbnQgdG8gdGhpbmsgYWJvdXQgdGhpcyBwcm9ibGVtIHNwYWNlIGluIHRoZSBmaXJzdA0K PiBwbGFjZSkuDQo+ID4gPiA+PiA+Pj4+Pg0KPiA+ID4gPj4gPj4+Pj4gSSBhZ3JlZSwgYnV0IHRo ZSBhcmd1bWVudCBpcyB0aGF0IGRvaW5nIHNvIGlzIGxlc3MgaGFybWZ1bA0KPiB0aGFuDQo+ID4g PiA+PiBkZXBsb3lpbmcgYQ0KPiA+ID4gPj4gPj4gY2lyY3VpdA0KPiA+ID4gPj4gPj4+Pj4gYnJl YWtlciB0aGF0IHRyaWdnZXJzIHRvbyBvZnRlbiB3aGVuIEVDTiBpcyB1c2VkLg0KPiA+ID4gPj4g Pj4+Pj4NCj4gPiA+ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IHN1cmUgSSBiZWxpZXZlIHRoaXMg YXJndW1lbnQsIHRob3VnaCwgc2luY2UgaXQNCj4gc2VlbXMNCj4gPiA+ID4+IHRoYXQNCj4gPiA+ ID4+IGFueSBuZXcNCj4gPiA+ID4+ID4+IEFRTQ0KPiA+ID4gPj4gPj4+Pj4gdGhhdCBhcHBsaWVz IEVDTiBtYXJrcyBtdWNoIG1vcmUgb2Z0ZW4gdGhhbiBhdCBwcmVzZW50IHdpbGwNCj4gPiA+IGhh dmUNCj4gPiA+ID4+IHRvDQo+ID4gPiA+PiA+PiBjb25zaWRlcg0KPiA+ID4gPj4gPj4+Pj4gYmFj a3dhcmRzIGNvbXBhdGliaWxpdHksIHRvIHdvcmsgd2l0aCBkZXBsb3llZCBUQ1AgKGUuZy4sDQo+ ID4gPiBkcmFmdC0NCj4gPiA+ID4+IGJyaXNjb2UtDQo+ID4gPiA+PiA+PiB0c3Z3Zy0NCj4gPiA+ ID4+ID4+Pj4+IGFxbS10Y3BtLXJtY2F0LWw0cy1wcm9ibGVtIHVzZXMgRUNUKDEpIGFzIGEgc2ln bmFsIHRvIHVzZQ0KPiB0aGUNCj4gPiA+IG5ldw0KPiA+ID4gPj4gbWFya2luZywNCj4gPiA+ID4+ ID4+Pj4+IHdoaWxlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBzZXQgRUNUKDApKS4gVGhlc2UN Cj4gY29tcGF0aWJpbGl0eQ0KPiA+ID4gPj4gbWVjaGFuaXNtcw0KPiA+ID4gPj4gPj4+Pj4gd291 bGQgc2VlbSB0byBwcmV2ZW50IHRoZSBpc3N1ZXMgd2l0aCB0aGUgY2lyY3VpdCBicmVha2VyDQo+ IHRvby4NCj4gPiA+ID4+ID4+Pj4+DQo+ID4gPiA+PiA+Pj4+Pj4gVW5kZXJzdGFuZCwgd2UgaGF2 ZSBhdCBsZWFzdCB0d28gcHJvcG9zYWxzIHRvIG1ha2UgRUNOLUNFDQo+IG1vcmUNCj4gPiA+ID4+ ID4+IGZyZXF1ZW50DQo+ID4gPiA+PiA+Pj4+Pj4gdGhhbiBwYWNrZXQgZHJvcCB3b3VsZCBiZSBm b3Igbm9uLUVDTiBwYWNrZXRzOiBwb3NzaWJseQ0KPiA+ID4gPj4gc3Vic3RhbnRpYWxseQ0KPiA+ ID4gPj4gPj4+Pj4+IG1vcmUgZnJlcXVlbnQuIFVubGVzcyBib3RoIGFyZSBraWxsZWQgb2ZmLCBF Q04tQ0Ugd2lsbA0KPiBzaG93IHVwDQo+ID4gPiA+PiBmcmVxdWVudGx5DQo+ID4gPiA+PiA+Pj4+ Pj4gZW5vdWdoIHRoYXQgY2xvc2luZyB0aGUgZmxvdyBvbiBFQ04tQ0Ugd291bGQga2lsbCB0b28g bWFueQ0KPiA+ID4gPj4gY29ubmVjdGlvbnMuDQo+ID4gPiA+PiA+Pj4+Pj4NCj4gPiA+ID4+ID4+ Pj4+PiBJZiB5b3Ugd2FudCBjaXJjdWl0LWJyZWFraW5nIG9uIHN1Y2ggY29ubmVjdGlvbnMsIHRo ZXJlDQo+IGFyZQ0KPiA+ID4gdHdvDQo+ID4gPiA+PiB3YXlzOg0KPiA+ID4gPj4gPj4+Pj4+IDEu IGNvbnZpbmNlIHRoZSBmb3J3YXJkaW5nIG5vZGVzIHRvIGRyb3AgcGFja2V0cyBpZiB0aGVpcg0K PiA+ID4gcXVldWUNCj4gPiA+ID4+IGV4Y2VlZHMNCj4gPiA+ID4+ID4+Pj4+PiBkZXNpZ24gY2Fw YWNpdHk7IG9yDQo+ID4gPiA+PiA+Pj4+Pj4gMi4gcmVxdWlyZSB0aGUgc2VuZGVyIHRvIHNlbmQg ZW5vdWdoIG5vdC1FQ04tY2FwYWJsZQ0KPiBwYWNrZXRzDQo+ID4gPiBzbw0KPiA+ID4gPj4gdGhh dCBvdXINCj4gPiA+ID4+ID4+Pj4+PiByZWNlaXZlciB3aWxsIHNlZSBlbm91Z2ggcGFja2V0LWRy b3BzIHdoZW4gYSBjaXJjdWl0LQ0KPiBicmVha2VyDQo+ID4gPiA+PiBzaG91bGQNCj4gPiA+ID4+ ID4+Pj4+PiBhY3RpdmF0ZS4NCj4gPiA+ID4+ID4+Pj4+Pg0KPiA+ID4gPj4gPj4+Pj4+IChJIHBy ZWZlciB0aGUgZmlyc3Qgb3B0aW9uOyBidXQgSSB3b3VsZG4ndCBvYmplY3QgdG8gdGhlDQo+ID4g PiA+PiBzZWNvbmQuKQ0KPiA+ID4gPj4gPj4+Pj4+DQo+ID4gPiA+PiA+Pj4+Pj4gVGhlcmUgcmVh bGx5IGlzbid0IGFueSB3YXkgZm9yIG91ciBjaXJjdWl0LWJyZWFrZXIgdG8ga25vdw0KPiA+ID4g Pj4gX2hvd19tdWNoXw0KPiA+ID4gPj4gPj4+Pj4+IG1vcmUgZnJlcXVlbnQgdGhlIEVDTi1DRSBt YXJrcyBtYXkgYmUuIDpeKA0KPiA+ID4gPj4gPj4+Pj4NCj4gPiA+ID4+ID4+Pj4+IFRoaXMgaXMg YSBwcm9ibGVtLCBib3RoIGZvciB0aGUgY2lyY3VpdCBicmVha2VyLCBhbmQgZm9yDQo+IHRoZQ0K PiA+ID4gPj4gYWxnb3JpdGhtcyBiZWluZw0KPiA+ID4gPj4gPj4+Pj4gZGVmaW5lZCBpbiBSTUNB VC4gV2UgZG8gbmVlZCBzb21lIHVuZGVyc3RhbmRpbmcgd2hhdCB0aGUNCj4gPiA+IGV4cGVjdGVk DQo+ID4gPiA+PiA+PiBtYXJraW5nDQo+ID4gPiA+PiA+Pj4+PiByYXRlcyBhcmUgbGlrZWx5IHRv IGJlLCBzbyBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIGNpcmN1aXQNCj4gPiA+ID4+IGJyZWFrZXJz DQo+ID4gPiA+PiBjYW4gYmUNCj4gPiA+ID4+ID4+IGRlZmluZWQuDQo+ID4gPiA+PiA+Pj4+Pg0K PiA+ID4gPj4gPj4+Pj4+IFdlIF93aWxsXyBiZSBzb3JyeSBpZiB3ZQ0KPiA+ID4gPj4gPj4+Pj4+ IGFsbG90IHRoZSBzYW1lIGZyZXF1ZW5jeSBvZiBDRSBwYWNrZXRzIGFzIHBhY2tldC1kcm9wcyB0 bw0KPiA+ID4gPj4gdHJpZ2dlcg0KPiA+ID4gPj4gdGhlDQo+ID4gPiA+PiA+Pj4+Pj4gY2lyY3Vp dC1icmVha2VyLg0KPiA+ID4gPj4gPj4+Pj4+DQo+ID4gPiA+PiA+Pj4+Pj4+IENvdWxkIHNvbWVv bmUgcHJvcG9zZSBpbml0aWFsIHRleHQgdG8gcXVhbGlmaWVzIHRoZQ0KPiBjdXJyZW50DQo+ID4g PiA+PiAiTUFZDQo+ID4gPiA+PiBpZ25vcmUiDQo+ID4gPiA+PiA+Pj4+Pj4+IHN0YXRlbWVudD8N Cj4gPiA+ID4+ID4+Pj4+Pg0KPiA+ID4gPj4gPj4+Pj4+IEVzc2VudGlhbGx5LCBmb3IgdGhlIHNl Y29uZCBvcHRpb24sIHlvdSBtaWdodCBwcm9wb3NlIHRleHQNCj4gdG8NCj4gPiA+ID4+IHRoZQ0K PiA+ID4gPj4gPj4+Pj4+IGVmZmVjdCBvZjoNCj4gPiA+ID4+ID4+Pj4+PiBdDQo+ID4gPiA+PiA+ Pj4+Pj4gXSBJZiB0b28gbWFueSBFQ04tQ0UgcGFja2V0cyBhcmUgcmVjZWl2ZWQsIHRoZSBzZW5k ZXINCj4gU0hPVUxEDQo+ID4gPiA+PiBzZW5kDQo+ID4gPiA+PiBzb21lDQo+ID4gPiA+PiA+Pj4+ Pj4gXSBub3QtRUNOLWNhcGFibGUgcGFja2V0cyB0byBkZXRlcm1pbmUgd2hldGhlciBlbm91Z2gN Cj4gcGFja2V0cw0KPiA+ID4gPj4gYWxvbmcgdGhlDQo+ID4gPiA+PiA+Pj4+Pj4gXSBwYXRoIGFy ZSBiZWluZyBkcm9wcGVkIHRvIGp1c3RpZnkgYWN0aXZhdGluZyBvdXINCj4gY2lyY3VpdC0NCj4g PiA+ID4+IGJyZWFrZXIuDQo+ID4gPiA+PiA+Pj4+Pj4NCj4gPiA+ID4+ID4+Pj4+PiBJw6Ligqzi hKJtIG5vdCBlbnRodXNpYXN0aWMgYWJvdXQgYWRkaW5nIHRoYXQ7IGJ1dCBpdCB3b3VsZA0KPiBy ZXNvbHZlDQo+ID4gPiA+PiB0aGUNCj4gPiA+ID4+IGlzc3VlLg0KPiA+ID4gPj4gPj4+Pj4NCj4g PiA+ID4+ID4+Pj4+IEnDouKCrOKEom0gbm90IGNvbnZpbmNlZCB0aGlzIHdvdWxkIHdvcmsuIFRo ZSBjaXJjdWl0IGJyZWFrZXIgaXMNCj4gPiA+ID4+IGxvb2tpbmcNCj4gPiA+ID4+IGF0IGxvbmcg dGVybQ0KPiA+ID4gPj4gPj4+Pj4gdHJlbmRzLCBhbmQgaW4gb3JkZXIgdG8gaGF2ZSBlbm91Z2gg bm90LUVDVCBwYWNrZXRzIHRvDQo+ID4gPiBkZXRlcm1pbmUNCj4gPiA+ID4+IGlmIGl0DQo+ID4g PiA+PiA+PiBzaG91bGQNCj4gPiA+ID4+ID4+Pj4+IHRyaWdnZXIsIHlvdcOi4oKs4oSiZCBlc3Nl bnRpYWxseSBoYXZlIHRvIHJ1biB3aXRob3V0IEVDTiBmb3INCj4gc29tZQ0KPiA+ID4gPj4gc2Vj b25kcy4NCj4gPiA+ID4+ID4+Pj4+DQo+ID4gPiA+PiA+Pj4+PiAtLQ0KPiA+ID4gPj4gPj4+Pj4g Q29saW4gUGVya2lucw0KPiA+ID4gPj4gPj4+Pj4gaHR0cHM6Ly9jc3BlcmtpbnMub3JnLw0KPiA+ ID4gPj4gPj4+Pg0KPiA+ID4gPj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gPj4gPj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4g PiA+PiA+Pj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPiA+ID4gPj4gPj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiA+ID4gPj4gPg0KPiA+ID4gPg0KPiA+ID4g Pg0KDQo= From nobody Thu Jun 30 09:28:31 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD9412D16D; Thu, 30 Jun 2016 09:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9FLU2j5cM5w; Thu, 30 Jun 2016 09:28:22 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D306512D113; Thu, 30 Jun 2016 09:28:21 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bIep8-0005uh-1O; Thu, 30 Jun 2016 18:28:18 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bIep7-0007mS-8a; Thu, 30 Jun 2016 18:28:17 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Thu, 30 Jun 2016 18:28:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160616222548.GB77166@verdi> <0643E158-BF26-4692-8167-B7A959CB20CE@csperkins.org> <8C16F1C6-B4A7-4BB4-B215-D7E7EAF308F8@erg.abdn.ac.uk> <3E053A65-2698-4749-8E3D-E0451DF84011@ifi.uio.no> <32a23d69d22062669f78df806a4eb6b8.squirrel@erg.abdn.ac.uk> To: "De Schepper, Koen (Nokia - BE)" X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 10 sum msgs/h 4 total rcpts 43919 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5AE02707A5F73F64E8158E2EEAD77F4720030D04 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1481 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , tsvwg , IETF AVTCore WG Subject: Re: [rtcweb] [tsvwg] [AVTCORE] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 16:28:25 -0000 Hi, > On 30. jun. 2016, at 17.58, De Schepper, Koen (Nokia - BE) = wrote: >=20 >=20 >> -----Original Message----- >> From: Black, David [mailto:david.black@emc.com] >> Sent: maandag 27 juni 2016 22:10 >> To: De Schepper, Koen (Nokia - BE) >> Cc: tsvwg; IETF AVTCore WG; rtcweb@ietf.org; Black, David >> Subject: RE: [tsvwg] [rtcweb] [AVTCORE] WG Last Call on changes: = draft- >> ietf-avtcore-rtp-circuit-breakers-16 >>=20 >>> As long as an AQM is marking at the same rate as dropping >>=20 >> That's an interesting assumption - it should be true for AQMs vetted >> here in the past, >=20 > And I hope for ect(0) the network will keep doing this in the future, = at=20 > least not to deviate too far from this. > L4S proposes to use ect(1) just because it deviates too much, so the = network=20 > can detect the different end-system behavior and can couple it = correctly to=20 > what it is doing for drop and ect(0). >=20 >=20 >> but there are easy ways for it not to hold (e.g., if >> dropping >> or marking is based on queue occupancy, it is possible that dropping >> reduces queue occupancy in a fashion that marking does not). >=20 > Do you mean that this results in different mark and drop probabilities=20= > for competing ECN and non-ECN flows? >=20 > The impact on the dropping/marking probability *value* applied by an = AQM can change=20 > due to presence of ECN flows, but I don't think this results in a = different=20 > drop compared to mark probability. Up to now all classic AQMs smooth = their p=20 > over sufficient long time to remove short fluctuations in queue sizes.=20= >=20 > =46rom an end system I think for classic ECN it is safe to assume that = if you=20 > detect high levels of drop, it means there is a high level of=20 > congestion AND the network takes care of it. If you detect a high = level > of marking, it means lots of congestion and nobody is currently taking = care=20 > of it. Everybody is looking at you as a sender to take care of it. = That's why > I think you should not use ECN if you don't use congestion control. >=20 > It also means that the competing drop flows are having a high level of = matching > drop. That's why I think a classic circuit breaker should also treat = drop and=20 > classic marking similar. >=20 > I understood ABE tries to modify the end system behavior slightly for = ECN. If=20 > this can be done safely with benefits that outweighs the = disadvantages,=20 > than that's no problem, but I think nobody is in favor to modify the = AQM=20 > behavior to ect(0). I pretty much agree with everything here=E2=80=A6 > Based on DualQ compatibility experiments with classic ECN, I also = believe=20 > that, if we want to further promote classic ECN too, we need some = extra=20 > safety measures for classic AQMs using ECN to avoid high CE marking = levels,=20 > where ect(0) flows start to push away too much the non-ect flows. For=20= > instance PIE has (for good reasons) a max of 10% marking, and then = switches=20 > to drop. As far as I know such measures are not mandatory in other = ECN/AQM=20 > related drafts, is it? =E2=80=A6 but here I=E2=80=99d like to put a note of warning: see the = appendix here: http://heim.ifi.uio.no/michawe/research/publications/CAIA-TR-150710A.pdf here, we found that this behavior is detrimental (the 10% threshold was = too small). =3D> I agree with the general notion of such a threshold, but the = threshold shouldn=E2=80=99t be too low (it can eliminate ECN=E2=80=99s = benefits). Cheers, Michael