From nobody Tue Oct 7 22:58:59 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966E71A9100; Tue, 7 Oct 2014 22:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOUtwTEfLsXC; Tue, 7 Oct 2014 22:58:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF321ACE76; Tue, 7 Oct 2014 22:58:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141008055843.543.2271.idtracker@ietfa.amsl.com> Date: Tue, 07 Oct 2014 22:58:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/7KQDLWIE8shwXptlv1kYJ8LoDyg Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-06.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 05:58:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. Title : Congestion Control Requirements For RMCAT Author : Randell Jesup Filename : draft-ietf-rmcat-cc-requirements-06.txt Pages : 9 Date : 2014-10-07 Abstract: Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g. with the introduction of WebRTC[I-D.ietf-rtcweb-overview]), it is especially important to ensure that this kind of traffic is congestion controlled. This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for realtime media congestion avoidance technique. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-cc-requirements-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 10 08:37:49 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F4C1A1AA0 for ; Fri, 10 Oct 2014 08:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeOyIYiO0bgD for ; Fri, 10 Oct 2014 08:37:45 -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 4E2E31A0052 for ; Fri, 10 Oct 2014 08:37:15 -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 1XccFk-0003mZ-4r; Fri, 10 Oct 2014 17:37:12 +0200 Received: from [129.240.66.44] (helo=hayesd-laptop) by mail-mx2.uio.no with esmtpsa (SSLv3:AES128-SHA:128) user davihay (Exim 4.80) (envelope-from ) id 1XccFj-0006Lw-Ho; Fri, 10 Oct 2014 17:37:12 +0200 Date: Fri, 10 Oct 2014 17:37:10 +0200 From: David Hayes To: "rmcat@ietf.org" Message-ID: <20141010173710.1769e033@hayesd-laptop> Organization: University of Oslo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-mageia-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 1494 max rcpts/h 38 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 27934C31CCA81D0273157B56DD94CDF32FA1DB8C X-UiO-SPAM-Test: remote_host: 129.240.66.44 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 1 total 404 max/h 5 blacklist 0 greylist 1 ratelimit 0 X-UiOonly: 431794205BCD7A513B51F88E9ADFA21B9CAB057F Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/l429rnqu_XJGyrzxf8TR7OZKir4 Cc: Simone Ferlin-Oliveira , Michael Welzl Welzl Subject: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 15:37:48 -0000 Dear All, We have just submitted of our initial shared bottleneck detection draft and will value your comments and suggestions. Regards, David Begin forwarded message: Date: Fri, 10 Oct 2014 08:17:57 -0700 From: To: Michael Welzl , David Hayes , Michael Welzl , Simone Ferlin , Simone Ferlin , David Hayes Subject: New Version Notification for draft-hayes-rmcat-sbd-00.txt A new version of I-D, draft-hayes-rmcat-sbd-00.txt has been successfully submitted by David Hayes and posted to the IETF repository. Name: draft-hayes-rmcat-sbd Revision: 00 Title: Shared Bottleneck Detection for Coupled Congestion Control for RTP Media. Document date: 2014-10-10 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt Status: https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 Abstract: This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. It relies on summary statistics that are calculated by a data receiver based on continuous measurements and regularly fed to a grouping algorithm that runs wherever the knowledge is needed. This mechanism complements the coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. 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. The IETF Secretariat -- ------------------------- David Hayes davihay@ifi.uio.no Department of Informatics University of Oslo From nobody Mon Oct 13 02:08:43 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1A01A8903 for ; Mon, 13 Oct 2014 02:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uubnbN1BOHOf for ; Mon, 13 Oct 2014 02:08:39 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF151A8905 for ; Mon, 13 Oct 2014 02:08:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 45AAFD930C; Mon, 13 Oct 2014 11:08: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 Floumao7pD73; Mon, 13 Oct 2014 11:08:37 +0200 (MEST) Received: from email.ee.ethz.ch (atlan02.ee.ethz.ch [129.132.52.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0044FD9302; Mon, 13 Oct 2014 11:08:36 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 13 Oct 2014 11:08:36 +0200 From: =?UTF-8?Q?Mirja_K=C3=BChlewind?= To: rmcat@ietf.org Message-ID: X-Sender: mirja.kuehlewind@tik.ee.ethz.ch User-Agent: Roundcube Webmail/1.0.2 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/YOfNqKWsQ1T7zjw1BgBOYD6l1cs Cc: "Karen E. Egede Nielsen" , "Eggert, Lars" Subject: [rmcat] Meeting agenda X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 09:08:41 -0000 Hi w-g, we have a (preliminary) agenda slot for Wednesday, November 12, 2014 0900-1130, Morning Session I Further, our request for an interim meeting was approved. We still don't have a room yet, but we requested the room for Sunday, November 2, 2014 0900-1300 Let's plan with this date and time slot for now. Please send agenda request for both meetings! We would like to have presentations on evaluation results and related algorithm updates in the Sunday meeting. Updates to working group documents and other documents not directly related to algorithms will go into the Wednesday meeting. If you plan a presentation, please let us know the title and the time you would like to allocate for the presentation. Your chairs From nobody Mon Oct 13 05:51:09 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843D31A8A59 for ; Mon, 13 Oct 2014 05:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RN7coaiVxNNn for ; Mon, 13 Oct 2014 05:51:05 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4731A1A8A4E for ; Mon, 13 Oct 2014 05:51:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7F9DDD930B; Mon, 13 Oct 2014 14:51:03 +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 aM9B7Hq7JJFz; Mon, 13 Oct 2014 14:51:03 +0200 (MEST) Received: from [192.168.178.32] (stgt-5f71871a.pool.mediaWays.net [95.113.135.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E9440D9302; Mon, 13 Oct 2014 14:51:02 +0200 (MEST) Message-ID: <543BCAB5.5010508@tik.ee.ethz.ch> Date: Mon, 13 Oct 2014 14:51:01 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: rmcat@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/5FLg3EqEpkSZ3sUbv9ebGQWc3i0 Cc: "Karen E. Egede Nielsen" , "Eggert, Lars" Subject: Re: [rmcat] Meeting agenda X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 12:51:07 -0000 Hi again, of course the interim is Nov 9th! Sorry and thx to Varun! Mirja On 13.10.2014 11:08, Mirja Kühlewind wrote: > Hi w-g, > > we have a (preliminary) agenda slot for > > Wednesday, November 12, 2014 > 0900-1130, Morning Session I > > Further, our request for an interim meeting was approved. We still don't > have a room yet, but we requested the room for > > Sunday, November 2, 2014 > 0900-1300 > > Let's plan with this date and time slot for now. > > Please send agenda request for both meetings! We would like to have > presentations on evaluation results and related algorithm updates in the > Sunday meeting. Updates to working group documents and other documents > not directly related to algorithms will go into the Wednesday meeting. > > If you plan a presentation, please let us know the title and the time > you would like to allocate for the presentation. > > Your chairs > > > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------ From nobody Mon Oct 13 08:58:11 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A961F1A0360 for ; Mon, 13 Oct 2014 08:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9q9ST7vZBZ3 for ; Mon, 13 Oct 2014 08:58:06 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573CD1A031C for ; Mon, 13 Oct 2014 08:58:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 70C1BD9309; Mon, 13 Oct 2014 17:58:03 +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 F8e11GxtvjHb; Mon, 13 Oct 2014 17:58:03 +0200 (MEST) Received: from [192.168.178.32] (stgt-5f71871a.pool.mediaWays.net [95.113.135.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E9374D9302; Mon, 13 Oct 2014 17:58:02 +0200 (MEST) Message-ID: <543BF68A.6070508@tik.ee.ethz.ch> Date: Mon, 13 Oct 2014 17:58:02 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Varun Singh , Joerg Ott , "rmcat@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/6ol3SbYzK6nMiWavKTgkt3WYKVo Subject: [rmcat] review of draft-ietf-rmcat-eval-criteria-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:58:09 -0000 Hi Varun, I reviewed the draft-ietf-rmcat-eval-criteria-02 document as an individual contributor (not w-g- chair). I have a couple of general comments and a set of more detailed comments below. For me it is currently not very clear what the purpose of this document is (in relation to the reqs doc and the test scenarios doc). Form my point of view the requirement document is (mainly) written for people who would like to develop a new rmcat algorithm. I think this document should address people who want to evaluate an (existing) proposal by not only implementing the initial test scenarios but e.g. perform additional tests to check if the initial requirements can be fulfilled. Therefore this document should relate closely to the reqs document (while not stating new requirements!). Therefore I would see the following topics as content of this document: 1. Summary of the requirements (of draft-ietf-rmcat-cc-requirements): This should only be a very brief summary mainly pointing to the other document. If you look at draft-ietf-rmcat-cc-requirements there might be even some requirements that do not need (simulative/testbed) evaluation e.g. the amount of overhead. Further you could add to the list some of the 'classical requirements' as convergence/stability (and provide a respective reference) but I believe these requirements are all somehow covered by draft-ietf-rmcat-cc-requirements...? 2. List of metric and parameters: Currently section 3 has 2 lists which overlap to some extend. Further there is another list in draft-ietf-rmcat-eval-test. I believe there should be ONE list in the eval document and the test document should relate to this. However, the description of which data should be traced i would rather see as a part of draft-ietf-rmcat-eval-test. More detailed comments further below. Further I have the feeling that the metrics described in RFC5166 are not comprehensive, e.g. minimizing oscillations is rather a requirement than a metric from my perspective. Therefore we should define our own list here (of course this referring RFC5166) and also focus on metrics that are related to media congestion control (where we e.g. might have application-limited traffic). Further, I would list parameters that can be varied in the evaluation and potentially even discuss a sensible range for evaluation, e.g. there is a maximum (base) RTT as we talk about the Internet and usually avoid to route the traffic several times around the world. 3. Guideline for evaluation (scenarios): Here is would like to see all three things from above to be set into relation: To evaluate a certain requirement (or set of related requirements), you can vary these parameter in this range and then look at this metric and you would expect a results/value of the metric in this range. I know, this more or less proposes a completely different document but this is just a proposal. Again for me the purpose of the currently document is not very clear anymore. Otherwise you would need to find a way to further explain in the existing document what the purpose and goals of this document are. If you plan a wider revision and would like to get some more input, I'm also willing to contribute text. Just let me know. Or we can sit together in Honolulu if you think that's helpful. Here some more detailed comments: Section 3: Metrics ------------------ - 'minimizing oscillations' is a requirement for me; e.g. oscillation size would be a metric defined as e.g. the difference between the minimum sending rate/window and the next maximum or the difference between the min and max within a given time frame.. - 'Reactivity': I'm used to the term responsiveness instead; again this is a requirement for me while convergence time (as given in RFC5166) is the respective metric for evaluation - 'packet loss and discards': What's the difference between a loss and a discard and why is this listed separately? Is this in number of packets or bytes? Or do you mean the loss rate (=total number of pkt/bytes divided by the lost pkts/bytes over a certain time interval)? - 'Section 2.1 of [RFC5166] discusses the tradeoff between throughput, delay and loss.' is not a metric - 'Thoughput', 'Sending rate, Receiver rate, Goodput' and 'Bandwidth Utilization' are all very closely connected might not need to be treated separately. I think the metric that is of interest is utilization while you usually need to measure the sending rate to actually get the utilization. As I stated above I would see this part, what exactly to measure (and also where!), as part of draft-ietf-rmcat-eval-test. It could also be a part of this document but might make the test document more complicated. In any case which data to trace in the measurement and metrics for statistical evaluation should be discussed separately. And one more comment regarding the sending/receiving rate: these are usually bytes over a certain time frame and the length of the time frame should be defined (together with the evaluation metric that is using this data); I usually use a time interval of two RTTs. - The discussion on fairness/unfairness does not belong in this section but in the next. In this section there are two metrics which might be of interest: jains fairness index and/or the ratio of the average throughput of one flow to another (or the ratio of groups of flows) over a certain time interval - In point 7 'stable rate' needs to be defined. I usually use e.g. time to reach 80%/95% of the equal share (or a desired/given rate in media transmissions...?) There is something similar done in draft-irtf-iccrg-tcpeval section 5.3.3. - Regarding your question on Jains fairness index: I think this is a valuable metric (as mentioned above) only the term fairness is wrong. This metric give an impression if the capacity is shared equally between competing flows or groups of flows. There are evaluation scenarios where this is desired, e.g. when two flow compete using the same congestion control algorithm and the same traffic model (in our case, might even send the same video) - Section 3.1. would go into the test document from my current point of view. - And regarding tracing (which might go into the test doc): wouldn't it be useful for some evaluations to trace the congestion window (if possible) because this might be larger than the sending rate...? Section 4: Guidelines --------------------- This section currently describes some requirements (Avoiding Congestion Collapse and Stability) as well as part of the traffic model and network model. I would propose to have the parameter discussion as mentioned above. Further the parameter discussion should be separated into traffic and network parameter. This would integrate some text from section 4.3., 4.8. and 4.9. (traffic model) as well as 4.4., 4.5. 4.6. and 4.7. (network model). And then use this section to give guidance how to evaluate the requirements in draft-ietf-rmcat-cc-requirements. Further this document should rely on e.g. draft-irtf-iccrg-tcpeval-01 and (only) discuss additional things needed to evaluate media congestion control (as the requirements are also slightly different). So one big difference is the traffic model. So there should be cases in the evaluation where the traffic is application limited. If there is e.g. in a certain scenario enough bandwidth capacity available to change the video coding to a higher rate, how long does it take until this is indicated to the application (assuming there is some kind of interface)? Or how often is the sending rate lower than the application rate (which could cause starvation)? This of course needs a traffic model as well as an interface which are currently both in separate documents (and work in progress). What I really miss in this section is any relation to the metrics. I would expect something like: convergence is reached if the convergence time is never longer than X sec (as a very general example) or (more media specific) quality is sufficient if the sending rate is never X% lower than the application rate and never for more than % seconds.... and so on. - section 4.1. and 4.2 it this actually the same kind of evaluation? And this states only a requirement up-to now. How would this be evaluated? - section 4.4. 'start-rates': what do you mean? The start rate of the application traffic or the link bandwidth? - section 4.5.: I believe most lower layer protocol nowadays have a very good recovery implemented such that there are usually e.g. in wifi not much errors/loss. therefore form the perceptive of the transport only the delay is varying. 'Furhermore packet loss may induce additional delay': this reads a little weird: make more clear that there is packet loss at the lower layer but only delay visible to the higher layer... - Section 4.6. 'The main motivation for the previous and current criteria is to identify situations in which the proposed congestion control is less performant.' Not sure why this is written here... isn't this always the intention? - section 4.4. also describes some king of evaluation on an transient effect which should be part of 4.7. then...? - Section 4.9. discussion on short flow is again more a requirement but short flow traffic should be configurable in the traffic model - section 4.10. this again is a requirement. I don't think this can be evaluated in simulation/testbeds; so I believe that does not belong in this document. Section 5 and 6 --------------- Not sure if this belong into this document. At least section 6 is partly documented in our charter already. If you see this document as a frame document that will introduce the other documents (e.g. reqs, tests, interface, traffic model) and explain the relation between those documents than this text can stay but should move into the introduction. Appendix A ----------- - I don't understand why this tradeoff is discussed here. - Appendix A.1: I really, really think that some kind of 'quality metrics' must be discussed in this document because this is the different to other congestion control evaluation. I don't think we should discuss any kind of quality of experience though. This metric should rather be e.g. % of times where the sending rate was lower than the application rate; % of times where the link was underutilizated and a higher coding could have been used. Again this also needs some kind of video traffic model; but I believe a simple interface which indicated 'go one step up/down' and the respective model that switches to certain points of time one step up or down would be sufficient for initial evaluation; though I'm not a video expert... All in all I would recommend to relate this document in any case stronger to draft-ietf-rmcat-cc-requirements and mainly discuss things that are specific to MEDIA congestion control while only referring or summarizing other aspects. I hope this is helpful. Let me know if you have questions or would like further input. Mirja From nobody Wed Oct 15 09:13:57 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431821A88F5 for ; Wed, 15 Oct 2014 09:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU4kf3iRJ_cO for ; Wed, 15 Oct 2014 09:13:49 -0700 (PDT) Received: from relay.mailchannels.net (aso-006-i438.relay.mailchannels.net [23.91.64.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC5D1A88FD for ; Wed, 15 Oct 2014 09:13:29 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id EDF0DAD958 for ; Wed, 15 Oct 2014 16:13:27 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.216.27.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.2.14); Wed, 15 Oct 2014 16:13:28 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1413389608310:1159325248 X-MC-Ingress-Time: 1413389608310 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:62139 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XeRCY-000GMa-Oh for rmcat@ietf.org; Wed, 15 Oct 2014 11:13:26 -0500 Message-ID: <543E9D2D.401@jesup.org> Date: Wed, 15 Oct 2014 12:13:33 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rmcat@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-AuthUser: randell@jesup.org Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/1ir8x9zrkA4br6di58bF6z6n9hM Subject: Re: [rmcat] Meeting agenda X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 16:13:53 -0000 On 10/13/2014 5:08 AM, Mirja K=FChlewind wrote: > > Further, our request for an interim meeting was approved. We still=20 > don't have a room yet, but we requested the room for > > Sunday, November 2, 2014 > 0900-1300 > > Let's plan with this date and time slot for now. Please request remote access (hopefully this is already planned, just=20 making sure). Thanks! --=20 Randell Jesup -- rjesup a t mozilla d o t com From nobody Fri Oct 17 01:29:28 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB531A9117 for ; Fri, 17 Oct 2014 01:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NloTEscHgG36 for ; Fri, 17 Oct 2014 01:29:24 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA931A9119 for ; Fri, 17 Oct 2014 01:29:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id ECFB1D930A for ; Fri, 17 Oct 2014 10:29:22 +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 l+8xL15tRni6 for ; Fri, 17 Oct 2014 10:29:22 +0200 (MEST) Received: from [192.168.178.32] (stgt-4d02cf6c.pool.mediaWays.net [77.2.207.108]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8ED9BD9302 for ; Fri, 17 Oct 2014 10:29:22 +0200 (MEST) Message-ID: <5440D361.9060905@tik.ee.ethz.ch> Date: Fri, 17 Oct 2014 10:29:21 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "rmcat@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/iKg3q8AvqShGAtQmgPHlRS33bdw Subject: [rmcat] Sunday Interim X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 08:29:26 -0000 Hi w-g, we got confirmation for the rmcat interim meeting. The meeting will take place on Sunday, Nov 9, 2014 09:00 - 13:00 Lehua Suite Mirja From nobody Sun Oct 19 21:07:55 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE611A0084 for ; Sun, 19 Oct 2014 21:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ct9tkqDmrka2 for ; Sun, 19 Oct 2014 21:07:50 -0700 (PDT) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5200E1A0070 for ; Sun, 19 Oct 2014 21:07:50 -0700 (PDT) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id s9K47kKb026077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 15:07:47 +1100 Message-ID: <54448A92.7090400@swin.edu.au> Date: Mon, 20 Oct 2014 15:07:46 +1100 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: rmcat@ietf.org References: <1C2B9EE0-F740-4188-A89F-46B173FD501B@ifi.uio.no> In-Reply-To: <1C2B9EE0-F740-4188-A89F-46B173FD501B@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/SrUNEhksAGabJbNOt9UT5c6-S5Y Subject: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 04:07:53 -0000 David, Had a quick glance, and draft-hayes-rmcat-sbd-00.txt looks like the start of an interesting piece of work. In the spirit of kicking off discussion, a couple of editorial nits/suggestions... In 2.1 and 3.1, you quote [Hayes-LCN14] as suggesting some parameter values "...that seem to work well over a wide range of practical Internet conditions." The I-D would be more self-contained if you also summarised somewhere in the I-D itself what [Hayes-LCN14] considered to be "practical Internet conditions". In 3. you introduce two variables, skewest and freqest. Adding an underscore and making them skew_est and freq_est would be visually clearer. (It took me a couple of reads to realise they weren't just typo'd words ;) ) 3.1.4. (heading) "Oscilation Estimate" -> "Oscillation Estimate" 3.1.3 "...([RFC5481] and [ITU-Y1540] is used..." -> "...([RFC5481] and [ITU-Y1540]) is used..." 3.2.1, First para uses "small", "moderate" numbers of flows fairly opaquely, then intimates that "large" == "hundreds". Is the vagueness just the nature of a -00.txt I-D, or a constraint that applies to your flow grouping algorithm? (Put another way, can you provide implementers stronger guidance as to what sort of _in_efficiencies would be experienced if they anyway went ahead and used the algorithm in 3.2.1 across hundreds+ flows? I could also see that detail perhaps being out of scope, so just a suggestion.) 4.1. For implementers it may be helpful if -01.txt elaborated on time stamp resolution considerations. (The current text implies that typical RTP media flows use sub-millisecond timers whose resolution is 'less than one hundredth of a typical paths range of delays'. Would be useful to capture your thoughts on what happens when the paths are tens of ms, or the timers aren't "sufficiently" sub-millisecond.) cheers, gja David Hayes on Fri, 10 Oct 2014 17:37:10 +0200 wrote: > > Dear All, > > We have just submitted of our initial shared bottleneck detection > draft and will value your comments and suggestions. > > Regards, > > David > > Begin forwarded message: > > Date: Fri, 10 Oct 2014 08:17:57 -0700 > From: > To: Michael Welzl , David Hayes > , Michael Welzl , Simone Ferlin > , Simone Ferlin , David Hayes > Subject: New Version Notification for > draft-hayes-rmcat-sbd-00.txt > > > > A new version of I-D, draft-hayes-rmcat-sbd-00.txt > has been successfully submitted by David Hayes and posted to the > IETF repository. > > Name: draft-hayes-rmcat-sbd > Revision: 00 > Title: Shared Bottleneck Detection for Coupled > Congestion Control for RTP Media. Document date: 2014-10-10 > Group: Individual Submission > Pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt > Status: https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ > Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 > > > Abstract: > This document describes a mechanism to detect whether end-to-end data > flows share a common bottleneck. It relies on summary statistics > that are calculated by a data receiver based on continuous > measurements and regularly fed to a grouping algorithm that runs > wherever the knowledge is needed. This mechanism complements the > coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. > > > > > 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. > > The IETF Secretariat > > > > -- > > ------------------------- > David Hayes > davihay@ifi.uio.no > Department of Informatics > University of Oslo From nobody Tue Oct 21 02:22:16 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E61E1A01AA for ; Tue, 21 Oct 2014 02:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UumF_FWLAGud for ; Tue, 21 Oct 2014 02:22:12 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5688B1A01F0 for ; Tue, 21 Oct 2014 02:22:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9924CD9303; Tue, 21 Oct 2014 11:22:09 +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 N1VtvlgSoGVl; Tue, 21 Oct 2014 11:22:09 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4D9AED9302; Tue, 21 Oct 2014 11:22:09 +0200 (MEST) Message-ID: <544625C1.3050808@tik.ee.ethz.ch> Date: Tue, 21 Oct 2014 11:22:09 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: David Hayes , "rmcat@ietf.org" References: <20141010173710.1769e033@hayesd-laptop> In-Reply-To: <20141010173710.1769e033@hayesd-laptop> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/wvwXBjZ4JjY7rfj4n8jKzuhDt8E Cc: Simone Ferlin-Oliveira , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 09:22:15 -0000 Hi David, hi all, I've read your document and have a couple of questions (as an individual contributor): 1) You propose to use the OWD, to do all the calculation at the receiver and to signal the information to the sender. Did you also do some analysis how good your approach would be if you use RTT (because than the sender could also work independent of the receiver)? 2) You also talk about a receiver based approach. I'm not sure if this case is needed because that's the case where simply congestion control does its job. While if one sender has multiple flows it seems to be more reasonable for me to couple these. 3) Am I right to that you need an initial set-up time of 17.5 sec? Can you also explain a little further why you've chosen 350ms and N=50? 4) Can you also explain with which (network) effect you have skewness? Is this really an effect in real systems that gives you valuable information? 5) If you look at the variance (and use the max) you might want to apply some kind of filtering first e.g. to filter out single out liners (due to some processing delays). 6) Can you also explain a little more, why you also use the oscillation frequency and the value p_v=0.2? While the other metrics actually measures some kind of network behavior, e.g. delay variance is determined by the queue size, the oscillation size is determined by the congestion control behavior. I guess the flows have to use the same congestion control scheme...? 7) For packet loss you can also estimated the loss frequency. I would think if the congestion control operates loss-based that this would actually give you a pretty good estimate if flows share the same bottleneck. Or even easier if the loss of the flows always occur in the same RTT. 8) And one last question regarding the grouping: Do you always need to apply all three conditions? Why are those three needed? Mirja On 10.10.2014 17:37, David Hayes wrote: > Dear All, > > We have just submitted of our initial shared bottleneck detection > draft and will value your comments and suggestions. > > Regards, > > David > > Begin forwarded message: > > Date: Fri, 10 Oct 2014 08:17:57 -0700 > From: > To: Michael Welzl , David Hayes > , Michael Welzl , Simone Ferlin > , Simone Ferlin , David Hayes > Subject: New Version Notification for > draft-hayes-rmcat-sbd-00.txt > > > > A new version of I-D, draft-hayes-rmcat-sbd-00.txt > has been successfully submitted by David Hayes and posted to the > IETF repository. > > Name: draft-hayes-rmcat-sbd > Revision: 00 > Title: Shared Bottleneck Detection for Coupled > Congestion Control for RTP Media. Document date: 2014-10-10 > Group: Individual Submission > Pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt > Status: https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ > Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 > > > Abstract: > This document describes a mechanism to detect whether end-to-end data > flows share a common bottleneck. It relies on summary statistics > that are calculated by a data receiver based on continuous > measurements and regularly fed to a grouping algorithm that runs > wherever the knowledge is needed. This mechanism complements the > coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. > > > > > 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. > > The IETF Secretariat > > > From nobody Tue Oct 21 02:59:03 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A921A01A8 for ; Tue, 21 Oct 2014 02:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7lcsu0JL5aL for ; Tue, 21 Oct 2014 02:58: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 DC8E71A017E for ; Tue, 21 Oct 2014 02:58:52 -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 1XgWDL-0005FH-4P; Tue, 21 Oct 2014 11:58:51 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XgWDK-0000lI-P0; Tue, 21 Oct 2014 11:58:51 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Michael Welzl In-Reply-To: <544625C1.3050808@tik.ee.ethz.ch> Date: Tue, 21 Oct 2014 11:58:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4066211E-7CCC-49F0-96D2-DC6E41AFFFA4@ifi.uio.no> References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> To: =?iso-8859-1?Q?Mirja_K=FChlewind?= X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 5 sum rcpts/h 16 sum msgs/h 6 total rcpts 21560 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 03AF74DB334A31C5CB4CB74BF9EDD3BC9321DE63 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 0 bait 0 mail/h: 5 total 6560 max/h 17 blacklist 0 greylist 1 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/lF4XqeRO0wJOhqFXaeZzbi29kVk Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , David Hayes Subject: Re: [rmcat] New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 09:58:56 -0000 Hi Mirja, Thanks a lot for reading and for your comments! I'd like to answer the first two items (and leave the others to my = co-authors): On 21. okt. 2014, at 11:22, Mirja K=FChlewind wrote: > Hi David, hi all, >=20 > I've read your document and have a couple of questions (as an = individual contributor): >=20 > 1) You propose to use the OWD, to do all the calculation at the = receiver and to signal the information to the sender. Did you also do = some analysis how good your approach would be if you use RTT (because = than the sender could also work independent of the receiver)? >=20 > 2) You also talk about a receiver based approach. I'm not sure if this = case is needed because that's the case where simply congestion control = does its job. While if one sender has multiple flows it seems to be more = reasonable for me to couple these. Not only is the RTT noisier, but one can also satisfy the requirement of = limiting the amount of signaling while taking enough samples with this = approach. If we were to go for a sender-only variant, we'd need to = signal much more (even if the RTT was used, we'd need to have some form = of per-packet ACK to get as many samples as we now have). The whole point here was to try to construct something that can work = reliably and without requiring too much signaling, hence the receiver / = sender split of the algorithm. Cheers, Michael From nobody Tue Oct 21 05:03:34 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B91B1A1B24 for ; Tue, 21 Oct 2014 05:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40GRrdNVK4O7 for ; Tue, 21 Oct 2014 05:03:28 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655891A1B23 for ; Tue, 21 Oct 2014 05:03:28 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id u20so788039oif.14 for ; Tue, 21 Oct 2014 05:03:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KX/DTwoo/N6f1JEhpzFS/SIqYgvqg25OZbk/zN/uwD8=; b=BB7w9MfRq1dRzt7AhCYVYZRSggEdbJZDGxsS1GtjfNUmK63ViRzJ9hiMStzAdDoCZY lBtRJTlHn2y09XMSasy+2eEB6nJwHyI3leL1t1ZiHJzDWcCgdqymXzx7ncJCrQlxdEQA LakRfglqd+v5uF1/7FQAT8S6+2fZXz/oHourSTWYBUMui+ngiieo3v6HKujnVp/V+Jd4 7cDH82ZFprOZF9QNDWiJ8kSbFsyzvbDp3VI1LEd4miB3RQCjGb6jytk8sgTKEdW0nhSv hyysehwhemWNuvRE/C3CZG6yUTbTXz++4RKFQGKHSPhBt6DcETEunXTopZ0SrnejcFYu KMvg== X-Gm-Message-State: ALoCoQmh7uuhNyy1I41mQ2vtRTlbcoMHVc0/9iZMfmW6u1CROrNSVVPI/pBgV0oyVWi1YkjOkVe4 MIME-Version: 1.0 X-Received: by 10.202.189.196 with SMTP id n187mr1377670oif.83.1413893007673; Tue, 21 Oct 2014 05:03:27 -0700 (PDT) Received: by 10.202.224.137 with HTTP; Tue, 21 Oct 2014 05:03:27 -0700 (PDT) In-Reply-To: <54448A92.7090400@swin.edu.au> References: <1C2B9EE0-F740-4188-A89F-46B173FD501B@ifi.uio.no> <54448A92.7090400@swin.edu.au> Date: Tue, 21 Oct 2014 14:03:27 +0200 Message-ID: From: Simone Ferlin-Oliveira To: grenville armitage Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/viWy9G_bXL33Zt67cnmi6UhRer4 Cc: rmcat@ietf.org Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 12:03:31 -0000 Grenville, On behalf of the authors, I am answering to your comment about timestamps (4.1) of the draft: We actually have in mind to add more on timestamp precision and also mention it to different places the algorithm can be implemented. However, the work I am doing for that at the moment is going to be included in the next version of the draft. Thanks, Simone On 20 October 2014 06:07, grenville armitage wrote: > David, > > Had a quick glance, and draft-hayes-rmcat-sbd-00.txt looks like the start of > an interesting piece of work. > > In the spirit of kicking off discussion, a couple of editorial > nits/suggestions... > > In 2.1 and 3.1, you quote [Hayes-LCN14] as suggesting some parameter values > "...that seem to work well over a wide range of practical Internet > conditions." The I-D would be more self-contained if you also summarised > somewhere in the I-D itself what [Hayes-LCN14] considered to be "practical > Internet conditions". > > In 3. you introduce two variables, skewest and freqest. Adding an underscore > and making them skew_est and freq_est would be visually clearer. (It took me > a couple of reads to realise they weren't just typo'd words ;) ) > > 3.1.4. (heading) "Oscilation Estimate" -> "Oscillation Estimate" > > 3.1.3 "...([RFC5481] and [ITU-Y1540] is used..." -> "...([RFC5481] and > [ITU-Y1540]) is used..." > > 3.2.1, First para uses "small", "moderate" numbers of flows fairly opaquely, > then intimates that "large" == "hundreds". Is the vagueness just the nature > of a -00.txt I-D, or a constraint that applies to your flow grouping > algorithm? (Put another way, can you provide implementers stronger guidance > as to what sort of _in_efficiencies would be experienced if they anyway went > ahead and used the algorithm in 3.2.1 across hundreds+ flows? I could also > see that detail perhaps being out of scope, so just a suggestion.) > > 4.1. For implementers it may be helpful if -01.txt elaborated on time stamp > resolution considerations. (The current text implies that typical RTP media > flows use sub-millisecond timers whose resolution is 'less than one > hundredth of a typical paths range of delays'. Would be useful to capture > your thoughts on what happens when the paths are tens of ms, or the timers > aren't "sufficiently" sub-millisecond.) > > cheers, > gja > > David Hayes on Fri, 10 Oct 2014 17:37:10 +0200 wrote: >> >> >> Dear All, >> >> We have just submitted of our initial shared bottleneck detection >> draft and will value your comments and suggestions. >> >> Regards, >> >> David >> >> Begin forwarded message: >> >> Date: Fri, 10 Oct 2014 08:17:57 -0700 >> From: >> To: Michael Welzl , David Hayes >> , Michael Welzl , Simone Ferlin >> , Simone Ferlin , David Hayes >> Subject: New Version Notification for >> draft-hayes-rmcat-sbd-00.txt >> >> >> >> A new version of I-D, draft-hayes-rmcat-sbd-00.txt >> has been successfully submitted by David Hayes and posted to the >> IETF repository. >> >> Name: draft-hayes-rmcat-sbd >> Revision: 00 >> Title: Shared Bottleneck Detection for Coupled >> Congestion Control for RTP Media. Document date: 2014-10-10 >> Group: Individual Submission >> Pages: 12 >> URL: >> http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt >> Status: https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ >> Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 >> >> >> Abstract: >> This document describes a mechanism to detect whether end-to-end data >> flows share a common bottleneck. It relies on summary statistics >> that are calculated by a data receiver based on continuous >> measurements and regularly fed to a grouping algorithm that runs >> wherever the knowledge is needed. This mechanism complements the >> coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> >> -- >> >> ------------------------- >> David Hayes >> davihay@ifi.uio.no >> Department of Informatics >> University of Oslo > > > From nobody Tue Oct 21 05:15:24 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39F01A1B2A for ; Tue, 21 Oct 2014 05:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1A8dRpOBL8Z for ; Tue, 21 Oct 2014 05:15:18 -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 085871A1B26 for ; Tue, 21 Oct 2014 05:15:17 -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 1XgYLM-0003rQ-8T; Tue, 21 Oct 2014 14:15:16 +0200 Received: from [129.240.66.44] (helo=hayesd-laptop) by mail-mx1.uio.no with esmtpsa (SSLv3:AES128-SHA:128) user davihay (Exim 4.80) (envelope-from ) id 1XgYLL-00004y-MM; Tue, 21 Oct 2014 14:15:16 +0200 Date: Tue, 21 Oct 2014 14:15:14 +0200 From: David Hayes To: grenville armitage Message-ID: <20141021141514.4bf700ec@hayesd-laptop> In-Reply-To: <54448A92.7090400@swin.edu.au> References: <1C2B9EE0-F740-4188-A89F-46B173FD501B@ifi.uio.no> <54448A92.7090400@swin.edu.au> Organization: University of Oslo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-mageia-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 1523 max rcpts/h 38 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 860D7631FCA42A527B4A30CD472C5D56C92FC240 X-UiO-SPAM-Test: remote_host: 129.240.66.44 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 411 max/h 5 blacklist 0 greylist 0 ratelimit 0 X-UiOonly: E3DD517DE9DCE3FA41DB7B8ACB5A964ECA3ACC7D Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/SOYdawLcnFbBOH-lyB7UYsRMMXI Cc: rmcat@ietf.org Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 12:15:22 -0000 Hi Grenville, Thank you for your comments on the draft. Some notes inline. Thanks and regards, David On Mon, 20 Oct 2014 15:07:46 +1100 grenville armitage wrote: > David, > > Had a quick glance, and draft-hayes-rmcat-sbd-00.txt looks like the > start of an interesting piece of work. > > In the spirit of kicking off discussion, a couple of editorial > nits/suggestions... > > In 2.1 and 3.1, you quote [Hayes-LCN14] as suggesting some parameter > values "...that seem to work well over a wide range of practical > Internet conditions." The I-D would be more self-contained if you > also summarised somewhere in the I-D itself what [Hayes-LCN14] > considered to be "practical Internet conditions". > The LCN paper tested two very different network conditions with identical parameters. We are currently working on more expansive and quantitative tests, which we hope to eventually publish in a journal. The vagueness in the current comment reflects this and will be made more concrete when we have more data to back it up. > In 3. you introduce two variables, skewest and freqest. Adding an > underscore and making them skew_est and freq_est would be visually > clearer. (It took me a couple of reads to realise they weren't just > typo'd words ;) ) > > 3.1.4. (heading) "Oscilation Estimate" -> "Oscillation Estimate" > > 3.1.3 "...([RFC5481] and [ITU-Y1540] is used..." -> "...([RFC5481] > and [ITU-Y1540]) is used..." > > 3.2.1, First para uses "small", "moderate" numbers of flows fairly > opaquely, then intimates that "large" == "hundreds". Is the > vagueness just the nature of a -00.txt I-D, or a constraint that > applies to your flow grouping algorithm? (Put another way, can you > provide implementers stronger guidance as to what sort of > _in_efficiencies would be experienced if they anyway went ahead and > used the algorithm in 3.2.1 across hundreds+ flows? I could also see > that detail perhaps being out of scope, so just a suggestion.) For hundreds of flows I expect the sorting required by the grouping algorithm could become an issue, but it is beyond the scope of a RMCAT document to discuss that (as you suggest). It is mentioned because the basic SBD algorithm is generic, and can be applied to more than just RTC-Web. On the number of flows for RTC-Web, draft-ietf-rtcweb-use-cases-and-requirements-14 requires RTC-Web be capable of working with "several" flows and draft-ietf-rmcat-eval-test-00 tests with up to 5 media flows. This mechanism is more than sufficient for these numbers. Does anyone on the list have any more information on the expected numbers of flows? > > 4.1. For implementers it may be helpful if -01.txt elaborated on time > stamp resolution considerations. (The current text implies that > typical RTP media flows use sub-millisecond timers whose resolution > is 'less than one hundredth of a typical paths range of delays'. > Would be useful to capture your thoughts on what happens when the > paths are tens of ms, or the timers aren't "sufficiently" > sub-millisecond.) > > cheers, > gja > > David Hayes on Fri, 10 Oct 2014 17:37:10 +0200 > wrote: > > > > Dear All, > > > > We have just submitted of our initial shared bottleneck detection > > draft and will value your comments and suggestions. > > > > Regards, > > > > David > > > > Begin forwarded message: > > > > Date: Fri, 10 Oct 2014 08:17:57 -0700 > > From: > > To: Michael Welzl , David Hayes > > , Michael Welzl , Simone > > Ferlin , Simone Ferlin , David > > Hayes Subject: New Version Notification for > > draft-hayes-rmcat-sbd-00.txt > > > > > > > > A new version of I-D, draft-hayes-rmcat-sbd-00.txt > > has been successfully submitted by David Hayes and posted to the > > IETF repository. > > > > Name: draft-hayes-rmcat-sbd > > Revision: 00 > > Title: Shared Bottleneck Detection for Coupled > > Congestion Control for RTP Media. Document date: 2014-10-10 > > Group: Individual Submission > > Pages: 12 > > URL: > > http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ > > Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 > > > > > > Abstract: > > This document describes a mechanism to detect whether end-to-end > > data flows share a common bottleneck. It relies on summary > > statistics that are calculated by a data receiver based on > > continuous measurements and regularly fed to a grouping algorithm > > that runs wherever the knowledge is needed. This mechanism > > complements the coupled congestion control mechanism in > > draft-welzl-rmcat-coupled-cc. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > > > > > -- > > > > ------------------------- > > David Hayes > > davihay@ifi.uio.no > > Department of Informatics > > University of Oslo > > -- ------------------------- David Hayes davihay@ifi.uio.no Department of Informatics University of Oslo From nobody Tue Oct 21 08:37:08 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222CC1A8830 for ; Tue, 21 Oct 2014 08:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRyIISz433Rv for ; Tue, 21 Oct 2014 08:37:03 -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 5B61E1A87D9 for ; Tue, 21 Oct 2014 08:37:03 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgbUb-0002Sn-JQ; Tue, 21 Oct 2014 17:37:01 +0200 Received: from [129.240.66.44] (helo=hayesd-laptop) by mail-mx3.uio.no with esmtpsa (SSLv3:AES128-SHA:128) user davihay (Exim 4.80) (envelope-from ) id 1XgbUa-0006HV-O4; Tue, 21 Oct 2014 17:37:01 +0200 Date: Tue, 21 Oct 2014 17:36:59 +0200 From: David Hayes To: Mirja =?UTF-8?B?S8O8aGxld2luZA==?= Message-ID: <20141021173659.44ecd880@hayesd-laptop> In-Reply-To: <544625C1.3050808@tik.ee.ethz.ch> References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> Organization: University of Oslo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-mageia-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 1529 max rcpts/h 38 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3B351EC59498E1D12F342C99BC3B8273D76359F7 X-UiO-SPAM-Test: remote_host: 129.240.66.44 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 1 total 414 max/h 5 blacklist 0 greylist 1 ratelimit 0 X-UiOonly: E7A338D14B1A15BB67BFC4716475AC794C8DF5C2 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/Vk0lLz7_JKEVJStxnzuHIKYSXFM Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:37:06 -0000 Hi Mirja, Thank you for going through this and giving your comments and questions! I have answered your questions inline. Regards, David On Tue, 21 Oct 2014 11:22:09 +0200 Mirja K=C3=BChlewind wrote: > Hi David, hi all, >=20 > I've read your document and have a couple of questions (as an > individual contributor): >=20 > 1) You propose to use the OWD, to do all the calculation at the > receiver and to signal the information to the sender. Did you also do > some analysis how good your approach would be if you use RTT (because > than the sender could also work independent of the receiver)? >=20 > 2) You also talk about a receiver based approach. I'm not sure if > this case is needed because that's the case where simply congestion > control does its job. While if one sender has multiple flows it seems > to be more reasonable for me to couple these. >=20 > 3) Am I right to that you need an initial set-up time of 17.5 sec? Not quite. Decisions can start to be made after T (nominally 350ms), though with far less accuracy, but increasingly more accurately as time progresses. This needs to be outlined in the draft.=20 > Can you also explain a little further why you've chosen 350ms and > N=3D50? Roughly, T should to be long enough to capture the short term variance in the OWD, but not too long so as to be able to sample the low frequency oscillations of OWD on the bottleneck. T=3D350ms provided good results (though not necessarily optimal) on the two very different networks we tested it on in the LCN paper. However, the dynamics on the Internet can change. T is one the parameters sent in the initialisation message, so although we want to recommend a good "all round" value for it, it can be changed to suit specific network dynamics. The system will need to keep N samples of many of the statistics. With larger values of N, many of the parameters can be calculated more accurately (or less noisily), but at the expense of memory and sensitivity to changing network conditions. Also, if N is too small it is difficult to get a good freq_est for comparison. N=3D50 was found to be good "all round" value in our tests so far. It too is one of the parameters sent during initialisation, potentially allowing an application to set it according to its needs for network dynamic sensitivity.=20 > 4) Can you also explain with which (network) effect you have > skewness? Is this really an effect in real systems that gives you > valuable information? OWD skewness (in an abstract way) is a function of the load at the bottleneck and the traffic dynamics. When a queue becomes congested, the queue distribution becomes skewed toward the back of the queue (At extreme loads the dynamic changes again). It is important in the algorithm for a number of reasons: 1. If there is no congestion along the path, all of the delay statistics are too noisy to be useful for grouping flows (there is no bottleneck!). Skewness is used to determine whether a flow is experiencing congestion -- or to put it another way that the statistics will be reliable for grouping flows. Other possible metrics could be: - magnitude of delay (but we do not know how long the queue is at the bottleneck and what the OWD_min is) - loss (loss can be caused by other factors, and may be to rare) - ECN (this will be good in the future, but is not reliable now - the bottleneck may not be ECN enabled) - etc Skewness was found to be a reliable congestion indicator that did not require any prior knowledge of queuing along the path. 2. Two similar bottlenecks with similar traffic but different loads can exhibit a similar variance, but will have a different skewness. This helps to distinguish this case. >=20 > 5) If you look at the variance (and use the max) you might want to > apply some kind of filtering first e.g. to filter out single out > liners (due to some processing delays). This is a good point, especially the further from the network interface measurements are made. Min would be a better option in terms of noise, but (in theory) Min is load ambiguous (see 2. above) at similar loads to where skewness is (there is a discussion in the LCN paper concerning this). A simple filter, ie second highest OWD, may be enough. >=20 > 6) Can you also explain a little more, why you also use the > oscillation frequency and the value p_v=3D0.2? While the other metrics > actually measures some kind of network behavior, e.g. delay variance > is determined by the queue size, the oscillation size is determined > by the congestion control behavior. I guess the flows have to use the > same congestion control scheme...? >=20 The low frequency oscillation of OWDs at a bottleneck depends on many things including: the queue size, other traffic at the bottleneck (flows starting, flows leaving, etc), and the combined behaviour of all of the traffic's congestion controllers. In our experiments (and general observations of OWD graphs), the low frequency oscillation of OWDs is discernibly different between different bottlenecks. This metric tries to capture that difference with an efficient estimate that can be easily compared. We use the short term variation in the signal, p_v, as a guide for de-noising. The skewness congestion test 4)1. above helps to ensure that we are measuring a signal and not just noise. > 7) For packet loss you can also estimated the loss frequency. I would > think if the congestion control operates loss-based that this would > actually give you a pretty good estimate if flows share the same > bottleneck. Or even easier if the loss of the flows always occur in > the same RTT. When the the packet loss rate is high, this becomes a reliable measure and is used by the algorithm. However, when the packet loss rate is low the signal is too rare to be useful. Within an RTT (we are looking at OWD) not all flows traversing a bottleneck will necessarily experience packet loss. Also, not all flows will necessarily have the same RTT, having different paths to their destinations. Hassayoun, Iyengar, and Ros in their paper "Dynamic window coupling for multipath congestion control", look at a similar idea for MPTCP. The SBD is intertwined with the congestion control, and although sufficient for their purpose, has different objectives and I don't think can be applied to achieve a reliable grouping in the RMCAT scenario. >=20 > 8) And one last question regarding the grouping: Do you always need > to apply all three conditions? Why are those three needed? >=20 All the statistics are noisy making fine grain grouping based on one statistic difficult. Using a number of statistics summarising different aspects of the signal allows us to more coarsely group based on each statistic (allowing for the noise) but still obtain a fine enough grouping. An aside on the noise: The noise is caused by the same things that we are looking for in the "signal" from the bottleneck: queueing, packet loss, etc. The bottleneck "signal" is generally stronger than the noise from the other devices along the path, but still the signal and noise have similar characteristics. This similarity makes filtering difficult. > Mirja >=20 >=20 >=20 > On 10.10.2014 17:37, David Hayes wrote: > > Dear All, > > > > We have just submitted of our initial shared bottleneck detection > > draft and will value your comments and suggestions. > > > > Regards, > > > > David > > > > Begin forwarded message: > > > > Date: Fri, 10 Oct 2014 08:17:57 -0700 > > From: > > To: Michael Welzl , David Hayes > > , Michael Welzl , Simone > > Ferlin , Simone Ferlin , David > > Hayes Subject: New Version Notification for > > draft-hayes-rmcat-sbd-00.txt > > > > > > > > A new version of I-D, draft-hayes-rmcat-sbd-00.txt > > has been successfully submitted by David Hayes and posted to the > > IETF repository. > > > > Name: draft-hayes-rmcat-sbd > > Revision: 00 > > Title: Shared Bottleneck Detection for Coupled > > Congestion Control for RTP Media. Document date: 2014-10-10 > > Group: Individual Submission > > Pages: 12 > > URL: > > http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ > > Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 > > > > > > Abstract: > > This document describes a mechanism to detect whether > > end-to-end data flows share a common bottleneck. It relies on > > summary statistics that are calculated by a data receiver based on > > continuous measurements and regularly fed to a grouping algorithm > > that runs wherever the knowledge is needed. This mechanism > > complements the coupled congestion control mechanism in > > draft-welzl-rmcat-coupled-cc. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > > > --=20 ------------------------- David Hayes davihay@ifi.uio.no Department of Informatics University of Oslo From nobody Tue Oct 21 11:19:49 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB611A6FF1 for ; Tue, 21 Oct 2014 11:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.511 X-Spam-Level: X-Spam-Status: No, score=-11.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWo-WpWRUrxx for ; Tue, 21 Oct 2014 11:19:36 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF781A871D for ; Tue, 21 Oct 2014 11:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=94536; q=dns/txt; s=iport; t=1413915565; x=1415125165; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dod3rS+X56imx6n58riNlFFF+svzEhxsX0j7A6TyD7s=; b=k4ZE66hFSK3+xHLHZ97/ddut3mmdzD+s334kbKFKaGs9a6WUkzb8sXVw fTH5SH6KyVyI2ITbHI34Sgb+n+/FDpn1PZcqZ3rmy+E0V8yy7k0pc2vXX Yow6P2B0AVd6REjE1VC6X7BTEyVDz/cs/RNodeajZ3i0V40G9GcPg7HEu 4=; X-Files: Skewness_metric.pdf : 61939 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADJxRlStJA2L/2dsb2JhbABcgw6BKwSDAtBvAht2FgF9hAIBAQEDASMiMgIFBwQCAQgOAwQBAQsdAwICAhgYFAkIAgQBDQUIBogpCK8OlGkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkCAWFgUHBoJxNoEeAQSPZYIcgg6BUIJghkuQcYQBg3dsAYFHgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,763,1406592000"; d="pdf'?scan'208";a="362072456" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP; 21 Oct 2014 18:19:24 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9LIJNAd008763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 18:19:23 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.5]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 13:19:23 -0500 From: "Michael Ramalho (mramalho)" To: David Hayes , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt Thread-Index: AQHP7RCEoF+eJFnbf0KFxHP/kALCP5w7A2SA//+83qA= Date: Tue, 21 Oct 2014 18:19:22 +0000 Message-ID: References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> <20141021173659.44ecd880@hayesd-laptop> In-Reply-To: <20141021173659.44ecd880@hayesd-laptop> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.253.202] Content-Type: multipart/mixed; boundary="_002_D21571530BF9644D9A443D6BD95B910327105C5Exmbrcdx12ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/k5T6ZuV79aCbHFPPs9yiljutq3w Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:19:41 -0000 --_002_D21571530BF9644D9A443D6BD95B910327105C5Exmbrcdx12ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF2aWQvTWlyamEsDQoNClRoYW5rIHlvdSBib3RoIGZvciB0aGlzIHRocmVhZC4NCg0KVGhpcyBp cyB0aGUgZmlyc3QgdGltZSBJIHJlY2FsbCB0aGF0IHNvbWVvbmUgb24gdGhlIFJNQ0FUIGxpc3Qg bWVudGlvbmVkIHRoYXQgYW4gYXN5bW1ldHJpY2FsIG9uZSB3YXkgZGVsYXkgcGRmIChpLmUuLCBu b3QgYXNzdW1pbmcgYSBzeW1tZXRyaWMgc21vb3RoZWQgZGVsYXllZCBoaXN0b2dyYW0gaW4gb3Vy IGRpc2NyZXRlIHRpbWUgd29yaykgY291bGQgYmUgdXNlZCBmb3Igc29tZSB1c2VmdWwgZ3JvdXBp bmcgb3IgY29uZ2VzdGlvbiBwdXJwb3NlLg0KDQpNeSBvbmx5IGNvbW1lbnQgaXMgaW4gdGhlIHRo cmVhZCBiZWxvdyB0aGF0IG1lbnRpb25zIHNrZXduZXNzLiBNeSBjb21tZW50cyBhcmUgcHJlZmFj ZWQgd2l0aCAiTUFSOiIuDQoNCk1pY2hhZWwgUmFtYWxobywgUGguRC4NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHJtY2F0IFttYWlsdG86cm1jYXQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIERhdmlkIEhheWVzDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIxLCAy MDE0IDExOjM3IEFNDQpUbzogTWlyamEgS8O8aGxld2luZA0KQ2M6IHJtY2F0QGlldGYub3JnOyBT aW1vbmUgRmVybGluLU9saXZlaXJhOyBNaWNoYWVsIFdlbHpsIFdlbHpsDQpTdWJqZWN0OiBSZTog W3JtY2F0XSBGdzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXllcy1ybWNh dC1zYmQtMDAudHh0DQoNCkhpIE1pcmphLA0KDQpUaGFuayB5b3UgZm9yIGdvaW5nIHRocm91Z2gg dGhpcyBhbmQgZ2l2aW5nIHlvdXIgY29tbWVudHMgYW5kIHF1ZXN0aW9ucyENCg0KSSBoYXZlIGFu c3dlcmVkIHlvdXIgcXVlc3Rpb25zIGlubGluZS4NCg0KUmVnYXJkcywNCg0KRGF2aWQNCg0KT24g VHVlLCAyMSBPY3QgMjAxNCAxMToyMjowOSArMDIwMA0KTWlyamEgS8O8aGxld2luZCA8bWlyamEu a3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4gd3JvdGU6DQoNCj4gSGkgRGF2aWQsIGhpIGFsbCwN Cj4gDQoNCioqKiogLi4uIFNOSVAgLi4uICoqKioNCg0KPiA0KSBDYW4geW91IGFsc28gZXhwbGFp biB3aXRoIHdoaWNoIChuZXR3b3JrKSBlZmZlY3QgeW91IGhhdmUgc2tld25lc3M/IA0KPiBJcyB0 aGlzIHJlYWxseSBhbiBlZmZlY3QgaW4gcmVhbCBzeXN0ZW1zIHRoYXQgZ2l2ZXMgeW91IHZhbHVh YmxlIA0KPiBpbmZvcm1hdGlvbj8NCg0KT1dEIHNrZXduZXNzIChpbiBhbiBhYnN0cmFjdCB3YXkp IGlzIGEgZnVuY3Rpb24gb2YgdGhlIGxvYWQgYXQgdGhlIGJvdHRsZW5lY2sgYW5kIHRoZSB0cmFm ZmljIGR5bmFtaWNzLiBXaGVuIGEgcXVldWUgYmVjb21lcyBjb25nZXN0ZWQsIHRoZSBxdWV1ZSBk aXN0cmlidXRpb24gYmVjb21lcyBza2V3ZWQgdG93YXJkIHRoZSBiYWNrIG9mIHRoZSBxdWV1ZSAo QXQgZXh0cmVtZSBsb2FkcyB0aGUgZHluYW1pYyBjaGFuZ2VzIGFnYWluKS4gSXQgaXMgaW1wb3J0 YW50IGluIHRoZSBhbGdvcml0aG0gZm9yIGEgbnVtYmVyIG9mIHJlYXNvbnM6DQoJMS4gSWYgdGhl cmUgaXMgbm8gY29uZ2VzdGlvbiBhbG9uZyB0aGUgcGF0aCwgYWxsIG9mIHRoZSBkZWxheQ0KCXN0 YXRpc3RpY3MgYXJlIHRvbyBub2lzeSB0byBiZSB1c2VmdWwgZm9yIGdyb3VwaW5nIGZsb3dzDQoJ KHRoZXJlIGlzIG5vIGJvdHRsZW5lY2shKS4gU2tld25lc3MgaXMgdXNlZCB0byBkZXRlcm1pbmUN Cgl3aGV0aGVyIGEgZmxvdyBpcyBleHBlcmllbmNpbmcgY29uZ2VzdGlvbiAtLSBvciB0byBwdXQg aXQNCglhbm90aGVyIHdheSB0aGF0IHRoZSBzdGF0aXN0aWNzIHdpbGwgYmUgcmVsaWFibGUgZm9y IGdyb3VwaW5nDQoJZmxvd3MuDQoNCglPdGhlciBwb3NzaWJsZSBtZXRyaWNzIGNvdWxkIGJlOg0K CS0gbWFnbml0dWRlIG9mIGRlbGF5IChidXQgd2UgZG8gbm90IGtub3cgaG93IGxvbmcgdGhlIHF1 ZXVlIGlzDQoJICBhdCB0aGUgYm90dGxlbmVjayBhbmQgd2hhdCB0aGUgT1dEX21pbiBpcykNCgkt IGxvc3MgKGxvc3MgY2FuIGJlIGNhdXNlZCBieSBvdGhlciBmYWN0b3JzLCBhbmQgbWF5IGJlIHRv IHJhcmUpDQogIAktIEVDTiAodGhpcyB3aWxsIGJlIGdvb2QgaW4gdGhlIGZ1dHVyZSwgYnV0IGlz IG5vdCByZWxpYWJsZQ0KICAJICBub3cgLSB0aGUgYm90dGxlbmVjayBtYXkgbm90IGJlIEVDTiBl bmFibGVkKQ0KCS0gZXRjDQoNCglTa2V3bmVzcyB3YXMgZm91bmQgdG8gYmUgYSByZWxpYWJsZSBj b25nZXN0aW9uIGluZGljYXRvciB0aGF0DQoJZGlkIG5vdCByZXF1aXJlIGFueSBwcmlvciBrbm93 bGVkZ2Ugb2YgcXVldWluZyBhbG9uZyB0aGUgcGF0aC4NCg0KTUFSOiBJIGhhdmUgYXR0YWNoZWQg YSBzbGlkZSB0aGF0IHNob3dzIHRoZSBkZWxheSBvZiBvbmUgVm9JUCBmbG93IHdoZW4gY29tcGV0 aW5nIHdpdGggMTAgbG9uZy1saXZlZCBUQ1AgZmxvd3MgaW4gYSBib3R0bGVuZWNrIGxpbmsgb2Yg MS4wMjQgTWJwcy4gVGhlIFZvSVAgZmxvdyBpcyA5NiBrYnBzIENCUiBhbmQgdGhlIFRDUHMgaGF2 ZSBubyBwcm9wYWdhdGlvbiBkZWxheSBPVEhFUiB0aGFuIHRoZSBib3R0bGVuZWNrIHF1ZXVlIChp LmUuLCB0aGUgbWVhc3VyZWQgUlRUIGluc2lkZSBhIGdpdmVuIFRDUCBpcyBlc3NlbnRpYWxseSBh IG1vdmluZyBhdmVyYWdlIG9mIHRoZSBib3R0bGVuZWNrIHF1ZXVlIGRlbGF5IC0gc28gdGhlIGR5 bmFtaWNzIG9mIHRoZSBUQ1BzIGFyZSBwcmltYXJpbHkgYSBmdW5jdGlvbiB0aGUgYm90dGxlbmVj ayBxdWV1ZSBkZWxheSBldm9sdXRpb24gaW4gdGltZSkuIFRoZSBxdWV1ZSBsZW5ndGggd2FzIHNl dCBzbyBhcyB0byBlcXVhbCA1MDAgbXMgYXQgdGhlIGxpbmsgc2VydmljZSByYXRlLiBBcyB0aGVy ZSBhcmUgbW9yZSBhbmQgbW9yZSBjb21wZXRpbmcgVENQcywgdGhlIHJlc3VsdGFudCBzbW9vdGhl ZCBoaXN0b2dyYW0gKGJvdHRvbSBncmFwaCkgaGFzIGluY3JlYXNpbmdseSBzaG9ydGVyIHRhaWxz IGluIHRoZSBkaXJlY3Rpb24gdG93YXJkIDAgbXMgKGkuZS4sIG1vZGVzIGFuZCBtZWFuIG5lYXJl ciB0byBxdWV1ZSBkZWxheSBtYXgpLCB3aGVyZWFzIGEgaGlzdG9ncmFtIGZyb20gYSBtaW5pbWFs bHkgIHV0aWxpemVkIHN5c3RlbSB3aWxsIG5vcm1hbGx5IGhhdmUgYSB0YWlsIG9mIHRoZSBkZWxh eXMgYXdheSBmcm9tIDAgKHdpdGggbWVhbiBhbmQgb25seSBtb2RlIG5lYXIgMCBtcykuDQoNCk1B UjogU28gY2xlYXJseSBjb21wZXRpbmcgd2l0aCBtb3JlIHNvdXJjZXMgdGhhdCBkZW1hbmQgcXVl dWUgb3ZlcmZsb3cgZm9yIHRoZWlyIGNvbmdlc3Rpb24gY29udHJvbCB3aWxsIGFmZmVjdCB0aGUg b2JzZXJ2ZWQgc2tld25lc3MgLSB3aXRoIG1vcmUgImNvbmdlc3Rpb24iIChJIGRlc2lyZSBhIGJl dHRlciBkZWZpbml0aW9uIG9mIHRoYXQgdGVybSkgcmVzdWx0aW5nIGluICJ0YWlsIHNrZXduZXNz IHRvd2FyZCB6ZXJvIiBhbmQgbGVzcyB2YXJpYW5jZSBhYm91dCB0aGUgbWVhbiAob2YgdGhlIGRl bGF5IGhpc3RvZ3JhbSkuDQoNCk1BUjogSWYgYWxsIGNvbXBldGluZyBmbG93cyBhcmUgUk1DQVQg Zmxvd3MsIHdlIGV4cGVjdCB0aGVtIHRvIG9zY2lsbGF0ZSBhYm91dCBzb21lIGVxdWlsaWJyaXVt IHF1ZXVlIGRlbGF5IChob3BlZnVsbHkgc29tZSBzbWFsbCBhbW91bnQpIGFuZCB0aHVzIHNob3Vs ZCBleHBlY3QgYSAic3ltbWV0cmljIiBkaXN0cmlidXRpb24gYWJvdXQgdGhpcyBlcXVpbGlicml1 bSAobWVhbikgdmFsdWUgKGFzc3VtaW5nIHRoZSBxdWV1ZSBuZXZlciBkcmFpbnMgY29tcGxldGVs eSkuIFdoZW4gdGhlcmUgYXJlIHNtYWxsIHBlcmlvZHMgb2YgdGltZSB3aXRoICJubyBpbnN0YW50 YW5lb3VzIGNvbmdlc3Rpb24iICh0aGUgcXVldWUgZHJhaW5zIGV2ZXJ5IHNvIG9mdGVuKSwgdGhl cmUgaXMgeWV0IGFnYWluIHNvbWUgYmlhcyB0b3dhcmQgdGhlIG1pbmltdW0gT1dEIChhbmQgYW5v dGhlciBtb2RlIGluIHRoZSBkaXN0cmlidXRpb24gbmVhciB6ZXJvIHF1ZXVlIGRlbGF5KS4NCg0K TUFSOiBPZiBjb3Vyc2UsIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBib3R0bGVuZWNrcyAtIGVhY2gg ZXhwZXJpZW5jaW5nIHNvbWUgY29uZ2VzdGlvbiAtIHlvdSBjYW4gZXhwZWN0IGEgY29udm9sdXRp b24gb2YgdGhlIGRpc3RyaWJ1dGlvbnMgcmVzdWx0aW5nIGluIG11bHRpcGxlIG1vZGVzIChpLmUu LCBtdWx0aXBsZSBsb2NhbCBtYXhpbWEgaW4gdGhlIE9XRCBoaXN0b2dyYW0pLiBTbyBJIGFtIGRv dWJ0ZnVsIHRoYXQgdGhpcyB0ZWNobmlxdWUgY291bGQgYmUgdXNlZCBmb3Igc3VjaCBjYXNlcyAt IGJ1dCBJIGFtIGxpc3RlbmluZyBoZXJlIGlmIHlvdSBoYXZlIGFuYWx5dGljYWwgdW5kZXJzdGFu ZGluZyBjb3VudGVyIHRvIG15IGludHVpdGlvbiAodGhhdCBoYXBwZW5zISkuDQoNCk1BUjogQWdh aW4sIEkgaGF2ZSBub3QgdGhvdWdodCBvZiB1c2luZyBzdWNoIGEgbWV0cmljIC4uLiBidXQgcGVy aGFwcyBoaWdoIHNrZXduZXNzIGFib3V0IGEgbWVhbiBpbiBhIGNsdXN0ZXIgb2YgaW5kaXZpZHVh bCBPV0QgZGF0YSBwb2ludHMgbmVhciB0byB0aGUgaGlnaGVzdCBkZWxheSBmb3IgdGhlIHF1ZXVl IGNvdWxkIHNpZ25hbCBzdWNoIGEgY29uZ2VzdGlvbiBieSBub24tZGVsYXkgYWRhcHRpdmUgc291 cmNlcy4gQW5kICBJIHRoaW5rIGluIHRoaXMgY2FzZSBhIGxvd2VyIHZhcmlhbmNlIG1pZ2h0IGlu ZGljYXRlICJtb3JlIGNvbXBldGluZyBzb3VyY2VzIiAoc2ltaWxhciB0byBteSBtdWx0aXBsZSBU Q1AgZXhwZXJpbWVudCkuDQoNCgkyLiBUd28gc2ltaWxhciBib3R0bGVuZWNrcyB3aXRoIHNpbWls YXIgdHJhZmZpYyBidXQgZGlmZmVyZW50DQoJbG9hZHMgY2FuIGV4aGliaXQgYSBzaW1pbGFyIHZh cmlhbmNlLCBidXQgd2lsbCBoYXZlIGEgZGlmZmVyZW50DQoJc2tld25lc3MuIFRoaXMgaGVscHMg dG8gZGlzdGluZ3Vpc2ggdGhpcyBjYXNlLg0KDQpNQVI6IFNpbmNlIHRoZSB0d28gInNpbWlsYXIg Ym90dGxlbmVja3MiIChpLmUuLCBzaW1pbGFyIHNlcnZpY2UgcmF0ZXMpIGNvdWxkIGhhdmUgZGlm ZmVyaW5nIGJ1ZmZlciBsZW5ndGhzIGluIGZyb250IG9mIHRoZW0gKGkuZS4sIHRoZSBtYXhpbXVt IGRlbGF5IG9mIHRoZSB0d28gaW5kaXZpZHVhbCBib3R0bGVuZWNrcyBjb3VsZCBiZSB2ZXJ5IGRp ZmZlcmVudCksIEkgZG9uJ3Qgc2VlIGhvdyB5b3UgY2FuIHVzZSB0aGlzIHRlY2huaXF1ZSB0byBk aWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlbS4gSXQgbG9va3MgbGlrZSB5b3UgYXNzdW1lZCB0aGUg dHdvIGJvdHRsZW5lY2tzIGhhZCBzaW1pbGFyIHdvcnN0LWNhc3QgcXVldWluZyBkZWxheXMgKGEg cG9vciBhc3N1bXB0aW9uIGJlY2F1c2Ugb25lIG9mIHRoZSBib3R0bGVuZWNrIGxpbmtzIGlzIG9m dGVuIHRoZSBhY2Nlc3MgbGluayB3aXRoIGEgdHlwaWNhbGx5IGxhcmdlciB3b3JzdC1jYXNlIGRl bGF5KS4NCg0KTUFSOiBGb3IgdHdvIGJvdHRsZW5lY2tzIGVhY2ggaGF2aW5nIHRyYWZmaWMgdGhh dCBkZW1hbmRzIHF1ZXVlIG92ZXJmbG93IGZvciB0aGVpciBjb25nZXN0aW9uIGNvbnRyb2wgKGUu Zy4sIFRDUCkgSSB3b3VsZCBleHBlY3QgdGhlIGNvbnZvbHV0aW9uIG9mIHRoZSBpbmRpdmlkdWFs IG1vZGVzLiBJZiB0aGUgbWVhbiBkZWxheSBvZiBib3RoIHdlcmUgc3VmZmljaWVudGx5IGRpZmZl cmVudCwgb25lIG1pZ2h0IGJlIGFibGUgdG8gZGlmZmVyZW50aWF0ZSB0aGUgc2tld25lc3Mgb2Yg dGhlIGluZGl2aWR1YWwgbW9kZXMgZm9yIGdyb3VwaW5nIHB1cnBvc2VzLiBXb3VsZCBiZSBhIG5p Y2UgTWFzdGVycyBwcm9qZWN0IHRvIGludmVzdGlnYXRlIChnb3QgYSBzdHVkZW50IGluIG1pbmQ/ KS4NCg0KPiANCj4gNSkgSWYgeW91IGxvb2sgYXQgdGhlIHZhcmlhbmNlIChhbmQgdXNlIHRoZSBt YXgpIHlvdSBtaWdodCB3YW50IHRvIA0KPiBhcHBseSBzb21lIGtpbmQgb2YgZmlsdGVyaW5nIGZp cnN0IGUuZy4gdG8gZmlsdGVyIG91dCBzaW5nbGUgb3V0IA0KPiBsaW5lcnMgKGR1ZSB0byBzb21l IHByb2Nlc3NpbmcgZGVsYXlzKS4NCg0KVGhpcyBpcyBhIGdvb2QgcG9pbnQsIGVzcGVjaWFsbHkg dGhlIGZ1cnRoZXIgZnJvbSB0aGUgbmV0d29yayBpbnRlcmZhY2UgbWVhc3VyZW1lbnRzIGFyZSBt YWRlLiBNaW4gd291bGQgYmUgYSBiZXR0ZXIgb3B0aW9uIGluIHRlcm1zIG9mIG5vaXNlLCBidXQg KGluIHRoZW9yeSkgTWluIGlzIGxvYWQgYW1iaWd1b3VzIChzZWUgMi4gYWJvdmUpIGF0IHNpbWls YXIgbG9hZHMgdG8gd2hlcmUgc2tld25lc3MgaXMgKHRoZXJlIGlzIGEgZGlzY3Vzc2lvbiBpbiB0 aGUgTENOIHBhcGVyIGNvbmNlcm5pbmcgdGhpcykuIEEgc2ltcGxlIGZpbHRlciwgaWUgc2Vjb25k IGhpZ2hlc3QgT1dELCBtYXkgYmUgZW5vdWdoLg0KDQpNQVI6IE91dGxpZXJzIGFyZSBvdXRsaWVy cyAtIHlvdSBjYW4ndCBhc3N1bWUgImp1c3Qgb25lIiAoaW4gcGlja2luZyB0aGUgInNlY29uZCBo aWdoZXN0IE9XRCIpLiBUbyBkbyB0aGlzIGNvcnJlY3RseSBzdGF0aXN0aWNhbGx5IHlvdSBuZWVk IHRvIHVzZSBjbHVzdGVyaW5nIHRlY2huaXF1ZXMgdG8gbWFrZSBzdXJlIHlvdXIgIm1heCBvciBt aW4iIHNhbXBsZXMgYXJlIHJlYXNvbmFibGUgZGF0YSBwb2ludHMgLSBidXQgcGVyaGFwcyB1c2lu ZyBkYXRhIHBvaW50cyB3aXRoaW4gdGhlIENERiA1JSB0byA5NSUgcmVnaW9uIGFyZSBnb29kIGVu b3VnaCBmb3IgYSB1bmltb2RhbCBPV0QgaGlzdG9ncmFtLg0K --_002_D21571530BF9644D9A443D6BD95B910327105C5Exmbrcdx12ciscoc_ Content-Type: application/pdf; name="Skewness_metric.pdf" Content-Description: Skewness_metric.pdf Content-Disposition: attachment; filename="Skewness_metric.pdf"; size=61939; creation-date="Tue, 21 Oct 2014 17:52:33 GMT"; modification-date="Tue, 21 Oct 2014 17:52:33 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDExIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDEvS2lkc1sgMyAwIFJdID4+ DQplbmRvYmoNCjMgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwv RXh0R1N0YXRlPDwvR1M1IDUgMCBSPj4vWE9iamVjdDw8L0ltYWdlNiA2IDAgUi9JbWFnZTcgNyAw IFI+Pi9Gb250PDwvRjEgOCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0lt YWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgNCAwIFIvR3JvdXA8PC9U eXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJl bnRzIDA+Pg0KZW5kb2JqDQo0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE1 NjE+Pg0Kc3RyZWFtDQp4nJVXWW/bRhB+F6D/sC8FuEG02ZtLIAjQ2E7qomlzqC1Quw+OLduqdSSW k9R96G/vN7MkRZ1244jcY66d/eagePZWPH/+7M3B8aHQL16Il4cH4nO/p4VWWmtjrS5FabUIXovb Ub/3+xMx6/eevf4QxNWi3zPiqiXWOhrtV6gvn/R77/o9cfTmQIiOJrOhyXpv/BZNtEJ/1kQVEw+M cl6cT2HF8fTsahTF4VxsU2I3j5OcMXuVOGUiBkmV2qaOknKXElcreTkE6SsjTBLDS/ILyTPQoypj RalKiBtOyRJ22Ot+76QwcuAKTQ8hbSiG0pji4K00LhZPhRyYWPw8FzK64vsLIuLHqB0J6dKSJxbE 4TtEEznwxRmN7mWJXRCeFnOa313LQchEt7yeF5h21przmUZfWnHL0amEddYWhyOoiB0VCzlImWS0 KupjS/KbDDYbMSbzzknAqKV7y7J48abduVvIP8Xwx37vCC4mNze+jSkq13HtCYQsKTduytc3BXZV BgcRt7gKW0YFiBvrlbXCeqNKL4JWqbItgolefKuvDfx/iQfZPmwxIHSg0pzBJq9cEiY4lewGQOAt v9tbn2i01WPYdjuRsCA6FvAVMxZ8e/elBQAT8+N+h9+DrlQouzaver5L64wlBxnHr0y7VPNNmrBu mCdLdCcygM9/hayK0K7VG9s1+gBEdBXiuo2NYnh+Ukx3Qcknoyq/ysUcexEV6wvlK/OxpARlTFDR CUgI8I9G6FfKOyMmtGBVCcAmwsokc7gKHJ50Y+EaNL4iJqAiAXO1lBCZqQosxQN5kFKq5OqFgCEv 6CRoFj3NquDzzBC3CZU4z8QYYcHFwNvZItjGMxhCszITw2CSjBOE1JwANw+KFG3WnZRnc70tmwVb 0UKoSCL0OD4NtpmY96pgsjFJxShSQCgF3k4Vzzwlzq4jztk5l1vuoGyj2jQRjZyLAmHhOLxcwNmd sJCWzDKiKb4epNwWxGlbEEdLd26jUabak+X58V2L6p/awOZMedPG5a934zYIefQPooPDhDZizgjL 7Hq6P+n79bj5nwEVSuS40D3dYyIqVHzZK1zMcSp3pXPt1zgeCL9qrfQ6imG/Un6t0SoiYTlKslkk Vy3kzXtpdF0z55eoSwPUpXGdTOFMAfdRObJ5fsOLO0tRcFUuAB1F6/4kE+2qeTEoh8DzpVXNidcu ZSoHSIy4s1S8pPlRvqlUvPvSpvtlZX666w5tTJTYuooYlkpTtrU09Psw4ByCtlzhf/PxE/EuyJiM 5NmNoPclfGoyRicTWdevb4S68ewKc/HqmFZe/ULO3X6UXfUeRqQVI/biwzT9rFbBc9Uv0dshS3rO Ew4dJdKd0xHpDUgJ1PptzRMPUW7LE8bsbwwddQ6QieSPDLmeMw7mU+qlPrU3mwOfY/6qbf64fHKC yA1cRrN5MKI91Yqqq/ukaSR3Atyidq2x7He+XTofJQZup8ZaQQA7H61bcFF4i5hF6q+47lJlg4Mb 52/K3Gi2o6Ivjq5fDZowD8EoJqgb7Ne628vVYTl7z57+YyRDcYvfXLIDfXGIyKfFyZmkLJooY+oc fbR8lxsX9L80o9+MOUEzPKCkQY7kvHyU03RAeqZmLasYzyCVZSz7MCb8m3q2usPL5EzFgi9pNK8N ZSPZnHlDxI/JSGZ1xL/sCIX0ungnKbbyVn7vCDETuq7bnsTgdb0K5gpYLnF/iInQcJ4W2bpQXCPo RxT4NHkvrSmGQBsXr7qnnWMXgDclzu1hoM+MZ81gPJ9JOomrajLauWjFVvDqgukuRg0d7iLQXeis ZszfJkRKLOz6RfY1Vd9Gzdlkct8IWDO9wkeMZ0N5gx+TEZlF+113Q9vn+hSjzptENCZPUH2qPZWw 1JRvVty5P9j87sAY1N/m+IcGVwzwv7sSqHWxArFIekwbJ6YTIx/qSmQyhFvYXdeIumBUAmZbQgdk P9BnxoIK2V2D46say2f4Tde88DiDLVp186jvPhM2nVPj92FVaL0tqjT61awJX2SBUXBMAFji67AG Qr5ZRvrXzreWR361gCk5sdqIvkeZ4dEehW2fW3zg/wBIY5XGDQplbmRzdHJlYW0NCmVuZG9iag0K NSAwIG9iag0KPDwvVHlwZS9FeHRHU3RhdGUvQk0vTm9ybWFsL2NhIDE+Pg0KZW5kb2JqDQo2IDAg b2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxNTk5L0hlaWdodCA3OTAv Q29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNl L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDMyMDY+Pg0Kc3RyZWFtDQp4nOydjXaruA5Gef+X 5s49TYwsfRI2kIQ2e6+sTgK29Qu1VHJmXQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP4mi+Kla0op x3QoFqkPyhWKAQfUOzB+d8wsh9e8JA0yZWadWQ/YDevrGEm/3VkHxhyTCwAAAAAAAPDbeU/zJGsW 1SOzxYsVWtOpWLNeYe37LQfUOzP+Eo51UV7UAznmTBnH3blvaOOMpN/urANjjskFAAAAAAAA+AO8 oXlyYXco9jRGqvip5tX53trUFJpXxay7Na/OpN+Z5tWuXAAAAAAAAIA/jGwpyPbO+BeUxh8LOdAd Wo92D+z7wSfBptpuu1PW3LeDZzNx42tGEfG4c9FIPuw2XqT+B5pXTsns4K4J4wd3AzplUX12ZMzI agAAAAAAAAB/iaL6lq2Jkar5TEU/u/6ILNl4iWeLlk7W86llFevHg7sqZaYVSw2aGQfsrjCeGwea V5nVtdARrU56e3fYm5tX42kJAAAAAAAA8HsZbF5l42fXjCNnu0O1PnWHpLBISh/vt4xMGW8lSfV2 xV3YvBpcv3gvZw3GemT9Y22ocbcXXN682g2NlDt7VQIAAAAAAAD8UmL1HdsLL21ezam7p8/gx6wP MNUK29UtCt31bWzs/KXmlZQbx2dtrsPNq8yx7kh2MLMoGnUs1QdddEwuAAAAAAAAwG9npAq+vHk1 29AY16c+tdsSqVcYUXjW2MGO0Fc1r6YUm9JwUGI969rmVZaWV8kFAAAAAAAA+O2MtG5ONq+KFV7X vDr8EEu9yGwnZLwRZN9MtUTqpQqJmeYfbF7Vup1vXl3S8rq2eTU+huYVAAAAAAAAfCeyP+P6J+eb V3LZwdV2149Prew+zTLYcinWKdostdzat7FLU8hyehZrSilyKSl9MB+mli3MqRfJLHIJUJswfrBO nkKl3VmFmYflAgAAAAAAAAC8n93mFQAAAAAAAAAAwKegeQUAAAAAAAAAMMWi+EXr/xZ2Df9OtwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAwGcZ/B8DZQcBAAAAAAAAAABehPwfQ48fBAAAAAAAAAAAeB2y B0XzCgAAAAAAAAAA7gDNKwAAAAAAAAAAuC2tMWX/JatjzSv5v00HAAAAAAAAeBEvrJYB4Da46305 8W9ecW+5Lbj9zhCdO0N0bguhuTNE584QndtCaO4M0fkINK8AwDLepxppXr1ERTgNobkzROfOEJ3b QmjuDNG5M0TnthCaO0N07gzRAfgSaF59A4TmzhCdO0N0bguhuTNE584QndtCaO4M0bkzRAfgS6B5 9Q0QmjtDdO4M0bkthObOEJ07Q3RuC6G5M0TnzhAdgO9Bfl94/KA9+w51YR5Cc2eIzp0hOreF0NwZ onNniM5tITR3hujcGaIDALNw37gthObOEJ07Q3RuC6G5M0TnzhCd20Jo7gzRuTNEBwBm4b5xWwjN nSE6d4bo3BZCc2eIzp0hOreF0NwZonNniA4AzJJ9lxB+Ke9Poe8EV98ZonNbCM2dITp3hujcFkJz Z4jOnSE6ADCLvG9wM/mlELi3gavvDNG5LYTmzhCdO0N0bguhuTNE584QHQCYhebVX4LAvQ1cfWeI zm0hNHeG6NwZonNbCM2dITp3hugAwCw0r/4SBO5t4Oo7Q3RuC6G5M0TnzhCd20Jo7gzRuTNEBwBm oXn1lyBwbwNX3xmic1sIzZ0hOneG6NwWQnNniM6dIToAMAvNq78EgXsbuPrOEJ3bQmjuDNG5M0Tn thCaO0N07gzRAYBZaF79JQgcAAAAAADcHMoWAJjlfc2r69YcV6+NzKZcZX62juXYIufVAAAAAAAA uA+ULQAwy5c0r160fj3FHdxdluYVAAAAAAD8eShbAGAWmleXzBp0Y70yzSsAAAAAAPjzULYAwCy/ unn18yZ+Ka8diSPdIu6InCXfO6EHmlf1Irtno7jiOAAAAAAAwE2gbAGAWV7bvPpvnex1atWtuRQb TcXZonlVrylHZgfj2dlFxuXuSgQAAAAAALgVlC0AMMsfePJq6mDRsxpcaleTYsrJDlhswe1KBAAA AAAAuBWULQAwC82r2aVW852+M82repF4Nio/IhEAAAAAAOBWULYAwCw0rw4vlR2MZ2fHF02zbG6x LAAAAAAAwH2gbAGAWb6teXV+lnt6Ko6UgqZ0kCIKQYNnAQAAAAAAPg5lCwDM8r7m1XWc/Frf+Kz6 YKaJnCufworLFiIKQYNnAQAAAAAAPg5lCwDM8hubV98MzSsAAAAAAPjVULYAwCw0r34XNK8AAAAA AOBXQ9kCALPQvPotyO8exjHvUQYAAAAAAOAYlC0AMAvNq78EgQMAAAAAgJtD2QIAs9C8+ksQOAAA AAAAuDmULQAwC82rvwSBAwAAAACAm0PZAgCz0Lz6SxA4AAAAAAC4OZQtADALzau/BIEDAAAAAICb Q9kCALPQvPpLEDgAAAAAALg5lC0AMMt7mlfLf0v+e12zWqLeuNpt5AFLl57Z6S/lbvoAAAAAAAA4 KFsAYJZXN69cz+qSFpbsGk21ks4YeOc77Z11AwAAAAAAWClbAGCeNzSvdo9Mr0nzKuHOugEAAAAA AKyULQAwz0ubV1mf6mT/6kc9q6Q8EttZ7Yj82mCc0gaf+ZrhO7m5egAAAAAAAJQtADDLn2xexVPu jTwop7gBd/4Hr1Z+CwAAAAAAwO2hbAGAWX5v82rNe1Z18yo7ODIlPsp12IpXcDd9AAAAAAAAHJQt ADDLL/03r+yb7Nkq93zUSEdrZIrU5CbcTR8AAAAAAAAHZQsAzPKG5tUr/m+D9k395FWctTuF5hUA AAAAAMCLoGwBgFne05P56Vmdb1s9Vkt6Sme+Nlj/i1hraJTFAXfgbvoAAAAAAAA4KFsAYJZf8UCR Y7d5tZb/t8GiPZU9yrWG7lZc/A7cUCUAAAAAAAALZQsAzPIbm1eQQeAAAAAAAODmULYAwCw0r/4S BA4AAAAAAG4OZQsAzELz6i9B4AAAAAAA4OZQtgDALDSv/hIEDgAAAAAAbg5lCwDMQvPqL0HgAAAA AADg5lC2AMAsNK/+EgQOAAAAAABuDmULAMxC8+ovQeAAAAAAAODmULYAwCw0r/4SBA4AAAAAAG4O ZQsAzPIbm1eZeuNqt5GHLb2n3z6uAAAAAAAAQA1lCwDMcs8mTM3yj5GDxQqfVeBFfFwBAAAAAACA GsoWAJiF5tUB6XEFefD9fFwBAAAAAACAGsoWAJjllzav1l5JeSS2s9oR+bXBOKUNlr2yTLEP8nEF AAAAAAAAaihbAGCWqSbMf4c/9YrqFc2reMq9kQfllOxfx6J5BQAAAAAAcADKFgCY5Z5NmBrXUBrv RNUHB6eMTPwUH1cAAACOwN0bAAC+CcoWAJjlnk2YmpHmlcWdlVPcrGKK/FgcfCcfVwAAAI7A3RsA AL4JyhYAmOWeTZiaqSev4qzdKTSvAOAIXIBwGJIHAAC+CcoWAJjlnk2YmqyndOZrg7v/zhXNKwDY gQsQDvMNyfMNNgIAwBiULQAwyz2bMDW7zau1/L8NFu2p7FGuleYVAOzy2QuQy//XMfg/Kfkz/FW7 AL4QLmc4DWULAMxyzyYMHIPAwfdyh+T/0eFTmsw2Pe7gMWh8MG3etn52gYzr8PGk/bgCd+bjzvm2 GyB/LoFfDmULAMxC8+ovQeDge/lsy+gOD884obsKfETDT4m+PzSvZlf7CB9X4Ibc57qmefVOuVO/ bgAUlC0AMAvNq78EgYPv5Q7J/9mvfWXNq0yZD7bX7hCs8xyz4j7heI/cke4uzavLeaee7lbzQRfV nVKn2G8JZcGn2kcfb179gdjBPyhbAGAWmld/CQIHF/BLs+hT/SL38c3Nq6IzUHeKPvts2C/NMcsx BxZNm7/dvFrT6LdkHV3tsxS9x4/rtn7oISgb3w92760m7qc9297fIV4nef8NRP2WmbuEL1RjvUG/ FM5B2QIAs9C8+ksQOLiAX7QbHHmo413SoxJv0mSqeXUfj61vzLFXCLq8efVq3pkGdU72l4z4OL7a exhR4CbNkKbDh26DH4yOv/E6NXYT8rD0qePneYUVUsru2XbNPo9sH19H+91hf4nc4dKDQ1C2AMAs NK/+EgQOLuCX7gbfr/Zz/1wXRbcosbOGwMe1eo8aUyIGBx/TPHY83oaU9Qb/2zKzv0i3OjcesdOL j+9HXkpr8lzZm7W1F9SrIzvYMnoLuoVS32quUvLC5tVIqscxyyLez6oxMlH5M/r55b/yZEw/fluA o1C2AMAsWfMKfinvTyH4a/yu3aAr1t7fKdptXr2NkTZRr/DnFZODX6HA+OL1mKJg35s14YQzGo7P esMlk7c4svaCT8uRiv6duAbIqlJCDn61GuvkhXZadNcyWhYX3/fdkFUuZdnlg3WF9LnjbkwWx2wF N3434oP+lzeHvfHNye7qftVvlmvvonAPKFsAYBbuGwDwW/eEH1G7366PvF6oTFCsfsUGgi+336bh uledXaiVXDMeLLRadYWeOnCgxnQV34S9xzwjlXzdxVKnnKl8o1s6bZ16H78jWY/tpsRLfes+vu02 +Fz2x0ybxllMX6JGU8c00HwiqcvtshvgYuTKs7vLxjjKleWYdZXWeZ8Pmha1jbEL7zN/Lh9pXr0r 3+BaKEIBYBbuGwDw4DfuBt+8iVV/Zd59Xa+G0WdqM98KvTeppzQUdZYt02bLrmG5oqyTRWIm91mv rf2ja6L4TXJPZIVxyIS9UyPLl4/F5dQ9BGXR5hl3qo5OWOdVhBRdZA/npfrEjB25yi6UXjcuLpdY q5PoEOOyJrfreZE7l1V6z5Hr2AXb8TVEOZwq5Om5Z8yJatT9wGupE/uNyQaXQxEKALNw3wCAB1kx e+O7hK6YXqnw/kY/bKxfvsEOdURWVjT9X1trSB2DSk60LydPumu3kAyV407IlqBe9qRBMlEKakGZ sHfKM8lVLF0zseygcJlp0W9P3axv00K1kveWO9Xijapf11/+IXVFUtUX+Blllu42YiV66W+gv60V IZD+8Vf0jFydk/H2Mr7I8EubUFwyMgMLEfZsNG1dvaCWD+bNlfRW64vrPfkGV0MRCgCzcN8AgGo/ vN6veZVv4NPS6RITBr8tmBQPFygglRoreNbwKMIbdIsarqHatQN0+p0VXzpmrZ6m6xIpqZ6SaPtO kVvEThmytzbBDosT7Zsg1Fp02ZWuTJMJuZi+gU3FnWTOLL1K/8yssWutsOuceC1KetXl836eTIoe 8sCLw/FQTHXSdhUbyqharrwG7eUmF5zIoPSVXVA2NA/ptVFLd/vd/JCZNpwAE54c5sOZBq+BIhQA ZuG+AQBuP+x2p7fbGeYbeLmZf0yx0w9JHC2OvPgX7ud9mHIN14GHE16t4W69k0bwhG7pgipilQJl K6ZYfwmPG7kVuvelJ/2bYow9Ei4Bp+0rsjTzVZWi+TWUfnza+AoTMnPGU7rpc4FWuYQinZpcr8CJ C+pn7og3jouYUmY4wUS+uciOiVvDXTdGRAzIVjPLdu/zcBeWdheIFSGtGcjqEaEvDL1y6SfzDa6G IhQAZuG+AQBto+t24xO7+vcyt5V1G/ij5owIlVVNV01cypBKmX9ikfUCTip2ieii/pJlkZ/7WG7M hyojnAIjHlD2PI8XkYqn1CzphLX12a4g8630dpzrohA93CYWUb7KFqvSbChrSw+p4rMry2SfnG6R cwrMJfOlsXDKHIvF4YQZWUosrjSffhl7H+sv3SUhIp4536iXpZPXf/dpq1c8wKncXmjywkyD10AR CgCzcN8A+Gr2KpE1dLQ+rfH/GS1PHqN7tY+aMCTU7f6lPpewF7jx12pr86sZrHd2IvgC0YMqbckz cJm46ftqJKmijMmXccP2BnudewXOOPyY54vp1kl+SvjOaTt1oSFWn+cHFcTgRvvpWt/+6BAX3/fz YAoNSNceGI7vheZ7ZXbsnPFPItdNqT+2I5nyPkOW8D2+ZJiwN9iwiZNeVFZXQRxuXvllTwd6Lo7w q6AIBYBZuG8AfDnTG/sbMLqPzc5My8tLjmzr/5Z9tSwcslpmd8Dl6o367QX1SMyE+ohWtdd0Smer fCqlF2DPSmfqBC6Er2v3Rnlm6R/YOODqXefXiefNMWV1Fgt5/JK0KcxJE8CeS3S4Vp+YQSPp51c4 IT0NaOmEVyA0SXTwifeTd+q2IC6xXtw69WBh9tjtWPh2Xr1Fa38ha//3rirUkM7ZNXa96gHOZxS0 1VmI1f0E7gxFKADMwn0D4MtxG9377wmrDXy+o05fw0K9aLuhjzVAVON6R+zVNU69Pb9dqJjTYsQ/ UqvtwKwKe/lcJ4zUdDDr9Pg6Rlm2FLMzz5uJ0tneUnP6WLS9AruGB5NnYyfHRAMvMKfXR5tmT+yp fUKJKoNGXn61E5qkAU2ccMrwRIfoe5HcTqWYJZORijkwHgLvc6XvyCLa86u6rKStxpYdbed7a5uX Lg2xN7k5IvHMBdLhXVCEAsAs3DcAvpmp7fdNtoV6KztSO7TXnLxkMy/riqSOeJHrKlfY0EaHqONv 0rAOWShJ1kN/ym8WyepmIuGb9L5sEq5W+bZjYO6KLUuTpNNpvCzOfD9r7/I5EuOgQxFQeeTx3z52 MmS7QfxZ5zJbgko6oN4SrfBFquSplWejly6TZ0R4LTFzwiuQt+U6M6x6iaq1wnXu7WRmudRuYqeJ l8f9x0s/se4UyBfIjgwp4KYfDWuUoIXan2/IN3gNFKEAMAv3DYBvRmybkz3hetVfVE9SaJvspUdK iR2Z2dbd7fib9F6N9QXVtFAsFh6FT0KUL9fNqxdLkeFqaMl6NeOi61eeNmtoXvkpQWd3uJJV2NsZ o8PbFBvPzV2HP/57YdyjgZnQZRHTx17CtOtSeke6tuQ1+hztJ+yoNuyEaLHwfgj6BYYPumIwV4Kj mh9qnc+kpVN7UNmdWK/6RrSau1aLb3dk11u9f6oxYdhgRu3GtwpxNP/V+QavgSIUAGbhvgHwzSxr t2Pf3RPeYWeotU020vK1bYEPSJSOinVEkHW965ZEGVd6RJ+4/f/L9vxVsSMjlUfwrOj6Vfiqd6T2 YZ51fpYTUc8NFm0n2xE/SDxsJnSI4XDGnkNLWVRyNkuN0M51uX+Eq92ypw0R5kSVnGl5cM8pkWeU DGiUvvje4Kx0GVIvzv68yvbSG50+0QM+RdIk9J6TYqXPi3CE3F+TS1LoW6zsFsryLQ5/eq/KotI/ YkAy7FhYpRDtlqVPvBdlGrwYilAAmIX7BsCXU+0Xr9qUXqZr2NDGff/Att9v5nfF7tYOsY54vetG t/RRmcRR12mWlB61VqoS6UJ2xj/SS07LOnDOIjtFeViYL2XlDnG2uAW344m9WoEsga9KgyzomdVK rg7ZyKsffMoQa5P1Zwy3PWJPhZEnNBiIZswuJ90dm3kc9GfYThbFnHO2L1feYYY8EGNhIxX80y2Q +EEY3h/cFlk6v1mfR1dJW/QYq6vzv1GmOaq5vR2s1syzV/sz8cM25FBwYzy1+cHqgxLhc1CEAsAs 3DcAvhy9a41719tsDnUF4XbydV0w1b8quhCxggj7fFuzvNwPMnxJYfL//754268jlZc8hdpnpUsv RU3KzOm86w5lVmQXV5QbpkhbRJDdv3A1/tTZmOizbo8ePObnEXOWszlTW7QuIXNi6OXIk/qEFkXl ARXWbZFVNzR2pY9mkQt0r8BxDzw1iTkl/V/lhvKPiKqUXxhuDuroL10jayiU0qhoiPm59r9rfAii FZnfon+cmVKNXlbmxvFYV6paV7o4wu+BIhQAZuG+AfDl6A15sr3/+M5Qb2VlSVBXBzPm7O/23S46 ceB63f3Wrim29K7QKPb/r4nstMeymuiEbpUOzn1JyNxYoequFbuzslTpLBFL2pHb+CX5FnCmzPON M/NM3IUC1mTlMeeGUWfujTxsRTRqxxzp7av0iUk4mF1m2GqSxOkzophbVShjxckQr1c+eZXqU3sm U1itVsj13rYry/erH1uplykcbbR+Vj53uqQRLBSwBzOV9kQfjXGeaXsuOp5Y8HYoQgFgFu4bAN9M 2+zpTanafn9U3bADt59lQZG8tkm7MuXcuNWXZcW/N51rr/KE3NhnZUgx+BVhVWXcjsec8s11x/6J HllmRi/Zgy6Rdl8uzeysYpFMYphSxfo5wA2uJNanwpjt7Wzka0fFQISTi2l0HIlI8NJ5Om/H2GXe LmN6QIf9mIosUe6NkRkWLeREV6gQ/1vo7DdSMyt33JKpV8RO+aRLg1Vdudn7XYWlMsWy1sPPn6v5 reS1k/pn4rIgujlFAjhnzwd6SMkY0zx2cFsoQgFgFu4bAN9Mup2W29GTXwS4Qluvs9zzx614eG32 DQjVIoqtvtrPX+6KKnCFi6KeV6vXLdh8lkUqOjCJ4HH/xKxweTCQOW6I1j+5cHSeuCTpp/z/R2ZL ntLR3H1l1JonQ586qpAYIqD1z80/nzNDdsnYSfUu1Sd1aRbQfoBLNH+wEiyis5NFLtZZxE67QqT6 SG64CCbTd0LgHCqlFPrIeMVTLnIxeLk5NoJDJgz6p1DVOXA5tGFQ+am9FHXOYwe3hSIUAGbhvgHw zaTb6aQcuJe2SsPdqmTWIrF/Ljbw+X7+td4obPx3qqtU1J7/csVE6ZHVTbESiUGc0jBrNMkARV3z bBFrRuueC3o12sHCcGVsp2aiXjN8lRkrM6R3eGfTudBrBaSX+jHSYyIxiohIt5wmBldrotLgrD7y OrI5kQTUpZM/NvxMo524k0WJK7oZ69lHsKoEsK4OufQ4YuMS4tUdq+XaRWWuRp8UK0jv9Wc3/9c/ lfkuLyoFSv9oVZWx67E/dSW/GYQzo87tAPweKEIBYBbuGwDfjNgwl0dupG2ts9x1B1tGLBIbZrmB tyLUPv+13oh+MKd82dLruWl6tWJrrPqzuslVIipkp5wTRdjjuVA3VawZrSvWsafiXGlvFrtCt8zP Upk+UR+HT4deK1y87xXQ+luH1751Y08jpBTxzd1+SHZiZhThpC++FeC0HtRKh+P58ce9hSv8pPWC f/wqdYhKjNSBIQm3ZcaFyqD3p7wC3vtjzasoUf10spworUOuuU8Xd2Tg1LHIph7LUrE/dTK74J1Q hALALNw3AL6ZanOo9oSf3Rmme+96Ix335zO7XCFxUGgYeZ0jfNmhawqjSaeU2fP7UF+loE2Yn/Wz 0qNzUDh11Hs6alaEi1Ei1CdM5nCZbzIWcUB4s5oOkoxmpls0V4+Ick+4et/thZf2jBJ5MujV07Zo u6wymSb9m073ky51Cix5IiUa2gXb+hMKFAHNXJHpcsQXuaBCE3ebkdliVMw0TK1z/g8/H8svaoVM mTrW6ue69OJW0VTU0ZSuiF4t/Jyfmo5wHsTxZDuYXfAJKEIBYBbuGwDfTLenjZvDn22gq4A/re3O blbuurt97Zwt6W6/P95qh2LkK1zh5Zqyo9NE+u354MRqMuFC3YZKjxgda8NR721Z7VLC/cxSKNM2 M8eFvqVEkZxLH0RzZJ1vXlVuzzzcf+wOnw79Iy0LL/V5uJMeUuc9r560JRrVSZEKd/ETJvfrDuiW pVD0TDyVufQ5cps6ZX70fCJCKH86LovswMi4957YyRYz5zHQRWpRi8SI7P4s1HDrDC74/LlmvwiK QHTj8pvDQKx1CAb/2pVr5E64g9vH/gnAY6kFH4EiFABm4b4B8OXYXa7c+rrjH1e12+bW2+lYdYSR 00LlNj4u/nzXbchf54pg4o5ubdhTw3W5TEPtmSxYmepmynrokT8rYktvp4zUKssWl1T1qTB9XZWN /SL/MuYZnfjghOwI2dTKSuxotXT4CW9Xod91WmJUp2rU2fqkdPtJhM6ZwptOnZ7bmW7do83zwj9l BmaBOK7AnggZQK/vTCC8PnvGCic9x2+ZY+ya8INM492fUm2r0uyCboUkXi43vV8KVUv3pj4Zzq7e xdOL2wHr81fYnFD4KBShADAL9w2ALydu/+Lud9v63kTVoFi115X78+Gttdghx410EyHrgmM7+TGt tD67uq2Pf3ymnVqv2/Nr6ZmSnXfSKafUWMJ7K6tQqU6q+tTyyM/OxHZkb/1/k5M0SzzpfFkpqRwu QnEm7jLxsgHFyGheZsvic2a5Lp8369z6sTHi1Oj7Cf26v6B51Y2JeZuIWHdvSocCtJNCeTZ1p57v OiX7OUOBiB9Hfu5OiW+y3rv66UImfCGTp1BVKl+sdizEQSO/4K4CzwHrMiwUbgBFKADMwn0DAHb2 h2ZL/FEth7bKwha5Px/bWutlo9yojBN64aY6lh3qq507uvXBXS/9a3X0w1oUszKOwc+jnnm+qZLh +dN+EiplAZUXiw1BWzw2V9uswurVjyrcIsKdd1rEurkyx+Le6SxtzCwyEdkm9mfTg86WtT92mixG 2hwXIxtTv+6h5tWuRDU+5mHnuTHp63DzygerfE0FQjvEaLW222wbZZ4uXmUX6LlCN1hK769xEYWY pTFFi2Fu8WyM+tkSKsbLR9+pXSg5E8ds2Hh8RXCjT8ZETwmFD0IRCgCzcN8AgLb9s7v3uC1cP/1A frqzzbblsRboZ41I7Hb+QeJDq6iMLQpe4L1NdNy397Zq3dT7K9TqRSs/yEj5Wcd0M7/OduwtMkfl iT8op2ff+pE1b7/+j/JL+NrguvYrKOmrKbcLBwrpTs9glPXnkPvjxeJULdpxLkZWpfjRLSR9fl2/ vXKpzJxenyyh/EvL3hMdDK+1tYnUKVbavtpbTW+as05EtrJ5IkCdGnX+PC+o6MbNfJk2yybFznVm Crt6t4ifMfxymIyp+rm27yDLFaRiMUxOMTW4jmN0S/TVYHx1cK2MOpHMgHGJ8HEoQgFgFu4bAN9O 2/1l+8Pn8cfbD2palA/Fpt1tzgd3uf3OfUdo3F13Lrt6Ux1rsb2NfWrFC9Tb9UMc4IugtUvI0cRb uoZPZe9I8rhZnWb7bQSr/9LqbnvKed40r1ZTPgsRdmLff6gMdxo6A5VRF4S+TsssPdzB58fVZrsz wU23h08zZ5RSbPUBV69E9Lp6G7t8rBeVZ50/y1in8VrDXUW1MoQC6jHRwSj49UOGFE7WivVh8sEq vOHEhIj7n1EzOcytXI95/lwXNbcIQea6f//RvsoWkWv2r8H4Vskml1V9swNC4bNQhALALNw3AOCH JX/y6jHg09vC3X2y2HLL/fx4P6T+tkhRI6iN90Ve8CWF2LfHAsRqsmyhtMG9Rr3naqO1T3F26Zy/ 6Vp4ppe+hjZRc4V3kUyeLJp9TNuYLT4hW9Y1hKC3usXRB9dpbsNn7F2XbWaark56dtYofCrumXtl 9Gtvqwh2x+OAmWt80Kh1qezadA+KbWFauy+3Tvgzc2nt52yKOb6WgXYGCtP6O08hSAR6srPh188y xI16elso5vInb4DsODa4RSRwnOJOxWFyqfBzS0tvedKPcibYN8kK8XhzbOWWwfiGX9dpmNRrXTbR mxbwS6AIBYBZuG8AwA9L/60luyO9yZ6w3ifr/Xk/bO1bPevuDXDpJqab51gjhNLgWj+srmWRNAA6 HYJK21yz7DnNgvSu2gnlT2wuBbV3dNsLu1/c1npFCea02iL9LBhtTyM+VRX8bMd4FfcSzK9mlV/6 rw1GtbMVotujPgfyYelW83lYhKr0tjDKmdAP8OfP0fwgveSTx+df15B8ZOzTVyOiR9OjzpmgXuei MR2iad4V8bYjA7eOiq40ickQlIm6bJ50yjw/CreI/DrdvFr6u7dzn/TY+M8iBHludG7JHOfeyvRw pgxHVmdaYpezoMVuOw6/BIpQAJiF+wYA/LCoJ6/Wvmj6sIZmM9u0svvc3a27nbsd7mS0f08krNTP mq0RvKDTfijKEK1e2PT/BLc7f5F625pJ9ZG5rrNu2Yqa1fQQcsHJk1e9OHFQqqQ85syx6i+to9Vc avVXNa/zfOeHELdu7tIn8GJWCMOEq5cwMup2tJkZtRUJ2Q5alaSeIUMqE2yIjSFnaK5wbo/6Cv1X kxVNmWeWbm9K6TYBMk8KJyhNtD/3XOQU6Bas1YiBC1EbDkNiZrtbO58E93aecAlmk0q5pb23rqj8 HH9GV2Tv4ykZweKnU0weX/1lIqQ7p4voiSE6FnsJ5rJ9366Yb65L3M7AvaEIBYBZuG8AfDtt9+f+ dtm2gs8PH1bT7leXrooUW9liN95vhoOYpXtvV1rCkZGXUfVCV0hbNouW0AXKao+lK89fpZ6MgopR F1Bzal0G1FvyIqivcdzBVOeovDJnjU9V2WI/S4YlkZspFtWIw1x8EwV0UJT049Fvlq7+2RUdfWed 0zMLgfxK1EWGyFyy4lrKCQVcAzPpduzqVttVvB4zug/Gq2apZkWuhPJ8TMIsEFKBQ6FJFw+aRKOE 96Mtbh0z1+dwjIVcyvlFhtK9j6daWyaLZuENZZcMn5CeH5RDsmVHwrqTPGbN6NQ2vlMWfgkUoQAw C/cNAFjt956S70MNbkRfq6Haqdo97dAW3dz2hEXLEiWufR1alBq1Apd7Y1Udkh8rtKK9xs3cCzWs ahAZr+fn9dmeipEaVe8ZuyoB+uaVjp3zlRsX1lzL5lW3eC83SxWngjDEeEwHWtqeh0PMnU2GYOmu C1OVpBfk+MyQPsemk9ia1YSHJ3y0OU5hM6Vb8JmutYZpAqxKbh3T6FVryIgfzMS1pffzbKpMpsB8 mtkpRRo8tOqNSlXKknDtfhHsxkIv5fwip8el3KnowCyaVlxuV2VCfrA7v+pflG2QX28srKk/lf72 pDNnPKPg41CEAsAs3DcAvpy231tCvdm2hdvxj+u5+J2qqwPiHtgdX01XYV2CUUmV4P2wqCcu8k34 evRLWLU3ZA3yY4WuSmIhcOF3rGQIVN3hYtHGtOHNY+0X1JBuwWKhwFOAO6MDJzOsxTQ42SZnTLPo 7c1MY2+TFh1l19l1poh1r39q74lk6ALnVm0Bcm1hp5LPg+nmlffVuazehMfmlYud86TRNrro4Q13 pBvnQ+2lJ6mqI261Cq5rmuReUMkT0tslURXQ3o1TsWhLx+RZ7f188W63weos2lPM+TxKFA6357Ic ju+LpWJeZY51wzIR8WDzan/c5djDsda9S7XIYGTXeBFFq5U+0ZzxjIKPsyzECwDm4L4B8OW0zd7y /Et620n+HG03iU9uC11ZJL+/UxdxYXpROtgiYHu/bFVPc1QhpZt1qQPrGsS5K5YncfpV6klXC+eE OjT1ZH9qQIO9ZyRMzRsdkx6KB4NWS3tIzIbflbC7clXxKAzJPGZ166V3E+X0YNqB6LcoeBflrvUq 2Y/OfTajEkMea1grfv57FLtOjI5dudPQmLOderZNnrnin+2Zlr6G7miRNttCwnWlC4JX+xW2teUt UQZ0UHTijSyxRjyZOidXLOaYyOnM3l7E2ve+dl79Y6J+NSnCeUbZ5W13XlVrxINyqtB5IMSVA3Ot fjJzG2W65Y+z8BugCAWAWbhvAHwz3RY9+xrIso3c3Yi+Drt3XbK/7e71r2zt0JbtxSz2lJglq4RE dNvGb/vqCxzRVxahnPgZs2aFpBt/4ZNXWRkiQxB01iGTZUvxa+tp+GZusNeFMgZUHC0c2LKlb16J LDXBElnk5qpE2o7HZ7qiesr51vx9YyfzIbo9U6RSyX60vhgxIUubPj2G7fF6FUal0k1ArYuEvsMu 7UwLoXNn/aDgQOHLwh8m/ey0zoQivkHeRDgGmldFrLWLnD4qbexHHeIYy+hzlRX7r9nmVSY0DpA6 LOIXnHa5ukyEiLEoa+Wl1b30xf6ya7uXq37PwlugCAX4HpaeeFCOlOu8SWMAuB/d7lR9DcRunj+7 LWyiu2120n2ye123r26Win112KWLUiKUGG2i3vO7luB1rrC2+PVlQZFVOsNVxohixeKuLoknm13N q826UfWCWB81I3sTva72TOWx6MCYVG3AYiJlzJH5ua6JU8z60rHeul76fgIUuXu0t7A+txvdks/o +Dxx2WA/dg7S453u0vYuPebZpCz9kbW79DZljW5bpq1BJaOMdrW7F8VeaEgk71vn2Ojb4UD/TOkM LFdI4+uydxIfb5XJzXtuYponLvf6dWKatbDql5ygsmL/9ZzQ/F+vLHRQkdLhMxuA7mB47xy7mt9H VoQ9MhRTqXmZZvZMU3796C4FZqEIBfge4vXujvx8lAfrIwDwPdhtnr0ZdNvR3/LkVdibu02vnN7L EBP9nl+93Na72+3bgvdqVzzWd9XMah5AykqDxKgrFcsXF64Lc21JMqJejPVjWVNGrc8/0DcBMnCV FcsqVeqGLaZSNnObMtvaa/KYyogacvDTKmvjTgLUIbOqjiXAw6inpe1IM1xL3FwWim4TLHuwil2w 8anfweZVXHazKKSfTYQuGUxmWq029TqpXubirnQ7zCa89dXTUalvnX9qJ3SGKZMTtb24FtAzgQg6 eGf2sXaqdppYu/ox67q6xbORXjfpqCAoZm93xEx/eFKuHGLhTXMD5MFkHe3yPlGt2l3Qx1MrmpxY 5ya2QC/LdpMZEQo3gSIU4HugeQUAl7DtzPs2S9sZuuOfod88L+EhhLZxzbbh3a5/WRe3NX5KidXE zt7+Z54sPYKqlzmjX1/s7ZdNMW+RLGSGC40RrdLFs3CU3hM+X3wJY9cvVtjCsXiFMyuE94JK1uXe aht909LZMtZegCYzo+vcsloZ54ixHM4G2ESaSoDo4ad3gj+tLS4tahP6sIowhRjFWM/aFYVK33cq mSaeC1r3cVe0NCrJShu+LQOj4N4/+05wvg4etoO3cD/FbTFaDv4q8Ra6cETp3WQfAmHLzzJWTdla keHPF7SnWlDc4iKHEz/vn7LZ0uKgTlXTg6+aQ2RchKMGs0uGwzklv1K2I+aeM5RMcA8oQgG+BHmx 07wCgAO0PWHb+3V7xde0Xw7rObKhXY0VuoYIFcpzmqog8g35Jv3nWDiyqfoCV6yhVZKVOF1MZSFj VzinVer0UN66AkVWLdLnmTdcFFyqtND/HOzWLqwojeo0t3rb1sFz2bU9HlCESXbAYqSsbKuMc99e DtcDHi6dSQAXuG3JbVBISOeC3sCYG/aU9uGImYOp7pz9NEosn3Wwl+S4dXLp0syozmc2Us7DXVSM 9m61ET/0SzlzZCZss56HunVmbozCqOCQOvjVUfMxJJpaIvhSL6g0cx5oflieOZnqVqgtB8hYS5fZ +6cw1AgcSdTJ7NJqJ9bJuV2mualwbyhCAb6EpacddGOyg/URAPhCtq113x/Ijr+fub2x24HXlbXa 1+vT/cbfbZVjIWC9d6Ef7O5+6Z/t2cwPTpBWLEs37KRiXlDw2FZQqCoqetLVIzHi3cdgb6totuPP J686lRL37r60qvahI/MwQJcMvVy/yPNn5opOdubzJURk5KVmjSfAFoXQBND2Os2d8kGZLXbPsP4s K62QOdY5aSar16WPbDM2zxybadsRmUh7osVS27jQZkzS0mXXXJQXtVScHlO1v+J+Tq/uyt0T7f32 NKFLHBsI5xDp1dXEo9dtW8S875ToF+m828UsLG5+KeiEcWYGP4++movck1eLsDpdwGV7kRsqVzc5 xdReisiW3jNVTOMsuD0UoQBfwnifaqR5NcJLzACAO2Ev9G3jZ0q2D+jUcNVBv6eV4x+vdTNsKzds w6dfXJQPqmaxQouDTfiFe+lOz+cH74dFqydLlM6+c4rVNYjUqoUp1ilCvVDCyMC5Fax1TrEtSZQh PhmSV+dyV7gtwS1W5+i6LZZirhgWxxh3OMem+tsFlnR8dFTvtU7HxTRF40ixvtNGeaBz6dPJcrWm gItRM6E7WBrVKRU7vctiR4r4JP50cdHCo4tkFb/4x2Y6nzg31b4toyyWyk2o4vUMzTr8a0W6QioQ Yx3NcHkiItdbJNwa/ObHSEe1CC5hZbma8nPxEnGPsfbBTiWkkkdi1BtYRzZVW9pYSG8N80t/4cIx dDGp+LSmAPABfq59dwcoDtZHAOA7sTeDbe9nCpBPKbaGjfGy7m1Qk9143Jf/DG5vRPmgahYvN+zq l2cZuLSexkUOtAosWetp6epZp3v0i17kqGLbms5jpvxpH93ZzroW66CzFNqcLAO9iXi+285bv+Uq 2VlOk+X5u9QLXVanTxtv5Tp77c9N3KKG9QY+vBs8X1u0hCu9t8DMHcuBdekM388WFawm1SscHybJ egjKA9YJ+zndmiHhNtiOx8ExaoWq2kt1SySEXfpyc9fSr2B/9pEtfOJywytTxDe0i5tKU1HYDa73 ZJ6ulWOtW0JY2zStVVxELd68YWMdV1vb/buOtEoqH+VoYFh5bfJ6q2tPSq/aEGfpIXwb1VYGemVs ti+rGA/3hiIU4DuheQUA59luBv2+flm7vehndFu1MmI3203big1dXLhFnNWxJHC7/SgoLL/0fw6+ yhtNrF7Z+kQ1KwpvnNGq8LBbWZ3vK5RF6aaScDvi2gKLLme2iEg1dx+HiP0H29lwdf3SNzSU6C2a 7aj92dvSucU6y7lvUd4IiawDEKJm349mwlPb0YRJUsEq2WxvnmxxH7Qlmjae1VZoNl14e1eHPgfk Uj6pnPTgZOnJLm1Cdtm5qR+sDsOucOJsJkvD6yjUXn38N3GLXq2b2V+w/ZSH5k8JbVj1Cou3HN7W jze9bPrUK4n10nqJ/coPjy3bvcgYf0Wbdy+4baJzgv9YRDPMHcwu+CAUoQBfwnifiuYVAAwSbwbL s67ZCoKP7Ab78kvsuvOJbUPuNvauUogVg/qQ7PaTuuHx3vUrzjvD7urH+ni7Zc7IIuOKxRjJSG1H +oqpTc3WcUvNmbZ0v/Skvd3g2nVPZZb2u1Q1r2Li2WRw2bLNCnP9e6uoVbfwvxrbmZk4XEYwT4XN GzvDythZZbZAP+3YfGjyJ/XYUXN8+AZaeTHiNlxSh7hgN6bdRtTI6ORuYswKlSExLcWa4bbppyce 8OIW3SAajUKR3gdWC/ZbA/2U6K/dG0VYfF02D/xbOsneqNveq1Pj+flHgghHu19lq23GD/h2UdLH 4lKHtS2SLXVVVsBHoAgF+B4Ww4GD9uw71AWA2+NuBospDO2pj2wIu/15/Uf/ooawNUhfdMSKwX9Q lcK61QCdj7paQT1sc9IVm2q9IbX3rHOCa4xR53RrazopO1qZj1ugrW59CLRQHfUuZNZpaTiyxk6S J23ZuH73fg3J8NTfSN66BC4uj6XsMzBRLatQ765uYPD2Zuyy2jXcayINnoYnI4RvRexC+NbnRsZm frqUGxGM2jNDL7ippiwSygQ1MsW8D2tXWNHR/3J6/9N745kYuT96Y223uVDACg3m74SgsOhocgr1 et26w097l3YNmvFb1IpMlos/E6l5svlX6iY8sPuydkXnh4yq/BkSrHbs2i7SsbjUYfX61qE0aTyb FfARKEIBYBbuGwDwg7sZdBveqx8fmtbN7mPr5tWq+1duBblXT0uPpVdAyu3d1wYs5g/cV7liU3XZ 5BbrW+VlibTjzxndsjIkDBVxEeotq1wwCvUKZGrEwmrp2noiW/rpboBUdRvgHrwxpbGf2rxiJnSC luCWNsw9GaLcJRTujz8WUIEbT4xtylj1Gj1sfaWVcc2r5yGxVJgeV/sfe9ei5DgKxPj/n+bqdmLo hxqDDcRJpJqaSxybVj/AqOPZ63FHVk7X5ReaV27+np4vzbWZ26pAFdLlVIm5GBVeAsibK3Vg21mw AwbkTwfBAx5OlbeREeNLlik7prClFFVCUtfaOPvEBWP6s8y1irb2FyfxIDMaz+K7tJj7lo56pslF R3JdhmzERr0gNoMilCCIUXDdIAjiD3YTLaS9/OgtG8KGcmleluRuXI4Ad8gtuQG30/gTIShKO2Le RlpJFTm4cLYVPcg1K8736XmvWyP3yLc46caKT7Q8p/qrKxzyOYmbsZuU79nLRl14IGjlBOSyeitP MMfFQW9L0Q6mRtvTNpQjRyqDU7FbnokcRHpdXThSHI1gjsjT2r7I34rSWT23aBSvzsIb0QaRbFzr qgJX12lAfO8uXjGMdXutm5WnAAMKGq0ya4728qs9eHFf154ir2e/iQ+oBBENn4TTUlHc5L1GmrbR CarRpEDUkvTuLKDOiOkB9uQigeCrFDQvt6E/rWfiGaAIJQhiFFw3CILIWtSDvbZ8YuRd9ILtd/Oy uvX1IwBxAYVEpB28LUj7sCVVxpRQmN1++5I/eoa/HKSeeZueES/nlROFrk+SGLETpa8OpjPS4oMo QBp6tlidbguv4XJCv1P2w9rf5ngULjEj5Atc8Hqc09zV00SzIsOiStiIyZ1PaDFYkygO2VzrIJQx 1Zkx7LWmnFpXhleZhLaZNEIRpQCTl/GNClUOLotEOpXs4NC0sZ6TK8hkZ1YrmLrXFNG2B/oGbKdY uQADmNUMwr43EgFj2NG8+jvt70J5irUFE53s/SioAuVdO57F8XrtePNKcuvPLHBZX9PDnHgjKEIJ ghgF1w2C+HHUbbb7Qrm89h9t5Ge3pelM9JlrXy/1COGWvUPLYKNoLYUjwE14bzCMREqvIyGlwA+l bLSibyiFXoa3m1cgWbEkSSIYwE8Y/Hb9JKHakDaSSQS2Ejqo82VcLkwOn/Vv+VZQyb7AylMuJlyN GtcBBzFqBEo7oi49Jqka0lwYxLaEwkRY+ZsOc4JD5XlwMEEA9RDDJ+48GodrwDf/1tBDBLKr6voO pcCQB0yCQlXUIqdSfQ0S2o5eAu6cWDwMARfcT5tMi5svRL2igvop/PXCW2qvPfhJ6l3zKqNsmsj4 QrMfNAOoAm7cybjAoqj+nVyuOMmviTMMy2iZNWJLPA8UoQRBjILrBkH8OOqWO+kjrzdqS/8uAH0h t+etK8EX4n6LG+7to9N8NBwNw1Ztrm/HoSqUvjHrOck1BGbv9lO5sYjgNy+4+316VUDN9B1nuF5H xKdcKl/7ejHKSxqNXmu79hzzO2UwVMOcDpd1LYEjIeFUo9SOlbKVagGcF1WQ6uQeNyrlKitffe4q x45gUqCvBdRGihBf6NKRAgZwhBpj7SBMAbjchVQFQRaJrmeYpkoD/oxEwCSrEUkwlLPdyGB7QF9g UUxURcHEpXhMPXg4wsGtkjxGzKUz7AKi4u8aXyBoMonuhmLDcLg2FNhyxVByS4H5wPZcjittxu2M WAqKUIIgRsF1gyB+GWrvnfDxPLB7XYD2Ywwju9O2CMruIQd4WjnT88S2UrYmpC4YDYZRVSn3jmmk imOY+7RGL0nRvLowLMg41DX+fBNtXypF6PUTUxMjmRGMy7ZmUm6Rgc7639Il76k3p09WtP1Po88g XuOaF8GxZA+NfBLhBIwDvyQp07wKKsEH3MfwJO362kYGT66FUT0jo0pANBx6EgoI+OrSLyxNmB3f vGpmFnKQ4/Rkwbrjq6JQ7QYoqnh8GEB5SWNwfLmzAi9/1VtSR2R46wtXaDqXYInwlZhKXbm7TG/S gzAqqs1c2LB0GIXVFcWWeCAoQgmCGAXXDYL4XZhdrZdIxzmvHe+7aAZb03z6SE8wjt8nh8fdTrjT rhwhVApXQ1HH7/yCO3C0hFTSu0bM2LLipa164AiAqHK/nh7l688mCv55IlpXAGt1jiTHQXRdoGnp n/K0Hs3+2pp6SUJHTMVD+mV8hWUhxzlOawRH+eXm6Wm6fapBiMrpuhi8OzYj3jXTCoC8XKatm02n bDRMVF1OQy8yai5J8oEjJkM1KbpycucKAJtXqJwiAj6evRXillPrWhyExoCYoW66tmmH5OOp4fNu RgDVIbtJ0oS0dbyutI0hkWtjV77AHo3H9mWuY5zzqmhaP62uIebEflCEEgQxCq4bBPHLkFtEtTUW W/d87B/fshs0m3kpLobIgP0tUiJwz1+tl99ntqpF3RK8uan2oegdMFktoGSO0IATUlxq6cb9BWSk 8NQkZcZg7qx+jJWjd8R6Ua47TGed6CrcdOcBHM94EPXbVD8UaPBFClIpyJe3rZFl/Uch0tHIvqhO UeKM5qWq+RLPiJisF3lO0rE1rQBICsWkd8adRtWlFRIo4WkZhY7AmtcRAC8aTskbhJ4F0fmYg7PY Nmpng7nw6npV7frmUsQ5+BTTFq9BNccjqINHkEHFltciESosxhBahZRDnjl0pzO2aV7zqsecKYme eiaeAYpQgiBGwXWDIH4cdQ+f9BGtnsyRXeSUSDF7b7ufb4/UUCJ6k4+Pux1y25ZXW0bFXIyHHOpa KAKlI+ld46ZIHtyuj1BaOtJncRyc6VMJlaaRhC0e6KGOpPyy5rzRuJzsCGYQUHPNYeWLFHvnktIa WdgNQySCWSJ8fmEwlHHXZ9DHGQ6lCiZ1X+gHOYx6PidXt6OKqsWkplhJ7e8OXEJDGsaof9GYs6kG Afx0h6IOpX3sd0GF8NotScQjTBP8QZ/i8fXrZEzGl5vqCG2hmFuqSdvVL9QpzWFP82sI5Khiezib 6TBYXdDHTvLEW0ARShDEKLhuEMSPo27z9IZT7vrU9nbvbrC1IR9hYnbFdj9fd7qtbkOnRSU9rg7S 8OL1Oill1D2EbfvkQS15Ts/V0uVxcnLZ0WN26TUTeXHuCcM0rXmV4w4hkF2qgLyWe50pyzgnVM97 m1cqsKLbE4YXDuWzY46gOMvLVRG6BtS5RzAyLv5dDsHMSsdKmspLOMiR4jBuQ17ImEbeJRXS11mm edUPmZc8tuCYaF1LRJsbLn7402kdXWerMxjBG5WXKxONWOVsDR0l1LYeutOHMqDMbxhOwVkmV5VK Dzff5bvgI/EmUIQSBDEKrhsEQWQpkcQRKFv27wbr/vZvzws3893jgC2u3ECb417ejdpC2/fxGCAX rm3RjWrIk5pXJqIXehdyMCf8jOwyZ1btIyWbizw8xTKMpFaNkS6DJKzDdAd8sL+oAsG1sjMDTz4+ HY62oZFqSajRgitekdEV1Zn017DGBApRKQaYQViE0qkw9Y3g+Frq8AWHFEWtvoyiksJP2xwUDTOP XJZb3omcdpFBFQKqV5rzY571JRpB68W95lUUq9b4epCIj4yhcrb8eLPiHHuBWC6y+HqlxXw0kHJZ ht92xZzT0XAzR/pNW9+PJWtoHGI/KEIJghgF1w2CIMq23Bysr5/z5NWpcOgcKmsRV3fzti2AJUu/ rU69c8GFtgg6GailJa8xVFLpXsEYRSOzc36mTKtpWB2+lwyeOBslOtmZUsvGp1vzgRG2J6OaUdf6 FoSr5zLyUMAtjbMaU/EXgjEVjXwZbqIZbvK4fZ2qFq4FUC6UBxrWpd2UG0GIRsAhdQcrE1dv8pxe u24EH4F2lu1k0Tn18WlEIJoHci4bW9b9qOyHctEkaVmiaEDrIQdVnSfjw0DJU7AtFH8cbpT6sPiv llnu+bYr5qyqorux7McxhTqtSIhloAglCGIUXDcI4pdRdndJtC/kp68X156jmMcQb8hvdEWcmlLN qxITqVyGNvZ2L+0eIRhlLkd+vUhVWt4ax4ka5fXQgG3xMkgPZydq+5Q4y7RmdXWSUrFH2kTuJ8RB k8Rl5gW7dxYO0vjx/qajNrqDbwOlQoaLVsXTPC+RcLLGoGccDBFeskQRRuVxHhxZIbq7278UgDQ5 SjLy5pMUr8wDUZSZhRMkaLrKy008+yNwkEglnuVAGV+d1gigi9it6hJGceh9SoKJif2Nxk8qoWAE f6doMpK5iD/G5XfCfDSQchrC3jIafEJyddKWFAmxDBShBEGMgusGQfwylJrQ+iKb1tabvseUW9BI YfUNFG9xpUjIVtwdzl/sXL1EX6A9RsXC3C06HKqUwQX5UMcrzatrvbWk3dR5MS5UR1D6cMxlTtp+ aR+hKCxZzv7JEHG8YdQmImCuhoVlLDjJ+JzHO/QqqLG4S2fI9Fg/D74OEYizOK3QMzGXHuXTCjcR HWwGWs4BbUnGuIxNl0vHOVTrpmCCklPxzEcND03nYLIYc+rkOIAlp+bgUDQwSR8lNTqm3SKQ7Eyx IUChlucb98tbbMKFC9v10QuicRmVal9zMrs5ckIvNNxK01VviB2gCCUIYhRcNwjiZyH3dSnVvaXZ 75Xd4FZy0roWgNnt6i+MpoSkVEdO3L3CckkwStp+R32H/5QtumKItNLosDVyg82TFjfkrzcK0ydF jR+2g0Rwjjh+kmXRMVBkkptishQTcj/60eVaBskjnRYwpgmmpq1GPqakum5qu1ulzxGDJ3vyPhHK aTtKnaTlKluGHbS9dX9QDav9zWVlLkHuDZktKFCiCcdTRru6eWdSC/4uiCelHZK/U1pnhjAzdLAx ZmO8cJDsvkJKKBfiuLq0ScJEr4f5cFyPkZOb/lHKZHDkVReSC8cZHYTYDIpQgiBGwXWDIH4WUsT8 bfuUsBCnvT59E0koee7sb+1odddrux9eRAxb8cNmbWGc/x+flNzBS0PJ7HsB0zEQEmWyRXAJip5O B6hPH2dfKulKKkOXD9N/b6vLukklj5vUe/45mzMU+eICqC5ft6kGsNeneEyfSmMKUDhaLpcLwHCr tlCcsSPJOaUPOjM4BjJ9Qx7ZKPnkBi1NeVaJpKyBodBhl5rzxcRPsr2Y06N0xbssj5hJgcm303cN fk6ZKATldDom9kJUUaMIfaJs6lEZwPEbTp0yv4YSK8mqDC5NSybyqgv5Vb7fa4IRO0ERShDEKLhu EMTPQm0d48dUMvoidTPJrB+luEwGixG545eK8oavXrAo2dUQLx3D5ttb/exal4rmhZ2/jmLN1KUg GqH3Uj1izKqGdMfM/oZK7f5dL9UJImPo7eYys1KYJiO77AiyQg+xb+vKmL4UdVyusmgh5yMalvC9 zqrnVhlpYrUYvCPJBap5oRjCXl3WhCz7LZ3Ms8qLrY2s5o68qnCpU+D+ipdcfIK6zS7LUTH08dDD pizfvvx0VQvII5634KoXGhoznYKCdDNaJh0M07CFrjKG7E+PCxcWjoj5keJqyJW3CUuZZReSqwKb 1NspHhGLQBFKEMQouG4QxC+jbiOT/XLcfqqP7KQnt99Sa1wb0Go3uas3Oq7sgW8aMuZcR6JjOCB5 7mz189luf2xM658S+xcQii+dKBMTnEQfn/t3PanCZPnI7EJWKKqKZALMpdd1SjZMXKrZc9p63CR7 DvoKecEs/QiJKSbRmbFHDWI2oqLLdIF2zjJ/KlC2hkunyKzMM2aTXTR82bjIqHpLWX40SMIWuTli fzRzE72oJm8SU4Zg8XRUzt+Y6p2bwl2DoKHOT49teafum4sIlJGi/NZJ4QrMHO+3Wwd338UQjwVF KEEQo+C6QRA/C7mJtWrCf/svrtrPsHfvPTqgGVn+PlbHK7a0BoLy59rISpjc2OrLq6A0Gx1TMjHc Roll7aaUJOq4ODPJto+/cmXFyqoEmhfxiQbBKWg+CWLfuJlywZF20f6tBQ3Cf1eZcWbF2XjnB1eF 4UPWXRgqFP/+oyxPYm4C5WOb9co8HDVB4N8r1/aVAXGRsXUoTrhFQ38bYov8OMNWo87CrLqyBd+Y b67OG2NCx1UwO/kPFZv3xfuFnLtoDlLQKQa2SjizOCG/ijPrOhmyG1YX8WBQhBIEMQquGwTxs5Cq 5W+LKTeWSuW86atMufW12srsugfHVJt5+UKruXLJHf4N+TM6sgmIOniH3k1uzU7dBWIwJ1B5AaMm iZ7D1LueJeDs/s2ddkCMXzYL5sBxST2zfJLq29xft8hocv2K+rKjeSXprYizCpo+TYUFlUd07ek4 +dJS0CiPOjLqKmX9OMplQIsyIFGuVRByvQtc4yMDnvTahWsPNa/saTPQqGHj+2Xrhrt6e3Ll7e9o AqcuDNtjt74WS1A62lPld62EIMLdJkFU5VDTfCPWgCKUIIhRcN0giJ+F32rK4+1P98DqHblHvTem l29WNWnZeEevYTV0SUQ0BrxFT4qaQ1xcUGc1crdV0onySiIvpslgkug5TL3rGQJWSWVXVM3mlaxB GU8YDPBGvK30uh0JLWVREqY8Ij43ijziVl/HyZVULQ1UGKcZuVnM8sKSF1sbLvuS5v1qbWf2lV/f vArCnscXBxsK3V6QXqvgQLZT66oVIlg816yjznASi1j72qsuncfw4sgNm/KW4u/X6XjCypmW3O5Y 925ed4bYAopQgiBGwXWDIH4ZVZsgtdv+dAMaeqdKwUsDevkmLGHxe4f/32hmMz+qgKwImqREylBy 4MKwdwTvacfzLaPDVlaaKshaIzhT73pyfO94iUZDT8l6VgWftROnwTGjlDB0O/Lng4obfPiq2W3z wb9TnKGz8eDwzKy7iMXTbIrcz7Lcyt0Yc5EUMLIzXRjdhHXHWBe2VQWaa1OGJwzRqGPqUES1rH67 pN+vKxiiF4Fkc+dn6GUrI9dcb15Zj3yK79eWsSk3D2LPkGwdoYwfJVF/xmzHQxEPBkUoQRCj4LpB EL+MKgT0IwE9n+6hB3eklzfeWCY5EWdfXHNcqzCwZb8wLHok43JSVH7R0z6dI4OQ3vHR0IsLwNqN Oehx50s2ycGW1XGo8gouh7X5Iuw5ux6LzeClx+f8sFHdtk7wcbgH62ZSB1thsdWsZ83xpgzS4+A1 5rUS0MjZrHWy8mdUqxrQBcRkrR6Ll4hrOYUh9S53FuGEuEBu0KIjcNVMrbre868a8uk1Mb84ctts mUp6ovkUS1avOg9WyH7Tdah3bFeIC6AIJQhiFFw3CIKoymX809VQm+F0d9ftFZDezQey7r5YQ4Yu +GIY5kjCd49WBbJ+UaTrdTdnyEwzshJBjc6A4+DTLt28A+u7czwdT17lQE9Bnip0kKf2suHhRV8C p4AtSH1G9j23l+ON5hWsxsJbu6NcPK4Fcbjhjq9VOLJnWjO798krGY2MFpwclPFYNEwGXe20U1Cv mgdDxlqcVdJwLrfPv2wKdY3mzkpo1Ecsm/AakvmY1OnqA3XaIKxk4pmgCCUIYhRcNwjidyH35km9 9Se+C1XOyG9mA56doymJZEdEsu6eWJPDelnUN5BVbUoaXNqly0uUttFCvnMc4+MslST1TuEGkmiS 9XdF9D3+Gs3rC8bJxTAgXuLBqlRl32xY2XGuueO7gr6x4Lk63jOijKbnaTxTR/PqOD+LggcZhEkZ ieefF2ZeNHN8GL8Zv+DZm7/3Kr9JszVhv53W6vUxWhkfFhSgKkM3uy9hazsB9yHhQTMd54cVMWzL OjV3VkKbjUnqbgqq0lINzrXqUkP548QjQRFKEMQouG4QBFE35+Of7oGUD3fH8crUS8hULV7f7fun KdywQ8wjMZUv7/bLYOXNuMttmXlTKNXknCl99alvoEnpN++uBzmA4+1o9DwdYTjr07AVWd3d7mQR c1gSwGUV4jXNq2ZIWydLesdvQxO+UNdpj4bqp027HdsXmRlPXh2vrPUczH1QYLfTqmrkWCWiMs6m DtcUFWYobjfQ/aECuM3p1lNeNVaNxtFEiNtpSvptUFemJGqwRy3PG4rYCYpQgiBGwXWDIH4ZSsi4 vwdpf7oZdUd6bxSrmMwe+jgIROsFa25Yq4O6OUsVILnlqzJEJbrkd5Tb2WMqN2vmdGSplRpnqrKZ d9drcUAE2tFoRSzgLIu3FIPxdyiVXl02nIIlfX/WtDzNahGAJiw9O3OAmzKA+Syto7QBq87YHudI ly9H7y90fmTtvw6Lf6Lyxl1A1QhsXokzTotw4iw++GnTyRWSrpbLVtaeb64NOkWy2idCTtKS4jCn spB0k/YCt4lDETtBEUoQxCi4bhDEL6Nqq2SPnH66GS8Ot5csu5H223qtc+02+4KtogG1ihgdx9K+ xy3LJ22EgDXqdYxeVt7dopcMr74uSvBjR54EqAqtZMtKReb2JIp0sT/YIwwTcr/pjuffFXZ5zozK hNxUqOPqwpkQVEGC4LXanSym8yjtsDzaRXuUfT12MXZBkRhyKSiALGjcmNTSGnb8INDIwtyiKvEB 2WmU9OVE5O3NK9G3NCU0P4wd/UkwBWSz6x6xiUMR20ARShDEKLhuEMTPQm7t5EpQlFrj0/1Ik5pX r9Ha+rHsuUv77saOGmzZ+1WYpoNV531uRrUODtuQmferpfouSAIZboxKb1ZC6i+j7iGl3H7mQQtM dRyZ9kqw2LqWgioA2xMEzZRFBVCIhYFtnGki4uiZIokcVCNdov3vjW7++B6O45b1YyQ3AVzTiTOH DQ0YsYsEYFE5E976rHJqM1QWTZRuchhN54Xzw7imMtqiMKpqgg/XBUtWqfM74S3X3h+K2AaKUIIg RsF1gyB+FmonmdTbjDai8tM3sJ1qtm6qk3httvsJ9PFGSQO1KIVYn1cng1wFkDcHo7HBda/DqpV7 gCRxvowamsehhx4WZVm1LMolbpQU/jRNy2urdvMcBt05DS+cKb4yJwZfRu8kmKYFIV1yvvjyz366 3XEHxUbRkwcTXotmwvXA65GO5pUK7wXj7Yo6LTNTXwtQC0DWxMSSXkO7batydmvRZINyYh5fNvkq MtMti4DP4TBpKGIDKEIJghgF1w2C+FnIrXhyLQu5/ZPrxLu2hRPXqrKTP5FRSQXkjjmlg4wQO7kY iNnhQWJiWe72E1Bq3WM50Teva2EFrE9ZIHurdFoGaFdNolSLLfdMH1joQfWrSnbSfiwRqMTUe+im nCnxaV0ETgmWcYQqj84EkyXZ+rSZgg+z3Zxo4PmmoHTlebKPlGaufa2JI4yak3N+cSsH71r3WWjU 2P0sdNOrEwfm5RqBwKeJaQ3tCutyKqyyrhuz2a1L5VU9U5OdxGLaUMRqUIQSBDEKrhsE8cuoOiXZ I6efbsbMza2WRV7jep07y5aXQsPj3BjEDFhHLsr08sjpaIHOlkU2KVBOenWZhHeLizYJUV9eW+sp 5U4yMHrBQVW07scrxG6X9Jg+4CbyytgMAk1nLak2c/jbsZaJMw6acy7S11ZA6Ur3tJ8TgdMXvM16 2bFrz+UIJDBhwxpTJueVU8CwGoS5uG99bjpHba23HpZWkOV6SZq2u5g7GrEUFKEEQYyC6wZB/CzU BtI9eZWF1pafvo3tLMuBTFR76dpvuOf1pIemVqg5oCWP38pIn5svailn7fEFYoZkddqmKtbgh7je U7HVSsxuIJ4waM1I2sHFyRcjIKIXlZyKfPkNz5magp4xa2FDksYbudDpj+T5E0o6qXXVcjOkxQkT IaMXZhPOo3S1lpzpBPtXf6aip/6S6ixNC4djWHkm90LH5KoNNq/AcVMPl3nW2n7AjoXoAUUoQRCj 4LpBED8Lr9HqrlOf9vr0rZi4VtU9bfTsSqpeF0Vzx5YXYlJFThhkPDpAOGivx3b+ST95NSlbICle ASFBpOK0BdKcNGqJnQ800rxq6MI72i1quro428pJuq4Wxf+swE5IioMqdHE/ZxptT88WK2peTZxT bv3AU8y08nK+HweclOYstpFZP6NxzYxO4ZaBt95G11uvddXIpo9nOr4wuhfhcm1xdGm1EPdBEUoQ xCi4bhDEz0IJpt958gpKVLfHzsdzRPc1y00hhkXfbTUXjplsGcRDOGrLmldKDZkYQpW0rVbDCrLZ Hohqc2QcW1NcfU8oNTiELjWqEZ4wsfPTFw3MPOv6idniay97cVYbigwklqYKcGRK2oIBzGkODRhY nKNm1U2IwynDiA+bV43h5c6h8RydDqasvXxjmyGvko4uLRjiJihCCYIYBdcNgvhlJP29ZzY7wCd9 jzlxrepRrFk8bHBTswDVOqKDTqXc5a0+VmqD9I7h3vrkldPa9mcdwgpSZE6S1SjGckIPDfPHWXfc ilzyMyWFSn9y5E+jJJirmBt68mM03Msj6dqUdS+ppRWT8XX878W0SKaXL9ZfGKgsTk63F//oKS/D 46zqpoThnGfEpxz4RCymrVIapTKYdPezLAdI4k60o2aIq6AIJQhiFFw3COJnYcSaOvK07zHT5LUq HV27okTARvrQa7dEkxHRevfew9MQMyNdJqY0rFRqB70xpeMkg/q5ws+6mZLQlUqoWCU+wfo41Uio mWCepwwSPvViuqcdT02omkGfzuSjuTWcLXZL2E1hK84uc9KCmg5TaB8vcKH4t2IVmoNkx1ZmRdPe B2SCcV85pniiAttQVJWlLhLD7qOxeDGUU68u177U/aRLbhm/YT0/YcdC9IEilCCIUXDdIIgfhVEP SX1tmp/2PebU5pXfPGPFdHs7HdqSmmjo8mDnf5eb9FfrtdcPvt6xe9STV/sh7AYqrSPpkPmpO9Ll Kb4PNa8y0KoTOMTcGj766i2FnbOuc5gh4Wy9dm7zCj6NaVjJar8501EazWTCn7lE3w2AdNS4bLxu zO4V8GEQfGz5fy7Wk68pTTmZ2SZirNKe6/39ZorLtXUtZOfq2aAIJQhiFFw3COJnUfd1ujWUSvOq HHn795if37xSm3cpSIeozqAEBjcy48L46fizwTzzKSDvvpK9kbydR2CQbrXri0oePxmk82B0wjzf TycF6Dbo5Mxiomm1RvYcCnPbl0g5mYkp/dL+zqEtGHpFD+1enI9NDulY4bHXMKdpdvPKJAJWF5zd K1FMJPcQ2nuWlLlY70JrZUAlHZ1/x3ou6VtfMMRNUIQSBDEKrhsE8ctI+nvPekS/hp9uxYLmVRnZ HJSqyp581ZZShEIT5bOQys38XCULdWtV+sVa73DLm1eV2/E+H896WXk7j8Ag3WrXkBnQZdeYy6vm +Q7UZUIHnafLU9AcHOtio50FUXyJvmomd29ImoNsJ8361zw1y5EnYyJ0LFkzHTd5gdWF3J+bC89Q LmUlFDnPnFZbYVdH8bPCWpC4RknDI3c5zChXYgMoQgmCGAXXDYL4ZVSphBo1VS+85XtMs72d9ydp 1ZFAREIlddOcH7++7L/WULoRDTAybF51xlwovonKCLsvnT+qwsZksUaLGYdPXk3RZdbWYlmafGNH l0cQ8bemwHQOs6DrZ3fAv15f/J1Kr9o3Je3nnpnyd21bF4HXMCZpcfPKhF0cAQlZgyRuCulYDEGN fC7Wk/cLBTjiSvqVZf1lzS0an5ylnwJFKEEQo+C6QRBEW5vMUi63sODJK6+ZIlV1SzFFIjHXLkcP Vbztv6GnlHaAav3yk1dT4ZWsct5JpELmjVCBdT9rTEJTE7S2LDYQcC9RS3LeDVU24ikaVecBfzgd 5hOLzTWU/j3bybxVhepXFk3jZl3ZSQFT0HybzxbMO1B+m+bVd2DxrLS1FOXR59Q9QHuTxqtciceD IpQgiFFw3SAIIp/tat+/TsxuXpUXUhNVBWmeQZqhmMxO3jDpuVCKqSmC2owMtWT3WGlujsqwQAFJ fQ3Zvrteg1hO6j9gk0v+bNDGP9CkthUxl8MdJMPMvU02WXI6lEXgZtMG8PJR9SRdDU0xrXmoKVVd lEdkx29KYwE67irK1Nva6XNwq69LFbN51T+8ucclm1b8kV9Vrga8XJve8qw4MQ6KUIIgRsF1gyB+ F1KvyD/K08tCFRRvxOzGSHXnGLctqWYZ9Xv13ksGLxzjE4jlaus0+ilNzxHgqUQskjxTOwz3Cf97 U3/PLSdtcnbzCoUcxBxVS1fB7IFrXmX35JXV0bDS5qasbbFxZHrliM6MSrNeFrJum98y6L1uV5R/ JmdladVo6Kf11lncisWOyBy10uoXDT3LLteYSd+doYg9oAglCGIUXDcI4mehtotIo5Uj6e3fYy5o XqUMugpWsk3VjHD33nsJEnr15RRKQizLY9WQvdiFrbRApwIEQVAF0XjAfQ2K8sp6vr01T14df0sV NhNQCtIz9L5cvhRV+dbp6Gz6XUmkciqx8x9U2bM4HFSOx0qTtmiWAJH3fKchAB/k8/MkeLuhqGTN 5O9rXq1HDaBJZfT66HTZDy+Zrq8TPk48DRShBEGMgusGQfws/GbPbPPK27JOvG0fuOapHiMJG5Jq lrnXi+54Kh05l5WWEUq6IyndNdqyJ6+q7JUkl+r6ezCKW5JcTnVWGtxsaPcW5DyaQ+A27Vrb6j0u oazbOGVSqLOmEETzC/y4+b4osMCijJV+8irf6L7KINdyiiuq5m7vBJflQQzANCdTbrxWJyf1LdJF 49KC6YYRTwXnGEEQo+C6QRC/CbmjK1tHedyegC5cC62o5HZ0spXyMhBNU1yWgX3t3vXx6KrXCf4P MW6zqiMEzSupL4IhtPBNQkHMglHVkuTsHE2Hp7eJ56z4J1UDPuY2BbP7PNeJH7Mmdz95pT5MalLk qYkz9RD+aOtLijypwUEWU66huF3DZklRFs8KbJrLHSQ9t23WPx0gd2aCidtEie2UOMvL5fLD9D0Z FKEEQYyC6wZB/CbUXhI9tN86YSPJIkJn6oimWIQaaoJNKfC7/ybRUOq8qp9SHdDr1qw/OSOZjyev Vsg9IIh0QGqcngPHrb5db3rmYFCQwlbDY5S+Wb5UtegSUsyTczPVaTKXnp9icD0yn07k8I+H9rVY tJO/Nq/ucCgjoCkRHHHL0TTfY5KpdFRSfUt0AqwVLqfmRpbSnCWrZKoMxtw9HBShBEGMgusGQfwm 5KZObh3r9u8B32Omo3MlGyOzbQSPQBhVe9+OGEdurVuDG12p9fUUSpVDwo73RKAq3WWSAQiidwjb K5jab+w3OnMw2NVBpTLR6E3UpeMIRllAjAuqZVIqTc202d45QS/fqlLXzZMVq59d9Exm/ZF7HFSQ XYTtEqQ/muTzCb0a7WNFeVptPxkgjz7Fpar1g46zrOfMxH0MKEIJghgF1w2C+FnIXfpL5emdnjpB H9lJb21jJFVhqPRjUpp9gh0ti/zBxoU52/1/nhSHOlRSjvcrR69K5MizUDVvsr8f2rMqkK2TzUZn DQYFKWxelZcPQKmNkoHIhb+P/fRf3b6woTt7Kmk6AeC1ePLq9ULQmGWu4ePfQbMW5dlPvoUEZV/t iMY2618AkFyf4mQrv+xApnEQdyLiyaAIJQhiFFw3COJnUfRIFQuueVVP2P49pt3wSh0xceE6hoIb 7Ymy0e/VOweXgs6IzcmsjLLoEM5eg6zQ2kD4iN9G+M4yOg1pV/PKNQZmxcT3FlQWFmR8CuzyZQr7 +G1mopxuZjlYRBJGt7z6Yz+TgDMn19jqeOmZH0HI8zrSoJY0p5wcuS2tURiNWYvtLwCXcqPmRMZn ckjTapVYCopQgiBGwXWDIH4cpzu9d20Fi0W5481TBFSg8aUot6p8RgegupPU29ML5YbfD3ifFVAW TnS0uJXnRpIa8D49aUXpWfF7qZi9iKDA9lGdbehyhbwZumaOY13Nq+KjOWEyNx1FvB5NbRxBDrJd I1ebWrbznkHNHc0r+2JXgUlDZb4+t7yfh6iAcX7FkSnrZJ0sTNyHgCKUIIhRcN0gCOJ0GXjDOqGl XNZP9Uw2dLwwWnK6brqwtTbb+xVKVmn2EdluLzzuJ5PThLRs0n/cNMfQIqQP/7NB2FRBynSaxYlI tada67nwz7WEoJquBTa1dVPZuaVGxlXOwUUEgON2puVCox6+adMYSo6GjMX26pKrdCGwzfqnA5dT VF3iK4kpS1bJVBmMuXs4KEIJghgF1w2CINrLQJV422H2t0uEjHDeb7Pnaka8ez+7RG3vTYdtLqt2 a8KZA7Eyl0yC4uCepXm6PEkf3rwaqpDa7HgGXLeqVqlrj4DVJmV77lx2ufxBo6htOZv8rJ/MwPWf S99GNnCOKOUZ0837aAssyM5tb8foGceJToBsuuTKki5H7tutrxM+TjwNFKEEQYyC6wZBENEyILWM fLuJld/xTn+qJ+PmFdCS9+14aXY2ePlonY6TmtRKtnQS7VByThK554aKuSffyNKXN6/qy4fAF7Ko liwSog6aiSBKa8W8q2RldIPGTk6V22zzoHml5r5fE29PN2vItzLcBN9fYJUbMQR9A/E/dT7qdN+P tRw1JbUOTPGMWAGKUIIgRsF1gyCIaBkou75yws59IJQz85Wydl4J2KmCUUrAsrVu+eIew1BHJsH4 KzjZP+4IPdKPhy1Smm1tO9fWZJReyccCilDQ03gYSt3KajFvfecEVvJ8H4Mo+givmPWWS6O9oJaA OTRUVN3gcILvLLBKT3DbY/o7YKcMLGyX7vsrpEyTHIzpezIoQgmCGAXXDYIg4DLw9q1gqKfWqYlA S07pPNh4HmM2fFGbf9PvmkrJS+Ye5dgWm/fphbbWm5sDp8jrz6fBFIUNfnn3GLxKIrlulSker6OF mrYOruJqDbnVZ+asB/adCd90UCRvGWv5WD/qW4JWoK6KR7wfurw8FXBKgTduPZ9j+u/FO75uIy6A IpQgiFFw3SAIAi4DcndZOidrRRziUFXUlocQpN25VrwvdRffviTn/ktGKQFl4WU+sogv0Tp0Cklg C5p7MtLMaLwB8C+ATGPhYQ6a5euPcC5tN/VxXGC6o7LKx5Tk74bGX2L9wp8NTrToBl9qt4dYfS0S /vQV5kmosSoRbNxixNsppv/GSUm9JR4LilCCIEbBdYMgCLgMmG08PL4URhrvFjKz10bJvOropi+t XsEkSsBQts2rjFSAEfWmmzSFnrRl2gje3KNFipTBnwlZBusKciIku9d0Mw0Z4Ug2Nba5bSKbV66x 07NQ3LWvpz+I1dRo2CpKloA5Xq667WgXN1k2SXxlsMH6NwC1pmQdwdWj3GjmUJg9ILEOFKEEQYyC 6wZBENEyUIXDO76AhnvdKmuWmAQqamLnoXYAxNa9ff7qXkGlBH+SblJF3Aq9Pr+ukcxG1y+LyXzM K6E3QrYZ/JR8oI9q+UpVz9qGSaS0t9VVEn/hWCzqxWcpE7AIyEznyU+9qkJK2QzuU7CzdyQNyYp+ 9PLyPKgJFN1f9BycaZdPXn0OKEIJghjFe9eN5PBGMkthvIs8bUTgZnCmhHpRgjbk/dRxf0IUsa+s 2MiP924FzUbXbIPXm59tIiW8b8+x6pciUj4DIFTtXVJQVkQ83bXVKeXM5ARJDWs0dYPegzApWe+E bi/4bsO7+QGo5SvJuaQbI8kuNbaS5023Jl0s8xXldcaP/tXLljDsQ3TfVjINOnHc5+hkkZyN4mCh 9szyfj4ay4VdvdOcIJcyLgMydw/H1+yiCYLYhrc3r06PbDO909aF5tU2DkOD3D/zGpOhy80Jp6Fo n/CVt9q2TxP3lmMQCuYNbYoFifZ79bY74VZ/XgSAppByI3riwql8KUOnqwZJwMhb8+mDgOO6T4Ov AGgmrO+r3ESdO6X9+8e9FFFyE813TlaRA4Le2F9Ow1lRMRFxmJVrFGBrwpwxxdFRepLDTgKfjWDR gzcXU293LcvbxNRnBYl1+ModNUEQS8Hm1btsbfadzav+E9i8AidM2l4OwOx49+9FZydakRdP7TU8 wnJyXgTkUKHkiIwm0Ep6FcmChkYynavDxmcolG9ZNGzPIX9A8yrnLKsll0ZrUORKY79jwakCXE/G HRR8TI4Znc0KNsWKa9AVyypfGx+7yn5Ne3x5PxfwgSs479K05lWZ4yqHxFPxlTtqgiCW4snNq3TA fFqO+BPaVzUubAx1ysq70LZ1x/chx++Y6+EQndkZ3ga3flb+bf/40QmNt6dDfSgablUlldTbtWzc JvcNImJ2rq1i7thd14+OGp+rZI1+BFqjIeG16rRydHaysPZZZm4yvmXdME2G5wdfLl+q1p1wlm/f 410CDSvF4e+/6+zDuZ/s8Vm2gEWx3NWfPTcdx62wkEeIfvhJ1rq5zAiwTFO5vWam79n41k01QRDr 8N51o9FRgR2DqE1x4arTnky/0cijdkelh0PEp22is4FzLZKjbK9xu8Yqwt8JjQbaUPNKom33g9Bw Re7kzZFVVOA+N4mPPhN2M3/WvPJb/X9HJ0vIml/3fEXRF8WuvlhIEtnOmCpyIeGkn83Y2mG4ho8t 2gqX55qIBwffNCKkkLbVm4O3etqu5HoIbaj010cY9xYO59X8nmRLmtLWEIstkOuhTPhjK/yxqKUi 7xQwu/JGc89iHc/cXr9gBf5SfNNGmiCIPXh78yrqBtxv0VzreEzsEW1oXp1eLg/2NF56rLR7O518 ohH6hx0av82nx6Oet5+LyA+5n5Tn7NnJ4y7KJ6OK0KMkG8rUtgi0rptMSevEsttvabdDaxudq9yc DVsSZzF8Cr5loci6hmUNvJkWglm+an2Koi86FwjqBdOtSfdoXhXmxf6WrwzUapOPsKSF88uPLJej uhZt7B3ZJXel+1+MWsDZLhSmxibe3/2Ggbl7Pr5mF00QxDa8vXnV+Mh3WkZbNI2rfBei86p2/6e/ 5SI/GmoH9Tsejdm+vMfKqenonMh6+6B5bYZquwbJ9J9wGre26U9B5IfSEamKqYW7QS2j5F60apnS tvg0RLvrxsn19YrduAh1FHZ5Avwc6twlksGwpbR8B2q0RQHkje2Ffpjlq64hx+t/J6m1xU+0/dVV zen1djUN6Ww6bm7Lp1hZzM2SIizvjL9f3bJeiokewPsFuNeoHE+4s0ez+HP3DF+Pr9lFEwSxDe9d N067Oo2D/S2a04ZS/wlDfZKeq/4+6mmenLaV+old5nwavVNzN7N2SqbHaH/z6k5UPwuRH3LHLs/Z I6OMovxj8OkiAveFmmcW9V0CMn0fDpSGJ2mmSXzafLWr7SgtNN0WAQFTYMr5YTDLV6nfQr28NUuN XXw2PnmVxepnynzPqlvNVauKz2yrzYXFlNl6yIwXm1xhRqHCJXLn7y+59JNnRBiMvLd+iFF8zS6a IIht+Ijm1cSO0+lB2Cy61rTp7IG0eynt5tX9blIe8fRmIoa4LeoowvP7m1enQ30oGn4oiaePrCJT tIN8kdTbpQSWwniUY3fwJn+RjLKS4niRsjpiHBF9pHJEMp/P03T/0lpbhIeqBLkgPzAFupKVUpbr SbJzDTRPtrB9/TfjSbSQho6KioNvXt2/69noqpHhBxN87KSWRRyc59tofAFquERhq2AmOT8nlLct m9U3TWIGvmYXTRDENjy2eZWPXkqj9eFPOL0KNmrk286D7V5Qm7Y/f3SQTsdPrZhrT63084FvG9wM htw0l5yaaLtwmjh45qej4YqUePLtQjLusQevKCcIqHdAbqRlPGFIy0ElIddpWCEea9SFdLU6Wgje l/TQWVtCks2rBwDK0rexaUJOt2SqNlhb7Ntt1ZX0/Mp1SuZdEZaLjJj2K9dbN3I1J1ekXbCVwAbI VdSIHUlU1WVuHDNCa6e1+OaFuXssvmkjTRDEHnDd6AGjRHw3Tgu87jM3kIFC0jSvPhNKQHdsrWv/ KlUJsIyckMmiKxXJ/a163wpKyyk/uH/ybQiKYWF/4zYkyyx6QvWtrjBTabtY1pbguyJcXS6N673N K9nu2N+7K7YqDdd4IYagQufvHeL+PstWtfIVe4avB+UVQRCj4LoR4fQJHIL4GvQU+KZJ4Da337QR lcxlPBvNq6Kv222uiRCatQp5lQHTYETNq6X0pKR/Q5OB+ChFr6pFNLLqp2fNq4U+phT+vCnCcH55 bvdshF4DW+X4LsQpeXqpPxS6YKLm1f3wtovp5uDEIlBeEQQxCq4bDXzfX4cRBMRpjc/aXp4zgfvP 1+7z4zei0g+jkYMLjhNSTiY288khSaG7QzIb6rXTnEsYur+7VC2Ij62KD8Yn3BxNK+avqlXFitc5 Oc27rXPig7lopjcoHDNXrrp5ywOflQD6iM2rD4ar4ah5dTfI0WNdzN2DQYVFEMQouG4QBNFYBmSv IK/vEtjNZ1WP3yAiTO9FNYJalx2drk0ssZC30sCnaXHnKvs/a+K/avJePH7/gKtUt2XU6/I21abN 1uZV2Dh5x59s6+m/xiTobJiPNk/tukSzeTUFurDVraRMvSnNq+ixLqbvwaAIJQhiFFw3CIJoN6/M OQs3gbpfFTWvVlnfAiiZz67Z27xyJL0EeJdG8OK6twFIrMDj9w+m1akqR3erYD3nnZ0TH8xdPati rjG/1hm1B1DnbpV1T0daFPHnCjOGuAdrmlev/066xXtLopaZvieCIpQgiFFw3SAIIloG5H5PnrNu H+jV0/c1r6BGDs5OZW9vVcBalmFjyorK4E8L1zEs4TIl8emFQUyHnFy+eQVnIiz4TR0k2LzaCzOv VYtv0fx6avPKFMUX3Hq2otm8km9WNK/qmHw09/GgCCUIYhRcNwiCaDWvUP9k3T4w3OZ+i3yAMhl0 e8weXzavdrDsbV4VAQJF3xJqpQyoK9+OZ+8fkuh8KxkralMW+UQRPQcPaF7tj0Y1dLi/v3klXyfx rOk2Gl8Fd2szZVZ/z6g007/KOo/E00ARShDEKLhuEATRal6hc/Y1r7LVUIvsbkNVRv1Obf+zweya bKY9VaWH0f5bcmQE9XcUxkfi2fsHtH4keUgWcHltxPU7fXxf86oEa3N/WFkR7u+b4KBp9yW3nrfB lTG8y+dJXSbbgP2WncO3giKUIIhRcN0gCKKxDMhmizmyigxqXuWv6FHIZgt4qiHsIe5tXqG/7ACK znS3diXI9Ky+oCo+GM/eP8jaQM0Ivc5Es/LHYCf63gdXWmvMLpjW5S8XwxzIVSLZqNb7y5Q4u8GZ voeDIpQgiFFw3SAIot28evUKtnSQcNvkW+Sk6Mbpv2NqPuMhG0TbeMIWYqN5tS1BpnNVjhBvwOP3 D7UmjaRl8yoAnuM7m1f1zTuevBIWf7kMZgKtEuD+MjXacnA76YkngSKUIIhRcN0gCOJ0GdjWP8Ft k+0aahFUyyVVZR31r8rxPZ1Dz1P02mzzqn6YQv7riP17s/uxEOJ/hL2NJ6YAE202r2TJv5v+G/De 5lV+9795pak8tKq/APAuP3lk1xP7zRn9cFCEEgQxCq4bBEE8qnmVoz+s+4p/ewRL5rh59Xqx6282 MU/UvPKObGOFWxHEfjx+/9DVvMpf2Ce/DKn0zest5kFnMb3rgRk2r5ah5PQV43l/Gao2DEm9nWiF mAWKUIIgRsF1gyCIxjJQ9cv6h3+MaEriD+u+5nGI8+ZVUttseXIZYR9J078yvUQt+Vezyk/6qyLi fzx+/yDbL7WQ2byKUR0XrZv90XhnClC/k42siSgFVibjq5F1O9229er+Nv83J/WTQRFKEMQouG4Q BNFuXplz1jav/D/l+l1y0ujlsmmvutmdab5B3tO8MonAet80r9ZLPM+iEiH249n7B1kYuHTj5tXP 6ty4cbM9Gk+oridw+DrYW5ucdzNGrhPaNK/4NcfzQBFKEMQouG4QBBEtA3KnJ89ZtANU5oyWfMe3 /ytgWnNRZ0j1ZPS/ebWneSVjHur9lE1jbQ+xRyhrIj9d2sNuq+pW6cnoJ+G7PdgO92XBLzavGjEg ZkDeTOp9RN5h7o1cb17+Jks8DBShBEGMgusGQRCt5lWqm0yl/BYxkU9KfPeTV15BHw9iZdOnSnWd 3haEhB6+wkc2Nq9y0L/aYJf4OLSaV+anlDuajL+GsuzI5egdPB4Q/ydw+DrIRds2r2YNrv9nIrxT PBYUoQRBjILrBkEQreYVOmdp80p+ber3nJ++/7Rb60Ave3G9+etjwwr0Ei3vTdxkTy9v7OYRHwdV G9eaV7+3QfLuv034PyH4T+DwdQA95Xk1BuY1m1cPBkUoQRCj4LpBEERjGZDfkJojC/kc206sMj8Z Rhv63XXt3QV9vP3Nq5eyT0gX7G1e1WrU5j69KohFkK1OO/W8gp4qoj8UPj5vW3ifsDt9AoevA5tX RAFFKEEQo+C6QRBEu3nl94GbKCX71yv5w9sUpjFlo+o1tf6zwZ2dK8vTC4HSvNqoDpy19ylr4hOA ywUWEJtX/1B9f/vC+4Td6RM4fCPKLHtV2ew/GyzzWk3uD98/fCUoQgmCGAXXDYIgHte8Op7z+bIe BehQueaV71+9oXMYPZ3yhOZVffMlLU1iNUx9snnVAnoa9HVkO5PdFoktAFNv0h1ENanc08JfsIX4 PlCEEgQxCq4bBEG0m1dZ/h3f6kZB2dIe206wyf1YyNDhjlCkr/c3r9xry/YdzSvFLSV7hCAiOKHM 5lWEGoG0/Z+VQ5371w/xLVjevEp4cDavHgiKUIIgRsF1gyCIaBlQu769/2Z4Sko6fc2e034RrLfW VlO/6c8GM/rXpR7RvHJap74liAbQ5IoUdGZH9AkLLyf1l8JPvTyp3uT8xfsWNkIfBopQgiBGwXWD IIh28+q1x0z66YXFhIq5L/v+3baqXPPHN4Le0scLNb7ouXn+23L0fmVNfBZEWTZq2xbzDyLu8L2B CfGNUF1i3by6PfTJvL7NnZgMilCCIEbBdYMgiEbzCp6zYRNYOjbf0bMqOJfM6Okssyd/A0/DNui5 bSAmKH5PVRDLYaql8RQWdW7Be6cYJ/iXwt5TJvaX/P8l83ij7lrEY0ARShDEKLhuEATRaF7JTaDa bG6g9L3Nq7pzV2/ANr7sudXlW3hKi6fNq7ylpakpfk9VEEvQ7E6ZFrFvZ72b/QPA5hWxAAubV378 cgPlP3j1SFCEEgQxCq4bBEG0m1ewX7GP0lc2r/LRCWw2r9LxhxV/EdjZucKKvtG82i8NvqgqiOUw 1YKevDIF/yaiTwKnGLEG5j6YxWZj1uD1xiQeXb4/ODEXFKEEQYyC6wZBEI1lADavlvORjxt9V/Mq u+fZTPMKyOpkd+M7GRb7J80rPnlFPBm+WoL/+SB1bgWnGLEAaiPhviKZa2Lz1oUYBUUoQfwg5MRP Au2D8HKCIH4Tnc2rDY8lqMeNZBfli2C+FDbNK/9AyP69d5HwtpMWN6/qgW34rqog1gLuf3TpTlfQ BEF4wHvHhuZV5v9F9HmgCCWIX4NsSZkV4O8tPNg+QhDEryFaBsp+r+wA5fElTIqJJI58zTKlN9Sg HZRq46h8MZ3Enw3uY+p7aI6tfWRlM76mKogNCKplqYImCMJDTjE54+Y2r+RNllP7saAIJYhfA5tX BEHcR6N5VXsUqfZeFm0C5ZjGnGqifAfgH+KlbPbY29qGgFvQvMrJp+QdqfmaSiA2AFZLUOcsLYJY CvntTPlqZmLnyn/v9s5bFRGDIpQgfgqmPcXmFUEQ19DTvJL9q4XNK2cr7/+XwPfgrHlVnwZ53xfH 9qGUhOXAPr0fNNUoRogTNCvkLZOLIH4U+p+Ym353s7ct378iHgOKUIL4KbB5RRDEFDSWAf8IUPlO cz4N8+QVOv4dMM8yRc0r2TJa1zNskFRU4+bVe9pHvHkR/fDVwkYoQbwVixpKYEqXrUt5STwDFKEE 8TvwPavLzaserHKDIIgHoN28ko8Arf7usmwsC6Wv3GpKN189IrGxzi7s9qvqjSS7mlf/sXc3yori WhhAef+XZmr6KCThR4JAwL3W7arrsRXx9BDZnzuhiZ/7r4ITrf/XIraCy5ycG6+EV40/syLZWF0q MCGOA8Ors3YReIgPhV1yBjj8eNaezJ1t/lhRmf72ZjuviqiqDK+u3M9u3JksvUy+yL5sfyb791P/ VXC89Rr55Aoa+OyEI67MqfLv3dp/cpFQhEIQs8G18ArYZ2UYGNKStC+ozxOYA/cjSng1vMvV8Op1 o8typIt3deYr7PSfpqHf+q+Ccy391yLCguudedzNf2wJr25JEQoB6bwCvrQeXl3ZAlScbfY/uuDV +1byK10Kr/KF6y/9bRRzBu8WXsF266c6Xff5McDhzgmK1z+2fHLdhyIUAkoP/NlJxOszi40bwMfw anxY1xV3HrYHk7lyP3yqOeRyaedVP9TQ+Vl3+cu5fFfXwittKjyC8Apu6MLwqvg6xvF+B4pQoJZx A2gfXvV9kYtc0OXVUJFNFZ1XafPVeE+7JjRfYfN4wiu4p3OOu/WPLZ9cN6EIBWoZN4CP4dXQDXVe oJRGNENo058UlDWUJ1UbO69anm9PO+KEV/wkp0NwvcOPu7xXWXh1Z4pQoJZxA1gPr4YbQ6DUn9AF VPTz/3BCMp9NdVlq93rL+e/hJjtc5mk+RADY54LwSs/wXSlCgVrGDeDDlJp8Kl8atBy5D5PwKr3z wBdqbprRZSFVNwmLTgsMt+2uzisAznFOGVL2Wf30N2LPpQgFahk3gI/h1TRXOX4fpt+T/uh5ZtFY tdR5NYZ4rdf+8v01AKe4JLw6+wSGfRShQC3jBnC78OqnE5IxmJrNrLryAdmzmu7z9J+m1f4A8AtO C6/66XnFj55UPJciFKhl3AA+Txt8P+y68Kro+f8h818Hz3VeDT/2bcOrLt8f4RUAu026osY/B75I +jXQ8GE63OQGFKFALeMGBJcmJLN/219yBcA0D/mbK3fSC93BUnjVT9bluMWXxUlqVexSm/0B4Dec Vobk37RkF0Px4XUTilCglnEDwsrCooWkaIwpTl7v9HaJzZkeFl699/nf/2UzGRvuDwCPd3IZkn6Y lu3DtKYIBWoZNyCsIXxYiSNWgpRjs4u1xOYXh6nZ8Grml3ybNa/et7IPDfkVAPtdEl7197j6CQVF KFDLuAExpSdvK3FEGaSk08eOOv0rZqVNvyH9RcPkhbXw6i+3u8H5drZT73+d3sohAHzjjDJkrrV5 aG/24XUfilCglnEDYtoYR2TtT2fOHExf6D5z5U4y9ry9x+BpePX6PaQ/3qDzqvhH+cl/HQB+wxhe 5fmVD687UIQCtYwbENOezqsze6KKV8nCq58bpork8EPn1SQyarXP3XvZq+xHALibvKk7wvdij6MI BWoZNyCssX9m25pXQ4/W4ed+aTAyfj36uwnJNDkcQ6rl8KrJrg6EVwA8Q/YpOn5VdMZXb+ymCAVq GTcgrOEUbiUhSXOqmZ6o4/YkzcTS/q6jXuJu0uRwvfPqDh1o496aNgjAE0xbx3+7qftxFKFALeMG BJd2Oi0+II2VTui6CXh6mSaHZWCVLzB7hzkOZQlwj70CgCUfwitaU4QCtYwbEF33YRhYOvc7chfy mYlBzi3T9qqx8SzNsu5xqcG+aLhKpg3+/L8RAA+VfQs2XJvGtPfbUIQCtYwbENyHzqv0StNJX9Cx c/qK8Oomic3ZZtKqSXh1k6+Jsx14f2o03ysAWJF+7RLn7OIpFKFALeMGhJXlRctZRJasvFejOjC8 KtKabN5czGmD4z9Mn91svbfzuwkAt7TU1/3DZxcPoggFahk3IKzs68j0ntmH5Y9cevC+3VgLr35U OpFhZtpgHl41/z1k/0BFaxgA3NLrS6K8mdmH100oQoFaxg2IqLio3ad+qo0x1859yb8JjdDYn761 xfAqb3W6zw6bNgjAU5Qdw5NG4tY7GJciFKhl3ICYZpudVsKrMVk6/2qDQdquxokM3eTs+mbhVZ+v HNJLrgB4gvQE5lafqihCgVrGDYipbHbacP24MeY6bWfSxv4fPr0sJzI8J7wq9w4A7mr4qBo+Xv/d 6yPsFhShQC3jBoQ1NNJsnQzYnTVgdH0S23TJ96S/e245vLWN4VV3j9VlxVYAPEX6QTp8lAqvbkIR CtQybkBMd+m8mnYevRfg+u1zyzKtmv44Da9a7u5s49Ut8jQAmFV8AdQVi2r6FGtKEQrUMm5ATON3 kUMkNdyce/A05jp2T9LoZmVPfsbn8Oq2c/R8agBwf5MP1TS8ar1zKEKBasYNiCmNRD52XnXnXW2w mCfXld+THvMq97MeXs1MH7yP3/1HAeDHrJ1j0JQiFKhl3ICwhjO3tUgqP9cb2qIO7IxaOrE8ZOP3 1H1csD2fO9g+xzNtEIDHWf2C7LfPNO5PEQrUMm5ATNs7r04Nr8ooJMa3omkk9XHaYH9gn9shfGoA 8BDZl0H51Qbv9dkajyIUqGXcgJiyxp5ubc2r8Z4hvCru378TWWfRTHj1owNUGlAtTRsc+ppud3b9 o/8oAPye4tuif3fd9buhYBShQC3jBsSUnrmN89QWTuS6dM2rQxOVbDfidV7NtFolP6Yn2DfiUwOA hyhbnfMvyG73CRuJIhSoZdyAmKbfRa7kJLPNUcfuxvTE8pDt31P5lhfCq5v+EnxqAPAQ0y/Ihu/g 7vs5G4MiFKhl3ICA0nO5LeFV3+fpylGnfPlKqgHDq5XOK98IA8D3pn3mK63mXEYRCtQybkBAaV6S fhe5mBp1Wb6UJS4H7ck0GTtk+7e1Hl6VdwMAO6Rfk+XnGD//TdnNKUKBWsYNCKjMS94rhC+dyKX3 D2PGIWd9az1IP31KWb7xSXg1c5YNAGyXnFyUnVf3XFUyEkUoUMu4ATGNYVRyOtcvdNHPJl2HzGtb zHB++pSy/OZ3El6lp9atdxYAHixtHS9OMHzINqQIBWoZNyCm7MvHyenc9MHXh1dfbvnOsrfZLYZX P/97AIBTDV/M/X3CFh+23U8vUHBzilCglnEDwkojo351GmDWY999WiCrZgf6Ps9tInVepbdX/pgz CAB7dF16xjIfXtGIIhSoZdyAmF4nbEnbT3b/3ONfWdOGSxNu34eVjqMfPqUsg6nJVRezxwAAuxSd VzPfENGIIhSoZdyAmKadVOszAWf7o77fh2KzZYzzo4qo6kPnFQCwV3kCk0dYrfcuLkUoUMu4ATGN yUk3Xki6X16wfTa8+vKsb2WzP35K+SmwCvFLAIDzCa/uSREK1DJuQExFeNWvzgQcp7MlC7YfHl5N I51vNn5zS51Xr//v+0N+wwBAll8d10DONxShQC3jBoQzWb80/XH+Gcn96ZjxzYlf2WIUqvOqzwLA 2fAqxC8BAM5XhFe9D9kbUIQCtYwbEFDW9rOhf/6MzqtpeFXkObu3/DALKVa43wMAnKA85zFt8B4U oUAt4wYENJ6w1Uwb7CZXGzy186oPMjoN776fOZ12Xg0A3yi+gCuWKWi9d3EpQoFaxg0IqDa86tOL TXfj7UN2Yza8+nLLDzDpscp+AX8PifB7AIAzpSctQ3jV+5BtTREK1DJuQDjpF4751QbXw6tp59W3 O7Iwe/HLzT5PGh7ma1613jMAeLbyi6L8Isu0ogiFJ+rmXPnql70WcBPZJLVu/PLx44lc8fjvdyNu 51UqGYeD/gYA4BzF0gehvyy7E0UoPMtKTnVZhGXcgIAWW56SOWuzT+mP7rwam766vkvjtFAmUwiz PwDAF7KlD96dV613KjpFKDzIlgP2goPauAEBLU0bXH/K60ZX3vPlbvxtdMjODtnyw6TjsMAKAA41 2+btS6K2FKFALeMGRJOes6UtTyv5VXp/FrR8lzJle5JmaJHPJ8O+cQA4x3x4RVOKUHio4eC9eMGr 3rgB8RQB0V9q9Dm8mjz+y677sYe/33rFwxCEVwBwqLJ73LTBG1CEwhOlyVVx48pXB4JIZ+dtDI7O 6Lyadn8NDWC7t/lUFrwCgHOMyVW6wGbANQpuRhEKTyS8Ai42u9jUdWteJY1e03W3op9MGpMB4DjO N+5JEQpPJLwCLpYu/rDxLG7s1zr6aoOvbfoa9I8xGQCOk56xFP3NbXcsOEUoPFS61JU1r4BTTfvn h1mEW577ark/YjdmF1CNfjJpTAaA42QnGO8p+c43mlOEArWMGxDNl4tNHTVmCK/mGZMB4DhlcmXa 4D0oQoFaxg2IpkiNqs7iDu+8eu2Fqw0CACdIO8ynUwib7lpoilB4kG7Vlbtx2WsBN5EtYLUtNTpy zav8e88xEHvfqfsIADhK3t89dnwLrxpShMJDpQevNa+AU6XfPBadVytnceM3ld9fbXCyAIVpgwDA Scroqma1T06iCIUnmh65Oq+A86SLXA0tT2PX08JTxtvd/P079sGaVwDA2WbDK+cbbSlC4YmEV8CV sgUfujGN+hBeDTlT12eZ094d+GbpLQCAjdJmb2ts3oQiFB6q1YJXvXEDQqpd8+rYzqvZ8Mo3oQDA 4bJzGHMGb0MRCtQybkBAO1qeDljzarpOu/AKADhTN/elmdXam1OEArWMGxBWmhptevARVxv8GF7t 2CYAwKzs1KLr5u/ncopQeKhu4sqXvuy1gFtIEqN0wfZ+w2gwPmX3i09jq2wdCvkVAHCk8dQiWeez 2d7wjyIUnqjtkWvcgICKNa+qIqP9+dXsnEHhFQBwpvHswmrtt6EIhScSXgEXyxawep/IbXnWlzMH hVcAQBNOM25FEQpPJLwCrpRddqeraKH/cs32jcmVs0oA4BQKn9tQhMITTRe8CrLm1bFv/Ow3ct72 p2/8PoP5yj/NdJ+v/6+XfdKs6BVepYumrzxruN3N3//xdbs+i6zGn4VXAMDZnKbehpIBqHWHcWPL Pnx8zEPDq9nN3uEfpZ+Lp9LbxY8rT+RuXlP/3vHRxs6rtchr8+vOdF5N7xReAQBncI56G+oFoNYd xg3h1TWv9aVhr/5uCK+eK122NI2PPj5rvL2j82pptXbJFQBwDeeot6FegIdqNWewv8e4MTslLf1V TH8zs/csbXnlkdNApnjR9U2t7MnS/qy/r9k93PKiX9655T+DlYRKePUsaXY0ZEgbF2x/3ThwzavJ XEInlgDAYea+PXv9oR31AjzRenZx/atfb0sqsjF9mm55+oClpy/d/mZTVe9r/W9PvXPFxoStePzH zdJK0UA1xFYbw6tpx1TVS8+veaXzCgC4gHPU21AvwBMJr2rDq9kH78uL9oVj2++s2plvtv9lXLbF entVmnHd4T8qlgxx0ZAdjTHShud+H16ZNggAtOEc9TbUC/BEwqsd4VWXmH3Axk19H15t3JON72v7 Xk0bnKZ3zu7e0tM/Wg+vNv4VzaUZ0d8/1PbUqJw2uC3ymr70GFvNThsEADiDc9TbUC/AQy2FDNe8 9JUvt2Ufvg+Xdmxqd3j18e18s9tLe7Xxzo//uFX/+sKrn7Fv6arxWWnL1rbnjk8coqrub+DLEq2q rQEA1HGOehvqBaDWHcaN3eHVx36nK8Oryzqvzrjz4w6v/7h9mzS3u/NqJnqq6ZUasqmxy2oSgkmu AAAiUDIAte4wbkz3YWmm2/THHeFVuv2q8Gq6V0u7uvJOtzx4dlfXt/PlnSuB2+wWpk9Zehh3s3vN qyFwGsKrNIX6+FVmOWcwD6/MGQQATudM9TZUDfBQG6OPs18a+HlpQJQe/VvDq/SJXUXitBJeZQmY EQkAOInTjNtQhMITfexpufjVgd+2e82rL6cNptMVp9MGAQDO5ZTjNhSh8ETCK+BKs2tebXnW+PSq BduTJa2WOq++ej8AAFsofG5DEQpPJLwCrjdmUDVPed1Ipg1ueJrwCgBopOsW/9COIhQeqstd/NJX vhzQ3L7Oqz4NoNK1qj4/bWzZGu54vXSX3Q8AcCKFz20oQoFaxg2IZt+aV/134ZU1rwCAxpxy3IYi FKhl3IBQdl9tsJ+mXivTBied+UNYNZ026EwSALiCU47bUITCQ6UTBk0bBM7Tpf1TXZ+FSx+fONzu xv/bvmC78AoAaMkpx20oQuGJhiN3euPKVwcimLloYH7/2hOXUq/1VU/f61sV0wb/tlMx/RAAgJ+g CIUnEl4BV9q3dNXOzqvZawwmnVfp/S79AwAQgSIUnkh4BVzpm6sNvm58XPMqe9rYefWKqvJpg+NN AAACUITCQ3W5i1/6ypcD2hqTq2Ta4Pbmq7rUa1jkKkmqhvBqmH5o5iAAQCiKUKCWcQNCGSboZeul 1zQ+bVxofcyjujEfy6YrvlOtdDksAAB+niIUqGXcgFCyVqhdjU/FSu8LD8qXsUomCwqvAACCU4TC Q6WrXZk2CJwnjYmGo3/HtMH1yCu7v+tmYqyZhdqNRQAAIShC4Yks2A5cJk2K0qWrNoZX/bvz6t/P i7lTNjlx+idfrX3Y7LHvFACAe1KEwhMJr4DLzIRI28KrsV8rCa/6ha6t7MEbwivJFQBAHIpQeCLh FXCZIoNKf/z8xCF26vosiJp7+nxsJbwCAAhPEQoPlS51Zc0r4FSza15tfNZ8eDV3scLP4VX+58h3 CADAjSlCIY4usePO9G+v2F3gNmbXvNrxxDSzKrawllwJrwAAYlOEQhDFwf734/Y71+8BIiimDW59 yjt96tMsq9jI0jrtwisAABSh8CjpPMGpHZsSXgFV9h39Y+q1vmD7NMIaMivhFQBAYIpQiEl4BdTa 0Xk1PjdJnxY3vpJZTcKrnTkaAAAPpAiFUIo2LeEVsMXuNa/Gp39KvbaEV0Vr1nfvCQCAx1CEwoPM zhZsMm1wiz3vELilcZX1mqsN9nnq9TF02th5ld0BAMCTbawuFZgQ05fh1cl7B9xIGjelR/+W/GpY nr1LrjY4H2GlXVVFl1USXg17oPMKACAORSjEJLwCNkqbncZ117vPE/fGfq0kvOqXF2xfDK+Sjitt VwAAASlC4UG+6aLcnlMJr4BU1gDV5fd8euIYRHV9Fk1NWqey5Cp7Zjbl0IJXAAABKUIhjtmka/ud 6d9esbvAbbzComRIqJozOBNe5Y1bRcy1Hl6d8QYBALgzRShQy7gBoezuvBoe2Q+LZSWZVRFejVMC J+tcleHVcBMAgBgUofAgwwG7Y9rgGbsB/L48Q6pa86rPJwP2aZY1N2dwY3il+QoAIBpFKFDLuAGh jGFRHpNvD5Gy1Gt5wfbxkcIrAAASilCglnEDotm35lW2hSSAWnqJYYKh8AoAgJQiFB7KtEHgMrNr XtU9/dOi6+kEwzS8Shd7l1wBAMSkCIUnanvkGjcgpjFQqnrK0E+VJFdFDJU1Vg3JVdenOZa2KwCA sBSh8ETCK6CJ2qN/yJqm8w2n4dWwJny2bPvkz/fvAgCAZ1GEwhMJr4CL7Wu7Sp/7vrfL8qv3Eu79 0H+Vd14VbVfCKwCAgBSh8FDWvAKukU79q1p4Kl1wfVi3amYh9sm0wdnOqzT1AgAgFEUoPJHOK+Ay 2dS/pFGq4onrnVdFb9VkzavyDgAAglGEwhMJr4BrZCtTvcOrfkd+tbTmVbLBlfBKzxUAQGSKUHio hgevcQPiKKb+TWf8fXz6MOVwvo0qiaw+TBsEACAqRSg80XTBK2teAWdIs6N0zavaldsXk6i5Na9m F2w/+p0BAPAYilCglnEDQtm95lWxkfFiheX1A7Ml3Ke9WWX0BQBAMIpQeJAtB+wFB7VxA+L4vvNq fubg+NfJPcl1CcsF2wEACEwRCs+yMkPwssmDxg2IY23Nq+1bSC84WMRfeadVsSqWOYMAAPSKUHgm a14B10iDo/TQ3xgojVMOk/CqLxa5yicQZpMHZ5bLMv4AAISjCAVqGTcglGzNq/yeTc8dequ6Psmo ih6rudWv0vAKAIDAFKFALeMGhJKteZX8uPG5/RBhvWcCloHVbHiV/zntzQEA8ACKUKCWcQMCGte8 2vHEYcH2fBmrj+FVX5mVAQDwkxShQC3jBgT0ZXiVLcbeZze3dF7JrwAAIlOEArWMGxDKN9MGs43k nVdbpg1moRcAAFEpQoFaxg0I5ZsF29ONlJnUxvDKzEEAgPAUofBEXdc1PHiNGxDHmBrlo05VmlTO D1wJrLo+bbjqJVcAAChC4cm6t+tf9+JXBFrJgqX3tQKHZGnjFmrDKwteAQCQUoTCD+gS17zcBa8C 3ME4ZzBfsP3g8CprtxJbAQCQUYTCc80GVhcc1MYNCGXIlnYs2J5O/ZsPr6aLs4utAADIKULhiVaa rIRXwGHyxqguuVbg1g2kK7Wvhlevm8maV9kfAAACU4QCtYwbEMeX0waHzqu+7xfDq7ThqgivAABA EQrUM25AHNli6nsXbO/7tAHrc3g1PgQAABSh8FjdxJUvfdlrAW2NIVU+zBy2YPskvOrTxAwAABSh 8EzDkft34+ID2bgBobxyqiS8qlhNPUmnZsKrouEqabuaWfkKAICoFKHwREV41V97LBs3IJSZrKl+ wfa/7GsxvErXhU8fBQAAilB4JuEVcJlDwqvXlMBuElgJrwAA+EQRCg+VxlamDQLnyVZcT64eWPfc ZILgdHl24RUAACsUoUAt4wbEkUZJw2rqFc1X+XJWWQuW8AoAgG0UoUAt4wZEkaxTNYROY860Ywuz 67QvhVcAAPCPIhQepFt15W5c9lpAW2OOlCxX1VddcLDvt4dXadh10jsCAOBxFKFALeMGxJEtV7U3 XEpXvsqarHReAQCwgSIUqGXcgCCKFaj2rHk1Ta6EVwAAVFKEwkOlswVdbRA4Q7bWetdnmdO+jQiv AACopwiFJxqO3OmNK18d+G1Z01SX/Vi1kU3TBid/TnpTAAA8jiIUnkh4BVxjjJ6SoGnHRrLIajW8 6uvzMQAAfpsiFJ5IeAVcIw2vxgBq10aKmYN9Hohlfyu8AgAgoQiFh+pyF7/0lS8HtDIkSOm0wfT+ qk2Va7YnnVdFbCW8AgAgpQgFahk3IIhsPfWuL5Kn2k1lHVZFeDW8Vv3VDAEA+HmKUKCWcQOCOLDz atzOXOeVBdsBAFihCIXH6Sau34GLXxFo5ZA1r9JNrax5JbwCAGCWIhSeZfaYteYVcJJjw6t0wfZi 2uArsnKpQQAAJhSh8CArB6yrDQKHO3baYJpTTacNDpmWzisAAAqKUHgQ4RVwpSxT6rIfa7aSBVPp 1manDe55CQAAfpoiFB5EeAVcKW2CSqcN7kiWhksKTte8Gu5Pr2AovAIAYKAIhQcRXgEXG1uhuj5d raqvHAeyBa/m1rxKMzHJFQAAKUUoPMj0OoNNrjlo3IAgju28KhZsH1e+yucMTruwAAAIThEK1DJu QBDHrHmVb60Ir4atWacdAIAlilCglnEDgkijpNe0wcn9VVsbc6p3kpV1c6VNWAAA8KYIBWoZNyCO cR2qd3j1TXPU0ppXpgoCALBCEQrUMm5AHNmaV/my6vu31nVFr1Xf9xquAABYoggFahk3IJpxzatv N5RMG+xm/goAAKYUoUAt4wYEtP+4zy4n+J41OIRXw3YNLAAALFCEArWMGxDNsZ1X5eULAQBglSIU qGXcgDgOW/MqWal9WPZq/BEAAJYpQoFaxg2II7vaYH7Prs2NVxUcpg0KrwAAWKcIBWoZNyCINFZK j/vdcVN6YcG/zqt+nEFoCiEAAPMUoUAt4wYEMWZK06zpHhsEACACRShQy7gBQYxzBvMF2w/ovEqm DX6zQQAAIlCEArWMGxBHtr76Nwu2Jxt83bDmFQAA2yhCgVrGDYjjjPDqmMsXAgAQhiIUqGXcgCAO nzb43u64SrtF2gEA+EgRCtQybkAI6UUAj11fXXgFAEANRShQy7gBQYwhVZcd99+EV6YNAgBQSxEK 1DJuQBzD9QGH435n1pR2beWtXMIrAADWKUKBWsYNiOPYBduHKGxmHmJnCiEAAPMUoUAt4waEkgZM 329q2Ni45pXmKwAAVilCgVrGDQgiW5+q675fn2pY/71/bTS/BwAA5ihCgVrGDQhiyJReU/y+W6p9 3GY3hlfargAA+EgRCtQybkAEaaY0hFf9d/mVzisAAHZQhAK1jBsQwbiI+uzi6t9tc8ysrHkFAMAn ilCgVttxY/rqX+7PeW+n67qVje943dmnbN/ODw/4XaL1vvyOkzqvhhtpw5XwCgCAFc7zgVrNw6ti B+4ZXn3crPBqat8eHvvfA6nXau3JpQYPWfNqOm3w2x0FAOCnOckHajUPr4p9EF4dtUvNCa/u5vCr DfbCKwAA6jnJB2rdNrxauTPt1yp6t6YPSB82+8jZvZq+xMojp3s7+1of38vH7RQvvf7I7XeuPGBp zz/+2mcfs/Jml+5c2VVqHd55ZdogAAA7OMkHarUdN6YhyZbYZPb2+p3rm5rdpaUtfNyr9adv3NXt IU/VK27c5nB7yz0f38uWl176W59rRynXvJq7f882u5k/wisAAFY4yQdqPS68mt6571lLb3xHePX9 DpwaXq1vZ+kBxabOyMo+7kPVE1m3drXBb7b5vqHzCgCAjZzkA7VuEl71X4QkW56Vmj5yfZeWHnx2 eDXd59lXX/mdTJ+7ssGlF53+u6z/Mpd+aesvPfsWpj+y2xmdV/07tho2as0rAAA+cpIP1AoSXq2/ 9PoubdnCGeHV7O5t3M7Sfu6+88tfxcdXWfpbn2sHGjujuvKeb7YpvAIAoIqTfKDWfcKr/t2cM/2r A8OrqmjlJuHV+qt/+Yof39GW2/v+sWYJr86TXW3wiKDJtEEAAHZwkg/UulV41U9Sji3T0/o8MJmd nja9c+WNb3/w7Mut78D6rn7czvZHbr9zy7PWH7Pyb7HxWbPbX9lPdkuvNvj9pt6plQXbAQDYynk+ UMu4AaEcHF6NP3Tz9wMAQE4RCtQybkAQh08b7NOcaui4k1wBALBKEQrUMm5AEBZsBwDgDhShQC3j BkSQZkrpQf9V1pQscvWKrYabAACwQBEK1DJuQARpsvT/QX/44upGEgAAtlGEArWMGxDBKZ1X2QsY SQAA2EQRCtQybkAQZ6x5lWzdSAIAwCaKUKCWcQOCOONqg8nWjSQAAGyiCAVqGTcglPdCVw58AADa UIRCHF1ix53p316xu8BtnHLQG0kAANhGEQpBFAf734/b71y/B/htwisAABpShEJMwitgO+EVAAAN KUIhJuEVsJ3wCgCAhhShEJPwCtjusIO+6xb/AADAAkUoBDQc+LvDqy3OfAfAdc662qBRAgAgvI3V pQIToimuKjj9K51XwJ+/pqj+nTMNPx60dSMJAACbKEIhlPVgSngFpIaoajjohVcAAFxPEQpxfIyh hFfAIM2p0oP+sPzKSAIAwDaKUAhiacrw7CTi9ZnFxg2IoOvH1dT/P+iH24cvfgUAAKsUoUAt4wZE MIZUeYwtvAIA4GKKUKCWcQOCeOVUSXgluQIA4HqKUKCWcQOCeF1e8B1eHXy1QQAA2EYRCtQybsDv 67p0kau/DOt1DwAAXEsRCtQybkAs85duAACAizgfBWoZNyCUsfMKAABaUIQCtYwbEIQ1rwAAuANF KFDLuAFBuNogAAB3oAgFahk3III0p0oPevkVAAAXU4QCtYwbEMFwecHiaoPCKwAALqYIBWoZNyCC V1b1L6pK17wSXgEAcDFFKFDLuAFBDDmVNa8AAGhIEQrUMm5ABDqvAAC4CUUoUMu4ARH8LXKVLHRl zSsAANpQhAK1jBsQwdhk1b3Cq1cXlvAKAIBrKUKBWsYNiKAIr7J7AADgQopQoJZxA37e0GT1N1Hw b9Er4RUAAE0oQoFaxg34ed24OnsyZ9CCVwAAtKAIBWoZN+DnpSHV0HnVW/AKAIAWFKFALeMGRDDk VOm0waZ7BABAUIpQoJZxAyIYLy/Y/R325gwCANCGIhSoZdyAON4LXTnqAQBoRhEK1DJuQAjJgu3D 7dcfAAC4kCIUqGXcgDh0XgEA0JwiFKhl3IAIrHkFAMBNKEKBWsYNiMDVBgEAuAlFKFDLuAE/L82p hvCql18BANCCIhSoZdyAn9f13eyC7cIrAACupwgFahk34OeVnVdz9wMAwDUUoUAt4wZEkK15ld8D AABXUoQCtYwbEEF2tcHkRwAAuJgiFKhl3IA43gtdOeoBAGhGEQrUMm5AKI54AADaUoQCtYwbEIoj HgCAthShQC3jBoTiiAcAoC1FKFDLuAGhOOIBAGhLEQrUMm5AKI54AADaUoQCtYwbEIojHgCAthSh QC3jBoTiiAcAoC1FKFDLuAGhOOIBAGhLEQrUMm5AKI54AADaUoQCtYwbEIojHgCAthShQC3jBoTi iAcAoC1FKFDLuAGhOOIBAGhLEQrUMm5AKI54AADaUoQCtYwbEIojHgCAthShQC3jBoTiiAcAoC1F KFDLuAGhOOIBAGhLEQrUMm5AKI54AADaUoQCtYwbEEf374j//38AANCIIhSoZdyACP6Prf5lVn9H /PAjAABcTBEK1DJuQARDVDUc8cIrAACaUIQCtYwb8PPSnCo94uVXAABcTxEK1DJuwM/rXtME/y15 1fXjbeEVAACXU4QCtYwb8PN0XgEAcB+KUKCWcQMisOYVAAA3oQgFahk3IAJXGwQA4CYUoUAt4wbE 8V7oylEPAEAzilCglnEDQnHEAwDQliIUqGXcgDh0XgEA0JwiFKhl3IAIrHkFAMBNKEKBWsYNiMDV BgEAuAlFKFDLuAE/L82p0iNefgUAwPUUoUAt4wb8vO41TfDfklddP94WXgEAcDlFKFDLuAE/T+cV AAD3oQgFahk3IAJrXgEAcBOKUKCWcQMicLVBAABuQhEK1DJuQBzvha4c9QAANKMIBWoZNyAURzwA AG0pQoFaxg0IxREPAEBbilCglnEDQnHEAwDQliIUqGXcgFAc8QAAtKUIBWoZNyAURzwAAG0pQoFa xg0IxREPAEBbilCglnEDQnHEAwDQliIUqGXcgFAc8QAAtKUIBWoZNyAURzwAAG0pQoFaxg0IxREP AEBbilCglnEDQnHEAwDQliIUqGXcgFAc8QAAtKUIBWoZNyAURzwAAG0pQoFaxg0IxREPAEBbilCg lnEDQnHEAwDQliIUqGXcgFAc8QAAtKUIBWoZNyAURzwAAG0pQoFaxg0IxREPAEBbilCglnEDQnHE AwDQliIUqGXcgFAc8QAAtKUIBWq1HTemr/7l/pz3drr/2rvb9USBGAyg3P9Nu08/1iogEmuZl5lz lh8tVRxMJyVZwE8vv+72A86bvc878qemG63H8k597Q0AAOfT2QE2cIDmzavZADKbV6ubvV2ZOewD 5I/8tRG+99cySke7AgDAKfV0dA0co3nz6nKGLpDm1SP5I9e8muloVwAAOKWejq6BY8Q2rzZW3p6v NTt3a/mA24etPnJ1VMuX2N7g6uvevsSeR2683Gv78vTt2rO17fE8Hfn+lRsPWH2vNka+/ZiNN//R yo2hnk5HuwIAwCn1dHQNHKNt3lh2J/b0K1a/3l65vanVIT3awqNH7h9Mda/3DO/Rg3/5zuwfz9P3 7Tf7uGdNaR8fvfSjn/b057WjXQEA4JR6OroGjnG65tVy5WvPerTjLzev3jKYl5tX+/fltRE+Hc9r 79v+Yc96Vm/slT0dQ+mJ+TraFQAATqmno2vgGCHNq8svuhN7nnVr+cjtIT168B81r5ZDfW147xrh zvFsvNbyuRsbfPSiy1+P7Zg+enO2X3p1F5bfnlpHuwIAwCn1dHQNHKNt3lh2G17o/JSetfr07SHt 2cIbm1ero3pheO8d4dPxPH3WW1a+EJE9b87Tn/b057WjXQEA4JR6OroGjpHTvLr8Pytm+aM3Nq9e a/i8t3m10bMqtYAObl5tj+eNzbE9A/ij3Xn0057+vHa0KwAAnFJPR9fAHo8uiZoV6cuVj7ZwsOWr b498T/tidWdX35aNUe158Guttun/GUQb+/IoWNV92dn52d7a9niejnz/yj3P2n7Mxq/Ezmetbn9j nGfU194AAHA+nR1gA9ue9hwerdxew5/yhtOWX0AAANpSE8E4lr0pzatT8IbTll9AAADaUhPBaDSv TscbTlt+AQEAaEtNBKPRvAJKzHgAANpShMJo3tK82uPP9gA4lNkMAMAf2VldKjBhNM68AkrMeAAA 2lKEwmg0r4ASMx4AgLYUoTAazSugxIwHAKAtRSiMZtmbWl5EvH1lsbwBQzHjAQBoSxEKVMkbMBQz HgCAthShQJW8AUMx4wEAaEsRClTJGzCO6XPGf/wDAIBGFKFAlbwBI/hoW12+PsTh7lsAADiYIhSo kjdgBNdW1XXGa14BANCEIhSokjege7d9qtsZr38FAMDxFKFAlbwB3Zu+LxP8vOXVdPn5WvMKAIDD KUKBKnkDuufMKwAAcihCgSp5A0bgnlcAAIRQhAJV8gaMwKcNAgAQQhEKVMkbMI7/N7oy6wEAaEYR ClTJGzAUMx4AgLYUoUCVvAFDMeMBAGhLEQpUyRswFDMeAIC2FKFAlbwBQzHjAQBoSxEKVMkbMBQz HgCAthShQJW8AUMx4wEAaEsRClTJGzAUMx4AgLYUoUCVvAHjmD5n/Mc/AABoRBEKVMkbMIKPttVn z+prxl+/BQCAgylCgSp5A0ZwbVVdZ7zmFQAATShCgSp5A7p326e6nfH6VwAAHE8RClTJG9C96fsy wc9bXk2Xn681rwAAOJwiFKiSN6B7zrwCACCHIhSokjdgBO55BQBACEUoUCVvwAimu2sFJ582CABA K4pQoEregBFoXgEAEEIRClTJGzAClw0CABBCEQpUyRvQPTdsBwAghyIUqJI3oHvT7VWD0+XuCkIA ADiWIhSokjege868AgAghyIUqJI3YATueQUAQAhFKFAlb8AIrh8v+DXjfdogAACtKEKBKnkDxvH/ RldmPQAAzShCgSp5A4ZixgMA0JYiFKiSN2AoZjwAAG0pQoEqeQOGYsYDANCWIhSokjdgKGY8AABt KUKBKnkDhmLGAwDQliIUqJI3YBymOwAAzSlCgSp5A8ZhugMA0JwiFKiSN2AcpjsAAM0pQoEqeQPG YboDANCcIhSokjdgENPndP/4BwAA7ShCgSp5A7r30bb67Fl9TffrtwAAcDxFKFAlb0D3rq2q63TX vAIAoBVFKFAlb0DfbvtUt9Nd/woAgCYUoUCVvAF9m74vE/y85dV0+fla8woAgBYUoUCVvAF9c+YV AABRFKFAlbwB3XPPKwAAcihCgSp5A7o33V0rOPm0QQAAGlKEAlXyBnRP8woAgByKUKBK3oDuuWwQ AIAcilCgSt6AvrlhOwAAURShQJW8AX2bbq8anC53VxACAMDhFKFAlbwBfXPmFQAAURShQJW8Ad1z zysAAHIoQoEqeQO6d/14wa/p7tMGAQBoSBEKVMkbMIj/N7oy5QEAaEkRClTJG9A9Z14BAJBDEQpU yRvQPfe8AgAghyIUqJI3oG8+bRAAgCiKUKBK3oC+Td+XCX7e8mq6/HyteQUAQAuKUKBK3oC+OfMK AIAoilCgSt6A7n3frf3m0wZ1rgAAaEURClTJG9A9nzYIAEAORShQJW9A95x5BQBADkUoUCVvQN/c 8woAgCiKUKBK3oC++bRBAACiKEKBKnkD+ubMKwAAoihCgSp5A7p37VNdp7vOFQAArShCgSp5A7rn 0wYBAMihCAWq5A0YxO2nDQIAQCuKUKBK3oAhTJPmFQAACRShQJW8Ad1z2SAAADkUoUCVvAHdm776 VW7YDgBAAEUoUCVvQN+++1T3zauL/hUAAI0oQoEqeQO69XObq+nunlfXLwEA4HCKUKBK3oC+ffeq vj5scLpfAwAAh1OEAlXyBnTv52wr97wCAKA1RShQJW9A35x5BQBAFEUoUCVvQM/c8woAgDCKUKBK 3oC+/TSpprvprnkFAEATilCgSt6A7n33qdzzCgCAAIpQoEregO5db3L1cw2h5hUAAI0oQoEqeQN6 dr3bleYVAAAZFKFAlbwB3XPZIAAAORShQJW8AX1zw3YAAKIoQoEqeQP6Nt3e8mq63F1BCAAAh1OE AlXyBvTtp3V1ceYVAADtKUKBKnkjltAkO0t07m7PPo1yw/azRGdAQpNMdJKJTiyhSSY6yUQHqJI3 YglNsrNEZ37a1c0nD7Ye2h86S3QGJDTJRCeZ6MQSmmSik0x0gCp5I5bQJDtFdGZNqtvTrjSvaEJo kolOMtGJJTTJRCeZ6ABV8kYsoUl2iuhMN/2q/7don64nX7Ue3R86RXTGJDTJRCeZ6MQSmmSik0x0 gCp5I5bQJDtFdGbnWblskOaEJpnoJBOdWEKTTHSSiQ5QJW/EEppkZ4nOT+fq/5lX3XeuLueJzoCE JpnoJBOdWEKTTHSSiQ5QJW/EEppkZ4nO7Mwr97yiLaFJJjrJRCeW0CQTnWSiA1TJG7GEJtlZojP7 tMG7e16dZBdecJboDEhokolOMtGJJTTJRCeZ6ABL0435j75+eLFYLAMs7nlFa0KTTHSSiU4soUkm OslEB5iZpYXrtzf1bOuC2mKxHLNMLhukMaFJJjrJRCeW0CQTnWSiA8xoXlkslu9l0ryiMaFJJjrJ RCeW0CQTnWSiA8ysNq/u69nWBbXFYjlmmTSvaExokolOMtGJJTTJRCeZ6AAzu5pX7Ytqi8Xy98vs u345HIolNMlEJ5noxBKaZKKTTHSAmX3NKwAAADhIo/oYCDU9bV5ZLJbxlkYJCQAAAOZWm1cX/SuL ZeClRSoCAACAdZpXFovlurRIQgAAAPDExpXFSloAAAAAAAAAAIASn/UQaHmZpxglWA2E6IQQnXxC E2j1I59EJ4S0lmlaWK5vO8LBmTjJRAd42bRokrQaCVfLfD776eEj4sNqIEQnhOjkm5V4sx+1GBEf lm++6ISQ1k5BWktj4iQTHeA3pIs0yzQuRpn8wU0mOoE0rzJpXsVafedFJ420lkZ7JJnoAL8hXWTS vMrnD24y0Ukzi4jQhNAeSSY6+RytBdIeSSY6wG9IF5kcDuXzBzfQ7IYJopND8yrTdO+6cvaYFkPj Z9aITixHa5mktVizKeNYGiiRLjI5HArncCicw6Eoy/kiNCH8J3iy29L7Ijp5tmMhNK1Ia+Fu+4qi A5RIF5k0r5KJTj6HQ1E0r87CxImiBg+neZXJxDkR0QFKpItM2iOxHKyegsOhHNPCRWhSiU4UNXiy 5TsvNCFMnBMRHaBEusikeZXJwWosB6un4MyrNCZOMtFJ5ngglomTbLXAER1gv9l/iJNgmcbFqLnV E0guohNjNRCiE0VoApk4yUQn1uqbLzQhTJxkq1EQHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABgcNOar/Vvf6H3bvAtL91wVAAAAADs96dtnLY9ou1X178CAAAAyKd5BQAAAECsWQ/n +u31KsLbNcsHL1dubHnnFnauXI5wNs7Zg1cfuTpyAAAAAEJsNK8efb184moX6NEDtrdQWrkxqtWf 7hk2AAAAADm2z7za+Prl5tX+zb4wgP3b3FgPAAAAQIjfNK9u7dny8rq/5Rb+onm1+uqPXgsAAACA HG8582rPlndu4Y+aV9ubAgAAACDT8ZcNvvGeV79Z+WjYAAAAAOR4uXl1yfi0wY1RuWwQAAAAgA3J 3aHksQEAAABwgOQGUfLYAAAAADhGZo8oc1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFX/ACn9fsYNCmVuZHN0cmVhbQ0K ZW5kb2JqDQo3IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxNTk5 L0hlaWdodCA3OTAvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ludGVy cG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTMwNzU+Pg0Kc3RyZWFtDQp4 nOzdjW7rOA4G0L7/S2d3UWwnE9uy6B+Fos/BYNCmjkOlMtGPSHJfLwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgP/5WXPr OVcf5VgNjZO0b1w9Q+OAw+Vd+Kz2PNxX7tXz3F740KvnGbPfBmtXdUfZfyeMPj+7pUbvcpXG773/ XgeOOfa4AAAAtN2Rqpbn/NkYFrWP3Dp54ww//x86Nc7ZPsPr31n+QHnRuxzQrj96hgP32rr7+fh/ wK37bZie3+lN1R7b8KvX2u59BzzhPS1i914Hjjn2uAAAAOwaMLy6cDq0zMs9CTE0vDo/W4ve5QDD q8YJr51GDmN4dYkzLeLM8Gr3cQEAADhsNa6ujnd6Xpmwes5QvI1OP6LDq3bGPDMGad/+Wnsal0/p 8slf3rj8NnqqrTrbp/o4oPPJ2Xryewru3HiX77fVx/143np+U/3r2jpm6zy7xWw9xHKxr41f3NYt y4dYrfPjR8sbL38+t8o+sz2WP+3fiu0jAQAA6NdIdquxtyeRXT5MaBzT81iNEcRrkaY/7vhht7bX RuJ+LZ7G5ePuVrV1Y/RUW2tpn2p3G7Qf/fX25PcX3LPxLt9vWxWe/021z99TWH8xJ39xjeO3HnS3 wp6qDtzYX17/vbZ+2nPMx/FblxsAAACdGskuGhh7zrk88kO05t3H6lzR6qP3Z/mtOnczfruq0I2H 73XyVI27L/9/bcGrPzq/384/5wdO1bOKkxug57Sd1+NNG3vrgHb9/eW1z9Dzo3YBH4/buYEBAABo Wya7ZXSNRrBL0mLn+duPtfXtVsbcrfxAwScHDoeD/4Hf4+FJy9aRy/9fW/Dqj87vt57nYXXC07hl d109qzi5l0KnbfhZEy3m2PO5dePWipaLOrY9Op+iY48LAABAWygybx0QPWc0LPfX0/7Rbtxun6Gn 4M7FHs74B07VPnL3gDPnX/7/2oJXf3R+v4We8/YZjj3Pu3c8tpdCp22IbvILn8/dG3dPfmB4tdU6 rnpcAAAA2npGNyeHV40z3De8ap+5c0JVY3jV/3tcnekdmzX1FHm+4K0fndxv/c/DsSVMPbxqTHhC xQzbEueHV/3HGF4BAADcYTX4f7y64PzwavW0nWfbPf/Pm+Utywd9dazoL4lvnacdgXfv0vh69Vla nqpnCNA41e6q2/dq3D263vYyt07eeNyts7VPsjys/Rvv/E2t3rj6dc8G23r+j2223dOu2jrmYyGr O7axha56Ptsnj96rsczDjwsAAAAcdj5i1wjpX1/F1wsAAAAASMjw6tfXV/H1AgAAAGB2P2smOj+r LnmSC/ymvruEAk8gAAAAAAAAAAAAAABks/sWlcYB/pUZAAAAAO6z+68kNw5o/xPM5lcAAAAAnHR4 ePX7heEVAAAAAPc588qrl+EVAAAAAHe6cHj18plXAAAAAFxq5CuvfgAAAGCgw2EZyONn7PDqcJ3Q z05jGJuNMew0hrHZGMNOYxibDWowvKIeO41hbDbGsNMYxmZjDDuNYWw2qMHwinrsNIax2RjDTmMY m40x7DSGsdmgjNW3A398vfV+4eXAqvHOYn2DMew0hrHZGMNOYxibjTHsNIax2YAofYMx7DSGsdkY w05jGJuNMew0hrHZgCh9gzHsNIax2RjDTmMYm40x7DSGsdmAKH2DMew0hrHZGMNOYxibjTHsNIax 2YAofYMx7DSGsdkYw05jGJuNMew0hrHZgCh9gzHsNIax2RjDTmMYm40x7DSGsdmAKH2DMew0hrHZ GMNOYxibjTHsNIax2YAofYMx7DSGsdkYw05jGJuNMew0hrHZgCh9gzHsNIax2RjDTmMYm40x7DSG sdmAKH0DAACAYYRQIErfAAAAYBghFIjSNwAAABhGCAWi9A0AAACGEUKBKH0DAACAYYRQIErfAAAA YBghFIjSNwAAABhGCAWi9A0AAACGEUKBKH0DAACAYYRQIErfAAAAYBghFIjSNwAAABhGCAWi9A0A AACGEUKBKH0DAACAYYRQIErfAAAAYBghFIjSNwAAABhGCAWi9A0AAACGEUKBKH0DAACAYYRQIErf AAAAYBghFIjSNwAAABhGCAWi9A0AAACGEUKBKH0DAACAYYRQIErfAAAAYBghFIjSNwAAABhGCAWi 9A0AAACGEUKBKH0DAACAYYRQIErfAAAAYBghFIjSNwAAABhGCAWi9A0AAACGEUKBKH0DAACAYYRQ IErfAAAAYBghFIjSNwAAABhGCAWi9A0AAACGEUKBKH0DAACAYYRQIErfAAAAYBghFIjSNwAAABhG CAWi9A0AAACGEUKBKH0DAACAYYRQIErfAAAAYBghFIjSNwAAABhGCAWi9A0AAACGEUKBKH0DAACA YYRQIErfAAAAYBghFIjSNwAAABhGCAWi9A0AAACGEUKBKH0DAACAYYRQIErfAAAAYBghFIjSNwAA ABhGCAWi9A0AAACGEUKBKH0DAACAYYRQIErfAAAAYBghFIjSNwAAABhGCAWi9A0AAACGEUKBKH0D AAD4lv/Gkd//eA4hFMr4eRM94OOW9qn0DQAA4Cves4hc8hxCKNSwnD71H/AxpIqeCgAAYAzDq2cS QqGGw8Or3y8aw6vdxwIAABhgGUREk4cQQqGGM6+8ehleAQAA6RlePZYQCjVcPrzymVcAAEAeWylE OnkCIRRquHZ41X4h1k+fM8sBAAB4Z3hVUme6FDChhvveNugD2wEAgO9qRBDp5AmEUKjB8AoAAKjK 8OrhhFCowfAKAACoqh1BBJTyhFAoY/XtwMsPs1p9v/ByYNV4Z7G+AQAAjGR49XBCKBClbwAAAMPs 5g8BpTwhFIjSNwAAgGEMrxBCgSh9AwAAGKYnf8gotQmhQJS+AQAADGN4hRAKROkbAADAGJ3hQ0ap TQgFovQNAABgjP7wIaYUJoQCUfoGAAAwhuEVLyEUiNM3AACAMULhQ1KpSggFovQNAABggGjykFSq EkKBKH0DAAAYwPCKX0IoEKVvAAAAAxhe8UsIBaL0DQAAYADDK34JoUCUvgEAANztWOwQVkoSQoEo fQMAALib4RV/hFAgSt8AAADuZnjFHyEUiNI3AACAuxle8UcIBaL0DQAA4G6GV/wRQoEofQMAALjV 4cwhrJQkhAJR+gYAAHArwyveCaFAlL4BAADc6kzmkFfqEUKBKH0DAAC4leEV74RQIErfAAAAbmV4 xTshFIjSNwAAgPucDBzySj1CKBClbwAAAPcxvOKDEApE6RsAAMB9DK/4IIQCUfoGAABwH8MrPgih QJS+AQAA3Od84BBZihFCgSh9AwAAuMklaUNkKUYIBaL0DQAA4CaGVywJoUCUvgEAANzE8IolIRSI 0jcAAICbGF6xJIQCUfoGAABwE8MrloRQIErfAAAAbmJ4xZIQCkTpGwAAwB2uihoiSzFCKBClbwAA AHe4MGpILZUIoUCUvgEAANzB8IpVQigQpW8AAAB3MLxilRAKROkbAADAHQyvWCWEAlH6BgAAcAfD K1YJoUCUvgEAAFzu2pwhtVQihAJR+gYAAHA5wyu2CKFAlL4BAABczvCKLUIoEKVvAAAAlzO8YosQ CkTpGwAAwOUMr9gihAJR+gYAAHC5y3OG4FKGEApE6RsAAMC17ggZgksZQigQpW8AAADXMryiQQgF ovQNAADgWoZXNAihQJS+AQAAXMvwigYhFIjSNwAAgGsZXtEghAJR+gYAAHAtwysahFAgSt8AAAAu dFPCEFzKEEKBKH0DAAC4kOEVbUIoEKVvAAAAFzK8ok0IBaL0DQAA4EL3JQzZpQYhFIjSNwAAgAsZ XtEmhAJR+gYAAHAhwyvahFAgSt8AAAAuZHhFmxAKROkbAADAVW6NF7JLDUIoEKVvAAAAVzG8YpcQ CkTpGwAAwFUMr9glhAJR+gYAAHAVwyt2CaFQxs+b6AGNu3TeCAAAcIDhFbuEUKjh41reHU+9f7s1 72rcfrxQAACAN4ZX7BJCoYbDw6vfLwyvAACA8QZkC/GlACEUajjzyqvG8YZXAADAfQyv6CGEQg2G VwAAwHQMr+ghhEIN1w6vPt5UuDxVj8NrAQAAHsLw6uE606WACTUMHl4drhMAAOCP4RU9hFCo4cLh 1e6IW98AAAAuYXhFDyEUarj8M68at+sbAADAeWOChfhSgBAKZay+VmrrJVXL+26ds/NGAACAEMMr OgmhQJS+AQAAnGd4RSchFIjSNwAAgPMMr+gkhAJR+gYAAHCe4RWdhFAgSt8AAADOM7yikxAKROkb AADAecOChQQzOyEUiNI3AACAk0amCglmdkIoEKVvAAAAJxle0U8IBaL0DQAA4CTDK/oJoUCUvgEA AJxkeEU/IRSI0jcAAICTDK/oJ4QCUfoGAABwkuEV/YRQIErfAAAAzhgcKSSY2QmhQJS+AQAAnGF4 RYgQCkTpGwAAwBmGV4QIoUCUvgEAAJxheEWIEApE6RsAAMAZhleECKFAlL4BAACcMT5SCDFTE0KB KH0DAAA4w/CKECEUiNI3AACAw76SJ4SYqQmhQJS+AQAAHGZ4RZQQCkTpGwAAwGGGV0QJoUCUvgEA ABxmeEWUEApE6RsAAMBhhldECaFAlL4BAAAcZnhFlBAKROkbAADAYYZXRAmhQJS+AQAAHPOtMCHE TE0IBaL0DQAA4BjDKw4QQoEofQMAADjG8IoDhFAgSt8AAACOMbziACEUiNI3AACAY74YJuSYeQmh QJS+AQAAHGN4xQFCKBClbwAAAAd8N0nIMfMSQoEofQMAADjA8IpjhFAgSt8AAAAOMLziGCEUiNI3 AACAAwyvOEYIBaL0DQAA4ADDK44RQoEofQMAAIj6eoz4egEcJoQCUfoGAAAQ9fUY8fUCOEwIBaL0 DQAAIOrrMeLrBXCYEApE6RsAAEBIhgyRoQaOEUKBKH0DAAAIyZAhMtTAMUIoEKVvAAAAIRkyRIYa OEYIBaL0DQAAICRDhshQA8cIoUCUvgEAAIQkyRBJyiBKCAWi9A0AAKBfngCRpxJChFAgSt8AAAD6 5QkQeSohRAgFovQNAACgX54AkacSQoRQIErfAAAA+uUJEHkqIUQIBaL0DQAAoF+eAJGnEkKEUCBK 3wAAAPrlCRB5KiFECAWi9A0AAKBfngCRpxJChFAgSt8AAAA6pUoPqYqhnxAKROkbAABAp1TpIVUx 9BNCgSh9AwAA6JQqPaQqhn5CKBClbwAAAJ1SpYdUxdBPCAWi9A0AAKBTqvSQqhj6CaFAlL4BAAB0 SpUeUhVDPyEUiNI3AACAHgmjQ8KS2CWEAlH6BgAA0CNhdEhYEruEUCBK3wAAAHokjA4JS2KXEApE 6RsAAECPhNEhYUnsEkIhoZ81oXtFD/i4pX0qfQMAAOiRMDokLIldQiiksjt6atyx8W37gI8zR08F AACwKmF0SFgSu4RQyKPz5VU9t/cPr36/6B+LddYJAAA8XM7ckLMq2oRQyOPM9XjmlVfthza8AgAA DsiZG3JWRZsQCnl8vBrq2H23zmB4BQAAjJQzN+SsijYhFFJZ/aj2ng9sv2l4tfWB7T3aBQMAALXl zAQ5q3qsznQpYEJCSV55FZpoAQAAvMuZG3JWRZsQCjVcPrwKvZEQAADgQ87ckLMq2oRQyOPMiySv HV61H07fAAAA2tKGhrSF0SCEQk7v12bndbo66fr4emsUtnXY7sEAAABLaUND2sJoEEIhoeTzolTF AAAACaUNDWkLo0EIhYQMrwAAgKllDg2Za2OVEAo5Zf5XQbPVAwAAZJM5NGSujVVCKBClbwAAAG2Z Q0Pm2lglhAJR+gYAANCWOTRkro1VQijk5G2DAADApJInhuTlsSSEQkI+sB0AAJhX8sSQvDyWhFBI yPAKAACYV/LEkLw8loRQyOn92sx2nWarBwAASCV5YkheHktCKCT00/Tt6vQNAACgJXliSF4eS0Io EKVvAAAADckTQ/LyWBJCgSh9AwAA2JI/LuSvkA9CKOSU5B2Cq9IWBgAAfF3+uJC/Qj4IoZBW2ssz bWEAAMDX5Y8L+SvkgxAKaaW9PNMWBgAAfF3+uJC/Qj4IoZCTtw0CAAAzyh8X8lfIByEUcsp8bWau DQAA+K4p4sIURfJHCIWcMl+bmWsDAAC+aJasMEud/BJCIa20l2fawgAAgO+aJSvMUie/hFDIo+d6 zHDNZqgBAABIaJasMEud/BJCIZXG57Tn+Qj3JGUAAADZzJIVZqmTX0IoJPSz5ttF/SNVMQAAQB6z ZIVZ6uSXEApE6RsAAMDSREFholJ5CaFAnL4BAAAsTRQUJiqVlxAKxOkbAADA0kRBYaJSeQmhQJy+ AQAALE0UFCYqlZcQCsTpGwAAwNJEQWGiUnkJoUCcvgEAACxNFBQmKpWXEApZ/Sx8u6J/pCoGAADI YK6UMFe1CKGQUPILM3l5AADAeHOlhLmqRQiFhJJfmMnLAwAAxpsrJcxVLUIoJJT8wkxeHgAAMN5c KWGuahFCISefeQUAAExkupQwXcFPJoRCQskvzOTlAQAA402XEqYr+MmEUEgo+YWZvDwAAGCwGSPC jDU/lhAKOWW+NjPXBgAAjDdjRJix5scSQiGh5QdepbpUUxUDAAB83YwRYcaaH0sIBaL0DQAA4N2M EWHGmh9LCAWi9A0AAODdjBFhxpofSwiFnLxtEAAAmMKk+WDSsp9JCIWE/i7M3y+yXafZ6gEAAL5o 0nwwadnPJIRCQh/Dq1eySzVVMQAAwHdNmg8mLfuZhFBIyPAKAACYxaT5YNKyn0kIhZzex1bZrtNs 9QAAAF80aT6YtOxnEkKBKH0DAAD4NW84mLfyBxJCIaHkF2by8gAAgGHmDQfzVv5AQigklPzCTF4e AAAwzLzhYN7KH0gIhYR+1ny7qH+kKgYAAPiiecPBvJU/kBAKROkbAADAr6nDwdTFP4oQCkTpGwAA wK+pw8HUxT+KEAoJrb5tMM+bB5OUAQAAfNfsyWD2+p9DCIWc3q/Nra+/JUMNAADA182eDGav/zmE UEhoeWH+3ZLhms1QAwAA8HWzJ4PZ638OIRQSMrwCAADymz0ZzF7/cwihkNPqR10luWCTlAEAAHzX 7Mlg9vqfQwgFovQNAACgQCwosISHEEKBKH0DAAAoEAsKLOEhhFDIafVtg0lkqwcAABivQCwosISH EEIhocYHtmeQqhgAAOArCsSCAkt4CCEUEjK8AgAAkisQCwos4SGEUEjI8AoAAMisRiaosYonEEIh J595BQAApFUjE9RYxRMIoVDb7gSscUDjLhdXCQAATKVGJqixiicQQqGwjwt8dzz1/m173nVRgQAA wJRqZIIaq3gCIRQSuuozrw4Pr36/MLwCAACWKgWCSmspTAiFVH62HTtb49vdAwyvAACApUqBoNJa ChNCIaGrLkzDKwAA4HKVAkGltRQmhEJh9w2velyxAgAAIJ1Kf+xXWsuMOtOlgAk5vX/81OHr1Cuv AACAy1UKBJXWUpgQCgm9T64+vjh2nq2TGF4BAAAhxdJAseVUJYRCQoZXAABATsXSQLHlVCWEQkJX Da9e/34H8fL8Wwe0H1TfAACAxyqWBootpyohFHJ6nyZlu06z1QMAAAxTLA0UW05VQigQpW8AAMBj FUsDxZZTlRAKROkbAADwTPWiQL0VlSSEQh7v7xNc+m5t71IVAwAADFMvCtRbUUlCKBClbwAAwDPV iwL1VlSSEApE6RsAAPBM9aJAvRWVJIRCHqvvFvS2QQAAIIOSOaDkouoRQiGnzNdm5toAAICblMwB JRdVjxAKOWW+NjPXBgAA3KRqDqi6rkqEUMgp87WZuTYAAOAmVXNA1XVVIoRCTpmvzcy1AQAAN6ma A6quqxIhFHLKfG1mrg0AALhD4RBQeGllCKGQh39tEAAAyKlwCCi8tDKEUCBK3wAAgKcpHAIKL60M IRSI0jcAAOBpCoeAwksrQwgFovQNAAB4lNoJoPbqahBCgSh9AwAAHqV2Aqi9uhqEUCBK3wAAgEep nQBqr64GIRSI0jcAAOBRaieA2qurQQiFPH6avl3dP1IVAwAA3Kr8n//lF1iAEAo5vV+b2a7TbPUA AAD3Kf/nf/kFFiCEQkLLCzPVpZqqGAAA4Fbl//wvv8AChFBIyPAKAABIovyf/+UXWIAQCjml/cCr l74BAACP8YS//Z+wxtkJoUCUvgEAwH/Yu6PltnUlC6D+/5/23CrX+CiiRLNFEtgA1qr7kFGUGAKb nd4YSYdFLDL7L/IyxyWEAlX6BgAALGKR2X+RlzkuIRQyPX5gMO0+TVsPAABwk0Vm/0Ve5riEUAj0 e2Nuf5EgajEAAMBN1hn813mlgxJCIZDDKwAAoLt1Bv91XumghFAI5PAKAADobp3Bf51XOighFDJ9 /av3cv6Rth4AAOByS039S73YEQmhQJW+AQAA01tq6l/qxY5ICAWq9A0AAJjeUlP/Ui92REIoBNre mFG3atRiAACAOyw19S/1YkckhEKg7VddRd2qUYsBAAAut9rIv9rrHY4QCoH81wYBAICOVhv5V3u9 wxFCIdDTe67S/oODUYsBAAAut9rIv9rrHY4QCoF85xUAANDLgvP+gi95LEIoUKVvAADAxBac9xd8 yWMRQoEqfQMAACa24Ly/4EseixAKOR6/nn2r79oeRS0GAAC41oLz/oIveSxCKFClbwAAwKyWHfaX feFDEEKBKn0DAABmteywv+wLH4IQCjleflrQxwYBAIBmlh32l33hQxBCgSp9AwAAprTypL/ya88n hAJV+gYAAExp5Ul/5deeTwiFTD42CAAANLbypL/ya88nhEKg3xvz5xdp92naegAAgPMWH/MXf/nh hFAI9HR49R12q0YtBgAAuMTiY/7iLz+cEAqBHF4BAAAtmfHtQDIhFDI9Hlul3adp6wEAAE4y49uB ZEIoUKVvAADATAz43zYhmxAKVOkbAAAwEwP+t03IJoRCpq+N3iv6T9RiAACAkwz43zYhmxAKgcJv zPDlAQAAx5nuf9iHZEIoBAq/McOXBwAAHGe6/2EfkgmhECj8xgxfHgAAcJzp/od9SCaEQibfeQUA ANzNaP/IbsQSQiFQ+I0ZvjwAAOAgo/0juxFLCIVA4Tdm+PIAAICDjPaP7EYsIRQyJd+byWsDAACO M9o/shuxhFAItP3CqyO36p9PfvmE4w8+/m79NQEAAFnM9U9sSCwhFObwdC9vb+2XTzj+4P4jAADA cMz1T2xILCEUAn1wYzq8AgAASsz1T2xILCEUAjm8AgAAbmWo37InsYRQCPTBd15deHj1tIA/fxYA ADAcQ/2WPYklhMIcGr/z6ohzLwgAALiRgX3LnrR3MF0KmDCHxodX5xYLAAD0ZKJ/ybbEEkIhU/WQ 2eEVAABwkIn+JdsSSwiFQB+cFzm8AgAADjLRv2RbYgmhEOiz86KX79R6+vXLJxx8sLQYAAAgk3H+ HTsTSwiFQOFvdopaDAAAUGKcf8fOxBJCIVPyf1ghbT0AAMBxxvl37EwsIRSo0jcAAGBQZvkdNieW EApU6RsAADAos/w++5NJCIUcX7t6r+4/UYsBAACOM8vvsz+ZhFDIl3afpq0HAAA4wiD/J1uUSQiF ZGnvufoRuCQAAOBPBvk/2aJMQihkyjy2+hG7MAAAYIdB/k+2KJMQCmmSj61+hC8PAADYMsUfYZcy CaEQZYhbcohFAgAAj0zxR9ilTEIo5PBfGwQAAG5iij/CLmUSQoEqfQMAAMZihD/IRmUSQoEqfQMA AMZihD/IRmUSQoEqfQMAAMZihD/IRmUSQoEqfQMAAAZifj/OXmUSQoEqfQMAAAZifj/OXmUSQoEq fQMAAAZifj/OXmUSQiHH167eq/tP1GIAAIAdhvcS25VJCIVMj/dm2n2ath4AAOAdw3uJ7cokhEKg 7Y0ZdatGLQYAANhheK+yY4GEUAjk8AoAADjP5P4BmxZICIVMsV949a1vAADAIEzuH7BpgYRQoErf AACAfMb2z9i3QEIoUKVvAABAPmP7Z+xbICEUMj1+YDDtPk1bDwAAsGVs/4x9CySEQqDfG3P7iwRR iwEAALbM7B+zdYGEUAjk8AoAADjDzP4xWxdICIVADq8AAIAzzOwfs3WBhFDI9PWv3sv5R9p6AACA Rwb2M+xeICEUqNI3AAAgmYH9DLsXSAgFqvQNAACIZVo/yQYGEkIh09dG7xX9J2oxAADAI9P6STYw kBAKgcJvzPDlAQDAykzrJ9nAQEIoBAq/McOXBwAAyzKqn2cPAwmhECj8xgxfHgAALMuofp49DCSE Qo7t91z5zisAAOAgc/pV7GQaIRSo0jcAACCQOf0qdjKNEApU6RsAAJDGkH4hm5lGCIVA2xsz6laN WgwAAPDtvOVSNjONEApRfOcVAABQZUK/lv1MI4RCoPAbM3x5AACwGhP6texnGiEUqNI3AAAgh/H8 crY0jRAKmWI/M/itbwAAQBLj+eVsaRohFAL5wnYAAOAIs/kd7GoaIRQCObwCAACOMJvfwa6mEUIh kMMrAADgTwbzm9jYNEIoZPKdVwAAwD6D+U1sbBohFKjSNwAAoDtT+X3sbRohFKjSNwAAoDtT+X3s bRohFDL52CAAAPCOkfxWtjeNEAqBfGE7AADwjnn8bnY4jRAKgRxeAQAA75jHG7DJUYRQCOTwCgAA eMkw3oZ9jiKEQibfeQUAAGwZxtuwz1GEUKBK3wAAgPb+N4abxJux1VGEUKBK3wAAgMbM4I3Z8ChC KGT62ui9ov9ELQYAAKZnAG/PnkcRQiFQ+I0ZvjwAAJiMAbw9ex5FCIVA4Tdm+PIAAGAmpu8ubHsU IRQChd+Y4csDAIBpGL17sfNRhFDI5DuvAABgcebujmx+FCEUAoXfmOHLAwCAOZi7O7L5UYRQCPTZ jfnn27RePuH4gyeXBwAAHGfo7sv+RxFCIVP13nx6/vaPv3zC8QfPrA0AACgxcXfnEkQRQiHQ9guv /rxV7zu8+vNnAQAAFzJuJ3AVogihMAeHVwAAMAGzdggXIooQCnO4/PDKd14BAEB7Zu0crkUOIRSi vPvi9CN/cOf/fPeEdw8+reHlIv/055oBAIBHhugoLkcDB9OlgAk5dg6gqh/lu/Bjg3/+VQAAwHmm 7DSuSA4hFHI4vAIAgDUZsQO5KDmEUMixc1rl8AoAACZmxA7kouQQQiHHmcOr738/LPzu73z5hIMP lhYDAAAcZL7O5LrkEEIhx8nDq2aiFgMAAEMzXMdyaXIIoRDl3ZugOi5pK209AAAwKJN1MlcnhxAK VOkbAABwCZN1MlcnhxAKVOkbAABwnrE6nAuUQwgFqvQNAAA4yUydzzXKIYQCVfoGAACcZKbO5xrl EEKBKn0DAADOMFAPwWXKIYQCVfoGAAB8zDQ9ClcqhxAKVOkbAADwMdP0KFypHEIoUKVvAADAZ4zS Y3G9QgihQJW+AQAAnzFKj8X1CiGEAlX6BgAAfMAcPRyXLIQQClTpGwAAUGWIHpGrFkIIBar0DQAA qDJEj8hVCyGEAlX6BgAAlJigB+XChRBCgSp9AwAASkzQg3LhQgihQJW+AQAAxxmfx+XahRBCgSp9 AwAAjjM+j8u1CyGEAlX6BgAAHGR2HprLF0IIBar0DQAAOMjsPDSXL4QQClTpGwAAcITBeXSuYAgh FKjSNwAA4E+m5gm4iCGEUKBK3wAAgD+ZmifgIoYQQoEqfQMAAPYZmefgOoYQQoEqfQMAAPYZmafh UiYQQoEqfQMAAHaYl2fiaiYQQoEqfQMAAHaYl2fiaiYQQoEqfQMAAN4xLE/GBU0ghAJV+gYAALxk Up6Pa5pACAWq9A0AANgyJk/JZU0ghAJV+gYAAGwZk6fksiYQQoEqfQMAAJ6YkWflyiYQQoEqfQMA AJ6YkWflyiYQQoEqfQMAAB4ZkCfm4iYQQoEqfQMAAB4ZkCfm4iYQQoEqfQMAAH6Zjufm+iYQQoEq fQMAAH6Zjufm+iYQQoEqfQMAAH4YjafnEicQQoEqfQMAAH4YjVfgKncnhAJV+gYAAHw701iGC92d EApU6RsAAPDtTGMZLnR3QihQpW8AAICheB2udXdCKFClbwAAgKF4Ha51d0IoUKVvAACwOBPxUlzu 7oRQoErfAABgcSbipbjc3QmhQJW+AQDAyozDq3HFuxNCgSp9AwCAlRmHV+OKdyeEAlX6BgAAyzIL L8hF704IBar0DQAAlmUWXpPr3pcQClTpGwAArMkgvCyXvi8hFKjSNwAAWJNBeFkufV9CKFClbwAA sCBT8Mpc/b6EUKBK3wAAYEGm4JW5+n0JoUCVvgEAwGqMwItTAH0JoUCVvgEAwFLMv6iBvoRQoErf AABgKeZfvpVBV0IoUKVvAACwDsMvP1RCR0IoUKVvAACwDsMvP1RCR0IoUKVvAACwCJMvvxRDR0Io UKVvAACwCJMvvxRDR0IoUKVvAACwAmMvj9RDR0IoTOPrwfEn7P+p4w8CAMBkjL08Ug8dCaEwh6d7 eXtrv3zC/p8qnWgBAMBMzLw8URIdCaEwB4dXAABwITMvT5RER0IozOHyw6uXT3j3lwMAwEwMvGyp io6EUJiDwysAALiKgZeXFEYvQijM4drDq+0vnp52xLkXBAAAfZhkeUdtXO5guhQwYQ6ND6/OLRYA AHKZdnlHbfQihMIcLjy8+vOIW98AAGBWRl12KI9ehFCYw7XvvNp55N2DAAAwAaMuO5RHL0IoTOPl e6Wefv3yCTsfInZ4BQDAOsy57FMhvQihQJW+AQDAfAy5/EmR9CKEAlX6BgAA8zHk8idF0osQClTp GwAATMaEyxHqpBchFKjSNwAAmIwJlyPUSS9CKFClbwAAMBPjLQcplV6EUKBK3wAAYCbGWw5SKr0I oUCVvgEAwDTMtpQomC6EUKBK3wAAYA4GW6rUTBdCKFClbwAAMAeDLVVqpgshFKjSNwAAmICplg8o my6EUKBK3wAAYAKmWj6gbLoQQoEqfQMAgNEZafmMyulCCAWq9A0AAIZmnuVjiqcLIRSo0jcAABia eZaPKZ4uhFCgSt8AAGBchlnOUD9dCKFAlb4BAMCgTLKcpIS6EEKBKn0DAIARGWM5TxV1IYQCVfoG AADDMcNyCYXUhRAKVOkbAAAMxwzLVdRSe0IoUKVvAAAwFgMsF1JO7QmhQJW+AQDAWAywXEg5tSeE AlX6BgAAAzG9ci0V1Z4QClTpGwAAjMLoyuUUVXtCKFClbwAAMAqjK5dTVO0JoUCVvgEAwBDMrdxB XbUnhAJV+gYAAPkMrdxEabUnhAJV+gYAAPkMrdxEabUnhAJV+gYAAOFMrNxHdbUnhAJV+gYAAOFM rNxHdbUnhAJV+gYAAMmMq9xNjTUmhAJV+gYAALHMqjSgzBoTQoEqfQMAgFhmVRpQZo0JoUCVvgEA QCaDKm2otMaEUKBK3wAAIJAplWYUW2NCKFClbwAAEMiUSjOKrTEhFKjSNwAASGNEpSX11pgQClTp GwAApDGi0pJ6a0wIBar0DQAAophPaUzJNSaEAlX6BgAAOQyntKfqGhNCgSp9AwCAHIZT2lN1jQmh QJW+AQBACJMpvai9loRQoErfAAAggbGUjpRfS0IoUKVvAACQwFhKR8qvJSEUqNI3AADozkxKXyqw JSEUqNI3AADoy0BKd4qwJSEUqNI3AADoy0BKd4qwJSEUqNI3AADoyDRKAnXYkhAKVOkbAAD0YhQl hFJsSQgFqvQNAAB6MYoSQim2JIQCVfoGAABdmEOJoiCbEUKBKn0DAID2DKGkUZPNCKFAlb4BAEBj JlACKctmhFCgSt8AAKAxEyiBlGUzQihQpW8AANCS8ZNMKrMZIRSo0jcAAGjG7EksxdmMEApU6RsA ALRh8CSZ+mxGCAWq9A0AABowdRJOiTYjhAJV+gYAAA2YOgmnRJsRQoEqfQMAgLsZORmCQm1DCAWq 9A0AAG5l3mQUarUNIRSo0jcAALjJ/yZNwyYDUa5tCKFAlb4BAMAdjJkMR9G2IYTCNL4eHH/C8Qcf f/fyxQMAsDgzJiNSt20IoTCHp3t5e2u/fMLxB/cfAQCAMwyYDErptiGEwhwuPLza/4PvngYAAJ8x XTIu1duGEApzcHgFAMCIjJYMTQG3IYTCHBxeAQAwHHMlo1PDbQihMIebDq/eHWcd8fFrAQBgBQZG 5qCSzziYLgVMmMMdh1fv+oO+AQDAGf8bJ02UTEMxNyCEwhwuP7zaaQ76BgAAHzNLMhkl3YAQCnO4 9vBqvzPoGwAAfMYgyXxUdQNCKEzj5ceBn3798glPD/754WJ9AwCAKh8VZFYKuwEhFKjSNwAAKDE/ MjHl3YAQClTpGwAAHGd4ZG4qvAEhFKjSNwAAOMJHBVmBIm9ACAWq9A0AAP5kZmQdqv1uQihQpW8A ALDDG65YjYK/mxAKVOkbAAC8Y1RkQcr+bkIoUKVvAACw5Q1XLEvl300IBar0DQAAHjm2YnHq/25C KFClbwAA8MtsCO6CuwmhQJW+AQDAtzdcwf9zI9xNCAWq9A0AAIyE8MgdcSshFKjSNwAAlvXzbivz IDxxU9xKCAWq9A0AgDUZA+Edd8ethFCgSt8AAFiNd1vBPjfIrYRQoErfAABYiukP6EsIBar0DQCA RXjDFZBACAWq9A0AgBUY+oAQQihQpW8AAMzNG66AKEIoUKVvAABMzKwHpBFCgSp9AwBgSt5wBWQS QoEqfQMAYD5GPCCWEApU6RsAADPxhisgnBAKVOkbAADTMNkB+YRQoErfAACYgDdcAaMQQoEqfQMA YHQGOmAgQihQpW8AAAzNNAeMRQgFqvQNAIBB+aggMCIhFKjSNwAARmSIAwYlhAJV+gYAwFi84QoY mhAKVOkbAAADMbsBoxNCgSp9AwBgCN5wBcxBCAWq9A0AgHxGNmAaQihQpW8AAMT6ebeVeQ2YiRAK VOkbAACBnFkBsxJCgSp9AwAgjQENmJgQClTpGwAAObzhCpieEApU6RsAAAkcWwGLEEKBKn0DAKAv x1bAUoRQoErfAADown9JEFiTEApU6RsAAC05swIWJ4QCVfoGAMDdfg+sTF4AQihQpW8AANzBgRXA S0IoUKVvAABc4vG0yoQF8I4QClTpGwAAn3FaBfABIRSo0jcAAI5zWgVwkhAKVOkbAAA7vL0K4FpC KFClbwAAfG8OqZxWAdxECAWq9A0AmnE4QGPvSk4dAnQkhAJV+gYANzl+OOAYgTOcRwGMRQgFqvQN AK51ybmBIwh2KA+AoQmhQJW+AcB5d58kOKzg+6JzUQC6E0KBKn0DgI/1OkxwlrUUFxpgMkIoUKVv AFCVdphw7Zcdlb7i2/cs3cd+AsxKCAWq9A0AjhvoMKHj0ZOzrDPsG8D0hFCgSt+gDZVGM4rtDs4T to5XmrdmHWRz3tHWaEOl0YxiA6r0DdpQaTSj2K7lPOGdM5XmIOuXrThCW6MNlUYzig2o0jdoQ6XR jGK7hPOEP11VaXe8Kev813bdffUVWIm2RhsqjWYUG1Clb9CGSqMZxXaGI4Xjbqq0qEOny/9yBfYZ bY02VBrNKDagSt+gDZVGM4qtyue2PrNspR05NGv/Vq65LVtsNKbSaEaxAVX6Bm2oNJpRbEc4TzhP pW0pqpsoNtpQaTSj2IAqfYM2VBrNKLYtb4C5g0qjGcVGGyqNZhQbUKVv0IZKoxnF9n3Pd4DzRKXR jGKjDZVGM4oN2Pp68PJ32y+JBak0mlmt2HyzUC+rVRodKTbaUGk0o9iAJ09tYdsl9A3aUGk0M1+x tfnvylE1X6URS7HRhkqjGcUGPHF4RQiVRjMJxbZ/3FT9H5kSKo1FKDbaUGk0o9iAJw6vCKHSaKZU bNeeMjluWoq2RjOKjTZUGs0oNuCJwytCqLRL3HTSsvL/4GPaGs0oNtpQaTSj2IAnRw6vAAAAoJmG mRgYwNdfh1cAAAAA0IvDKwAAAABiObwCAAAAIJlPFgMAAAAAAAAAAFzFO7K4yfbDqttKU36cdLyu FBtnqDTaU2zc6utf2wdfPrPTYhmbf0OB8758Fxb32P5L9PS77x6E447XlWLjDJVGe0/nCU+/9e5B OG5bMyqNO/g3FLiEFsEdtv8A+ReKBoxDtKHSaMDhFXdzeEUbL2tGsQFVWgT3cXhFY44UaEOlcben clJsXM55As0oNuASWgT3cXhFY44UuNX/fwmH8wRu5/CKu3396/fBp+e8exCO+y0kxQacoUVwH4dX tGQcohnHpNxq280UG5c7XlQqjZMez6y+FRvwKS2C+zi8ohnFRksGb27l8Ir2tDXu46QUuIQWwX2c J9DGfiEpNi5n8OY+Xxvfio37qTTu4/AKuIQWwX0cXtHAtmwUG5czeNOFd15xH22NZhQbcJWn/+8e XGX7D9C20pQfZ7x8i8K3YuMGx4tKpXEVxcattDWaUWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAwCK+/nXk+Zf80Kv+qse/cP8XXfT96QAAAACjezpd+fOw5fxpzK3nOSFnVr9ClgEA AAAwqO3pyv55i8OrkpBlAAAAAAxq//Bq+3HC0u/u/7ing6adzy1un/Du5+5/bPDlpyPPPPhu5b+P /PnTAQAAANixc3h18HTozwff/biXJ1Hv/tT+k0u/uPbB/Z94fGcAAAAA2Pr48OrdX7J9x9H+M989 +Oefevk3HDy8Or6eD1Z+/O8EAAAAYN/+4dWj7fO3v/sdfHj1uOCXL+HWw6uXPx0AAACAfQffebX/ u6McXu3/6A/WcP7lAAAAALDj6SDls2Oinb9k58c1Prw6efp0x4MAAAAA7Hv5ubnt7z4+8vS735vT mMzDq5cv5+SD+zuzffLLTQYAAACgpf3zGac3AAAAAHTk8AoAAACAQAc/Fuf8CgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 4P/ag0MCAAAAAEH/X3vDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAHAQPQbGtDQplbmRzdHJlYW0NCmVuZG9iag0KOCAwIG9iag0KPDwvVHlw ZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMS9CYXNlRm9udC9BcmlhbC9FbmNvZGluZy9X aW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgOSAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFy IDEyNi9XaWR0aHMgMzggMCBSPj4NCmVuZG9iag0KOSAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3Jp cHRvci9Gb250TmFtZS9BcmlhbC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA5MDUvRGVz Y2VudCAtMjEwL0NhcEhlaWdodCA3MjgvQXZnV2lkdGggNDQxL01heFdpZHRoIDI2NjUvRm9udFdl aWdodCA0MDAvWEhlaWdodCAyNTAvTGVhZGluZyAzMy9TdGVtViA0NC9Gb250QkJveFsgLTY2NSAt MjEwIDIwMDAgNzI4XSA+Pg0KZW5kb2JqDQoxMCAwIG9iag0KPDwvVGl0bGUoUG93ZXJQb2ludCBQ cmVzZW50YXRpb24pIC9BdXRob3IoTWljaGFlbCBSYW1hbGhvIFwobXJhbWFsaG9cKSkgL0NyZWF0 aW9uRGF0ZShEOjIwMTQxMDIxMTM1MjMzLTA0JzAwJykgL01vZERhdGUoRDoyMDE0MTAyMTEzNTIz My0wNCcwMCcpIC9Qcm9kdWNlcij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAAUABvAHcAZQByAFAA bwBpAG4AdACuACAAMgAwADEAMCkgL0NyZWF0b3Io/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAFAA bwB3AGUAcgBQAG8AaQBuAHQArgAgADIAMAAxADApID4+DQplbmRvYmoNCjE3IDAgb2JqDQo8PC9U eXBlL09ialN0bS9OIDI2L0ZpcnN0IDE4Ny9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDU1NT4+ DQpzdHJlYW0NCnicpVVLa+MwEL4X+h/m2D3JI9mSBaVQti1dQkOIA3sIe3ATNTF1rOAq0P77HVnO o9R1dhMIHo1mvnlrgglEgCkkCKgBMQZOvFLAEbggTgBPE+AchJDAYxA6BZ5ALEmuCMaBS0gkqWmQ JOApSIKLCJTQIDgojSAQ0liQCdBRAmRWJ6SSAEZIrCKqSCrJP1mgGBBTuqSQRMKBXGBMaKSfVBQk 6amIw/U1G3nlCMYsY9k6r9jkY21Y5urNzN2XZsVGCxCNfADRzc3lxWfIQ7HY1Ibdlu7qB3zBDqaA f2Bn4gQ474VPzLt7tu9dQNELPJZpvINQ1wJk1OUlOTU83kDOq408K0W1T1H2pZienKL6LkWa74B+ xC6gPtmjPlrUY1XB/YzTg+spC/YPdt9k8vOj5P/lEfsfQx8y7kKK3oHBkx+F+HZicNuLrCzmptur 1/BruCHNJPg93BAMhAcSBxIAYfjbkfQrtyEBIEQgASACICT/NciDmCa1MWNrHRvb0jzla79+ffij vDZVI/WLuGnltC2Mt7eTDqlEA/MB2Jp+IFuVdYYN/ee+mu+ZbTUzM3Ps0eRzU4ezx2zPv6qyqEy2 zH2E/uK2Igu5K2zV8rUrXnI6NNxvW78+W/vK7uxss6KYmpu3pTHOB+nYUz6r7QH/c0nfA/6uyEu7 OLgIXdvrBj+ktqjzVbvo2lyHm9Xb1P+ftmX21//WXdHVXRWI/tRd3tPddgQvL/4CDBMV6g0KZW5k c3RyZWFtDQplbmRvYmoNCjM4IDAgb2JqDQpbIDI3OCAwIDAgMCAwIDg4OSAwIDAgMzMzIDMzMyAw IDAgMjc4IDAgMjc4IDAgNTU2IDU1NiA1NTYgMCA1NTYgNTU2IDAgMCAwIDAgMCAwIDAgMCAwIDAg MCA2NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSAwIDcyMiAyNzggMCAwIDU1NiA4MzMgNzIyIDc3OCA2 NjcgNzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgMCAwIDAgNjExIDAgMCAwIDAgMCAwIDU1NiA1NTYg NTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDAgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgNTU2 IDMzMyA1MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAgNTAwIDAgMCAwIDU4NF0gDQplbmRvYmoN CjM5IDAgb2JqDQo8PC9UeXBlL1hSZWYvU2l6ZSAzOS9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5m byAxMCAwIFIvSURbPEI1RDRCMTk4ODA5NjcyNEU4REIxRDlGNjlDRTJEQjUyPjxCNUQ0QjE5ODgw OTY3MjRFOERCMUQ5RjY5Q0UyREI1Mj5dIC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEyND4+ DQpzdHJlYW0NCnicNc47EoJQDIXhXEBAQeWlwE5o3IcrYAH0LIrCwqW4AB9jQ0kJ1/ySIt+cmSQT EVvzbGxPRX70cFPMQwkv0CnDqDzvyuuqvBsRR6+coYQKTvAfqe3Cp12TAQdc8MCHDQQQwg62EEME ezjCARJIIYMCcvvSdxJZAHsdEOQNCmVuZHN0cmVhbQ0KZW5kb2JqDQp4cmVmDQowIDQwDQowMDAw MDAwMDExIDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAwMDEyNSAwMDAwMCBuDQow MDAwMDAwMTgxIDAwMDAwIG4NCjAwMDAwMDA0NzMgMDAwMDAgbg0KMDAwMDAwMjEwOSAwMDAwMCBu DQowMDAwMDAyMTYyIDAwMDAwIG4NCjAwMDAwNDU1NTEgMDAwMDAgbg0KMDAwMDA1ODgwOSAwMDAw MCBuDQowMDAwMDU4OTY4IDAwMDAwIG4NCjAwMDAwNTkxOTIgMDAwMDAgbg0KMDAwMDAwMDAxMiA2 NTUzNSBmDQowMDAwMDAwMDEzIDY1NTM1IGYNCjAwMDAwMDAwMTQgNjU1MzUgZg0KMDAwMDAwMDAx NSA2NTUzNSBmDQowMDAwMDAwMDE2IDY1NTM1IGYNCjAwMDAwMDAwMTcgNjU1MzUgZg0KMDAwMDAw MDAxOCA2NTUzNSBmDQowMDAwMDAwMDE5IDY1NTM1IGYNCjAwMDAwMDAwMjAgNjU1MzUgZg0KMDAw MDAwMDAyMSA2NTUzNSBmDQowMDAwMDAwMDIyIDY1NTM1IGYNCjAwMDAwMDAwMjMgNjU1MzUgZg0K MDAwMDAwMDAyNCA2NTUzNSBmDQowMDAwMDAwMDI1IDY1NTM1IGYNCjAwMDAwMDAwMjYgNjU1MzUg Zg0KMDAwMDAwMDAyNyA2NTUzNSBmDQowMDAwMDAwMDI4IDY1NTM1IGYNCjAwMDAwMDAwMjkgNjU1 MzUgZg0KMDAwMDAwMDAzMCA2NTUzNSBmDQowMDAwMDAwMDMxIDY1NTM1IGYNCjAwMDAwMDAwMzIg NjU1MzUgZg0KMDAwMDAwMDAzMyA2NTUzNSBmDQowMDAwMDAwMDM0IDY1NTM1IGYNCjAwMDAwMDAw MzUgNjU1MzUgZg0KMDAwMDAwMDAzNiA2NTUzNSBmDQowMDAwMDAwMDM3IDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDA2MDE1MSAwMDAwMCBuDQowMDAwMDYwNDc4IDAwMDAwIG4NCnRy YWlsZXINCjw8L1NpemUgNDAvUm9vdCAxIDAgUi9JbmZvIDEwIDAgUi9JRFs8QjVENEIxOTg4MDk2 NzI0RThEQjFEOUY2OUNFMkRCNTI+PEI1RDRCMTk4ODA5NjcyNEU4REIxRDlGNjlDRTJEQjUyPl0g Pj4NCnN0YXJ0eHJlZg0KNjA4MDMNCiUlRU9GDQp4cmVmDQowIDANCnRyYWlsZXINCjw8L1NpemUg NDAvUm9vdCAxIDAgUi9JbmZvIDEwIDAgUi9JRFs8QjVENEIxOTg4MDk2NzI0RThEQjFEOUY2OUNF MkRCNTI+PEI1RDRCMTk4ODA5NjcyNEU4REIxRDlGNjlDRTJEQjUyPl0gL1ByZXYgNjA4MDMvWFJl ZlN0bSA2MDQ3OD4+DQpzdGFydHhyZWYNCjYxNzYwDQolJUVPRg== --_002_D21571530BF9644D9A443D6BD95B910327105C5Exmbrcdx12ciscoc_-- From nobody Tue Oct 21 13:09:14 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5756A1A6F0E for ; Tue, 21 Oct 2014 13:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_7_Gbgt-ru5 for ; Tue, 21 Oct 2014 13:08:37 -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 DEF701A1AED for ; Tue, 21 Oct 2014 13:08:04 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Xgfis-00024f-Lt; Tue, 21 Oct 2014 22:08:02 +0200 Received: from 36.80-202-170.nextgentel.com ([80.202.170.36] helo=bilby.lan) by mail-mx6.uio.no with esmtpsa (SSLv3:AES128-SHA:128) user davihay (Exim 4.80.1) (envelope-from ) id 1Xgfir-0006XX-Co; Tue, 21 Oct 2014 22:08:02 +0200 Date: Tue, 21 Oct 2014 22:07:58 +0200 From: David hayes To: "Michael Ramalho (mramalho)" Message-ID: <20141021220758.35d2979e@bilby.lan> In-Reply-To: References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> <20141021173659.44ecd880@hayesd-laptop> Organization: University of Oslo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-mageia-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 7 sum msgs/h 1 total rcpts 1534 max rcpts/h 38 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: F9FDAC9C91FEF3BCF15B479D2FCA4CE9FD22AE67 X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 80.202.170.36 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 1 total 85 max/h 4 blacklist 0 greylist 1 ratelimit 0 X-UiOonly: 8CBA50F0BBB75B3BB06D2B28BA9D4A5117EFED4A Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/_vALBtlIHU6RPixjKlOsJ-MjvHM Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , Mirja =?UTF-8?B?S8O8aGxld2luZA==?= , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 20:08:50 -0000 Hi Michael, Thank you for your comments and suggestions, and your interest in skewness. Thank you also for your illustrative figure. It is probably good to note that although we talk about skewness, the mechanism uses an estimate of skewness. It is not exactly the same (much easier to calculate), but it does retain the properties that we want for the mechanism. One of my points I didn't explain clearly and lead you astray (sorry). I've clarified it below and added some comments. Thank you again for your interest. David On Tue, 21 Oct 2014 18:19:22 +0000 "Michael Ramalho (mramalho)" wrote: > David/Mirja, >=20 > Thank you both for this thread. >=20 > This is the first time I recall that someone on the RMCAT list > mentioned that an asymmetrical one way delay pdf (i.e., not assuming > a symmetric smoothed delayed histogram in our discrete time work) > could be used for some useful grouping or congestion purpose. >=20 > My only comment is in the thread below that mentions skewness. My > comments are prefaced with "MAR:". >=20 > Michael Ramalho, Ph.D. >=20 > -----Original Message----- > From: rmcat [mailto:rmcat-bounces@ietf.org] On Behalf Of David Hayes > Sent: Tuesday, October 21, 2014 11:37 AM > To: Mirja K=C3=BChlewind > Cc: rmcat@ietf.org; Simone Ferlin-Oliveira; Michael Welzl Welzl > Subject: Re: [rmcat] Fw: New Version Notification for > draft-hayes-rmcat-sbd-00.txt >=20 > Hi Mirja, >=20 > Thank you for going through this and giving your comments and > questions! >=20 > I have answered your questions inline. >=20 > Regards, >=20 > David >=20 > On Tue, 21 Oct 2014 11:22:09 +0200 > Mirja K=C3=BChlewind wrote: >=20 > > Hi David, hi all, > >=20 >=20 > **** ... SNIP ... **** >=20 > > 4) Can you also explain with which (network) effect you have > > skewness? Is this really an effect in real systems that gives you > > valuable information? >=20 > OWD skewness (in an abstract way) is a function of the load at the > bottleneck and the traffic dynamics. When a queue becomes congested, > the queue distribution becomes skewed toward the back of the queue > (At extreme loads the dynamic changes again). It is important in the > algorithm for a number of reasons: 1. If there is no congestion along > the path, all of the delay statistics are too noisy to be useful for > grouping flows (there is no bottleneck!). Skewness is used to > determine whether a flow is experiencing congestion -- or to put it > another way that the statistics will be reliable for grouping flows. >=20 > Other possible metrics could be: > - magnitude of delay (but we do not know how long the queue is > at the bottleneck and what the OWD_min is) > - loss (loss can be caused by other factors, and may be to > rare) > - ECN (this will be good in the future, but is not reliable > now - the bottleneck may not be ECN enabled) > - etc >=20 > Skewness was found to be a reliable congestion indicator that > did not require any prior knowledge of queuing along the path. >=20 > MAR: I have attached a slide that shows the delay of one VoIP flow > when competing with 10 long-lived TCP flows in a bottleneck link of > 1.024 Mbps. The VoIP flow is 96 kbps CBR and the TCPs have no > propagation delay OTHER than the bottleneck queue (i.e., the measured > RTT inside a given TCP is essentially a moving average of the > bottleneck queue delay - so the dynamics of the TCPs are primarily a > function the bottleneck queue delay evolution in time). The queue > length was set so as to equal 500 ms at the link service rate. As > there are more and more competing TCPs, the resultant smoothed > histogram (bottom graph) has increasingly shorter tails in the > direction toward 0 ms (i.e., modes and mean nearer to queue delay > max), whereas a histogram from a minimally utilized system will > normally have a tail of the delays away from 0 (with mean and only > mode near 0 ms). >=20 > MAR: So clearly competing with more sources that demand queue > overflow for their congestion control will affect the observed > skewness - with more "congestion" (I desire a better definition of > that term) resulting in "tail skewness toward zero" and less variance > about the mean (of the delay histogram). >=20 > MAR: If all competing flows are RMCAT flows, we expect them to > oscillate about some equilibrium queue delay (hopefully some small > amount) and thus should expect a "symmetric" distribution about this > equilibrium (mean) value (assuming the queue never drains > completely). When there are small periods of time with "no > instantaneous congestion" (the queue drains every so often), there is > yet again some bias toward the minimum OWD (and another mode in the > distribution near zero queue delay). >=20 Our experiments to date have been with cross traffic. It will be interesting to look at this in more detail when RMCAT's congestion control mechanism is clear. > MAR: Of course, if there are multiple bottlenecks - each experiencing > some congestion - you can expect a convolution of the distributions > resulting in multiple modes (i.e., multiple local maxima in the OWD > histogram). So I am doubtful that this technique could be used for > such cases - but I am listening here if you have analytical > understanding counter to my intuition (that happens!). I agree that the result of series bottlenecks would result in a convolution of the distributions of the bottlenecks. However, bottlenecks in series where the flows traversing them are not disjoint are beyond what this mechanism can do. I mentioned this with an example when I presented some results at the London meeting, where the comment was that this would be very rare in the current Internet topology anyway. But back to the basics of the mechanism: We use estimates of summary shape metrics to group flows sharing common bottlenecks. Detailed distributions although interesting and useful for the analysis are not very practical for the mechanism itself. >=20 > MAR: Again, I have not thought of using such a metric ... but perhaps > high skewness about a mean in a cluster of individual OWD data points > near to the highest delay for the queue could signal such a > congestion by non-delay adaptive sources. And I think in this case a > lower variance might indicate "more competing sources" (similar to my > multiple TCP experiment). >=20 > 2. Two similar bottlenecks with similar traffic but different > loads can exhibit a similar variance, but will have a > different skewness. This helps to distinguish this case. >=20 In this hypothetical example, I was meaning to describe two bottlenecks with disjoint sets of flows traversing each, not two bottlenecks in series. Sorry for the misunderstanding. The idea was to make the point that a finite queue can exhibit the same variance for two different loads, but that the skewness will generally be different at those same loads. I suppose the real point here is that having different "views" of the distribution of delays at the bottleneck (including frequency) enables the mechanism to better handle the noise in each measure when grouping. > MAR: Since the two "similar bottlenecks" (i.e., similar service > rates) could have differing buffer lengths in front of them (i.e., > the maximum delay of the two individual bottlenecks could be very > different), I don't see how you can use this technique to > differentiate between them. It looks like you assumed the two > bottlenecks had similar worst-cast queuing delays (a poor assumption > because one of the bottleneck links is often the access link with a > typically larger worst-case delay). >=20 > MAR: For two bottlenecks each having traffic that demands queue > overflow for their congestion control (e.g., TCP) I would expect the > convolution of the individual modes. If the mean delay of both were > sufficiently different, one might be able to differentiate the > skewness of the individual modes for grouping purposes. Would be a > nice Masters project to investigate (got a student in mind?). >=20 > >=20 > > 5) If you look at the variance (and use the max) you might want to=20 > > apply some kind of filtering first e.g. to filter out single out=20 > > liners (due to some processing delays). >=20 > This is a good point, especially the further from the network > interface measurements are made. Min would be a better option in > terms of noise, but (in theory) Min is load ambiguous (see 2. above) > at similar loads to where skewness is (there is a discussion in the > LCN paper concerning this). A simple filter, ie second highest OWD, > may be enough. >=20 > MAR: Outliers are outliers - you can't assume "just one" (in picking > the "second highest OWD"). To do this correctly statistically you > need to use clustering techniques to make sure your "max or min" > samples are reasonable data points - but perhaps using data points > within the CDF 5% to 95% region are good enough for a unimodal OWD > histogram. --=20 +-------------------------------+ | David A. Hayes | | david.hayes@ieee.org | +-------------------------------+ From nobody Tue Oct 21 13:16:07 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29D31A6EEC for ; Tue, 21 Oct 2014 13:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJk4FrO6pVzz for ; Tue, 21 Oct 2014 13:16:04 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468DE1A6F20 for ; Tue, 21 Oct 2014 13:15:23 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id va2so1681924obc.39 for ; Tue, 21 Oct 2014 13:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jsio/peb4rNzlV6lub1h2QAuVP54lVfMmSGlc1InmxE=; b=zEKgSzl6EeXXs/3NzWBlAiIJGkYoPAWi0EJRxKrpYAGTNUFBqguX5ublDOGvmKx2El 8xdsZIO7tJKG/qu+nVUCQIUaJl1KYQlLF/bV9pbT/dHYXbdqPTdwx4yXCx0Qcusn1d9X D4/YmH1WNgszrntmkqmCGKMJBgW7uDKDAQbAdsBhHvJsE34ZSUrF1pDkk9BgdcZQ9U7X u18ZMyOAuxVe5T6ALiL6F4flMYag4uAtawP8x0V3aVP5c2HZ8JL3HAT2ECxrMHgYbuLX 6exjwGmRQ5EhqbNO9BA0UEsx46ibtgN/n5WGNQFuFQejMIm32q8CQRPPLonR5u36QTh/ fhkw== MIME-Version: 1.0 X-Received: by 10.60.161.115 with SMTP id xr19mr31663553oeb.8.1413922522755; Tue, 21 Oct 2014 13:15:22 -0700 (PDT) Received: by 10.202.227.211 with HTTP; Tue, 21 Oct 2014 13:15:22 -0700 (PDT) In-Reply-To: <20141021220758.35d2979e@bilby.lan> References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> <20141021173659.44ecd880@hayesd-laptop> <20141021220758.35d2979e@bilby.lan> Date: Tue, 21 Oct 2014 13:15:22 -0700 Message-ID: From: Dave Taht To: David hayes Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/FmFj3WLB09O_B0yYezpWQa77ZVo Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "Michael Ramalho \(mramalho\)" , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 20:16:05 -0000 I am curious as to how these "skewness" plots are being derived? Packet captures? Samples from a traffic generator? We have a ton of stuff from netperf-wrapper runs that might be analyzable via this metric. From nobody Tue Oct 21 14:27:24 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE721A870D for ; Tue, 21 Oct 2014 14:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4A0S2LSjCYd for ; Tue, 21 Oct 2014 14:27:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4CEC1A86E7 for ; Tue, 21 Oct 2014 14:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3672; q=dns/txt; s=iport; t=1413926840; x=1415136440; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hRKSnHX5pALA8B1l+QNQMlnbQl/EFb2y1S1KELoanhA=; b=cf7+Fjq9r8kPAdvqo1/E539NbKmuZ5Y3aI/BU9XLktWAGfLXoPPppsTI 8cOXfSA6xmugf1S23+QaiLzeIX0XzunN2TEczE6KE1VCyRrR3cf/qt1fK WczWKWQ/mwun9mAXDYqe4cA4r1/Z/txAhAAsKKh50Ap7vCI9gvm+PfbI8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFADrPRlStJA2K/2dsb2JhbABcgw6BKwSDAtFHAht7FgF9hAIBAQEEIxFDAgwEAgEIEQQBAQMCBh0DAgICHxEUAQgIAgQBDQUIiCMDEbIIjjENhjIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSyJKoNMggQxBwaCcTaBHgEEkgGHCoI+g0GOGoJahAGDeGyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,764,1406592000"; d="scan'208";a="365453176" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP; 21 Oct 2014 21:27:19 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9LLRIkB021449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 21:27:18 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.5]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 16:27:18 -0500 From: "Michael Ramalho (mramalho)" To: Dave Taht , David hayes Thread-Topic: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt Thread-Index: AQHP7RCEoF+eJFnbf0KFxHP/kALCP5w7A2SA//+83qCAAI7ZAIAAAhEA//+xwSA= Date: Tue, 21 Oct 2014 21:27:18 +0000 Message-ID: References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> <20141021173659.44ecd880@hayesd-laptop> <20141021220758.35d2979e@bilby.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.253.202] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/hlaldzzZqsQZohm3Lw2Dsrf3Omo Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:27:22 -0000 SGkgRGF2ZSAoVGFodCksDQoNClRob3NlIHdlcmUgb2xkIHBsb3RzIG9mIG1pbmUgZnJvbSBhIG5v dyBjcnVzdHkgbGFiIHNldCB1cC4gSSBoYXZlIG11Y2ggaGlnaGVyIHByZWNpc2lvbiB0b29scy90 b3lzIG5vdy4gSSBqdXN0IHBpY2tlZCBhIHBsb3QgdG8gc2hvdyB0aGUgZ2VuZXJhbCBjb25jZXB0 L2lkZWEgb2Ygd2hhdCBJIHRob3VnaHQgdGhlIERhdmlkIEhheWVzIGRyYWZ0IHdhcyBhdHRlbXB0 aW5nIHRvIGRlc2NyaWJlIGluICJza2V3bmVzcyIuDQoNCkZvciBGSUZPLCB0aGUgc2hhcGUgb2Yg dGhlIE9XRCBwZGYgY2FuIHByb3ZpZGUgaW5mb3JtYXRpb24gKGEgZmlyc3Qtb3JkZXIgZ3Vlc3Mp IG9uIGhvdyBtYW55IHNvdXJjZXMgYXJlIGNvbnRyaWJ1dGluZyB0byB0aGUgY29uZ2VzdGlvbi4g T24gb3ZlcnN1YnNjcmliZWQgSVNQLXRvLUlTUCBjb25uZWN0aW9ucywgSSdsbCBiZXQgeW91IHdp bGwgZmluZCBhIHZlcnkgc2tpbm55IG1vZGUgdmVyeSBjbG9zZSB0byB0aGUgbWF4aW11bSBxdWV1 ZSBkZWxheSBvbiB0aGF0IGludGVyY29ubmVjdC4gVG8gbWUsIERhdmlkJ3MgeyJza2V3bmVzcyIg KyAidmFyaWFuY2UifSAgaXMgYSBmaXJzdC1vcmRlciBwcm94eSBmb3IgImEgc2hhcGUgY2hhcmFj dGVyaXphdGlvbiIgZm9yIHRoZSBkaXN0cmlidXRpb24uIEkgaGFkIG5vdCB0aG91Z2h0IG9mIHRo b3NlIGNvbmNlcHRzIHRoYXQgd2F5IGJlZm9yZSAoYW5kIGluZGVlZCwgZXZlbiBub3cgYW0gdGhp bmtpbmcgYWJvdXQgc29tZXRoaW5nIGJldHRlciB0aGFuIHNrZXduZXNzIEkgbWlnaHQgcGFzcyBi eSBEYXZpZCkuDQoNClRvIGFuc3dlciB5b3VyIHF1ZXN0aW9uczoNCg0KMSkgVGhlIDEwIGxvbmct bGl2ZWQgVENQcyB3ZXJlIGdlbmVyYXRlZCBieSBhbiBvbGQgc2VydmVyIHNlbmRpbmcgYSB2ZXJ5 LCB2ZXJ5IGxvbmcgZmlsZSB0byBhbm90aGVyIG1hY2hpbmUgb25lIHJvdXRlciBob3AgYXdheSBp biBhIGxhYi4gQXMgdGhlIGJvdHRsZW5lY2sgbGluayB3YXMgc28gbG93ICgxIE1icHMpLCB0aGUg b2xkIG1hY2hpbmUgaGFkIG5vIHByb2JsZW0ga2VlcGluZyB1cC4NCg0KMikgVGhlIGRlbGF5cyB3 ZXJlIHRoZSBpbmRpdmlkdWFsIGRlbGF5cyBvZiB0aGUgKDk2a2JwcyBDQlIpIFZvSVAgb24gYSBw YWNrZXQgY2FwdHVyZS4gVGhlIFZvSVAgcGFja2V0cyBlbXVsYXRlZCBHLjcxMSBzZW50IHdpdGgg cHRpbWUgPSAxMG1zLiBXaXRoIG5vIFFvUyBvciBBUU0gKGp1c3QgRklGTyksIHRoZSBpbmRpdmlk dWFsIFRDUCBwYWNrZXRzIGhhZCBzaW1pbGFyIGRlbGF5cyBvZiBjb3Vyc2UuIFRoZSBkaWZmZXJl bnQgY29sb3JzIG9uIHRoZSBkZWxheSBwbG90cyB3ZXJlIG1lZGlhbiBmaWx0ZXJlZCB2ZXJzaW9u cyBvZiB0aGUgb3JpZ2luYWwgZGF0YSAodGhlIGJsdWUgbGluZSB3YXMgYW4gMTEgcG9pbnQgbWVk aWFuIGZpbHRlciBhcHBsaWVkIHRvIHRoZSBpbmRpdmlkdWFsIHNhbXBsZXMpLg0KDQozKSBJIHVz ZWQgTUFUTEFCIHRvIGdlbmVyYXRlIGEgc21vb3RoZWQgaGlzdG9ncmFtIG9mIHRoZSBkZWxheSBz YW1wbGVzIGZvciB0aGUgcGVyaW9kIG9mIHRpbWUgaW4gd2hpY2ggdGhlIFRDUCBwYWNrZXRzIHdl cmUgY29tcGV0aW5nIHdpdGggdGhlIFZvSVAgcGFja2V0cy4gTmFtZWx5Og0KDQolQ3JlYXRlIGJp bnMgZm9yIHRoZSBzbW9vdGhlZCBwZGYgKDUwMG1zIHdhcyB0aGUgaGlnaGVzdCBwb3NzaWJsZSBP V0QpDQp4X2JpbnMgPSAwOjAuNTptYXgoUGFja2V0X2RlbGF5cygxLGJlZ2luX2luZGV4OmVuZF9p bmRleCkpOw0KJUNyZWF0ZSB0aGUgc21vb3RoZWQgcGRmDQprc2RlbnNpdHkoUGFja2V0X2RlbGF5 cygxLGJlZ2luX2luZGV4OmVuZF9pbmRleCkseF9iaW5zKTsNCg0KLi4uIHdoZXJlIGJlZ2luX2lu ZGV4IGFuZCBlbmRfaW5kZXggd2VyZSB0aGUgZGlzY3JldGUtdGltZSBpbmRleCBmb3IgdGhlIFZv SVAgZmxvdyB0aGF0IGNvcnJlc3BvbmRlZCB0byB0aGUgc3RhcnQgYW5kIGVuZCB0aW1lcyBvZiB0 aGUgVENQIGZsb3dzLg0KDQpXZSBjYW4gY29udGludWUgdGhpcyB0aHJlYWQgb2ZmIHRoZSBybWNh dCBsaXN0IGZvciBtb3JlIGRldGFpbHMgKEkgY2FuIHRoaW5rIG9mIGV4cGVyaW1lbnRzIHlvdSBj YW4gcnVuKS4NCg0KQmVzdCwNCg0KTWljaGFlbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogRGF2ZSBUYWh0IFttYWlsdG86ZGF2ZS50YWh0QGdtYWlsLmNvbV0gDQpTZW50OiBU dWVzZGF5LCBPY3RvYmVyIDIxLCAyMDE0IDQ6MTUgUE0NClRvOiBEYXZpZCBoYXllcw0KQ2M6IE1p Y2hhZWwgUmFtYWxobyAobXJhbWFsaG8pOyBybWNhdEBpZXRmLm9yZzsgU2ltb25lIEZlcmxpbi1P bGl2ZWlyYTsgTWlyamEgS8O8aGxld2luZDsgTWljaGFlbCBXZWx6bCBXZWx6bA0KU3ViamVjdDog UmU6IFtybWNhdF0gRnc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGF5ZXMt cm1jYXQtc2JkLTAwLnR4dA0KDQpJIGFtIGN1cmlvdXMgYXMgdG8gaG93IHRoZXNlICJza2V3bmVz cyIgcGxvdHMgYXJlIGJlaW5nIGRlcml2ZWQ/DQpQYWNrZXQgY2FwdHVyZXM/IFNhbXBsZXMNCmZy b20gYSB0cmFmZmljIGdlbmVyYXRvcj8gV2UgaGF2ZSBhIHRvbiBvZiBzdHVmZiBmcm9tIG5ldHBl cmYtd3JhcHBlciBydW5zIHRoYXQgbWlnaHQgYmUgYW5hbHl6YWJsZSB2aWEgdGhpcyBtZXRyaWMu DQo= From nobody Wed Oct 22 01:03:01 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC781A8AF0 for ; Wed, 22 Oct 2014 01:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aq2m7Frn8hX for ; Wed, 22 Oct 2014 01:02:53 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCA91A8AE5 for ; Wed, 22 Oct 2014 01:02:50 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id k14so3048997wgh.7 for ; Wed, 22 Oct 2014 01:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=vjnOl3Ikebgp1OA10HavwQm706/bq1EVs7vRpItfAgw=; b=IiNPG1DeS7gQXjB00yo+31D0UvafgggaazaMzauWZ+SN+qDPqwQ/8u3/X7Ofy8P1wy lreDtjri0CZYRZHDYqZ2n707V/jja/FL5wWlE/xm8RIZtWnQ6VVbdQoLpp/mZDn8WiUN XlzBdmRCIS8VbHkcIBXD0NLyXW4EBbRiYzgrE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=vjnOl3Ikebgp1OA10HavwQm706/bq1EVs7vRpItfAgw=; b=f75kyxxujoAyCyHiuW8Mo7YMY6Sn4YaL/EsEn4IK9p2aBP/oVMbCOiZ50zjPvsCzAp x0o8f2oI5OoTXifMbipPqIh+eXSKptsYqtV6hjgaG6nViSv36iJ38lta/fBXZ49MDat3 zzmEOZVJ4yTl2gmM/mVvdpyMNNvChz/hAAsBGerL/ITd50p6WGNuv/e0VNB2J+FOgtn8 dIVN8Q0hbht78t0x4WPxYUTHVNPPdaHgNU/wOosPnpjDMEh2DLZeSc3trVTVcyH7ud76 TZXSaj86z9oW8wrffTExJ1sPSzwYOjtEZKmQjfWWgVAOPYXl8TqjyxJoUdokxYz5cFWE eb+Q== X-Gm-Message-State: ALoCoQkqNpwU1fwJTAXgzi9norUpf9rMSw89zWuUpwisGQYuh7uG17yrROf0aSuRKygcp5wiiDMnbIN81bRvxx8t2qltqxaqdLXrzoJ6rkPLYO6JhwcAoJk= X-Received: by 10.181.28.7 with SMTP id jk7mr8308053wid.14.1413964968968; Wed, 22 Oct 2014 01:02:48 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIPttdCH2SJ02MV/3/Cp3GymEJhPgICN2BBm6wWB2A= Date: Wed, 22 Oct 2014 10:02:47 +0200 Message-ID: To: "Mo Zanaty (mzanaty)" Content-Type: multipart/alternative; boundary=001a11364c1cb37bb40505fe5f03 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/7XHAF98Hpe6-jmiCpcu47h9owGc Cc: "Eggert, Lars" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , draft-ietf-rmcat-app-interaction@tools.ietf.org, rmcat WG Subject: Re: [rmcat] comments RMCAT app interactions draft X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 08:02:57 -0000 --001a11364c1cb37bb40505fe5f03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mo, all Please find follow up below. BR, Karen *From:* Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] *Sent:* 22. oktober 2014 09:01 *To:* Karen Elisabeth Egede Nielsen *Cc:* Mirja K=C3=BChlewind; Eggert, Lars; draft-ietf-rmcat-app-interaction@tools.ietf.org *Subject:* Re: comments RMCAT app interactions draft Hi Karen, Thank you for the comments. Adding co-authors to review my responses (see Mo: inline) and provide their own as well. Feel free to include the list as well if you think the discussion should be wider. Best regards, Mo On 10/21/14, 12:06 PM, Karen Elisabeth Egede Nielsen < karen.nielsen@tieto.com> wrote: Hi Mo, Please accept the below comments to the present draft. Having been made aware, however, of the discussion about the draft scope and contents at IETF89 (Mirja made me aware =E2=80=93 J), then some of the comments below may actually not be so useful. I.e., some parts may go away in consistency with the comments given to this effect at IETF89. Please see other email on this. BR, Karen Comments: Usage of term =E2=80=9COS=E2=80=9D: (multiple places) In the document UDP and IP functions are consistently quoted as being OS functions. In user mode UDP/IP stack solutions this is not the case, meaning that here the UDP (or IP) layer does not reside more in OS space than the application layer does. I understand that kernel OS UDP/IP stack solutions are widely deployed but also User mode stack solutions exists and are getting some momentum in these years for some of the same reasons that implementation of transport layer in user mode has momentum. Would it be relevant to at least make the note in the document that the UDP/IP layer may not actually be part of the OS. Or alternatively completely remove all notions of the OS in the document as it wherever used seems to refer to UDP/IP stack functions. Mo: I agree user-space network stacks should be included. =E2=80=9COS=E2=80= =9D was not intended to exclude them or only encompass the kernel (although most network stacks are in kernel space in most OS=E2=80=99es). *[Karen] User mode network stack solutions do not invoke the OS IP stack (typically in OS kernel) but instead uses the OS as an HW abstraction layer in which to execute the user mode stack. But this is a very minor issue in the context of this doc.* How about if we just clarify in the initial definition of OS that this encompasses user-space network stacks as well as traditional kernel stacks?= I=E2=80=99m hesitant to replace OS with UDP/IP stack in case we want to describe other interactions, like interface-level traffic shaping which may be a lower layer than UDP/IP functions. I guess we could go with =E2=80=9Cnetwork stac= k=E2=80=9D though, if that is preferred over OS. *[Karen] Either way would works fine for me. * Then potentially most of the OS and UDP/IP aspects of this document may actually be removed =E2=80=93 except for the overall setting of context whi= ch I think is nice and beneficial. Mo: Nothing was intended as pure context with no relevant interactions to describe. If we remove the interactions (5.6), it probably makes sense to remove the component completely. *[Karen] Setting the context of a function is generally very valuable even if not all parts/components are in scope of the work (RFC). But let=E2=80= =99s see what others think . References (e.g. [Singh12]) of course also can serve for architectural context.* Also I agree with the comment given by Lars at IETF89 that most of the described interaction in-between the UDP/IP and the CC likely would be handled in the CC and the interface for the relation in between CC and UDP/IP would be described in each CC algorithm proposals. Mo: Yes, in most cases things like pacing/shaping for a single flow would be done by the CC. But, as mentioned in 5.6, interface-level traffic shaping may also be used (for local bottlenecks) if supported by the OS. *(= The network stack solution ;-).* The text can probably be clearer on this, if we agree it is a worthwhile thing to retain. I=E2=80=99m aware of implementations that do this, but the= y are fairly rare, so I=E2=80=99m fine with omitting such interactions if we want= to simplify the draft. However, I think we should at least retain the ECN and DSCP parts of the CC-UDP/IP interactions in 5.6. *[Karen] I think this would depend on to which extend these CC =E2=80=93 ne= twork stack interactions are described in the CC algorithm proposals themselves.* *It would be good to have comments from the CC designers on this.* Section 4: Would it be right to clarify that the looser model in [Singh12] corresponds to the model in figure 2. Mo: Yes, will do. Section 5.4: Allowed rate: I know that it is merely an example. Still the one second example sounds like a bit of a long time compared to TCP CC which operates on an RTT granularity basis. Mo: Agreed. There is really no need for the example, so it can be removed. FEC: The FEC may influences the sensitivity towards certain network impairments (potentially to be communicated to CC) but that such sensitivity would stem from FEC would not be exposed as the interface. Or would it ? Mo: I think you=E2=80=99re right. FEC is just a consideration when exposing= Loss Tolerance which is the real interface. Folding the FEC consideration into the Loss Tolerance part would be clearer. The same about the probing: If FEC is run, probing may be done in particular manner, but it would not necessarily be exposed on the interface between codec and CC. Or would it ? Mo: Perhaps Varun or Lars can comment on FEC probing since they wrote a draft on it. ;) We should decide which is a better model, to have FEC coupled with CC so the Allowed Rate only includes media and only increases after successful probing, or have FEC coupled with the Codec (or RTP) but invisible to CC so the Allowed Rate includes FEC and increases speculatively (so the Codec/RTP must cautiously apply FEC upon speculative increases signaled by the CC). The draft currently does the latter, but I= =E2=80=99m open to changing this. Section 5.5: I wonder if the following should not be a requirement for the RMCAT CC, and go into that document, rather than be stated as something to handle at the interface in between RTP and RMCAT CC: RTP Circuit Breakers: The intent behind RTP circuit breakers [I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill switch of last resort, not true congestion control. The breakers should never trip when an effective congestion control is operating. This may impose some boundaries on RMCAT solutions to ensure the congestion control never approaches situations which may trigger the breakers. Mo: Yes, it is more a requirement for no interaction! We can remove it unless/until we discover some specific quantifiable boundaries that would be dynamically imposed on the CC. *[Karen] I think that we should have this be lifted into the requirements doc.* Section 5.7: I wonder if the context here does not belong to the Coupled CC work ? Mo: This section is really just a stub to acknowledge that interface may exist and point to the Coupled CC draft for details. *[Karen] Ok. We see were we end exactly in terms of scope of this doc: App* *=C3=9F**=C3=A0** CC interaction only or interactions generally between the= various components.* --001a11364c1cb37bb40505fe5f03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi= Mo, all

=C2= =A0

Please find follow up below.

=C2=A0

BR, Karen

=C2=A0=

From: Mo Zanaty (mzanaty) [mailto:= mzanaty@cisco.com]
Sent: 22. oktober 2014 09:01
To: Karen Elisabeth Egede Nielsen
= Cc: Mirja K=C3=BChlewind; Eggert, Lars; draft-ietf-rmcat-app-interaction@tools.= ietf.org
Subject: Re: comments RMCAT app interactions draft

=C2=A0

Hi Karen,

=C2=A0

Thank you for the comments. Adding co-authors t= o review my responses (see Mo: inline) and provide their own as well. Feel = free to include the list as well if you think the discussion should be wide= r.

=C2=A0=

Best reg= ards,

Mo<= /span>

=C2=A0

On 10/= 21/14, 12:06 PM, Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> wrote:

<= /div>

=C2=A0

Hi Mo,

=C2=A0

Please accept the below comments to the present draft.

=C2=A0=

Having been made aware, however, of the discussion about the draft scope = and contents at IETF89 (Mirja made me aware =E2=80=93 J),

=

then some= of the comments below may actually not be so useful. I.e., some parts may = go away in consistency with

the comment= s given to this effect at IETF89.

Plea= se see other email on this.

=C2=A0

BR, Karen

=C2=A0

Comments:

=C2=A0

Usage of term= =E2=80=9COS=E2=80=9D: (multiple places)=

=C2=A0

In the document UDP and IP fun= ctions are consistently quoted as being OS functions.

In user mode UDP/IP stack solutions this is not the case, = meaning that here the UDP (or IP) layer does not reside more

in OS space than the application layer does. I unders= tand that kernel OS UDP/IP stack solutions are widely

deployed but also User mode stack solutions exists and are= getting some momentum in these years for some of the same reasons

that implementation of transport layer in user = mode has momentum.

Would it be relev= ant to at least make the note in the document that the UDP/IP layer may not= actually be part of the OS.

<= p class=3D"MsoNormal">Or alterna= tively completely remove all notions of the OS in the document as it wherev= er used seems to refer to UDP/IP stack functions.

=C2=A0

Mo: I agree user-space network stacks should be included. =E2=80=9COS= =E2=80=9D was not intended to exclude them or only encompass the kernel (al= though most network stacks are in kernel space in most OS=E2=80=99es).

[Karen] User mode network stack soluti= ons do not invoke the OS IP stack (typically in OS kernel) but instead uses= the OS as an HW abstraction layer in which to execute the user mode stack.= But this is a very minor issue in the context of this doc.<= /p>

How about if= we just clarify in the initial definition of OS that this encompasses user= -space network stacks as well as traditional kernel stacks? I=E2=80=99m hesitant to replace OS with UDP/IP stack in case = we want to describe other interactions, like interface-level traffic shapin= g which may be a lower layer than UDP/IP functions. I guess we could go wit= h =E2=80=9Cnetwork stack=E2=80=9D though, if that is preferred over OS.

=C2=A0=

[Karen] Either way would works fine for me.

=C2=A0

Then potentially =C2=A0most of the OS and UDP/IP aspects of this = document may actually be removed =E2=80=93 except for the overall setting o= f context which I think is nice and beneficial.

=C2=A0

Mo: Nothing was intende= d as pure context with no relevant interactions to describe. If we remove t= he interactions (5.6), it probably makes sense to remove the component comp= letely.

[Karen] Setting the context of a function is generally v= ery valuable even if not all parts/components are in scope of the work (RFC= ). But let=E2=80=99s see what others think . References (e.g. [Singh12]) of= course also can serve for architectural context.

=C2=A0

Also I agree w= ith the comment given by Lars at IETF89 =C2=A0that most of the described in= teraction in-between the UDP/IP and the CC likely would be handled in the C= C =C2=A0and the interface for the relation in between CC and UDP/IP would b= e described in each CC algorithm proposals.

=C2= =A0

Mo: Y= es, in most cases things like pacing/shaping for a single flow would be don= e by the CC. But, as mentioned = in 5.6, interface-level traffic shaping may also be used (for local bottlen= ecks) if supported by the OS.= (The network sta= ck solution ;-).

The text can probably be clearer on this, if we agree = it is a worthwhile thing to retain. I=E2=80=99= m aware of implementations that do this, but they are fairly rare, so I=E2= =80=99m fine with omitting such interactions if we want to simplify the dra= ft. However, I think we should at least retain the ECN and DSCP parts of th= e CC-UDP/IP interactions in 5.6.

=C2=A0

[Karen] I think this would de= pend on to which extend these CC =E2=80=93 network stack interactions are d= escribed in the CC algorithm proposals themselves.

It woul= d be good to have comments from the CC designers on this.

=C2=A0=

Section 4:

=C2=A0

Would it be right to clarify that the looser model in [S= ingh12] corresponds to the model in figure 2.

=C2= =A0

Mo: Y= es, will do.

=C2=A0

Section= 5.4:

<= span lang=3D"EN-US" style=3D"color:black">=C2=A0

Allowed rate:

=C2=A0

I know that it is merely an example. Still the = one second example sounds like a bit of a long time compared to TCP CC whic= h operates on an RTT granularity basis.<= /span>

=C2=A0

Mo: Agreed.= There is really no need for the example, so it can be removed.

<= /div>

=C2=A0

FEC: The FEC may influences the= sensitivity towards certain network impairments (potentially to be communi= cated to CC) =C2=A0but that such sensitivity would stem from FEC would not = be exposed as the interface. Or would it ?

=C2=A0=

Mo: I th= ink you=E2=80=99re right. FEC is just a consideration when exposing Loss To= lerance which is the real interface. Folding the FEC consideration into the= Loss Tolerance part would be clearer.

=C2=A0

The same about the probing: If FEC is run, probing may b= e done in particular manner, but it would not necessarily be exposed on the= interface between codec and CC. Or would it ?

= =C2=A0

Mo= : Perhaps Varun or Lars can comment on FEC probing since they wrote a draft= on it. ;) =C2=A0We should decide which is a better model, to have FEC coup= led with CC so the Allowed Rate only includes media and only increases afte= r successful probing, or have FEC coupled with the Codec (or RTP) but invis= ible to CC so the Allowed Rate includes FEC and increases speculatively (so= the Codec/RTP must cautiously apply FEC upon speculative increases signale= d by the CC). The draft currently does the latter, but I=E2=80=99m open to = changing this.

=C2=A0

Section 5.5:<= /p>

=C2=A0=

I wonder if the following should not b= e a requirement for the RMCAT CC, and go into that document, rather than be= stated as

something to handle at the i= nterface in between RTP and RMCAT CC:

=C2=A0

=C2=A0=C2=A0 RTP Circuit Breakers: The intent behind RTP circuit b= reakers
=C2=A0=C2=A0 [I-D.ietf-avtcore-rtp-circuit-breakers] is to provi= de a kill switch
=C2=A0=C2=A0 of last resort, not true congestion contro= l.=C2=A0 The breakers should
=C2=A0=C2=A0 never trip when an effective c= ongestion control is operating.=C2=A0 This
=C2=A0=C2=A0 may impose some = boundaries on RMCAT solutions to ensure the
=C2=A0=C2=A0 congestion cont= rol never approaches situations which may trigger the
=C2=A0=C2=A0 break= ers.

=C2=A0

Mo: Yes, it is more a requirement for no inter= action! We can remove it unless/until we discover some specific quantifiabl= e boundaries that would be dynamically imposed on the CC.

[Karen] = I think that we should have this be lifted into the requirements doc.

=C2=A0

= Section 5.7:

=C2=A0

I wonder if the context here does not belong to the Coup= led CC work ?

=C2=A0

Mo: This section is really just a stu= b to acknowledge that interface may exist and point to the Coupled CC draft= for details.

[Karen] Ok. We see we= re we end exactly in terms of scope of this doc: App=C3=9F=C3=A0 CC interaction only or interactions generally between the various co= mponents.

--001a11364c1cb37bb40505fe5f03-- From nobody Wed Oct 22 02:06:03 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9892C1A8BC3 for ; Wed, 22 Oct 2014 02:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz9SLdlsvoY0 for ; Wed, 22 Oct 2014 02:06:01 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2031A8BC2 for ; Wed, 22 Oct 2014 02:06:01 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id y10so3150192wgg.15 for ; Wed, 22 Oct 2014 02:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=D/5zJBBRu5VhBNwww6I0Th4EHAZW9rz2GGejCrQv8IQ=; b=QEOXexkGYtCw50JH2xx5VK8tdLInjfjH+/1VXhWTTnf+Cx+SMl9Psj3UYSBEZnsZ1h ahKDK94whcZLqc2rMceVhxpn2fp8+ZQG5XEHhcTw+bL//7VvdtBCRbgRfy+VdIpfUFrK ZZ94IYgpmbINXWWcnwG0+eJ1LNMdwVTIKoyP0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc:content-type; bh=D/5zJBBRu5VhBNwww6I0Th4EHAZW9rz2GGejCrQv8IQ=; b=nA8A7k+XJBypeLx3ZR9DVCkm6TTsV14O/mPdnqz0JIk9uxkRPiUdYNsCAltOtiO98/ U+uPa1GaOoDbJDRTzIloV0J0T+fXxARPWIh206COvv/RSJy0k/RpwKrrb/JKZYYHIzkm p7QbHqq1S39GwohluGh2n3S3qo7zFq6tOhRDs3dYamrhYcbi9HfFoP0K+LdcLvmCLvOx RCNGrhJjFa4BPLuPjUZnnJHRggI+F+Fi5HTLv87Ir8EZ66n567OyoWpodZw4jrtzPYNf ziowQL+oX3OVbp1oI/e4bVuP7W0opEVBblshZ4LmXGaKX1b4Outu7ziALrQWHbKmg9Y8 ghtg== X-Gm-Message-State: ALoCoQl8FI4F4fD2wyFQ4Ps6YPqyL7zp2mOWW3iZxCMynWfR9M33cICAuwE2+5ZwGYYiXhu9Be3uvp8cDh9UbsmWU/TnQeOROknFjbyw1jU9cr68UsujpsM= X-Received: by 10.194.161.166 with SMTP id xt6mr50844922wjb.1.1413968760167; Wed, 22 Oct 2014 02:06:00 -0700 (PDT) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/t12R9c799MkcoSqq0oj+grkzezQ== Date: Wed, 22 Oct 2014 11:05:59 +0200 Message-ID: To: rmcat WG Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/6mcdG07OprzaKy5dIAY52CXWYP8 Cc: "Eggert, Lars" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , draft-ietf-rmcat-app-interaction@tools.ietf.org Subject: [rmcat] call for comments on draft-ietf-rmcat-app-interaction-00 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 09:06:02 -0000 Hi, In order to progress the wg document on application interactions we and the authors of the doc would like to call for people, CC designers in particular, to read the document and provide comments with focus on the following aspects: 1. Scope of document: Which interfaces are we looking to have described in this document - especially should the document only describe the interface in between the RMCAT Congestion controller and the application or should the document provide an more extensive description of the various components and their interrelations - still likely with a special emphasis on the RMCAT Congestion controller and the application/codec interface - ? This was discussed already at IETF89 RMCAT session (see minutes) - this is an attempt to recap this discussion in order to establish consensus. 2. What (given the scope assumed for 1.) are the top 3-4 interactions (e.g., allowed rate) that matter the most and which are needed to be described in the document ? Thanks. BR, Karen/Chairs From nobody Wed Oct 22 07:36:50 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54541ACCF5 for ; Wed, 22 Oct 2014 07:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAPIgwJSFC0y for ; Wed, 22 Oct 2014 07:36:33 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9720D1AC40B for ; Wed, 22 Oct 2014 07:36:33 -0700 (PDT) Received: by mail-oi0-f53.google.com with SMTP id v63so2788454oia.40 for ; Wed, 22 Oct 2014 07:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5WJq15xMTu77s49fDPEw2ubzRFz0TU9MsV6sAqDW5zA=; b=o7zOlKLpBAT8ds3pJ9ZJede0KTRSdzUo3VCTdHVQBlSUhzSD1I8HW2039CFzs/Ga40 o8thDNBcu+7FQB3oiVdpF04gaoDtRztW/QqcioL8shKBm4XtJDXS+ByGc3NVPoreJCTO 6R/oBeAMI0jaLuaRXCnqM/kJlZizyl2qVZO5gnpYQuCu0wKI55toIlJN7rxghvAboUZN wNCkyVY21EbPPgItetEbvsLwn1c3ySEHEU1r10x+kWKxgBxHDKxfdVG6KjVmQm5r/M7b yMM6OcnhsrgDIz6Yv5tQMQiMyxEFZNKBeQyrHFwVr7QvnMSfJAczHom3x1UZCYyHXMJG kBrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5WJq15xMTu77s49fDPEw2ubzRFz0TU9MsV6sAqDW5zA=; b=ZruOUpcL/EZ9zBoQYPjjRb7tybA/OkuhjE5V10BVxmNQUfiXb+UYECJX1VBPA+Paje TkHtYz5VbhrG4BPVOrKudQ6FjSWX87QvYaHMRFGQZ2/R3BW67vGkHwviUpAfdkFPEam9 LZkQBAWEq9dKfu1iR87LH20kZVT2q43dJfq8fQtb4BKi2ffjp7GbG/hyuMuLQlZs4XC2 HUWpc3s7zXCSlvUKeFVf2d6Son944znz9uO8OQ+8rNqKMpYWbD9k8ritU1QmePxdMPEC qEU9uKHiBhtpJdMjgTyXE8BQpDBzlK35joG5E4YRCexVBxaIxjPGScaWiKqRLYsKB/e+ LSzA== X-Gm-Message-State: ALoCoQn0yw2hxQd+gAyPiBTLjdVEa5DzcMp9BMfHVCcqBSZFAUTkBw4+039Y6AurydDR5py+PUvk MIME-Version: 1.0 X-Received: by 10.202.170.21 with SMTP id t21mr34272723oie.5.1413988592699; Wed, 22 Oct 2014 07:36:32 -0700 (PDT) Sender: holmer@google.com Received: by 10.182.143.71 with HTTP; Wed, 22 Oct 2014 07:36:32 -0700 (PDT) In-Reply-To: <20141010173710.1769e033@hayesd-laptop> References: <20141010173710.1769e033@hayesd-laptop> Date: Wed, 22 Oct 2014 16:36:32 +0200 X-Google-Sender-Auth: xLqyS1xe4egQ_eyQUc252Loclu0 Message-ID: From: Stefan Holmer To: David Hayes Content-Type: multipart/alternative; boundary=001a113cdf64c8fb5d050603df63 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/KUIY0om7k0a48HtagxJlcRSxAgY Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 14:36:35 -0000 --001a113cdf64c8fb5d050603df63 Content-Type: text/plain; charset=UTF-8 Nice draft! I have a few comments: You're mentioning that skewness would require all delay measurements to be stored, and therefore you're computing some different metric which is related to skew. I wonder if it shouldn't be possible to more accurately estimate the skew from a histogram instead? That way you at least won't need to store all delay measurements. Might not be worth the trouble if your metric works well. As mentioned by Mirja, it seems a bit error prone to use the max of the OWD (also, shouldn't it be max_T(OWD)?) when computing the PDV. Somewhat related to this, I wonder if you have any plans to test this algorithm on WiFi? I have seen many cases of WiFi with a lot of contention and/or interference, where the delay gets skewed not because lack of bandwidth, but because of lower layer retransmissions or because the access point was busy serving someone else for a moment. I wonder if that can cause you to incorrectly detect shared bottlenecks, where in reality there was only a shared WiFi... Now that I think of it, the WiFi effect should result in positive skewness, while you're looking for negative skewness, so you may be ok here. :) It would be good to have the diff() operation defined somewhere. Is it the diff between successive measurements, or the diff between the flows? /Stefan On Fri, Oct 10, 2014 at 5:37 PM, David Hayes wrote: > Dear All, > > We have just submitted of our initial shared bottleneck detection > draft and will value your comments and suggestions. > > Regards, > > David > > Begin forwarded message: > > Date: Fri, 10 Oct 2014 08:17:57 -0700 > From: > To: Michael Welzl , David Hayes > , Michael Welzl , Simone Ferlin > , Simone Ferlin , David Hayes > Subject: New Version Notification for > draft-hayes-rmcat-sbd-00.txt > > > > A new version of I-D, draft-hayes-rmcat-sbd-00.txt > has been successfully submitted by David Hayes and posted to the > IETF repository. > > Name: draft-hayes-rmcat-sbd > Revision: 00 > Title: Shared Bottleneck Detection for Coupled > Congestion Control for RTP Media. Document date: 2014-10-10 > Group: Individual Submission > Pages: 12 > URL: > http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt > Status: https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ > Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 > > > Abstract: > This document describes a mechanism to detect whether end-to-end data > flows share a common bottleneck. It relies on summary statistics > that are calculated by a data receiver based on continuous > measurements and regularly fed to a grouping algorithm that runs > wherever the knowledge is needed. This mechanism complements the > coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. > > > > > 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. > > The IETF Secretariat > > > > -- > > ------------------------- > David Hayes > davihay@ifi.uio.no > Department of Informatics > University of Oslo > > --001a113cdf64c8fb5d050603df63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nice draft! I have a few comments:

You&= #39;re mentioning that skewness would require all delay measurements to be = stored, and therefore you're computing some different metric which is r= elated to skew. I wonder if it shouldn't be possible to more accurately= estimate the skew from a histogram instead? That way you at least won'= t need to store all delay measurements. Might not be worth the trouble if y= our metric works well.

As mentioned by Mirja, it s= eems a bit error prone to use the max of the OWD (also, shouldn't it be= max_T(OWD)?) when computing the PDV.=C2=A0

Somewh= at related to this, I wonder if you have any plans to test this algorithm o= n WiFi? I have seen many cases of WiFi with a lot of contention and/or inte= rference, where the delay gets skewed not because lack of bandwidth, but be= cause of lower layer retransmissions or because the access point was busy s= erving someone else for a moment. I wonder if that can cause you to incorre= ctly detect shared bottlenecks, where in reality there was only a shared Wi= Fi... Now that I think of it, the WiFi effect should result in positive ske= wness, while you're looking for negative skewness, so you may be ok her= e. :)

It would be good to have the diff() operatio= n defined somewhere. Is it the diff between successive measurements, or the= diff between the flows?

/Stefan


On Fri, = Oct 10, 2014 at 5:37 PM, David Hayes <davihay@ifi.uio.no> w= rote:
Dear All,

We have just submitted of our initial shared bottleneck detection
draft and will value your comments and suggestions.

Regards,

David

Begin forwarded message:

Date: Fri, 10 Oct 2014 08:17:57 -0700
From: <internet-drafts@ietf.= org>
To: Michael Welzl <michawe@ifi.uio= .no>, David Hayes
<davihay@ifi.uio.no>, Micha= el Welzl <michawe@ifi.uio.no&g= t;, Simone Ferlin
<ferlin@simula.no>, Simone Fe= rlin <ferlin@simula.no>, Davi= d Hayes
<davihay@ifi.uio.no> Subjec= t: New Version Notification for
draft-hayes-rmcat-sbd-00.txt



A new version of I-D, draft-hayes-rmcat-sbd-00.txt
has been successfully submitted by David Hayes and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hayes-rmcat-sbd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Shared Bottleneck Detection for Co= upled
Congestion Control for RTP Media. Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0= 2014-10-10
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:
http://www.ietf.org/internet-drafts/draft-hayes-rmcat-s= bd-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.iet= f.org/doc/draft-hayes-rmcat-sbd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/draft= -hayes-rmcat-sbd-00


Abstract:
=C2=A0 =C2=A0This document describes a mechanism to detect whether end-to-e= nd data
=C2=A0 =C2=A0flows share a common bottleneck.=C2=A0 It relies on summary st= atistics
=C2=A0 =C2=A0that are calculated by a data receiver based on continuous
=C2=A0 =C2=A0measurements and regularly fed to a grouping algorithm that ru= ns
=C2=A0 =C2=A0wherever the knowledge is needed.=C2=A0 This mechanism complem= ents the
=C2=A0 =C2=A0coupled congestion control mechanism in draft-welzl-rmcat-coup= led-cc.




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.

The IETF Secretariat



--

-------------------------
David Hayes
davihay@ifi.uio.no
Department of Informatics
University of Oslo


--001a113cdf64c8fb5d050603df63-- From nobody Wed Oct 22 08:20:11 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34631ACD5F for ; Wed, 22 Oct 2014 08:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JsGAT5DGU-7 for ; Wed, 22 Oct 2014 08:20:01 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EBC1ACD4B for ; Wed, 22 Oct 2014 08:20:01 -0700 (PDT) Received: by mail-oi0-f46.google.com with SMTP id h136so2875037oig.5 for ; Wed, 22 Oct 2014 08:20:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wtQq4RT/wEXGU4zeYK4zKF05eKyybRUGxylWvZMbePo=; b=NjlW2NHtCIldz1z+ly0CFHj2bVhqtCjcDC6VM2x+9yx5XFIJTreKWkTaPfqytg0mAG A5d2U9GhSTBJEsvu/TkLT8HwzSl5ZPtdXHRzKX8OiwUCKwbYY7nyeQTnfxDaub61PiXz UlfabaZ7N0xRgrot3oUFkkNK0w1i7yNTiEw+w3J2GnQULAOuz0o6HFCnLaMxGm3CFdzy yPz9BAtF0SMnpGiFrEe3V1+WudrbQeYyYd/n8BPSNMiMUD+AYueMhlnT4VrZ07v0ljgG Xd4d2Pziyq4WOFkJtVupdagGgTUEa6ZIbsL7FfCiYnjoWJ1G81Y45ExPMs8mkxABeBUk FYkA== X-Gm-Message-State: ALoCoQmfdY3eLZPyDGJz82TbzdtSHJsywAibRxvjcuT/BGlRya76q88xjdtn45RGSpl6uXiQKMNC MIME-Version: 1.0 X-Received: by 10.182.68.107 with SMTP id v11mr24858359obt.32.1413991201015; Wed, 22 Oct 2014 08:20:01 -0700 (PDT) Received: by 10.202.224.137 with HTTP; Wed, 22 Oct 2014 08:20:00 -0700 (PDT) In-Reply-To: References: <20141010173710.1769e033@hayesd-laptop> Date: Wed, 22 Oct 2014 17:20:00 +0200 Message-ID: From: Simone Ferlin-Oliveira To: Stefan Holmer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/dKDwO7M6q_YUDH-42sLZoUj8rTE Cc: "rmcat@ietf.org" , Michael Welzl Welzl , David Hayes Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:20:05 -0000 Hi Stefan, Thanks for your comments. Would you have any traces of such WiFi cases you mention? We plan to run other tests with the algorithm. I have already an implementation and we are testing it with wired/3G/4G at the moment. Simone (co-author) On 22 October 2014 16:36, Stefan Holmer wrote: > Nice draft! I have a few comments: > > You're mentioning that skewness would require all delay measurements to be > stored, and therefore you're computing some different metric which is > related to skew. I wonder if it shouldn't be possible to more accurately > estimate the skew from a histogram instead? That way you at least won't need > to store all delay measurements. Might not be worth the trouble if your > metric works well. > > As mentioned by Mirja, it seems a bit error prone to use the max of the OWD > (also, shouldn't it be max_T(OWD)?) when computing the PDV. > > Somewhat related to this, I wonder if you have any plans to test this > algorithm on WiFi? I have seen many cases of WiFi with a lot of contention > and/or interference, where the delay gets skewed not because lack of > bandwidth, but because of lower layer retransmissions or because the access > point was busy serving someone else for a moment. I wonder if that can cause > you to incorrectly detect shared bottlenecks, where in reality there was > only a shared WiFi... Now that I think of it, the WiFi effect should result > in positive skewness, while you're looking for negative skewness, so you may > be ok here. :) > > It would be good to have the diff() operation defined somewhere. Is it the > diff between successive measurements, or the diff between the flows? > > /Stefan > > > On Fri, Oct 10, 2014 at 5:37 PM, David Hayes wrote: >> >> Dear All, >> >> We have just submitted of our initial shared bottleneck detection >> draft and will value your comments and suggestions. >> >> Regards, >> >> David >> >> Begin forwarded message: >> >> Date: Fri, 10 Oct 2014 08:17:57 -0700 >> From: >> To: Michael Welzl , David Hayes >> , Michael Welzl , Simone Ferlin >> , Simone Ferlin , David Hayes >> Subject: New Version Notification for >> draft-hayes-rmcat-sbd-00.txt >> >> >> >> A new version of I-D, draft-hayes-rmcat-sbd-00.txt >> has been successfully submitted by David Hayes and posted to the >> IETF repository. >> >> Name: draft-hayes-rmcat-sbd >> Revision: 00 >> Title: Shared Bottleneck Detection for Coupled >> Congestion Control for RTP Media. Document date: 2014-10-10 >> Group: Individual Submission >> Pages: 12 >> URL: >> http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt >> Status: https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ >> Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 >> >> >> Abstract: >> This document describes a mechanism to detect whether end-to-end data >> flows share a common bottleneck. It relies on summary statistics >> that are calculated by a data receiver based on continuous >> measurements and regularly fed to a grouping algorithm that runs >> wherever the knowledge is needed. This mechanism complements the >> coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> >> -- >> >> ------------------------- >> David Hayes >> davihay@ifi.uio.no >> Department of Informatics >> University of Oslo >> > From nobody Wed Oct 22 08:24:12 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01731ACD9F for ; Wed, 22 Oct 2014 08:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2Aa7c3JAZcM for ; Wed, 22 Oct 2014 08:23:58 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076271ACD7D for ; Wed, 22 Oct 2014 08:22:51 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id nt9so1708986obb.15 for ; Wed, 22 Oct 2014 08:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1YomgWoh4nh0CnO1d8N2nKCAORGMowkrfa2fLLDklfs=; b=Gov1do3DtgayqHSVrPUKnHlCNPk8urhSI3OJxNFcqGqOZm9FmtdkBEWH5ktPBLlf5s UnQ+uIQ5gEr9c8dr2XBLIHsSZPPi/H5fUhSPOaKGnany7IvYSIyzAlk/wE5J9PpeOGW1 VwyiMvQELUgAlkpgSpWTc6U22+bAL2uGGNpAmqKFcCpLWFgLjQ2ZovVu5uD6GPv5OgRs vB/Jv2QHjaJ6OzvU3v0bmQAuRhP6pJQJz60t4x7EMU9RGM/m73aEr2IG26XN1+5lr5pj nkXxCXIoDsEcOSo04kaRKZOXMxoi61zhKu9q8EyLPNudsmYNIZ9K8oRA9mIQN1IG5CTS Zkog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1YomgWoh4nh0CnO1d8N2nKCAORGMowkrfa2fLLDklfs=; b=RSNEIhy1OrGadlStzLzTsmgfEPR8qWm8MzF1f5M74dC8rnmm6/Zwr+PEyKVtbq2TON JhfJ0/RDG6YriYeQp1Wr8Q8oGSolqFCOsvlMaMncwLa47N2r6Y5Vz7inaYhLD88JcZBz hnBOhq6Lh8YhFgWu51SsO0oQiWdLWzzLKN/X6eEB6glb9yGUPWBqAV3uhXCtjGO3L5sj lND8/GNa2FbzJVqRw0aUqnKy0e2arz4n68A/XAoQIbX13K80+KqTrWpptMNw6KJcjifZ 6g2wu9ae7sHV3iQqrQWTsAdoh9HHl7B2a3DvT/BmwcAqXfiGWDJZ8s0xUHYljjadGAxK VqTw== X-Gm-Message-State: ALoCoQm3imRXnVZy5jmarLjrRifh60w7nBQE+KN8wu5kTJ6o9/f82U0kRCU7tOw4KynIeOr7xTdT MIME-Version: 1.0 X-Received: by 10.60.68.108 with SMTP id v12mr1455921oet.69.1413991371322; Wed, 22 Oct 2014 08:22:51 -0700 (PDT) Sender: holmer@google.com Received: by 10.182.143.71 with HTTP; Wed, 22 Oct 2014 08:22:51 -0700 (PDT) In-Reply-To: References: <20141010173710.1769e033@hayesd-laptop> Date: Wed, 22 Oct 2014 17:22:51 +0200 X-Google-Sender-Auth: EPSKOES12zZAk6JPkxOrUabPp8o Message-ID: From: Stefan Holmer To: Simone Ferlin-Oliveira Content-Type: multipart/alternative; boundary=001a11330d5e67515e0506048535 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/6RLABqT4slO_4TwjBjXP67GEcUs Cc: "rmcat@ietf.org" , Michael Welzl Welzl , David Hayes Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:24:00 -0000 --001a11330d5e67515e0506048535 Content-Type: text/plain; charset=UTF-8 If you checkout the webrtc repository you'll find one trace under: webrtc/resources/google-wifi-3mbps.rx. It contains packet arrival times in nanoseconds (I think) when the sender sent at a constant rate of 3 mbps. On Wed, Oct 22, 2014 at 5:20 PM, Simone Ferlin-Oliveira wrote: > Hi Stefan, > > Thanks for your comments. > > Would you have any traces of such WiFi cases you mention? > We plan to run other tests with the algorithm. I have already an > implementation and we are testing it with wired/3G/4G at the moment. > > Simone (co-author) > > On 22 October 2014 16:36, Stefan Holmer wrote: > > Nice draft! I have a few comments: > > > > You're mentioning that skewness would require all delay measurements to > be > > stored, and therefore you're computing some different metric which is > > related to skew. I wonder if it shouldn't be possible to more accurately > > estimate the skew from a histogram instead? That way you at least won't > need > > to store all delay measurements. Might not be worth the trouble if your > > metric works well. > > > > As mentioned by Mirja, it seems a bit error prone to use the max of the > OWD > > (also, shouldn't it be max_T(OWD)?) when computing the PDV. > > > > Somewhat related to this, I wonder if you have any plans to test this > > algorithm on WiFi? I have seen many cases of WiFi with a lot of > contention > > and/or interference, where the delay gets skewed not because lack of > > bandwidth, but because of lower layer retransmissions or because the > access > > point was busy serving someone else for a moment. I wonder if that can > cause > > you to incorrectly detect shared bottlenecks, where in reality there was > > only a shared WiFi... Now that I think of it, the WiFi effect should > result > > in positive skewness, while you're looking for negative skewness, so you > may > > be ok here. :) > > > > It would be good to have the diff() operation defined somewhere. Is it > the > > diff between successive measurements, or the diff between the flows? > > > > /Stefan > > > > > > On Fri, Oct 10, 2014 at 5:37 PM, David Hayes wrote: > >> > >> Dear All, > >> > >> We have just submitted of our initial shared bottleneck detection > >> draft and will value your comments and suggestions. > >> > >> Regards, > >> > >> David > >> > >> Begin forwarded message: > >> > >> Date: Fri, 10 Oct 2014 08:17:57 -0700 > >> From: > >> To: Michael Welzl , David Hayes > >> , Michael Welzl , Simone Ferlin > >> , Simone Ferlin , David Hayes > >> Subject: New Version Notification for > >> draft-hayes-rmcat-sbd-00.txt > >> > >> > >> > >> A new version of I-D, draft-hayes-rmcat-sbd-00.txt > >> has been successfully submitted by David Hayes and posted to the > >> IETF repository. > >> > >> Name: draft-hayes-rmcat-sbd > >> Revision: 00 > >> Title: Shared Bottleneck Detection for Coupled > >> Congestion Control for RTP Media. Document date: 2014-10-10 > >> Group: Individual Submission > >> Pages: 12 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt > >> Status: https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ > >> Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 > >> > >> > >> Abstract: > >> This document describes a mechanism to detect whether end-to-end data > >> flows share a common bottleneck. It relies on summary statistics > >> that are calculated by a data receiver based on continuous > >> measurements and regularly fed to a grouping algorithm that runs > >> wherever the knowledge is needed. This mechanism complements the > >> coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. > >> > >> > >> > >> > >> 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. > >> > >> The IETF Secretariat > >> > >> > >> > >> -- > >> > >> ------------------------- > >> David Hayes > >> davihay@ifi.uio.no > >> Department of Informatics > >> University of Oslo > >> > > > --001a11330d5e67515e0506048535 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you checkout the webrtc repository you'll find one = trace under: webrtc/resources/google-wifi-3mbps.rx. It contains packet arri= val times in nanoseconds (I think) when the sender sent at a constant rate = of 3 mbps.

O= n Wed, Oct 22, 2014 at 5:20 PM, Simone Ferlin-Oliveira &l= t;ferlin@simula.no> wrote:
Hi Stefan,

Thanks for your comments.

Would you have any traces of such WiFi cases you mention?
We plan to run other tests with the algorithm. I have already an
implementation and we are testing it with wired/3G/4G at the moment.

Simone (co-author)

On 22 October 2014 16:36, Stefan Holmer <stefan@webrtc.org> wrote:
> Nice draft! I have a few comments:
>
> You're mentioning that skewness would require all delay measuremen= ts to be
> stored, and therefore you're computing some different metric which= is
> related to skew. I wonder if it shouldn't be possible to more accu= rately
> estimate the skew from a histogram instead? That way you at least won&= #39;t need
> to store all delay measurements. Might not be worth the trouble if you= r
> metric works well.
>
> As mentioned by Mirja, it seems a bit error prone to use the max of th= e OWD
> (also, shouldn't it be max_T(OWD)?) when computing the PDV.
>
> Somewhat related to this, I wonder if you have any plans to test this<= br> > algorithm on WiFi? I have seen many cases of WiFi with a lot of conten= tion
> and/or interference, where the delay gets skewed not because lack of > bandwidth, but because of lower layer retransmissions or because the a= ccess
> point was busy serving someone else for a moment. I wonder if that can= cause
> you to incorrectly detect shared bottlenecks, where in reality there w= as
> only a shared WiFi... Now that I think of it, the WiFi effect should r= esult
> in positive skewness, while you're looking for negative skewness, = so you may
> be ok here. :)
>
> It would be good to have the diff() operation defined somewhere. Is it= the
> diff between successive measurements, or the diff between the flows? >
> /Stefan
>
>
> On Fri, Oct 10, 2014 at 5:37 PM, David Hayes <davihay@ifi.uio.no> wrote:
>>
>> Dear All,
>>
>> We have just submitted of our initial shared bottleneck detection<= br> >> draft and will value your comments and suggestions.
>>
>> Regards,
>>
>> David
>>
>> Begin forwarded message:
>>
>> Date: Fri, 10 Oct 2014 08:17:57 -0700
>> From: <internet-dra= fts@ietf.org>
>> To: Michael Welzl <michaw= e@ifi.uio.no>, David Hayes
>> <davihay@ifi.uio.no&g= t;, Michael Welzl <michawe@ifi.uio= .no>, Simone Ferlin
>> <ferlin@simula.no>, = Simone Ferlin <ferlin@simula.no&= gt;, David Hayes
>> <davihay@ifi.uio.no&g= t; Subject: New Version Notification for
>> draft-hayes-rmcat-sbd-00.txt
>>
>>
>>
>> A new version of I-D, draft-hayes-rmcat-sbd-00.txt
>> has been successfully submitted by David Hayes and posted to the >> IETF repository.
>>
>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hayes-rmcat-sb= d
>> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Shared Bottleneck Detecti= on for Coupled
>> Congestion Control for RTP Media. Document date:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 2014-10-10
>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
>> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
>> URL:
>> http://www.ietf.org/internet-drafts/draft-haye= s-rmcat-sbd-00.txt
>> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatr= acker.ietf.org/doc/draft-hayes-rmcat-sbd/
>> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/h= tml/draft-hayes-rmcat-sbd-00
>>
>>
>> Abstract:
>>=C2=A0 =C2=A0 This document describes a mechanism to detect whether= end-to-end data
>>=C2=A0 =C2=A0 flows share a common bottleneck.=C2=A0 It relies on s= ummary statistics
>>=C2=A0 =C2=A0 that are calculated by a data receiver based on conti= nuous
>>=C2=A0 =C2=A0 measurements and regularly fed to a grouping algorith= m that runs
>>=C2=A0 =C2=A0 wherever the knowledge is needed.=C2=A0 This mechanis= m complements the
>>=C2=A0 =C2=A0 coupled congestion control mechanism in draft-welzl-r= mcat-coupled-cc.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of<= br> >> submission until the htmlized version and diff are available at >> tools.ietf.org= .
>>
>> The IETF Secretariat
>>
>>
>>
>> --
>>
>> -------------------------
>> David Hayes
>> davihay@ifi.uio.no
>> Department of Informatics
>> University of Oslo
>>
>

--001a11330d5e67515e0506048535-- From nobody Wed Oct 22 10:12:26 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69351ACE67 for ; Wed, 22 Oct 2014 10:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-Usljp3mhCC for ; Wed, 22 Oct 2014 10:12:19 -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 15D1A1ACE56 for ; Wed, 22 Oct 2014 10:12:18 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgzSL-0008P0-4Q; Wed, 22 Oct 2014 19:12:17 +0200 Received: from 36.80-202-170.nextgentel.com ([80.202.170.36] helo=bilby.lan) by mail-mx6.uio.no with esmtpsa (SSLv3:AES128-SHA:128) user davihay (Exim 4.80.1) (envelope-from ) id 1XgzSK-0006z0-4N; Wed, 22 Oct 2014 19:12:17 +0200 Date: Wed, 22 Oct 2014 19:12:14 +0200 From: David hayes To: Stefan Holmer Message-ID: <20141022191214.20694951@bilby.lan> In-Reply-To: References: <20141010173710.1769e033@hayesd-laptop> Organization: University of Oslo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-mageia-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 1 total rcpts 1543 max rcpts/h 38 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: AA6EED801C8A82B7308B724AF119D1428F960F4F X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 80.202.170.36 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 1 total 86 max/h 4 blacklist 0 greylist 1 ratelimit 0 X-UiOonly: BCD0B7DD2D859272F4C806DAC4D4A7178D2D3DB7 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/ZsTr3OmksarVxAOGLYrTdb0hdQY Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 17:12:22 -0000 Hi Stefan, Thanks for your comments! They are very much appreciated. I have added some responses inline. Kind regards, David On Wed, 22 Oct 2014 16:36:32 +0200 Stefan Holmer wrote: > Nice draft! I have a few comments: > > You're mentioning that skewness would require all delay measurements > to be stored, and therefore you're computing some different metric > which is related to skew. I wonder if it shouldn't be possible to > more accurately estimate the skew from a histogram instead? That way > you at least won't need to store all delay measurements. Might not be > worth the trouble if your metric works well. The 3rd central moment is difficult to calculate for a number of reasons. Yes you need the mean to start with, which would require storing all the delay measurements so that when you have the mean, you can compare them with it. The other problem is, that being a cubic function, it is very sensitive to outliers and therefore requires a high number of samples for an accurate result. Skew_est is efficient to calculate and less sensitive to outliers (the test is only above and below the mean), meaning we don't need quite as many samples. Using a histogram was one of the ideas I looked at. In the end I didn't go with it for the following reasons. To do this we need to know what a good bin size is, and probably need to use the same bin size for each flow (a common base for comparing). If we know the min/max network delays of every flow we can work out a good bin size, but generally we don't know this a priori -- and it could also change with new flows or changes in the network paths. We could use the previous NT's PDV as a guide for this, but the flows we are comparing with are probably going to different receivers. In this case we would need to communicate the information between sender and receivers. > > As mentioned by Mirja, it seems a bit error prone to use the max of > the OWD (also, shouldn't it be max_T(OWD)?) when computing the PDV. > max_T would be more consistent with our notation. Thanks. We used max_T instead of min_T because of their relationship to skew_est in a MM1K queueing model(LCN paper). However, the difference between MM1K and real networks and the problem of coping with outliers and may make min_T a better choice. In our tests we did not have any significant problems, but we would not have had processing delays Mirja pointed to. > Somewhat related to this, I wonder if you have any plans to test this > algorithm on WiFi? I have seen many cases of WiFi with a lot of > contention and/or interference, where the delay gets skewed not > because lack of bandwidth, but because of lower layer retransmissions > or because the access point was busy serving someone else for a > moment. I wonder if that can cause you to incorrectly detect shared > bottlenecks, where in reality there was only a shared WiFi... Now > that I think of it, the WiFi effect should result in positive > skewness, while you're looking for negative skewness, so you may be > ok here. :) > Simone has answered here. Thanks! > It would be good to have the diff() operation defined somewhere. Is > it the diff between successive measurements, or the diff between the > flows? > Can you elaborate on this suggestion a bit more please. Thanks! > /Stefan > > > On Fri, Oct 10, 2014 at 5:37 PM, David Hayes > wrote: > > > Dear All, > > > > We have just submitted of our initial shared bottleneck detection > > draft and will value your comments and suggestions. > > > > Regards, > > > > David > > > > Begin forwarded message: > > > > Date: Fri, 10 Oct 2014 08:17:57 -0700 > > From: > > To: Michael Welzl , David Hayes > > , Michael Welzl , Simone > > Ferlin , Simone Ferlin , David > > Hayes Subject: New Version Notification for > > draft-hayes-rmcat-sbd-00.txt > > > > > > > > A new version of I-D, draft-hayes-rmcat-sbd-00.txt > > has been successfully submitted by David Hayes and posted to the > > IETF repository. > > > > Name: draft-hayes-rmcat-sbd > > Revision: 00 > > Title: Shared Bottleneck Detection for Coupled > > Congestion Control for RTP Media. Document date: 2014-10-10 > > Group: Individual Submission > > Pages: 12 > > URL: > > http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ > > Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 > > > > > > Abstract: > > This document describes a mechanism to detect whether end-to-end > > data flows share a common bottleneck. It relies on summary > > statistics that are calculated by a data receiver based on > > continuous measurements and regularly fed to a grouping algorithm > > that runs wherever the knowledge is needed. This mechanism > > complements the coupled congestion control mechanism in > > draft-welzl-rmcat-coupled-cc. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > > > > > -- > > > > ------------------------- > > David Hayes > > davihay@ifi.uio.no > > Department of Informatics > > University of Oslo > > > > -- +-------------------------------+ | David A. Hayes | | david.hayes@ieee.org | +-------------------------------+ From nobody Wed Oct 22 10:36:52 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690E81ACE8D for ; Wed, 22 Oct 2014 10:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SacHbf7cNF6z for ; Wed, 22 Oct 2014 10:36:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99E11ACE97 for ; Wed, 22 Oct 2014 10:36:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5630AD9303; Wed, 22 Oct 2014 19:36:44 +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 H5+bXuVWro+g; Wed, 22 Oct 2014 19:36:44 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id EAF73D9302; Wed, 22 Oct 2014 19:36:43 +0200 (MEST) Message-ID: <5447EB2B.9070302@tik.ee.ethz.ch> Date: Wed, 22 Oct 2014 19:36:43 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: David Hayes References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> <20141021173659.44ecd880@hayesd-laptop> In-Reply-To: <20141021173659.44ecd880@hayesd-laptop> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/JMOsZqkR2Sk7g626Eb2tD-OZNfs Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 17:36:50 -0000 Hi David, just again on the skewness point: Form my current understanding what you somehow want to measure with this is something like a standing queue..? Still the way you calculate the skewness seems very abstract to me. However, if it can be shown that this provides useful information, it definitely should be used. The question (for all the metrics that you propose) is how can you show that these are the right metrics. One approach is definitely to do more measurements in various scenario but could you also assess the risk of failures? Or (and this potentially is more a question for the cc congestion) how bad is if you group two flows together wrongly? Mirja On 21.10.2014 17:36, David Hayes wrote: > Hi Mirja, > > Thank you for going through this and giving your comments and questions! > > I have answered your questions inline. > > Regards, > > David > > On Tue, 21 Oct 2014 11:22:09 +0200 > Mirja Kühlewind wrote: > >> Hi David, hi all, >> >> I've read your document and have a couple of questions (as an >> individual contributor): >> >> 1) You propose to use the OWD, to do all the calculation at the >> receiver and to signal the information to the sender. Did you also do >> some analysis how good your approach would be if you use RTT (because >> than the sender could also work independent of the receiver)? >> >> 2) You also talk about a receiver based approach. I'm not sure if >> this case is needed because that's the case where simply congestion >> control does its job. While if one sender has multiple flows it seems >> to be more reasonable for me to couple these. >> >> 3) Am I right to that you need an initial set-up time of 17.5 sec? > > Not quite. Decisions can start to be made after T (nominally 350ms), > though with far less accuracy, but increasingly more accurately as > time progresses. This needs to be outlined in the draft. > >> Can you also explain a little further why you've chosen 350ms and >> N=50? > > Roughly, T should to be long enough to capture the short term variance > in the OWD, but not too long so as to be able to sample the low > frequency oscillations of OWD on the bottleneck. T=350ms provided > good results (though not necessarily optimal) on the two very different > networks we tested it on in the LCN paper. However, the dynamics on the > Internet can change. T is one the parameters sent in the initialisation > message, so although we want to recommend a good "all round" value for > it, it can be changed to suit specific network dynamics. > > The system will need to keep N samples of many of the statistics. With > larger values of N, many of the parameters can be calculated more > accurately (or less noisily), but at the expense of memory and > sensitivity to changing network conditions. Also, if N is too small it > is difficult to get a good freq_est for comparison. N=50 was found to be > good "all round" value in our tests so far. It too is one of the > parameters sent during initialisation, potentially allowing an > application to set it according to its needs for network dynamic > sensitivity. > >> 4) Can you also explain with which (network) effect you have >> skewness? Is this really an effect in real systems that gives you >> valuable information? > > OWD skewness (in an abstract way) is a function of the load at the > bottleneck and the traffic dynamics. When a queue becomes congested, > the queue distribution becomes skewed toward the back of the queue (At > extreme loads the dynamic changes again). It is important in the > algorithm for a number of reasons: > 1. If there is no congestion along the path, all of the delay > statistics are too noisy to be useful for grouping flows > (there is no bottleneck!). Skewness is used to determine > whether a flow is experiencing congestion -- or to put it > another way that the statistics will be reliable for grouping > flows. > > Other possible metrics could be: > - magnitude of delay (but we do not know how long the queue is > at the bottleneck and what the OWD_min is) > - loss (loss can be caused by other factors, and may be to rare) > - ECN (this will be good in the future, but is not reliable > now - the bottleneck may not be ECN enabled) > - etc > > Skewness was found to be a reliable congestion indicator that > did not require any prior knowledge of queuing along the path. > > > 2. Two similar bottlenecks with similar traffic but different > loads can exhibit a similar variance, but will have a different > skewness. This helps to distinguish this case. > >> >> 5) If you look at the variance (and use the max) you might want to >> apply some kind of filtering first e.g. to filter out single out >> liners (due to some processing delays). > > This is a good point, especially the further from the network interface > measurements are made. Min would be a better option in terms of noise, > but (in theory) Min is load ambiguous (see 2. above) at similar loads > to where skewness is (there is a discussion in the LCN paper concerning > this). A simple filter, ie second highest OWD, may be enough. > >> >> 6) Can you also explain a little more, why you also use the >> oscillation frequency and the value p_v=0.2? While the other metrics >> actually measures some kind of network behavior, e.g. delay variance >> is determined by the queue size, the oscillation size is determined >> by the congestion control behavior. I guess the flows have to use the >> same congestion control scheme...? >> > > The low frequency oscillation of OWDs at a bottleneck depends on many > things including: the queue size, other traffic at the bottleneck (flows > starting, flows leaving, etc), and the combined behaviour of all of the > traffic's congestion controllers. In our experiments (and general > observations of OWD graphs), the low frequency oscillation of OWDs is > discernibly different between different bottlenecks. This metric tries > to capture that difference with an efficient estimate that can be > easily compared. > > We use the short term variation in the signal, p_v, as a guide for > de-noising. The skewness congestion test 4)1. above helps to ensure > that we are measuring a signal and not just noise. > > >> 7) For packet loss you can also estimated the loss frequency. I would >> think if the congestion control operates loss-based that this would >> actually give you a pretty good estimate if flows share the same >> bottleneck. Or even easier if the loss of the flows always occur in >> the same RTT. > > When the the packet loss rate is high, this becomes a reliable measure > and is used by the algorithm. However, when the packet loss rate is low > the signal is too rare to be useful. > > Within an RTT (we are looking at OWD) not all flows traversing a > bottleneck will necessarily experience packet loss. Also, not all flows > will necessarily have the same RTT, having different paths to their > destinations. > > Hassayoun, Iyengar, and Ros in their paper "Dynamic window coupling for > multipath congestion control", look at a similar idea for MPTCP. The > SBD is intertwined with the congestion control, and although sufficient > for their purpose, has different objectives and I don't think can be > applied to achieve a reliable grouping in the RMCAT scenario. > >> >> 8) And one last question regarding the grouping: Do you always need >> to apply all three conditions? Why are those three needed? >> > > All the statistics are noisy making fine grain grouping based > on one statistic difficult. Using a number of statistics summarising > different aspects of the signal allows us to more coarsely group based > on each statistic (allowing for the noise) but still obtain a fine > enough grouping. > > An aside on the noise: The noise is caused by the same things that we > are looking for in the "signal" from the bottleneck: queueing, packet > loss, etc. The bottleneck "signal" is generally stronger than the noise > from the other devices along the path, but still the signal and noise > have similar characteristics. This similarity makes filtering difficult. > >> Mirja >> >> >> >> On 10.10.2014 17:37, David Hayes wrote: >>> Dear All, >>> >>> We have just submitted of our initial shared bottleneck detection >>> draft and will value your comments and suggestions. >>> >>> Regards, >>> >>> David >>> >>> Begin forwarded message: >>> >>> Date: Fri, 10 Oct 2014 08:17:57 -0700 >>> From: >>> To: Michael Welzl , David Hayes >>> , Michael Welzl , Simone >>> Ferlin , Simone Ferlin , David >>> Hayes Subject: New Version Notification for >>> draft-hayes-rmcat-sbd-00.txt >>> >>> >>> >>> A new version of I-D, draft-hayes-rmcat-sbd-00.txt >>> has been successfully submitted by David Hayes and posted to the >>> IETF repository. >>> >>> Name: draft-hayes-rmcat-sbd >>> Revision: 00 >>> Title: Shared Bottleneck Detection for Coupled >>> Congestion Control for RTP Media. Document date: 2014-10-10 >>> Group: Individual Submission >>> Pages: 12 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ >>> Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 >>> >>> >>> Abstract: >>> This document describes a mechanism to detect whether >>> end-to-end data flows share a common bottleneck. It relies on >>> summary statistics that are calculated by a data receiver based on >>> continuous measurements and regularly fed to a grouping algorithm >>> that runs wherever the knowledge is needed. This mechanism >>> complements the coupled congestion control mechanism in >>> draft-welzl-rmcat-coupled-cc. >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >>> >>> > > > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------ From nobody Wed Oct 22 10:44:20 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58551ACD53 for ; Wed, 22 Oct 2014 10:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKiHLQspAIVx for ; Wed, 22 Oct 2014 10:44:16 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BED1A9103 for ; Wed, 22 Oct 2014 10:44:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8698DD9302; Wed, 22 Oct 2014 19:44:14 +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 vYDZPeYm4NLb; Wed, 22 Oct 2014 19:44:14 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3A33AD9304; Wed, 22 Oct 2014 19:44:14 +0200 (MEST) Message-ID: <5447ECED.4050904@tik.ee.ethz.ch> Date: Wed, 22 Oct 2014 19:44:13 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Stefan Holmer , David Hayes References: <20141010173710.1769e033@hayesd-laptop> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/3fcHMELhAg1uz_igFfgF1dtASAM Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 17:44:18 -0000 Hi Stefan, asking this because I'm personally curious but also as rmcat chair: Are you planning to implement some kind of coupled congestion control in your system? Mirja On 22.10.2014 16:36, Stefan Holmer wrote: > Nice draft! I have a few comments: > > You're mentioning that skewness would require all delay measurements to be > stored, and therefore you're computing some different metric which is > related to skew. I wonder if it shouldn't be possible to more accurately > estimate the skew from a histogram instead? That way you at least won't > need to store all delay measurements. Might not be worth the trouble if > your metric works well. > > As mentioned by Mirja, it seems a bit error prone to use the max of the OWD > (also, shouldn't it be max_T(OWD)?) when computing the PDV. > > Somewhat related to this, I wonder if you have any plans to test this > algorithm on WiFi? I have seen many cases of WiFi with a lot of contention > and/or interference, where the delay gets skewed not because lack of > bandwidth, but because of lower layer retransmissions or because the access > point was busy serving someone else for a moment. I wonder if that can > cause you to incorrectly detect shared bottlenecks, where in reality there > was only a shared WiFi... Now that I think of it, the WiFi effect should > result in positive skewness, while you're looking for negative skewness, so > you may be ok here. :) > > It would be good to have the diff() operation defined somewhere. Is it the > diff between successive measurements, or the diff between the flows? > > /Stefan > > > On Fri, Oct 10, 2014 at 5:37 PM, David Hayes wrote: > >> Dear All, >> >> We have just submitted of our initial shared bottleneck detection >> draft and will value your comments and suggestions. >> >> Regards, >> >> David >> >> Begin forwarded message: >> >> Date: Fri, 10 Oct 2014 08:17:57 -0700 >> From: >> To: Michael Welzl , David Hayes >> , Michael Welzl , Simone Ferlin >> , Simone Ferlin , David Hayes >> Subject: New Version Notification for >> draft-hayes-rmcat-sbd-00.txt >> >> >> >> A new version of I-D, draft-hayes-rmcat-sbd-00.txt >> has been successfully submitted by David Hayes and posted to the >> IETF repository. >> >> Name: draft-hayes-rmcat-sbd >> Revision: 00 >> Title: Shared Bottleneck Detection for Coupled >> Congestion Control for RTP Media. Document date: 2014-10-10 >> Group: Individual Submission >> Pages: 12 >> URL: >> http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt >> Status: https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ >> Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 >> >> >> Abstract: >> This document describes a mechanism to detect whether end-to-end data >> flows share a common bottleneck. It relies on summary statistics >> that are calculated by a data receiver based on continuous >> measurements and regularly fed to a grouping algorithm that runs >> wherever the knowledge is needed. This mechanism complements the >> coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> >> -- >> >> ------------------------- >> David Hayes >> davihay@ifi.uio.no >> Department of Informatics >> University of Oslo >> >> > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------ From nobody Wed Oct 22 23:59:10 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0052E1A885B for ; Wed, 22 Oct 2014 23:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVDzZg9li-hz for ; Wed, 22 Oct 2014 23:59:07 -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 1A8D91A884A for ; Wed, 22 Oct 2014 23:59:06 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XhCMT-0007Az-4x; Thu, 23 Oct 2014 08:59:05 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XhCMS-0005vO-Lc; Thu, 23 Oct 2014 08:59:05 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: <5447EB2B.9070302@tik.ee.ethz.ch> Date: Thu, 23 Oct 2014 08:59:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> <20141021173659.44ecd880@hayesd-laptop> <5447EB2B.9070302@tik.ee.ethz.ch> To: =?iso-8859-1?Q?Mirja_K=FChlewind?= X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 8 sum msgs/h 3 total rcpts 21632 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 77747953B88B2842020E5DE6AB5755E3898AED61 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 0 bait 0 mail/h: 2 total 6591 max/h 17 blacklist 0 greylist 1 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/2ME4rfMYjF8Bkd1FKxA50iFKumQ Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , David Hayes Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 06:59:09 -0000 Hi, Maybe I can help with this bit (and I hope David will correct me in case = I put this wrongly) - On 22. okt. 2014, at 19:36, Mirja K=FChlewind wrote: > Hi David, >=20 > just again on the skewness point: Form my current understanding what = you somehow want to measure with this is something like a standing = queue..? Still the way you calculate the skewness seems very abstract to = me. My understanding is that the intuition behind using skewness is that = you'd get a negative skewness in the OWD distribution only if you have = (common) congestion (the queue is often full and sometimes drains). > However, if it can be shown that this provides useful information, it = definitely should be used. The question (for all the metrics that you = propose) is how can you show that these are the right metrics. One = approach is definitely to do more measurements in various scenario but = could you also assess the risk of failures? Or (and this potentially is = more a question for the cc congestion) how bad is if you group two flows = together wrongly? Indeed that's a question about coupled-cc. My answer to "how bad is it = ..." is: the behavior can be very wrong. E.g., assume priorities of 1/10 = vs. 1. Coupled-cc will take the total and divide the rates accordingly. = If these flows don't share a common bottleneck, that's just a very wrong = thing to do - you may end up giving one flow much less and another flow = much more than its own congestion controller has derived. I think that sort of problem is unavoidable; the best one can do is to = try to get the shared bottleneck detection scheme to be as reliable as = possible (which is a part of why this work took us a long time, we = really do believe that this is pretty reliable) and use it = conservatively: e.g., one could turn on coupling only after a minute or = multiple minutes of a stable positive signal, and immediately turn it = off in case of a negative one. This would be extremely conservative, but = I'm just saying it's a parameter that can be tuned. Cheers, Michael From nobody Thu Oct 23 02:28:27 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D0C1A89A2 for ; Thu, 23 Oct 2014 02:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ud5SGPJxYKP1 for ; Thu, 23 Oct 2014 02:28:23 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E0E1A875F for ; Thu, 23 Oct 2014 02:28:23 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uy5so427435obc.22 for ; Thu, 23 Oct 2014 02:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lRSgiPDurSlqXF+WJzztYjCayuKE+Z4hVIdJwvoar5k=; b=AcF1yf08pwFC5YVsyJKwOiF4CIP3CuI5Q0wOFPNKmnL9ZSLNMDeTuiykw7iT8b+cFS EfQZnuZ56U2O5PowXuhZ6EcwAd/qQEY8YA1/8On0zUm+uPnAq2JCNdhHi1RAfEnz2C3P 5xe5KKuK4KeVJnILbxULBvLbs2I/wcy4QkSpjY8FOoq90QOXvMkogUrMLJaNcAnrULUM 1GeA8RZ32MAeRelHPiQx1SqBdrv6XHzcrGezxlxokWGT9oSE8af6PjxlbEjCemvQzeuN /R0sNj5BncI1d2AmG6K6BdqP62FrWpSD2zReIfWDC/kj+49Gmm148YPnsSoNkYaRbTGQ Pgmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lRSgiPDurSlqXF+WJzztYjCayuKE+Z4hVIdJwvoar5k=; b=Tor3XEFqyy0odH6l8MlY//Rwkph7Nn7SsAT+ZfLr+BJvHtbHYIJeEr10S5VZlFGjL0 EB6XSQyITHIM5olTs2eP8AYZ2KFZh2DSLf/IMFhjosDSz6ujbfrXO2Atgmwt2Ia/bPPM vwN0B4CvT7gmIzQaHTLhwIIfMHyoMGJri1LbDhP+4gwzeSi2q8oTjxtZIKJm8YzCn4dh 4y79OQOjMSHGMCkruF8bk7ShT9xuke4nvWKEWZc0E4jXOSIM0evjonBKJvN2rchdOn0r xxlFeiBHosRcF9wDeC1hjEfACnuPCcm97bebhby2fGzkNW1hHNI5Et59H3hEM9IzF7pq 2GXw== X-Gm-Message-State: ALoCoQlB5WtJHt/9NgMTnRlN/oglNmqmir3afCXOKauX2tOok4MTxM9khu9elonitU85lGnrJ+SK MIME-Version: 1.0 X-Received: by 10.182.165.36 with SMTP id yv4mr1539525obb.39.1414056502760; Thu, 23 Oct 2014 02:28:22 -0700 (PDT) Sender: holmer@google.com Received: by 10.182.143.71 with HTTP; Thu, 23 Oct 2014 02:28:22 -0700 (PDT) In-Reply-To: References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> <20141021173659.44ecd880@hayesd-laptop> <5447EB2B.9070302@tik.ee.ethz.ch> Date: Thu, 23 Oct 2014 11:28:22 +0200 X-Google-Sender-Auth: 7dn5EX6AaIwP6IdhTs8GQyLY09c Message-ID: From: Stefan Holmer To: Michael Welzl Content-Type: multipart/alternative; boundary=001a11c2fd348a40c9050613af25 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/n0kevdbN6in_Yi4-llaJqtlnDw0 Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , David Hayes Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 09:28:25 -0000 --001a11c2fd348a40c9050613af25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 23, 2014 at 8:59 AM, Michael Welzl wrote: > Hi, > > Maybe I can help with this bit (and I hope David will correct me in case = I > put this wrongly) - > > On 22. okt. 2014, at 19:36, Mirja K=C3=BChlewind wrote: > > > Hi David, > > > > just again on the skewness point: Form my current understanding what yo= u > somehow want to measure with this is something like a standing queue..? > Still the way you calculate the skewness seems very abstract to me. > > My understanding is that the intuition behind using skewness is that you'= d > get a negative skewness in the OWD distribution only if you have (common) > congestion (the queue is often full and sometimes drains). > Yes, that was my final conclusion about skewness as well when reading the draft. I think that also should help avoid false classifications of congestion when the channel periodically goes silent, for instance on some WiFis. Do you guys have any idea of when this metric might fail? > > > > However, if it can be shown that this provides useful information, it > definitely should be used. The question (for all the metrics that you > propose) is how can you show that these are the right metrics. One approa= ch > is definitely to do more measurements in various scenario but could you > also assess the risk of failures? Or (and this potentially is more a > question for the cc congestion) how bad is if you group two flows togethe= r > wrongly? > > Indeed that's a question about coupled-cc. My answer to "how bad is it > ..." is: the behavior can be very wrong. E.g., assume priorities of 1/10 > vs. 1. Coupled-cc will take the total and divide the rates accordingly. I= f > these flows don't share a common bottleneck, that's just a very wrong thi= ng > to do - you may end up giving one flow much less and another flow much mo= re > than its own congestion controller has derived. > > I think that sort of problem is unavoidable; the best one can do is to tr= y > to get the shared bottleneck detection scheme to be as reliable as possib= le > (which is a part of why this work took us a long time, we really do belie= ve > that this is pretty reliable) and use it conservatively: e.g., one could > turn on coupling only after a minute or multiple minutes of a stable > positive signal, and immediately turn it off in case of a negative one. > This would be extremely conservative, but I'm just saying it's a paramete= r > that can be tuned. > > Cheers, > Michael > > --001a11c2fd348a40c9050613af25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 23, 2014 at 8:59 AM, Michael Welzl <mich= awe@ifi.uio.no> wrote:
Hi,<= br>
Maybe I can help with this bit (and I hope David will correct me in case I = put this wrongly) -

On 22. okt. 2014, at 19:36, Mirja K=C3=BChlewind wrote:

> Hi David,
>
> just again on the skewness point: Form my current understanding what y= ou somehow want to measure with this is something like a standing queue..? = Still the way you calculate the skewness seems very abstract to me.

My understanding is that the intuition behind using skewness is that= you'd get a negative skewness in the OWD distribution only if you have= (common) congestion (the queue is often full and sometimes drains).

Yes, that was my final conclusion about skewn= ess as well when reading the draft. I think that also should help avoid fal= se classifications of congestion when the channel periodically goes silent,= for instance on some WiFis. Do you guys have any idea of when this metric = might fail?
=C2=A0


> However, if it can be shown that this provides useful information, it = definitely should be used. The question (for all the metrics that you propo= se) is how can you show that these are the right metrics. One approach is d= efinitely to do more measurements in various scenario but could you also as= sess the risk of failures? Or (and this potentially is more a question for = the cc congestion) how bad is if you group two flows together wrongly?

Indeed that's a question about coupled-cc. My answer to "ho= w bad is it ..." is: the behavior can be very wrong. E.g., assume prio= rities of 1/10 vs. 1. Coupled-cc will take the total and divide the rates a= ccordingly. If these flows don't share a common bottleneck, that's = just a very wrong thing to do - you may end up giving one flow much less an= d another flow much more than its own congestion controller has derived.
I think that sort of problem is unavoidable; the best one can do is to try = to get the shared bottleneck detection scheme to be as reliable as possible= (which is a part of why this work took us a long time, we really do believ= e that this is pretty reliable) and use it conservatively: e.g., one could = turn on coupling only after a minute or multiple minutes of a stable positi= ve signal, and immediately turn it off in case of a negative one. This woul= d be extremely conservative, but I'm just saying it's a parameter t= hat can be tuned.

Cheers,
Michael


--001a11c2fd348a40c9050613af25-- From nobody Thu Oct 23 02:31:57 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396E01A875F for ; Thu, 23 Oct 2014 02:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j3-QIxTQ-Np for ; Thu, 23 Oct 2014 02:31:53 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855431A89AF for ; Thu, 23 Oct 2014 02:31:53 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id va2so132011obc.21 for ; Thu, 23 Oct 2014 02:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MofoXPg0DzWODkkwBnMrV97XhqtP0MfIkvL1OFkyd7E=; b=HE626b035kjPn6rJt7cyXgYdgFAckzDlJWzwYAMqTUwid5eIkXnq906/LtO3IK7ndv VEAhfWywiJBmBUv5e0JHX1+0kvPs4Tt0owXOReH+wLVbkETfppvY0kabzgeQMJsbtzjh eOKyPKNWPGPJKApkw2ch2YcXWZomAuRaGS/jalHrRX2CNPMSAZKKmNZqioc2rB6rqyK6 vJmWrhCdfhNxfpJ3+UQKHvyuyoJcVr8fGpEp5pN+M9VYjOpy8gaEAoGSG5YMJhOYYGa6 4ePkFWx+XNb6beVpSPcHxS5XxYPHPmHnWFiDFeYXYjFr7GqnawoCe4ney4+ISIuDLSY6 s0AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MofoXPg0DzWODkkwBnMrV97XhqtP0MfIkvL1OFkyd7E=; b=E7LEEgektBE/bZXKAEZ/8vHMf1jDOzzef/R6GrvYKEwzNb1Ukme4jtxmgqLElIlD3s 2Qc9Nbi0Nede8TNIQIzY0IQavNY3M/WJ5maV+q+NNYX4A6yEs8rWGtRZiKS/Df7qmutT jw3tKUm73/UD0O7FxfNmRsgOswDVk5sCP8yxam2IA7gUX7Z2QQyo143Sd3xMVl6h2E4r Ds+AilkvrAgNYfL/H5JEA3gJBtoZuQDQkqtHtQNq0dIzk1nXFM4CEZksaOwkTcR5WU+1 dny4Uf6tZ/E5/59h00Yx6eSRrBoL6uPt5Ulms36JcmfeWsCNzGKLPFZH3n6Dx02WoXya ABXA== X-Gm-Message-State: ALoCoQmQWM6W9lqPRP2wVRBLv5Gqt2RW1I4E6tKRh1JpgVrROfPXJTimmuoPFEPjd36wWl0Kv2hE MIME-Version: 1.0 X-Received: by 10.60.161.115 with SMTP id xr19mr3301790oeb.8.1414056712882; Thu, 23 Oct 2014 02:31:52 -0700 (PDT) Sender: holmer@google.com Received: by 10.182.143.71 with HTTP; Thu, 23 Oct 2014 02:31:52 -0700 (PDT) In-Reply-To: <20141022191214.20694951@bilby.lan> References: <20141010173710.1769e033@hayesd-laptop> <20141022191214.20694951@bilby.lan> Date: Thu, 23 Oct 2014 11:31:52 +0200 X-Google-Sender-Auth: FQkwknbEzjGWLzp2t4xVP3E365c Message-ID: From: Stefan Holmer To: David hayes Content-Type: multipart/alternative; boundary=089e012287c61066c9050613bcc0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/MSFzDZMFSggS8zZOJuAIUObicfk Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 09:31:56 -0000 --089e012287c61066c9050613bcc0 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 22, 2014 at 7:12 PM, David hayes wrote: > Hi Stefan, > > Thanks for your comments! They are very much appreciated. > > I have added some responses inline. > > Kind regards, > > David > > On Wed, 22 Oct 2014 16:36:32 +0200 > Stefan Holmer wrote: > > > Nice draft! I have a few comments: > > > > You're mentioning that skewness would require all delay measurements > > to be stored, and therefore you're computing some different metric > > which is related to skew. I wonder if it shouldn't be possible to > > more accurately estimate the skew from a histogram instead? That way > > you at least won't need to store all delay measurements. Might not be > > worth the trouble if your metric works well. > > The 3rd central moment is difficult to calculate for a > number of reasons. Yes you need the mean to start with, which would > require storing all the delay measurements so that when you have the > mean, you can compare them with it. The other problem is, that being a > cubic function, it is very sensitive to outliers and therefore requires > a high number of samples for an accurate result. Skew_est is efficient > to calculate and less sensitive to outliers (the test is only above and > below the mean), meaning we don't need quite as many samples. > > > Using a histogram was one of the ideas I looked at. In the end I didn't > go with it for the following reasons. To do this we need to know what a > good bin size is, and probably need to use the same bin size for each > flow (a common base for comparing). If we know the min/max network > delays of every flow we can work out a good bin size, but > generally we don't know this a priori -- and it could also change with > new flows or changes in the network paths. We could use the previous > NT's PDV as a guide for this, but the flows we are comparing with are > probably going to different receivers. In this case we would need to > communicate the information between sender and receivers. > Thanks for the background, I haven't researched this much, so I trust your judgment. :) > > > > > As mentioned by Mirja, it seems a bit error prone to use the max of > > the OWD (also, shouldn't it be max_T(OWD)?) when computing the PDV. > > > > max_T would be more consistent with our notation. Thanks. > > We used max_T instead of min_T because of their relationship to > skew_est in a MM1K queueing model(LCN paper). However, the difference > between MM1K and real networks and the problem of coping with outliers > and may make min_T a better choice. In our tests we did not have any > significant problems, but we would not have had processing delays Mirja > pointed to. > I see. As you say, some way of getting rid of outliers is probably a good idea. > > > Somewhat related to this, I wonder if you have any plans to test this > > algorithm on WiFi? I have seen many cases of WiFi with a lot of > > contention and/or interference, where the delay gets skewed not > > because lack of bandwidth, but because of lower layer retransmissions > > or because the access point was busy serving someone else for a > > moment. I wonder if that can cause you to incorrectly detect shared > > bottlenecks, where in reality there was only a shared WiFi... Now > > that I think of it, the WiFi effect should result in positive > > skewness, while you're looking for negative skewness, so you may be > > ok here. :) > > > Simone has answered here. Thanks! > > > > It would be good to have the diff() operation defined somewhere. Is > > it the diff between successive measurements, or the diff between the > > flows? > > > > Can you elaborate on this suggestion a bit more please. Thanks! > It just wasn't immediately obvious to me if diff() in for instance "diff(freqest) < p_f" took the difference over freqest over time or the difference over pairs of flows at one time instant. I assume it's the latter though? > > > /Stefan > > > > > > On Fri, Oct 10, 2014 at 5:37 PM, David Hayes > > wrote: > > > > > Dear All, > > > > > > We have just submitted of our initial shared bottleneck detection > > > draft and will value your comments and suggestions. > > > > > > Regards, > > > > > > David > > > > > > Begin forwarded message: > > > > > > Date: Fri, 10 Oct 2014 08:17:57 -0700 > > > From: > > > To: Michael Welzl , David Hayes > > > , Michael Welzl , Simone > > > Ferlin , Simone Ferlin , David > > > Hayes Subject: New Version Notification for > > > draft-hayes-rmcat-sbd-00.txt > > > > > > > > > > > > A new version of I-D, draft-hayes-rmcat-sbd-00.txt > > > has been successfully submitted by David Hayes and posted to the > > > IETF repository. > > > > > > Name: draft-hayes-rmcat-sbd > > > Revision: 00 > > > Title: Shared Bottleneck Detection for Coupled > > > Congestion Control for RTP Media. Document date: 2014-10-10 > > > Group: Individual Submission > > > Pages: 12 > > > URL: > > > http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ > > > Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 > > > > > > > > > Abstract: > > > This document describes a mechanism to detect whether end-to-end > > > data flows share a common bottleneck. It relies on summary > > > statistics that are calculated by a data receiver based on > > > continuous measurements and regularly fed to a grouping algorithm > > > that runs wherever the knowledge is needed. This mechanism > > > complements the coupled congestion control mechanism in > > > draft-welzl-rmcat-coupled-cc. > > > > > > > > > > > > > > > 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. > > > > > > The IETF Secretariat > > > > > > > > > > > > -- > > > > > > ------------------------- > > > David Hayes > > > davihay@ifi.uio.no > > > Department of Informatics > > > University of Oslo > > > > > > > > > > -- > > +-------------------------------+ > | David A. Hayes | > | david.hayes@ieee.org | > +-------------------------------+ > --089e012287c61066c9050613bcc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 22, 2014 at 7:12 PM, David hayes <daviha= y@ifi.uio.no> wrote:
Hi Stefan,

Thanks for your comments! They are very much appreciated.

I have added some responses inline.

Kind regards,

David

On Wed, 22 Oct 2014 16:36:32 +0200
Stefan Holmer <ste= fan@webrtc.org> wrote:

> Nice draft! I have a few comments:
>
> You're mentioning that skewness would require all delay measuremen= ts
> to be stored, and therefore you're computing some different metric=
> which is related to skew. I wonder if it shouldn't be possible to<= br> > more accurately estimate the skew from a histogram instead? That way > you at least won't need to store all delay measurements. Might not= be
> worth the trouble if your metric works well.

The 3rd central moment is difficult to calculate for a
number of reasons. Yes you need the mean to start with, which would
require storing all the delay measurements so that when you have the
mean, you can compare them with it. The other problem is, that being a
cubic function, it is very sensitive to outliers and therefore requires
a high number of samples for an accurate result. Skew_est is efficient
to calculate and less sensitive to outliers (the test is only above and
below the mean), meaning we don't need quite as many samples.


Using a histogram was one of the ideas I looked at. In the end I didn't=
go with it for the following reasons. To do this we need to know what a
good bin size is, and probably need to use the same bin size for each
flow (a common base for comparing). If we know the min/max network
delays of every flow we can work out a good bin size, but
generally we don't know this a priori -- and it could also change with<= br> new flows or changes in the network paths. We could use the previous
NT's PDV as a guide for this, but the flows we are comparing with are probably going to different receivers. In this case we would need to
communicate the information between sender and receivers.
<= div>
Thanks for the background, I haven't researched this= much, so I trust your judgment. :)
=C2=A0

>
> As mentioned by Mirja, it seems a bit error prone to use the max of > the OWD (also, shouldn't it be max_T(OWD)?) when computing the PDV= .
>

max_T would be more consistent with our notation. Thanks.

We used max_T instead of min_T because of their relationship to
skew_est in a MM1K queueing model(LCN paper). However, the difference
between MM1K and real networks and the problem of coping with outliers
and may make min_T a better choice. In our tests we did not have any
significant problems, but we would not have had processing delays Mirja
pointed to.

I see. As you say, some way= of getting rid of outliers is probably a good idea.
=C2=A0
=

> Somewhat related to this, I wonder if you have any plans to test this<= br> > algorithm on WiFi? I have seen many cases of WiFi with a lot of
> contention and/or interference, where the delay gets skewed not
> because lack of bandwidth, but because of lower layer retransmissions<= br> > or because the access point was busy serving someone else for a
> moment. I wonder if that can cause you to incorrectly detect shared > bottlenecks, where in reality there was only a shared WiFi... Now
> that I think of it, the WiFi effect should result in positive
> skewness, while you're looking for negative skewness, so you may b= e
> ok here. :)
>
Simone has answered here. Thanks!


> It would be good to have the diff() operation defined somewhere. Is > it the diff between successive measurements, or the diff between the > flows?
>

Can you elaborate on this suggestion a bit more please. Thanks!
<= /blockquote>

It just wasn't immediately obvious to m= e if diff() in for instance "diff(freqest) < p_f" took the difference over freqest = over time or the difference over pairs of flows at one time instant. I assu= me it's the latter though?
=C2=A0

> /Stefan
>
>
> On Fri, Oct 10, 2014 at 5:37 PM, David Hayes <davihay@ifi.uio.no>
> wrote:
>
> > Dear All,
> >
> > We have just submitted of our initial shared bottleneck detection=
> > draft and will value your comments and suggestions.
> >
> > Regards,
> >
> > David
> >
> > Begin forwarded message:
> >
> > Date: Fri, 10 Oct 2014 08:17:57 -0700
> > From: <internet-drafts@ietf.org>
> > To: Michael Welzl <michawe@ifi.uio.no>, David Hayes
> > <daviha= y@ifi.uio.no>, Michael Welzl <michawe@ifi.uio.no>, Simone
> > Ferlin <f= erlin@simula.no>, Simone Ferlin <ferlin@simula.no>, David
> > Hayes <= davihay@ifi.uio.no> Subject: New Version Notification for
> > draft-hayes-rmcat-sbd-00.txt
> >
> >
> >
> > A new version of I-D, draft-hayes-rmcat-sbd-00.txt
> > has been successfully submitted by David Hayes and posted to the<= br> > > IETF repository.
> >
> > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hayes-rmcat-s= bd
> > Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
> > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Shared Bottleneck Detect= ion for Coupled
> > Congestion Control for RTP Media. Document date:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 2014-10-10
> > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission > > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
> > URL:
> > http://www.ietf.org/internet= -drafts/draft-hayes-rmcat-sbd-00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draf= t-hayes-rmcat-sbd/
> > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http:= //tools.ietf.org/html/draft-hayes-rmcat-sbd-00
> >
> >
> > Abstract:
> >=C2=A0 =C2=A0 This document describes a mechanism to detect whethe= r end-to-end
> > data flows share a common bottleneck.=C2=A0 It relies on summary<= br> > > statistics that are calculated by a data receiver based on
> > continuous measurements and regularly fed to a grouping algorithm=
> > that runs wherever the knowledge is needed.=C2=A0 This mechanism<= br> > > complements the coupled congestion control mechanism in
> > draft-welzl-rmcat-coupled-cc.
> >
> >
> >
> >
> > 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.
> >
> > The IETF Secretariat
> >
> >
> >
> > --
> >
> > -------------------------
> > David Hayes
> > davihay@if= i.uio.no
> > Department of Informatics
> > University of Oslo
> >
> >



--

+-------------------------------+
| David A. Hayes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | | david.hayes@ieee= .org=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-------------------------------+

--089e012287c61066c9050613bcc0-- From nobody Thu Oct 23 02:36:49 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75E71A89B4 for ; Thu, 23 Oct 2014 02:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fji7y2dwI1La for ; Thu, 23 Oct 2014 02:36:45 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917AA1A89AF for ; Thu, 23 Oct 2014 02:36:45 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uy5so435423obc.22 for ; Thu, 23 Oct 2014 02:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Y2p72O/1w06NHdNGXBQLjxuarGv/ldqVAPNYVPaiiG4=; b=MOXUOb1av7wL9Yvxh0Aylp06k30Srg4qH9M5J7/ZzZjiL/c+D/4fagn19SG0ECuE5L r3/sEUz69GV3VUq81c+ETNIKhWj6khXjSHJ3rDIyHyJmJOACSfrfogoYo9hIIO8ocZNI RV2ltryYZbyun0HZScOu0J9KwMeIpqebhoVsrGUMEMbpxFrEtVrzVad955AnA0F89+l8 8VjskTOVRzAY+wq5+Dqju/I1OYX9uERWR/YRei5BL5wDRo6vNvdd1HUT/7YGe7eyuiD4 n+Hh55zgOwMVvtdymMw5CbNiQLmgLgSGuvlsOOzrvjvA4uwWVKKb6FNq+h2n6RRid8uW y7iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y2p72O/1w06NHdNGXBQLjxuarGv/ldqVAPNYVPaiiG4=; b=Tsd6ykumoFU4kondG9GIg9Ulm/ie2GgpTuGiOds3T0GtpNOACoH47gGqgvPvS1qPNw cthsPb+WbBtTVqTOOYv4LAUv7/5OydBh5bx6KPTJ2PUEKE8Mw8i+Yac0vhNpnOjvTPtW oq4I/5rMPgG8GDgqIA691EYNpz2KCD9XJ3k59ZLhbVQRmOqymmyguDq8V9I/q00+pARF 7b1vTYmO4vrwXnk76++wrIW6/sVXmxkfbbhaIflMV65V0E/l7cIsG1mE5t/Qson3yhQA G/4QlsEZJuX1f+HYBaFGMxVU6Cfj52TbMntfFXSQPc7Z0ECneSILBXWpa11LSZor6ouz XhCA== X-Gm-Message-State: ALoCoQl/sya9JPThTZKphPaDNQkcDg3ru0NdtenWy+OBBLN1F9zrm0GkyA/+V3n04WvRv8j2Ldi/ MIME-Version: 1.0 X-Received: by 10.202.79.85 with SMTP id d82mr1028148oib.65.1414057004975; Thu, 23 Oct 2014 02:36:44 -0700 (PDT) Sender: holmer@google.com Received: by 10.182.143.71 with HTTP; Thu, 23 Oct 2014 02:36:44 -0700 (PDT) In-Reply-To: <5447ECED.4050904@tik.ee.ethz.ch> References: <20141010173710.1769e033@hayesd-laptop> <5447ECED.4050904@tik.ee.ethz.ch> Date: Thu, 23 Oct 2014 11:36:44 +0200 X-Google-Sender-Auth: VJkCjyFo_MucubYYwL34GNOYzWI Message-ID: From: Stefan Holmer To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a113d7aec797596050613cd4d Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/0rSpuaxzBfSkVHk5EDv0hAosCHc Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , Michael Welzl Welzl , David Hayes Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 09:36:47 -0000 --001a113d7aec797596050613cd4d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We don't have plans for it right now, but I can imagine that it might happen sooner or later. I do think this draft could be useful in for instance mesh conferences where your uplink bottleneck is on your access link. The main question is if it's reliable enough that the benefits clearly are greater than the downsides of incorrect classification. On Wed, Oct 22, 2014 at 7:44 PM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi Stefan, > > asking this because I'm personally curious but also as rmcat chair: > > Are you planning to implement some kind of coupled congestion control in > your system? > > Mirja > > > > On 22.10.2014 16:36, Stefan Holmer wrote: > >> Nice draft! I have a few comments: >> >> You're mentioning that skewness would require all delay measurements to = be >> stored, and therefore you're computing some different metric which is >> related to skew. I wonder if it shouldn't be possible to more accurately >> estimate the skew from a histogram instead? That way you at least won't >> need to store all delay measurements. Might not be worth the trouble if >> your metric works well. >> >> As mentioned by Mirja, it seems a bit error prone to use the max of the >> OWD >> (also, shouldn't it be max_T(OWD)?) when computing the PDV. >> >> Somewhat related to this, I wonder if you have any plans to test this >> algorithm on WiFi? I have seen many cases of WiFi with a lot of contenti= on >> and/or interference, where the delay gets skewed not because lack of >> bandwidth, but because of lower layer retransmissions or because the >> access >> point was busy serving someone else for a moment. I wonder if that can >> cause you to incorrectly detect shared bottlenecks, where in reality the= re >> was only a shared WiFi... Now that I think of it, the WiFi effect should >> result in positive skewness, while you're looking for negative skewness, >> so >> you may be ok here. :) >> >> It would be good to have the diff() operation defined somewhere. Is it t= he >> diff between successive measurements, or the diff between the flows? >> >> /Stefan >> >> >> On Fri, Oct 10, 2014 at 5:37 PM, David Hayes wrote: >> >> Dear All, >>> >>> We have just submitted of our initial shared bottleneck detection >>> draft and will value your comments and suggestions. >>> >>> Regards, >>> >>> David >>> >>> Begin forwarded message: >>> >>> Date: Fri, 10 Oct 2014 08:17:57 -0700 >>> From: >>> To: Michael Welzl , David Hayes >>> , Michael Welzl , Simone Ferlin >>> , Simone Ferlin , David Hayes >>> Subject: New Version Notification for >>> draft-hayes-rmcat-sbd-00.txt >>> >>> >>> >>> A new version of I-D, draft-hayes-rmcat-sbd-00.txt >>> has been successfully submitted by David Hayes and posted to the >>> IETF repository. >>> >>> Name: draft-hayes-rmcat-sbd >>> Revision: 00 >>> Title: Shared Bottleneck Detection for Coupled >>> Congestion Control for RTP Media. Document date: 2014-10-10 >>> Group: Individual Submission >>> Pages: 12 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ >>> Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 >>> >>> >>> Abstract: >>> This document describes a mechanism to detect whether end-to-end da= ta >>> flows share a common bottleneck. It relies on summary statistics >>> that are calculated by a data receiver based on continuous >>> measurements and regularly fed to a grouping algorithm that runs >>> wherever the knowledge is needed. This mechanism complements the >>> coupled congestion control mechanism in draft-welzl-rmcat-coupled-c= c. >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >>> >>> >>> -- >>> >>> ------------------------- >>> David Hayes >>> davihay@ifi.uio.no >>> Department of Informatics >>> University of Oslo >>> >>> >>> >> > -- > ------------------------------------------ > Dipl.-Ing. Mirja K=C3=BChlewind > Communication Systems Group > Institute TIK, ETH Z=C3=BCrich > Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland > > Room ETZ G93 > phone: +41 44 63 26932 > email: mirja.kuehlewind@tik.ee.ethz.ch > ------------------------------------------ > --001a113d7aec797596050613cd4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We don't have plans for it right now, but I can imagin= e that it might happen sooner or later. I do think this draft could be usef= ul in for instance mesh conferences where your uplink bottleneck is on your= access link. The main question is if it's reliable enough that the ben= efits clearly are greater than the downsides of incorrect classification.

On Wed, Oct 22,= 2014 at 7:44 PM, Mirja K=C3=BChlewind <mir= ja.kuehlewind@tik.ee.ethz.ch> wrote:
Hi Stefan,

asking this because I'm personally curious but also as rmcat chair:

Are you planning to implement some kind of coupled congestion control in yo= ur system?

Mirja



On 22.10.2014 16:36, Stefan Holmer wrote:
Nice draft! I have a few comments:

You're mentioning that skewness would require all delay measurements to= be
stored, and therefore you're computing some different metric which is related to skew. I wonder if it shouldn't be possible to more accuratel= y
estimate the skew from a histogram instead? That way you at least won't=
need to store all delay measurements. Might not be worth the trouble if
your metric works well.

As mentioned by Mirja, it seems a bit error prone to use the max of the OWD=
(also, shouldn't it be max_T(OWD)?) when computing the PDV.

Somewhat related to this, I wonder if you have any plans to test this
algorithm on WiFi? I have seen many cases of WiFi with a lot of contention<= br> and/or interference, where the delay gets skewed not because lack of
bandwidth, but because of lower layer retransmissions or because the access=
point was busy serving someone else for a moment. I wonder if that can
cause you to incorrectly detect shared bottlenecks, where in reality there<= br> was only a shared WiFi... Now that I think of it, the WiFi effect should result in positive skewness, while you're looking for negative skewness= , so
you may be ok here. :)

It would be good to have the diff() operation defined somewhere. Is it the<= br> diff between successive measurements, or the diff between the flows?

/Stefan


On Fri, Oct 10, 2014 at 5:37 PM, David Hayes <davihay@ifi.uio.no> w= rote:

Dear All,

We have just submitted of our initial shared bottleneck detection
draft and will value your comments and suggestions.

Regards,

David

Begin forwarded message:

Date: Fri, 10 Oct 2014 08:17:57 -0700
From: <internet-drafts@ietf.org>
To: Michael Welzl <michawe@ifi.uio.no>, David Hayes
<davihay@ifi.uio.no>, Michael Welzl <michawe@ifi.uio.no>, S= imone Ferlin
<= ferlin@simula.no>, Simone Ferlin <ferlin@simula.no>, David Hay= es
<davihay@ifi.uio.no> Subject: New Version Notification for
draft-hayes-rmcat-sbd-00.txt



A new version of I-D, draft-hayes-rmcat-sbd-00.txt
has been successfully submitted by David Hayes and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hayes-rmcat-sbd
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Shared Bottleneck Detection for Co= upled
Congestion Control for RTP Media. Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0= 2014-10-10
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:
http://www.ietf.org/internet-dr= afts/draft-hayes-rmcat-sbd-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ie= tf.org/html/draft-hayes-rmcat-sbd-00


Abstract:
=C2=A0 =C2=A0 This document describes a mechanism to detect whether end-to-= end data
=C2=A0 =C2=A0 flows share a common bottleneck.=C2=A0 It relies on summary s= tatistics
=C2=A0 =C2=A0 that are calculated by a data receiver based on continuous =C2=A0 =C2=A0 measurements and regularly fed to a grouping algorithm that r= uns
=C2=A0 =C2=A0 wherever the knowledge is needed.=C2=A0 This mechanism comple= ments the
=C2=A0 =C2=A0 coupled congestion control mechanism in draft-welzl-rmcat-cou= pled-cc.




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.

The IETF Secretariat



--

-------------------------
David Hayes
da= vihay@ifi.uio.no
Department of Informatics
University of Oslo




--
------------------------------------------
Dipl.-Ing. Mirja K=C3=BChlewind
Communication Systems Group
Institute TIK, ETH Z=C3=BCrich
Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: mirja.kuehlewind@tik.ee.ethz.ch
------------------------------------------

--001a113d7aec797596050613cd4d-- From nobody Thu Oct 23 02:51:27 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06B61A8A3D for ; Thu, 23 Oct 2014 02:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_RX4j3OgNto for ; Thu, 23 Oct 2014 02:51:22 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8ED31A8A20 for ; Thu, 23 Oct 2014 02:51:21 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-11-5448cf973b63 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.4B.21334.79FC8445; Thu, 23 Oct 2014 11:51:19 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.251]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 11:51:19 +0200 From: Zaheduzzaman Sarker To: Stefan Holmer , Michael Welzl Thread-Topic: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt Thread-Index: AQHP7RCEeWzDZrv0j0WSBFtdnPjVDJw6jgyAgAGzyICAAOAsgIAAKbgAgAAmEAA= Date: Thu, 23 Oct 2014 09:51:18 +0000 Message-ID: References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> <20141021173659.44ecd880@hayesd-laptop> <5447EB2B.9070302@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_E0F7A68B07B53F4FBD12DABD61CBA90E127CCF25ESESSMB307erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM+Jvje708x4hBid3WVp8v/uf3aJxZ77F j7M7WS02rJ7CYrH65gc2i66Dp5gd2DyWLPnJ5LF69UNmj20dh9k9jn34yubxe98itgDWKC6b lNSczLLUIn27BK6MiWfmMhcsyq5oP3WIqYFxTUYXIyeHhICJxPMF61ghbDGJC/fWs3UxcnEI CRxllDj8r4kRwlnCKLHm7AWgDAcHm4CNxOPFfiANIgKeEm8X/mcCqWEW2Mco0fT+NztIQlgg ROLp2x42iKJQiV03+hghbD+JJd96wGwWAVWJRxM2gdXzCvhKnOlcywSxbB6TxO19p8ASnAKB EmuXtzKB2IxA530/tQbMZhYQl7j1ZD4TxNkCEkv2nGeGsEUlXj7+B/WOosTHV/sYQY5mFsiX mHJFBmKXoMTJmU9YJjCKzkIyaRZC1SwkVRBhTYn1u/QhqhUlpnQ/ZIewNSRa58xlRxZfwMi+ ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwYg9u+a27g3H1a8dDjAIcjEo8vAkzPUKEWBPL iitzDzFKc7AoifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjBjZx0Rs6ArdmFgYz m52uD7Z6+TI5lUGHs/R81tbZ019ff//E8pXnG01ZcYbcS3cDHT0iI0MmfFjYlHfN3OTE8Ssc vqxd4bFN1ud9d3ZMEr7ypSCrz9NpQV2pqtMPt7rw17ozSw7sPXWqieeuwx2bmFXbbndtnLni e3BA1/aFa6uDNlubrdirxFKckWioxVxUnAgAxoM/FbkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/OoeS5x_MY0lmaETQcSPZMqjPbUU Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , David Hayes Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 09:51:24 -0000 --_000_E0F7A68B07B53F4FBD12DABD61CBA90E127CCF25ESESSMB307erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgd291bGQgYWxzbyBsaWtlIHRvIHNlZSBzb21lIHN0YXRpc3RpY3Mgb24gdGhlIGZh bHNlIHBvc2l0aXZlcyB3aGlsZSBkZXRlY3RpbmcgdGhlIHNoYXJlZCBib3R0bGVuZWNrIHdpdGgg dGhpcyBtZXRob2QuDQoNCkJSDQoNClphaGVkDQoNCkZyb206IHJtY2F0IFttYWlsdG86cm1jYXQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZWZhbiBIb2xtZXINClNlbnQ6IGRlbiAy MyBva3RvYmVyIDIwMTQgMTE6MjgNClRvOiBNaWNoYWVsIFdlbHpsDQpDYzogcm1jYXRAaWV0Zi5v cmc7IFNpbW9uZSBGZXJsaW4tT2xpdmVpcmE7IE1pcmphIEvDvGhsZXdpbmQ7IERhdmlkIEhheWVz DQpTdWJqZWN0OiBSZTogW3JtY2F0XSBGdzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1oYXllcy1ybWNhdC1zYmQtMDAudHh0DQoNCg0KDQpPbiBUaHUsIE9jdCAyMywgMjAxNCBh dCA4OjU5IEFNLCBNaWNoYWVsIFdlbHpsIDxtaWNoYXdlQGlmaS51aW8ubm88bWFpbHRvOm1pY2hh d2VAaWZpLnVpby5ubz4+IHdyb3RlOg0KSGksDQoNCk1heWJlIEkgY2FuIGhlbHAgd2l0aCB0aGlz IGJpdCAoYW5kIEkgaG9wZSBEYXZpZCB3aWxsIGNvcnJlY3QgbWUgaW4gY2FzZSBJIHB1dCB0aGlz IHdyb25nbHkpIC0NCg0KT24gMjIuIG9rdC4gMjAxNCwgYXQgMTk6MzYsIE1pcmphIEvDvGhsZXdp bmQgd3JvdGU6DQoNCj4gSGkgRGF2aWQsDQo+DQo+IGp1c3QgYWdhaW4gb24gdGhlIHNrZXduZXNz IHBvaW50OiBGb3JtIG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZyB3aGF0IHlvdSBzb21laG93IHdh bnQgdG8gbWVhc3VyZSB3aXRoIHRoaXMgaXMgc29tZXRoaW5nIGxpa2UgYSBzdGFuZGluZyBxdWV1 ZS4uPyBTdGlsbCB0aGUgd2F5IHlvdSBjYWxjdWxhdGUgdGhlIHNrZXduZXNzIHNlZW1zIHZlcnkg YWJzdHJhY3QgdG8gbWUuDQoNCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgaW50dWl0aW9u IGJlaGluZCB1c2luZyBza2V3bmVzcyBpcyB0aGF0IHlvdSdkIGdldCBhIG5lZ2F0aXZlIHNrZXdu ZXNzIGluIHRoZSBPV0QgZGlzdHJpYnV0aW9uIG9ubHkgaWYgeW91IGhhdmUgKGNvbW1vbikgY29u Z2VzdGlvbiAodGhlIHF1ZXVlIGlzIG9mdGVuIGZ1bGwgYW5kIHNvbWV0aW1lcyBkcmFpbnMpLg0K DQpZZXMsIHRoYXQgd2FzIG15IGZpbmFsIGNvbmNsdXNpb24gYWJvdXQgc2tld25lc3MgYXMgd2Vs bCB3aGVuIHJlYWRpbmcgdGhlIGRyYWZ0LiBJIHRoaW5rIHRoYXQgYWxzbyBzaG91bGQgaGVscCBh dm9pZCBmYWxzZSBjbGFzc2lmaWNhdGlvbnMgb2YgY29uZ2VzdGlvbiB3aGVuIHRoZSBjaGFubmVs IHBlcmlvZGljYWxseSBnb2VzIHNpbGVudCwgZm9yIGluc3RhbmNlIG9uIHNvbWUgV2lGaXMuIERv IHlvdSBndXlzIGhhdmUgYW55IGlkZWEgb2Ygd2hlbiB0aGlzIG1ldHJpYyBtaWdodCBmYWlsPw0K DQoNCg0KPiBIb3dldmVyLCBpZiBpdCBjYW4gYmUgc2hvd24gdGhhdCB0aGlzIHByb3ZpZGVzIHVz ZWZ1bCBpbmZvcm1hdGlvbiwgaXQgZGVmaW5pdGVseSBzaG91bGQgYmUgdXNlZC4gVGhlIHF1ZXN0 aW9uIChmb3IgYWxsIHRoZSBtZXRyaWNzIHRoYXQgeW91IHByb3Bvc2UpIGlzIGhvdyBjYW4geW91 IHNob3cgdGhhdCB0aGVzZSBhcmUgdGhlIHJpZ2h0IG1ldHJpY3MuIE9uZSBhcHByb2FjaCBpcyBk ZWZpbml0ZWx5IHRvIGRvIG1vcmUgbWVhc3VyZW1lbnRzIGluIHZhcmlvdXMgc2NlbmFyaW8gYnV0 IGNvdWxkIHlvdSBhbHNvIGFzc2VzcyB0aGUgcmlzayBvZiBmYWlsdXJlcz8gT3IgKGFuZCB0aGlz IHBvdGVudGlhbGx5IGlzIG1vcmUgYSBxdWVzdGlvbiBmb3IgdGhlIGNjIGNvbmdlc3Rpb24pIGhv dyBiYWQgaXMgaWYgeW91IGdyb3VwIHR3byBmbG93cyB0b2dldGhlciB3cm9uZ2x5Pw0KDQpJbmRl ZWQgdGhhdCdzIGEgcXVlc3Rpb24gYWJvdXQgY291cGxlZC1jYy4gTXkgYW5zd2VyIHRvICJob3cg YmFkIGlzIGl0IC4uLiIgaXM6IHRoZSBiZWhhdmlvciBjYW4gYmUgdmVyeSB3cm9uZy4gRS5nLiwg YXNzdW1lIHByaW9yaXRpZXMgb2YgMS8xMCB2cy4gMS4gQ291cGxlZC1jYyB3aWxsIHRha2UgdGhl IHRvdGFsIGFuZCBkaXZpZGUgdGhlIHJhdGVzIGFjY29yZGluZ2x5LiBJZiB0aGVzZSBmbG93cyBk b24ndCBzaGFyZSBhIGNvbW1vbiBib3R0bGVuZWNrLCB0aGF0J3MganVzdCBhIHZlcnkgd3Jvbmcg dGhpbmcgdG8gZG8gLSB5b3UgbWF5IGVuZCB1cCBnaXZpbmcgb25lIGZsb3cgbXVjaCBsZXNzIGFu ZCBhbm90aGVyIGZsb3cgbXVjaCBtb3JlIHRoYW4gaXRzIG93biBjb25nZXN0aW9uIGNvbnRyb2xs ZXIgaGFzIGRlcml2ZWQuDQoNCkkgdGhpbmsgdGhhdCBzb3J0IG9mIHByb2JsZW0gaXMgdW5hdm9p ZGFibGU7IHRoZSBiZXN0IG9uZSBjYW4gZG8gaXMgdG8gdHJ5IHRvIGdldCB0aGUgc2hhcmVkIGJv dHRsZW5lY2sgZGV0ZWN0aW9uIHNjaGVtZSB0byBiZSBhcyByZWxpYWJsZSBhcyBwb3NzaWJsZSAo d2hpY2ggaXMgYSBwYXJ0IG9mIHdoeSB0aGlzIHdvcmsgdG9vayB1cyBhIGxvbmcgdGltZSwgd2Ug cmVhbGx5IGRvIGJlbGlldmUgdGhhdCB0aGlzIGlzIHByZXR0eSByZWxpYWJsZSkgYW5kIHVzZSBp dCBjb25zZXJ2YXRpdmVseTogZS5nLiwgb25lIGNvdWxkIHR1cm4gb24gY291cGxpbmcgb25seSBh ZnRlciBhIG1pbnV0ZSBvciBtdWx0aXBsZSBtaW51dGVzIG9mIGEgc3RhYmxlIHBvc2l0aXZlIHNp Z25hbCwgYW5kIGltbWVkaWF0ZWx5IHR1cm4gaXQgb2ZmIGluIGNhc2Ugb2YgYSBuZWdhdGl2ZSBv bmUuIFRoaXMgd291bGQgYmUgZXh0cmVtZWx5IGNvbnNlcnZhdGl2ZSwgYnV0IEknbSBqdXN0IHNh eWluZyBpdCdzIGEgcGFyYW1ldGVyIHRoYXQgY2FuIGJlIHR1bmVkLg0KDQpDaGVlcnMsDQpNaWNo YWVsDQoNCg== --_000_E0F7A68B07B53F4FBD12DABD61CBA90E127CCF25ESESSMB307erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VnJpbmRhOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VnJpbmRhOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K c3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBhbHNvIGxpa2UgdG8gc2VlIHNv bWUgc3RhdGlzdGljcyBvbiB0aGUgZmFsc2UgcG9zaXRpdmVzIHdoaWxlIGRldGVjdGluZyB0aGUg c2hhcmVkIGJvdHRsZW5lY2sgd2l0aCB0aGlzIG1ldGhvZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlphaGVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJtY2F0IFttYWlsdG86cm1jYXQtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3RlZmFuIEhvbG1lcjxicj4NCjxiPlNlbnQ6 PC9iPiBkZW4gMjMgb2t0b2JlciAyMDE0IDExOjI4PGJyPg0KPGI+VG86PC9iPiBNaWNoYWVsIFdl bHpsPGJyPg0KPGI+Q2M6PC9iPiBybWNhdEBpZXRmLm9yZzsgU2ltb25lIEZlcmxpbi1PbGl2ZWly YTsgTWlyamEgS8O8aGxld2luZDsgRGF2aWQgSGF5ZXM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtybWNhdF0gRnc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGF5ZXMtcm1j YXQtc2JkLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUaHUsIE9jdCAyMywgMjAxNCBhdCA4OjU5IEFNLCBNaWNoYWVsIFdlbHpsICZsdDs8YSBocmVm PSJtYWlsdG86bWljaGF3ZUBpZmkudWlvLm5vIiB0YXJnZXQ9Il9ibGFuayI+bWljaGF3ZUBpZmku dWlvLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSw8YnI+DQo8YnI+DQpNYXliZSBJIGNhbiBoZWxwIHdpdGggdGhpcyBiaXQgKGFuZCBJIGhv cGUgRGF2aWQgd2lsbCBjb3JyZWN0IG1lIGluIGNhc2UgSSBwdXQgdGhpcyB3cm9uZ2x5KSAtPGJy Pg0KPGJyPg0KT24gMjIuIG9rdC4gMjAxNCwgYXQgMTk6MzYsIE1pcmphIEvDvGhsZXdpbmQgd3Jv dGU6PGJyPg0KPGJyPg0KJmd0OyBIaSBEYXZpZCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBqdXN0IGFn YWluIG9uIHRoZSBza2V3bmVzcyBwb2ludDogRm9ybSBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcg d2hhdCB5b3Ugc29tZWhvdyB3YW50IHRvIG1lYXN1cmUgd2l0aCB0aGlzIGlzIHNvbWV0aGluZyBs aWtlIGEgc3RhbmRpbmcgcXVldWUuLj8gU3RpbGwgdGhlIHdheSB5b3UgY2FsY3VsYXRlIHRoZSBz a2V3bmVzcyBzZWVtcyB2ZXJ5IGFic3RyYWN0IHRvIG1lLjxicj4NCjxicj4NCk15IHVuZGVyc3Rh bmRpbmcgaXMgdGhhdCB0aGUgaW50dWl0aW9uIGJlaGluZCB1c2luZyBza2V3bmVzcyBpcyB0aGF0 IHlvdSdkIGdldCBhIG5lZ2F0aXZlIHNrZXduZXNzIGluIHRoZSBPV0QgZGlzdHJpYnV0aW9uIG9u bHkgaWYgeW91IGhhdmUgKGNvbW1vbikgY29uZ2VzdGlvbiAodGhlIHF1ZXVlIGlzIG9mdGVuIGZ1 bGwgYW5kIHNvbWV0aW1lcyBkcmFpbnMpLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+WWVzLCB0aGF0IHdhcyBteSBmaW5hbCBjb25jbHVzaW9uIGFib3V0IHNr ZXduZXNzIGFzIHdlbGwgd2hlbiByZWFkaW5nIHRoZSBkcmFmdC4gSSB0aGluayB0aGF0IGFsc28g c2hvdWxkIGhlbHAgYXZvaWQgZmFsc2UgY2xhc3NpZmljYXRpb25zIG9mIGNvbmdlc3Rpb24gd2hl biB0aGUgY2hhbm5lbCBwZXJpb2RpY2FsbHkgZ29lcyBzaWxlbnQsIGZvciBpbnN0YW5jZSBvbiBz b21lIFdpRmlzLiBEbyB5b3UgZ3V5cw0KIGhhdmUgYW55IGlkZWEgb2Ygd2hlbiB0aGlzIG1ldHJp YyBtaWdodCBmYWlsPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4N CiZndDsgSG93ZXZlciwgaWYgaXQgY2FuIGJlIHNob3duIHRoYXQgdGhpcyBwcm92aWRlcyB1c2Vm dWwgaW5mb3JtYXRpb24sIGl0IGRlZmluaXRlbHkgc2hvdWxkIGJlIHVzZWQuIFRoZSBxdWVzdGlv biAoZm9yIGFsbCB0aGUgbWV0cmljcyB0aGF0IHlvdSBwcm9wb3NlKSBpcyBob3cgY2FuIHlvdSBz aG93IHRoYXQgdGhlc2UgYXJlIHRoZSByaWdodCBtZXRyaWNzLiBPbmUgYXBwcm9hY2ggaXMgZGVm aW5pdGVseSB0byBkbyBtb3JlIG1lYXN1cmVtZW50cyBpbg0KIHZhcmlvdXMgc2NlbmFyaW8gYnV0 IGNvdWxkIHlvdSBhbHNvIGFzc2VzcyB0aGUgcmlzayBvZiBmYWlsdXJlcz8gT3IgKGFuZCB0aGlz IHBvdGVudGlhbGx5IGlzIG1vcmUgYSBxdWVzdGlvbiBmb3IgdGhlIGNjIGNvbmdlc3Rpb24pIGhv dyBiYWQgaXMgaWYgeW91IGdyb3VwIHR3byBmbG93cyB0b2dldGhlciB3cm9uZ2x5Pzxicj4NCjxi cj4NCkluZGVlZCB0aGF0J3MgYSBxdWVzdGlvbiBhYm91dCBjb3VwbGVkLWNjLiBNeSBhbnN3ZXIg dG8gJnF1b3Q7aG93IGJhZCBpcyBpdCAuLi4mcXVvdDsgaXM6IHRoZSBiZWhhdmlvciBjYW4gYmUg dmVyeSB3cm9uZy4gRS5nLiwgYXNzdW1lIHByaW9yaXRpZXMgb2YgMS8xMCB2cy4gMS4gQ291cGxl ZC1jYyB3aWxsIHRha2UgdGhlIHRvdGFsIGFuZCBkaXZpZGUgdGhlIHJhdGVzIGFjY29yZGluZ2x5 LiBJZiB0aGVzZSBmbG93cyBkb24ndCBzaGFyZSBhIGNvbW1vbiBib3R0bGVuZWNrLA0KIHRoYXQn cyBqdXN0IGEgdmVyeSB3cm9uZyB0aGluZyB0byBkbyAtIHlvdSBtYXkgZW5kIHVwIGdpdmluZyBv bmUgZmxvdyBtdWNoIGxlc3MgYW5kIGFub3RoZXIgZmxvdyBtdWNoIG1vcmUgdGhhbiBpdHMgb3du IGNvbmdlc3Rpb24gY29udHJvbGxlciBoYXMgZGVyaXZlZC48YnI+DQo8YnI+DQpJIHRoaW5rIHRo YXQgc29ydCBvZiBwcm9ibGVtIGlzIHVuYXZvaWRhYmxlOyB0aGUgYmVzdCBvbmUgY2FuIGRvIGlz IHRvIHRyeSB0byBnZXQgdGhlIHNoYXJlZCBib3R0bGVuZWNrIGRldGVjdGlvbiBzY2hlbWUgdG8g YmUgYXMgcmVsaWFibGUgYXMgcG9zc2libGUgKHdoaWNoIGlzIGEgcGFydCBvZiB3aHkgdGhpcyB3 b3JrIHRvb2sgdXMgYSBsb25nIHRpbWUsIHdlIHJlYWxseSBkbyBiZWxpZXZlIHRoYXQgdGhpcyBp cyBwcmV0dHkgcmVsaWFibGUpDQogYW5kIHVzZSBpdCBjb25zZXJ2YXRpdmVseTogZS5nLiwgb25l IGNvdWxkIHR1cm4gb24gY291cGxpbmcgb25seSBhZnRlciBhIG1pbnV0ZSBvciBtdWx0aXBsZSBt aW51dGVzIG9mIGEgc3RhYmxlIHBvc2l0aXZlIHNpZ25hbCwgYW5kIGltbWVkaWF0ZWx5IHR1cm4g aXQgb2ZmIGluIGNhc2Ugb2YgYSBuZWdhdGl2ZSBvbmUuIFRoaXMgd291bGQgYmUgZXh0cmVtZWx5 IGNvbnNlcnZhdGl2ZSwgYnV0IEknbSBqdXN0IHNheWluZyBpdCdzIGEgcGFyYW1ldGVyDQogdGhh dCBjYW4gYmUgdHVuZWQuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCk1pY2hhZWw8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_E0F7A68B07B53F4FBD12DABD61CBA90E127CCF25ESESSMB307erics_-- From nobody Thu Oct 23 04:55:27 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9521A9029 for ; Thu, 23 Oct 2014 04:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_VPCp0Ei8UG for ; Thu, 23 Oct 2014 04:55:22 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3EF91A8F38 for ; Thu, 23 Oct 2014 04:55:22 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id at20so740922iec.6 for ; Thu, 23 Oct 2014 04:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=8V81N+tHUb0FurQzu2zfthx7fL/ed/CvC5s8PC6jQV4=; b=DqmiiiTN5I2Bat0tLKgjVbGeQHaYjitQbncKmxK0lhJ2FyZmH0a3nVtw3bO0JWL/7g H61Ds6GKk5bzOP7scWf9Ya8HrG1vB0QX4+WT3duOw56QYKYMF1K3EbbJPhWzF3dALyI0 UlKCaFmQBEiddjZPE9OkdoMp6THRDgbiD0tIz54yPKdeE4MwApQAUCu1Hf89ME9dVBoU e3GJ2rQR9+hK2IK8i+ncxp1UTjeQlwrbUru9Sq2E9zrqhPBaotYTXpd7R4TkfGNpVP5s qDzFX8IwS+0Nq8XrChOL0G1zauB+1mNWiv9dyS4un2cpyz8GpNry8u7HH8CALoN9S4/V UXHg== X-Received: by 10.42.228.4 with SMTP id jc4mr455021icb.96.1414065321986; Thu, 23 Oct 2014 04:55:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.114.138 with HTTP; Thu, 23 Oct 2014 04:55:00 -0700 (PDT) In-Reply-To: <543BF68A.6070508@tik.ee.ethz.ch> References: <543BF68A.6070508@tik.ee.ethz.ch> From: Varun Singh Date: Thu, 23 Oct 2014 14:55:00 +0300 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/Ev_T76FU1aPEmyQzsdfGjqoOvJ8 Cc: "rmcat@ietf.org" , Joerg Ott Subject: Re: [rmcat] review of draft-ietf-rmcat-eval-criteria-02 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 11:55:26 -0000 Hi Mirja, Thank you for the feedback and apologies for the tardiness, I needed to resync with the other drafts. Comments inline. On Mon, Oct 13, 2014 at 6:58 PM, Mirja K=C3=BChlewind wrote: > Hi Varun, > > I reviewed the draft-ietf-rmcat-eval-criteria-02 document as an individua= l > contributor (not w-g- chair). I have a couple of general comments and a s= et > of more detailed comments below. > > For me it is currently not very clear what the purpose of this document i= s > (in relation to the reqs doc and the test scenarios doc). Form my point o= f > view the requirement document is (mainly) written for people who would li= ke > to develop a new rmcat algorithm. I think this document should address > people who want to evaluate an (existing) proposal by not only implementi= ng The idea of the criteria document was to create guidelines that the test documents could either follow or fulfill. > the initial test scenarios but e.g. perform additional tests to check if = the > initial requirements can be fulfilled. Therefore this document should rel= ate > closely to the reqs document (while not stating new requirements!). > True, this document should not generate new congestion control requirements. The motivation behind the guidelines section was to have a set of requirements for the test cases. i.e., the congestion control behaviour is described by the requirements document, while the test-cases documents attempt to fulfil the guidelines in the criteria document. However, the text currently in the document may appear as the new congestion control requirements. More discussion below. > Therefore I would see the following topics as content of this document: > > 1. Summary of the requirements (of draft-ietf-rmcat-cc-requirements): > This should only be a very brief summary mainly pointing to the other > document. If you look at draft-ietf-rmcat-cc-requirements there might be > even some requirements that do not need (simulative/testbed) evaluation e= .g. > the amount of overhead. Further you could add to the list some of the > 'classical requirements' as convergence/stability (and provide a respecti= ve > reference) but I believe these requirements are all somehow covered by > draft-ietf-rmcat-cc-requirements...? > > 2. List of metric and parameters: > Currently section 3 has 2 lists which overlap to some extend. Further the= re > is another list in draft-ietf-rmcat-eval-test. I believe there should be = ONE > list in the eval document and the test document should relate to this. > However, the description of which data should be traced i would rather se= e > as a part of draft-ietf-rmcat-eval-test. More detailed comments further > below. > Further I have the feeling that the metrics described in RFC5166 are not > comprehensive, e.g. minimizing oscillations is rather a requirement than = a > metric from my perspective. Therefore we should define our own list here = (of > course this referring RFC5166) and also focus on metrics that are related= to > media congestion control (where we e.g. might have application-limited > traffic). > Yes, RFC5166 was a starting point. I was hoping that the metrics section would firm up when we have more proposals/evaluations. Perhaps after Honolulu, we'll have a better list of metrics. > Further, I would list parameters that can be varied in the evaluation and > potentially even discuss a sensible range for evaluation, e.g. there is a > maximum (base) RTT as we talk about the Internet and usually avoid to rou= te > the traffic several times around the world. > Sure, I agree with the general guidance and am happy to add values that make sense. Earlier version carried RTT and loss tables, which have since moved to the appendix of eval-test -- in an attempt to make this document more generic. > 3. Guideline for evaluation (scenarios): > Here is would like to see all three things from above to be set into > relation: To evaluate a certain requirement (or set of related > requirements), you can vary these parameter in this range and then look a= t > this metric and you would expect a results/value of the metric in this > range. > > I know, this more or less proposes a completely different document but th= is > is just a proposal. Again for me the purpose of the currently document is > not very clear anymore. Otherwise you would need to find a way to further I think there are at least multiple ways to do this: 1. To test the follow requirement vary these parameters, or doing this test fulfils a set of requirements. 2. These kind of network/traffic behaviour exists, check how the proposal performs in these scenarios. I suppose we want to find a way to express both in this document. > explain in the existing document what the purpose and goals of this docum= ent > are. If you plan a wider revision and would like to get some more input, = I'm > also willing to contribute text. Just let me know. Or we can sit together= in > Honolulu if you think that's helpful. > > > Here some more detailed comments: > > Section 3: Metrics > ------------------ > - 'minimizing oscillations' is a requirement for me; e.g. oscillation siz= e > would be a metric defined as e.g. the difference between the minimum send= ing > rate/window and the next maximum or the difference between the min and ma= x > within a given time frame.. > There needs to be component of frequency of oscillations too, i.e., number of times it oscillates between a max and min. Because it could just be ramping up or ramping down. The timescales to measure this are important, partly because the media is data limited and it may generate video which is bursty. > - 'Reactivity': I'm used to the term responsiveness instead; again this i= s a > requirement for me while convergence time (as given in RFC5166) is the > respective metric for evaluation > I agree. > - 'packet loss and discards': What's the difference between a loss and a > discard and why is this listed separately? Is this in number of packets o= r Discards, unlike lost packets are received by the RTP endpoint but discarded by the dejitter buffer because it was arrived too late to be played back. > bytes? Or do you mean the loss rate (=3Dtotal number of pkt/bytes divided= by Here it is packets. But we can have Packets sent, packets lost, packets discarded. Similarly Bytes sent, bytes lost, bytes discarded. > the lost pkts/bytes over a certain time interval)? > There was some discussion in the eval-test to do 200ms or 500ms. > - 'Section 2.1 of [RFC5166] discusses the tradeoff between > throughput, delay and loss.' is not a metric > I suppose this is an open issue of sort, we need a metric for comparing performance of a proposal when it can be tuned to give higher throughput at expense of some loss and delay. Or, when comparing across proposals: when there are no losses or comparative delay, we would prefer the one with higher throughput. For the oscillations, responsiveness, and the trade-off metric: I am hoping that we would be able to get better insight into measuring these metrics more accurately when we have more comparative evaluations. > - 'Thoughput', 'Sending rate, Receiver rate, Goodput' and 'Bandwidth > Utilization' are all very closely connected might not need to be treated Goodput is the bytes in an interval fed into the decoder. This removes the packet overheads and any packets that were discarded by the dejitter buffer. > separately. I think the metric that is of interest is utilization while y= ou > usually need to measure the sending rate to actually get the utilization.= As True we need the sending rate, easily possible in controlled simulation environments and testbeds. > I stated above I would see this part, what exactly to measure (and also > where!), as part of draft-ietf-rmcat-eval-test. It could also be a part o= f > this document but might make the test document more complicated. In any c= ase > which data to trace in the measurement and metrics for statistical > evaluation should be discussed separately. And one more comment regarding > the sending/receiving rate: these are usually bytes over a certain time > frame and the length of the time frame should be defined (together with t= he > evaluation metric that is using this data); I usually use a time interval= of > two RTTs. > I think during the tests we were thinking about 200 or 500ms. If the RTTs are low and too few video frames are generated, we might get 0 frames in that interval. I dont have a strong opinion about this, but may be Zahed can weigh in, as his proposal sometimes drops a few video frames to test (unloaded) delay? > - The discussion on fairness/unfairness does not belong in this section b= ut > in the next. In this section there are two metrics which might be of > interest: jains fairness index and/or the ratio of the average throughput= of > one flow to another (or the ratio of groups of flows) over a certain time > interval > > - In point 7 'stable rate' needs to be defined. I usually use e.g. time t= o > reach 80%/95% of the equal share (or a desired/given rate in media > transmissions...?) There is something similar done in > draft-irtf-iccrg-tcpeval section 5.3.3. > It makes senses to check stability in a few simple scenarios: when there no cross traffic, fixed network characteristics (i think we have one of these in the test-cases), but is unlikely going to apply to an LTE scenario. Will look in to this, thanks for the pointer. > - Regarding your question on Jains fairness index: I think this is a > valuable metric (as mentioned above) only the term fairness is wrong. Thi= s > metric give an impression if the capacity is shared equally between > competing flows or groups of flows. There are evaluation scenarios where > this is desired, e.g. when two flow compete using the same congestion > control algorithm and the same traffic model (in our case, might even sen= d > the same video) > Will fold it in. > - Section 3.1. would go into the test document from my current point of > view. > > - And regarding tracing (which might go into the test doc): wouldn't it b= e > useful for some evaluations to trace the congestion window (if possible) > because this might be larger than the sending rate...? > This is something that the proposals should point out. In my opinion, I have not made any significant changes to the metrics section since the first version, mainly because we haven't discussed the proposal evaluations in much detail. I think this will be fixed after the upcoming IETF meeting and we'll see more metrics. > > Section 4: Guidelines > --------------------- > This section currently describes some requirements (Avoiding Congestion > Collapse and Stability) as well as part of the traffic model and network > model. > I would propose to have the parameter discussion as mentioned above. Furt= her > the parameter discussion should be separated into traffic and network > parameter. This would integrate some text from section 4.3., 4.8. and 4.9= . > (traffic model) as well as 4.4., 4.5. 4.6. and 4.7. (network model). And > then use this section to give guidance how to evaluate the requirements i= n > draft-ietf-rmcat-cc-requirements. > > Further this document should rely on e.g. draft-irtf-iccrg-tcpeval-01 and > (only) discuss additional things needed to evaluate media congestion cont= rol > (as the requirements are also slightly different). So one big difference = is > the traffic model. So there should be cases in the evaluation where the > traffic is application limited. If there is e.g. in a certain scenario > enough bandwidth capacity available to change the video coding to a highe= r > rate, how long does it take until this is indicated to the application > (assuming there is some kind of interface)? Or how often is the sending r= ate > lower than the application rate (which could cause starvation)? This of > course needs a traffic model as well as an interface which are currently > both in separate documents (and work in progress). > > What I really miss in this section is any relation to the metrics. I woul= d > expect something like: convergence is reached if the convergence time is > never longer than X sec (as a very general example) or (more media specif= ic) > quality is sufficient if the sending rate is never X% lower than the > application rate and never for more than % seconds.... and so on. > > - section 4.1. and 4.2 it this actually the same kind of evaluation? And > this states only a requirement up-to now. How would this be evaluated? > I think 4.1 could be removed or be reworded into something like: Simulate conditions that will not immediately trigger the circuit breaker. > - section 4.4. 'start-rates': what do you mean? The start rate of the > application traffic or the link bandwidth? > application traffic, i.e., the starting video media bit rate. > - section 4.5.: I believe most lower layer protocol nowadays have a very > good recovery implemented such that there are usually e.g. in wifi not mu= ch > errors/loss. therefore form the perceptive of the transport only the dela= y > is varying. True, but it is also possible to turn off link layer retransmissions, I think the cellular test cases want them to be turned off. > 'Furhermore packet loss may induce additional delay': this reads a little > weird: make more clear that there is packet loss at the lower layer but o= nly > delay visible to the higher layer... > Will fix language. > - Section 4.6. 'The main motivation for the previous and current criteria= is > to > identify situations in which the proposed congestion control is less > performant.' Not sure why this is written here... isn't this always th= e > intention? > Yes. Depending on the variation of the link capacity, this test would really be brutal for some congestion control algorithms. > - section 4.4. also describes some king of evaluation on an transient eff= ect > which should be part of 4.7. then...? > Yes. 4.4 is transience at the start of the session, and 4.7 is transience mid session. This can be merged. > - Section 4.9. discussion on short flow is again more a requirement but > short flow traffic should be configurable in the traffic model > This can be removed entirely or folded into a single guideline about measuring performance with cross-traffic. > - section 4.10. this again is a requirement. I don't think this can be > evaluated in simulation/testbeds; so I believe that does not belong in th= is > document. > I think it should be covered under metrics at the very least, because it contributes to overhead. Additionally, the performance would vary for example on the frequency of feedback packets and what > > > Section 5 and 6 > --------------- > Not sure if this belong into this document. At least section 6 is partly > documented in our charter already. If you see this document as a frame > document that will introduce the other documents (e.g. reqs, tests, > interface, traffic model) and explain the relation between those document= s > than this text can stay but should move into the introduction. > Sections 5 and 6 can be removed. > > Appendix A > ----------- > - I don't understand why this tradeoff is discussed here. > I think this is the remnants of the discussion for the trade-off between Throughput, loss, and delay. > - Appendix A.1: I really, really think that some kind of 'quality metrics= ' > must be discussed in this document because this is the different to other > congestion control evaluation. I don't think we should discuss any kind o= f > quality of experience though. This metric should rather be e.g. % of time= s > where the sending rate was lower than the application rate; % of times wh= ere There are many strategies here, in the end a lot depends on what was render= ed. A sender can burst a large frame, pace the same frame over a short interval or over a large interval, etc. All these have various short-term impacts, I don't know if we are there yet in terms of quantifying it. Or if we should attempt to model this based on raw transport metrics. (delays, throughput, etc.) > the link was underutilizated and a higher coding could have been used. Ag= ain > this also needs some kind of video traffic model; but I believe a simple > interface which indicated 'go one step up/down' and the respective model > that switches to certain points of time one step up or down would be > sufficient for initial evaluation; though I'm not a video expert... > It is not in the main section because it was unclear what quality meant. The agreement was we want the highest throughput possible with the least amount of delay :) but anything less was unclear. Since the proposals are now being evaluated, I am hoping that we'll come together on some metric in the near future. > > > All in all I would recommend to relate this document in any case stronger= to > draft-ietf-rmcat-cc-requirements and mainly discuss things that are speci= fic > to MEDIA congestion control while only referring or summarizing other > aspects. > > I hope this is helpful. Let me know if you have questions or would like > further input. > I will hold my updates until after Honolulu, based on the evaluation results, I'll have more insight into the metrics. -Varun > Mirja > > --=20 http://www.netlab.tkk.fi/~varun/ From nobody Thu Oct 23 05:26:56 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614871AD0C7 for ; Thu, 23 Oct 2014 05:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKB4Z9LEsRVe for ; Thu, 23 Oct 2014 05:26:52 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EE61AD34F for ; Thu, 23 Oct 2014 05:26:52 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tr6so831016ieb.0 for ; Thu, 23 Oct 2014 05:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=weRKfypiMe6bvcv6mIre7jMhpG2WXbGZD11WKJO7MgM=; b=FdTn+pzzDLVDGFszNyL2cBWehENzwE1uYaHvYEVyAVhvwPui16/OG6TVBMKqYObCnJ xkogQYF6XAFaBQ9qgGXjqNp72J4zhMYxSbxDQ16etupY3WKEkzOednbr3POH3CZ2ru4E DDLXclXzEIYl8qOt18cw0YCBAt1KEmikEQ5liK9BfwmXEozOUh3OvGQtrktW74Cn/xlT sVEITZ/jzmDdE2IRPgw5m2pylROcVxVuOPaaOOjV5ccBKVMTWS6GNsxjreLJBeRrZy0l PGc5zgoz4eccUWp/M11UqEi0sjG34zUXh1nY0p2MEfGTwRJ5uqJgBJUS3JJ2ieW2IqvJ 9yug== X-Received: by 10.42.216.16 with SMTP id hg16mr1053112icb.86.1414067211412; Thu, 23 Oct 2014 05:26:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.114.138 with HTTP; Thu, 23 Oct 2014 05:26:30 -0700 (PDT) In-Reply-To: References: <20141010173710.1769e033@hayesd-laptop> <5447ECED.4050904@tik.ee.ethz.ch> From: Varun Singh Date: Thu, 23 Oct 2014 15:26:30 +0300 Message-ID: To: Stefan Holmer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/ERNnd5dRmLvmDPCNmWrWBwckVEs Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , David Hayes , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 12:26:54 -0000 On Thu, Oct 23, 2014 at 12:36 PM, Stefan Holmer wrote: > We don't have plans for it right now, but I can imagine that it might hap= pen > sooner or later. I do think this draft could be useful in for instance me= sh > conferences where your uplink bottleneck is on your access link. The main > question is if it's reliable enough that the benefits clearly are greater > than the downsides of incorrect classification. > In a mesh the endpoint already knows that the outbound streams belong to a group and the main thing to figure out which ones share a common bottleneck, if not all of them. Another possible simplification is that the flows are carrying the same content, but may be at different rates (if each has an independent congestion controller). > > On Wed, Oct 22, 2014 at 7:44 PM, Mirja K=C3=BChlewind > wrote: >> >> Hi Stefan, >> >> asking this because I'm personally curious but also as rmcat chair: >> >> Are you planning to implement some kind of coupled congestion control in >> your system? >> >> Mirja >> >> >> >> On 22.10.2014 16:36, Stefan Holmer wrote: >>> >>> Nice draft! I have a few comments: >>> >>> You're mentioning that skewness would require all delay measurements to >>> be >>> stored, and therefore you're computing some different metric which is >>> related to skew. I wonder if it shouldn't be possible to more accuratel= y >>> estimate the skew from a histogram instead? That way you at least won't >>> need to store all delay measurements. Might not be worth the trouble if >>> your metric works well. >>> >>> As mentioned by Mirja, it seems a bit error prone to use the max of the >>> OWD >>> (also, shouldn't it be max_T(OWD)?) when computing the PDV. >>> >>> Somewhat related to this, I wonder if you have any plans to test this >>> algorithm on WiFi? I have seen many cases of WiFi with a lot of >>> contention >>> and/or interference, where the delay gets skewed not because lack of >>> bandwidth, but because of lower layer retransmissions or because the >>> access >>> point was busy serving someone else for a moment. I wonder if that can >>> cause you to incorrectly detect shared bottlenecks, where in reality >>> there >>> was only a shared WiFi... Now that I think of it, the WiFi effect shoul= d >>> result in positive skewness, while you're looking for negative skewness= , >>> so >>> you may be ok here. :) >>> >>> It would be good to have the diff() operation defined somewhere. Is it >>> the >>> diff between successive measurements, or the diff between the flows? >>> >>> /Stefan >>> >>> >>> On Fri, Oct 10, 2014 at 5:37 PM, David Hayes wrote= : >>> >>>> Dear All, >>>> >>>> We have just submitted of our initial shared bottleneck detection >>>> draft and will value your comments and suggestions. >>>> >>>> Regards, >>>> >>>> David >>>> >>>> Begin forwarded message: >>>> >>>> Date: Fri, 10 Oct 2014 08:17:57 -0700 >>>> From: >>>> To: Michael Welzl , David Hayes >>>> , Michael Welzl , Simone Ferli= n >>>> , Simone Ferlin , David Hayes >>>> Subject: New Version Notification for >>>> draft-hayes-rmcat-sbd-00.txt >>>> >>>> >>>> >>>> A new version of I-D, draft-hayes-rmcat-sbd-00.txt >>>> has been successfully submitted by David Hayes and posted to the >>>> IETF repository. >>>> >>>> Name: draft-hayes-rmcat-sbd >>>> Revision: 00 >>>> Title: Shared Bottleneck Detection for Coupled >>>> Congestion Control for RTP Media. Document date: 2014-10-10 >>>> Group: Individual Submission >>>> Pages: 12 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt >>>> Status: https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd= / >>>> Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 >>>> >>>> >>>> Abstract: >>>> This document describes a mechanism to detect whether end-to-end >>>> data >>>> flows share a common bottleneck. It relies on summary statistics >>>> that are calculated by a data receiver based on continuous >>>> measurements and regularly fed to a grouping algorithm that runs >>>> wherever the knowledge is needed. This mechanism complements the >>>> coupled congestion control mechanism in >>>> draft-welzl-rmcat-coupled-cc. >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> The IETF Secretariat >>>> >>>> >>>> >>>> -- >>>> >>>> ------------------------- >>>> David Hayes >>>> davihay@ifi.uio.no >>>> Department of Informatics >>>> University of Oslo >>>> >>>> >>> >> >> -- >> ------------------------------------------ >> Dipl.-Ing. Mirja K=C3=BChlewind >> Communication Systems Group >> Institute TIK, ETH Z=C3=BCrich >> Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland >> >> Room ETZ G93 >> phone: +41 44 63 26932 >> email: mirja.kuehlewind@tik.ee.ethz.ch >> ------------------------------------------ > > --=20 http://www.netlab.tkk.fi/~varun/ From nobody Thu Oct 23 06:40:35 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC651A1A72 for ; Thu, 23 Oct 2014 06:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ixrq4wW6Il8a for ; Thu, 23 Oct 2014 06:40:29 -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 C20431A90E2 for ; Thu, 23 Oct 2014 06:40:28 -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 1XhIcs-0004j1-Nf; Thu, 23 Oct 2014 15:40:26 +0200 Received: from [129.240.66.44] (helo=hayesd-laptop) by mail-mx1.uio.no with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) user davihay (Exim 4.80) (envelope-from ) id 1XhIcs-00069y-1c; Thu, 23 Oct 2014 15:40:26 +0200 Date: Thu, 23 Oct 2014 15:40:24 +0200 From: David Hayes To: Zaheduzzaman Sarker Message-ID: <20141023154024.5ceba84e@hayesd-laptop> In-Reply-To: References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> <20141021173659.44ecd880@hayesd-laptop> <5447EB2B.9070302@tik.ee.ethz.ch> Organization: University of Oslo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-mageia-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 10 sum msgs/h 2 total rcpts 1550 max rcpts/h 38 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BB531CB2DAC476273DBA9273D705CB0177E7E958 X-UiO-SPAM-Test: remote_host: 129.240.66.44 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 2 total 417 max/h 5 blacklist 0 greylist 1 ratelimit 0 X-UiOonly: 2A937CAFD5C6AE9CC889C2311B0AED6DB14EC3E2 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/zhf4jV0L9qojJka8FylENEZAd_o Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , Mirja =?UTF-8?B?S8O8aGxld2luZA==?= , Stefan Holmer , Michael Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 13:40:32 -0000 Hi Zahed and Stefan, Thank you for your interest. Our initial work has been presented in the LCN paper http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D6925767 The detailed algorithm presented in the draft has some improvements for implementation and robustness (over that used to produce the LCN paper results). I will present some results using the draft algorithm at the meeting in Honolulu. We are currently working on quantitative statistics. Networks are dynamic, and so are bottlenecks. It is also not just a right and wrong answer. Our current work is looking at this in terms of "complete group", "incomplete group", and "false group". We will be using the raw queue data to independently (of the algorithm) determine bottlenecks. I don't think this will be ready by Honolulu. In addition to this, a coupled congestion controller may not want to change coupling every T seconds, even if that reflects what is actually happening in the network. What it should do may depend on all sorts of things, possibly including the codec used. We plan to add a section to the draft discussing this, and include recommendations on using the SBD signal for different requirements. Kind regards, David On Thu, 23 Oct 2014 09:51:18 +0000 Zaheduzzaman Sarker wrote: > Hi, >=20 > I would also like to see some statistics on the false positives while > detecting the shared bottleneck with this method. >=20 > BR >=20 > Zahed >=20 > From: rmcat [mailto:rmcat-bounces@ietf.org] On Behalf Of Stefan Holmer > Sent: den 23 oktober 2014 11:28 > To: Michael Welzl > Cc: rmcat@ietf.org; Simone Ferlin-Oliveira; Mirja K=C3=BChlewind; David > Hayes Subject: Re: [rmcat] Fw: New Version Notification for > draft-hayes-rmcat-sbd-00.txt >=20 >=20 >=20 > On Thu, Oct 23, 2014 at 8:59 AM, Michael Welzl > > wrote: Hi, >=20 > Maybe I can help with this bit (and I hope David will correct me in > case I put this wrongly) - >=20 > On 22. okt. 2014, at 19:36, Mirja K=C3=BChlewind wrote: >=20 > > Hi David, > > > > just again on the skewness point: Form my current understanding > > what you somehow want to measure with this is something like a > > standing queue..? Still the way you calculate the skewness seems > > very abstract to me. >=20 > My understanding is that the intuition behind using skewness is that > you'd get a negative skewness in the OWD distribution only if you > have (common) congestion (the queue is often full and sometimes > drains). >=20 > Yes, that was my final conclusion about skewness as well when reading > the draft. I think that also should help avoid false classifications > of congestion when the channel periodically goes silent, for instance > on some WiFis. Do you guys have any idea of when this metric might > fail? >=20 >=20 >=20 > > However, if it can be shown that this provides useful information, > > it definitely should be used. The question (for all the metrics > > that you propose) is how can you show that these are the right > > metrics. One approach is definitely to do more measurements in > > various scenario but could you also assess the risk of failures? Or > > (and this potentially is more a question for the cc congestion) how > > bad is if you group two flows together wrongly? >=20 > Indeed that's a question about coupled-cc. My answer to "how bad is > it ..." is: the behavior can be very wrong. E.g., assume priorities > of 1/10 vs. 1. Coupled-cc will take the total and divide the rates > accordingly. If these flows don't share a common bottleneck, that's > just a very wrong thing to do - you may end up giving one flow much > less and another flow much more than its own congestion controller > has derived. >=20 > I think that sort of problem is unavoidable; the best one can do is > to try to get the shared bottleneck detection scheme to be as > reliable as possible (which is a part of why this work took us a long > time, we really do believe that this is pretty reliable) and use it > conservatively: e.g., one could turn on coupling only after a minute > or multiple minutes of a stable positive signal, and immediately turn > it off in case of a negative one. This would be extremely > conservative, but I'm just saying it's a parameter that can be tuned. >=20 > Cheers, > Michael >=20 --=20 ------------------------- David Hayes davihay@ifi.uio.no Department of Informatics University of Oslo From nobody Thu Oct 23 07:01:35 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6AB1A90F7 for ; Thu, 23 Oct 2014 07:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uEbHyhCry3u for ; Thu, 23 Oct 2014 07:01:31 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669061A6FBF for ; Thu, 23 Oct 2014 07:01:31 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id v63so735820oia.41 for ; Thu, 23 Oct 2014 07:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YhXgMgrRjOTSFZqKqUx0BULKmOdwT82ZRGV3tiaR04w=; b=ICnqUVCjpdRn/FV2qmrQUqyIr5V0+5wrvlQfmP61t/8cD2e4yrrgz6ShP7QqlrjjtZ mMdrUSpZxgnOWYqbYgC2M+J1YIQsRdSGyvXwuJibiqVZX6C8OjDR+sNypW/CsCC1pxij V2RXIyOuqt6i55JeJzS+AVlLD0cEa+4aBbRSHYWdB2J8/13ICNqbgqAf6sRwWXxfONZv WSC4BvNBVLZTMElXWmZU+fLU/Is8pkUlLaQn2VueokTVFzGxs72rFwCO9kGCXwnVhCIE KVVoIq0T9YnfvRLeUkknMYgS67lEIWId1Pyh+xrpOG/NR2rc46tcR8uq20t431l9/m46 NG6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YhXgMgrRjOTSFZqKqUx0BULKmOdwT82ZRGV3tiaR04w=; b=OWtC8yGK6/yLzaQMloPIgITga3P2QeAjPZxltxMW8IOPo2j+g8J1gmRaRj6WOj+Ews omN+FpOcY8fa3BgbH1zt2yK5hRZw5YXJ+asuRbMPiMcKul9QZyXaLxpLhnsujv5AAeas 2fQzC7AkRy7dSOF7RgLozDOwWGF3E+vpcWz4wszwTq7+ULJSFXjuhMewiI96qkyBRoVv 5j7EoIq0no92X0N/thnabxyFXdvSemDVgBXRt1aCIZX3dw1cXBySGjR89aH9Tl2bDbx7 0JlfgK73sNLI1iZduOuocIsplHOqwjXZkKwQVnxOUDgMudBnuqr8Is+uKG0innNf+aXU UUUQ== X-Gm-Message-State: ALoCoQljWvXI5tvsm+0Yu18ZdWuARruJsS5GaR1HTwW2jrDQTsndESLCsXNrXVlkO4KV9/TeStHm MIME-Version: 1.0 X-Received: by 10.60.179.112 with SMTP id df16mr1145208oec.70.1414072890310; Thu, 23 Oct 2014 07:01:30 -0700 (PDT) Sender: holmer@google.com Received: by 10.182.143.71 with HTTP; Thu, 23 Oct 2014 07:01:30 -0700 (PDT) In-Reply-To: References: <20141010173710.1769e033@hayesd-laptop> <5447ECED.4050904@tik.ee.ethz.ch> Date: Thu, 23 Oct 2014 16:01:30 +0200 X-Google-Sender-Auth: JFlyZOLIrxpgfNpqNRBtxjPBTGM Message-ID: From: Stefan Holmer To: Varun Singh Content-Type: multipart/alternative; boundary=089e01182e8c5067320506178033 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/g_ziUdlPsUPMZ2K7VLgiVUWjl7A Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , David Hayes , Michael Welzl Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 14:01:34 -0000 --089e01182e8c5067320506178033 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 23, 2014 at 2:26 PM, Varun Singh wrote: > On Thu, Oct 23, 2014 at 12:36 PM, Stefan Holmer wrote= : > > We don't have plans for it right now, but I can imagine that it might > happen > > sooner or later. I do think this draft could be useful in for instance > mesh > > conferences where your uplink bottleneck is on your access link. The ma= in > > question is if it's reliable enough that the benefits clearly are great= er > > than the downsides of incorrect classification. > > > > In a mesh the endpoint already knows that the outbound streams belong > to a group and the main thing to figure out which ones share a common > bottleneck, if not all of them. > What do you mean with "belong to a group"? What I mean could be useful is to determine if the bottleneck is shared (e.g., the access link is the bottleneck) and then use some sort of coupled cc. > > Another possible simplification is that the flows are carrying the > same content, but may be at different rates (if each has an > independent congestion controller). > > > > > On Wed, Oct 22, 2014 at 7:44 PM, Mirja K=C3=BChlewind > > wrote: > >> > >> Hi Stefan, > >> > >> asking this because I'm personally curious but also as rmcat chair: > >> > >> Are you planning to implement some kind of coupled congestion control = in > >> your system? > >> > >> Mirja > >> > >> > >> > >> On 22.10.2014 16:36, Stefan Holmer wrote: > >>> > >>> Nice draft! I have a few comments: > >>> > >>> You're mentioning that skewness would require all delay measurements = to > >>> be > >>> stored, and therefore you're computing some different metric which is > >>> related to skew. I wonder if it shouldn't be possible to more > accurately > >>> estimate the skew from a histogram instead? That way you at least won= 't > >>> need to store all delay measurements. Might not be worth the trouble = if > >>> your metric works well. > >>> > >>> As mentioned by Mirja, it seems a bit error prone to use the max of t= he > >>> OWD > >>> (also, shouldn't it be max_T(OWD)?) when computing the PDV. > >>> > >>> Somewhat related to this, I wonder if you have any plans to test this > >>> algorithm on WiFi? I have seen many cases of WiFi with a lot of > >>> contention > >>> and/or interference, where the delay gets skewed not because lack of > >>> bandwidth, but because of lower layer retransmissions or because the > >>> access > >>> point was busy serving someone else for a moment. I wonder if that ca= n > >>> cause you to incorrectly detect shared bottlenecks, where in reality > >>> there > >>> was only a shared WiFi... Now that I think of it, the WiFi effect > should > >>> result in positive skewness, while you're looking for negative > skewness, > >>> so > >>> you may be ok here. :) > >>> > >>> It would be good to have the diff() operation defined somewhere. Is i= t > >>> the > >>> diff between successive measurements, or the diff between the flows? > >>> > >>> /Stefan > >>> > >>> > >>> On Fri, Oct 10, 2014 at 5:37 PM, David Hayes > wrote: > >>> > >>>> Dear All, > >>>> > >>>> We have just submitted of our initial shared bottleneck detection > >>>> draft and will value your comments and suggestions. > >>>> > >>>> Regards, > >>>> > >>>> David > >>>> > >>>> Begin forwarded message: > >>>> > >>>> Date: Fri, 10 Oct 2014 08:17:57 -0700 > >>>> From: > >>>> To: Michael Welzl , David Hayes > >>>> , Michael Welzl , Simone > Ferlin > >>>> , Simone Ferlin , David Hayes > >>>> Subject: New Version Notification for > >>>> draft-hayes-rmcat-sbd-00.txt > >>>> > >>>> > >>>> > >>>> A new version of I-D, draft-hayes-rmcat-sbd-00.txt > >>>> has been successfully submitted by David Hayes and posted to the > >>>> IETF repository. > >>>> > >>>> Name: draft-hayes-rmcat-sbd > >>>> Revision: 00 > >>>> Title: Shared Bottleneck Detection for Coupled > >>>> Congestion Control for RTP Media. Document date: 2014-10-10 > >>>> Group: Individual Submission > >>>> Pages: 12 > >>>> URL: > >>>> http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt > >>>> Status: > https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ > >>>> Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00 > >>>> > >>>> > >>>> Abstract: > >>>> This document describes a mechanism to detect whether end-to-end > >>>> data > >>>> flows share a common bottleneck. It relies on summary statistic= s > >>>> that are calculated by a data receiver based on continuous > >>>> measurements and regularly fed to a grouping algorithm that runs > >>>> wherever the knowledge is needed. This mechanism complements th= e > >>>> coupled congestion control mechanism in > >>>> draft-welzl-rmcat-coupled-cc. > >>>> > >>>> > >>>> > >>>> > >>>> 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. > >>>> > >>>> The IETF Secretariat > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> ------------------------- > >>>> David Hayes > >>>> davihay@ifi.uio.no > >>>> Department of Informatics > >>>> University of Oslo > >>>> > >>>> > >>> > >> > >> -- > >> ------------------------------------------ > >> Dipl.-Ing. Mirja K=C3=BChlewind > >> Communication Systems Group > >> Institute TIK, ETH Z=C3=BCrich > >> Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland > >> > >> Room ETZ G93 > >> phone: +41 44 63 26932 > >> email: mirja.kuehlewind@tik.ee.ethz.ch > >> ------------------------------------------ > > > > > > > > -- > http://www.netlab.tkk.fi/~varun/ > --089e01182e8c5067320506178033 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 23, 2014 at 2:26 PM, Varun Singh <vsi= ngh.ietf@gmail.com> wrote:
= On Thu, Oct 23, 2014 at 12:36 PM, Stefan Holmer <stefan@webrtc.org> w= rote:
> We don't have plans for it right now, but I can imagine that it mi= ght happen
> sooner or later. I do think this draft could be useful in for instance= mesh
> conferences where your uplink bottleneck is on your access link. The m= ain
> question is if it's reliable enough that the benefits clearly are = greater
> than the downsides of incorrect classification.
>

In a mesh the endpoint already knows that the outbound streams belon= g
to a group and the main thing to figure out which ones share a common
bottleneck, if not all of them.

What do= you mean with "belong to a group"? What I mean could be useful i= s to determine if the bottleneck is shared (e.g., the access link is the bo= ttleneck) and then use some sort of=C2=A0
coupled cc.
= =C2=A0

Another possible simplification is that the flows are carrying the
same content, but may be at different rates (if each has an
independent congestion controller).

>
> On Wed, Oct 22, 2014 at 7:44 PM, Mirja K=C3=BChlewind
> <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
>>
>> Hi Stefan,
>>
>> asking this because I'm personally curious but also as rmcat c= hair:
>>
>> Are you planning to implement some kind of coupled congestion cont= rol in
>> your system?
>>
>> Mirja
>>
>>
>>
>> On 22.10.2014 16:36, Stefan Holmer wrote:
>>>
>>> Nice draft! I have a few comments:
>>>
>>> You're mentioning that skewness would require all delay me= asurements to
>>> be
>>> stored, and therefore you're computing some different metr= ic which is
>>> related to skew. I wonder if it shouldn't be possible to m= ore accurately
>>> estimate the skew from a histogram instead? That way you at le= ast won't
>>> need to store all delay measurements. Might not be worth the t= rouble if
>>> your metric works well.
>>>
>>> As mentioned by Mirja, it seems a bit error prone to use the m= ax of the
>>> OWD
>>> (also, shouldn't it be max_T(OWD)?) when computing the PDV= .
>>>
>>> Somewhat related to this, I wonder if you have any plans to te= st this
>>> algorithm on WiFi? I have seen many cases of WiFi with a lot o= f
>>> contention
>>> and/or interference, where the delay gets skewed not because l= ack of
>>> bandwidth, but because of lower layer retransmissions or becau= se the
>>> access
>>> point was busy serving someone else for a moment. I wonder if = that can
>>> cause you to incorrectly detect shared bottlenecks, where in r= eality
>>> there
>>> was only a shared WiFi... Now that I think of it, the WiFi eff= ect should
>>> result in positive skewness, while you're looking for nega= tive skewness,
>>> so
>>> you may be ok here. :)
>>>
>>> It would be good to have the diff() operation defined somewher= e. Is it
>>> the
>>> diff between successive measurements, or the diff between the = flows?
>>>
>>> /Stefan
>>>
>>>
>>> On Fri, Oct 10, 2014 at 5:37 PM, David Hayes <davihay@ifi.uio.no> wrote:=
>>>
>>>> Dear All,
>>>>
>>>> We have just submitted of our initial shared bottleneck de= tection
>>>> draft and will value your comments and suggestions.
>>>>
>>>> Regards,
>>>>
>>>> David
>>>>
>>>> Begin forwarded message:
>>>>
>>>> Date: Fri, 10 Oct 2014 08:17:57 -0700
>>>> From: <internet-drafts@ietf.org>
>>>> To: Michael Welzl <michawe@ifi.uio.no>, David Hayes
>>>> <davihay@ifi.uio.no>, Michael Welzl <michawe@ifi.uio.no>, Simone Ferlin
>>>> <f= erlin@simula.no>, Simone Ferlin <ferlin@simula.no>, David Hayes
>>>> <davihay@ifi.uio.no> Subject: New Version Notification for
>>>> draft-hayes-rmcat-sbd-00.txt
>>>>
>>>>
>>>>
>>>> A new version of I-D, draft-hayes-rmcat-sbd-00.txt
>>>> has been successfully submitted by David Hayes and posted = to the
>>>> IETF repository.
>>>>
>>>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hayes-= rmcat-sbd
>>>> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
>>>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Shared Bottleneck= Detection for Coupled
>>>> Congestion Control for RTP Media. Document date:=C2=A0 =C2= =A0 =C2=A0 =C2=A0 2014-10-10
>>>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submis= sion
>>>> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
>>>> URL:
>>>> http://www.ietf.org/i= nternet-drafts/draft-hayes-rmcat-sbd-00.txt
>>>> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/
>>>> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00
>>>>
>>>>
>>>> Abstract:
>>>>=C2=A0 =C2=A0 =C2=A0This document describes a mechanism to = detect whether end-to-end
>>>> data
>>>>=C2=A0 =C2=A0 =C2=A0flows share a common bottleneck.=C2=A0 = It relies on summary statistics
>>>>=C2=A0 =C2=A0 =C2=A0that are calculated by a data receiver = based on continuous
>>>>=C2=A0 =C2=A0 =C2=A0measurements and regularly fed to a gro= uping algorithm that runs
>>>>=C2=A0 =C2=A0 =C2=A0wherever the knowledge is needed.=C2=A0= This mechanism complements the
>>>>=C2=A0 =C2=A0 =C2=A0coupled congestion control mechanism in=
>>>> draft-welzl-rmcat-coupled-cc.
>>>>
>>>>
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the = time of
>>>> submission until the htmlized version and diff are availab= le at
>>>> tools.ietf.org.
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> -------------------------
>>>> David Hayes
>>>> dav= ihay@ifi.uio.no
>>>> Department of Informatics
>>>> University of Oslo
>>>>
>>>>
>>>
>>
>> --
>> ------------------------------------------
>> Dipl.-Ing. Mirja K=C3=BChlewind
>> Communication Systems Group
>> Institute TIK, ETH Z=C3=BCrich
>> Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland
>>
>> Room ETZ G93
>> phone: +41 44 63 26932
>> email: mirja.kuehlewind@tik.ee.ethz.ch
>> ------------------------------------------
>
>



--
http://www.netlab.tkk.fi/~varun/

--089e01182e8c5067320506178033-- From nobody Thu Oct 23 07:03:18 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982C31A8F36 for ; Thu, 23 Oct 2014 07:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGCu7RmdCGHU for ; Thu, 23 Oct 2014 07:03:13 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0478D1A903D for ; Thu, 23 Oct 2014 07:03:12 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id a3so745450oib.36 for ; Thu, 23 Oct 2014 07:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=G/jYbCD5/3gF3z3XKjSFFbRIIZRJ8yjIjH8c4SNyv4M=; b=obNNdNamYUGOQWZHt6WR5tm7+aMFnsLJpWenIA492UgqZLD6FxWJuW2joFx+YX1emj tr/Dgky3kwmmgvtcJNS+04MNbOnqgwR8LW7ORp0Y2fMSC6q6+7MPc6r/KhMS/pqT8nhe PpiZeBFTzDtEYjZjJ3/+vRMCBQ+6xOzJLQEE6ATmgRW8FjP0Uhv4xAV5P9kZklEnHEUi 2KYRtjxU27Hq7Q35mfOahqYMXqA/JLPhmFqGkY/PwJuKlNeqJ5b0Yx3BIfFLO03V8sEo TXAdqx6cUFPOfqvXl+0xNOZPguJUodpEQ0JBtdrADeyP1z6RNKssVWtV+EKCi9D9Zxy1 tgsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G/jYbCD5/3gF3z3XKjSFFbRIIZRJ8yjIjH8c4SNyv4M=; b=YEjQ2yqjnS64t/PTX6BrZ9oGVorNbivqlG0Mhc2d/wRSmDD53OHza9m/SAiI45THXh P4b+eOwniGfxuJ52+I+MwfWhecnIDD2DtncHWl9vjtqNBBinQmKxi9bWkPFuGYvWoe7O 1mHtS78njL1YqUJWNPYaOw8TvCxkHeNqyEWX7xMa59LzwTa7PecFrI0txhIOIW0ZCeRu JfUKJWNLbS3pZYl2XPo+CiZjNbmgvfA/q86D+Ct2p8uDYL97xM8xeAJ/+mzPxWp64h8e T9iuXMQAnXx+hLeTKt+UAnOMM/6tDTRdlfJahc5hT98nAonzPiAsYFXwd2ZzrhVsFK/P ubdQ== X-Gm-Message-State: ALoCoQln4m3py29dhCuHSvCwG60vaT9hmjA8ow9goGdua32ZtgQ+0nYB3v9KJ6FbhKuC+THCU65V MIME-Version: 1.0 X-Received: by 10.182.125.34 with SMTP id mn2mr861521obb.80.1414072992397; Thu, 23 Oct 2014 07:03:12 -0700 (PDT) Sender: holmer@google.com Received: by 10.182.143.71 with HTTP; Thu, 23 Oct 2014 07:03:12 -0700 (PDT) In-Reply-To: <20141023154024.5ceba84e@hayesd-laptop> References: <20141010173710.1769e033@hayesd-laptop> <544625C1.3050808@tik.ee.ethz.ch> <20141021173659.44ecd880@hayesd-laptop> <5447EB2B.9070302@tik.ee.ethz.ch> <20141023154024.5ceba84e@hayesd-laptop> Date: Thu, 23 Oct 2014 16:03:12 +0200 X-Google-Sender-Auth: qBfUD7V7YzrTAYl7re3m6DkkuJM Message-ID: From: Stefan Holmer To: David Hayes Content-Type: multipart/alternative; boundary=089e0122fa2466175f05061786ed Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/3RllfsJGH8GXlWhDAiv2z2dMHm0 Cc: "rmcat@ietf.org" , Simone Ferlin-Oliveira , Zaheduzzaman Sarker , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Michael Welzl Subject: Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 14:03:15 -0000 --089e0122fa2466175f05061786ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, those results would be interesting to see. It's unfortunately pretty difficult to do quantitative analysis of these things... On Thu, Oct 23, 2014 at 3:40 PM, David Hayes wrote: > Hi Zahed and Stefan, > > Thank you for your interest. > > Our initial work has been presented in the LCN paper > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D6925767 > > The detailed algorithm presented in the draft has some > improvements for implementation and robustness (over that used to > produce the LCN paper results). I will present some results using the > draft algorithm at the meeting in Honolulu. > > We are currently working on quantitative statistics. Networks are > dynamic, and so are bottlenecks. It is also not just a right and > wrong answer. Our current work is looking at this in terms of "complete > group", "incomplete group", and "false group". We will be using the raw > queue data to independently (of the algorithm) determine bottlenecks. > I don't think this will be ready by Honolulu. > > In addition to this, a coupled congestion controller may not want to > change coupling every T seconds, even if that reflects what is actually > happening in the network. What it should do may depend on all sorts of > things, possibly including the codec used. We plan to add a section to > the draft discussing this, and include recommendations on using the SBD > signal for different requirements. > > Kind regards, > > David > > > On Thu, 23 Oct 2014 09:51:18 +0000 > Zaheduzzaman Sarker wrote: > > > Hi, > > > > I would also like to see some statistics on the false positives while > > detecting the shared bottleneck with this method. > > > > BR > > > > Zahed > > > > From: rmcat [mailto:rmcat-bounces@ietf.org] On Behalf Of Stefan Holmer > > Sent: den 23 oktober 2014 11:28 > > To: Michael Welzl > > Cc: rmcat@ietf.org; Simone Ferlin-Oliveira; Mirja K=C3=BChlewind; David > > Hayes Subject: Re: [rmcat] Fw: New Version Notification for > > draft-hayes-rmcat-sbd-00.txt > > > > > > > > On Thu, Oct 23, 2014 at 8:59 AM, Michael Welzl > > > wrote: Hi, > > > > Maybe I can help with this bit (and I hope David will correct me in > > case I put this wrongly) - > > > > On 22. okt. 2014, at 19:36, Mirja K=C3=BChlewind wrote: > > > > > Hi David, > > > > > > just again on the skewness point: Form my current understanding > > > what you somehow want to measure with this is something like a > > > standing queue..? Still the way you calculate the skewness seems > > > very abstract to me. > > > > My understanding is that the intuition behind using skewness is that > > you'd get a negative skewness in the OWD distribution only if you > > have (common) congestion (the queue is often full and sometimes > > drains). > > > > Yes, that was my final conclusion about skewness as well when reading > > the draft. I think that also should help avoid false classifications > > of congestion when the channel periodically goes silent, for instance > > on some WiFis. Do you guys have any idea of when this metric might > > fail? > > > > > > > > > However, if it can be shown that this provides useful information, > > > it definitely should be used. The question (for all the metrics > > > that you propose) is how can you show that these are the right > > > metrics. One approach is definitely to do more measurements in > > > various scenario but could you also assess the risk of failures? Or > > > (and this potentially is more a question for the cc congestion) how > > > bad is if you group two flows together wrongly? > > > > Indeed that's a question about coupled-cc. My answer to "how bad is > > it ..." is: the behavior can be very wrong. E.g., assume priorities > > of 1/10 vs. 1. Coupled-cc will take the total and divide the rates > > accordingly. If these flows don't share a common bottleneck, that's > > just a very wrong thing to do - you may end up giving one flow much > > less and another flow much more than its own congestion controller > > has derived. > > > > I think that sort of problem is unavoidable; the best one can do is > > to try to get the shared bottleneck detection scheme to be as > > reliable as possible (which is a part of why this work took us a long > > time, we really do believe that this is pretty reliable) and use it > > conservatively: e.g., one could turn on coupling only after a minute > > or multiple minutes of a stable positive signal, and immediately turn > > it off in case of a negative one. This would be extremely > > conservative, but I'm just saying it's a parameter that can be tuned. > > > > Cheers, > > Michael > > > > > > -- > > ------------------------- > David Hayes > davihay@ifi.uio.no > Department of Informatics > University of Oslo > --089e0122fa2466175f05061786ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, those results would be interesting to see. It's un= fortunately pretty difficult to do quantitative analysis of these things...=

On Thu, Oct= 23, 2014 at 3:40 PM, David Hayes <davihay@ifi.uio.no> wrot= e:
Hi Zahed and Stefan,

Thank you for your interest.

Our initial work has been presented in the LCN paper
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?a= rnumber=3D6925767

The detailed algorithm presented in the draft has some
improvements for implementation and robustness (over that used to
produce the LCN paper results). I will present some results using the
draft algorithm at the meeting in Honolulu.

We are currently working on quantitative statistics. Networks are
dynamic, and so are bottlenecks. It is also not just a right and
wrong answer. Our current work is looking at this in terms of "complet= e
group", "incomplete group", and "false group". We = will be using the raw
queue data to independently (of the algorithm) determine bottlenecks.
I don't think this will be ready by Honolulu.

In addition to this, a coupled congestion controller may not want to
change coupling every T seconds, even if that reflects what is actually
happening in the network. What it should do may depend on all sorts of
things, possibly including the codec used. We plan to add a section to
the draft discussing this, and include recommendations on using the SBD
signal for different requirements.

Kind regards,

David


On Thu, 23 Oct 2014 09:51:18 +0000
Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

> Hi,
>
> I would also like to see some statistics on the false positives while<= br> > detecting the shared bottleneck with this method.
>
> BR
>
> Zahed
>
> From: rmcat [mailto:rmcat-bo= unces@ietf.org] On Behalf Of Stefan Holmer
> Sent: den 23 oktober 2014 11:28
> To: Michael Welzl
> Cc: rmcat@ietf.org; Simone Ferli= n-Oliveira; Mirja K=C3=BChlewind; David
> Hayes Subject: Re: [rmcat] Fw: New Version Notification for
> draft-hayes-rmcat-sbd-00.txt
>
>
>
> On Thu, Oct 23, 2014 at 8:59 AM, Michael Welzl
> <michawe@ifi.uio.no<mailto:michawe@ifi.uio.no>= ;> wrote: Hi,
>
> Maybe I can help with this bit (and I hope David will correct me in > case I put this wrongly) -
>
> On 22. okt. 2014, at 19:36, Mirja K=C3=BChlewind wrote:
>
> > Hi David,
> >
> > just again on the skewness point: Form my current understanding > > what you somehow want to measure with this is something like a > > standing queue..? Still the way you calculate the skewness seems<= br> > > very abstract to me.
>
> My understanding is that the intuition behind using skewness is that > you'd get a negative skewness in the OWD distribution only if you<= br> > have (common) congestion (the queue is often full and sometimes
> drains).
>
> Yes, that was my final conclusion about skewness as well when reading<= br> > the draft. I think that also should help avoid false classifications > of congestion when the channel periodically goes silent, for instance<= br> > on some WiFis. Do you guys have any idea of when this metric might
> fail?
>
>
>
> > However, if it can be shown that this provides useful information= ,
> > it definitely should be used. The question (for all the metrics > > that you propose) is how can you show that these are the right > > metrics. One approach is definitely to do more measurements in > > various scenario but could you also assess the risk of failures? = Or
> > (and this potentially is more a question for the cc congestion) h= ow
> > bad is if you group two flows together wrongly?
>
> Indeed that's a question about coupled-cc. My answer to "how = bad is
> it ..." is: the behavior can be very wrong. E.g., assume prioriti= es
> of 1/10 vs. 1. Coupled-cc will take the total and divide the rates
> accordingly. If these flows don't share a common bottleneck, that&= #39;s
> just a very wrong thing to do - you may end up giving one flow much > less and another flow much more than its own congestion controller
> has derived.
>
> I think that sort of problem is unavoidable; the best one can do is > to try to get the shared bottleneck detection scheme to be as
> reliable as possible (which is a part of why this work took us a long<= br> > time, we really do believe that this is pretty reliable) and use it > conservatively: e.g., one could turn on coupling only after a minute > or multiple minutes of a stable positive signal, and immediately turn<= br> > it off in case of a negative one. This would be extremely
> conservative, but I'm just saying it's a parameter that can be= tuned.
>
> Cheers,
> Michael
>



--

-------------------------
David Hayes
davihay@ifi.uio.no
Department of Informatics
University of Oslo

--089e0122fa2466175f05061786ed-- From nobody Fri Oct 24 05:50:30 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470CE1A8AB5 for ; Fri, 24 Oct 2014 05:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQqMSUROA4WN for ; Fri, 24 Oct 2014 05:50:25 -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 103D51A8BB3 for ; Fri, 24 Oct 2014 05:50:25 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XheJz-0001ec-M4 for rmcat@ietf.org; Fri, 24 Oct 2014 14:50:23 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1XheJy-0004he-Fo for rmcat@ietf.org; Fri, 24 Oct 2014 14:50:23 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_609E5293-FFBD-46A6-8E13-B74A10C1541E" Date: Fri, 24 Oct 2014 14:50:22 +0200 References: <20141024124538.23846.1832.idtracker@ietfa.amsl.com> To: "rmcat@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 9 sum msgs/h 4 total rcpts 21691 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8D97CCABBECA9D6DB74D2609DCD4B2D4864286E5 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 6623 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/mFdSe1tUKiuN2bEwtasOdE2_mPI Subject: [rmcat] Fwd: New Version Notification for draft-welzl-rmcat-coupled-cc-04.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 12:50:28 -0000 --Apple-Mail=_609E5293-FFBD-46A6-8E13-B74A10C1541E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi folks, This is just to inform you that we have submitted an update of the = coupled-cc draft. Since there is now some interest in shared bottleneck = detection, wouldn't that be a good time to consider reading this = companion document too, which describes what SBD can be good for? :-) = =3D> please read and comment. More information at: http://heim.ifi.uio.no/~safiquli/coupled-cc/index.html This update mentions that the mechanism should also work for = window-based controllers; we say this because we have some early, quite = promising simulation results with LEDBAT. Cheers, Michael Begin forwarded message: > From: > Subject: New Version Notification for = draft-welzl-rmcat-coupled-cc-04.txt > Date: 24. oktober 2014 14:45:38 GMT+02:00 > To: Michael Welzl , Safiqul Islam = , Stein Gjessing , Michael Welzl = , Safiqul Islam , Stein = Gjessing >=20 >=20 > A new version of I-D, draft-welzl-rmcat-coupled-cc-04.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Name: draft-welzl-rmcat-coupled-cc > Revision: 04 > Title: Coupled congestion control for RTP media > Document date: 2014-10-24 > Group: Individual Submission > Pages: 20 > URL: = http://www.ietf.org/internet-drafts/draft-welzl-rmcat-coupled-cc-04.txt > Status: = https://datatracker.ietf.org/doc/draft-welzl-rmcat-coupled-cc/ > Htmlized: = http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-welzl-rmcat-coupled-cc-04 >=20 > Abstract: > When multiple congestion controlled RTP sessions traverse the same > network bottleneck, it can be beneficial to combine their controls > such that the total on-the-wire behavior is improved. This document > describes such a method for flows that have the same sender, in a = way > that is as flexible and simple as possible while minimizing the > amount of changes needed to existing RTP applications. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_609E5293-FFBD-46A6-8E13-B74A10C1541E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = folks,

This is just to inform you that we have = submitted an update of the coupled-cc draft. Since there is now some = interest in shared bottleneck detection, wouldn't that be a good time to = consider reading this companion document too, which describes what SBD = can be good for?  :-)  =3D> please read and comment. More = information at:

= This update mentions that the mechanism should also work for = window-based controllers; we say this because we have some early, quite = promising simulation results with = LEDBAT.

Cheers,
Michael

<= /div>


Begin forwarded = message:

Subject: New Version Notification for = draft-welzl-rmcat-coupled-cc-04.txt
Date: 24. oktober 2014 = 14:45:38 GMT+02:00
To: Michael Welzl <michawe@ifi.uio.no>, Safiqul = Islam <safiquli@ifi.uio.no>, Stein = Gjessing <steing@ifi.uio.no>, Michael = Welzl <michawe@ifi.uio.no>, Safiqul = Islam <safiquli@ifi.uio.no>, Stein = Gjessing <steing@ifi.uio.no>


A new version of I-D, = draft-welzl-rmcat-coupled-cc-04.txt
has been successfully submitted = by Michael Welzl and posted to the
IETF repository.

Name: = draft-welzl-rmcat-coupled-cc
Revision: = 04
Title: Coupled congestion control for = RTP media
Document date: 2014-10-24
Group: = Individual Submission
Pages: 20
URL: =            http://www.ietf.org/internet-drafts/draft-welzl-rmcat-coupled-cc-04= .txt
Status:         ht= tps://datatracker.ietf.org/doc/draft-welzl-rmcat-coupled-cc/
Htmliz= ed:       http:/= /tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-04
Diff: =           http://www.ietf.org/rfcdiff?url2=3Ddraft-welzl-rmcat-coupled-cc-04
Abstract:
  When multiple congestion controlled RTP = sessions traverse the same
  network bottleneck, it can be = beneficial to combine their controls
  such that the total = on-the-wire behavior is improved.  This document
=   describes such a method for flows that have the same sender, = in a way
  that is as flexible and simple as possible = while minimizing the
  amount of changes needed to = existing RTP applications.




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.

The IETF = Secretariat


= --Apple-Mail=_609E5293-FFBD-46A6-8E13-B74A10C1541E-- From nobody Fri Oct 24 08:31:57 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57771A1A4E for ; Fri, 24 Oct 2014 08:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AtjIawIFQji for ; Fri, 24 Oct 2014 08:31:52 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8191A06E9 for ; Fri, 24 Oct 2014 08:31:52 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id rd18so2013110iec.41 for ; Fri, 24 Oct 2014 08:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=eFOHbN3MP5jDYocjsH1Q07CSYSdns9pLW908fQ/VMGE=; b=i++tEUJ25qrG43iuybS7mKO2P5DxVtsVxcL+Vf27IBn/2Y+kIvBcqG7TpKXSxL10yk dpWZ1Dx99BNOl5JqFmW/BA5Jyoo0drLR96STXkpH9bWM+AzO2KIsIlnt0sxp3DEeHESC te+KPexE68bzsVU3i5fvKxTAs/eSkI2Bl4Sti/NhsaIU4KtLQFbu+tv49wZBxxBN0gB5 iUX2aMvtnPthe9czVOyznBZzPYAW0u8F7Jx/fjS9Yc0dzWXwmGoKSPoyQnL8zmDynK02 g2Q2DdsabbLIi6qgZusZ/tb7nFXdacBhRpW3CYCXI2zbZB0P24EaxlhGCrhLuQv478qH o5oA== X-Received: by 10.50.43.167 with SMTP id x7mr4388199igl.41.1414164712111; Fri, 24 Oct 2014 08:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.114.138 with HTTP; Fri, 24 Oct 2014 08:31:31 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Fri, 24 Oct 2014 18:31:31 +0300 Message-ID: To: Karen Elisabeth Egede Nielsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/ZyK359Jjo2tawEnNRrQ0G7D21uk Cc: rmcat WG , "Eggert, Lars" , draft-ietf-rmcat-app-interaction@tools.ietf.org, =?UTF-8?Q?Mirja_K=C3=BChlewind?= Subject: Re: [rmcat] call for comments on draft-ietf-rmcat-app-interaction-00 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:31:54 -0000 Hi all, Comments inline On Wed, Oct 22, 2014 at 12:05 PM, Karen Elisabeth Egede Nielsen wrote: > Hi, > > In order to progress the wg document on application interactions we and > the authors of the doc would like to call for people, CC designers in > particular, to > read the document and provide comments with focus on the following > aspects: > > 1. Scope of document: Which interfaces are we looking to have described > in this document - especially should the document only describe the > interface in between the RMCAT Congestion controller and the application > or should the document provide an more extensive description of the > various components and their interrelations - still likely with a special > emphasis on the RMCAT Congestion controller and the application/codec > interface - ? > > This was discussed already at IETF89 RMCAT session (see minutes) - this > is an attempt to recap this discussion in order to establish consensus. > My personal thoughts on this: I am waiting for the Constraints API for WebRTC/Media Source API [1,2]. The API allows the web application to provide hints to the underlying WebRTC stack on what it expects (or at least that is what I think it does). For example through the API the application can configure the range of expected video resolutions, video frame rate, etc. This will be discussed and maybe finalized at next weeks W3C meeting. I don=E2=80=99t know, if we have to strictly follow the variables manipulat= ed by the Constraints API, but it will surely help the discussion in the application interactions draft. Or even provide feedback to the W3C, if there are variables that the congestion control proposal=E2=80=99s need. But honestly, I am not sure I have figured out all these interfaces yet. Cheers, Varun [1]: http://w3c.github.io/mediacapture-main/#media-track-constraints [2]: http://w3c.github.io/mediacapture-main/#constrainable-interface > 2. What (given the scope assumed for 1.) are the top 3-4 interactions > (e.g., allowed rate) that matter the most and which are needed to be > described in the document ? > > Thanks. > > BR, Karen/Chairs > --=20 http://www.netlab.tkk.fi/~varun/ From nobody Fri Oct 24 09:01:11 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715EC1A1B77 for ; Fri, 24 Oct 2014 09:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1AM7V4B7G1u for ; Fri, 24 Oct 2014 09:00:58 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F231A1B63 for ; Fri, 24 Oct 2014 09:00:58 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id hn18so890439igb.1 for ; Fri, 24 Oct 2014 09:00:57 -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:content-type; bh=SMC+6DEx2incK3/aEUG6kZ58sU6AWpyG4A6tpQ9GgfQ=; b=NyaF81ujk6PDXduGKtEFVwD/Hlutgrx2HFypUFcWXSBe5BTWQQHCy11a8fX+yAe0cy 11RpJ/TNk08axoosuGq/l8uZC+ZC2PUmBQ062uMe3/2E4zFC1DIlsWYjBN9l5JnuAPu7 EJZMzDM78ZGQLr7FSBQS5GjD/uKPXFwh2ncqL+uJg2BWSuOv/xhFnkCwNYPd9L2Xbodb FPo05dhdQ7OKaPqXMybH8gkEJYY2ZmaTLUWB+YiCbufbBtRH4RXB+yLjuCS9FeRbph8H /u4bvesdiCahlYT6lt8lkt+YqaMWuYQdjYfxkHCBBwitKq05+qK/1VZ2AMyx/URf+74e tAtA== X-Received: by 10.107.10.82 with SMTP id u79mr3358514ioi.46.1414166457570; Fri, 24 Oct 2014 09:00:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.114.138 with HTTP; Fri, 24 Oct 2014 09:00:37 -0700 (PDT) From: Varun Singh Date: Fri, 24 Oct 2014 19:00:37 +0300 Message-ID: To: rmcat WG , marcin.nagy@aalto.fi Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/2jKAEPFgq2cpW2g_Fh2ERxKQ1FU Subject: [rmcat] New Version Notification for draft-singh-rmcat-adaptive-fec-01.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 16:01:04 -0000 Hi all, This is just to inform you that we have submitted a minor update to adaptive-fec based on the list discussion. Cheers, Varun Begin forwarded message: A new version of I-D, draft-singh-rmcat-adaptive-fec-01.txt has been successfully submitted by Varun Singh and posted to the IETF repository. Name: draft-singh-rmcat-adaptive-fec Revision: 01 Title: Congestion Control Using FEC for Conversational Media Document date: 2014-10-24 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-singh-rmcat-adaptive-fec-01.txt Status: https://datatracker.ietf.org/doc/draft-singh-rmcat-adaptive-fec/ Htmlized: http://tools.ietf.org/html/draft-singh-rmcat-adaptive-fec-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-singh-rmcat-adaptive-fec-01 Abstract: This document describes a new mechanism for conversational multimedia flows. The proposed mechanism uses Forward Error Correction (FEC) encoded RTP packets (redundant packets) along side the media packets to probe for available network capacity. A straightforward interpretation is, the sending endpoint increases the transmission rate by keeping the media rate constant but increases the amount of FEC. If no losses and discards occur, the endpoint can then increase the media rate. If losses occur, the redundant FEC packets help in recovering the lost packets. Consequently, the endpoint can vary the FEC bit rate to conservatively (by a small amount) or aggressively (by a large amount) probe for available network capacity. 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. The IETF Secretariat --- http://www.netlab.tkk.fi/~varun From nobody Mon Oct 27 07:13:14 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498A41ACD7D for ; Mon, 27 Oct 2014 07:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTS8OkBXhl1u for ; Mon, 27 Oct 2014 07:12:04 -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 A3BE71ACD65 for ; Mon, 27 Oct 2014 07:11:59 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-27-544e52add414 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 78.86.04081.DA25E445; Mon, 27 Oct 2014 15:11:57 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.67]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 15:11:57 +0100 From: Ingemar Johansson S To: "rmcat WG (rmcat@ietf.org)" Thread-Topic: New Version Notification for draft-johansson-rmcat-scream-cc-03.txt Thread-Index: AQHP8e7Kcr7X1y80XUySKNLX3b1KkZxD+1wA Date: Mon, 27 Oct 2014 14:11:57 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA320023D0@ESESSMB205.ericsson.se> References: <20141027140301.23009.47523.idtracker@ietfa.amsl.com> In-Reply-To: <20141027140301.23009.47523.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje7aIL8Qg69rrCwOLNjJbrH65gc2 ByaPJUt+MnlM3niYLYApissmJTUnsyy1SN8ugSujc80fxoIZQhXXD7UzNTDeEexi5OSQEDCR +P5oFyuELSZx4d56ti5GLg4hgSOMEq+W/GeGcBYzSiy995ERpIpNwEZi5aHvQDYHh4iAgcTN XlOQMLOAqsSqD91MILawQJDE7E1fmEFsEYFgicMfnjBB2EYSq+e9ZAJpZQGqP70uDSTMK+Ar 8XftKbByIQFHiYc9PWDlnAJOElunXmADsRkFZCXuf7/HArFKXOLWk/lMEDcLSCzZc54ZwhaV ePn4H9QvihIfX+0Du5JZQFNi/S59iFZFiSndD9kh1gpKnJz5hGUCo9gsJFNnIXTMQtIxC0nH AkaWVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBkXNwy2+DHYwvnzseYhTgYFTi4f1Q4xsi xJpYVlyZe4hRmoNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY3WdOzDm8cY30 nyWPfv7ZIBIXc1q678O75rUmfzaXSJ+T6trJHnn9gaa1+b61oRfPcLS9efBMji0yqkjCsk/p gI8D/xzuNeEHNLPOia06KjBpUlx1mZDUVDUPS9GrG9SfnzHlvqy43Ma54Pi626/y3da4X7mw c1ahvJP9HwO3/U7H7733nHHMXImlOCPRUIu5qDgRABLhLL19AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/13L3eLhtr6EglTBKnZ_riGkSysU Cc: "iccrg@irtf.org" Subject: [rmcat] FW: New Version Notification for draft-johansson-rmcat-scream-cc-03.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 14:12:18 -0000 SGkNCg0KQSBuZXcgdmVyc2lvbiBvZiB0aGUgU0NSZUFNIGRyYWZ0IGlzIHBvc3RlZC4NClRoZSBj aGFuZ2VzIGFyZSA6DQorIE1vcmUgZGV0YWlsZWQgYWxnb3JpdGhtIGRlc2NyaXB0aW9uIA0KKyBT aW11bGF0aW9uIHJlc3VsdHMgYW5kIHBzZXVkbyBjb2RlIHJlbW92ZWQNCkxpbmsgdG8gZHJhZnQg OiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtam9oYW5zc29uLXJtY2F0LXNjcmVhbS1j Yy0wMy50eHQNCg0KL0luZ2VtYXIgYW5kIFphaGVkDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogZGVuIDI3IG9rdG9iZXIgMjAxNCAxNTowMw0KVG86IFphaGVk dXp6YW1hbiBTYXJrZXI7IEluZ2VtYXIgSm9oYW5zc29uIFM7IFphaGVkdXp6YW1hbiBTYXJrZXI7 IEluZ2VtYXIgSm9oYW5zc29uIFMNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtam9oYW5zc29uLXJtY2F0LXNjcmVhbS1jYy0wMy50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtam9oYW5zc29uLXJtY2F0LXNjcmVhbS1jYy0wMy50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSW5nZW1hciBKb2hhbnNzb24gYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtam9oYW5zc29uLXJtY2F0 LXNjcmVhbS1jYw0KUmV2aXNpb246CTAzDQpUaXRsZToJCVNlbGYtQ2xvY2tlZCBSYXRlIEFkYXB0 YXRpb24gZm9yIE11bHRpbWVkaWENCkRvY3VtZW50IGRhdGU6CTIwMTQtMTAtMjcNCkdyb3VwOgkJ SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTIyDQpVUkw6ICAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtam9oYW5zc29uLXJtY2F0LXNjcmVh bS1jYy0wMy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1qb2hhbnNzb24tcm1jYXQtc2NyZWFtLWNjLw0KSHRtbGl6ZWQ6ICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvaGFuc3Nvbi1ybWNhdC1zY3JlYW0tY2Mt MDMNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1qb2hhbnNzb24tcm1jYXQtc2NyZWFtLWNjLTAzDQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1v IGRlc2NyaWJlcyBhIHJhdGUgYWRhcHRhdGlvbiBmcmFtZXdvcmsgZm9yIGNvbnZlcnNhdGlvbmFs DQogICB2aWRlbyBzZXJ2aWNlcy4gIFRoZSBzb2x1dGlvbiBjb25mb3JtcyB0byB0aGUgcGFja2V0 IGNvbnNlcnZhdGlvbg0KICAgcHJpbmNpcGxlIGFuZCB1c2VzIGEgaHlicmlkIGxvc3MgYW5kIGRl bGF5IGJhc2VkIGNvbmdlc3Rpb24gY29udHJvbA0KICAgYWxnb3JpdGhtLiAgVGhlIGZyYW1ld29y ayBpcyBldmFsdWF0ZWQgb3ZlciBib3RoIHNpbXVsYXRlZCBib3R0bGVuZWNrDQogICBzY2VuYXJp b3MgYXMgd2VsbCBhcyBpbiBhIExURSAoTG9uZyBUZXJtIEV2b2x1dGlvbikgc3lzdGVtIHNpbXVs YXRvcg0KICAgYW5kIGlzIHNob3duIHRvIGFjaGlldmUgYm90aCBsb3cgbGF0ZW5jeSBhbmQgaGln aCB2aWRlbyB0aHJvdWdocHV0IGluDQogICB0aGVzZSBzY2VuYXJpb3MuDQoNCg== From nobody Mon Oct 27 08:48:34 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09D51A00F6 for ; Mon, 27 Oct 2014 08:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTD0GHcYp3cz for ; Mon, 27 Oct 2014 08:48:27 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D272B1A9092 for ; Mon, 27 Oct 2014 08:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2002; q=dns/txt; s=iport; t=1414424906; x=1415634506; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DOmwoG3fI0K0uEf2uWMiSdAuQSYxEWQw8gnIKlLhCNQ=; b=E1TZ0GIPuOV/teZ2ZVUjSVB0q1fPJoNr/iVItI0wGBBY3k7eKzC9tI3Z CrU+oJj/9cPk6v78TDAiyzsz1Pn44v78NykXmhwA5ibLLkErQnpsjcans qAbHg8nlOzuOYo/DEHzcOOaXe9pjsfKJ8/VjUCUKhT8iEgpQBdCeT1p4j 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAIZoTlStJA2F/2dsb2JhbABcgw5UWATNPodLAoEcFgFyC4QDAQEEDiwrEgIQAgEINhAyGwEGAwIEDgUJiDgNy1YBAQEBAQEBAQEBAQEBAQEBAQEakQgHhEsFkgeESIcSgTE8gw2RNIN4bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,796,1406592000"; d="scan'208";a="90653422" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 27 Oct 2014 15:48:26 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9RFmQfM011417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 15:48:26 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.207]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 10:48:25 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "rmcat@ietf.org" Thread-Topic: New Version Notification for draft-zhu-rmcat-video-traffic-source-00.txt Thread-Index: AQHP8fw8w+uwEg74rUW31v6GI0WGcpxEFuYA Date: Mon, 27 Oct 2014 15:48:25 +0000 Message-ID: References: <20141027153942.7939.25328.idtracker@ietfa.amsl.com> In-Reply-To: <20141027153942.7939.25328.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.152.13.82] Content-Type: text/plain; charset="us-ascii" Content-ID: <655071050949144B9C1BC8010502FB33@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/4B-vU1imyghte4zTabbSEqXCRO4 Cc: "Sergio Mena de la Cruz \(semena\)" , Zaheduzzaman Sarker Subject: [rmcat] FW: New Version Notification for draft-zhu-rmcat-video-traffic-source-00.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 15:48:31 -0000 This draft describes two different approaches for generating synthetic traffic source for evaluating RMCAT candidate schemes. If time permits, we would like to request for a slot to present this draft at IETF-91. And, of course, comments are welcome. Best, Xiaoqing On 10/27/14, 10:39 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-zhu-rmcat-video-traffic-source-00.txt >has been successfully submitted by Xiaoqing Zhu and posted to the >IETF repository. > >Name: draft-zhu-rmcat-video-traffic-source >Revision: 00 >Title: Modeling Video Traffic Sources for RMCAT Evaluations >Document date: 2014-10-26 >Group: Individual Submission >Pages: 14 >URL: =20 >http://www.ietf.org/internet-drafts/draft-zhu-rmcat-video-traffic-source-0 >0.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-zhu-rmcat-video-traffic-source/ >Htmlized: =20 >http://tools.ietf.org/html/draft-zhu-rmcat-video-traffic-source-00 > > >Abstract: > This document describes two reference video traffic source models for > evaluating RMCAT candidate algorithms. The first model statistically > characterizes the behavior of a live video encoder in response to > changing requests on target video rate. The second model is trace- > driven, and emulates the encoder output by scaling the pre-encoded > video frame sizes from a widely used video test sequence. Both > models are designed to strike a balance between simplicity, > repeatability, and authenticity in modeling the interactions between > a video traffic source and the congestion control module. > > =20 > =20 >Auto-upload of this draft missed out one author name. Therefore we >adjusted the meta data to fix this. > >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. > >The IETF Secretariat > From nobody Mon Oct 27 11:30:07 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CF41ACEA7; Mon, 27 Oct 2014 11:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpghK5_B02Wr; Mon, 27 Oct 2014 11:29:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6271A8AE3; Mon, 27 Oct 2014 11:27:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027182704.18420.64429.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 11:27:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/tA5EmoGaGeY8UBbN3MGEuaklPd4 Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:29:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. Title : Congestion Control Requirements for Interactive Real-Time Media Authors : Randell Jesup Zaheduzzaman Sarker Filename : draft-ietf-rmcat-cc-requirements-07.txt Pages : 11 Date : 2014-10-27 Abstract: Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g. with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled. This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for real-time media congestion avoidance technique. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-cc-requirements-07 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 Oct 27 14:07:35 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA541AD51A for ; Mon, 27 Oct 2014 14:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsFc2r3ZbKkS for ; Mon, 27 Oct 2014 14:07:12 -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 96B2C1AD512 for ; Mon, 27 Oct 2014 14:07:12 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XirVO-00042y-7O; Mon, 27 Oct 2014 22:07:10 +0100 Received: from [80.202.170.36] (helo=bilby.lan) by mail-mx3.uio.no with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) user davihay (Exim 4.80) (envelope-from ) id 1XirVN-00046f-Ff; Mon, 27 Oct 2014 22:07:10 +0100 Date: Mon, 27 Oct 2014 22:06:27 +0100 From: David hayes To: "rmcat@ietf.org" Message-ID: <20141027220627.28e6a2be@bilby.lan> Organization: University of Oslo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-mageia-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 1573 max rcpts/h 38 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7A5DA1899094DFF245F2640820A72A1C7695E019 X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 80.202.170.36 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 1 total 89 max/h 4 blacklist 0 greylist 1 ratelimit 0 X-UiOonly: 4A9F0D8FA3DE9BDC55769F6ED2E2B5F6E9C5D6F7 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/3T0wwkUMB0-_x4FLY6uzeB0tWV4 Cc: Simone Ferlin-Oliveira , Michael Welzl Subject: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-01.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:07:18 -0000 Hi All, We have posted an update to the SBD draft. The main changes are clarifications based on the feedback so far on the list. Thank you! There is also a correction to skew_est, [E_T() -> E_NT()]. Hopefully this will provide a good basis for further discussions on the list and at the meeting. Regards, David Begin forwarded message: Date: Mon, 27 Oct 2014 13:42:25 -0700 From: To: Michael Welzl , David Hayes , Michael Welzl , Simone Ferlin , Simone Ferlin , David Hayes Subject: New Version Notification for draft-hayes-rmcat-sbd-01.txt A new version of I-D, draft-hayes-rmcat-sbd-01.txt has been successfully submitted by David Hayes and posted to the IETF repository. Name: draft-hayes-rmcat-sbd Revision: 01 Title: Shared Bottleneck Detection for Coupled Congestion Control for RTP Media. Document date: 2014-10-27 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-01.txt Status: https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/ Htmlized: http://tools.ietf.org/html/draft-hayes-rmcat-sbd-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-hayes-rmcat-sbd-01 Abstract: This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. It relies on summary statistics that are calculated by a data receiver based on continuous measurements and regularly fed to a grouping algorithm that runs wherever the knowledge is needed. This mechanism complements the coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. 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. The IETF Secretariat -- +-------------------------------+ | David A. Hayes | | david.hayes@ieee.org | +-------------------------------+ From nobody Mon Oct 27 15:43:30 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585331A1B3C; Mon, 27 Oct 2014 15:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JuRSvToZHx1; Mon, 27 Oct 2014 15:43:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 249BB1A1A8D; Mon, 27 Oct 2014 15:43:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027224307.28009.74595.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 15:43:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/e9_jH9e6mAobyZZ8Tv6rf2pNco0 Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-app-interaction-01.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:43:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. Title : RTP Application Interaction with Congestion Control Authors : Mo Zanaty Varun Singh Suhas Nandakumar Zaheduzzaman Sarker Filename : draft-ietf-rmcat-app-interaction-01.txt Pages : 15 Date : 2014-10-27 Abstract: Interactive real-time media applications that use the Real-time Transport Protocol (RTP) over the User Datagram Protocol (UDP) must use congestion control techniques above the UDP layer since it provides none. This memo describes the interactions and conceptual interfaces necessary between the application components that relate to congestion control, including the RTP layer, the higher-level media codec control layer, and the lower-level transport interface, as well as components dedicated to congestion control functions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-app-interaction/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rmcat-app-interaction-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-app-interaction-01 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 Tue Oct 28 02:19:04 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A121A1AB4 for ; Tue, 28 Oct 2014 02:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PONFKHmXSxs for ; Tue, 28 Oct 2014 02:18:38 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7D51A1AA8 for ; Tue, 28 Oct 2014 02:18:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0F272D9305 for ; Tue, 28 Oct 2014 10:18:35 +0100 (MET) 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 TaPPlL6klk1e for ; Tue, 28 Oct 2014 10:18:35 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C1FA4D9304 for ; Tue, 28 Oct 2014 10:18:35 +0100 (MET) Message-ID: <544F5F6B.3070305@tik.ee.ethz.ch> Date: Tue, 28 Oct 2014 10:18:35 +0100 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rmcat@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/ZkYzi7NbBkr6XbpNAKMxz51XAnE Subject: [rmcat] Draft agenda X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 09:18:40 -0000 Hi, we uploaded a draft agenda (incl. agenda for Sunday interim): https://datatracker.ietf.org/meeting/91/agenda/rmcat/ Please let us know if there are any chances needed or you an additional presentation! Mirja From nobody Tue Oct 28 07:02:00 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D951A8907 for ; Tue, 28 Oct 2014 07:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hfwzg4SI3bI6 for ; Tue, 28 Oct 2014 07:01:57 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED241A8901 for ; Tue, 28 Oct 2014 07:01:57 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id n12so932087wgh.14 for ; Tue, 28 Oct 2014 07:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to :content-type:content-transfer-encoding; bh=PuN9BHgB9hr5iUT/9i2IHySPfD4IMF6XgjXfUAb/090=; b=xujXtmhLksOV7Z8jm8l/JcrSo3YjS/SZ1wGY6aMjdr2zaj33w7jO+pB+aYphqRTOad ZJiREPlvTG0KAr4RlBNttHSsaIKd4LLN+ogERFh5stsgSTdxi4Zy79qJqRZ0KvKD5Jzd +jEJHtALfFBXlbaCV7exQLTzHMT9wEzyqksUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type:content-transfer-encoding; bh=PuN9BHgB9hr5iUT/9i2IHySPfD4IMF6XgjXfUAb/090=; b=Nx3Ra0gVm8oBc4U9LMannQ8Ez38sFrF5Nz+fGn7vmV5GI1Q9/OKw0ckjWZCJiDWIPk NcUlGvdebWFBROF/B9RrwVnAWx5GCf5B8p0AE+CKU7EWmxYHUJplIjSG//NpUPwHM4Ps ePyUSqSv3mzv0P29TnL16O++b+eEVz3+5m6VD5UvWLbOalmiOqvAZQRUGf8kgoI5PdHE erJ+rqhE+8DI3UymICXIHz1dRL9ctrnNrJ5XoUbUIADKgGRgy/So3fea3MgYU6Fa4Frg Z4zt6susjboZq8n8dwezCuuGetLe13Ypf4ISNB3Emr4gULSyXqp04sVgz/lTPdvPjG4b 04vQ== X-Gm-Message-State: ALoCoQlNJbJSYGWUBX/PbKpzLfGI6c/ttm3jx8kxQmnu/tk8rTphScaXnwVybYEQHBtgdPhQwjuRsmQZ+DURLiTWY0ePvJfabpMRaBZROlcTqc+tg9a+XHo= X-Received: by 10.194.61.208 with SMTP id s16mr4443977wjr.104.1414504915883; Tue, 28 Oct 2014 07:01:55 -0700 (PDT) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/yt7f1gnWeFKf1S3yemUO6G7p5zw== Date: Tue, 28 Oct 2014 15:01:55 +0100 Message-ID: <6ba9fa9b3d206e3dacff255a83119b11@mail.gmail.com> To: rmcat@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/pyzaONCXAvaXyCo6H02TSWsBGl4 Subject: [rmcat] Slides for Interim X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 14:01:59 -0000 Hi, Please send the presentations for the Interim meeting to the Chairs no late= r than Friday November 7th EOB (any time zone). Thanks. BR, Karen > -----Original Message----- > From: rmcat [mailto:rmcat-bounces@ietf.org] On Behalf Of Mirja K=C3=BChle= wind > Sent: 28. oktober 2014 10:19 > To: rmcat@ietf.org > Subject: [rmcat] Draft agenda > > Hi, > > we uploaded a draft agenda (incl. agenda for Sunday interim): > > https://datatracker.ietf.org/meeting/91/agenda/rmcat/ > > Please let us know if there are any chances needed or you an additional > presentation! > > Mirja From nobody Tue Oct 28 08:15:53 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58561A8A65 for ; Tue, 28 Oct 2014 08:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIOYjU_f9Jb2 for ; Tue, 28 Oct 2014 08:15:49 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6781A8A0B for ; Tue, 28 Oct 2014 08:15:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 26AF1D9309; Tue, 28 Oct 2014 16:15:46 +0100 (MET) 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 CYSivCx3ikf9; Tue, 28 Oct 2014 16:15:45 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9F2FBD9305; Tue, 28 Oct 2014 16:15:45 +0100 (MET) Message-ID: <544FB321.40800@tik.ee.ethz.ch> Date: Tue, 28 Oct 2014 16:15:45 +0100 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Zaheduzzaman Sarker , Ingemar Johansson S , "rmcat@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/aPtUJKEAdGXaHbZ5STMDgeXoSeA Subject: [rmcat] Comments on draft-johansson-rmcat-scream-cc-03 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 15:15:52 -0000 Hi Ingemar, hi Zahed, I have a couple of questions/comments (as an individual contributor) on your draft. This is not a full review as I'm just addressing a couple of aspects which came to my mind immediately when reading (in random order). 1) RTCP feedback - You might want to think about which calculations should be done at the receiver and which at the sender. For LEBDAT it is proposed to calculate the the OWD at the receiver but you could probably even find a way to calculate the average (queuing) delay at the receiver and e.g. send the feedback only once an RTT. In fact if you implement a maximum increase rate, as in LEDBAT, of one packet per RTT, it's fine if you only update once per RTT as smaller updates will not open a packet window. - If you don't need a reliable transport, you don't actually need a real ack-number. All you need is the number of newly received bytes no matter if in order or not. However, later on (at the end of section 4.1.1.1) you say loss could be detected by holes in the sequence number space. For actually detecting 'holes' you would even need something like SACK. I guess you instead assume dup ACK as in TCP...? Again I don't think it is needed to copy TCP completely.. - RFC6679 specifies ECN feedback for RTP 2) self-clocking In the intro you say scream is self-clocked but the transmission scheduling (section 4.1.2) says '[packets] are scheduled at intervals given by t_pace'. In this case you just need sent-out timers and there is no self-clocking anymore...? 3) Variables It's hard to follow all the variables you introduce. I would propose to have a section where you introduce all variables at once. Further, just based on the fact that there are quite a lot variables, would it be possible to reduce the number of variables (and thereby even simplify the algorithm without a large performance degradation)? Due to my thesis a recently re-read a lot of the congestion control evaluation and design literature and there is actually (e.g. in Jain's 'Congestion Avoidance in Computer Networks...') also some kind of requirement for simplicity because this allows better assessment of question on robustness. So for me personally my next step is to review my own algorithm (in my thesis) and try to make to make it simpler and evaluate how much performance this would cost... 4) loss decrease by 0.8 Why 0.8? Also, and i know this is often not correctly done in most existing algorithms (in TCP Cubic), you should decrease by at 0.5 after Slow Start, as you have doubled the window before. However as you don't slow start that often, that's probably not a real problem. 5) Conditions for owd_target adjustments - I not sure I really understand the conditions: " o owd_mem > owd_target o owd_target > owd_target_lo " The first condition, is actually the condition where LEDBAT decreases the window. At the same time you would want to increase the target. That doesn't sound very stable... The second condition I don't understand because you start with owd_target=owd_target_lo but then you never increase it if it is not larger than owd_target_lo... so you never increase...? - One minor comment on the same section (4.1.1.7): you say the average OWD should be zero (after restart) but you mean the queuing delay should be zero (because the OWD includes the end-to-end delay), right? - In general I'm not too sure about the idea of interrupting video (also audio?)... 6) transmission decision Could you explain the the second condition (in section 4.1.2.1) a little more. The idea is that you increase faster (than one packet per RTT) if the delay is low...? LEDBAT already provides variables for this kind of usage, by GAIN and ALLOWED_INCREASE. Would it be an option to use these variables instead? 7) One very general comment: Maybe it would be an option to separate the framework and the congestion control even more (in different documents) so that one could even use different congestion control schemes...? Or are there any reasons why explicitly LEDBAT is needed? So far... Mirja From nobody Wed Oct 29 02:31:35 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3298E1A6FFE for ; Wed, 29 Oct 2014 02:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Gp4NRDaQcBL for ; Wed, 29 Oct 2014 02:31:32 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AB21A7004 for ; Wed, 29 Oct 2014 02:31:31 -0700 (PDT) X-AuditID: c1b4fb2d-f79fc6d000001087-7d-5450b3f1e228 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DD.16.04231.1F3B0545; Wed, 29 Oct 2014 10:31:30 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.67]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 10:31:29 +0100 From: Ingemar Johansson S To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Zaheduzzaman Sarker , "rmcat@ietf.org" Thread-Topic: Comments on draft-johansson-rmcat-scream-cc-03 Thread-Index: AQHP8sINW5Ly3VgwZEOBrUXlsVp6NJxGqmfQ Date: Wed, 29 Oct 2014 09:31:29 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA320034CF@ESESSMB205.ericsson.se> References: <544FB321.40800@tik.ee.ethz.ch> In-Reply-To: <544FB321.40800@tik.ee.ethz.ch> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje6nzQEhBldOsFlsWD2FxWL1zQ9s DkweS5b8ZPI49uErWwBTFJdNSmpOZllqkb5dAlfGx+nvmAreZVfc/fKApYGxJ7OLkZNDQsBE 4uPRVcwQtpjEhXvr2boYuTiEBI4wSjzc+ZQFJCEksJhRYtM8cxCbTcBGYuWh74wgRSICKxkl jizZwASSYBawkvhy/C/YJGEBa4ntb6YzgtgiQA13V/9hhbCNJI6cuAVWzyKgKnHjNMRmXgFf iYsTb7JDLNOWONzaCFbDKaAj0f/oD1gNo4CsxP3v91ggdolL3HoynwniagGJJXvOQ30gKvHy 8T9WCFtRov1pA9ANHED1mhLrd+lDtCpKTOl+yA6xVlDi5MwnLBMYxWYhmToLoWMWko5ZSDoW MLKsYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMnoNbfuvuYFz92vEQowAHoxIPb8GEgBAh 1sSy4srcQ4zSHCxK4ryLzs0LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCodXBifYBa91bl na8FV5ke+9p8n6G6SmPlbH/m0KMbNqna3nTmd7O8aGl/fz7Hud77C563TLy/XtxgrkiD7yHz 3sxH/bFsO9a6vZodvXul1XmzjgY//2fR77/d17mr/m/nbg45saa3LG6pcjnXPzHXi0cmVB2r +c6WuHtBXKza7vVWe+V//punxFKckWioxVxUnAgA9f/AF38CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/z6G8W1DomdXBcCIVBomjrmIlAjc Cc: Ingemar Johansson S Subject: Re: [rmcat] Comments on draft-johansson-rmcat-scream-cc-03 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 09:31:35 -0000 SGkNCg0KTWFueSB0aGFua3MgZm9yIHRoZSBjb21tZW50cy9xdWVzdGlvbnMuIA0KTXksIGhvcGVm dWxseSBjb21wcmVoZW5zaWJsZSwgYW5zd2VycyBpbmxpbmUgYmVsb3csIG1hcmtlZCB3aXRoIFtJ Sl0uIA0KDQovSW5nZW1hcg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IE1pcmphIEvDvGhsZXdpbmQgW21haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNo XQ0KPiBTZW50OiBkZW4gMjggb2t0b2JlciAyMDE0IDE2OjE2DQo+IFRvOiBaYWhlZHV6emFtYW4g U2Fya2VyOyBJbmdlbWFyIEpvaGFuc3NvbiBTOyBybWNhdEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBD b21tZW50cyBvbiBkcmFmdC1qb2hhbnNzb24tcm1jYXQtc2NyZWFtLWNjLTAzDQo+IA0KPiBIaSBJ bmdlbWFyLCBoaSBaYWhlZCwNCj4gDQo+IEkgaGF2ZSBhIGNvdXBsZSBvZiBxdWVzdGlvbnMvY29t bWVudHMgKGFzIGFuIGluZGl2aWR1YWwgY29udHJpYnV0b3IpIG9uIHlvdXINCj4gZHJhZnQuIFRo aXMgaXMgbm90IGEgZnVsbCByZXZpZXcgYXMgSSdtIGp1c3QgYWRkcmVzc2luZyBhIGNvdXBsZSBv ZiBhc3BlY3RzIHdoaWNoDQo+IGNhbWUgdG8gbXkgbWluZCBpbW1lZGlhdGVseSB3aGVuIHJlYWRp bmcgKGluIHJhbmRvbSBvcmRlcikuDQo+IA0KPiAxKSBSVENQIGZlZWRiYWNrDQo+IC0gWW91IG1p Z2h0IHdhbnQgdG8gdGhpbmsgYWJvdXQgd2hpY2ggY2FsY3VsYXRpb25zIHNob3VsZCBiZSBkb25l IGF0IHRoZQ0KPiByZWNlaXZlciBhbmQgd2hpY2ggYXQgdGhlIHNlbmRlci4gRm9yIExFQkRBVCBp dCBpcyBwcm9wb3NlZCB0byBjYWxjdWxhdGUgdGhlDQo+IHRoZSBPV0QgYXQgdGhlIHJlY2VpdmVy IGJ1dCB5b3UgY291bGQgcHJvYmFibHkgZXZlbiBmaW5kIGEgd2F5IHRvIGNhbGN1bGF0ZQ0KPiB0 aGUgYXZlcmFnZSAocXVldWluZykgZGVsYXkgYXQgdGhlIHJlY2VpdmVyIGFuZCBlLmcuIHNlbmQg dGhlIGZlZWRiYWNrIG9ubHkNCj4gb25jZSBhbiBSVFQuIEluIGZhY3QgaWYgeW91IGltcGxlbWVu dCBhIG1heGltdW0gaW5jcmVhc2UgcmF0ZSwgYXMgaW4gTEVEQkFULA0KPiBvZiBvbmUgcGFja2V0 IHBlciBSVFQsIGl0J3MgZmluZSBpZiB5b3Ugb25seSB1cGRhdGUgb25jZSBwZXIgUlRUIGFzIHNt YWxsZXINCj4gdXBkYXRlcyB3aWxsIG5vdCBvcGVuIGEgcGFja2V0IHdpbmRvdy4NCltJSl0gU28g ZmFyIEkgaGF2ZSBmb2N1c2VkIG9uIGdldHRpbmcgU0NSZUFNIHJvYnVzdC4gRm9yIHZhcmlvdXMg cmVhc29ucyBJIGVuZGVkIA0KdXAgd2l0aCBhbGwgcHJvY2Vzc2luZyAgaW4gdGhlIHNlbmRlciBh bmQgdGltZWx5IGZlZWRiYWNrLiBCdXQgaXQgaXMgcG9zc2libGUgdGhhdCBvbmUgDQpjYW4gZG8g YXMgeW91IHN1Z2dlc3QgYWJvdmUuIFRoZSBBQ0stY2xvY2tpbmcgbWF5IG5lZWQgdG8gYmUgc29s dmVkIGluIHNvbWUgDQpvdGhlciB3YXkgdGhlbiBhcyBpdCBiZWNvbWVzIG5lY2Vzc2FyeSB0byBw cmVkaWN0IGhvdyBtYW55IG5ldyBieXRlcyB0aGUgbmV4dCBBQ0sgd2lsbCANCmFja25vd2xlZGdl IGluIG9yZGVyIHRvIGtlZXAgYSBzdGVhZHkgc3RyZWFtIG9mIHBhY2tldHMuIA0KQnV0IHRoYXQg Y2FuIG1heWJlIGJlIHNvbHZlZCwgYWxzbyBpbiBjYXNlcyB3aGVyZSBPV0QgaW5jcmVhc2VzIHN1 ZGRlbmx5DQppdCBpcyBwb3NzaWJsZSB0byBzZW5kIGFuIGVhcmx5IGZlZWRiYWNrLiANClF1ZXN0 aW9uIGlzIGhvdyBtdWNoIG9uZSBjYW4gc2F2ZSB3aXRoIHRoaXMgaW4gdGVybXMgb2YgUlRDUCBv dmVyaGVhZD8uIA0KRGlnZ2VkIGluIHRoZSBMVEUgIHNpbXVsYXRpb24gbG9ncy4gSSByYW4gdGhl IHNpbXVsYXRpb25zIHdpdGggYSB2aWRlbyBzb3VyY2UgdGhhdCANCmhhZCBhIG1heCBiaXRyYXRl IG9mIDEuNU1icHMuIA0KSSB1c2UgcmVkdWNlIHNpemVkIFJUQ1AgZm9yIHRoZSBmZWVkYmFjayBh bmQgYSBmdWxsIGNvbXBvdW5kIFJUQ1AgaXMgdHJhbnNtaXR0ZWQgDQpldmVyeSAyIHNlY29uZHMs IEFWUCByZWd1bGFyIG1vZGUgd2l0aCA3MGticHMgUlRDUCBCVyBpcyB1c2VkLiANCkkgZ2V0IGFu IFJUQ1AgYml0cmF0ZSBvZiBtYXhpbXVtIDE0a2JwcywgaW4gcHJhY3Rpc2Ugb25lIGZlZWRiYWNr IGlzIHRyYW5zbWl0dGVkIA0Kcm91Z2hseSBvbmNlIHBlciB2aWRlbyBmcmFtZS4gMTRrYnBzIGlz IG5vdCB0b28gbXVjaCB0byB3b3JyeSBhYm91dCBhbmQgaXQgaXMgZGVmaW5pdGVseSANCm11Y2gg bGVzcyB0aGFuIDcwa2Jwcy4NCkJ1dCBpdCBjYW4gcGVyaGFwcyBiZWNvbWUgYW4gaXNzdWUgaWYg dGhlIGJhbmR3aWR0aCBpbiB0aGUgdHdvIGRpcmVjdGlvbnMgYXJlIA0KaGlnaGx5IGFzc3ltZXRy aWMgb3IgaW4gY2VydGFpbiBjb25mZXJlbmNpbmcgc2NlbmFyaW9zLg0KDQo+IA0KPiAtIElmIHlv dSBkb24ndCBuZWVkIGEgcmVsaWFibGUgdHJhbnNwb3J0LCB5b3UgZG9uJ3QgYWN0dWFsbHkgbmVl ZCBhIHJlYWwgYWNrLQ0KPiBudW1iZXIuIEFsbCB5b3UgbmVlZCBpcyB0aGUgbnVtYmVyIG9mIG5l d2x5IHJlY2VpdmVkIGJ5dGVzIG5vIG1hdHRlciBpZiBpbg0KPiBvcmRlciBvciBub3QuIEhvd2V2 ZXIsIGxhdGVyIG9uIChhdCB0aGUgZW5kIG9mIHNlY3Rpb24gNC4xLjEuMSkgeW91IHNheSBsb3Nz DQo+IGNvdWxkIGJlIGRldGVjdGVkIGJ5IGhvbGVzIGluIHRoZSBzZXF1ZW5jZSBudW1iZXIgc3Bh Y2UuIEZvciBhY3R1YWxseQ0KPiBkZXRlY3RpbmcgJ2hvbGVzJyB5b3Ugd291bGQgZXZlbiBuZWVk IHNvbWV0aGluZyBsaWtlIFNBQ0suIEkgZ3Vlc3MgeW91DQo+IGluc3RlYWQgYXNzdW1lIGR1cCBB Q0sgYXMgaW4gVENQLi4uPyBBZ2FpbiBJIGRvbid0IHRoaW5rIGl0IGlzIG5lZWRlZCB0byBjb3B5 DQo+IFRDUCBjb21wbGV0ZWx5Li4NCltJSl0gSSB3b3VsZCBzYXkgdGhhdCBvbmUgZ2V0IHNvbWV0 aGluZyBsaWtlIFRDUCBTQUNLLCBpbnN0ZWFkIG9mIGFja25vd2xlZGdlbWVudCANCm9mIGJ5dGUg c2VxdWVuY2VzLiBUaGUgbG9zcyBkZXRlY3Rpb24gaXMgZ2l2ZW4gYnkgdGhlIEFDSyBsaXN0LiAN CkkgZG9uJ3QgdXNlIFRDUCBkdXBBQ0sgY291bnRpbmcsIGluc3RlYWQgSSB1c2UgYSBtYXJnaW4g dG8gY292ZXIgcG9zc2libGUgcmVvcmRlcmluZy4gDQpGb3IgaW5zdGFuY2UsIGlmIHNlcXVlbmNl IG51bWJlciBTTiBpcyB0aGUgaGlnaGVzdCBhY2tub3dsZWRnZWQgc2VxdWVuY2UgbnVtYmVyDQp0 aGUgdGhlIGFsZ29yaXRobSBsb29rcyBmb3IgbG9zcyBpbmRpY2F0aW9ucyBmb3IgU04tNSBvciBl YXJsaWVyLiBUaGUgYmVuZWZpdCB3aXRoIGFuIEFDSyANCmxpc3QgaXMgdGhhdCBhbHJlYWR5IHRo ZXJlIGdldCBzdXBwb3J0IGZvciByZXRyYW5zbWlzc2lvbiBhbmQgc2ltaWxhciBmdW5jdGlvbmFs aXR5IGFzIA0KUkZDNDU4NSBHZW5lcmljIE5BQ0suDQoNCj4gDQo+IC0gUkZDNjY3OSBzcGVjaWZp ZXMgRUNOIGZlZWRiYWNrIGZvciBSVFANCltJSl0gWWVzLCB0aGluZyBpcyB0aGF0IEkgYW0gbG9v a2luZyBtb3JlIGF0IHRoZSBhY2N1cmF0ZSBFQ04gZm9yIFRDUCBpbiBUQ1AgYXMgb25lIA0KYW55 d2F5IGhhcyBhY2Nlc3MgdG8gdGltZWx5IGFuZCBmcmVxdWVudCBmZWVkYmFjayBpbiBTQ1JlQU0u IFRoaXMgbWF5IGhvd2V2ZXIgDQpjaGFuZ2UgaWYgb25lIGNhbiBnZXQgbGVzcyBmcmVxdWVudCBm ZWRiYWNrIHRvIHdvcmsuIA0KPiANCj4gMikgc2VsZi1jbG9ja2luZw0KPiBJbiB0aGUgaW50cm8g eW91IHNheSBzY3JlYW0gaXMgc2VsZi1jbG9ja2VkIGJ1dCB0aGUgdHJhbnNtaXNzaW9uIHNjaGVk dWxpbmcNCj4gKHNlY3Rpb24gNC4xLjIpIHNheXMgJ1twYWNrZXRzXSBhcmUgc2NoZWR1bGVkIGF0 IGludGVydmFscyBnaXZlbiBieSB0X3BhY2UnLiBJbg0KPiB0aGlzIGNhc2UgeW91IGp1c3QgbmVl ZCBzZW50LW91dCB0aW1lcnMgYW5kIHRoZXJlIGlzIG5vIHNlbGYtY2xvY2tpbmcNCj4gYW55bW9y ZS4uLj8NCltJSl0gVGhlIHBhY2luZyBpcyBzZXQgc3VjaCB0aGF0IG5ldyBSVFAgcGFja2V0cyBh cmUgY2xvY2tlZCBhdCBpbnRlcnZhbHMgZ2l2ZW4gYnkgdGhlIA0KZXN0aW1hdGVkIGJhbmR3aWR0 aCwgZ2l2ZW4gYnkgdGhlIENXTkQgYW5kIHRoZSBSVFQsIGFuZCB0aGUgc2l6ZSBvZiB0aGUgbW9z dCANCnJlY2VudGx5IHRyYW5zbWl0dGVkIFJUUCBwYWNrZXQuIFRoZSBwYWNpbmcgaXMgdGhlcmUg dG8gYnJlYWsgdXAgY29hbGVzY2luZyB0ZW5kZW5jaWVzDQp0aGF0IEkgaGF2ZSBzZWVuIGluIHNp bXVsYXRpb25zLiBJdCBkb2VzIG5vdCBkbyBhd2F5IHdpdGggdGhlIHNlbGYtY2xvY2tpbmcgYXMg dGhlIGJhc2ljIA0KcnVsZSB0aGF0IGJ5dGVzIGluIGZsaWdodCBtdXN0IHN0aWxsIGJlIHNhdGlz ZmllZC4gDQoNCj4gDQo+IDMpIFZhcmlhYmxlcw0KPiBJdCdzIGhhcmQgdG8gZm9sbG93IGFsbCB0 aGUgdmFyaWFibGVzIHlvdSBpbnRyb2R1Y2UuIEkgd291bGQgcHJvcG9zZSB0byBoYXZlIGENCj4g c2VjdGlvbiB3aGVyZSB5b3UgaW50cm9kdWNlIGFsbCB2YXJpYWJsZXMgYXQgb25jZS4gRnVydGhl ciwganVzdCBiYXNlZCBvbiB0aGUNCj4gZmFjdCB0aGF0IHRoZXJlIGFyZSBxdWl0ZSBhIGxvdCB2 YXJpYWJsZXMsIHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHJlZHVjZSB0aGUNCj4gbnVtYmVyIG9m IHZhcmlhYmxlcyAoYW5kIHRoZXJlYnkgZXZlbiBzaW1wbGlmeSB0aGUgYWxnb3JpdGhtIHdpdGhv dXQgYSBsYXJnZQ0KPiBwZXJmb3JtYW5jZSBkZWdyYWRhdGlvbik/DQo+IER1ZSB0byBteSB0aGVz aXMgYSByZWNlbnRseSByZS1yZWFkIGEgbG90IG9mIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgZXZh bHVhdGlvbg0KPiBhbmQgZGVzaWduIGxpdGVyYXR1cmUgYW5kIHRoZXJlIGlzIGFjdHVhbGx5IChl LmcuIGluIEphaW4ncyAnQ29uZ2VzdGlvbg0KPiBBdm9pZGFuY2UgaW4gQ29tcHV0ZXIgTmV0d29y a3MuLi4nKSBhbHNvIHNvbWUga2luZCBvZiByZXF1aXJlbWVudCBmb3INCj4gc2ltcGxpY2l0eSBi ZWNhdXNlIHRoaXMgYWxsb3dzIGJldHRlciBhc3Nlc3NtZW50IG9mIHF1ZXN0aW9uIG9uIHJvYnVz dG5lc3MuDQo+IFNvIGZvciBtZSBwZXJzb25hbGx5IG15IG5leHQgc3RlcCBpcyB0byByZXZpZXcg bXkgb3duIGFsZ29yaXRobSAoaW4gbXkNCj4gdGhlc2lzKSBhbmQgdHJ5IHRvIG1ha2UgdG8gbWFr ZSBpdCBzaW1wbGVyIGFuZCBldmFsdWF0ZSBob3cgbXVjaA0KPiBwZXJmb3JtYW5jZSB0aGlzIHdv dWxkIGNvc3QuLi4NCltJSl0gWW91IGFyZSByaWdodCwgSSB3aWxsIHRyeSB0byBkbyB0aGlzIGJl dHRlciBuZXh0IHRpbWUsIGEgc2VjdGlvbiB3aXRoIGFsbCB0aGUgDQp2YXJpYWJsZXMgaW4gb25l IHBsYWNlIGlzIHByb2JhYmx5IGEgZ29vZCBzdGFydC4NClNvbWUgcGFydHMgb2YgdGhlIGFsZ29y aXRobSBjYW4gYWN0dWFsbHkgYmUgc3RyaXBwZWQgYXdheSwgZm9yIGluc3RhbmNlIHRoZSANCk9X RCB0cmVuZCBjb21wdXRhdGlvbiBpcyB0aGVyZSB0byByZWR1Y2UgdGhlIGppdHRlciwgYWxzbyB0 aGVyZSBhcmUgcGFydHMgaW4gDQp0aGUgdmlkZW8gcmF0ZSBjb250cm9sIHBhcnRzIHRoYXQgY2Fu IGJlIHJlbW92ZWQuIFRoZSBlbmQgcmVzdWx0IG1heSBiZSANCm1vcmUgaml0dGVyIGJ1dCBpdCBt YXkgYmUgZWFzaWVyIHRvIHVuZGVyc3RhbmQgdGhlIGFsZ29yaXRobSBkZXNjcmlwdGlvbg0KTWF5 IHJlaW50cm9kdWNlIHRoZSBwc2V1ZG8gY29kZSBsYXRlciBvbiBhcyBpdCBtYXkgbWFrZSB0aGlu Z3MgbW9yZSANCmNvbXByZWhlbnNpYmxlLiANCg0KPiANCj4gNCkgbG9zcyBkZWNyZWFzZSBieSAw LjgNCj4gV2h5IDAuOD8gQWxzbywgYW5kIGkga25vdyB0aGlzIGlzIG9mdGVuIG5vdCBjb3JyZWN0 bHkgZG9uZSBpbiBtb3N0IGV4aXN0aW5nDQo+IGFsZ29yaXRobXMgKGluIFRDUCBDdWJpYyksIHlv dSBzaG91bGQgZGVjcmVhc2UgYnkgYXQgMC41IGFmdGVyIFNsb3cgU3RhcnQsIGFzDQo+IHlvdSBo YXZlIGRvdWJsZWQgdGhlIHdpbmRvdyBiZWZvcmUuIEhvd2V2ZXIgYXMgeW91IGRvbid0IHNsb3cg c3RhcnQgdGhhdA0KPiBvZnRlbiwgdGhhdCdzIHByb2JhYmx5IG5vdCBhIHJlYWwgcHJvYmxlbS4N CltJSl0gVGhpcyBpcyBzZXQgYmFzZWQgb24gZXhwZXJpbWVudGF0aW9uIGFnYWluc3QgVENQIChO ZXdSZW5vKSBiYXNlZCBmaWxlIA0KdHJhbnNmZXJzIG92ZXIgdGhlIHNhbWUgQ29EZWwgb3IgUElF IEFRTSBlcXVpcHBlZCBib3R0bGVuZWNrLiANCklmIEkgc2V0IHRoZSBDV05EIHNjYWxlIGluIFND UmVBTSB0byAwLjUgaS5lIHJlZHVjZSBieSA1MCUgaXN0ZiAyMCUgSSBzZWUgdGhhdCB0aGUgZmls ZSANCnRyYW5zZmVyIG91dGNvbXBldGVzIFNDUmVBTS4gSSBiZWxpZXZlIHRoaXMgaGFwcGVucyBi ZWNhdXNlIFNDUmVBTSBoYXMgYSB2aWRlbyANCnNvdXJjZSB3aXRoIGxpbWl0ZWQgYml0cmF0ZSwg d2hpbGUgdGhlIGZpbGUgdHJhbnNmZXIgaGFzICJ1bmxpbWl0ZWQiIHNvdXJjZSBiaXRyYXRlLg0K DQo+IA0KPiA1KSBDb25kaXRpb25zIGZvciBvd2RfdGFyZ2V0IGFkanVzdG1lbnRzDQo+IC0gSSBu b3Qgc3VyZSBJIHJlYWxseSB1bmRlcnN0YW5kIHRoZSBjb25kaXRpb25zOg0KPiAiDQo+ICAgICBv ICBvd2RfbWVtID4gb3dkX3RhcmdldA0KPiANCj4gICAgIG8gIG93ZF90YXJnZXQgPiBvd2RfdGFy Z2V0X2xvDQo+ICINCj4gDQo+IFRoZSBmaXJzdCBjb25kaXRpb24sIGlzIGFjdHVhbGx5IHRoZSBj b25kaXRpb24gd2hlcmUgTEVEQkFUIGRlY3JlYXNlcyB0aGUNCj4gd2luZG93LiBBdCB0aGUgc2Ft ZSB0aW1lIHlvdSB3b3VsZCB3YW50IHRvIGluY3JlYXNlIHRoZSB0YXJnZXQuIFRoYXQNCj4gZG9l c24ndCBzb3VuZCB2ZXJ5IHN0YWJsZS4uLg0KPiBUaGUgc2Vjb25kIGNvbmRpdGlvbiBJIGRvbid0 IHVuZGVyc3RhbmQgYmVjYXVzZSB5b3Ugc3RhcnQgd2l0aA0KPiBvd2RfdGFyZ2V0PW93ZF90YXJn ZXRfbG8gYnV0IHRoZW4geW91IG5ldmVyIGluY3JlYXNlIGl0IGlmIGl0IGlzIG5vdCBsYXJnZXIN Cj4gdGhhbiBvd2RfdGFyZ2V0X2xvLi4uIHNvIHlvdSBuZXZlciBpbmNyZWFzZS4uLj8NCm93ZF9t ZW0gaXMgYW4gYXZlcmFnZSBPV0QuIE5vcm1hbGx5IHRoaXMgc2hvdWxkIG5vdCBleGNlZWQgb3dk X3RhcmdldCANCnRvbyBtdWNoIG9yIHRvbyBvZnRlbiBidXQgaW4gY2FzZSB0aGlzIGhhcHBlbnMg aXQgbWF5IGJlIGFuIGluZGljYXRpb24gb2YgY29tcGV0aW5nIA0KZmxvd3MgYW5kIHRoYXQgdGhl IG93ZF90YXJnZXQgbWF5IG5lZWQgdG8gYmUgaW5jcmVhc2VkLCBkZXBlbmRpbmcgb24gb3V0Y29t ZSBvZiB0aGUgDQpzdWJzZXF1ZW50IGFsZ29yaXRobSBzdGVwcy4NClRoZSBzZWNvbmQgY29uZGl0 aW9uIGluZGljYXRlcyB0aGF0IHRoZSBvd2RfdGFyZ2V0IGlzIHJhaXNlZCB0byBtYWtlIFNDUmVB TSBjb3BlIHdpdGggDQpjb21wZXRpbmcgZmxvd3MuIEluIHRoYXQgY2FzZSBpdCBpcyBuZWNlc3Nh cnkgdG8gY2hlY2sgaWYgaXQgaXMgcG9zc2libGUgdG8gcmVkdWNlIG93ZF90YXJnZXQNCmlmIGZv ciBpbnN0YW5jZSB0aGUgY29tcGV0aW5nIGZsb3cgaGFzIGNvbXBsZXRlZC4NCg0KPiANCj4gLSBP bmUgbWlub3IgY29tbWVudCBvbiB0aGUgc2FtZSBzZWN0aW9uICg0LjEuMS43KTogeW91IHNheSB0 aGUgYXZlcmFnZQ0KPiBPV0Qgc2hvdWxkIGJlIHplcm8gKGFmdGVyIHJlc3RhcnQpIGJ1dCB5b3Ug bWVhbiB0aGUgcXVldWluZyBkZWxheSBzaG91bGQNCj4gYmUgemVybyAoYmVjYXVzZSB0aGUgT1dE IGluY2x1ZGVzIHRoZSBlbmQtdG8tZW5kIGRlbGF5KSwgcmlnaHQ/DQpbSUpdIE9XRCBpbiB0aGlz IGRyYWZ0IGlzIHRoZSBvbmUgd2F5IGV4dHJhIGRlbGF5LiBpLmUgb25seSB0aGUgcXVldWluZyBk ZWxheSwNCiBndWVzcyBJIG5lZWQgdG8gY2xhcmlmeSB0aGlzLg0KPiANCj4gLSBJbiBnZW5lcmFs IEknbSBub3QgdG9vIHN1cmUgYWJvdXQgdGhlIGlkZWEgb2YgaW50ZXJydXB0aW5nIHZpZGVvIChh bHNvDQo+IGF1ZGlvPykuLi4NCltJSl0gTm8gYXVkaW8gaXMgbm90IGludGVycnVwdGVkIGFzIGl0 IGlzIG5vdCB0cmFuc21pc3Npb24gc2NoZWR1bGVkIGJ5IFNDUmFBTS4gDQpPbmx5IHZpZGVvIGlz IGludGVycnVwdGVkLCBvbmUgY2FuIGFyZ3VlIGhvdyBnb29kIGl0IGlzIGJ1dCBJIGhhdmUgeWV0 IHRvIGZpbmQgDQphbm90aGVyIG1ldGhvZCB0aGF0IGNhbiBtYWtlIFNDUmVBTSB3b3JrIHdlbGwg YWdhaW5zdCBjb21wZXRpbmcgVENQIG92ZXIgDQp0YWlsIGRyb3AgbGlua3MgYW5kIHRoYXQgYXQg dGhlIHNhbWUgdGltZSBkb2VzIG5vdCBjcmVhdGUgc2VsZi1pbmZsaWN0ZWQgY29uZ2V0c2lvbiAN CmluIHdpcmVsZXNzIGFjY2VzcyBzdWNoIGFzIExURSAoYW5kIHBvc3NpYmx5IGV2ZW4gV2lGaSku IA0KUG9zc2libHkgdGhlIHNoYXJlZCBib3R0bGVuZWNrIGRldGVjdGlvbiAoU0JEKSBjYW4gYmUg dXNlZnVsIGhlcmUgPy4gVGhlcmUgd2FzIA0Kc29tZSBxdWVzdGlvbnMgYXJvdW5kIHRoZSBiZWhh dmlvci9wZXJmb3JtYW5jZSBpbiBXaUZpIGFjY2VzcywgYW5kIEkgYW0gdG9vDQphbW9uZyB0aGUg Y3VyaW91cy4gDQoNCj4gDQo+IDYpIHRyYW5zbWlzc2lvbiBkZWNpc2lvbg0KPiBDb3VsZCB5b3Ug ZXhwbGFpbiB0aGUgdGhlIHNlY29uZCBjb25kaXRpb24gKGluIHNlY3Rpb24gNC4xLjIuMSkgYSBs aXR0bGUgbW9yZS4NCj4gVGhlIGlkZWEgaXMgdGhhdCB5b3UgaW5jcmVhc2UgZmFzdGVyICh0aGFu IG9uZSBwYWNrZXQgcGVyIFJUVCkgaWYgdGhlIGRlbGF5IGlzDQo+IGxvdy4uLj8gTEVEQkFUIGFs cmVhZHkgcHJvdmlkZXMgdmFyaWFibGVzIGZvciB0aGlzIGtpbmQgb2YgdXNhZ2UsIGJ5IEdBSU4g YW5kDQo+IEFMTE9XRURfSU5DUkVBU0UuIFdvdWxkIGl0IGJlIGFuIG9wdGlvbiB0byB1c2UgdGhl c2UgdmFyaWFibGVzIGluc3RlYWQ/DQpbSUpdIFRoaXMgc2VjdGlvbiBkb2VzIG5vdCBkZWFsIHdp dGggdGhlIHVwZGF0ZSBvZiB0aGUgQ1dORCwgaW5zdGVhZCBpdCBwcm92aWRlcyANCndpdGggdGhl IGFiaWxpdHkgdG8gdHJhbnNtaXQgUlRQIHBhY2tldHMgZXZlbiB0aG91Z2ggYnl0ZXMgaW4gZmxp Z2h0IGV4Y2VlZHMgQ1dORCANCnVuZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4NCkFib3V0IENXTkQg dXBkYXRlcyA6IEluaXRpYWxseSBJIHRyaWVkIHRvIHVzZSB0aGUgTEVEQkFUIGFsZ29yaXRobSBh cyBpcy4gDQpJbiB0aGUgZW5kIEkgaGFkIHRvIHNldCBBTExPV0VEX0lOQ1JFQVNFIHRvIGEgdmVy eSBoaWdoIHZhbHVlIHRvIGF2b2lkIHRoYXQgDQppdCBsaW1pdGVkIENXTkQgZ3Jvd3RoIHRvIG11 Y2ggc28gSSBlbmRlZCB1cCByZW1vdmluZyB0aGUgbGluZQ0KY3duZCA9IG1pbihjd25kLCBtYXhf YWxsb3dlZF9jd25kKSBjb21wbGV0ZWx5LiBUaGUgcHJvYmxlbSBpcyB0aGUgc291cmNlIA0KKGJp dHJhdGUpIGxpbWl0YXRpb24gcHJvcGVydGllcyBvZiB0aGUgdmlkZW8gY29kZXIsIA0KYmVjYXVz ZSBvZiB0aGlzIHRoZSBjb25nZXRzaW9uIHdpbmRvdyBpcyBub3QgYWx3YXlzIHVzZWQgdG8gaXRz IGZ1bGwgZXh0ZW50LiANClRoZSBDV05EIGlzIGhvd2V2ZXIgbGltaXRlZCBieSBtZWFucyBvZiBj b25nZXN0aW9uIA0Kd2luZG93IHZhbGlkYXRpb24gYnV0IHRoZW4gb24gYSBsb25nZXIgdGltZXNj YWxlLg0KDQo+IA0KPiA3KSBPbmUgdmVyeSBnZW5lcmFsIGNvbW1lbnQ6IE1heWJlIGl0IHdvdWxk IGJlIGFuIG9wdGlvbiB0byBzZXBhcmF0ZSB0aGUNCj4gZnJhbWV3b3JrIGFuZCB0aGUgY29uZ2Vz dGlvbiBjb250cm9sIGV2ZW4gbW9yZSAoaW4gZGlmZmVyZW50IGRvY3VtZW50cykNCj4gc28gdGhh dCBvbmUgY291bGQgZXZlbiB1c2UgZGlmZmVyZW50IGNvbmdlc3Rpb24gY29udHJvbCBzY2hlbWVz Li4uPyBPciBhcmUNCj4gdGhlcmUgYW55IHJlYXNvbnMgd2h5IGV4cGxpY2l0bHkgTEVEQkFUIGlz IG5lZWRlZD8NCltJSl0gSSBiYXNlZCB0aGUgYWxnb3JpdGhtIG9uIExFREJBVCwgdGhlcmUgY291 bGQgYmUgb3RoZXIgY29uY2VwdHMgbGlrZSANCmRlbGF5IGdyYWRpZW50IGFsZ29yaXRobXMgdGhh dCBjYW4gZG8gZXF1YWxseSB3ZWxsLiBJdCBjYW4gYmUgYSBnb29kIGlkZWEgdG8gc3BsaXQgDQp1 cCBpbiBzZXZlcmFsIGRyYWZ0cy4gIA0KPiANCj4gU28gZmFyLi4uDQo+IA0KPiBNaXJqYQ0KDQo= From nobody Wed Oct 29 09:35:30 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BFF1A1B4D for ; Wed, 29 Oct 2014 09:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uJRnMt8AF75 for ; Wed, 29 Oct 2014 09:35:18 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A191A1B8F for ; Wed, 29 Oct 2014 09:34:40 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id k14so3735388wgh.1 for ; Wed, 29 Oct 2014 09:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ilB6kmm+3x76TmItyp/YOFdPW0Ov87+R17umdFPWgSM=; b=adOTTgsC74LyIInrF1y0cISjps+wLWbdS1xt5+OOFvstKI97240hesbUBhgJfn6c+u 2OuFqC1qiymSkOF/t2qLcH4Bp7v/hY6qQxElv1PyMpQ3nQxCBhcUnq+BFKhYWvSpMhVi 4mFxmb5qZPQml2Hc676VYtWeAYHrNBgbNIO8M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ilB6kmm+3x76TmItyp/YOFdPW0Ov87+R17umdFPWgSM=; b=Xu0tlxkrrWVbugLBYsHbIAOuBwg7voK1QsSF3hI2RVcmRHmTwScGGcnvR8Z4RC9K72 UmJh9ilDuTpFJ+Tb1VBW5lr8Z0Qde/fKflaH+NQdzxagaj98f81Zmbdc8UW1c32yNtNi 7nWHJOBmqx3sHUr6UydcNYzHtqoeh1iUPfHiVppwJQ5iFjiF88KZhiVtHLRlu0uzxhlg kl+yRWhN3W8JnXXM+WiyAclZWW9vQWranXoFXPAo0wajpMHiX6WrTQIsBAp4J9fuS8MI nImDtybH6wXyiuSwLT03Ct9xn/MQOq6taOvgxhwJ3vNiUdJFY5KR6w2wjrNTv85pZP0r PzbQ== X-Gm-Message-State: ALoCoQm/h8U0Ly1Bs1cs3zqbgzzmnKRGql/oIfuwqMJ3VgX0VYWtymZPass8SOpVzADNDlwrWN8nwqpKqBUdsV5oGprmRubIFZNhI64cBjpG/KSosG212TA= MIME-Version: 1.0 X-Received: by 10.194.186.207 with SMTP id fm15mr14199872wjc.1.1414600479126; Wed, 29 Oct 2014 09:34:39 -0700 (PDT) Received: by 10.194.240.36 with HTTP; Wed, 29 Oct 2014 09:34:39 -0700 (PDT) In-Reply-To: <20141027182704.18420.64429.idtracker@ietfa.amsl.com> References: <20141027182704.18420.64429.idtracker@ietfa.amsl.com> Date: Wed, 29 Oct 2014 17:34:39 +0100 Message-ID: From: Karen Elisabeth Egede Nielsen To: Zaheduzzaman Sarker , Randell Jesup , Randell Jesup Content-Type: multipart/alternative; boundary=047d7beb91020ece5c0506925790 X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/Xm8NKKosZTfNbzqEW4gYxfHOfYs Cc: rmcat WG Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:35:21 -0000 --047d7beb91020ece5c0506925790 Content-Type: text/plain; charset=UTF-8 Hi Zahed, Randell, As an individual I have made a quick read of version 07. I am generally very happy with the updates. Still I have a few comments which you make take into consideration: General Comments on the substance: #1: As stated in http://www.ietf.org/mail-archive/web/rmcat/current/msg00969.html, but also by others previously, I think that the text on the relation to the circuit breaker, right now placed in the draft-ietf-rmcat-app-interaction-0, should be lifted into this req doc. Possibly in the following form: RTP Circuit Breakers: The intent behind RTP circuit breakers [I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill switch of last resort, not true congestion control. The breakers should never trip when an effective congestion control is operating. An RMCAT congestion control algorithm should ensure that one never approaches a situations which may trigger the breakers. #2: In respect to Fred Bakers comment on having an explicit requirement on the algorithm to minimize self-induced latency, then while I agree that an algorithm that fulfills the requirements in the document need to support this requirement, then perhaps it might still be beneficial to extend the sub clause 1.B. to more explicitly address this issue also - e.g. - say (?) It should provide this as-low-as-possible-delay transit even when faced with intermediate bottlenecks and competing flows. Competing flows may limit what's possible to achieve. Special care must be taken for that the algorithm minimizes self-induced latency. Some detailed (mainly editorial) comments: 1.C: Suggest to replace: It is expected that the mechanism reacts to the routing change events in a way that avoids delay buildup. with: It is expected that the mechanism reacts to the effect of the routing changes in a way that avoids delay buildup. There are no explicit events I presume (?) 1.D: Is it correct to assume that what is meant more explicit here is: It is assumed that a local or remote interface change can generate an explicit notification to the algorithm. and if so, would it be relevant to clarify the text accordingly ? 1G. Note that this competing traffic may on a shared access link, may --> may exist ? Section 3: 2nd paragraph: TFRC's only consideration of loss events as congestion indication can be considered as biggest lacking looking at the current Internet deployment. --> (?) Looking at the current Internet deployment, looking at the current Internet deployment TFRC's consideration of only loss events as congestion indication, can be considered as the biggest lack of the algorithm. TFRC's only consideration of loss Looking at the current Internet deployment, TFRC's consideration for only loss events as congestion indication can be considered as biggest lacking 3rd paragraph: variance --> variant BR, Karen On 27 October 2014 19:27, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the RTP Media Congestion Avoidance > Techniques Working Group of the IETF. > > Title : Congestion Control Requirements for Interactive > Real-Time Media > Authors : Randell Jesup > Zaheduzzaman Sarker > Filename : draft-ietf-rmcat-cc-requirements-07.txt > Pages : 11 > Date : 2014-10-27 > > Abstract: > Congestion control is needed for all data transported across the > Internet, in order to promote fair usage and prevent congestion > collapse. The requirements for interactive, point-to-point real-time > multimedia, which needs low-delay, semi-reliable data delivery, are > different from the requirements for bulk transfer like FTP or bursty > transfers like Web pages. Due to an increasing amount of RTP-based > real-time media traffic on the Internet (e.g. with the introduction > of the Web Real-Time Communication (WebRTC)), it is especially > important to ensure that this kind of traffic is congestion > controlled. > > This document describes a set of requirements that can be used to > evaluate other congestion control mechanisms in order to figure out > their fitness for this purpose, and in particular to provide a set of > possible requirements for real-time media congestion avoidance > technique. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-cc-requirements-07 > > > 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/ > > --047d7beb91020ece5c0506925790 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Zahed, Randell,=C2=A0

As an individu= al I have made a quick read of version 07.
I am generally very ha= ppy with the updates. Still I have a few comments which you make take into = consideration:

General Comments on the substance:<= /div>

#1:

As stated in=C2=A0http://www.ietf.org/mail-archive/web/rmcat/current/msg0096= 9.html, but also by others previously, I think that the
text = on the relation to the circuit breaker, right now placed in the=C2=A0 draft-ietf-rmc= at-app-interaction-0, =C2=A0should be lifted into this req doc.
Pos= sibly in the following form:

RTP C= ircuit Breakers: The intent behind RTP circuit breakers= =C2=A0
[I-D.ietf-avtcore-rtp-circuit-breakers] is= to provide a kill=C2=A0
switch= =C2=A0of last resort, not true congestion control. The breakers should
never trip when an effective congestion control is operat= ing.=C2=A0
An RMCAT congestion control=C2=A0algorithm should ensure that one
never= approaches a situations which may trigger the=C2=A0breaker= s.


#2:
=

In respect to Fred Bakers comment on having an explicit requi= rement on the algorithm to=C2=A0minimize self-induced latency, then
while I agree that a= n algorithm that fulfills the requirements in the document=C2=A0need to support thi= s requirement, then perhaps=C2=A0
it might still be beneficial to extend = the sub clause 1.B. to more explicitly address this issue also - e.g. - say= (?)


It should provide this as=
-low-as-possible-delay transit even
            when faced with intermediate bottlenecks and competing
            flows.   Competing flows may limit what's possible to
            achieve. Special care must be taken for that the algorithm mini=
mizes=20
            self-induced latency.<=
br>


Some detailed (mainly editorial) c=
omments:


=

Su=
ggest to replace:
  It is expected that the mechanism reacts to
            the routing change events in a way that avoids delay
            buildup.
with:
 It is expected that the me=
chanism reacts to the effect of
            the routing changes in a way that avoids delay
            buildup.

There are no explicit events I pres=
ume (?)

1=
.D:
Is it correct to assume that wha=
t is meant more explicit here is:

It is assumed that a local or =
remote interface change can generate
            an explicit notification to the algorithm.


and if so, would it be relevan= t to clarify the text accordingly ?


1G.=C2=A0

Note that this c=
ompeting
            traffic may on a shared access link, 


may --=
> may exist ?


Section 3:

=
2nd paragraph:

TFRC's only consideration of loss
   events as congestion indication can be considered as biggest lacking
   looking at the current Internet deployment.
=

--> (?)
Looking at =
the current Internet deployment,=C2=A0looking at the curren=
t Internet deployment TFRC's consideration of only loss=

   events as congestion indication, can=
 be considered as the biggest lack of the algorithm.
   TFRC's only cons=
ideration of loss
  =C2=A0

   Looking at the current I=
nternet deployment, TFRC's=C2=A0consideration for only
   loss events as congestion indication can be considered as b=
iggest lacking
   
3rd paragraph:<=
/pre>
<=
span style=3D"white-space:normal">
variance --> variant


BR, Karen


On 27 October 2014 19:27, <internet-drafts@ietf= .org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the RTP Media Congestion Avoidance Techn= iques Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Congestion Control Requirements for Interactive Real-Time Media
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rand= ell Jesup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Zaheduzzaman Sarker
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rmcat-cc-requirements-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-10-27

Abstract:
=C2=A0 =C2=A0Congestion control is needed for all data transported across t= he
=C2=A0 =C2=A0Internet, in order to promote fair usage and prevent congestio= n
=C2=A0 =C2=A0collapse.=C2=A0 The requirements for interactive, point-to-poi= nt real-time
=C2=A0 =C2=A0multimedia, which needs low-delay, semi-reliable data delivery= , are
=C2=A0 =C2=A0different from the requirements for bulk transfer like FTP or = bursty
=C2=A0 =C2=A0transfers like Web pages.=C2=A0 Due to an increasing amount of= RTP-based
=C2=A0 =C2=A0real-time media traffic on the Internet (e.g. with the introdu= ction
=C2=A0 =C2=A0of the Web Real-Time Communication (WebRTC)), it is especially=
=C2=A0 =C2=A0important to ensure that this kind of traffic is congestion =C2=A0 =C2=A0controlled.

=C2=A0 =C2=A0This document describes a set of requirements that can be used= to
=C2=A0 =C2=A0evaluate other congestion control mechanisms in order to figur= e out
=C2=A0 =C2=A0their fitness for this purpose, and in particular to provide a= set of
=C2=A0 =C2=A0possible requirements for real-time media congestion avoidance=
=C2=A0 =C2=A0technique.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-= requirements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rmcat-cc-requiremen= ts-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmc= at-cc-requirements-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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


--047d7beb91020ece5c0506925790-- From nobody Wed Oct 29 11:31:14 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034C21A87D1 for ; Wed, 29 Oct 2014 11:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_3W8eKg3hKy for ; Wed, 29 Oct 2014 11:31:08 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09E51A87D0 for ; Wed, 29 Oct 2014 11:31:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F19B6D930E; Wed, 29 Oct 2014 19:31:04 +0100 (MET) 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 MA2ZfFuXgV9F; Wed, 29 Oct 2014 19:31:04 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A1D8ED930C; Wed, 29 Oct 2014 19:31:04 +0100 (MET) Message-ID: <54513268.8070107@tik.ee.ethz.ch> Date: Wed, 29 Oct 2014 19:31:04 +0100 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ingemar Johansson S , Zaheduzzaman Sarker , "rmcat@ietf.org" References: <544FB321.40800@tik.ee.ethz.ch> <81564C0D7D4D2A4B9A86C8C7404A13DA320034CF@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA320034CF@ESESSMB205.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/BzSl3hYyijeHMovCWRYJz9kkD1g Subject: Re: [rmcat] Comments on draft-johansson-rmcat-scream-cc-03 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 18:31:12 -0000 Hi Ingemar, see inline.. On 29.10.2014 10:31, Ingemar Johansson S wrote: > Hi > > Many thanks for the comments/questions. > My, hopefully comprehensible, answers inline below, marked with [IJ]. > > /Ingemar > >> -----Original Message----- >> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >> Sent: den 28 oktober 2014 16:16 >> To: Zaheduzzaman Sarker; Ingemar Johansson S; rmcat@ietf.org >> Subject: Comments on draft-johansson-rmcat-scream-cc-03 >> >> Hi Ingemar, hi Zahed, >> >> I have a couple of questions/comments (as an individual contributor) on your >> draft. This is not a full review as I'm just addressing a couple of aspects which >> came to my mind immediately when reading (in random order). >> >> 1) RTCP feedback >> - You might want to think about which calculations should be done at the >> receiver and which at the sender. For LEBDAT it is proposed to calculate the >> the OWD at the receiver but you could probably even find a way to calculate >> the average (queuing) delay at the receiver and e.g. send the feedback only >> once an RTT. In fact if you implement a maximum increase rate, as in LEDBAT, >> of one packet per RTT, it's fine if you only update once per RTT as smaller >> updates will not open a packet window. > [IJ] So far I have focused on getting SCReAM robust. For various reasons I ended > up with all processing in the sender and timely feedback. But it is possible that one > can do as you suggest above. The ACK-clocking may need to be solved in some > other way then as it becomes necessary to predict how many new bytes the next ACK will > acknowledge in order to keep a steady stream of packets. > But that can maybe be solved, also in cases where OWD increases suddenly > it is possible to send an early feedback. > Question is how much one can save with this in terms of RTCP overhead?. > Digged in the LTE simulation logs. I ran the simulations with a video source that > had a max bitrate of 1.5Mbps. > I use reduce sized RTCP for the feedback and a full compound RTCP is transmitted > every 2 seconds, AVP regular mode with 70kbps RTCP BW is used. > I get an RTCP bitrate of maximum 14kbps, in practise one feedback is transmitted > roughly once per video frame. 14kbps is not too much to worry about and it is definitely > much less than 70kbps. > But it can perhaps become an issue if the bandwidth in the two directions are > highly assymetric or in certain conferencing scenarios. My point just was if it is possible to reduce overhead without (strong) performance degradation, we should do that. However, if there are good reasons to do it this way, you should (simply) state these reasons. > >> >> - If you don't need a reliable transport, you don't actually need a real ack- >> number. All you need is the number of newly received bytes no matter if in >> order or not. However, later on (at the end of section 4.1.1.1) you say loss >> could be detected by holes in the sequence number space. For actually >> detecting 'holes' you would even need something like SACK. I guess you >> instead assume dup ACK as in TCP...? Again I don't think it is needed to copy >> TCP completely.. > [IJ] I would say that one get something like TCP SACK, instead of acknowledgement > of byte sequences. The loss detection is given by the ACK list. > I don't use TCP dupACK counting, instead I use a margin to cover possible reordering. > For instance, if sequence number SN is the highest acknowledged sequence number > the the algorithm looks for loss indications for SN-5 or earlier. The benefit with an ACK > list is that already there get support for retransmission and similar functionality as > RFC4585 Generic NACK. Ah now that I look at Figure 1 that's clear. The text is less clear... > >> >> - RFC6679 specifies ECN feedback for RTP > [IJ] Yes, thing is that I am looking more at the accurate ECN for TCP in TCP as one > anyway has access to timely and frequent feedback in SCReAM. This may however > change if one can get less frequent fedback to work. >> >> 2) self-clocking >> In the intro you say scream is self-clocked but the transmission scheduling >> (section 4.1.2) says '[packets] are scheduled at intervals given by t_pace'. In >> this case you just need sent-out timers and there is no self-clocking >> anymore...? > [IJ] The pacing is set such that new RTP packets are clocked at intervals given by the > estimated bandwidth, given by the CWND and the RTT, and the size of the most > recently transmitted RTP packet. The pacing is there to break up coalescing tendencies > that I have seen in simulations. It does not do away with the self-clocking as the basic > rule that bytes in flight must still be satisfied. I'd interpret the terminology here differently. If you don't use the ack arrival as trigger to send out new packets but use timers instead, that's not self-clocked anymore. As you have a congestion window it's still the packet conservation principle but you don't use the ack clock. > >> >> 3) Variables >> It's hard to follow all the variables you introduce. I would propose to have a >> section where you introduce all variables at once. Further, just based on the >> fact that there are quite a lot variables, would it be possible to reduce the >> number of variables (and thereby even simplify the algorithm without a large >> performance degradation)? >> Due to my thesis a recently re-read a lot of the congestion control evaluation >> and design literature and there is actually (e.g. in Jain's 'Congestion >> Avoidance in Computer Networks...') also some kind of requirement for >> simplicity because this allows better assessment of question on robustness. >> So for me personally my next step is to review my own algorithm (in my >> thesis) and try to make to make it simpler and evaluate how much >> performance this would cost... > [IJ] You are right, I will try to do this better next time, a section with all the > variables in one place is probably a good start. > Some parts of the algorithm can actually be stripped away, for instance the > OWD trend computation is there to reduce the jitter, also there are parts in > the video rate control parts that can be removed. The end result may be > more jitter but it may be easier to understand the algorithm description > May reintroduce the pseudo code later on as it may make things more > comprehensible. > >> >> 4) loss decrease by 0.8 >> Why 0.8? Also, and i know this is often not correctly done in most existing >> algorithms (in TCP Cubic), you should decrease by at 0.5 after Slow Start, as >> you have doubled the window before. However as you don't slow start that >> often, that's probably not a real problem. > [IJ] This is set based on experimentation against TCP (NewReno) based file > transfers over the same CoDel or PIE AQM equipped bottleneck. > If I set the CWND scale in SCReAM to 0.5 i.e reduce by 50% istf 20% I see that the file > transfer outcompetes SCReAM. I believe this happens because SCReAM has a video > source with limited bitrate, while the file transfer has "unlimited" source bitrate. Okay, I'm okay to have a higher value that 0.5 but you should reason it and I'm not sure if saying you've tested it in a couple of scenarios is enough of reasoning. Is there an explanation why Scream has to be more aggressive (in the decrease behavior)...? > >> >> 5) Conditions for owd_target adjustments >> - I not sure I really understand the conditions: >> " >> o owd_mem > owd_target >> >> o owd_target > owd_target_lo >> " >> >> The first condition, is actually the condition where LEDBAT decreases the >> window. At the same time you would want to increase the target. That >> doesn't sound very stable... >> The second condition I don't understand because you start with >> owd_target=owd_target_lo but then you never increase it if it is not larger >> than owd_target_lo... so you never increase...? > owd_mem is an average OWD. Normally this should not exceed owd_target > too much or too often but in case this happens it may be an indication of competing > flows and that the owd_target may need to be increased, depending on outcome of the > subsequent algorithm steps. > The second condition indicates that the owd_target is raised to make SCReAM cope with > competing flows. In that case it is necessary to check if it is possible to reduce owd_target > if for instance the competing flow has completed. Ah, so that's one or the other condition have to be true not both at the same time...? I would split this up because the first one is the condition to raise owd_target while the second might reduce owd_target, right? > >> >> - One minor comment on the same section (4.1.1.7): you say the average >> OWD should be zero (after restart) but you mean the queuing delay should >> be zero (because the OWD includes the end-to-end delay), right? > [IJ] OWD in this draft is the one way extra delay. i.e only the queuing delay, > guess I need to clarify this. >> >> - In general I'm not too sure about the idea of interrupting video (also >> audio?)... > [IJ] No audio is not interrupted as it is not transmission scheduled by SCRaAM. > Only video is interrupted, one can argue how good it is but I have yet to find > another method that can make SCReAM work well against competing TCP over > tail drop links and that at the same time does not create self-inflicted congetsion > in wireless access such as LTE (and possibly even WiFi). > Possibly the shared bottleneck detection (SBD) can be useful here ?. There was > some questions around the behavior/performance in WiFi access, and I am too > among the curious. I know audio has a much lower rate but should also be congestion controlled. And interrupting the video can also be very annoying especially if you do that very often. Maybe you have to put a limit how often this probing is done. > >> >> 6) transmission decision >> Could you explain the the second condition (in section 4.1.2.1) a little more. >> The idea is that you increase faster (than one packet per RTT) if the delay is >> low...? LEDBAT already provides variables for this kind of usage, by GAIN and >> ALLOWED_INCREASE. Would it be an option to use these variables instead? > [IJ] This section does not deal with the update of the CWND, instead it provides > with the ability to transmit RTP packets even though bytes in flight exceeds CWND > under certain conditions. > About CWND updates : Initially I tried to use the LEDBAT algorithm as is. > In the end I had to set ALLOWED_INCREASE to a very high value to avoid that > it limited CWND growth to much so I ended up removing the line > cwnd = min(cwnd, max_allowed_cwnd) completely. The problem is the source > (bitrate) limitation properties of the video coder, > because of this the congetsion window is not always used to its full extent. > The CWND is however limited by means of congestion > window validation but then on a longer timescale. Why don't you just increase cwnd instead on sending packets even though cwnd would not allow to do so. Where is the difference? ALLOWED_INCREASE was meant to limit the burstiness. As you use pacing this is not a problem for you anyway. However I would prefer to still have ALLOWED_INCREASE set to high value instead of removing it completely. Did you also try to use GAIN because this would be the right parameter, I believe. > >> >> 7) One very general comment: Maybe it would be an option to separate the >> framework and the congestion control even more (in different documents) >> so that one could even use different congestion control schemes...? Or are >> there any reasons why explicitly LEDBAT is needed? > [IJ] I based the algorithm on LEDBAT, there could be other concepts like > delay gradient algorithms that can do equally well. It can be a good idea to split > up in several drafts. Also re-inserting the code in the appendix is probably still helpful... Mirja >> >> So far... >> >> Mirja > From nobody Thu Oct 30 04:07:35 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C201AD0B1 for ; Thu, 30 Oct 2014 04:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VooADTYdDAol for ; Thu, 30 Oct 2014 04:07:29 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98FC71AD087 for ; Thu, 30 Oct 2014 04:07:28 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-c0-54521bedf72a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 58.53.04387.DEB12545; Thu, 30 Oct 2014 12:07:26 +0100 (CET) Received: from [150.132.141.93] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.174.1; Thu, 30 Oct 2014 12:07:25 +0100 Message-ID: <54521BEB.8090807@ericsson.com> Date: Thu, 30 Oct 2014 12:07:23 +0100 From: Zaheduzzaman Sarker Organization: Ericsson AB User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Karen Elisabeth Egede Nielsen , Randell Jesup , Randell Jesup References: <20141027182704.18420.64429.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje476aAQg7ZLfBaHWmeyWJzdlmXR OPkds8Xqmx/YHFg8liz5yeTxYfk6No9Dz4MCmKO4bFJSczLLUov07RK4MtbvfMBWMEu24vXB XywNjEvEuxg5OSQETCTePrrPAmGLSVy4t54NxBYSOMIo8edpVBcjF5C9hlHi9/o9jCAJXgFt iR03Z7CD2CwCqhJtBw8ydTFycLAJ2Eg8XuwHEuYXkJTY0LCbGcQWFYiSuHOpnxWiVVDi5Mwn LCAzRQQ6GCU2fpsHVsQsICtx/e1OsMXCAh4SB5Z3sEAsbmOU2DHlKNhiToFAiRe3r7BCNFhI LH5zkB3Clpdo3jqbGeQIIQFdia6XcRMYhWYh2TcLSccsJB0LGJlXMYoWpxYX56YbGemlFmUm Fxfn5+nlpZZsYgQG+MEtv612MB587niIUYCDUYmH98PDwBAh1sSy4srcQ4zSHCxK4rwLz80L FhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDI1eS7fF9MzY4l23a09aV9n2dp6SImvuSab841 1pLwBy+XzXcM9impVnswZ2vOt4Olz/neroyd5aB48PietDMltQ6PvES1Kvdx7vNuCrv68kdP pq5LaRvf1bwN25bM6myuiuetqV7iWmBoe/CgfrXHiuZtU3huRt76JKaRwPxtvuj6V2vV+1SU WIozEg21mIuKEwGT3+afUQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/Sym0z5iwRwadvDgOIENTQ-R205I Cc: rmcat WG Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 11:07:33 -0000 On 2014-10-29 17:34, Karen Elisabeth Egede Nielsen wrote: > Hi Zahed, Randell, > > As an individual I have made a quick read of version 07. > I am generally very happy with the updates. Still I have a few comments > which you make take into consideration: > > General Comments on the substance: > > #1: > > As stated in > http://www.ietf.org/mail-archive/web/rmcat/current/msg00969.html, but > also by others previously, I think that the > text on the relation to the circuit breaker, right now placed in the > draft-ietf-rmcat-app-interaction-0, should be lifted into this req doc. > Possibly in the following form: > > RTP Circuit Breakers: The intent behind RTP circuit breakers > [I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill > switch of last resort, not true congestion control. The breakers should > never trip when an effective congestion control is operating. AN RMCAT congestion control will control a subset of flows that will be available in the network and the congestion may not only be caused by the RTP flows. In my understanding the media timeout and RTCP timeout circuit breaker can still trip no matter how effective congestion control is operating. Among the circuit breaker triggers those two usually means something went really wrong in the communication path like link failure, severe congestion by other flows. > An RMCAT congestion control algorithm should ensure that one > never approaches a situations which may trigger the breakers. Do you mean an RMCAT congestion will work as a circuit breaker as well and the requirements also includes that a RMCAT congestion algorithm should also be able to influence other traffics on the path as well? I guess not. It is our expectation that any RTP application which supposed to generate huge amount of traffic must implement circuit breaker but in reality that may not be the case. An application which does not implement circuit breaker can use a RMCAT congestion control solution and vice versa. To me the important thing is "An RMCAT congestion control algorithm should be able to effectively functional in the presence or absence of RTP circuit breaker". It is "expected to operate within the constraints defined by these circuit breakers (as written in the circuit breaker draft, it is and "expected" behavior)" when circuit breaker is present and that it should not cause congestion collapse when circuit breaker is not implemented. > > > #2: > > In respect to Fred Bakers comment on having an explicit requirement on > the algorithm to minimize self-induced latency, then > while I agree that an algorithm that fulfills the requirements in the > document need to support this requirement, then perhaps > it might still be beneficial to extend the sub clause 1.B. to more > explicitly address this issue also - e.g. - say (?) > > > It should provide this as-low-as-possible-delay transit even > when faced with intermediate bottlenecks and competing > flows. Competing flows may limit what's possible to > achieve. Special care must be taken for that the algorithm minimizes > self-induced latency. > > Sounds good to me. > > Some detailed (mainly editorial) comments: > > All your editorials looks great. thanks. > BR -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Services, Media and Network Features Laboratoriegränd 11 97128 Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== From nobody Thu Oct 30 06:35:40 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A761AD241 for ; Thu, 30 Oct 2014 06:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1UX9s-IDuzi for ; Thu, 30 Oct 2014 06:35:33 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D46C1AD213 for ; Thu, 30 Oct 2014 06:34:20 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so3680243wgh.39 for ; Thu, 30 Oct 2014 06:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=NTcbKjPA3S5RBnSKZwkVtIAvojFtfYVVR4fvYgAPVP0=; b=Dzaedadh4esY9AUTemx1W+4polgJqHaGEbTgF4CZVDaiY5/gmd9u4gjng20oD1jTFs ZGhjVbwjEbsnbqtSvPcXbS65RYTJ5vQ2BkJW8zSq3VDHD1FfSRW/dQIsQifuVeceb2G9 6QPmC2Sb3d4UL70Bwg8HS6KKJ0zHbhfuCgiuQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=NTcbKjPA3S5RBnSKZwkVtIAvojFtfYVVR4fvYgAPVP0=; b=ML9XdnIsNAgR+0oa/7qyiH4HbGK/NIAga3RfRyIc9eP9xKiNF48lzC+rdmU1QuHvXh Yr/TRtXx3bOHzoBBQU3jH/mIK9e8Q2x4N0yvEaYs1xyUSfCdBN26MNamIBSE38Wv9dSW xJGQZ0cXqJcRYwVb3456GGIx15xSNlaTqaRQTazEFZiID2UWEPNZjvMZLPVfvqb8rTAy Zyx9/wo51fza2IFPXlDce5zcMo1xSZcOjMehhe+90WhQRAZ7FcpNyKXC+TgbKi7PJNQH NBh7cep1f9hSuNcYsSnWQEN5ZGAHGMlEUPDorFCq6dzqkWH+hQ+t7WHH4sA1ab9rxvWG jlzw== X-Gm-Message-State: ALoCoQlFvCH/MQgD0ArrA1D888eTPTZovRHRO25MDmCC67YLBeiko9hcAucxxG8i9EdEU7/Zptgyutcf8BFLaAs5U82s0ByFh+AZNPoJDiS8VH7JJZAX2kU= X-Received: by 10.180.211.70 with SMTP id na6mr19867780wic.3.1414676058434; Thu, 30 Oct 2014 06:34:18 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20141027182704.18420.64429.idtracker@ietfa.amsl.com> <54521BEB.8090807@ericsson.com> In-Reply-To: <54521BEB.8090807@ericsson.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI4AqIjp6bGsdg9EwX9iFbsOHr/kAHciq4HAugGitWbUmF+UA== Date: Thu, 30 Oct 2014 14:34:17 +0100 Message-ID: <59ef1bef12d457c5f934d87680712c68@mail.gmail.com> To: Zaheduzzaman Sarker , Randell Jesup , Randell Jesup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/jwxJB7qcLhc8PttsXj0zFuUBK5A Cc: rmcat WG Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:35:35 -0000 Hi Zahed, >> #1: >> >> As stated in >> http://www.ietf.org/mail-archive/web/rmcat/current/msg00969.html, but >> also by others previously, I think that the text on the relation to >> the circuit breaker, right now placed in the >> draft-ietf-rmcat-app-interaction-0, should be lifted into this req doc. >> Possibly in the following form: >> >> RTP Circuit Breakers: The intent behind RTP circuit breakers >> [I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill switch of >> last resort, not true congestion control. The breakers should never >> trip when an effective congestion control is operating. >AN RMCAT congestion control will control a subset of flows that will be >available in the network and the congestion may not only be caused by the >RTP flows. In my understanding the media timeout and RTCP timeout circuit >breaker can still trip no matter how effective congestion control is >operating. >Among the circuit breaker triggers those two usually means something went >really wrong in the communication path like link failure, severe congestio= n >by >other flows. >> An RMCAT congestion control algorithm should ensure that one never >> approaches a situations which may trigger the breakers. > Do you mean an RMCAT congestion will work as a circuit breaker as well > and >the requirements also includes that a RMCAT congestion algorithm should >also >be able to influence other traffics on the path as well? I guess not. Agree. > >It is our expectation that any RTP application which supposed to generate >huge amount of traffic must implement circuit breaker but in reality that >may >not be the case. An application which does not implement circuit breaker >can >use a RMCAT congestion control solution and vice versa. > >To me the important thing is "An RMCAT congestion control algorithm shoul= d >be able to effectively functional in the presence or absence of RTP circui= t >breaker". It is "expected to operate within the constraints defined by >these >circuit breakers (as written in the circuit breaker draft, it is and >"expected" >behavior)" when circuit breaker is present and that it should not cause >congestion collapse when circuit breaker is not implemented. > Would it then not be relevant to add this last paragraph (slightly reformulated) to the requirement doc ? BR, Karen > >BR >-- > >Zahed > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >ANM ZAHEDUZZAMAN SARKER > > >Ericsson AB >Services, Media and Network Features >Laboratoriegr=C3=A4nd 11 >97128 Lule=C3=A5, Sweden >Phone +46 10 717 37 43 >Fax +46 920 996 21 >SMS/MMS +46 76 115 37 43 >zaheduzzaman.sarker@ericsson.com >www.ericsson.com > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D From nobody Thu Oct 30 06:45:15 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526381AD210 for ; Thu, 30 Oct 2014 06:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQBP6ePliSBr for ; Thu, 30 Oct 2014 06:45:12 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C941AD1D5 for ; Thu, 30 Oct 2014 06:45:12 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-57-545240e52cfd Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EA.8B.04387.5E042545; Thu, 30 Oct 2014 14:45:10 +0100 (CET) Received: from [150.132.141.93] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.174.1; Thu, 30 Oct 2014 14:45:09 +0100 Message-ID: <545240E3.6080503@ericsson.com> Date: Thu, 30 Oct 2014 14:45:07 +0100 From: Zaheduzzaman Sarker Organization: Ericsson AB User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Karen Elisabeth Egede Nielsen , Randell Jesup , Randell Jesup References: <20141027182704.18420.64429.idtracker@ietfa.amsl.com> <54521BEB.8090807@ericsson.com> <59ef1bef12d457c5f934d87680712c68@mail.gmail.com> In-Reply-To: <59ef1bef12d457c5f934d87680712c68@mail.gmail.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje4zh6AQg6VTWS0Otc5ksTi7Lcui cfI7ZovVNz+wObB4LFnyk8njw/J1bB6HngcFMEdx2aSk5mSWpRbp2yVwZZydsZ614DVHxdpP GxgbGKexdzFyckgImEic/z+RFcIWk7hwbz1bFyMXh5DAEUaJ87d7mCCcNYwSz1esBOvgFdCW mN+1hAXEZhFQlTj44idQNwcHm4CNxOPFfiBhfgFJiQ0Nu5lBbFGBKIk7l/pZIVoFJU7OfMIC MlNEoINRYuO3eWBFzAKyEtff7mQDsYUFPCQOLO9ggVh8g1HizoFNYMs4BewkDrx7yAbRYCGx +M1BdghbXqJ562xmkCOEBHQlul7GTWAUmoVk3ywkHbOQdCxgZF7FKFqcWlycm25kpJdalJlc XJyfp5eXWrKJERjiB7f8ttrBePC54yFGAQ5GJR7eDw8DQ4RYE8uKK3MPMUpzsCiJ8y48Ny9Y SCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6OhrrJtY3pHTmTEBe4zCXV638MOLn6Qu1FCUMU4 Q2XVRsZ5S/oCC0+XndKNFDn2KyPOR/LdtsWu+8/7fohRCWd0miZixr/jdcCkh68sFbXmX7c2 qp5ZZHTnyA7pyKQqgT+sWxab2Ut/yfg5teDNlTMC5wTurAs7eoqlfcHuW8LzgxtuzKq2F1Ni Kc5INNRiLipOBAA3K8+9UgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/1-k4AHl6jl2T_fsOgMswL8JlD6s Cc: rmcat WG Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:45:14 -0000 On 2014-10-30 14:34, Karen Elisabeth Egede Nielsen wrote: >> To me the important thing is "An RMCAT congestion control algorithm should >> be able to effectively functional in the presence or absence of RTP circuit >> breaker". It is "expected to operate within the constraints defined by >> these >> circuit breakers (as written in the circuit breaker draft, it is and >> "expected" >> behavior)" when circuit breaker is present and that it should not cause >> congestion collapse when circuit breaker is not implemented. >> > > Would it then not be relevant to add this last paragraph (slightly > reformulated) to the requirement doc ? Are you suggesting to add it as a new requirement? or as a general discussion (perhaps in the intro). BR Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Services, Media and Network Features Laboratoriegränd 11 97128 Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== From nobody Thu Oct 30 07:07:54 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017DE1AD386 for ; Thu, 30 Oct 2014 07:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt3nIKqS9-pL for ; Thu, 30 Oct 2014 07:07:46 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C73A1AD38D for ; Thu, 30 Oct 2014 07:05:32 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id bs8so4633698wib.17 for ; Thu, 30 Oct 2014 07:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ezGjDWl+z6DQsrWQlLqSwOKjuUaCUNZk7c1E9ftML0k=; b=a8X5a3dtF1a67gqRNn2QmNo7HpfsM3sY/r8mBsDafsl/VuFteiq5syvjaFh9RlMqkd 7MyP0EsF0SkOQrAeQEnKQxtbaaMrFdzQBK/Jo2buwJW/etcHSLQblMVsieub5JPsFI2D JFZja1rFv6cQ4ErJQxHq/864mCS6oSb0eSoUE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ezGjDWl+z6DQsrWQlLqSwOKjuUaCUNZk7c1E9ftML0k=; b=Gq//N7vfVnXUjriJbMh76yg8kQVJppk80SRkwXzxEZUo1OBzQc9UDeLAlFuGPjz1do uYiqnMPMcuMxrnJC8KTyb2hQNoQ27WK2G9aFTpuNkmCWae+Cyu35RFPnroghJRy7IBtT NFNTV6sy0rsjh0Qdb4FlACVmaP1GQQROtqmvaYM2rHUQuj6GVAjA9ZY7KhKD6faD9eAz ot76NXuuAy0O3IBhb7lqc3DasM7hmc8E6hHEO8wI4xWHPb+hfx2WXHMvCrxW3U9GgZ2J 1zt9SDqR2ha4uYIHw0/ywN77z4yuj6ZgbdH5+1ElsHKssmoDE9n+26updw6IkyM6t5RO ntmQ== X-Gm-Message-State: ALoCoQkTKM5/nZfzAPK5Kt0ZvyPUMShzGByBqKs0eGiM55d4nlXmrnVafSDjKyYKkrkiRHB2jTOENVS8gbWB6WKK7pZX7P0+HwNguVuWlNvqvE19FIj/uIQ= X-Received: by 10.194.61.208 with SMTP id s16mr3970165wjr.104.1414677930504; Thu, 30 Oct 2014 07:05:30 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20141027182704.18420.64429.idtracker@ietfa.amsl.com> <54521BEB.8090807@ericsson.com> <59ef1bef12d457c5f934d87680712c68@mail.gmail.com> <545240E3.6080503@ericsson.com> In-Reply-To: <545240E3.6080503@ericsson.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI4AqIjp6bGsdg9EwX9iFbsOHr/kAHciq4HAugGitUB6sGXWgJs1Vg4my+qh/A= Date: Thu, 30 Oct 2014 15:05:29 +0100 Message-ID: To: Zaheduzzaman Sarker , Randell Jesup , Randell Jesup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/Su3zgv9fA0gfCLyssz1D2el6wto Cc: rmcat WG Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 14:07:48 -0000 Interworking with circuit breaker and prevention of collapse when circuit breaker is not active to me sounds like requirements. The same may goes for the statement from the app interaction reformulated, e.g., in the following way: The RMCAT congestion control should constrain the traffic under its control so that the circuit breaker only may trip as a consequence of issues exterior to the RMCAT congestion control, like link path failures or severe congestion caused by traffic flows not under RMCAT congestion control. My personal preference would be to have this become an explicit new requirement (with subclauses). Would you rather like to see this be discussed in the introduction only ? BR, Karen > RTP Circuit Breakers: The intent behind RTP circuit breakers > [I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill switch of > last resort, not true congestion control. The breakers should never > trip when an effective congestion control is operating. AN RMCAT congestion control will control a subset of flows that will be available in the network and the congestion may not only be caused by the RTP flows. In my understanding the media timeout and RTCP timeout circuit breaker can still trip no matter how effective congestion control is operating. Among the circuit breaker triggers those two usually means something went really wrong in the communication path like link failure, severe congestion by other flows. > An RMCAT congestion control algorithm should ensure that one never > approaches a situations which may trigger the breakers. Do you mean an RMCAT congestion will work as a circuit breaker as well an= d the requirements also includes r the statements from the app interaction stated in the following way: But I >-----Original Message----- >From: Zaheduzzaman Sarker [mailto:zaheduzzaman.sarker@ericsson.com] >Sent: 30. oktober 2014 14:45 >To: Karen Elisabeth Egede Nielsen; Randell Jesup; Randell Jesup >Cc: rmcat WG >Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt > > > >On 2014-10-30 14:34, Karen Elisabeth Egede Nielsen wrote: >>> To me the important thing is "An RMCAT congestion control algorithm >>> should be able to effectively functional in the presence or absence >>> of RTP circuit breaker". It is "expected to operate within the >>> constraints defined by these circuit breakers (as written in the >>> circuit breaker draft, it is and "expected" >>> behavior)" when circuit breaker is present and that it should not >>> cause congestion collapse when circuit breaker is not implemented. >>> >> >> Would it then not be relevant to add this last paragraph (slightly >> reformulated) to the requirement doc ? > >Are you suggesting to add it as a new requirement? or as a general >discussion >(perhaps in the intro). > > >BR > >Zahed > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >ANM ZAHEDUZZAMAN SARKER > > >Ericsson AB >Services, Media and Network Features >Laboratoriegr=C3=A4nd 11 >97128 Lule=C3=A5, Sweden >Phone +46 10 717 37 43 >Fax +46 920 996 21 >SMS/MMS +46 76 115 37 43 >zaheduzzaman.sarker@ericsson.com >www.ericsson.com > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D From nobody Thu Oct 30 08:38:39 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81301AD439 for ; Thu, 30 Oct 2014 08:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JeNlmoxeu4y for ; Thu, 30 Oct 2014 08:38:35 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA8E1A0151 for ; Thu, 30 Oct 2014 08:38:35 -0700 (PDT) X-AuditID: c1b4fb2d-f79fc6d000001087-23-54525b794818 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.57.04231.97B52545; Thu, 30 Oct 2014 16:38:33 +0100 (CET) Received: from [150.132.141.93] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.174.1; Thu, 30 Oct 2014 16:38:32 +0100 Message-ID: <54525B77.40109@ericsson.com> Date: Thu, 30 Oct 2014 16:38:31 +0100 From: Zaheduzzaman Sarker Organization: Ericsson AB User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Karen Elisabeth Egede Nielsen , Randell Jesup , Randell Jesup References: <20141027182704.18420.64429.idtracker@ietfa.amsl.com> <54521BEB.8090807@ericsson.com> <59ef1bef12d457c5f934d87680712c68@mail.gmail.com> <545240E3.6080503@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+JvjW5ldFCIQftWRYtDrTNZLM5uy7Jo nPyO2WL1zQ9sDiweS5b8ZPL4sHwdm8eh50EBzFFcNimpOZllqUX6dglcGQda/7IVzBOp6Dh9 gqWBcYlAFyMHh4SAicSBLTJdjJxAppjEhXvr2boYuTiEBI4wSqx5uJgJJCEksIZR4urPYhCb V0BT4vSFo8wgNouAqsS3KS9YQOawCdhIPF7sBxLmF5CU2NCwG6xEVCBK4s6lflaIVkGJkzOf sIDMFxHoYJTY+G0eWBGzgKzE9bc72UBsYQEPiQPLO1ggjljFJHHu1A2wBKeAncSrx9+YIBos JBa/OcgOYctLNG+dzQxyhJCArkTXy7gJjEKzkOybhaRjFpKOBYzMqxhFi1OLi3PTjYz1Uosy k4uL8/P08lJLNjECw/vglt+6OxhXv3Y8xCjAwajEw/vhYWCIEGtiWXFl7iFGaQ4WJXHeRefm BQsJpCeWpGanphakFsUXleakFh9iZOLglGpg9A18w3tyR5P0l6k12rz+yX/eamZW8xoZNxiK RzMY6rItcJE9mnqwqDmQ76V3zmKG3cd+7ijxdzae8HL+ro8BvUxGRzd9/5PTsICnlWVzqvhj fuF+0dpXfTXhMTGHvOT3HRS8r72F/6OpvmZXskX0Fp1HXgKn7NetOF0eN8HrxWJ76fb6+1FK LMUZiYZazEXFiQDiDqmlUAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/uRsVeHh7mJLUetLHJnOrFQ8XF9M Cc: rmcat WG Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-07.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:38:38 -0000 On 2014-10-30 15:05, Karen Elisabeth Egede Nielsen wrote: > Interworking with circuit breaker and prevention of collapse when circuit > breaker is not active to me sounds like requirements. > > The same may goes for the statement from the app interaction reformulated, > e.g., in the following way: > > The RMCAT congestion control should constrain the traffic under its control > so that the circuit breaker only may trip as > a consequence of issues exterior to the RMCAT congestion control, like link > path failures or severe congestion caused by traffic flows not under RMCAT > congestion control. > > My personal preference would be to have this become an explicit new > requirement (with subclauses). > Would you rather like to see this be discussed in the introduction only ? > If we define requirements on the relationship between circuit breaker and RMCAT congestion control algorithm then I think we will have to state more than what is stated above (explaining how the requirement can be realize when RTP/AVPF is used). The circuit breaker draft states - "Receiving rapid feedback about congestion events potentially allows congestion control algorithms to be more responsive, and to better adapt the media transmission to the limitations of the network. It is expected that many RTP congestion control algorithms will adopt the RTP/AVPF profile for this reason, defining new transport layer feedback reports that suit their requirements. Since these reports are not yet defined, and likely very specific to the details of the congestion control algorithm chosen, they cannot be used as part of the generic RTP circuit breaker.". This is a general wisdom that RMCAT congestion control algorithms with use RTP/AVPF. Correct me if I am wrong but we are yet to see the impact of circuit breaker when used with RTP/AVPF. I was thinking that we can keep the relationship between the generic circuit breaker and congestion control algorithm as "expected" not as "required". Then we have eval guideline which can outline how to evaluate to candidate RMCAT Algorithms when circuit breaker is available and not available. BR -- Zahed ================================================== ANM ZAHEDUZZAMAN SARKER Ericsson AB Services, Media and Network Features Laboratoriegränd 11 97128 Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ================================================== From nobody Thu Oct 30 17:38:00 2014 Return-Path: X-Original-To: rmcat@ietfa.amsl.com Delivered-To: rmcat@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8B31A8988 for ; Thu, 30 Oct 2014 17:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 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, HTML_OBFUSCATE_10_20=0.093, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IoXaqYvQUl7 for ; Thu, 30 Oct 2014 17:37:56 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AEB1A88B1 for ; Thu, 30 Oct 2014 17:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1414715876; x=1446251876; h=from:to:subject:date:message-id:mime-version; bh=ur/4gmelowx1HhdpX4dKS1o9uqGFsoN01/GYkgAFyAQ=; b=f4KsJOt4kX/GD1gChvWPP/TH3qnOiLWy5EAajlEYWaVaa7dYuIkVxvrH ajxplEx4tJWcjd0vpJLymlNnJh0DnQekv0HvfKvS6r+Ye+ZUmLj7fXoVy hC1RsVaNkAPa0POriq/gX8dpOok96FZj+ls86rNnJO4jwnkESKyBrT2o5 M=; X-IronPort-AV: E=McAfee;i="5600,1067,7607"; a="80111919" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Oct 2014 17:37:55 -0700 X-IronPort-AV: E=Sophos;i="5.07,290,1413270000"; d="scan'208,217";a="766370816" Received: from nasanexhc02.na.qualcomm.com ([10.46.56.110]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 30 Oct 2014 17:37:55 -0700 Received: from NASANEXM01D.na.qualcomm.com (129.46.53.246) by NASANEXHC02.na.qualcomm.com (10.46.56.110) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 30 Oct 2014 17:37:55 -0700 Received: from NASANEXM01E.na.qualcomm.com (10.46.201.191) by NASANEXM01D.na.qualcomm.com (129.46.53.246) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 30 Oct 2014 17:37:54 -0700 Received: from NASANEXM01E.na.qualcomm.com ([10.46.201.191]) by NASANEXM01E.na.qualcomm.com ([10.46.201.191]) with mapi id 15.00.0913.011; Thu, 30 Oct 2014 17:37:54 -0700 From: "Van Der Auwera, Geert" To: "rmcat@ietf.org" Thread-Topic: delay recovery phase Thread-Index: Ac/0h1WVO6v5I3xETHieiC/HSBKY6A== Date: Fri, 31 Oct 2014 00:37:54 +0000 Message-ID: <479bbc3c4afe41cc8c8226c71a96de2c@NASANEXM01E.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_479bbc3c4afe41cc8c8226c71a96de2cNASANEXM01Enaqualcommco_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/BLXrsxll4xaGdQJ0jFds-AuqGrY Subject: [rmcat] delay recovery phase X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 00:37:59 -0000 --_000_479bbc3c4afe41cc8c8226c71a96de2cNASANEXM01Enaqualcommco_ Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Hi all, I would like to start a discussion about potential sender CC behavior when = the link rate suddenly down-switches and as a result there is significant d= elay buildup due to receiver CC detection delay, feedback message delay, et= c. Assuming that the sender receives a TMMBR message (or similar) with the = new max target bit rate, in this approach, the sender initiates a delay rec= overy phase (rate undershoot) to recover the delay of the buffered data as = described in more details below. If people think that this topic is of inte= rest, I could provide experimental results during the meeting (5min. presen= tation). Thanks. Best regards, Geert Summary: At time instant t0, the link rate decreases suddenly from R0 to R1. Since t= here is a response delay =C4T at the sender, the sending rate is decreased = at time t1 (t0 + =C4T). The delay increases fast from D0 to D1 during =C4T.= To reduce the built up delay quickly, the sending rate is decreased to Ru = (

Hi all,

 

I would like to start a discussion about potential s= ender CC behavior when the link rate suddenly down-switches and as a result= there is significant delay buildup due to receiver CC detection delay, fee= dback message delay, etc. Assuming that the sender receives a TMMBR message (or similar) with the new max tar= get bit rate, in this approach, the sender initiates a delay recovery phase= (rate undershoot) to recover the delay of the buffered data as described i= n more details below. If people think that this topic is of interest, I could provide experimental results= during the meeting (5min. presentation). Thanks.

 

Best regards,

 

Geert

 

 

Summary:

 

At time instant t0, the link rate decreas= es suddenly from R0 to R1. Since there is a response = delay =C4T at the sender, the sending rate is decreased at time t1 (t0 + =C4T). The delay increases fast from D0 to D1 during =C4T. To reduce the built = up delay quickly, the sending rate is decreased to Ru (<R1) at time t1 for a period of time =C4Tu durin= g which the delay is reduced. After time =C4Tu the rate is increased to R1.

 

The problem is to estimate =C4T at the sender side i= n order to compute =C4Tu. The receiver sends a minimal compound = RTCP packet including the RR and TMMBR message to the sender with the estim= ated maximum bit rate for the forward link. Typically, the receiver will send this message immediately after con= gestion is detected. With this information, the sender can make an estimate= of =C4T as the time difference between the sending time of the RTCP SR (re= ferenced in the RR by LSR) and the time that the RR+TMMBR is received, assuming that the congestion was d= etected at the receiver side after this particular SR was received.

--_000_479bbc3c4afe41cc8c8226c71a96de2cNASANEXM01Enaqualcommco_--